RFC 4859

RFC 4859 at a Glance 🎀

Okay bestie, here's the vibe check. This is RFC 4859, titled Codepoint Registry for the Flags Field in the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Session Attribute Object ✨. It was written by Adrian Farrel from Old Dog Consulting (email adrian@olddog.co.uk) and published in April 2007. It's Informational, so it's giving "here's some info," not "you must do this." 💅 The title block doesn't list anything it obsoletes or updates, so it's a fresh little doc with no drama 🌸

Status of This Memo 📝

This memo is for the Internet community to read 💖 It isn't an Internet standard of any kind, and it can be shared freely with no restrictions.

Copyright Notice ©️

Copyright is held by The IETF Trust, 2007 🫶

Abstract 🦋

This doc tells IANA how to make a brand new codepoint registry for the flags field in the Session Attribute object. That object lives in RSVP-TE signaling messages used for Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) signaling. It's the whole setup for keeping track of those bits, honestly iconic 👑

1. Introduction ✨

Okay so RSVP [RFC2205] got a glow-up into RSVP for Traffic Engineering (RSVP-TE) so it could handle MPLS signaling [RFC3209] and GMPLS [RFC3473]. Main character energy 💅

[RFC3209] introduced the Session Attribute object, which rides along on the RSVP Path message. That object has an eight-bit flags field, and the original RSVP-TE spec gave meaning to three of those bits. Later MPLS and GMPLS RFCs claimed more flags 🌈

We need a registry to track which bits are used, so no bit gets assigned twice, and to define how new bits can be claimed. That's the whole point 🔥

This document lists the bits that are already in use and gives IANA what it needs to create the registry. It does NOT define what the bits do. The real rules for each bit live in the RFCs it references, so go check those for the deets 🙈

2. Existing Usage 🍓

2.1. RFC 3209

[RFC3209] uses three bits, like this:

0x01  Local protection desired

0x02  Label recording desired

0x04  SE Style desired

2.2. RFC 4090

[RFC4090] uses two bits, like this:

0x08  Bandwidth protection desired

0x10  Node protection desired

2.3. RFC 4736

[RFC4736] uses one bit, like this:

0x20  Path re-evaluation request

3. Security Considerations 🔐

Okay, this informational doc exists purely to make an IANA registry, and registries like this help protect the IETF process against denial-of-service attacks. That's serious business, babe 😭

Aside from that, this document has no other security considerations.

4. IANA Considerations 📋

IANA has made a new codepoint registry, and here's the tea:

• It lives under the "RSVP-TE Parameters" branch of the tree 🌳
• It's called "Session Attribute Object Flags" 🎀
• New flags can only be assigned through IETF consensus [RFC2434] 🫶
• It already references the flags described in Section 2 of this document 💜

5. Acknowledgements 💖

Huge thanks to JP Vasseur, Bill Fenner, and Thomas Narten for reviewing this document. You're iconic, all three of you ✨

6. References 📚

6.1. Normative References

• [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification", RFC 2205, September 1997.
• [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
• [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
• [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.

6.2. Informative References

• [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
• [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "Reoptimization of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, November 2006.

Author's Address 🦋

Adrian Farrel, Old Dog Consulting, adrian@olddog.co.uk 💌

Full Copyright Statement ©️

Copyright is held by The IETF Trust, 2007. This document is covered by the rights, licenses, and restrictions in BCP 78, and beyond what that says, the authors keep all their rights 🔒

The document and everything in it is provided "AS IS." The contributor, the organization they represent or are sponsored by (if any), the Internet Society, the IETF Trust, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes no warranty that using the information won't infringe any rights, and no implied warranties of merchantability or fitness for a particular purpose 💀

Intellectual Property 🌸

The IETF doesn't take a position on whether any Intellectual Property Rights might apply to the technology in this document, or whether licenses would be available for it. It also doesn't claim to have searched for any such rights. If you want the rules around rights in RFC documents, check BCP 78 and BCP 79 📖

Copies of IPR disclosures sent to the IETF Secretariat, plus any license assurances or results from attempts to get general permission for implementers or users, are posted in the IETF's online IPR repository at http://www.ietf.org/ipr. If anyone knows about copyrights, patents, patent applications, or other proprietary rights that could cover technology needed to implement this standard, the IETF wants to hear about it at ietf-ipr@ietf.org 🫶

Acknowledgement 🌈

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