Internet DRAFT - draft-ietf-tewg-interarea-mpls-te-req

draft-ietf-tewg-interarea-mpls-te-req



TEWG Working Group                                      JL Le Roux,(Ed.) 
Internet Draft                                           France Telecom 
                                                       JP Vasseur, (Ed.) 
                                                       Cisco System Inc. 
                                                        Jim Boyle, (Ed.) 
                                                                  PDNETs 
Category: Informational                                                  
Expires: April 2005                                        November 2004 
 
 
           Requirements for Inter-Area MPLS Traffic Engineering 
 
               draft-ietf-tewg-interarea-mpls-te-req-03.txt 
 
 
Status of this Memo 
 
   By submitting this Internet-Draft, we certify that any applicable 
   patent or IPR claims of which we are aware have been disclosed, and 
   any of which we become aware will be disclosed, in accordance with 
   RFC 3668. 
    
   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.'' 
 
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 
    
    
    
    
    
Abstract 
    
   This document lists a detailed set of functional requirements for the 
   support of inter-area MPLS Traffic Engineering (inter-area MPLS TE). 
   It is intended that solutions that specify procedures and protocol 
   extensions for inter-area MPLS-TE satisfy these requirements.  
    
    
    
 
Le Roux et al.     Informational - Expires April 2005           [Page 1] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

    
Conventions used in this document 
 
   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. 
    
 
Table of Contents 
    
   1.      Introduction................................................3 
   2.      Contributing Authors........................................4 
   3.      Terminology.................................................5 
   4.      Current intra-area uses of MPLS Traffic Engineering.........5 
   4.1.    Intra-area MPLS Traffic Engineering Architecture............5 
   4.2.    Intra-area MPLS Traffic Engineering Applications............6 
   4.2.1.  Intra-area resource optimization............................6 
   4.2.2.  Intra-area QoS guarantees...................................6 
   4.2.3.  Fast recovery within an area................................7 
   4.3.    Intra-area MPLS-TE and routing..............................7 
   5.      Problem Statement, Requirements and Objectives of inter 
             area MPLS-TE..............................................8 
   5.1.    Inter-Area Traffic Engineering Problem Statement............8 
   5.2.    Motivations for inter-area MPLS-TE..........................9 
   5.3.    Key Objectives for an inter-area MPLS-TE solution...........9 
   5.3.1.  Preserve the IGP hierarchy concept..........................9 
   5.3.2.  Preserve Scalability.......................................10 
   6.      Application Scenario.......................................11 
   7.      Detailed requirements for inter-area MPLS-TE...............12 
   7.1.    Inter-area MPLS TE operations and interoperability.........12 
   7.2.    Inter-Area TE-LSP signalling...............................12 
   7.3.    Path optimality............................................12 
   7.4.    Inter-Area MPLS-TE Routing.................................13 
   7.5.    Inter-Area MPLS-TE Path computation........................13 
   7.6.    Inter-area Crankback Routing...............................13 
   7.7.    Support of diversely routed inter-area TE LSPs.............14 
   7.8.    Intra/Inter-area Path selection policy.....................15 
   7.9.    Reoptimization of inter-area TE LSP........................15 
   7.10.   Inter-area LSP Recovery....................................16 
   7.10.1.  Rerouting of inter-area TE LSPs...........................16 
   7.10.2.  Fast recovery of inter-area TE LSP........................16 
   7.11.   DS-TE support..............................................17 
   7.12.   Hierarchical LSP support...................................17 

   7.13.   Hard/Soft pre-emption......................................17 
   7.14.   Auto-discovery of TE meshes................................17 
   7.15.   Inter-area MPLS TE fault management requirements...........17 
   7.16.   Inter-area MPLS-TE and routing.............................18 
   8.      Evaluation criteria........................................18 
   8.1.    Performances...............................................18 
   8.2.    Complexity and risks.......................................18 
   8.3.    Backward Compatibility.....................................19 
   9.      Security Considerations....................................19 
 
Le Roux et al.   Informational - Expires October 2004         [Page 2] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   10.     Acknowledgements...........................................19 
   11.     Intellectual Property Statement............................19 
   11.1.   IPR Disclosure Acknowledgement.............................20 
   12.     Normative References.......................................20 
   13.     Informative References.....................................20 
   14.     Editors' Address:..........................................22 
   15.     Full Copyright Statement...................................22 
    
 
 
 
1. Introduction 
    
   The set of MPLS Traffic Engineering components, defined in [RSVP-TE], 
   [OSPF-TE] and [ISIS-TE], which supports the requirements defined in 
   [TE-REQ], is used today by many network operators to achieve major 
   Traffic Engineering objectives defined in [TE-OVW] and summarized 
   below: 
    
        -Aggregated Traffic measurement 
        -Optimization of network resources utilization  
        -Support for services requiring end-to-end QoS guarantees 
        -Fast recovery against link/node/SRLG failures 
 
   However, the current set of MPLS Traffic Engineering mechanisms have 
   to date been limited to use within a single IGP area.  
 
   This document discusses the requirements for an inter-area MPLS 
   Traffic Engineering mechanism that may be used to achieve the same 
   set of objectives across multiple IGP areas. 
 
   Basically, it would be useful to extend MPLS TE capabilities across 
   IGP areas to support inter-area resources optimization, to provide 
   strict QoS guarantees between two edge routers located within 
   distinct areas, and to protect inter-area traffic against ABR 
   failures.  
   
   This document firstly addresses current uses of MPLS Traffic 
   Engineering within a single IGP area. This helps, then, in discussing 
   a set of functional requirements a solution must or should satisfy in 
   order to support inter-area MPLS Traffic Engineering. Since the scope 
   of requirements will vary between operators, some requirements will 
   be mandatory (MUST) whereas others will be optional (SHOULD). 
   Finally, a set of evaluation criteria for any solution meeting these 
   requirements is given. 
 
 
 
 
 
 
 
 
