RSVP-TE: Extensions to RSVP for LSP Tunnels
updated by
- rfc-3936 — Procedures for Modifying the Resource reSerVation Protocol (RSVP)
- rfc-4420 — Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
- rfc-4874 — Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
- rfc-5151 — Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions
- rfc-5420 — Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)
- rfc-5711 — Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages
- rfc-6780 — RSVP ASSOCIATION Object Extensions
- rfc-6790 — The Use of Entropy Labels in MPLS Forwarding
- rfc-7274 — Allocating and Retiring Special-Purpose MPLS Labels
Extracted elements (29)
Make-before-break rerouting uses a new LSP ID in SENDER_TEMPLATE combined with the SE reservation style so that old and new LSPs share resources on common links without double-counting. This prevents Admission Control from rejecting the new LSP while the old one still holds reservations.
The Extended Tunnel ID in the LSP_TUNNEL SESSION object is normally zero (widest scope) but an ingress node may place its own IPv4 address there to narrow the SESSION to a unique ingress-egress pair, enabling multiple distinct TE tunnels between the same endpoints without SESSION collision.
The LABEL_REQUEST includes an L3PID field because the network layer protocol over an LSP cannot be inferred from the L2 header (which only identifies MPLS). This allows non-IP protocols to be carried and aids allocation of protocol-specific reserved MPLS labels.
The Wildcard Filter (WF) style is excluded from this specification because its merging rules are incompatible with EXPLICIT_ROUTE objects, and because it cannot provide proper per-link reservations when all senders transmit simultaneously, making it unsuitable for traffic engineering.
RRO syntax is designed so that, with minor changes, the entire object can be used as input to the EXPLICIT_ROUTE object. A sender can thus 'pin down' a session path by taking a received Resv RRO and applying it as the ERO in the next Path message.
The ERO and RRO are assigned class values of the form 0bbbbbbb, so RSVP nodes that do not recognize them respond with 'Unknown Object Class' errors, causing path setup to fail. Both objects MUST only be used when all routers along the path are RSVP-capable and support the respective object.
A node MUST NOT advertise the LABEL_REQUEST object in messages passing through non-RSVP-capable routers, and SHOULD send a PathErr with error code 'Routing problem' and error value 'MPLS being negotiated, but a non-RSVP capable router stands in the path' (value 8).
A node that receives and forwards a Path message containing a LABEL_REQUEST MUST copy the L3PID from the received object to the forwarded object. If the receiver cannot support the L3PID, it SHOULD send a PathErr with error value 'Unsupported L3PID' (value 10).
For ATM nodes that are not merge-capable (M-bit not set in LABEL_REQUEST), the downstream node MUST assign unique labels to those senders. Any node intending to police individual senders to a session MUST assign unique labels to those senders.
For labeled IPv4 datagrams where DF is set and size exceeds M (Path MTU minus label stack size), an LSR MUST NOT forward the datagram and MUST send an ICMP Destination Unreachable with code 'Fragmentation Required and DF Set' with Next-Hop MTU set to M. For IPv6 datagrams exceeding M, an ICMP Packet Too Big with Next-Hop MTU=M MUST be generated.
If a label range is specified in LABEL_REQUEST, the downstream node MUST allocate the label from that range. If no label is available, the node MUST send a PathErr with error code 'Routing problem' and error value 'MPLS label allocation failure' (value 9).
In Resv messages, the LABEL object for a sender MUST immediately follow the FILTER_SPEC for that sender, prior to any subsequent FILTER_SPEC. No more than one LABEL and/or RECORD_ROUTE may follow each FILTER_SPEC.
LABEL_REQUEST and LABEL objects are mandatory for LSP tunnel setup: a receiver that accepts a LABEL_REQUEST MUST include a LABEL object in corresponding Resv messages. Conversely, a node MUST NOT include a LABEL object in a Resv message if no LABEL_REQUEST was present in the corresponding Path message.
The EXPLICIT_ROUTE object (ERO, class 20, C-Type 1) specifies a path as a series of variable-length subobjects each describing an abstract node. Subobject types: 1=IPv4 prefix (8 bytes), 2=IPv6 prefix (20 bytes), 32=AS number (4 bytes). Each subobject carries an L-bit indicating loose (1) vs. strict (0) hop.
The HELLO message (message type 20) enables rapid detection of node failure or restart between adjacent RSVP nodes. It carries HELLO REQUEST (class 22, C-Type 1) or HELLO ACK (class 22, C-Type 2) objects, each containing a 32-bit Src_Instance (non-zero, changed on restart) and 32-bit Dst_Instance (last received Src_Instance; zero in initial Hello).
The LABEL object (class 16, C-Type 1) carries a single 32-bit MPLS label in Resv messages, binding a label to an LSP tunnel sender. Generic MPLS and FR labels are encoded right-aligned; ATM labels place VPI right-justified in bits 0–15 and VCI right-justified in bits 16–31.
The LABEL_REQUEST object (class 19) is carried in Path messages to request downstream label binding and identify the L3 protocol (L3PID as Ethertype) to be carried over the LSP. Three C-Types: Type 1 (no label range), Type 2 (ATM VPI/VCI range with M-bit for merge capability), Type 3 (Frame Relay DLCI range with DLI length indicator).
The RECORD_ROUTE object (RRO, class 21, C-Type 1) records the actual path of an LSP as a LIFO stack of subobjects added at each hop. Three subobject types: IPv4 address (type 1, 8 bytes), IPv6 address (type 2, 20 bytes), and Label (type 3). Address subobjects carry flags 0x01 (local protection available) and 0x02 (local protection in use).
The SESSION_ATTRIBUTE object (two C-Types) carries tunnel name, setup priority, hold priority, local-protection desired, label recording, and SE-style desired flags. The resource-affinity C-Type additionally carries 32-bit exclude-any, include-any, and include-all affinity bitmasks for constraint-based routing.
IANA allocations: HELLO message type=20; new classes LABEL=16, LABEL_REQUEST=19, EXPLICIT_ROUTE=20, RECORD_ROUTE=21, SESSION_ATTRIBUTE=207, HELLO=22; new SESSION/SENDER_TEMPLATE/FILTER_SPEC C-Types 7 (IPv4) and 8 (IPv6); error codes Routing Problem=24 (10 sub-values) and Notify=25 (3 sub-values including 'RRO too large for MTU' and 'Tunnel locally repaired').
The security considerations of base RSVP (RFC 2205) apply to this specification. LSP tunnels bypass normal IP routing and filtering mechanisms; operators should consider that label-switched traffic is opaque to intermediate nodes and may circumvent IP-layer access controls.
LSP setup state: ingress sends Path with LABEL_REQUEST; intermediate nodes forward Path and store state; egress allocates label and sends Resv with LABEL; each upstream node uses received LABEL as outgoing label, allocates new incoming label, updates ILM→NHLFE binding, and forwards Resv with new LABEL. LSP is established when Resv reaches ingress.
ERO subobject header: 1-bit L (loose/strict flag), 7-bit Type, 8-bit Length (MUST be a multiple of 4 and at least 4). IPv4 prefix subobject is always 8 bytes (4-octet address + 1-octet prefix length + 1-octet pad). IPv6 prefix subobject is always 20 bytes. AS number subobject is 4 bytes with 2-octet AS number.
LABEL object: class=16, C-Type=1, one 4-octet field containing the label value. Generic MPLS labels are unsigned integers 0–1048575 encoded right-aligned; ATM labels encode VPI in bits 0-15 and VCI in bits 16-31.
LABEL_REQUEST with ATM label range (class 19, C-Type 2): L3PID (16-bit), M-bit (merge-capable flag), 12-bit minimum VPI, 16-bit minimum VCI, 12-bit maximum VPI, 16-bit maximum VCI. VPI/VCI values shorter than the field width MUST be right-justified with leading zeros.
LABEL_REQUEST without label range (class 19, C-Type 1): 16-bit reserved (MUST be zero on transmission, ignored on receipt) followed by 16-bit L3PID encoded as a standard Ethertype value identifying the layer-3 protocol.
LSP_TUNNEL_IPv4 SENDER_TEMPLATE object (C-Type 7): 32-bit IPv4 tunnel sender address, 16-bit zero field, 16-bit LSP ID. The LSP ID distinguishes multiple concurrent LSPs within the same SESSION and enables make-before-break rerouting.
LSP_TUNNEL_IPv4 SESSION object (SESSION C-Type 7): 32-bit IPv4 tunnel endpoint address (egress node), 16-bit zero field, 16-bit Tunnel ID (constant for tunnel lifetime), 32-bit Extended Tunnel ID (normally zero; ingress may set to its IPv4 address to narrow session scope to an ingress-egress pair).
RRO Label subobject (type 3): 1-byte Flags (0x01=Global label), 1-byte C-Type (copied from Label object), followed by contents of the Label object. A node MUST NOT push a Label Record subobject without also pushing an IPv4 or IPv6 address subobject.