draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt   draft-ietf-ccamp-inter-domain-pd-path-comp-04.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Intended status: Standards Track A. Ayyangar, Ed. Intended status: Standards Track A. Ayyangar, Ed.
Expires: March 2, 2007 Juniper Networks Expires: August 10, 2007 Nuova Systems
R. Zhang R. Zhang
BT Infonet BT Infonet
August 29, 2006 February 6, 2007
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-03.txt draft-ietf-ccamp-inter-domain-pd-path-comp-04
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 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 38
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 time. It is inappropriate to use Internet-Drafts as reference
material 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.
This Internet-Draft will expire on March 2, 2007. This Internet-Draft will expire on August 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 IGP areas and Autonomous
Systems. Per-domain computation applies where the full path of an Systems. Per-domain computation applies where the full path of an
skipping to change at page 3, line 12 skipping to change at page 3, line 12
"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 Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5
3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5 3.1. Common assumptions . . . . . . . . . . . . . . . . . . . . 5
3.2. Example of topology for the inter-area TE case . . . . . . 7 3.2. Example of topology for the inter-area TE case . . . . . . 7
3.3. Example of topology for the inter-AS TE case . . . . . . . 7 3.3. Example of topology for the inter-AS TE case . . . . . . . 8
4. Per-domain path computation procedures . . . . . . . . . . . . 9 4. Per-domain path computation procedures . . . . . . . . . . . . 9
4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12 4.1. Example with an inter-area TE LSP . . . . . . . . . . . . 12
4.1.1. Case 1: T0 is a contiguous 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.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. Example with an inter-AS TE LSP . . . . . . . . . . . . . 14
4.2.1. Case 1: T1 is a contiguous TE LSP . . . . . . . . . . 14 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 4.2.2. Case 2: T1 is a stitched or nested TE LSP . . . . . . 15
5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15 5. Path optimality/diversity . . . . . . . . . . . . . . . . . . 15
6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15 6. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 15
6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15 6.1. Contiguous TE LSPs . . . . . . . . . . . . . . . . . . . . 15
6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16 6.2. Stitched or nested (non-contiguous) TE LSPs . . . . . . . 16
6.3. Path characteristics after reoptimization . . . . . . . . 17 6.3. Path characteristics after reoptimization . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 21
1. Terminology 1. Terminology
Terminology used in this document Terminology used in this document
ABR Routers: routers used to connect two IGP areas (areas in OSPF or AS: Autonomous System.
levels in IS-IS).
ASBR Routers: routers used to connect together ASes of a different or ABR: routers used to connect two IGP areas (areas in OSPF or levels
the same Service Provider via one or more Inter-AS links. in IS-IS).
ASBR: 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 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. 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.
skipping to change at page 4, line 35 skipping to change at page 4, line 37
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
[I-D.ietf-ccamp-inter-domain-framework] and will not be repeated [RFC4726] and will not be repeated here.
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 [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
[I-D.ietf-ccamp-inter-domain-framework]. [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 [I-D.ietf-ccamp-inter-domain-rsvp-te] and
[I-D.ietf-ccamp-lsp-stitching]. [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.
skipping to change at page 5, line 30 skipping to change at page 5, line 31
therefore, not meet all requirements for other deployment scenarios. 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 and 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 paths 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 [I-D.ietf-pce-architecture]). Other across different domains (see [RFC4655]). Other offline mechanisms
offline mechanisms for path computation are not precluded either. for path computation are not precluded either. Note also that a
Note also that a Service Provider may elect to use different inter- Service Provider may elect to use different inter-domain path
domain path computation techniques for different TE LSP types. computation techniques for different TE LSP types.
3. General assumptions 3. General 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 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). A domain may itself comprise multiple other domains. E.g.
An AS may itself be composed of several other sub-AS(es) (BGP An AS may itself be composed of several other sub-AS(es) (BGP
confederations) or areas/levels. In this case, the path computation confederations) or areas/levels. In this case, the path computation
technique described for inter-area and inter-AS MPLS Traffic technique described for inter-area and inter-AS MPLS Traffic
Engineering just recursively applies. Engineering just recursively applies.
- The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209]). - The inter-domain TE LSPs are signaled using RSVP-TE ([RFC3209] and
[RFC3473]).
- The path (ERO) for an inter-domain TE LSP may be signaled as a set - 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: 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 * The complete strict path in the source domain followed by boundary
LSRs (or domain identifiers, e.g. AS numbers) 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 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, BGP, policy routing information
next-hop boundary node (domain exit point, such as ABR/ASBR) along yielding the next-hop boundary node (domain exit point, such as ABR/
the path as the TE LSP is being signaled, along with potential ASBR) along the path as the TE LSP is being signaled, along with
crankback mechanisms. Alternatively the domain exit points may be potential crankback mechanisms. Alternatively the domain exit points
statically configured on the Head-end LSR in which case next-hop may be statically configured on the Head-end LSR in which case next-
boundary node auto-discovery would not be required. 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 if
the path is not signaled by the Head-end LSR as a set of strict hops the path is not signaled by the Head-end LSR as a set of strict hops
or if the strict hop is an abstract node (e.g. an AS). In any case, or if the strict hop is an abstract node (e.g. an AS). In any case,
no topology or resource information needs to be distributed between no topology or resource information needs to be distributed between
domains (as mandated per [RFC4105] and [RFC4216]), which is critical domains (as mandated per [RFC4105] and [RFC4216]), which is critical
to preserve IGP/BGP scalability and confidentiality in the case of TE to preserve IGP/BGP scalability and confidentiality in the 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-LSP) or for a contiguous TE LSP within the domain may be pre- Stitched LSPs (S-LSP) or for a contiguous TE LSP within the domain
configured or computed dynamically based on the arriving inter-domain may be pre-configured or computed dynamically based on the arriving
LSP setup request (depending on the requirements of the transit inter-domain LSP setup request (depending on the requirements of the
domain). Note that this capability is explicitly specified as a transit domain). Note that this capability is explicitly specified
requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP are as a requirement in [RFC4216]. When the paths for the H-LSPs/S-LSP
pre-configured, the constraints as well as other parameters like are pre-configured, the constraints as well as other parameters like
local protection scheme for the intra-domain H-LSP/S-LSP are also local protection scheme for the intra-domain H-LSP/S-LSP are also
pre-configured. 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, at
the domain boundary LSRs, there will exist some sort of local mapping the domain boundary LSRs, there will exist some sort of local mapping
based on policy agreement in order to translate such constraints based on policy agreement in order to translate such constraints
across domain boundaries. It is expected that such an assumption across domain boundaries. It is expected that such an assumption
skipping to change at page 8, line 39 skipping to change at page 8, 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 ASs are TE enabled, other words, the ASes 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 technique described in this document applies to the case of a single
AS made of multiple IGP areas, multiples ASs made of a single IGP AS made of multiple IGP areas, multiples ASs made of a single IGP
areas or any combination of the above. For the sake of simplicity, areas or any combination of the above. For the sake of simplicity,
each routing domain will be considered as single area in this each routing domain will be considered as single area in this
document. The case of an Inter-AS TE LSP spanning multiple ASs where document. The case of an Inter-AS TE LSP spanning multiple ASs where
some of those ASs are themselves made of multiple IGP areas can be some of those ASs are themselves made of multiple IGP areas can be
easily derived from the examples above: the per-domain path easily derived from the examples above: the per-domain path
computation technique described in this document is applied computation technique described in this document is applied
skipping to change at page 9, line 14 skipping to change at page 9, line 20
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 inter-
domain TE 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. 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 area, and exert a strict control on dynamic path computation in some domain, and exert a strict control
the path in other areas (defining strict hops). on the path in other domains (defining strict hops).
When an LSR (e.g. 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]. In procedures as described in [I-D.ietf-ccamp-inter-domain-rsvp-te]. In
addition, the following procedures describe the path computation 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 boundary LSR is not present in the TED. 1) If the next hop 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 o 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 o If the domain is PSC (Packet Switch Capable) and uses in-band
control channel control channel
If the two conditions above are satisfied then the boundary LSR If the two conditions above are satisfied then the boundary LSR
SHOULD check if the next-hop has IP reachability (via IGP or BGP). 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 If the next-hop is not reachable, then a signaling failure occurs and
the LSR SHOULD send back a PErr message upstream with error code=24 the LSR SHOULD send back an RSVP PathErr message upstream with error
("Routing Problem") and error subcode as described in section 4.3.4 code=24 ("Routing Problem") and error subcode as described in section
of [RFC3209]. If the next-hop is reachable, then it SHOULD find a 4.3.4 of [RFC3209]. If the next-hop is reachable, then it SHOULD
domain boundary LSR (domain boundary point) to get to the next-hop. find a domain boundary LSR (domain boundary point) to get to the
The determination of domain boundary point based on routing next-hop. The determination of domain boundary point based on
information is what we term as "auto-discovery" in this document. In routing information is what we term as "auto-discovery" in this
the absence of such an auto-discovery mechanism, a) the ABR in the document. In the absence of such an auto-discovery mechanism, a) the
case of inter-area TE or the ASBR in the next-hop AS in the case of ABR in the case of inter-area TE or the ASBR in the next-hop AS in
inter-AS TE should be the signaled loose next-hop in the ERO and the case of inter-AS TE should be the signaled loose next-hop in the
hence should be accessible via the TED or b) there needs to be an ERO and hence should be accessible via the TED or b) there needs to
alternate scheme that provides the domain exit points. Otherwise the be an alternate scheme that provides the domain exit points.
path computation for the inter-domain TE LSP will fail. 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 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 present
in the TED in the TED
a) Case of a contiguous TE LSP. The boundary LSR that processes the o Case of a contiguous TE LSP. The boundary LSR that processes the
ERO SHOULD perform an ERO expansion (unless not allowed by policy) ERO SHOULD perform an ERO expansion (unless not allowed by policy)
after having computed the path to the next loose hop (ABR/ASBR) that after having computed the path to the next loose hop (ABR/ASBR)
obeys the set of required constraints. If no path satisfying the set that obeys the set of required constraints. If no path satisfying
of constraints can be found, then this SHOULD be treated as a path the set of constraints can be found, then this SHOULD be treated
computation and signaling failure and a PErr message SHOULD be sent as a path computation and signaling failure and an RSVP PathErr
for the inter-domain TE LSP based on section 4.3.4 of [RFC3209]. message SHOULD be sent for the inter-domain TE LSP based on
section 4.3.4 of [RFC3209].
b) Case of stitched or nested LSP o Case of stitched or nested LSP
i) If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP o
setup (the LSR has local policy for nesting or stitching), and if
there is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR
that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP to the
next-hop boundary LSR. If pre-configured H-LSP(s) or S-LSP(s)
already exist, then it will try to select from among those intra-
domain LSPs. Depending on local policy, it MAY signal a new H-LSP/
S-LSP if this selection fails. If the H-LSP/S-LSP is successfully
signaled or selected, it propagates the inter-domain Path message to
the next-hop following the procedures described in
[I-D.ietf-ccamp-inter-domain-rsvp-te]. If, for some reason the
dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then
this SHOULD be treated as a path computation and signaling failure
and a PErr message SHOULD be sent upstream for the inter-domain LSP.
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 PErr SHOULD be sent
upstream for the inter-domain TE LSP. In both these cases procedures
described in section 4.3.4 of [RFC3209] SHOULD be followed to handle
the failure.
ii) If, however, the boundary LSR is not a candidate for intra-domain * If the boundary LSR is a candidate LSR for intra-area H-LSP/
H-LSP/S-LSP (the LSR does not have local policy for nesting or S-LSP setup (the LSR has local policy for nesting or
stitching), then it SHOULD apply the same procedure as for the stitching), the TE LSP is a candidate for hierarchy/nesting
contiguous case. (the "Contiguous LSP" bit defined in
[I-D.ietf-ccamp-inter-domain-rsvp-te] is not set) and if there
is no H-LSP/S-LSP from this LSR to the next-hop boundary LSR
that satisfies the constraints, it SHOULD signal a H-LSP/S-LSP
to the next-hop boundary LSR. If pre-configured H-LSP(s) or
S-LSP(s) already exist, then it will try to select from among
those intra-domain LSPs. Depending on local policy, it MAY
signal a new H-LSP/S-LSP if this selection fails. If the
H-LSP/S-LSP is successfully signaled or selected, it propagates
the inter-domain Path message to the next-hop following the
procedures described in [I-D.ietf-ccamp-inter-domain-rsvp-te].
If, for some reason the dynamic H-LSP/S-LSP setup to the next-
hop boundary LSR fails, then this SHOULD be treated as a path
computation and signaling failure and an RSVP PathErr message
SHOULD be sent upstream for the inter-domain LSP. 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 an RSVP PathErr
SHOULD be sent upstream for the inter-domain TE LSP. In both
these cases procedures described in section 4.3.4 of [RFC3209]
SHOULD be followed to handle the failure.
* If, however, the boundary LSR is not a candidate for intra-
domain H-LSP/S-LSP (the LSR does not have local policy for
nesting or stitching) or the TE LSP is a not candidate for
hierarchy/nesting (the "Contiguous LSP" bit defined in
[I-D.ietf-ccamp-inter-domain-rsvp-te] is set), then it SHOULD
apply the same procedure as for the contiguous case.
Note that in both cases, path computation and signaling process may Note that in both cases, path computation and signaling 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
ASs. In such a case, upon receiving the ERO whose next hop is an AS, ASes. In such a case, upon receiving the ERO whose next hop is an
the boundary LSR has to determine the next-hop boundary LSR which may AS, the boundary LSR has to determine the next-hop boundary LSR which
be determined based on the "auto-discovery" process mentioned above. may be determined based on the "auto-discovery" process mentioned
If multiple ASBRs candidates exist the boundary LSR may apply some above. If multiple ASBRs candidates exist the boundary LSR may apply
policies based on peering contracts that may have been pre- some policies based on peering contracts that may have been pre-
negotiated. Once the next-hop boundary LSR has been determined a negotiated. Once the next-hop boundary LSR has been determined a
similar procedure 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
is running at the AS boundaries. An implementation supporting
inter-AS MPLS TE MUST allow the set up of inter-AS TE LSP over the
region interconnecting multiple ASBRs. In other words, an ASBR
compliant with this document MUST support the set up of TE LSP over
inter-ASBR links and MUST be able to perform all the usual operations
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 inter-ASBR links). This of course implies for the inter-ASBR links
to be TE-enabled although no IGP is running on those links. This to be TE-enabled although no IGP is running on those links. This
allows an LSR (could be entry ASBR) in the previous AS to make a more allows an LSR (could be entry ASBR) in the previous AS to make a more
appropriate route selection up to the entry ASBR in the immediately appropriate route selection up to the entry ASBR in the immediately
downstream AS taking into account the constraints associated with the downstream AS taking into account the constraints associated with the
inter-ASBR links. This reduces the risk of call set up failure due inter-ASBR links. This reduces the risk of call set up failure due
to inter-ASBR links not satisfying the inter-AS TE LSP set of to inter-ASBR links not satisfying the inter-AS TE LSP set of
constraints. Note that the TE information is only related to the constraints. Note that the TE information is only related to the
inter-ASBR links: the TE LSA/LSP flooded by the ASBR includes not 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-ASBR only the TE-enabled links contained in the AS but also the inter-ASBR
links. links.
Note that no summarized TE information is leaked between ASs which is Note that no summarized TE information is leaked between ASes which
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 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 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 that the ASBR belongs to.
skipping to change at page 12, line 39 skipping to change at page 12, line 48
- Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)- - Example 2 (mix of strict and loose hops): R0-X1-ABR1-ABR3(loose)-
X2-X3-R1 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 set
up failure or when an RSVP PErr is received indicating the TE LSP has up failure or when an RSVP PathErr is received indicating the TE LSP
suffered a failure, an implementation might support the possibility has suffered a failure, an implementation might support the
to retry a particular path option configurable amount of times possibility to retry a particular path option configurable amount of
(optionally with dynamic intervals between each trial) before trying times (optionally with dynamic intervals between each trial) before
a lower priority path option. 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 PErr 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
[I-D.ietf-ccamp-crankback]). If crankback is not allowed for that [I-D.ietf-ccamp-crankback]). If crankback is not allowed for that
inter-area TE LSP or if ABR1 has been configured not to perform inter-area TE LSP or if ABR1 has been configured not to perform
crankback, then ABR1 MUST stop the signaling process and MUST forward crankback, then ABR1 MUST stop the signaling process and MUST forward
a PErr up to the Head-end LSR (R0) without trying to select another a PathErr up to the Head-end LSR (R0) without trying to select
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 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 area 0 along the LSP path (say ABR3), either directly from the ERO
(if for example the next hop ABR is specified as a loose hop in the (if for example the next hop ABR is specified as a loose hop in the
skipping to change at page 13, line 35 skipping to change at page 13, line 44
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
[I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message [I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message
for inter-area TE LSP to ABR3. Note that irrespective of whether for inter-area TE LSP to ABR3. Note that irrespective of whether
ABR1 does nesting or stitching, the Path message for the inter-area ABR1 does nesting or stitching, the Path message for the inter-area
TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same TE LSP is always forwarded to ABR3. ABR3 then repeats the 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 PErr message to constraints for the inter-area TE LSP, ABR3 sends a PathErr message
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 [I-D.ietf-ccamp-crankback]). If crankback is not
allowed for that inter-area TE LSP or if ABR1 has been configured not allowed for that inter-area TE LSP or if ABR1 has been configured not
to perform crankback, then ABR1 forwards the PErr up to the inter- to perform crankback, then ABR1 forwards the PathErr up to the inter-
area Head-end LSR (R0) without trying to select another egress LSR. 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
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-ASBRs
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
skipping to change at page 14, line 32 skipping to change at page 14, line 39
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 the 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 PErr message constraints for the inter-AS TE LSP, then ASBR4 sends a PathErr
to ASBR1. Then ASBR1 can in turn either select another ASBR (ASBR5 message to ASBR1. Then ASBR1 can in turn either select another ASBR
in the example above) if crankback is allowed for this inter-AS TE (ASBR5 in the example above) if crankback is allowed for this
LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not allowed inter-AS TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is
for that inter-AS TE LSP or if ASBR1 has been configured not to not allowed for that inter-AS TE LSP or if ASBR1 has been configured
perform crankback, ABR1 stops the signaling process and forwards a not to perform crankback, ABR1 stops the signaling process and
PErr up to the Head-end LSR (R0) without trying to select another forwards a PathErr up to the Head-end LSR (R0) without trying to
egress LSR. In this case, the Head-end LSR can in turn select select another egress LSR. In this case, the Head-end LSR can in
another sequence of loose hops, if configured. Alternatively, the turn select another sequence of loose hops, if configured.
Head-end LSR may decide to retry the same path; this can be useful in Alternatively, the Head-end LSR may decide to retry the same path;
case of set up failure due an outdated IGP TE database in some this can be useful in case of set up failure due an outdated IGP TE
downstream AS. An alternative could also be for the Head-end LSR to database in some downstream AS. An alternative could also be for the
retry to same sequence of loose hops after having relaxed some Head-end LSR to retry to same sequence of loose hops after having
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).
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 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 such as PCE-based path computation techniques may be used techniques such as PCE-based path computation techniques may be used
(see [I-D.ietf-pce-architecture]). (see [RFC4655]).
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 As stated in [RFC4216]and in [RFC4105], the ability to reoptimize an
constitutes a requirement. The reoptimization process significantly already established inter-domain TE LSP constitutes a requirement.
differs based upon the nature of the TE LSP and the mechanism in use The reoptimization process significantly differs based upon the
for the TE LSP computation. nature of the TE LSP and the mechanism in use 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
skipping to change at page 16, line 51 skipping to change at page 17, line 10
the boundary LSR may either initiate new S-LSP setup, in case the the boundary LSR may either 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 it
may select an existing or new H-LSP in case of nesting. When the LSP may select an existing or new H-LSP in case of nesting. When the LSP
setup along the current path is complete, the Head-end LSR should setup along the current path is complete, the Head-end LSR should
switchover the traffic onto that path and the old path is eventually switchover the traffic onto that path and the old path is eventually
torn down. Note that the Head-end LSR does not know a priori whether torn down. Note that the Head-end LSR does not know a priori whether
a more optimal path exists. Such a manual trigger from the Head-end a more optimal path exists. Such a manual trigger from the Head-end
LSR of the inter-domain TE LSP is, however, not considered to be a LSR of the inter-domain TE LSP is, however, not considered to be a
frequent occurrence. frequent occurrence.
Note that stitching or nesting rely on local optimization: the
reoptimization process allows to locally reoptimize each TE S-LSP or
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
being set up.
Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be Procedures described in [I-D.ietf-ccamp-loose-path-reopt] MUST be
used if the operator does not desire local reoptimization of certain used if the operator does not desire local reoptimization of certain
inter-domain LSPs. In this case, any reoptimization event within the inter-domain LSPs. In this case, any reoptimization event within the
domain MUST be reported to the Head-end node. This SHOULD be a domain MUST be reported to the Head-end node. This SHOULD be a
configurable policy. 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
skipping to change at page 17, line 32 skipping to change at page 17, line 34
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. IANA Considerations
This document makes no request for any IANA action. This document makes no request for any IANA action.
8. Security Considerations 8. Security Considerations
Signaling of inter-domain TE LSPs raises security issues that have Signaling of inter-domain TE LSPs raises security issues (discussed
been described in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]; in section 7 of [I-D.ietf-ccamp-inter-domain-rsvp-te]).
however the path computation aspects specified in this document do
not raise additional security concerns. [RFC4726] provides an overview of the requirements for security in an
MPLS-TE or GMPLS multi-domain environment. In particular, when
signaling an inter-domain RSVP-TE LSP, an operator may make use of
the security features already defined for RSVP-TE ([RFC3209]). This
may require some coordination between the domains to share the keys
(see [RFC2747] and [RFC3097]), and care is required to ensure that
the keys are changed sufficiently frequently. Note that this may
involve additional synchronization, should the domain border nodes be
protected with FRR, since the MP and PLR should also share the key.
For an inter-domain TE LSP, especially when it traverses different
administrative or trust domains, the following mechanisms SHOULD be
provided to an operator (also see [RFC4216]):
1) A way to enforce policies and filters at the domain borders to
process the incoming inter-domain TE LSP setup requests (Path
messages) based on certain agreed trust and service levels/contracts
between domains. Various LSP attributes such as bandwidth, priority,
etc. could be part of such a contract. 2) A way for the operator to
rate-limit LSP setup requests or error notifications from a
particular domain. 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
noted that the process for establishing paths described in this
document does not increase the information exchanged between ASes and
preserves topology confidentiality, in compliance with [RFC4105] and
[RFC4216]. That being said, the signaling of inter-domain TE LSP
according to the procedure defined in this document requires path
computation on boundary nodes that may be exposed to various attacks.
Thus it is RECOMMENDED to support policy decisions to reject the ERO
expansion of an inter-domain TE LSP if not allowed.
9. Acknowledgements 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, Dimitri Papadimitriou and Faisal Aslam. Farrel, Jean-Louis Le Roux, Dimitri Papadimitriou and Faisal Aslam.
10. References 10. References
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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, September 1999.
[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
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (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.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
skipping to change at page 18, line 38 skipping to change at page 19, line 24
[RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to [RFC4205] Kompella, K. and Y. Rekhter, "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Intermediate System (IS-IS) Extensions in Support of
Generalized Multi-Protocol Label Switching (GMPLS)", Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4205, October 2005. RFC 4205, October 2005.
10.2. Informative References 10.2. Informative References
[I-D.ietf-ccamp-crankback] [I-D.ietf-ccamp-crankback]
Farrel, A., "Crankback Signaling Extensions for MPLS and Farrel, A., "Crankback Signaling Extensions for MPLS and
GMPLS RSVP-TE", draft-ietf-ccamp-crankback-05 (work in GMPLS RSVP-TE", draft-ietf-ccamp-crankback-06 (work in
progress), May 2005. progress), January 2007.
[I-D.ietf-ccamp-inter-domain-framework]
Farrel, A., "A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering",
draft-ietf-ccamp-inter-domain-framework-05 (work in
progress), July 2006.
[I-D.ietf-ccamp-inter-domain-pd-path-comp]
Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-02 (work in
progress), February 2006.
[I-D.ietf-ccamp-inter-domain-rsvp-te] [I-D.ietf-ccamp-inter-domain-rsvp-te]
Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS
Engineering - RSVP-TE extensions", Traffic Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in
progress), March 2006. progress), January 2007.
[I-D.ietf-ccamp-loose-path-reopt] [I-D.ietf-ccamp-loose-path-reopt]
Vasseur, J., "Reoptimization of Multiprotocol Label Vasseur, J., "Reoptimization of Multiprotocol Label
Switching (MPLS) Traffic Engineering (TE) loosely routed Switching (MPLS) Traffic Engineering (TE) loosely routed
Label Switch Path (LSP)", Label Switch Path (LSP)",
draft-ietf-ccamp-loose-path-reopt-02 (work in progress), draft-ietf-ccamp-loose-path-reopt-02 (work in progress),
February 2006. February 2006.
[I-D.ietf-ccamp-lsp-stitching] [I-D.ietf-ccamp-lsp-stitching]
Ayyangar, A. and J. Vasseur, "Label Switched Path Ayyangar, A., "Label Switched Path Stitching with
Stitching with Generalized MPLS Traffic Engineering", Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-03 (work in progress), draft-ietf-ccamp-lsp-stitching-04 (work in progress),
March 2006. December 2006.
[I-D.ietf-pce-architecture] [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
Farrel, A., "A Path Computation Element (PCE) Based McManus, "Requirements for Traffic Engineering Over MPLS",
Architecture", draft-ietf-pce-architecture-05 (work in RFC 2702, September 1999.
progress), April 2006.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for
Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System
(AS) Traffic Engineering (TE) Requirements", RFC 4216, (AS) Traffic Engineering (TE) Requirements", RFC 4216,
November 2005. November 2005.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, 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 Nuova Systems
1194 N.Mathilda Avenue 2600 San Tomas Expressway
Sunnyvale, CA 94089 Santa Clara, CA 95051
USA USA
Email: arthi@juniper.net Email: arthi@nuovasystems.com
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@bt.infonet.com Email: raymond_zhang@bt.infonet.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE 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.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 57 change blocks. 
185 lines changed or deleted 219 lines changed or added

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