Le Roux et al.   Informational - Expires October 2004         [Page 3] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

 
 
2. Contributing Authors 
 
   This document was the collective work of several. The text and 
   content of this document was contributed by the editors and the 
   co-authors listed below (The contact information for the editors 
   appears in section 13, and is not repeated below): 
 
   Ting-Wo Chung                         Yuichi Ikejiri                  
   Bell Canada                           NTT Communications Corporation   
   181 Bay Street, Suite 350,            1-1-6, Uchisaiwai-cho, 
   Toronto,                              Chiyoda-ku, Tokyo 100-8019 
   Ontario, Canada, M5J 2T3              JAPAN    
   Email: ting_wo.chung@bell.ca          Email: y.ikejiri@ntt.com                     
 
   Raymond Zhang                         Parantap Lahiri  
   Infonet Services Corporation          MCI   
   2160 E. Grand Ave.                    22001 loudoun Cty Pky  
   El Segundo, CA 90025                  Ashburn, VA 20147  
   USA                                   USA   
   Email: raymond_zhang@infonet.com      E-mail: parantap.lahiri@mci.com   
                                    
   Kenji Kumaki  
   KDDI Corporation  
   Garden Air Tower  
   Iidabashi, Chiyoda-ku,  
   Tokyo 102-8460,  
   JAPAN  
   E-mail : ke-kumaki@kddi.com  
 
  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Le Roux et al.   Informational - Expires October 2004         [Page 4] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

 
3. Terminology 
 
   LSR: Label Switching Router  
    
   LSP: Label Switched Path 
    
   TE-LSP: Traffic Engineering Label Switched Path  
     
   Inter-area TE-LSP : TE-LSP whose head-end LSR and tail-end LSR do   
          not reside within the same IGP area or both head-end   
          LSR and tail-end LSR are in the same IGP area but the TE LSP   
          transiting path may be across different IGP areas. 
     
   IGP area: OSPF area or IS-IS level. 
     
   ABR: Area Border Router, router used to connect two IGP areas (ABR in 
   OSPF or L1/L2 router in IS-IS). 
    
   CSPF: Constraint-based Shortest Path First. 
    
   SRLG: Shared Risk Link Group. 
 
    
4. Current intra-area uses of MPLS Traffic Engineering 
 
   This section addresses architecture, capabilities and uses of MPLS-TE 
   within a single IGP area. It first summarizes the current MPLS-TE 
   architecture, then addresses various MPLS-TE capabilities, and 
   finally lists various approaches to integrate MPLS-TE into routing. 
   This section is intended to help defining the requirements for MPLS-
   TE extensions across multiple IGP areas. 
    
4.1. Intra-area MPLS Traffic Engineering Architecture 
     
   The MPLS-TE control plane allows establishing explicitly routed MPLS 
   LSPs whose path follows a set of TE constraints. It is used to 
   achieve major TE objectives such as resource usage optimization, QoS 
   guarantee and fast failure recovery. It basically consists of three 
   main components: 
    
        -The routing component, responsible for the discovery of the TE  
         topology. This is ensured thanks to extensions of link state   
         IGP:[ISIS-TE], [OSPF-TE]. 
        -The path computation component, responsible for the placement  
         of the LSP. It is performed on the Head-End LSR thanks to a  
         CSPF algorithm, which takes TE topology and LSP constraints as  
         input. 
        -The signalling component, responsible for the establishment of   
         the LSP (explicit routing, label distribution  
         and resources reservation) along the computed path. This is  
         ensured thanks to RSVP-TE [RSVP-TE]) 
 
Le Roux et al.   Informational - Expires October 2004         [Page 5] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

    
 
4.2. Intra-area MPLS Traffic Engineering Applications 
 
 
4.2.1. Intra-area resource optimization 
 
   MPLS-TE can be used within an area to redirect paths of aggregated 
   flows away from over-utilized resources within a network. In a small 
   scale, this may be done by explicitly configuring a path to be used 
   between two routers.  In a grander scale, a mesh of LSPs can be 
   established between central points in a network. LSPs paths can be 
   defined statically in configuration or arrived at by an algorithm 
   that determines the shortest path given constraints such as bandwidth 
   or other administrative constraints. 
   In this way, MPLS-TE allows for greater control over how traffic 
   demands are routed over a network topology and utilize a network's 
   ressources.  
 
   Note also that TE-LSPs allow to measure traffic matrix in a simple 
   and scalable manner. Basically, aggregated traffic rate between two 
   LSRs is easily measured by accounting of traffic sent onto a TE LSP 
   provisioned between the two LSRs in question. 
 
 
