Network Working Group                                     T. Takeda, Ed.
Internet Draft                                                       NTT
Intended Status: Informational                               Y. Ikejiri                            A. Farrel, Ed.
Created March 24th, 2008                             NTT Communications
Expires: September 24th, April 13, 2008                                 A. Farrel                                Old 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.txt

         draft-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 realize

   Protection 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) recovery Paths (LSPs) in multi-domain networks based on the existing
   framework environments. 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................................................4 Scope................................................5
   1.4 Note on Other Recovery Techniques.............................5 Techniques.............................6
   1.5 Signaling Options.............................................6
   2. Diversity in Multi-domain Multi-Domain Networks.............................6
   2.1 Multi-domain Multi-Domain Network Topology.................................6
   2.2 Note on Domain Diversity......................................8
   3. Factors to Consider............................................8 Consider............................................9
   3.1 Scalability versus Optimality.................................8 Versus Optimality.................................9
   3.2 Key Concepts..................................................9
   4. Diverse LSP Setup Schemes without Without Confidentiality.............11
   4.1 Management Configuration.....................................11
   4.2 Head-end Head-End Path Computation (with multi-domain visibility).....11 (With Multi-Domain Visibility).....12
   4.3 Per-domain Per-Domain Path Computation..................................11 Computation..................................12
   4.3.1 Sequential Path Computation................................12
   4.3.2 Simultaneous Path Computation..............................12 Computation..............................13
   4.4 Inter-domain Inter-Domain Collaborative Path Computation..................13 Computation..................14
   4.4.1 Sequential Path Computation................................14 Computation................................15
   4.4.2 Simultaneous Path Computation..............................14 Computation..............................15
   5. Diverse LSP Setup Schemes with With Confidentiality................15
   5.1 Management Configuration.....................................16 Configuration.....................................17
   5.2 Head-end Head-End Path Computation (with multi-domain visibility).....16 (With Multi-Domain Visibility).....17
   5.3 Per-Domain Path Computation..................................16 Computation..................................17
   5.3.1 Sequential Path Computation................................16 Computation................................17
   5.3.2 Simultaneous Path Computation..............................17 Computation..............................18
   5.4 Inter-domain Inter-Domain Collaborative Path Computation..................17 Computation..................19
   5.4.1 Sequential Path Computation................................17 Computation................................19
   5.4.2 Simultaneous Path Computation..............................18 Computation..............................20
   6. Network Topology Specific Considerations......................18 Considerations......................20
   7. Addressing Considerations.....................................19 Considerations.....................................20
   8. Note on SRLG Diversity........................................19 Diversity........................................20
   9. IANA Considerations...........................................19 Considerations ..........................................21
   10. Security Considerations......................................19 Considerations......................................21
   11. References...................................................20 References...................................................21
   11.1 Normative References........................................20 References........................................21
   11.2 Informative References......................................20 References......................................22
   12. Acknowledgments..............................................22 Acknowledgments..............................................24
   13. Authors' Addresses...........................................22 Addresses...........................................24

1. Introduction

   This document analyzes various schemes to realize

   Protection and recovery in 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 are described in [RFC4428]. These
   are important features for this document is on establishing end-to-end
   diverse Traffic Engineering (TE) LSPs service delivery in multi-domain MPLS and GMPLS
   networks. It
   presents various diverse LSP setup schemes based on existing
   functional elements.

1.1 Terminology

   The reader is assumed

   MPLS 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 following GMPLS networks are several key terminologies used within this
   document.

   - Domain: See [RFC4726]. A
   being 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 out  Examples of scope. Section 1.2 provides some more
     details.

   - Working LSP: See such domains include
   Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes).

   [RFC4726] provides a framework for inter-domain MPLS and GMPLS
   traffic engineering. It introduces and discusses the various schemes
   and processes to establish Label Switched Paths (LSPs) in multi-
   domain environments.

   However, protection and recovery introduce additional complexities to
   LSP establishment. Protection LSPs are generally required to path
   diverse from the working LSPs that they protect. Achieving this is
   particularly challenging in multi-domain environments because no
   single path computation or planning point is capable of determining
   both paths from one end to the other.

   This document analyzes various schemes to realize MPLS and GMPLS
   LSP recovery in multi-domain networks. The main focus for this
   document is on establishing end-to-end diverse Traffic Engineering
   (TE) LSPs in multi-domain networks.

