[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 rfc4105                                           
TEWG Working Group                                      JL Le Roux,(Ed.)
Internet Draft                                           France Telecom
                                                       JP Vasseur, (Ed.)
                                                       Cisco System Inc.
                                                        Jim Boyle, (Ed.)
Category: Informational
Expires: October 2004                                           May 2004

           Requirements for Inter-area MPLS Traffic Engineering


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document lists a detailed set of functional requirements for the
   support of inter-area MPLS Traffic Engineering (inter-area MPLS TE)
   which could serve as a guideline to develop the required set of
   protocol extensions.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

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 Applications............5
   4.1.1.  Intra-area resources optimization...........................5
   4.1.2.  Intra-area QoS guarantees...................................6
   4.1.3.  Fast recovery within an area................................6
   4.2.    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.    Requirements 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...............................14
   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..............................................16
   7.12.   Hierarchical LSP support...................................16
   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.............................17
   8.      Evaluation criteria........................................18
   8.1.    Performances...............................................18
   8.2.    Complexity and risks.......................................18
   8.3.    Backward Compatibility.....................................18
   9.      Security Considerations....................................19
   10.     Acknowledgements...........................................19
   11.     Normative References.......................................19
   12.     Informative References.....................................20
   13.     Editors' Address:..........................................21

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

1. Introduction

   The set of MPLS Traffic Engineering tools, defined in [RSVP-TE],
   [OSPF-TE] and [ISIS-TE], that 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

        -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

   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-01      May 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,
   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-01      May 2004

3. Terminology

   LSR: Label Switching Router

   TE-LSP: MPLS 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.

4. Current intra-area uses of MPLS Traffic Engineering

   This section addresses capabilities and uses of MPLS-TE within a
   single IGP area. It first addresses various capabilities offered by
   these mechanisms and then 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 Applications

4.1.1. Intra-area resources optimization

   MPLS-TE can be used within an area to redirect paths of aggregated
   flows away from over-utilized resources within a network topology. 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 of how traffic
   demands utilize a network topology.  As mentioned in Section 1, uses
   to date have been limited to within a single IGP area.

   Note also that TE-LSPs allow to measure traffic matrix in a simple
   and scalable manner. Basically, aggregated traffic rate between two

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

   LSRs is easily measured by accounting of traffic sent onto a TE LSP
   provisioned between the two LSRs in question.

4.1.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

   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.

   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

4.1.3. Fast recovery within an area

   As traffic sensitive applications are deployed, one of the key
   requirements is to provide fast recovery mechanisms, allowing to
   guarantee 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 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

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

   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.2. Intra-area MPLS-TE and routing

   There are several possibilities to direct traffic into intra-area TE

        1) Static routing to the LSP destination address or any other
        2) Traffic to the destination of the TE LSP or somewhere
            beyond this destination from an IGP SPF perspective.
        3) 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-
           Adjacency, as defined in [LSP-HIER].
        4) Traffic sent to a set of 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
           (2) or by means of IGP SPF (3). This is often called BGP
           recursive routing.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

5. Problem Statement, Requirements and Objectives of inter-area MPLS-TE