4.2.2. Intra-area QoS guarantees 
 
   The DiffServ IETF working group has defined a set of mechanisms  
   described in [DIFF-ARCH], [DIFF-AF] and [DIFF-EF] or [MPLS-DIFF] that  
   can be activated at the edge or over a DiffServ domain to contribute 
   to the enforcement of a (set of) QoS policy(ies), which can be 
   expressed in terms of maximum one-way transit delay, inter-packet 
   delay variation, loss rate, etc. Many Operators have some or full 
   deployment of DiffServ implementations in their networks today, 
   either across the entire network or at least at the edge of the 
   network. 
    
   In situations where strict QoS bounds are required, admission control 
   inside the backbone of a network is in some cases required in 
   addition to current DiffServ mechanisms. When the propagation delay 
   can be bounded, the performance targets, such as maximum one-way 
   transit delay may be guaranteed by providing bandwidth guarantees 
   along the DiffServ-enabled path.   
    
   MPLS-TE can be simply used with DiffServ: in that case, it only 
   ensures aggregate QoS guarantees for the whole traffic. It can also 
   be more intimately combined with DiffServ to perform per-class of 
   service admission control and resource reservation. This requires 
   extensions to MPLS-TE called DiffServ Aware TE and defined in [DS-TE-
   PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For 
   instance, an EF DS-TE LSP may be provisioned between voice gateways 
   within the same area to ensure strict QoS to VoIP traffic.  
 
Le Roux et al.   Informational - Expires October 2004         [Page 6] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

 
   MPLS-TE allows computing intra-area shortest paths satisfying various 
   constraints including bandwidth. For the sake of illustration, if the 
   IGP metrics reflects the propagation delay, it allows finding a 
   minimum propagation delay path satisfying various constraints like 
   bandwidth.  
 
 
4.2.3. Fast recovery within an area 
 
   As quality sensitive applications are deployed, one of the key 
   requirements is to provide fast recovery mechanisms, allowing 
   guaranteeing traffic recovery on the order of tens of msecs, in case 
   of network element failure. Note that this cannot be achieved by 
   relying only on classical IGP rerouting.  
 
   Various recovery mechanisms can be used to protect traffic carried 
   onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms 
   are based on the provisioning of backup LSPs that are used to recover 
   traffic in case of failure of protected LSPs. Among those protection 
   mechanisms, local protection, also called Fast Reroute is intended to 
   achieve sub-50ms recovery in case of link/node/SRLG failure along the 
   LSP path [FAST-REROUTE]. Fast Reroute is currently used by many 
   operators to protect sensitive traffic inside an IGP area. 
    
   [FAST-REROUTE] defines two modes for backup LSPs. The first one, 
   called one-to-one backup, consists in setting up a detour LSP per 
   protected LSP and per element to protect. The second one called 
   facility-backup consists in setting up one or several bypass LSPs to 
   protect a given facility (link or node). In case of failure, all 
   protected LSPs are nested into the bypass LSPs (benefiting from the 
   MPLS label stacking property). 
 
 
4.3. Intra-area MPLS-TE and routing 
 
   There are several possibilities to direct traffic into intra-area TE 
   LSPs: 
    
        1) Static routing to the LSP destination address or any other  
           addresses.  
        2) IGP routes beyond the LSP destination, from an IGP SPF   
           perspective (IGP shortcuts). 
        3) BGP routes announced by a (MP-)BGP peer that is reachable  
           through the TE-LSP by means of a single static route to the     
           corresponding BGP next-hop address (option 1) or by means of    
           IGP shortcuts (option 2). This is often called BGP recursive  
           routing. 
        4) The LSP can be advertised as a link into the IGP to become  
           part of IGP database for all nodes, and thus taken into   
           account during SPF for all nodes. Note that, even if similar  
           in concept, this is different from the notion of Forwarding- 
 
Le Roux et al.   Informational - Expires October 2004         [Page 7] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

           Adjacency, as defined in [LSP-HIER], where the LSP is    
           advertised as a TE-link into the IGP-TE, to become part of   
           the TE database and taken into account in CSPF. 
 
5. Problem Statement, Requirements and Objectives of inter-area MPLS-TE 
 
5.1. Inter-Area Traffic Engineering Problem Statement  
 
   As described in section 4, MPLS-TE is deployed today by many 
   operators to optimize network bandwidth usage, to provide strict QoS 
   guarantees and to ensure sub-50ms recovery in case of link/node/SRLG 
   failure.  
 
   However, MPLS-TE mechanisms are currently limited to a single IGP 
   area. The limitation comes essentially from the Routing and Path 
   computation components and less from the signaling component.  
   This is basically due to the fact that hierarchy limits topology 
   visibility of head-end LSRs to their IGP area, and consequently head-
   end LSRs can no longer run a CSPF algorithm to compute the shortest 
   constrained path to the tail-end as CSPF requires the whole topology 
   to compute an end-to-end shortest constrained path. 
    
   Several operators have multi-area networks and many operators that 
   are still using a single IGP area may have to migrate to a multi-area 
   environment, as their network grows and single area scalability 
   limits are approached. 
   
   Hence, those operators may require inter-area traffic engineering to: 
        - Perform inter-area resource optimization.              
        - Provide inter-area QoS guarantees for traffic between edge  
          nodes located in different areas. 
        - Provide fast recovery across areas, to protect inter-area  
          traffic in case of link or node failure, including ABR node  
          failures. 
 
   For instance an operator running a multi-area IGP may have Voice 
   gateways located in different areas. Such VoIP transport requires 
   inter-area QoS guarantees and inter-area fast protection. 
    
   One possible approach for inter-area traffic engineering could 
   consist of deploying MPLS-TE on a per-area basis, but such an 
   approach has several limitations: 
        - Traffic aggregation at the ABR levels implies some constraints   
           that do no lead to efficient traffic engineering. Actually   
           such per-area TE approach might lead to sub-optimal resource   
           utilization, by optimizing resources independently in each  
           area. And what many operators want is to optimize their   
           resources as a whole, in other words as if there was only one  
           area (flat network). 
        - This does not allow computing an inter-area constrained  
          shortest path and thus does not ensure end-to-end QoS  
          guarantees across areas. 
 
