Network Working Group Z. Li Internet-Draft L. Zhang Intended status: Experimental Y. Liu Expires: August 22, 2013 Huawei Technologies February 18, 2013 OSPF Extensions for Automatic Computation of MPLS Traffic Engineering Path Using Traffic Engineering Layers and Areas draft-li-ospf-auto-mbb-te-path-00 Abstract As the network scale expands, especially in the mobile backhaul network, automatic computation of MPLS Traffic Engineering (TE) path becomes very important. But owing to requirements on the MPLS TE path, explicit path or affinity property has to be introduced for the path computation. This causes the complexity of MPLS TE path design. The document proposes an architecture and corresponding OSPF extensions to improve automation on computation of MPLS TE path. MPLS TE networks are divided into different traffic engineering layers and areas according to the characteristics of the network topology. MPLS TE path can compute automatically based on traffic engineering layers and areas to satisfy major requirements to bear mobile network services. 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]. 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 August 22, 2013. Li, et al. Expires August 22, 2013 [Page 1] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 Copyright Notice Copyright (c) 2013 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Mobile Backhaul Network and Service Deployment . . . . . . 3 2.2. Weakness of Existing MPLS TE Path Computation . . . . . . 4 3. Architecture of MPLS TE Auto Path Computation . . . . . . . . 6 3.1. Concept of TL and TA . . . . . . . . . . . . . . . . . . . 6 3.2. TL and TA Information Flooding . . . . . . . . . . . . . . 8 3.3. Enhanced CSPF Algorithm Based on TL and TA . . . . . . . . 8 3.3.1. An Example of Enhanced CSPF Algorithm Based on TL and TA . . . . . . . . . . . . . . . . . . . . . . . . 9 4. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. OSPF TA TLV and TL TLV Format . . . . . . . . . . . . . . 10 4.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 11 4.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Li, et al. Expires August 22, 2013 [Page 2] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 1. Introduction As the network scale expands, especially in the mobile backhaul network, automatic computation of MPLS TE path becomes very important. Since the mobile traffic has high SLA (Service Level Agreement) requirement, MPLS TE is introduced to provide bandwidth guarantee and traffic protection. On the other hand, in order to provide traffic engineering properties, constraints such as explicit path or affinity property has to be specified for a MPLS TE tunnel. This causes that the path design is very complex. For example, when explicit path is specified for a MPLS TE tunnel in a large scale network, many hops along the MPLS TE path have to be specified. This operation is cumbersome and error-prone. In addition, if new nodes are introduced in the network, a lot of configuration of existing explicit paths has to be changed. This document proposes an architecture and corresponding OSPF extensions to improve automation on computation of MPLS TE path. MPLS TE layers and areas are introduced according to the characteristics of the network topology. MPLS TE path can compute more automatically based on MPLS TE layers and areas to reduce the operation expense greatly. 2. Problem Statement 2.1. Mobile Backhaul Network and Service Deployment Mobile multimedia devices such as smartphones are ubiquitous now which runs a wide variety of bandwidth-intensive applications and causes unprecedented growth in mobile data traffic. The huge growth is challenging legacy network infrastructure. There are two obvious solutions to cope with the growing bandwidth: -- Increase the radio wireless interface bandwidth -- Increase more cell sites: more LTE eNodeBs and associated Cell Site Gateways(CSGs) are added in the networks. This causes the network scale expands fast and has much effect on the service provision. Li, et al. Expires August 22, 2013 [Page 3] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 ---------------- / \ / \ / \ +----+ Access +----+ |CSG1| Ring 1 |ASG1|------------- +----+ +----+ \ \ / \ \ / +----+ \ +----+ |RSG1| -------------| | Aggregate +----+ |ASG2| Ring | -------------| | +----+ / +----+ |RSG2| / \ +----+ / \ / +----+ Access +----+ / |CSG2| Ring 2 |ASG3|------------- +----+ +----+ \ / \ / \ / ----------------- Figure 1 Mobile Backhaul Network The topology of mobile backhaul network is shown in the Figure 1. It usually adopts ring topology to save fiber resource and it is divided into the aggregate network and the access network. Cell Site Gateways(CSGs) connects the eNodeBs and RNC site gateways(RSGs) connects the RNCs. The mobile traffic is transported from CSGs to RSGs. The network takes a typical aggregate traffic model that more than one access rings will attach to one pair of aggregate site gateways(ASGs) and more than one aggregate rings will attach to one pair of RSGs. 2.2. Weakness of Existing MPLS TE Path Computation Since the mobile traffic has high SLA (Service Level Agreement) requirement, MPLS TE is introduced to provide bandwidth guarantee and traffic protection. As the network scale expands, automation becomes more and more important to reduce the effort of service provision. But the path design becomes complex inevitably owing to guarantee traffic engineering properties. There are following two primary requirements for MPLS TE path computation: 1. Completely disjointed primary and backup LSP Li, et al. Expires August 22, 2013 [Page 4] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 MPLS TE Hot-standby feature is introduced to implement traffic protection. That is, primary LSP and backup LSP are setup at the same time for one MPLS TE tunnel. In order to achieve higher protection, it is requires that the primary and backup LSP should not share any nodes and links. Thus when failure happens in the primary path, the backup LSP can always take over the traffic. According to current SPF(Shortest Path First) algorithm, if there is no other constraints, it may be difficult to satisfy above path computation requirement. For example, in figure 1 the primary path computed from CSG1 to RSG1 may be CSG1->ASG2->ASG1->RSG1. Since the primary path passes through both ASG2 and ASG1, the backup path cannot be disjointed completely from the primary path. In fact, it is apparent that the two completely disjointed paths exists from CSG1 to RSG1 in the figure 1. 2. Avoid passing through different access rings When the mobile traffic is transported from the CSG to the RSG, it is expected that the path would not pass through multiple access rings. Since the bandwidth of the access ring is always designed to satisfy requirement of its own, if mobile traffic from other access ring pass through, the access ring is prone to be overloaded which will cause traffic loss owing to traffic congestion. When automatic path computation is done for MPLS TE tunnels, it may be inevitable that the path will path through multiple access rings. For example, in figure 1 the primary path computed from CSG1 to RSG2 may be CSG1->ASG2->CSG2->ASG3->RSG2 instead of CSG1->ASG2->ASG3->RSG2. There are two possible solutions to satisfy requirements described above: The first one is to set reasonable link cost. For example, the cost of the key link between ASG1 and ASG2 can be set as a large value, then the primary LSP will not be calculated to pass through the key link and the backup LSP can be disjointed from the primary LSP completely. The cost of the access ring can also be larger than the aggregate ring to avoid that the traffic will pass through unexpected rings. The second one is to use explicit-path or affinity property to achieve better path design. When explicit path is used, it has to designate the exact nodes or links which the primary LSP and the backup LSP go through. When affinity property is used, it can divide different rings with different colors and the primary LSP and backup LSP can setup with different affinity property. Li, et al. Expires August 22, 2013 [Page 5] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 The two methods can satisfy the two requirements of path computation. But as we know the mobile backhaul network faces more frequent topology change than the fixed network. Adding and deleting of eNodeB will change the access ring topology and which will change the hops and cost for mobile traffic from the source to the destination. It will be very complex and time-consuming to adjust the cost for a large scale network or change explicit path or affinity property for a great deal of MPLS TE tunnels. It is necessary to propose a more automatic way to satisfy the requirements. 3. Architecture of MPLS TE Auto Path Computation 3.1. Concept of TL and TA Li, et al. Expires August 22, 2013 [Page 6] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 10.10.10.10 +-----+ +-----+ |NodeD| |NodeE| |L3A0 | |L3A0 | +-----+--------+-----+ /// \\\ // \\ / \ | | | | | Aggregate | +---|--+ Ring 1 | |NodeC | +--------+ |L2A0A3| | NodeB | //+------+\ |L2A0A1A2| / \\ //+--------+ \ | +-----------+ / \ \\\ | | Node A |/ \ \\\\ |Access Ring 3|L2A0A1A2A3 | \ \\ | +-----------+ | || | | | | Access Ring 2 +-------+ \ / | | | |NodeH | \\ // | | | |L1A2 | +-----+ | | | +-------+ |NodeI| +-------+ \ | / |L1A3 | |NodeG | \ | / +-----+ |L1A1 | --------------- +-------+ Acess Ring 1/ \ / \ / +-------+ | NodeF | | L1A1 | +-------+ 1.1.1.1 Figure 2 Definition of TAs and TLs New network constraints are introduced to improve automation of MPLS TE path computation, As the figure above shows, the mobile backhaul network can be divided into multiple layers and multiple areas. The layers and areas can be designated easily according to the natural physical topology. We propose two concepts below: o TE Layer (TL): It indicates the physical layer of the node in the network. The TL value should be increased from the access ring to the aggregate ring layer by layer. The TL values from the access ring to the aggregate ring can be not continuous. They just Li, et al. Expires August 22, 2013 [Page 7] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 reflect the relation of the different layers. In order to accommodate future network expansion, it is better that the lowest TL value should not start from the 0 or 1. o TE Area(TA): It indicates the physical ring of the node. All nodes of the physical ring forms a natural area. TA value must be unique in the whole network. TA is designed mostly according to the physical topology with the aim to separate the obvious physical areas. One node can have multiple TA values when it belongs to multiple rings. TL and TA are defined for every node instead of every link to reduce the effort of configuration and operation. TA and TL indicates the network layer and area which one node belongs to. TL and TA value should be set for the node before the path of the TE LSP is calculated just like that the cost of the link should be set before the routes are calculated. TL and TA are only defined for MPLS TE path computation according to the natural topology of the mobile network. They have no relationship with IGP area or level. 3.2. TL and TA Information Flooding After the TL and TA value are set for the node, the TL and TA information of this node should be flooded through IGP. When all nodes TL and TA information are flooded, every node in this route region will have the whole TL and TA information which will be added to the TEDB for TE LSP calculation. When a TE LSP requires path computation in a source node , a new enhanced CSPF algorithm based on TL and TA will be used to calculate the optimal path automatically. 3.3. Enhanced CSPF Algorithm Based on TL and TA The enhanced CSPF algorithm based on TL and TA can calculate the TE path more automatically comparing with the existing CSPF algorithm. In order to achieve more automatic path computation, some new rules are introduced for the CSPF algorithm. We assume that: o The high layer is TL high(TLh), the low layer is TL low(TLl); o The source node of the LSP has the TA value TAs, the destination node of LSP has the TA value TAd, the passed node has the TA value TAp. The rules for the enhanced CSPF algorithm are as follows: Li, et al. Expires August 22, 2013 [Page 8] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 o Rule 1: If the destination node of the LSP is not in the same TA as the source node or the passed node, the node in the different layer will be the potential next-hop for the LSP path calculation. o Rule 2: One LSP's TL track can not include TLh->TLl->TLh, this means that the LSP cannot pass through the low layer twice. o Rule 3: If the LSP reach a node that in the same TA as the destination node, the LSP must be calculated in this TA only. o Rule 4: If the LSP reach a node that among more than one TAs, the node in different TA should be prior to be the next hop. This rule ensures that the primary and backup LSPs would not pass the same links. Since these rules are applied to calculate both the primary and secondary path automatically, rules for determining which is the primary or the secondary should also be introduced. The rules are as follows: o Rule 5: The LSP which passes fewer TLs will be the primary LSP. o Rule 6: If the two LSPs passes the same TLs, the one with shorter metric in every layer from high to low will be the main LSP 3.3.1. An Example of Enhanced CSPF Algorithm Based on TL and TA As the figure above shows, the TL and TA values are designed for every node and the flooding has completed. Now the primary LSP and the backup LSPp should setup from the source node(1.1.1.1) to the destination node(10.10.10.10), the path calculation is as follows: 1. The source node(1.1.1.1) is TL1TA1 and the destination node(10.10.10.10) is TL3TA0. The LSP path should be calculated towards the node with higher TL value in TA1, according to Rule 1 . The candidate nodes are NodeA and NodeB and we assume that the algorithm will choose NodeB as the next hop according to the cost. 2. After get NodeB, there are three candidate nodes for the next hop which are NodeA and NodeE and NodeH. Node H will be excluded according to Rule 2, because it will cause the LSP to passe through TL2->TL1->TL2, that means the LSP will pass another access ring which is on the same low layer as the source node. 3. NodeB is in TA0, which is the same as the destination node, so we can only choose NodeA or Node E, according to Rule 3 Li, et al. Expires August 22, 2013 [Page 9] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 4. TA1 has been passed, so the NodeB in TA1 is exclued according to rule4 5. Node E is the best appropriate choice according to the Rules.As a result ,we can get a path NodeF->NodeB->NodeE->NodeD 6. The other path is calculated according to the rules with the nodes and links passed by the first path excluded. So we can get the other path NodeF->NodeA->NodeC->NodeD. 7. Then we will select the primary path from these two paths. According to the rule5 and rule6, the path NodeF->NodeA->NodeC->NodeD is determined as the primary LSP and the path NodeF->NodeB->NodeE->NodeD is the backup LSP. 4. OSPF Extensions 4.1. OSPF TA TLV and TL TLV Format The OSPF TA TLV and TL TLV are used to advertise the TA and TL a node belongs to. The OSPF TA TLV and TL TLV (advertised in an OSPF router information LSA defined in [RFC4970]) has 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Value // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Type: identifies the TLV type Length: the length of the value field in octets The format of the TA TLV and TL TLV are the same as the TLV format used by the Traffic Engineering Extensions to OSPF (see [RFC3630]). TLV: OSPFv2 TA TYPE: TBD, OSPFv2 TL TYPE: TBD, OSPFv3 TA TYPE: TBD OSPFv3 TL TYPE: TBD Li, et al. Expires August 22, 2013 [Page 10] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 LENGTH: Variable 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Area number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Area number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Layer number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - OSPF TE-Area Group TLV and TE-Layer Group TLV format 4.2. Elements of Procedure The OSPF TA and TL TLV is carried within the OSPF Routing Information LSA. Specifically, a router MUST originate a new LSA whenever the content of this information changes, or whenever required by regular routing procedure (e.g., updates). The OSPF TLVs are OPTIONAL and MUST NOT included more than one instance. If either of the TLVs occurs more than once within the OSPF Router Information LSA, only the first instance is processed, subsequent TLV(s) SHOULD be silently ignored. When the TA or TL of a node change, a new router information LSA SHOULD be advertised. The flood scope is OSPF Area using type 10 LSA or Routing-domain scope using type 11 LSA. As defined in [RFC2370] for OSPFv2 and in [RFC2740]for OSPFv3, the flooding scope of the Router Information LSA is determined by the LSA Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. The TA TLV and TL TLV may be advertised within an Area-local or Routing-domain scope Router Information LSA, depending on the MPLS TE profile: - If the MPLS TE Area and Layer are contained within a single area, the TA TLV and TL TLV MUST be generated within an Area-local Router Information LSA. - If the MPLS TE Area and Layer spans multiple OSPF areas, the TA TLV and TL TLV MUST be generated within a Routing-domain scope router Li, et al. Expires August 22, 2013 [Page 11] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 information LSA. 4.3. Backward Compatibility The TLVs defined in this document do not introduce any interoperability issue. For OSPF, a router not supporting the TLV SHOULD just silently ignore the TLV as specified in [RFC2370]. 5. IANA Considerations The registry for the Router Information LSA is defined in [RFC4970]. IANA assigned a new OSPF TLV code-point for the OSPF-TE-Attributes TLVs carried within the Router Information LSA. Value Sub-TLV References ----- -------- ---------- TBD OSPF-TE-Area TLV (IPv4) RFC 4970 TBD OSPF-TE-Layer TLV (IPv4) RFC 4970 TBD OSPF-TE-Area TLV (IPv6) RFC 4970 TBD OSPF-TE-Layer TLV (IPv6) RFC 4970 6. Security Considerations TBD. 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 4970, July 2007. Li, et al. Expires August 22, 2013 [Page 12] Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013 Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Li Zhang Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: monica.zhangli@huawei.com Yuanjiao Liu Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: liuyuanjiao@huawei.com Li, et al. Expires August 22, 2013 [Page 13]