TEWG Working Group JL Le Roux,(Ed.)
Internet Draft France Telecom
JP Vasseur, (Ed.)
Cisco System Inc.
Jim Boyle, (Ed.)
PDNETs
Category: Informational
Expires: November 2004 June 2004
Requirements for Inter-area MPLS Traffic Engineering
draft-ietf-tewg-interarea-mpls-te-req-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document lists a detailed set of functional requirements for the
support of inter-area MPLS Traffic Engineering (inter-area MPLS TE).
It is intended that solutions that specify procedures and protocol
extensions for inter-area MPLS-TE satisfy these requirements.
Le Roux, et. al. Informational - Expires November 2004 [Page 1]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
Table of Contents
1. Introduction................................................3
2. Contributing Authors........................................4
3. Terminology.................................................5
4. Current intra-area uses of MPLS Traffic Engineering.........5
4.1. Intra-area MPLS Traffic Engineering Architecture............5
4.2. Intra-area MPLS Traffic Engineering Applications............6
4.2.1. Intra-area resource optimization............................6
4.2.2. Intra-area QoS guarantees...................................6
4.2.3. Fast recovery within an area................................7
4.3. Intra-area MPLS-TE and routing..............................7
5. Problem Statement, Requirements and Objectives of inter
area MPLS-TE..............................................8
5.1. Inter-Area Traffic Engineering Problem Statement............8
5.2. Motivations for inter-area MPLS-TE..........................9
5.3. Key Objectives for an inter-area MPLS-TE solution...........9
5.3.1. Preserve the IGP hierarchy concept..........................9
5.3.2. Preserve Scalability.......................................10
6. Application Scenario.......................................11
7. Detailed requirements for inter-area MPLS-TE...............12
7.1. Inter-area MPLS TE operations and interoperability.........12
7.2. Inter-Area TE-LSP signalling...............................12
7.3. Path optimality............................................12
7.4. Inter-Area MPLS-TE Routing.................................13
7.5. Inter-Area MPLS-TE Path computation........................13
7.6. Inter-area Crankback Routing...............................13
7.7. Support of diversely routed inter-area TE LSPs.............14
7.8. Intra/Inter-area Path selection policy.....................15
7.9. Reoptimization of inter-area TE LSP........................15
7.10. Inter-area LSP Recovery....................................16
7.10.1. Rerouting of inter-area TE LSPs................... ........16
7.10.2. Fast recovery of inter-area TE LSP................ ........16
7.11. DS-TE support..............................................17
7.12. Hierarchical LSP support...................................17
7.13. Hard/Soft pre-emption......................................17
7.14. Auto-discovery of TE meshes................................17
7.15. Inter-area MPLS TE fault management requirements...........17
7.16. Inter-area MPLS-TE and routing.............................18
8. Evaluation criteria........................................18
8.1. Performances...............................................18
8.2. Complexity and risks.......................................18
8.3. Backward Compatibility.....................................19
9. Security Considerations....................................19
10. Acknowledgements...........................................19
Le Roux, et. al. Informational - Expires November 2004 [Page 2]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
11. Normative References.......................................19
12. Informative References.....................................19
13. Intellectual Property Statement............................21
14. Editors' Address:..........................................21
1. Introduction
The set of MPLS Traffic Engineering components, defined in [RSVP-TE],
[OSPF-TE] and [ISIS-TE], which supports the requirements defined in
[TE-REQ], is used today by many network operators to achieve major
Traffic Engineering objectives defined in [TE-OVW] and summarized
below:
-Aggregated Traffic measurement
-Optimization of network resources utilization
-Support for services requiring end-to-end QoS guarantees
-Fast recovery against link/node/SRLG failures
However, the current set of MPLS Traffic Engineering components have
to date been limited to use within a single IGP area.
This document discusses the requirements for an inter-area MPLS
Traffic Engineering mechanism that may be used to achieve the same
set of objectives across multiple IGP areas.
Basically, it would be useful to extend MPLS TE capabilities across
IGP areas to support inter-area resources optimization, to provide
strict QoS guarantees between two edge routers located within
distinct areas, and to protect inter-area traffic against ABR
failures.
This document firstly addresses current uses of MPLS Traffic
Engineering within a single IGP area. This helps, then, in discussing
a set of functional requirements a solution must or should satisfy in
order to support inter-area MPLS Traffic Engineering. Since the scope
of requirements will vary between operators, some requirements will
be mandatory (MUST) whereas others will be optional (SHOULD).
Finally, a set of evaluation criteria for any solution meeting these
requirements is given.
Le Roux, et. al. Informational - Expires November 2004 [Page 3]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
2. Contributing Authors
This document was the collective work of several. The text and
content of this document was contributed by the editors and the
co-authors listed below (The contact information for the editors
appears in section 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 E-mail: parantap.lahiri@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460,
JAPAN
E-mail : ke-kumaki@kddi.com
Le Roux, et. al. Informational - Expires November 2004 [Page 4]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
3. Terminology
LSR: Label Switching Router
TE-LSP: MPLS Traffic Engineering Label Switched Path
Inter-area TE-LSP : TE-LSP whose head-end LSR and tail-end LSR do
not reside within the same IGP area or both head-end
LSR and tail-end LSR are in the same IGP area but the TE LSP
transiting path may be across different IGP areas.
IGP area: OSPF area or IS-IS level.
ABR: Area Border Router, router used to connect two IGP areas (ABR in
OSPF or L1/L2 router in IS-IS).
CSPF: Constraint-based Shortest Path First.
4. Current intra-area uses of MPLS Traffic Engineering
This section addresses architecture, capabilities and uses of MPLS-TE
within a single IGP area. It first summarizes the current MPLS-TE
architecture, then addresses various MPLS-TE capabilities, and
finally lists various approaches to integrate MPLS-TE into routing.
This section is intended to help defining the requirements for MPLS-
TE extensions across multiple IGP areas.
4.1. Intra-area MPLS Traffic Engineering Architecture
The MPLS-TE control plane allows establishing explicitly routed MPLS
LSPs whose path obeys a set of TE constraints. It is used to achieve
major TE objectives such as resource usage optimization, QoS
guarantee and fast failure recovery. It basically consists of three
main components:
-The Routing component, responsible for the discovery of the TE
topology. This is ensured thanks to extensions of link state
IGP:[ISIS-TE], [OSPF-TE].
-The Path Computation component, responsible for the placement
of the LSP. It is performed on the Head-End LSR thanks to a
CSPF algorithm, which takes TE topology and LSP Constraints
as input.
-The Signalling component, responsible for the establishment of
the LSP (explicit routing, label distribution
an resources reservation) along the computed path. This is
ensured thanks to [RSVP-TE]
Le Roux, et. al. Informational - Expires November 2004 [Page 5]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
4.2. Intra-area MPLS Traffic Engineering Applications
4.2.1. Intra-area resource optimization
MPLS-TE can be used within an area to redirect paths of aggregated
flows away from over-utilized resources within a network. In a small
scale, this may be done by explicitly configuring a path to be used
between two routers. In a grander scale, a mesh of LSPs can be
established between central points in a network. LSPs paths can be
defined statically in configuration or arrived at by an algorithm
that determines the shortest path given constraints such as bandwidth
or other administrative constraints.
In this way, MPLS-TE allows for greater control over how traffic
demands are routed over a network topology and utilize a network's
ressources. As mentioned in Section 1, uses to date have been
limited to a single IGP area.
Note also that TE-LSPs allow to measure traffic matrix in a simple
and scalable manner. Basically, aggregated traffic rate between two
LSRs is easily measured by accounting of traffic sent onto a TE LSP
provisioned between the two LSRs in question.
4.2.2. Intra-area QoS guarantees
The DiffServ IETF working group has defined a set of mechanisms
described in [DIFF-ARCH], [DIFF-AF] and [DIFF-EF] or [MPLS-DIFF] that
can be activated at the edge or over a DiffServ domain to contribute
to the enforcement of a (set of) QoS policy(ies), which can be
expressed in terms of maximum one-way transit delay, inter-packet
delay variation, loss rate, etc. Many Operators have some or full
deployment of DiffServ implementations in their networks today,
either across the entire network or at least at the edge of the
network.
In situations where strict QoS bounds are required, admission control
inside the backbone of a network is in some cases required in
addition to current DiffServ mechanisms. When the propagation delay
can be bounded, the performance targets, such as maximum one-way
transit delay may be guaranteed by providing bandwidth guarantees
along the DiffServ-enabled path.
MPLS-TE can be simply used with DiffServ: in that case, it only
ensures aggregate QoS guarantees for the whole traffic. It can also
be more intimately combined with DiffServ to perform per-class of
service admission control and resource reservation. This requires
extensions to MPLS-TE called DiffServ Aware TE and defined in [DS-TE-
PROTO]. DS-TE allows ensuring strict end-to-end QoS guarantees. For
instance, an EF DS-TE LSP may be provisioned between voice gateways
within the same area to ensure strict QoS to VoIP traffic.
Le Roux, et. al. Informational - Expires November 2004 [Page 6]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
MPLS-TE allows computing intra-area shortest paths satisfying various
constraints including bandwidth. For the sake of illustration, if the
IGP metrics reflects the propagation delay, it allows finding a
minimum propagation delay path satisfying various constraints like
bandwidth.
4.2.3. Fast recovery within an area
As quality sensitive applications are deployed, one of the key
requirements is to provide fast recovery mechanisms, allowing to
guarantee traffic recovery on the order of tens of msecs, in case of
network element failure. Note that this cannot be achieved by relying
only on IGP rerouting.
Various recovery mechanisms can be used to protect traffic carried
onto TE LSPs. They are defined in [MPLS-RECOV]. Protection mechanisms
are based on the provisioning of backup LSPs that are used to recover
traffic in case of failure of protected LSPs. Among those protection
mechanisms, local protection, also called Fast Reroute is intended to
achieve sub-50ms recovery in case of link/node/SRLG failure along the
LSP path [FAST-REROUTE]. Fast Reroute is currently used by many
operators to protect sensitive traffic inside an IGP area.
[FAST-REROUTE] defines two modes for backup LSPs. The first one,
called one-to-one backup, consists in setting up a detour LSP per
protected LSP and per element to protect. The second one called
facility-backup consists in setting up one or several bypass LSPs to
protect a given facility (link or node). In case of failure, all
protected LSPs are nested into the bypass LSPs (benefiting from the
MPLS label stacking property).
4.3. Intra-area MPLS-TE and routing
There are several possibilities to direct traffic into intra-area TE
LSPs:
1) Static routes to the LSP destination address or any other
addresses.
2) IGP routes beyond the LSP destination, from an IGP SPF
perspective (IGP shortcuts).
3) BGP routes announced by a (MP-)BGP peer that is reachable
through the TE-LSP by means of a single static route to the
corresponding BGP next-hop address (option 1) or by means of
IGP shortcuts (option 2). This is often called BGP recursive
routing.
4) The LSP can be advertised as a link into the IGP to become
part of IGP database for all nodes, and thus taken into
account during SPF for all nodes. Note that, even if similar
in concept, this is different from the notion of Forwarding-
Adjacency, as defined in [LSP-HIER], where the LSP is
Le Roux, et. al. Informational - Expires November 2004 [Page 7]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
advertised as a TE-link into the IGP-TE, to become part of
the TE database and taken into account in CSPF.
5. Problem Statement, Requirements and Objectives of inter-area MPLS-TE
5.1. Inter-Area Traffic Engineering Problem Statement
As described in section 4, MPLS-TE is deployed today by many
operators to optimize network bandwidth usage, to provide strict QoS
guarantees and to ensure sub-50ms recovery in case of link/node/SRLG
failure.
However, MPLS-TE mechanisms are currently limited to a single IGP
area. The limitation comes essentially from the Routing and Path
Computation components and less from the Signaling component.
This is basically due to the fact that hierarchy limits topology
visibility of head-end LSRs to their IGP area, and consequently head-
end LSRs can no longer run a CSPF algorithm to compute the shortest
constrained path to the tail-end, as CSPF requires the whole topology
to compute an end-to-end shortest constrained path.
Several operators have multi-area networks and many operators that
are still using a single IGP area may have to migrate to a multi-area
environment, as their network grows and single area scalability
limits are approached.
Hence, those operators may require inter-area traffic engineering to:
- Perform inter-area resource optimization.
- Provide inter-area QoS guarantees for traffic between edge
nodes located in different areas.
- Provide fast recovery across areas, to protect inter-area
traffic in case of link or node failure, including ABR node
failures.
For instance an operator running a multi-area IGP may have Voice
gateways located in different areas. Such VoIP transport requires
inter-area QoS guarantees and inter-area fast protection.
One possible approach for inter-area traffic engineering could
consist of deploying MPLS-TE on a per-area basis, but such an
approach has several limitations:
- Traffic aggregation at the ABR levels implies some constraints
that do no lead to efficient traffic engineering. Actually
such per-area TE approach might lead to sub-optimal resource
utilization, by optimizing resources independently in each
area. And what many operators want is to optimize their
resources as a whole, in other words as if there was only one
area (flat network).
- This does not allow computing an inter-area constrained
shortest path and thus does not ensure end-to-end QoS
guarantees across areas.
Le Roux, et. al. Informational - Expires November 2004 [Page 8]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
- Inter-area traffic cannot be protected with local protection
mechanisms such as [FAST-REROUTE] in case of ABR failure.
5.2. Motivations for inter-area MPLS-TE
For the reasons mentioned above, it is highly desired to extend the
current set of MPLS-TE mechanisms across multiple IGP areas in order
to support the intra area applications described in section 4 across
areas.
Inter-area MPLS-TE extensions are highly desired to provide:
- Inter-area resources optimization.
- Strict inter-area QoS guarantees.
- Fast recovery across areas, particularly in order to protect
inter-area traffic against ABR failures.
Basically, the solution MUST allow setting up inter-area TE LSPs, ie
LSPs whose path crosses at least two IGP areas.
It may be desired to compute inter-area shortest path that satisfy
some bandwidth constraints or any other constraints, as currently
possible within a single IGP area. For the sake of illustration, if
the IGP metrics reflects the propagation delay, it may be needed to
be able to find the optimal (shortest) path satisfying some
constraints (i.e bandwidth) across multiple IGP areas: such a path
would be the inter-area path offering the minimal propagation delay.
Thus the solution SHOULD provide the ability to compute an inter-area
shortest path satisfying a set of constraints (i.e. bandwidth).
5.3. Key Objectives for an inter-area MPLS-TE solution
Any solution for inter-area MPLS-TE should be designed having as key
objectives to preserve IGP hierarchy concept, and to preserve routing
and signaling scalability.
5.3.1. Preserve the IGP hierarchy concept
The absence of a full link state topology database makes the
computation of an end-to-end optimal path by the head-end LSR not
possible without further signaling and routing extensions. There are
several reasons that network operators choose to break up their
network into different areas. These often include scalability and
containment of routing information. The latter can help isolate most
of a network from receiving and processing updates that are of no
consequence to its routing decisions. Containment of routing
information MUST not be compromised to allow inter-area traffic
engineering. Information propagation for path-selection MUST continue
to be localized. In other words, the solution MUST entirely preserve
the concept of IGP hierarchy.
Le Roux, et. al. Informational - Expires November 2004 [Page 9]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
5.3.2. Preserve Scalability
Being able to achieve the requirements listed in this document MUST
be performed while preserving the IGP scalability, which is of the
utmost importance. The hierarchy preservation objective addressed in
the above section is actually an element to preserve IGP scalability.
The solution MUST also not increase IGP load which could compromise
IGP scalability. In particular, a solution satisfying those
requirements MUST not require for the IGP to carry some unreasonable
amount of extra information and MUST not unreasonably increase the
IGP flooding frequency.
Likewise, the solution MUST also preserve scalability of RSVP-TE
([RSVP-TE]).
Additionally, the base specification of MPLS TE is architecturally
structured and relatively devoid of excessive state propagation in
terms of routing or signaling. Its strength in extensibility can
also be seen as an Achilles heel, as there is really no limit to
what is possible with extensions. It is paramount to maintain
architectural vision and discretion when adapting it for use for
inter-area MPLS-TE. Additional information carried within
an area, or propagated outside of an area (via routing or
signaling) should neither be excessive, patchwork, nor
non-relevant.
Particularly, as mentioned in 5.2 it may be desired, for some inter-
area TE LSP carrying highly sensitive traffic, to compute a shortest
inter-area path satisfying a set of constraints like bandwidth. This
may require an additional routing mechanism, as base CSPF at head-end
can not longer be used due to the lack of topology and resources
information. Such routing mechanism MUST not compromise the
scalability of the overall system.
Le Roux, et. al. Informational - Expires November 2004 [Page 10]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
6. Application Scenario
---area1--------area0------area2--
------R1-ABR1-R2-------ABR3-------
| \ | / | |
| R0 \ | / | R4 |
| R5 \ |/ | |
---------ABR2----------ABR4-------
- ABR1, ABR2: Area0-Area1 ABRs
- ABR3, ABR4: Area0-Area2 ABRs
- R0, R1, R5: LSRs in area 1
- R2: an LSR in area 0
- R4: an LSR in area 2
Typically, an inter-area TE LSP will be set up between R0 and R4
where both LSRs belong to different IGP areas. Note that the solution
MUST support the capability to protect such an inter-area TE LSP from
the failure on any link/SRLG/Node within any area and the failure of
any traversed ABR. For instance, if the TE-LSP R0->R4 goes through
R1->ABR1->R2, then it can be protected against ABR1 failure, thanks
to a backup LSP (detour or bypass) that may follow the alternate path
R1->ABR2->R2.
For instance R0 and R4 may be two voice gateways located in distinct
areas. An inter-area DS-TE LSP with class-type EF, is setup from R1
to R4 to route VoIP traffic classified as EF. Per-class inter-area
constraint based routing allows to route the DS-TE LSP over a path
that will ensure strict QoS guarantees for VoIP traffic.
In another application R0 and R4 may be two pseudo wire gateways
residing in different areas. An inter-area LSP may be setup to carry
pseudo wires.
In some cases, it might also be possible to have an inter-area TE LSP
from R0 to R5 transiting via the backbone area (or any other levels
with IS-IS). Basically, there may be cases where there is no longer
enough resources on any intra area path R0-to-R5, while there is a
feasible inter-area path through the backbone area.
Le Roux, et. al. Informational - Expires November 2004 [Page 11]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
7. Detailed requirements for inter-area MPLS-TE
7.1. Inter-area MPLS TE operations and interoperability
The inter-area MPLS TE solution MUST be consistent with requirements
discussed in [TE-REQ] and the derived solution MUST be such that it
will interoperate seamlessly with current intra-area MPLS TE
mechanisms and inherit its capability sets from [RSVP-TE].
The proposed solution MUST allow provisioning at the head-end with
end-to-end RSVP signalling (potentially with loose paths) traversing
across the interconnected ABRs, without further provisioning required
along the transit path.
7.2. Inter-Area TE-LSP signalling
The solution MUST allow for the signalling of inter-area TE-LSPs,
using RSVP-TE.
The proposed solution MUST allow the head-end LSR to explicitly
specify a set of LSRs, including ABRs, by means of strict or loose
hops for the inter-area TE LSP.
In addition, the proposed solution SHOULD also provide the ability to
specify and signal certain resources to be explicitly excluded in the
inter-area TE LSP path establishment.
7.3. Path optimality
In the context of this requirement document, an optimal path is
defined as the shortest path across multiple areas taking into
account either the IGP or TE metric [METRIC]. In other words, such a
path is the path that would have been computed making use of some
CSPF algorithm in the absence of multiple IGP areas.
As already mentioned in 5.2, the solution SHOULD provide the
capability to dynamically compute an optimal path satisfying a set of
specified constraints defined in [TE-REQ] across multiple IGP areas.
Note that this requirement document does not mandate that all inter-
area TE LSPs require the computation of an optimal (shortest) inter-
area path: some inter-area TE LSP paths may be computed via some
mechanisms not guaranteeing an optimal end to end path whereas some
other inter-area TE LSP paths carrying sensitive traffic could be
computed making use of some mechanisms allowing to dynamically
compute an optimal end-to-end path. Note that regular constraints
like bandwidth, affinities, IGP/TE metric optimization, path
Le Roux, et. al. Informational - Expires November 2004 [Page 12]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
diversity, etc, MUST be taken into account in the computation of an
optimal end-to-end path.
7.4. Inter-Area MPLS-TE Routing
As already mentioned in 5.1, IGP hierarchy does not allow the Head-
End LSR computing an end-to-end optimal path. Additional mechanisms
are required to compute an optimal path. These additional mechanisms
MUST not alter the IGP hierarchy principles.
Particularly, in order to maintain containment of routing information
and preserve the overall IGP scalability, the solution MUST preclude
the leaking across area of any TE Topology related information even
in a summarized form.
Conversely, this does not preclude the leaking of non topology
related information, that are not taken into account during path
selection, such as static TE Node information like TE router ids.
7.5. Inter-Area MPLS-TE Path computation
Several methods may be used for path computation, as follows:
-Per-area path computation based on ERO expansion on the Head-
End LSR and on ABRs, with two options for ABR selection:
-Static configuration of ABRs as loose hops at the head-end LSR.
-Dynamic ABR selection.
-Inter-area end-to-end path computation, that may be
based for instance on a recursive constraint based searching
thanks to collaboration between ABRs.
Note that any path computation method may be used provided that it
respect key objectives pointed out in 5.3.
In case a solution supports more than one method, it SHOULD allow the
operator to select by configuration, and on a per-LSP basis, the
desired option.
7.6. Inter-area Crankback Routing
Crankback routing, as defined in [CRANKBACK] may be used for inter-
area TE-LSP. Basically for paths computed thanks to ERO expansions
with a dynamic selection of downstream ABRs, crankback routing can be
used when there is no feasible path from a selected downstream ABR to
the destination: The upstream ABR or Head-End LSR, selects another
downstream ABR, and perform ERO expansion.
Note that such method does not allow computing and optimal path but
just a feasible path.
Le Roux, et. al. Informational - Expires November 2004 [Page 13]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
Note also that there can be 0(N^2) LSP setup failures before finding
a feasible path where N is the average number of ABR between two
areas. This may have a non negligible impact on the LSP setup delay.
Crankback may also be used for inter-area LSP recovery: Basically in
case a link/node/SRLG failure occurs in the backbone or tail-end
area, the ABR upstream to the failure computes an alternate path an
reroutes locally the LSP.
An inter-area MPLS-TE solution MAY support [CRANKBACK].
A solution that supports [CRANKBACK], MUST allow to
activate/deactivate it via signaling, on a per-LSP basis.
7.7. Support of diversely routed inter-area TE LSPs
There are several cases where the ability to compute diversely routed
TE LSP paths may be desirable. For instance, in case of LSP
protection, primary and backup LSPs should be diversely routed.
Another example is the requirement to set up multiple diversely
routed TE LSPs between a pair of LSRs residing in different IGP
areas. For instance when a single TE-LSP satisfying the bandwidth
constraint could not be found between two end-points, a solution
would consist of setting up multiple TE-LSPs such that the sum of
their bandwidth satisfy the bandwidth requirement. In this case, it
may be desirable to have these TE-LSPs diversely routed in order to
minimize the impact of a failure, on the traffic between the two end-
points.
Hence, the solution MUST be able to establish diversely routed inter-
area TE LSPs, when diverse patsh exist. It MUST support all kinds of
path diversity (link, node, SRLG).
The solution SHOULD allow computing an optimal placement of diversely
routed LSP. There may be various criteria to determine such an
optimal placement. For instance the placement of two diversely routed
LSPs, for load-balancing purpose may consists of minimizing their
cumulative cost. The placement of two diversely routed LSPs for
protection purpose may consists in minimizing the cost of the primary
LSP while bounding the cost, or hop count of the backup LSP.
Le Roux, et. al. Informational - Expires November 2004 [Page 14]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
7.8. Intra/Inter-area Path selection policy
For inter-area TE LSPs whose head-end and tail-end LSRs reside in the
same IGP area, there may be intra-area and inter-area feasible paths.
In case the shortest path is an inter-area path, an operator may
either want to avoid, as far as possible, crossing area and thus
prefer selecting a sub-optimal intra-area path, or conversely may
prefer to use a shortest path, even if it crosses areas.
Thus, the solution MUST allow to enable/disable IGP area crossing, on
a per-LSP basis, for TE LSPs whose head-end and tail-end reside in
the same IGP area.
7.9. Reoptimization of inter-area TE LSP
The solution MUST provide the ability to reoptimize in a minimally
disruptive manner (make before break) an inter-area TE LSP, should a
more optimal path appear in any traversed IGP area. The operator
should be able to parameter such a reoptimization on a timer or
event-driven basis. It should also be possible to trigger such a
reoptimization manually.
The solution SHOULD provide the ability to locally reoptimize an
inter-area TE-LSP within an area, i.e. retaining the same set of
transit ABRs. The reoptimization process in that case, MAY be
controlled by the head-end LSR of the inter-area LSP, or by an ABR.
The ABR should check for local optimality of the inter-area TE LSPs
established through it, based on a timer or triggered by an event.
Option of providing manual trigger to check for optimality should
also be provided.
In some cases it is important to restrict the control of
reoptimization to the Head-End LSR only. Thus, the solution MUST
allow to activate/deactivate ABR control of reoptimization, via
signalling on a per LSP-basis.
The solution SHOULD also provide the ability to perform an end-to-end
reoptimization, resulting potentially in a change on the set of
transit ABRs. Such reoptimization can be controlled only by the HE
LSR.
In case of head-end control of reoptimization, the solution SHOULD
provide the ability for the inter-area head-end LSR to be informed of
the existence of a more optimal path in a downstream area and keep a
strict control on the reoptimization process. Hence, the inter-area
head-end LSR, once informed of a more optimal path in some downstream
IGP areas, could decide (or not) to gracefully perform a make-before-
break reoptimization, according to the inter-area TE LSP
characteristics.
Le Roux, et. al. Informational - Expires November 2004 [Page 15]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
7.10. Inter-area LSP Recovery.
7.10.1. Rerouting of inter-area TE LSPs
The solution MUST support rerouting of an inter-area TE LSP in case
of SRLG/link/node failure or pre-emption. Such rerouting may be
controlled by the Head-End LSR or by an ABR (see section 7.6 on
crankback).
7.10.2. Fast recovery of inter-area TE LSP
The solution MUST provide the ability to benefit from fast recovery
making use of the local protection techniques specified in [FAST-
REROUTE] in both the case of an intra-area network element failure
(link/SRLG/Node) and an ABR node failure. Note that different
protection techniques SHOULD be usable in different parts of the
network to protect an inter-area TE LSP. This is of the utmost
importance in particular in the case of an ABR node failure that
typically carries a great deal of inter-area traffic. Moreover, the
solution SHOULD allow computing and setting up a backup tunnel
following an optimal path that offers bandwidth guarantees during
failure along with other potential constraints (like bounded
propagation delay increase along the backup path).
The solution SHOULD allow to protect ABRs while providing the same
level of performances (recovery delay, bandwidth consumption) as
provided today within an area.
Note that some signalling approaches may have an impact on FRR
performances (recovery delay, bandwidth consumption). Typically, when
some intra-area LSPs are used to set up the inter-area TE LSP, then
the protection of ABR using [FAST-REROUTE] may lead to higher
recovery delays and also higher resources consumption.
The use of [FAST-REROUTE] to protect ABRs, while ensuring the same
level of performances, currently requires to use a single end-to-end
RSVP session, with no use of any intra-area LSP. Thus, the solution
MUST provide the ability, via signalling on a per-LSP basis, to
allow/preclude the use of intra-area LSPs to set up the inter-area
LSPs.
Le Roux, et. al. Informational - Expires November 2004 [Page 16]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
7.11. DS-TE support
The proposed inter-area MPLS TE solution SHOULD also satisfy core
requirements documented in [DSTE-REQ] and interoperate seamlessly
with current intra-area MPLS DS-TE mechanism [DSTE-PROTO].
7.12. Hierarchical LSP support
In case of large inter-area MPLS deployment potentially involving a
large number of LSRs, it can be desirable/necessary to introduce
some level of hierarchy in order to reduce the number of
states on LSRs (it is worth mentioning that such a solution implies
other challenges). Hence, the proposed solution SHOULD allow inter-
area TE LSP aggregation (also referred to as LSP nesting) such that
individual TE LSPs can be carried onto one or more aggregating
LSP(s). One such mechanism, for example is described in [LSP-HIER].
7.13. Hard/Soft pre-emption
As defined in [MPLS-PREEMPT], there are two pre-emption models
applicable to MPLS: Soft and Hard Pre-emption.
An inter-area MPLS-TE solution SHOULD support the two models.
In case of hard pre-emption, the pre-empted inter-area TE-LSP should
be rerouted, following requirements defined in section 7.10.1.
In case of soft pre-emption, the pre-empted inter-area TE-LSP should
be re-optimized, following requirements defined in section 7.9.
7.14. Auto-discovery of TE meshes
Because the number of LSRs participating in some TE mesh might be
quite large, it might be desirable to provide some discovery
mechanisms allowing an LSR to automatically discover the LSRs members
of the TE mesh(es) that it belongs to. The discovery mechanism SHOULD
be applicable across multiple IGP areas, and SHOULD not impact the
IGP scalability, provided that IGP extensions are used for such a
discovery mechanism.
7.15. nter-area MPLS TE fault management requirements
The proposed solution SHOULD be able to interoperate with fault
detection mechanisms of intra-area MPLS TE.
The solution SHOULD support[LSP-PING] and [MPLS-TTL].
Le Roux, et. al. Informational - Expires November 2004 [Page 17]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
The solution SHOULD also support for fault detection on backup LSPs,
in case [FAST-REROUTE] is deployed.
7.16. Inter-area MPLS-TE and routing
In the case of intra-area MPLS TE, there are currently several
possibilities to route traffic into an intra-area TE LSP. They are
listed in section 4.2.
In case of inter-area MPLS-TE, the solution MUST support static
routing into the LSP, and also BGP recursive routing with a static
route to the BGP next-hop address.
ABRs propagate IP reacheability information (summary LSA in OSPF and
IP reacheability TLV in ISIS), that MAY be used by the head-end LSR
to route traffic to a destination beyond the TE LSP tail-head LSR
(e.g. to an ASBR).
The use of IGP shortcuts, MUST be precluded when TE LSP head-end and
tail-end LSRs do not reside in the same IGP area. It MAY be used when
they reside in the same area.
The advertisement of an inter-area TE LSP as a link, into the IGP, to
attract traffic to an LSP source MUST be precluded when TE LSP head-
end and tail-end LSRs do not reside in the same IGP area. It MAY be
used when they reside in the same area.
8. Evaluation criteria
8.1. Performances
The solution SHOULD clearly be evaluated with respects to the
following criteria:
(1) Optimality of the computed inter-area TE LSP paths.
(2) Optimality of the computed backup paths protecting against
the failure of an ABR, capability to share bandwidth among backup
tunnels protecting independent facilities.
(3) Inter-area TE LSP set up time.
(4) RSVP-TE and IGP scalability (state impact, number of messages,
message size)
8.2. Complexity and risks
The proposed solution(s) SHOULD not introduce complexity
to the current operating network to such a degree that it would
affect the stability and diminish the benefits of deploying such
solution over SP networks.
Le Roux, et. al. Informational - Expires November 2004 [Page 18]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
8.3. Backward Compatibility
The deployment of inter-area MPLS TE SHOULD not have impact on
existing MPLS TE mechanisms to allow for a smooth migration or co-
existence. In particular the solution SHOULD allow the setup of an
inter-area TE-LSP among transit LSRs that do not support inter-area
extensions, provided that these LSRs do not participate in the inter-
area TE procedure. For illustration purpose the solution MAY require
inter-area extensions only on end-point LSRs, on ABRs, and
potentially on PLRs protecting an ABR.
9. Security Considerations
Inter-area MPLS-TE does not raise any new security issue, beyond
those of intra-area MPLS-TE.
10. Acknowledgements
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal
Sharma and Arthi Ayyangar for their useful comments and suggestions.
11. Normative References
[TE-REQ] Awduche et. al., "Requirements for Traffic Engineering
over MPLS", RFC2702.
[DSTE-REQ] Le faucheur, F., et al, ô Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineeringö, RFC3564.
12. Informative References
[MPLS-ARCH] Rosen, et. al., "Multiprotocol Label Switching
Architecture", RFC 3031.
[TE-OVW] Awduche, et. al., "Overview and Principles of Internet
Traffic Engineering", RFC 3272.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC
3209.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
Extensions to OSPF Version 2", RFC3630.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic
Engineering", draft-ietf-isis-traffic-04.txt, work in progress.
Le Roux, et. al. Informational - Expires November 2004 [Page 19]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
[TE-APP] Boyle, et. al., "Applicability Statement of Traffic
Engineering", RFC 3346.
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE
for LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt, work
in progress.
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,
Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",
Internet Draft "draft-ietf-mpls-lsp-ping-05.txt", work in progress.
[MPLS-TTL] Agarwal, R., et al, "Time to Live (TTL) Processing in MPLS
Networks", RFC 3443.
[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress.
[MPLS-RECOV] V. Sharma, F. Hellstrand, "Framework for Multi-Protocol
Label Switching (MPLS)-based Recovery", RFC 3469.
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for MPLS
Signalingö, draft-ietf-ccamp-crankback-01.txt, work in progress.
[MPLS-DIFF] Le Faucheur, et. al., "MPLS Support of Differentiated
Services", RFC 3270.
[DSTE-PROTO] Le faucheur, F., et al, ôProtocol extensions for support
of Differentiated-Service-aware MPLS Traffic Engineeringö, draft-
ietf-tewg-diff-te-proto-07.txt, work in progress.
[DIFF-ARCH] Blake, et. al., "An Architecture for Differentiated
Services", RFC 2475.
[DIFF-AF] Heinanen, et. al., "Assured Forwarding PHB Group", RFC
2597.
[DIFF-EF] Davie, et. al., "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246.
[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption",
draft-farrel-mpls-preemption-interim-00.txt, work in progress.
[METRIC] Le Faucheur, et. Al., "Use of Interior Gateway Protocol
(IGP) Metric as a second MPLS Traffic Engineering Metric", draft-
ietf-tewg-te-metric-igp-02.txt, work in progress.
Le Roux, et. al. Informational - Expires November 2004 [Page 20]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
13. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in RFC 2028. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
14. Editors' Address:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough , MA - 01719
USA
Email: jpv@cisco.com
Jim Boyle
Email: jboyle@pdnets.com
Le Roux, et. al. Informational - Expires November 2004 [Page 21]
Internet Draft draft-ietf-tewg-interarea-mpls-te-req-02 June 2004
Full Copyright Statement
"Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Le Roux, et. al. Informational - Expires November 2004 [Page 22]