Le Roux et al.   Informational - Expires October 2004         [Page 8] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

        - Inter-area traffic cannot be protected with local protection  
          mechanisms such as [FAST-REROUTE] in case of ABR failure. 
         
   Hence, existing MPLS TE mechanisms have to be enhanced to support 
   inter-area TE LSPs. 
 
 
5.2. Motivations for inter-area MPLS-TE 
 
   For the reasons mentioned above, it is highly desired to extend the 
   current set of MPLS-TE mechanisms across multiple IGP areas in order 
   to support the intra area applications described in section 4 across 
   areas. 
    
   Basically, the solution MUST allow setting up inter-area TE LSPs, ie 
   LSPs whose path crosses at least two IGP areas.  
 
   Inter-area MPLS-TE extensions are highly desired to provide: 
        - Inter-area resources optimization. 
        - Strict inter-area QoS guarantees. 
        - Fast recovery across areas, particularly in order to protect 
           inter-area traffic against ABR failures. 
    
   It may be desired to compute inter-area shortest path that satisfy 
   some bandwidth constraints or any other constraints, as currently 
   possible within a single IGP area. For the sake of illustration, if 
   the IGP metrics reflects the propagation delay, it may be needed to 
   be able to find the optimal (shortest) path satisfying some 
   constraints (e.g. bandwidth) across multiple IGP areas: such a path 
   would be the inter-area path offering the minimal propagation delay. 
 
   Thus the solution SHOULD provide the ability to compute inter-area 
   shortest paths satisfying a set of constraints (i.e. bandwidth). 
 
 
5.3. Key Objectives for an inter-area MPLS-TE solution  
 
   Any solution for inter-area MPLS-TE should be designed having as key 
   objectives to preserve IGP hierarchy concept, and to preserve routing 
   and signaling scalability. 
 
5.3.1. Preserve the IGP hierarchy concept 
 
   The absence of a full link state topology database makes the 
   computation of an end-to-end optimal path by the head-end LSR not 
   possible without further signaling and routing extensions. There are 
   several reasons that network operators choose to break up their 
   network into different areas. These often include scalability and 
   containment of routing information. The latter can help isolate most 
   of a network from receiving and processing updates that are of no 
   consequence to its routing decisions. Containment of routing 
   information MUST not be compromised to allow inter-area traffic 
 
Le Roux et al.   Informational - Expires October 2004         [Page 9] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   engineering. Information propagation for path-selection MUST continue 
   to be localized. In other words, the solution MUST entirely preserve 
   the concept of IGP hierarchy.  
 
 
 
5.3.2. Preserve Scalability 
 
   Being able to achieve the requirements listed in this document MUST 
   be performed while preserving the IGP scalability, which is of the 
   utmost importance. The hierarchy preservation objective addressed in 
   the above section is actually an element to preserve IGP scalability. 
   The solution MUST also not unreasonably increase IGP load which could 
   compromise IGP scalability. In particular, a solution satisfying 
   those requirements MUST not require for the IGP to carry some 
   unreasonable amount of extra information and MUST not unreasonably 
   increase the IGP flooding frequency. 
 
   Likewise, the solution MUST also preserve scalability of RSVP-TE 
   ([RSVP-TE]). 
  
   Additionally, the base specification of MPLS TE is architecturally 
   structured and relatively devoid of excessive state propagation in 
   terms of routing or signaling.  Its strength in extensibility can 
   also be seen as an Achilles heel, as there is really no limit to 
   what is possible with extensions.  It is paramount to maintain 
   architectural vision and discretion when adapting it for use for 
   inter-area MPLS-TE.  Additional information carried within 
   an area, or propagated outside of an area (via routing or 
   signaling) should neither be excessive, patchwork, nor 
   non-relevant. 
 
   Particularly, as mentioned in 5.2 it may be desired, for some inter-
   area TE LSP carrying highly sensitive traffic, to compute a shortest 
   inter-area path satisfying a set of constraints like bandwidth. This 
   may require an additional routing mechanism, as base CSPF at head-end 
   can not longer be used due to the lack of topology and resources 
   information. Such routing mechanism MUST not compromise the 
   scalability of the overall system. 
 
    
 
 
 
 
 
 
 
 
 
 
 
 
Le Roux et al.   Informational - Expires October 2004        [Page 10] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

 
 
 
 
 
 
6. Application Scenario 
 
   ---area1--------area0------area2--  
    ------R1-ABR1-R2-------ABR3-------  
   |       \   |  /        |         |  
   | R0     \  | /         |      R4 |  
   | R5      \ |/          |         |  
    ---------ABR2----------ABR4-------  
     
   - ABR1, ABR2: Area0-Area1 ABRs 
   - ABR3, ABR4: Area0-Area2 ABRs 
    
   - R0, R1, R5: LSRs in area 1  
   - R2: an LSR in area 0  
   - R4: an LSR in area 2  
    
   Although the terminology and examples provided in this document make 
   use of the OSPF terminology, this document equally applies to IS-IS. 
     
   Typically, an inter-area TE LSP will be set up between R0 and R4 
   where both LSRs belong to different IGP areas. Note that the solution 
   MUST support the capability to protect such an inter-area TE LSP from 
   the failure on any Link/SRLG/Node within any area and the failure of 
   any traversed ABR. For instance, if the TE-LSP R0->R4 goes through 
   R1->ABR1->R2, then it can be protected against ABR1 failure, thanks 
   to a backup LSP (detour or bypass) that may follow the alternate path 
   R1->ABR2->R2. 
    
   For instance R0 and R4 may be two voice gateways located in distinct 
   areas. An inter-area DS-TE LSP with class-type EF, is setup from R1 
   to R4 to route VoIP traffic classified as EF. Per-class inter-area 
   constraint based routing allows routing the DS-TE LSP over a path 
   that will ensure strict QoS guarantees for VoIP traffic. 
    
   In another application R0 and R4 may be two pseudo wire gateways 
   residing in different areas. An inter-area LSP may be setup to carry 
   pseudo wires.  
                                                                
   In some cases, it might also be possible to have an inter-area TE LSP  
   from R0 to R5 transiting via the backbone area (or any other levels  
   with IS-IS). Basically, there may be cases where there is no longer 
   enough resources on any intra area path R0-to-R5, while there is a 
   feasible inter-area path through the backbone area. 
 
    
    
 
