Network Working Group                              Tomonori                                    T. Takeda, Ed.
Internet Draft                                                      NTT
Intended Status: Informational                           Yuichi                               Y. Ikejiri
Expires:
Created March 24th, 2008                             NTT Communications
                                                          Adrian
Expires: September 24th, 2008                                 A. Farrel
                                                     Old Dog Consulting
                                                  Jean-Philippe
                                                            JP. Vasseur
                                                    Cisco Systems, Inc.

                                                         September 2007

        Analysis of Inter-domain Label Switched Path (LSP) Recovery
          draft-ietf-ccamp-inter-domain-recovery-analysis-02.txt
          draft-ietf-ccamp-inter-domain-recovery-analysis-03.txt

Status of this Memo

   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 Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
   (LSP) recovery in multi-domain networks based on the existing
   framework for multi-domain LSPs.

   The main focus for this document is on establishing end-to-end
   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
   presents various diverse LSP setup schemes based on existing
   functional elements.

Table of Contents

   1. Introduction...................................................2 Introduction...................................................3
   1.1 Terminology...................................................3
   1.2 Domain........................................................4
   1.3 Document Scope................................................4
   1.4 Note on Other Recovery Techniques.............................5
   1.5 Signaling Options.............................................6
   2. Diversity in Multi-domain Networks.............................6
   2.1 Multi-domain Network Topology.................................6
   2.2 Note on Domain Diversity......................................8
   3. Factors to Consider............................................8
   3.1 Scalability versus Optimality.................................8
   3.2 Key Concepts..................................................9
   4. Diverse LSP Setup Schemes without Confidentiality.............11
   4.1 Management Configuration.....................................11
   4.2 Head-end Path Computation (with multi-domain visibility).....11
   4.3 Per-domain Path Computation..................................11
   4.3.1 Sequential Path Computation................................12
   4.3.2 Simultaneous Path Computation..............................12
   4.4 Inter-domain Collaborative Path Computation..................13
   4.4.1 Sequential Path Computation................................14
   4.4.2 Simultaneous Path Computation..............................14
   5. Diverse LSP Setup Schemes with Confidentiality................15
   5.1 Management Configuration.....................................16
   5.2 Head-end Path Computation (with multi-domain visibility).....16
   5.3 Per-Domain Path Computation..................................16
   5.3.1 Sequential Path Computation................................16
   5.3.2 Simultaneous Path Computation..............................17
   5.4 Inter-domain Collaborative Path Computation..................17
   5.4.1 Sequential Path Computation................................17
   5.4.2 Simultaneous Path Computation..............................18
   6. Network Topology Specific Considerations......................18
   7. Addressing Considerations.....................................19
   8. Note on SRLG Diversity........................................19
   9. Security Considerations.......................................19 IANA Considerations...........................................19
   10. Security Considerations......................................19
   11. References...................................................20
   10.1
   11.1 Normative References........................................20
   10.2
   11.2 Informative References......................................20
   11. Acknowledgments..............................................22
   12. Acknowledgments..............................................22
   13. Authors' Addresses...........................................22
   Intellectual Property Consideration..............................23
   Full Copyright Statement.........................................23

1. Introduction

   This document analyzes various schemes to realize Multiprotocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS) Label Switched Path
   (LSP) recovery in multi-domain networks based on the existing
   framework for multi-domain LSPs.

   The main focus for this document is on establishing end-to-end
   diverse Traffic Engineering (TE) LSPs in multi-domain networks. It
   presents various diverse LSP setup schemes based on existing
   functional elements.

1.1 Terminology

   The reader is assumed to be familiar with the terminology in
   [RFC4726] that provides a framework for inter-domain Label Switched
   Path (LSP) setup, and [RFC4427] that provides terminology for LSP
   recovery.

   The following are several key terminologies 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 some more
     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 user traffic even when the working LSP is transporting
     normal user traffic (e.g., 1+1 protection). In such a scenario,
     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)).
     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 two diverse LSPs are
     referred to as the working LSP and recovery LSP hereafter.
     Sometimes, diversity is referred to as disjointness.

   - Confidentiality: See [RFC4216]. 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.

