MPLS Working Group Internet Draft S. Van den Bosch D. Papadimitriou Document: draft-vandenbosch-mpls-fa- Alcatel considerations-01.txt Expires: January 2003 July 2002 Further considerations for Forwarding Adjacency LSPs draft-vandenbosch-mpls-fa-considerations-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 [1]. 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. Abstract Forwarding adjacencies (FA) as described in [2] are a useful tool for improving the scalability of Generalized MPLS (GMPLS) Traffic Engineering (TE). Through the aggregation of TE LSPs this concept enables the creation of a TE-LSP Hierarchy. Forwarding adjacency LSPs (FA-LSP or simply FA) may be advertised as TE link into the same instance of ISIS/OSPF as the one that was used to create the LSP, allowing other LSRs to use FAs as TE-links for their path computation. As such, forwarding adjacency LSP have characteristics of both links and LSPs. This document list a number of topics for further study regarding forwarding adjacencies in an attempt to identify what future work may result in the MPLS WG (or other) from the link/LSP duality. 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 RFC 2119 [3]. Van den Bosch et al. Informational - Expires January 2003 1 Further considerations for FA-LSPs July 2002 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 Conventions used in this document..................................1 1. Introduction....................................................2 2. Topics for further study........................................3 2.1. Establishment and teardown of FA for PSC interfaces..........3 2.2. Dynamic recomputation of paths for FA-LSPs...................4 2.3. Protection of FA-LSPs........................................4 2.4. Interworking with fast reroute techniques....................4 2.5. Traffic engineering attributes of FA-LSPs....................5 3. A Step Further..................................................5 3.1. A new resource class sub TLV.................................6 4. Security Considerations.........................................7 References.........................................................8 Acknowledgments....................................................8 Author's Addresses.................................................8 Full Copyright Statement...........................................9 1. Introduction In its successful attempt to extend MPLS for non-packet oriented TE- attributes within the scope of an integrated model encompassing several layers, , GMPLS has been rapidly confronted to mapping of the several data plane layers within the control plane. As such, and from the control plane viewpoint a transport plane layer is mapped to an LSP region (see [2]). Following this approach, a TE-link (at the control plane) maps exactly the definition the one proposed in the canonical layered model where a link is a link bundle (using the IETF terminology). The TE Link concept opens the door for a clear separation between the routing adjacencies and data plane bearer links. Furthermore, TE Links have been extended to non adjacent devices by introducing the Forwarding Adjacency (FA) concept enabling in turn to decrease the number of control plane instances to control N transport layers. Using the Forwarding Adjacency a node may (under its local control policy configuration) advertise an LSP as a TE link into the same ISIS/OSPF instance as the one that determines the path taken for this LSP. Such a link is referred to as a "forwarding adjacency" (FA) and the corresponding LSP to as a "forwarding adjacency LSP", or simply FA-LSP. Since the advertised entity appears as a TE link in ISIS/OSPF, both end-point nodes of the FA-LSP must belong to the same ISIS level/OSPF area (intra-area improvement of scalability). Afterwards, ISIS/OSPF floods the link-state information about FAs just as it floods the information about any other TE Link. This allows other nodes (belonging to the same region) to use FAs as any other TE Links for path computation purposes. Van den Bosch et al. Informational - Expires January 2003 2 Further considerations for FA-LSPs July 2002 While this definition is in perfect alignment for non-packet LSP regions and boundaries, the same concept(s) can be re-used in the MPLS LSP context but with a major difference. The mapping goes in the opposite direction from the control to the IP/MPLS forwarding plane since FA-LSP in the packet domain are purely abstract concept that would if well tailored, provide additional scalability within a routing plane instance (in particular, an area). Indeed, the use of FAÆs provides a mechanism for improving bandwidth utilization when its dynamic allocation can be performed in discrete units; it also enables aggregating forwarding state, and in turn, reducing significantly the number of required labels. Therefore, FAs may significantly improve the scalability of GMPLS TE-capable control planes, and allow the creation of a TE-LSP hierarchy. In this context, the present document tries to identify and briefly address some of the issues for FA-LSP in a packet-switching (PSC) context that could require further effort from the Sub-IP Area community. 2. Topics for further study This section list some topics, this might be extended in future release of this document. 2.1. Establishment and teardown of FA for PSC interfaces A LSR can have multiple interface Switching Capabilities (SC). This aspect is of particular importance with packet switch capable (PSC) interfaces that can simultaneously belong to four PSC regions. These effectively constitute a logical hierarchy that can be exploited through label stacking in order to provide scalable TE in large single area networks. However, combining such an approach with constraint-based TE-routing would imply the need for dynamic modification of an interface's switching capability in order to promote/demote it in the logical hierarchy (corresponding to the creation/deletion of a layer in the hierarchy). The other way is to advertise multiple PSC capabilities, and so let the network dynamically build-up this hierarchy. In such an eventuality, the increasing complexity comes up from the ôdynamic modificationö that would arise from such policy since each Switching Capability value can be assigned independently to each ingress LSR (when initiating the packet LSP Path/Label Request message). It is unclear if the setup of a FA-LSP should be done by provisioning or whether it can be triggered by the setup of client LSPs. A FA-LSP that is set up needs to be advertised with a certain bandwidth and priority. If an FA-LSP triggered by other LSP setup requests is allowed, this could lead to the advertisement of FA-LSPs with zero available bandwidth. If several levels of such LSPs exist, it is also unclear if their priorities should all be updated when a new LSP arrives with a higher priority (lower priority value). Finally, it is not specified what should happen with existing LSPs Van den Bosch et al. Informational - Expires January 2003 3 Further considerations for FA-LSPs July 2002 that could potentially use the FA-LSP but were set up prior to its establishment. 2.2. Dynamic recomputation of paths for FA-LSPs The path information regarding the FA-LSP may be available to other nodes by means of the PATH TLV. This information may be used by other nodes for their own path computations. They could for instance take it into account when computing a backup path. Then if the FA- LSP changes path, primary and backup path of the client LSPs may no longer be disjoint. Therefore, it may be necessary to foresee the possibility to restrict the re-routability of the FA-LSP and advertise this in the PATH TLV. In this way, ingress LSR that use this information would know whether it is subject to any change at a lower LSP region or not. 2.3. Protection of FA-LSPs Four packet interface switching capabilities (PSC-1 to PSC-4) are defined (see [2]). When FA-LSPs are protected, it means that SRLG information needs to propagate to the upper LSP region(s) for consistency. It is not obvious how the SRLG information and disjointness of FA-LSPs can be treated in an efficient way with a label stack of potentially depth four (PSC-1 -4) or even more if regions do not delimit LSP tunnel diameter. In particular, it is not obvious to determine to which region(s) this information should be made available, in absence of any specific rules, one can assume for instance that only interfaces belonging to the initiating region should be have this information available. However, nothing precludes that other PSC regions may use existing FAÆs for their own purposes. For instance, consider an FA-LSP established within PSC-4 region, the LSR interfaces surrounding this FA belongs either to PSC-1 or û2 or û3 or any combination of these values. It becomes then a key issue to know if an upper region LSP can be link protected by component links referring to a single or multiple regions. 2.4. Interworking with fast reroute techniques An FA-LSP is at the same time a path to the server layer and a link to the client layer. In this context, link protection techniques such as the ones proposed for fast local restoration may be applicable [4]. More specifically, one could for instance envisage the establishment of FA-LSPs for the intra-area sections of a multi-area LSP. In that case, fast local reroute techniques applied at the FA-LSP level could provide inter-area protection of multi-area LSPs. Inter-area protection would be provided by means of a backup LSP using different Area Border Routers (ABRs) than the primary LSP. Van den Bosch et al. Informational - Expires January 2003 4 Further considerations for FA-LSPs July 2002 In addition, this would require a fast failure detection and notification mechanism for the FA-LSP. Another interworking aspect is related to the re-routing of backup LSPs with local protection techniques. This might be interesting for resource sharing between backup paths or between primary and backup paths. A mechanism for providing feedback about downstream detour LSPs is proposed in [5] and can potentially find a use for FA-LSP as well. 2.5. Traffic engineering attributes of FA-LSPs It is not clear how the TE attributes (defined as Sub-TLVs of the Opaque LSA TE-Link TLV), such as link color (aka resource class) and metric, of a FA-LSP should be set. The current specification [2], for instance, proposes to treat FA-LSP as uncolored links. This may create ambiguity with local policy decisions. It may also hinder the efficient establishment of LSPs with resource requirements over FA- LSPs. In general, we want the following functionality to be available: Include-Any: represents a set of resource classes, at least one of which, the links in the path taken by the FA-LSP MUST contain. Include-All: represents a set of resource classes, all of which, the links in the path taken by the FA-LSP MUST contain. Exclude-All, represents a set of resource classes, all of which, the links in the path taken by the FA-LSP MUST not contain. Note: Include-Any can be rephrased as Exclude-All with appropriate changes to the list of resource classes. Hence, we need a solution for Exclude-Any and Include-All. Moreover, since the maximum reservable bandwidth can be larger than the real Maximum LSP bandwidth for each region to which the interface belongs, the per-region allocation of the over- provisioning capacity is unknown making over-provisioning (by default) a cross-region process. As such one can assume that this capacity can be shared by all PSC regions. Note: the bandwidth of the FA-LSP must be at least as big as the LSP that induced it, but may be bigger if only discrete bandwidths are available for the FA-LSP. 3. A Step Further As a matter of fact, the FA concept is more than mature to achieve a first set of features, we propose here to enlarge the scope to achieve better scalability in (G)MPLS-TE networks keeping in mind the trade-off between functionality and complexity. Van den Bosch et al. Informational - Expires January 2003 5 Further considerations for FA-LSPs July 2002 3.1. A new resource class sub TLV The traffic engineering attributes for a FA-LSP are described in [2], according to the sub-TLV structure defined in [6]. It is mentioned in [2] that the default behavior of a FA-LSP (no resource class) may be overridden by local policy. In the example of Figure 1, the links may be one or more of five resource classes: Gold (G), Silver (S), Bronze (B), Owned (O) and Leased (L). [R6]---S,O---[R7]---S,O---[R8] | | S,O B,O | | [R1]---G,O---[R2]---G,O---[R3]---G,L---[R4]---G,O---[R5] Figure 1. Resource class definition Suppose [R2]-[R3]-[R4] has been made into a FA-LSP. If the default value (no resource class) is overridden, the operator has two options: include the union or the largest common denominator of all resource classes on any of the links of the FA-LSP. The former approach would cause {G,L,O} to be announced as resource class. Not only would this be meaningless semantically in this case, it also causes problems when setting up an LSP specifying 'include O'. Such an LSP would be allowed to use the FA-LSP, even though it passes a link which is not 'Owned'. In the latter case, {G} would be announced as resource class which would cause a problem during the setup of an LSP specifying 'exclude Leased'. Such an LSP would incorrectly be allowed to use the FA-LSP. As a solution to this problem, we propose the introduction of an additional resource class sub TLV, sub TLV 10, in [6]. 10 - Exclude resource class/color (4 octets) with exactly the same format as sub TLV 9. 9 - Resource class/color (4 octets) The application of the new sub TLV would be as following: 1. sub TLV 10 can only be present together with sub TLV 9 2. If both are present, sub TLV 9 MUST be used for resource class operations with 'include' lists. In case of an FA-LSP, it must therefore be the result of an AND operation on the resource class bit masks of all links of the FA-LSP. Sub TLV 10 MUST be used for resource class operations with 'exclude' lists and must therefore be constructed by means of an OR operation on the bit masks of all links of an FA-LSP. 3. If only sub TLV 9 is present, it can be used both for 'include' and 'exclude' list operations. This allows for backward compatibility. Van den Bosch et al. Informational - Expires January 2003 6 Further considerations for FA-LSPs July 2002 4. Security Considerations The approach outlined in this document poses no new security problems. Van den Bosch et al. Informational - Expires January 2003 7 Further considerations for FA-LSPs July 2002 References 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 K. Kompella, Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", work in progress, draft-ietf-mpls-lsp-hierarchy-06.txt 3 S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC2119. 4 P. Pan, Ed. , D. Gan, G. Swallow, J. Vasseur, D. Cooper, A. Atlas, M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels," work in progress, draft-ietf-mpls-rsvp-lsp-fastreroute-00.txt 5 S. De Cnodder, R. Cetin, S. Van den Bosch, A. Atlas, "Backup Record Route for Fast Reroute Techniques in RSVP-TE," work in progress, draft-decnodder-mpls-ero-rro-fastreroute-00.txt 6 Katz, D., Yeung, D., Kompella, K., "Traffic Engineering Extensions to OSPF", work in progress, draft-katz-yeung-ospf- traffic-06.txt Acknowledgments The authors wish to thank Stefaan De Cnodder for his comments on the draft. Author's Addresses Sven Van den Bosch (Alcatel) Francis Wellesplein 1 Phone: 32-3-240-8103 B-2018 Antwerpen Email: sven.van_den_bosch@alcatel.be Belgium Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1 Phone: 32-3-240-8491 B-2018 Antwerpen Email: dimitri.papadimitriou@alcatel.be Belgium Van den Bosch et al. Informational - Expires January 2003 8 Further considerations for FA-LSPs July 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Van den Bosch et al. Informational - Expires January 2003 9