Le Roux et al.   Informational - Expires October 2004        [Page 11] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

 
 
7. Detailed requirements for inter-area MPLS-TE 
 
 
7.1. Inter-area MPLS TE operations and interoperability  
  
   The inter-area MPLS TE solution MUST be consistent with requirements  
   discussed in [TE-REQ] and the derived solution MUST be such that it  
   will interoperate seamlessly with current intra-area MPLS TE 
   mechanisms and inherit its capability sets from [RSVP-TE].  
     
   The proposed solution MUST allow provisioning at the head-end with 
   end-to-end RSVP signalling (potentially with loose paths) traversing 
   across the interconnected ABRs, without further provisioning required 
   along the transit path.  
 
 
7.2. Inter-Area TE-LSP signalling 
 
   The solution MUST allow for the signalling of inter-area TE-LSPs, 
   using RSVP-TE. 
 
   In addition to the signaling of classical TE constraints (bandwidth, 
   admin-groups€), the proposed solution MUST allow the head-end LSR to 
   explicitly specify a set of LSRs, including ABRs, by means of strict 
   or loose hops for the inter-area TE LSP.  
     
   In addition, the proposed solution SHOULD also provide the ability to  
   specify and signal certain resources to be explicitly excluded in the 
   inter-area TE LSP path establishment.  
 
 
7.3. Path optimality  
 
   In the context of this requirement document, an optimal path is  
   defined as the shortest path across multiple areas taking into 
   account either the IGP or TE metric [METRIC]. In other words, such a 
   path is the path that would have been computed making use of some 
   CSPF algorithm in the absence of multiple IGP areas.  
 
   As already mentioned in 5.2, the solution SHOULD provide the 
   capability to dynamically compute an optimal path satisfying a set of 
   specified constraints defined in [TE-REQ] across multiple IGP areas. 
   Note that this requirement document does not mandate that all inter-
   area TE LSPs require the computation of an optimal (shortest) inter-
   area path: some inter-area TE LSP paths may be computed via some 
   mechanisms not guaranteeing an optimal end to end path whereas some 
   other inter-area TE LSP paths carrying sensitive traffic could be 
   computed making use of some mechanisms allowing to dynamically 
   compute an optimal end-to-end path. Note that regular constraints 
   like bandwidth, affinities, IGP/TE metric optimization, path 
 
Le Roux et al.   Informational - Expires October 2004        [Page 12] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   diversity, etc, MUST be taken into account in the computation of an 
   optimal end-to-end path. 
 
 
 
7.4. Inter-Area MPLS-TE Routing 
 
   As already mentioned in 5.3, IGP hierarchy does not allow the Head-
   End LSR computing an end-to-end optimal path. Additional mechanisms 
   are required to compute an optimal path. These additional mechanisms 
   MUST not alter the IGP hierarchy principles. 
   Particularly, in order to maintain containment of routing information 
   and preserve the overall IGP scalability, the solution SHOULD avoid 
   the leaking across area of any dynamic TE Topology related  
   information even in a summarized form. 
 
   Conversely, this does not preclude the leaking of non topology 
   related information, that are not taken into account during path 
   selection, such as static TE Node information like TE router ids or 
   TE node capabilities. 
  
 
7.5. Inter-Area MPLS-TE Path computation  
  
   Several methods may be used for path computation, as for instance: 
 
      -Per-area path computation based on ERO expansion on the Head- 
       End LSR and on ABRs, with two options for ABR selection: 
        -Static configuration of ABRs as loose hops at the head-end LSR. 
        -Dynamic ABR selection. 
 
      -Inter-area end-to-end path computation, which may be  
       based for instance on a recursive constraint based searching 
       thanks to collaboration between ABRs. 
    
   Note that any path computation method may be used provided that it 
   respect key objectives pointed out in 5.3. 
    
   In case a solution supports more than one method, it should allow the 
   operator to select by configuration, and on a per-LSP basis, the 
   desired option. 
 
 
7.6. Inter-area Crankback Routing 
 
   Crankback routing, as defined in [CRANKBACK] may be used for inter-
   area TE-LSPs. Basically for paths computed thanks to ERO expansions 
   with a dynamic selection of downstream ABRs, crankback routing can be 
   used when there is no feasible path from a selected downstream ABR to 
   the destination: The upstream ABR or Head-End LSR, selects another 
   downstream ABR, and performs ERO expansion. 

 
