RFC 3210

Applicability Statement for Extensions to RSVP for LSP-Tunnels 🎀

okay bestie, first the paperwork 📋 this is RFC 3210 from the Network Working Group, dated December 2001. It's Informational 🌸 which means it's giving info, not a standard. The authors are D. Awduche (Movaz Networks), A. Hannan (Routingloop), and X. Xiao (Photuris). It doesn't list anything it obsoletes or updates ✨

Status of this Memo 💅

this memo is here to provide information for the Internet community 💖 it does not specify an Internet standard of any kind, and distribution of it is unlimited 🦋

Copyright Notice 🌈

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

Abstract 🧚

this memo talks about how "Extensions to RSVP (Resource ReSerVation Protocol) for LSP Tunnels" should be applied in practice 🔥 it covers the protocol's principles of operation and the network context it was designed for, plus deployment guidelines and the known limitations 💜 it's meant to go along with the submission of "Extensions to RSVP for LSP Tunnels" onto the Internet standards track, so it's basically the sidekick to that spec 👑

1.0 Introduction ✨

okay so service providers and users have been very clear that they NEED traffic engineering in IP networks 😭 these capabilities can be built on Multiprotocol Label Switching (MPLS) and run on label switching routers (LSRs) from different vendors, as long as they all speak the same signaling and label distribution protocol 🫶 the requirements for traffic engineering in MPLS based IP networks are described in [2] 🎀 so there's a real need for an open, non-proprietary, standards based signaling and label distribution protocol for the MPLS traffic engineering application, one that lets LSRs from different vendors interoperate. it's giving teamwork 🌸

the "Extensions to RSVP for LSP tunnels" (RSVP-TE) specification [1] was built by the IETF MPLS working group to cover exactly that 💅 RSVP-TE is a mix of several related proposals that went into the MPLS working group ✨ it has all the objects, packet formats, and procedures you need to establish and maintain explicit label switched paths (LSPs) 👑 explicit LSPs are foundational to the traffic engineering application in MPLS based IP networks, no cap 🔥 and beyond traffic engineering, the RSVP-TE specification may have other uses within the Internet 🦋

this memo describes how the RSVP-TE specifications [1] apply. it highlights the principles of operation, explains the network context they were developed for, offers guidelines for deployment, and points out known protocol limitations 💖

this applicability statement is only about using RSVP to set up unicast LSP-tunnels 🧚 it's noted that not every feature described in RFC2205 [3] is required to support setting up and maintaining LSP-tunnels 💜 anything about supporting other RSVP features and capabilities on an implementation that also does LSP-tunnels is out of scope for this doc 🙈 but supporting those extra features shouldn't introduce new security vulnerabilities in environments that only use RSVP to set up LSP-tunnels 🫶 that part is a whole vibe check ngl 😭

this applicability statement does not rule out other signaling and label distribution protocols for the traffic engineering application in MPLS based networks 🌈 service providers are free to deploy whatever signaling protocol meets their needs 💅

so here's the tea 🍓 CR-LDP [6] and RSVP-TE [1] are two signaling protocols that do similar jobs in MPLS networks. right now there's no consensus on which one is technically superior 🤷‍♀️ so network administrators should pick between the two based on their needs and their particular situation ✨

2.0 Technical Overview of Extensions to RSVP for LSP Tunnels 🦋

okay this is the main event 🎀 the RSVP-TE specification extends the original RSVP protocol by giving it new capabilities that support the following functions in an MPLS domain:

(1) downstream-on-demand label distribution
(2) instantiation of explicit label switched paths
(3) allocation of network resources (e.g., bandwidth) to
    explicit LSPs
(4) rerouting of established LSP-tunnels in a smooth fashion
    using the concept of make-before-break

(5) tracking of the actual route traversed by an LSP-tunnel
(6) diagnostics on LSP-tunnels
(7) the concept of nodal abstraction
(8) preemption options that are administratively controllable

the spec adds several new RSVP objects, like LABEL-REQUEST, RECORD-ROUTE, LABEL, EXPLICIT-ROUTE, and new SESSION objects 💜 it also defines new error messages so exception conditions can be reported ✨ all of the new RSVP-TE objects are optional with respect to the RSVP protocol, except LABEL-REQUEST and LABEL, which are both mandatory for setting up LSP-tunnels 🔥 that's the one I'd remember at the party 😭

two big things make RSVP-TE different from the original RSVP protocol [3] 👑

the first difference is that the RSVP-TE specification [1] is meant for label switching routers (as well as hosts) to set up and maintain LSP-tunnels and to reserve network resources for those tunnels 💅 the original RSVP specification [3] was for hosts to request and reserve network resources for micro-flows 🌸

