RSVP-TE Extensions for Collecting Shared Risk Link Group (SRLG) Information
Extracted elements (27)
The document notes that knowledge of SRLG information across multiple LSPs does not allow a CE device to derive the provider network topology, though an entity controlling multiple CEs could infer some topology information. PE devices are therefore allowed to control the communication of SRLGs outside the provider network.
The dual-homing use case motivates SRLG collection: when CE1 has an established LSP1 via PE1, CE1 can collect LSP1's SRLGs and pass them as exclusion constraints (via XRO/EXRS per RFC 4874) to PE2 when requesting a diverse LSP2, solving the diversity problem across a provider network without exposing provider topology.
The SRLG collection mechanism uses two distinct objects — LSP_REQUIRED_ATTRIBUTES and LSP_ATTRIBUTES — to allow the ingress node to choose between mandatory SRLG collection (which may cause LSP establishment failure if unsupported) and best-effort collection (which allows the LSP to be established even if some nodes cannot supply SRLG data).
The SRLG subobject interaction with Path Key Subobject (RFC 5553) is explicitly addressed: when a Confidential Path Segment is replaced by a PKS in the RRO, any SRLG subobjects from the hidden segment MAY be retained by adding them after the PKS, preserving SRLG information while protecting topology confidentiality.
A node that does not recognize the RRO SRLG subobject will ignore it and pass it on unchanged, as specified in RFC 3209 for unrecognized subobjects.
A node that does not recognize the SRLG Collection Flag in the Attribute Flags TLV will pass it unaltered if in an LSP_ATTRIBUTES object, or reject the Path message with the appropriate error if in an LSP_REQUIRED_ATTRIBUTES object, per RFC 5420.
At domain boundaries, a node MAY remove SRLG information from RROs and MAY add a summary or mapped values. However, this SHOULD NOT be done unless explicitly mandated by local policy, preserving maximum SRLG visibility by default.
A node MUST NOT add SRLG information to the RRO without an explicit request by the ingress node in the Path message.
A node MUST NOT push an SRLG subobject in the ROUTE_RECORD without also pushing either an IPv4 subobject, an IPv6 subobject, an Unnumbered Interface ID subobject, or a Path Key Subobject (PKS).
At border nodes of inter-domain or inter-layer networks, the following SRLG processing policies MUST be capable of being configured: (1) participation in SRLG collection and change notification, and (2) whether SRLG IDs can be exposed, summarized, mapped, or removed at domain boundaries.
For bidirectional LSPs, the node MUST include SRLG information in the same order for both Path and Resv messages: the upstream SRLG subobject is added to the RRO before the downstream SRLG subobject.
For bidirectional LSPs, upstream and downstream SRLG data MUST be added in separate SRLG subobjects. A single SRLG subobject MUST NOT contain a mixture of upstream and downstream SRLGs. The D-bit MUST be set appropriately to indicate direction.
If adding SRLG information would cause the RRO to exceed its maximum size, the requested SRLGs MUST NOT be added. If the request was in LSP_REQUIRED_ATTRIBUTES, the node MUST drop the RRO entirely per RFC 3209; if in LSP_ATTRIBUTES, it MAY omit some or all SRLGs.
If an SRLG ID applies in both upstream and downstream directions, it SHOULD be added to both the upstream and downstream SRLG subobjects.
SRLG IDs SHOULD be unique in multi-layer, multi-domain scenarios where SRLG IDs may be configured by different management entities, in order to enable proper use of collected SRLG information.
The ingress node of the LSP MUST be capable of indicating whether SRLG information is to be collected during the signaling procedure of setting up an LSP.
The Reserved 15-bit field in the RRO SRLG Subobject SHOULD be set to zero on transmission and MUST be ignored on receipt.
The SRLG subobject MUST be pushed by the node before the node IP address or link identifier in the ROUTE_RECORD object, and MUST be pushed within the hop to which it applies.
When a node receives a Path message with LSP_ATTRIBUTES carrying the SRLG Collection Flag and local policy prohibits SRLG collection, the Path message MUST NOT be rejected; instead, it MUST be forwarded without any SRLG subobjects added to the RRO.
When SRLG information of a link changes, the procedures defined in Section 4.4.3 of RFC 3209 MUST be used to refresh the SRLG information for each affected LSP, if local node policy dictates that the change be communicated to other nodes.
A new SRLG Collection Flag is defined in the Attribute Flags TLV (RFC 5420). When set, it signals that SRLG information SHOULD be reported to the ingress and egress nodes along the LSP setup path. It is carried in either an LSP_REQUIRED_ATTRIBUTES object (mandatory collection) or an LSP_ATTRIBUTES object (desired but not mandatory).
The SRLG ID is a 32-bit quantity as defined in RFC 4202. Each 4-octet SRLG ID field in the RRO SRLG Subobject represents one SRLG membership, and multiple SRLG ID fields may appear in a single subobject.
IANA assigned Bit 12 in the 'Attribute Flags' subregistry of the RSVP-TE Parameters registry for the SRLG Collection Flag. It is valid for Attribute Flags Path and RRO contexts, but not for Attribute Flags Resv or ERO.
IANA assigned value 21 ('SRLG Recording Rejected') under 'Sub-Codes - 2 Policy Control Failure' in the RSVP Parameters registry, used when a node's policy prohibits SRLG collection on a mandatory-collection LSP.
IANA assigned value 34 under the 'Sub-object type - 21 ROUTE_RECORD - Type 1 Route Record' subregistry in the RSVP Parameters registry for the SRLG subobject.
The procedures permit transfer of SRLG data between layers or domains during LSP signaling. Local policy at layer or domain boundaries explicitly governs whether SRLG information is shared, summarized, mapped, or suppressed, limiting inadvertent topology disclosure.
The RRO SRLG Subobject contains an 8-bit Type field, an 8-bit Length field (total octets including Type and Length), a 1-bit Direction bit (D-bit), a 15-bit Reserved field, and one or more 4-octet SRLG ID fields. The D-bit distinguishes upstream (set) from downstream (unset) SRLGs.