Le Roux et al.   Informational - Expires October 2004        [Page 13] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   Note that such method does not allow computing and optimal path but 
   just a feasible path. 
   Note also that there can be 0(N2) LSP setup failures before finding 
   a feasible path where N is the average number of ABR between two 
   areas. This may have a non negligible impact on the LSP setup delay. 
 
   Crankback may also be used for inter-area LSP recovery: Basically in 
   case a link/node/SRLG failure occurs in the backbone or tail-end 
   area, the ABR upstream to the failure computes an alternate path and 
   reroutes locally the LSP. 
 
   An inter-area MPLS-TE solution MAY support [CRANKBACK]. 
   A solution that supports [CRANKBACK], MUST allow to 
   activate/deactivate it via signaling, on a per-LSP basis.  
 
     
7.7. Support of diversely routed inter-area TE LSPs  
     
   There are several cases where the ability to compute diversely routed  
   TE LSP paths may be desirable. For instance, in case of LSP 
   protection, primary and backup LSPs should be diversely routed. 
   Another example is the requirement to set up multiple diversely 
   routed TE LSPs between a pair of LSRs residing in different IGP 
   areas. For instance when a single TE-LSP satisfying the bandwidth 
   constraint could not be found between two end-points, a solution 
   would consist of setting up multiple TE-LSPs such that the sum of 
   their bandwidth satisfy the bandwidth requirement. In this case, it 
   may be desirable to have these TE-LSPs diversely routed in order to 
   minimize the impact of a failure, on the traffic between the two end-
   points.  
 
   Hence, the solution MUST be able to establish diversely routed inter-
   area TE LSPs, when diverse path exist. It MUST support all kinds of 
   diversity (link, node, SRLG). 
    
   The solution SHOULD allow computing an optimal placement of diversely 
   routed LSP. There may be various criteria to determine such an 
   optimal placement. For instance the placement of two diversely routed 
   LSPs, for load-balancing purpose may consists of minimizing their 
   cumulative cost. The placement of two diversely routed LSPs for 
   protection purpose may consists in minimizing the cost of the primary 
   LSP while bounding the cost, or hop count of the backup LSP.   
    
    
 
 
 
 
 
 
 

 
Le Roux et al.   Informational - Expires October 2004        [Page 14] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

7.8. Intra/Inter-area Path selection policy  
     
   For inter-area TE LSPs whose head-end and tail-end LSRs reside in the 
   same IGP area, there may be intra-area and inter-area feasible paths. 
   In case the shortest path is an inter-area path, an operator may 
   either want to avoid, as far as possible, crossing area and thus 
   prefer selecting a sub-optimal intra-area path, or conversely may 
   prefer to use a shortest path, even if it crosses areas. 
   Thus, the solution should allow to enable/disable IGP area crossing, 
   on a per-LSP basis, for TE LSPs whose head-end and tail-end reside in 
   the same IGP area.  
     
 
7.9. Reoptimization of inter-area TE LSP  
     
   The solution MUST provide the ability to reoptimize in a minimally 
   disruptive manner (make before break) an inter-area TE LSP, should a 
   more optimal path appear in any traversed IGP area. The operator 
   should be able to parameter such a reoptimization on a timer or 
   event-driven basis. It should also be possible to trigger such a 
   reoptimization manually.  
    
   The solution SHOULD provide the ability to locally reoptimize and 
   inter-area TE-LSP within an area, i.e. retaining the same set of 
   transit ABRs. The reoptimization process in that case, MAY be 
   controlled by the head-end LSR of the inter-area LSP, or by an ABR. 
   The ABR should check for local optimality of the inter-area TE LSPs 
   established through it, based on a timer or triggered by an event. 
   Option of providing manual trigger to check for optimality should 
   also be provided.   
    
   In some cases it is important to restrict the control of 
   reoptimization to the Head-End LSR only. Thus, the solution MUST 
   allow to activate/deactivate ABR control of reoptimization, via 
   signalling on a per LSP-basis. 
    
   The solution SHOULD also provide the ability to perform an end-to-end 
   reoptimization, resulting potentially in a change on the set of 
   transit ABRs. Such reoptimization can be controlled only by the HE 
   LSR. 
 
   In case of head-end control of reoptimization, the solution SHOULD 
   provide the ability for the inter-area head-end LSR to be informed of 
   the existence of a more optimal path in a downstream area and keep a 
   strict control on the reoptimization process. Hence, the inter-area 
   head-end LSR, once informed of a more optimal path in some downstream 
   IGP areas, could decide (or not) to gracefully perform a make-before-
   break reoptimization, according to the inter-area TE LSP 
   characteristics. 
    
     
                                     
 
Le Roux et al.   Informational - Expires October 2004        [Page 15] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

7.10. Inter-area LSP Recovery.  
 
7.10.1. Rerouting of inter-area TE LSPs 
     
   The solution MUST support rerouting of an inter-area TE LSP in case 
   of SRLG/link/node failure or pre-emption. Such rerouting may be 
   controlled by the Head-End LSR or by an ABR (see section 7.6 on 
   crankback). 
    
 
7.10.2. Fast recovery of inter-area TE LSP  
 
   The solution MUST provide the ability to benefit from fast recovery  
   making use of the local protection techniques specified in [FAST- 
   REROUTE] in both the case of an intra-area network element failure  
   (link/SRLG/Node) and an ABR node failure. Note that different  
   protection techniques SHOULD be usable in different parts of the 
   network to protect an inter-area TE LSP. This is of the utmost 
   importance in particular in the case of an ABR node failure that 
   typically carries a great deal of inter-area traffic. Moreover, the 
   solution SHOULD allow computing and setting up a backup tunnel 
   following an optimal path that offers bandwidth guarantees during 
   failure along with other potential constraints (like bounded 
   propagation delay increase along the backup path).  
    
   The solution SHOULD allow to protect ABRs while providing the same 
   level of performances (recovery delay, bandwidth consumption) as 
   provided today within an area. 
    
   Note that some signalling approaches may have an impact on FRR 
   performances (recovery delay, bandwidth consumption). Typically, when  
   some intra-area LSPs (LSP-Segment, FA-LSPs) are used to support the 
   inter-area TE LSP, then the protection of ABR using [FAST-REROUTE] 
   may lead to higher bandwidth consumption, and higher recovery delays. 
   The use of [FAST-REROUTE] to protect ABRs, while ensuring the same 
   level of performances,  currently requires to use a single end-to-end 
   RSVP session (contiguous LSP), with no use of any intra-area LSP. 
   Thus, the solution MUST provide the ability, via signalling on a per-
   LSP basis, to allow/preclude the use of intra-area LSPs to support 
   the inter-area LSPs.  
    
    
 
 
     
    
    
    
    
    
    

 
