CCAMP Working Group Dean Cheng Internet Draft Polaris Networks Expires: August 2003 February 2003 OSPF Extensions to Support Multi-Area Traffic Engineering draft-cheng-ccamp-ospf-multiarea-te-extensions-01.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 TE Extensions to Multi-Area OSPF Routing ...................... 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 ............................................. 5 4.0 TE Advertisements and their Advertising Scope .................. 5 4.1 Option 1:Area TE LSA Advertised throughout a Single OSPF Domain . 5 4.2 Option 2:Area TE LSA Advertised per-Area and per-Configuration .. 6 4.2.3 TE Advertisements from OSPF Backbone to Non-Backbone Area ..... 6 4.2.3.1 Option 2-1: Per-Area and On-Demand Advertising .............. 6 4.2.3.2 Option 2-2: Per-LSR and On-Demand Advertising ............... 7 5.0 Security Considerations ........................................ 7 6.0 Acknowledgements ............................................... 7 [Page 1] 7.0 References ..................................................... 7 7.1 Formative References ........................................... 7 7.2 Informative References ......................................... 7 8.0 Author's Address .............................................. 7 1.0 Introduction This document specifies additional traffic engineering parameters and their formats that could be used to support constraint-based routing for MPLS/GMPLS LSPs 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]. In OSPF networks with multiple areas, only reachability information may be exchanged between OSPF areas per [OSPF]. There are a number of practical ways to perform routing with traffic engineering across OSPF area boundary in MPLS/GMPLS networks as documented in the [MULTI-AREA]. One desirable practice is to obtain traffic engineering information from other areas so that the head-end LSR in the source area may select an optimized or "intelligent" path towards the tail-end LSR across OSPF area boundaries. In traditional OSPF networks, IP traffic across multiple areas is generally sent to the ABRs based on the cross-area reachability information advertised by the ABRs. This document proposes that for MPLS/GMPLS LSPs across multiple OSPF areas with traffic engineering requirements, the TE links as defined in the [OSPF-TE] and [GMPLS-OSPF] may be constructed between ABRs within each area and then advertised to other areas, along with other required information, which can then be used in the constraint-based routing in the path selection procedure at the head-end LSR. This document proposed the following TLVs as extensions to OSPF-TE and GMPLS-OSPF: 1) Top level TLV - Address TLV, type 3 (TBD) 2) Sub-TLV - Area Sub-TLV, type 17 (TBD) 3) Sub-TLV - Address Sub-TLV, type 18 (TBD) 4) Sub-TLV - Peer ABR Sub-TLV, type 19 (TBD) 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. Note in such a scenario, the entry ABR of all the areas (except [Page 2] the source area) needs to expand the loose hops to strict hops using the link-state based OSPF routing and traffic engineering database within the associated 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 or the source area. 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 (refer to the [OSPF]). Second, the topology of the inter-connectivity of the ABRs in the OSPF domain, or a subset of such, along with the traffic parameters, need to be made known to the head-end LSR. Note this inter-connectivity is in abstract context. 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 TE Extensions to Multi-Area OSPF Routing 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 ID Sub-TLV The Area ID 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 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 (17 - TBD) | 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 ID [Page 3] 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 - TBD) | Length (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : | // : // | : | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address Sub-TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 ID 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 - TBD) | 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) [Page 4] 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 Inter-ABR TE link is advertised by an ABR. 3.3.1 Peer-ABR Router ID 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. 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 - TBD) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer ABR Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.0 TE Advertisements and their Advertising Scope To allow the head-end LSR to compute a MPLS/GMPLS LSP across multiple OSPF areas, traffic engineering information as described in the Section 3.0 needs to be advertised and made known to the head-end LSR, in addition to the classical routing information per [OSPF]. The TE advertisements related to multiple areas are as the following using the formats as described in the Section 3.0: 1) The OSPF Area ID of the IPv4 addresses and subnets that are reachable through the advertising ABRs in their home area. 2) The TE links between the ABRs within this area. There always exists a tradeoff between the amount of the routing information that needs to be passed around and the availability of the routing information in other areas that may be used to compute the path across the area boundary. This document proposes a flexible mechanism to satisfy different requirements and applications in MPLS/GMPLS networks as described in the following. 4.1 Option 1:Area TE LSAs Advertised throughout a Single OSPF Domain The TE advertisements as described in the Section 4.0 can always be generated by ABRs in each of the OSPF areas including the backbone and non-backbone areas with the LSA type as 11 (see [OSPF-OPAQUE]), and as a result, these advertisements will be flooded throughout the entire OSPF domain. [Page 5] The information contained in these advertisements can then be used for computing LSPs that across OSPF area boundaries at the head-end LSR. 4.2 Option 2:Area TE LSAs Advertised per-Area and per-Configuration With this option, the backbone area always generates its area TE LSAs; a non-backbone area may only generate its area TE LSAs if configured to do so, and the area TE LSAs from a non-backbone area is only advertised to the backbone area. The collection of the area TE LSAs that maintained within the OSPF backbone area may only be advertised to individual non-backbone area or individual LSR if configured to do so. 4.2.1 TE Advertisements in the OSPF Backbone Area The ABRs in the OSPF backbone area always adveritse the additional opaque TE information as above. The type-10 opaque LSA is used per [OSPF-OPAQUE]. After the advertising, the information may be adveritised to non-backbone areas or individual LSRs subject to the configuration. 4.2.2 TE Advertisements from OSPF Non-Backbone to Backbone Area The ABRs in a non-backbone area may choose to advertise or not to advertise the additional opaque TE information to the backbone area. If choose to advertise, the type-10 opaque LSA is used in the backbone area per [OSPF-OPAQUE]. After the advertising, the information will be available in the OSPF backbone area, and then they may be advertised to other non-backbone areas or individual LSRs subject to the configuration. 4.2.3 TE Advertisements from OSPF Backbone to Non-Backbone Area The collection of area TE advertisements as described in the Section 4.2.1 and the Section 4.2.2 that are maintained in the backbone area may be further advertised to other non-backbone areas or individual LSRs with different options as described below. 4.2.3.1 Option 2-1:Per-Area and On-Demand Advertising If any non-backbone area wishes to have the additional TE routing information from other areas, one or more ABRs in that area can re-advertise the information that is available in the backbone area throughout 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 6] 4.2.3.2 Option 2-2:Per-LSR and On-Demand Advertising This scenario is similar to the one described in the Section 4.2.3.1, except that the on-demand advertising is based on individual LSRs that actually wishes to obtain and maintain the additional TE routing information. To accomplish the per-LSR based advertising on-demand, a special communication channel is required between the LSR and 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.2.3.2) was taken from Yakov Rekhter and is appreaciated. 7.0 References 7.1 Normative References 123456789012345678901234567890123456789012345678901234567890123456789012 [OSPF] RFC 2328, "OSPF Version 2" [OSPF-OPAQUE] RFC 2370, "The OSPF Opaque LSA Option" [MULTI-AREA] "Multi-area MPLS Traffic Engineering", work in Progress. [OSPF-TE] "Traffic Engineering Extensions to OSPF", work in Progress [GMPLS-OSPF] "OSPF Extensions in Support of Generalized MPLS", work in progress. 7.2 Informative References [GMPLS-Routing] "Routing Extensions in Support of Generalized MPLS", work in progress. 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 7]