draft-ietf-ccamp-inter-domain-pd-path-comp-06.txt   rfc5152.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Request for Comments: 5152 Cisco Systems, Inc.
Intended status: Standards Track A. Ayyangar, Ed. Category: Standards Track A. Ayyangar, Ed.
Expires: May 19, 2008 Juniper Networks, Inc Juniper Networks
R. Zhang R. Zhang
BT BT
November 16, 2007 February 2008
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-06
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 19, 2008. Status of This Memo
Copyright Notice
Copyright (C) The IETF Trust (2007). This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract Abstract
This document specifies a per-domain path computation technique for This document specifies a per-domain path computation technique for
establishing inter-domain Traffic Engineering (TE) Multiprotocol establishing inter-domain Traffic Engineering (TE) Multiprotocol
Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched
Paths (LSPs). In this document a domain refers to a collection of Paths (LSPs). In this document, a domain refers to a collection of
network elements within a common sphere of address management or path network elements within a common sphere of address management or path
computational responsibility such as IGP areas and Autonomous computational responsibility such as Interior Gateway Protocol (IGP)
Systems. areas and Autonomous Systems.
Per-domain computation applies where the full path of an inter-domain 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 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 LSP, and is not signaled across domain boundaries. This is most
likely to arise owing to TE visibility limitations. The signaling likely to arise owing to TE visibility limitations. The signaling
message indicates the destination and nodes up to the next domain message indicates the destination and nodes up to the next domain
boundary. It may also indicate further domain boundaries or domain boundary. It may also indicate further domain boundaries or domain
identifiers. The path through each domain, possibly including the identifiers. The path through each domain, possibly including the
choice of exit point from the domain, must be determined within the choice of exit point from the domain, must be determined within the
domain. domain.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology .....................................................3
3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language ......................................4
3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 3. General Assumptions .............................................4
3.2. Example of topology for the inter-area TE case . . . . . . 7 3.1. Common Assumptions .........................................4
3.3. Example of topology for the inter-AS TE case . . . . . . . 8 3.2. Example of Topology for the Inter-Area TE Case .............6
4. Per-domain path computation procedures . . . . . . . . . . . . 9 3.3. Example of Topology for the Inter-AS TE Case ...............7
4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 13 4. Per-Domain Path Computation Procedures ..........................8
4.1.1. Case 1: T0 is a contiguous TE LSP . . . . . . . . . . 13 4.1. Example with an Inter-Area TE LSP .........................11
4.1.2. Case 2: T0 is a stitched or nested TE LSP . . . . . . 14 4.1.1. Case 1: T0 Is a Contiguous TE LSP ..................11
4.2. Example with an inter-AS TE LSP . . . . . . . . . . . . . 14 4.1.2. Case 2: T0 Is a Stitched or Nested TE LSP ..........12
4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 4.2. Example with an Inter-AS TE LSP ...........................13
4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 15 4.2.1. Case 1: T1 Is a Contiguous TE LSP ..................13
5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 4.2.2. Case 2: T1 Is a Stitched or Nested TE LSP ..........14
6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 16 5. Path Optimality/Diversity ......................................14
6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 17 6. Reoptimization of an Inter-Domain TE LSP .......................15
6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 17 6.1. Contiguous TE LSPs ........................................15
6.3. Path characteristics after reoptimization . . . . . . . . 18 6.2. Stitched or Nested (non-contiguous) TE LSPs ...............16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.3. Path Characteristics after Reoptimization .................17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations ........................................17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements ...............................................18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. References .....................................................18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References ......................................18
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References ....................................18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 23
1. Terminology
Terminology used in this document
AS: Autonomous System.
ABR: Area Border Router: routers used to connect two IGP areas (areas
in OSPF or levels in IS-IS).
ASBR: Autonomous System Border Router: routers used to connect
together ASes of a different or 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-area TE or an ASBR in the context of inter-AS TE.
ERO: Explicit Route Object
IGP: Interior Gateway Protocol
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router.
LSP: Label Switched Path.
TE LSP: Traffic Engineering Label Switched Path.
PCE: Path Computation Element: an entity (component, application or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TED: Traffic Engineering Database.
The notion of contiguous, stitched and nested TE LSPs is defined in
[RFC4726] and will not be repeated here.
2. Introduction 1. 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 [RFC4105] and [RFC4216]. The framework Group and have been stated in [RFC4105] and [RFC4216]. The framework
for inter-domain MPLS Traffic Engineering has been provided in for inter-domain MPLS Traffic Engineering has been provided in
[RFC4726]. [RFC4726].
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 [I-D.ietf-ccamp-inter-domain-rsvp-te] and LSPs are specified in [RFC5151] and [RFC5150].
[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 LSPs where each
in charge of computing a section of an inter-domain TE LSP path is node in charge of computing a section of an inter-domain TE LSP path
always along the path of such TE LSP. is always along the path of such a 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 (LSR that inititiated domains is not available at the Head-end LSR (the LSR that initiated
the TE LSP), one approach described in this document consists of the TE LSP), one approach described in this document consists of
using a per-domain path computation technique during LSP setup to using a per-domain path computation technique during LSP setup to
determine the inter-domain TE LSP as it traverses multiple domains. determine the inter-domain TE LSP as it traverses multiple domains.
The mechanisms proposed in this document are also applicable to MPLS The mechanisms proposed in this document are also applicable to MPLS
TE domains other than IGP areas and ASs. TE domains other than IGP areas and ASs.
The solution described in this document does not attempt to address The solution described in this document does not attempt to address
all the requirements specified in [RFC4105] and [RFC4216]. This is all the requirements specified in [RFC4105] and [RFC4216]. This is
acceptable according to [RFC4216] which indicates that a solution may acceptable according to [RFC4216], which indicates that a solution
be developed to address a particular deployment scenario and might, may be developed to address a particular deployment scenario and
therefore, not meet all requirements for other deployment scenarios. might, therefore, not meet all requirements for other deployment
scenarios.
It must be pointed out that the inter-domain path computation It must be pointed out that the inter-domain path computation
technique proposed in this document is one among many others and the technique proposed in this document is one among many others. The
choice of the appropriate technique must be driven by the set of choice of the appropriate technique must be driven by the set of
requirements for the paths attributes and the applicability to a requirements for the path attributes and the applicability to a
particular technique with respect to the deployment scenario. For particular technique with respect to the deployment scenario. For
example, if the requirement is to get an end-to-end constraint-based example, if the requirement is to get an end-to-end constraint-based
shortest path across multiple domains, then a mechanism using one or shortest path across multiple domains, then a mechanism using one or
more distributed PCEs could be used to compute the shortest path more distributed PCEs could be used to compute the shortest path
across different domains (see [RFC4655]). Other offline mechanisms across different domains (see [RFC4655]). Other off-line mechanisms
for path computation are not precluded either. Note also that a for path computation are not precluded either. Note also that a
Service Provider may elect to use different inter-domain path Service Provider may elect to use different inter-domain path
computation techniques for different TE LSP types. computation techniques for different TE LSP types.
3. General assumptions 2. Terminology
3.1. Common assumptions Terminology used in this document:
AS: Autonomous System.
ABR: Area Border Router, a router used to connect two IGP areas
(areas in OSPF or levels in Intermediate System to Intermediate
System (IS-IS)).
ASBR: Autonomous System Border Router, a router used to connect
together ASs of a different or 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-area TE or an ASBR in the context of inter-AS TE.
ERO: Explicit Route Object.
IGP: Interior Gateway Protocol.
Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
Inter-area TE LSP: A TE LSP that crosses an IGP area.
LSR: Label Switching Router.
LSP: Label Switched Path.
TE LSP: Traffic Engineering Label Switched Path.
PCE: Path Computation Element, an entity (component, application, or
network node) that is capable of computing a network path or route
based on a network graph and applying computational constraints.
TED: Traffic Engineering Database.
The notion of contiguous, stitched, and nested TE LSPs is defined in
[RFC4726] and will not be repeated here.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. General 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 doing Traffic Engineering (i.e., running OSPF-TE or ISIS-TE and
RSVP-TE). A domain may itself comprise multiple other domains. E.g. RSVP-TE (Resource Reservation Protocol Traffic Engineering)). A
An AS may itself be composed of several other sub-AS(es) (BGP domain may itself comprise multiple other domains, e.g., an AS may
confederations) or areas/levels. In this case, the path computation itself be composed of several other sub-ASs (BGP confederations) or
technique described for inter-area and inter-AS MPLS Traffic areas/levels. In this case, the path computation technique
Engineering just recursively applies. described for inter-area and inter-AS MPLS Traffic Engineering
applies recursively.
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and
[RFC3473]). [RFC3473]).
- The path (specified by an ERO (Explicit Route Object) in an RSVP-TE - The path (specified by an ERO (Explicit Route Object) in an RSVP-TE
Path message)) for an inter-domain TE LSP may be signaled as a set of Path message) for an inter-domain TE LSP may be signaled as a set
(loose and/or strict) hops. of (loose and/or strict) hops.
- The hops may identify: - 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 * The complete strict path in the source domain followed by
LSRs (or domain identifiers, e.g. AS numbers) 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. * 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 be either 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
discovery mechanism based on IGP, BGP, policy routing information auto-discovery mechanism (e.g., based on IGP, BGP, policy routing
yielding the next-hop boundary node (domain exit point, such as Area information) yielding the next-hop boundary node (domain exit point,
Border Router (ABR) or an Autonomous System Border Router (ASBR) such as an Area Border Router (ABR) or an Autonomous System Border
along the path as the TE LSP is being signaled, along with potential Router (ASBR)) along the path as the TE LSP is being signaled, along
crankback mechanisms. Alternatively the domain exit points may be with potential crankback mechanisms. Alternatively, the domain exit
statically configured on the Head-end LSR in which case next-hop points may be statically configured on the Head-end LSR, in which
boundary node auto-discovery would not be required. case next-hop 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
the path is not signaled by the Head-end LSR as a set of strict hops if the path is not signaled by the Head-end LSR as a set of strict
or if the strict hop is an abstract node (e.g. an AS). In any case, hops or if the strict hop is an abstract node (e.g., an AS). In
no topology or resource information needs to be distributed between any case, no topology or resource information needs to be
domains (as mandated per [RFC4105] and [RFC4216]), which is critical distributed between domains (as mandated per [RFC4105] and
to preserve IGP/BGP scalability and confidentiality in the case of TE [RFC4216]), which is critical to preserve IGP/BGP scalability and
LSPs spanning multiple routing domains. confidentiality in the case of TE LSPs spanning multiple routing
domains.
- The paths for the intra-domain Hierarchical LSPs (H-LSP) or - The paths for the intra-domain Hierarchical LSP (H-LSP) or Stitched
Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain LSP (S-LSP) or for a contiguous TE LSP within the domain may be
may be pre-configured or computed dynamically based on the arriving pre-configured or computed dynamically based on the arriving
inter-domain LSP setup request (depending on the requirements of the inter-domain LSP setup request (depending on the requirements of
transit domain). Note that this capability is explicitly specified the transit domain). Note that this capability is explicitly
as a requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP specified as a requirement in [RFC4216]. When the paths for the
are pre-configured, the constraints as well as other parameters like H-LSP/S-LSP are pre-configured, the constraints as well as other
local protection scheme for the intra-domain H-LSP/S-LSP are also parameters like a local protection scheme for the intra-domain H-
pre-configured. LSP/S-LSP are also pre-configured.
- While certain constraints like bandwidth can be used across - While certain constraints like bandwidth can be used across
different domains, certain other TE constraints like resource different domains, certain other TE constraints like resource
affinity, color, metric, etc. as listed in [RFC2702] may need to be affinity, color, metric, etc. as listed in [RFC2702] may need to be
translated at domain boundaries. If required, it is assumed that, at translated at domain boundaries. If required, it is assumed that,
the domain boundary LSRs, there will exist some sort of local mapping at the domain boundary LSRs, there will exist some sort of local
based on policy agreement in order to translate such constraints mapping based on policy agreement in order to translate such
across domain boundaries. It is expected that such an assumption constraints across domain boundaries. It is expected that such an
particularly applies to inter-AS TE: for example, the local mapping assumption particularly applies to inter-AS TE: for example, the
would be similar to the Inter-AS TE Agreement Enforcement Polices local mapping would be similar to the inter-AS TE agreement
stated in [RFC4216]. enforcement polices stated in [RFC4216].
- The procedures defined in this document are applicable to any node - The procedures defined in this document are applicable to any node
(not just boundary node) that receives a Path message with an ERO (not just a boundary node) that receives a Path message with an ERO
that constains a loose hop or an abstract node that is not a simple that constrains a loose hop or an abstract node that is not a
abstract node (that is, an abstract node that identifies more than simple abstract node (that is, an abstract node that identifies
one LSR). 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 =======>
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 is an LSR in area 1.
- X2, X3: LSRs in area 2, - X2 and X3 are LSRs in area 2.
- An inter-area TE LSP T0 originated at R0 in area 1 and terminating - An inter-area TE LSP T0 originated at R0 in area 1 and terminated
at R1 in area 2. at R1 in area 2.
Notes: Notes:
- The terminology used in the example above corresponds to OSPF but - The terminology used in the example above corresponds to OSPF, but
the path computation technique proposed in this document equally the path computation technique proposed in this document equally
applies to the case of an IS-IS multi-level network. applies to the case of an IS-IS multi-level network.
- Just a few routers in each area are depicted in the diagram above - Just a few routers in each area are depicted in the diagram above
for the sake of simplicity. 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
inter-area TE LSP between two IGP areas that does not transit through an inter-area TE LSP between two IGP areas that does not transit
area 0 is not precluded. through 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 [RFC4216]: various scenarios defined in [RFC4216]:
<-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---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
skipping to change at page 9, line 4 skipping to change at page 7, line 44
- Three interconnected ASs, respectively AS1, AS2, and AS3. Note - Three interconnected ASs, respectively AS1, AS2, and AS3. Note
that in some scenarios described in [RFC4216] AS1=AS3. that in some scenarios described in [RFC4216] AS1=AS3.
- The ASBRs in different ASs 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 [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In extensions (see [RFC3630], [RFC3784], [RFC4203] and [RFC4205]). In
other words, the ASes are TE enabled, other words, the ASs are TE enabled.
- CE: Customer Edge router.
- 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 technique described in this document applies to the case of a
AS made of multiple IGP areas, multiples ASs made of a single IGP single AS made of multiple IGP areas, multiple ASs made of a single
areas or any combination of the above. For the sake of simplicity, IGP area, or any combination of the above. For the sake of
each routing domain will be considered as single area in this simplicity, each routing domain will be considered as a single area
document. The case of an Inter-AS TE LSP spanning multiple ASs where in this document. The case of an inter-AS TE LSP spanning multiple
some of those ASs are themselves made of multiple IGP areas can be ASs where some of those ASs are themselves made of multiple IGP
easily derived from the examples above: the per-domain path areas can be easily derived from the examples above: the per-domain
computation technique described in this document is applied path computation technique described in this document is applied
recursively in this case. 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 terminated 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 The mechanisms for inter-domain TE LSP computation as described in
this document can be used regardless of the nature of the inter- this document can be used regardless of the nature of the
domain TE LSP (contiguous, stitched or nested). inter-domain TE LSP (contiguous, stitched, or nested).
Note that any path can be defined as a set of loose and strict hops. Note that any path can be defined as a set of loose and strict hops.
In 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 domain, and exert a strict control dynamic path computation in some domains, and exert a strict control
on the path in other domains (defining strict hops). on the path in other domains (defining strict hops).
When an LSR that is a boundary node such as an ABR/ASBR receives a When an LSR that is a boundary node such as an ABR/ASBR receives a
Path message with an ERO that contains a strict node, the procedures Path message with an ERO that contains a strict node, the procedures
specified in [RFC3209] apply and no further action is needed. specified in [RFC3209] apply and no further action is needed.
When an LSR that is a boundary node such as an ABR/ASBR receives a When an LSR that is a boundary node such as an ABR/ASBR receives a
Path message with an ERO that contains a loose hop or an abstract Path message with an ERO that contains a loose hop or an abstract
node that is not a simple abstract node (that is, an abstract node node that is not a simple abstract node (that is, an abstract node
that identifies more than one LSR), then it MUST follow the that identifies more than one LSR), then it MUST follow the
procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. procedures as described in [RFC5151].
In addition, the following procedures describe the path computation In addition, the following procedures describe the path computation
procedures that SHOULD be carried out on the LSR: procedures that SHOULD be carried out on the LSR:
1) If the next hop is not present in the TED, the two following 1) If the next hop is not present in the TED, the two following
conditions MUST be checked: conditions MUST be checked:
o If the IP address of the next hop boundary LSR is outside of the o Whether the IP address of the next-hop boundary LSR is outside
current domain, of the current domain
o If the next hop domain is PSC (Packet Switch Capable) and uses in-
band control channel
If the two conditions above are satisfied then the boundary LSR o Whether the next-hop domain is PSC (Packet Switch Capable) and
SHOULD check if the next-hop has IP reachability (via IGP or BGP). uses in-band control channel
If the next-hop is not reachable, then a signaling failure occurs and
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 next hop is not reachable, then a signaling failure occurs and
the LSR SHOULD send back an RSVP PathErr message upstream with error the LSR SHOULD send back an RSVP PathErr message upstream with error
code=24 ("Routing Problem") and error subcode as described in section code=24 ("Routing Problem") and error subcode as described in section
4.3.4 of [RFC3209]. If the available routing information indicates 4.3.4 of [RFC3209]. If the available routing information indicates
that next-hop is reachable, the selected route will be expected to that next hop is reachable, the selected route will be expected to
pass through a domain boundary via a domain boundary LSR. The pass through a domain boundary via a domain boundary LSR. The
determination of domain boundary point based on routing information determination of domain boundary point based on routing information
is what we term as "auto-discovery" in this document. In the absence is what we term as "auto-discovery" in this document. In the absence
of such an auto-discovery mechanism, a) the ABR in the case of inter- of such an auto-discovery mechanism, a) the ABR in the case of
area TE or the ASBR in the next-hop AS in the case of inter-AS TE inter-area TE or the ASBR in the next-hop AS in the case of inter-AS
should be the signaled loose next-hop in the ERO and hence should be TE should be the signaled loose next hop in the ERO and hence should
accessible via the TED or b) there needs to be an alternate scheme be accessible via the TED, or b) there needs to be an alternate
that provides the domain exit points. Otherwise the path computation scheme that provides the domain exit points. Otherwise, the path
for the inter-domain TE LSP will fail. 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 an 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 present in the TED. In other words, an implementation MAY support
the possibility to trigger a signaling failure whenever the next-hop the possibility to trigger a signaling failure whenever the next hop
is not present in the TED. is not present in the TED.
2) Once the next-hop boundary LSR has been determined (according to 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 the procedure described in 1)) or if the next-hop boundary is
in the TED present in the TED:
o Case of a contiguous TE LSP. Unless not allowed by policy, the o Case of a contiguous TE LSP. Unless not allowed by policy, the
boundary LSR that processes the ERO SHOULD perform an ERO boundary LSR that processes the ERO SHOULD perform an ERO
expansion (process consisting of computing the constrained path up expansion (a process consisting of computing the constrained
to the next loose hop and add the list of hops as strcit nodes in path up to the next loose hop and adding the list of hops as
the ERO). If no path satisfying the set of constraints can be strict nodes in the ERO). If no path satisfying the set of
found, then this is treated as a path computation and signaling constraints can be found, then this is treated as a path
failure and an RSVP PathErr message SHOULD be sent for the inter- computation and signaling failure and an RSVP PathErr message
domain TE LSP based on section 4.3.4 of [RFC3209]. SHOULD be sent for the inter-domain TE LSP based on section
4.3.4 of [RFC3209].
o Case of stitched or nested LSP o Case of a stitched or nested TE LSP
* If the boundary LSR is a candidate LSR for intra-area H-LSP/ * If the boundary LSR is a candidate LSR for intra-area H-LSP/
S-LSP setup (the boundary has local policy for nesting or S-LSP setup (the boundary has local policy for nesting or
stitching), the TE LSP is a candidate for hierarchy/nesting stitching), the TE LSP is a candidate for hierarchy/nesting
(the "Contiguous LSP" bit defined in (the "Contiguous LSP" bit defined in [RFC5151] is not set),
[I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there and if there is no H-LSP/S-LSP from this LSR to the next-hop
is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR boundary LSR that satisfies the constraints, it SHOULD
that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP signal an H-LSP/S-LSP to the next-hop boundary LSR. If a
to the next-hop boundary LSR. If pre-configured H-LSP(s) or pre-configured H-LSP(s) or S-LSP(s) already exists, then it
S-LSP(s) already exist, then it will try to select from among will try to select from among those intra-domain LSPs.
those intra-domain LSPs. Depending on local policy, it MAY Depending on local policy, it MAY signal a new H-LSP/S-LSP
signal a new H-LSP/S-LSP if this selection fails. If the if this selection fails. If the H-LSP/S-LSP is successfully
H-LSP/S-LSP is successfully signaled or selected, it propagates signaled or selected, it propagates the inter-domain Path
the inter-domain Path message to the next-hop following the message to the next hop following the procedures described
procedures described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. in [RFC5151]. If for some reason the dynamic H-LSP/S-LSP
If, for some reason the dynamic H-LSP/S-LSP setup to the next- setup to the next-hop boundary LSR fails, then this SHOULD
hop boundary LSR fails, then this SHOULD be treated as a path be treated as a path computation and signaling failure and
computation and signaling failure and an RSVP PathErr message an RSVP PathErr message SHOULD be sent upstream for the
SHOULD be sent upstream for the inter-domain LSP. Similarly, inter-domain LSP. Similarly, if selection of a pre-
if selection of a preconfigured H-LSP/S-LSP fails and local configured H-LSP/S-LSP fails and local policy prevents
policy prevents dynamic H-LSP/S this SHOULD be treated as a dynamic H-LSP/S, this SHOULD be treated as a path
path computation and signaling failure and an RSVP PathErr computation and signaling failure and an RSVP PathErr
SHOULD be sent upstream for the inter-domain TE LSP. In both message SHOULD be sent upstream for the inter-domain TE LSP.
these cases procedures described in section 4.3.4 of [RFC3209] In both of these cases, procedures described in section
SHOULD be followed to handle the failure. 4.3.4 of [RFC3209] SHOULD be followed to handle the failure.
* If, however, the boundary LSR is not a candidate for intra- * If, however, the boundary LSR is not a candidate for
domain H-LSP/S-LSP (the boundary LSR does not have local policy intra-domain H-LSP/S-LSP (the boundary LSR does not have
for nesting or stitching) or the TE LSP is a not candidate for local policy for nesting or stitching) or the TE LSP is not
hierarchy/nesting (the "Contiguous LSP" bit defined in a candidate for hierarchy/nesting (the "Contiguous LSP" bit
[I-D.ietf-ccamp-inter-domain-rsvp-te] is set), then it SHOULD defined in [RFC5151] is set), then it SHOULD apply the same
apply the same procedure as for the contiguous case. procedure as for the contiguous case.
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 ASs. In such a case, upon receiving the ERO whose next hop is an AS,
AS, the boundary LSR has to determine the next-hop boundary LSR which the boundary LSR has to determine the next-hop boundary LSR, which
may be determined based on the "auto-discovery" process mentioned may be determined based on the auto-discovery process mentioned
above. If multiple ASBRs candidates exist the boundary LSR may apply above. If multiple ASBR candidates exist, the boundary LSR may apply
some policies based on peering contracts that may have been pre- some policies based on peering contracts that may have been
negotiated. Once the next-hop boundary LSR has been determined a pre-negotiated. Once the next-hop boundary LSR has been determined,
similar procedure as the one described above is followed. a similar procedure as the one described above is followed.
Note related to the inter-AS TE case: Note the following related to the inter-AS TE case:
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 inter-ASBR links). This of course implies that the inter-ASBR links
to be TE-enabled although no IGP is running on those links. be TE-enabled although no IGP is running on those links.
<-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> <-- AS1 ----> <------- AS2 ------><--- AS3 ----->
<---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
Figure 3 - Flooding of the TE-related information for the Inter-ASBR links Figure 3 - Flooding of the TE-related information for
the inter-ASBR links
Referring to figure 3, ASBR1 for example would advertise in its OSPF Referring to Figure 3, ASBR1 for example would advertise in its OSPF
LSA/IS-IS LSP the Traffic Engineering TLVs related to the link ASBR1- Link State Advertisement (LSA)/IS-IS LSP the Traffic Engineering TLVs
ASBR4. related to the link ASBR1-ASBR4.
This allows an LSR (could be entry ASBR) in the previous AS to make a This allows an LSR (could be the entry ASBR) in the previous AS to
more appropriate route selection up to the entry ASBR in the make a more appropriate route selection up to the entry ASBR in the
immediately downstream AS taking into account the constraints immediately downstream AS taking into account the constraints
associated with the inter-ASBR links. This reduces the risk of call associated with the inter-ASBR links. This reduces the risk of call
set up failure due to inter-ASBR links not satisfying the inter-AS TE set up failure due to inter-ASBR links not satisfying the inter-AS TE
LSP set of constraints. Note that the TE information is only related LSP set of constraints. Note that the TE information is only related
to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes to the inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes
not only the TE-enabled links contained in the AS but also the inter- not only the TE-enabled links contained in the AS but also the
ASBR links. inter-ASBR links.
Note that no summarized TE information is leaked between ASes which Note that no summarized TE information is leaked between ASs, which
is compliant with the requirements listed in [RFC4105] and [RFC4216]. is compliant with the requirements listed in [RFC4105] and [RFC4216].
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)) floods its IGP TE LSA ((opaque LSA for OSPF)/LSP (TLV 22 for IS-IS))
in 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
ASBR4. ASBR1-ASBR4.
Thanks to such an optimization, the inter-ASBRs TE link information Thanks to such an optimization, the inter-ASBR TE link information
corresponding to the links originated by the ASBR is made available corresponding to the links originated by the ASBR is made available
in the TED of other LSRs in the same domain that the ASBR belongs to. in the TED of other LSRs in the same domain to which the ASBR
Consequently, the path computation for an inter-AS TE LSP path can belongs. Consequently, the path computation for an inter-AS TE LSP
also take into account the inter-ASBR link(s). This will improve the path can also take into account the inter-ASBR link(s). This will
chance of successful signaling along the next AS in case of resource improve the chance of successful signaling along the next AS in case
shortage or unsatisfied constraints on inter-ASBR links and it of resource shortage or unsatisfied constraints on inter-ASBR links,
potentially reduces one level of crankback. Note that no topology and it potentially reduces one level of crankback. Note that no
information is flooded and these links are not used in IGP SPF topology information is flooded, and these links are not used in IGP
computations. Only the TE information for the outgoing links SPF computations. Only the TE information for the outgoing links
directly connected to the ASBR is advertised. directly connected to the ASBR is advertised.
Note that an Operator may decide to operate a stitched segment or Note that an operator may decide to operate a stitched segment or
1-hop 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
The following example uses figure 1 as a reference. The following example uses Figure 1 as a reference.
4.1.1. Case 1: T0 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 The Head-end LSR (R0) first determines the next-hop ABR (which could
be 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 the auto-discovery mechanism). R0 then computes the path to reach
selected next hop ABR (ABR1) and signals the Path message. When the the selected next-hop ABR (ABR1) and signals the Path message. When
Path message reaches ABR1, it first determines the next hop ABR from the Path message reaches ABR1, it first determines the next-hop ABR
its area 0 along the LSP path (say ABR3), either directly from the from its area 0 along the LSP path (say, ABR3), either directly from
ERO (if for example the next hop ABR is specified as a loose hop in the ERO (if for example the next-hop ABR is specified as a loose hop
the ERO) or by using the auto-discovery mechanism specified above. in 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-ABR1-ABR3(loose)- - Example 2 (mix of strict and loose hops):
X2-X3-R1 R0-X1-ABR1-ABR3(loose)-X2-X3-R1
Note that a set of paths can be configured on the Head-end LSR, 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 ordered by priority. Each priority path can be associated with a
different set of constraints. It may be desirable to systematically different set of constraints. It may be desirable to systematically
have a last resort option with no constraint to ensure that the 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 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 between the inter-area TE LSP source and destination. In case of
up failure or when an RSVP PathErr is received indicating the TE LSP setup failure or when an RSVP PathErr is received indicating that the
has suffered a failure, an implementation might support the TE LSP has suffered a failure, an implementation might support the
possibility to retry a particular path option configurable amount of possibility of retrying a particular path option a configurable
times (optionally with dynamic intervals between each trial) before amount of times (optionally with dynamic intervals between each
trying a lower priority path option. trial) before trying a lower-priority path option.
Once it has computed the path up to the next hop ABR (ABR3), ABR1 Once it has computed the path up to the next-hop ABR (ABR3), ABR1
sends the Path message along the computed path. Upon receiving the sends the Path message along the computed path. Upon receiving the
Path message, ABR3 then repeats a similar procedure. If ABR3 cannot Path message, ABR3 then repeats a similar procedure. If ABR3 cannot
find a path obeying the set of constraints for the inter-area TE LSP, find a path obeying the set of constraints for the inter-area TE LSP,
the signaling process stops and ABR3 sends a PathErr message to ABR1. the signaling process stops and ABR3 sends a PathErr message to ABR1.
Then ABR1 can in turn trigger a new path computation by selecting Then ABR1 can in turn trigger a new path computation by selecting
another egress boundary LSR (ABR4 in the example above) if crankback another egress boundary LSR (ABR4 in the example above) if crankback
is allowed for this inter-area TE LSP (see is allowed for this inter-area TE LSP (see [RFC4920]). If crankback
[I-D.ietf-ccamp-crankback]). If crankback is not allowed for that is not allowed for that inter-area TE LSP or if ABR1 has been
inter-area TE LSP or if ABR1 has been configured not to perform configured not to perform crankback, then ABR1 MUST stop the
crankback, then ABR1 MUST stop the signaling process and MUST forward signaling process and MUST forward a PathErr up to the Head-end LSR
a PathErr up to the Head-end LSR (R0) without trying to select (R0) without trying to select another ABR.
another ABR.
4.1.2. Case 2: T0 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 The Head-end LSR (R0) first determines the next-hop ABR (which could
be 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 the auto-discovery mechanism). R0 then computes the path to reach
selected next hop ABR and signals the Path message. When the Path the selected next-hop ABR 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 its area 0 along the LSP path (say ABR3), either directly from the
(if for example the next hop ABR is specified as a loose hop in the ERO (if for example the next-hop ABR is specified as a loose hop in
ERO) or by using an auto-discovery mechanism, specified above. the 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 whether it has an H-LSP or S-LSP to ABR3 matching
constraints carried in the inter-area TE LSP Path message. If not, the constraints carried in the inter-area TE LSP Path message. If
ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 not, ABR1 computes the path for an H-LSP or S-LSP from ABR1 to ABR3
satisfying the constraint and sets it up accordingly. Note that the satisfying the constraint and sets it up accordingly. Note that the
H-LSP or S-LSP 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 the signaling procedures described in [RFC5151], ABR1 sends the Path
[I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message message for the inter-area TE LSP to ABR3. Note that irrespective of
for inter-area TE LSP to ABR3. Note that irrespective of whether whether ABR1 does nesting or stitching, the Path message for the
ABR1 does nesting or stitching, the Path message for the inter-area inter-area TE LSP is always forwarded to ABR3. ABR3 then repeats the
TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same exact same procedures. If ABR3 cannot find a path obeying the set of
procedures. If ABR3 cannot find a path obeying the set of
constraints for the inter-area TE LSP, ABR3 sends a PathErr message constraints for the inter-area TE LSP, ABR3 sends a PathErr message
to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to to ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to
ABR3 if such an LSP exists or select another egress boundary LSR ABR3 if such an LSP exists or select another egress boundary LSR
(ABR4 in the example above) if crankback is allowed for this inter- (ABR4 in the example above) if crankback is allowed for this inter-
area TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not area TE LSP (see [RFC4920]). If crankback is not allowed for that
allowed for that inter-area TE LSP or if ABR1 has been configured not inter-area TE LSP or if ABR1 has been configured not to perform
to perform crankback, then ABR1 forwards the PathErr up to the inter- crankback, then ABR1 forwards the PathErr up to the inter-area Head-
area Head-end LSR (R0) without trying to select another egress LSR. 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
The following example uses figure 2 as a reference. The following example uses Figure 2 as a reference.
The path computation procedures for establishing an inter-AS TE LSP The path computation procedures for establishing an inter-AS TE LSP
are very similar to those of an inter-area TE LSP described above. are very similar to those of an inter-area TE LSP described above.
The main difference is related to the presence of inter-ASBRs The main difference is related to the presence of inter-ASBR link(s).
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 The inter-AS TE path may be configured on the Head-end LSR as a set
of 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):
- Example 2 (mix of strict and loose hops): R2-ASBR3-ASBR2-ASBR1- ASBR4(loose)-ASBR9(loose)-R6(loose)
ASBR4-ASBR10(loose)-ASBR9-R6
In the example 1 above, a per-AS path computation is performed, - Example 2 (mix of strict and loose hops):
respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3. Note R2-ASBR3-ASBR2-ASBR1-ASBR4-ASBR10(loose)-ASBR9-R6
that when an LSR has to perform an ERO expansion, the next hop must
either belong to the same AS, or must be the ASBR directly connected In example 1 above, a per-AS path computation is performed,
to the next hops AS. In this later case, the ASBR reachability is respectively on R0 for AS1, ASBR4 for AS2, and ASBR9 for AS3. Note
that when an LSR has to perform an ERO expansion, the next hop either
must belong to the same AS or must be the ASBR directly connected to
the next hop AS. In this latter case, the ASBR reachability is
announced in the IGP TE LSA/LSP originated by its neighboring ASBR. announced in the IGP TE LSA/LSP originated by its neighboring ASBR.
In the example 1 above, the TE LSP path is defined as: ASBR4(loose)- In example 1 above, the TE LSP path is defined as: ASBR4(loose)-
ASBR9(loose)-R6(loose). This implies that R0 must compute the path ASBR9(loose)-R6(loose). This implies that R0 must compute the path
from R0 to ASBR4, hence the need for R0 to get the TE reservation from R0 to ASBR4, hence the need for R0 to get the TE reservation
state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In state related to the ASBR1-ASBR4 link (flooded in AS1 by ASBR1). In
addition, ASBR1 must also announce the IP address of ASBR4 specified addition, ASBR1 must also announce the IP address of ASBR4 specified
in the T1's path configuration. in T1's path configuration.
Once it has computed the path up to the next hop ASBR, ASBR1 sends Once it has computed the path up to the next-hop ASBR, ASBR1 sends
the Path message for the inter-area TE LSP to ASBR4 (supposing that the Path message for the inter-area TE LSP to ASBR4 (supposing that
ASBR4 is the selected next hop ASBR). ASBR4 then repeats the exact ASBR4 is the selected next-hop ASBR). ASBR4 then repeats the exact
same procedures. If ASBR4 cannot find a path obeying the set of same procedures. If ASBR4 cannot find a path obeying the set of
constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr
message to ASBR1. Then ASBR1 can in turn either select another ASBR message to ASBR1. Then ASBR1 can in turn either select another ASBR
(ASBR5 in the example above) if crankback is allowed for this (ASBR5 in the example above) if crankback is allowed for this inter-
inter-AS TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is AS TE LSP (see [RFC4920]), or if crankback is not allowed for that
not allowed for that inter-AS TE LSP or if ASBR1 has been configured inter-AS TE LSP or if ASBR1 has been configured not to perform
not to perform crankback, ABR1 stops the signaling process and crankback, ABR1 stops the signaling process and forwards a PathErr up
forwards a PathErr up to the Head-end LSR (R0) without trying to to the Head-end LSR (R0) without trying to select another egress LSR.
select another egress LSR. In this case, the Head-end LSR can in In this case, the Head-end LSR can in turn select another sequence of
turn select another sequence of loose hops, if configured. loose hops, if configured. Alternatively, the Head-end LSR may
Alternatively, the Head-end LSR may decide to retry the same path; decide to retry the same path; this can be useful in case of setup
this can be useful in case of set up failure due an outdated IGP TE failure due to an outdated IGP TE database in some downstream AS. An
database in some downstream AS. An alternative could also be for the alternative could also be for the Head-end LSR to retry the same
Head-end LSR to retry to same sequence of loose hops after having sequence of loose hops after having relaxed some constraint(s).
relaxed some 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 The path computation procedures are very similar to the inter-area
LSP setup case described earlier. In this case, the H-LSPs or S-LSPs LSP setup case described earlier. In this case, the H-LSPs or S-LSPs
are originated by the ASBRs at the entry to the AS. are originated by the ASBRs at the entry to the AS.
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 computation approach may not be possible in some topologies (due to
the well-known 'trapping' problem). the well-known "trapping" problem).
For example, consider the following simple topology: For example, consider the following simple topology:
+-------+ +-------+
/ \ / \
A----B-----C------D A----B-----C------D
\ / \ /
+---------+ +---------+
Figure 4 - Example of "trapping" problem Figure 4 - Example of the "trapping" problem
In the simple topology depicted in figure 3, with a serialized In the simple topology depicted in Figure 4, with a serialized
approach using the per-domain path computation technique specified in approach using the per-domain path computation technique specified in
this document, a first TE LSP may be computed following the path this document, a first TE LSP may be computed following the path
A-B-C-D, in which case no diverse path could be found although two A-B-C-D, in which case no diverse path could be found although two
diverse paths actually exist: A-C-D and A-B-D. The aim of that diverse paths actually exist: A-C-D and A-B-D. The aim of that
simple example that can easily be extended to the inter-domain case simple example that can easily be extended to the inter-domain case
is to illustrate the potential issue of not being able to find is to illustrate the potential issue of not being able to find
diverse paths using the per-domain path computation approach when diverse paths using the per-domain path computation approach when
diverse paths exist. diverse paths exist.
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 not meet the set of If the per-domain path computation technique does not 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 requirements for a set of diversely routed TE LSPs), other techniques
techniques such as PCE-based path computation techniques may be used such as PCE-based path computation techniques may be used (see
(see [RFC4655]). [RFC4655]).
6. Reoptimization of an inter-domain TE LSP 6. Reoptimization of an Inter-Domain TE LSP
As stated in [RFC4216]and in [RFC4105], the ability to reoptimize an As stated in [RFC4216] and [RFC4105], the ability to reoptimize an
already established inter-domain TE LSP constitutes a requirement. already established inter-domain TE LSP constitutes a requirement.
The reoptimization process significantly differs based upon the The reoptimization process significantly differs based upon the
nature of the TE LSP and the mechanism in use for the TE LSP nature of the TE LSP and the mechanism in use for the TE LSP
computation. 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 better route might
might appear within any traversed domain. Then in this case, it is 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 a better path. This is a known as a TE LSP
LSP reoptimization procedure. reoptimization procedure.
[RFC4736] proposes a mechanism that allows the Head-end LSR to be [RFC4736] proposes a mechanism that allows the Head-end LSR to be
notified of the existence of a more optimal path in a downstream notified of the existence of a more optimal path in a downstream
domain. The Head-end LSR may then decide to gracefully reroute the domain. The Head-end LSR may then decide to gracefully reroute the
TE LSP using the so-called Make-Before-Break procedure. In case of a TE LSP using the Make-Before-Break procedure. In case of a
contiguous LSP, the reoptimization process is strictly controlled by contiguous LSP, the reoptimization process is strictly controlled by
the Head-end LSR which triggers the make-before-break procedure as the Head-end LSR that triggers the Make-Before-Break procedure as
defined in [RFC3209], regardless of the location of the more optimal defined in [RFC3209], regardless of the location of the better path.
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. 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 The main reason is that the inter-domain TE LSP is a different LSP
(and therefore different RSVP session) from the intra-domain S-LSP or (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 H-LSP in an area or an AS. Therefore, reoptimization in a domain is
done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since done by locally reoptimizing the intra-domain H-LSP or S-LSP. Since
the inter-domain TE LSPs are transported using S-LSP or H-LSP across the inter-domain TE LSPs are transported using S-LSP or H-LSP across
each domain, optimality of the inter-domain TE LSP in a domain is each domain, optimality of the inter-domain TE LSP in a domain is
dependent on the optimality of the corresponding S-LSP or H-LSPs. dependent on the optimality of the corresponding S-LSP or H-LSP. If
If, after an inter-domain LSP is setup, a more optimal path is after an inter-domain LSP is set up a more optimal path is available
available within an domain, the corresponding S-LSP or H-LSP will be within a domain, the corresponding S-LSP or H-LSP will be reoptimized
reoptimized using "Make-Before-Break" techniques discussed in using Make-Before-Break techniques discussed in [RFC3209].
[RFC3209]. Reoptimization of the H-LSP or S-LSP automatically Reoptimization of the H-LSP or S-LSP automatically reoptimizes the
reoptimizes the inter-domain TE LSPs that the H-LSP or the S-LSP inter-domain TE LSPs that the H-LSP or S-LSP transports.
transports. Reoptimization parameters like frequency of Reoptimization parameters like frequency of reoptimization, criteria
reoptimization, criteria for reoptimization like metric or bandwidth for reoptimization like metric or bandwidth availability, etc. can
availability, etc can vary from one domain to another and can be vary from one domain to another and can be configured as required,
configured as required, per intra-domain TE S-LSP or H-LSP if it is per intra-domain TE S-LSP or H-LSP if it is pre-configured or based
preconfigured or based on some global policy within the domain. on some global policy within the domain.
Hence, in this scheme, since each domain takes care of reoptimizing Hence, in this scheme, since each domain takes care of reoptimizing
its own S-LSPs or H-LSPs, and therefore the corresponding inter- its own S-LSPs or H-LSPs, and therefore the corresponding
domain TE LSPs, the Make-Before-Break can happen locally and is not inter-domain TE LSPs, the Make-Before-Break can happen locally and is
triggered by the Head-end LSR for the inter-domain LSP. So, no not triggered by the Head-end LSR for the inter-domain LSP. So, no
additional RSVP signaling is required for LSP reoptimization and additional RSVP signaling is required for LSP reoptimization, and
reoptimization is transparent to the Head-end LSR of the inter-domain reoptimization is transparent to the Head-end LSR of the inter-domain
TE LSP. TE LSP.
If, however, an operator desires to manually trigger reoptimization If, however, an operator desires to manually trigger reoptimization
at the Head-end LSR for the inter-domain TE LSP, then this solution at the Head-end LSR for the inter-domain TE LSP, then this solution
does not prevent that. A manual trigger for reoptimization at the does not prevent that. A manual trigger for reoptimization at the
Head-end LSR SHOULD force a reoptimization thereby signaling a "new" Head-end LSR SHOULD force a reoptimization thereby signaling a "new"
path for the same LSP (along the more optimal path) making use of the path for the same LSP (along the more optimal path) making use of the
Make-Before-Break procedure. In response to this new setup request, Make-Before-Break procedure. In response to this new setup request,
the boundary LSR may either initiate new S-LSP setup, in case the the boundary LSR either may initiate new S-LSP setup, in case the
inter-domain TE LSP is being stitched to the intra-domain S-LSP or it inter-domain TE LSP is being stitched to the intra-domain S-LSP, or
may select an existing or new H-LSP in case of nesting. When the LSP it may select an existing or new H-LSP, in case of nesting. When the
setup along the current path is complete, the Head-end LSR should LSP setup along the current path is complete, the Head-end LSR should
switchover the traffic onto that path and the old path is eventually switch over the traffic onto that path, and the old path is
torn down. Note that the Head-end LSR does not know a priori whether eventually torn down. Note that the Head-end LSR does not know a
a more optimal path exists. Such a manual trigger from the Head-end priori whether a more optimal path exists. Such a manual trigger
LSR of the inter-domain TE LSP is, however, not considered to be a from the Head-end LSR of the inter-domain TE LSP is, however, not
frequent occurrence. considered to be a frequent occurrence.
Procedures described in [RFC4736] MUST be used if the operator does Procedures described in [RFC4736] MUST be used if the operator does
not desire local reoptimization of certain inter-domain LSPs. In not desire local reoptimization of certain inter-domain LSPs. In
this case, any reoptimization event within the domain MUST be this case, any reoptimization event within the domain MUST be
reported to the Head-end node. This SHOULD be a configurable policy. reported to the Head-end node. This SHOULD be a configurable policy.
6.3. Path characteristics after reoptimization 6.3. Path Characteristics after Reoptimization
Note that in the case of loose hop reoptimization of contiguous Note that in the case of loose hop reoptimization of contiguous
inter-domain TE LSP or local reoptimization of stitched/nested S-LSP inter-domain TE LSP or local reoptimization of stitched/nested S-LSP
where boundary LSRs are specified as loose hops, the TE LSP may where boundary LSRs are specified as loose hops, the TE LSP may
follow a preferable path within one or more domain(s) but would still follow a preferable path within one or more domain(s) but would still
traverse the same set of boundary LSRs. In contrast, in the case of traverse the same set of boundary LSRs. In contrast, in the case of
PCE-based path computation techniques, because end to end optimal PCE-based path computation techniques, because the end-to-end optimal
path is computed, the reoptimization process may lead to following a path is computed, the reoptimization process may lead to following a
completely different inter-domain path (including a different set of completely different inter-domain path (including a different set of
boundary LSRs). boundary LSRs).
7. IANA Considerations 7. Security Considerations
This document makes no request for any IANA action.
8. Security Considerations
Signaling of inter-domain TE LSPs raises security issues (discussed Signaling of inter-domain TE LSPs raises security issues (discussed
in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]). in section 7 of [RFC5151]).
[RFC4726] provides an overview of the requirements for security in an [RFC4726] provides an overview of the requirements for security in an
MPLS-TE or GMPLS multi-domain environment. In particular, when MPLS-TE or GMPLS multi-domain environment. In particular, when
signaling an inter-domain RSVP-TE LSP, an operator may make use of signaling an inter-domain RSVP-TE LSP, an operator may make use of
the security features already defined for RSVP-TE ([RFC3209]). This the security features already defined for RSVP-TE ([RFC3209]). This
may require some coordination between the domains to share the keys may require some coordination between the domains to share the keys
(see [RFC2747] and [RFC3097]), and care is required to ensure that (see [RFC2747] and [RFC3097]), and care is required to ensure that
the keys are changed sufficiently frequently. Note that this may the keys are changed sufficiently frequently. Note that this may
involve additional synchronization, should the domain border nodes be involve additional synchronization, should the domain border nodes be
protected with Fast Rerotue ([RFC4090], since the Merge Point (MP) protected with Fast Reroute ([RFC4090], since the Merge Point (MP)
and Point of Local Repair (PLR) should also share the key. For an and Point of Local Repair (PLR) should also share the key. For an
inter-domain TE LSP, especially when it traverses different inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms SHOULD be administrative or trust domains, the following mechanisms SHOULD be
provided to an operator (also see [RFC4216]): provided to an operator (also see [RFC4216]):
1) A way to enforce policies and filters at the domain borders to 1) A way to enforce policies and filters at the domain borders to
process the incoming inter-domain TE LSP setup requests (Path process the incoming inter-domain TE LSP setup requests (Path
messages) based on certain agreed trust and service levels/contracts messages) based on certain agreed trust and service
between domains. Various LSP attributes such as bandwidth, priority, levels/contracts between domains. Various LSP attributes such as
etc. could be part of such a contract. 2) A way for the operator to bandwidth, priority, etc. could be part of such a contract.
rate-limit LSP setup requests or error notifications from a
particular domain. 3) A mechanism to allow policy-based outbound RSVP 2) A way for the operator to rate-limit LSP setup requests or error
message processing at the domain border node, which may involve notifications from a particular domain.
filtering or modification of certain addresses in RSVP objects and
messages. 3) A mechanism to allow policy-based outbound RSVP message processing
at the domain border node, which may involve filtering or
modification of certain addresses in RSVP objects and messages.
This document relates to inter-domain path computation. It must be This document relates to inter-domain path computation. It must be
noted that the process for establishing paths described in this noted that the process for establishing paths described in this
document does not increase the information exchanged between ASes and document does not increase the information exchanged between ASs and
preserves topology confidentiality, in compliance with [RFC4105] and preserves topology confidentiality, in compliance with [RFC4105] and
[RFC4216]. That being said, the signaling of inter-domain TE LSP [RFC4216]. That being said, the signaling of inter-domain TE LSP
according to the procedure defined in this document requires path according to the procedure defined in this document requires path
computation on boundary nodes that may be exposed to various attacks. computation on boundary nodes that may be exposed to various attacks.
Thus it is RECOMMENDED to support policy decisions to reject the ERO Thus, it is RECOMMENDED to support policy decisions to reject the ERO
expansion of an inter-domain TE LSP if not allowed. expansion of an inter-domain TE LSP if not allowed.
9. Acknowledgements 8. 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, Dimitri Papadimitriou and Faisal Aslam. Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou, and Faisal Aslam.
10. References 9. References
10.1. Normative References 9.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
10.2. Informative References 9.2. Informative References
[I-D.ietf-ccamp-crankback] [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
Farrel, A., "Crankback Signaling Extensions for MPLS and N., and G. Ash, "Crankback Signaling Extensions for MPLS
GMPLS RSVP-TE", draft-ietf-ccamp-crankback-06 (work in and GMPLS RSVP-TE", RFC 4920, July 2007.
progress), January 2007.
[I-D.ietf-ccamp-inter-domain-rsvp-te] [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
Ayyangar, A., "Inter domain Multiprotocol Label Switching Domain MPLS and GMPLS Traffic Engineering -- Resource
(MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - Reservation Protocol-Traffic Engineering (RSVP-TE)
RSVP-TE extensions", Extensions", RFC 5151, February 2008.
draft-ietf-ccamp-inter-domain-rsvp-te-07 (work in
progress), September 2007.
[I-D.ietf-ccamp-lsp-stitching] [RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
Ayyangar, A., "Label Switched Path Stitching with "Label Switched Path Stitching with Generalized
Generalized Multiprotocol Label Switching Traffic Multiprotocol Label Switching Traffic Engineering (GMPLS
Engineering (GMPLS TE)", draft-ietf-ccamp-lsp-stitching-06 TE)", RFC 5150, February 2008.
(work in progress), April 2007.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over
RFC 2702, September 1999. MPLS", RFC 2702, September 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Authentication", RFC 2747, January 2000. Cryptographic Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097, Authentication -- Updated Message Type Value", RFC 3097,
April 2001. April 2001.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic
(TE) Extensions to OSPF Version 2", RFC 3630, Engineering (TE) Extensions to OSPF Version 2", RFC 3630,
September 2003. September 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
May 2005. May 2005.
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for [RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
of Generalized Multi-Protocol Label Switching (GMPLS)", in Support of Generalized Multi-Protocol Label Switching
RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to [RFC4205] Kompella, K., Ed., and Y. Rekhter, Ed., "Intermediate
Intermediate System (IS-IS) Extensions in Support of System to Intermediate System (IS-IS) Extensions in
Generalized Multi-Protocol Label Switching (GMPLS)", Support of Generalized Multi-Protocol Label Switching
RFC 4205, October 2005. (GMPLS)", RFC 4205, October 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
(AS) Traffic Engineering (TE) Requirements", RFC 4216, Autonomous System (AS) Traffic Engineering (TE)
November 2005. Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Element (PCE)-Based Architecture", RFC 4655, August 2006. Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A Framework
Inter-Domain Multiprotocol Label Switching Traffic for Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
[RFC4736] Vasseur, JP., Ikejiri, Y., and R. Zhang, "Reoptimization [RFC4736] Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang,
of Multiprotocol Label Switching (MPLS) Traffic "Reoptimization of Multiprotocol Label Switching (MPLS)
Engineering (TE) Loosely Routed Label Switched Path Traffic Engineering (TE) Loosely Routed Label Switched
(LSP)", RFC 4736, November 2006. Path (LSP)", RFC 4736, November 2006.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc.
1414 Massachusetts Avenue 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 Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: arthi@juniper.net EMail: arthi@juniper.net
Raymond Zhang Raymond Zhang
BT BT
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond.zhang@bt.com EMail: raymond.zhang@bt.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
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, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 23, line 44 skipping to change at line 962
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 147 change blocks. 
483 lines changed or deleted 461 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/