draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt   draft-ietf-ccamp-inter-domain-recovery-analysis-03.txt 
Network Working Group Tomonori Takeda, Ed. Network Working Group T. Takeda, Ed.
Internet Draft NTT Internet Draft NTT
Intended Status: Informational Yuichi Ikejiri Intended Status: Informational Y. Ikejiri
Expires: March 2008 NTT Communications Created March 24th, 2008 NTT Communications
Adrian Farrel Expires: September 24th, 2008 A. Farrel
Old Dog Consulting Old Dog Consulting
Jean-Philippe Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
September 2007
Analysis of Inter-domain Label Switched Path (LSP) Recovery Analysis of Inter-domain Label Switched Path (LSP) Recovery
draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt draft-ietf-ccamp-inter-domain-recovery-analysis-03.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 2, line 7 skipping to change at page 2, line 7
(LSP) recovery in multi-domain networks based on the existing (LSP) recovery in multi-domain networks based on the existing
framework for multi-domain LSPs. framework for multi-domain LSPs.
The main focus for this document is on establishing end-to-end The main focus for this document is on establishing end-to-end
diverse Traffic Engineering (TE) LSPs in multi-domain networks. It diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
presents various diverse LSP setup schemes based on existing presents various diverse LSP setup schemes based on existing
functional elements. functional elements.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
1.1 Terminology...................................................3 1.1 Terminology...................................................3
1.2 Domain........................................................4 1.2 Domain........................................................4
1.3 Document Scope................................................4 1.3 Document Scope................................................4
1.4 Note on Other Recovery Techniques.............................5 1.4 Note on Other Recovery Techniques.............................5
1.5 Signaling Options.............................................6 1.5 Signaling Options.............................................6
2. Diversity in Multi-domain Networks.............................6 2. Diversity in Multi-domain Networks.............................6
2.1 Multi-domain Network Topology.................................6 2.1 Multi-domain Network Topology.................................6
2.2 Note on Domain Diversity......................................8 2.2 Note on Domain Diversity......................................8
3. Factors to Consider............................................8 3. Factors to Consider............................................8
3.1 Scalability versus Optimality.................................8 3.1 Scalability versus Optimality.................................8
skipping to change at page 2, line 40 skipping to change at page 2, line 40
5.2 Head-end Path Computation (with multi-domain visibility).....16 5.2 Head-end Path Computation (with multi-domain visibility).....16
5.3 Per-Domain Path Computation..................................16 5.3 Per-Domain Path Computation..................................16
5.3.1 Sequential Path Computation................................16 5.3.1 Sequential Path Computation................................16
5.3.2 Simultaneous Path Computation..............................17 5.3.2 Simultaneous Path Computation..............................17
5.4 Inter-domain Collaborative Path Computation..................17 5.4 Inter-domain Collaborative Path Computation..................17
5.4.1 Sequential Path Computation................................17 5.4.1 Sequential Path Computation................................17
5.4.2 Simultaneous Path Computation..............................18 5.4.2 Simultaneous Path Computation..............................18
6. Network Topology Specific Considerations......................18 6. Network Topology Specific Considerations......................18
7. Addressing Considerations.....................................19 7. Addressing Considerations.....................................19
8. Note on SRLG Diversity........................................19 8. Note on SRLG Diversity........................................19
9. Security Considerations.......................................19 9. IANA Considerations...........................................19
10. References...................................................20 10. Security Considerations......................................19
10.1 Normative References........................................20 11. References...................................................20
10.2 Informative References......................................20 11.1 Normative References........................................20
11. Acknowledgments..............................................22 11.2 Informative References......................................20
12. Authors' Addresses...........................................22 12. Acknowledgments..............................................22
Intellectual Property Consideration..............................23 13. Authors' Addresses...........................................22
Full Copyright Statement.........................................23
1. Introduction 1. Introduction
This document analyzes various schemes to realize Multiprotocol Label This document analyzes various schemes to realize Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
(LSP) recovery in multi-domain networks based on the existing (LSP) recovery in multi-domain networks based on the existing
framework for multi-domain LSPs. framework for multi-domain LSPs.
The main focus for this document is on establishing end-to-end The main focus for this document is on establishing end-to-end
diverse Traffic Engineering (TE) LSPs in multi-domain networks. It diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
skipping to change at page 5, line 40 skipping to change at page 5, line 44
LSPs (see Section 1.4). LSPs (see Section 1.4).
- Details of maintenance of diverse LSPs, such as re-optimization and - Details of maintenance of diverse LSPs, such as re-optimization and
OAM. OAM.
- Comparative evaluation of various diverse LSP setup schemes - Comparative evaluation of various diverse LSP setup schemes
mentioned in this document. mentioned in this document.
1.4 Note on Other Recovery Techniques 1.4 Note on Other Recovery Techniques
Fast Reroute and segment recovery in multi-domain networks are Fast Reroute and segment recovery in multi-domain networks are
described in Section 5.4 of [RFC4726], and a more detailed analysis described in Section 5.4 of [RFC4726], and a more detailed analysis
is provided in Section 5 of [inter-domain-rsvp]. This document does is provided in Section 5 of [RFC5151]. This document does not cover
not cover any additional analysis for Fast ReRoute and segment any additional analysis for Fast ReRoute and segment recovery in
recovery in multi-domain networks. multi-domain networks.
Also, the recovery type of an LSP or service may change at a domain Also, the recovery type of an LSP or service may change at a domain
boundary. That is, the recovery type could remain the same within one boundary. That is, the recovery type could remain the same within one
domain, but might be different in the next domain. This may be due to domain, but might be different in the next domain. This may be due to
the capabilities of each domain, administrative policies, or to the capabilities of each domain, administrative policies, or to
topology limitations. An example is where protection at the domain topology limitations. An example is where protection at the domain
boundary is provided by link protection on the inter-domain link(s), boundary is provided by link protection on the inter-domain link(s),
but where protection within each domain is achieved through segment but where protection within each domain is achieved through segment
recovery. This mixture of protection techniques is beyond the scope recovery. This mixture of protection techniques is beyond the scope
of this document. of this document.
skipping to change at page 6, line 18 skipping to change at page 6, line 21
of this document (see Section 2.2). of this document (see Section 2.2).
1.5 Signaling Options 1.5 Signaling Options
There are three signaling options for establishing inter-domain TE There are three signaling options for establishing inter-domain TE
LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The
description in this document of diverse LSP setup is agnostic in description in this document of diverse LSP setup is agnostic in
relation to the signaling option used, unless otherwise specified. relation to the signaling option used, unless otherwise specified.
Note that signaling option-specific considerations for Fast Reroute Note that signaling option-specific considerations for Fast Reroute
and segment recovery are described in Section 5 of [inter-domain- and segment recovery are described in Section 5 of [RFC5151].
rsvp].
2. Diversity in Multi-domain Networks 2. Diversity in Multi-domain Networks
As described in Section 1.3, analysis of diverse LSP setup schemes in As described in Section 1.3, analysis of diverse LSP setup schemes in
multi-domain networks is the main focus of this document. This multi-domain networks is the main focus of this document. This
section describes some assumptions in this problem space made in this section describes some assumptions in this problem space made in this
document. document.
2.1 Multi-domain Network Topology 2.1 Multi-domain Network Topology
skipping to change at page 9, line 49 skipping to change at page 9, line 49
networks, and L1VPNs. networks, and L1VPNs.
o Per domain path computation or inter-domain collaborative path o Per domain path computation or inter-domain collaborative path
computation computation
- Per domain path computation - Per domain path computation
In this scheme, a path is computed domain by domain as LSP In this scheme, a path is computed domain by domain as LSP
signaling progresses through the network. This scheme requires signaling progresses through the network. This scheme requires
ERO expansion in each domain. The case for unprotected LSPs under ERO expansion in each domain. The case for unprotected LSPs under
this scheme is covered in [inter-domain-pd]. this scheme is covered in [RFC5152].
- Inter-domain collaborative path computation - Inter-domain collaborative path computation
In this scheme, path computation is typically done before In this scheme, path computation is typically done before
signaling. This scheme typically uses communication between signaling. This scheme typically uses communication between
cooperating path computation elements (PCEs) [RFC4655]. An cooperating path computation elements (PCEs) [RFC4655]. An
example of such a scheme is Backward Recursive Path Computation example of such a scheme is Backward Recursive Path Computation
(BRPC) [brpc]. The use of BRPC for unprotected LSPs under this (BRPC) [brpc]. The use of BRPC for unprotected LSPs under this
scheme is covered in [brpc]. scheme is covered in [brpc].
Note that these are path computation techniques. It is also Note that these are path computation techniques. It is also
skipping to change at page 11, line 40 skipping to change at page 11, line 40
The full explicit paths for the working and recovery LSPs are The full explicit paths for the working and recovery LSPs are
computed at the head-end either by the head-end itself or by a PCE. computed at the head-end either by the head-end itself or by a PCE.
In either case the computing entity has full TE visibility across In either case the computing entity has full TE visibility across
multiple domains and no further computation or signaling multiple domains and no further computation or signaling
considerations are needed. considerations are needed.
4.3 Per-domain Path Computation 4.3 Per-domain Path Computation
Sections 3.2.2, 3.2.3 and 3.3 of [RFC4726] describe this path Sections 3.2.2, 3.2.3 and 3.3 of [RFC4726] describe this path
computation technique. More detailed procedures are described in computation technique. More detailed procedures are described in
[inter-domain-pd]. [RFC5152].
In this scheme, the explicit paths of the working and recovery LSPs In this scheme, the explicit paths of the working and recovery LSPs
are specified as the complete strict path in the source domain are specified as the complete strict path in the source domain
followed by one of the following: followed by one of the following:
- The complete list of boundary LSRs (or domain identifiers, e.g., AS - The complete list of boundary LSRs (or domain identifiers, e.g., AS
numbers) along the path. numbers) along the path.
- The boundary LSR for the source domain and the LSP destination. - The boundary LSR for the source domain and the LSP destination.
skipping to change at page 12, line 16 skipping to change at page 12, line 16
two specific schemes, which are described in Sections 4.3.1 and 4.3.2 two specific schemes, which are described in Sections 4.3.1 and 4.3.2
respectively. respectively.
4.3.1 Sequential Path Computation 4.3.1 Sequential Path Computation
The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details
are as follows. It should be noted that the PRIMARY_PATH_ROUTE Object are as follows. It should be noted that the PRIMARY_PATH_ROUTE Object
defined in [RFC4872] for end-to-end protection is not intended as a defined in [RFC4872] for end-to-end protection is not intended as a
path exclusion mechanism. path exclusion mechanism.
Assume that the working LSP is established as described in [inter- Assume that the working LSP is established as described in [RFC5152].
domain-pd]. Also, assume that the route of the working LSP (full Also, assume that the route of the working LSP (full route) is
route) is available at the head-end through the RRO. available at the head-end through the RRO.
o Path computation aspect o Path computation aspect
When performing path computation (ERO expansion) for the recovery When performing path computation (ERO expansion) for the recovery
LSP as it crosses each domain boundary a path is selected that LSP as it crosses each domain boundary a path is selected that
avoids the nodes/links/SRLGs used by the working path so that a avoids the nodes/links/SRLGs used by the working path so that a
diverse path is obtained. When path computation is performed by a diverse path is obtained. When path computation is performed by a
PCE on behalf of each domain boundary LSR, the resources to avoid PCE on behalf of each domain boundary LSR, the resources to avoid
can be communicated to a PCE using the XRO extension [PCEP-XRO] to can be communicated to a PCE using the XRO extension [PCEP-XRO] to
the PCE Protocol (PCEP) [PCEP]. the PCE Protocol (PCEP) [PCEP].
skipping to change at page 15, line 43 skipping to change at page 15, line 43
- Path key: Provide each per-domain segment of the path in advance to - Path key: Provide each per-domain segment of the path in advance to
the domain boundary nodes or to the PCE that computed the path for the domain boundary nodes or to the PCE that computed the path for
a limited period of time (temporary caching) and identify it in the a limited period of time (temporary caching) and identify it in the
signaled ERO using a path key. When path computation is done by signaled ERO using a path key. When path computation is done by
PCE, the identify of the PCE containing state for the path may be PCE, the identify of the PCE containing state for the path may be
required as well (e.g., PCE I-D). The path key is provided by the required as well (e.g., PCE I-D). The path key is provided by the
PCE to the head-end for inclusion in the ERO [conf-segment]. PCE to the head-end for inclusion in the ERO [conf-segment].
- LSP segment: Pre-establish each per-domain segments of the path - LSP segment: Pre-establish each per-domain segments of the path
using hierarchical LSPs [RFC4206] or LSP stitching segments using hierarchical LSPs [RFC4206] or LSP stitching segments
[LSP-stitch] and signal the end-to-end LSP to use these per-domain [RFC5150] and signal the end-to-end LSP to use these per-domain
LSPs. This scheme might need additional identifiers (such as LSP LSPs. This scheme might need additional identifiers (such as LSP
IDs) in the Path message so that the domain boundary node can IDs) in the Path message so that the domain boundary node can
identify which LSP segment or tunnel to use for the end-to-end LSP. identify which LSP segment or tunnel to use for the end-to-end LSP.
Furthermore, this scheme may require additional communication to Furthermore, this scheme may require additional communication to
pre-establish the LSP segments. pre-establish the LSP segments.
These techniques may be directly applied, or may be applied with These techniques may be directly applied, or may be applied with
extensions, depending on specific diverse LSP setup schemes described extensions, depending on specific diverse LSP setup schemes described
below. below.
skipping to change at page 16, line 37 skipping to change at page 16, line 37
5.2 Head-end Path Computation (with multi-domain visibility) 5.2 Head-end Path Computation (with multi-domain visibility)
This scheme is not applicable since multi-domain visibility violates This scheme is not applicable since multi-domain visibility violates
confidentiality. confidentiality.
5.3 Per-Domain Path Computation 5.3 Per-Domain Path Computation
5.3.1 Sequential Path Computation 5.3.1 Sequential Path Computation
Assume the working LSP is established as described in [inter-domain- Assume the working LSP is established as described in [RFC5152].
pd].
It is not possible to obtain the route of the working LSP from the It is not possible to obtain the route of the working LSP from the
RRO at the head-end due to confidentiality restrictions. In order to RRO at the head-end due to confidentiality restrictions. In order to
provide the path of the working LSP through each domain to the provide the path of the working LSP through each domain to the
computation point responsible for computing the path of the computation point responsible for computing the path of the
protection LSP through each domain additional mechanisms are needed. protection LSP through each domain additional mechanisms are needed.
Examples of such mechanisms are: Examples of such mechanisms are:
- Information identifying the working LSP is included in the Path - Information identifying the working LSP is included in the Path
message for the recovery LSP, and the domain boundary node consults message for the recovery LSP, and the domain boundary node consults
skipping to change at page 19, line 35 skipping to change at page 19, line 35
- Record of the SRLGs used by the working LSP. - Record of the SRLGs used by the working LSP.
- Indication of a set of SRLGs to exclude in the computation of the - Indication of a set of SRLGs to exclude in the computation of the
recovery LSP's path. recovery LSP's path.
Furthermore, SRLG IDs may be assigned independently in each domain, Furthermore, SRLG IDs may be assigned independently in each domain,
and might not have global meaning. In such a scenario, some mapping and might not have global meaning. In such a scenario, some mapping
functions are necessary, similar to the mapping of other TE functions are necessary, similar to the mapping of other TE
parameters mentioned in Section 1.2. parameters mentioned in Section 1.2.
9. Security Considerations 9. IANA Considerations
This informational document makes no requests for IANA action.
10. Security Considerations
This document does not require additional security considerations This document does not require additional security considerations
mentioned in [RFC4726], which is the basis of this document. That is, mentioned in [RFC4726], which is the basis of this document. That is,
LSP path computation and setup across domain boundaries is LSP path computation and setup across domain boundaries is
necessarily a security concern and will be subject to operational necessarily a security concern and will be subject to operational
policies. In particular, the trust model across domain boundaries for policies. In particular, the trust model across domain boundaries for
computation and signaling must be carefully considered since LSP computation and signaling must be carefully considered since LSP
setup (whether successful or not) can consume domain network data setup (whether successful or not) can consume domain network data
resources (bandwidth), and signaling or computation requests can resources (bandwidth), and signaling or computation requests can
consume network processing resources (CPU and control channel consume network processing resources (CPU and control channel
bandwidth). bandwidth).
RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication
capabilities, and these should be seriously considered in all inter- capabilities, and these should be seriously considered in all inter-
domain deployments. domain deployments.
More discussion on security considerations in MPLG/GMPLS networks is More discussion on security considerations in MPLG/GMPLS networks is
found in a specific document [security-fw]. found in a specific document [security-fw].
10. References 11. References
10.1 Normative References 11.1 Normative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE: Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209, Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001. December 2001.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain MPLS Traffic
Engineering", RFC 4726, November 2006.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed.,
"Recovery (Protection and Restoration) "Recovery (Protection and Restoration)
Terminology for Generalized Multi-Protocol Label Terminology for Generalized Multi-Protocol Label
Switching (GMPLS)", RFC 4427, March 2006. Switching (GMPLS)", RFC 4427, March 2006.
10.2 Informative References [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain MPLS Traffic
Engineering", RFC 4726, November 2006.
11.2 Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched
Paths (LSP) Hierarchy with Generalized Multi-
Protocol Label Switching (GMPLS) Traffic
Engineering (TE)", RFC 4206, October 2005.
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Rekhter, "Generalized Multiprotocol Label Rekhter, "Generalized Multiprotocol Label
Switching (GMPLS) User-Network Interface (UNI): Switching (GMPLS) User-Network Interface (UNI):
Resource ReserVation Protocol-Traffic Engineering Resource ReserVation Protocol-Traffic Engineering
(RSVP-TE) Support for the Overlay Model", (RSVP-TE) Support for the Overlay Model",
RFC 4208, October 2005. RFC 4208, October 2005.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-
Layer 1 Virtual Private Networks", RFC 4847, Autonomous System (AS) Traffic Engineering (TE)
April 2007. Requirements", RFC 4216, November 2005
[RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path
Computation Element (PCE) Architecture", Computation Element (PCE) Architecture",
RFC 4655, August 2006. RFC 4655, August 2006.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for
Layer 1 Virtual Private Networks", RFC 4847,
April 2007.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D.
(Eds.), "RSVP-TE Extensions in support of End-to- (Eds.), "RSVP-TE Extensions in support of End-to-
End Generalized Multi-Protocol Label Switching End Generalized Multi-Protocol Label Switching
(GMPLS)-based Recovery", RFC 4872, May 2007. (GMPLS)-based Recovery", RFC 4872, May 2007.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels",
RFC 4090, May 2005.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and
A. Farrel, "GMPLS Based Segment Recovery", A. Farrel, "GMPLS Based Segment Recovery",
RFC 4873, May 2007. RFC 4873, May 2007.
[RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005
[inter-domain-rsvp] Farrel, A., Ed., "Inter domain Multiprotocol
Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering - RSVP-TE
extensions", draft-ietf-ccamp-inter-domain-rsvp-
te, work in progress.
[RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S.,
"Exclude Routes - Extension to Resource "Exclude Routes - Extension to Resource
ReserVation Protocol-Traffic Engineering ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4874, April 2007. (RSVP-TE)", RFC 4874, April 2007.
[inter-domain-pd] Vasseur JP., Ed., and Ayyangar A., Ed., "A Per- [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions
domain path computation method for establishing for MPLS and GMPLS RSVP-TE ", RFC 4920, July
Inter-domain Traffic Engineering (TE) Label 2007.
Switched Paths (LSPs)", draft-ietf-ccamp-inter-
domain-pd-path-comp, work in progress. [RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur,
"Label Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)", RFC 5150, February 2008.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur,
"Inter-Domain MPLS and GMPLS Traffic Engineering
-- Resource Reservation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 5151,
February 2008.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R.
Zhang, "A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering
(TE) Label Switched Paths (LSPs)", RFC 5152,
February 2008.
[brpc] Vasseur, JP., Ed., "A Backward Recursive [brpc] Vasseur, JP., Ed., "A Backward Recursive
PCE-based Computation (BRPC) procedure to compute PCE-based Computation (BRPC) procedure to compute
shortest inter-domain Traffic Engineering Label shortest inter-domain Traffic Engineering Label
Switched Paths", draft-ietf-pce-brpc, work in Switched Paths", draft-ietf-pce-brpc, work in
progress. progress.
[PCEP-XRO] Oki, E., and A. Farrel, "Extensions to the Path
Computation Element Communication Protocol (PCEP)
for Route Exclusions", draft-ietf-pce-pcep-xro,
work in progress.
[PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path
Computation Element (PCE) communication Protocol
(PCEP)", draft-ietf-pce-pcep, work in progress.
[conf-segment] Bradford, R., Ed., "Preserving Topology [conf-segment] Bradford, R., Ed., "Preserving Topology
Confidentiality in Inter-Domain Path Computation Confidentiality in Inter-Domain Path Computation
using a key based mechanism ", draft-ietf-pce- using a key based mechanism ", draft-ietf-pce-
path-key, work in progress. path-key, work in progress.
[RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path
for MPLS and GMPLS RSVP-TE ", RFC 4920, Computation Element (PCE) communication Protocol
July 2007. (PCEP)", draft-ietf-pce-pcep, work in progress.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched
Paths (LSP) Hierarchy with Generalized Multi-
Protocol Label Switching (GMPLS) Traffic
Engineering (TE)", RFC 4206, October 2005.
[LSP-stitch] Ayyangar, A., Kompella, K., Vasseur, JP., and [PCEP-XRO] Oki, E., and A. Farrel, "Extensions to the Path
A. Farrel, "Label Switched Path Stitching with Computation Element Communication Protocol (PCEP)
Generalized Multiprotocol Label Switching Traffic for Route Exclusions", draft-ietf-pce-pcep-xro,
Engineering (GMPLS TE)", draft-ietf-ccamp-lsp- work in progress.
stitching, work in progress.
[security-fw] Fang, L., " Security Framework for MPLS and GMPLS [security-fw] Fang, L., " Security Framework for MPLS and GMPLS
Networks", draft-fang-mpls-gmpls-security- Networks", draft-ietf-mpls-mpls-gmpls-security-
Framework, work in progress. framework, work in progress.
11. Acknowledgments 12. Acknowledgments
Authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro Authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro
Fujihara, Dimitri Papadimitriou and Meral Shirazipour for valuable Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for valuable
comments. comments.
12. Authors' Addresses 13. Authors' Addresses
Tomonori Takeda Tomonori Takeda
NTT Network Service Systems Laboratories, NTT Corporation NTT Network Service Systems Laboratories, NTT Corporation
3-9-11, Midori-Cho 3-9-11, Midori-Cho
Musashino-Shi, Tokyo 180-8585 Japan Musashino-Shi, Tokyo 180-8585 Japan
Email : takeda.tomonori@lab.ntt.co.jp Email : takeda.tomonori@lab.ntt.co.jp
Yuichi Ikejiri Yuichi Ikejiri
NTT Communications Corporation NTT Communications Corporation
Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
skipping to change at page 23, line 31 skipping to change at page 23, line 37
at http://www.ietf.org/ipr. at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
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 This document is subject to the rights, licenses and
restrictions contained in BCP 78, and except as set restrictions contained in BCP 78, and except as set
forth therein, the authors retain all their rights. forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY,
THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
 End of changes. 32 change blocks. 
92 lines changed or deleted 90 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/