Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions
updated by
- rfc-4003 — GMPLS Signaling Procedure for Egress Control
- rfc-4201 — Link Bundling in MPLS Traffic Engineering (TE)
- rfc-4420 — Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
- rfc-4783 — GMPLS - Communication of Alarm Information
- rfc-4873 — GMPLS Segment Recovery
- rfc-4874 — Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
- rfc-4974 — Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in Support of Calls
- rfc-5063 — Extensions to GMPLS Resource Reservation Protocol (RSVP) Graceful Restart
- 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-6002 — Generalized MPLS (GMPLS) Data Channel Switching Capable (DCSC) and Channel Set Label Extensions
- rfc-6003 — Ethernet Traffic Parameters
- rfc-6780 — RSVP ASSOCIATION Object Extensions
- rfc-8359 — Network-Assigned Upstream Label
Extracted elements (32)
In GMPLS, Path, PathTear and ResvConf messages SHOULD be addressed directly to the adjacent node's control plane address (omitting the router-alert option) because routes are explicitly signaled and hops that cannot allocate labels cannot exist in the LSP path.
The Notify message was introduced to enable targeted, non-hop-by-hop failure notification to nodes responsible for LSP restoration, unlike PathErr and ResvErr which are hop-by-hop. It does not replace existing error messages but provides a faster, directed notification path.
The Path_State_Removed flag in ERROR_SPEC was introduced to allow intermediate nodes to release Path state on certain errors when RSVP is used with explicit routes. Without this flag, idle resources are held until the source receives the PathErr and sends a PathTear, which hampers rapid reconvergence during outages.
If an egress node does not support the Admin_Status object, it will not reflect it back in the Resv message. To handle this, the ingress SHOULD wait a configurable period (default 30 seconds) for the reflected Admin_Status before sending a PathTear.
The Path_State_Removed flag does not introduce interoperability incompatibilities; nodes that do not implement it simply leave the flag at zero and process PathErr messages per legacy behavior.
A node MUST NOT set the Path_State_Removed flag in a PathErr unless it has also removed the associated Path state or generated a PathTear. A node that receives a PathErr with Path_State_Removed=0 MUST NOT set the flag unless it also sends a PathTear.
A node receiving an IF_ID RSVP_HOP object SHOULD check consistency with any received ERO; if inconsistent, it MUST send a PathErr with error code 'Routing Error' / 'Bad Explicit Route Object'.
A Notify message MUST NOT be generated unless an appropriate Notify Request object has been previously received. When generating Notify messages for multiple LSPs sharing the same ERROR_SPEC, a node SHOULD combine them into a single message.
For bidirectional LSPs, Label RRO subobjects for both downstream and upstream labels MUST be included in the RRO when recording labels.
If the egress cannot support the indicated G-PID, it MUST generate a PathErr with 'Routing problem/Unsupported L3PID'. In the PSC penultimate-hop-popping case, if the G-PID is unsupported the penultimate hop MUST generate a ResvErr with 'Routing problem/Unacceptable label value'.
The Restart_Cap object MUST NOT be sent when there is no mechanism to detect data channel failures independent of control channel failures. Nodes supporting state recovery MUST include the Restart_Cap object in all Hello messages.
Transit and egress nodes MUST verify the LSP Encoding Type is supported; if not, they MUST generate a PathErr with 'Routing problem/Unsupported Encoding'. Nodes MUST also verify the Switching Type on the incoming interface; if unsupported, a PathErr with 'Routing problem/Switching Type' MUST be generated.
Transit nodes processing a Path message with a Protection object MUST verify the requested protection can be satisfied by the outgoing interface; if it cannot, they MUST generate a PathErr with 'Routing problem/Unsupported Link Protection'.
When a waveband is switched to another waveband with mirrored wavelengths, the Start and End Label fields in the waveband label MUST be flipped before forwarding. This MUST be performed in both directions for bidirectional waveband tunnels.
When an intersected Label Set is empty at a node, the Path MUST be terminated and a PathErr with 'Routing problem/Label Set' MUST be generated. The label propagated upstream in a Resv message MUST fall within the Label Set.
When establishing a bidirectional LSP, the Upstream_Label object MUST indicate a label that is valid for forwarding at the time the Path message is sent. An unacceptable upstream label MUST cause the receiver to issue a PathErr with 'Routing problem/Unacceptable label value'.
When sending Path messages to a neighbor that restarted with preserved forwarding state, the neighbor MUST include a Recovery_Label object with the label from the most recent Resv, and MUST send all Path state within approximately 1/2 of the Recovery Time. After detecting a restart, Resv state to the restarting node MUST NOT be refreshed until a corresponding Path message is received.
Bidirectional LSP setup is indicated by the presence of an Upstream_Label object (Class-Num 35, same format as generalized label) in the Path message. The upstream label is immediately usable for data traffic at the terminator, enabling simultaneous bidirectional data flow after Path/Resv exchange.
The Notify message (Message Type 21) provides non-adjacent LSP event notification. It may be forwarded hop-by-hop or encapsulated in a new IP header to the target address, and uses RFC 2961 Ack messages for reliable delivery.
RFC 3473 defines new RSVP IANA assignments: Notify message type (21); new Class-Nums for LABEL_SET (36), ACCEPTABLE_LABEL_SET (130), NOTIFY_REQUEST (195), PROTECTION (37), ADMIN_STATUS (196), RESTART_CAP (131), UPSTREAM_LABEL (35), SUGGESTED_LABEL (129), RECOVERY_LABEL (34); Label ERO/RRO subobject Type 3; and six new routing/notify error codes.
The Notify message can be sent in a non-hop-by-hop fashion, which precludes RSVP's hop-by-hop integrity and authentication model from RFC 2747. IPsec (AH or ESP) in transport mode SHOULD be used with automated key management (IKE) for non-hop-by-hop Notify messages; if IPsec is unavailable and security is required, Notify messages MUST be sent hop-by-hop.
Nodal fault recovery proceeds through: (1) Hello lost → wait Restart Time; (2) new Hello received → compare Src_Instance to determine control-channel-only vs. nodal fault; (3) if nodal, enter Recovery Period; (4) Path messages with Recovery_Label trigger MPLS forwarding table lookup to restore state; (5) state not resynchronized within Recovery Time is removed.
The Admin_Status object (Class-Num 196, C-Type 1) is a 32-bit field with R (Reflect), T (Testing), A (Administratively Down), and D (Delete) bits used to convey LSP administrative state in Path, Resv, and Notify messages.
The Generalized Label object (Class-Num 16, C-Type 2) carries a variable-length Label field and travels upstream in Resv messages. Presence of both a generalized and normal label object in a Resv message is a protocol error.
The Generalized Label Request object (Class-Num 19, C-Type 4) carries a 1-byte LSP Encoding Type, 1-byte Switching Type, and 2-byte G-PID field, set by the ingress and used by the egress to verify LSP parameters.
The IF_ID RSVP_HOP object (IPv4 C-Type 3, IPv6 C-Type 4) extends the standard RSVP_HOP with a Logical Interface Handle and variable-length TLVs identifying the data channel(s) when control and data channels are separated.
The Label ERO subobject (Type 3) contains an L-bit, U-bit, C-Type, and variable-length Label field; U-bit clear means downstream label, U-bit set means upstream label for bidirectional LSPs.
The Label Set object (Class-Num 36, C-Type 1) contains an Action byte, Reserved field, 14-bit Label Type, and one or more variable-length Subchannel fields. Actions 0–3 allow specific labels/ranges to be included or excluded.
The Notify Request object (Class-Num 195) carries an IPv4 (32-bit, C-Type 1) or IPv6 (128-bit, C-Type 2) Notify Node Address identifying the node to be sent failure notifications.
The Protection object (Class-Num 37, C-Type 1) carries an S-bit and Link Flags field describing the protection attributes of an LSP; it is optional and carried in Path messages.
The Restart_Cap object (Class-Num 131, C-Type 1) carries a 32-bit Restart Time (ms) and 32-bit Recovery Time (ms) in Hello messages; a Restart Time of 0xffffffff indicates an indeterminate restart interval with preserved data plane.
The Waveband Switching Label (Class-Num 16, C-Type 3) extends the generalized label format with three 32-bit fields: Waveband Id, Start Label, and End Label, used to identify a contiguous band of wavelengths.