1.2 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) 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 domain usage include administrative separation,
   scalability, and forming protection domains.

   As described in [RFC4726], there could be TE parameters (such as
   color and priority) whose meanings are specific to each domain. In
   such scenarios, mapping functions could be performed 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) LSP recovery in multi-
   domain networks based on the existing framework for multi-domain LSP
   setup [RFC4726]. Note that this document does not intend to prevent
   development of additional techniques where appropriate (i.e.,
   additional to ones described in this document, which are based on the
   existing framework described in [RFC4726]). In other words, this
   document is informational and intends to show how the existing
   framework can be applied with specific procedures described in this
   document and the documents referred to by this document.

   There are various recovery techniques for LSPs. For TE LSPs, major
   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 main focus is the analysis of diverse TE LSP
   (hereafter LSP) setup schemes (path computation and signaling
   aspects), which can advantageously be used in the context of 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 of diverse LSPs in
   multi-domain networks, and this document provides more detailed
   analysis based on that content.

   [RFC4105] and [RFC4216] describe requirements for diverse LSPs. There
   could be various types of diversity, and this document focuses on
   node/link/SRLG diversity.

   Based on the service grade, both the working LSP and the recovery LSP
   may be established at the time of service establishment (e.g.,
   service requiring high resiliency). Alternatively, the recovery LSP
   may be added later due to a change in the grade of the service. This
   document covers both scenarios. Also, there may or may not be
   confidentiality requirements among domains. This document covers both
   scenarios. Section 3.2 describes more details on confidentiality.

   Specific assumptions made in this problem space are described in
   Section 2.

   Note that the recovery LSP may be used for 1+1 protection, 1:1
   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, 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 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.

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 [inter-domain-rsvp]. [RFC5151]. This document does not cover
   any additional analysis for Fast ReRoute and segment recovery in
   multi-domain networks.

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

2. Diversity in Multi-domain Networks

   As described in Section 1.3, analysis of diverse LSP setup schemes in
   multi-domain networks is the main focus of this document. This
   section describes some assumptions in this problem space made in this
   document.

