4105
INFORMATIONAL
Requirements for Inter-Area MPLS Traffic Engineering
Authors: J.-L. Le Roux, J.-P. Vasseur, J. Boyle
Date: June 2005
Area: subip
Working Group: tewg
Stream: IETF
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. This memo provides information for the Internet community.
RFC 4105
INFORMATIONAL
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
<span class="h1">Requirements for Inter-Area MPLS Traffic Engineering</span>
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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Current Intra-Area Uses of MPLS Traffic Engineering .............<a href="#page-4">4</a>
<a href="#section-4.1">4.1</a>. Intra-Area MPLS Traffic Engineering Architecture ...........<a href="#page-4">4</a>
<a href="#section-4.2">4.2</a>. Intra-Area MPLS Traffic Engineering Applications ...........<a href="#page-4">4</a>
<a href="#section-4.2.1">4.2.1</a>. Intra-Area Resource Optimization ....................<a href="#page-4">4</a>
<a href="#section-4.2.2">4.2.2</a>. Intra-Area QoS Guarantees ...........................<a href="#page-5">5</a>
<a href="#section-4.2.3">4.2.3</a>. Fast Recovery within an IGP Area ....................<a href="#page-5">5</a>
<a href="#section-4.3">4.3</a>. Intra-Area MPLS TE and Routing .............................<a href="#page-6">6</a>
<a href="#section-5">5</a>. Problem Statement, Requirements, and Objectives of Inter-Area ...<a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Inter-Area Traffic Engineering Problem Statement ...........<a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Overview of Requirements for Inter-Area MPLS TE ............<a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. Key Objectives for an Inter-Area MPLS-TE Solution ..........<a href="#page-8">8</a>
<a href="#section-5.3.1">5.3.1</a>. Preserving the IGP Hierarchy Concept ................<a href="#page-8">8</a>
<a href="#section-5.3.2">5.3.2</a>. Preserving Scalability ..............................<a href="#page-8">8</a>
<a href="#section-6">6</a>. Application Scenario.............................................<a href="#page-9">9</a>
<span class="grey">Le Roux, et al. Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<a href="#section-7">7</a>. Detailed Requirements for Inter-Area MPLS TE ...................<a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Inter-Area MPLS TE Operations and Interoperability ........<a href="#page-10">10</a>
<a href="#section-7.2">7.2</a>. Inter-Area TE-LSP Signaling ...............................<a href="#page-10">10</a>
<a href="#section-7.3">7.3</a>. Path Optimality ...........................................<a href="#page-11">11</a>
<a href="#section-7.4">7.4</a>. Inter-Area MPLS-TE Routing ................................<a href="#page-11">11</a>
<a href="#section-7.5">7.5</a>. Inter-Area MPLS-TE Path Computation .......................<a href="#page-12">12</a>
<a href="#section-7.6">7.6</a>. Inter-Area Crankback Routing ..............................<a href="#page-12">12</a>
<a href="#section-7.7">7.7</a>. Support of Diversely-Routed Inter-Area TE LSPs ............<a href="#page-13">13</a>
<a href="#section-7.8">7.8</a>. Intra/Inter-Area Path Selection Policy ....................<a href="#page-13">13</a>
<a href="#section-7.9">7.9</a>. Reoptimization of Inter-Area TE LSP .......................<a href="#page-13">13</a>
<a href="#section-7.10">7.10</a>. Inter-Area LSP Recovery ..................................<a href="#page-14">14</a>
<a href="#section-7.10.1">7.10.1</a>. Rerouting of Inter-Area TE LSPs ..................<a href="#page-14">14</a>
<a href="#section-7.10.2">7.10.2</a>. Fast Recovery of Inter-Area TE LSP ...............<a href="#page-14">14</a>
<a href="#section-7.11">7.11</a>. DS-TE support ............................................<a href="#page-15">15</a>
<a href="#section-7.12">7.12</a>. Hierarchical LSP Support .................................<a href="#page-15">15</a>
<a href="#section-7.13">7.13</a>. Hard/Soft Preemption .....................................<a href="#page-15">15</a>
<a href="#section-7.14">7.14</a>. Auto-Discovery of TE Meshes ..............................<a href="#page-16">16</a>
<a href="#section-7.15">7.15</a>. Inter-Area MPLS TE Fault Management Requirements .........<a href="#page-16">16</a>
<a href="#section-7.16">7.16</a>. Inter-Area MPLS TE and Routing ...........................<a href="#page-16">16</a>
<a href="#section-8">8</a>. Evaluation criteria ............................................<a href="#page-17">17</a>
<a href="#section-8.1">8.1</a>. Performances ..............................................<a href="#page-17">17</a>
<a href="#section-8.2">8.2</a>. Complexity and Risks ......................................<a href="#page-17">17</a>
<a href="#section-8.3">8.3</a>. Backward Compatibility ....................................<a href="#page-17">17</a>
<a href="#section-9">9</a>. Security Considerations ........................................<a href="#page-17">17</a>
<a href="#section-10">10</a>. Acknowledgements ..............................................<a href="#page-17">17</a>
<a href="#section-11">11</a>. Contributing Authors ..........................................<a href="#page-18">18</a>
<a href="#section-12">12</a>. Normative References ..........................................<a href="#page-19">19</a>
<a href="#section-13">13</a>. Informative References ........................................<a href="#page-19">19</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The set of MPLS Traffic Engineering components, defined in [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>],
[<a href="#ref-OSPF-TE" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">OSPF-TE</a>], and [<a href="#ref-ISIS-TE" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">ISIS-TE</a>], which supports the requirements defined in
[<a href="#ref-TE-REQ" title=""Requirements for Traffic Engineering Over MPLS"">TE-REQ</a>], is used today by many network operators to achieve major
Traffic Engineering objectives defined in [<a href="#ref-TE-OVW" title=""Overview and Principles of Internet Traffic Engineering"">TE-OVW</a>]. 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 [<a href="#ref-TE-APP" title=""Applicability Statement for Traffic Engineering with MPLS"">TE-APP</a>].
The set of MPLS Traffic Engineering mechanisms, to date, has been
limited to use within a single Interior Gateway Protocol (IGP) area.
<span class="grey">Le Roux, et al. Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to indicate requirements levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
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.
<span class="grey">Le Roux, et al. Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Current Intra-Area Uses of MPLS Traffic Engineering</span>
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.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Intra-Area MPLS Traffic Engineering Architecture</span>
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:
[<a href="#ref-ISIS-TE" title=""Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)"">ISIS-TE</a>], [<a href="#ref-OSPF-TE" title=""Traffic Engineering (TE) Extensions to OSPF Version 2"">OSPF-TE</a>].
- 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 [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>].
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Intra-Area MPLS Traffic Engineering Applications</span>
<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>. Intra-Area Resource Optimization</span>
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.
<span class="grey">Le Roux, et al. Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>. Intra-Area QoS Guarantees</span>
The DiffServ IETF working group has defined a set of mechanisms
described in [<a href="#ref-DIFF-ARCH" title=""An Architecture for Differentiated Service"">DIFF-ARCH</a>], [<a href="#ref-DIFF-AF" title=""Assured Forwarding PHB Group"">DIFF-AF</a>], and [<a href="#ref-DIFF-EF" title=""An Expedited Forwarding PHB (Per-Hop Behavior)"">DIFF-EF</a>] or [<a href="#ref-MPLS-DIFF" title=""Multi-Protocol Label Switching (MPLS) Support of Differentiated Services"">MPLS-DIFF</a>],
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
[<a href="#ref-DSTE-PROTO" title=""Protocol Extensions for Support of Differentiated-Service-aware MPLS Traffic Engineering"">DSTE-PROTO</a>]. 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.
<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>. Fast Recovery within an IGP Area</span>
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 [<a href="#ref-MPLS-RECOV" title=""Framework for Multi- Protocol Label Switching (MPLS)-based Recovery"">MPLS-RECOV</a>]. 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
<span class="grey">Le Roux, et al. Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
failure along the LSP path [<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>]. Fast Reroute is currently
used by many operators to protect sensitive traffic inside an IGP
area.
[<a id="ref-FAST-REROUTE">FAST-REROUTE</a>] 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).
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Intra-Area MPLS TE and Routing</span>
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 [<a href="#ref-LSP-HIER" title=""LSP Hierarchy with Generalized MPLS TE"">LSP-HIER</a>]. 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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Problem Statement, Requirements, and Objectives of Inter-Area</span>
<span class="h2"> MPLS TE</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Inter-Area Traffic Engineering Problem Statement</span>
As described in <a href="#section-4">Section 4</a>, 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-
<span class="grey">Le Roux, et al. Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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 [<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>] in case of ABR failure.
Therefore, existing MPLS TE mechanisms have to be enhanced to support
inter-area TE LSPs.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Overview of Requirements for Inter-Area MPLS TE</span>
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 <a href="#section-4">Section 4</a> across
areas.
<span class="grey">Le Roux, et al. Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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).
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Key Objectives for an Inter-Area MPLS-TE Solution</span>
Any solution for inter-area MPLS TE should be designed with
preserving IGP hierarchy concept, and preserving routing and
signaling scalability as key objectives.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. Preserving the IGP Hierarchy Concept</span>
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.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. Preserving Scalability</span>
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.
<span class="grey">Le Roux, et al. Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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
([<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>]).
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 <a href="#section-5.2">Section 5.2</a>, 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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Application Scenario</span>
---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.
<span class="grey">Le Roux, et al. Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Detailed Requirements for Inter-Area MPLS TE</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Inter-Area MPLS TE Operations and Interoperability</span>
The inter-area MPLS TE solution MUST be consistent with requirements
discussed in [<a href="#ref-TE-REQ" title=""Requirements for Traffic Engineering Over MPLS"">TE-REQ</a>], and the derived solution MUST interoperate
seamlessly with current intra-area MPLS TE mechanisms and inherit its
capability sets from [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>].
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.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Inter-Area TE-LSP Signaling</span>
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.
<span class="grey">Le Roux, et al. Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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.
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Path Optimality</span>
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 [<a href="#ref-METRIC" title=""Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric"">METRIC</a>]. 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 <a href="#section-5.2">Section 5.2</a>, the solution SHOULD provide the
capability to compute an optimal path dynamically, satisfying a set
of specified constraints (defined in [<a href="#ref-TE-REQ" title=""Requirements for Traffic Engineering Over MPLS"">TE-REQ</a>]) 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.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Inter-Area MPLS-TE Routing</span>
As mentioned in <a href="#section-5.3">Section 5.3</a>, 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).
<span class="grey">Le Roux, et al. Informational [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Inter-Area MPLS-TE Path Computation</span>
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 <a href="#section-5.3">Section 5.3</a>.
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.
<span class="h3"><a class="selflink" id="section-7.6" href="#section-7.6">7.6</a>. Inter-Area Crankback Routing</span>
Crankback routing, as defined in [<a href="#ref-CRANKBACK" title=""Crankback Signaling Extensions for MPLS Signaling"">CRANKBACK</a>], 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 [<a href="#ref-CRANKBACK" title=""Crankback Signaling Extensions for MPLS Signaling"">CRANKBACK</a>]. A solution
that does, MUST allow [<a href="#ref-CRANKBACK" title=""Crankback Signaling Extensions for MPLS Signaling"">CRANKBACK</a>] to be activated/deactivated via
signaling, on a per-LSP basis.
<span class="grey">Le Roux, et al. Informational [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h3"><a class="selflink" id="section-7.7" href="#section-7.7">7.7</a>. Support of Diversely-Routed Inter-Area TE LSPs</span>
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.
<span class="h3"><a class="selflink" id="section-7.8" href="#section-7.8">7.8</a>. Intra/Inter-Area Path Selection Policy</span>
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.
<span class="h3"><a class="selflink" id="section-7.9" href="#section-7.9">7.9</a>. Reoptimization of Inter-Area TE LSP</span>
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.
<span class="grey">Le Roux, et al. Informational [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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.
<span class="h3"><a class="selflink" id="section-7.10" href="#section-7.10">7.10</a>. Inter-Area LSP Recovery</span>
<span class="h4"><a class="selflink" id="section-7.10.1" href="#section-7.10.1">7.10.1</a>. Rerouting of Inter-Area TE LSPs</span>
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 <a href="#section-7.6">Section 7.6</a>, on
crankback).
<span class="h4"><a class="selflink" id="section-7.10.2" href="#section-7.10.2">7.10.2</a>. Fast Recovery of Inter-Area TE LSP</span>
The solution MUST provide the ability to benefit from fast recovery,
making use of the local protection techniques specified in
[<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>] 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
<span class="grey">Le Roux, et al. Informational [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
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 [<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>] may
lead to higher bandwidth consumption and higher recovery delays. The
use of [<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>] 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.
<span class="h3"><a class="selflink" id="section-7.11" href="#section-7.11">7.11</a>. DS-TE support</span>
The proposed inter-area MPLS TE solution SHOULD also satisfy core
requirements documented in [<a href="#ref-DSTE-REQ" title=""Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering"">DSTE-REQ</a>] and interoperate seamlessly
with current intra-area MPLS DS-TE mechanism [<a href="#ref-DSTE-PROTO" title=""Protocol Extensions for Support of Differentiated-Service-aware MPLS Traffic Engineering"">DSTE-PROTO</a>].
<span class="h3"><a class="selflink" id="section-7.12" href="#section-7.12">7.12</a>. Hierarchical LSP Support</span>
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 [<a href="#ref-LSP-HIER" title=""LSP Hierarchy with Generalized MPLS TE"">LSP-HIER</a>].
<span class="h3"><a class="selflink" id="section-7.13" href="#section-7.13">7.13</a>. Hard/Soft Preemption</span>
As defined in [<a href="#ref-MPLS-PREEMPT" title=""Interim Report on MPLS Pre-emption"">MPLS-PREEMPT</a>], 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 <a href="#section-7.10.1">Section 7.10.1</a>.
<span class="grey">Le Roux, et al. Informational [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
In the case of soft preemption, the preempted inter-area TE LSP
should be re-optimized, following requirements defined in <a href="#section-7.9">Section</a>
<a href="#section-7.9">7.9</a>.
<span class="h3"><a class="selflink" id="section-7.14" href="#section-7.14">7.14</a>. Auto-Discovery of TE Meshes</span>
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.
<span class="h3"><a class="selflink" id="section-7.15" href="#section-7.15">7.15</a>. Inter-Area MPLS TE Fault Management Requirements</span>
The proposed solution SHOULD be able to interoperate with fault
detection mechanisms of intra-area MPLS TE.
The solution SHOULD support [<a href="#ref-LSP-PING" title=""Detecting Data Plane Liveliness in MPLS"">LSP-PING</a>] and [<a href="#ref-MPLS-TTL" title=""Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks"">MPLS-TTL</a>].
The solution SHOULD also support fault detection on backup LSPs, in
case [<a href="#ref-FAST-REROUTE" title=""Fast Reroute Extensions to RSVP-TE for LSP Tunnels"">FAST-REROUTE</a>] is deployed.
<span class="h3"><a class="selflink" id="section-7.16" href="#section-7.16">7.16</a>. Inter-Area MPLS TE and Routing</span>
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 <a href="#section-4.2">Section 4.2</a>.
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.
<span class="grey">Le Roux, et al. Informational [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Evaluation criteria</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Performances</span>
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).
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Complexity and Risks</span>
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.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Backward Compatibility</span>
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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document does not introduce new security issues beyond those
inherent in MPLS TE [<a href="#ref-RSVP-TE" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RSVP-TE</a>] 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.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgements</span>
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal
Sharma, and Arthi Ayyangar for their useful comments and suggestions.
<span class="grey">Le Roux, et al. Informational [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Contributing Authors</span>
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 <a href="#section-14">Section 14</a> 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: [email protected] EMail: [email protected]
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: [email protected] EMail: [email protected]
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460,
JAPAN
EMail: [email protected]
<span class="grey">Le Roux, et al. Informational [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-TE-REQ">TE-REQ</a>] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", <a href="./rfc2702">RFC 2702</a>, September 1999.
[<a id="ref-DSTE-REQ">DSTE-REQ</a>] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", <a href="./rfc3564">RFC 3564</a>, July 2003.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. Informative References</span>
[<a id="ref-TE-OVW">TE-OVW</a>] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
X. Xiao, "Overview and Principles of Internet Traffic
Engineering", <a href="./rfc3272">RFC 3272</a>, May 2002.
[<a id="ref-RSVP-TE">RSVP-TE</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-OSPF-TE">OSPF-TE</a>] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", <a href="./rfc3630">RFC</a>
<a href="./rfc3630">3630</a>, September 2003.
[<a id="ref-ISIS-TE">ISIS-TE</a>] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", <a href="./rfc3784">RFC 3784</a>, June 2004.
[<a id="ref-TE-APP">TE-APP</a>] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche,
D., Christian, B., and W. Lai, "Applicability
Statement for Traffic Engineering with MPLS", <a href="./rfc3346">RFC</a>
<a href="./rfc3346">3346</a>, August 2002.
[<a id="ref-FAST-REROUTE">FAST-REROUTE</a>] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
<a href="./rfc4090">RFC 4090</a>, May 2005.
[<a id="ref-LSP-PING">LSP-PING</a>] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
G., Wadhwa, S., Bonica, R., "Detecting Data Plane
Liveliness in MPLS", Work in Progress.
[<a id="ref-MPLS-TTL">MPLS-TTL</a>] Agarwal, P. and B. Akyol, "Time To Live (TTL)
Processing in Multi-Protocol Label Switching (MPLS)
Networks", <a href="./rfc3443">RFC 3443</a>, January 2003.
<span class="grey">Le Roux, et al. Informational [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
[<a id="ref-LSP-HIER">LSP-HIER</a>] Kompella, K., and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", Work in Progress.
[<a id="ref-MPLS-RECOV">MPLS-RECOV</a>] Sharma, V. and F. Hellstrand, "Framework for Multi-
Protocol Label Switching (MPLS)-based Recovery", <a href="./rfc3469">RFC</a>
<a href="./rfc3469">3469</a>, February 2003.
[<a id="ref-CRANKBACK">CRANKBACK</a>] Farrel, A., Ed., "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress.
[<a id="ref-MPLS-DIFF">MPLS-DIFF</a>] 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", <a href="./rfc3270">RFC 3270</a>, May
2002.
[<a id="ref-DSTE-PROTO">DSTE-PROTO</a>] Le Faucheur, F., et al., "Protocol Extensions for
Support of Differentiated-Service-aware MPLS Traffic
Engineering", Work in Progress.
[<a id="ref-DIFF-ARCH">DIFF-ARCH</a>] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", <a href="./rfc2475">RFC 2475</a>, December 1998.
[<a id="ref-DIFF-AF">DIFF-AF</a>] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", <a href="./rfc2597">RFC 2597</a>, June 1999.
[<a id="ref-DIFF-EF">DIFF-EF</a>] 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)", <a href="./rfc3246">RFC 3246</a>, March 2002.
[<a id="ref-MPLS-PREEMPT">MPLS-PREEMPT</a>] Farrel, A., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Interim+Report+on+MPLS+Pre-emption%22'>"Interim Report on MPLS Pre-emption"</a>, Work
in Progress.
[<a id="ref-METRIC">METRIC</a>] 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", <a href="https://www.rfc-editor.org/bcp/bcp87">BCP 87</a>, <a href="./rfc3785">RFC 3785</a>, May 2004.
<span class="grey">Le Roux, et al. Informational [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>. Editors' Addresses</span>
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: [email protected]
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA - 01719
USA
EMail: [email protected]
Jim Boyle
EMail: [email protected]
<span class="grey">Le Roux, et al. Informational [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc4105">RFC 4105</a> Inter-Area MPLS TE Reqs June 2005</span>
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Le Roux, et al. Informational [Page 22]
Annotations
Select text to annotate