Le Roux et al.   Informational - Expires October 2004        [Page 16] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

7.11. DS-TE support  
     
   The proposed inter-area MPLS TE solution SHOULD also satisfy core  
   requirements documented in [DSTE-REQ] and interoperate seamlessly 
   with current intra-area MPLS DS-TE mechanism [DSTE-PROTO]. 
 
 
7.12. Hierarchical LSP support  
     
   In case of large inter-area MPLS deployment potentially involving a  
   large number of LSRs, it can be desirable/necessary to introduce  
   some level of hierarchy in order to reduce the number of  
   states on LSRs (it is worth mentioning that such a solution implies 
   other challenges). Hence, the proposed solution SHOULD allow inter-
   area TE LSP aggregation (also referred to as LSP nesting) such that 
   individual TE LSPs can be carried onto one or more aggregating 
   LSP(s).  One such mechanism, for example is described in [LSP-HIER]. 
    
     
7.13. Hard/Soft pre-emption  
     
   As defined in [MPLS-PREEMPT], there are two pre-emption models 
   applicable to MPLS: Soft and Hard Pre-emption 
    
   An inter-area MPLS-TE solution SHOULD support the two models.  
 
   In case of hard pre-emption, the pre-empted inter-area TE-LSP should 
   be rerouted, following requirements defined in section 7.10.1. 
   In case of soft pre-emption, the pre-empted inter-area TE-LSP should 
   be re-optimized, following requirements defined in section 7.9. 
 
     
7.14. Auto-discovery of TE meshes 
     
   A TE mesh is a set of LSRs, fully interconnected by a full mesh of 
   TE-LSPs. 
   Because the number of LSRs participating in some TE mesh might be 
   quite large, it might be desirable to provide some discovery 
   mechanisms allowing an LSR to automatically discover the LSRs members 
   of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD 
   be applicable across multiple IGP areas, and SHOULD not impact the 
   IGP scalability, provided that IGP extensions are used for such a 
   discovery mechanism. 
    
    
7.15. Inter-area MPLS TE fault management requirements  
     
   The proposed solution SHOULD be able to interoperate with fault  
   detection mechanisms of intra-area MPLS TE. 
 
   The solution SHOULD support [LSP-PING] and [MPLS-TTL].  
 
 
Le Roux et al.   Informational - Expires October 2004        [Page 17] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   The solution SHOULD also support for fault detection on backup LSPs,    
   in case [FAST-REROUTE] is deployed. 
    
     
7.16. Inter-area MPLS-TE and routing   
                                                                        
   In the case of intra-area MPLS TE, there are currently several  
   possibilities to route traffic into an intra-area TE LSP. They are 
   listed in section 4.2. 
    
   In case of inter-area MPLS-TE, the solution MUST support static 
   routing into the LSP, and also BGP recursive routing with a static 
   route to the BGP next-hop address. 
 
   ABRs propagate IP reacheability information (summary LSA in OSPF and 
   IP reacheability TLV in ISIS), that MAY be used by the head-end LSR  
   to route traffic to a destination beyond the TE LSP tail-head LSR 
   (e.g. to an ASBR). 
    
   The use of IGP shortcuts, MUST be precluded when TE LSP head-end and 
   tail-end LSRs do not reside in the same IGP area. It MAY be used when 
   they reside in the same area. 
    
   The advertisement of an inter-area TE LSP as a link into the IGP, to 
   attract traffic to an LSP source MUST be precluded when TE LSP head-
   end and tail-end LSRs do not reside in the same IGP area. It MAY be 
   used when they reside in the same area. 
 
 
8. Evaluation criteria  
     
8.1. Performances  
     
   The solution will be evaluated with respects to the following 
   criteria:  
   (1) Optimality of the computed inter-area TE LSP primary and backup   
       paths, in terms of path cost. 
   (2) Capability to share bandwidth among inter-are backup LSPs    
       protecting independent facilities.  
   (3) Inter-area TE LSP set up time (in msec). 
   (4) RSVP-TE and IGP scalability (state impact, number of messages,    
       message size) 
     
    
8.2. Complexity and risks  
     
   The proposed solution(s) SHOULD not introduce complexity  
   to the current operating network to such a degree that it would 
   affect the stability and diminish the benefits of deploying such 
   solution over SP networks.  
     

 
Le Roux et al.   Informational - Expires October 2004        [Page 18] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

8.3. Backward Compatibility  
     
   The deployment of inter-area MPLS TE SHOULD not have impact on 
   existing MPLS TE mechanisms to allow for a smooth migration or co-
   existence. In particular the solution SHOULD allow the setup of an 
   inter-area TE-LSP among transit LSRs that do not support inter-area 
   extensions, provided that these LSRs do not participate in the inter-
   area TE procedure. For illustration purpose the solution MAY require 
   inter-area extensions only on end-point LSRs, ABRs and potentially on 
   PLRs protecting an ABR. 
 
