OSPF W. Lu Internet-Draft Ericsson Intended status: Standards Track July 9, 2011 Expires: January 10, 2012 OSPF TE Extension for Area IDs draft-lu-ospf-area-tlv-01 Abstract For multi-area path computation, it is desirable to have knowledge of area boundaries and the corresponding border routers which are capable of processing inter-area TE traffic. This memo defines a TLV to the OSPF TE extensions to meet such need. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 10, 2012. 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. Lu Expires January 10, 2012 [Page 1] Internet-Draft OSPF TE Extension for Area IDs July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Current Solutions . . . . . . . . . . . . . . . . . . . . 3 1.2.1. Global TED . . . . . . . . . . . . . . . . . . . . . . 3 1.2.2. Stitch . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2.3. Crankback . . . . . . . . . . . . . . . . . . . . . . 4 1.2.4. Distributed Path Computation . . . . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.4. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Exit Area . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. TE-ABR . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. The importance of ABR whereabouts . . . . . . . . . . . . 6 3.2. Topic not Yet Addressed . . . . . . . . . . . . . . . . . 6 3.3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Scope of the proposal . . . . . . . . . . . . . . . . . . . . 7 5. Area ID TLV . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. TLV Origination Point . . . . . . . . . . . . . . . . . . 8 5.2. TLV encoding . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Use-Case 1 . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1.1. Crankback approach . . . . . . . . . . . . . . . . . . 10 6.1.2. BRPC approach . . . . . . . . . . . . . . . . . . . . 10 6.2. Use-Case 2 . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Lu Expires January 10, 2012 [Page 2] Internet-Draft OSPF TE Extension for Area IDs July 2011 1. Introduction 1.1. Background Traffic Engineering (TE) based networks are widely used by network operators. The provision and setup mechanisms work fine in a single IGP area thanks to the well defined TE extensions to the corresponding protocols, namely RSVP-TE [RFC3209], OSPF-TE [RFC3630], and ISIS-TE [RFC3784]. From the single area TE database, LSPs can be derived to meet various TE constraints using some Path Computation Element (PCE) methods such as CSPF. The mechanisms however cannot be applied directly to multi-area networks, for which the path computation is one of the key applications of the PCE-based architecture [RFC4655]. It is highly desirable to compute inter-area shortest paths that satisfy some bandwidth constraints or any other constraints, with little manual intervention, as is possible within a single IGP area. 1.2. Current Solutions Listed below are a few existing inter-area path computation mechanisms. As can be seen the ABR whereabouts are indispensable in computing inter-area LSPs. 1.2.1. Global TED A single TE database that contains all TE information of each and every area/domain is called the global TED. This certainly makes it easy to compute shortest path LSPs that meet all constraint requirements. The drawbacks nevertheless are apparent: a. IGP hierarchy enables improved IGP scalability by dividing the IGP domain into areas and limiting the flooding scope of topology information to within area boundaries. The global TED goes against this principle. b. Even if one is willing to compromise this principle, the LSPs created upon this global TED would lack of area information which may be required for enforcing path selection policies. 1.2.2. Stitch This method uses per-area path computation based on ERO expansion on the head-end LSR and on ABRs. ABRs can be selected through either: Lu Expires January 10, 2012 [Page 3] Internet-Draft OSPF TE Extension for Area IDs July 2011 a. Static configuration of ABRs as loose hops at the head-end LSR; b. Dynamic ABR selection - Proprietary, knowledge of ABRs may be aquired through non-standard protocol modification. 1.2.3. Crankback Crankback method defined in [RFC4920] allows an LSP to be constructed to beyond the area scope provided some intermediate nodes, i.e. ABRs, are known. Crankback can probe the ABRs one after another till a viable path is found if it exists. Note that this method does not allow computing an optimal path but just a feasible path. It may also have some non-negligible setup delay. These issues nevertheless are beyond the scope of this document. 1.2.4. Distributed Path Computation PCE architecture document [RFC4655] outlines a distributed PCE architecture. The idea is that various PCEs which have partial information of the topologies work together to conclude the best paths that meet the computation constraint requirements. Individual PCEs may not have any visibility beyond the areas they are servicing. For inter-area path computation purpose, the knowledge of ABRs are essential for the neighboring PCEs to find out the overall best path over the combined areas. BRPC as defined in [RFC5441] provides one of such methods. OSPF-CAP [RFC5088] on the other hand defines methods to make known distributed PCEs using OSPF capability TLVs. Note that although [RFC5088] contains PCE-DOMAIN sub-TLV for OSPF Area ID, it however cannot be used for identifying area border LSRs. It is for locating PCEs, not LSRs. 1.3. Requirements Language 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 [RFC2119]. 1.4. Acronyms Lu Expires January 10, 2012 [Page 4] Internet-Draft OSPF TE Extension for Area IDs July 2011 ABR - Area Border Router BRPC - Backward-Recursive Path Computation CSPF - Constrained Shortest Path First IGP - Interior Gateway Protocol LSA - Link State Advertisement LSDB - Link-State DataBase LSP - Label Switched Path LSR - Label Switching Router OSPF - Open Shortest Path First PCC - Path Computation Client PCE - Path Computation Element TE - Traffic Engineering TED - Traffic Engineering Database TLV - Type Length Value VSPT - Virtual Shortest Path Tree 2. Definitions The following definitions are under the context where TE is enabled. 2.1. Exit Area A neighboring OSPF area to which an inter-area path can possibly be extended is called Exit Area. The ABR which connects the current area to an Exit Area is called exit ABR. 2.2. TE-ABR An exit ABR is also referred to as TE-ABR. Lu Expires January 10, 2012 [Page 5] Internet-Draft OSPF TE Extension for Area IDs July 2011 3. Motivation 3.1. The importance of ABR whereabouts All solutions listed in Section 1.2, except the global TED approach, have to use the knowledge of exit ABRs to accomplish their inter-area path computation tasks. Some methods require manual configuration which is costly and error prone. Others may have to use proprietary means to acquire the information. It is desirable to have the exit ABR information available and make it conveniently accessible to the relevant PCEs without adding lot of complexity to the protocols nor too much burden to the participating routers. 3.2. Topic not Yet Addressed Apart from the manual provision, currently the exit ABR information is difficult to acquire. The reasons are: 1. OSPF TE Database (TED) does not contain information on exit ABRs; 2. CSPF operates on the TED and is therefore limited to the information the latter provides. Unless the critical information of the exit ABRs becomes available, the CSPF cannot operate optimally by seeing beyond the area scope. 3. One may argue that CSPF can dig into OSPF's other repositories, such as LSDB, to find out the ABR whereabouts. This is not advisable because it negates the purpose of keeping TED opque and independent from the normal OSPF operation. This is also technically difficult because usually CSPF and OSPF are two different processes that they may not be running in the same nodes. 4. Even if one is willing for CSPF to intrude into OSPF space, and use the ABR bit (B bit) information for locating border routers, these ABRs are not necessarily the exit ABRs. In other words, even if CSPF learns which routers sit on area borders, it is still unable to ascentain whether the ABRs are supporting TE on the other side of the borders. OSPF's hierarchical design limits the topology sharing to within area boundaries. 5. And even if one is willing to jump across this limit and somehow manages to aquire the ABRs' TE ability onto other areas, there is still the need for one more key information, the Area IDs. Lu Expires January 10, 2012 [Page 6] Internet-Draft OSPF TE Extension for Area IDs July 2011 6. The Area IDs are critical to the distributed PCE architecture. They are essential in enforcing path computation area sequences and PCE policies. They are also useful for consolidating path computation jobs. Section 6.2 provides an example of ABR consolidation. 7. It is important to understand that the proposed TLV also implies TE capabilities. In other words the TLV signifies that the advertising router is not only an ABR, but also an LSR capable of handling TE traffic. Unless tied with TE knowledge, methods of discovering of ABRs will not be useful in locating TE-ABRs, i.e. the LSRs that can transit TE traffic across areas. 8. At last, since the TLV is TE based, it should be defined in the OSPF TE extensions and maintained similarly with its counterparts, Router Address TLV and Link TLV. 3.3. Benefits The benefits of having an OSPF Area ID TLV are listed below: 1. It fits into OSPF TE architecture, preserves the protocol's hierarchy, and adds little burden to the OSPF process; 2. It automates the TE-ABR discovery, and eliminates the need of manual provisioning; 3. Very often an LSR is also a PCE. If this LSR is also an ABR, it can compute a two-area LSP effortlessly. The PCC only needs to send the request to one TE-ABR (if there are multiple TE-ABRs sharing the same border), provided it has knowledge of the TE-ABR whereabouts. 4. Scope of the proposal This document describes solutions for inter-area path computation and does not address inter-domain scenarios. It is also specific to OSPF as an IGP protocol, though the concepts apply to ISIS which are to be defined in a separate document. 5. Area ID TLV [RFC3630] section 2.4 defines two TLVs. This memo adds a third TLV called the Area ID TLV. Lu Expires January 10, 2012 [Page 7] Internet-Draft OSPF TE Extension for Area IDs July 2011 5.1. TLV Origination Point The Area ID TLV is originated and maintained by TE-ABR routers. The TLV is encoded in an OSPF TE LSA which is an area-opaque LSA, and handled the same way as the TE-LINK TLV and TE-ROUTER-ADDRESS TLV. This TLV is flooded throughout and within the originating area. ----------------- --------- | || | | ABR1 | | Area0 || Area1 | | ABR2 | | | ========= | || | | || Area2 | | || | ====ABR4========ABR3======== | || | | Area4 || Area3 | | || | ----------------- --------- Figure 1: TLV Origination In Figure 1 for example, it is assumed all ABRs and areas are TE enabled. For ABR1 and ABR2, since they sit between Area0 and Area1, both will originate an Area ID TLV concerning Area1 and flood it into Area0, and vice versa. Likewise, ABR3 will originate a TLV covering Area2, Area3, and Area4, and flood it into Area0, and so on for Area2, Area3 and Area4. Lu Expires January 10, 2012 [Page 8] Internet-Draft OSPF TE Extension for Area IDs July 2011 5.2. TLV encoding 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 | Len | Area-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area-ID (Cont) | Another Area-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Another Area-ID (Cont) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | More Area-IDs | | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: TLV Format Type The Area ID TLV consists of a 1-octet type value which will be allocated by the IANA (suggested value 3). Len 1-octet unsigned integer value 4xN to represent N exit areas, not including the originating area. Value The value fields contains one or more Area IDs. Each Area ID is a four-octet OSPF Area ID associated with an exit area for which the ABR has TE enabled. An ABR may connect to multiple areas. Therefore it may generate 1 TLV with N IDs, where N is the total number of exit areas, not including the originating area. Since the Len field is of 1-octet, this TLV can hold upto 63 IDs. For non-ABR routers this Area-ID TLV SHOULD not occur. 5.3. Example Consider Figure 1 again. Router ABR3 connects to four areas Area0, Area2, Area3, and Area4. Assuming all ABRs and areas are TE enabled except Area4 which is not TE-enabled. ABR3 originates and floods following Area-ID TLVs as shown in Figure 3, assuming type is 3. Lu Expires January 10, 2012 [Page 9] Internet-Draft OSPF TE Extension for Area IDs July 2011 ========================================== |To |Type| Len|Area-IDs ...| ------------------------------------------ |Area0 | 3| 8|0 0 0 2|0 0 0 3| |Area2 | 3| 8|0 0 0 0|0 0 0 3| |Area3 | 3| 8|0 0 0 0|0 0 0 2| |Area4 | None | ========================================== Figure 3: Sample TLV 6. Applications 6.1. Use-Case 1 ---------- --------- ---------- | || || | | ABR1 ABR3 | | H || T || | | ABR2 || | | Area1 || Area0 || Area2 | | || || | ---------- --------- ---------- Figure 4: Use-Case 1 The topology is shown in Figure 4. The headend "H" is in Area1. The tailend "T" is in Area0. LSRs are running OSPF-TE and RSVP-TE. 6.1.1. Crankback approach The crankback method requires a list of ABRs for tryout. The list usually has to be provisioned manually. With the proposed Area-ID TLVs, the ABR information is made available through the OSPF TE database. Therefore "H" learns the ABR list dynamically from its OSPF TED, which is ABR1 and ABR2. "H" starts the crankback procedure with "ABR1" from which it reaches "T". The LSP thus is established successfully, though not necessarily optimal. 6.1.2. BRPC approach With the method defined in [RFC5441], the VSPT has to be first built from "T" in Area0. Given that the area sequence is Area0->Area1, the initial VSPT has the candidate exit ABRs ABR1, ABR2, and ABR3. Lu Expires January 10, 2012 [Page 10] Internet-Draft OSPF TE Extension for Area IDs July 2011 Now with the proposed OSPF Area ID TLVs the PCE of Area0 knows that ABR3 connects Area2, not Area1, therefore ABR3 is not considered as an exit ABR. Subsequently the PCE of Area1 takes the VSPT passed by the PCE of Area0 as input and concludes the end-to-end path computation. 6.2. Use-Case 2 Very often an LSR is also a PCE. In that case, the Area ID TLVs can make the path computation job more efficient. ----------- ----------- | || | | ABR1 Area1 | | H || | | ABR2 T | | Area0 || | | ABR3 | | | ----------- | || | | ABR4 Area2 | | || | ----------- ----------- Figure 5: Use-Case 2 As shown in Figure 5, if the headend "H" knows that the tailend "T", or some intermediate node to reach, is in Area1, it sends a PCReq to one of the ABRs that connect to Area1. The draft proposal makes the ABR list conveniently available, which is [ABR1, ABR2, ABR3]. Note that ABR4 is not listed since it is not an exit ABR to Area1. Assuming by some local policy ABR1 is chosen. Since ABR1 sits across Area0 and Area1, it has visibility to TEDs of both areas. ABR1 which is also a PCE performs the path computation job in the same way as an intra-area path computation. Note that the resulting path, if existent, does not necessarily go through ABR1. It can be for example H->ABR3->T. Note also that the ABR selection is a local decision. One can use some criteria, for example the highest te-router-id, to select the ABR. However, the candidate ABRs have to share the common border such as the one between Area0 and Area1. This can be achieved by grouping ABRs according to their exit Area IDs in the proposed OSPF Area ID TLVs. Lu Expires January 10, 2012 [Page 11] Internet-Draft OSPF TE Extension for Area IDs July 2011 7. Acknowledgements The author would like to thank Sriganesh Kini, Meral Shirazipour, and Dimitri Papadimitriou for their reviews and comments. 8. IANA Considerations This document defines the following TLV to the OSPF TE Extensions under TE LSA: +-------------------+-------------+---------------+ | Type | Name | Source | +-------------------+-------------+---------------+ | TBD (recommend 3) | Area ID TLV | This document | +-------------------+-------------+---------------+ 9. Security Considerations There are no specific security considerations within the scope of this document. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 10.2. Informative References [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. [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004. [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for Lu Expires January 10, 2012 [Page 12] Internet-Draft OSPF TE Extension for Area IDs July 2011 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. [RFC4920] Farrel, A., Satyanarayana, A., Iwata, A., Fujita, N., and G. Ash, "Crankback Signaling Extensions for MPLS and GMPLS RSVP-TE", RFC 4920, July 2007. [RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5441] Vasseur, JP., Zhang, R., Bitar, N., and JL. Le Roux, "A Backward-Recursive PCE-Based Computation (BRPC) Procedure to Compute Shortest Constrained Inter-Domain Traffic Engineering Label Switched Paths", RFC 5441, April 2009. Author's Address Wenhu Lu Ericsson 300 Holger Way San Jose, California 95134 USA Phone: 408 750-5436 Email: wenhu.lu@ericsson.com Lu Expires January 10, 2012 [Page 13]