Internet Engineering Task Force (IETF) K. Shiomoto, Ed. Request for Comments: 6107 NTT Updates: 3477, 4206 A. Farrel, Ed. Category: Standards Track Old Dog Consulting ISSN: 2070-1721 February 2011 Procedures for Dynamically Signaled Hierarchical Label Switched Paths Abstract Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) or Generalized MPLS (GMPLS) networks can be used to form links to carry traffic in those networks or in other (client) networks. Protocol mechanisms already exist to facilitate the establishment of such LSPs and to bundle traffic engineering (TE) links to reduce the load on routing protocols. This document defines extensions to those mechanisms to support identifying the use to which such LSPs are to be put and to enable the TE link endpoints to be assigned addresses or unnumbered identifiers during the signaling process. The mechanisms defined in this document deprecate the technique for the signaling of LSPs that are to be used as numbered TE links described in RFC 4206. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6107. Shiomoto & Farrel Standards Track [Page 1]
RFC 6107 Procedures for H-LSPs February 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction and Problem Statement ..............................3 1.1. Background .................................................4 1.1.1. Hierarchical LSPs ...................................4 1.1.2. LSP Stitching Segments ..............................5 1.1.3. Private Links .......................................5 1.1.4. Routing Adjacencies .................................5 1.1.5. Forwarding Adjacencies ..............................5 1.1.6. Client/Server Networks ..............................6 1.1.7. Link Bundles ........................................6 1.2. Desired Function ...........................................7 1.3. Existing Mechanisms ........................................7 1.3.1. LSP Setup ...........................................7 1.3.2. Routing Adjacency Establishment and Link State Advertisement .................................7 1.3.3. TE Link Advertisement ...............................7 1.3.4. Configuration and Management Techniques .............8 1.3.5. Signaled Unnumbered FAs .............................8 1.3.6. Establishing Numbered FAs through Signaling and Routing .........................................9 1.4. Overview of Required Extensions ...........................10 1.4.1. Efficient Signaling of Numbered FAs ................10 1.4.2. LSPs for Use as Private Links ......................10 1.4.3. Signaling an LSP for Use in Another Network ........10 1.4.4. Signaling an LSP for Use in a Link Bundle ..........11 1.4.5. Support for IPv4 and IPv6 ..........................11 1.4.6. Backward Compatibility .............................11 2. Overview of Solution ...........................................11 2.1. Common Approach for Numbered and Unnumbered Links .........11 2.2. LSP Usage Indication ......................................12 2.3. IGP Instance Identification ...............................12 2.4. Link Bundle Identification ................................12 Shiomoto & Farrel Standards Track [Page 2]
RFC 6107 Procedures for H-LSPs February 2011 2.5. Backward Compatibility ....................................12 3. Mechanisms and Protocol Extensions .............................13 3.1. LSP_TUNNEL_INTERFACE_ID Object ............................13 3.1.1. Existing Definition and Usage ......................13 3.1.2. Unnumbered Links with Action Identification ........13 3.1.3. IPv4 Numbered Links with Action Identification .....16 3.1.4. IPv6 Numbered Links with Action Identification .....17 3.2. Target IGP Identification TLV .............................18 3.3. Component Link Identification TLV .........................19 3.3.1. Unnumbered Component Link Identification ...........20 3.3.2. IPv4 Numbered Component Link Identification ........20 3.3.3. IPv6 Numbered Component Link Identification ........21 3.4. Link State Advertisement ..................................21 3.5. Message Formats ...........................................22 3.6. Error Cases and Non-Acceptance ............................22 3.7. Backward Compatibility ....................................24 4. Security Considerations ........................................25 5. IANA Considerations ............................................25 5.1. New Class Types ...........................................25 5.2. Hierarchy Actions .........................................26 5.3. New Error Codes and Error Values ..........................26 6. Acknowledgements ...............................................27 7. References .....................................................27 7.1. Normative References ......................................27 7.2. Informative References ....................................28 1. Introduction and Problem Statement Traffic Engineering (TE) links in a Multiprotocol Label Switching (MPLS) or a Generalized MPLS (GMPLS) network may be constructed from Label Switched Paths (LSPs) [RFC4206]. Such LSPs are known as hierarchical LSPs (H-LSPs). The LSPs established in one network may be used as TE links in another network, and this is particularly useful when a server layer network (for example, an optical network) provides LSPs for use as TE links in a client network (for example, a packet network). This enables the construction of a multilayer network (MLN) [RFC5212]. When the number of TE links (created from LSPs or otherwise) between a pair of nodes grows large, it is inefficient to advertise them individually. This may cause scaling issues in configuration and in the routing protocols used to carry the advertisements. The solution (described in [RFC4201]) is to collect the TE links together and to advertise them as a single TE link called a link bundle. Shiomoto & Farrel Standards Track [Page 3]
RFC 6107 Procedures for H-LSPs February 2011 These various mechanisms have proved to be very powerful in building dynamically provisioned networks, but, as set out later in this document, several issues have been identified during deployment with how LSPs are established and made available for use as H-LSPs or as components of a link bundle, and with how these links are advertised appropriately in an interior gateway protocol (IGP). These issues relate to how the LSP's endpoints coordinate two things: the use to which the LSP is put and the identifiers of the endpoints. This document provides solutions to these issues by defining mechanisms so that the ends of signaled LSPs can exchange information about: - Whether the LSP is an ordinary LSP or an H-LSP. - In which IGP instances the LSP should be advertised as a link. - How the client networks should make use of the new links. - Whether the link should form part of a bundle (and if so, which bundle). - How the link endpoints should be identified when advertised. This document deprecates one of the mechanisms defined in [RFC4206] for the signaling of LSPs that are to be used as numbered TE links (see Sections 1.3.6 and 1.4.6 for more details), and provides extensions to the other mechanisms defined in [RFC4206] so that the use to which the new LSP is to be put may be indicated during signaling. It also extends the mechanisms defined in [RFC3477] for signaling unnumbered TE links. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1.1. Background 1.1.1. Hierarchical LSPs [RFC3031] describes how MPLS labels may be stacked so that LSPs may be nested with one LSP running through another. This concept of H-LSPs is formalized in [RFC4206] with a set of protocol mechanisms for the establishment of an H-LSP that can carry one or more other LSPs. [RFC4206] goes on to explain that an H-LSP may carry other LSPs only according to their switching types. This is a function of the way labels are carried. In a packet switch capable (PSC) network, the H-LSP can carry other PSC LSPs using the MPLS label stack. In non- packet networks where the label is implicit, label stacks are not possible, and H-LSPs rely on the ability to nest switching Shiomoto & Farrel Standards Track [Page 4]
RFC 6107 Procedures for H-LSPs February 2011 technologies. Thus, for example, a lambda switch capable (LSC) LSP can carry a time-division multiplexing (TDM) LSP, but cannot carry another LSC LSP. Signaling mechanisms defined in [RFC4206] allow an H-LSP to be treated as a single hop in the path of another LSP (i.e., one hop of the LSP carried by the H-LSP). This mechanism is known as "non- adjacent signaling". 1.1.2. LSP Stitching Segments LSP stitching is defined in [RFC5150]. It enables LSPs of the same switching type to be included (stitched) as hops in an end-to-end LSP. The stitching LSP (S-LSP) is used in the control plane in the same way as an H-LSP, but in the data plane the LSPs are stitched so that there is no label stacking or nesting of technologies. Thus, an S-LSP must be of the same switching technology as the end-to-end LSP that it facilitates. 1.1.3. Private Links An H-LSP or S-LSP can be used as a private link. Such links are known by their endpoints, but are not more widely known and are not advertised by routing protocols. They can be used to carry traffic between the endpoints, but are not usually used to carry traffic that is going beyond the egress of the LSP. 1.1.4. Routing Adjacencies A routing adjacency is formed between two IGP speakers that are logically adjacent. In this sense, 'logically adjacent' means that the routers have a protocol tunnel between them through which they can exchange routing protocol messages. The tunnel is also usually available for carrying IP data although a distinction should be made in GMPLS networks between data-plane traffic and control-plane traffic. Routing adjacencies for forwarding data traffic are only relevant in PSC networks (i.e., IP/MPLS networks). 1.1.5. Forwarding Adjacencies A Forwarding Adjacency (FA) is defined in [RFC4206] as a data link created from an LSP and advertised in the same instance of the control plane that advertises the TE links from which the LSP is constructed. The LSP itself is called an FA-LSP. Shiomoto & Farrel Standards Track [Page 5]
RFC 6107 Procedures for H-LSPs February 2011 Thus, an H-LSP or S-LSP may form an FA such that it is advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that the LSP traverses. As observed in [RFC4206], the nodes at the ends of an FA would not usually have a routing adjacency. 1.1.6. Client/Server Networks An LSP may be created in one network and used as a link (sometimes called a virtual link) in another network [RFC5212]. In this case, the networks are often referred to as server and client networks, respectively. The server network LSP is used as an H-LSP or an S-LSP as described above, but it does not form an FA because the client and server networks run separate instances of the control-plane routing protocols. The virtual link may be used in the client network as a private link or may be advertised in the client network IGP. Additionally, the link may be used in the client network to form a routing adjacency and/or as a TE link. 1.1.7. Link Bundles [RFC4201] recognizes that a pair of adjacent routers may have a large number of TE links that run between them. This can be a considerable burden to the operator who may need to configure them and to the IGP that must distribute information about each of them. A TE link bundle is defined by [RFC4201] as a TE link that is advertised as an aggregate of multiple TE links that could have been advertised in their own right. All TE links that are collected into a TE link bundle have the same TE properties. Thus, a link bundle is a shorthand that improves the scaling properties of the network. Since a TE link may, itself, be an LSP (either an FA or a virtual link), a link bundle may be constructed from FA-LSPs or virtual links. Shiomoto & Farrel Standards Track [Page 6]
RFC 6107 Procedures for H-LSPs February 2011 1.2. Desired Function It should be possible to signal an LSP and automatically coordinate its use and advertisement in any of the ways described in Section 1.3 with minimum involvement from an operator. The mechanisms used should be applicable to numbered and unnumbered links and should not require implementation complexities. 1.3. Existing Mechanisms This section briefly introduces existing protocol mechanisms used to satisfy the desired function described in Section 1.2. 1.3.1. LSP Setup Both unidirectional LSPs and bidirectional LSPs are signaled from the ingress label switching router (LSR) to the egress LSR. That is, the ingress LSR is the initiator, and the egress learns about the LSP through the signaling protocol [RFC3209] [RFC3473]. 1.3.2. Routing Adjacency Establishment and Link State Advertisement Although hosts can discover routers (for example, through ICMP [RFC1256]), routing adjacencies are usually configured at both ends of the adjacency. This requires that each router know the identity of the router at the other end of the link connecting the routers, and know that the IGP is to be run on this link. Once a routing adjacency has been established, a pair of routers may use the IGP to share information about the links available for carrying IP traffic in the network. Suitable routing protocols are OSPF version 2 [RFC2328], OSPF version 3 [RFC5340], and IS-IS [RFC1195]. 1.3.3. TE Link Advertisement Extensions have been made to IGPs to advertise TE link properties ([RFC3630], [RFC5329], [RFC5305], [RFC5308], and [ISIS-IPV6-TE]) and also to advertise link properties in GMPLS networks ([RFC4202], [RFC4203], and [RFC5307]). TE link advertisement can be performed by the same instance of the IGP as is used for normal link state advertisement, or can use a separate instance. Furthermore, the ends of a TE link advertised in an IGP do not need to form a routing adjacency. This is particularly the case with FAs as described in Section 1.1.5. Shiomoto & Farrel Standards Track [Page 7]
RFC 6107 Procedures for H-LSPs February 2011 1.3.4. Configuration and Management Techniques LSPs are usually created as the result of a management action. This is true even when a control plane is used: the management action is a request to the control plane to signal the LSP. If the LSP is to be used as an H-LSP or S-LSP, management commands can be used to install the LSP as a link. The link must be defined, interface identifiers allocated, and the endpoints configured to know about (and advertise, if necessary) the new link. If the LSP is to be used as part of a link bundle, the operator must decide which bundle it forms part of and ensure that information is configured at the ingress and egress, along with the necessary interface identifiers. These mechanisms are perfectly functional and quite common in MLNs, but require configuration coordination and additional management. They are open to user error and misconfiguration that might result in the LSP not being used (a waste of resources) or the LSP being made available in the wrong way with some impact on traffic engineering. 1.3.5. Signaled Unnumbered FAs [RFC3477] describes how to establish an LSP and to make it available automatically as a TE link in the same instance of the routing protocol as advertises the TE links it traverses, using IPv4-based unnumbered identifiers to identify the new TE link. That is, [RFC3477] describes how to create an unnumbered FA. The mechanism, as defined in Section 3 of [RFC3477], is briefly as follows: - The ingress of the LSP signals the LSP as normal using a Path message, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The sender's LSR Router ID - The sender's interface ID for the TE link being created - The egress of the LSP responds as normal to accept the LSP and set it up, and includes an LSP_TUNNEL_INTERFACE_ID object. The LSP_TUNNEL_INTERFACE_ID object identifies: - The egress's LSR Router ID - The egress's interface ID for the TE link being created. Shiomoto & Farrel Standards Track [Page 8]
RFC 6107 Procedures for H-LSPs February 2011 - Following the exchange of the Path and Resv messages, both the ingress and the egress know that the LSP is to be advertised as a TE link in the same instance of the routing protocol as was used to advertise the TE links that it traverses, and also know the unnumbered interface identifiers to use in the advertisement. [RFC3477] does not include mechanisms to support IPv6-based unnumbered identifiers, nor IPv4 or IPv6 numbered identifiers. 1.3.6. Establishing Numbered FAs through Signaling and Routing [RFC4206] describes procedures to establish an LSP and to make it available automatically as a TE link that is identified using IPv4 addresses in the same instance of the routing protocol as advertises the TE links it traverses (that is, as a numbered FA). The mechanism, as defined in [RFC4206], is briefly as follows: - The ingress of the LSP signals the LSP as normal using a Path message, and sets the IPv4 tunnel sender address to the IP address it will use to identify its interface for the TE link being created. This is one address from a /31 pair. - The egress of the LSP responds as normal to accept the LSP and set it up. It infers the address that it must assign to identify its interface for the TE link being created as the partner address of the /31 pair. - The ingress decides whether the LSP is to be advertised as a TE link (i.e., as an FA). If so, it advertises the link in the IGP in the usual way. - If the link is unidirectional, nothing more needs to be done. If the link is bidirectional, the egress must also advertise the link, but it does not know that advertisement is required as there is no indication in the signaling messages. - When the ingress's advertisement of the link is received by the egress, it must check to see whether it is the egress of the LSP that formed the link. Typically, this means the egress: - Checks to see if the link advertisement is new. - Checks to see if the Link-ID address in the received advertisement matches its own TE Router ID. - Checks the advertising router ID from the advertisement against the ingress address of each LSP for which it is the egress. - Deduces the LSP that has been advertised as a TE link and issues the corresponding advertisement for the reverse direction. Shiomoto & Farrel Standards Track [Page 9]
RFC 6107 Procedures for H-LSPs February 2011 It is possible that some reduction in processing can be achieved by mapping based on the /31 pairing, but nevertheless, there is a fair amount of processing required, and this does not scale well in large networks. Note that this document deprecates this procedure as explained in Section 1.4.6. No explanation is provided in [RFC4206] of how to create numbered IPv6 FAs. 1.4. Overview of Required Extensions This section provides a brief outline of the required protocol extensions. 1.4.1. Efficient Signaling of Numbered FAs The mechanism described in Section 1.3.6 is inefficient. The egress must wait until it receives an advertisement from the ingress before it knows that the LSP is to be installed as a TE link and advertised as an FA. Further, it must parse all received advertisements to determine if any is the trigger for it to advertise an FA. An efficient signaling mechanism is required so that the egress is informed by the ingress during LSP establishment. 1.4.2. LSPs for Use as Private Links There is currently no mechanism by which an ingress can indicate that an LSP is set up for use as a private link. Any attempt to make it a link would currently cause it to be advertised as an FA. A signaling mechanism is needed to identify the use to which an LSP is to be put.