2.1 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 Connectivity
                           +-----Domain#2-----+
                           |                  |
                           | E--------------F |
                           | |              | |
                           | |              | |
                           +-+--------------+-+
                             |              |
                             |              |
                 +--Domain#1-+--+   +-------+------+
                 |           |  |   |       |      |
                 |           |  |   |       |      |
                 |      A----B--+---+--C----D      |
                 |      |       |   |  |           |
                 |      |       |   |  |           |
                 +------+-------+   +--+-Domain#4--+
                        |              |
                      +-+--------------+-+
                      | |              | |
                      | |              | |
                      | G--------------H |
                      |                  |
                      +-----Domain#3-----+

                     Figure 2: Mesh 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 the same set of domains.

   Indeed, 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.

   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 level routing may perform "domain re-entry",
   where a path enters a domain after the path exits that domain (e.g.,
   domain#X-domain#Y-domain#X). This requires specific considerations
   when confidentiality is required (described in Section 3.2), 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 is an assumption that under such a network topology,
     the set of domains that the working LSP and the recovery LSP follow
     must be the same and 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 are beyond the scope of this document.

3. Factors to Consider

3.1 Scalability 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 as to minimize 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 and
   RFC4216, it may not be possible to compute an optimal path. As such,
   it may not be possible to compute diverse paths, even if they exist.
   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 is possible to specify (by
       means of the Explicit Route Object - ERO - comprising a list of
       strict hops) or obtain record of (by means of the Record Route
       Object - RRO) a route across other domains.

       Examples of this configuration are multi-area networks, and some
       forms of multi-AS networks (especially within the same provider).

     - With confidentiality

       Under this network configuration, it is not possible to specify
       or obtain a full and strict route (by means of ERO/RRO) across
       other domains, although paths may be specified/obtained in the
       form of an ERO/RRO containing loose hops. Therefore, it is not
       possible to specify or obtain a full route at the head-end of a
       multi-domain LSP.

       Examples of this configuration are some forms of multi-AS
       networks (especially inter-provider networks), GMPLS-UNI
       networks, and L1VPNs.

   o Per domain path computation or inter-domain collaborative path
     computation

     - Per domain path computation

       In this scheme, a path is computed domain by domain as LSP
       signaling progresses through the network. This scheme requires
       ERO expansion in each domain. The case for unprotected LSPs under
       this scheme is covered in [inter-domain-pd]. [RFC5152].

     - Inter-domain collaborative path computation
       In this scheme, path computation is typically done before
       signaling. This scheme typically uses communication between
       cooperating path computation elements (PCEs) [RFC4655]. 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. 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 considering the
       recovery LSP), and then the path of the recovery LSP is computed.
       Typically, this scheme is applicable when the recovery LSP is
       added later as change of the service grade. But this scheme can
       also be applicable when both of the working and recovery LSPs are
       established from the start. In this scheme, diverse LSPs may not
       be correctly computed (without some form of re-optimization or
       recomputation technique) in "trap" topologies. Furthermore, such
       sequential path computation approaches may prevent the selection
       of 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, it is possible to avoid trap
       topologies. Furthermore it may allow for achieving more optimal
       results.

   Note that LSP setup with or without confidentiality is given as a
   per-domain configuration, while the choices of per-domain path
   computation or inter-domain collaborative path computation, and
   sequential path computation or simultaneous path computation may be a
   matter of choice 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.

   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 Confidentiality

   In the following, various schemes for diverse LSP setup are presented
   based on different path computation techniques assuming that there is
   no requirement for confidentiality between domains. Section 5 makes a
   similar examination of schemes where inter-domain confidentiality is
   required.

4.1 Management Configuration

   Section 3.1 of [RFC4726] describes this path computation technique.
   The full explicit paths for the working and recovery LSPs are
   specified by a management application at the head-end, and no further
   computation or signaling considerations are needed.

