of specified constraints (defined in [TE-REQ]) across multiple IGP
areas. Note that this requirement document does not mandate that all
inter-area TE LSPs require the computation of an optimal (shortest)
inter-area path. Some inter-area TE-LSP paths may be computed via
some mechanisms that do not guarantee an optimal end-to-end path,
whereas some other inter-area TE-LSP paths carrying sensitive traffic
could be computed by making use of mechanisms allowing an optimal
end-to-end path to be computed dynamically. Note that regular
constraints such as bandwidth, affinities, IGP/TE metric
optimization, path diversity, etc., MUST be taken into account in the
computation of an optimal end-to-end path.
7.4. Inter-Area MPLS-TE Routing
As mentioned in Section 5.3, IGP hierarchy does not allow the head-
end LSR to compute an end-to-end optimal path. Additional mechanisms
are required to compute an optimal path. These mechanisms MUST not
alter the IGP hierarchy principles. Particularly, in order to
maintain containment of routing information and to preserve the
overall IGP scalability, the solution SHOULD avoid any dynamic-TE-
topology-related information from leaking across areas, even in a
summarized form.
Conversely, this does not preclude the leaking of non-topology-
related information that is not taken into account during path
selection, such as static TE Node information (TE router ids or TE
node capabilities).
7.5. Inter-Area MPLS-TE Path Computation
Several methods may be used for path computation, including the
following:
- Per-area path computation based on ERO expansion on the head-end
LSR and on ABRs, with two options for ABR selection:
1) Static configuration of ABRs as loose hops at the head-end
LSR.
2) Dynamic ABR selection.
- Inter-area end-to-end path computation, which may be based on (for
instance) a recursive constraint-based searching thanks to
collaboration between ABRs.
Note that any path computation method may be used provided that it
respect key objectives pointed out in Section 5.3.
If a solution supports more than one method, it should allow the
operator to select by configuration, and on a per-LSP basis, the
desired option.
7.6. Inter-Area Crankback Routing
Crankback routing, as defined in [CRANKBACK], may be used for inter-
area TE LSPs. For paths computed thanks to ERO expansions with a
dynamic selection of downstream ABRs, crankback routing can be used
when there is no feasible path from a selected downstream ABR to the
destination. The upstream ABR or head-end LSR selects another
downstream ABR and performs ERO expansion.
Note that this method does not allow computing an optimal path but
just a feasible path. Note also that there can be 0(N^2) LSP setup
failures before finding a feasible path, where N is the average
number of ABR between two areas. This may have a non-negligible
impact on the LSP setup delay.
Crankback may also be used for inter-area LSP recovery. If a
link/node/SRLG failure occurs in the backbone or tail-end area, the
ABR upstream to the failure computes an alternate path and reroutes
the LSP locally.
An inter-area MPLS-TE solution MAY support [CRANKBACK]. A solution
that does, MUST allow [CRANKBACK] to be activated/deactivated via
signaling, on a per-LSP basis.
7.7. Support of Diversely-Routed Inter-Area TE LSPs
There are several cases where the ability to compute diversely-routed
TE-LSP paths may be desirable. For instance, in the case of LSP
protection, primary and backup LSPs should be diversely routed.
Another example is the requirement to set up multiple diversely-
routed TE LSPs between a pair of LSRs residing in different IGP
areas. For instance, when a single TE LSP satisfying the bandwidth
constraint cannot be found between two end-points, a solution would
consist of setting up multiple TE LSPs so that the sum of their
bandwidth satisfy the bandwidth requirement. In this case, it may be
desirable to have these TE LSPs diversely routed in order to minimize
the impact of a failure, on the traffic between the two end-points.
Thus, the solution MUST be able to establish diversely-routed inter-
area TE LSPs when diverse paths exist. It MUST support all kinds of
diversity (link, node, SRLG).
The solution SHOULD allow computing an optimal placement of
diversely-routed LSPs. There may be various criteria to determine an
optimal placement. For instance, the placement of two diversely
routed LSPs for load-balancing purposes may consist of minimizing
their cumulative cost. The placement of two diversely-routed LSPs
for protection purposes may consist of minimizing the cost of the
primary LSP while bounding the cost or hop count of the backup LSP.
7.8. Intra/Inter-Area Path Selection Policy
For inter-area TE LSPs whose head-end and tail-end LSRs reside in the
same IGP area, there may be intra-area and inter-area feasible paths.
If the shortest path is an inter-area path, an operator either may
want to avoid, as far as possible, crossing area and thus may prefer
selecting a sub-optimal intra-area path or, conversely, may prefer to
use a shortest path, even if it crosses areas. Thus, the solution
should allow IGP area crossing to be enabled/disabled, on a per-LSP
basis, for TE LSPs whose head-end and tail-end reside in the same IGP
area.
7.9. Reoptimization of Inter-Area TE LSP
The solution MUST provide the ability to reoptimize in a minimally
disruptive manner (make before break) an inter-area TE LSP, should a
more optimal path appear in any traversed IGP area. The operator
should be able to parameterize such a reoptimization according to a
timer or event-driven basis. It should also be possible to trigger
such a reoptimization manually.
The solution SHOULD provide the ability to reoptimize an inter-area
TE LSP locally within an area; i.e., while retaining the same set of
transit ABRs. The reoptimization process in that case MAY be
controlled by the head-end LSR of the inter-area LSP, or by an ABR.
The ABR should check for local optimality of the inter-area TE LSPs
established through it on a timer or event driven basis. The option
of a manual trigger to check for optimality should also be provided.
In some cases it is important to restrict the control of
reoptimization to the Head-End LSR only. Thus, the solution MUST
allow for activating/deactivating ABR control of reoptimization, via
signaling on a per LSP-basis.
The solution SHOULD also provide the ability to perform an end-to-end
reoptimization, potentially resulting in a change on the set of
transit ABRs. Such reoptimization can only be controlled by the
Head-End LSR.
In the case of head-end control of reoptimization, the solution
SHOULD provide the ability for the inter-area head-end LSR to be
informed of the existence of a more optimal path in a downstream area
and keep a strict control over the reoptimization process. Thus, the
inter-area head-end LSR, once informed of a more optimal path in some
downstream IGP areas, could decide to perform a make-before-break
reoptimization gracefully (or not to), according to the inter-area
TE-LSP characteristics.
7.10. Inter-Area LSP Recovery
7.10.1. Rerouting of Inter-Area TE LSPs
The solution MUST support rerouting of an inter-area TE LSP in case
of SRLG/link/node failure or preemption. Such rerouting may be
controlled by the Head-End LSR or by an ABR (see Section 7.6, on
crankback).
7.10.2. Fast Recovery of Inter-Area TE LSP
The solution MUST provide the ability to benefit from fast recovery,
making use of the local protection techniques specified in
[FAST-REROUTE] both in the case of an intra-area network element
failure (link/SRLG/node) and in that of an ABR node failure. Note
that different protection techniques SHOULD be usable in different
parts of the network to protect an inter-area TE LSP. This is of the
utmost importance, particularly in the case of an ABR node failure,
as this node typically carries a great deal of inter-area traffic.
Moreover, the solution SHOULD allow computing and setting up a backup
tunnel following an optimal path that offers bandwidth guarantees
during failure, along with other potential constraints (such as
bounded propagation delay increase along the backup path).
The solution SHOULD allow ABRs to be protected, while providing the
same level of performances (recovery delay, bandwidth consumption) as
provided today within an area.
Note that some signaling approaches may have an impact on FRR
performances (recovery delay, bandwidth consumption). Typically,
when some intra-area LSPs (LSP-Segment, FA-LSPs) are used to support
the inter-area TE LSP, the protection of ABR using [FAST-REROUTE] may
lead to higher bandwidth consumption and higher recovery delays. The
use of [FAST-REROUTE] to protect ABRs, although ensuring the same
level of performances, currently requires a single end-to-end RSVP
session (contiguous LSP) to be used, without any intra-area LSP.
Thus, the solution MUST provide the ability, via signalling on a
per-LSP basis, to allow or preclude the use of intra-area LSPs to
support the inter-area LSPs.
7.11. DS-TE support
The proposed inter-area MPLS TE solution SHOULD also satisfy core
requirements documented in [DSTE-REQ] and interoperate seamlessly
with current intra-area MPLS DS-TE mechanism [DSTE-PROTO].
7.12. Hierarchical LSP Support
In the case of a large inter-area MPLS deployment, potentially
involving a large number of LSRs, it may be desirable/necessary to
introduce some level of hierarchy in order to reduce the number of
states on LSRs (such a solution implies other challenges). Thus, the
proposed solution SHOULD allow inter-area TE-LSP aggregation (also
referred to as LSP nesting) so that individual TE LSPs can be carried
onto one or more aggregating LSPs. One such mechanism, for example,
is described in [LSP-HIER].
7.13. Hard/Soft Preemption
As defined in [MPLS-PREEMPT], two preemption models are applicable to
MPLS: Soft and Hard Preemption.
An inter-area MPLS-TE solution SHOULD support the two models.
In the case of hard preemption, the preempted inter-area TE LSP
should be rerouted, following requirements defined in Section 7.10.1.
In the case of soft preemption, the preempted inter-area TE LSP
should be re-optimized, following requirements defined in Section
7.9.
7.14. Auto-Discovery of TE Meshes
A TE mesh is a set of LSRs that are fully interconnected by a full
mesh of TE LSPs. Because the number of LSRs participating in some TE
mesh might be quite large, it might be desirable to provide some
discovery mechanisms allowing an LSR to discover automatically the
LSRs members of the TE mesh(es) that it belongs to. The discovery
mechanism SHOULD be applicable across multiple IGP areas, and SHOULD
not impact the IGP scalability, provided that IGP extensions are used
for such a discovery mechanism.
7.15. Inter-Area MPLS TE Fault Management Requirements
The proposed solution SHOULD be able to interoperate with fault
detection mechanisms of intra-area MPLS TE.
The solution SHOULD support [LSP-PING] and [MPLS-TTL].
The solution SHOULD also support fault detection on backup LSPs, in
case [FAST-REROUTE] is deployed.
7.16. Inter-Area MPLS TE and Routing
In the case of intra-area MPLS TE, there are currently several
possibilities for routing traffic into an intra-area TE LSP. They
are listed in Section 4.2.
In the case of inter-area MPLS TE, the solution MUST support static
routing into the LSP, and also BGP recursive routing with a static
route to the BGP next-hop address.
ABRs propagate IP reachability information (summary LSA in OSPF and
IP reachability TLV in ISIS), that MAY be used by the head-end LSR to
route traffic to a destination beyond the TE-LSP tail-head LSR (e.g.,
to an ASBR).
The use of IGP shortcuts MUST be precluded when TE-LSP head-end and
tail-end LSRs do not reside in the same IGP area. It MAY be used
when they reside in the same area.
The advertisement of an inter-area TE LSP as a link into the IGP, in
order to attract traffic to an LSP source, MUST be precluded when
TE-LSP head-end and tail-end LSRs do not reside in the same IGP area.
It MAY be used when they reside in the same area.
8. Evaluation criteria
8.1. Performances
The solution will be evaluated with respect to the following
criteria:
(1) Optimality of the computed inter-area TE-LSP primary and backup
paths, in terms of path cost.
(2) Capability to share bandwidth among inter-area backup LSPs
protecting independent facilities.
(3) Inter-area TE-LSP setup time (in msec).
(4) RSVP-TE and IGP scalability (state impact, number of messages,
message size).
8.2. Complexity and Risks
The proposed solution SHOULD not introduce complexity to the current
operating network to such a degree that it would affect the stability
and diminish the benefits of deploying such a solution over SP
networks.
8.3. Backward Compatibility
In order to allow for a smooth migration or co-existence, the
deployment of inter-area MPLS TE SHOULD not affect existing MPLS TE
mechanisms. In particular, the solution SHOULD allow the setup of an
inter-area TE LSP among transit LSRs that do not support inter-area
extensions, provided that these LSRs do not participate in the
inter-area TE procedure. For illustration purposes, the solution MAY
require inter-area extensions only on end-point LSRs, on ABRs, and,
potentially, on Points of Local Repair (PLR) protecting an ABR.
9. Security Considerations
This document does not introduce new security issues beyond those
inherent in MPLS TE [RSVP-TE] and an inter-area MPLS-TE solution may
use the same mechanisms proposed for that technology. It is,
however, specifically important that manipulation of administratively
configurable parameters be executed in a secure manner by authorized
entities.
10. Acknowledgements
We would like to thank Dimitri Papadimitriou, Adrian Farrel, Vishal
Sharma, and Arthi Ayyangar for their useful comments and suggestions.
11. Contributing Authors
This document was the collective work of several authors. The text
and content of this document was contributed by the editors and the
co-authors listed below (the contact information for the editors
appears in Section 14 and is not repeated below):
Ting-Wo Chung Yuichi Ikejiri
Bell Canada NTT Communications Corporation
181 Bay Street, Suite 350, 1-1-6, Uchisaiwai-cho,
Toronto, Chiyoda-ku, Tokyo 100-8019
Ontario, Canada, M5J 2T3 JAPAN
EMail: ting_wo.chung@bell.ca EMail: y.ikejiri@ntt.com
Raymond Zhang Parantap Lahiri
Infonet Services Corporation MCI
2160 E. Grand Ave. 22001 Loudoun Cty Pky
El Segundo, CA 90025 Ashburn, VA 20147
USA USA
EMail: raymond_zhang@infonet.com EMail: parantap.lahiri@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460,
JAPAN
EMail: ke-kumaki@kddi.com
12. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O’Dell, M., and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
13. Informative References
[TE-OVW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., and
X. Xiao, "Overview and Principles of Internet Traffic
Engineering", RFC 3272, May 2002.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001.
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[TE-APP] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche,
D., Christian, B., and W. Lai, "Applicability
Statement for Traffic Engineering with MPLS", RFC
3346, August 2002.
[FAST-REROUTE] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed.,
"Fast Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[LSP-PING] Kompella, K., Pan, P., Sheth, N., Cooper, D., Swallow,
G., Wadhwa, S., Bonica, R., "Detecting Data Plane
Liveliness in MPLS", Work in Progress.
[MPLS-TTL] Agarwal, P. and B. Akyol, "Time To Live (TTL)
Processing in Multi-Protocol Label Switching (MPLS)
Networks", RFC 3443, January 2003.
[LSP-HIER] Kompella, K., and Y. Rekhter, "LSP Hierarchy with
Generalized MPLS TE", Work in Progress.
[MPLS-RECOV] Sharma, V. and F. Hellstrand, "Framework for Multi-
Protocol Label Switching (MPLS)-based Recovery", RFC
3469, February 2003.
[CRANKBACK] Farrel, A., Ed., "Crankback Signaling Extensions for
MPLS Signaling", Work in Progress.
[MPLS-DIFF] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P., and J.
Heinanen, "Multi-Protocol Label Switching (MPLS)
Support of Differentiated Services", RFC 3270, May
2002.
[DSTE-PROTO] Le Faucheur, F., et al., "Protocol Extensions for
Support of Differentiated-Service-aware MPLS Traffic
Engineering", Work in Progress.
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DIFF-AF] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[DIFF-EF] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[MPLS-PREEMPT] Farrel, A., "Interim Report on MPLS Pre-emption", Work
in Progress.
[METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P.,
and T. Telkamp, "Use of Interior Gateway Protocol
(IGP) Metric as a second MPLS Traffic Engineering (TE)
Metric", BCP 87, RFC 3785, May 2004.
14. Editors’ Addresses
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
France
EMail: jeanlouis.leroux@francetelecom.com
Jean-Philippe Vasseur
Cisco Systems, Inc.
300 Beaver Brook Road
Boxborough, MA - 01719
USA
EMail: jpv@cisco.com
Jim Boyle
EMail: jboyle@pdnets.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.