1.1 Terminology

   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
     transport
     also carry user traffic even when the working LSP is operating
     normally and transporting
     normal the user traffic (e.g., 1+1 protection). In such a scenario,
     the
     The 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. Those The 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 applies Confidentiality refers to the
     protection of information about the topology and resources
     present within
     of one domain from visibility by people or applications outside
     that domain.

1.2 Domain

   As defined

   In order to fully understand the issues addressed in [RFC4726], a domain this document,
   it is necessary to carefully define and scope the term "domain".

   As defined in [RFC4726], a domain is considered to be any collection
   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 of motivations for using more than one domain usage include
   administrative separation, scalability, and forming the 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 could may be performed needed 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 Generalized MPLS (GMPLS) and GMPLS LSP
   recovery in multi-
   domain networks multi-domain networks. It is based on the existing
   framework for multi-domain LSP setup [RFC4726]. Note that this
   document does not intend to prevent 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 show shows how the existing
   framework techniques 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 the

   The main focus of this document is the analysis of diverse TE LSP
   (hereafter LSP)
   setup schemes (path computation and signaling
   aspects), which that can advantageously be used in the context of end-to-
   end end-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 analysis
   The 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 be
   are various types of diversity, and this document focuses on
   node/link/SRLG node,
   link, and shared risk link group (SRLG) diversity.

   Based on

   Recovery LSPs may be used for 1+1 protection, 1:1 protection, or
   shared mesh restoration. However, the service grade, both requirements for path
   diversity, the working LSP ways to compute diverse paths, and the recovery LSP
   may be established at the time signaling of service establishment (e.g.,
   service requiring high resiliency). Alternatively,
   these TE LSPs are common across all uses, and these topics are the recovery LSP
   main 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/SRLG the 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 diverse LSP 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, the

   The recovery type of an LSP or service may change at a domain
   boundary. That is, the recovery type could remain the same within one
   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-specific option considerations for Fast Reroute and
   segment recovery are described in Section 5 of [RFC5151].

2. Diversity in Multi-domain 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 section describes some assumptions about achieving path
   diversity in this problem space made in this
   document. multi-domain networks.

