ietf-corpus

rfc-4206

Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)

K. Kompella, Y. Rekhter
date2005-10 streamIETF areartg wgmpls statusPROPOSED STANDARD pages14 canonicalhttps://www.rfc-editor.org/rfc/rfc4206 doi10.17487/RFC4206
To improve scalability of Generalized Multi-Protocol Label Switching (GMPLS) it may be useful to aggregate Label Switched Paths (LSPs) by creating a hierarchy of such LSPs. A way to create such a hierarchy is by (a) a Label Switching Router (LSR) creating a Traffic Engineering Label Switched Path (TE LSP), (b) the LSR forming a forwarding adjacency (FA) out of that LSP (by advertising this LSP as a Traffic Engineering (TE) link into the same instance of ISIS/OSPF as the one that was used to create the LSP), (c) allowing other LSRs to use FAs for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (by using the label stack construct). This document describes the mechanisms to accomplish this. [PROPOSED STANDARD]

updated by

Extracted elements (24)

design-rationale §1

FAs are introduced to improve GMPLS scalability by aggregating LSPs into a hierarchy. Other LSRs can use FAs for path computation and nest their LSPs into the FA-LSP using the label stack construct, reducing the number of LSPs visible at the top level.

mpls, routing

design-rationale §5.1

LSP regions and their boundaries are determined using Interface Switching Capability ordering to control FA-LSP boundaries. When an LSP crosses a region boundary at a node, that node becomes an edge LSR responsible for establishing an FA-LSP across the region.

mpls, routing

interoperability-note §4

FAs are not expected to be used for establishing ISIS/OSPF peering between routers at the ends of the adjacency. To restrict FAs to TE path computations only, IS-IS can set the default metric to maximum (2^24 - 1) or OSPF can advertise only a TE opaque LSA without a regular LSA.

mpls, routing

normative-requirement §6.1.1 SHOULD

A PathErr sent in response to a Path message with an IF_ID RSVP_HOP object SHOULD contain an IF_ID HOP object to identify the data channel in the case of separated control and data planes.

mpls, routing

normative-requirement §6.1.2 MUST

For CR-LDP signaling of an LSP tunneled over an FA-LSP, the Request message MUST contain an IF_ID TLV object and the data interface identification MUST identify the FA-LSP. The head-end LSR must create a targeted LDP session with the tail-end LSR.

mpls, routing

normative-requirement §6.1.1 MUST

For RSVP-TE signaling of an LSP tunneled over an FA-LSP, the Path message MUST contain an IF_ID RSVP_HOP object instead of an RSVP_HOP object, and the data interface identification MUST identify the FA-LSP.

mpls, routing

normative-requirement §3.1.10 MUST

If FAs are bundled via link bundling and the bundled link carries an SRLG TLV, the list of SRLGs in the underlying path followed by each FA-LSP forming component links MUST be the same (though exact paths need not be identical).

mpls, routing

normative-requirement §6.3 MUST

The holding priority of an FA-LSP must be the minimum of its configured holding priority and the holding priorities of all LSPs tunneling through it, promoting the FA-LSP to higher priority when a higher-priority LSP traverses it. If configured, the holding priority of an FA-LSP is restricted to 0.

mpls, routing

normative-requirement §6.1.1 MUST NOT

The IP header for Path messages tunneled over an FA-LSP MUST NOT have the Router Alert option, so the message is IP-routed to the tail-end of the FA-LSP without being intercepted by intermediate nodes as an RSVP message.

mpls, routing

normative-requirement §6.1.1 MUST NOT

When using IF_ID RSVP_HOP, the IP TTL vs. RSVP TTL check MUST NOT be made, as the number of control plane hops may exceed one. Instead, the receiver must verify that the identified data interface terminates on itself and that the PHOP address belongs to the same node as the other end of that interface.

mpls, routing

protocol-element §1

A Forwarding Adjacency (FA) is a TE link formed by advertising an FA-LSP into the same ISIS/OSPF instance that created the LSP. The FA is applicable only when an LSP is both created and used as a TE link by exactly the same instance of the GMPLS control plane.

mpls, routing

protocol-element §6.2

An FA-LSP is torn down by the head-end LSR when there are no more LSPs carried by it. Upon teardown, the associated FA is withdrawn from IS-IS/OSPF advertisement.

mpls, routing

protocol-element §3.1.6

By default, the Maximum Reservable Bandwidth and initial Maximum LSP Bandwidth for all priorities of an FA is set to the bandwidth of the FA-LSP. The Maximum LSP Bandwidth at any priority MUST NOT exceed the bandwidth of the FA-LSP.

mpls, routing

protocol-element §3

FAs may be represented as either unnumbered or numbered links. If numbered with IPv4 addresses, the local and remote addresses come from a /31 allocated by the LSR originating the FA-LSP; the head-end address is the IPv4 tunnel sender address.

mpls, routing, ip

protocol-element §5.1

LSP regions are defined using an ordering of Interface Switching Capabilities: PSC-1 < PSC-2 < PSC-3 < PSC-4 < TDM < LSC < FSC. A region boundary exists at node-i when the interface switching capability increases across that node along the LSP path.

mpls, routing

protocol-element §3.1.10

SRLG information for an FA advertisement is the union of SRLGs of the underlying TE links making up the FA-LSP path, carried in the SRLG TLV in IS-IS or the SRLG sub-TLV of the TE Link TLV in OSPF. This information may change over time as the underlying path changes.

mpls, routing

protocol-element §3.1.9

The Interface Switching Capability of an FA is set to the near-end Interface Switching Capability of the first link in the FA-LSP. For PSC-type capabilities, the Interface MTU is the minimum MTU along the FA-LSP path and the Minimum LSP Bandwidth is the bandwidth of the FA-LSP.

mpls, routing

protocol-element §3.1.1

The Link Type of an FA in OSPF is set to 'point-to-point', and the Link ID is set to the Router ID of the tail-end of the FA-LSP.

mpls, routing

protocol-element §3.1.5

The TE metric of an FA defaults to max(1, (TE metric of the FA-LSP path) - 1), so the FA attracts traffic in preference to setting up a new LSP. This may be overridden by configuration at the head-end.

mpls, routing

protocol-element §6.2

When an LSR at a region edge receives a Path/Request message, it checks existing FA-LSPs for a match along the ERO subsequence spanning the region. If a matching FA-LSP with sufficient bandwidth and compatible L3PID is found, the LSP is tunneled through it; otherwise a new FA-LSP is established.

mpls, routing

protocol-element §6.2

When tunneling an LSP through an existing FA-LSP, the ERO is adjusted by removing the subsequence of hops within the FA-LSP and replacing it with just the endpoint of the FA-LSP. The PHOP in the message is set to the head-end of the FA-LSP.

mpls, routing

security-consideration §7

Because Path message IP destination addresses are set to the receiver's address rather than the session destination, IPSec AH may now be a viable means of securing RSVP-TE messages, overcoming objections raised in RFC 2747 Section 1.2.

mpls, security

security-consideration §7

CR-LDP avoids the control/data plane separation security issue because CR-LDP messages are sent over TCP sessions with no assumption of direct neighbor adjacency; TCP MD5 (per RFC 3036) is the recommended authentication mechanism for LDP message integrity.

mpls, security

security-consideration §7

The separation of control and data planes in FA-LSPs breaks the implicit binding between data interfaces and the interface over which a control message is sent. Mechanisms depending on 'sending interface' or 'receiving interface' concepts (e.g., RSVP security associations per RFC 2747) must be redefined in terms of sender's/receiver's IP addresses rather than interfaces.

mpls, security