Network Working Group T. Takeda, Ed. Internet Draft NTT Intended Status: Informational
Y. IkejiriA. Farrel, Ed. Created March 24th, 2008 NTT Communications Expires: September 24th,April 13, 2008 A. FarrelOld Dog Consulting Expires: October 13, 2008 Y. Ikejiri NTT Communications JP. Vasseur Cisco Systems, Inc. Analysis of Inter-domain Label Switched Path (LSP) Recovery draft-ietf-ccamp-inter-domain-recovery-analysis-03.txtdraft-ietf-ccamp-inter-domain-recovery-analysis-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document analyzes various schemes to realizeProtection and recovery are important features of service provision in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. Increasingly, MPLS and GMPLS networking is being widened from single domain scope to operate in multi-domain environments. Various schemes and processes have been developed to establish Label Switched Path (LSP) recoveryPaths (LSPs) in multi-domain networks based on the existing frameworkenvironments. These are discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering. This document analyzes the application of these techniques to protection and recovery in multi-domain LSPs.networks. 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.Table of Contents 1. Introduction...................................................3 1.1 Terminology...................................................3 1.2 Domain........................................................4 1.3 Document Scope................................................4Scope................................................5 1.4 Note on Other Recovery Techniques.............................5Techniques.............................6 1.5 Signaling Options.............................................6 2. Diversity in Multi-domainMulti-Domain Networks.............................6 2.1 Multi-domainMulti-Domain Network Topology.................................6 2.2 Note on Domain Diversity......................................8 3. Factors to Consider............................................8Consider............................................9 3.1 Scalability versus Optimality.................................8Versus Optimality.................................9 3.2 Key Concepts..................................................9 4. Diverse LSP Setup Schemes withoutWithout Confidentiality.............11 4.1 Management Configuration.....................................11 4.2 Head-endHead-End Path Computation (with multi-domain visibility).....11(With Multi-Domain Visibility).....12 4.3 Per-domainPer-Domain Path Computation..................................11Computation..................................12 4.3.1 Sequential Path Computation................................12 4.3.2 Simultaneous Path Computation..............................12Computation..............................13 4.4 Inter-domainInter-Domain Collaborative Path Computation..................13Computation..................14 4.4.1 Sequential Path Computation................................14Computation................................15 4.4.2 Simultaneous Path Computation..............................14Computation..............................15 5. Diverse LSP Setup Schemes withWith Confidentiality................15 5.1 Management Configuration.....................................16Configuration.....................................17 5.2 Head-endHead-End Path Computation (with multi-domain visibility).....16(With Multi-Domain Visibility).....17 5.3 Per-Domain Path Computation..................................16Computation..................................17 5.3.1 Sequential Path Computation................................16Computation................................17 5.3.2 Simultaneous Path Computation..............................17Computation..............................18 5.4 Inter-domainInter-Domain Collaborative Path Computation..................17Computation..................19 5.4.1 Sequential Path Computation................................17Computation................................19 5.4.2 Simultaneous Path Computation..............................18Computation..............................20 6. Network Topology Specific Considerations......................18Considerations......................20 7. Addressing Considerations.....................................19Considerations.....................................20 8. Note on SRLG Diversity........................................19Diversity........................................20 9. IANA Considerations...........................................19Considerations ..........................................21 10. Security Considerations......................................19Considerations......................................21 11. References...................................................20References...................................................21 11.1 Normative References........................................20References........................................21 11.2 Informative References......................................20References......................................22 12. Acknowledgments..............................................22Acknowledgments..............................................24 13. Authors' Addresses...........................................22Addresses...........................................24 1. Introduction This document analyzes various schemes to realizeProtection and recovery in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path (LSP) recovery in multi-domainnetworks based on the existing framework for multi-domain LSPs. The main focusare described in [RFC4428]. These are important features for this document is on establishing end-to-end diverse Traffic Engineering (TE) LSPsservice delivery in multi-domainMPLS and GMPLS networks. It presents various diverse LSP setup schemes based on existing functional elements. 1.1 Terminology The reader is assumedMPLS and GMPLS networking was originally limited to be familiar with the terminology in [RFC4726] that provides a framework for inter-domain Label Switched Path (LSP) setup,single domain environments. Increasingly, multi-domain MPLS and [RFC4427] that provides terminology for LSP recovery. The followingGMPLS networks are several key terminologies used within this document. - Domain: See [RFC4726]. Abeing considered, where a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Note that nested domains continue to be outExamples of scope. Section 1.2 provides some more details. - Working LSP: Seesuch 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 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 Path (LSP) setup. Key terminology may also be found in [RFC4216] where requirements for MPLS traffic engineering inter-AS are set out. The following key terms from those sources are used within this document. - Domain: See [RFC4726]. A domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Note that nested domains continue to be out of scope. Section 1.2 provides additional details. - Working LSP: See [RFC4427]. The working LSP transports normal user traffic. Note that the term LSP and TE LSP will be used interchangeably. - Recovery LSP: See [RFC4427]. The recovery LSP transports normal user traffic when the working LSP fails. The recovery LSP may transportalso carry user traffic even when the working LSP is operating normally and transporting normalthe user traffic (e.g., 1+1 protection). In such a scenario, theThe recovery LSP is sometimes referred to as a protecting LSP. - Diversity: See [RFC4726]. Diversity means the relationship of multiple LSPs, where those LSPs do not share some specific type 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- balancing and recovery. In this document, the recovery aspect of diversity, specifically the end-to-end diversity of two traffic engineering (TE) LSPs, is the focus. ThoseThe two diverse LSPs are referred to as the working LSP and recovery LSP hereafter. Sometimes, diversity is referred to as disjointness.LSP. - Confidentiality: See [RFC4216]. The term confidentiality appliesConfidentiality refers to the protection of information about the topology and resources present withinof one domain from visibility by people or applications outside that domain. 1.2 Domain As definedIn order to fully understand the issues addressed in [RFC4726], a domainthis document, it is necessary to carefully define and scope the term "domain". As defined in [RFC4726], a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include IGP areas and Autonomous Systems. A network accessed over the Generalized Multiprotocol Label Switching (GMPLS)GMPLS User-to-Network Interface (UNI) [RFC4208] and a Layer One Virtual Private Network (L1VPN) [RFC4847] are special cases of multi-domain networks. Example objectives ofmotivations for using more than one domain usageinclude administrative separation, scalability, and formingthe construction of domains for the purpose of providing protection. These latter "protection domains" offer edge-to-edge protection domains.facilities for spans or segments of end-to-end LSPs. As described in [RFC4726], there could be TE parameters (such as color and priority) whose meanings are specific to each domain. In such scenarios, in order to set up inter-domain LSPs, mapping functions couldmay be performedneeded to transform the TE parameters based on policy agreements between domain administrators. 1.3 Document Scope This document analyzes various schemes to realize Multiprotocol Label Switching (MPLS) and GeneralizedMPLS (GMPLS)and GMPLS LSP recovery in multi- domain networksmulti-domain networks. It is based on the existing framework for multi-domain LSP setup [RFC4726]. Note that this document does not intend toprevent the development of additional techniques where appropriate (i.e., additional to the ones described in this document, which are based on the existing framework described in [RFC4726]).document). In other words, this document is informational and intends to showshows how the existing frameworktechniques can be applied with specific procedures described in this document and the documents referred to by this document.applied. There are various recovery techniques for LSPs. For TE LSPs, the major techniques are end-to-end recovery [RFC4872], local protection such as Fast Reroute (FRR) [RFC4090] (in packet switching environments), and segment recovery [RFC4873] (in GMPLS). In this document theThe main focus of this document is the analysis of diverse TE LSP (hereafter LSP)setup schemes (path computation and signaling aspects), whichthat can advantageouslybe used in the context of end-to- endend-to-end recovery. This document presents various diverse LSP setup schemes by combining various functional elements. In particular, Section 5.5 of [RFC4726] describes some analysisThe methodology is to show different combinations of diverse LSPs in multi-domain networks,functional elements such as path computation and this document provides more detailed analysis based on that content.signaling techniques. [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There could beare various types of diversity, and this document focuses on node/link/SRLGnode, link, and shared risk link group (SRLG) diversity. Based onRecovery LSPs may be used for 1+1 protection, 1:1 protection, or shared mesh restoration. However, the service grade, bothrequirements for path diversity, the working LSPways to compute diverse paths, and the recovery LSP may be established at the timesignaling of service establishment (e.g., service requiring high resiliency). Alternatively,these TE LSPs are common across all uses, and these topics are the recovery LSPmain scope of this document. Note that diverse LSPs 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 protection, or shared mesh restoration. However, ways to compute diverse paths, and the signaling of 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,used for various purposes in addition 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 single network element failure. This document does not preclude use of diverse LSP setup schemes for those purposes. The following are beyond the scope of this document. - Analysis of recovery techniques other than link/node/SRLGthe use of link, node, or SRLG diverse LSPs (see Section 1.4). - Details of maintenance of diverse LSPs, such as re-optimization and OAM. - Comparative evaluation of various diverseLSP setup schemes mentioned in this document.schemes. 1.4 Note on Other Recovery Techniques Fast Reroute and segment recovery in multi-domain networks are described in Section 5.4 of [RFC4726], and a more detailed analysis is provided in Section 5 of [RFC5151]. This document does not cover any additional analysis for Fast ReRoute and segment recovery in multi-domain networks. Also, theThe recovery type of an LSP or service may change at a domain 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 the capabilities of each domain, administrative policies, or to topology limitations. An example is where protection at the domain boundary is provided by link protection on the inter-domain link(s),links, but where protection within each domain is achieved through segment recovery. This mixture of protection techniques is beyond the scope of this document. Domain diversity (that is, the selection of paths that have only the 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 this document (see Section 2.2). 1.5 Signaling Options There are three signaling options for establishing inter-domain TE LSPs: nesting, contiguous LSPs, and stitching [RFC4726]. The description in this document of diverse LSP setup is agnostic in relation to the signaling option used, unless otherwise specified. Note that signaling option-specificoption considerations for Fast Reroute and segment recovery are described in Section 5 of[RFC5151]. 2. Diversity in Multi-domainMulti-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 section describes some assumptions about achieving path diversity in this problem space made in this document.multi-domain networks. 2.1 Multi-domainMulti-Domain Network Topology Figures 1 and 2 show example multi-domain network topologies. In 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- domain#2-domain#3 in that order. +--Domain#1--+ +--Domain#2--+ +--Domain#3--+ | | | | | | | B------+---+---D-----E--+---+------J | | / | | \ / | | \ | | / | | \ / | | \ | | A | | H | | L | | \ | | / \ | | / | | \ | | / \ | | / | | C------+---+---F-----G--+---+------K | | | | | | | +------------+ +------------+ +------------+ Figure 1: Linear Domain Connectivity +-----Domain#2-----+ | | | E--------------F | | | | | | | | | +-+--------------+-+ | | | | +--Domain#1-+--+ +-------+------+ | | | | | | | | | | | | | A----B--+---+--C----D | | | | | | | | | | | | | +------+-------+ +--+-Domain#4--+ | | +-+--------------+-+ | | | | | | | | | G--------------H | | | +-----Domain#3-----+ Figure 2: MeshMeshed Domain Connectivity In Figure 2, domains are connected in a mesh topology. There are multiple paths between nodes A and D, and these paths do not necessarily followcross the same set ofdomains. Indeed, ifIf inter-domain connectivity forms a mesh, domain level routing is required (even for the unprotected case). This is tightly coupled with the next hop domain resolution/discovery mechanisms.mechanisms used in IP networks. In this document, we assume that domain level routing is given via configuration, policy, or some external mechanism, and that this is not part of the path computation process described later in this document. In addition, domainDomain level routing may performalso allow "domain re-entry",re-entry" where a path entersre-enters a domain after the path exitsthat domainit has previously exited (e.g., domain#X-domain#Y-domain#X).domain#X- domain#Y-domain#X). This requires specific considerations when confidentiality is required(described in Section 3.2),3.2) is required, and is beyond the scope of this document. 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 document, we assume that the working LSP and recovery LSP follow the same set of domains in the same order (via configuration, policy or some external mechanism). That is, we assume that the domain mesh topology is reduced to a linear domain topology for each pair of working and recovery LSPs. In summary, - There is no assumption about the multi-domain network topology. For example, there could be more than two domain boundary nodes or inter-domain links (links connecting a pair of domain boundary nodes belonging to different domains). - However, thereIt is an assumptionassumed that under suchin a networkmulti-domain topology, the setsequence of domains that the working LSP and the recovery LSP follow must be the same and is pre-configured. - Domain re-entry is not considered. 2.2 Note on Domain Diversity As described in Section 1.4, domain diversity means the selection of paths that have only the ingress and egress domains in common. This may provide enhanced resilience against failures, and is a way to 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 follow the same set of domains in the same order. Under this assumption, domain diversity cannot be achieved. However, by relaxing this assumption, domain diversity could be achieved, e.g., by either of the following schemes. - Consider domain diversity as a special case of SRLG diversity (i.e., assign an SRLG ID to each domain). - Configure domain level routing to provide domain diverse paths (e.g., by means of AS_PATH in BGP). Details of the operation of domain diversity are beyond the scope of this document. 3. Factors to Consider 3.1 Scalability versusVersus Optimality As described in [RFC4726], scalability and optimality are two conflicting objectives. Note that the meaning of optimality differs depending on each network operation. Some examples of optimality in the context of diverse LSPs are: - Minimizing the sum of their cost while maintaining diversity. - Restricting the difference of their cost (socosts (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 (and not across domain boundaries) as required by RFC4105[RFC4105] and RFC4216,[RFC4216], it may not be possible to compute an optimal path. As such, it maymight not be possible to compute diverse paths, even if they exist. However, if we assume domain level routing is given (as discussed in Section 2), it is possible to compute diverse paths using specific computation schemes, if such paths exist. This is discussed in Section 4. 3.2 Key Concepts Three key concepts to classify various diverse LSP computation and setup schemes are presented below. o With or without confidentiality - Without confidentiality Under this network configuration, itIt is possible to specify a path across multiple domains in signaling (by means of the RSVP-TE Explicit Route Object - ERO - comprising a list of strict hops) or(ERO)), and to obtain record of the inter-domain path used (by means of the RSVP-TE Record Route Object - RRO) a route across other domains. Examples of(RRO)). In this configuration are multi-area networks, and some forms of multi-AS networks (especially withincase, 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 forms of multi-AS networks (especially within the same provider). In these cases, there is no requirement for confidentiality. - With confidentiality Under this network configuration,Where confidentiality of domain topology and operational policy is required, it is not possible to specify or obtain a full and strict route (by means of ERO/RRO)path across other domains, althoughdomains. Partial paths may be specified/obtained in the form of an ERO/RRO containing loose hops. Therefore, it is not possible to specifyspecified and reported using domain identifiers or obtain a full route atthe head-endaddresses of a multi-domain LSP.domain border routers in the EROs and RROs. Examples of this configuration are some forms of multi-AS networks (especially inter-provider networks), GMPLS-UNI networks, and L1VPNs. o Per domainMulti-domain path computation orcomputation, per-domain path computation, and inter-domain collaborative path computation - Per domainMulti-domain path computation InIf 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 scheme,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 domaindomain-by-domain as LSP signaling progresses through the network. This scheme requires ERO expansion in each domain.domain to construct the next segment of the path toward the destination. The case forestablishment of unprotected LSPs underin this schemeway is covered in [RFC5152]. - Inter-domain collaborative path computation In this scheme, path computation is typically done before signaling. This scheme typicallysignaling and uses communication between cooperating path computation elements (PCEs) [RFC4655].PCEs. An example of such a scheme is Backward Recursive Path Computation (BRPC) [brpc]. The use of BRPC for unprotected LSPs under this scheme is covered in [brpc]. Note that these are path computation techniques.[BRPC]. 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 ispossible to combine multiple path computation techniques (including using a different technique for the working and recovery LSPs), but details are beyond the scope of this document. o Sequential path computation or simultaneous path computation - Sequential path computation The path of the working LSP is computed (withoutwithout considering the recovery LSP),LSP, and then the path of the recovery LSP is computed. Typically, thisThis scheme is applicable when the recovery LSP is added later as a change ofto the service grade. But this scheme cangrade, but may also be applicableused when both ofthe working and recovery LSPs are established from the start. InUsing this scheme, diverse LSPsapproach it may not be correctly computed (without some form of re-optimization or recomputation technique)possible to find diverse paths for the LSPs in "trap" topologies. Furthermore, such sequential path computation approaches may preventreduce the selectionlikelihood of selecting an "optimal" solution with regards to a specific objective function. - Simultaneous path computation The path of the working LSP and the path of the recovery LSP are computed simultaneously. Typically, this scheme is applicable when both the working LSP and the recovery LSP are established together.In this scheme,scheme it is possible to avoid trap topologies. Furthermoreconditions and it may allow for achievingbe more possible to achieve an optimal results.result. Note that LSP setup with or without confidentiality is given as a per-domain configuration, while the choicesdepends on per- domain configuration. The choice of per-domain path computation or inter-domain collaborative path computation, and the choice between sequential path computation or simultaneous path computation maycan be a matter of choicedetermined for each individual pair of working/recovery LSPs. The analysis of various diverse LSP setup schemes is described in Sections 4 and 5, based on above criteria.the concepts set out above. Some other considerations, such as network topology-specific considerations, addressing considerations, and SRLG diversity are described in Sections 6, 7, and 8. 4. Diverse LSP Setup Schemes withoutWithout Confidentiality In the following, variousThis section examines schemes for diverse LSP setup are presentedbased on different path computation techniques assuming that there is no requirement for confidentiality between domains.domain confidentiality. Section 5 makes a similar examination of schemes where inter-domaindomain confidentiality is required. 4.1 Management Configuration Section 3.1 of[RFC4726] describes this path computation technique. Thetechnique where 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. 4.2 Head-endHead-End Path Computation (with multi-domain visibility)(With Multi-Domain Visibility) 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. 4.3 Per-domainPer-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 [RFC5152]. In this scheme, the explicit paths of the working and recovery LSPs are specified as the complete strict path inpaths through the source domain followed by oneeither of the following: - The complete list of boundary LSRs (oror domain identifiers, e.g.,identifiers (e.g., AS numbers) along the path.paths. - The boundary LSR for the source domain and theLSP destination. Thus, ERO expansion is neededin order to navigate each domain, the path must be expanded at each domain boundaries. Pathboundary, i.e. per-domain. This path computation is performed by,by the boundary LSR or by a PCE on behalf of, each domain boundary LSR. Forits behalf. There are two schemes for establishing diverse LSPs using per-domain computation, there are two specific schemes, whichcomputation. These are described inSections 4.3.1 and 4.3.2 respectively.4.3.2. 4.3.1 Sequential Path Computation As previously noted, the main issue with sequential path computation is that diverse paths cannot be guaranteed. Where a per-domain path computation scheme is applied, the computation of second path needs to be aware of the path used by the first path in order that path diversity can be attempted. The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details are as follows.used when the second path is signaled to report the details of the first path. 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 [RFC5152]. Also, assume that the routemechanism and should not be used for this purpose. The process for sequential path computation is as follows: - The working LSP is established using per-domain path computation as described in [RFC5152]. The path of the working LSP (full route)is available at the head-end through the RRO. o Path computation aspect When performingRSVP-TE RRO since domain confidentiality is not required. - The path computation (ERO expansion) forof the recovery LSP as it crosses eachacross the first domain boundary a pathis selected that avoidscomputed excluding the nodes/links/SRLGsresources used by the working path soLSP within that a diverse path is obtained. When path computation is performed bydomain. If a PCE on behalf of each domain boundary LSR,is used, the resources to avoidbe avoided can be communicatedpassed to athe PCE using the XRO extension [PCEP-XRO]Exclude Route Object (XRO) extensions to the PCE Protocol (PCEP)[PCEP-XRO], [PCEP]. o Signaling aspect In order that- The recovery LSP is now signaled across the computation noted above can be performed, each computation point must be aware offirst domain as usual, but the path of the working LSP. This information can be supplied in the XRO includedLSP is also conveyed in the Path message for recovery LSP.an RSVP-TE XRO. The XRO lists nodes, links and SRLGs that must be avoided by the LSP being signaled, and its contents are 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 could exist) because the first (working) LSP is established without consideration of the need for a diverse recovery LSP. Crankback [RFC4920] may be used in combination with this scheme in order to improveIt is possible modify the possibility of successful diverse LSP setup. Furthermore, re-optimizationpath of the working LSP andusing the crankback techniques [RFC4920] if the setup of the recovery LSP may be used to achieve fully diverse paths.is blocked or if some resources are shared. 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 maximal. 4.3.2 Simultaneous Path Computation o PathSimultaneous path computation aspect When signaling the working LSP,gives a better likelihood of finding a pair of diverse paths as the pathdiversity requirement forms part of not onlythe working LSP, but alsocomputation process. In per-domain path computation mechanisms there are several aspects to consider. Simultaneous path computation means that the paths of the working and recovery LSPLSPs are computed at the same time. Since we are considering per-domain path computation, these two paths must be computed at the boundary of each domain. The process for simultaneous path computation is computed. For example, in Figure 1, when node D receivesas follows: - The ingress LSR (or a Path message forPCE) computes a pair of diverse paths across the first domain. If a PCE is used, PCEP offers the ability to request disjoint paths. - The working LSP between nodes A and L, node D expandsis signaled across the ERO to reach domain#3. Atfirst domain as usual, but must carry with it the same time, node D computesrequirement for a disjoint recovery LSP and the information about the path already computed for the recovery LSP across the samefirst domain. In particular, the domain from node F to reach domain#3. The entryboundary node forused by the recovery LSP (node F) needs tomust be known by the entryreported. - Each domain boundary node for the working LSP (node D). In this example the path forrouter in turn computes a pair of disjoint paths across the next domain. The working LSP may be computed by node Dis signaled as D-E-domain#3,usual and the computed path forof the recovery LSP as F-G-domain#3. o Signaling aspect Two signaling features are neededis collected in order to make this scheme work.the signaling messages. - A mechanism is needed to signal, duringWhen the working LSP setup,has been set up, the entry boundary node to be used byfull path of the recovery LSP. This mechanism may grow in complexity asLSP is returned to the length ofhead-end LSR in the chain of domains grows, and assignaling messages for the interconnectivity ofworking LSP. This allows the domains becomes more complex. But it may be perfectly feasible in simpler topologies. - There must be a mechanismhead-end LSR to forcesignal the recovery LSP to follow the route computed above. One way to realize this is to haveusing a specific object (withfull path without the same format asneed for further path computation. Note that the ERO)signaling protocol mechanisms do not currently exist to collect the routepath of the recovery LSP in the Path message for the working LSP and to return is to the head-end induring the Resv message. Whensignaling the recovery LSP, the contentof the ERO is copied from this object. Protocol mechanisms to achieve these signaling features are not currently available. The definitionworking LSP. Definition of protocol extensions ismechanisms are beyond the scope of this document. This schemedocument, but it is believed that such mechanisms would be simple to define and implement. Note also cannot guaranteethat the mechanism described is still not able to establishguarantee the selection of diverse LSPs (even ifpaths even where they could exist) if thereexist since, when domains are more than two domain boundary nodes outmultiply interconnected, the determination of each domain.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. Note that even if a solution is found, the degree of optimality of the solution (i.e., of theset of diverse TE LSPs) might not be maximal. 4.4 Inter-domainInter-Domain Collaborative Path Computation Collaborative path computation requires the cooperation between PCEs that are responsible for different domains. This approach is described in Section 3.4 of [RFC4726] describes this approach, and [brpc] provides detail of[RFC4726]. Backward Recursive Path Computation which isrecursive path computation (BRPC) [BRPC] provides a collaborative path computation technique. Path computation is performed for each oftechnique where the working and recoverypaths of LSPs are fully determined by the use of inter-PCEcommunication between PCEs before each LSP is signaled. Therethe LSPs are two specific schemesestablished. Two ways to use BRPC for establishingdiverse LSPs using this scheme, whichare described in Sections 4.4.1 and 4.4.2.the following sections. 4.4.1 Sequential Path Computation Route exclusion using the XRO [PCEP-XRO] can be requested in PCEP [PCEP], and this can be used to compute theIn sequential path of a recovery LSP aftercomputation, the path of the working LSP has been determined. Details are as follows. The working LSPis computed using a collaborative PCE approach suchBRPC as thatdescribed in [brpc], and[BRPC]. The path of the recovery LSP may be immediately established. Assumeis then computed also using BRPC with the addition that the path of the working LSP (full route)is available from the computation request or from the RRO. o Path computation aspect When requesting path computation forexplicitly excluded using the recovery LSP, anXRO is includedroute exclusion techniques described in the PCEP path computation request message (see [PCEP-XRO]). The content of the XRO is copied from the RRO of[PCEP-XRO]. In this case, the working LSP. Alternatively,LSP could be set up before or after the contentpath of the XROrecovery LSP is copied from the ERO of the path computation reply forcomputed. In the working LSP. Thelatter 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 determinethe correctactual path forof the recoveryworking LSP (justas describedreported in [RFC4655] and [RFC4726] for the computation of a single inter-domain LSP by collaborating PCEs), and these PCEs exchangethe XRO information to ensure thatRSVP-TE RRO should be used when computing the computedpath is diverse fromof the working LSP. o Signaling aspect Therecovery LSP is signaled by including an ERO whose content is copied from the result returned by the PCE.LSP. This scheme cannot guarantee to establish diverse LSPs (even if they exist) because the working LSP may block the recovery LSP. In such a scenario, re-optimization of the working and recovery LSPs may be used to achieve fully diverse paths. 4.4.2 Simultaneous Path Computation o Path computation aspect The PCEP SVEC Object [PCEP] allows diverseIn simultaneous path computation to be requested. It would be possible to extend BRPC [brpc]computation, the PCEs collaborate to compute diverse paths throughthe definitionpaths of a specific process. Such extensions are beyond the scope of this document. o Signaling aspect In this scheme the PCE returns the full routes forboth the working and the recovery LSPs and theyat the same time. Since both LSPs are computed in a single pass, the LSPs can be signaled accordingly.simultaneously of sequentially according to the preference of the head-end LSR. Collaborative simultaneous path computation is achieved using the 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. This scheme can guarantee to establish diverse LSPs (ifwhere they exist),are possible, assuming that domain level routing is givenpre-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 In the context of this section, the term confidentiality applies to the protection of information about the topology and resources present within one domain from visibility by people or applications outside that domain. This includes, but is not limited to, recording of LSP routes, in addition toand the advertisements of TE information. The confidentiality does not apply to the protection of user traffic. Diverse LSP setup schemes with confidentiality are similar to ones without confidentiality. However, several additional mechanisms are needed to preserve confidentiality. Examples of such mechanisms are: - Path key: Provide each per-domainA path key is used in place of a segment of the path in advance to the domain boundary nodes or toof an LSP when the PCE that computedLSP is signaled, when the path for a limited periodof time (temporary caching) and identify it inthe signaled ERO using a path key. WhenLSP is reported by signaling, or when the LSP's path computationis donegenerated by PCE,a PCE. This allows the identifyexact path of the PCE containing state forLSP to remain confidential through the substitution of "confidential path maysegments" (CPSs) by these path keys. [PCE-PATH-KEY] describes how path keys can be required as well (e.g., PCE I-D).used by PCEs to preserve path confidentiality, and [RSVP-PATH-KEY] explains how path keys are used in signaling. Note that if path keys are signaled in RSVP-TE EROs they must be expanded so that the signaling can proceed. This expansion normally takes place when the first node in the CPS is reached. The expansion of the path key is providedwould normally be carried out by the PCE tothat generated the head-endkey, and for inclusion inthat reason, the ERO [conf-segment].path key contains an identifier of the PCE (the PCE-ID). - LSP segment: Pre-establish each per-domain segments of the path using hierarchical LSPs [RFC4206] orLSP stitchingsegments [RFC5150] and signal the end-to-endcan be pre-established across domains according to some management policy. The LSP segments can be used to use these per-domain LSPs. This scheme might need additional identifiers (suchsupport end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP IDs) in the Path message so thatstitching segments [RFC5150]. The end-to-end LSPs are signaled indicating just the series of domains or domain boundary node can identify whichborder routers. Upon entry to each domain an existing trans-domain LSP segment or tunnelis selected and used to usecarry the end-to- end LSP across the domain. 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. Furthermore, this schemeLSP at the domain border. It is also worth noting that in schemes that result in a single contiguous end-to-end LSP (without LSP tunneling or stitching) the same concept of LSP segments may require additional communication to pre-establishapply provided that ERO expansion is applied at domain boundaries and that the path of the LSP segments.is not reported in the RSVP-TE RRO. These techniques may be applied directly applied,or may be applied with extensions,require protocol extensions depending on the specific diverse LSP setup schemes described below. Note that in the schemes below, the paths of the working and recovery LSPs are not impacted by the confidentiality requirements. 5.1 Management Configuration It is not possible to obtain or specifyAlthough management systems may exist that can determine end-to-end paths even in the full explicit route for either LSP atpresence of domain confidentiality, the head-end due to confidentiality restrictions. Therefore, this informationfull paths cannot be provided to signalingthe head-end LSR for LSP setup. Confidentiality does not prevent the full computation of inter-domain paths andsignaling of sufficient information to distinguishas this would break the paths. Howeverconfidentiality requirements. Thus, for LSPs that are configured through management applications, the end-to-end path information for each domainmust either be provided in a wayconstructed using LSP segments that does not have meaning to other domains. Example mechanismscross the domains, or communicated to preserve confidentiality as described above, include: - Path key - LSP segmentthe head-end LSR with the use of path keys. 5.2 Head-endHead-End Path Computation (with multi-domain visibility) This scheme(With Multi-Domain Visibility) It is not applicable since multi-domain visibility violates confidentiality.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 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 AssumeIn sequential path computation, we can assume that the working LSP has its path computed and is establishedset up using the normal per-domain technique as described in [RFC5152]. It is not possible to obtain the routeHowever, because of the working LSP from the RRO at the head-end due toconfidentiality restrictions. In order to provide the path of the working LSP through each domain to the computation point responsible for computingissues, the full path of the protection LSP through each domain additional mechanisms are needed. Examples of such mechanisms are: - Information identifying theworking LSP is includednot returned in the Path messagesignaling messages and is not available to the head- end LSR. To compute a disjoint path for the recovery LSP, and theeach domain boundaryborder node consults the entity which computedneeds to know the path of the working LSP (i.e.,within the domain boundary node or PCE), sothat it provides entry to. This is easy for the diverse path can be computed. Wheningress LSR as it has access to the entity which computedRSVP-TE RRO within first domain. In subsequent domains, the process requires that the path of the working LSP is the PCE, PCE needssomehow made available to be temporarily stateful. An example of such information isthe Association Object [RFC4872]. 5.3.2 Simultaneous Path Computation In this schemedomain border router as the intentionrecovery LSP is to compute the path ofsignaled. Note that the working and recovery LSP atLSPs do not use the same time as the working LSP. In order to force the recovery LSP to followborder routers if the computed path as well as to preserve confidentiality, additional mechanismsLSPs are needednode or SRLG diverse. There are several possible mechanisms to communicate the computed recovery path fromachieve this. - Path keys could be used in the path ofRRO for the working LSP (where it was computed) to the recoveryLSP. Examples of such mechanisms, that must continue to preserve confidentiality, are as follows. - LSP segment:As described before. The LSP segment forthe recovery LSP is established domain-by-domain assignaling messages are propagated back towards the working LSP setup progresses. How to initiate such LSP segmentshead-end LSR, each domain border router substitutes a path key for the recovery LSP is beyond the scopesegment of this document. - Alternatively, information identifyingthe working LSP is included in the Path message for the recovery LSP, andLSP's path within its domain. Thus, the domain boundary node consultsRRO received at the entity which computedhead-end LSR consists of the path ofwithin the recovery LSP (i.e.,initial domain boundary node or PCE), so as to obtain the pathfollowed by a series of the recovery LSP. This requires that the entity which computed thepath ofkeys. When the recovery LSP is temporarily stateful. An example of such information is the Association Object [RFC4872]. Detailed protocol specifications are beyondsignaled, the scope of this document. 5.4 Inter-domain Collaborative Path Computation 5.4.1 Sequential Path Computation Route exclusion usingpath keys can be included in the XRO [PCEP-XRO]ERO as exclusions. Each domain border router in combination withturn can expand the path key [conf-segment] canfor its domain and know which resources must be requested inavoided. PCEP [PCEP] and thisprovides a protocol that can be used to computerequest the pathexpansion of a recovery LSP afterthe path ofkey from the working LSP has been determined. Details aredomain border router used by the working LSP, or from some third party such as follows. Thea PCE. - Instead of using path keys, each confidential path segment in the RRO of the working LSP is computedcould be encrypted by the domain border routers. These encrypted segments would appear as describedexclusions in [brpc] withthe help of path key [conf-segment],ERO for the recovery LSP and maycould be immediately established. It is not possible to obtaindecrypted by the RROdomain border routers. No mechanism currently exists in RSVP-TE for this function which would probably assume a domain-wide encryption key. - The identity of the working LSP (full route) atcould be included in the head-end dueXRO of the recovery LSP to confidentiality restrictions. o Path computation aspectindicate that a disjoint path must be found. This is similaroption could require a simple extension to the case without confidentiality (Section 4.4.1), but in ordercurrent XRO specification [RFC4874] to preserve confidentiality, additional mechanisms are needed. Inallow LSP identifiers to be included. It could also use the Association Object [RFC4872] to identify the working LSP. This scheme would also need a way for a domain border router to find the PCEPpath computation requestof an LSP within its domain. An efficient way to achieve this would be to also include the domain border router used by the working LSP in the signaling for the recovery LSP, an XRObut other schemes based on management applications or stateful PCEs might also be developed. Clearly, the details of this alternative have not been specified. 5.3.2 Simultaneous Path Computation In per-domain simultaneous path computation the path of the recovery LSP is included.computed at the same time as the working LSP (i.e., as the working LSP is signaled). The contentcomputed path of the XROrecovery LSP is copied frompropagated to the EROhead-end LSR as part of the path computation replysignaling process for the working LSP, whichbut confidentiality must be maintained, so the full path cannot be returned. There are two options as follows. - LSP segment: As the signaling of the working LSP progresses and the path of the recovery LSP is given incomputed domain-by-domain, trans-domain LSPs can be set up for use by the recovery LSP. When the recovery LSP is signaled, it will pick up these LSP segments and use them for tunneling or stitching. 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]. Furthermore, when the recovery LSP is signaled it needs to be sure to pick up the correct LSP segment. Therefore some form of strict hopsLSP segment identifier needs to be reported in the signaling of the working LSP and propagated in the signaling of the recovery LSP. Mechanisms for this do not currently exist, but would be relatively simple to construct. Alternatively, the LSP segments could be marked as providing protection for the local domain, domain boundaries or domain identifiers, andworking 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 keys. When a PCE receives XRO containing one or moreis signaled each path keys, it needskey is expanded, domain-by-domain to retrieveachieve the correct path. This requires that the entity that computes the original content and performpath computation forof the recovery LSP excluding certain nodes/links/SRLGs. It(domain border LSR or PCE) is likely thatstateful. 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 content (i.e., expansion)path of the path key cannot be directly retrieved byworking LSP is determined first using a PCE in onemechanism such as BRPC. Since domain from a PCEconfidentiality is in another domain since that act would violateuse, the intended confidentiality. Thus,path key expansion andreturned may contain path keys. When the computation of apath across a domain must both be performed within that domain. o Signaling aspect The full route forof the recovery LSP can not be returned to the head-end by PCE because it cannotis computed (which may be collected from the other PCEs owing to confidentiality restrictions. In order to forcebefore or after the recoveryworking LSP is signaled) the path exclusions supplied to followthe PCE and exchanged between PCEs must use path computed above, additional mechanisms are needed. Examples of such mechanisms arekeys as described before: - Path key - LSP segmentin [PCEP-XRO]. 5.4.2 Simultaneous Path Computation As described in Section 4.4.2, diverse path computation can be requested byusing the PCEP SVEC Object [PCEP], and [brpc] canBRPC could be extended for inter-domain diverse path computation. However, it is not possible for PCE to return the full route of the working LSP and recovery LSP 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 forto conform to domain confidentiality requirements, path keys must be used in the workingpaths returned by the PCEs and recovery LSPs.signaled by RSVP-TE. Note that the LSP segment approach in Section 5may not be applicable here because a path cannot be determined until BRPC procedures are completed. 6. Network Topology Specific Considerations In some specific network topologies, diverse LSP setuptopologies the schemes mentioned abovefor setting up diverse LSPs could be drasticallysignificantly simplified. For example, assume there are onlyconsider the L1VPN or GMPLS UNI case. This may be viewed as a linear sequence of three domains connected linearly, andwhere the first and thelast domaindomains contain only a single node. Assume that we need to establish diverse LSPs from the node in the first domain to thenode in the last domain.each. In such a scenario, no BRPC procedures are needed, because there is no need for path computation in the first and last domains.domains even if the source and destination nodes are multi-homed. 7. Addressing Considerations All of the above-mentionedschemes described in this document are applicable when a single address space is used across all domains. However, there couldThere may also be cases where private addressesaddress spaces are used within some of the domains. This caseproblem is similar to the one with confidentiality,use of domain confidentiality since the ERO and RRO are meaningless outside a domain even if they are available. This document does not exclude other schemes, but details are beyondavailable, and the scope of this document.problem can be solved using the same techniques. 8. Note on SRLG Diversity The above-mentionedschemes described in this document are applicable when the nodes and links in different domains belong to different SRLGs. However, there could be cases whereSRLGs which is normally the case. However, it is possible that nodes andor links in different domains belong to the same SRLG. That is, where SRLGsan SRLG may span domain boundaries. In such cases, in order to establish SRLG diverse LSPs, several considerations are needed, such as:needed: - Record of the SRLGs used by the working LSP. - Indication of a set of SRLGs to exclude in the computation of the 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, and might not have global meaning. In such a scenario, some mapping functions are necessary, similar to the mapping of other TE parameters mentioned in Section 1.2. 9. IANA Considerations This informational document makes no requests for IANA action. 10. 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).makes no requests for IANA action. 10. Security Considerations The core protocols used to achieve the procedures described in this document are RSVP-TE [RFC3209]and PCEP [PCEP]PCEP. These protocols include policy and authentication capabilities,capabilities as described in [RFC3209] and [PCEP]. Furthermore, these protocols may be operated using more advanced security features such as IPsec [RFC4301] and TLS [RFC4346]. Security may be regarded as particularly important in inter-domain deployments and serious consideration should be seriously consideredgiven to applying the available security techniques as described in all inter- domain deployments.the documents referenced above and as set out in [RFC4726]. More discussion on security considerations in MPLG/GMPLS networks is found in a specific document [security-fw].[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.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. [RFC4216] Zhang, R., and Vasseur, JP., "MPLS Inter-Autonomous System (AS) Traffic Engineering (TE) Requirements", RFC 4216, November 2005 [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 Framework for Inter-Domain MPLS Traffic Engineering", RFC 4726, November 2006. 11.2 Informative References [RFC3812] Srinivasan, C., Viswanathan, A., and Nadeau, T., "Multiprotocol Label Switching (MPLS) Traffic 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, "Requirements for Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi- ProtocolMulti-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI): Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Support for the Overlay Model", RFC 4208, October 2005. [RFC4216] Zhang, R.,[RFC4301] Kent, S., Seo, K., "Security Architecture for the Internet Protocol," December 2005. [RFC4346] Dierks, T., and Vasseur, J.-P., "MPLS Inter- Autonomous System (AS) Traffic Engineering (TE) Requirements",Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4216, November 20054346, [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 Computation Element (PCE) Architecture", RFC 4655, August 2006. [RFC4802] Nadeau, T., and Farrel, A., "Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base", February 2007. [RFC4847] Takeda, T., Ed., "Framework and Requirements for Layer 1 Virtual Private Networks", RFC 4847, April 2007. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D. (Eds.), "RSVP-TE Extensions in support of End-to- EndEnd-to-End Generalized Multi-Protocol Label Switching (GMPLS)-based(GMPLS)- based Recovery", RFC 4872, May 2007. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Based Segment Recovery", RFC 4873, May 2007. [RFC4874] Lee, C.Y., Farrel, A., and De Cnodder, S., "Exclude Routes - Extension to Resource ReserVation Protocol-TrafficProtocol- Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. [RFC4920] Farrel, A., Ed., "Crankback Signaling Extensions for 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 (GMPLS TE)", RFC 5150, February 2008. [RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur,"Inter-Domain MPLS and GMPLS Traffic Engineering -- Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R.Zhang, R., "A Per-Domain Path Computation Method for Establishing Inter-Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, February 2008. [brpc][BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based Computation (BRPC) procedure to compute shortest inter-domain Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc, work in progress. [conf-segment][PCE-PATH-KEY] Bradford, R., Ed.,Vasseur, JP., and Farrel, A, "Preserving Topology Confidentiality in Inter-Domain Path Computation usingUsing a key based mechanism ", draft-ietf-pce- path-key,Key Based Mechanism", draft-ietf-pce-path-key, work in progress. [PCEP] Vasseur, JP., Ed., and Le Roux, JL., Ed., "Path Computation Element (PCE) communication Protocol (PCEP)", draft-ietf-pce-pcep, work in progress. [PCEP-XRO] Oki, E.,E. and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", draft-ietf-pce-pcep-xro, work in progress. [security-fw][RSVP-PATH-KEY] Bradford, R., Vasseur, JP., and Farrel, A., "RSVP 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-gmpls-security-draft-ietf-mpls-mpls-and-gmpls-security- framework, work in progress. 12. Acknowledgments AuthorsThe authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro Fujihara, Dimitri Papadimitriou, and Meral Shirazipour for valuable comments. Deborah Brungard provided useful advice about the text. 13. Authors' Addresses Tomonori Takeda NTT Network Service Systems Laboratories, NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email : email@example.com Yuichi Ikejiri NTT Communications Corporation Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku Tokyo 163-1421, Japan Email: firstname.lastname@example.org Adrian Farrel Old Dog Consulting Email: email@example.com Jean-Philippe Vasseur Cisco Systems, Inc. 300 Beaver Brook Road Boxborough , MA - 01719 USA Email: firstname.lastname@example.org Intellectual Property Consideration The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.