draft-ietf-ccamp-inter-domain-pd-path-comp-02.txt   draft-ietf-ccamp-inter-domain-pd-path-comp-03.txt 
Networking Working Group JP. Vasseur, Ed. Networking Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Internet-Draft Cisco Systems, Inc
Proposed Status: Standard A. Ayyangar, Ed. Intended status: Standards Track A. Ayyangar, Ed.
Expires: August 11, 2006 Juniper Networks Expires: March 2, 2007 Juniper Networks
R. Zhang R. Zhang
BT Infonet BT Infonet
February 7, 2006 August 29, 2006
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-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 39 skipping to change at page 1, line 37
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 August 11, 2006. This Internet-Draft will expire on March 2, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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
skipping to change at page 3, line 31 skipping to change at page 3, line 31
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 . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
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 ABR Routers: routers used to connect two IGP areas (areas in OSPF or
levels in IS-IS). levels in IS-IS).
ASBR Routers: routers used to connect together ASes of a different or ASBR Routers: routers used to connect together ASes of a different or
skipping to change at page 10, line 34 skipping to change at page 10, line 34
i) If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP i) If the boundary LSR is a candidate LSR for intra-area H-LSP/S-LSP
setup (the LSR has local policy for nesting or stitching), and if 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 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 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) 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- 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/ 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 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 signaled or selected, it propagates the inter-domain Path message to
the next-hop following the procedures described in [I-D.ietf-ccamp- the next-hop following the procedures described in
inter-domain-rsvp-te]. If, for some reason the dynamic H-LSP/S-LSP [I-D.ietf-ccamp-inter-domain-rsvp-te]. If, for some reason the
setup to the next-hop boundary LSR fails, then this SHOULD be treated dynamic H-LSP/S-LSP setup to the next-hop boundary LSR fails, then
as a path computation and signaling failure and a PErr message SHOULD this SHOULD be treated as a path computation and signaling failure
be sent upstream for the inter-domain LSP. Similarly, if selection and a PErr message SHOULD be sent upstream for the inter-domain LSP.
of a preconfigured H-LSP/S-LSP fails and local policy prevents Similarly, if selection of a preconfigured H-LSP/S-LSP fails and
dynamic H-LSP/S this SHOULD be treated as a path computation and local policy prevents dynamic H-LSP/S this SHOULD be treated as a
signaling failure and a PErr SHOULD be sent upstream for the inter- path computation and signaling failure and a PErr SHOULD be sent
domain TE LSP. In both these cases procedures described in section upstream for the inter-domain TE LSP. In both these cases procedures
4.3.4 of [RFC3209] SHOULD be followed to handle the failure. 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 ii) 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 H-LSP/S-LSP (the LSR does not have local policy for nesting or
stitching), then it SHOULD apply the same procedure as for the stitching), then it SHOULD apply the same procedure as for the
contiguous case. 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
skipping to change at page 13, line 4 skipping to change at page 13, line 4
(optionally with dynamic intervals between each trial) before trying (optionally with dynamic intervals between each trial) before trying
a lower priority path option. 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 PErr 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 [I-D.ietf-ccamp- is allowed for this inter-area TE LSP (see
crankback]). If crankback is not allowed for that inter-area TE LSP [I-D.ietf-ccamp-crankback]). If crankback is not allowed for that
or if ABR1 has been configured not to perform crankback, then ABR1 inter-area TE LSP or if ABR1 has been configured not to perform
MUST stop the signaling process and MUST forward a PErr up to the crankback, then ABR1 MUST stop the signaling process and MUST forward
Head-end LSR (R0) without trying to select another ABR. a PErr up to the Head-end LSR (R0) without trying to select 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
ERO) or by using an auto-discovery mechanism, specified above. ERO) or by using an auto-discovery mechanism, specified above.
ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the ABR1 then checks if it has a H-LSP or S-LSP to ABR3 matching the
constraints carried in the inter-area TE LSP Path message. If not, constraints carried in the inter-area TE LSP Path message. If not,
ABR1 computes the path for a H-LSP or S-LSP from ABR1 to ABR3 ABR1 computes the path for a 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 [I-D.ietf-ccamp-inter-domain- the signaling procedures described in
rsvp-te], ABR1 sends the Path message for inter-area TE LSP to ABR3. [I-D.ietf-ccamp-inter-domain-rsvp-te], ABR1 sends the Path message
Note that irrespective of whether ABR1 does nesting or stitching, the for inter-area TE LSP to ABR3. Note that irrespective of whether
Path message for the inter-area TE LSP is always forwarded to ABR3. ABR1 does nesting or stitching, the Path message for the inter-area
ABR3 then repeats the exact same procedures. If ABR3 cannot find a TE LSP is always forwarded to ABR3. ABR3 then repeats the exact same
path obeying the set of constraints for the inter-area TE LSP, ABR3 procedures. If ABR3 cannot find a path obeying the set of
sends a PErr message to ABR1. Then ABR1 can in turn either select constraints for the inter-area TE LSP, ABR3 sends a PErr message to
another H-LSP/S-LSP to ABR3 if such an LSP exists or select another ABR1. Then ABR1 can in turn either select another H-LSP/S-LSP to
egress boundary LSR (ABR4 in the example above) if crankback is ABR3 if such an LSP exists or select another egress boundary LSR
allowed for this inter-area TE LSP (see [I-D.ietf-ccamp-crankback]). (ABR4 in the example above) if crankback is allowed for this inter-
If crankback is not allowed for that inter-area TE LSP or if ABR1 has area TE LSP (see [I-D.ietf-ccamp-crankback]). If crankback is not
been configured not to perform crankback, then ABR1 forwards the PErr allowed for that inter-area TE LSP or if ABR1 has been configured not
up to the inter-area Head-end LSR (R0) without trying to select to perform crankback, then ABR1 forwards the PErr up to the inter-
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 18, line 42 skipping to change at page 18, line 42
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-05 (work in
progress), May 2005. progress), May 2005.
[I-D.ietf-ccamp-inter-domain-framework] [I-D.ietf-ccamp-inter-domain-framework]
Farrel, A., "A Framework for Inter-Domain MPLS Traffic Farrel, A., "A Framework for Inter-Domain Multiprotocol
Engineering", draft-ietf-ccamp-inter-domain-framework-04 Label Switching Traffic Engineering",
(work in progress), July 2005. draft-ietf-ccamp-inter-domain-framework-05 (work in
progress), July 2006.
[I-D.ietf-ccamp-inter-domain-pd-path-comp] [I-D.ietf-ccamp-inter-domain-pd-path-comp]
Vasseur, J., "A Per-domain path computation method for Vasseur, J., "A Per-domain path computation method for
establishing Inter-domain Traffic Engineering (TE) Label establishing Inter-domain Traffic Engineering (TE) Label
Switched Paths (LSPs)", Switched Paths (LSPs)",
draft-ietf-ccamp-inter-domain-pd-path-comp-01 (work in draft-ietf-ccamp-inter-domain-pd-path-comp-02 (work in
progress), October 2005. 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 GMPLS Traffic
Engineering - RSVP-TE extensions", Engineering - RSVP-TE extensions",
draft-ietf-ccamp-inter-domain-rsvp-te-02 (work in draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in
progress), October 2005. progress), March 2006.
[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. and J. Vasseur, "Label Switched Path
Stitching with Generalized MPLS Traffic Engineering", Stitching with Generalized MPLS Traffic Engineering",
draft-ietf-ccamp-lsp-stitching-02 (work in progress), draft-ietf-ccamp-lsp-stitching-03 (work in progress),
September 2005. March 2006.
[I-D.ietf-pce-architecture] [I-D.ietf-pce-architecture]
Farrel, A., "A Path Computation Element (PCE) Based Farrel, A., "A Path Computation Element (PCE) Based
Architecture", draft-ietf-pce-architecture-04 (work in Architecture", draft-ietf-pce-architecture-05 (work in
progress), January 2006. progress), April 2006.
[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.
Authors' Addresses Authors' Addresses
skipping to change at page 21, line 5 skipping to change at page 21, line 5
Email: arthi@juniper.net Email: arthi@juniper.net
Raymond Zhang Raymond Zhang
BT Infonet BT Infonet
2160 E. Grand Ave. 2160 E. Grand Ave.
El Segundo, CA 90025 El Segundo, CA 90025
USA USA
Email: raymond_zhang@bt.infonet.com Email: raymond_zhang@bt.infonet.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any 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
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 21, line 29 skipping to change at page 21, line 45
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.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 17 change blocks. 
65 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/