draft-ietf-ccamp-inter-domain-recovery-analysis-03.txt   draft-ietf-ccamp-inter-domain-recovery-analysis-04.txt 
Network Working Group T. Takeda, Ed. Network Working Group T. Takeda, Ed.
Internet Draft NTT Internet Draft NTT
Intended Status: Informational Y. Ikejiri Intended Status: Informational A. Farrel, Ed.
Created March 24th, 2008 NTT Communications Created April 13, 2008 Old Dog Consulting
Expires: September 24th, 2008 A. Farrel Expires: October 13, 2008 Y. Ikejiri
Old Dog Consulting NTT Communications
JP. Vasseur JP. Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
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-03.txt
draft-ietf-ccamp-inter-domain-recovery-analysis-04.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 40 skipping to change at page 1, line 40
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.
Abstract Abstract
This document analyzes various schemes to realize Multiprotocol Label Protection and recovery are important features of service provision
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
(LSP) recovery in multi-domain networks based on the existing networks. Increasingly, MPLS and GMPLS networking is being widened
framework for multi-domain LSPs. from single domain scope to operate in multi-domain environments.
The main focus for this document is on establishing end-to-end Various schemes and processes have been developed to establish Label
diverse Traffic Engineering (TE) LSPs in multi-domain networks. It Switched Paths (LSPs) in multi-domain environments. These are
presents various diverse LSP setup schemes based on existing discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
functional elements. Label Switching Traffic Engineering.
This document analyzes the application of these techniques to
protection and recovery in multi-domain networks. The main focus for
this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks.
Table of Contents Table of Contents
1. Introduction...................................................3 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................................................5
1.4 Note on Other Recovery Techniques.............................5 1.4 Note on Other Recovery Techniques.............................6
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............................................9
3.1 Scalability versus Optimality.................................8 3.1 Scalability Versus Optimality.................................9
3.2 Key Concepts..................................................9 3.2 Key Concepts..................................................9
4. Diverse LSP Setup Schemes without Confidentiality.............11 4. Diverse LSP Setup Schemes Without Confidentiality.............11
4.1 Management Configuration.....................................11 4.1 Management Configuration.....................................11
4.2 Head-end Path Computation (with multi-domain visibility).....11 4.2 Head-End Path Computation (With Multi-Domain Visibility).....12
4.3 Per-domain Path Computation..................................11 4.3 Per-Domain Path Computation..................................12
4.3.1 Sequential Path Computation................................12 4.3.1 Sequential Path Computation................................12
4.3.2 Simultaneous Path Computation..............................12 4.3.2 Simultaneous Path Computation..............................13
4.4 Inter-domain Collaborative Path Computation..................13 4.4 Inter-Domain Collaborative Path Computation..................14
4.4.1 Sequential Path Computation................................14 4.4.1 Sequential Path Computation................................15
4.4.2 Simultaneous Path Computation..............................14 4.4.2 Simultaneous Path Computation..............................15
5. Diverse LSP Setup Schemes with Confidentiality................15 5. Diverse LSP Setup Schemes With Confidentiality................15
5.1 Management Configuration.....................................16 5.1 Management Configuration.....................................17
5.2 Head-end Path Computation (with multi-domain visibility).....16 5.2 Head-End Path Computation (With Multi-Domain Visibility).....17
5.3 Per-Domain Path Computation..................................16 5.3 Per-Domain Path Computation..................................17
5.3.1 Sequential Path Computation................................16 5.3.1 Sequential Path Computation................................17
5.3.2 Simultaneous Path Computation..............................17 5.3.2 Simultaneous Path Computation..............................18
5.4 Inter-domain Collaborative Path Computation..................17 5.4 Inter-Domain Collaborative Path Computation..................19
5.4.1 Sequential Path Computation................................17 5.4.1 Sequential Path Computation................................19
5.4.2 Simultaneous Path Computation..............................18 5.4.2 Simultaneous Path Computation..............................20
6. Network Topology Specific Considerations......................18 6. Network Topology Specific Considerations......................20
7. Addressing Considerations.....................................19 7. Addressing Considerations.....................................20
8. Note on SRLG Diversity........................................19 8. Note on SRLG Diversity........................................20
9. IANA Considerations...........................................19 9. IANA Considerations ..........................................21
10. Security Considerations......................................19 10. Security Considerations......................................21
11. References...................................................20 11. References...................................................21
11.1 Normative References........................................20 11.1 Normative References........................................21
11.2 Informative References......................................20 11.2 Informative References......................................22
12. Acknowledgments..............................................22 12. Acknowledgments..............................................24
13. Authors' Addresses...........................................22 13. Authors' Addresses...........................................24
1. Introduction 1. Introduction
This document analyzes various schemes to realize Multiprotocol Label Protection and recovery in Multiprotocol Label Switching (MPLS) and
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path Generalized MPLS (GMPLS) networks are described in [RFC4428]. These
(LSP) recovery in multi-domain networks based on the existing are important features for service delivery in MPLS and GMPLS
framework for multi-domain LSPs. networks.
The main focus for this document is on establishing end-to-end MPLS and GMPLS networking was originally limited to single domain
diverse Traffic Engineering (TE) LSPs in multi-domain networks. It environments. Increasingly, multi-domain MPLS and GMPLS networks are
presents various diverse LSP setup schemes based on existing being considered, where a domain is considered to be any collection
functional elements. of network elements within a common sphere of address management or
path computational responsibility. Examples of such domains include
Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).
[RFC4726] provides a framework for inter-domain MPLS and GMPLS
traffic engineering. It introduces and discusses the various schemes
and processes to establish Label Switched Paths (LSPs) in multi-
domain environments.
However, protection and recovery introduce additional complexities to
LSP establishment. Protection LSPs are generally required to path
diverse from the working LSPs that they protect. Achieving this is
particularly challenging in multi-domain environments because no
single path computation or planning point is capable of determining
both paths from one end to the other.
This document analyzes various schemes to realize MPLS and GMPLS
LSP recovery in multi-domain networks. The main focus for this
document is on establishing end-to-end diverse Traffic Engineering
(TE) LSPs in multi-domain networks.
1.1 Terminology 1.1 Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology for LSP
recovery set out in [RFC4427], and with the terms introduced in
[RFC4726] that provides a framework for inter-domain Label Switched [RFC4726] that provides a framework for inter-domain Label Switched
Path (LSP) setup, and [RFC4427] that provides terminology for LSP Path (LSP) setup. Key terminology may also be found in [RFC4216]
recovery. where requirements for MPLS traffic engineering inter-AS are set out.
The following are several key terminologies used within this The following key terms from those sources are used within this
document. document.
- Domain: See [RFC4726]. A domain is considered to be any - Domain: See [RFC4726]. A domain is considered to be any
collection of network elements within a common sphere of address collection of network elements within a common sphere of address
management or path computational responsibility. Note that nested management or path computational responsibility. Note that nested
domains continue to be out of scope. Section 1.2 provides some more domains continue to be out of scope. Section 1.2 provides
details. additional details.
- Working LSP: See [RFC4427]. The working LSP transports normal user - Working LSP: See [RFC4427]. The working LSP transports normal user
traffic. Note that the term LSP and TE LSP will be used traffic. Note that the term LSP and TE LSP will be used
interchangeably. interchangeably.
- Recovery LSP: See [RFC4427]. The recovery LSP transports normal - Recovery LSP: See [RFC4427]. The recovery LSP transports normal
user traffic when the working LSP fails. The recovery LSP may user traffic when the working LSP fails. The recovery LSP may
transport user traffic even when the working LSP is transporting also carry user traffic even when the working LSP is operating
normal user traffic (e.g., 1+1 protection). In such a scenario, normally and transporting the user traffic (e.g., 1+1 protection).
the recovery LSP is sometimes referred to as a protecting LSP. The recovery LSP is sometimes referred to as a protecting LSP.
- Diversity: See [RFC4726]. Diversity means the relationship - Diversity: See [RFC4726]. Diversity means the relationship
of multiple LSPs, where those LSPs do not share some specific type of multiple LSPs, where those LSPs do not share some specific type
of resource (e.g., link, node, or shared risk link group (SRLG)). of resource (e.g., link, node, or shared risk link group (SRLG)).
Diversity is also referred to as disjointness.
Diverse LSPs may be used for various purposes, such as load- Diverse LSPs may be used for various purposes, such as load-
balancing and recovery. In this document, the recovery aspect of balancing and recovery. In this document, the recovery aspect of
diversity, specifically the end-to-end diversity of two traffic diversity, specifically the end-to-end diversity of two traffic
engineering (TE) LSPs, is the focus. Those two diverse LSPs are engineering (TE) LSPs, is the focus. The two diverse LSPs are
referred to as the working LSP and recovery LSP hereafter. referred to as the working LSP and recovery LSP.
Sometimes, diversity is referred to as disjointness.
- Confidentiality: See [RFC4216]. The term confidentiality applies - Confidentiality: See [RFC4216]. Confidentiality refers to the
to the protection of information about the topology and resources protection of information about the topology and resources
present within one domain from visibility by people or of one domain from visibility by people or applications outside
applications outside that domain. that domain.
1.2 Domain 1.2 Domain
In order to fully understand the issues addressed in this document,
it is necessary to carefully define and scope the term "domain".
As defined in [RFC4726], a domain is considered to be any collection As defined in [RFC4726], a domain is considered to be any collection
of network elements within a common sphere of address management or of network elements within a common sphere of address management or
path computational responsibility. Examples of such domains include path computational responsibility. Examples of such domains include
IGP areas and Autonomous Systems. A network accessed over the IGP areas and Autonomous Systems. A network accessed over the GMPLS
Generalized Multiprotocol Label Switching (GMPLS) User-to-Network User-to-Network Interface (UNI) [RFC4208] and a Layer One Virtual
Interface (UNI) [RFC4208] and a Layer One Virtual Private Network Private Network (L1VPN) [RFC4847] are special cases of multi-domain
(L1VPN) [RFC4847] are special cases of multi-domain networks. networks.
Example objectives of domain usage include administrative separation, Example motivations for using more than one domain include
scalability, and forming protection domains. administrative separation, scalability, and the construction of
domains for the purpose of providing protection. These latter
"protection domains" offer edge-to-edge protection facilities for
spans or segments of end-to-end LSPs.
As described in [RFC4726], there could be TE parameters (such as As described in [RFC4726], there could be TE parameters (such as
color and priority) whose meanings are specific to each domain. In color and priority) whose meanings are specific to each domain. In
such scenarios, mapping functions could be performed based on policy such scenarios, in order to set up inter-domain LSPs, mapping
agreements between domain administrators. functions may be needed to transform the TE parameters based on
policy agreements between domain administrators.
1.3 Document Scope 1.3 Document Scope
This document analyzes various schemes to realize Multiprotocol Label This document analyzes various schemes to realize MPLS and GMPLS LSP
Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi- recovery in multi-domain networks. It is based on the existing
domain networks based on the existing framework for multi-domain LSP framework for multi-domain LSP setup [RFC4726]. Note that this
setup [RFC4726]. Note that this document does not intend to prevent document does not prevent the development of additional techniques
development of additional techniques where appropriate (i.e., where appropriate (i.e., additional to the ones described in this
additional to ones described in this document, which are based on the document). In other words, this shows how the existing techniques can
existing framework described in [RFC4726]). In other words, this be applied.
document is informational and intends to show how the existing
framework can be applied with specific procedures described in this
document and the documents referred to by this document.
There are various recovery techniques for LSPs. For TE LSPs, major There are various recovery techniques for LSPs. For TE LSPs, the
techniques are end-to-end recovery [RFC4872], local protection such major techniques are end-to-end recovery [RFC4872], local protection
as Fast Reroute (FRR) [RFC4090] (in packet switching environments), such as Fast Reroute (FRR) [RFC4090] (in packet switching
and segment recovery [RFC4873] (in GMPLS). environments), and segment recovery [RFC4873] (in GMPLS).
In this document the main focus is the analysis of diverse TE LSP The main focus of this document is the analysis of diverse TE LSP
(hereafter LSP) setup schemes (path computation and signaling setup schemes that can be used in the context of end-to-end recovery.
aspects), which can advantageously be used in the context of end-to- The methodology is to show different combinations of functional
end recovery. This document presents various diverse LSP setup elements such as path computation and signaling techniques.
schemes by combining various functional elements. In particular,
Section 5.5 of [RFC4726] describes some analysis of diverse LSPs in
multi-domain networks, and this document provides more detailed
analysis based on that content.
[RFC4105] and [RFC4216] describe requirements for diverse LSPs. There [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There
could be various types of diversity, and this document focuses on are various types of diversity, and this document focuses on node,
node/link/SRLG diversity. link, and shared risk link group (SRLG) diversity.
Based on the service grade, both the working LSP and the recovery LSP
may be established at the time of service establishment (e.g.,
service requiring high resiliency). Alternatively, the recovery LSP
may be added later due to a change in the grade of the service. This
document covers both scenarios. Also, there may or may not be
confidentiality requirements among domains. This document covers both
scenarios. Section 3.2 describes more details on confidentiality.
Specific assumptions made in this problem space are described in
Section 2.
Note that the recovery LSP may be used for 1+1 protection, 1:1 Recovery LSPs may be used for 1+1 protection, 1:1 protection, or
protection, or shared mesh restoration. However, ways to compute shared mesh restoration. However, the requirements for path
diverse paths, and the signaling of these TE LSPs are common across diversity, the ways to compute diverse paths, and the signaling of
all uses, and these topics are the main scope of this document. these TE LSPs are common across all uses, and these topics are the
main scope of this document.
Also, note that diverse LSPs may be used for various purposes, in Note that diverse LSPs may be used for various purposes in addition
addition to recovery. An example is for load-balancing, so as to to recovery. An example is for load-balancing, so as to limit the
limit the traffic disruption to a portion of the traffic flow in case traffic disruption to a portion of the traffic flow in case of a
of a single network element failure. This document does not preclude single network element failure. This document does not preclude use
use of diverse LSP setup schemes for those purposes. of diverse LSP setup schemes for those purposes.
The following are beyond the scope of this document. The following are beyond the scope of this document.
- Analysis of recovery techniques other than link/node/SRLG diverse - Analysis of recovery techniques other than the use of link, node,
LSPs (see Section 1.4). or SRLG diverse 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
mentioned in this document. - Comparative evaluation of LSP setup schemes.
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 [RFC5151]. This document does not cover is provided in Section 5 of [RFC5151]. This document does not cover
any additional analysis for Fast ReRoute and segment recovery in any additional analysis for Fast ReRoute and segment recovery in
multi-domain networks. multi-domain networks.
Also, the recovery type of an LSP or service may change at a domain 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 links,
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.
Domain diversity (that is, the selection of paths that have only the Domain diversity (that is, the selection of paths that have only the
ingress and egress domains in common) may be considered as one form ingress and egress domains in common) may be considered as one form
of diversity in multi-domain networks, but this is beyond the scope of diversity in multi-domain networks, but this is beyond the scope
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 considerations for Fast Reroute and
and segment recovery are described in Section 5 of [RFC5151]. segment recovery are described in [RFC5151].
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 This section describes some assumptions about achieving path
multi-domain networks is the main focus of this document. This diversity in multi-domain networks.
section describes some assumptions in this problem space made in this
document.
2.1 Multi-domain Network Topology 2.1 Multi-Domain Network Topology
Figures 1 and 2 show example multi-domain network topologies. In Figures 1 and 2 show example multi-domain network topologies. In
Figure 1, domains are connected in a linear topology. There are Figure 1, domains are connected in a linear topology. There are
multiple paths between nodes A and L, but all of them cross domain#1- multiple paths between nodes A and L, but all of them cross domain#1-
domain#2-domain#3 in that order. domain#2-domain#3 in that order.
+--Domain#1--+ +--Domain#2--+ +--Domain#3--+ +--Domain#1--+ +--Domain#2--+ +--Domain#3--+
| | | | | | | | | | | |
| B------+---+---D-----E--+---+------J | | B------+---+---D-----E--+---+------J |
| / | | \ / | | \ | | / | | \ / | | \ |
| / | | \ / | | \ | | / | | \ / | | \ |
| A | | H | | L | | A | | H | | L |
| \ | | / \ | | / | | \ | | / \ | | / |
| \ | | / \ | | / | | \ | | / \ | | / |
| C------+---+---F-----G--+---+------K | | C------+---+---F-----G--+---+------K |
| | | | | | | | | | | |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
Figure 1: Linear Connectivity Figure 1: Linear Domain Connectivity
+-----Domain#2-----+ +-----Domain#2-----+
| | | |
| E--------------F | | E--------------F |
| | | | | | | |
| | | | | | | |
+-+--------------+-+ +-+--------------+-+
| | | |
| | | |
+--Domain#1-+--+ +-------+------+ +--Domain#1-+--+ +-------+------+
| | | | | | | | | | | |
skipping to change at page 7, line 27 skipping to change at page 7, line 42
| | | | | | | | | | | |
+------+-------+ +--+-Domain#4--+ +------+-------+ +--+-Domain#4--+
| | | |
+-+--------------+-+ +-+--------------+-+
| | | | | | | |
| | | | | | | |
| G--------------H | | G--------------H |
| | | |
+-----Domain#3-----+ +-----Domain#3-----+
Figure 2: Mesh Connectivity Figure 2: Meshed Domain Connectivity
In Figure 2, domains are connected in a mesh topology. There are In Figure 2, domains are connected in a mesh topology. There are
multiple paths between nodes A and D, and these paths do not multiple paths between nodes A and D, and these paths do not cross
necessarily follow the same set of domains. the same domains. If inter-domain connectivity forms a mesh, domain
level routing is required (even for the unprotected case). This is
Indeed, if inter-domain connectivity forms a mesh, domain level tightly coupled with the next hop domain resolution/discovery
routing is required (even for the unprotected case). This is tightly mechanisms used in IP networks.
coupled with the next hop domain resolution/discovery mechanisms.
In this document, we assume that domain level routing is given via In this document, we assume that domain level routing is given via
configuration, policy, or some external mechanism, and that this is configuration, policy, or some external mechanism, and that this is
not part of the path computation process described later in this not part of the path computation process described later in this
document. document.
In addition, domain level routing may perform "domain re-entry", Domain level routing may also allow "domain re-entry" where a path
where a path enters a domain after the path exits that domain (e.g., re-enters a domain that it has previously exited (e.g., domain#X-
domain#X-domain#Y-domain#X). This requires specific considerations domain#Y-domain#X). This requires specific considerations when
when confidentiality is required (described in Section 3.2), and is confidentiality (described in Section 3.2) is required, and is beyond
beyond the scope of this document. the scope of this document.
Furthermore, the working LSP and the recovery LSP may or may not be Furthermore, the working LSP and the recovery LSP may or may not be
routed along the same set of domains in the same order. In this routed along the same set of domains in the same order. In this
document, we assume that the working LSP and recovery LSP follow the document, we assume that the working LSP and recovery LSP follow the
same set of domains in the same order (via configuration, policy or same set of domains in the same order (via configuration, policy or
some external mechanism). That is, we assume that the domain mesh some external mechanism). That is, we assume that the domain mesh
topology is reduced to a linear domain topology for each pair of topology is reduced to a linear domain topology for each pair of
working and recovery LSPs. working and recovery LSPs.
In summary, In summary,
- There is no assumption about the multi-domain network topology. For - There is no assumption about the multi-domain network topology. For
example, there could be more than two domain boundary nodes or example, there could be more than two domain boundary nodes or
inter-domain links (links connecting a pair of domain boundary inter-domain links (links connecting a pair of domain boundary
nodes belonging to different domains). nodes belonging to different domains).
- However, there is an assumption that under such a network topology,
the set of domains that the working LSP and the recovery LSP follow - It is assumed that in a multi-domain topology, the sequence of
must be the same and pre-configured. domains that the working LSP and the recovery LSP follow must be
the same and is pre-configured.
- Domain re-entry is not considered. - Domain re-entry is not considered.
2.2 Note on Domain Diversity 2.2 Note on Domain Diversity
As described in Section 1.4, domain diversity means the selection of As described in Section 1.4, domain diversity means the selection of
paths that have only the ingress and egress domains in common. This paths that have only the ingress and egress domains in common. This
may provide enhanced resilience against failures, and is a way to may provide enhanced resilience against failures, and is a way to
ensure path diversity for most of the path of the LSP. ensure path diversity for most of the path of the LSP.
In Section 2.1 we assumed that the working LSP and the recovery LSP In Section 2.1 we assumed that the working LSP and the recovery LSP
skipping to change at page 8, line 33 skipping to change at page 9, line 4
ensure path diversity for most of the path of the LSP. ensure path diversity for most of the path of the LSP.
In Section 2.1 we assumed that the working LSP and the recovery LSP In Section 2.1 we assumed that the working LSP and the recovery LSP
follow the same set of domains in the same order. Under this follow the same set of domains in the same order. Under this
assumption, domain diversity cannot be achieved. However, by relaxing assumption, domain diversity cannot be achieved. However, by relaxing
this assumption, domain diversity could be achieved, e.g., by either this assumption, domain diversity could be achieved, e.g., by either
of the following schemes. of the following schemes.
- Consider domain diversity as a special case of SRLG diversity - Consider domain diversity as a special case of SRLG diversity
(i.e., assign an SRLG ID to each domain). (i.e., assign an SRLG ID to each domain).
- Configure domain level routing to provide domain diverse paths - Configure domain level routing to provide domain diverse paths
(e.g., by means of AS_PATH in BGP). (e.g., by means of AS_PATH in BGP).
Details are beyond the scope of this document. Details of the operation of domain diversity are beyond the scope of
this document.
3. Factors to Consider 3. Factors to Consider
3.1 Scalability versus Optimality 3.1 Scalability Versus Optimality
As described in [RFC4726], scalability and optimality are two As described in [RFC4726], scalability and optimality are two
conflicting objectives. Note that the meaning of optimality differs conflicting objectives. Note that the meaning of optimality differs
depending on each network operation. Some examples of optimality in depending on each network operation. Some examples of optimality in
the context of diverse LSPs are: the context of diverse LSPs are:
- Minimizing the sum of their cost while maintaining diversity. - Minimizing the sum of their cost while maintaining diversity.
- Restricting the difference of their cost (so as to minimize delay
difference after switch-over) while maintaining diversity. - Restricting the difference of their costs (for example, so as to
minimize the delay difference after switch-over) while maintaining
diversity.
By restricting TE information distribution to only within each domain By restricting TE information distribution to only within each domain
(and not across domain boundaries) as required by RFC4105 and (and not across domain boundaries) as required by [RFC4105] and
RFC4216, it may not be possible to compute an optimal path. As such, [RFC4216], it may not be possible to compute an optimal path. As
it may not be possible to compute diverse paths, even if they exist. such, it might not be possible to compute diverse paths, even if they
However, if we assume domain level routing is given (as discussed in exist. However, if we assume domain level routing is given (as
Section 2), it is possible to compute diverse paths using specific discussed in Section 2), it is possible to compute diverse paths
computation schemes, if such paths exist. This is discussed in using specific computation schemes, if such paths exist. This is
Section 4. discussed in Section 4.
3.2 Key Concepts 3.2 Key Concepts
Three key concepts to classify various diverse LSP computation and Three key concepts to classify various diverse LSP computation and
setup schemes are presented below. setup schemes are presented below.
o With or without confidentiality o With or without confidentiality
- Without confidentiality - Without confidentiality
Under this network configuration, it is possible to specify (by It is possible to specify a path across multiple domains in
means of the Explicit Route Object - ERO - comprising a list of signaling (by means of the RSVP-TE Explicit Route Object (ERO)),
strict hops) or obtain record of (by means of the Record Route and to obtain record of the inter-domain path used (by means of
Object - RRO) a route across other domains. the RSVP-TE Record Route Object (RRO)). In this case, it is clear
that one domain has control over the path followed in another
domain, and that the path actually used in one domain is visible
from within another domain.
Examples of this configuration are multi-area networks, and some Examples of this configuration are multi-area networks, and some
forms of multi-AS networks (especially within the same provider). forms of multi-AS networks (especially within the same provider).
In these cases, there is no requirement for confidentiality.
- With confidentiality - With confidentiality
Under this network configuration, it is not possible to specify Where confidentiality of domain topology and operational policy
or obtain a full and strict route (by means of ERO/RRO) across is required, it is not possible to specify or obtain a full path
other domains, although paths may be specified/obtained in the across other domains. Partial paths may be specified and reported
form of an ERO/RRO containing loose hops. Therefore, it is not using domain identifiers or the addresses of domain border
possible to specify or obtain a full route at the head-end of a routers in the EROs and RROs.
multi-domain LSP.
Examples of this configuration are some forms of multi-AS Examples of this configuration are some forms of multi-AS
networks (especially inter-provider networks), GMPLS-UNI networks (especially inter-provider networks), GMPLS-UNI
networks, and L1VPNs. networks, and L1VPNs.
o Per domain path computation or inter-domain collaborative path o Multi-domain path computation, per-domain path computation, and
computation inter-domain collaborative path computation
- Per domain path computation - Multi-domain path computation
In this scheme, a path is computed domain by domain as LSP If a single network element can see the topology of all domains
along the path, it is able to compute a full end-to-end path.
Clearly this is only possible where confidentiality is not
required.
Such a network element might be the head-end Label Switching
Router (LSR), a Path Computation Element (PCE) [RFC4655], or a
Network Management System (NMS). This mode of path computation is
discussed in Sections 4 and 5.
- Per-domain path computation
The path of an LSP may be 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 to construct the next segment of
this scheme is covered in [RFC5152]. the path toward the destination. The establishment of unprotected
LSPs in this way 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 and uses communication between cooperating PCEs. 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].
scheme is covered in [brpc].
Note that these are path computation techniques. It is also
possible to obtain a path via management configuration, or head-end
path computation (with multi-domain visibility). This is discussed
in Sections 4 and 5.
Note also that it is possible to combine multiple path computation It is possible to combine multiple path computation techniques
techniques (including using a different technique for the working (including using a different technique for the working and recovery
and recovery LSPs), but details are beyond the scope of this LSPs), but details are beyond the scope of this document.
document.
o Sequential path computation or simultaneous path computation o Sequential path computation or simultaneous path computation
- Sequential path computation - Sequential path computation
The path of the working LSP is computed (without considering the The path of the working LSP is computed without considering the
recovery LSP), and then the path of the recovery LSP is computed. recovery LSP, and then the path of the recovery LSP is computed.
Typically, this scheme is applicable when the recovery LSP is This scheme is applicable when the recovery LSP is added later as
added later as change of the service grade. But this scheme can a change to the service grade, but may also be used when both the
also be applicable when both of the working and recovery LSPs are working and recovery LSPs are established from the start.
established from the start. In this scheme, diverse LSPs may not
be correctly computed (without some form of re-optimization or Using this approach it may not be possible to find diverse paths
recomputation technique) in "trap" topologies. Furthermore, such for the LSPs in "trap" topologies. Furthermore, such sequential
sequential path computation approaches may prevent the selection path computation approaches reduce the likelihood of selecting an
of an "optimal" solution with regards to a specific objective "optimal" solution with regards to a specific objective function.
function.
- Simultaneous path computation - Simultaneous path computation
The path of the working LSP and the path of the recovery LSP are The path of the working LSP and the path of the recovery LSP are
computed simultaneously. Typically, this scheme is applicable computed simultaneously. In this scheme it is possible to avoid
when both the working LSP and the recovery LSP are established trap conditions and it may be more possible to achieve an optimal
together. In this scheme, it is possible to avoid trap result.
topologies. Furthermore it may allow for achieving more optimal
results.
Note that LSP setup with or without confidentiality is given as a Note that LSP setup with or without confidentiality depends on per-
per-domain configuration, while the choices of per-domain path domain configuration. The choice of per-domain path computation or
computation or inter-domain collaborative path computation, and inter-domain collaborative path computation, and the choice between
sequential path computation or simultaneous path computation may be a sequential path computation or simultaneous path computation can be
matter of choice for each individual pair of working/recovery LSPs. determined for each individual pair of working/recovery LSPs.
The analysis of various diverse LSP setup schemes is described in The analysis of various diverse LSP setup schemes is described in
Sections 4 and 5, based on above criteria. Sections 4 and 5, based on the concepts set out above.
Some other considerations, such as network topology-specific Some other considerations, such as network topology-specific
considerations, addressing considerations, and SRLG diversity are considerations, addressing considerations, and SRLG diversity are
described in Sections 6, 7, and 8. described in Sections 6, 7, and 8.
4. Diverse LSP Setup Schemes without Confidentiality 4. Diverse LSP Setup Schemes Without Confidentiality
In the following, various schemes for diverse LSP setup are presented This section examines schemes for diverse LSP setup based on
based on different path computation techniques assuming that there is different path computation techniques assuming that there is no
no requirement for confidentiality between domains. Section 5 makes a requirement for domain confidentiality. Section 5 makes a similar
similar examination of schemes where inter-domain confidentiality is examination of schemes where domain confidentiality is required.
required.
4.1 Management Configuration 4.1 Management Configuration
Section 3.1 of [RFC4726] describes this path computation technique. [RFC4726] describes this path computation technique where the full
The full explicit paths for the working and recovery LSPs are explicit paths for the working and recovery LSPs are specified by a
specified by a management application at the head-end, and no further management application at the head-end, and no further computation or
computation or signaling considerations are needed. signaling considerations are needed.
4.2 Head-end Path Computation (with multi-domain visibility) 4.2 Head-End Path Computation (With Multi-Domain Visibility)
Section 3.2.1 of [RFC4726] describes this path computation technique. Section 3.2.1 [RFC4726] describes this path computation technique.
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
[RFC5152]. [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 paths through the source domain
followed by one of the following: followed by either 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 paths.
- The boundary LSR for the source domain and the LSP destination. - The LSP destination.
Thus, ERO expansion is needed at domain boundaries. Path computation Thus, in order to navigate each domain, the path must be expanded at
is performed by, or by a PCE on behalf of, each domain boundary LSR. each domain boundary, i.e. per-domain. This path computation is
performed by the boundary LSR or by a PCE on its behalf.
For establishing diverse LSPs using per-domain computation, there are There are two schemes for establishing diverse LSPs using per-domain
two specific schemes, which are described in Sections 4.3.1 and 4.3.2 computation. These are described Sections 4.3.1 and 4.3.2.
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 As previously noted, the main issue with sequential path computation
are as follows. It should be noted that the PRIMARY_PATH_ROUTE Object is that diverse paths cannot be guaranteed. Where a per-domain path
defined in [RFC4872] for end-to-end protection is not intended as a computation scheme is applied, the computation of second path needs
path exclusion mechanism. to be aware of the path used by the first path in order that path
diversity can be attempted.
Assume that the working LSP is established as described in [RFC5152]. The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used when the
Also, assume that the route of the working LSP (full route) is second path is signaled to report the details of the first path. It
available at the head-end through the RRO. should be noted that the PRIMARY_PATH_ROUTE Object defined in
[RFC4872] for end-to-end protection is not intended as a path
exclusion mechanism and should not be used for this purpose.
o Path computation aspect The process for sequential path computation is as follows:
When performing path computation (ERO expansion) for the recovery - The working LSP is established using per-domain path computation as
LSP as it crosses each domain boundary a path is selected that described in [RFC5152]. The path of the working LSP is available at
avoids the nodes/links/SRLGs used by the working path so that a the head-end through the RSVP-TE RRO since domain confidentiality
diverse path is obtained. When path computation is performed by a is not required.
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
the PCE Protocol (PCEP) [PCEP].
o Signaling aspect - The path of the recovery LSP across the first domain is computed
excluding the resources used by the working LSP within that domain.
If a PCE is used, the resources to be avoided can be passed to the
PCE using the Exclude Route Object (XRO) extensions to the PCE
Protocol [PCEP-XRO], [PCEP].
In order that the computation noted above can be performed, each - The recovery LSP is now signaled across the first domain as usual,
computation point must be aware of the path of the working LSP. but the path of the working LSP is also conveyed in an RSVP-TE XRO.
This information can be supplied in the XRO included in the Path The XRO lists nodes, links and SRLGs that must be avoided by the
message for recovery LSP. The XRO lists nodes, links and SRLGs that LSP being signaled, and its contents are copied from the RRO of the
must be avoided by the LSP being signaled, and its contents are working LSP.
copied from the RRO of the working LSP.
- At each subsequent domain boundary, a segment of the path of the
recovery LSP can be computed across the new domain excluding the
resources indicated in the RSVP-TE XRO.
This scheme cannot guarantee to establish diverse LSPs (even if they This scheme cannot guarantee to establish diverse LSPs (even if they
could exist) because the first LSP is established without could exist) because the first (working) LSP is established without
consideration of the need for a diverse recovery LSP. Crankback consideration of the need for a diverse recovery LSP. It is possible
[RFC4920] may be used in combination with this scheme in order to modify the path of the working LSP using the crankback techniques
improve the possibility of successful diverse LSP setup. Furthermore, [RFC4920] if the setup of the recovery LSP is blocked or if some
re-optimization of the working LSP and the recovery LSP may be used resources are shared.
to achieve fully diverse paths.
Note that even if a solution is found, the degree of optimality of Note that even if a solution is found, the degree of optimality of
the solution (i.e., of the set of diverse TE LSPs) might not be the solution (i.e., of the set of diverse TE LSPs) might not be
maximal. maximal.
4.3.2 Simultaneous Path Computation 4.3.2 Simultaneous Path Computation
o Path computation aspect Simultaneous path computation gives a better likelihood of finding a
When signaling the working LSP, the path of not only the working pair of diverse paths as the diversity requirement forms part of the
LSP, but also the recovery LSP is computed. For example, in computation process. In per-domain path computation mechanisms there
Figure 1, when node D receives a Path message for the working LSP are several aspects to consider.
between nodes A and L, node D expands the ERO to reach domain#3. At
the same time, node D computes a path for the recovery LSP across
the same domain from node F to reach domain#3. The entry boundary
node for the recovery LSP (node F) needs to be known by the entry
boundary node for the working LSP (node D). In this example the
path for the working LSP may be computed by node D as D-E-domain#3,
and the path for recovery LSP as F-G-domain#3.
o Signaling aspect
Two signaling features are needed in order to make this scheme
work.
- A mechanism is needed to signal, during working LSP setup, the
entry boundary node to be used by the recovery LSP. This
mechanism may grow in complexity as the length of the chain of
domains grows, and as the interconnectivity of the domains
becomes more complex. But it may be perfectly feasible in simpler
topologies.
- There must be a mechanism to force the recovery LSP to follow the Simultaneous path computation means that the paths of the working and
route computed above. One way to realize this is to have a recovery LSPs are computed at the same time. Since we are considering
specific object (with the same format as the ERO) to collect the per-domain path computation, these two paths must be computed at the
route of the recovery LSP in the Path message for the working LSP boundary of each domain.
and to return is to the head-end in the Resv message. When
signaling the recovery LSP, the content of the ERO is copied from
this object.
Protocol mechanisms to achieve these signaling features are not The process for simultaneous path computation is as follows:
currently available. The definition of protocol extensions is
beyond the scope of this document.
This scheme also cannot guarantee to establish diverse LSPs (even if - The ingress LSR (or a PCE) computes a pair of diverse paths across
they could exist) if there are more than two domain boundary nodes the first domain. If a PCE is used, PCEP offers the ability to
out of each domain. Crankback [RFC4920] may also be used in request disjoint paths.
combination with this scheme to improve the chances of success.
Note that even if a solution is found, the degree of optimality of - The working LSP is signaled across the first domain as usual, but
the solution (i.e., of the set of diverse TE LSPs) might not be must carry with it the requirement for a disjoint recovery LSP and
maximal. the information about the path already computed for the recovery
LSP across the first domain. In particular, the domain boundary
node used by the recovery LSP must be reported.
4.4 Inter-domain Collaborative Path Computation - Each domain boundary router in turn computes a pair of disjoint
paths across the next domain. The working LSP is signaled as usual
and the computed path of the recovery LSP is collected in the
signaling messages.
Section 3.4 of [RFC4726] describes this approach, and [brpc] provides - When the working LSP has been set up, the full path of the recovery
detail of Backward Recursive Path Computation which is a LSP is returned to the head-end LSR in the signaling messages for
collaborative path computation technique. Path computation is the working LSP. This allows the head-end LSR to signal the
performed for each of the working and recovery LSPs by the use of recovery LSP using a full path without the need for further path
inter-PCE communication before each LSP is signaled. computation.
There are two specific schemes for establishing diverse LSPs using Note that the signaling protocol mechanisms do not currently exist to
this scheme, which are described in Sections 4.4.1 and 4.4.2. collect the path of the recovery LSP during the signaling of the
working LSP. Definition of protocol mechanisms are beyond the scope
of this document, but it is believed that such mechanisms would be
simple to define and implement.
4.4.1 Sequential Path Computation Note also that the mechanism described is still not able to guarantee
the selection of diverse paths even where they exist since, when
domains are multiply interconnected, the determination of diverse
end-to-end paths may depend on the correct selection of inter-domain
links. Crankback [RFC4920] may also be used in combination with this
scheme to improve the chances of success.
Route exclusion using the XRO [PCEP-XRO] can be requested in PCEP Note that even if a solution is found, the degree of optimality of
[PCEP], and this can be used to compute the path of a recovery LSP the solution (i.e., set of diverse TE LSPs) might not be maximal.
after the path of the working LSP has been determined. Details are as
follows.
The working LSP is computed using a collaborative PCE approach such 4.4 Inter-Domain Collaborative Path Computation
as that described in [brpc], and the LSP may be immediately
established. Assume that the path of the working LSP (full route) is
available from the computation request or from the RRO.
o Path computation aspect Collaborative path computation requires the cooperation between PCEs
that are responsible for different domains. This approach is
described in Section 3.4 of [RFC4726]. Backward recursive path
computation (BRPC) [BRPC] provides a collaborative path computation
technique where the paths of LSPs are fully determined by
communication between PCEs before the LSPs are established. Two ways
to use BRPC for diverse LSPs are described in the following sections.
When requesting path computation for the recovery LSP, an XRO is 4.4.1 Sequential Path Computation
included in the PCEP path computation request message (see
[PCEP-XRO]). The content of the XRO is copied from the RRO of the
working LSP. Alternatively, the content of the XRO is copied from
the ERO of the path computation reply for the working LSP. The
latter case is useful when the working LSP is not established at
the time of the path computation request for the recovery LSP. The
computation request specifies that the full route must be returned.
Per-domain PCEs may need to be invoked by the first PCE that is
consulted in order to collaboratively determine the correct path
for the recovery LSP (just as described in [RFC4655] and [RFC4726]
for the computation of a single inter-domain LSP by collaborating
PCEs), and these PCEs exchange the XRO information to ensure that
the computed path is diverse from the working LSP.
o Signaling aspect In sequential path computation, the path of the working LSP is
computed using BRPC as described in [BRPC]. The path of the recovery
LSP is then computed also using BRPC with the addition that the path
of the working LSP is explicitly excluded using the XRO route
exclusion techniques described in [PCEP-XRO].
The recovery LSP is signaled by including an ERO whose content is In this case, the working LSP could be set up before or after the
copied from the result returned by the PCE. path of the recovery LSP is computed. In the latter case the actual
path of the working LSP as reported in the RSVP-TE RRO should be used
when computing the path of the recovery LSP.
This scheme cannot guarantee to establish diverse LSPs (even if they This scheme cannot guarantee to establish diverse LSPs (even if they
exist) because the working LSP may block the recovery LSP. In such a exist) because the working LSP may block the recovery LSP. In such a
scenario, re-optimization of the working and recovery LSPs may be scenario, re-optimization of the working and recovery LSPs may be
used to achieve fully diverse paths. used to achieve fully diverse paths.
4.4.2 Simultaneous Path Computation 4.4.2 Simultaneous Path Computation
o Path computation aspect In simultaneous path computation, the PCEs collaborate to compute the
The PCEP SVEC Object [PCEP] allows diverse path computation to be paths of both the working and the recovery LSPs at the same time.
requested. It would be possible to extend BRPC [brpc] to compute Since both LSPs are computed in a single pass, the LSPs can be
diverse paths through the definition of a specific process. Such signaled simultaneously of sequentially according to the preference
extensions are beyond the scope of this document. of the head-end LSR.
o Signaling aspect
In this scheme the PCE returns the full routes for the working and
recovery LSPs and they are signaled accordingly.
This scheme can guarantee to establish diverse LSPs (if they exist), Collaborative simultaneous path computation is achieved using the
assuming domain level routing is given as described in Section 2. Synchronization Vector (SVEC) object in the PCE Protocol [PCEP]. This
object allows two computation requests to be associated and made
dependent. The coordination of multiple computation requests within
the BRPC mechanism is not described in [BRPC]. It is believed that it
is possible to specify procedures for such coordination, but the
development of new procedures is outside the scope of this document.
Furthermore, the computed set of TE LSPs can be guaranteed to be This scheme can guarantee to establish diverse LSPs where they are
optimal with respect to some objective functions. possible, assuming that domain level routing is pre-determined as
described in Section 2. Furthermore, the computed set of TE LSPs can
be guaranteed to be optimal with respect to some objective functions.
5. Diverse LSP Setup Schemes with Confidentiality 5. Diverse LSP Setup Schemes with Confidentiality
In the context of this section, the term confidentiality applies to In the context of this section, the term confidentiality applies to
the protection of information about the topology and resources the protection of information about the topology and resources
present within one domain from visibility by people or applications present within one domain from visibility by people or applications
outside that domain. This includes, but is not limited to, recording outside that domain. This includes, but is not limited to, recording
of LSP routes, in addition to advertisements of TE information. The of LSP routes, and the advertisements of TE information. The
confidentiality does not apply to the protection of user traffic. confidentiality does not apply to the protection of user traffic.
Diverse LSP setup schemes with confidentiality are similar to ones Diverse LSP setup schemes with confidentiality are similar to ones
without confidentiality. However, several additional mechanisms are without confidentiality. However, several additional mechanisms are
needed to preserve confidentiality. Examples of such mechanisms are: needed to preserve confidentiality. Examples of such mechanisms are:
- Path key: Provide each per-domain segment of the path in advance to - Path key: A path key is used in place of a segment of the path of
the domain boundary nodes or to the PCE that computed the path for an LSP when the LSP is signaled, when the path of the LSP is
a limited period of time (temporary caching) and identify it in the reported by signaling, or when the LSP's path is generated by a
signaled ERO using a path key. When path computation is done by PCE. This allows the exact path of the LSP to remain confidential
PCE, the identify of the PCE containing state for the path may be through the substitution of "confidential path segments" (CPSs) by
required as well (e.g., PCE I-D). The path key is provided by the these path keys.
PCE to the head-end for inclusion in the ERO [conf-segment].
- LSP segment: Pre-establish each per-domain segments of the path [PCE-PATH-KEY] describes how path keys can be used by PCEs to
using hierarchical LSPs [RFC4206] or LSP stitching segments preserve path confidentiality, and [RSVP-PATH-KEY] explains how
[RFC5150] and signal the end-to-end LSP to use these per-domain path keys are used in signaling. Note that if path keys are
LSPs. This scheme might need additional identifiers (such as LSP signaled in RSVP-TE EROs they must be expanded so that the
IDs) in the Path message so that the domain boundary node can signaling can proceed. This expansion normally takes place when the
identify which LSP segment or tunnel to use for the end-to-end LSP. first node in the CPS is reached. The expansion of the path key
Furthermore, this scheme may require additional communication to would normally be carried out by the PCE that generated the key,
pre-establish the LSP segments. and for that reason, the path key contains an identifier of the PCE
(the PCE-ID).
These techniques may be directly applied, or may be applied with - LSP segment: LSP segments can be pre-established across domains
extensions, depending on specific diverse LSP setup schemes described according to some management policy. The LSP segments can be used
below. to support end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP
stitching segments [RFC5150].
Note that in the schemes below, the paths of the working and recovery The end-to-end LSPs are signaled indicating just the series of
LSPs are not impacted by the confidentiality requirements. domains or domain border routers. Upon entry to each domain an
existing trans-domain LSP is selected and used to carry the end-to-
end LSP across the domain.
5.1 Management Configuration Note that although the LSP segments are described as being pre-
established, they could be set up on demand on receipt of the
request for the end-to-end LSP at the domain border.
It is not possible to obtain or specify the full explicit route for It is also worth noting that in schemes that result in a single
either LSP at the head-end due to confidentiality restrictions. contiguous end-to-end LSP (without LSP tunneling or stitching) the
Therefore, this information cannot be provided to signaling for LSP same concept of LSP segments may apply provided that ERO expansion
setup. is applied at domain boundaries and that the path of the LSP is not
reported in the RSVP-TE RRO.
Confidentiality does not prevent the full computation of inter-domain These techniques may be applied directly or may require protocol
paths and signaling of sufficient information to distinguish the extensions depending on the specific diverse LSP setup schemes
paths. However the path information for each domain must be provided described below. Note that in the schemes below, the paths of the
in a way that does not have meaning to other domains. Example working and recovery LSPs are not impacted by the confidentiality
mechanisms to preserve confidentiality as described above, include: requirements.
- Path key 5.1 Management Configuration
- LSP segment
5.2 Head-end Path Computation (with multi-domain visibility) Although management systems may exist that can determine end-to-end
paths even in the presence of domain confidentiality, the full paths
cannot be provided to the head-end LSR for LSP signaling as this
would break the confidentiality requirements.
This scheme is not applicable since multi-domain visibility violates Thus, for LSPs that are configured through management applications,
confidentiality. the end-to-end path must either be constructed using LSP segments
that cross the domains, or communicated to the head-end LSR with the
use of path keys.
5.2 Head-End Path Computation (With Multi-Domain Visibility)
It is not possible for the head-end LSR to compute the full end-to-
end path of an inter-domain LSP when domain confidentiality is in use
because the LSR will not have any TE information about the other
domains.
5.3 Per-Domain Path Computation 5.3 Per-Domain Path Computation
Per-domain path computation for working and recovery LSPs is
practical with domain confidentiality. As when there are no
confidentiality restrictions, we can separate the cases of sequential
and simultaneous path computation.
5.3.1 Sequential Path Computation 5.3.1 Sequential Path Computation
Assume the working LSP is established as described in [RFC5152]. In sequential path computation, we can assume that the working LSP
has its path computed and is set up using the normal per-domain
technique as described in [RFC5152]. However, because of
confidentiality issues, the full path of the working LSP is not
returned in the signaling messages and is not available to the head-
end LSR.
It is not possible to obtain the route of the working LSP from the To compute a disjoint path for the recovery LSP, each domain border
RRO at the head-end due to confidentiality restrictions. In order to node needs to know the path of the working LSP within the domain that
provide the path of the working LSP through each domain to the it provides entry to. This is easy for the ingress LSR as it has
computation point responsible for computing the path of the access to the RSVP-TE RRO within first domain. In subsequent domains,
protection LSP through each domain additional mechanisms are needed. the process requires that the path of the working LSP is somehow made
Examples of such mechanisms are: available to the domain border router as the recovery LSP is
signaled. Note that the working and recovery LSPs do not use the same
border routers if the LSPs are node or SRLG diverse.
- Information identifying the working LSP is included in the Path There are several possible mechanisms to achieve this.
message for the recovery LSP, and the domain boundary node consults
the entity which computed the path of the working LSP (i.e., domain
boundary node or PCE), so that the diverse path can be computed.
When the entity which computed the path of the working LSP is the
PCE, PCE needs to be temporarily stateful. An example of such
information is the Association Object [RFC4872].
5.3.2 Simultaneous Path Computation - Path keys could be used in the RRO for the working LSP. As the
signaling messages are propagated back towards the head-end LSR,
each domain border router substitutes a path key for the segment of
the working LSP's path within its domain. Thus, the RRO received at
the head-end LSR consists of the path within the initial domain
followed by a series of path keys.
In this scheme the intention is to compute the path of the recovery When the recovery LSP is signaled, the path keys can be included in
LSP at the same time as the working LSP. In order to force the the ERO as exclusions. Each domain border router in turn can
recovery LSP to follow the computed path as well as to preserve expand the path key for its domain and know which resources must be
confidentiality, additional mechanisms are needed to communicate the avoided. PCEP provides a protocol that can be used to request the
computed recovery path from the path of the working LSP (where it was expansion of the path key from the domain border router used by the
computed) to the recovery LSP. Examples of such mechanisms, that must working LSP, or from some third party such as a PCE.
continue to preserve confidentiality, are as follows.
- LSP segment: As described before. The LSP segment for the recovery - Instead of using path keys, each confidential path segment in the
LSP is established domain-by-domain as the working LSP setup RRO of the working LSP could be encrypted by the domain border
progresses. How to initiate such LSP segments for the recovery LSP routers. These encrypted segments would appear as exclusions in the
is beyond the scope of this document. ERO for the recovery LSP and could be decrypted by the domain
border routers.
- Alternatively, information identifying the working LSP is included No mechanism currently exists in RSVP-TE for this function which
in the Path message for the recovery LSP, and the domain boundary would probably assume a domain-wide encryption key.
node consults the entity which computed the path of the recovery
LSP (i.e., domain boundary node or PCE), so as to obtain the path
of the recovery LSP. This requires that the entity which computed
the path of the recovery LSP is temporarily stateful. An example of
such information is the Association Object [RFC4872]. Detailed
protocol specifications are beyond the scope of this document.
5.4 Inter-domain Collaborative Path Computation - The identity of the working LSP could be included in the XRO of the
recovery LSP to indicate that a disjoint path must be found.
5.4.1 Sequential Path Computation This option could require a simple extension to the current XRO
specification [RFC4874] to allow LSP identifiers to be included. It
could also use the Association Object [RFC4872] to identify the
working LSP.
Route exclusion using the XRO [PCEP-XRO] in combination with the path This scheme would also need a way for a domain border router to
key [conf-segment] can be requested in PCEP [PCEP] and this can be find the path of an LSP within its domain. An efficient way to
used to compute the path of a recovery LSP after the path of the achieve this would be to also include the domain border router used
working LSP has been determined. Details are as follows. by the working LSP in the signaling for the recovery LSP, but other
schemes based on management applications or stateful PCEs might
also be developed.
The working LSP is computed as described in [brpc] with the help of Clearly, the details of this alternative have not been specified.
path key [conf-segment], and may be immediately established. It is
not possible to obtain the RRO of the working LSP (full route) at the
head-end due to confidentiality restrictions.
o Path computation aspect 5.3.2 Simultaneous Path Computation
This is similar to the case without confidentiality (Section In per-domain simultaneous path computation the path of the recovery
4.4.1), but in order to preserve confidentiality, additional LSP is computed at the same time as the working LSP (i.e., as the
mechanisms are needed. working LSP is signaled). The computed path of the recovery LSP is
propagated to the head-end LSR as part of the signaling process for
the working LSP, but confidentiality must be maintained, so the full
path cannot be returned. There are two options as follows.
In the PCEP path computation request for the recovery LSP, an XRO - LSP segment: As the signaling of the working LSP progresses and the
is included. The content of the XRO is copied from the ERO of the path of the recovery LSP is computed domain-by-domain, trans-domain
path computation reply for the working LSP, which is given in the LSPs can be set up for use by the recovery LSP. When the recovery
form of strict hops for the local domain, domain boundaries or LSP is signaled, it will pick up these LSP segments and use them
domain identifiers, and path keys. When a PCE receives XRO for tunneling or stitching.
containing one or more path keys, it needs to retrieve the original
content and perform path computation for the recovery LSP excluding
certain nodes/links/SRLGs. It is likely that the content (i.e.,
expansion) of the path key cannot be directly retrieved by a PCE in
one domain from a PCE in another domain since that act would
violate the intended confidentiality. Thus, path key expansion and
the computation of a path across a domain must both be performed
within that domain.
o Signaling aspect This mechanism needs coordination through the management plane
between domain border routers so that a router on the working path
can request the establishment of an LSP segment for use by the
protection path. This could be achieved through the TE MIB modules
[RFC3812], [RFC4802].
The full route for the recovery LSP can not be returned to the Furthermore, when the recovery LSP is signaled it needs to be sure
head-end by PCE because it cannot be collected from the other PCEs to pick up the correct LSP segment. Therefore some form of LSP
owing to confidentiality restrictions. In order to force the segment identifier needs to be reported in the signaling of the
recovery LSP to follow the path computed above, additional working LSP and propagated in the signaling of the recovery LSP.
mechanisms are needed. Examples of such mechanisms are as described Mechanisms for this do not currently exist, but would be relatively
before: simple to construct.
- Path key Alternatively, the LSP segments could be marked as providing
- LSP segment protection for the working LSP. In this case the recovery LSP can
be signaled with the identifier of the working LSP using the
Association Object [RFC4872] enabling the correct LSP segments to
be selected.
- Path key: The path of the recovery LSP can be determined and
returned to the head-end LSR just described in Section 4.4.2, but
each CPS is replaced by a path key. As the recovery path is
signaled each path key is expanded, domain-by-domain to achieve the
correct path. This requires that the entity that computes the path
of the recovery LSP (domain border LSR or PCE) is stateful.
5.4 Inter-Domain Collaborative Path Computation
Cooperative collaboration between PCEs is also applicable when domain
confidentiality is required.
5.4.1 Sequential Path Computation
In sequential cooperative path computation the path of the working
LSP is determined first using a mechanism such as BRPC. Since domain
confidentiality is in use, the path returned may contain path keys.
When the path of the recovery LSP is computed (which may be before or
after the working LSP is signaled) the path exclusions supplied to
the PCE and exchanged between PCEs must use path keys as described in
[PCEP-XRO].
5.4.2 Simultaneous Path Computation 5.4.2 Simultaneous Path Computation
As described in Section 4.4.2, diverse path computation can be As described in Section 4.4.2, diverse path computation can be
requested by PCEP SVEC Object [PCEP], and [brpc] can be extended for requested using the PCEP SVEC Object [PCEP], and BRPC could be
inter-domain diverse path computation. However, it is not possible extended for inter-domain diverse path computation. However, to
for PCE to return the full route of the working LSP and recovery LSP conform to domain confidentiality requirements, path keys must be
to the head-end due to confidentiality. In order to force the working used in the paths returned by the PCEs and signaled by RSVP-TE.
and recovery LSPs to follow the paths computed, additional mechanisms
are needed. Examples of such mechanisms are as described before:
- Path key: Use this for the working and recovery LSPs.
Note that the LSP segment approach in Section 5 may not be applicable Note that the LSP segment approach may not be applicable here because
here because a path cannot be determined until BRPC procedures are a path cannot be determined until BRPC procedures are completed.
completed.
6. Network Topology Specific Considerations 6. Network Topology Specific Considerations
In some specific network topologies, diverse LSP setup schemes In some specific network topologies the schemes for setting up
mentioned above could be drastically simplified. diverse LSPs could be significantly simplified.
For example, assume there are only three domains connected linearly, For example, consider the L1VPN or GMPLS UNI case. This may be viewed
and the first and the last domain contain only a single node. Assume as a linear sequence of three domains where the first and last
that we need to establish diverse LSPs from the node in the first domains contain only a single node each. In such a scenario, no BRPC
domain to the node in the last domain. In such a scenario, no BRPC
procedures are needed, because there is no need for path computation procedures are needed, because there is no need for path computation
in the first and last domains. in the first and last domains even if the source and destination
nodes are multi-homed.
7. Addressing Considerations 7. Addressing Considerations
All of the above-mentioned schemes are applicable when a single All of the schemes described in this document are applicable when a
address space is used across all domains. single address space is used across all domains.
However, there could be cases where private addresses are used within There may also be cases where private address spaces are used within
some of the domains. This case is similar to the one with some of the domains. This problem is similar to the use of domain
confidentiality, since the ERO and RRO are meaningless even if they confidentiality since the ERO and RRO are meaningless outside a
are available. This document does not exclude other schemes, but domain even if they are available, and the problem can be solved
details are beyond the scope of this document. using the same techniques.
8. Note on SRLG Diversity 8. Note on SRLG Diversity
The above-mentioned schemes are applicable when the nodes and links The schemes described in this document are applicable when the nodes
in different domains belong to different SRLGs. and links in different domains belong to different SRLGs which is
normally the case.
However, there could be cases where the nodes and links in different However, it is possible that nodes or links in different domains
domains belong to the same SRLG. That is, where SRLGs span domain belong to the same SRLG. That is, an SRLG may span domain boundaries.
boundaries. In such cases, in order to establish SRLG diverse LSPs, In such cases, in order to establish SRLG diverse LSPs, several
several considerations are needed, such as: considerations are needed:
- 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.
In this case, there is tension between any requirement for domain
confidentiality and the requirement for SRLG diversity. One of them
must be compromised.
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. IANA Considerations 9. IANA Considerations
This informational document makes no requests for IANA action. This informational document makes no requests for IANA action.
10. Security Considerations 10. Security Considerations
This document does not require additional security considerations The core protocols used to achieve the procedures described in this
mentioned in [RFC4726], which is the basis of this document. That is, document are RSVP-TE and PCEP. These protocols include policy and
LSP path computation and setup across domain boundaries is authentication capabilities as described in [RFC3209] and [PCEP].
necessarily a security concern and will be subject to operational Furthermore, these protocols may be operated using more advanced
policies. In particular, the trust model across domain boundaries for security features such as IPsec [RFC4301] and TLS [RFC4346].
computation and signaling must be carefully considered since LSP
setup (whether successful or not) can consume domain network data
resources (bandwidth), and signaling or computation requests can
consume network processing resources (CPU and control channel
bandwidth).
RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication Security may be regarded as particularly important in inter-domain
capabilities, and these should be seriously considered in all inter- deployments and serious consideration should be given to applying
domain deployments. the available security techniques as described in the documents
referenced above and as set out in [RFC4726].
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].
This document does not of itself require additional security measures
and does not modify the trust model implicit in the protocols used.
Note, however, that domain confidentiality (that is the
confidentiality of the topology and path information from within any
one domain) is an important consideration in this document, and a
significant number of the mechanisms described in this document are
designed to preserve domain confidentiality.
11. References 11. References
11.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
Extensions to RSVP for LSP Tunnels", RFC 3209, to RSVP for LSP Tunnels", RFC 3209, December 2001.
December 2001.
[RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., [RFC4216] Zhang, R., and Vasseur, JP., "MPLS Inter-Autonomous
"Recovery (Protection and Restoration) System (AS) Traffic Engineering (TE) Requirements",
Terminology for Generalized Multi-Protocol Label RFC 4216, November 2005
Switching (GMPLS)", RFC 4427, March 2006. [RFC4427] Mannie, E., Ed. and D. Papadimitriou, Ed., "Recovery
(Protection and Restoration) Terminology for
Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4427, March 2006.
[RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
Framework for Inter-Domain MPLS Traffic Framework for Inter-Domain MPLS Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, November 2006.
11.2 Informative References 11.2 Informative References
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T.,
Reroute Extensions to RSVP-TE for LSP Tunnels", "Multiprotocol Label Switching (MPLS) Traffic
RFC 4090, May 2005. Engineering (TE) Management Information Base (MIB)",
June 2004.
[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, [RFC4105] Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle,
"Requirements for Inter-Area MPLS Traffic "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005. Engineering", RFC 4105, June 2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths
Paths (LSP) Hierarchy with Generalized Multi- (LSP) Hierarchy with Generalized Multi-Protocol
Protocol Label Switching (GMPLS) Traffic Label Switching (GMPLS) Traffic Engineering (TE)",
Engineering (TE)", RFC 4206, October 2005. 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
Switching (GMPLS) User-Network Interface (UNI): (GMPLS) User-Network Interface (UNI): Resource
Resource ReserVation Protocol-Traffic Engineering ReserVation Protocol-Traffic Engineering (RSVP-TE)
(RSVP-TE) Support for the Overlay Model", Support for the Overlay Model", RFC 4208, October
RFC 4208, October 2005. 2005.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter- [RFC4301] Kent, S., Seo, K., "Security Architecture for the
Autonomous System (AS) Traffic Engineering (TE) Internet Protocol," December 2005.
Requirements", RFC 4216, November 2005
[RFC4346] Dierks, T., and Rescorla, E., "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346,
[RFC4428] D. Papadimitriou, Ed., "Analysis of Generalized
Multi-Protocol Label Switching (GMPLS)-based
Recovery Mechanisms (including Protection and
Restoration)", RFC 4428, March 2006.
[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,
RFC 4655, August 2006. August 2006.
[RFC4847] Takeda, T., Ed., "Framework and Requirements for [RFC4802] Nadeau, T., and Farrel, A., "Generalized
Layer 1 Virtual Private Networks", RFC 4847, Multiprotocol Label Switching (GMPLS) Traffic
April 2007. Engineering Management Information Base", February
2007.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. [RFC4847] Takeda, T., Ed., "Framework and Requirements for
(Eds.), "RSVP-TE Extensions in support of End-to- Layer 1 Virtual Private Networks", RFC 4847, April
End Generalized Multi-Protocol Label Switching 2007.
(GMPLS)-based Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.),
A. Farrel, "GMPLS Based Segment Recovery", "RSVP-TE Extensions in support of End-to-End
RFC 4873, May 2007. Generalized Multi-Protocol Label Switching (GMPLS)-
based Recovery", RFC 4872, May 2007.
[RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A.
"Exclude Routes - Extension to Resource Farrel, "GMPLS Based Segment Recovery", RFC 4873,
ReserVation Protocol-Traffic Engineering May 2007.
(RSVP-TE)", RFC 4874, April 2007.
[RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., "Exclude
for MPLS and GMPLS RSVP-TE ", RFC 4920, July Routes - Extension to Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE)", RFC 4874, April
2007. 2007.
[RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for
"Label Switched Path Stitching with Generalized MPLS and GMPLS RSVP-TE ", RFC 4920, July 2007.
[RFC5150] Ayyangar, A., Kompella, K., and JP. Vasseur, "Label
Switched Path Stitching with Generalized
Multiprotocol Label Switching Traffic Engineering Multiprotocol Label Switching Traffic Engineering
(GMPLS TE)", RFC 5150, February 2008. (GMPLS TE)", RFC 5150, February 2008.
[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, [RFC5151] Farrel, A., Ed., "Inter-Domain MPLS and GMPLS
"Inter-Domain MPLS and GMPLS Traffic Engineering Traffic Engineering -- Resource Reservation
-- Resource Reservation Protocol-Traffic Protocol-Traffic Engineering (RSVP-TE) Extensions",
Engineering (RSVP-TE) Extensions", RFC 5151, RFC 5151, February 2008.
February 2008.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and Zhang, R.,
Zhang, "A Per-Domain Path Computation Method for "A Per-Domain Path Computation Method for
Establishing Inter-Domain Traffic Engineering Establishing Inter-Domain Traffic Engineering (TE)
(TE) Label Switched Paths (LSPs)", RFC 5152, Label Switched Paths (LSPs)", RFC 5152, February
February 2008. 2008.
[brpc] Vasseur, JP., Ed., "A Backward Recursive [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based
PCE-based Computation (BRPC) procedure to compute Computation (BRPC) procedure to compute shortest
shortest inter-domain Traffic Engineering Label inter-domain Traffic Engineering Label Switched
Switched Paths", draft-ietf-pce-brpc, work in Paths", draft-ietf-pce-brpc, work in progress.
progress.
[conf-segment] Bradford, R., Ed., "Preserving Topology [PCE-PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A,
Confidentiality in Inter-Domain Path Computation "Preserving Topology Confidentiality in Inter-Domain
using a key based mechanism ", draft-ietf-pce- Path Computation Using a Key Based Mechanism",
path-key, work in progress. draft-ietf-pce-path-key, work in progress.
[PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path
Computation Element (PCE) communication Protocol Computation Element (PCE) communication Protocol
(PCEP)", draft-ietf-pce-pcep, work in progress. (PCEP)", draft-ietf-pce-pcep, work in progress.
[PCEP-XRO] Oki, E., and A. Farrel, "Extensions to the Path [PCEP-XRO] Oki, E. and A. Farrel, "Extensions to the Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
for Route Exclusions", draft-ietf-pce-pcep-xro, for Route Exclusions", draft-ietf-pce-pcep-xro, work
work in progress. in progress.
[security-fw] Fang, L., " Security Framework for MPLS and GMPLS [RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A., "RSVP
Networks", draft-ietf-mpls-mpls-gmpls-security- Extensions for Path Key Support", draft-ietf-ccamp-
path-key-ero, work in progress.
[SECURITY-FW] Fang, L., " Security Framework for MPLS and GMPLS
Networks", draft-ietf-mpls-mpls-and-gmpls-security-
framework, work in progress. framework, work in progress.
12. Acknowledgments 12. Acknowledgments
Authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro The 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. Deborah Brungard provided useful advice about the text.
13. 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
 End of changes. 164 change blocks. 
573 lines changed or deleted 662 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/