RFC 3209
RSVP-TE: Extensions to RSVP for LSP Tunnels
RFC 3209: RSVP-TE: Extensions to RSVP for LSP Tunnels 🎀
okay so bestie, this one is the RFC that taught RSVP how to build LSP tunnels, and it's giving main character energy 🦋 It was published in December 2001 as an Internet standards track document from the Network Working Group, and it's RFC 3209. It doesn't list any RFCs it obsoletes or updates in its header.
The authors, all from networking companies that were absolutely cooking at the time:
- D. Awduche, Movaz Networks, Inc. ✨
- L. Berger, Juniper Networks, Inc. 💜
- D. Gan, Juniper Networks, Inc. 💜
- T. Li, Procket Networks, Inc. 🌸
- V. Srinivasan, Cosine Communications, Inc. 🍓
- G. Swallow, Cisco Systems, Inc. 👑
Status of this Memo
okay so this document is an Internet standards track protocol for the Internet community 💅 It's also asking people for discussion and suggestions for improvements, so bring your ideas! 🫶 If you want to know where this protocol actually stands, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 🌈
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.Abstract
so this document explains how to use RSVP (Resource Reservation Protocol), plus all the extensions it needs, to set up label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching) 🔥 The vibe is that the flow along an LSP is completely identified by the label applied at the ingress node of the path. Because of that, these paths can be treated as tunnels 🧚 A big reason anyone cares is traffic engineering with MPLS, which is specified in RFC 2702.
we're adding several new objects to RSVP so it can set up explicitly routed label-switched paths while using RSVP as the signaling protocol 💖 The end result is label-switched tunnels that can be routed automatically away from network failures, congestion, and bottlenecks. Iconic behaviour, honestly ✨
Contents
1 Introduction .......................................... 3
1.1 Background ............................................. 4
1.2 Terminology ............................................ 6
2 Overview .............................................. 7
2.1 LSP Tunnels and Traffic Engineered Tunnels ............. 7
2.2 Operation of LSP Tunnels ............................... 8
2.3 Service Classes ........................................ 10
2.4 Reservation Styles ..................................... 10
2.4.1 Fixed Filter (FF) Style ................................ 10
2.4.2 Wildcard Filter (WF) Style ............................. 11
2.4.3 Shared Explicit (SE) Style ............................. 11
2.5 Rerouting Traffic Engineered Tunnels ................... 12
2.6 Path MTU ............................................... 13
3 LSP Tunnel related Message Formats ..................... 15
3.1 Path Message ........................................... 15
3.2 Resv Message ........................................... 16
4 LSP Tunnel related Objects ............................. 17
4.1 Label Object ........................................... 17
4.1.1 Handling Label Objects in Resv messages ................ 17
4.1.2 Non-support of the Label Object ........................ 19
4.2 Label Request Object ................................... 19
4.2.1 Label Request without Label Range ...................... 19
4.2.2 Label Request with ATM Label Range ..................... 20
4.2.3 Label Request with Frame Relay Label Range ............. 21
4.2.4 Handling of LABEL_REQUEST .............................. 22
4.2.5 Non-support of the Label Request Object ................ 23
4.3 Explicit Route Object .................................. 23
4.3.1 Applicability .......................................... 24
4.3.2 Semantics of the Explicit Route Object ................. 24
4.3.3 Subobjects ............................................. 25
4.3.4 Processing of the Explicit Route Object ................ 28
4.3.5 Loops .................................................. 30
4.3.6 Forward Compatibility .................................. 30
4.3.7 Non-support of the Explicit Route Object ............... 31
4.4 Record Route Object .................................... 31
4.4.1 Subobjects ............................................. 31
4.4.2 Applicability .......................................... 34
4.4.3 Processing RRO ......................................... 35
4.4.4 Loop Detection ......................................... 36
4.4.5 Forward Compatibility .................................. 37
4.4.6 Non-support of RRO ..................................... 37
4.5 Error Codes for ERO and RRO ............................ 37
4.6 Session, Sender Template, and Filter Spec Objects ...... 38
4.6.1 Session Object ......................................... 39
4.6.2 Sender Template Object ................................. 40
4.6.3 Filter Specification Object ............................ 42
4.6.4 Reroute and Bandwidth Increase Procedure ............... 42
4.7 Session Attribute Object ............................... 43
4.7.1 Format without resource affinities ..................... 43
4.7.2 Format with resource affinities ........................ 45
4.7.3 Procedures applying to both C-Types .................... 46
4.7.4 Resource Affinity Procedures .......................... 48
5 Hello Extension ........................................ 49
5.1 Hello Message Format ................................... 50
5.2 HELLO Object formats ................................... 51
5.2.1 HELLO REQUEST object ................................... 51
5.2.2 HELLO ACK object ....................................... 51
5.3 Hello Message Usage .................................... 52
5.4 Multi-Link Considerations .............................. 53
5.5 Compatibility .......................................... 54
6 Security Considerations ................................ 54
7 IANA Considerations .................................... 54
7.1 Message Types .......................................... 55
7.2 Class Numbers and C-Types .............................. 55
7.3 Error Codes and Globally-Defined Error Value Sub-Codes . 57
7.4 Subobject Definitions .................................. 57
8 Intellectual Property Considerations ................... 58
9 Acknowledgments ........................................ 58
10 References ............................................. 58
11 Authors' Addresses ..................................... 60
12 Full Copyright Statement ............................... 611. Introduction ✨
okay so Section 2.9 of the MPLS architecture [2] defines a label distribution protocol as a set of procedures that lets one Label Switched Router (LSR) tell another what the labels used to forward traffic between and through them mean 🧠 The MPLS architecture doesn't assume there's just one label distribution protocol. This document is the spec for extending RSVP so it can set up label switched paths (LSPs) in MPLS networks 💅
a bunch of the new features here came from the requirements for traffic engineering over MPLS (see [3]) 🔥 The extended RSVP supports setting up explicitly routed LSPs, with or without resource reservations. It also handles smooth rerouting of LSPs, preemption, and loop detection. Not bad for one protocol, periodt 👑
the LSPs made with RSVP can carry the "Traffic Trunks" described in [3]. An LSP and a traffic trunk are different things, though they're closely related 🫶 For example, two LSPs between the same source and destination could be load shared to carry a single traffic trunk. The other way around works too: several traffic trunks could ride in the same LSP if, say, that LSP can carry several service classes. The applicability of these extensions is discussed further in [10] 🌸
since the traffic flowing along a label-switched path is defined by the label applied at the ingress node of the LSP, these paths can be treated as tunnels 🧚 They tunnel below normal IP routing and filtering mechanisms, and when an LSP gets used this way we call it an LSP tunnel.
LSP tunnels make it possible to do all kinds of policies for network performance optimization 💖 For example, LSP tunnels can be routed away from network failures, congestion, and bottlenecks, either automatically or manually. You can also set up multiple parallel LSP tunnels between two nodes, then map traffic between those nodes onto the tunnels according to local policy 🍓 Traffic engineering (that's performance optimization of operational networks) is expected to be a big application of this spec, but the extended RSVP can be used in a much wider context too.
the purpose of this document is to describe how to use RSVP to establish LSP tunnels 🎀 The goal is to fully describe all the objects, packet formats, and procedures needed to get interoperable implementations, so everyone's stuff actually works together. A few new objects are also defined to make LSP tunnels easier to manage and debug 🔍
the document also describes a way to detect node failures quickly using a new HELLO message 🌈
all the objects and messages described in this specification are optional with respect to RSVP 🙈 The document also covers what happens when a node doesn't support one of the objects described here.
last thing: the discussion here is restricted to unicast label switched paths. Multicast LSPs are left for further study 🦋
1.1. Background ✨
okay so hosts and routers that support both RSVP [1] and Multi-Protocol Label Switching [2] can slap labels onto RSVP flows 🏷️ and when MPLS and RSVP team up, the definition of a flow gets way more flexible 💅 Once a label switched path (LSP) is set up, the traffic on it is defined by the label applied at the ingress node of the LSP 🚦 You can map label to traffic using a bunch of different criteria 🎀 The set of packets that a specific node gives the same label value to is called a forwarding equivalence class (FEC) (see [2]), and that basically is the "RSVP flow" 🦋 When traffic gets mapped onto a label-switched path like this, we call the LSP an "LSP Tunnel" 🚇 And once labels are tied to traffic flows, a router can look at a packet's label value and figure out which reservation state belongs to it 🧠✨
the signaling model uses downstream-on-demand label distribution, and it's giving very specific vibes 🌸 A request to bind labels to a specific LSP tunnel starts at the ingress node through an RSVP Path message 📨 For that, the Path message gets a LABEL_REQUEST object tacked on 🏷️ Labels are allocated downstream, then distributed (propagated upstream) through an RSVP Resv message 🔁 The Resv message gets extended with a special LABEL object 💜 How label allocation, distribution, binding, and stacking work is covered in later sections of this document 📖
the signaling model also supports explicit routing, which is so iconic 👑 This happens by sticking a simple EXPLICIT_ROUTE object into RSVP Path messages 🗺️ The EXPLICIT_ROUTE object holds a concatenation of hops that makes up the explicitly routed path 🧩 With it, the paths taken by label-switched RSVP-MPLS flows can be pre-determined, totally independent of conventional IP routing 🙌 The explicit path can be set up administratively, or computed automatically by a suitable entity based on QoS and policy requirements, while taking the prevailing network state into account 📊 In general, path computation can be control-driven or data-driven 🧮 The mechanisms, processes, and algorithms used to compute explicitly routed paths are out of scope for this spec 🙅♀️
one super useful application of explicit routing is traffic engineering 🚀 With explicitly routed LSPs, a node at the ingress edge of an MPLS domain gets to control the path its traffic takes from itself, through the MPLS network, to an egress node 🛣️ Explicit routing can be used to optimize how network resources get used and to boost traffic-oriented performance characteristics 📈💖
the idea of explicitly routed label switched paths can be generalized using abstract nodes 🧁 An abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP 🫥 An abstract node is called simple if it contains only one physical node 🔍 With this abstraction, an explicitly routed LSP can be specified as a sequence of IP prefixes or a sequence of Autonomous Systems 🌐
the signaling model supports specifying an explicit path as a sequence of strict and loose routes 🧵 Combining abstract nodes with strict and loose routes seriously levels up how flexible path definitions can be 🥹✨
an advantage of using RSVP to set up LSP tunnels is that it lets you allocate resources along the path 💰 For example, bandwidth can be allocated to an LSP tunnel using standard RSVP reservations and Integrated Services service classes [4] 🎟️
resource reservations are useful, but they're not mandatory 🙃 An LSP can be instantiated without any resource reservations at all 🫠 LSPs like that can be used, for example, to carry best effort traffic 🌈 They can also be used in lots of other contexts, including fall-back and recovery policies under fault conditions, and so forth 🛟
1.2. Terminology 📚
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 [6] 💅
the reader is assumed to be familiar with the terminology in [1], [2] and [3] 🤓
Abstract Node
A group of nodes whose internal topology is opaque to the ingress node of the LSP. An abstract node is said to be simple if it contains only one physical node. 🧁
Explicitly Routed LSP
An LSP whose path is established by a means other than normal IP routing. 🗺️
Label Switched Path
The path created by the concatenation of one or more label switched hops, allowing a packet to be forwarded by swapping labels from an MPLS node to another MPLS node. For a more precise definition see [2]. 🦋
LSP
A Label Switched Path 💜
LSP Tunnel
An LSP which is used to tunnel below normal IP routing and/or filtering mechanisms. 🚇
Traffic Engineered Tunnel (TE Tunnel)
A set of one or more LSP Tunnels which carries a traffic trunk. 🎀
Traffic Trunk
A set of flows aggregated by their service class and then placed on an LSP or set of LSPs called a traffic engineered tunnel. For further discussion see [3]. 🧃
2. Overview ✨
2.1. LSP Tunnels and Traffic Engineered Tunnels 🌸
according to [1], "RSVP defines a 'session' to be a data flow with a particular destination and transport-layer protocol." 🧾 But when RSVP and MPLS are combined, a flow or session can be defined with way more flexibility and generality 🌈 The ingress node of an LSP can use a variety of means to decide which packets get a particular label 🎯 Once a label is assigned to a set of packets, that label effectively defines the "flow" through the LSP 🫶 We call such an LSP an "LSP tunnel" because the traffic inside it is opaque to intermediate nodes along the label switched path 🙈
new RSVP SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects, called LSP_TUNNEL_IPv4 and LSP_TUNNEL_IPv6, have been defined to support the LSP tunnel feature 🧚 From the perspective of a node along the label switched path, the semantics of these objects are that traffic belonging to the LSP tunnel is identified solely on the basis of packets arriving from the PHOP or "previous hop" (see [1]) with the particular label value(s) this node assigned to upstream senders to the session 🔥 Honestly the IPv4(v6) in the object name just means the destination address is an IPv4(v6) address, nothing more 🙌 When we talk about these objects generically, we use the qualifier LSP_TUNNEL 💖
in some applications it's useful to group sets of LSP tunnels together 👯 This can help during reroute operations, or to spread a traffic trunk over multiple paths 🛤️ In the traffic engineering application, these sets are called traffic engineered tunnels (TE tunnels) 🫧 To make it possible to identify and associate these LSP tunnels, two identifiers get carried around 🪪 A tunnel ID is part of the SESSION object, and the SESSION object uniquely defines a traffic engineered tunnel 💜 The SENDER_TEMPLATE and FILTER_SPEC objects carry an LSP ID 🏷️ The SENDER_TEMPLATE (or FILTER_SPEC) object together with the SESSION object uniquely identifies an LSP tunnel
2.2. Operation of LSP Tunnels ✨
okay bestie, this section is basically a highlight reel of everything RSVP can do once it's been extended by this doc for LSP tunnels 🎀 there are six big moves: (1) setting up LSP tunnels with or without QoS, (2) rerouting one dynamically, (3) seeing the actual route it took, (4) identifying and diagnosing them, (5) preempting one under admin policy control, and (6) doing downstream-on-demand label allocation, distribution, and binding 💅 we'll get into the details later, but here's the vibe for each 🦋
so, to create an LSP tunnel, the first MPLS node on the path (the sender node, with respect to the path) makes an RSVP Path message with a session type of LSP_TUNNEL_IPv4 or LSP_TUNNEL_IPv6 🧚 and then it drops a LABEL_REQUEST object into that Path message. the LABEL_REQUEST says "hey, I want a label binding for this path," and it also tells everyone which network layer protocol is going to ride this path 🌸 this matters because you can't just assume it's IP, and you can't figure it out from the L2 header either, since that only says "MPLS" 🙈
if the sender knows a route that's likely to hit the tunnel's QoS needs, or uses network resources efficiently, or fits some policy criteria, it can totally use that route for some or all of its sessions 👑 to do that, it adds an EXPLICIT_ROUTE object to the Path message, and that object spells out the route as a sequence of abstract nodes 💜
if the sender finds a better route after a session is already up, no stress, it can reroute dynamically by just changing the EXPLICIT_ROUTE object 🔥 but if something goes sideways with an EXPLICIT_ROUTE, like it makes a routing loop or some routers don't support it, the sender gets notified 😭
adding a RECORD_ROUTE object to the Path message lets the sender see the actual route the LSP tunnel takes 👀 it can also use that object to ask the network to notify it about changes to the routing path 🫶 RECORD_ROUTE works like a path vector, so it can be used for loop detection 🌈
last but not least, a SESSION_ATTRIBUTE object can be added to Path messages to help with session identification and diagnostics 🍓 it also carries extra control info like setup and hold priorities, resource affinities (see [3]), and local-protection ⭐
routers along the path can use the setup and hold priorities, plus SENDER_TSPEC and any POLICY_DATA objects in Path messages, as input to policy control 💖 in traffic engineering, this is super useful: the Path message can check that bandwidth exists at a given priority along the whole path before anything gets preempted at lower priorities 🦋 if a Path message keeps going even when there aren't enough resources, lower priority reservations downstream could get preempted for nothing, which is a total waste 😩
when the EXPLICIT_ROUTE object (ERO) is present, the Path message goes toward its destination along the path the ERO specifies 🎀 each node on the way records the ERO in its path state block 🌸 nodes are also allowed to modify the ERO before forwarding the Path message 💅 in that case, the modified ERO SHOULD be stored in the path state block in addition to the received ERO 🫶
the LABEL_REQUEST object asks intermediate routers and receiver nodes to provide a label binding for the session 🧚 if a node can't do that, it sends a PathErr message with an "unknown object class" error 🙈 and if LABEL_REQUEST isn't supported end to end, the sender gets notified by the first node that doesn't support it 😭
the destination node of a label-switched path answers a LABEL_REQUEST by putting a LABEL object in its Resv message 👑 the LABEL object goes into the filter spec list right after the filter spec it belongs to 💜
the Resv message travels back upstream toward the sender, following the path state the Path message created, in reverse order 🔥 and if that path state came from an ERO, the Resv follows the reverse path of the ERO 🦋
each node that gets a Resv with a LABEL object uses that label for outgoing traffic tied to this LSP tunnel 💖 if the node isn't the sender, it allocates a new label and puts it in the LABEL object of the Resv it sends upstream to the PHOP 🌈 that upstream label is the one this node uses to identify incoming traffic for this LSP tunnel, and it also works as shorthand for the Filter Spec 🍓 now the node can update its "Incoming Label Map" (ILM), which maps incoming labeled packets to a "Next Hop Label Forwarding Entry" (NHLFE), see [2] ⭐
once the Resv message reaches the sender node, a label-switched path is effectively established 🎉✨
2.3. Service Classes 🎀
this doc doesn't restrict the type of Integrated Service requests for reservations 💅 however, an implementation SHOULD support the Controlled-Load service [4] and the Null Service [16] 🫶
2.4. Reservation Styles 🌸
the receiver node picks a reservation style from a set of options for each session, and every RSVP session has to have one specific style 👑 senders have zero say in that choice 🙅♀️ and the receiver can pick different styles for different LSPs 💜
an RSVP session can end up as one or more LSPs, depending on which style gets chosen 🦋
some styles, like FF, dedicate a reservation to one individual sender node 🧚 others, like WF and SE, can share one reservation across several sender nodes 🔥 the next sections go through each style and its pros and cons 💖 for a deeper dive, check [1] 🌈
2.4.1. Fixed Filter (FF) Style 💅
the Fixed Filter (FF) reservation style makes a distinct reservation for each sender's traffic, and nobody else shares it 🎀 this is common when traffic from each sender is likely to be concurrent and independent 🍓 the total reserved bandwidth on a link for FF sessions is the sum of the reservations for the individual senders 💜
since every sender has its own reservation, each one gets a unique label 🦋 this can end up as a point-to-point LSP between every sender/receiver pair ⭐
2.4.2. Wildcard Filter (WF) Style 🌈
with the Wildcard Filter (WF) reservation style, one shared reservation covers all senders to a session 🫶 the total reservation on a link stays the same no matter how many senders there are 👑
a single multipoint-to-point label-switched-path gets created for all senders to the session 🧚 on links the senders share, one label value is allocated to the session 💖 if there's only one sender, the LSP looks like a normal point-to-point connection 🌸 when there are multiple senders, you get a multipoint-to-point LSP (a reversed tree) 🔥
this style is useful when not all senders send traffic at the same time 📞 a phone conference is a good example, since not everyone talks at once 🎀 but if all senders send at the same time, there's no way to get the right reservations made 😩 either the reserved bandwidth on links near the destination ends up less than needed, or the reserved bandwidth on links near some senders ends up more than needed 🙈 that really limits WF for traffic engineering 💀
and because of the merging rules of WF, EXPLICIT_ROUTE objects can't be used with WF reservations 🚫 combined with that issue and the lack of fit for traffic engineering, this document doesn't consider WF 🙅♀️
2.4.3. Shared Explicit (SE) Style 🦋
the Shared Explicit (SE) style lets a receiver explicitly name the senders to include in a reservation 💅 there's a single reservation on a link for all the listed senders 🫶 because each sender is listed in the Resv message, different labels can go to different senders, which creates separate LSPs 🧚
SE style reservations can use a multipoint-to-point label-switched-path or an LSP per sender 🌈 multipoint-to-point LSPs can be used when Path messages don't carry the EXPLICIT_ROUTE object, or when Path messages have identical EXPLICIT_ROUTE objects 👑 in either of those cases, a common label can be assigned 💜
Path messages from different senders can each carry their own ERO, and the paths those senders take can converge and diverge at any point in the network topology 🔥 when Path messages have differing EXPLICIT_ROUTE objects, separate LSPs must be established for each EXPLICIT_ROUTE object 💖
2.5. Rerouting Traffic Engineered Tunnels 🦋
okay so one of the big requirements for Traffic Engineering is being able to reroute an established TE tunnel under a bunch of different conditions, depending on administrative policy. sometimes policy says a tunnel should move over once a more "optimal" route shows up 👀 another super common reason is when a resource on the tunnel's established path fails 💀 and some policies also want the tunnel to go back to its original path once that failed resource comes back to life 🫶
in general, you really don't want to disrupt traffic or mess with network operations while a reroute is happening ✨ so the smooth move is to set up a brand new LSP tunnel, shift traffic over onto it, and only THEN tear down the old one. this is called "make-before-break" 💅 the tricky part is that the old and new LSP tunnels can end up fighting over resources on the network segments they share. depending on what's available, that fight can make Admission Control block the new LSP tunnel from getting set up at all 😭 the good news is that using RSVP to set up LSP tunnels handles this super elegantly, which is so iconic 🙌
to make make-before-break smooth, on links the old and new LSPs have in common, the resources used by the old LSP tunnel should not be released before traffic has moved to the new one. also, reservations should not be counted twice, because that might make Admission Control reject the new LSP tunnel 🙅♀️
bandwidth increases have a similar vibe 🎀 the new reservation is for the full amount needed, but the actual extra allocation is only the delta between the new and old bandwidth. if policy is applied to PATH messages by intermediate nodes, then a PATH message requesting too much bandwidth gets rejected. and if you just bump the bandwidth request without changing the SENDER_TEMPLATE, the tunnel could get torn down, depending on local policy 😬
the combo of the LSP_TUNNEL SESSION object and the SE reservation style naturally handles smooth transitions in bandwidth and routing ✨ the idea is that the old and new LSP tunnels share resources along links they have in common. the LSP_TUNNEL SESSION object narrows the scope of the RSVP session down to the particular TE tunnel in question. to uniquely identify a TE tunnel, we use the destination IP address (an address of the node that is the egress of the tunnel), a Tunnel ID, and the tunnel ingress node's IP address, which goes in the Extended Tunnel ID field.
during a reroute or bandwidth-increase, the tunnel ingress needs to look like two different senders to the RSVP session 👯 this is achieved by including the "LSP ID", which is carried in the SENDER_TEMPLATE and FILTER_SPEC objects. since the semantics of these objects changed, new C-Types are assigned.
to effect a reroute, the ingress node picks a new LSP ID and forms a new SENDER_TEMPLATE. then it creates a new ERO to define the new path. after that, it sends a new Path Message using the original SESSION object plus the new SENDER_TEMPLATE and ERO. it keeps using the old LSP and keeps refreshing the old Path message. on links that aren't held in common, the new Path message is treated like a conventional new LSP tunnel setup. on links held in common, the shared SESSION object and SE style let the LSP get established while sharing resources with the old LSP. once the ingress node gets a Resv message for the new LSP, it can transition traffic to it and tear down the old LSP 🎉
for a bandwidth-increase, a new Path Message with a new LSP_ID can try for a larger bandwidth reservation, while the current LSP_ID keeps getting refreshed so the reservation isn't lost if the larger one fails 🫶
2.6. Path MTU 📏
Standard RSVP [1] and Int-Serv [11] give the RSVP sender the minimum MTU available between the sender and the receiver. this path MTU identification capability is also provided for LSPs established via RSVP.
path MTU info is carried, depending on which one is present, in the Integrated Services or Null Service objects. with Integrated Services objects, path MTU is provided based on the procedures defined in [11]. path MTU identification when using Null Service objects is defined in [16].
with standard RSVP, the sender uses the path MTU info to check which IP packets exceed the path MTU. for packets that exceed it, the sender either fragments the packets or, when the IP datagram has the "Don't Fragment" bit set, issues an ICMP destination unreachable message. this path MTU related handling is also required for LSPs established via RSVP.
the following algorithm applies to all unlabeled IP datagrams, and to any labeled packets the node knows to be IP datagrams, which need labels added before forwarding. for labeled packets, the bottom of the stack is found and the IP header is examined.
Using the terminology defined in [5], an LSR MUST execute the following algorithm:
- Let N be the number of bytes in the label stack (i.e, 4 times the number of label stack entries) including labels to be added by this node.
- Let M be the smaller of the "Maximum Initially Labeled IP Datagram Size" or of (Path MTU - N).
when the size of an IPv4 datagram (without labels) exceeds the value of M:
- if the DF bit is not set in the IPv4 header, then
- (a) the datagram MUST be broken into fragments, each of whose size is no greater than M, and
- (b) each fragment MUST be labeled and then forwarded.
- if the DF bit is set in the IPv4 header, then
- (a) the datagram MUST NOT be forwarded
- (b) create an ICMP Destination Unreachable Message:
- i. set its Code field [12] to "Fragmentation Required and DF Set",
- ii. set its Next-Hop MTU field [13] to M
- (c) if possible, transmit the ICMP Destination Unreachable Message to the source of the discarded datagram.
when the size of an IPv6 datagram (without labels) exceeds the value of M:
- (a) the datagram MUST NOT be forwarded
- (b) create an ICMP Packet too Big Message with the Next-Hop link MTU field [14] set to M
- (c) if possible, transmit the ICMP Packet too Big Message to the source of the discarded datagram.
3. LSP Tunnel related Message Formats 📨
five new objects are defined in this section:
Object name Applicable RSVP messages
--------------- ------------------------
LABEL_REQUEST Path
LABEL Resv
EXPLICIT_ROUTE Path
RECORD_ROUTE Path, Resv
SESSION_ATTRIBUTE Pathnew C-Types are also assigned for the SESSION, SENDER_TEMPLATE, and FILTER_SPEC objects.
detailed descriptions of the new objects are given in later sections. all new objects are OPTIONAL with respect to RSVP. an implementation can choose to support a subset of objects. however, the LABEL_REQUEST and LABEL objects are mandatory with respect to this specification.
the LABEL and RECORD_ROUTE objects are sender specific. in Resv messages, they MUST appear after the associated FILTER_SPEC and before any subsequent FILTER_SPEC.
the relative placement of the EXPLICIT_ROUTE, LABEL_REQUEST, and SESSION_ATTRIBUTE objects is simply a recommendation. the ordering of these objects isn't important, so an implementation MUST be prepared to accept objects in any order.
3.1. Path Message
the format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]3.2. Resv Message
the format of the Resv message is as follows:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= <FF flow descriptor list>
| <SE flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
<LABEL> [ <RECORD_ROUTE> ]
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC> <LABEL>
[ <RECORD_ROUTE> ]
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> <LABEL> [ <RECORD_ROUTE> ] Note: LABEL and RECORD_ROUTE (if present), are bound to the
preceding FILTER_SPEC. No more than one LABEL and/or
RECORD_ROUTE may follow each FILTER_SPEC.4. LSP Tunnel related Objects 🧚
4.1. Label Object 🏷️
Labels MAY be carried in Resv messages. for the FF and SE styles, a label is associated with each sender. the label for a sender MUST immediately follow the FILTER_SPEC for that sender in the Resv message.
the LABEL object has the following format, LABEL class = 16, C_Type = 1:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (top label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the contents of a LABEL is a single label, encoded in 4 octets. each generic MPLS label is an unsigned integer in the range 0 through 1048575. generic MPLS labels and FR labels are encoded right aligned in 4 octets. ATM labels are encoded with the VPI right justified in bits 0-15 and the VCI right justified in bits 16-31.
4.1.1. Handling Label Objects in Resv messages 🔍
in MPLS, a node may support multiple label spaces, perhaps associating a unique space with each incoming interface. for the purposes of the following discussion, the term "same label" means the identical label value drawn from the identical label space. further, the following applies only to unicast sessions.
labels received in Resv messages on different interfaces are always considered to be different, even if the label value is the same. 💖
4.1.1.1. Downstream
Okay so the downstream node is the one that picks the label to represent the flow 💖. If a label range was asked for in the label request, the label MUST be drawn from that range ✨. If there's no label available, the node sends a PathErr with the error code routing problem and the error value label allocation failure 💀.
If a node gets a Resv message that gave the same label value to multiple senders, that node MAY also assign a single value to those same senders, or to any subset of them 🫶. But here's the tea: if a node plans to police individual senders to a session, it MUST assign unique labels to those senders 🚨.
Bestie, this one is important. Policing individual senders means every sender needs its own label, so no sharing allowed 🙅♀️
Now for ATM, there's one extra condition 🦋. Some ATM nodes just can't merge streams. Those nodes MAY say so by setting a bit in the label request to zero. The M-bit in the LABEL_REQUEST object of C-Type 2 (the label request with ATM label range) is what does this job. The M-bit SHOULD be set by nodes that are merge capable 💅. And if the M-bit isn't set for any senders, the downstream node MUST assign unique labels to those senders 🙈.
Once a label is allocated, the node formats a brand new LABEL object and sends it as part of the Resv message to the previous hop 🎀. The node SHOULD be ready to forward packets carrying the assigned label before it sends that Resv message 🏃♀️. The LABEL object SHOULD be kept in the Reservation State Block, and it gets used again in the next Resv refresh event when the Resv message is formatted 🌸.
A node is expected to send a Resv message before its refresh timers expire if the contents of the LABEL object change ⏰.
4.1.1.2. Upstream
A node uses the label carried in the LABEL object as the outgoing label for the sender 🦋. The router then allocates a brand new label and binds it to the incoming interface of this session/sender. It's the same interface the router uses to forward Resv messages to the previous hops, so it's all connected 🔗.
Several circumstances can lead to an unacceptable label 😬:
- the node is a merge incapable ATM switch, but the downstream node has assigned the same label to two senders
- the implicit null label was assigned, but the node can't do a penultimate pop for the associated L3PID
- the assigned label is outside the requested label range
If any of these happen, the node sends a ResvErr with the error code routing problem and the error value unacceptable label value 🚫.
4.1.2. Non-support of the Label Object
Normally, a node should never receive a LABEL object in a Resv message unless it had included a LABEL_REQUEST object in the matching Path message 🤔. But an RSVP router that doesn't recognize the LABEL object sends a ResvErr with the error code Unknown object class toward the receiver. And that makes the reservation fail, which is giving major drama 💀.
4.2. Label Request Object
The Label Request Class is 19 🎀. Right now there are three possible C_Types:
- Type 1 is a Label Request without a label range.
- Type 2 is a label request with an ATM label range.
- Type 3 is a label request with a Frame Relay label range.
The LABEL_REQUEST object formats are shown below 👀.
4.2.1. Label Request without Label Range
Class = 19, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt 🙌.
L3PID: An identifier of the layer 3 protocol using this path. Standard Ethertype values are used 🧚.
4.2.2. Label Request with ATM Label Range
Class = 19, C_Type = 2
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Res | Minimum VPI | Minimum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Maximum VPI | Maximum VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved (Res): This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt 🌷.
L3PID: An identifier of the layer 3 protocol using this path. Standard Ethertype values are used 💜.
M: Setting this bit to one means the node is capable of merging in the data plane ✨.
Minimum VPI (12 bits): This 12 bit field specifies the lower bound of a block of Virtual Path Identifiers that's supported on the originating switch. If the VPI is less than 12 bits, it MUST be right justified in this field, and the preceding bits MUST be set to zero 📐.
Minimum VCI (16 bits): This 16 bit field specifies the lower bound of a block of Virtual Connection Identifiers that's supported on the originating switch. If the VCI is less than 16 bits, it MUST be right justified in this field, and the preceding bits MUST be set to zero 📐.
Maximum VPI (12 bits): This 12 bit field specifies the upper bound of a block of Virtual Path Identifiers that's supported on the originating switch. If the VPI is less than 12 bits, it MUST be right justified in this field, and the preceding bits MUST be set to zero 📐.
Maximum VCI (16 bits): This 16 bit field specifies the upper bound of a block of Virtual Connection Identifiers that's supported on the originating switch. If the VCI is less than 16 bits, it MUST be right justified in this field, and the preceding bits MUST be set to zero 📐.
4.2.3. Label Request with Frame Relay Label Range
Class = 19, C_Type = 3
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | L3PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |DLI| Minimum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Maximum DLCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved: This field is reserved. It MUST be set to zero on transmission and ignored on receipt 🫧.
L3PID: An identifier of the layer 3 protocol using this path. Standard Ethertype values are used 🧚.
DLI: DLCI Length Indicator 🔢. It's the number of bits in the DLCI. These are the supported values:
Len DLCI bits
0 10
2 23Minimum DLCI: This 23-bit field specifies the lower bound of a block of Data Link Connection Identifiers (DLCIs) that's supported on the originating switch. The DLCI MUST be right justified in this field, and unused bits MUST be set to 0 📐.
Maximum DLCI: This 23-bit field specifies the upper bound of a block of Data Link Connection Identifiers (DLCIs) that's supported on the originating switch. The DLCI MUST be right justified in this field, and unused bits MUST be set to 0 📐.
4.2.4. Handling of LABEL_REQUEST
To set up an LSP tunnel, the sender creates a Path message with a LABEL_REQUEST object 🚀. This object says a label binding for this path is wanted, and it also tells everyone which network layer protocol is going to ride this path. That's how non-IP network layer protocols get to travel down an LSP 🌈. This info is also handy for actual label allocation, because some reserved labels are protocol specific, see [5] 🧠.
The LABEL_REQUEST SHOULD be stored in the Path State Block, so Path refresh messages also carry the LABEL_REQUEST object 🔁. When the Path message reaches the receiver, the LABEL_REQUEST object is what tells the receiver to allocate a label and put it in the LABEL object for the matching Resv message 🎯. If a label range was specified, the label MUST be allocated from that range ✨. A receiver that accepts a LABEL_REQUEST object MUST include a LABEL object in the Resv messages for that Path message 💖. And if a LABEL_REQUEST object wasn't in the Path message, a node MUST NOT include a LABEL object in a Resv message for that Path message's session and PHOP 🙅♀️.
A node that sends a LABEL_REQUEST object MUST be ready to accept and correctly process a LABEL object in the corresponding Resv messages 🫶.
A node that recognizes a LABEL_REQUEST object, but can't support it (maybe because it failed to allocate labels), SHOULD send a PathErr with the error code Routing problem and the error value MPLS label allocation failure. 😵. This also covers the case where a label range was specified and a label can't be allocated from that range 🥲.
A node that receives and forwards a Path message, each with a LABEL_REQUEST object, MUST copy the L3PID from the received LABEL_REQUEST object to the forwarded LABEL_REQUEST object 🔄.
If the receiver can't support the protocol L3PID, it SHOULD send a PathErr with the error code Routing problem and the error value Unsupported L3PID. 🚫. This makes the RSVP session fail 💀.
4.2.5. Non-support of the Label Request Object
An RSVP router that doesn't recognize the LABEL_REQUEST object sends a PathErr with the error code Unknown object class toward the sender 🙈. An RSVP router that recognizes the LABEL_REQUEST object but doesn't recognize the C_Type sends a PathErr with the error code Unknown object C_Type toward the sender. Either way, path setup fails. The sender should notify management that an LSP can't be established, and it might possibly take action to keep the reservation going without the LABEL_REQUEST 🛠️.
RSVP is designed to cope gracefully with non-RSVP routers anywhere between senders and receivers ✨. But obviously, non-RSVP routers can't convey labels via RSVP 🙃. So if a router has a neighbor that's known to not be RSVP capable, the router MUST NOT advertise the LABEL_REQUEST object when it sends messages through the non-RSVP routers 🚫. The router SHOULD send a PathErr back to the sender with the error code Routing problem and the error value MPLS being negotiated, but a non-RSVP capable router stands in the path. 📣. This same message SHOULD be sent if a router receives a LABEL_REQUEST object in a message from a non-RSVP capable router 🫢. See [1] for a description of how a downstream router can figure out whether non-RSVP routers are present 🔍.
4.3. Explicit Route Object 🎀
okay bestie, the EXPLICIT_ROUTE object (ERO) is where we tell the network exactly which path we want, like handing over a map with the stops already circled 🗺️✨ The Explicit Route Class is 20. Right now there's only one C_Type defined, Type 1 Explicit Route. Here's the layout:
Class = 20, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Subobjects
So the contents of an EXPLICIT_ROUTE object are a bunch of variable-length chunks called subobjects 🧩 We'll get into them in section 4.3.3 below.
Also, if a Path message has more than one EXPLICIT_ROUTE object, only the first one counts 👑 The later ones MAY be ignored, and they SHOULD NOT be propagated. Main character energy: just the first one matters.
4.3.1. Applicability
Okay, real talk: the EXPLICIT_ROUTE object is meant for unicast only 🙈 Using explicit routing for multicast is still a topic for further research, so no cap, don't go there yet.
The EXPLICIT_ROUTE object should only be used when every router along the explicit route supports RSVP and the EXPLICIT_ROUTE object. Its class value has the form 0bbbbbbb, so any RSVP router that doesn't understand it will reply with an "Unknown Object Class" error. Not a vibe 💀
4.3.2. Semantics of the Explicit Route Object
An explicit route is basically a particular path through the network topology ✨ Usually a node picks it, with the goal of steering traffic down that exact path.
Here's the cute part 🦋 An explicit route is written as a list of groups of nodes, not just single nodes. So you can say "this group has to be crossed" without naming the precise router. That gives the routing system a lot of local flexibility to fill in the request, and it means the route generator doesn't need perfect info about every detail of the path. Honestly iconic.
Each subobject identifies one group of nodes, so an explicit route is really just a specification of groups to be traversed 💅
To keep things tidy, we call each group an abstract node. An explicit route is a set of abstract nodes to be traversed. If an abstract node is only one node, we call it a simple abstract node 🧚
Example time 🌸 Imagine an explicit route made up only of Autonomous System number subobjects. Each subobject stands for one Autonomous System in the global topology, so each AS is an abstract node, and the route is a path that goes through every AS you listed. There may be several hops inside each AS, but the source node can't see them. They're opaque to it, so it doesn't need to know. Lowkey genius.
4.3.3. Subobjects
Same as before: the contents of an EXPLICIT_ROUTE object are a series of variable-length items called subobjects. Each subobject looks like this 🎀
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+
|L| Type | Length | (Subobject contents) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------//----------------+L
The L bit is an attribute of the subobject 🔑 It gets set if the subobject is a loose hop in the explicit route. If it isn't set, the subobject is a strict hop instead.
Type
The Type tells you what kind of stuff is inside the subobject. Right now these are the defined values:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system numberLength
The Length is the total size of the subobject in bytes, counting the L, Type and Length fields too. The Length MUST be at least 4, and MUST be a multiple of 4. Please don't skip this one, bestie 🙏
4.3.3.1. Strict and Loose Subobjects
The L bit is a single-bit attribute 🌈 If it's set, the value is 'loose.' If not, it's 'strict.' For short, a subobject with 'loose' is a 'loose subobject,' and otherwise it's a 'strict subobject.' The abstract node of a strict or loose subobject is then a strict or loose node. Loose and strict nodes are always judged relative to the abstract node that came before them 🧭
Here's the rule for strict nodes: the path between a strict node and the node right before it MUST only include network nodes from the strict node and its preceding abstract node. Hard boundary, no wiggle room 💀
Loose nodes are more relaxed. The path between a loose node and its preceding node MAY include other network nodes that aren't part of the loose node or its preceding abstract node. That's the flexibility we talked about earlier, obsessed with it 😭
4.3.3.2. Subobject 1: IPv4 prefix
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L
Same deal as before: the L bit is an attribute of the subobject. It's set if the subobject is a loose hop in the explicit route, and not set if it's a strict hop 🔑
Type
0x01 IPv4 addressLength
Total length in bytes, counting the Type and Length fields. For this one the Length is always 8 📏
IPv4 address
This is an IPv4 address, but it gets treated as a prefix based on the prefix length below. Bits past the prefix are ignored on receipt, and they SHOULD be set to zero on transmission 🫶
Prefix length
The length in bits of the IPv4 prefix.
Padding
Zero on transmission, ignored on receipt.
So the contents are a 4-octet IPv4 address, a 1-octet prefix length, and a 1-octet pad 🍓 The abstract node this subobject stands for is every node with an IP address inside that prefix. And a prefix length of 32? That's just one single IPv4 node, periodt ✨
4.3.3.3. Subobject 2: IPv6 Prefix
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Resvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L
Still the same: the L bit is an attribute of the subobject, set for a loose hop and unset for a strict one 🔑
Type
0x02 IPv6 addressLength
Total length in bytes, counting the Type and Length fields. This one is always 20 💖
IPv6 address
An IPv6 address, treated as a prefix based on the prefix length value below. Bits past the prefix are ignored on receipt and SHOULD be set to zero on transmission 🫶
Prefix Length
The length in bits of the IPv6 prefix.
Padding
Zero on transmission, ignored on receipt.
The contents are a 16-octet IPv6 address, a 1-octet prefix length, and a 1-octet pad 🌸 The abstract node is the set of nodes whose IP address lies inside this prefix. A prefix length of 128 means one single IPv6 node. Same energy as the IPv4 one, just bigger 🦋
4.3.3.4. Subobject 32: Autonomous System Number
The contents of an Autonomous System (AS) number subobject are a 2-octet AS number 🌈 The abstract node this one stands for is the set of nodes that belong to that autonomous system.
The length of the AS number subobject is 4 octets, so simple and so cute 🎀
4.3.4. Processing of the Explicit Route Object
4.3.4.1. Selection of the Next Hop
okay so when a node gets a Path message with an EXPLICIT_ROUTE object, it has to figure out the next hop for that path 🧭. That's necessary bc the next abstract node on the explicit route might be an IP subnet or an Autonomous System, so picking the next hop can mean choosing from a few feasible options 💅. How it chooses is up to the implementation and can be influenced by local policy, and honestly that's out of scope for this spec ✨. What IS assumed is that every node makes a best effort to find a loop-free path 🔁. And note that local policy can override the paths it works out 🙈.
To find the next hop, a node does the following steps 🎀:
1) The node that gets the RSVP message MUST look at the first subobject FIRST 👑. If the node isn't part of the abstract node that the first subobject describes, it got the message by mistake, so it SHOULD return a "Bad initial subobject" error 😭. If there's no first subobject at all, the message is also broken, and the system SHOULD return a "Bad EXPLICIT_ROUTE object" error 💀.
2) If there's no second subobject, that means the explicit route is over 🦋. The EXPLICIT_ROUTE object SHOULD be removed from the Path message. This node may or may not be the end of the path, and then we keep going with section 4.3.4.2, where a brand new EXPLICIT_ROUTE object MAY be added to the Path message 🌸.
3) Next up, the node looks at the second subobject 👀. If the node is ALSO part of the abstract node that the second subobject describes, it deletes the first subobject and goes back to step 2 🔄. Once the second subobject becomes the first one in the next round, the node can figure out the next abstract node on the path after running steps 2 and 3 as many times as needed 💖.
4) Abstract Node Border Case 🚧: the node checks whether it's topologically adjacent to the abstract node described by the second subobject 🫶. If it is, the node picks a specific next hop that belongs to that abstract node ✨. Then it deletes the first subobject and continues with section 4.3.4.2 🦋.
5) Interior of the Abstract Node Case 🌈: otherwise, the node picks a next hop inside its own abstract node (the one the first subobject describes) that's on the path toward the abstract node of the second subobject, which is the next abstract node 🧚. If no such path exists, there are two possibilities 👇:
5a) If the second subobject is a strict subobject, it's an error, and the node SHOULD return a "Bad strict node" error 🙅♀️.
5b) Otherwise, if the second subobject is a loose subobject, the node picks any next hop that's on the path to the next abstract node 🫠. If there's no path at all, that's an error, and the node SHOULD return a "Bad loose node" error 💔.
6) Finally, the node swaps the first subobject for any subobject that names an abstract node containing the next hop 🔥. This matters bc it's what lets the next hop accept the explicit route when it receives it 🎯.
4.3.4.2. Adding subobjects to the Explicit Route Object
after picking a next hop, the node MAY change the explicit route in a few ways 🎀.
If the EXPLICIT_ROUTE object got removed while the node ran the algorithm in section 4.3.4.1, the node MAY add a brand new EXPLICIT_ROUTE object 🌸.
Otherwise, if the node is a member of the abstract node for the first subobject, a series of subobjects MAY be inserted before the first subobject, OR MAY replace the first subobject 🦋. Each subobject in this series MUST denote an abstract node that's a subset of the current abstract node 💅.
Or, if the first subobject is a loose subobject, an arbitrary series of subobjects MAY be inserted in front of it ✨.
4.3.5. Loops
the EXPLICIT_ROUTE object has a finite length, BUT loose nodes mean it's possible to build forwarding loops while the underlying routing protocol is still settling 😭🔁. The originator of the explicit route can catch this using another opaque route object called the RECORD_ROUTE object 🕵️♀️. The RECORD_ROUTE object collects detailed path info, so it's useful for loop detection and diagnostics 🍓.
4.3.6. Forward Compatibility
new subobjects might get defined down the line 🧚. If a node runs into a subobject it doesn't recognize during its normal ERO processing, it sends a PathErr with the error code "Routing Error" and error value "Bad Explicit Route Object" back toward the sender 🙈. The EXPLICIT_ROUTE object gets included, truncated (on the left) to the offending subobject 💅. An unrecognized subobject that a node never hits during its ERO processing SHOULD be ignored 🫶. It just gets passed forward along with the rest of the remaining ERO stack 🌈.
4.3.7. Non-support of the Explicit Route Object
if an RSVP router doesn't recognize the EXPLICIT_ROUTE object, it sends a PathErr with the error code "Unknown object class" back toward the sender 💀. That makes the path setup fail 😭. The sender should tell management that an LSP can't be established, and maybe try to keep the reservation going without the EXPLICIT_ROUTE or with a different explicit route 🦋.
4.4. Record Route Object
routes can be recorded with the RECORD_ROUTE object (RRO) 📝. Labels can optionally get recorded too ✨. The Record Route Class is 21 🎀. Right now only one C_Type is defined, which is Type 1 Record Route 👑. The RECORD_ROUTE object looks like this 👇:
Class = 21, C_Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Subobjects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Subobjects 🧩
the contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects 💖. Section 4.4.1 below defines them 🔍.
RROs can show up in both RSVP Path and Resv messages 🌸. If a Path message has multiple RROs, only the first one is meaningful 🙈. The later ones SHOULD be ignored and SHOULD NOT be propagated 🚫. In a Resv message, it's the same deal: if you hit multiple RROs after a FILTER_SPEC and before the next FILTER_SPEC, only the first RRO counts ✨. The later ones SHOULD be ignored and SHOULD NOT be propagated 💅.
4.4.1. Subobjects
the contents of a RECORD_ROUTE object are a series of variable-length data items called subobjects, and each one has its own Length field 🎀. The length is the total size of the subobject in bytes, Type and Length fields included 📏. The length MUST always be a multiple of 4, and at least 4 🔢.
Subobjects work like a last-in-first-out stack 🥞. The first subobject from the start of the RRO counts as the top, and the last one is the bottom 🫶. When a new subobject gets added, it always goes on top 🦋.
an empty RRO with no subobjects is considered illegal 🚫.
Three kinds of subobjects are defined right now 👑.
4.4.1.1. Subobject 1: IPv4 address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv4 address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🏷️
0x01: IPv4 address 💖
Length 📏
the Length is the total length of the subobject in bytes, Type and Length fields included 🎀. It's always 8 ✨.
IPv4 address 🌐
a 32-bit unicast, host address 🫶. Any network-reachable interface address is allowed here 🌸. Illegal addresses, like certain loopback addresses, SHOULD NOT be used 🚫.
Prefix length 🔢
32💅
Flags 🚩
0x01Local protection available 🛡️- this shows that the link downstream of this node is protected through a local repair mechanism 🧚. This flag can only be set if the Local protection flag was set in the
SESSION_ATTRIBUTEobject of the corresponding Path message 👑.
- this shows that the link downstream of this node is protected through a local repair mechanism 🧚. This flag can only be set if the Local protection flag was set in the
0x02Local protection in use 🔧- this shows that a local repair mechanism is in use to keep this tunnel up (usually when the link it was previously routed over goes down) 😭🦋.
4.4.1.2. Subobject 2: IPv6 address
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | IPv6 address (16 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 address (continued) | Prefix Length | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type 🏷️
0x02: IPv6 address 💜
Length 📏
the Length is the total length of the subobject in bytes, Type and Length fields included 🎀. It's always 20 ✨.
IPv6 address 🌍
a 128-bit unicast host address 💖.
Prefix length 🔢
128🫶
Flags 🚩
0x01Local protection available 🛡️- this shows that the link downstream of this node is protected through a local repair mechanism 🧚. This flag can only be set if the Local protection flag was set in the
SESSION_ATTRIBUTEobject of the corresponding Path message 👑.
- this shows that the link downstream of this node is protected through a local repair mechanism 🧚. This flag can only be set if the Local protection flag was set in the
0x02Local protection in use 🔧- this shows that a local repair mechanism is in use to keep this tunnel up (usually when the link it was previously routed over goes down) 😭🦋.
4.4.1.3. Subobject 3, Label ✨
Okay so the Type is 0x03, which is just the Label 🎀
The Length is the whole subobject's size in bytes, Type and Length fields included 💅
Flags has one bit for now: 0x01 = Global label. This flag says the label will be understood if it's received on any interface 🌈
The C-Type is copied from the Label Object, so whatever C-Type that object has, this one matches 💖
Contents of Label Object are also copied straight from the Label Object 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents of Label Object |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+4.4.2. Applicability 🌸
Only unicast sessions get the procedures defined here, so keep that in mind 💜
RRO can show up in RSVP for three main reasons, and it's giving multitasking 🧚
First, an RRO can work as a loop detection mechanism. It helps discover L3 routing loops, or loops that are baked into the explicit route itself. The exact procedure is described later in this document 🔥
Second, an RRO collects up-to-date, detailed, hop-by-hop path info about RSVP sessions. That's super valuable for the sender or receiver. Any path change (due to network topology changes) gets reported, so nothing gets hidden 👑
Third, the RRO syntax is designed so that, with minor changes, the whole object can be used as input to the EXPLICIT_ROUTE object. This is iconic because if the sender gets an RRO from the receiver in a Resv message, it can apply it to the EXPLICIT_ROUTE object in the next Path message. That's how you "pin down session path" 📌✨
4.4.3. Processing RRO 💖
Usually a node starts an RSVP session by adding the RRO to the Path message. The initial RRO has only one subobject: the sender's IP addresses. If the node also wants label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object 🎀
When an intermediate router gets a Path message containing an RRO, it stores a copy in the Path State Block. The RRO then gets used in the next Path refresh event for formatting Path messages. When a new Path message is about to go out, the router adds a new subobject to the RRO and appends the resulting RRO to the Path message before sending 🦋
The newly added subobject MUST be this router's IP address. Main character energy, no notes 👑 The address to be added SHOULD be the interface address of the outgoing Path messages. If there are multiple addresses to pick from, the decision is a local matter. That said, it is RECOMMENDED that the same address be chosen consistently 💅
When the Label_Recording flag is set in the SESSION_ATTRIBUTE object, nodes doing route recording SHOULD include a Label Record subobject. If the node is using a global label space, then it SHOULD set the Global Label flag 🌈
The Label Record subobject gets pushed onto the RECORD_ROUTE object before the node's IP address does. A node MUST NOT push on a Label Record subobject without also pushing on an IPv4 or IPv6 subobject. Not me putting a label on nothing 💀
Heads up: when the initial Path message shows up, a node is unlikely to have a label to include yet. Once it gets one, the node SHOULD include the label in the RRO in the next Path refresh event 🍓
If the newly added subobject makes the RRO too big to fit in a Path (or Resv) message, the RRO object SHALL be dropped from the message, and message processing continues as normal. A PathErr (or ResvErr) message SHOULD be sent back to the sender (or receiver). The error code is "Notify" and the error value is RRO too large for MTU 🙈 If the receiver gets such a ResvErr, it SHOULD send a PathErr message with error code "Notify" and error value RRO notification 🫶
A sender that receives either of these error values SHOULD remove the RRO from the Path message. Don't keep the big RRO around, bestie 😭
Nodes SHOULD resend the above PathErr or ResvErr message each n seconds, where n is the greater of 15 and the refresh interval for the associated Path or RESV message. The node MAY apply limits and/or back-off timers to limit the number of messages sent. Basically, don't spam, but you can keep reminding them 🧚
An RSVP router can decide to send Path messages before its refresh time if the RRO in the next Path message is different from the previous one. This can happen if the contents of the RRO received from the previous hop router change, or if this RRO is newly added to (or deleted from) the Path message 🌸
When the destination node of an RSVP session gets a Path message with an RRO, that means the sender node needs route recording. The destination node kicks off the RRO process by adding an RRO to Resv messages. The processing mirrors the Path messages. The only difference is that the RRO in a Resv message records the path information in the reverse direction 🔁
Note that each node along the path will now have the complete route from source to destination. The Path RRO has the route from the source to this node, and the Resv RRO has the route from this node to the destination. This is super useful for network management 📊✨
A received Path message without an RRO means the sender node no longer needs route recording. Subsequent Resv messages SHALL NOT contain an RRO. Route recording is officially over, no cap 🫶
4.4.4. Loop Detection 🔥
As part of processing an incoming RRO, an intermediate router looks into all the subobjects contained within it. If the router figures out that it's already in the list, a forwarding loop exists 😳
An RSVP session is loop-free if downstream nodes receive Path messages, or upstream nodes receive Resv messages, with no routing loops detected in the contained RRO. That's the goal, periodt 💜
There are two broad classes of forwarding loops. The first is the transient loop. It happens as a normal part of operations, while L3 routing tries to converge on a consistent forwarding path for all destinations. The second is the permanent loop, which normally results from network mis-configuration 🙃
The action a node takes on receipt of an RRO depends on the message type the RRO came in. Context matters, iykyk 🌈
For Path messages containing a forwarding loop, the router builds and sends a "Routing problem" PathErr message with the error value loop detected, and then drops the Path message. Until the loop is eliminated, the session is not suitable for forwarding data packets. How the loop eliminated is beyond the scope of this document 🦋
For Resv messages containing a forwarding loop, the router simply drops the message. Resv messages should not loop if Path messages do not loop ✨
4.4.5. Forward Compatibility 🧚
New subobjects may be defined for the RRO, so the list can grow 🌱 When processing an RRO, unrecognized subobjects SHOULD be ignored and passed on. When processing an RRO for loop detection, a node SHOULD parse over any unrecognized objects 💅
Here's the lowkey genius part: loop detection works by spotting subobjects that the node itself inserted on an earlier pass of the object. This makes sure the subobjects needed for loop detection are always understood 🫶
4.4.6. Non-support of RRO 🙈
The RRO object is to be used only when all routers along the path support RSVP and the RRO object. The RRO object gets a class value of the form 0bbbbbbb. So RSVP routers that don't support the object will respond with an Unknown Object Class error 💀
4.5. Error Codes for ERO and RRO 🎀
In the processing described above, certain errors must be reported as either a "Routing Problem" or "Notify". The value of the "Routing Problem" error code is 24, and the value of the "Notify" error code is 25 💖
Here are the error values for the Routing Problem Error Code:
Value Error:
1 Bad EXPLICIT_ROUTE object
2 Bad strict node
3 Bad loose node
4 Bad initial subobject
5 No route available toward destination
6 Unacceptable label value
7 RRO indicated routing loops
8 MPLS being negotiated, but a non-RSVP-capable router
stands in the path
9 MPLS label allocation failure
10 Unsupported L3PIDFor the Notify Error Code, the 16 bits of the Error Value field look like this:
ss00 cccc cccc ccccThe high order bits are as defined under Error Code 1. (See [1].) 🔁
When ss = 00, these subcodes are defined:
1 RRO too large for MTU
2 RRO notification
3 Tunnel locally repaired4.6. Session, Sender Template, and Filter Spec Objects 💜
New C-Types are defined for the SESSION, SENDER_TEMPLATE and FILTER_SPEC objects. Bestie, this is the glow-up 🌸
The LSP_TUNNEL objects have the following format:
4.6.1. Session Object 🦋
4.6.1.1. LSP_TUNNEL_IPv4 Session Object ✨
Class = SESSION, LSP_TUNNEL_IPv4 C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+IPv4 tunnel end point address is the IPv4 address of the egress node for the tunnel 🌈
Tunnel ID is a 16-bit identifier used in the SESSION. It stays constant over the life of the tunnel 💖
Extended Tunnel ID is a 32-bit identifier used in the SESSION that also stays constant over the life of the tunnel. It's normally set to all zeros. Ingress nodes that want to narrow the scope of a SESSION to the ingress-egress pair can put their IPv4 address here as a globally unique identifier. Super smart, not gonna lie 🧚👑
4.6.1.2. LSP_TUNNEL_IPv6 Session Object
okay so this one's the IPv6 version of the tunnel SESSION object, and it's giving main character energy 💖✨
Class = SESSION, LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel end point address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IPv6 tunnel end point address 🌸 this is the IPv6 address of the egress node for the tunnel. The egress is the far end, so this is where your tunnel is headed. 🧚
- Tunnel ID 🎀 a 16-bit identifier that shows up in the SESSION and stays the same for the whole life of the tunnel. Consistent, iconic behavior.
- Extended Tunnel ID 💅 a 16-byte identifier, also in the SESSION, that stays constant for the tunnel's whole life. It's normally all zeros, but ingress nodes that want to narrow the SESSION down to just the ingress-egress pair can put their IPv6 address here as a globally unique identifier. Ngl that's a super clean move 😭🔥
4.6.2. Sender Template Object
4.6.2.1. LSP_TUNNEL_IPv4 Sender Template Object
okay so the sender template is basically "who's sending," and the IPv4 flavor looks like this 🦋
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv4 C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 tunnel sender address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IPv4 tunnel sender address 💖 the IPv4 address for a sender node.
- LSP ID 🫶 a 16-bit identifier that's used in both the SENDER_TEMPLATE and the FILTER_SPEC. It can be changed so a sender can share resources with itself, which is lowkey genius 🧠✨
4.6.2.2. LSP_TUNNEL_IPv6 Sender Template Object
same energy, but it's the IPv6 glow-up 🌈
Class = SENDER_TEMPLATE, LSP_TUNNEL_IPv6 C_Type = 8
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 tunnel sender address |
+ +
| (16 bytes) |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MUST be zero | LSP ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IPv6 tunnel sender address 🌸 the IPv6 address for a sender node.
- LSP ID 💅 same deal as the IPv4 version: a 16-bit identifier used in the SENDER_TEMPLATE and the FILTER_SPEC that can be changed so a sender can share resources with itself. Periodt 💜
4.6.3. Filter Specification Object
4.6.3.1. LSP_TUNNEL_IPv4 Filter Specification Object
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv4 C-Type = 7the IPv4 FILTER_SPEC is literally a copy of the IPv4 SENDER_TEMPLATE, no notes 🙈 same format, same vibes.
4.6.3.2. LSP_TUNNEL_IPv6 Filter Specification Object
Class = FILTER SPECIFICATION, LSP_TUNNEL_IPv6 C_Type = 8and the IPv6 FILTER_SPEC is identical to the IPv6 SENDER_TEMPLATE. twins 👯♀️🦋
4.6.4. Reroute and Bandwidth Increase Procedure
okay this section is the really iconic part 👑 it explains how to set up a tunnel that can keep its resource reservations (without double counting 🙅♀️) while it's getting rerouted or trying to bump up its bandwidth. no drama, just clean upgrades ✨
so first, in the initial Path message, the ingress node makes a SESSION object, assigns a Tunnel_ID, and puts its IPv4 address in the Extended_Tunnel_ID. it also makes a SENDER_TEMPLATE and assigns an LSP_ID. after that, tunnel setup just goes through the normal procedure 🌷
when the egress node gets that Path message, it sends a Resv message back toward the ingress node with the STYLE Shared Explicit 🫶
now say an ingress node already has a working path and wants to change it. it builds a new Path message like this: it reuses the existing SESSION object, so the Tunnel_ID and Extended_Tunnel_ID stay exactly the same. it picks a brand-new LSP_ID to make a new SENDER_TEMPLATE, and it creates an EXPLICIT_ROUTE object for the new route. then the new Path message gets sent, and the ingress node refreshes both the old and new path messages 🧚
the egress node answers with a Resv message that has an SE flow descriptor formatted like this:
<FLOWSPEC><old_FILTER_SPEC><old_LABEL_OBJECT><new_FILTER_SPEC>
<new_LABEL_OBJECT>(bestie note, this one's important 🚨: if the PHOPs are different, then two messages get sent, each one with the matching FILTER_SPEC and LABEL_OBJECT.)
once the ingress node gets the Resv message(s), it's allowed to start using the new route. it SHOULD send a PathTear message for the old route 🧹✨
4.7. Session Attribute Object
the Session Attribute Class is 207 💜 there are two C_Types, LSP_TUNNEL (C-Type = 7) and LSP_TUNNEL_RA (C-Type = 1). the LSP_TUNNEL_RA one has all the same fields as LSP_TUNNEL, plus it carries resource affinity information. here are the formats 🎀
4.7.1. Format without resource affinities
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL C-Type = 7
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Setup Priority 👑 how important the session is when it comes to grabbing resources, in the range of 0 to 7. 0 is the highest priority. this is what decides whether this session can preempt another session 💅
- Holding Priority 🌸 how important the session is when it comes to keeping resources, in the range of 0 to 7. 0 is the highest priority. this is what decides whether this session can be preempted by another session 😭
- Flags 🚩 these are the flags:
0x01Local protection desired 🛡️ this lets transit routers use a local repair mechanism, which might violate the explicit route object. if a fault shows up on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. literally so fast 🏃♀️💨0x02Label recording desired 🏷️ this flag says label information should be included when doing a route record.0x04SE Style desired ✨ this flag says the tunnel ingress node may choose to reroute this tunnel without tearing it down. a tunnel egress node SHOULD use the SE Style when it responds with a Resv message 🦋
- Name Length 🍓 the length of the display string before padding, in bytes.
- Session Name 🧚 a null padded string of characters.
4.7.2. Format with resource affinities ✨
okay so this is the version with the resource affinities baked in 💅 the class is 207 and the C-Type is 1 (LSP_TUNNEL_RA) 🦋
SESSION_ATTRIBUTE class = 207, LSP_TUNNEL_RA C-Type = 1
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags | Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Session Name (NULL padded display string) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Exclude-any 🚫
This is a 32-bit vector holding a set of attribute filters linked to a tunnel. If any one of them shows up, the link is unacceptable. 💀
Include-any 🌸
This is a 32-bit vector holding a set of attribute filters linked to a tunnel. If any one of them shows up, the link is acceptable (for this test). An all-zero set automatically passes. ✨
Include-all 👑
This is a 32-bit vector holding a set of attribute filters linked to a tunnel. Every one of them has to be present for the link to be acceptable (for this test). An all-zero set automatically passes. 💜
Setup Priority 🍓
This is how important the session is when it comes to grabbing resources, from 0 to 7. 0 is the highest priority. Setup Priority decides whether this session can preempt another session. 🔥
Holding Priority 🧚
This is how important the session is when it comes to keeping resources, from 0 to 7. 0 is the highest priority. Holding Priority decides whether this session can be preempted by another session. 🫶
Flags 🎀
0x01Local protection desired: this flag lets transit routers use a local repair mechanism, which may end up violating the explicit route object. When a fault is spotted on an adjacent downstream link or node, a transit router can reroute traffic for fast service restoration. ⚡0x02Label recording desired: this flag says label info should be included when doing a route record. 🏷️0x04SE Style desired: this flag says the tunnel ingress node may choose to reroute this tunnel without tearing it down. A tunnel egress node SHOULD use the SE Style when responding with a Resv message. 🦋
Heads up bestie: that SHOULD on the SE Style is an actual requirement, not a vibe. 🙈
Name Length 📏
The length of the display string before padding, counted in bytes. 💖
Session Name 🌈
A null padded string of characters. 🌸
4.7.3. Procedures applying to both C-Types 🧁
okay so the setup and holding priorities are OPTIONAL to support 🙈 a node can recognize this info and still be unable to actually do the operation. even so, it SHOULD pass the info downstream unchanged. that's the polite move 🫶
so like I said earlier, preemption is run by two priorities 👑 Setup Priority is for grabbing resources, and Holding Priority is for keeping them. to be specific, Holding Priority is the priority that resources assigned to this session get reserved at. ALSO the Setup Priority SHOULD never be higher than the Holding Priority for a given session. no exceptions, bestie 💅
the setup and holding priorities are basically the same thing as the preemption and defending priorities from [9] 🦋 how the two objects interact is ultimately policy stuff, but the following default interaction is RECOMMENDED 🌸
when both objects are present, the preemption priority policy element is the one that gets used. there's a mapping between the two priority spaces: a session attribute priority S maps to a preemption priority P with the formula P = 2^(14-2S). the reverse mapping is in this table 👇
Preemption Priority Session Attribute Priority
0 - 3 7
4 - 15 6
16 - 63 5
64 - 255 4
256 - 1023 3
1024 - 4095 2
4096 - 16383 1
16384 - 65535 0when a new Path message is up for admission, the requested bandwidth gets compared with the bandwidth available at the priority in Setup Priority 🎀
if the requested bandwidth isn't available, a PathErr message comes back with Error Code 01, Admission Control Failure, and Error Value 0x0002 🙃 the first 0 in the Error Value is a globally defined subcode and isn't informational. the 002 means "requested bandwidth unavailable" 💀
if the requested bandwidth is less than the unused bandwidth, processing is complete ✨ if the requested bandwidth is available but it's being used by lower priority sessions, then those lower priority sessions (starting with the lowest priority) MAY be preempted to free up the bandwidth needed 🔥
when preemption is supported, each preempted reservation triggers a TC_Preempt() upcall to local clients, and that upcall passes a subcode that says why 🧚 a ResvErr and/or PathErr with the code "Policy Control failure" SHOULD be sent toward the downstream receivers and upstream senders 📣
the support of local-protection is OPTIONAL 🌈 a node may recognize the local-protection Flag but still be unable to perform the requested operation. in that case, the node SHOULD pass the info downstream unchanged 🫶
recording the Label subobject in the ROUTE_RECORD object is controlled by the label-recording-desired flag in the SESSION_ATTRIBUTE object. the Label subobject isn't needed for every app, so it doesn't get recorded automatically 🙅♀️ the flag lets apps ask for it only when they actually need it 💖
the Session Name field is a string, usually made of displayable characters 🌸 the Length MUST always be a multiple of 4 and MUST be at least 8 ✨ if the object length isn't a multiple of 4, the object gets padded with trailing NULL characters. the Name Length field holds the actual string length 📏
4.7.4. Resource Affinity Procedures 🧲
resource classes and resource class affinities are described in [3] 📚 in this doc we just call the latter term "resource affinities" because it's shorter 💅 resource classes can be attached to links and advertised in routing protocols. RSVP uses resource class affinities in two ways. to get validated, a link MUST pass the three tests below. if a link fails a test, a PathErr with the code "policy control failure" SHOULD be sent 🙈
when a new reservation is being considered for admission over a strict node in an ERO, a node MAY validate the resource affinities against the resource classes of that link 🦋 when a node is choosing links to extend a loose node of an ERO, the node MUST validate the resource classes of those links against the resource affinities 👑 if no acceptable links can be found to extend the ERO, the node SHOULD send a PathErr message with the error code "Routing Problem" and the error value "no route available toward destination" 😭
to get validated, a link MUST pass the following three tests 💖
to describe the tests precisely, use the definitions from the object description above. we also define:
Link-attr 🌷 a 32-bit vector representing the attributes associated with a link.
the three tests are:
- Exclude-any 🚫 this test excludes a link from consideration if the link carries any of the attributes in the set.
(link-attr & exclude-any) == 0- Include-any ✨ this test accepts a link if the link carries any of the attributes in the set.
(include-any == 0) | ((link-attr & include-any) != 0)- Include-all 👑 this test accepts a link only if the link carries all of the attributes in the set.
(include-all == 0) | (((link-attr & include-all) ^ include-
all) == 0)for a link to be acceptable, all three tests MUST pass 🫶 if the test fails, the node SHOULD send a PathErr message with the error code "Routing Problem" and the error value "no route available toward destination" 🙃
if a Path message contains multiple SESSION_ATTRIBUTE objects, only the first one is meaningful 🎀 the later ones can be ignored and don't need to be forwarded.
all RSVP routers, whether they support the SESSION_ATTRIBUTE object or not, SHALL forward the object unmodified 🌈 the presence of non-RSVP routers anywhere between senders and receivers has no impact on this object 🦋
5. Hello Extension 💖
Okay so the RSVP Hello extension is how RSVP nodes check whether their neighbor is still alive 👀 It's giving "u up?" but for routers 😭 It gives you node to node failure detection, and when a failure is detected it gets handled pretty much the same way as a link layer communication failure ✨ This is meant for times when link layer failure notifications aren't available and you're not using unnumbered links, or when the link layer's own failure detection just isn't fast enough to catch a dead node in time 🦋
Ngl, node failure detection is not the same thing as link failure detection 🙅♀️ Especially when you've got multiple parallel unnumbered links. Keep that in mind, bestie 🫶
The Hello extension is specifically built so that one side can use it while the other side doesn't 🌈 Neighbor failure detection can kick off at any time. That includes when neighbors first meet each other, or just while they're already sharing Resv or Path state 💜
The Hello extension is made of a Hello message, a HELLO REQUEST object, and a HELLO ACK object 🎀 Hello processing between two neighbors lets each side pick its own failure detection intervals, which are usually configured 🌸 Each neighbor can issue HELLO REQUEST objects on its own, and every request gets an acknowledgment back ✨ Hello Messages also carry enough info that one neighbor can stop sending hello requests and still do neighbor failure detection anyway 👑 A Hello message can also be tucked inside a bundle message as a sub-message 🧚
Here's the big idea 💅 Neighbor failure detection works by collecting and storing a neighbor's "instance" value. If that value changes, or if the neighbor isn't properly reporting the value we've advertised to it, then the neighbor is presumed to have reset 😭 Whenever a neighbor's value changes or communication with it gets lost, the instance value we advertise to that neighbor also changes 🔥 The HELLO objects give us a way to poll for an instance value and to provide one. A poll request also includes the sender's instance value, so the receiver of a poll can optionally treat that poll as an implicit poll response 🙈 This optional handling is an optimization, and it can cut down on the total number of polls and responses that a pair of neighbors has to process 💀 When both sides support the optimization, the result is just one set of polls and responses per failure detection interval 🌈 Depending on the intervals you pick, you can get the same benefit even if only one neighbor supports it ⭐
5.1. Hello Message Format
Hello Messages are always sent between two RSVP neighbors 💖 The IP source address is the IP address of the sending node, and the IP destination address is the IP address of the neighbor node 🦋
The HELLO mechanism is meant for immediate neighbors 🫶 When HELLO messages are being exchanged between immediate neighbors, the IP TTL field of all outgoing HELLO messages SHOULD be set to 1 ✨
The Hello message has a Msg Type of 20 🎀 Here's what the Hello message format looks like:
<Hello Message> ::= <Common Header> [ <INTEGRITY> ]
<HELLO>5.2. HELLO Object formats
The HELLO Class is 22 🌸 There are two C_Types defined, bestie 👑
5.2.1. HELLO REQUEST object
Class = HELLO Class, C_Type = 1 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+5.2.2. HELLO ACK object
Class = HELLO Class, C_Type = 2 🦋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Src_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dst_Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Src_Instance: 32 bits 🔥
This is a 32 bit value that represents the sender's instance. The advertiser keeps a per neighbor representation/value. This value MUST change when the sender is reset, when the node reboots, or when communication is lost to the neighboring node, and otherwise it stays the same. This field MUST NOT be set to zero (0) 🙅♀️
Dst_Instance: 32 bits 🌈
This is the most recently received Src_Instance value from the neighbor. This field MUST be set to zero (0) when no value has ever been seen from the neighbor 💅
5.3. Hello Message Usage
The Hello Message is completely OPTIONAL 🎀 All messages may be ignored by nodes that don't want to take part in Hello message processing. The rest of this section assumes that the receiver as well as the sender is participating. In particular, the use of MUST and SHOULD with respect to the receiver only applies to a node that supports Hello message processing 🫶
A node periodically generates a Hello message containing a HELLO REQUEST object for each neighbor whose status is being tracked ⏰ The periodicity is governed by the hello_interval. This value MAY be configured on a per neighbor basis. The default value is 5 ms ✨
When generating a message containing a HELLO REQUEST object, the sender fills in the Src_Instance field with a value that represents its per neighbor instance. This value MUST NOT change while the agent is exchanging Hellos with the corresponding neighbor 💜 The sender also fills in the Dst_Instance field with the Src_Instance value most recently received from the neighbor. For reference, we'll call this variable Neighbor_Src_Instance. If no value has ever been received from the neighbor, or this node considers communication to the neighbor to have been lost, then Neighbor_Src_Instance is set to zero (0). The generation of a message SHOULD be suppressed when a HELLO REQUEST object was received from the destination node within the prior hello_interval interval 🙈
On receipt of a message containing a HELLO REQUEST object, the receiver MUST generate a Hello message containing a HELLO ACK object 🔥 The receiver SHOULD also verify that the neighbor hasn't reset. It does this by comparing the sender's Src_Instance field value with the previously received value. If Neighbor_Src_Instance is zero and the Src_Instance field is non-zero, then Neighbor_Src_Instance gets updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost 😭
The receiver of a HELLO REQUEST object SHOULD also verify that the neighbor is reflecting back the receiver's Instance value 🪞 It does this by comparing the received Dst_Instance field with the Src_Instance field value most recently transmitted to that neighbor. If the neighbor keeps advertising a wrong non-zero value after a configured number of intervals, then the node MUST treat the neighbor as if communication has been lost 💀
On receipt of a message containing a HELLO ACK object, the receiver MUST verify that the neighbor hasn't reset. It does this by comparing the sender's Src_Instance field value with the previously received value. If Neighbor_Src_Instance is zero and the Src_Instance field is non-zero, then Neighbor_Src_Instance gets updated with the new value. If the value differs or the Src_Instance field is zero, then the node MUST treat the neighbor as if communication has been lost 🌸
The receiver of a HELLO ACK object MUST also verify that the neighbor is reflecting back the receiver's Instance value. If the neighbor advertises a wrong value in the Dst_Instance field, then a node MUST treat the neighbor as if communication has been lost 👑
If no Instance values are received, via either REQUEST or ACK objects, from a neighbor within a configured number of hello_intervals, then a node MUST presume that it can't communicate with the neighbor. The default for this number is 3.5 🧚
When communication is lost or presumed lost as described above, a node MAY re-initiate HELLOs 🦋 If a node does re-initiate, it MUST use a Src_Instance value different from the one advertised in the previous HELLO message. This new value MUST continue to be advertised to the corresponding neighbor until a reset or reboot occurs, or until another communication failure is detected. If a new instance value hasn't been received from the neighbor, then the node MUST advertise zero in the Dst_instance value field 🫶
5.4. Multi-Link Considerations
As mentioned before, the Hello extension is aimed at detecting node failures, not per link failures 🎯 When there's only one link between neighboring nodes, or when all links between a pair of nodes fail, the difference between node and link failures isn't really meaningful, and handling those failures has already been covered 💅 When there are multiple links shared between neighbors, there are special considerations 👀 When the links between neighbors are numbered, Hellos MUST be run on each link, and the previously described mechanisms apply 🔥
When the links are unnumbered, link failure detection MUST be provided by some means other than Hellos 🙅♀️ Each node SHOULD use a single Hello exchange with the neighbor ✨ The case where all links have failed is the same as the no received value case mentioned in the previous section 🌈
5.5. Compatibility
The Hello extension doesn't affect the processing of any other RSVP message 💜 The only effect is that a link (node) down event can be declared sooner than it otherwise would have been. The RSVP response to that condition stays unchanged 🎀
The Hello extension is fully backwards compatible 🫶 The Hello class is assigned a class value of the form 0bbbbbbb. Depending on the implementation, implementations that don't support the extension will either silently discard Hello messages or respond with an "Unknown Object Class" error 🙈 Either way, the sender won't see an acknowledgment for the Hello it issued 😭
6. Security Considerations 🔐
In principle, these extensions to RSVP pose no security exposures beyond what RFC 2205[1] already covers 🛡️ However, there's a slight change in the trust model, and it's a big deal 😱 Traffic sent on a normal RSVP session can be filtered according to source and destination addresses, as well as port numbers. In this specification, filtering only happens based on an incoming label 🏷️ For this reason, an administration may want to limit the domain over which LSP tunnels can be established 🚧 This can be done by setting filters on various ports to deny action on an RSVP path message with a SESSION object of type LSP_TUNNEL_IPv4 (7) or LSP_TUNNEL_IPv6 (8) 💅🔥
7. IANA Considerations ✨
okay so IANA is the crew that handles the official number registries for RSVP protocol parameters 📋💖 Here in this doc, we get two brand-new objects: EXPLICIT_ROUTE and ROUTE_RECORD. Both of them hold subobjects inside, so this section lays out the rules for how subobject numbers get handed out 🧚 It follows the terminology from BCP 26 "Guidelines for Writing an IANA Considerations Section in RFCs" [15] (very serious name, very iconic 💅)
EXPLICIT_ROUTE Subobject Type
EXPLICIT_ROUTE Subobject Type is a 7-bit number that tells you what job the subobject does 🦋 There are no range restrictions, so every possible value is up for grabs.
Following the policies in [15], subobject types in the range 0 - 63 (0x00 - 0x3F) get allocated through an IETF Consensus action. Codes in the range 64 - 95 (0x40 - 0x5F) are First Come First Served, and codes in the range 96 - 127 (0x60 - 0x7F) are reserved for Private Use 🌸
ROUTE_RECORD Subobject Type
ROUTE_RECORD Subobject Type is an 8-bit number that identifies the function of the subobject ✨ Again, no range restrictions, so all possible values are available for assignment.
Following the policies outlined in [15], subobject types in the range 0 - 127 (0x00 - 0x7F) are allocated through an IETF Consensus action. Codes in the range 128 - 191 (0x80 - 0xBF) are allocated as First Come First Served, and codes in the range 192 - 255 (0xC0 - 0xFF) are reserved for Private Use 🎀
The following assignments are made in this document. 👑
7.1. Message Types
Message Message
Number Name
20 Hello7.2. Class Numbers and C-Types
Class Class
Number Name
1 SESSION
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
10 FILTER_SPEC
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
11 SENDER_TEMPLATE
Class Types or C-Types:
7 LSP Tunnel IPv4
8 LSP Tunnel IPv6
16 RSVP_LABEL
Class Types or C-Types:
1 Type 1 Label
19 LABEL_REQUEST
Class Types or C-Types:
1 Without Label Range
2 With ATM Label Range
3 With Frame Relay Label Range
20 EXPLICIT_ROUTE
Class Types or C-Types:
1 Type 1 Explicit Route
21 ROUTE_RECORD
Class Types or C-Types:
1 Type 1 Route Record
22 HELLO
Class Types or C-Types:
1 Request
2 Acknowledgment
207 SESSION_ATTRIBUTE
Class Types or C-Types:
1 LSP_TUNNEL_RA
7 LSP Tunnel7.3. Error Codes and Globally-Defined Error Value Sub-Codes
The following list extends the basic list of Error Codes and Values that are defined in [RFC2205] 🔥
Error Code Meaning
24 Routing Problem
This Error Code has the following globally-defined
Error Value sub-codes:
1 Bad EXPLICIT_ROUTE object
2 Bad strict node
3 Bad loose node
4 Bad initial subobject
5 No route available toward
destination
6 Unacceptable label value
7 RRO indicated routing loops
8 MPLS being negotiated, but a
non-RSVP-capable router stands
in the path
9 MPLS label allocation failure
10 Unsupported L3PID
25 Notify Error
This Error Code has the following globally-defined
Error Value sub-codes:
1 RRO too large for MTU
2 RRO Notification
3 Tunnel locally repaired7.4. Subobject Definitions
Subobjects of the EXPLICIT_ROUTE object with C-Type 1:
1 IPv4 prefix
2 IPv6 prefix
32 Autonomous system number
Subobjects of the RECORD_ROUTE object with C-Type 1:
1 IPv4 address
2 IPv6 address
3 Label8. Intellectual Property Considerations ✨
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. ⭐
9. Acknowledgments 🫶
This document contains ideas as well as text that have appeared in previous Internet Drafts. The authors of the current document wish to thank the authors of those drafts. They are Steven Blake, Bruce Davie, Roch Guerin, Sanjay Kamat, Yakov Rekhter, Eric Rosen, and Arun Viswanathan. We also wish to thank Bora Akyol, Yoram Bernet and Alex Mondrus for their comments on this document. 💜
10. References 📚
[1] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1, Functional
Specification", RFC 2205, September 1997.
[2] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label
Switching Architecture", RFC 3031, January 2001.
[3] Awduche, D., Malcolm, J., Agogbua, J., O'Dell and J. McManus,
"Requirements for Traffic Engineering over MPLS", RFC 2702,
September 1999.
[4] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service", RFC 2211, September 1997.
[5] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D.,
Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032,
January 2001.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Almquist, P., "Type of Service in the Internet Protocol Suite",
RFC 1349, July 1992.
[8] 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.
[9] Herzog, S., "Signaled Preemption Priority Policy Element", RFC
2751, January 2000.
[10] Awduche, D., Hannan, A. and X. Xiao, "Applicability Statement
for Extensions to RSVP for LSP-Tunnels", RFC 3210, December
2001.
[11] Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
RFC 2210, September 1997.
[12] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
September 1981.
[13] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[14] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 2463,
December 1998.
[15] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[16] Bernet, Y., Smiht, A. and B. Davie, "Specification of the Null
Service Type", RFC 2997, November 2000.11. Authors' Addresses 🎀
Daniel O. Awduche
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703-298-5291
EMail: awduche@movaz.com
Lou Berger
Movaz Networks, Inc.
7926 Jones Branch Drive, Suite 615
McLean, VA 22102
Voice: +1 703 847 1801
EMail: lberger@movaz.com
Der-Hwa Gan
Juniper Networks, Inc.
385 Ravendale Drive
Mountain View, CA 94043
EMail: dhg@juniper.net
Tony Li
Procket Networks
3910 Freedom Circle, Ste. 102A
Santa Clara CA 95054
EMail: tli@procket.com
Vijay Srinivasan
Cosine Communications, Inc.
1200 Bridge Parkway
Redwood City, CA 94065
Voice: +1 650 628 4892
EMail: vsriniva@cosinecom.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA 01824
Voice: +1 978 244 8143
EMail: swallow@cisco.com12. Full Copyright Statement 🌈
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein 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. 🦋
📦 where this page comes from
- ietf: rfc3209 2001-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms