Network Working Group K. Shiomoto (NTT) Internet Draft R. Rabbat (Google) Updates: 3477, 4206 A. Ayyangar (Juniper Networks) Proposed Category: Proposed Standard A. Farrel (Old Dog Consulting) Z. Ali (Cisco Systems, Inc.) Expires: August 2008 February 22, 2008 Procedures for Dynamically Signaled Hierarchical Label Switched Paths draft-ietf-ccamp-lsp-hierarchy-bis-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on August 22,2008. Abstract This document discusses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a Shiomoto Expires October 2007 [Page 1] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 dynamically signaled Forwarding Adjacency LSP (FA-LSP) or as a Routing Adjacency (RA). In addition, the document also discusses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP, and how to identify the instance that should be used. Conventions used in this document 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]. Table of Contents 1. Introduction and Problem Statement..........................3 1.1. LSP Hierarchy............................................3 1.2. LSP advertisement and Usage...............................4 1.3. Problem Statement........................................6 1.4. Current Approaches and Shortcomings.......................8 1.5. Contents of This Document.................................9 2. Revision history...........................................9 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00.9 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01.9 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02.10 3. Proposed Solution..........................................10 3.1. IGP Instance Identification...............................11 3.2. LSP advertisement and Usage Identification................11 3.3. Bundling.................................................12 3.4. LSP_TUNNEL_INTERFACE_ID Object............................12 3.4.1. Unnumbered link.........................................13 3.4.2. IPv4 numbered link......................................14 3.4.3. IPv6 numbered link......................................15 3.4.4. Unnumbered link with target IGP instance identifier......16 3.4.5. Message Formats........................................16 3.5. TLVs.....................................................17 3.5.1. Unnumbered Component Link Identifier....................17 3.5.2. IPv4 Numbered Component Link Identifier.................18 3.6. LSA advertisement........................................18 4. Applicability Statement.....................................19 5. Backward Compatibility Considerations.......................19 6. Security Considerations.....................................19 7. IANA Considerations........................................20 8. Acknowledgement............................................20 9. References.................................................20 9.1. Normative References.....................................20 Shiomoto Expires August 2008 [Page 2] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 9.2. Informative References....................................20 Author's Addresses............................................21 Intellectual Property Statement................................22 Copyright Statement...........................................23 1. Introduction and Problem Statement 1.1. LSP Hierarchy LSP hierarchy has been developed to improve the scalability of Generalized Multi-Protocol Label Switching (GMPLS) by allowing Label Switched Paths (LSPs) to be aggregated into a hierarchy of such LSPs [RFC4206]. An LSP may be advertised as a traffic engineering (TE) link for use within the same instance of the control plane as was used to set up the LSP. This TE link is called a Forwarding Adjacency (FA), and the LSP is known as an FA-LSP. [RFC4206] defines the operation as follows for a numbered FA: 1. The ingress signals the LSP using a /31 sender address that it allocates as the source address in the signaling message (tunnel sender address in the Sender Template object of the Path message), and targeting the TE router ID of the egress (destination address in the Sender object of the Path message). 2. The egress sets up the LSP using normal procedures and allocating the partner address of the assigned /31 address in the local interface address. 3. The ingress then forms a Forwarding Adjacency (FA) out of that LSP by advertising it as a Traffic Engineering (TE) link using the routing protocol (OSPF/ISIS) and using the /31 address to identify the local end of the TE link. 4. When the egress receives the TE link advertisement, it checks the Link-ID address of the TE advertisement against its own TE Router ID. If it matches its own TE Router ID, the egress checks the advertising router ID of the TE advertisement against the ingress addresses of all LSPs for which it is the egress and finds the address match with the advertising router ID of the TE advertisement. Shiomoto Expires August 2008 [Page 3] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 5. The egress then advertises the FA LSP as a TE link setting the advertising TE Router ID in the Link-ID and the partner address of the assigned /31 address in the local interface address. Nesting of LSPs originated by other LSRs into that LSP can be achieved by using the label stack construct. 1.2. LSP advertisement and Usage There are three different ways in which traffic can be forwarded to There are different ways in which an LSP can be used to carry traffic and potentially advertised as a link by a routing protocol. First, the LSP can be used either as a link inside or outside the network that was used to form the LSP. In the former case, the LSP can carry traffic that could have been routed down the TE links that are navigated by the LSP. In the latter case, it is used by a client network, which is provided on top of the network [MLN-REQ]. It can provide a new, virtual, point-to-point link in a client network. The former case can only be achieved in packet networks as they are the only type of network that supports nesting of LSPs within the same technology LSP, but the latter case is applicable to all client/server network relationships such as IP over MPLS, or packet over optical. Second, the link formed by the LSP can be advertised by the routing protocol as available to carry traffic, or can be kept as a private link known only to the head and tail end LSRs. These two options give rise to four possible combinations as follows. 1. The LSP is created and advertised as a TE link in the same instance of the routing protocol as was used to advertise the links that it traverses. This is a Forwarding Adjacency as described in [RFC4206]. Note that no routing adjacency is formed over the LSP. 2. The LSP is created and made available to carry traffic in the same network as the links that it traverses, but it is not advertised. The availability of the LSP is private to the end Shiomoto Expires August 2008 [Page 4] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 points. This is a hierarchical LSP, but not an FA. It might be used for inter-domain traffic engineering [RFC4726]. 3. The LSP is created as before, but is advertised as a link in another instance of the routing protocol. This method of operation is particular to client/server networks and especially multi-layer networks [MLN-REQ], [PCE-INTER-LAYER-REQ]. 4. An LSP can be created and used by a client network without being advertised in the client network routing protocol. Just as in case 2, the existence of the LSP as a protocol tunnel is known only to the tunnel LSP points which are nodes in the client network. Notes: a. Case 1 includes the multi-layer traffic engineering scenario where a single instance of the routing protocol is used across both layers. This situation was particularly envisaged in [RFC4206]. b. The example cited in case 2 is special because the hierarchical LSP is edge-to-edge within a particular domain and no TE links are advertised outside of the domain (by definition of the domain). The purpose of the TE link is to carry traffic across the domain and not to carry intra-domain traffic. Advertising the TE link within the domain might cause internal traffic to take longer paths as it seeks to use the hierarchical LSP. c. Case 3 is not the only option for the multi-layer network as explained in Note a. d. The client network in case 3 may be a different technology TE network (such as a GMPLS TDM network that operates over a GMPLS WDM network, or an MPLS-TE network operating over a GMPLS optical network), a same-technology TE network where LSP nesting is allowed (for example, an MPLS-TE network operating over another MPLS-TE network), or a non-TE network (such as an IP network operating over an MPLS-TE or GMPLS network of any technology). Thus, the link advertised may be a TE link, or a routing link. In the second instance, the LSP is used to form a virtual adjacency between two non-neighboring IP routers (a Routing Adjacency - RA) forming IGP shortcuts. e. IGP shortcuts are precluded when the LSP end-points reside Shiomoto Expires August 2008 [Page 5] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 within different IGP areas [RFC4105]. f. IGP shortcuts should be treated with extreme caution when they are created and used in the same IP/MPLS network. Thus, it may be more common to use them as described in case 4 and even in this case, only when the egress of the LSP is the final destination of the traffic carried. g. It would be unusual although not impossible to use a hierarchical LSP as an IGP shortcut within the control plane. 1.3. Problem Statement The extensions described in this document are intended for dynamically signaled bi-directional Forwarding Adjacency LSPs (FA-LSPs). In particular this document addresses the following points: (1) How to let the egress node know that this bi-directional LSP needs to be advertised as an FA, or as an RA, or as an FA and RA or is a local virtual link only for the use of the ingress and egress nodes. (2) How to indicate that a new LSP should be treated as part of a TE link bundle and advertised as part of that bundle. (3) How to identify the routing instance in which such an advertisement should happen. We should note that these aspects are equally applicable to both numbered and unnumbered TE links. In order for the egress of an LSP to be able to advertise the LSP as a TE link it needs to know that such an advertisement is desirable, and it also needs to know the TE Router ID of the ingress LSR. (Please recall that the Router ID of the other end of the link is set in the Link-ID sub-TLV of the Link TLV of the TE Opaque-LSA [RFC3630].) If the LSP is to form part of a TE link bundle, the egress must also know the identity of the bundle. When the mechanism set out in section 1.1 is used for numbered FAs, there is no way to carry the TE Router ID of the ingress LSR in the RSVP signaling message (Path message) and there is no way to indicate that the new LSP is to be used as an FA LSP. Therefore the egress LSR has to wait to receive a routing protocol advertisement of the TE link flooded by the ingress to Shiomoto Expires August 2008 [Page 6] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 learn about the new TE link and to deduce that the LSP forms that TE link. The egress must learn the TE Router ID of the ingress node before it can advertise the FA as described in Section 1.2. Note further, that in this approach, the egress LSR must search potentially many LSPs every time it receives an advertisement for a new TE link. [RFC3477] defines a different method for the exchange of information in the signaling protocol during the establishment of LSPs that will be advertised as unnumbered TE links. If the LSP_TUNNEL_INTERFACE_ID object is present, it indicates that the LSP is to be advertised as a TE link, and it contains the TE Router ID of the ingress LSR. This mechanism resolves many of the issues listed above, and provides a solution for unnumbered TE links, however, the LSP_TUNNEL_INTERFACE_ID object cannot be used for numbered FAs as currently defined, and so the problem remains for numbered TE links. Related to the above problem, a few key observations are worth noting: 6. The term FA is applicable only when an LSP is created and used as a TE link in the same instance of the IGP. [RFC4206] did not consider scenarios where an LSP is created (and maintained) by one instance of the IGP, and is used as a (TE) link by another instance of IGP. This leaves open the question of advertising a TE link into a different instance of the IGP as is needed in multi-region/multi-layer networks [MLN-REQ], and how to identify which instance of the IGP should be used. In addition, the TE link advertised into the different IGP instance may be associated with an IGP neighbor adjacency. We call it a routing adjacency (RA). The decision as to whether the link should be advertised to MPLS TE topology or IP topology or both depends on operator policy. Therefore, a mechanism to indicate the choice to the Egress node is needed. 7. [RFC4206] provides a way to exchange numbered identifiers for the TE link, but this does not clearly state that the Ingress node can use presence of the LSP_TUNNEL_INTERFACE_ID object as a trigger for TE link advertisement at the egress node. Shiomoto Expires August 2008 [Page 7] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 8. It is important to note that an LSP that is set up in a server GMPLS transport network and advertised as a TE link in a client MPLS data network is NOT an FA-LSP according to the definitions explained in point 1, above. This is the case regardless of whether the GMPLS network is packet- or non- packet-capable. 9. When an egress checks the address of the advertised TE link to find the LSP sender (Recall step (4) as described in section 1.1), it must check the Link-ID address of all received TE advertisements against its own TE Router ID. If it matches its own TE Router ID, the egress checks the advertising router ID of the TE advertisement against the ingress addresses of all LSPs for which it is the egress. It is an assertion of the authors that this method is not scalable due to the amount of processing needed for all the TE Link State Advertisements (LSAs). 10.Further, if a set of LSPs are to be bundled into a single TE link [RFC4201] then not only is it necessary to identify to the egress that the LSP will be advertised as part of a TE link, it is also necessary to indicate the identity of the TE link. This identity is distinct from the identity of the component link. Thus, in this case an additional identifier needs to be signaled, but none is currently available. 1.4. Current Approaches and Shortcomings [RFC3477] provides a mechanism to exchange unnumbered identifiers for the TE link during FA-LSP establishment, and this can be used as a notification to the egress that the LSP will be used as a TE link. So, for unnumbered TE links, there is a well-defined indication available, and this could be documented and used as a trigger for TE link advertisement by the egress. The use of unnumbered TE links may be arguably more sensible than assigning numbers to FAs, especially in the case of large networks. Some operators though prefer to consistently use numbered TE links for both static and dynamic (that is, FA) TE links in their networks. In the case of numbered TE links, however, there is no available indication to allow the egress to know that an LSP should be advertised as a TE link. In addition, using unnumbered TE links does not address the issue of advertising TE links into a different instance of the Shiomoto Expires August 2008 [Page 8] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 IGP. There is no defined mechanism to identify whether it should be advertised as an FA, a full Routing Adjacency (RA), or it should be used as a local virtual link. The Link Management Protocol (LMP) [RFC4204] could possibly be run on remote adjacencies between the endpoints of an LSP. But LMP peer discovery would be required for dynamic LMP peering and is not currently specified. In addition, the concept of a remote LMP adjacency remains unproven. Lastly, there would be a requirement that all layers/regions in a MLN network run LMP. This may not be the case in existing networks and would put undue burden on the network operator to deploy another protocol. 1.5. Contents of This Document This document provides a consolidated way of exchanging TE link identifiers when an LSP is established through signaling. It also provides a mechanism to allow the ingress to control whether, and into which IGP instances, an LSP is advertised as an FA and/ or RA by the egress. The proposed mechanism applies equally to Hierarchical LSPs (H-LSPs) and Stitchable LSPs (S- LSPs). The method described below extends the method described in [RFC3477], which is applied for an FA-LSP represented as an unnumbered TE link. 2. Revision history 2.1. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-00 o Fixed page formatting o Updated author addresses o Readability fixes 2.2. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-01 o Added indication of bundled link o Added "ACTION" field, which obsoletes R and F bits o Readability fixes Shiomoto Expires August 2008 [Page 9] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 2.3. Changes from version draft-ietf-ccamp-lsp-hierarchy-bis-02 o Rewrite Section 1.2 o Updated author addresses o Readability fixes 3. Proposed Solution The following method allows the ingress and egress LSRs to exchange the link addresses or link identifiers (including the node ID) of the ends of a numbered or unnumbered TE link to be formed from an LSP. It is an extension of the procedures defined in [RFC3477] for unnumbered TE links. If an ingress LSR that originates an LSP, intends to advertise this LSP as a TE link in IS-IS or OSPF [RFC4206], the ingress LSR MUST allocate an address or identifier to the TE link (just like for any other TE link), and it MUST do this before the LSP setup request is signaled. Moreover, the Path message used for establishing the LSP that will be used to form the TE link MUST contain the LSP_TUNNEL_INTERFACE_ID object (as extended and described below), with the interface address or identifier allocated by the ingress LSR. If the Path message for the H-LSP/S-LSP contains the LSP_TUNNEL_INTERFACE_ID object, then the egress LSR (assuming it accepts the LSP request) MUST allocate an address or identifier to the TE link that will be formed (just like for any other numbered or unnumbered TE link). Furthermore, the Resv message for the LSP MUST contain an LSP_TUNNEL_INTERFACE_ID object, with the interface address or identifier allocated by the egress LSR. In all cases where an LSP is to be advertised as a TE link, the Tunnel Sender Address in the Sender Template Object of the Path message MUST be set to the TE Router ID of the ingress LSR. We should note that this is a change from the method described in [RFC4206]. Once the egress LSR has successfully sent a Resv message as described above it SHOULD advertise the LSP as a TE link using the addresses/identifiers exchanged. Once the Resv has been processed by the ingress LSR and the LSP has been successfully established, the ingress LSR SHOULD advertise the LSP as a TE link using the addresses/identifiers exchanged. Shiomoto Expires August 2008 [Page 10] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 Once the TE link advertisement has been flooded it is available for use in path computation and LSP signaling just like any other TE link. 3.1. IGP Instance Identification The mechanism described so far allows an ingress LSR to indicate that an LSP is to be used as a TE link and allows the ingress and egress LSRs to exchange addresses or identifiers for that TE link, during LSP setup. However, it is also necessary to indicate into which instance of the IGP the advertisement should be made. This is only necessary if the LSP is to be advertised as a TE link into a different instance of the IGP, and the default behavior may safely be left with the LSP advertised into the same instance of the IGP. Indication of the IGP in which the advertisement is to be made first requires that a 32-bit identifier be assigned to each of the IGP instances within a network, and that ingress and egress LSRs have the same understanding of these numbers. This is a management configuration exercise outside the scope of this document. Once these numbers have been assigned, they MAY be signaled as additional information in the LSP_TUNNEL_INTERFACE_ID object to indicate to which instance of the IGP the object applies. The IGP instance identifier value of 0xffffffff is reserved to indicate that the TE link SHOULD be advertised into the same instance of the IGP as was used to establish the LSP. Similarly, absence of the IGP instance identifier means that an FA is to be established (in the same IGP instance). 3.2. LSP advertisement and Usage Identification As mentioned earlier, the egress node also needs to know if it needs to create a full routing adjacency or forwarding adjacency or just need to treat the LSP as a local virtual link. The extensions defined in the following also specify the LSP advertisement and usage treatment. Shiomoto Expires August 2008 [Page 11] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 It is not mutually exclusive whether the LSP has routing adjacency and whether it has forwarding adjacency. The LSP can have both routing and forwarding adjacency. In this case, the LSP can be used to carry both pure IP datagram packets and MPLS labeled packets. If the LSP has only forwarding adjacency, it is used as TE-link to carry only MPLS labeled packets. If the LSP has only routing adjacency, it is used as IP link to carry only pure IP datagram packets. Note that the LSP which has only forwarding adjacency is useful to improve the scalability. Suppose that distant PSC domains are connected by a set of lower-layer LSPs created in the optical domain (TDM, LSC, or FSC). We do not require routing adjacency on all such lower-layer LSPs as long as we have control plane connectivity through a subset of lower-layer LSPs which have routing adjacency. We reduce the amount of overhead of IGP protocol processing on the LSPs which do not have routing adjacency. It is mutually exclusive whether the LPS has routing adjacency and whether it is treated as a local virtual link. Likewise, it is mutually exclusive whether the LSP has forwarding adjacency and whether it is treated as a local virtual link. 3.3. Bundling It is possible to treat LSPs as component links and to bundle them into a single TE link. However there is currently no way to signal that an LSP will be used as part of a bundle and to identify the bundled link to which the LSP is supposed to belong. Each LSP that is to form a component link is signaled using the LSP_TUNNEL_INTERFACE_ID object to identify the TE link bundle to which the LSP will belong. Thus multiple LSPs may be signaled with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object. When the LSP is to form a component link, the LSP_TUNNEL_INTERFACE_ID object MUST also contain an additional TLV to identify the component link. This may be a numbered or unnumbered identifier. Multiple LSPs may be signaled with the same address/identifier in the LSP_TUNNEL_INTERFACE_ID object. 3.4. LSP_TUNNEL_INTERFACE_ID Object The LSP_TUNNEL_INTERFACE_ID object defined in [RFC3477] has a class number of 193, which designates that a node that does not Shiomoto Expires August 2008 [Page 12] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 understand the object SHOULD ignore the object but forward it, unexamined and unmodified, in all messages resulting from this message. [RFC3477] defines one class type to indicate an unnumbered interface identifier. This document defines three new class types as follows. C-Type Meaning Reference ---------------------------------------------------------------- 1 Unnumbered interface identifier [RFC3477] 2 (TBD by IANA) IPv4 interface identifier with target 2.2.2 3 (TBD by IANA) IPv6 interface identifier with target 2.2.3 4 (TBD by IANA) Unnumbered interface with target 2.2.4 Multiple instances of the LSP_TUNNEL_INTERFACE_ID object with C- Type values 2, 3 or 4 MAY appear in any one Path or Resv message, in which case, each MUST have a different value for the Target IGP Instance field. 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, other instances of the object with any other C-Type value MUST NOT have Target IGP Instance set to 0xffffffff. 3.4.1. Unnumbered link The unnumbered link identifier defined by [RFC3477] is not changed by this document. Its usage also remains the same. That is, when present in a Path message it indicates that the LSP being established SHOULD be advertised by the egress LSR as a TE link, and that unnumbered link identifier is the ingress' identifier for the TE link. Note that since this form of the object does not contain a target IGP instance identifier it cannot identify a specific instance of the IGP into which this TE link should be advertised. Similarly, LSP advertisement and usage treatment also needs to be specified. Thus, when C-Type 1 is used, the TE link SHOULD be advertised only into the same instance of the IGP as was used to create the LSP. That is, the use of C-Type 1 is unchanged from [RFC3477] and is used to create an unnumbered Forwarding Adjacency. This object can appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface Shiomoto Expires August 2008 [Page 13] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 ID" for that LSP; in the latter case, we call it the "Reverse Interface ID" for the LSP. A Path or Resv message MUST have only one instance of this object with C-Type 1. 3.4.2. IPv4 numbered link A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined to carry an IPv4 numbered interface address and to indicate into which instance of the IGP the consequent TE link should be advertised. The format of the object is as shown below. C-NUM = 193, C-Type = 2(TBD by IANA) 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 (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ACTION: This field specifies how the LSP advertisement and usage treatment. It indicates if the egress LSR needs to create a full routing adjacency or forwarding adjacency or just need to treat the LSP as a local virtual link. It takes the following values: "0000": LSP is an FA and is only advertised into the MPLS-TE topology. We should note that it assures the backward compatibility with the method to exchange unnumbered FA information described in [RFC3477]. Shiomoto Expires August 2008 [Page 14] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 "0001": LSP is an RA and is only advertised into the IP network. "0010": LSP is an RA and FA and is advertised in both IP and MPLS-TE topologies. "0011": LSP is neither the FA nor RA and is to be used as a local virtual link. In this case the LSP is advertised neither in IP nor MPLS topology. The Padding MUST be set to zero on transmission, SHOULD be ignored and forwarded unchanged, and SHOULD be ignored on receipt. This object can appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface Address" for that LSP; in the latter case, we call it the "Reverse Interface Address" for the LSP. 3.4.3. IPv6 numbered link A new C-Type variant of the LSP_TUNNEL_INTERFACE_ID Object is defined to carry an IPv6 numbered interface address and to indicate into which instance of the IGP the consequent TE link should be advertised. The format of the object is as shown below. C-NUM = 193, C-Type = 3(TBD by IANA) 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 (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Interface Address (128 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. In the former case, we call it the "Forward Shiomoto Expires August 2008 [Page 15] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 Interface Address" for that LSP; in the latter case, we call it the "Reverse Interface Address" for the LSP. 3.4.4. Unnumbered link with target IGP instance identifier 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, but extends its utility. The format of the object is as shown below. C-NUM = 193, C-Type = 4(TBD by IANA) 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IGP Instance (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ACTION | PADDING | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLVs | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object can optionally appear in either a Path message or a Resv message. In the former case, we call it the "Forward Interface ID" for that LSP; in the latter case, we call it the "Reverse Interface ID" for the LSP. 3.4.5. Message Formats [RFC3477] does not state where in the Path message or Resv message the LSP_TUNNEL_INTERFACE_ID object should be placed. Since [RFC3209] states that all implementations are to handle all objects received in any order, this is not a problem. However, it is RECOMMENDED that the LSP_TUNNEL_INTERFACE_ID object(s) be placed in the Path message immediately after the SENDER_TSPEC object, and in the Resv message immediately after the FILTER_SPEC object. Shiomoto Expires August 2008 [Page 16] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 3.5. TLVs All TLVs of the LSP_TUNNEL_INTERFACE_ID object have the following format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (16 bits) | Length (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field contains the total length of the TLV including the Type and Length fields in bytes A value field whose length is not a multiple of four MUST be zero-padded so that the TLV is four-byte aligned. This document defines two Type values to be used to specify the component link identifier that the sending LSR has assigned to the LSP if it forms part of a TE link bundle. The consequent TLV formats are shown in the next sections. 3.5.1. Unnumbered Component Link Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Component Link Identifier (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV is present if the signaled LSP is to be used as an unnumbered component link of a bundled TE link. In this case, the identifier (numbered or unnumbered) in the main body of the LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which this LSP is a component, and the Component Link Identifier of this TLV specifies the unnumbered identifier that is assigned to this component link within the bundle. Shiomoto Expires August 2008 [Page 17] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 This TLV MUST NOT be present in the same instance of the LSP_TUNNEL_INTERFACE_ID object as a TLV with type 2 (numbered component link identifier). 3.5.2. IPv4 Numbered Component Link Identifier 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 2 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This TLV is present if the signaled LSP is to be used as a numbered component link of a bundled TE link. In this case, the identifier (numbered or unnumbered) in the main body of the LSP_TUNNEL_INTERFACE_ID object indicates the TE link bundle of which this LSP is a component, and the IPv4 Address field of this TLV specifies the numbered identifier that is assigned to this component link within the bundle. This TLV MUST NOT be present in the same instance of the LSP_TUNNEL_INTERFACE_ID object as a TLV with type 1 (unnumbered component link identifier). 3.6. LSA advertisement The ingress and egress LSRs MAY advertise link state associated with TE links created as described above. The link state may be advertised in either the same IGP instance as used to compute and signal the path for the LSPs that support the TE links, or another IGP instance. In the former case, the address space for the link state MUST be the same as that used to establish the LSPs. In the latter case, the address space for the link state MAY be different, which means that addresses already allocated in the IGP instance used to establish the LSPs MAY be used by the advertised TE link without any ambiguity. In the IGP the TE Router ID of the ingress LSR is taken from the Tunnel Sender Address in the Sender Template object. 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. Shiomoto Expires August 2008 [Page 18] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 The link interface addresses or link interface identifiers for the forward and reverse direction links are taken from the LSP_TUNNEL_INTREFACE_ID object on the Path and Resv messages respectively. Address overlap checking for these objects MUST be turned off when the LSA is advertised into a IGP instance different from the one used to establish the LSP because the addresses MAY be allocated in both domains. 4. Applicability Statement The method is applicable for both hierarchical LSPs [RFC4206] and LSP stitching [STITCH]. 5. Backward Compatibility Considerations The method does 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. This method obsoletes the method to exchange the numbered FA information described in [RFC4206]. This is not believed to be an issue as an informal survey indicated that dynamically signaled numbered FAs had not been deployed. Indeed it was the attempt to implement numbered FAs that gave rise to the work on this document. 6. 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. Shiomoto Expires August 2008 [Page 19] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 7. IANA Considerations This document defines three new C-Types for the LSP_TUNNEL_INTERFACE_ID object. The C-Types for this object are managed by IANA, and IANA is requested to assign values to the new C-Types as tabulated in section 2.2 and described in sections 2.2.2, 2.2.3 and 2.2.4. 8. Acknowledgement The authors would like to thank John Drake and Yakov Rekhter for their valuable discussions and comments. Funding for the RFC Editor function is currently provided by the Internet Society. 9. References 9.1. Normative References [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC3477]Kompella, K. and Rekhter, Y., "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003. [RFC4201]Kompella, K., Rekhter, Y., and Berger, L.," Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4206] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", RFC 4206, October 2005. [STITCH] Ayyangar, A. and J.P. Vasseur, "Label Switched Path Stitching with Generalized MPLS Traffic Engineering", draft-ietf-ccamp-lsp-stitching, (work in progress). 9.2. Informative References [RFC3630]Katz, D., Kompella, K. and Yeung, D., "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. Shiomoto Expires August 2008 [Page 20] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 [RFC4105]Le Roux, J.-L., Vassuer, J.-P., and Boyle, J. (Eds.), "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4204]Lang, J. (Ed.), "Link Management Protocol (LMP)", RFC 4204, October 2005. [RFC4726]Farrel, A., Vasseur, J.-P., and Ayyangar, A., " A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering ", RFC 4726, November 2006. [MLN-REQ]Shiomoto, K., et al, "Requirements for GMPLS-based multi-region and multi-layer networks (MRN/MLN)", draft-ietf-ccamp-gmpls-mln-reqs, (work in progress). [PCE-INTER-LAYER-REQ] Oki, E. (Ed.), " PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering ", draft-ietf-pce-inter-layer-req, (work in progress). Author's 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 Shiomoto Expires August 2008 [Page 21] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 Richard Rabbat Google Inc. Email: rabbat@alum.mit.edu Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 United States of America Phone: Email: arthi@juniper.net Adrian Farrel Old Dog Consulting EMail: adrian@olddog.co.uk Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario, K2K 3E8 Canada. EMail: zali@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other Shiomoto Expires August 2008 [Page 22] Internet-Draft draft-ietf-ccamp-lsp-hierarchy-bis-03 Feburuary 2008 proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Shiomoto Expires August 2008 [Page 23]