CCAMP Working Group D. Cheng (Polaris Networks) Internet Draft Expiration Date: September 2002 OSPF Extensions to Support Multi-Area Traffic Engineering draft-cheng-ccamp-ospf-multiarea-te-extensions-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract The [MULTI-AREA] introduces a set of mechanisms that could be used to construct LSPs that span multiple IS-IS/OSPF areas, where one scenario is to allow the head-end LSR to compute the path all the way to the ABR in the tail-end area. This document proposes some new OSPF extensions that can be used in supporting that scenario, i.e., by leaking some of the useful information from individual areas to others, the constraint-based routing at the head-end LSR of LSPs in OSPF networks with multiple areas can be optimized. Table of Contents 1.0 Introduction ............................................... 2 2.0 Applicability .............................................. 2 3.0 OSPF Routing Enhancements ................................... 3 3.1 Area Sub-TLV ............................................... 3 3.2 Address TLV ................................................. 3 3.2.1 Address Sub-TLV ........................................... 4 3.3 Inter-ABR TE Link TLV ....................................... 4 3.3.1 Peer ABR Sub-TLV .......................................... 4 4.0 Scope and Mechanisms for Advertising......................... 5 4.1 Option 1: AS-Wide Advertising ............................... 5 4.2 Option 2: Per-Area and On-Demand Advertising ................ 5 4.3 Option 3: Per-LSR and On-Demand Advertising ................. 6 5.0 Security Considerations ..................................... 6 6.0 Acknowledgements ............................................ 6 7.0 References .................................................. 6 8.0 Author's Address ........................................... 6 [Page 1] 1.0 Introduction This document specifies additional traffic engineering parameters and their formats that could be used to support constraint-based routing for GMPLS LSP across multiple areas in OSPF networks. Currently there already exist extensions to OSPF to support traffic extensions in MPLS and GMPLS networks, as documented in [OSPF-TE] and [GMPLS-OSPF]. However, in OSPF networks with multiple areas, it is sometimes desirable to obtain traffic parameters from other areas so that the head-end LSR in one area may be able to select an optimized path toward the tail-end LSR across OSPF area boundary. There are a number of practical ways to perform routing across OSPF area boundary in GMPLS networks as documented in the [MULTI-AREA]. The extensions as proposed in this document may be used in support some of the scenarios as described in that document. This document proposed the following TLVs as extensions to GMPLS-OSPF: 1) Top level TLV - Address TLV, type 3 2) Sub-TLV - Area Sub-TLV, type 17 3) Sub-TLV - Address Sub-TLV, type 18 4) Sub-TLV - Peer ABR Sub-TLV, type 19 2.0 Applicability To establish and maintain MPLS/GMPLS LSPs that span multiple OSPF areas, one may wish to let the head-end of a LSP to calculate an optimal or near-optimal path from itself all the way to the entry ABR of the destination area where the tail-end LSR resides. Note the portion of the LSP that is outside of the source area where the head-end LSR resides most likely contains loose hops. In particular, it may be practical to let these loose hops be a list of concatenation of ABRs in the same OSPF domain, i.e., exit ABR of the source area, the entry and exist ABRs of the area that the LSP needs to traverse, and finally the entry ABR of the destination area. To support the routing calculation for LSPs that span multiple OSPF areas at the head-end LSR, additional information in areas other than the source area needs to be made known to the head-end LSR. In this document, two pieces of additional information are specified. First, the destination area needs to be known by the head-end LSR. Note currently in the OSPF networks, area information is not included in the advertisements of reachable addresses/subnets, using type-3 or type-5 LSA. Second, the topology of the inter-connectivity of the ABRs in the OSPF domain, or a subset of such, along with the traffic parameters, needs to be made known to the head-end LSR. Note this inter-connectivity is in abstract context. [Page 2] With the two pieces of information, the head-end LSR may then find and optimize the LSP from itself to the entry ABR of the destination area. 3.0 OSPF Routing Enhancements In this section we define some additional TE parameters that may be used to support constraint-based routing in OSPF networks with multiple areas. These TE parameters are carried using the format of Type/Length/Value (TLV), which is consistent with those already specified in the [OSPF-TE] and [GMPLS-OSPF]. 3.1 Area Sub-TLV The Area sub-TLV specifies the Area ID of an OSPF area where a set Of IP addresses and subnets included in an Address TLV (see the Section 3.2) belong to, or an inter-ABR TE link belong to (see the Section 3.3). The format of the Area sub-TLV is as follows: 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 (17) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OSPF Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.2 Address TLV The Address TLV specifies a set of reachable IP addresses or/and IP subnets and the OSPF area that they belong to. The Address TLV is a top-level TLV and contains a single Area sub-TLV and one or more Address sub-TLVs. Each Address sub-TLV contains one or more IP addresses or/and IP subnets and the Area sub-TLV specifies the Area ID of the OSPF area where these IP addresses and subnets belong to. The Address TLV is advertised by an ABR. Its format is as the follows: 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 (3) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [Page 3] 3.2.1 Address Sub-TLV The Address sub-TLV specifies one or more IP addresses or subnets that belong to an OSPF area as indicated by the Area sub-TLV. The format of the Address sub-TLV is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-type (18) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr_length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address or Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Address or Subnet | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Addr_length specifies the length of the IPv4 address specified in number of bits, and it applies to all IP addresses and subnets included in the same Address sub-TLV. 3.3 Inter-ABR TE link TLV The inter-ABR TE link TLV specifies a regular OSPF TE link as exactly defined in the [GMPLS-OSPF] with two additional sub-TLVs as follows: 1) the Area sub-TLV (see the Section 3.1). 2) the peer-ABR sub-TLV (see the Section 3.3.1) For the inter-ABR TE link TLV, the above two sub-TLVs are mandatory. An inter-ABR TE link describes a GMPLS TE link between two ABR in the same OSPF area in abstract context. The Address TLV is advertised by an ABR. 3.3.1 Peer-ABR Sub-TLV The peer ABR Router ID sub-TLV specifies the Router ID of the peer end of the inter-ABR TE link. Note the local end is identified by the advertising Router ID included in the LSA header. The two Router IDs identify the two ABRs as two endpoint of the TE link and the information contained in the Area sub-TLV specifies the area where the TE link is in. [Page 4] The format of the peer ABR Router ID sub-TLV is as follows: 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 (19) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ABR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.0 Advertising Scope and Related Mechanisms There always exists a tradeoff between the amount of the routing information that needs to be passed around and the degree of routing optimization. In order to be flexible enough to meet different routing requirements in MPLS/GMPLS networks, this document does not limit to a single scope and mechanism for the advertising of the additional routing information as described in the Section 3. The following sections describe some of the practices in distributing the additional routing information, but does not preclude others. 4.1 Option 1: AS-Wide Advertising The ABR always advertises the routing information belong to each of the areas that it attached as described in the Section 3.0 unconditionally using type-11 opaque LSA throughout the entire OSPF domain where the ABR belongs to. With this option, all routers in the same OSPF domain have to store and maintain the additional routing information, but any router can use these information to calculate LSPs that across multiple OSPF areas with better optimization. 4.2 Option 2: Per-Area and On-Demand Advertising In this scenario, the ABR only advertises the additional routing information that belong to a non-backbone area unconditionally to the backbone area using type-10 opaque LSA. If any non-backbone area wishes to have the additional routing information as described in the Section 3.0, one or more ABRs in that area will then re-advertise the information that is available in the backbone area into that area. All these advertisements use type-10 opaque LSA. The on-demand advertising may be triggered by a configuration option from the network management system. With this option, the additional routing information only needs to be injected into individual areas that requesting for them. [Page 5] 4.3 Option 3: Per-LSR and On-Demand Advertising This scenario is similar to the one as described in the Section 4.2, except that the on-demand advertising is based on individual LSRs that actually wishe to obtain and maintain the additional routing information. To accomplish the per-LSR based advertising on-demand, a special communication channel is required between the head-end LSR and an an ABR in the same area. A GRE tunnel may be used in this case. The type-9 opaque LSA is used to carry the routing information. 5.0 Security Considerations Security issues are not discussed in this document. 6.0 Acknowledgements Suggestion of using GRE tunnels for obtaining additional routing information (Section 4.3) was taken from Yakov Rekhter and is appreaciated. 7.0 References [MULTI-AREA] "Multi-area MPLS Traffic Engineering", draft-kompella-mpls-multiarea-te-02.txt, work in Progress. [OSPF-TE] "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-04.txt, work in Progress [GMPLS-Routing] "Routing Extensions in Support of Generalized MPLS", draft-ietf-ccamp-gmpls-routing-01.txt, work in progress. [GMPLS-OSPF] "OSPF Extensions in Support of Generalized MPLS", draft-ietf-ccamp-ospf-gmpls-extensions-04.txt 8.0 Authors' Addresses Dean Cheng Polaris Networks Inc. 6810 Santa Teresa Blvd. San Jose, CA 95119 Phone: +1 408 284 8061 Email: dcheng@polarisnetworks.com [Page 6]