9. Security Considerations  
     
   This document does not introduce new security issues beyond those 
   inherent in MPLS-TE [RFC3209] and may use the same mechanisms 
   proposed for this technology. It is, however, specifically important 
   that manipulation of administratively configurable parameters be 
   executed in a secure manner by authorized entities. 
    
 
 
10. Acknowledgements 
 
   We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal 
   Sharma and Arthi Ayyangar for their useful comments and suggestions.  
 
 
11. Intellectual Property Statement 
 
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed to 
   pertain to the implementation or use of the technology described in 
   this document or the extent to which any license under such rights 
   might or might not be available; nor does it represent that it has 
   made any independent effort to identify any such rights. Information 
   on the procedures with respect to rights in RFC documents can be 
   found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use of 
   such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository at 
   http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard. Please address the information at ietf-ipr@ietf.org. 
 
    

 
Le Roux et al.   Informational - Expires October 2004        [Page 19] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

11.1. IPR Disclosure Acknowledgement 
 
   By submitting this internet-draft, I certify that any applicable 
   patent or other IPR claims of which I am aware have been disclosed, 
   or will be disclosed, and any of which I become aware will be 
   disclosed, in accordance with RFC 3668. 
 
 
12. Normative References 
 
  
   [RFC] Bradner, S., "Key words for use in RFCs to indicate 
   requirements levels", RFC 2119, March 1997. 
    
   [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 
   RFC 3667, February 2004. 
    
   [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 
   Technology", BCP 79, RFC 3668, February 2004. 
     
   [TE-REQ] Awduche et. al., "Requirements for Traffic Engineering  
   over MPLS", RFC2702. 
                                                                     
   [DSTE-REQ] Le faucheur, F., et al, "Requirements for Support of 
   Differentiated Services-aware MPLS Traffic Engineering", RFC3564.
 
 
13. Informative References 
 
   [MPLS-ARCH] Rosen, et. al., "Multiprotocol Label Switching 
   Architecture", RFC 3031. 
     
   [TE-OVW] Awduche, et. al., "Overview and Principles of Internet 
   Traffic Engineering", RFC 3272. 
    
   [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC  
   3209. 
 
   [OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering  
   Extensions to OSPF Version 2", RFC3630. 
     
   [ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic 
   Engineering", RFC 3784.  
 
   [TE-APP] Boyle, et. al., "Applicability Statement of Traffic 
   Engineering", RFC 3346. 
    
   [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE 
   for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, work 
   in progress. 
    
    
 
Le Roux et al.   Informational - Expires October 2004        [Page 20] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

   [RFC3209] Awduche, D., et al, " RSVP-TE: Extensions to RSVP for LSP 
   Tunnels", RFC3209. 
    
 
   [LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,  
   Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",  
   Internet Draft "draft-ietf-mpls-lsp-ping-07.txt", work in progress. 
     
   [MPLS-TTL] Agarwal, R., et al, "Time to Live (TTL) Processing in MPLS 
   Networks", RFC 3443.  
     
   [LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized  
   MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. 
    
   [MPLS-RECOV] V. Sharma, F. Hellstrand, "Framework for Multi-Protocol 
   Label Switching (MPLS)-based Recovery", RFC 3469. 
     
   [CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS 
   Signaling", draft-ietf-ccamp-crankback-03.txt, work in progress. 
    
   [MPLS-DIFF] Le Faucheur, et. al., "MPLS Support of Differentiated 
   Services", RFC 3270. 
 
   [DSTE-PROTO] Le faucheur, F., et al, "Protocol extensions for support 
   of Differentiated-Service-aware MPLS Traffic Engineering", draft-
   ietf-tewg-diff-te-proto-07.txt,  work in progress. 
    
   [DIFF-ARCH] Blake, et. al., "An Architecture for Differentiated 
   Services", RFC 2475. 
    
   [DIFF-AF] Heinanen, et. al., "Assured Forwarding PHB Group", RFC 
   2597. 
    
   [DIFF-EF] Davie, et. al., "An Expedited Forwarding PHB (Per-Hop 
   Behavior)", RFC 3246. 
 
   [MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", 
   draft-farrel-mpls-preemption-interim-00.txt, work in progress. 
 
   [METRIC] Le Faucheur, et. Al., "Use of Interior Gateway Protocol 
   (IGP) Metric as a second  MPLS Traffic Engineering Metric", RFC 3785. 
 
    
    
    
    
    
    
    
    
 
 
 
Le Roux et al.   Informational - Expires October 2004        [Page 21] 
  
Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-03   November 2004 
                                      

14. Editors' Address:  
     
   Jean-Louis Le Roux  
   France Telecom  
   2, avenue Pierre-Marzin  
   22307 Lannion Cedex  
   France  
     
   Jean-Philippe Vasseur  
   Cisco Systems, Inc.  
   300 Beaver Brook Road  
   Boxborough , MA - 01719  
   USA  
   Email: jpv@cisco.com  
    
   Jim Boyle 
   Email: jboyle@pdnets.com 
 
 
 
15. Full Copyright Statement 
 
 
   Copyright (C) The Internet Society (2004). This document is subject 
   to the rights, licenses and restrictions contained in BCP 78 and 
   except as set forth therein, the authors retain all their rights. 
 
   This document and the information contained herein are provided on an 
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
   INCLUNG BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
 
















 
Le Roux et al.   Informational - Expires October 2004        [Page 22]