2.1 Multi-domain Multi-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: Mesh Meshed 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 follow cross
   the same set of domains.

   Indeed, if If 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, domain

   Domain level routing may perform also allow "domain re-entry", re-entry" where a path enters
   re-enters a domain after the path exits that domain it 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, there It is an assumption assumed that under such in a network multi-domain topology, the set sequence 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 versus Versus 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 (so costs (for example, so as to
     minimize the delay difference after switch-over) while maintaining
     diversity.

   By restricting TE information distribution to only within each domain
   (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 may might 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, it

       It 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 within case, it is clear
       that one domain has control over the path followed in another
       domain, and that the path actually used in one domain is visible
       from within another domain.

       Examples of this configuration are multi-area networks, and some
       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, although domains. Partial paths may be specified/obtained in the
       form of an ERO/RRO containing loose hops. Therefore, it is not
       possible to specify specified and reported
       using domain identifiers or obtain a full route at the head-end addresses 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 domain Multi-domain path computation or computation, per-domain path computation, and
     inter-domain collaborative path computation

     - Per domain Multi-domain path computation

       In

       If a single network element can see the topology of all domains
       along the path, it is able to compute a full end-to-end path.
       Clearly this 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 domain domain-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 for establishment of unprotected
       LSPs under in this scheme way is covered in [RFC5152].

     - Inter-domain collaborative path computation

       In this scheme, path computation is typically done before
       signaling. This scheme typically
       signaling 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 is possible 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 (without without considering the
       recovery LSP), LSP, and then the path of the recovery LSP is computed.
       Typically, this
       This scheme is applicable when the recovery LSP is added later as
       a change of to the service grade. But this scheme can grade, but may also be applicable used when both of the
       working and recovery LSPs are established from the start. In

       Using this scheme, diverse LSPs approach 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 prevent reduce the selection likelihood 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. Furthermore conditions and it may allow for achieving be 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 choices depends 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 may can be a
   matter of choice
   determined 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 without Without Confidentiality

   In the following, various

   This section examines schemes for diverse LSP setup are presented based 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-domain domain confidentiality is required.

4.1 Management Configuration

   Section 3.1 of

   [RFC4726] describes this path computation technique.
   The technique 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-end Head-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-domain 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
   [RFC5152].

   In this scheme, the explicit paths of the working and recovery LSPs
   are specified as the complete strict path in paths through the source domain
   followed by one either of the following:

   - The complete list of boundary LSRs (or or domain identifiers, e.g., identifiers (e.g., AS
     numbers) along the path. paths.

   - The boundary LSR for the source domain and the LSP destination.

   Thus, ERO expansion is needed in order to navigate each domain, the path must be expanded at
   each domain boundaries. Path boundary, 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.

   For its behalf.

   There are two schemes for establishing diverse LSPs using per-domain computation, there are
   two specific schemes, which
   computation. These are described in Sections 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 route mechanism 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 performing RSVP-TE RRO since domain confidentiality
     is not required.

   - The path computation (ERO expansion) for of the recovery LSP as it crosses each across the first domain boundary a path is selected that
     avoids computed
     excluding the nodes/links/SRLGs resources used by the working path so LSP within that a
     diverse path is obtained. When path computation is performed by domain.
     If a PCE on behalf of each domain boundary LSR, is used, the resources to avoid be avoided can be communicated passed to a the
     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 of first domain as usual,
     but the path of the working LSP.
     This information can be supplied in the XRO included LSP 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
   improve It is possible
   modify the possibility of successful diverse LSP setup. Furthermore,
   re-optimization path of the working LSP and using 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 Path

   Simultaneous path computation aspect
     When signaling the working LSP, gives a better likelihood of finding a
   pair of diverse paths as the path diversity requirement forms part of not only the working
     LSP, but also
   computation 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 LSP LSPs 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 receives as follows:

   - The ingress LSR (or a Path message for PCE) 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 expands is signaled across the ERO to reach domain#3. At first domain as usual, but
     must carry with it the same time, node D computes requirement for a disjoint recovery LSP and
     the information about the path already computed for the recovery
     LSP across the same first domain. In particular, the domain from node F to reach domain#3. The entry boundary
     node for used by the recovery LSP (node F) needs to must be known by the entry reported.

   - Each domain boundary node for the working LSP (node D). In this example the
     path for router in turn computes a pair of disjoint
     paths across the next domain. The working LSP may be computed by node D is signaled as D-E-domain#3, usual
     and the computed path for of the recovery LSP as F-G-domain#3.

   o Signaling aspect

     Two signaling features are needed is collected in order to make this scheme
     work. the
     signaling messages.

   - A mechanism is needed to signal, during When the working LSP setup, has been set up, the
       entry boundary node to be used by full path of the recovery LSP. This
       mechanism may grow in complexity as
     LSP is returned to the length of head-end LSR in the chain of
       domains grows, and as signaling messages for
     the interconnectivity of working LSP. This allows the domains
       becomes more complex. But it may be perfectly feasible in simpler
       topologies.

     - There must be a mechanism head-end LSR to force signal the
     recovery LSP to follow the
       route computed above. One way to realize this is to have using a
       specific object (with full path without the same format as need for further path
     computation.

   Note that the ERO) signaling protocol mechanisms do not currently exist to
   collect the
       route path of the recovery LSP in the Path message for the working LSP
       and to return is to the head-end in during 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
   working LSP. Definition of protocol extensions is mechanisms are beyond the scope
   of this document.

   This scheme document, but it is believed that such mechanisms would be
   simple to define and implement.

   Note also cannot guarantee that the mechanism described is still not able to establish guarantee
   the selection of diverse LSPs (even if paths even where they could exist) if there exist since, when
   domains are more than two domain boundary nodes
   out multiply 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 the set of diverse TE LSPs) might not be maximal.

4.4 Inter-domain Inter-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 is recursive path
   computation (BRPC) [BRPC] provides a collaborative path computation technique. Path computation is
   performed for each of
   technique where the working and recovery paths of LSPs are fully determined by the use of
   inter-PCE
   communication between PCEs before each LSP is signaled.

   There the LSPs are two specific schemes established. Two ways
   to use BRPC for establishing diverse LSPs using
   this scheme, which are 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 the

   In sequential path of a recovery LSP
   after computation, the path of the working LSP has been determined. Details are as
   follows.

   The working LSP is
   computed using a collaborative PCE approach such BRPC as that described in [brpc], and [BRPC]. The path of the recovery
   LSP may be immediately
   established. Assume is 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 for explicitly excluded using the recovery LSP, an XRO is
     included route
   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 content
   path of the XRO recovery LSP is copied from
     the ERO of the path computation reply for computed. In the working LSP. The latter case is useful when the working LSP is not established at
     the time of the path computation request for the recovery LSP. The
     computation request specifies that the full route must be returned.
     Per-domain PCEs may need to be invoked by the first PCE that is
     consulted in order to collaboratively determine the correct actual
   path
     for of the recovery working LSP (just as described reported 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 RSVP-TE RRO should be used
   when computing the computed path is diverse from of the working LSP.

   o Signaling aspect

     The recovery 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 diverse

   In simultaneous path computation to be
     requested. It would be possible to extend BRPC [brpc] computation, the PCEs collaborate to compute
     diverse paths through the definition
   paths 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 for both the working and the recovery LSPs and they at 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 (if where they exist), are
   possible, assuming that domain level routing is given pre-determined as
   described in Section 2. Furthermore, the computed set of TE LSPs can
   be guaranteed to be optimal with respect to some objective functions.

5. Diverse LSP Setup Schemes with Confidentiality

   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 to and 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-domain A path key is used in place of a segment of the path in advance to
     the domain boundary nodes or to of
     an LSP when the PCE that computed LSP is signaled, when the path for
     a limited period of time (temporary caching) and identify it in the
     signaled ERO using a path key. When LSP is
     reported by signaling, or when the LSP's path computation is done generated by
     PCE, a
     PCE. This allows the identify exact path of the PCE containing state for LSP to remain confidential
     through the substitution of "confidential path may segments" (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 provided
     would normally be carried out by the PCE to that generated the head-end key,
     and for inclusion in that 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] or LSP stitching segments
     [RFC5150] and signal the end-to-end can 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 (such support end-to-end LSPs as hierarchical LSPs [RFC4206] or as LSP
     IDs) in the Path message so that
     stitching segments [RFC5150].

     The end-to-end LSPs are signaled indicating just the series of
     domains or domain boundary node can
     identify which border routers. Upon entry to each domain an
     existing trans-domain LSP segment or tunnel is selected and used to use carry 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 scheme LSP 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-establish apply 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 specify

   Although management systems may exist that can determine end-to-end
   paths even in the full explicit route for
   either LSP at presence of domain confidentiality, the head-end due to confidentiality restrictions.
   Therefore, this information full paths
   cannot be provided to signaling the head-end LSR for LSP
   setup.

   Confidentiality does not prevent the full computation of inter-domain
   paths and signaling of sufficient information to distinguish as this
   would break the
   paths. However confidentiality requirements.

   Thus, for LSPs that are configured through management applications,
   the end-to-end path information for each domain must either be provided
   in a way constructed using LSP segments
   that does not have meaning to other domains. Example
   mechanisms cross the domains, or communicated to preserve confidentiality as described above, include:

   - Path key
   - LSP segment the head-end LSR with the
   use of path keys.

5.2 Head-end Head-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

   Assume

   In sequential path computation, we can assume that the working LSP
   has its path computed and is established set up using the normal per-domain
   technique as described in [RFC5152].

   It is not possible to obtain the route However, because of the working LSP from the
   RRO at the head-end due to
   confidentiality restrictions. In order to
   provide the path of the working LSP through each domain to the
   computation point responsible for computing issues, the full path of the
   protection LSP through each domain additional mechanisms are needed.
   Examples of such mechanisms are:

   - Information identifying the working LSP is included not
   returned in the Path
     message signaling messages and is not available to the head-
   end LSR.

   To compute a disjoint path for the recovery LSP, and the each domain boundary border
   node consults
     the entity which computed needs to know the path of the working LSP (i.e., within the domain
     boundary node or PCE), so that
   it provides entry to. This is easy for the diverse path can be computed.
     When ingress LSR as it has
   access to the entity which computed RSVP-TE RRO within first domain. In subsequent domains,
   the process requires that the path of the working LSP is the
     PCE, PCE needs somehow made
   available to be temporarily stateful. An example of such
     information is the Association Object [RFC4872].

5.3.2 Simultaneous Path Computation

   In this scheme domain border router as the intention recovery LSP is to compute the path of
   signaled. Note that the working and recovery
   LSP at LSPs do not use the same time as the working LSP. In order to force the
   recovery LSP to follow
   border routers if the computed path as well as to preserve
   confidentiality, additional mechanisms LSPs are needed node or SRLG diverse.

   There are several possible mechanisms to communicate the
   computed recovery path from achieve this.

   - Path keys could be used in the path of RRO for the working LSP (where it was
   computed) to the recovery LSP. Examples of such mechanisms, that must
   continue to preserve confidentiality, are as follows.

   - LSP segment: As described before. The LSP segment for the recovery
     LSP is established domain-by-domain as
     signaling messages are propagated back towards the working LSP setup
     progresses. How to initiate such LSP segments head-end LSR,
     each domain border router substitutes a path key for the recovery LSP
     is beyond the scope segment of this document.

   - Alternatively, information identifying
     the working LSP is included
     in the Path message for the recovery LSP, and LSP's path within its domain. Thus, the domain boundary
     node consults RRO received at
     the entity which computed head-end LSR consists of the path of within the recovery
     LSP (i.e., initial domain boundary node or PCE), so as to obtain the path
     followed by a series of the recovery LSP. This requires that the entity which computed
     the path of keys.

     When the recovery LSP is temporarily stateful. An example of
     such information is the Association Object [RFC4872]. Detailed
     protocol specifications are beyond signaled, the scope of this document.

5.4 Inter-domain Collaborative Path Computation

5.4.1 Sequential Path Computation

   Route exclusion using path keys can be included in
     the XRO [PCEP-XRO] ERO as exclusions. Each domain border router in combination with turn can
     expand the path key [conf-segment] can for its domain and know which resources must be requested in
     avoided. PCEP [PCEP] and this provides a protocol that can be used to compute request the path
     expansion of a recovery LSP after the path of key from the
   working LSP has been determined. Details are domain border router used by the
     working LSP, or from some third party such as follows.

   The a PCE.

   - Instead of using path keys, each confidential path segment in the
     RRO of the working LSP is computed could be encrypted by the domain border
     routers. These encrypted segments would appear as described exclusions in [brpc] with the help of
   path key [conf-segment],
     ERO for the recovery LSP and may could be immediately established. It is
   not possible to obtain decrypted by the RRO domain
     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) at could be included in the
   head-end due XRO of the
     recovery LSP to confidentiality restrictions.

   o Path computation aspect indicate that a disjoint path must be found.

     This is similar option could require a simple extension to the case without confidentiality (Section
     4.4.1), but in order current XRO
     specification [RFC4874] to preserve confidentiality, additional
     mechanisms are needed.

     In allow 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 PCEP path computation request of 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 XRO but 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 content computed path of the XRO recovery LSP is copied from
   propagated to the ERO head-end LSR as part of the
     path computation reply signaling process for
   the working LSP, which but 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 in computed 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 hops LSP
     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, and working LSP. In this case the recovery LSP can
     be signaled with the identifier of the working LSP using the
     Association Object [RFC4872] enabling the correct LSP segments to
     be selected.

   - Path key: The path of the recovery LSP can be determined and
     returned to the head-end LSR just described in Section 4.4.2, but
     each CPS is replaced by a path key. As the recovery path keys. When a PCE receives XRO
     containing one or more is
     signaled each path keys, it needs key is expanded, domain-by-domain to retrieve achieve the
     correct path. This requires that the entity that computes the original
     content and perform path computation for
     of the recovery LSP excluding
     certain nodes/links/SRLGs. It (domain border LSR or PCE) is likely that stateful.

5.4 Inter-Domain Collaborative Path Computation

   Cooperative collaboration between PCEs is also applicable when domain
   confidentiality is required.

5.4.1 Sequential Path Computation

   In sequential cooperative path computation the content (i.e.,
     expansion) path of the path key cannot be directly retrieved by working
   LSP is determined first using a PCE in
     one mechanism such as BRPC. Since domain from a PCE
   confidentiality is in another domain since that act would
     violate use, the intended confidentiality. Thus, path key expansion and returned may contain path keys.

   When the computation of a path across a domain must both be performed
     within that domain.

   o Signaling aspect

     The full route for of the recovery LSP can not be returned to the
     head-end by PCE because it cannot is computed (which may be collected from the other PCEs
     owing to confidentiality restrictions. In order to force before or
   after the
     recovery working LSP is signaled) the path exclusions supplied to follow
   the PCE and exchanged between PCEs must use path computed above, additional
     mechanisms are needed. Examples of such mechanisms are keys as described
     before:

     - Path key
     - LSP segment in
   [PCEP-XRO].

5.4.2 Simultaneous Path Computation

   As described in Section 4.4.2, diverse path computation can be
   requested by using the PCEP SVEC Object [PCEP], and [brpc] can BRPC 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 for to
   conform to domain confidentiality requirements, path keys must be
   used in the working paths returned by the PCEs and recovery LSPs. signaled by RSVP-TE.

   Note that the LSP segment approach in Section 5 may 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 setup topologies the schemes
   mentioned above for setting up
   diverse LSPs could be drastically significantly simplified.

   For example, assume there are only consider the L1VPN or GMPLS UNI case. This may be viewed
   as a linear sequence of three domains connected linearly,
   and where the first and the last domain
   domains contain only a single node. Assume
   that we need to establish diverse LSPs from the node in the first
   domain to the node 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-mentioned schemes described in this document are applicable when a
   single address space is used across all domains.

   However, there could

   There may also be cases where private addresses address spaces are used within
   some of the domains. This case problem 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 beyond available, and the scope of this document. problem can be solved
   using the same techniques.

8. Note on SRLG Diversity

   The above-mentioned schemes described in this document are applicable when the nodes
   and links in different domains belong to different SRLGs.

   However, there could be cases where SRLGs which is
   normally the case.

   However, it is possible that nodes and or links in different domains
   belong to the same SRLG. That is, where SRLGs an 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 considered given 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-
                       Protocol Multi-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 2005 4346,
   [RFC4428]        D. Papadimitriou, Ed., "Analysis of Generalized
                    Multi-Protocol Label Switching (GMPLS)-based
                    Recovery Mechanisms (including Protection and
                    Restoration)", RFC 4428, March 2006.

   [RFC4655]        Farrel, A., Vasseur, JP., and J. Ash, "Path
                    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-
                       End End-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-Traffic Protocol-
                    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
                       using Using 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

   Authors

   The 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 : takeda.tomonori@lab.ntt.co.jp

   Yuichi Ikejiri
   NTT Communications Corporation
   Tokyo Opera City Tower 3-20-2 Nishi Shinjuku, Shinjuku-ku
   Tokyo 163-1421, Japan
   Email: y.ikejiri@ntt.com
   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk

   Jean-Philippe Vasseur
   Cisco Systems, Inc.
   300 Beaver Brook Road
   Boxborough , MA - 01719
   USA
   Email: jpv@cisco.com

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 ietf-ipr@ietf.org.

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.