draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt   draft-ietf-ccamp-inter-domain-pd-path-comp-02.txt 
Network Working Group JP Vasseur (Editor) Networking Working Group JP. Vasseur, Ed.
IETF Internet draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc
Proposed Status: Standard Arthi Ayyangar (Editor) Proposed Status: Standard A. Ayyangar, Ed.
Juniper Networks Expires: August 11, 2006 Juniper Networks
Raymond Zhang R. Zhang
Infonet Service Corporation BT Infonet
February 7, 2006
Expires: April 2006
October 2005
draft-ietf-ccamp-inter-domain-pd-path-comp-01.txt
A Per-domain path computation method for establishing Inter-domain A Per-domain path computation method for establishing Inter-domain
Traffic Engineering (TE) Label Switched Paths (LSPs) Traffic Engineering (TE) Label Switched Paths (LSPs)
draft-ietf-ccamp-inter-domain-pd-path-comp-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware
been or will be disclosed, and any of which he or she becomes aware have been or will be disclosed, and any of which he or she becomes
will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract This Internet-Draft will expire on August 11, 2006.
This document specifies a per-domain path computation technique for Copyright Notice
establishing inter-domain Traffic Engineering (TE) Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Paths
(LSPs). In this document a domain refers to a collection of network
elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domain Copyright (C) The Internet Society (2006).
TE LSP cannot be or is not determined at the ingress node of the TE
Vasseur, Ayyangar and Zhang 1 Abstract
LSP, and is not signaled across domain boundaries. This is most likely This document specifies a per-domain path computation technique for
to arise owing to TE visibility limitations. The signaling message establishing inter-domain Traffic Engineering (TE) Multiprotocol
indicates the destination and nodes up to the next domain boundary. It Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
may also indicate further domain boundaries or domain identifiers. The Paths (LSPs). In this document a domain refers to a collection of
path through each domain, possibly including the choice of exit point network elements within a common sphere of address management or path
from the domain, must be determined within the domain. computational responsibility such as IGP areas and Autonomous
Systems. Per-domain computation applies where the full path of an
inter-domain TE LSP cannot be or is not determined at the ingress
node of the TE LSP, and is not signaled across domain boundaries.
This is most likely to arise owing to TE visibility limitations. The
signaling message indicates the destination and nodes up to the next
domain boundary. It may also indicate further domain boundaries or
domain identifiers. The path through each domain, possibly including
the choice of exit point from the domain, must be determined within
the domain.
Conventions used in this document Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of content Table of Contents
1. Terminology..................................................3
2. Introduction.................................................3
3. General assumptions..........................................4
3.1 Common assumptions..........................................4
3.2 Example of topology for the inter-area TE case .............5
3.3 Example of topology for the inter-AS TE case ...............6
4. Per-domain path computation procedures.......................7
4.1 Example with an inter-area TE LSP...........................10
4.1.1 Case 1: T1 is a contiguous TE LSP.........................10
4.1.2 Case 2: T1 is a stitched or nested TE LSP.................11
4.2 Example with an inter-AS TE LSP.............................11
4.2.1 Case 1: T1 is a contiguous TE LSP.........................12
4.2.2 Case 2: T1 is a stitched or a nested TE LSP...............12
5. Path optimality/diversity....................................13
6. Reoptimization of an inter-domain TE LSP.....................13
6.1 Contiguous TE LSPs..........................................13
6.2. Stitched or nested (non-contiguous) TE LSPs................13
6.3 Path characteristics after reoptimization...................15
7. Security Considerations .....................................15
8. Intellectual Property Considerations ........................15
9. Acknowledgments..............................................15
10. References..................................................15
10.1 Normatives References .....................................16
10.2 Informative References ....................................17
Vasseur, Ayyangar and Zhang 2 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5
3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5
3.2. Example of topology for the inter-area TE case . . . . . . 7
3.3. Example of topology for the inter-AS TE case . . . . . . . 7
4. Per-domain path computation procedures . . . . . . . . . . . . 9
4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12
4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 12
4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 13
4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 13
4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14
4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 14
5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15
6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15
6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15
6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16
6.3. Path characteristics after reoptimization . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Terminology 1. Terminology
Terminology used in this document
ABR Routers: routers used to connect two IGP areas (areas in OSPF or ABR Routers: routers used to connect two IGP areas (areas in OSPF or
levels in IS-IS) levels in IS-IS).
ASBR Routers: routers used to connect together ASes of a different or ASBR Routers: routers used to connect together ASes of a different or
the same Service Provider via one or more Inter-AS links. the same Service Provider via one or more Inter-AS links.
Boundary LSR: a boundary LSR is either an ABR in the context of inter- Boundary LSR: a boundary LSR is either an ABR in the context of
area TE or an ASBR in the context of inter-AS TE. inter-area TE or an ASBR in the context of inter-AS TE.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary. Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area. Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router LSR: Label Switching Router.
LSP: Label Switched Path LSP: Label Switched Path.
TE LSP: Traffic Engineering Label Switched Path TE LSP: Traffic Engineering Label Switched Path.
PCE: Path Computation Element: an entity (component, application or PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints. based on a network graph and applying computational constraints.
TED: Traffic Engineering Database TED: Traffic Engineering Database.
The notion of contiguous, stitched and nested TE LSPs is defined in The notion of contiguous, stitched and nested TE LSPs is defined in
[INT-DOMAIN-FRWK] and will not be repeated here. [I-D.ietf-ccamp-inter-domain-framework] and will not be repeated
here.
2. Introduction 2. Introduction
The requirements for inter-domain Traffic Engineering (inter-area and The requirements for inter-domain Traffic Engineering (inter-area and
inter-AS TE) have been developed by the Traffic Engineering Working inter-AS TE) have been developed by the Traffic Engineering Working
Group and have been stated in [INT-AREA-REQS] and [INT-AS-REQS]. The Group and have been stated in [RFC4105] and [RFC4216]. The framework
framework for inter-domain MPLS Traffic Engineering has been provided for inter-domain MPLS Traffic Engineering has been provided in
in [INT-DOMAIN-FRWK]. [I-D.ietf-ccamp-inter-domain-framework].
Some of the mechanisms used to establish and maintain inter-domain TE Some of the mechanisms used to establish and maintain inter-domain TE
LSPs are specified in [INTER-DOMAIN-SIG] and [LSP-STITCHING]. LSPs are specified in [I-D.ietf-ccamp-inter-domain-rsvp-te] and
[I-D.ietf-ccamp-lsp-stitching].
This document exclusively focuses on the path computation aspects and This document exclusively focuses on the path computation aspects and
defines a method for establishing inter-domain TE LSP where each node defines a method for establishing inter-domain TE LSP where each node
in charge of computing a section of an inter-domain TE LSP path is in charge of computing a section of an inter-domain TE LSP path is
always along the path of such TE LSP. always along the path of such TE LSP.
When the visibility of an end to end complete path spanning multiple When the visibility of an end to end complete path spanning multiple
domains is not available at the Head-end LSR, one approach described in domains is not available at the Head-end LSR, one approach described
this document consists of using a per-domain path computation technique in this document consists of using a per-domain path computation
technique during LSP setup to determine the inter-domain TE LSP as it
Vasseur, Ayyangar and Zhang 3 traverses multiple domains.
during LSP setup to determine the inter-domain TE LSP as it traverses
multiple domains.
The mechanisms proposed in this document are also applicable to MPLS TE The mechanisms proposed in this document are also applicable to MPLS
domains other than IGP areas and ASes. TE domains other than IGP areas and ASs.
The solution described in this document does not attempt to address all The solution described in this document does not attempt to address
the requirements specified in [INT-AREA-REQS] and [INT-AS-REQS]. This all the requirements specified in [RFC4105] and [RFC4216]. This is
is acceptable according to [INT-AS-REQS] which indicates that a acceptable according to [RFC4216] which indicates that a solution may
solution may be developed to address a particular deployment scenario be developed to address a particular deployment scenario and might,
and might, therefore, not meet all requirements for other deployment therefore, not meet all requirements for other deployment scenarios.
scenarios.
It must be pointed out that the inter-domain path computation technique It must be pointed out that the inter-domain path computation
proposed in this document is one among many others and the choice of technique proposed in this document is one among many others and the
the appropriate technique must be driven by the set of requirements for choice of the appropriate technique must be driven by the set of
the paths attributes and the applicability to a particular technique requirements for the paths attributes and the applicability to a
with respect to the deployment scenario. For example, if the particular technique with respect to the deployment scenario. For
requirement is to get an end-to-end constraint-based shortest path example, if the requirement is to get an end-to-end constraint-based
across multiple domains, then a mechanism using one or more distributed shortest path across multiple domains, then a mechanism using one or
PCEs could be used to compute the shortest path across different more distributed PCEs could be used to compute the shortest path
domains (see [PCE-ARCH]). Other offline mechanisms for path computation across different domains (see [I-D.ietf-pce-architecture]). Other
are not precluded either. Note also that a Service Provider may elect offline mechanisms for path computation are not precluded either.
to use different inter-domain path computation techniques for different Note also that a Service Provider may elect to use different inter-
TE LSP types. domain path computation techniques for different TE LSP types.
3. General assumptions 3. General assumptions
In the rest of this document, we make the following set of assumptions:
3.1. Common assumptions 3.1. Common assumptions
- Each domain in all the examples below is assumed to be capable of - Each domain in all the examples below is assumed to be capable of
doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP- doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and
TE). A domain may itself comprise multiple other domains. E.g. An AS RSVP-TE). A domain may itself comprise multiple other domains. E.g.
may itself be composed of several other sub-AS(es) (BGP confederations) An AS may itself be composed of several other sub-AS(es) (BGP
or areas/levels. In this case, the path computation technique described confederations) or areas/levels. In this case, the path computation
for inter-area and inter-AS MPLS Traffic Engineering just recursively technique described for inter-area and inter-AS MPLS Traffic
applies. Engineering just recursively applies.
- The inter-domain TE LSPs are signaled using RSVP-TE ([RSVP-TE]). - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209]).
- The path (ERO) for an inter-domain TE LSP may be signaled as a set
of (loose and/or strict) hops. The hops may identify:
- The path (ERO) for an inter-domain TE LSP may be signaled as a set of
(loose and/or strict) hops. The hops may identify:
* The complete strict path end-to-end across different domains * The complete strict path end-to-end across different domains
* The complete strict path in the source domain followed by
boundary LSRs (or domain identifiers, e.g. AS numbers) * The complete strict path in the source domain followed by boundary
LSRs (or domain identifiers, e.g. AS numbers)
* The complete list of boundary LSRs along the path * The complete list of boundary LSRs along the path
* The current boundary LSR and the LSP destination
Vasseur, Ayyangar and Zhang 4 * The current boundary LSR and the LSP destination.
The set of (loose or strict) hops can either be statically configured The set of (loose or strict) hops can either be statically configured
on the Head-end LSR or dynamically computed. A per-domain path on the Head-end LSR or dynamically computed. A per-domain path
computation method is defined in this document with an optional Auto- computation method is defined in this document with an optional Auto-
discovery mechanism based on IGP and/or BGP information yielding the discovery mechanism based on IGP and/or BGP information yielding the
next-hop boundary node (domain exit point, such as ABR/ASBR) along the next-hop boundary node (domain exit point, such as ABR/ASBR) along
path as the TE LSP is being signaled, along with potential crankback the path as the TE LSP is being signaled, along with potential
mechanisms. Alternatively the domain exit points may be statically crankback mechanisms. Alternatively the domain exit points may be
configured on the Head-end LSR in which case next-hop boundary node statically configured on the Head-end LSR in which case next-hop
auto-discovery would not be required. boundary node auto-discovery would not be required.
- Boundary LSRs are assumed to be capable of performing local path - Boundary LSRs are assumed to be capable of performing local path
computation for expansion of a loose next-hop in the signaled ERO if computation for expansion of a loose next-hop in the signaled ERO if
the path is not signaled by the Head-end LSR as a set of strict hops or the path is not signaled by the Head-end LSR as a set of strict hops
if the strict hop is an abstract node (e.g. an AS). In any case, no or if the strict hop is an abstract node (e.g. an AS). In any case,
topology or resource information needs to be distributed between no topology or resource information needs to be distributed between
domains (as mandated per [INT-AREA-REQS] and [INT-AS-REQS]), which is domains (as mandated per [RFC4105] and [RFC4216]), which is critical
critical to preserve IGP/BGP scalability and confidentiality in the to preserve IGP/BGP scalability and confidentiality in the case of TE
case of TE LSPs spanning multiple routing domains. LSPs spanning multiple routing domains.
- The paths for the intra-domain Hierarchical LSPs (H-LSP) or S-LSPs - The paths for the intra-domain Hierarchical LSPs (H-LSP) or S-LSPs
(S-LSP) or for a contiguous TE LSP within the domain may be pre- (S-LSP) or for a contiguous TE LSP within the domain may be pre-
configured or computed dynamically based on the arriving inter-domain configured or computed dynamically based on the arriving inter-domain
LSP setup request (depending on the requirements of the transit LSP setup request (depending on the requirements of the transit
domain). Note that this capability is explicitly specified as a domain). Note that this capability is explicitly specified as a
requirement in [INT-AS-REQS]. When the paths for the H-LSPs/S-LSP are requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP are
pre-configured, the constraints as well as other parameters like local pre-configured, the constraints as well as other parameters like
protection scheme for the intra-domain H-LSP/S-LSP are also pre- local protection scheme for the intra-domain H-LSP/S-LSP are also
configured. pre-configured.
- While certain constraints like bandwidth can be used across different - While certain constraints like bandwidth can be used across
domains, certain other TE constraints like resource affinity, color, different domains, certain other TE constraints like resource
metric, etc. as listed in [RFC2702] may need to be translated at domain affinity, color, metric, etc. as listed in [RFC2702] may need to be
boundaries. If required, it is assumed that, at the domain boundary translated at domain boundaries. If required, it is assumed that, at
LSRs, there will exist some sort of local mapping based on policy the domain boundary LSRs, there will exist some sort of local mapping
agreement in order to translate such constraints across domain based on policy agreement in order to translate such constraints
boundaries. It is expected that such an assumption particularly applies across domain boundaries. It is expected that such an assumption
to inter-AS TE: for example, the local mapping would be similar to the particularly applies to inter-AS TE: for example, the local mapping
Inter-AS TE Agreement Enforcement Polices stated in [INT-AS-REQS]. would be similar to the Inter-AS TE Agreement Enforcement Polices
stated in [RFC4216].
- The procedures defined in this document are applicable to any node
(not just boundary node) that receives a Path message with an ERO
that constains a loose hop or an abstract node that is not a simple
abstract node (that is, an abstract node that identifies more than
one LSR).
3.2. Example of topology for the inter-area TE case 3.2. Example of topology for the inter-area TE case
The following example will be used for the inter-area TE case in this The following example will be used for the inter-area TE case in this
document. document.
<-area 1-><-- area 0 --><--- area 2 ---> <-area 1-><-- area 0 --><--- area 2 --->
------ABR1------------ABR3------- ------ABR1------------ABR3-------
| / | | \ | | / | | \ |
R0--X1 | | X2---X3--R1 R0--X1 | | X2---X3--R1
| | | / | | | | / |
------ABR2-----------ABR4-------- ------ABR2-----------ABR4--------
<=========== Inter-area TE LSP =======> <=========== Inter-area TE LSP =======>
Vasseur, Ayyangar and Zhang 5
Figure 1 - Example of topology for the inter-area TE case Figure 1 - Example of topology for the inter-area TE case
Description of Figure 1: Description of Figure 1:
- ABR1, ABR2, ABR3 and ABR4 are ABRs, - ABR1, ABR2, ABR3 and ABR4 are ABRs,
- X1: an LSR in area 1, - X1: an LSR in area 1,
- X2, X3: LSRs in area 2, - X2, X3: LSRs in area 2,
- An inter-area TE LSP T0 originated at R0 in area 1 and terminating at - An inter-area TE LSP T0 originated at R0 in area 1 and terminating
R1 in area 2. at R1 in area 2.
Notes: Notes:
- The terminology used in the example above corresponds to OSPF but the
path computation technique proposed in this document equally applies to - The terminology used in the example above corresponds to OSPF but
the case of an IS-IS multi-level network. the path computation technique proposed in this document equally
- Just a few routers in each area are depicted in the diagram above for applies to the case of an IS-IS multi-level network.
the sake of simplicity.
- Just a few routers in each area are depicted in the diagram above
for the sake of simplicity.
- The example depicted in Figure 1 shows the case where the Head-end - The example depicted in Figure 1 shows the case where the Head-end
and Tail-end areas are connected by means of area 0. The case of an and Tail-end areas are connected by means of area 0. The case of an
inter-area TE LSP between two IGP areas that does not transit through inter-area TE LSP between two IGP areas that does not transit through
area 0 is not precluded. area 0 is not precluded.
3.3. Example of topology for the inter-AS TE case 3.3. Example of topology for the inter-AS TE case
We consider the following general case, built on a superset of the We consider the following general case, built on a superset of the
various scenarios defined in [INT-AS-REQS]: various scenarios defined in [RFC4216]:
<-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ---->
<---BGP---> <---BGP--> <---BGP---> <---BGP-->
CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9----R6
|\ \ | / | / | / | | | |\ \ | / | / | / | | |
| \ ASBR2---/ ASBR5 | -- | | | | \ ASBR2---/ ASBR5 | -- | | |
| \ | | |/ | | | | \ | | |/ | | |
R1-R2---ASBR3----ASBR6--R4---ASBR8----ASBR10---R7---CE2 R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2
<======= Inter-AS TE LSP(LSR to LSR)===========> <======= Inter-AS TE LSP(LSR to LSR)===========>
or or
<======== Inter-AS TE LSP (CE to ASBR => <======== Inter-AS TE LSP (CE to ASBR =>
or or
<================= Inter-AS TE LSP (CE to CE)===============> <================= Inter-AS TE LSP (CE to CE)===============>
Figure 2 - Example of topology for the inter-AS TE case Figure 2 - Example of topology for the inter-AS TE case
The diagram depicted in Figure 2 covers all the inter-AS TE deployment The diagram depicted in Figure 2 covers all the inter-AS TE
cases described in [INT-AS-REQS]. deployment cases described in [RFC4216].
Description of Figure 2: Description of Figure 2:
Vasseur, Ayyangar and Zhang 6 - Three interconnected ASs, respectively AS1, AS2, and AS3. Note
that in some scenarios described in [RFC4216] AS1=AS3.
- Three interconnected ASes, respectively AS1, AS2, and AS3. Note that
in some scenarios described in [INT-AS-REQS] AS1=AS3.
- The ASBRs in different ASes are BGP peers. There is usually no IGP - The ASBRs in different ASs are BGP peers. There is usually no IGP
running on the single hop links interconnecting the ASBRs and also running on the single hop links interconnecting the ASBRs and also
referred to as inter-ASBR links. referred to as inter-ASBR links.
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE - Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE
extensions (see [OSPF-TE], [ISIS-TE], [G-OSPF] and [G-ISIS]). In other extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In
words, the ASes are TE enabled, other words, the ASs are TE enabled,
- Each AS can be made of several IGP areas. The path computation - Each AS can be made of several IGP areas. The path computation
technique described in this document applies to the case of a single AS technique described in this document applies to the case of a single
made of multiple IGP areas, multiples ASes made of a single IGP areas AS made of multiple IGP areas, multiples ASs made of a single IGP
or any combination of the above. For the sake of simplicity, each areas or any combination of the above. For the sake of simplicity,
routing domain will be considered as single area in this document. The each routing domain will be considered as single area in this
case of an Inter-AS TE LSP spanning multiple ASes where some of those document. The case of an Inter-AS TE LSP spanning multiple ASs where
ASes are themselves made of multiple IGP areas can be easily derived some of those ASs are themselves made of multiple IGP areas can be
from the examples above: the per-domain path computation technique easily derived from the examples above: the per-domain path
described in this document is applied recursively in this case. computation technique described in this document is applied
recursively in this case.
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6 - An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6
in AS3. in AS3.
4. Per-domain path computation procedures 4. Per-domain path computation procedures
The mechanisms for inter-domain TE LSP computation as described in this The mechanisms for inter-domain TE LSP computation as described in
document can be used regardless of the nature of the inter-domain TE this document can be used regardless of the nature of the inter-
LSP (contiguous, stitched or nested). domain TE LSP (contiguous, stitched or nested).
Note that any path can be defined as a set of loose and strict hops. In Note that any path can be defined as a set of loose and strict hops.
other words, in some cases, it might be desirable to rely on the In other words, in some cases, it might be desirable to rely on the
dynamic path computation in some area, and exert a strict control on dynamic path computation in some area, and exert a strict control on
the path in other areas (defining strict hops). the path in other areas (defining strict hops).
When a boundary LSR (e.g. ABR/ASBR) receives a Path message with an ERO When an LSR (e.g. a boundary node such as an ABR/ASBR) receives a
that contains a loose hop or an abstract node that is not a simple Path message with an ERO that contains a loose hop or an abstract
abstract node (that is, an abstract node that identifies more than one node that is not a simple abstract node (that is, an abstract node
LSR), then it MUST follow the procedures as described in [INTER-DOMAIN- that identifies more than one LSR), then it MUST follow the
SIG]. In addition, the following procedures describe the path procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. In
computation procedures that SHOULD be carried out on the LSR: addition, the following procedures describe the path computation
procedures that SHOULD be carried out on the LSR:
1) If the next hop boundary LSR is not present in the TED. 1) If the next hop boundary LSR is not present in the TED.
If the loose next-hop is not present in the TED, the following If the loose next-hop is not present in the TED, the following
conditions MUST be checked: conditions MUST be checked:
- If the IP address of the next hop boundary LSR is outside of the - If the IP address of the next hop boundary LSR is outside of the
current domain, current domain,
- If the domain is PSC (Packet Switch Capable) and uses in-band - If the domain is PSC (Packet Switch Capable) and uses in-band
control channel control channel
Vasseur, Ayyangar and Zhang 7 If the two conditions above are satisfied then the boundary LSR
SHOULD check if the next-hop has IP reachability (via IGP or BGP).
If the two conditions above are satisfied then the boundary LSR SHOULD If the next-hop is not reachable, then a signaling failure occurs and
check if the next-hop has IP reachability (via IGP or BGP). If the the LSR SHOULD send back a PErr message upstream with error code=24
next-hop is not reachable, then a signaling failure occurs and the LSR ("Routing Problem") and error subcode as described in section 4.3.4
SHOULD send back a PathErr message upstream with error code=24 of [RFC3209]. If the next-hop is reachable, then it SHOULD find a
("Routing Problem") and error subcode as described in section 4.3.4 of domain boundary LSR (domain boundary point) to get to the next-hop.
[RSVP-TE]. If the next-hop is reachable, then it SHOULD find a domain The determination of domain boundary point based on routing
boundary LSR (domain boundary point) to get to the next-hop. The information is what we term as "auto-discovery" in this document. In
determination of domain boundary point based on routing information is the absence of such an auto-discovery mechanism, a) the ABR in the
what we term as "auto-discovery" in this document. In the absence of case of inter-area TE or the ASBR in the next-hop AS in the case of
such an auto-discovery mechanism, a) the ABR in the case of inter-area inter-AS TE should be the signaled loose next-hop in the ERO and
TE or the ASBR in the next-hop AS in the case of inter-AS TE should be hence should be accessible via the TED or b) there needs to be an
the signaled loose next-hop in the ERO and hence should be accessible alternate scheme that provides the domain exit points. Otherwise the
via the TED or b) there needs to be an alternate scheme that provides path computation for the inter-domain TE LSP will fail.
the domain exit points. Otherwise the path computation for the inter-
domain TE LSP will fail.
An implementation MAY support the ability to disable such IP An implementation MAY support the ability to disable such IP
reachability fall-back option should the next hop boundary LSR not be reachability fall-back option should the next hop boundary LSR not be
present in the TED. In other words, an implementation MAY support the present in the TED. In other words, an implementation MAY support
possibility to trigger a signaling failure whenever the next-hop is not the possibility to trigger a signaling failure whenever the next-hop
present in the TED. is not present in the TED.
2) If the next-hop boundary LSR is present in the TED. 2) Once the next-hop boundary LSR has been determined (according to
the procedure described in 1)) or if the next-hop boundary is present
in the TED
a) Case of a contiguous TE LSP. The boundary LSR that processes a) Case of a contiguous TE LSP. The boundary LSR that processes the
the ERO SHOULD perform an ERO expansion (unless not allowed by ERO SHOULD perform an ERO expansion (unless not allowed by policy)
policy) after having computed the path to the next loose hop after having computed the path to the next loose hop (ABR/ASBR) that
(ABR/ASBR) that obeys the set of required constraints. If no obeys the set of required constraints. If no path satisfying the set
path satisfying the set of constraints can be found, then this of constraints can be found, then this SHOULD be treated as a path
SHOULD be treated as a path computation and signaling failure computation and signaling failure and a PErr message SHOULD be sent
and a PathErr message SHOULD be sent for the inter-domain TE for the inter-domain TE LSP based on section 4.3.4 of [RFC3209].
LSP based on section 4.3.4 of [RSVP-TE].
b) Case of stitched or nested LSP b) Case of stitched or nested LSP
i) If the boundary LSR is a candidate LSR for intra- i) If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP
area H-LSP/S-LSP setup (the LSR has local policy for setup (the LSR has local policy for nesting or stitching), and if
nesting or stitching), and if there is no H-LSP/S-LSP there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR
from this LSR to the next-hop boundary LSR that that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP to the
satisfies the constraints, it SHOULD signal a H-LSP/S- next-hop boundary LSR. If pre-configured H-LSP(s) or S-LSP(s)
LSP to the next-hop boundary LSR. If pre-configured H- already exist, then it will try to select from among those intra-
LSP(s) or S-LSP(s) already exist, then it will try to domain LSPs. Depending on local policy, it MAY signal a new H-LSP/
select from among those intra-domain LSPs. Depending on S-LSP if this selection fails. If the H-LSP/S-LSP is successfully
local policy, it MAY signal a new H-LSP/S-LSP if this signaled or selected, it propagates the inter-domain Path message to
selection fails. If the H-LSP/S-LSP is successfully the next-hop following the procedures described in [I-D.ietf-ccamp-
signaled or selected, it propagates the inter-domain inter-domain-rsvp-te]. If, for some reason the dynamic H-LSP/S-LSP
Path message to the next-hop following the procedures setup to the next-hop boundary LSR fails, then this SHOULD be treated
described in [INTER-DOMAIN-SIG]. If, for some reason as a path computation and signaling failure and a PErr message SHOULD
the dynamic H-LSP/S-LSP setup to the next-hop boundary be sent upstream for the inter-domain LSP. Similarly, if selection
LSR fails, then this SHOULD be treated as a path of a preconfigured H-LSP/S-LSP fails and local policy prevents
dynamic H-LSP/S this SHOULD be treated as a path computation and
Vasseur, Ayyangar and Zhang 8 signaling failure and a PErr SHOULD be sent upstream for the inter-
computation and signaling failure and a PathErr message domain TE LSP. In both these cases procedures described in section
SHOULD be sent upstream for the inter-domain LSP. 4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
Similarly, if selection of a preconfigured H-LSP/S-LSP
fails and local policy prevents dynamic H-LSP/S this
SHOULD be treated as a path computation and signaling
failure and a PathErr SHOULD be sent upstream for the
inter-domain TE LSP. In both these cases procedures
described in section 4.3.4 of [RSVP-TE] SHOULD be
followed to handle the failure.
ii) If, however, the boundary LSR is not a candidate ii) If, however, the boundary LSR is not a candidate for intra-domain
for intra-domain H-LSP/S-LSP (the LSR does not have H-LSP/S-LSP (the LSR does not have local policy for nesting or
local policy for nesting or stitching), then it SHOULD stitching), then it SHOULD apply the same procedure as for the
apply the same procedure as for the contiguous case. contiguous case.
Note that in both cases, path computation and signaling Note that in both cases, path computation and signaling process may
process may be stopped due to policy violation. be stopped due to policy violation.
The ERO of an inter-domain TE LSP may comprise abstract nodes such as The ERO of an inter-domain TE LSP may comprise abstract nodes such as
ASes. In such a case, upon receiving the ERO whose next hop is an AS, ASs. In such a case, upon receiving the ERO whose next hop is an AS,
the boundary LSR has to determine the next-hop boundary LSR which may the boundary LSR has to determine the next-hop boundary LSR which may
be determined based on the "auto-discovery" process mentioned above. If be determined based on the "auto-discovery" process mentioned above.
multiple ASBRs candidates exist the boundary LSR may apply some If multiple ASBRs candidates exist the boundary LSR may apply some
policies based on peering contracts that may have been pre-negotiated. policies based on peering contracts that may have been pre-
Once the next-hop boundary LSR has been determined a similar procedure negotiated. Once the next-hop boundary LSR has been determined a
as the one described above is followed. similar procedure as the one described above is followed.
Note related to the inter-AS TE case Note related to the inter-AS TE case
The links interconnecting ASBRs are usually not TE-enabled and no IGP The links interconnecting ASBRs are usually not TE-enabled and no IGP
is running at the AS boundaries. An implementation supporting inter-AS is running at the AS boundaries. An implementation supporting
MPLS TE MUST allow the set up of inter-AS TE LSP over the region inter-AS MPLS TE MUST allow the set up of inter-AS TE LSP over the
interconnecting multiple ASBRs. In other words, an ASBR compliant with region interconnecting multiple ASBRs. In other words, an ASBR
this document MUST support the set up of TE LSP over inter-ASBR links compliant with this document MUST support the set up of TE LSP over
and MUST be able to perform all the usual operations related to MPLS inter-ASBR links and MUST be able to perform all the usual operations
Traffic Engineering (call admission control, ...). related to MPLS Traffic Engineering (call admission control, ...).
In terms of computation of an inter-AS TE LSP path, an interesting In terms of computation of an inter-AS TE LSP path, an interesting
optimization technique consists of allowing the ASBRs to flood the TE optimization technique consists of allowing the ASBRs to flood the TE
information related to the inter-ASBR link(s) although no IGP TE is information related to the inter-ASBR link(s) although no IGP TE is
enabled over those links (and so there is no IGP adjacency over the enabled over those links (and so there is no IGP adjacency over the
inter-ASBR links). This of course implies for the inter-ASBR links to inter-ASBR links). This of course implies for the inter-ASBR links
be TE-enabled although no IGP is running on those links. This allows an to be TE-enabled although no IGP is running on those links. This
LSR (could be entry ASBR) in the previous AS to make a more appropriate allows an LSR (could be entry ASBR) in the previous AS to make a more
route selection up to the entry ASBR in the immediately downstream AS appropriate route selection up to the entry ASBR in the immediately
taking into account the constraints associated with the inter-ASBR downstream AS taking into account the constraints associated with the
links. This reduces the risk of call set up failure due to inter-ASBR inter-ASBR links. This reduces the risk of call set up failure due
links not satisfying the inter-AS TE LSP set of constraints. Note that to inter-ASBR links not satisfying the inter-AS TE LSP set of
the TE information is only related to the inter-ASBR links: the TE constraints. Note that the TE information is only related to the
LSA/LSP flooded by the ASBR includes not only the TE-enabled links inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not
contained in the AS but also the inter-ASBR links. only the TE-enabled links contained in the AS but also the inter-ASBR
links.
Vasseur, Ayyangar and Zhang 9
Note that no summarized TE information is leaked between ASes which is Note that no summarized TE information is leaked between ASs which is
compliant with the requirements listed in [INT-AREA-REQS] and [INT-AS- compliant with the requirements listed in [RFC4105] and [RFC4216].
REQS].
For example, consider the diagram depicted in Figure 2: when ASBR1 For example, consider the diagram depicted in Figure 2: when ASBR1
floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS)) in floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS))
its routing domain, it reflects the reservation states and TE in its routing domain, it reflects the reservation states and TE
properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1- properties of the following links: X1-ASBR1, ASBR1-ASBR2 and ASBR1-
ASBR4. ASBR4.
Thanks to such an optimization, the inter-ASBRs TE link information Thanks to such an optimization, the inter-ASBRs TE link information
corresponding to the links originated by the ASBR is made available in corresponding to the links originated by the ASBR is made available
the TED of other LSRs in the same domain that the ASBR belongs to. in the TED of other LSRs in the same domain that the ASBR belongs to.
Consequently, the path computation for an inter-AS TE LSP path can also Consequently, the path computation for an inter-AS TE LSP path can
take into account the inter-ASBR link(s). This will improve the chance also take into account the inter-ASBR link(s). This will improve the
of successful signaling along the next AS in case of resource shortage chance of successful signaling along the next AS in case of resource
or unsatisfied constraints on inter-ASBR links and it potentially shortage or unsatisfied constraints on inter-ASBR links and it
reduces one level of crankback. Note that no topology information is potentially reduces one level of crankback. Note that no topology
flooded and these links are not used in IGP SPF computations. Only the information is flooded and these links are not used in IGP SPF
TE information for the outgoing links directly connected to the ASBR is computations. Only the TE information for the outgoing links
advertised. directly connected to the ASBR is advertised.
Note that an Operator may decide to operate a stitched segment or 1-hop Note that an Operator may decide to operate a stitched segment or
hierarchical LSP for the inter-ASBR link. 1-hop hierarchical LSP for the inter-ASBR link.
4.1. Example with an inter-area TE LSP 4.1. Example with an inter-area TE LSP
4.1.1 Case 1: T1 is a contiguous TE LSP 4.1.1. Case 1: T0 is a contiguous TE LSP
The Head-end LSR (R0) first determines the next hop ABR (which could be The Head-end LSR (R0) first determines the next hop ABR (which could
manually configured by the user or dynamically determined by using be manually configured by the user or dynamically determined by using
auto-discovery mechanism). R0 then computes the path to reach the auto-discovery mechanism). R0 then computes the path to reach the
selected next hop ABR and signals the Path message. When the Path selected next hop ABR (ABR1) and signals the Path message. When the
message reaches ABR1, it first determines the next hop ABR from its Path message reaches ABR1, it first determines the next hop ABR from
area 0 along the LSP path (say ABR3), either directly from the ERO (if its area 0 along the LSP path (say ABR3), either directly from the
for example the next hop ABR is specified as a loose hop in the ERO) or ERO (if for example the next hop ABR is specified as a loose hop in
by using the auto-discovery mechanism specified above. the ERO) or by using the auto-discovery mechanism specified above.
- Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose) - Example 1 (set of loose hops): R0-ABR1(loose)-ABR3(loose)-R1(loose)
- Example 2 (mix of strict and loose hops): R0-X1-ASR1-ABR3(loose)-X2-
X3-R1
Note that a set of paths can be configured on the Head-end LSR, ordered
by priority. Each priority path can be associated with a different set
of constraints. It may be desirable to systematically have a last
resort option with no constraint to ensure that the inter-area TE LSP
could always be set up if at least a TE path exists between the inter-
area TE LSP source and destination. In case of set up failure or when
an RSVP PathErr is received indicating the TE LSP has suffered a
failure, an implementation might support the possibility to retry a
Vasseur, Ayyangar and Zhang 10 - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)-
X2-X3-R1
particular path option configurable amount of times (optionally with Note that a set of paths can be configured on the Head-end LSR,
dynamic intervals between each trial) before trying a lower priority ordered by priority. Each priority path can be associated with a
path option. different set of constraints. It may be desirable to systematically
have a last resort option with no constraint to ensure that the
inter-area TE LSP could always be set up if at least a TE path exists
between the inter-area TE LSP source and destination. In case of set
up failure or when an RSVP PErr is received indicating the TE LSP has
suffered a failure, an implementation might support the possibility
to retry a particular path option configurable amount of times
(optionally with dynamic intervals between each trial) before trying
a lower priority path option.
Once it has computed the path up to the next hop ABR (ABR3), ABR1 sends Once it has computed the path up to the next hop ABR (ABR3), ABR1
the Path message along the computed path. Upon receiving the Path sends the Path message along the computed path. Upon receiving the
message, ABR3 then repeats a similar procedure. If ABR3 cannot find a Path message, ABR3 then repeats a similar procedure. If ABR3 cannot
path obeying the set of constraints for the inter-area TE LSP, the find a path obeying the set of constraints for the inter-area TE LSP,
signaling process stops and ABR3 sends a PathErr message to ABR1. Then the signaling process stops and ABR3 sends a PErr message to ABR1.
ABR1 can in turn trigger a new path computation by selecting another Then ABR1 can in turn trigger a new path computation by selecting
egress boundary LSR (ABR4 in the example above) if crankback is allowed another egress boundary LSR (ABR4 in the example above) if crankback
for this inter-area TE LSP (see [CRANKBACK]). If crankback is not is allowed for this inter-area TE LSP (see [I-D.ietf-ccamp-
allowed for that inter-area TE LSP or if ABR1 has been configured not crankback]). If crankback is not allowed for that inter-area TE LSP
to perform crankback, then ABR1 MUST stop the signaling process and or if ABR1 has been configured not to perform crankback, then ABR1
MUST forward a PathErr up to the Head-end LSR (R0) without trying to MUST stop the signaling process and MUST forward a PErr up to the
select another ABR. Head-end LSR (R0) without trying to select another ABR.
4.1.2 Case 2: T1 is a stitched or nested TE LSP 4.1.2. Case 2: T0 is a stitched or nested TE LSP
The Head-end LSR (R0) first determines the next hop ABR (which could be The Head-end LSR (R0) first determines the next hop ABR (which could
manually configured by the user or dynamically determined by using be manually configured by the user or dynamically determined by using
auto-discovery mechanism). R0 then computes the path to reach the auto-discovery mechanism). R0 then computes the path to reach the
selected next hop ABR and signals the Path message. When the Path selected next hop ABR and signals the Path message. When the Path
message reaches ABR1, it first determines the next hop ABR from its message reaches ABR1, it first determines the next hop ABR from its
area 0 along the LSP path (say ABR3), either directly from the ERO (if area 0 along the LSP path (say ABR3), either directly from the ERO
for example the next hop ABR is specified as a loose hop in the ERO) or (if for example the next hop ABR is specified as a loose hop in the
by using an auto-discovery mechanism, specified above. ERO) or by using an auto-discovery mechanism, specified above.
ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the
constraints carried in the inter-area TE LSP Path message. If not, ABR1 constraints carried in the inter-area TE LSP Path message. If not,
computes the path for a H-LSP or S-LSP from ABR1 to ABR3 satisfying the ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3
constraint and sets it up accordingly. Note that the H-LSP or S-LSP satisfying the constraint and sets it up accordingly. Note that the
could have also been pre-configured. H-LSP or S-LSP could have also been pre-configured.
Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using Once ABR1 has selected the H-LSP/S-LSP for the inter-area LSP, using
the signaling procedures described in [INTER-DOMAIN-SIG], ABR1 sends the signaling procedures described in [I-D.ietf-ccamp-inter-domain-
the Path message for inter-area TE LSP to ABR3. Note that irrespective rsvp-te], ABR1 sends the Path message for inter-area TE LSP to ABR3.
of whether ABR1 does nesting or stitching, the Path message for the Note that irrespective of whether ABR1 does nesting or stitching, the
inter-area TE LSP is always forwarded to ABR3. ABR3 then repeats the Path message for the inter-area TE LSP is always forwarded to ABR3.
exact same procedures. If ABR3 cannot find a path obeying the set of ABR3 then repeats the exact same procedures. If ABR3 cannot find a
constraints for the inter-area TE LSP, ABR3 sends a PathErr message to path obeying the set of constraints for the inter-area TE LSP, ABR3
ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to ABR3 sends a PErr message to ABR1. Then ABR1 can in turn either select
if such an LSP exists or select another egress boundary LSR (ABR4 in another H-LSP/S-LSP to ABR3 if such an LSP exists or select another
the example above) if crankback is allowed for this inter-area TE LSP egress boundary LSR (ABR4 in the example above) if crankback is
(see [CRANKBACK]). If crankback is not allowed for that inter-area TE allowed for this inter-area TE LSP (see [I-D.ietf-ccamp-crankback]).
LSP or if ABR1 has been configured not to perform crankback, then ABR1 If crankback is not allowed for that inter-area TE LSP or if ABR1 has
forwards the PathErr up to the inter-area Head-end LSR (R0) without been configured not to perform crankback, then ABR1 forwards the PErr
trying to select another egress LSR. up to the inter-area Head-end LSR (R0) without trying to select
another egress LSR.
4.2. Example with an inter-AS TE LSP 4.2. Example with an inter-AS TE LSP
Vasseur, Ayyangar and Zhang 11 The path computation procedures for establishing an inter-AS TE LSP
are very similar to those of an inter-area TE LSP described above.
The path computation procedures for establishing an inter-AS TE LSP are The main difference is related to the presence of inter-ASBRs
very similar to those of an inter-area TE LSP described above. The main link(s).
difference is related to the presence of inter-ASBRs link(s).
4.2.1. Case 1: T1 is a contiguous TE LSP 4.2.1. Case 1: T1 is a contiguous TE LSP
The inter-AS TE path may be configured on the Head-end LSR as a set of The inter-AS TE path may be configured on the Head-end LSR as a set
strict hops, loose hops or a combination of both. of strict hops, loose hops or a combination of both.
- Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose) - Example 1 (set of loose hops): ASBR4(loose)-ASBR9(loose)-R6(loose)
- Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1-ASBR4-
ASBR10(loose)-ASBR9-R6 - Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1-
ASBR4-ASBR10(loose)-ASBR9-R6
In the example 1 above, a per-AS path computation is performed, In the example 1 above, a per-AS path computation is performed,
respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note that respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note
when an LSR has to perform an ERO expansion, the next hop must either that when an LSR has to perform an ERO expansion, the next hop must
belong to the same AS, or must be the ASBR directly connected to the either belong to the same AS, or must be the ASBR directly connected
next hops AS. In this later case, the ASBR reachability is announced in to the next hops AS. In this later case, the ASBR reachability is
the IGP TE LSA/LSP originated by its neighboring ASBR. In the example 1 announced in the IGP TE LSA/LSP originated by its neighboring ASBR.
above, the TE LSP path is defined as: ASBR4(loose)-ASBR9(loose)- In the example 1 above, the TE LSP path is defined as: ASBR4(loose)-
R6(loose). This implies that R0 must compute the path from R0 to ASBR4, ASBR9(loose)-R6(loose). This implies that R0 must compute the path
hence the need for R0 to get the TE reservation state related to the from R0 to ASBR4, hence the need for R0 to get the TE reservation
ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In addition, ASBR1 must state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In
also announce the IP address of ASBR4 specified in the T1's path addition, ASBR1 must also announce the IP address of ASBR4 specified
configuration. in the T1's path configuration.
Once it has computed the path up to the next hop ASBR, ASBR1 sends the Once it has computed the path up to the next hop ASBR, ASBR1 sends
Path message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 the Path message for the inter-area TE LSP to ASBR4 (supposing that
is the selected next hop ASBR). ASBR4 then repeats the exact same ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact
procedures. If ASBR4 cannot find a path obeying the set of constraints same procedures. If ASBR4 cannot find a path obeying the set of
for the inter-AS TE LSP, then ASBR4 sends a PathErr message to ASBR1. constraints for the inter-AS TE LSP, then ASBR4 sends a PErr message
Then ASBR1 can in turn either select another ASBR (ASBR5 in the example to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5
above) if crankback is allowed for this inter-AS TE LSP (see in the example above) if crankback is allowed for this inter-AS TE
[CRANKBACK]). If crankback is not allowed for that inter-AS TE LSP or LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not allowed
if ASBR1 has been configured not to perform crankback, ABR1 stops the for that inter-AS TE LSP or if ASBR1 has been configured not to
signaling process and forwards a PathErr up to the Head-end LSR (R0) perform crankback, ABR1 stops the signaling process and forwards a
without trying to select another egress LSR. In this case, the Head-end PErr up to the Head-end LSR (R0) without trying to select another
LSR can in turn select another sequence of loose hops, if configured. egress LSR. In this case, the Head-end LSR can in turn select
Alternatively, the Head-end LSR may decide to retry the same path; this another sequence of loose hops, if configured. Alternatively, the
can be useful in case of set up failure due an outdated IGP TE database Head-end LSR may decide to retry the same path; this can be useful in
in some downstream AS. An alternative could also be for the Head-end case of set up failure due an outdated IGP TE database in some
LSR to retry to same sequence of loose hops after having relaxed some downstream AS. An alternative could also be for the Head-end LSR to
retry to same sequence of loose hops after having relaxed some
constraint(s). constraint(s).
4.2.2. Case 2: T1 is a stitched or nested TE LSP 4.2.2. Case 2: T1 is a stitched or nested TE LSP
The path computation procedures are very similar to the inter-area LSP The path computation procedures are very similar to the inter-area
setup case described earlier. In this case, the H-LSPs or S-LSPs are LSP setup case described earlier. In this case, the H-LSPs or S-LSPs
originated by the ASBRs at the entry to the AS. are originated by the ASBRs at the entry to the AS.
Vasseur, Ayyangar and Zhang 12
5. Path optimality/diversity 5. Path optimality/diversity
Since the inter-domain TE LSP is computed on a per domain (area, AS) Since the inter-domain TE LSP is computed on a per domain (area, AS)
basis, one cannot guarantee that the optimal inter-domain path can be basis, one cannot guarantee that the optimal inter-domain path can be
found. found.
Moreover, computing two diverse paths using a per-domain path Moreover, computing two diverse paths using a per-domain path
computation approach may not be possible in some topologies (due to the computation approach may not be possible in some topologies (due to
well-known "trapping" problem). the well-known 'trapping' problem).
As already pointed out, the required path computation method can be As already pointed out, the required path computation method can be
selected by the Service Provider on a per LSP basis. selected by the Service Provider on a per LSP basis.
If the per-domain path computation technique does no meet the set of If the per-domain path computation technique does no meet the set of
requirements for a particular TE LSP (e.g. path optimality, requirements for a particular TE LSP (e.g. path optimality,
requirements for a set of diversely routed TE LSPs, ...) other techniques requirements for a set of diversely routed TE LSPs, ...) other
such as PCE-based path computation techniques may be used (see [PCE- techniques such as PCE-based path computation techniques may be used
ARCH]). (see [I-D.ietf-pce-architecture]).
6. Reoptimization of an inter-domain TE LSP 6. Reoptimization of an inter-domain TE LSP
The ability to reoptimize an already established inter-domain TE LSP The ability to reoptimize an already established inter-domain TE LSP
constitutes a requirement. The reoptimization process significantly constitutes a requirement. The reoptimization process significantly
differs based upon the nature of the TE LSP and the mechanism in use differs based upon the nature of the TE LSP and the mechanism in use
for the TE LSP computation. for the TE LSP computation.
The following mechanisms can be used for reoptimization and are The following mechanisms can be used for reoptimization and are
dependent on the nature of the inter-domain TE LSP. dependent on the nature of the inter-domain TE LSP.
6.1. Contiguous TE LSPs 6.1. Contiguous TE LSPs
After an inter-domain TE LSP has been set up, a more optimal route After an inter-domain TE LSP has been set up, a more optimal route
might appear within any traversed domain. Then in this case, it is might appear within any traversed domain. Then in this case, it is
desirable to get the ability to reroute an inter-domain TE LSP in a desirable to get the ability to reroute an inter-domain TE LSP in a
non-disruptive fashion (making use of the so-called Make-Before-Break non-disruptive fashion (making use of the so-called Make-Before-Break
procedure) to follow such more optimal path. This is a known as a TE procedure) to follow such more optimal path. This is a known as a TE
LSP reoptimization procedure. LSP reoptimization procedure.
[LOOSE-REOPT] proposes a mechanism that allows the Head-end LSR to be [I-D.ietf-ccamp-loose-path-reopt] proposes a mechanism that allows
notified of the existence of a more optimal path in a downstream the Head-end LSR to be notified of the existence of a more optimal
domain. The Head-end LSR may then decide to gracefully reroute the TE path in a downstream domain. The Head-end LSR may then decide to
LSP using the so-called Make-Before-Break procedure. gracefully reroute the TE LSP using the so-called Make-Before-Break
In case of a contiguous LSP, the reoptimization process is strictly procedure. In case of a contiguous LSP, the reoptimization process
controlled by the Head-end LSR which triggers the make-before-break is strictly controlled by the Head-end LSR which triggers the make-
procedure, regardless of the location of the more optimal path. before-break procedure, regardless of the location of the more
optimal path.
6.2. Stitched or nested (non-contiguous) TE LSPs 6.2. Stitched or nested (non-contiguous) TE LSPs
In the case of a stitched or nested inter-domain TE LSP, the In the case of a stitched or nested inter-domain TE LSP, the
reoptimization process is treated as a local matter to any domain. The reoptimization process is treated as a local matter to any domain.
The main reason is that the inter-domain TE LSP is a different LSP
Vasseur, Ayyangar and Zhang 13 (and therefore different RSVP session) from the intra-domain S-LSP or
H-LSP in an area or an AS. Therefore, reoptimization in a domain is
main reason is that the inter-domain TE LSP is a different LSP (and done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since
therefore different RSVP session) from the intra-domain S-LSP or H-LSP the inter-domain TE LSPs are transported using S-LSP or H-LSP across
in an area or an AS. Therefore, reoptimization in a domain is done by each domain, optimality of the inter-domain TE LSP in a domain is
locally reoptimizing the intra-domain H-LSP or S-LSP. Since the inter- dependent on the optimality of the corresponding S-LSP or H-LSPs.
domain TE LSPs are transported using S-LSP or H-LSP across each domain, If, after an inter-domain LSP is setup, a more optimal path is
optimality of the inter-domain TE LSP in a domain is dependent on the available within an domain, the corresponding S-LSP or H-LSP will be
optimality of the corresponding S-LSP or H-LSPs. If, after an inter- reoptimized using "Make-Before-Break" techniques discussed in
domain LSP is setup, a more optimal path is available within an domain, [RFC3209]. Reoptimization of the H-LSP or S-LSP automatically
the corresponding S-LSP or H-LSP will be reoptimized using "Make- reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP
Before-Break" techniques discussed in [RSVP-TE]. Reoptimization of the transports. Reoptimization parameters like frequency of
H-LSP or S-LSP automatically reoptimizes the inter-domain TE LSPs that reoptimization, criteria for reoptimization like metric or bandwidth
the H-LSP or the S-LSP transports. Reoptimization parameters like availability, etc can vary from one domain to another and can be
frequency of reoptimization, criteria for reoptimization like metric or configured as required, per intra-domain TE S-LSP or H-LSP if it is
bandwidth availability, etc can vary from one domain to another and can
be configured as required, per intra-domain TE S-LSP or H-LSP if it is
preconfigured or based on some global policy within the domain. preconfigured or based on some global policy within the domain.
Hence, in this scheme, since each domain takes care of reoptimizing its Hence, in this scheme, since each domain takes care of reoptimizing
own S-LSPs or H-LSPs, and therefore the corresponding inter-domain TE its own S-LSPs or H-LSPs, and therefore the corresponding inter-
LSPs, the Make-Before-Break can happen locally and is not triggered by domain TE LSPs, the Make-Before-Break can happen locally and is not
the Head-end LSR for the inter-domain LSP. So, no additional RSVP triggered by the Head-end LSR for the inter-domain LSP. So, no
signaling is required for LSP reoptimization and reoptimization is additional RSVP signaling is required for LSP reoptimization and
transparent to the Head-end LSR of the inter-domain TE LSP. reoptimization is transparent to the Head-end LSR of the inter-domain
TE LSP.
If, however, an operator desires to manually trigger reoptimization at If, however, an operator desires to manually trigger reoptimization
the Head-end LSR for the inter-domain TE LSP, then this solution does at the Head-end LSR for the inter-domain TE LSP, then this solution
not prevent that. A manual trigger for reoptimization at the Head-end does not prevent that. A manual trigger for reoptimization at the
LSR SHOULD force a reoptimization thereby signaling a "new" path for Head-end LSR SHOULD force a reoptimization thereby signaling a "new"
the same LSP (along the more optimal path) making use of the Make- path for the same LSP (along the more optimal path) making use of the
Before-Break procedure. In response to this new setup request, the Make-Before-Break procedure. In response to this new setup request,
boundary LSR may either initiate new S-LSP setup, in case the inter- the boundary LSR may either initiate new S-LSP setup, in case the
domain TE LSP is being stitched to the intra-domain S-LSP or it may inter-domain TE LSP is being stitched to the intra-domain S-LSP or it
select an existing or new H-LSP in case of nesting. When the LSP setup may select an existing or new H-LSP in case of nesting. When the LSP
along the current path is complete, the Head-end LSR should switchover setup along the current path is complete, the Head-end LSR should
the traffic onto that path and the old path is eventually torn down. switchover the traffic onto that path and the old path is eventually
Note that the Head-end LSR does not know a priori whether a more torn down. Note that the Head-end LSR does not know a priori whether
optimal path exists. Such a manual trigger from the Head-end LSR of the a more optimal path exists. Such a manual trigger from the Head-end
inter-domain TE LSP is, however, not considered to be a frequent LSR of the inter-domain TE LSP is, however, not considered to be a
occurrence. frequent occurrence.
Note that stitching or nesting rely on local optimization: the Note that stitching or nesting rely on local optimization: the
reoptimization process allows to locally reoptimize each TE S-LSP reoptimization process allows to locally reoptimize each TE S-LSP or
or H-LSP: hence, the reoptimization is not global and consequently the H-LSP: hence, the reoptimization is not global and consequently the
end to end path may no longer be optimal should it be optimal when end-to-end path may no longer be optimal should it be optimal when
being set up. being set up.
Procedures described in [LOOSE-REOPT] MUST be used if the operator does Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be
not desire local reoptimization of certain inter-domain LSPs. In this used if the operator does not desire local reoptimization of certain
case, any reoptimization event within the domain MUST be reported to inter-domain LSPs. In this case, any reoptimization event within the
the Head-end node. This SHOULD be a configurable policy. domain MUST be reported to the Head-end node. This SHOULD be a
configurable policy.
Vasseur, Ayyangar and Zhang 14
6.3. Path characteristics after reoptimization 6.3. Path characteristics after reoptimization
Note that in the case of loose hop reoptimization of contiguous inter- Note that in the case of loose hop reoptimization of contiguous
domain TE LSP or local reoptimization of stitched/nested S-LSP where inter-domain TE LSP or local reoptimization of stitched/nested S-LSP
boundary LSRs are specified as loose hops, the TE LSP may follow a where boundary LSRs are specified as loose hops, the TE LSP may
preferable path within one or more domain(s) but would still traverse follow a preferable path within one or more domain(s) but would still
the same set of boundary LSRs. In contrast, in the case of PCE-based traverse the same set of boundary LSRs. In contrast, in the case of
path computation techniques, because end to end optimal path is PCE-based path computation techniques, because end to end optimal
computed, the reoptimization process may lead to following a completely path is computed, the reoptimization process may lead to following a
different inter-domain path (including a different set of boundary completely different inter-domain path (including a different set of
LSRs). boundary LSRs).
7. Security Considerations
Signaling of inter-domain TE LSPs raises security issues that have been
described in section 7 of [INTER-DOMAIN-SIG]; however the path
computation aspects specified in this document do not raise additional
security concerns.
8. Intellectual Property Considerations 7. IANA Considerations
The IETF takes no position regarding the validity or scope of any This document makes no request for any IANA action.
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 8. Security Considerations
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 Signaling of inter-domain TE LSPs raises security issues that have
copyrights, patents or patent applications, or other proprietary been described in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te];
rights that may cover technology that may be required to implement however the path computation aspects specified in this document do
this standard. Please address the information to the IETF at ietf- not raise additional security concerns.
ipr@ietf.org.
9. Acknowledgments 9. Acknowledgements
We would like to acknowledge input and helpful comments from Adrian We would like to acknowledge input and helpful comments from Adrian
Farrel, Jean-Louis Le Roux and Dimitri Papadimitriou. Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam.
10. References 10. References
Vasseur, Ayyangar and Zhang 15
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
requirements levels", RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3979] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Technology", BCP 79, RFC 3979, March 2005. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RSVP] Braden, et al, "Resource ReSerVation Protocol (RSVP)" Version [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
1, Functional Specification", RFC 2205, September 1997. McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
3209, December 2001. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
Extensions to OSPF Version 2", RFC 3630, September 2003. (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering", [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[G-OSPF]Rekhter Y., Kompella K, et al., "OSPF Extensions in Support of [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
Generalized Multi-Protocol Label Switching", draft-ietf-ccamp-ospf- of Generalized Multi-Protocol Label Switching (GMPLS)",
gmpls-extensions, work in progress. RFC 4203, October 2005.
[G-ISIS] Rekhter Y., Kompella K, et al., "IS-IS Extensions in Support
of Generalized Multi-Protocol Label Switching", draft-ietf-isis-gmpls-
extensions, work in progress.
10.2. Informative references [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005.
[CRANKBACK] Farrel A., et al., "Crankback Signaling Extensions for MPLS 10.2. Informative References
and GMPLS RSVP-TE", draft-ietf-ccamp-crankback, work in progress.
[INT-AREA-REQ] Le Roux, J.L., Vasseur, J.P., Boyle, J., "Requirements [I-D.ietf-ccamp-crankback]
for inter-area MPLS Traffic Engineering", RFC 4105, June 2005. Farrel, A., "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", draft-ietf-ccamp-crankback-05 (work in
progress), May 2005.
[INT-AS-REQ] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic [I-D.ietf-ccamp-inter-domain-framework]
Engineering Requirements", draft-ietf-tewg-interas-mpls-te-req, work in Farrel, A., "A Framework for Inter-Domain MPLS Traffic
progress. Engineering", draft-ietf-ccamp-inter-domain-framework-04
(work in progress), July 2005.
[INT-DOMAIN-FRWK] Farrel, A., Vasseur, J.P., Ayyangar, A., "A Framework [I-D.ietf-ccamp-inter-domain-pd-path-comp]
for Inter-Domain MPLS Traffic Engineering", draft-ietf-ccamp-inter- Vasseur, J., "A Per-domain path computation method for
domain-framework, work in progress. establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-01 (work in
progress), October 2005.
Vasseur, Ayyangar and Zhang 16 [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic
Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in
progress), October 2005.
[INTER-DOMAIN-SIG] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS [I-D.ietf-ccamp-loose-path-reopt]
Traffic Engineering - RSVP extensions", draft-ietf-ccamp-inter-domain- Vasseur, J., "Reoptimization of Multiprotocol Label
rsvp-te, work in progress. Switching (MPLS) Traffic Engineering (TE) loosely routed
Label Switch Path (LSP)",
draft-ietf-ccamp-loose-path-reopt-02 (work in progress),
February 2006.
[LSP-STITCHING] Ayyangar, A., Vasseur, JP. "Label Switched Path [I-D.ietf-ccamp-lsp-stitching]
Stitching with Generalized MPLS Traffic Engineering", draft-ietf-ccamp- Ayyangar, A. and J. Vasseur, "Label Switched Path
lsp-stitching-00, work under progress. Stitching with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-02 (work in progress),
September 2005.
[LOOSE-PATH-REOPT] Vasseur, Ikejiri and Zhang "Reoptimization of an [I-D.ietf-pce-architecture]
explicit loosely routed MPLS TE paths", draft-ietf-ccamp-loose-path- Farrel, A., "A Path Computation Element (PCE) Based
reopt, work in Progress. Architecture", draft-ietf-pce-architecture-04 (work in
progress), January 2006.
[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002. Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[PCE-ARCH] Farrel A., Vasseur J.P, Ash J, "Path Computation Element [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(PCE) Architecture", draft-ietf-pce-architecture, work in progress. (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005.
Authors' Address: Authors' Addresses
Jean-Philippe Vasseur (Editor) JP Vasseur (editor)
Cisco Systems, Inc. Cisco Systems, Inc
300 Beaver Brook Road 1414 Massachusetts Avenue
Boxborough , MA - 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
Arthi Ayyangar (Editor) Arthi Ayyangar (editor)
Juniper Networks, Inc Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Avenue
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
e-mail: arthi@juniper.net
Email: arthi@juniper.net
Raymond Zhang Raymond Zhang
BT/Infonet BT Infonet
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond_zhang@infonet.com
Full Copyright Statement Email: raymond_zhang@bt.infonet.com
Copyright (C) The Internet Society (2005). This document is subject to Intellectual Property Statement
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights. 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.
Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
Vasseur, Ayyangar and Zhang 17
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Vasseur, Ayyangar and Zhang 18 Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 132 change blocks. 
540 lines changed or deleted 560 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/