RFC 2836

Per Hop Behavior Identification Codes

📅 published May 2000, from ietf

Per Hop Behavior Identification Codes 🎀

Part 1 of 2 💖

Okay bestie, the title block first 📋. This is RFC 2836, "Per Hop Behavior Identification Codes" 🦋. It came out of the Network Working Group in May 2000 and was written by S. Brim, B. Carpenter, and F. Le Faucheur. It's on the Standards Track 🔥. The header doesn't list anything it obsoletes or updates.

Status of this Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Table of Contents 🌸

   1. Introduction................................................. 1
   1.1. Usage Scenarios............................................ 2
   2. Encoding..................................................... 3
   3. IANA Considerations.......................................... 4
   4. Security considerations...................................... 4
   References...................................................... 4
   Authors' Addresses.............................................. 5
   Intellectual Property........................................... 6
   Full Copyright Statement........................................ 7

1. Introduction 🍓

Okay so, Differentiated Services [RFC 2474, RFC 2475] brought in the idea of Per Hop Behaviors (PHBs) 💅. A PHB describes how traffic in a particular behavior aggregate gets treated at one individual network node 🧚. In IP packet headers, though, PHBs don't show up by name. You get Differentiated Services Codepoint (DSCP) values instead 🫶. There are only 64 possible DSCP values, but there's no limit on how many PHBs you can have, so it's giving mismatch 😭. Inside any given network domain, there's a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings 🙈.

Sometimes you need to identify a specific PHB inside a protocol message 💬. Think messages that negotiate bandwidth management or path selection, especially when those messages travel between management domains. Work that's still in progress includes communication between bandwidth brokers, and MPLS support of diffserv 🔥.

Other times, what you need to identify isn't one PHB but a whole set of them 👑. One example is a set of PHBs that must follow the same physical path to prevent re-ordering ✨. An instance of this is the set of three PHBs in a single Assured Forwarding class, like AF11, AF12 and AF13 [RFC 2597] 🌈.

This document defines a binary encoding that uniquely identifies PHBs and/or sets of PHBs in protocol messages 💖. This encoding MUST be used when such identification is required 💅.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🎀.

1.1. Usage Scenarios 🦋

Diffserv services are expected to run over a bunch of different underlying technologies, which for this discussion we're loosely calling "link layers" 🌸. For carrying IP packets, some of these link layers use connections or logical connections, and the forwarding behavior each link layer device gives is a property of that connection 🔥. So inside the link layer domain, each link layer node schedules traffic based on which connection the traffic is riding in 👑. Examples of these "link layers" include ATM and MPLS 💜.

To support diffserv efficiently over these link layers, one model is to send different Behavior Aggregates (BAs), or sets of Behavior Aggregates, over different connections 🧚. That way each one gets its own different and appropriate forwarding behavior inside the link layer cloud ✨. When those connections get set up dynamically to carry diffserv traffic, it's super useful to say, at connection establishment time, which forwarding behavior(s) each connection should get from the link layer device 💅. That way the BAs experience consistent forwarding behavior inside the link layer cloud 🫶. You do this by putting the encoding of the matching PHB, or set of PHBs, from this document into the connection establishment signaling messages 🎀. For details on how some MPLS label distribution protocols (RSVP and LDP) propose to use PHB encodings for Diff-Serv over MPLS, see [MPLS-DS] 📚.

There's another approach too 🌈. The ATM Forum needs to indicate desired IP QOS treatments in ATM signaling, so ATM switches can support the wanted service just as well as IP forwarders do 💖. To do that, the Forum is defining a new VC call setup information element that will carry PHB identification codes 🦋. (It'll be generalized to do more if needed 🍓.)

2. Encoding 🔥

PHBs and sets of PHBs get encoded in an unsigned 16 bit binary field 💅.

The 16 bit field is laid out as follows 💜:

Case 1: PHBs defined by standards action, as per [RFC 2474] 👑.

The encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero 🌸. Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping 🙈.

The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1 ✨. (So for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1 🧚.)

    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  |         DSCP          | 0   0   0   0   0   0   0   0   X   0 |
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Case 2: PHBs not defined by standards action, i.e. experimental or local use PHBs as allowed by [RFC 2474] 🦋. In this case, an arbitrary 12 bit PHB identification code, assigned by the IANA, is placed left-justified in the 16 bit field 🌈. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs 💖. Bits 12 and 13 are zero 🎀.

    0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
  |                      PHB id code              | 0   0   X   1 |
  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Bits 12 and 13 are reserved, either for expanding the PHB identification code later or for other use at some point in the future 👑.

Okay bestie, so the Internet Society owns the copyright here, and it's Copyright (C) The Internet Society (2000). All Rights Reserved. 🦋

Here's the good news. You're allowed to copy this document and share it with others, and you can even make derivative works 💅 that comment on it, explain it, or help people implement it. You can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🎀. The one condition is that the copyright notice and this paragraph have to be included on all those copies and derivative works. Periodt. 💖

Now the not-so-fun part. You can't modify this document itself 🙈. That includes things like removing the copyright notice or the references to the Internet Society or other Internet organizations. There are two exceptions. First, you can do it when you need to develop Internet standards, but then you have to follow the copyright procedures defined in the Internet Standards process. Second, you can do it to translate the document into languages other than English 🌈.

Also, these permissions are perpetual ⭐. The Internet Society, its successors, and its assigns will never revoke them. Iconic. 👑

Last thing, and it's a bit of a serious one 🥺. This document and the information in it are provided on an "AS IS" basis. THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. So basically, no guarantees. Use it with your eyes open 👀💀.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society, for keeping the RFC Editor running 🧚💜.

📦 where this page comes from