the second difference is that RSVP-TE generalizes the concept of "RSVP flow." 🌈 an RSVP session can now be an arbitrary aggregation of traffic (based on local policies) between the originating node of an LSP-tunnel and the tunnel's egress node 🧚 to be definite, in the original RSVP protocol [3], a session was a data flow with a particular destination and transport layer protocol 💖 in RSVP-TE, a session is implicitly the set of packets that get the same MPLS label value at the originating node of an LSP-tunnel 🦋 labels can be assigned based on all sorts of criteria, and they might even cover all packets (or subsets of them) between the tunnel's endpoints 💅 since traffic gets aggregated, the number of LSP-tunnels (and so the number of RSVP sessions) doesn't grow in proportion to the number of flows in the network ✨ this is a huge deal because RSVP-TE [1] tackles a major scaling issue with the original RSVP protocol [3]: the massive amount of system resources you'd otherwise need to manage reservations and keep state for potentially thousands or even millions of RSVP sessions at micro-flow granularity 😭🔥

for a technical description of the RSVP-TE protocol specification, go read [1] 🫶

---

part 1 done, bestie! part 2 is coming with Section 3.0 and Section 4.0 💜🎀

5.0 Limitations 🚧

okay so bestie, let's talk about what RSVP-TE can't do 🙈 It only supports unicast LSP-tunnels, so no multicast LSP-tunnels. Multicast is just not supported, sorry, not sorry 💅

It also only does unidirectional LSP-tunnels. Bidirectional LSP-tunnels are not supported, so you can't have one tunnel doing both directions in one go 🦋

Then there's the soft state thing. RSVP is kinda clingy: it has to keep sending refresh messages on a regular schedule to keep established LSP-tunnels alive, and ngl that's a real concern 😭 People have submitted several proposals to the RSVP working group to fix this, and you can check out e.g. [5] if you want the deep dive 🌸

6.0 Conclusion ✨

so to wrap up the whole applicability chat: this document talked about where the "Extensions to RSVP for LSP Tunnels" spec fits. It added a bunch of enhancements to RSVP that make it useful in places where the original RSVP protocol would've been totally inappropriate 💜 And the context where RSVP-TE really shines is traffic engineering in MPLS based IP networks. Iconic behaviour, honestly 👑

7.0 Security Considerations 💀

okay this part is serious, so listen up 🫶 This document doesn't introduce any new security issues. BUT the RSVP-TE spec adds new opaque objects to RSVP, which means the security considerations for the original RSVP protocol are still very much relevant. Don't skip them!!

And when this stuff is deployed in service provider networks, it is mandatory to make sure that only authorized entities are allowed to start setting up LSP-tunnels. Not optional, not a vibe, a must 🔥

8.0 Acknowledgments 🎀

the authors gave a big shoutout to the folks who gave useful comments during the initial review of this memo on the MPLS WG mailing list: Eric Gray, John Renwick, and George Swallow. Thank you, legends 🫶

9.0 References 📚

[1]   Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G. and V.
      Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels," RFC
      3209, December 2001.

[2]   Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
      McManus, "Requirements for Traffic Engineering Over MPLS," RFC
      2702, September 1999.

[3]   Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
      "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
      Specification", RFC 2205, September 1997.

[4]   Rosen, E., Viswanathan, A. and R. Callon, "A Proposed
      Architecture for MPLS", RFC 3031, January 2001.

[5]   Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
      Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
      2961, April 2001.

[6]   Jamoussi, B. et al, "Constraint-Based LSP Setup using LDP,"
      Work in Progress.

10.0 Authors' Addresses 🌈

these are the people who wrote it, so here's where to find them 💖

Daniel O. Awduche
Movaz Networks
7926 Jones Branch Drive, Suite 615
McLean, VA 22102

EMail: awduche@movaz.com
Voice: +1 703-298-5291

Alan Hannan
RoutingLoop
112 Falkirk Court
Sunnyvale, CA 94087

EMail: alan@routingloop.com
Voice: +1 408 666-2326

XiPeng Xiao
Photuris Inc.
2025 Stierlin Ct.
Mountain View, CA 94043

EMail: xxiao@photuris.com
Voice: +1 650-919-3215

11.0 Full Copyright Statement ⭐

Copyright (C) The Internet Society (2001). All Rights Reserved. 💜

okay the legal bit, but make it cute 🎀 This document and its translations can be copied and shared with others, and derivative works that comment on it or help implement it can be made, copied, published, and distributed, in whole or in part, with no restrictions at all. The catch is that the above copyright notice and this paragraph have to be on every copy and derivative work. This document itself cannot be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when it needs translating into languages other than English.

The limited permissions above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Forever and ever 🧚

This document and the information in it is 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 for keeping the lights on 🌸