4.2 Head-end Path Computation (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 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
   [inter-domain-pd].
   [RFC5152].

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

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

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

   Thus, ERO expansion is needed at domain boundaries. Path computation
   is performed by, or by a PCE on behalf of, each domain boundary LSR.

   For establishing diverse LSPs using per-domain computation, there are
   two specific schemes, which are described in Sections 4.3.1 and 4.3.2
   respectively.

4.3.1 Sequential Path Computation

   The RSVP-TE EXCLUDE_ROUTE Object (XRO) [RFC4874] can be used. Details
   are as follows. It should be noted that the PRIMARY_PATH_ROUTE Object
   defined in [RFC4872] for end-to-end protection is not intended as a
   path exclusion mechanism.

   Assume that the working LSP is established as described in [inter-
   domain-pd]. [RFC5152].
   Also, assume that the route of the working LSP (full route) is
   available at the head-end through the RRO.

   o Path computation aspect

     When performing path computation (ERO expansion) for the recovery
     LSP as it crosses each domain boundary a path is selected that
     avoids the nodes/links/SRLGs used by the working path so that a
     diverse path is obtained. When path computation is performed by a
     PCE on behalf of each domain boundary LSR, the resources to avoid
     can be communicated to a PCE using the XRO extension [PCEP-XRO] to
     the PCE Protocol (PCEP) [PCEP].

   o Signaling aspect

     In order that the computation noted above can be performed, each
     computation point must be aware of the path of the working LSP.
     This information can be supplied in the XRO included in the Path
     message for recovery LSP. 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.

   This scheme cannot guarantee to establish diverse LSPs (even if they
   could exist) because the first 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 the possibility of successful diverse LSP setup. Furthermore,
   re-optimization of the working LSP and the recovery LSP may be used
   to achieve fully diverse paths.

   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 computation aspect
     When signaling the working LSP, the path of not only the working
     LSP, but also the recovery LSP is computed. For example, in
     Figure 1, when node D receives a Path message for the working LSP
     between nodes A and L, node D expands the ERO to reach domain#3. At
     the same time, node D computes a path for the recovery LSP across
     the same domain from node F to reach domain#3. The entry boundary
     node for the recovery LSP (node F) needs to be known by the entry
     boundary node for the working LSP (node D). In this example the
     path for the working LSP may be computed by node D as D-E-domain#3,
     and the path for recovery LSP as F-G-domain#3.

   o Signaling aspect

     Two signaling features are needed in order to make this scheme
     work.

     - A mechanism is needed to signal, during working LSP setup, the
       entry boundary node to be used by the recovery LSP. This
       mechanism may grow in complexity as the length of the chain of
       domains grows, and as the interconnectivity of the domains
       becomes more complex. But it may be perfectly feasible in simpler
       topologies.

     - There must be a mechanism to force the recovery LSP to follow the
       route computed above. One way to realize this is to have a
       specific object (with the same format as the ERO) to collect the
       route of the recovery LSP in the Path message for the working LSP
       and to return is to the head-end in the Resv message. When
       signaling the recovery LSP, the content of the ERO is copied from
       this object.

     Protocol mechanisms to achieve these signaling features are not
     currently available. The definition of protocol extensions is
     beyond the scope of this document.

   This scheme also cannot guarantee to establish diverse LSPs (even if
   they could exist) if there are more than two domain boundary nodes
   out of each domain. 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 Collaborative Path Computation

   Section 3.4 of [RFC4726] describes this approach, and [brpc] provides
   detail of Backward Recursive Path Computation which is a
   collaborative path computation technique. Path computation is
   performed for each of the working and recovery LSPs by the use of
   inter-PCE communication before each LSP is signaled.

   There are two specific schemes for establishing diverse LSPs using
   this scheme, which are described in Sections 4.4.1 and 4.4.2.

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 path of a recovery LSP
   after the path of the working LSP has been determined. Details are as
   follows.

   The working LSP is computed using a collaborative PCE approach such
   as that described in [brpc], and the LSP may be immediately
   established. Assume that the path of the working LSP (full route) is
   available from the computation request or from the RRO.

   o Path computation aspect

     When requesting path computation for the recovery LSP, an XRO is
     included in the PCEP path computation request message (see
     [PCEP-XRO]). The content of the XRO is copied from the RRO of the
     working LSP. Alternatively, the content of the XRO is copied from
     the ERO of the path computation reply for the working LSP. The
     latter case is useful when the working LSP is not established at
     the time of the path computation request for the recovery LSP. The
     computation request specifies that the full route must be returned.
     Per-domain PCEs may need to be invoked by the first PCE that is
     consulted in order to collaboratively determine the correct path
     for the recovery LSP (just as described in [RFC4655] and [RFC4726]
     for the computation of a single inter-domain LSP by collaborating
     PCEs), and these PCEs exchange the XRO information to ensure that
     the computed path is diverse from the working LSP.

   o Signaling aspect

     The recovery LSP is signaled by including an ERO whose content is
     copied from the result returned by the PCE.

   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 path computation to be
     requested. It would be possible to extend BRPC [brpc] to compute
     diverse paths through the definition 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 the working and
     recovery LSPs and they are signaled accordingly.

   This scheme can guarantee to establish diverse LSPs (if they exist),
   assuming domain level routing is given 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 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 segment of the path in advance to
     the domain boundary nodes or to the PCE that computed the path for
     a limited period of time (temporary caching) and identify it in the
     signaled ERO using a path key. When path computation is done by
     PCE, the identify of the PCE containing state for the path may be
     required as well (e.g., PCE I-D). The path key is provided by the
     PCE to the head-end for inclusion in the ERO [conf-segment].

   - LSP segment: Pre-establish each per-domain segments of the path
     using hierarchical LSPs [RFC4206] or LSP stitching segments
     [LSP-stitch]
     [RFC5150] and signal the end-to-end LSP to use these per-domain
     LSPs. This scheme might need additional identifiers (such as LSP
     IDs) in the Path message so that the domain boundary node can
     identify which LSP segment or tunnel to use for the end-to-end LSP.
     Furthermore, this scheme may require additional communication to
     pre-establish the LSP segments.

   These techniques may be directly applied, or may be applied with
   extensions, depending on 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 the full explicit route for
   either LSP at the head-end due to confidentiality restrictions.
   Therefore, this information cannot be provided to signaling for LSP
   setup.

   Confidentiality does not prevent the full computation of inter-domain
   paths and signaling of sufficient information to distinguish the
   paths. However the path information for each domain must be provided
   in a way that does not have meaning to other domains. Example
   mechanisms to preserve confidentiality as described above, include:

   - Path key
   - LSP segment

5.2 Head-end Path Computation (with multi-domain visibility)

   This scheme is not applicable since multi-domain visibility violates
   confidentiality.

5.3 Per-Domain Path Computation

5.3.1 Sequential Path Computation

   Assume the working LSP is established as described in [inter-domain-
   pd]. [RFC5152].

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

   - Information identifying the working LSP is included in the Path
     message for the recovery LSP, and the domain boundary node consults
     the entity which computed the path of the working LSP (i.e., domain
     boundary node or PCE), so that the diverse path can be computed.
     When the entity which computed the path of the working LSP is the
     PCE, PCE needs to be temporarily stateful. An example of such
     information is the Association Object [RFC4872].

5.3.2 Simultaneous Path Computation

   In this scheme the intention is to compute the path of the recovery
   LSP at the same time as the working LSP. In order to force the
   recovery LSP to follow the computed path as well as to preserve
   confidentiality, additional mechanisms are needed to communicate the
   computed recovery path from the path of 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 the working LSP setup
     progresses. How to initiate such LSP segments for the recovery LSP
     is beyond the scope of this document.

   - Alternatively, information identifying the working LSP is included
     in the Path message for the recovery LSP, and the domain boundary
     node consults the entity which computed the path of the recovery
     LSP (i.e., domain boundary node or PCE), so as to obtain the path
     of the recovery LSP. This requires that the entity which computed
     the path of the recovery LSP is temporarily stateful. An example of
     such information is the Association Object [RFC4872]. Detailed
     protocol specifications are beyond the scope of this document.

5.4 Inter-domain Collaborative Path Computation

5.4.1 Sequential Path Computation

   Route exclusion using the XRO [PCEP-XRO] in combination with the path
   key [conf-segment] can be requested in PCEP [PCEP] and this can be
   used to compute the path of a recovery LSP after the path of the
   working LSP has been determined. Details are as follows.

   The working LSP is computed as described in [brpc] with the help of
   path key [conf-segment], and may be immediately established. It is
   not possible to obtain the RRO of the working LSP (full route) at the
   head-end due to confidentiality restrictions.

   o Path computation aspect

     This is similar to the case without confidentiality (Section
     4.4.1), but in order to preserve confidentiality, additional
     mechanisms are needed.

     In the PCEP path computation request for the recovery LSP, an XRO
     is included. The content of the XRO is copied from the ERO of the
     path computation reply for the working LSP, which is given in the
     form of strict hops for the local domain, domain boundaries or
     domain identifiers, and path keys. When a PCE receives XRO
     containing one or more path keys, it needs to retrieve the original
     content and perform path computation for the recovery LSP excluding
     certain nodes/links/SRLGs. It is likely that the content (i.e.,
     expansion) of the path key cannot be directly retrieved by a PCE in
     one domain from a PCE in another domain since that act would
     violate the intended confidentiality. Thus, path key expansion and
     the computation of a path across a domain must both be performed
     within that domain.

   o Signaling aspect

     The full route for the recovery LSP can not be returned to the
     head-end by PCE because it cannot be collected from the other PCEs
     owing to confidentiality restrictions. In order to force the
     recovery LSP to follow the path computed above, additional
     mechanisms are needed. Examples of such mechanisms are as described
     before:

     - Path key
     - LSP segment

5.4.2 Simultaneous Path Computation

   As described in Section 4.4.2, diverse path computation can be
   requested by PCEP SVEC Object [PCEP], and [brpc] can 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 the working and recovery LSPs.

   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 schemes
   mentioned above could be drastically simplified.

   For example, assume there are only three domains connected linearly,
   and the first and the last domain contain only a single node. Assume
   that we need to establish diverse LSPs from the node in the first
   domain to the node in the last domain. In such a scenario, no BRPC
   procedures are needed, because there is no need for path computation
   in the first and last domains.

7. Addressing Considerations

   All of the above-mentioned schemes are applicable when a single
   address space is used across all domains.

   However, there could be cases where private addresses are used within
   some of the domains. This case is similar to the one with
   confidentiality, since the ERO and RRO are meaningless even if they
   are available. This document does not exclude other schemes, but
   details are beyond the scope of this document.

8. Note on SRLG Diversity

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

   However, there could be cases where the nodes and links in different
   domains belong to the same SRLG. That is, where SRLGs span domain
   boundaries. In such cases, in order to establish SRLG diverse LSPs,
   several considerations are needed, such as:

   - 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.

   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).

   RSVP-TE [RFC3209] and PCEP [PCEP] include policy and authentication
   capabilities, and these should be seriously considered in all inter-
   domain deployments.

   More discussion on security considerations in MPLG/GMPLS networks is
   found in a specific document [security-fw].

