rfc-4561

Definition of a Record Route Object (RRO) Node-Id Sub-Object

J.-P. Vasseur (Editor), Z. Ali, S. Sivabalan

date2006-06 streamIETF areartg wgmpls statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc4561 doi10.17487/RFC4561 errataview

In the context of MPLS TE Fast Reroute, the Merge Point (MP) address is required at the Point of Local Repair (PLR) in order to select a backup tunnel intersecting a fast reroutable Traffic Engineering Label Switched Path (TE LSP) on a downstream Label Switching Router (LSR). However, existing protocol mechanisms are not sufficient to find an MP address in multi-domain routing networks where a domain is defined as an Interior Gateway Protocol (IGP) area or an Autonomous System (AS). Hence, the current MPLS Fast Reroute mechanism cannot be used in order to protect inter-domain TE LSPs from a failure of an Area Border Router (ABR) or Autonomous System Border Router (ASBR). This document specifies the use of existing Record Route Object (RRO) IPv4 and IPv6 sub-objects (with a new flag defined) thus defining the node-id sub-object in order to solve this issue. The MPLS Fast Reroute mechanism mentioned in this document refers to the "Facility backup" MPLS TE Fast Reroute method. [STANDARDS-TRACK]

Extracted elements (13)

design-rationale §1

In multi-domain routing networks (inter-area or inter-AS), existing RRO mechanisms cannot unambiguously identify the Merge Point (MP) address because interface addresses in RRO sub-objects differ across domains and the PLR lacks cross-domain IGP topology knowledge. This gap prevents MPLS Fast Reroute from protecting inter-domain TE LSPs against ABR/ASBR failures.

mpls, routing

design-rationale §3

The solution reuses the existing RRO IPv4 and IPv6 sub-object formats from RFC 3209 rather than defining new sub-object types, adding only a new flag bit (0x20). This minimizes protocol changes while solving the inter-domain MP identification problem.

mpls, routing

interoperability-note §4

In the inter-AS case, the technique assumes the MP's node-id from the downstream AS does not overlap with any LSR node-id in the PLR's AS. This non-overlap assumption is required for correct MP identification across AS boundaries.

mpls, routing

interoperability-note §3

Two implementation options are permitted for combining node-id and interface address recording in the RRO: (1) add the node-id sub-object plus an optional separate IPv4/IPv6 interface-address sub-object, or (2) add an IPv4/IPv6 interface-address sub-object plus an optional node-id sub-object. Both orderings are valid.

mpls, routing

interoperability-note §4

When both IPv4 node-id and IPv6 node-id sub-objects are present in an RRO, a PLR may use either or both of them when finding the MP address.

mpls, routing

normative-requirement §3 MUST

A node MUST use the same node-id address consistently in RRO IPv4 or IPv6 sub-objects.

mpls, routing

normative-requirement §4 MUST

If the backup tunnel terminates at an address different from the MP's node-id (Case 2), a node-id sub-object MUST also be included in the RRO of the backup tunnel so the PLR can compare node-ids across primary and backup tunnel RROs to find the MP.

mpls, routing

normative-requirement §3 RECOMMENDED

It is RECOMMENDED that an LSR recording a node-id address in an IPv4/IPv6 RRO sub-object also set the node-id flag (0x20).

mpls, routing

normative-requirement §3 SHOULD

Once an address is used in the RRO's IPv4 or IPv6 sub-object, it SHOULD always be used for the lifetime of the TE LSP.

mpls, routing

protocol-element §3

A new flag value 0x20 (Node-id) is defined for use in existing RRO IPv4 and IPv6 sub-objects. When set, it indicates the address in the sub-object is a node-id — specifically the 'Router Address' per OSPF-TE or 'Traffic Engineering Router ID' per ISIS-TE — rather than an interface address.

mpls, routing

protocol-element §3

The node-id sub-object is an existing RRO IPv4 or IPv6 sub-object (as defined in RFC 3209) with the new 0x20 (Node-id) flag set, inserted in the RRO carried in RSVP Resv messages to convey the node-id of each LSR along the TE LSP path.

mpls, routing

security-consideration §5

This document does not introduce new security issues. The security considerations pertaining to RSVP (RFC 2205) and RSVP-TE (RFC 3209) remain relevant and apply to this extension.

security, mpls

state-machine §4

MP selection at the PLR has two cases: Case 1 — if the backup tunnel destination equals the MP's node-id, the PLR compares the backup tunnel destination directly against node-ids in the primary tunnel's RRO; Case 2 — if the backup tunnel destination differs from the MP's node-id, the PLR compares node-id sub-objects present in both primary and backup tunnel RROs.

mpls, routing