Procedures for Dynamically Signaled Hierarchical Label Switched Paths
updates
Extracted elements (29)
A unified approach using the LSP_TUNNEL_INTERFACE_ID object with different C-Types for numbered and unnumbered, IPv4 and IPv6 links was chosen to avoid implementation complexity while supporting all address families. The Actions field allows the ingress to explicitly communicate link usage to the egress during signaling, eliminating the need for out-of-band coordination or inference from IGP advertisements.
The IGP Instance Identifier TLV is optional and defaults to the same IGP instance (value 0xffffffff) to preserve backward compatibility with RFC 3477 and RFC 4206 for the FA use case, while enabling multi-layer networks (MLNs) to target a different IGP instance in the client network without requiring address space coordination across layers.
The numbered FA signaling procedure from RFC 4206 Section 1.3.6 is deprecated because it requires the egress to parse all received IGP advertisements to detect when it must issue a reverse FA advertisement — a complex, non-scalable process. An informal CCAMP survey found no significant deployments of this mechanism, making deprecation safe.
Backward compatibility with RFC 3477 C-Type 1 (unnumbered FA) is fully maintained; back-level ingress nodes continue to use C-Type 1 and back-level egresses continue to support it. The new unnumbered C-Type 4 with IGP Instance Identifier set to 0xffffffff is functionally equivalent to the existing C-Type 1 mechanism.
The LSP_TUNNEL_INTERFACE_ID object has class number 193, which per RFC 2205 causes nodes that do not understand it to ignore it but forward it unexamined. A back-level egress will reject Path messages with the new C-Types (2, 3, 4) using RFC 2205 procedures, informing the ingress that the egress is back-level.
An egress LSR that cannot accept parameters in a received LSP_TUNNEL_INTERFACE_ID object SHOULD respond with a PathErr using error code 38 (LSP Hierarchy Issue) and the appropriate error value. If the error arises after successful LSP setup, the PathErr SHOULD be sent with the Path_State_Removed flag clear so the LSP remains operational.
An ingress receiving a rejected LSP_TUNNEL_INTERFACE_ID object on a Resv SHOULD respond with a PathTear. The ingress MAY send a ResvErr to allow the egress to correct the error, but MUST guard against protocol loops if the egress responds with the same problematic object.
If a TE link created from an LSP is advertised in the same IGP instance as the traversed TE links, the addresses for the new link and the links it is built from MUST come from the same address space. If advertised into another IGP instance, addresses MAY be drawn from overlapping address spaces.
New implementations SHOULD place LSP_TUNNEL_INTERFACE_ID objects in Path messages immediately after the SENDER_TSPEC object and in Resv messages immediately after the FILTER_SPEC object. All implementations SHOULD handle received messages with objects in any order.
On a Resv message, the Actions field in LSP_TUNNEL_INTERFACE_ID SHOULD be set to reflect the value received on the corresponding Path message, and MUST be ignored on receipt.
Reserved bits in the Actions field and the Reserved word of the LSP_TUNNEL_INTERFACE_ID object MUST be set to zero on transmission and SHOULD be ignored on receipt.
The ingress and egress of an LSP set up using the LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as a link in accordance with the parameters agreed in the object. The TE link SHOULD inherit TE properties from the LSP as described in RFC 5212, subject to local policy.
The Target IGP Identification TLV MUST be ignored if found in an LSP_TUNNEL_INTERFACE_ID object in a Resv message, and SHOULD NOT be included there. Similarly it SHOULD NOT be present and MUST be ignored when the P-flag is set indicating a private link.
When an LSP carries multiple LSP_TUNNEL_INTERFACE_ID objects (to offer capacity to multiple networks), each instance MUST have a different IGP Instance Identifier. A Path/Resv MUST NOT contain more than one C-Type 1 object; if one is present, all other instances MUST include an IGP Instance Identifier TLV with a non-0xffffffff value identifying a different IGP instance.
When an LSP is torn down via PathTear or PathErr with Path_State_Removed set, the ingress and egress SHOULD withdraw any link advertisement the LSP created. The advertisement MAY be retained as a virtual link in another layer network per policy.
When the B-flag is set in the Actions field of the LSP_TUNNEL_INTERFACE_ID object in a Path message, exactly one Component Link Identifier TLV MUST be present in both the Path and Resv LSP_TUNNEL_INTERFACE_ID objects.
The 8-bit Actions field in the LSP_TUNNEL_INTERFACE_ID object carries five bit flags: P (Private, bit 7), T (TE link suppression, bit 6), R (Routing adjacency, bit 5), B (Bundle, bit 4), and H (Hierarchy/stitching, bit 3). All flags are simultaneously meaningful; a value of 0x00 indicates a standard FA.
The LSP_TUNNEL_INTERFACE_ID object (C-NUM 193) is extended with three new C-Types (2, 3, 4) to support IPv4 numbered, IPv6 numbered, and unnumbered links respectively, each carrying an Actions field and optional TLVs to indicate how the resulting TE link is to be used and advertised.
The Target IGP Identification TLV (Type 1) carries a 32-bit IGP Instance Identifier to tell the egress which IGP instance to use for advertising the new TE link. The reserved value 0xffffffff means 'same IGP instance as used for the traversed TE links'. Absent TLV implies the same default.
Three Component Link Identification TLVs identify the component link within a bundle: Type 2 (Unnumbered, 32-bit identifier), Type 3 (IPv4 Numbered, 32-bit address), and Type 4 (IPv6 Numbered, 128-bit address). When the B-flag is set, exactly one of these TLVs MUST appear in both Path and Resv objects.
IANA allocated three new Class Types for the LSP_TUNNEL_INTERFACE_ID object (C-NUM 193) in the RSVP Parameters registry: C-Type 2 (IPv4 interface identifier with target), C-Type 3 (IPv6 interface identifier with target), and C-Type 4 (Unnumbered interface with target).
IANA created the 'Hierarchy Actions' sub-registry under 'Generalized Multi-Protocol Label Switching (GMPLS) Signaling Parameters', with Standards Action registration procedure, defining bits 3–7: H (Hierarchy/stitching, 0x10), B (Bundle, 0x08), R (Routing adjacency, 0x04), T (TE link, 0x02), P (Private, 0x01).
IANA defined RSVP error code 38 ('LSP Hierarchy Issue') with 16 globally-defined error value sub-codes covering: link advertisement not supported/not allowed by policy, TE link creation, routing adjacency creation, bundle creation, hierarchical LSP not supported, LSP stitching not supported, link address family issues, IGP instance unknown/not allowed, component link identifier invalid/missing.
The ability of an ingress LSR to request that an egress LSR advertise an LSP as a TE link MUST be subject to appropriate policy checks at the egress LSR. The egress MUST NOT automatically accept such a request unless explicitly configured with a policy permitting it.
The extensions in this document do not constitute an additional security risk relative to RFC 3477. The extra interface identifier information could arguably make RSVP messages harder to spoof, representing a minor security improvement. Further MPLS-TE and GMPLS security details are in RFC 5920.
LSP setup for H-LSPs: ingress sends Path with LSP_TUNNEL_INTERFACE_ID (Forward Interface ID) containing Actions and optional TLVs; egress accepts and responds with Resv containing LSP_TUNNEL_INTERFACE_ID (Reverse Interface ID) mirroring the Actions field. Both endpoints then advertise the resulting TE link as specified. On teardown (PathTear/PathErr), advertisements are withdrawn.
C-Type 2 (IPv4 numbered interface with target): 32-bit IPv4 Interface Address, 8-bit Actions field, 24-bit Reserved, followed by variable-length TLVs. Used in Path and Resv messages to identify the numbered IPv4 TE link endpoint.
C-Type 3 (IPv6 numbered interface with target): 128-bit IPv6 Interface Address, 8-bit Actions field, 24-bit Reserved, followed by variable-length TLVs. Used in Path and Resv messages to identify the numbered IPv6 TE link endpoint.
C-Type 4 (Unnumbered interface with target): 32-bit LSR Router ID, 32-bit Interface ID, 8-bit Actions field, 24-bit Reserved, followed by variable-length TLVs. Used in Path (Forward Interface ID) and Resv (Reverse Interface ID) messages.