10.

11. References

10.1

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.

   [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.

   [RFC4427]           Mannie, E., Ed.

11.2 Informative References

   [RFC4090]           Pan, P., Swallow, G., and D. Papadimitriou, Ed.,
                       "Recovery (Protection A. Atlas, "Fast
                       Reroute Extensions to RSVP-TE for LSP Tunnels",
                       RFC 4090, May 2005.

   [RFC4105]           Le Roux, J.-L. , Vasseur, J.-P., and Restoration)
                       Terminology 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)", (GMPLS) Traffic
                       Engineering (TE)", RFC 4427, March 2006.

10.2 Informative References 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.

   [RFC4847]           Takeda, T., Ed., "Framework

   [RFC4216]           Zhang, R., and Requirements for
                       Layer 1 Virtual Private Networks", Vasseur, J.-P., "MPLS Inter-
                       Autonomous System (AS) Traffic Engineering (TE)
                       Requirements", RFC 4847,
                       April 2007. 4216, November 2005

   [RFC4655]           Farrel, A., Vasseur, JP., and J. Ash, "Path
                       Computation Element (PCE) Architecture",
                       RFC 4655, August 2006.

   [RFC4847]           Takeda, T., Ed., "Framework and Requirements for
                       Layer 1 Virtual Private Networks", RFC 4847,
                       April 2007.

   [RFC4872]           Lang, J., Rekhter, Y., and Papadimitriou, D.
                       (Eds.), "RSVP-TE Extensions in support of End-to-
                       End Generalized Multi-Protocol Label Switching
                       (GMPLS)-based Recovery", RFC 4872, May 2007.

   [RFC4090]           Pan, P., Swallow, G., and A. Atlas, "Fast
                       Reroute Extensions to RSVP-TE for LSP Tunnels",
                       RFC 4090, May 2005.

   [RFC4873]           Berger, L., Bryskin, I., Papadimitriou, D., and
                       A. Farrel, "GMPLS Based Segment Recovery",
                       RFC 4873, May 2007.

   [RFC4105]           Le Roux, J.-L. , Vasseur, J.-P., and J. Boyle,
                       "Requirements for Inter-Area MPLS Traffic
                       Engineering", RFC 4105, June 2005.

   [RFC4216]           Zhang, R., and Vasseur, J.-P., "MPLS Inter-
                       Autonomous System (AS) Traffic Engineering (TE)
                       Requirements", RFC 4216, November 2005

   [inter-domain-rsvp] Farrel, A., Ed., "Inter domain Multiprotocol
                       Label Switching (MPLS) and Generalized MPLS
                       (GMPLS) Traffic Engineering - RSVP-TE
                       extensions", draft-ietf-ccamp-inter-domain-rsvp-
                       te, work in progress.

   [RFC4874]           Lee, C.Y., Farrel, A., and De Cnodder, S.,
                       "Exclude Routes - Extension to Resource
                       ReserVation Protocol-Traffic Engineering
                       (RSVP-TE)", RFC 4874, April 2007.

   [inter-domain-pd]   Vasseur JP.,

   [RFC4920]           Farrel, A., Ed., "Crankback Signaling Extensions
                       for MPLS and Ayyangar 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, "A Per-
                       domain path computation method Per-Domain Path Computation Method for establishing
                       Inter-domain
                       Establishing Inter-Domain Traffic Engineering
                       (TE) Label Switched Paths (LSPs)", draft-ietf-ccamp-inter-
                       domain-pd-path-comp, work in progress. RFC 5152,
                       February 2008.

   [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.

   [PCEP-XRO]          Oki, E., and A. Farrel, "Extensions to the Path
                       Computation Element Communication Protocol (PCEP)
                       for Route Exclusions", draft-ietf-pce-pcep-xro,
                       work in progress.

   [PCEP]              Vasseur, JP., Ed., and  Le Roux, JL., Ed., "Path
                       Computation Element (PCE) communication Protocol
                       (PCEP)", draft-ietf-pce-pcep, work in progress.

   [conf-segment]      Bradford, R., Ed., "Preserving Topology
                       Confidentiality in Inter-Domain Path Computation
                       using a key based mechanism ", draft-ietf-pce-
                       path-key, work in progress.

   [RFC4920]           Farrel, A.,

   [PCEP]              Vasseur, JP., Ed., "Crankback Signaling Extensions
                       for MPLS and GMPLS RSVP-TE ", RFC 4920,
                       July 2007.

   [RFC4206]           Kompella, K. and Y. Rekhter, "Label Switched
                       Paths (LSP) Hierarchy with Generalized Multi-  Le Roux, JL., Ed., "Path
                       Computation Element (PCE) communication Protocol Label Switching (GMPLS) Traffic
                       Engineering (TE)", RFC 4206, October 2005.

   [LSP-stitch]        Ayyangar, A., Kompella, K., Vasseur, JP.,
                       (PCEP)", draft-ietf-pce-pcep, work in progress.

   [PCEP-XRO]          Oki, E., and A. Farrel, "Label Switched "Extensions to the Path Stitching with
                       Generalized Multiprotocol Label Switching Traffic
                       Engineering (GMPLS TE)", draft-ietf-ccamp-lsp-
                       stitching,
                       Computation Element Communication Protocol (PCEP)
                       for Route Exclusions", draft-ietf-pce-pcep-xro,
                       work in progress.

   [security-fw]       Fang, L., " Security Framework for MPLS and GMPLS
                       Networks", draft-fang-mpls-gmpls-security-
                       Framework, draft-ietf-mpls-mpls-gmpls-security-
                       framework, work in progress.

11.

12. Acknowledgments

   Authors would like to thank Eiji Oki, Ichiro Inoue, Kazuhiro
   Fujihara, Dimitri Papadimitriou Papadimitriou, and Meral Shirazipour for valuable
   comments.

12.

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 (2007). (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.