RFC 3140
Per Hop Behavior Identification Codes
Per Hop Behavior Identification Codes 💖
okay bestie, here's the vibe check on this one 🎀
RFC 3140, Per Hop Behavior Identification Codes Authors: D. Black, S. Brim, B. Carpenter, F. Le Faucheur (Network Working Group) Category: Standards Track 📜 Date: June 2001 🗓️ Obsoletes: RFC 2836 (this one replaces it 👑). It doesn't list anything it updates.
Status of This Memo ✨
this doc is an Internet standards track protocol for the Internet community, and it's literally 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 Notice 💅
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract 🦋
so this doc defines a 16 bit encoding mechanism for identifying differentiated services Per Hop Behaviors (PHBs) inside protocol messages 🧚 and it replaces RFC 2836 🍓
Table of Contents 📚
1. Introduction.................................................2
1.1. Usage Scenarios............................................2
2. Encoding.....................................................3
3. Signalling the Class Selector Codepoints.....................4
4. IANA Considerations..........................................5
5. Security Considerations......................................5
Changes from RFC 2836...........................................5
Acknowledgements................................................6
References......................................................6
Authors' Addresses..............................................6
Intellectual Property...........................................7
Full Copyright Statement........................................81. Introduction ✨
okay so Differentiated Services [RFC 2474, RFC 2475] brought in the idea of Per Hop Behaviors (PHBs) 💜 which describe how traffic in a particular behavior aggregate gets treated at one network node. the thing is, IP packet headers don't say "this is a PHB" 🙈 they carry Differentiated Services Codepoint (DSCP) values instead. there are only 64 possible DSCP values, but there's no limit on how many PHBs there can be 😭 inside any network domain, there's a locally defined mapping between DSCP values and PHBs. standardized PHBs recommend a DSCP mapping, but network operators are allowed to pick different mappings 💅
sometimes you need to name a specific PHB inside a protocol message 🎀 like when a message is negotiating bandwidth management or path selection, especially when it's passing between management domains. work that's currently in progress includes communication between bandwidth brokers and MPLS support of diffserv 🌸
other times you don't need one PHB, you need a whole set of them 🧚♀️ one example is a set of PHBs that have to follow the same physical path so packets don't get re-ordered. the set of three PHBs in a single Assured Forwarding class, like AF11, AF12 and AF13 [RFC 2597], is one of those 🍓
this doc defines a binary encoding that uniquely identifies PHBs and/or sets of PHBs in protocol messages 🦋 this encoding MUST be used when that identification is required ✨
this doc replaces RFC 2836, which didn't think about the Class Selector codepoints 🙈
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 underlying technologies, which we're loosely calling "link layers" for this discussion 💖 for moving IP packets, some of these link layers use connections (or logical connections), and the forwarding behavior each link layer device supports is a property of that connection. basically, inside the link layer domain, each link layer node schedules traffic based on which connection the traffic rides on 🫶 examples of these "link layers" include ATM and MPLS 💜
for diffserv to work efficiently over these link layers, one model is to send different Behavior Aggregates (BAs) (or sets of Behavior Aggregates) over different connections, so each gets different (and appropriate) forwarding behaviors inside the link layer cloud ✨ when those connections are set up dynamically for diffserv traffic, it's super useful to say, at connection setup time, which forwarding behavior(s) each connection should get from the link layer device 😭 that way the BAs experience consistent forwarding inside the link layer cloud. you do this by putting the encoding of the matching PHB (or set of PHBs), as defined in this doc, into the connection establishment signaling messages 🎀 details on how some MPLS label distribution protocols (RSVP and LDP) use PHB encodings to support Diff-Serv over MPLS can be found in [MPLS-DS] 🧚
the other approach is that the ATM Forum needs a way to indicate desired IP QOS treatments in ATM signaling, so ATM switches can support the desired service just as well as IP forwarders do 👑 the Forum is defining a new VC call setup information element that will carry PHB identification codes (although it will be generalized to do more if needed) 💅
2. Encoding 🦋
PHBs and sets of PHBs are 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 🫶 and note that the recommended DSCP value MUST be used, even if the network in question has picked a different mapping 😭
the encoding for a set of PHBs is the numerically smallest of the encodings for the PHBs in the set, with bit 14 set to 1. (so for the AF1x PHBs, the encoding is the one for AF11, 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, meaning experimental or local use PHBs that [RFC 2474] allows 🧚 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 or for other use at some point in the future 🔮
in both cases, when a single PHBID is used to identify a set of PHBs (i.e., bit 14 is set to 1), that set of PHBs MUST constitute a PHB Scheduling Class. (meaning that using PHBs from the set MUST NOT cause intra-microflow traffic reordering when different PHBs from the set are applied to traffic in the same microflow 😭🔥) the set of AF1x PHBs [RFC 2597] is an example of a PHB Scheduling Class 👑 sets of PHBs that don't count as a PHB Scheduling Class can still be identified, by using more than one PHBID 💜
3. Signalling the Class Selector Codepoints 🌈
[RFC 2474] defines the eight DS codepoint values of the form 'xxx000' (where x may be '0' or '1') as the Class Selector Codepoints 💖 codepoint 000000 is the recommended DSCP value for the Default PHB, so the Case 1 PHBID built from that codepoint is what signals the Default PHB (see Section 2 above) 🫶
for convenience, and to keep things consistent with networks that use IP Precedence [RFC 1812], the Case 1 format PHBIDs built from the other seven Class Selector Codepoints may also be used to signal PHBs 🧚 in each case, the PHB signaled by such a PHBID is the PHB that the embedded class selector codepoint (or the IP Precedence value that matches it in non-diffserv domains) gets mapped to in the recipient's network 🎀 different networks will use different mappings, so check Section 4 of [RFC 2474] for more 🍓
any specified use of PHBIDs SHOULD allow the use of the eight Case 1 PHBIDs built from the Class Selector Codepoints 💅
4. IANA Considerations 📜
IANA is requested to create a new assignment registry for "Per-Hop Behavior Identification Codes", initially allowing values in the range 0 to 4095 decimal 🔢
assigning a value in this field requires:
- the identity of the assignee 🫶
- a brief description of the new PHB, with enough detail to tell it apart from existing standardized and non-standardized PHBs. for a set of PHBs, this description should cover all the PHBs in the set ✨
- a reference to a stable document that describes the PHB in detail 📚
during the first year this registry exists, IANA is requested to refer all requests to the IETF diffserv WG for review 🧚 after that, requests should be reviewed by the IETF Transport Area Directors or by an expert they designate 👑
if the number of assignments starts to approach 4096, the Transport Area Directors should be alerted. 🚨
5. Security Considerations 💀
okay this part is serious 😭 this encoding in itself raises no security issues. however, users of this encoding should consider that modifying a PHB identification code may count as theft or denial of service, so protocols using this encoding MUST be adequately protected 🔥
just signalling a PHBID SHOULD NOT be enough to give the sender access to a PHB they wouldn't otherwise be able to use 🙅♀️ in cases where this is an issue, receivers SHOULD treat received PHBIDs as requests for service, and use local policy to decide whether to grant or deny those requests 🛡️💅
Changes from RFC 2836 🦋
[RFC 2836] didn't consider the Class Selector code points, which are covered by section 3 of this document 🎀 a clarification was added at the end of section 2 for the case of PHB Scheduling Classes 💜 and the second paragraph of section 5 was added too ✨
Acknowledgements 🫶
useful comments were made by members of the IETF Diffserv working group 💖
References 📚
Okay bestie, here's the reading list for everything this doc leans on 💖
- [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
- [RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
- [RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
- [RFC 2836] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
- [MPLS-DS] Le Faucheur, F., et al., "MPLS Support of Differentiated Services", Work in Progress.
Authors' Addresses 💌
The three humans who wrote this, with their contact details 🦋
David L. Black
EMC Corporation
42 South St.
Hopkinton, MA 01748
EMail: black_david@emc.comScott W. Brim
146 Honness Lane
Ithaca, NY 14850
USA
EMail: sbrim@cisco.comBrian E. Carpenter
IBM
c/o iCAIR
Suite 150
1890 Maple Avenue
Evanston, IL 60201
USA
EMail: brian@icair.orgFrancois Le Faucheur
Cisco Systems
Petra B - Les Lucioles
291, rue Albert Caquot
06560 Valbonne
France
EMail: flefauch@cisco.comIntellectual Property 🧠
Okay, this part is the legal stuff, but it's important so let's go 🫶
The IETF doesn't take a position on whether any intellectual property or other rights that someone might claim over the tech in this document are valid or in scope, or on whether any license for those rights is available. It also doesn't say it has searched for any such rights. If you want to know how the IETF handles rights for standards-track and standards-related documents, check out BCP-11. Any claims of rights that were filed for publication, and any assurances of licenses that were promised, can be requested from the IETF Secretariat. The same goes for the result of any attempt to get a general license or permission for implementers or users to use those proprietary rights.
The IETF also invites anyone to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to practise this standard. Send that info to the IETF Executive Director 📬
Full Copyright Statement 📜
Copyright (C) The Internet Society (2001). All Rights Reserved. ✨
You can copy and share this document, translations included, and you can make derivative works that comment on or explain it, or that help people implement it. You can prepare, copy, publish, and distribute those, in whole or in part, without any kind of restriction, as long as the copyright notice and this paragraph are on every copy and derivative work 💖
The one catch is that this document itself may not be modified in any way. That covers removing the copyright notice or the references to the Internet Society or other Internet organizations. The exception is when it's needed for developing Internet standards, in which case the copyright procedures in the Internet Standards process have to be followed. It also covers translating it into languages other than English.
These limited permissions are perpetual and won't be revoked by the Internet Society or its successors or assigns 🌈
This document and the information in it are provided on an "AS IS" basis, and 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. 💀
Acknowledgement 🙏
Funding for the RFC Editor function is currently provided by the Internet Society. Thank you to them for keeping the lights on 🌸
📦 where this page comes from
- ietf: rfc3140 2001-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms