From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6107.txt | 1683 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1683 insertions(+) create mode 100644 doc/rfc/rfc6107.txt (limited to 'doc/rfc/rfc6107.txt') diff --git a/doc/rfc/rfc6107.txt b/doc/rfc/rfc6107.txt new file mode 100644 index 0000000..6d67616 --- /dev/null +++ b/doc/rfc/rfc6107.txt @@ -0,0 +1,1683 @@ + + + + + + +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. + +1.4.3. Signaling an LSP for Use in Another Network + + The existing signaling/routing mechanisms are designed for use in the + creation of FAs. That is, the TE link created is advertised in the + single IGP instance. + + The numbered TE link mechanism (Section 1.3.6) could, in theory, be + used in an MLN with multiple IGP instances if the addressing model is + kept consistent across the networks, and if the egress searches all + advertisements in all IGP instances. However, this is complex and + does not work for unnumbered interfaces. + + + + +Shiomoto & Farrel Standards Track [Page 10] + +RFC 6107 Procedures for H-LSPs February 2011 + + + A signaling mechanism is required to indicate in which IGP instance + the TE link should be advertised. + +1.4.4. Signaling an LSP for Use in a Link Bundle + + A signaling mechanism is required to indicate that an LSP is intended + to form a component link of a link bundle, and to identify the bundle + and the IGP instance in which the bundle is advertised. + +1.4.5. Support for IPv4 and IPv6 + + The protocol mechanisms must support IPv4 and IPv6 numbered and + unnumbered TE links. + +1.4.6. Backward Compatibility + + The existing protocol mechanisms for unnumbered FAs as defined in + [RFC4206] and [RFC3477] must continue to be supported, and new + mechanisms must be devised such that their introduction will not + break existing implementations or deployments. + + Note that an informal survey in the CCAMP working group established + that there are no significant deployments of numbered FAs established + using the technique described in [RFC4206] and set out in Section + 1.3.6. Therefore, this document deprecates this procedure. + +2. Overview of Solution + + This section provides an overview of the mechanisms and protocol + extensions defined in this document. Details are presented in + Section 3. + +2.1. Common Approach for Numbered and Unnumbered Links + + The LSP_TUNNEL_INTERFACE_ID object [RFC3477] is extended for use for + all H-LSPs and S-LSPs whether they form numbered or unnumbered IPv4 + or IPv6 links. Different Class Types of the object identify the + address type for which it applies. + + + + + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 11] + +RFC 6107 Procedures for H-LSPs February 2011 + + +2.2. LSP Usage Indication + + The LSP_TUNNEL_INTERFACE_ID object is given flags in a new Actions + field to say how the LSP is to be used. The following categories are + supported: + + - The LSP is used as an advertised TE link. + - The LSP is used to form a routing adjacency. + - The LSP is used to form an advertised TE link and a routing + adjacency. + - The LSP forms a private link and is not advertised. + - The LSP is used as part of a link bundle. + - The LSP is used as a hierarchical LSP or a stitching segment. + +2.3. IGP Instance Identification + + An optional TLV is added to the LSP_TUNNEL_INTERFACE_ID object to + identify the IGP instance into which the link formed by the LSP is to + be advertised. If the TLV is absent and the link is to be advertised + as indicated by the Actions field, the link is advertised in the same + instance of the IGP as was used to advertise the TE links it + traverses. + +2.4. Link Bundle Identification + + When an LSP is to be used as a component link of a link bundle, the + LSP_TUNNEL_INTERFACE_ID object refers to the bundle indicating how + the bundle is addressed and used, and a new TLV indicates the + component link identifier for the link that the LSP creates. + +2.5. Backward Compatibility + + Backward compatibility has three aspects. + + - Existing mechanisms for unnumbered FAs described in [RFC3477] and + [RFC4206] must continue to work, so that ingress nodes do not have + to be updated when egresses are updated. + + - Existing mechanisms for establishing numbered FAs described in + [RFC4206] are safely deprecated by this document, as they are not + significantly deployed. + + - New mechanisms must be gracefully rejected by existing egress + implementations so that egress nodes do not have to be updated when + ingresses are updated. + + + + + + +Shiomoto & Farrel Standards Track [Page 12] + +RFC 6107 Procedures for H-LSPs February 2011 + + +3. Mechanisms and Protocol Extensions + + This section defines protocol mechanisms and extensions to achieve + the function described in the previous section. + +3.1. LSP_TUNNEL_INTERFACE_ID Object + + The principal signaling protocol element used to achieve all of the + required functions is the LSP_TUNNEL_INTERFACE_ID object defined in + [RFC3477]. The existing definition and usage continues to be + supported as described in the next section. Subsequent sections + describe new variants of the object (denoted by new Class Types), and + additional information carried in the object by means of extensions. + +3.1.1. Existing Definition and Usage + + This document does not deprecate the mechanisms defined in [RFC3477] + and [RFC4206]. Those procedures must continue to operate as + described in Section 3.7. + + That means that the LSP_TUNNEL_INTERFACE_ID object with Class Type 1 + remains unchanged, and can be used to establish an LSP that will be + advertised as an unnumbered TE link in the same instance of the IGP + as was used to advertise the TE links that the LSP traverses (that + is, as an FA). The procedure is unchanged and operates as summarized + in Section 1.3.5. + + [RFC3477] does not make any suggestions about where in Path or Resv + messages the LSP_TUNNEL_INTERFACE_ID object should be placed. See + Section 3.5 for recommended placement of this object in new + implementations. + +3.1.2. Unnumbered Links with Action Identification + + A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined + to carry an unnumbered interface identifier and to indicate into + which instance of the IGP the consequent TE link should be + advertised. This does not deprecate the use of C-Type 1. + + The format of the object is as shown below. + + C-NUM = 193, C-Type = 4 + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 13] + +RFC 6107 Procedures for H-LSPs February 2011 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | LSR's Router ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Interface ID (32 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Actions | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ TLVs ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + LSR's Router ID + + Unchanged from the definition in [RFC3477]. + + Interface ID + + Unchanged from the definition in [RFC3477]. + + Actions + + This field specifies how the LSP that is being set up is to be + treated. + + The field has meaning only on a Path message. On a Resv + message, the field SHOULD be set to reflect the value received + on the corresponding Path message, and it MUST be ignored on + receipt. + + The field is composed of bit flags as follows: + + -+-+-+-+-+-+-+- + | | | |H|B|R|T|P| + -+-+-+-+-+-+-+- + + P-flag (Private) + 0 means that the LSP is to be advertised as a link according + to the settings of the other flags. + 1 means the LSP is to form a private link and is not to be + advertised in the IGP, but is to be used according to the + settings of the other flags. + + T-flag (TE link) + 0 means that the LSP is to be used as a TE link. + 1 means that the LSP is not to be used as a TE link. It may + still be used as an IP link providing a routing adjacency + as defined by the R-flag. + + + +Shiomoto & Farrel Standards Track [Page 14] + +RFC 6107 Procedures for H-LSPs February 2011 + + + R-flag (Routing adjacency) + 0 means that the link is not to be used as a routing + adjacency. + 1 means that the link is to be used to form a routing + adjacency. + + B-flag (Bundle) + 0 means that the LSP will not form part of a link bundle. + 1 means that the LSP will form part of a bundle. See Section + 3.3 for more details. + + H-flag (Hierarchy/stitching) + The use of an LSP as an H-LSP or as an S-LSP is usually + implicit from the network technologies of the networks and + the LSP, but this is not always the case (for example, in PSC + networks). + 0 means that the LSP is to be used as a hierarchical LSP. + 1 means that the LSP is to be used as a stitching segment. + + Other bits are reserved for future use. They MUST be set to + zero on transmission and SHOULD be ignored on receipt. + + Note that all defined bit flags have meaning at the same time. + An LSP that is to form an FA would carry the Actions field set + to 0x00. That is: + P=0 (advertised) + T=0 (TE link) + R=0 (not a routing adjacency) + B=0 (not a bundle) + H=0 (hierarchical LSP) + + Reserved + + The Reserved bits MUST be set to zero on transmission and + SHOULD be ignored on receipt. + + TLVs + + Zero, one, or more TLVs may be present. Each TLV is encoded as + follows: + + + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 15] + +RFC 6107 Procedures for H-LSPs February 2011 + + + Type (16 bits) + + The identifier of the TLV. Two type values are defined in + this document: + + 1 IGP Instance Identifier TLV + 2 Unnumbered Component Link Identifier TLV + 3 IPv4 Numbered Component Link Identifier TLV + 4 IPv6 Numbered Component Link Identifier TLV + + Length (16 bits) + + Indicates the total length of the TLV in octets, i.e., 4 + + the length of the value field in octets. A value field + whose length is not a multiple of four MUST be zero-padded + so that the TLV is four-octet aligned. + + Value + + The data for the TLV padded as described above. + + If this object is carried in a Path message, it is known as the + "Forward Interface ID" for the LSP that is being set up. On a Resv + message, the object is known as the "Reverse Interface ID" for the + LSP. + +3.1.3. IPv4 Numbered Links with Action Identification + + A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined + to carry an IPv4 numbered interface address. + + The format of the object is as shown below. + + C-NUM = 193, C-Type = 2 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Interface Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Actions | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ TLVs ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Shiomoto & Farrel Standards Track [Page 16] + +RFC 6107 Procedures for H-LSPs February 2011 + + + IPv4 Interface Address + + The address assigned to the interface that the sender applies + to this LSP. + + Actions + + See Section 3.1.2. + + Reserved + + See Section 3.1.2. + + TLVs + + See Section 3.1.2. + + If this object is carried in a Path message, it is known as the + "Forward Interface ID" for the LSP that is being set up. On a Resv + message, the object is known as the "Reverse Interface ID" for the + LSP. + +3.1.4. IPv6 Numbered Links with Action Identification + + A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID object is defined + to carry an IPv6 numbered interface address. + + The format of the object is as shown below. + + C-NUM = 193, C-Type = 3 + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Interface Address (128 bits) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Interface Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Interface Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Interface Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Actions | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ TLVs ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Shiomoto & Farrel Standards Track [Page 17] + +RFC 6107 Procedures for H-LSPs February 2011 + + + IPv6 Interface Address + + The address assigned to the interface the sender applies to + this LSP. + + Actions + + See Section 3.1.2. + + Reserved + + See Section 3.1.2. + + TLVs + + See Section 3.1.2. + + If this object is carried in a Path message, it is known as the + "Forward Interface ID" for the LSP that is being set up. On a Resv + message, the object is known as the "Reverse Interface ID" for the + LSP. + +3.2. Target IGP Identification TLV + + If the LSP being set up is to be advertised as a link, the egress + needs to know which instance of the IGP it should use to make the + advertisement. The default in [RFC4206] and [RFC3477] is that the + LSP is advertised as an FA, that is, in the same instance of the IGP + as was used to advertise the TE links that the LSP traverses. + + In order to facilitate an indication from the ingress to the egress + of which IGP instance to use, the IGP Identification TLV is defined + for inclusion in the new variants of the LSP_TUNNEL_INTERFACE_ID + object defined in this document. + + The TLV has meaning only in a Path message. It SHOULD NOT be + included in the LSP_TUNNEL_INTERFACE_ID object in a Resv message and + MUST be ignored if found. + + If the P-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID + object in a Path message is clear (i.e., zero), this TLV indicates + the IGP instance to use for the advertisement. If the TLV is absent, + the same instance of the IGP should be used as is used to advertise + the TE links that the LSP traverses. Thus, for an FA, the TLV can be + omitted; alternatively, the IGP Instance TLV may be present and + identify the IGP instance or carry the reserved value 0xffffffff. + + + + + +Shiomoto & Farrel Standards Track [Page 18] + +RFC 6107 Procedures for H-LSPs February 2011 + + + If the P-flag in the Actions field in the LSP_TUNNEL_INTERFACE_ID + object in a Resv message is set (i.e., one) indicating that the LSP + is not to be advertised as a link, this TLV SHOULD NOT be present and + MUST be ignored if encountered. + + The TLV is formatted as described in Section 3.1.2. The Type field + has the value 1, and the Value field has the following content: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IGP Instance Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IGP Instance Identifier + + A 32-bit identifier assigned to each of the IGP instances within a + network, such that ingress and egress LSRs have the same + understanding of these numbers. This is a management + configuration exercise outside the scope of this document. + + Note that the IGP Instance Identifier might be mapped from an + instance identifier used in the IGP itself (such as section 2.4 of + [RFC5340] for OSPFv3, or [OSPFv2-MI] for OSPFv2) as a matter of + network policy. See [OSPF-TI] for further discussion of this + topic in OSPF, and [ISIS-GENAP] for IS-IS. + + The value 0xffffffff is reserved to mean that the LSP is to be + advertised in the same instance of the IGP as was used to + advertise the TE links that the LSP traverses. + +3.3. Component Link Identification TLV + + If the LSP that is being set up is to be used as a component link in + a link bundle [RFC4201], it is necessary to indicate both the + identity of the component link and the identity of the link bundle. + Furthermore, it is necessary to indicate how the link bundle (that + may be automatically created by the establishment of this LSP) is to + be used and advertised. + + If the B-flag in the Actions field of the LSP_TUNNEL_INTERFACE_ID + object is set, the other fields of the object apply to the link + bundle itself. That is, the interface identifiers (numbered or + unnumbered) and the other flags in the Actions field apply to the + link bundle and not to the component link that the LSP will form. + + Furthermore, the IGP Instance Identifier TLV (if present) also + applies to the link bundle and not to the component link. + + + +Shiomoto & Farrel Standards Track [Page 19] + +RFC 6107 Procedures for H-LSPs February 2011 + + + In order to exchange the identity of the component link, the + Component Link Identifier TLVs are introduced as set out in the next + sections. If the B-flag is set in the Actions field of the + LSP_TUNNEL_INTERFACE_ID object in the Path message, exactly one of + these TLVs MUST be present in the LSP_TUNNEL_INTERFACE_ID object in + both the Path and Resv objects. + +3.3.1. Unnumbered Component Link Identification + + If the component link is to be unnumbered, the Unnumbered Component + Link Identifier TLV is used. The TLV is formatted as described in + Section 3.1.2. The Type field has the value 2, and the Value field + has the following content: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Component Link Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Component Link Identifier + + Unnumbered identifier that is assigned to this component link + within the bundle [RFC4201]. + +3.3.2. IPv4 Numbered Component Link Identification + + If the component link is identified with an IPv4 address, the IPv4 + Numbered Component Link Identifier TLV is used. The TLV is formatted + as described in Section 3.1.2. The Type field has the value 3, and + the Value field has the following content: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv4 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IPv4 Address + + The IPv4 address that is assigned to this component link within + the bundle. + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 20] + +RFC 6107 Procedures for H-LSPs February 2011 + + +3.3.3. IPv6 Numbered Component Link Identification + + If the component link is identified with an IPv6 address, the IPv6 + Numbered Component Link Identifier TLV is used. The TLV is formatted + as described in Section 3.1.2. The Type field has the value 4, and + the Value field has the following content: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IPv6 Address (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IPv6 Address + + The IPv6 address that is assigned to this component link within + the bundle. + +3.4. Link State Advertisement + + The ingress and egress of an LSP that is set up using the + LSP_TUNNEL_INTERFACE_ID object MUST advertise the LSP as agreed in + the parameters of the object. + + Where a TE link is created from the LSP, the TE link SHOULD inherit + the TE properties of the LSP as described in [RFC5212], but this + process is subject to local and network-wide policy. + + It is possible that an LSP will be used to offer capacity and + connectivity to multiple other networks. In this case, multiple + instances of the LSP_TUNNEL_INTERFACE_ID object are permitted in the + same Path and Resv messages. Each instance MUST have a different IGP + Instance Identifier. + + Note, however, that a Path or Resv message MUST NOT contain more than + one instance of the LSP_TUNNEL_INTERFACE_ID object with C-Type 1, and + if such an object is present, all other instances of the + LSP_TUNNEL_INTERFACE_ID object MUST include an IGP Instance + Identifier TLV with IGP Instance Identifier set to a value that + identifies some other IGP instance (in particular, not the value + 0xffffffff). + + + + +Shiomoto & Farrel Standards Track [Page 21] + +RFC 6107 Procedures for H-LSPs February 2011 + + + If the link created from an LSP is advertised in the same IGP + instance as was used to advertise the TE links that the LSP + traverses, the addresses for the new link and for the links from + which it is built MUST come from the same address space. + + If the link is advertised into another IGP instance, the addresses + MAY be drawn from overlapping address spaces such that some addresses + have different meanings in each IGP instance. + + In the IGP, the TE Router ID of the ingress LSR is taken from the + Tunnel Sender Address in the Sender Template object signaled in the + Path message. It is assumed that the ingress LSR knows the TE Router + ID of the egress LSR since it has chosen to establish an LSP to that + LSR and plans to use the LSP as a TE link. + + The link interface addresses or link interface identifiers for the + forward and reverse direction links are taken from the + LSP_TUNNEL_INTERFACE_ID object on the Path and Resv messages, + respectively. + + When an LSP is torn down through explicit action (a PathTear message + or a PathErr message with the Path_State_Removed flag set), the + ingress and egress LSRs SHOULD withdraw the advertisement of any link + that the LSP created and that was previously advertised. The link + state advertisement MAY be retained as a virtual link in another + layer network according to network-wide policy [PCE-LAYER]. + +3.5. Message Formats + + [RFC3477] does not state where in the Path message or Resv message + the LSP_TUNNEL_INTERFACE_ID object should be placed. + + It is RECOMMENDED that new implementations place the + LSP_TUNNEL_INTERFACE_ID objects in the Path message immediately after + the SENDER_TSPEC object, and in the Resv message immediately after + the FILTER_SPEC object. + + All implementations SHOULD be able to handle received messages with + objects in any order, as described in [RFC3209]. + +3.6. Error Cases and Non-Acceptance + + Error cases and non-acceptance of new object variants caused by back- + level implementations are discussed in Section 3.7. + + An egress LSR that receives an LSP_TUNNEL_INTERFACE_ID object may + have cause to reject the parameters carried in the object for a + number of reasons as set out below. In all cases, the egress SHOULD + + + +Shiomoto & Farrel Standards Track [Page 22] + +RFC 6107 Procedures for H-LSPs February 2011 + + + respond with a PathErr message with the error code as indicated in + the list below. In most cases, the error will arise during LSP + setup, no Resv state will exist, and the PathErr will cause Path + state to be removed. Where the error arises after the LSP has been + successfully set up, the PathErr SHOULD be sent with the + Path_State_Removed flag [RFC3473] clear so that the LSP remains + operational. + + The error cases identified are as follows and are reported using the + new error code 'LSP Hierarchy Issue' (code 38) and the error values + listed below. + + Error | Error | Error-case + code | value | + ------+-------+------------------------------------------------------ + 38 1 Link advertisement not supported + 38 2 Link advertisement not allowed by policy + 38 3 TE link creation not supported + 38 4 TE link creation not allowed by policy + 38 5 Routing adjacency creation not supported + 38 6 Routing adjacency creation not allowed by policy + 38 7 Bundle creation not supported + 38 8 Bundle creation not allowed by policy + 38 9 Hierarchical LSP not supported + 38 10 LSP stitching not supported + 38 11 Link address type or family not supported + 38 12 IGP instance unknown + 38 13 IGP instance advertisement not allowed by policy + 38 14 Component link identifier not valid + 38 15 Unsupported component link identifier address family + + When an ingress LSR receives an LSP_TUNNEL_INTERFACE_ID object on a + Resv message, it may need to reject it because of the setting of + certain parameters in the object. Since these reasons all represent + errors rather than mismatches of negotiable parameters, the ingress + SHOULD respond with a PathTear to remove the LSP. The ingress MAY + use a ResvErr with one of the following error codes, allowing the + egress the option to correct the error in a new Resv message, or to + tear down the LSP with a PathErr with the Path_State_Removed flag + set. An ingress that uses the ResvErr MUST take precautions against + a protocol loop where the egress responds with the same + LSP_TUNNEL_INTERFACE_ID object with the same (or different) issues. + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 23] + +RFC 6107 Procedures for H-LSPs February 2011 + + + Error | Error | Error-case + code | value | + ------+-------+------------------------------------------------------ + 38 11 Link address type or family not supported + 38 14 Component link identifier not valid + 38 15 Unsupported component link identifier address family + 38 16 Component link identifier missing + +3.7. Backward Compatibility + + The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class + number of 193. According to [RFC2205], this means that a node that + does not understand the object SHOULD ignore the object but forward + it, unexamined and unmodified. Thus, there are no issues with + transit LSRs supporting the pre-existing or new Class Types of this + object. + + A back-level ingress node will behave as follows: + + - It will not issue Path messages containing LSP_TUNNEL_INTERFACE_ID + objects with the new Class Types defined in this document. + + - It will reject Resv messages containing LSP_TUNNEL_INTERFACE_ID + objects with the new Class Types defined in this document as + described in [RFC2205]. In any case, such a situation would + represent an error by the egress. + + - It will continue to use the LSP_TUNNEL_INTERFACE_ID object with + Class Type 1 as defined in [RFC3477]. This behavior is supported + by back-level egresses and by egresses conforming to this document. + + - According to an informal survey, there is no significant deployment + of numbered FA establishment following the procedures defined in + [RFC4206] and set out in Section 1.3.6 of this document. It is + therefore safe to assume that back-level ingress LSRs will not use + this mechanism. + + A back-level egress node will behave as follows: + + - It will continue to support the LSP_TUNNEL_INTERFACE_ID object with + Class Type 1, as defined in [RFC3477], if issued by an ingress. + + - It will reject a Path message that carries an + LSP_TUNNEL_INTERFACE_ID object with any of the new Class Types + defined in this document using the procedures of [RFC2205]. This + will inform the ingress that the egress is a back-level LSR. + + + + + +Shiomoto & Farrel Standards Track [Page 24] + +RFC 6107 Procedures for H-LSPs February 2011 + + + - It will not expect to use the procedures for numbered FA + establishment defined in [RFC4206] and set out in Section 1.3.6 of + this document. + + In summary, the new mechanisms defined in this document do not impact + the method to exchange unnumbered FA information described in + [RFC3477]. That mechanism can be safely used in combination with the + new mechanisms described here and is functionally equivalent to using + the new C-Type indicating an unnumbered link with target IGP instance + identifier with the Target IGP Instance value set to 0xffffffff. + + The mechanisms in this document obsolete the method to exchange the + numbered FA information described in [RFC4206] as described in + Section 1.4.6. + +4. Security Considerations + + [RFC3477] points out that one can argue that the use of the extra + interface identifier that it provides could make an RSVP message + harder to spoof. In that respect, the minor extensions to the + protocol made in this document do not constitute an additional + security risk, but could also be said to improve security. + + It should be noted that 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. That is, the egress LSR + MUST NOT automatically accept the word of the ingress unless it is + configured with such a policy. + + Further details of security for MPLS-TE and GMPLS can be found in + [RFC5920]. + +5. IANA Considerations + +5.1. New Class Types + + IANA maintains a registry of RSVP parameters called "Resource + Reservation Protocol (RSVP) Parameters" with a sub-registry called + "Class Names, Class Numbers, and Class Types". There is an entry in + this registry for the LSP_TUNNEL_INTERFACE_ID object defined in + [RFC3477] with one Class Type defined. + + IANA has allocated three new Class Types for this object as defined + in Sections 3.1.2, 3.1.3, and 3.1.4 as follows: + + + + + + + +Shiomoto & Farrel Standards Track [Page 25] + +RFC 6107 Procedures for H-LSPs February 2011 + + + C-Type Meaning Reference + --------------------------------------------------------------- + 2 IPv4 interface identifier with target [RFC6107] + 3 IPv6 interface identifier with target [RFC6107] + 4 Unnumbered interface with target [RFC6107] + +5.2. Hierarchy Actions + + Section 3.1.2 defines an 8-bit flags field in the + LSP_TUNNEL_INTERFACE_ID object. IANA has created a new sub-registry + of the "Generalized Multi-Protocol Label Switching (GMPLS) Signaling + Parameters" registry called the "Hierarchy Actions" sub-registry as + follows: + + Registry Name: Hierarchy Actions + Reference: [RFC6107] + Registration Procedures: Standards Action + + Registry: + Bit Number Hex Value Name Reference + ---------- ----------- ----------------------- --------- + 0-2 Unassigned + 3 0x10 Hierarchy/stitching (H) [RFC6107] + 4 0x08 Bundle (B) [RFC6107] + 5 0x04 Routing adjacency (R) [RFC6107] + 6 0x02 TE link (T) [RFC6107] + 7 0x01 Private (P) [RFC6107] + +5.3. New Error Codes and Error Values + + IANA maintains a registry of RSVP error codes and error values as the + "Error Codes and Globally-Defined Error Value Sub-Codes" sub-registry + of the "Resource Reservation Protocol (RSVP) Parameters" registry. + + IANA has defined a new error code with value 38 as below (see also + Section 3.6). + + Error Code Meaning + + 38 LSP Hierarchy Issue [RFC6107] + + IANA has listed the following error values for this error code (see + also Section 3.6). + + + + + + + + +Shiomoto & Farrel Standards Track [Page 26] + +RFC 6107 Procedures for H-LSPs February 2011 + + + This Error Code has the following globally-defined Error + Value sub-codes: + + 1 = Link advertisement not supported [RFC6107] + 2 = Link advertisement not allowed by policy [RFC6107] + 3 = TE link creation not supported [RFC6107] + 4 = TE link creation not allowed by policy [RFC6107] + 5 = Routing adjacency creation not supported [RFC6107] + 6 = Routing adjacency creation not allowed by policy [RFC6107] + 7 = Bundle creation not supported [RFC6107] + 8 = Bundle creation not allowed by policy [RFC6107] + 9 = Hierarchical LSP not supported [RFC6107] + 10 = LSP stitching not supported [RFC6107] + 11 = Link address type or family not supported [RFC6107] + 12 = IGP instance unknown [RFC6107] + 13 = IGP instance advertisement not allowed by policy [RFC6107] + 14 = Component link identifier not valid [RFC6107] + 15 = Unsupported component link identifier address [RFC6107] + family + 16 = Component link identifier missing [RFC6107] + +6. Acknowledgements + + The authors would like to thank Lou Berger, Deborah Brungard, John + Drake, Yakov Rekhter, Igor Bryskin, and Lucy Yong for their valuable + discussions and comments. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., + and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- + Version 1 Functional Specification", RFC 2205, + September 1997. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", RFC + 3031, January 2001. + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, + V., and G. Swallow, "RSVP-TE: Extensions to RSVP for + LSP Tunnels", RFC 3209, December 2001. + + + + + +Shiomoto & Farrel Standards Track [Page 27] + +RFC 6107 Procedures for H-LSPs February 2011 + + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, January 2003. + + [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered + Links in Resource ReSerVation Protocol - Traffic + Engineering (RSVP-TE)", RFC 3477, January 2003. + + [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link + Bundling in MPLS Traffic Engineering (TE)", RFC 4201, + October 2005. + + [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths + (LSP) Hierarchy with Generalized Multi-Protocol Label + Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, + October 2005. + + [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. + Farrel, "Label Switched Path Stitching with + Generalized Multiprotocol Label Switching Traffic + Engineering (GMPLS TE)", RFC 5150, February 2008. + +7.2. Informative References + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP + and dual environments", RFC 1195, December 1990. + + [RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", + RFC 1256, September 1991. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April + 1998. + + [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic + Engineering (TE) Extensions to OSPF Version 2", RFC + 3630, September 2003. + + [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing + Extensions in Support of Generalized Multi-Protocol + Label Switching (GMPLS)", RFC 4202, October 2005. + + [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF + Extensions in Support of Generalized Multi-Protocol + Label Switching (GMPLS)", RFC 4203, October 2005. + + + + + + +Shiomoto & Farrel Standards Track [Page 28] + +RFC 6107 Procedures for H-LSPs February 2011 + + + [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., + Vigoureux, M., and D. Brungard, "Requirements for + GMPLS-Based Multi-Region and Multi-Layer Networks + (MRN/MLN)", RFC 5212, July 2008. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, October 2008. + + [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS + Extensions in Support of Generalized Multi-Protocol + Label Switching (GMPLS)", RFC 5307, October 2008. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + October 2008. + + [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, + Ed., "Traffic Engineering Extensions to OSPF Version + 3", RFC 5329, September 2008. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, + "OSPF for IPv6", RFC 5340, July 2008. + + [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS + Networks", RFC 5920, July 2010. + + [ISIS-GENAP] Ginsberg, L., Previdi, S., and M. Shand, "Advertising + Generic Information in IS-IS", Work in Progress, + November 2010. + + [ISIS-IPV6-TE] Harrison, J., Berger, J., and M. Bartlett, "IPv6 + Traffic Engineering in IS-IS", Work in Progress, + September 2010. + + [OSPF-TI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Transport + Instance Extensions", Work in Progress, October 2010. + + [OSPFv2-MI] Lindem, A., Roy, A., and S. Mirtorabi, "OSPF Multi- + Instance Extensions", Work in Progress, October 2010. + + [PCE-LAYER] Takeda, T., Ed., and A. Farrel, "PCC-PCE Communication + and PCE Discovery Requirements for Inter-Layer Traffic + Engineering", Work in Progress, December 2010. + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 29] + +RFC 6107 Procedures for H-LSPs February 2011 + + +Authors' Addresses + + Richard Rabbat + Google Inc. + 1600 Amphitheatre Pkwy + Mountain View, CA 94043 + United States of America + EMail: rabbat@alum.mit.edu + + Arthi Ayyangar + Juniper Networks + 1194 N. Mathilda Ave. + Sunnyvale, CA 94089 + United States of America + EMail: arthi@juniper.net + + Zafar Ali + Cisco Systems, Inc. + 2000 Innovation Drive + Kanata, Ontario, K2K 3E8 + Canada + EMail: zali@cisco.com + +Editors' Addresses + + Kohei Shiomoto + NTT Network Service Systems Laboratories + 3-9-11 Midori + Musashino, Tokyo 180-8585 + Japan + Phone: +81 422 59 4402 + EMail: shiomoto.kohei@lab.ntt.co.jp + + Adrian Farrel + Old Dog Consulting + EMail: adrian@olddog.co.uk + + + + + + + + + + + + + + + +Shiomoto & Farrel Standards Track [Page 30] + -- cgit v1.2.3