Network Working Group Z. Li Internet-Draft L. Zhang Intended status: Standards Track Y. Liu Expires: March 28, 2014 Huawei Technologies September 24, 2013 IGP Extensions for Automatic Computation of MPLS Traffic Engineering Path Using Traffic Engineering Layers and Areas draft-li-ccamp-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 and ISIS 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 March 28, 2014. Li, et al. Expires March 28, 2014 [Page 1] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . 7 3.3. Enhanced CSPF Algorithm Based on TL and TA . . . . . . . 7 3.3.1. An Example of Enhanced CSPF Algorithm Based on TL and TA . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. OSPF TA TLV and TL TLV Format . . . . . . . . . . . . 10 4.1.2. Elements of Procedure . . . . . . . . . . . . . . . . 11 4.1.3. Backward Compatibility . . . . . . . . . . . . . . . 12 4.2. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 12 4.2.1. IS-IS TA TLV and TL TLV Format . . . . . . . . . . . 12 4.2.2. Elements of Procedure . . . . . . . . . . . . . . . . 13 4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative Reference . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Li, et al. Expires March 28, 2014 [Page 2] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 As the network scale expands, especially in the mobile backhaul network, automatic computation of MPLS TE path becomes very important ([I-D.li-mpls-seamless-mpls-mbb]). 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 and ISIS 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. ---------------- / \ / \ / \ +------+ +----+ Access +----+ |eNodeB|---|CSG1| Ring 1 |ASG1|------------- +------+ +----+ +----+ \ \ / \ \ / +----+ +---+ \ +----+ |RSG1|----|RNC| Li, et al. Expires March 28, 2014 [Page 3] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 -------------| | Aggregate +----+ +---+ |ASG2| Ring | -------------| | +----+ +---+ / +----+ |RSG2|----|RNC| / \ +----+ +---+ / \ / +------+ +----+ Access +----+ / |eNodeB|---|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) connect the eNodeBs and RNC site gateways(RSGs) connect 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 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 requires that the primary and backup LSP should not share any nodes and links. Thus when a failure happens on 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 Li, et al. Expires March 28, 2014 [Page 4] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 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 March 28, 2014 [Page 5] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 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 192.168.10.1 +-----+ +-----+ |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 | +-------+ Li, et al. Expires March 28, 2014 [Page 6] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 192.168.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 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 Li, et al. Expires March 28, 2014 [Page 7] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 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: 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: Li, et al. Expires March 28, 2014 [Page 8] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 1. The source node(192.168.1.1) is TL1TA1 and the destination node(192.168.10.1) 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 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. IGP Extensions We define an enhanced CSPF algorithms based on TE layers and TE areas to satisfy the path calculation requirements described above. Before the path calculation, TL and TA information of the node should be flooded through IGPs. This document also specifies IGP (OSPF and IS- IS) TE Area and TE Layer TLVs (Type Length Value) allowing for the automatic discovery of the TE Area and TE Layer of a node, to be carried in the OSPF Router Information (Link State Advertisement) LSA [RFC4970] and IS-IS Router Capability TLV [RFC4971]. The routing extensions specified in this document provide the ability to signal multiple TE Area and TE Layer values. There are relatively tight real-time constraints on the operation of IGPs (such as OSPF and IS-IS). For this reason, some care needs to be taken when extend to carry additional information in an IGP. The information described in this document is relatively small in total Li, et al. Expires March 28, 2014 [Page 9] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 volume (compared with other information already carried in IGPs), and also relatively stable (i.e., changes are based on configuration changes, but not on dynamic events within the network, or on dynamic triggers such as the leaking of information from other routing protocols or routing protocol instances). 4.1. OSPF Extensions 4.1.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 are 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 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires March 28, 2014 [Page 10] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Area number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Area number N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TE-Layer number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 OSPF TE-Area TLV and TE-Layer TLV format 4.1.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 and subsequent TLV(s) SHOULD be silently ignored. When the TA or TL of a node changes, 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 [RFC5250] for OSPFv2 and in [RFC5340]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 information LSA. Li, et al. Expires March 28, 2014 [Page 11] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 4.1.3. Backward Compatibility The OSPF TLVs defined in this document do not introduce any interoperability issue. A router not supporting the TLV SHOULD just silently ignore the TLV as specified in [RFC5250]. 4.2. IS-IS Extensions 4.2.1. IS-IS TA TLV and TL TLV Format The IS-IS TA sub-TLV and TL sub-TLV are used to advertise the TA and TL a node belongs to. The IS-IS TA sub-TLV and TL sub-TLV are advertised in IS-IS Router Capability TLV [RFC4971]). The IS-IS TA sub-TLV and TL sub-TLV are composed of 1 octet for the type, 1 octet specifying the TLV length and a value field. The format of the IS-IS TA sub-TLV and TL sub-TLV for IPv4 and IPv6 are as follows: Sub-TLV: ISIS IPv4 TYPE: TBD ISIS IPv6 TYPE: TBD Sub-TLV: TE-Area TYPE: TBD TE-Layer TYPE: TBD 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Li, et al. Expires March 28, 2014 [Page 12] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 Figure 4 IS-IS TE-Area sub-TLV and TE-Layer sub-TLV format 4.2.2. Elements of Procedure The IS-IS TE-Area TLV and TE-Layer TLV are advertised within the IS- IS Router CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST originate a new IS-IS LSP whenever the content of any of the advertised sub-TLV changes or whenever required by regular IS-IS procedure (LSP updates). If an LSR desires to join or leave a particular TE-Area or TE-Layer, it MUST originate a new LSP comprising the refreshed IS-IS Router capability TLV with the updated TE-Area sub-TLV and TE-Layer sub-TLV. As specified in [RFC4971], a router may generate multiple IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different flooding scopes. If the flooding scope of a TE-Area sub-TLV and TE-Layer sub- TLV is limited to an IS-IS level, the sub-TLV MUST NOT be leaked across level and the S flag of the Router CAPABILITY TLV MUST be cleared. If the flooding scope of a TE-Area sub-TLV and TE-Layer sub-TLV is the entire routing domain, the TLV MUST be leaked across IS-IS levels, and the S flag of the Router CAPABILITY TLV MUST be set. In both cases, the flooding rules specified in [RFC4971] apply. 4.2.3. Backward Compatibility The IS-IS sub-TLVs defined in this document do not introduce any interoperability issue. A router which does not support the sub-TLVs SHOULD just silently ignore the sub-TLV as specified in [RFC6823]. 5. IANA Considerations 5.1. OSPF 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 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 5.2. IS-IS Li, et al. Expires March 28, 2014 [Page 13] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 The registry for the Router Capability TLV is defined in [RFC4971]. IANA assigned a new IS-IS sub-TLV code-point for the ISIS-TE- Attributes TLVs sub-TLVs carried within the IS-IS Router Capability TLV. Value Sub-TLV References ----- -------- ---------- TBD ISIS-TE-Area TLV (IPv4) RFC 4971 TBD ISIS-TE-Layer TLV (IPv4) RFC 4971 TBD ISIS-TE-Area TLV (IPv6) RFC 4971 TBD ISIS-TE-Layer TLV (IPv6) RFC 4971 6. Security Considerations TBD. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information", RFC 4971, July 2007. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising Generic Information in IS-IS", RFC 6823, December 2012. 7.2. Informative Reference [I-D.li-mpls-seamless-mpls-mbb] Li, et al. Expires March 28, 2014 [Page 14] Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013 Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-00 (work in progress), July 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 March 28, 2014 [Page 15]