doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc4105.txt b/doc/rfc/rfc4105.txt
new file mode 100644
index 0000000..676fde9
--- /dev/null
+++ b/doc/rfc/rfc4105.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                 J.-L. Le Roux, Ed.
+Request for Comments: 4105                                France Telecom
+Category: Informational                               J.-P. Vasseur, Ed.
+                                                     Cisco Systems, Inc.
+                                                           J. Boyle, Ed.
+                                                                  PDNETs
+                                                               June 2005
+
+
+         Requirements for Inter-Area MPLS Traffic Engineering
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+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.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................3
+   3. Terminology .....................................................3
+   4. Current Intra-Area Uses of MPLS Traffic Engineering .............4
+      4.1. Intra-Area MPLS Traffic Engineering Architecture ...........4
+      4.2. Intra-Area MPLS Traffic Engineering Applications ...........4
+           4.2.1. Intra-Area Resource Optimization ....................4
+           4.2.2. Intra-Area QoS Guarantees ...........................5
+           4.2.3. Fast Recovery within an IGP Area ....................5
+      4.3. Intra-Area MPLS TE and Routing .............................6
+   5. Problem Statement, Requirements, and Objectives of Inter-Area ...6
+      5.1. Inter-Area Traffic Engineering Problem Statement ...........6
+      5.2. Overview of Requirements for Inter-Area MPLS TE ............7
+      5.3. Key Objectives for an Inter-Area MPLS-TE Solution ..........8
+           5.3.1. Preserving the IGP Hierarchy Concept ................8
+           5.3.2. Preserving Scalability ..............................8
+   6. Application Scenario.............................................9
+
+
+
+
+Le Roux, et al.              Informational                      [Page 1]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   7. Detailed Requirements for Inter-Area MPLS TE ...................10
+      7.1. Inter-Area MPLS TE Operations and Interoperability ........10
+      7.2. Inter-Area TE-LSP Signaling ...............................10
+      7.3. Path Optimality ...........................................11
+      7.4. Inter-Area MPLS-TE Routing ................................11
+      7.5. Inter-Area MPLS-TE Path Computation .......................12
+      7.6. Inter-Area Crankback Routing ..............................12
+      7.7. Support of Diversely-Routed Inter-Area TE LSPs ............13
+      7.8. Intra/Inter-Area Path Selection Policy ....................13
+      7.9. Reoptimization of Inter-Area TE LSP .......................13
+      7.10. Inter-Area LSP Recovery ..................................14
+            7.10.1. Rerouting of Inter-Area TE LSPs ..................14
+            7.10.2. Fast Recovery of Inter-Area TE LSP ...............14
+      7.11. DS-TE support ............................................15
+      7.12. Hierarchical LSP Support .................................15
+      7.13. Hard/Soft Preemption .....................................15
+      7.14. Auto-Discovery of TE Meshes ..............................16
+      7.15. Inter-Area MPLS TE Fault Management Requirements .........16
+      7.16. Inter-Area MPLS TE and Routing ...........................16
+   8. Evaluation criteria ............................................17
+      8.1. Performances ..............................................17
+      8.2. Complexity and Risks ......................................17
+      8.3. Backward Compatibility ....................................17
+   9. Security Considerations ........................................17
+   10. Acknowledgements ..............................................17
+   11. Contributing Authors ..........................................18
+   12. Normative References ..........................................19
+   13. Informative References ........................................19
+
+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].  These objectives
+   include:
+
+      - Aggregated Traffic measurement
+      - Optimization of network resources utilization
+      - Support for services requiring end-to-end QoS guarantees
+      - Fast recovery against link/node/Shared Risk Link Group (SRLG)
+        failures
+
+   Furthermore, the applicability of MPLS to traffic engineering in IP
+   networks is discussed in [TE-APP].
+
+   The set of MPLS Traffic Engineering mechanisms, to date, has been
+   limited to use within a single Interior Gateway Protocol (IGP) area.
+
+
+
+Le Roux, et al.              Informational                      [Page 2]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   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 Area Border
+   Router (ABR) failures.
+
+   First, this document addresses current uses of MPLS Traffic
+   Engineering within a single IGP area.  Then, it discusses a set of
+   functional requirements that a solution must or should satisfy in
+   order to support inter-area MPLS Traffic Engineering.  Because 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.
+
+2.  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 [RFC2119].
+
+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 whose head-end
+                      LSR and tail-end LSR are both in the same IGP area
+                      although the TE-LSP transiting path is across
+                      different IGP areas.
+
+   IGP area:          OSPF area or IS-IS level.
+
+   ABR:               Area Border Router, a 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.
+
+
+
+
+Le Roux, et al.              Informational                      [Page 3]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+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 define 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 paths follow 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 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 signaling 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].
+
+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.  On 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 administrative constraints
+   such as bandwidth.  In this way, MPLS TE allows for greater control
+   over how traffic demands are routed over a network topology and
+   utilize a network's resources.
+
+   Note also that TE LSPs allow measuring traffic matrix in a simple and
+   scalable manner.  The 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.
+
+
+
+
+Le Roux, et al.              Informational                      [Page 4]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+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 of or over a DiffServ domain to
+   contribute to the enforcement of a QoS policy (or set of policies),
+   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 its edge.
+
+   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, which are defined in
+   [DSTE-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, which satisfy
+   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, which satisfies
+   various constraints, such as bandwidth.
+
+4.2.3.  Fast Recovery within an IGP Area
+
+   As quality-sensitive applications are deployed, one of the key
+   requirements is to provide fast recovery mechanisms, allowing traffic
+   recovery to be guaranteed 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
+
+
+
+Le Roux, et al.              Informational                      [Page 5]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   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, called
+   one-to-one backup, consists of setting up one detour LSP per
+   protected LSP and per element to protect.  The second, called
+   facility backup, consists of 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 for directing 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 BGP peer (or an 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 can be 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].  Forwarding-Adjacency is when 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 more from the Routing and Path
+   computation components than from the signaling component.  This is
+   basically because the hierarchy limits topology visibility of head-
+
+
+
+Le Roux, et al.              Informational                      [Page 6]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   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.
+
+   Thus, 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 not lead to efficient traffic engineering.  Actually, this per-
+     area TE approach might lead to sub-optimal resource utilization, by
+     optimizing resources independently in each area.  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.
+
+   Therefore, existing MPLS TE mechanisms have to be enhanced to support
+   inter-area TE LSPs.
+
+5.2.  Overview of 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 4 across
+   areas.
+
+
+
+
+Le Roux, et al.              Informational                      [Page 7]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   The solution MUST allow setting up inter-area TE LSPs; i.e., LSPs
+   whose path crosses at least two IGP areas.
+
+   Inter-area MPLS-TE extensions are highly desired in order to provide:
+
+   - Inter-area resources optimization.
+   - Strict inter-area QoS guarantees.
+   - Fast recovery across areas, particularly to protect inter-area
+     traffic against ABR failures.
+
+   It may be desired to compute inter-area shortest paths that satisfy
+   some bandwidth constraints or any other constraints, as is currently
+   possible within a single IGP area.  For the sake of illustration, if
+   the IGP metrics reflects the propagation delay, it may be necessary
+   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 with
+   preserving IGP hierarchy concept, and preserving routing and
+   signaling scalability as key objectives.
+
+5.3.1.  Preserving 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.
+
+5.3.2.  Preserving Scalability
+
+   Achieving 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.
+
+
+
+Le Roux, et al.              Informational                      [Page 8]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   The solution also MUST not increase IGP load unreasonably, which
+   could compromise IGP scalability.  In particular, a solution
+   satisfying those requirements MUST not require 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 no real 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 be
+   neither excessive, patchwork, nor non-relevant.
+
+   Particularly, as mentioned in Section 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 such as
+   bandwidth.  This may require an additional routing mechanism, as base
+   CSPF at head-end can no longer be used due to the lack of topology
+   and resource information.  Such a routing mechanism MUST not
+   compromise the scalability of the overall system.
+
+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.
+
+
+
+
+
+
+Le Roux, et al.              Informational                      [Page 9]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   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 set up from R1
+   to R4 to route VoIP traffic classified as EF.  Per-class inter-area
+   constraint-based routing allows the DS-TE LSP to be routed 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 set up 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).  There may be cases where there are no longer enough
+   resources on any intra area path R0-to-R5, and where there is a
+   feasible inter-area path through the backbone area.
+
+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 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 signaling (potentially with loose paths) traversing
+   across the interconnected ABRs, without further provisioning required
+   along the transit path.
+
+7.2.  Inter-Area TE-LSP Signaling
+
+   The solution MUST allow for the signaling 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
+   specify a set of LSRs explicitly, including ABRs, by means of strict
+   or loose hops for the inter-area TE LSP.
+
+
+
+Le Roux, et al.              Informational                     [Page 10]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   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 by making use of some
+   CSPF algorithm in the absence of multiple IGP areas.
+
+   As mentioned in Section 5.2, the solution SHOULD provide the
+   capability to compute an optimal path dynamically, 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 that do not guarantee an optimal end-to-end path,
+   whereas some other inter-area TE-LSP paths carrying sensitive traffic
+   could be computed by making use of mechanisms allowing an optimal
+   end-to-end path to be computed dynamically.  Note that regular
+   constraints such as 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 mentioned in Section 5.3, IGP hierarchy does not allow the head-
+   end LSR to compute an end-to-end optimal path.  Additional mechanisms
+   are required to compute an optimal path.  These mechanisms MUST not
+   alter the IGP hierarchy principles.  Particularly, in order to
+   maintain containment of routing information and to preserve the
+   overall IGP scalability, the solution SHOULD avoid any dynamic-TE-
+   topology-related information from leaking across areas, even in a
+   summarized form.
+
+   Conversely, this does not preclude the leaking of non-topology-
+   related information that is not taken into account during path
+   selection, such as static TE Node information (TE router ids or TE
+   node capabilities).
+
+
+
+
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 11]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+7.5.  Inter-Area MPLS-TE Path Computation
+
+   Several methods may be used for path computation, including the
+   following:
+
+   - Per-area path computation based on ERO expansion on the head-end
+     LSR and on ABRs, with two options for ABR selection:
+
+         1) Static configuration of ABRs as loose hops at the head-end
+            LSR.
+         2) Dynamic ABR selection.
+
+   - Inter-area end-to-end path computation, which may be based on (for
+     instance) 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 Section 5.3.
+
+   If 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.  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.
+
+   Note that this method does not allow computing an 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.  If 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
+   the LSP locally.
+
+   An inter-area MPLS-TE solution MAY support [CRANKBACK].  A solution
+   that does, MUST allow [CRANKBACK] to be activated/deactivated via
+   signaling, on a per-LSP basis.
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 12]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+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 the 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 cannot be found between two end-points, a solution would
+   consist of setting up multiple TE LSPs so 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.
+
+   Thus, the solution MUST be able to establish diversely-routed inter-
+   area TE LSPs when diverse paths exist.  It MUST support all kinds of
+   diversity (link, node, SRLG).
+
+   The solution SHOULD allow computing an optimal placement of
+   diversely-routed LSPs.  There may be various criteria to determine an
+   optimal placement.  For instance, the placement of two diversely
+   routed LSPs for load-balancing purposes may consist of minimizing
+   their cumulative cost.  The placement of two diversely-routed LSPs
+   for protection purposes may consist of minimizing the cost of the
+   primary LSP while bounding the cost or hop count of the backup LSP.
+
+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.
+   If the shortest path is an inter-area path, an operator either may
+   want to avoid, as far as possible, crossing area and thus may 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 IGP area crossing to be enabled/disabled, 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 parameterize such a reoptimization according to a
+   timer or event-driven basis.  It should also be possible to trigger
+   such a reoptimization manually.
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 13]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   The solution SHOULD provide the ability to reoptimize an inter-area
+   TE LSP locally within an area; i.e., while 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 on a timer or event driven basis.  The option
+   of a 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 for activating/deactivating ABR control of reoptimization, via
+   signaling on a per LSP-basis.
+
+   The solution SHOULD also provide the ability to perform an end-to-end
+   reoptimization, potentially resulting in a change on the set of
+   transit ABRs.  Such reoptimization can only be controlled by the
+   Head-End LSR.
+
+   In the 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 over the reoptimization process.  Thus, the
+   inter-area head-end LSR, once informed of a more optimal path in some
+   downstream IGP areas, could decide to perform a make-before-break
+   reoptimization gracefully (or not to), according to the inter-area
+   TE-LSP characteristics.
+
+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 preemption.  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] both in the case of an intra-area network element
+   failure (link/SRLG/node) and in that of 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, particularly in the case of an ABR node failure,
+   as this node 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
+
+
+
+Le Roux, et al.              Informational                     [Page 14]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   during failure, along with other potential constraints (such as
+   bounded propagation delay increase along the backup path).
+
+   The solution SHOULD allow ABRs to be protected, while providing the
+   same level of performances (recovery delay, bandwidth consumption) as
+   provided today within an area.
+
+   Note that some signaling 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, 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, although ensuring the same
+   level of performances, currently requires a single end-to-end RSVP
+   session (contiguous LSP) to be used, without any intra-area LSP.
+   Thus, the solution MUST provide the ability, via signalling on a
+   per-LSP basis, to allow or preclude the use of intra-area LSPs to
+   support the inter-area LSPs.
+
+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 the case of a large inter-area MPLS deployment, potentially
+   involving a large number of LSRs, it may be desirable/necessary to
+   introduce some level of hierarchy in order to reduce the number of
+   states on LSRs (such a solution implies other challenges).  Thus, the
+   proposed solution SHOULD allow inter-area TE-LSP aggregation (also
+   referred to as LSP nesting) so that individual TE LSPs can be carried
+   onto one or more aggregating LSPs.  One such mechanism, for example,
+   is described in [LSP-HIER].
+
+7.13.  Hard/Soft Preemption
+
+   As defined in [MPLS-PREEMPT], two preemption models are applicable to
+   MPLS: Soft and Hard Preemption.
+
+   An inter-area MPLS-TE solution SHOULD support the two models.
+
+   In the case of hard preemption, the preempted inter-area TE LSP
+   should be rerouted, following requirements defined in Section 7.10.1.
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 15]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   In the case of soft preemption, the preempted 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 that are 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 discover automatically 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 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 for routing traffic into an intra-area TE LSP.  They
+   are listed in Section 4.2.
+
+   In the 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 reachability information (summary LSA in OSPF and
+   IP reachability 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, in
+   order 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.
+
+
+
+Le Roux, et al.              Informational                     [Page 16]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+8.  Evaluation criteria
+
+8.1.  Performances
+
+   The solution will be evaluated with respect 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-area backup LSPs
+       protecting independent facilities.
+   (3) Inter-area TE-LSP setup time (in msec).
+   (4) RSVP-TE and IGP scalability (state impact, number of messages,
+       message size).
+
+8.2.  Complexity and Risks
+
+   The proposed solution 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 a solution over SP
+   networks.
+
+8.3.  Backward Compatibility
+
+   In order to allow for a smooth migration or co-existence, the
+   deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE
+   mechanisms.  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 purposes, the solution MAY
+   require inter-area extensions only on end-point LSRs, on ABRs, and,
+   potentially, on Points of Local Repair (PLR) protecting an ABR.
+
+9.  Security Considerations
+
+   This document does not introduce new security issues beyond those
+   inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may
+   use the same mechanisms proposed for that 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.
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 17]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+11.  Contributing Authors
+
+   This document was the collective work of several authors.  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 14 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      EMail: parantap.lahiri@mci.com
+
+
+   Kenji Kumaki
+   KDDI Corporation
+   Garden Air Tower
+   Iidabashi, Chiyoda-ku,
+   Tokyo 102-8460,
+   JAPAN
+
+   EMail: ke-kumaki@kddi.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 18]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+12.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to indicate
+                  requirements levels", RFC 2119, March 1997.
+
+   [TE-REQ]       Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
+                  J. McManus, "Requirements for Traffic Engineering Over
+                  MPLS", RFC 2702, September 1999.
+
+   [DSTE-REQ]     Le Faucheur, F. and W. Lai, "Requirements for Support
+                  of Differentiated Services-aware MPLS Traffic
+                  Engineering", RFC 3564, July 2003.
+
+13.  Informative References
+
+   [TE-OVW]       Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
+                  X. Xiao, "Overview and Principles of Internet Traffic
+                  Engineering", RFC 3272, May 2002.
+
+   [RSVP-TE]      Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
+                  V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
+                  LSP Tunnels", RFC 3209, December 2001.
+
+   [OSPF-TE]      Katz, D., Kompella, K., and D. Yeung, "Traffic
+                  Engineering (TE) Extensions to OSPF Version 2", RFC
+                  3630, September 2003.
+
+   [ISIS-TE]      Smit, H. and T. Li, "Intermediate System to
+                  Intermediate System (IS-IS) Extensions for Traffic
+                  Engineering (TE)", RFC 3784, June 2004.
+
+   [TE-APP]       Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche,
+                  D., Christian, B., and W. Lai, "Applicability
+                  Statement for Traffic Engineering with MPLS", RFC
+                  3346, August 2002.
+
+   [FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
+                  "Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
+                  RFC 4090, May 2005.
+
+   [LSP-PING]     Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
+                  G., Wadhwa, S., Bonica, R., "Detecting Data Plane
+                  Liveliness in MPLS", Work in Progress.
+
+   [MPLS-TTL]     Agarwal, P. and B. Akyol, "Time To Live (TTL)
+                  Processing in Multi-Protocol Label Switching (MPLS)
+                  Networks", RFC 3443, January 2003.
+
+
+
+
+Le Roux, et al.              Informational                     [Page 19]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+   [LSP-HIER]     Kompella, K., and Y. Rekhter, "LSP Hierarchy with
+                  Generalized MPLS TE", Work in Progress.
+
+   [MPLS-RECOV]   Sharma, V. and F. Hellstrand, "Framework for Multi-
+                  Protocol Label Switching (MPLS)-based Recovery", RFC
+                  3469, February 2003.
+
+   [CRANKBACK]    Farrel, A., Ed., "Crankback Signaling Extensions for
+                  MPLS Signaling", Work in Progress.
+
+   [MPLS-DIFF]    Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
+                  Vaananen, P., Krishnan, R., Cheval, P., and J.
+                  Heinanen, "Multi-Protocol Label Switching (MPLS)
+                  Support of Differentiated Services", RFC 3270, May
+                  2002.
+
+   [DSTE-PROTO]   Le Faucheur, F., et al., "Protocol Extensions for
+                  Support of Differentiated-Service-aware MPLS Traffic
+                  Engineering",  Work in Progress.
+
+   [DIFF-ARCH]    Blake, S., Black, D., Carlson, M., Davies, E., Wang,
+                  Z., and W. Weiss, "An Architecture for Differentiated
+                  Service", RFC 2475, December 1998.
+
+   [DIFF-AF]      Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+                  "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [DIFF-EF]      Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
+                  Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
+                  D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+                  Behavior)", RFC 3246, March 2002.
+
+   [MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work
+                  in Progress.
+
+   [METRIC]       Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
+                  and T. Telkamp, "Use of Interior Gateway Protocol
+                  (IGP) Metric as a second MPLS Traffic Engineering (TE)
+                  Metric", BCP 87, RFC 3785, May 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 20]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+14.  Editors' Addresses
+
+   Jean-Louis Le Roux
+   France Telecom
+   2, avenue Pierre-Marzin
+   22307 Lannion Cedex
+   France
+
+   EMail: jeanlouis.leroux@francetelecom.com
+
+
+   Jean-Philippe Vasseur
+   Cisco Systems, Inc.
+   300 Beaver Brook Road
+   Boxborough, MA - 01719
+   USA
+
+   EMail: jpv@cisco.com
+
+
+   Jim Boyle
+
+   EMail: jboyle@pdnets.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 21]
+
+RFC 4105                Inter-Area MPLS TE Reqs                June 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   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,
+   INCLUDING 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.
+
+Intellectual Property
+
+   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 to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Le Roux, et al.              Informational                     [Page 22]
+