draft-ietf-ccamp-inter-domain-recovery-analysis-00.txt   draft-ietf-ccamp-inter-domain-recovery-analysis-01.txt 
Network Working Group Tomonori Takeda Network Working Group Tomonori Takeda, Ed.
Internet Draft NTT Internet Draft NTT
Proposed Status: Informational Yuichi Ikejiri Intended Status: Informational Yuichi Ikejiri
Expires: June 2007 NTT Communications Expires: January 2008 NTT Communications
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
December 2006
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-00.txt draft-ietf-ccamp-inter-domain-recovery-analysis-01.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. Terminology....................................................2 1. Introduction...................................................2
2. Introduction...................................................3 1.1 Terminology...................................................3
2.1 Domain........................................................3 1.2 Domain........................................................4
2.2 Document Scope................................................4 1.3 Document Scope................................................4
2.3 Note on Other Recovery Techniques.............................5 1.4 Note on Other Recovery Techniques.............................5
2.4 Signaling Options.............................................5 1.5 Signaling Options.............................................5
3. Diversity in Multi-domain Networks.............................5 2. Diversity in Multi-domain Networks.............................5
3.1 Multi-domain Network Topology.................................6 2.1 Multi-domain Network Topology.................................6
3.2 Note on Domain Diversity......................................7 2.2 Note on Domain Diversity......................................7
4. Factors to Consider............................................7 3. Factors to Consider............................................8
4.1 Scalability versus Optimality.................................7 3.1 Scalability versus Optimality.................................8
4.2 Key Concepts..................................................8 3.2 Key Concepts..................................................8
5. Diverse LSP Setup Schemes without Confidentiality.............10 4. Diverse LSP Setup Schemes without Confidentiality.............10
5.1 Management Configuration.....................................10 4.1 Management Configuration.....................................10
5.2 Head-end Path Computation (with multi-domain visibility).....10 4.2 Head-end Path Computation (with multi-domain visibility).....10
5.3 Per-domain Path Computation..................................10 4.3 Per-domain Path Computation..................................10
5.3.1 Sequential Path Computation................................11 4.3.1 Sequential Path Computation................................11
5.3.2 Simultaneous Path Computation..............................11 4.3.2 Simultaneous Path Computation..............................12
5.4 Inter-domain Collaborative Path Computation..................12 4.4 Inter-domain Collaborative Path Computation..................13
5.4.1 Sequential Path Computation................................12 4.4.1 Sequential Path Computation................................13
5.4.2 Simultaneous Path Computation..............................13 4.4.2 Simultaneous Path Computation..............................14
6. Diverse LSP Setup Schemes with Confidentiality................13 5. Diverse LSP Setup Schemes with Confidentiality................14
6.1 Management Configuration.....................................14 5.1 Management Configuration.....................................15
6.2 Head-end Path Computation (with multi-domain visibility).....14 5.2 Head-end Path Computation (with multi-domain visibility).....15
6.3 Per-Domain Path Computation..................................15 5.3 Per-Domain Path Computation..................................15
6.3.1 Sequential Path Computation................................15 5.3.1 Sequential Path Computation................................15
6.3.2 Simultaneous Path Computation..............................15 5.3.2 Simultaneous Path Computation..............................16
6.4 Inter-domain Collaborate Path Computation....................16 5.4 Inter-domain Collaborate Path Computation....................16
6.4.1 Sequential Path Computation................................16 5.4.1 Sequential Path Computation................................16
6.4.2 Simultaneous Path Computation..............................16 5.4.2 Simultaneous Path Computation..............................17
7. Network Topology Specific Considerations......................17 6. Network Topology Specific Considerations......................18
8. Addressing Considerations.....................................17 7. Addressing Considerations.....................................18
9. Note on SRLG Diversity........................................17 8. Note on SRLG Diversity........................................18
10. Manageability Considerations.................................17 9. Security Considerations.......................................18
11. Security Considerations......................................18 10. References...................................................19
12. References...................................................18 10.1 Normative References........................................19
12.1 Normative References........................................18 10.2 Informative References......................................19
12.2 Informative References......................................18 11. Acknowledgments..............................................21
13. Acknowledgments..............................................20 12. Authors' Addresses...........................................21
14. Author's Addresses...........................................20 Intellectual Property Consideration..............................22
15. Intellectual Property Consideration..........................20 Full Copyright Statement.........................................22
16. Full Copyright Statement.....................................21
1. Terminology 1. Introduction
The reader is assumed to be familiar with the terminology in [inter-
domain-fw] that provides a framework for inter-domain Label Switched This document analyzes various schemes to realize Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
(LSP) recovery in multi-domain networks based on the existing
framework for multi-domain LSPs.
The main focus for this document is on establishing end-to-end
diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
presents various diverse LSP setup schemes based on existing
functional elements.
1.1 Terminology
The reader is assumed to be familiar with the terminology in
[RFC4726] that provides a framework for inter-domain Label Switched
Path (LSP) setup, and [RFC4427] that provides terminology for LSP Path (LSP) setup, and [RFC4427] that provides terminology for LSP
recovery. recovery.
The following are several key terminologies used within this The following are several key terminologies used within this
document. document.
- Domain: See [inter-domain-fw]. 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. domains continue to be out of scope.
- 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 transport user traffic even when the working LSP is transporting
normal user traffic (e.g., 1+1 protection). In such a scenario, normal user traffic (e.g., 1+1 protection). In such a scenario,
the recovery LSP is sometimes referred to as a protecting LSP. the recovery LSP is sometimes referred to as a protecting LSP.
- Diversity: See [inter-domain-fw]. 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)).
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. Those two diverse LSPs are
referred to as the working LSP and recovery LSP hereafter. referred to as the working LSP and recovery LSP hereafter.
Sometimes, diversity is referred to as disjointness. Sometimes, diversity is referred to as disjointness.
- Confidentiality: See [RFC4216]. The term confidentiality applies - Confidentiality: See [RFC4216]. The term confidentiality applies
to the protection of information about the topology and resources to the protection of information about the topology and resources
present within one domain from visibility by people or present within one domain from visibility by people or
applications outside that domain. applications outside that domain.
2. Introduction 1.2 Domain
2.1 Domain
As defined in [inter-domain-fw], a domain is considered to be any As defined in [RFC4726], a domain is considered to be any collection
collection of network elements within a common sphere of address of network elements within a common sphere of address management or
management or path computational responsibility. Examples of such path computational responsibility. Examples of such domains include
domains include IGP areas and Autonomous Systems. A network accessed IGP areas and Autonomous Systems. A network accessed over the
over the Generalized Multiprotocol Label Switching (GMPLS) User-to- Generalized Multiprotocol Label Switching (GMPLS) User-to-Network
Network Interface (UNI) [RFC4208] and a Layer One Virtual Private Interface (UNI) [RFC4208] and a Layer One Virtual Private Network
Network (L1VPNs) [L1VPN-FW] 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 objectives of domain usage include administrative separation,
scalability, and forming protection domains. scalability, and forming protection domains.
As described in [inter-domain-fw], there could be TE parameters (such As described in [RFC4726], there could be TE parameters (such as
as color and priority) whose meanings are specific to each domain. In color and priority) whose meanings are specific to each domain. In
such a scenarios, mapping functions could be performed based on such a scenarios, mapping functions could be performed based on
policy agreements between domain administrators. policy agreements between domain administrators.
2.2 Document Scope 1.3 Document Scope
This document analyzes various schemes to realize Multiprotocol Label This document analyzes various schemes to realize Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi- Switching (MPLS) and Generalized MPLS (GMPLS) LSP recovery in multi-
domain networks based on the existing framework for multi-domain LSP domain networks based on the existing framework for multi-domain LSP
setup [inter-domain-fw]. setup [RFC4726].
There are various recovery techniques for LSPs. For TE LSPs, major There are various recovery techniques for LSPs. For TE LSPs, major
techniques are end-to-end recovery [e2e-recovery], local protection techniques are end-to-end recovery [RFC4872], local protection such
such as Fast Reroute (FRR) [RFC4090] (in packet switching as Fast Reroute (FRR) [RFC4090] (in packet switching environments),
environments), and segment recovery [seg-recovery] (in GMPLS). and segment recovery [RFC4873] (in GMPLS).
In this version of the document the main focus is the analysis of In this version of the document the main focus is the analysis of
diverse TE LSP (hereafter LSP) setup schemes, which can diverse TE LSP (hereafter LSP) setup schemes, which can
advantageously used in the context of end-to-end recovery. This advantageously used in the context of end-to-end recovery. This
document presents various diverse LSP setup schemes by combining document presents various diverse LSP setup schemes by combining
various functional elements. Analysis of other recovery techniques various functional elements. Details of maintenance of diverse LSPs,
could be added in a later revision of this document if necessary. such as re-optimization and OAM, are beyond the scope of this
Furthermore, details of maintenance of diverse LSPs, such as re- document.
optimization and OAM, are for further study.
Note that the comparative evaluation of these various schemes is out Note that the comparative evaluation of these various schemes is out
of scope for this document, and should be described in separate of scope for this document, and should be described in separate
applicability documents. applicability documents.
[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 could be various types of diversity, and this document focuses on
node/link/SRLG diversity. Note that domain diversity (that is, the node/link/SRLG diversity. Note that domain diversity (that is, the
selection of paths that have only the ingress and egress domains in selection of paths that have only the ingress and egress domains in
common) is discussed in section 3.2. common) is discussed in Section 2.2.
Based on the service grade, both the working LSP and the recovery LSP Based on the service grade, both the working LSP and the recovery LSP
may be established at the time of service establishment (e.g., may be established at the time of service establishment (e.g.,
service requiring high resiliency). Alternatively, the recovery LSP service requiring high resiliency). Alternatively, the recovery LSP
may be added later due to a change in the grade of the service. may be added later due to a change in the grade of the service.
Also, the recovery LSP may be used for 1+1 protection, 1:1 Also, the recovery LSP may be used for 1+1 protection, 1:1
protection, or shared mesh restoration. However, ways to compute protection, or shared mesh restoration. However, ways to compute
diverse paths, and the signaling of these TE LSPs are common across diverse paths, and the signaling of these TE LSPs are common across
all uses, and these topics are the main scope of this document. all uses, and these topics are the main scope of this document.
Section 5 of [inter-domain-fw] describes some analysis of diverse Section 5.5 of [RFC4726] describes some analysis of diverse LSPs in
LSPs in multi-domain networks, and this document provides more multi-domain networks, and this document provides more detailed
detailed analysis based on that content. analysis based on that content.
Note that diverse LSPs may be used for various purposes, in addition Note that diverse LSPs may be used for various purposes, in addition
to recovery. An example is for load-balancing, so as to limit the to recovery. An example is for load-balancing, so as to limit the
traffic disruption to a portion of the traffic flow in case of a traffic disruption to a portion of the traffic flow in case of a
single network element failure. This document does not preclude use single network element failure. This document does not preclude use
of diverse LSP setup schemes for those purposes. of diverse LSP setup schemes for those purposes.
2.3 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 [inter-domain-fw], and a more detailed described in Section 5.4 of [RFC4726], and a more detailed analysis
analysis is provided in section 5 of [inter-domain-rsvp]. Additional is provided in Section 5 of [inter-domain-rsvp].
analysis may be added in a future revision of this document if
necessary.
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 would 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 for further study. recovery. This mixture of protection techniques is beyond the scope
of this document.
2.4 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 [inter-domain-fw]. 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 [inter-domain-
rsvp]. Also note that if the recovery type changes at the domain rsvp].
boundary, the nesting and stitching options may be more suitable.
Details are for further study.
3. Diversity in Multi-domain Networks
As described in section 2.2, analysis of diverse LSP setup schemes in 2. Diversity in Multi-domain Networks
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.
3.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 |
| / | | \ / | | \ | | / | | \ / | | \ |
skipping to change at page 6, line 30 skipping to change at page 6, line 34
| C------+---+---F-----G--+---+------K | | C------+---+---F-----G--+---+------K |
| | | | | | | | | | | |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
Figure 1: Linear Connectivity Figure 1: Linear Connectivity
+-----Domain#2-----+ +-----Domain#2-----+
| | | |
| E--------------F | | E--------------F |
| | | | | | | |
| | | |
+-+--------------+-+ +-+--------------+-+
| | | |
+-Domain#1-+-+ +---------+--+ | |
+--Domain#1-+--+ +-------+------+
| | | | | | | | | | | |
| A-------B-+--+-C-------D |
| | | | | | | | | | | |
+--+---------+ +-+-Domain#4-+ | A----B--+---+--C----D |
| | | | | |
| | | | | |
+------+-------+ +--+-Domain#4--+
| | | |
+-+--------------+-+ +-+--------------+-+
| | | | | | | |
| | | |
| G--------------H | | G--------------H |
| | | |
+-----Domain#3-----+ +-----Domain#3-----+
Figure 2: Mesh Connectivity Figure 2: Mesh 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
necessarily follow the same set of domains. necessarily follow the same set of domains.
Indeed, if inter-domain connectivity forms a mesh, domain level Indeed, if inter-domain connectivity forms a mesh, domain level
routing is required (even for the unprotected case). This is tightly routing is required (even for the unprotected case). This is tightly
coupled with the next hop domain resolution/discovery mechanisms. coupled with the next hop domain resolution/discovery mechanisms.
skipping to change at page 7, line 5 skipping to change at page 7, line 14
Figure 2: Mesh Connectivity Figure 2: Mesh 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
necessarily follow the same set of domains. necessarily follow the same set of domains.
Indeed, if inter-domain connectivity forms a mesh, domain level Indeed, if inter-domain connectivity forms a mesh, domain level
routing is required (even for the unprotected case). This is tightly routing is required (even for the unprotected case). This is tightly
coupled with the next hop domain resolution/discovery mechanisms. coupled with the next hop domain resolution/discovery mechanisms.
In this version of the document, we assume that domain level routing In this document, we assume that domain level routing is given via
is given via configuration or policy, and this is not part of path configuration, policy, or some external mechanism, and that this is
computation process described later in this document. Details on more not part of the path computation process described later in this
advanced domain level routing are for further study. document.
In addition, domain level routing may perform "domain re-entry", In addition, domain level routing may perform "domain re-entry",
where a path enters a domain after the path exits that domain (e.g., where a path enters a domain after the path exits that domain (e.g.,
domain#X-domain#Y-domain#X). This requires specific considerations domain#X-domain#Y-domain#X). This requires specific considerations
when confidentiality is required (described in section 4.2), and is when confidentiality is required (described in Section 3.2), and is
for further study. beyond 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
version of the document, we assume that the working LSP and recovery document, we assume that the working LSP and recovery LSP follow the
LSP follow the same set of domains in the same order (via same set of domains in the same order (via configuration, policy or
configuration or policy). Details on other scenarios are for further some external mechanism). That is, we assume that the domain mesh
study. topology is reduced to a linear domain topology for each pair of
working and recovery LSPs.
3.2 Note on Domain Diversity 2.2 Note on Domain Diversity
As described in section 2.2, domain diversity means the selection of As described in Section 1.3, 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 3.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 for further study, should it been considered as a Details are beyond the scope of this document.
requirement.
4. Factors to Consider 3. Factors to Consider
4.1 Scalability versus Optimality 3.1 Scalability versus Optimality
As described in [inter-domain-fw], 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 - Restricting the difference of their cost (so as to minimize delay
difference after switch-over) while maintaining diversity 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 such,
it may not be possible to compute diverse paths, even if they exist. it may not be possible to compute diverse paths, even if they exist.
However, if we assume domain level routing is given (as discussed in However, if we assume domain level routing is given (as discussed in
section 3), it is possible to compute diverse paths in some schemes Section 2), it is possible to compute diverse paths using specific
if such paths exist. This is discussed in section 5. computation schemes, if such paths exist. This is discussed in
Section 4.
4.2 Key Concepts 3.2 Key Concepts
Three key concepts to classify various diverse LSP setup schemes are Three key concepts to classify various diverse LSP computation and
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 Under this network configuration, it is possible to specify (by
means of the Explicit Route Object - ERO comprising a list of means of the Explicit Route Object - ERO - comprising a list of
strict hops) or obtain (by means of the recorded Route Object - strict hops) or obtain record of (by means of the Record Route
RRO) a route across other domains. Object - RRO) a route across other domains.
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).
- With confidentiality - With confidentiality
Under this network configuration, it is not possible to specify Under this network configuration, it is not possible to specify
or obtain a route (by means of ERO/RRO) across other domains. or obtain a full and strict route (by means of ERO/RRO) across
Paths may be specified/obtained in the form of ERO/RRO containing other domains, although paths may be specified/obtained in the
loose hops. Therefore, it is not possible to specify or obtain a form of an ERO/RRO containing loose hops. Therefore, it is not
full route at the head-end of a multi-domain LSP. possible to specify or obtain a full route at the head-end of a
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 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 [inter-domain-pd].
- 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) [PCE-arch]. The case cooperating path computation elements (PCEs) [RFC4655]. An
for unprotected LSP under this scheme is covered in [brpc]. example of such a scheme is Backward Recursive Pause Computation
(BRPC) [brpc]. The use of BRPC for unprotected LSPs under this
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
possible to obtain a path via management configuration, or head-end possible to obtain a path via management configuration, or head-end
path computation (with multi-domain visibility). This is also path computation (with multi-domain visibility). This is discussed
discussed in sections 5 and 6. in Sections 4 and 5.
Note also that it is possible to combine multiple path computation Note also that it is possible to combine multiple path computation
techniques (including using a different technique for the working techniques (including using a different technique for the working
and recovery LSPs), but this is for further study and is likely and recovery LSPs), but details are beyond the scope of this
to require sequential path computation (see below). 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 Typically, this scheme is applicable when the recovery LSP is
added later as change of the service grade. But this scheme can added later as change of the service grade. But this scheme can
also be applicable when both of the working and recovery LSPs are also be applicable when both of the working and recovery LSPs are
established from the start. In this scheme, diverse LSPs may not established from the start. In this scheme, diverse LSPs may not
be correctly computed (without some form of re-optimization or be correctly computed (without some form of re-optimization or
recomputation technique) in "trap" topologies. Furthermore, such recomputation technique) in "trap" topologies. Furthermore, such
sequential path computation approach may prevent from finding an sequential path computation approaches may prevent the selection
"optimal" solution with regards to a specific objective function. of an "optimal" solution with regards to a specific objective
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. Typically, this scheme is applicable
when both the working LSP and the recovery LSP are established when both the working LSP and the recovery LSP are established
together. In this scheme, it is possible to avoid trap together. In this scheme, it is possible to avoid trap
topologies. Furthermore it may allow for achieving more optimal topologies. Furthermore it may allow for achieving more optimal
results. results.
Note that LSP setup with or without confidentiality is given as a Note that LSP setup with or without confidentiality is given as a
per-domain configuration, while the choices of per-domain path per-domain configuration, while the choices of per-domain path
computation or inter-domain collaborative path computation, and computation or inter-domain collaborative path computation, and
sequential path computation or simultaneous path computation may be a sequential path computation or simultaneous path computation may be a
matter of choice for each individual pair of working/recovery LSPs. matter of choice 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 5 and 6, based on above criteria. Sections 4 and 5, based on above criteria.
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 7, 8 and 9. described in Sections 6, 7, and 8.
5. Diverse LSP Setup Schemes without Confidentiality 4. Diverse LSP Setup Schemes without Confidentiality
In the following, various schemes for diverse LSP setup are presented In the following, various schemes for diverse LSP setup are presented
based on different path computation techniques assuming that there is based on different path computation techniques assuming that there is
no requirement for confidentiality between domains. Section 6 makes a no requirement for confidentiality between domains. Section 5 makes a
similar examination of schemes where inter-domain confidentiality is similar examination of schemes where inter-domain confidentiality is
required. required.
5.1 Management Configuration 4.1 Management Configuration
Section 3.1 of [inter-domain-fw] describes this path computation
technique. The full explicit paths for the working and recovery LSPs
are specified by a management application at the head-end, and no
further computation or signaling specific considerations are needed.
5.2 Head-end Path Computation (with multi-domain visibility) Section 3.1 of [RFC4726] describes this path computation technique.
The full explicit paths for the working and recovery LSPs are
specified by a management application at the head-end, and no further
computation or signaling considerations are needed.
Section 3.2.1 of [inter-domain-fw] describes this path computation 4.2 Head-end Path Computation (with multi-domain visibility)
technique. 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. In either case the computing entity has full TE visibility
across multiple domains and no further computation or signaling
specific considerations are needed.
5.3 Per-domain Path Computation Section 3.2.1 of [RFC4726] describes this path computation technique.
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.
In either case the computing entity has full TE visibility across
multiple domains and no further computation or signaling
considerations are needed.
Sections 3.2.2, 3.2.3 and 3.3 of [inter-domain-fw] describe this path 4.3 Per-domain Path Computation
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]. [inter-domain-pd].
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.
Thus, ERO expansion is needed at domain boundaries. Path computation Thus, ERO expansion is needed at domain boundaries. Path computation
is performed by, or by a PCE on behalf of, each domain boundary LSR. is performed by, or by a PCE on behalf of, each domain boundary LSR.
For establishing diverse LSPs using per-domain computation, there are For establishing diverse LSPs using per-domain computation, there are
two specific schemes, which are described in sections 5.3.1 and 5.3.2 two specific schemes, which are described in Sections 4.3.1 and 4.3.2
respectively. respectively.
5.3.1 Sequential Path Computation 4.3.1 Sequential Path Computation
The Exclude Route Object (XRO) [XRO] can be used. Details are as The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details
follows. 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
path exclusion mechanism.
Assume that the working LSP is established as described in [inter- Assume that the working LSP is established as described in [inter-
domain-pd]. Also, assume that the route of the working LSP (full domain-pd]. Also, assume that the route of the working LSP (full
route) is available at the head-end through the RRO. route) is 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. diverse path is obtained. When path computation is performed by a
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 o Signaling aspect
In order that the computation noted above can be performed, each In order that the computation noted above can be performed, each
computation point must be aware of the path of the working LSP. computation point must be aware of the path of the working LSP.
This information can be supplied in the XRO included in the Path This information can be supplied in the XRO included in the Path
message for recovery LSP. The XRO lists nodes, links and SRLGs that message for recovery LSP. The XRO lists nodes, links and SRLGs that
must be avoided by the LSP being signaled, and its contents are must be avoided by the LSP being signaled, and its contents are
copied from the RRO of the working LSP. copied from the RRO of the working LSP.
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 LSP is established without
consideration of the need for a diverse recovery LSP. Crankback consideration of the need for a diverse recovery LSP. Crankback
[crankback] may be used in combination with this scheme in order to [crankback] may be used in combination with this scheme in order to
improve the possibility of successful diverse LSP setup. Furthermore, improve the possibility of successful diverse LSP setup. Furthermore,
re-optimization of the working LSP and the recovery LSP may be used re-optimization of the working LSP and the recovery LSP may be used
to achieve fully diverse paths. 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 (set of diverse TE LSP) might not be maximized. the solution (i.e., of the set of diverse TE LSPs) might not be
maximal.
5.3.2 Simultaneous Path Computation 4.3.2 Simultaneous Path Computation
o Path computation aspect o Path computation aspect
When signaling the working LSP, the path of not only the working When signaling the working LSP, the path of not only the working
LSP, but also the recovery LSP is computed. For example, in LSP, but also the recovery LSP is computed. For example, in
Figure 1, when node D receives a Path message for the working LSP Figure 1, when node D receives a Path message for the working LSP
between nodes A and L, node D expands the ERO to reach domain#3. At 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 time, node D computes a path for the recovery LSP across
the same domain from node F to reach domain#3. The entry boundary the same domain from node F to reach domain#3. The entry boundary
node for the recovery LSP (node F) needs to be specified in the node for the recovery LSP (node F) needs to be known by the entry
Path message for the working LSP. In this example the path for the boundary node for the working LSP (node D). In this example the
working LSP may be computed by node D as D-E-domain#3, and the path path for the working LSP may be computed by node D as D-E-domain#3,
for recovery LSP as F-G-domain#3. and the path for recovery LSP as F-G-domain#3.
o Signaling aspect o Signaling aspect
There must be a mechanism to force the recovery LSP to follow the Two signaling features are needed in order to make this scheme
route computed above. One way to realize this is to have a specific work.
object (with the same format as the ERO) to collect the route of
the recovery LSP in the Path message for the working LSP and to - A mechanism is needed to signal, during working LSP setup, the
return is to the head-end in the Resv message. When signaling the entry boundary node to be used by the recovery LSP. This
recovery LSP, the content of the ERO is copied from this object. 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
route computed above. One way to realize this is to have a
specific object (with the same format as the ERO) to collect the
route of the recovery LSP in the Path message for the working LSP
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
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 This scheme also cannot guarantee to establish diverse LSPs (even if
they could exist) if there are more than two domain boundary nodes they could exist) if there are more than two domain boundary nodes
out of each domain. Crankback [crankback] may also be used in out of each domain. Crankback [crankback] may also be used in
combination with this scheme to improve the chances of success. combination with this scheme to improve the chances of success.
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 (set of diverse TE LSP) might not be maximized. the solution (i.e., of the set of diverse TE LSPs) might not be
maximal.
5.4 Inter-domain Collaborative Path Computation 4.4 Inter-domain Collaborative Path Computation
Section 3.4 of [inter-domain-fw] describes this approach. [brpc] Section 3.4 of [RFC4726] describes this approach, and [brpc] provides
provides some more detail. Path computation is performed for each of detail of Backward Recursive Path Computation which is a
the working and recovery LSPs by the use of inter-PCE communication collaborative path computation technique. Path computation is
before each LSP is signaled. performed for each of the working and recovery LSPs by the use of
inter-PCE communication before each LSP is signaled.
There are two specific schemes for establishing diverse LSPs using There are two specific schemes for establishing diverse LSPs using
this scheme, which are described in sections 5.4.1 and 5.4.2. this scheme, which are described in Sections 4.4.1 and 4.4.2.
5.4.1 Sequential Path Computation 4.4.1 Sequential Path Computation
Route exclusion using the XRO [XRO] can be requested in the PCE Route exclusion using the XRO [PCEP-XRO] can be requested in PCEP
communication protocol (PCEP) [PCEP] and this can be used to compute [PCEP], and this can be used to compute the path of a recovery LSP
the path of a recovery LSP after the path of the working LSP has been after the path of the working LSP has been determined. Details are as
determined. Details are as follows. follows.
The working LSP is computed and may be immediately established as The working LSP is computed using a collaborative PCE approach such
described in [brpc]. Assume that the path of the working LSP (full as that described in [brpc], and the LSP may be immediately
route) is available from the RRO. 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 o Path computation aspect
When requesting path computation for the recovery LSP, an XRO is When requesting path computation for the recovery LSP, an XRO is
included in the PCEP path computation request message (see [PCEP]). included in the PCEP path computation request message (see
The content of the XRO is copied from the RRO of the working LSP. [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 computation request specifies that the full route must be the ERO of the path computation reply for the working LSP. The
returned. Per-domain PCEs may need to be invoked by the first PCE latter case is useful when the working LSP is not established at
that is consulted in order to collaboratively determine the correct the time of the path computation request for the recovery LSP. The
path for the recovery LSP (just as described in [PCE-arch] and computation request specifies that the full route must be returned.
[inter-domain-fw] for the computation of a single inter-domain LSP Per-domain PCEs may need to be invoked by the first PCE that is
by collaborating PCEs), and these PCEs exchange the XRO information consulted in order to collaboratively determine the correct path
to ensure that the computed path is diverse from the working LSP. 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 o Signaling aspect
The recovery LSP is signaled by including an ERO whose content is The recovery LSP is signaled by including an ERO whose content is
copied from the result returned by the PCE. copied from the result returned by the PCE.
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 be blocking. In such a scenario, exist) because the working LSP may block the recovery LSP. In such a
re-optimization of the working and recovery LSPs may be used to scenario, re-optimization of the working and recovery LSPs may be
achieve fully diverse paths. used to achieve fully diverse paths.
Note that PCEP [PCEP] does not currently include support for the XRO,
but that this is planned to be added in a future version.
5.4.2 Simultaneous Path Computation 4.4.2 Simultaneous Path Computation
o Path computation aspect o Path computation aspect
The PCEP SVEC Object allows diverse path computation to be The PCEP SVEC Object [PCEP] allows diverse path computation to be
requested. It would be possible to extend [brpc] to compute diverse requested. It would be possible to extend BRPC [brpc] to compute
paths. Details are for further study. diverse paths through the definition of a specific process. Such
extensions are beyond the scope of this document.
o Signaling aspect o Signaling aspect
In this scheme the PCE returns the full routes for the working and In this scheme the PCE returns the full routes for the working and
recovery LSPs and they are signaled accordingly. recovery LSPs and they are signaled accordingly.
This scheme can guarantee to establish diverse LSPs (if they exist), This scheme can guarantee to establish diverse LSPs (if they exist),
assuming domain level routing is given as described in section 3. assuming domain level routing is given as described in Section 2.
Furthermore, the computed set of TE LSPs may be optimal with respect Furthermore, the computed set of TE LSPs can be guaranteed to be
to some objective functions. optimal with respect to some objective functions.
6. 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, in addition to 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
skipping to change at page 14, line 20 skipping to change at page 15, line 12
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 [LSP-stitch] and signal the end-to-end LSP to use these per-domain
LSPs. This scheme may need additional identifiers (such as LSP IDs) LSPs. This scheme might need additional identifiers (such as LSP
in the Path message so that the domain boundary node can identify IDs) in the Path message so that the domain boundary node can
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 communication to pre-establish Furthermore, this scheme may require additional communication to
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.
Note that in the schemes below, the paths of the working and recovery Note that in the schemes below, the paths of the working and recovery
LSPs are not impacted by the confidentiality requirements. LSPs are not impacted by the confidentiality requirements.
6.1 Management Configuration 5.1 Management Configuration
It is not possible to obtain or specify the full explicit route for It is not possible to obtain or specify the full explicit route for
either LSP at the head-end due to confidentiality restrictions. either LSP at the head-end due to confidentiality restrictions.
Therefore, this information cannot be provided to signaling for LSP Therefore, this information cannot be provided to signaling for LSP
setup. setup.
Confidentially need not prevent the full computation of inter-domain Confidentiality does not prevent the full computation of inter-domain
paths and signaling of sufficient information to distinguish the paths and signaling of sufficient information to distinguish the
paths. However the path information for each domain must be provided paths. However the path information for each domain must be provided
in a way that does not have meaning to other domains. Example in a way that does not have meaning to other domains. Example
mechanisms to preserve confidentiality as described above, include: mechanisms to preserve confidentiality as described above, include:
- Path key - Path key
- LSP segment - LSP segment
Details are for further study. 5.2 Head-end Path Computation (with multi-domain visibility)
6.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.
6.3 Per-Domain Path Computation 5.3 Per-Domain Path Computation
6.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 [inter-domain-
pd]. 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. In order to provide the RRO at the head-end due to confidentiality restrictions. In order to
path of the working LSP through each domain to the computation point provide the path of the working LSP through each domain to the
responsible for computing the path of the protection LSP through each computation point responsible for computing the path of the
domain additional mechanisms are needed. Examples of such mechanisms protection LSP through each domain additional mechanisms are needed.
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
the entity which computed the path of the working LSP (i.e., domain 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. 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 When the entity which computed the path of the working LSP is the
PCE, PCE needs to be temporarily stateful. An example of such PCE, PCE needs to be temporarily stateful. An example of such
information is the Association Object [e2e-recovery]. information is the Association Object [RFC4872].
Details are for further study.
6.3.2 Simultaneous Path Computation 5.3.2 Simultaneous Path Computation
In this scheme the intention is to compute the path of the recovery In this scheme the intention is to compute the path of the recovery
LSP at the same time as the working LSP. In order to force the LSP at the same time as the working LSP. In order to force the
recovery LSP to follow the computed path as well as to preserve recovery LSP to follow the computed path as well as to preserve
confidentiality, additional mechanisms are needed to communicate the confidentiality, additional mechanisms are needed to communicate the
computed recovery path from the path of the working LSP (where it was computed recovery path from the path of the working LSP (where it was
computed) to the recovery LSP. Examples of such mechanisms, that must computed) to the recovery LSP. Examples of such mechanisms, that must
continue to preserve confidentiality, are as follows. continue to preserve confidentiality, are as follows.
- LSP segment: As described before. The LSP segment for the recovery - LSP segment: As described before. The LSP segment for the recovery
LSP is established domain-by-domain as the working LSP setup LSP is established domain-by-domain as the working LSP setup
progresses. progresses. How to initiate such LSP segments for the recovery LSP
is beyond the scope of this document.
- Alternatively, information identifying the working LSP is included - Alternatively, information identifying the working LSP is included
in the Path message for the recovery LSP, and the domain boundary in the Path message for the recovery LSP, and the domain boundary
node consults the entity which computed the path of the recovery 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 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 of the recovery LSP. This requires that the entity which computed
the path of the recovery LSP is temporarily stateful. An example of the path of the recovery LSP is temporarily stateful. An example of
such information is the Association Object [e2e-recovery]. such information is the Association Object [RFC4872]. Detailed
protocol specifications are beyond the scope of this document.
Details are for further study.
6.4 Inter-domain Collaborate Path Computation 5.4 Inter-domain Collaborate Path Computation
6.4.1 Sequential Path Computation 5.4.1 Sequential Path Computation
Assume working LSP is established as described in [brpc]. Route exclusion using the XRO [PCEP-XRO] in combination with the path
key [conf-segment] can be requested in PCEP [PCEP] and this can be
used to compute the path of a recovery LSP after the path of the
working LSP has been determined. Details are as follows.
It is not possible to obtain RRO of working LSP (full route) at the The working LSP is computed as described in [brpc] with the help of
head-end due to confidentiality. 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 o Path computation aspect
In order to obtain the path of the working LSP when computing the This is similar to the case without confidentiality (Section
path of the recovery LSP, additional mechanisms are needed. 4.4.1), but in order to preserve confidentiality, additional
Examples of such mechanisms are: mechanisms are needed.
- Information identifying the working LSP is included in the PCEP In the PCEP path computation request for the recovery LSP, an XRO
message when requesting path computation of the recovery LSP is included. The content of the XRO is copied from the ERO of the
should the PCE stateful (temporarily). An example of such path computation reply for the working LSP, which is given in the
information is the Association Object [e2e-recovery]. form of strict hops for the local domain, domain boundaries or
domain identifiers, and path keys. When a PCE receives XRO
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 o Signaling aspect
The full route for the recovery LSP can not be returned to the The full route for the recovery LSP can not be returned to the
head-end by PCE because it cannot be collected from the other PCEs head-end by PCE because it cannot be collected from the other PCEs
owing to confidentiality restrictions. In order to force the owing to confidentiality restrictions. In order to force the
recovery LSP to follow the path computed above, additional recovery LSP to follow the path computed above, additional
mechanisms are needed. Examples of such mechanisms are as described mechanisms are needed. Examples of such mechanisms are as described
before: before:
- Path key - Path key
- LSP segment - LSP segment
Details are for further study. 5.4.2 Simultaneous Path Computation
6.4.2 Simultaneous Path Computation
It is not possible for PCE to return the full route of the working As described in Section 4.4.2, diverse path computation can be
LSP and recovery LSP to the head-end due to confidentiality. In order requested by PCEP SVEC Object [PCEP], and [brpc] can be extended for
to force the working and recovery LSPs to follow the paths computed, inter-domain diverse path computation. However, it is not possible
additional mechanisms are needed. Examples of such mechanisms are as for PCE to return the full route of the working LSP and recovery LSP
described before: to the head-end due to confidentiality. In order to force the working
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. - Path key: Use this for the working and recovery LSPs.
Note that the LSP segment approach in section 6 may not be applicable Note that the LSP segment approach in Section 5 may not be applicable
here since a path cannot be determined until BRPC procedures are here because a path cannot be determined until BRPC procedures are
completed. completed.
Details are for further study. 6. Network Topology Specific Considerations
7. Network Topology Specific Considerations
In some specific network topologies, diverse LSP setup schemes In some specific network topologies, diverse LSP setup schemes
mentioned above could be drastically simplified. mentioned above could be drastically simplified.
For example, assume there are only three domains connected linearly, For example, assume there are only three domains connected linearly,
and the first and the last domain contain only a single node. Assume and the first and the last domain contain only a single node. Assume
that we need to establish diverse LSPs from the node in the first that we need to establish diverse LSPs from the node in the first
domain to the node in the last domain. 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.
8. Addressing Considerations 7. Addressing Considerations
All of the above-mentioned schemes are applicable when a single All of the above-mentioned schemes are applicable when a single
address space is used across all domains. address space is used across all domains.
However, there could be several cases where private addresses are However, there could be cases where private addresses are used within
used within some of the domains. This case is similar to the one with some of the domains. This case is similar to the one with
confidentiality, since the ERO and RRO are meaningless even if they confidentiality, since the ERO and RRO are meaningless even if they
are available. Details are for further study. are available. This document does not exclude other schemes, but
details are beyond the scope of this document.
9. Note on SRLG Diversity 8. Note on SRLG Diversity
The above-mentioned schemes are applicable when the nodes and links The above-mentioned schemes are applicable when the nodes and links
in different domain belong to different SRLGs. in different domains belong to different SRLGs.
However, there could be several cases where the nodes and links in However, there could be cases where the nodes and links in different
different domain belong to the same SRLG. That is, where SRLGs span domains belong to the same SRLG. That is, where SRLGs span domain
domain boundaries. In such cases, in order to establish SRLG diverse boundaries. In such cases, in order to establish SRLG diverse LSPs,
LSPs, several considerations are needed, such as: several considerations are needed, such as:
- 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 2.1. parameters mentioned in Section 1.2.
Details are for further study.
10. Manageability Considerations 9. Security Considerations
This document does not require additional security considerations
mentioned in [RFC4726], which is the basis of this document. That is,
LSP path computation and setup across domain boundaries is
necessarily a security concern and will be subject to operational
policies. In particular, the trust model across domain boundaries for
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).
TBD RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication
capabilities, and these should be seriously considered in all inter-
domain deployments.
11. Security Considerations More discussion on security considerations in MPLG/GMPLS networks is
found in a specific document [security-fw].
TBD 10. References
12. References 10.1 Normative References
12.1 Normative References [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[inter-domain-fw] Farrel, A., et al., "A Framework for Inter-Domain [RFC4726] Farrel, A., Vasseur, J.-P., and A. Ayyangar, "A
MPLS Traffic Engineering", draft-ietf-ccamp- Framework for Inter-Domain MPLS Traffic
inter-domain-framework, work in progress. 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.
12.2 Informative References 10.2 Informative References
[RFC4208] Swallow, G., et al., "Generalized Multiprotocol [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Label Switching (GMPLS) User-Network Interface Rekhter, "Generalized Multiprotocol Label
(UNI): Resource ReserVation Protocol-Traffic Switching (GMPLS) User-Network Interface (UNI):
Engineering (RSVP-TE) Support for the Overlay Resource ReserVation Protocol-Traffic Engineering
Model", RFC 4208, October 2005. (RSVP-TE) Support for the Overlay Model",
RFC 4208, October 2005.
[L1VPN-FW] Takeda, T., Editor "Framework and Requirements [RFC4847] Takeda, T., Ed., "Framework and Requirements for
for Layer 1 Virtual Private Networks", draft- Layer 1 Virtual Private Networks", RFC 4847,
ietf-l1vpn-framework, work in progress. April 2007.
[PCE-arch] A. Farrel, JP. Vasseur and J. Ash, "Path [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "Path
Computation Element (PCE) Architecture", draft- Computation Element (PCE) Architecture",
ietf-pce-architecture, work in progress. RFC 4655, August 2006.
[e2e-recovery] 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", (GMPLS)-based Recovery", RFC 4872, May 2007.
draft-ietf-ccamp-gmpls-recovery-e2e-signaling,
work in progress.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels",
May 2005. RFC 4090, May 2005.
[seg-recovery] Berger, L., Bryskin, I., Papadimitriou, D., and [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and
Farrel, A., "GMPLS Based Segment Recovery", A. Farrel, "GMPLS Based Segment Recovery",
draft-ietf-ccamp-gmpls-segment-recovery, work in RFC 4873, May 2007.
progress.
[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.
[RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter- [RFC4216] Zhang, R., and Vasseur, J.-P., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE) Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005 Requirements", RFC 4216, November 2005
[inter-domain-rsvp] Ayyangar, A., Vasseur, JP. "Inter-domain MPLS [inter-domain-rsvp] Farrel, A., Ed., "Inter domain Multiprotocol
Traffic Engineering - RSVP extensions", draft- Label Switching (MPLS) and Generalized MPLS
ietf-ccamp-inter-domain-rsvp-te, work in (GMPLS) Traffic Engineering - RSVP-TE
progress. extensions", draft-ietf-ccamp-inter-domain-rsvp-
te, work in progress.
[XRO] Lee et al., "Exclude Routes - Extension to [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S.,
RSVP-TE", draft-ietf-ccamp-rsvp-te-exclude-route, "Exclude Routes - Extension to Resource
work in progress. ReserVation Protocol-Traffic Engineering
(RSVP-TE)", RFC 4874, April 2007.
[inter-domain-pd] Vasseur JP., Ayyangar A., Zhang R., "A [inter-domain-pd] Vasseur JP., Ed., and Ayyangar A., Ed., "A Per-
per-domain path computation method for computing domain path computation method for establishing
Inter-domain Traffic Engineering Label Switched Inter-domain Traffic Engineering (TE) Label
Path", draft-ietf-ccamp-inter-domain-pd-path- Switched Paths (LSPs)", draft-ietf-ccamp-inter-
comp, work in progress. domain-pd-path-comp, work in progress.
[brpc] Vasseur, JP., Zhang, R., and Bitar, N., "A [brpc] Vasseur, JP., Ed., "A Backward Recursive
Backward Recursive PCE-based Computation (BRPC) PCE-based Computation (BRPC) procedure to compute
procedure to compute shortest inter-domain shortest inter-domain Traffic Engineering Label
Traffic Engineering Label Switched Path", draft- Switched Path", draft-ietf-pce-brpc, work in
vasseur-ccamp-brpc, work in progress. progress.
[PCEP] Vasseur, J., "Path Computation Element (PCE) [PCEP-XRO] Oki, E., and A. Farrel, "Extensions to the Path
communication Protocol (PCEP) - Version 1 -", Computation Element Communication Protocol (PCEP)
draft-ietf-pce-pcep, work in progress. for Route Exclusions", draft-ietf-pce-pcep-xro,
work in progress.
[conf-segment] Bradford, R., Vasseur, JP., and Farrel, A., [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path
"Preserving Topology Confidentiality in Inter- Computation Element (PCE) communication Protocol
Domain Path Computation and Signaling", draft- (PCEP)", draft-ietf-pce-pcep, work in progress.
bradford-pce-path-key, work in progress.
[crankback] Farrel, A., et al., "Crankback Signaling [conf-segment] Bradford, R., Ed., "Preserving Topology
Extensions for MPLS Signaling", draft-ietf- Confidentiality in Inter-Domain Path Computation
ccamp-crankback, work in progress. using a key based mechanism ", draft-ietf-pce-
path-key, work in progress.
[crankback] Farrel, A., Ed., "Crankback Signaling Extensions
for MPLS Signaling", draft-ietf-ccamp-crankback,
work in progress.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched
Paths (LSP) Hierarchy with Generalized Multi- Paths (LSP) Hierarchy with Generalized Multi-
Protocol Label Switching (GMPLS) Traffic Protocol Label Switching (GMPLS) Traffic
Engineering (TE)", RFC 4206, October 2005. Engineering (TE)", RFC 4206, October 2005.
[LSP-stitch] Ayyangar, A., and Vasseur, JP., "LSP Stitching [LSP-stitch] Ayyangar, A., Kompella, K., Vasseur, JP., and
with Generalized MPLS TE", draft-ietf-ccamp-lsp- A. Farrel, "Label Switched Path Stitching with
Generalized Multiprotocol Label Switching Traffic
Engineering (GMPLS TE)", draft-ietf-ccamp-lsp-
stitching, work in progress. stitching, work in progress.
13. Acknowledgments [security-fw] Fang, L., " Security Framework for MPLS and GMPLS
Networks", draft-fang-mpls-gmpls-security-
Framework, work in progress.
Authors would like to thank Eiji Oki, Ichiro Inoue and Kazuhiro 11. Acknowledgments
Authors would like to thank Eiji Oki, Ichiro Inoue, and Kazuhiro
Fujihara for valuable comments. Fujihara for valuable comments.
14. Author's Addresses 12. 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 20, line 37 skipping to change at page 22, line 17
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Jean-Philippe Vasseur Jean-Philippe Vasseur
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough , MA - 01719 Boxborough , MA - 01719
USA USA
Email: jpv@cisco.com Email: jpv@cisco.com
15. Intellectual Property Consideration Intellectual Property Consideration
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology to pertain to the implementation or use of the technology
described in this document or the extent to which any license described in this document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79. rights in RFC documents can be found in BCP 78 and BCP 79.
skipping to change at page 21, line 12 skipping to change at page 22, line 41
of such proprietary rights by implementers or users of this of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository specification can be obtained from the IETF on-line IPR repository
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.
16. Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006). Copyright (C) The IETF Trust (2007).
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. 146 change blocks. 
349 lines changed or deleted 419 lines changed or added

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