5.1. Inter-Area Traffic Engineering Problem Statement

   As described in section 1, 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

   However, MPLS-TE mechanisms are currently limited to a single IGP
   area. 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.

   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

   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 in 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.
        - Inter-area traffic cannot be protected with local protection
          mechanisms such as [FAST-REROUTE] in case of ABR failure.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

 5.2. Requirements 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 1 across

   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 (i.e 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
   engineering. Information propagation for path-selection MUST continue
   to be localized. In other words, the solution MUST entirely preserve
   the concept of IGP hierarchy.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

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 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

   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

   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-01      May 2004

6. Application Scenario

   |       \   |  /        |         |
   | R0     \  | /         |      R4 |
   | R5      \ |/          |         |

   - 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

   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 to route 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 wire connections.

   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-01      May 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.

   If multiple signalling methods are proposed in the solution, the
   head-end LSR MUST have the ability to signal the required or desired
   method on a per-LSP basis.

   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

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

   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
   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.
   One solution could consist of extending the IGP for the leaking of
   summarized TE information across areas, but this would not scale: An
   ABR would have to compute and advertise summarized TE data for each
   potential destination and a large set of constraints combinations
   which would ineluctability have undesirable consequences in term of
   amount of flooded information and ABR CSPF computations.
   Thus, in order to maintain containment of routing information and
   preserve the overall IGP scalability, the solution MUST preclude the
   leaking across area of any TE link information summarized or not.

   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 follows:

      -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, that 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.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

7.6. Inter-area Crankback Routing

   Crankback routing, as defined in [CRANKBACK] may be used for inter-
   area TE-LSP. 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 perform ERO expansion.
   Note that such method does not allow computing and optimal path but
   just a feasible path.
   Note also that there can be 0(N^2) 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 an
   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-

   Hence, the solution SHOULD be able to provide the ability to compute
   diversely routed inter-area TE LSP paths. In particular, if such
   paths obeying the set of constraints exist, the solution SHOULD be
   able to compute them. For the sake of illustration, there are some
   algorithms that may not always allow to find diversely routed TE LSPs
   because they make use of a two steps approach that cannot guarantee
   to compute two diversely routed TE LSP paths even if such a solution
   exist. This is in contrast with other methods that simultaneously
   compute the set of diversely routed paths and that can always find
   such paths if they exist. Moreover, the solution SHOULD not require
   extra-load in signalling and routing in order to reach that

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 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 MUST 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 non
   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 inter-area head-end LSR 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.

   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

   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

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 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

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).

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].

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

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

   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].

   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).

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

   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 SHOULD clearly be evaluated with respects to the
   following criteria:
   (1) Optimality of the computed inter-area TE LSP path.
   (2) Optimality of the computed backup tunnel path protecting against
       the failure of an ABR, capability to share bandwidth among backup
       tunnels protecting independent facilities.
   (3) Inter-area TE LSP set up time.
   (4) RSVP-TE and IGP scalability (state impact, number of messages,
       message size)

   Other criteria may be added in further revisions of this document.

8.2. Complexity and risks

   The proposed solution(s) SHOULD not introduce unnecessary 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.

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 on end-point LSRs an ABRs only.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

9. Security Considerations

   Inter-area MPLS-TE does not raise any new security issue, beyond
   those of intra-area MPLS-TE.

10. Acknowledgements

   We would like to thank Dimitri Papadimitriou for its useful comments
   and suggestions.

11. Normative References

   [TE-REQ] Awduche et. al., "Requirements for Traffic Engineering
   over MPLS", RFC2702.

   [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", draft-ietf-isis-traffic-04.txt, work in progress.

   [RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC

   [FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
   for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt, work
   in progress.

   [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-05.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-01.txt, work in progress.

   [DSTE-REQ] Le faucheur, F., et al, “ Requirements for Support of
   Differentiated Services-aware MPLS Traffic Engineering”, RFC3564.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

   [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.

12. Informative References

   [MPLS-ARCH] Rosen, et. al., "Multiprotocol Label Switching
   Architecture", RFC 3031.

   [DIFF-ARCH] Blake, et. al., "An Architecture for Differentiated
   Services", RFC 2475.

   [DIFF-AF] Heinanen, et. al., "Assured Forwarding PHB Group", RFC

   [DIFF-EF] Davie, et. al., "An Expedited Forwarding PHB (Per-Hop
   Behavior)", RFC 3246.

   [MPLS-DIFF] Le Faucheur, et. al., "MPLS Support of Differentiated
   Services", RFC 3270.

   [TE-OVW] Awduche, et. al., "Overview and Principles of Internet
   Traffic Engineering", RFC 3272.

   [TE-APP] Boyle, et. al., "Applicability Statement of Traffic
   Engineering", RFC 3346.

   [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", draft-
   ietf-tewg-te-metric-igp-02.txt, work in progress.

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

Internet Draft  draft-ietf-tewg-interarea-mpls-te-req-01      May 2004

13. Editors' Address:

   Jean-Louis Le Roux
   France Telecom
   2, avenue Pierre-Marzin
   22307 Lannion Cedex

   Jean-Philippe Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   Email: jpv@cisco.com

   Jim Boyle
   Email: jboyle@pdnets.com

Full Copyright Statement

   "Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist its implementation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

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