CCAMP Working Group                                   Zafar Ali Ali, Ed.
   Internet Draft                                   George Swallow Swallow, Ed.
   Intended status: Standard Track                    Clarence Filsfils
   Expires: August 2, 2014                                 Matt Hartley
                                               Gabriele Maria Galimberti                        Cisco Systems
                                                             Ori Gerstel
                                                      SDN Solutions Ltd.
                                                            Kenji Kumaki
                                                        KDDI Corporation
                                                          Ruediger Kunze
                                                     Deutsche Telekom AG
                                                           Julien Meuric
                                                   France Telecom Orange
                                                        February
   Expires: January 3, 2015                               F. Zhang, Ed.
                                                                 Huawei
                                                         D. Beller, Ed.
                                                         Alcatel-Lucent
                                                           July 4, 2014

       Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
                         Diversity using Exclude Route

                     draft-ietf-ccamp-lsp-diversity-03.txt

                     draft-ietf-ccamp-lsp-diversity-04.txt

   Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on August 2, 2014. January 3, 2015.

   Copyright Notice

   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal Provisions
   Relating to IETF Documents (http://trustee.ietf.org/license-info)
   in effect on the date of publication of this document.  Please
   review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License
   text as described in Section 4.e of the Trust Legal Provisions
   and are provided without warranty as described in the Simplified
   BSD License.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt      draft-ietf-ccamp-lsp-diversity-04.txt

   Abstract

   RFC 4874 specifies methods by which path exclusions may be
   communicated during RSVP-TE signaling in networks where precise
   explicit paths are not computed by the LSP source node. This
   document specifies signaling procedures for additional route exclusion
   subobjects
   subobject based on Paths currently existing or expected to exist
   within the network.

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   Table of Contents

   1. Introduction ................................................2 ............................................... 2
         1.1. Client Initiated Identifier ........................ 5
         1.2. PCE allocated Identifiers .......................... 6
         1.3. UNI-N allocated Identifiers ........................ 7
   2. RSVP-TE signaling extensions.................................4 extensions ............................... 9
         2.1. Terminology..........................................4
         2.2. Path Diversity XRO Subobjects..................................5
   2.2.1. IPv4 Point-to-Point Subobject ............................ 9
         2.1.1. Tunnel identifier TLVs ........................... 12
         2.1.2. Path subobject...................... 5
   2.2.2. IPv6 Point-to-Point Key TLVs .................................... 14
         2.1.3. Path subobject...................... 8
         2.3. Affinity Set TLVs ........................... 16
         2.2. Processing rules for the Path Diversity XRO subobjects.........9
         2.4. subobject ... 19
         2.2.1. Processing rules for the tunnel identifier TLVs .. 20
         2.2.2. Processing rules for the Path Key TLVs ........... 22
         2.2.3. Processing rules for the PAS TLVs ................ 23
         2.3. Diversity EXRS Subobject.................................12 Subobject ........................... 25
   3. Security Considerations.....................................13 Considerations .................................... 27
   4. IANA Considerations.........................................13
         4.1. New XRO subobject types.............................13
         4.2. New EXRS subobject types............................14
         4.3. New RSVP error sub-codes............................14
   5. Acknowledgements............................................14 Considerations ........................................ 27
   6. References..................................................14 References ................................................. 28
         6.1. Normative Reference.................................14 References ............................... 28
         6.2. Informative References..............................15 References ............................. 29

   1. Introduction

      Path diversity for multiple connections is a well-known requirement from Service Providers.
      Such diversity ensures Label-Switched
      Provider requirement. Diversity constraints ensure that Label-
      Switched Paths (LSPs) may be established without sharing

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      resources, thus greatly reducing the probability of simultaneous
      connection failures.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

    When a source node has full topological knowledge and is permitted
    to signal an Explicit Route Object, Object (ERO), diverse paths can be
    computed locally. However, there are scenarios when path
    computations are performed by remote nodes, thus there is a need for
    relevant diversity requirements constraints to be communicated to those nodes.
    These include (but are not limited to):

      .  LSPs with loose hops in the Explicit Route Object (ERO), ERO, e.g. inter-domain LSPs;

      .  Generalized Multi-Protocol Label Switching (GMPLS) User-
        Network Interface (UNI) where path computation may be performed
        by the (server layer) core node [RFC4208].

      [RFC4874] introduced a means of specifying nodes and resources to
      be excluded from a route, using the eXclude Route Object (XRO) and
      Explicit Exclusion Route Subobject (EXRS).

      [RFC4874] It facilitates the
      calculation of diverse paths for LSPs based on known properties of
      those paths including addresses of links and nodes traversed, and
      Shared Risk Link Groups (SRLGs) of traversed links. Employing
      these mechanisms requires that the source node that initiates
      signaling knows the relevant properties of the path(s) from which
      diversity is desired. However, there are circumstances under which
      this may not be possible or desirable, including (but not limited
      to):

      .  Exclusion of a path which does not originate, terminate or
         traverse the source node signaling the diverse LSP, in which
         case the addresses and SRLGs of the path from which diversity
         is required are unknown to the source node.

      .  Exclusion of a path which is known to the source node of the
         diverse LSP, however the node has incomplete or no path
         information, e.g. due to policy. In other words, the scenario
         in which the reference path is known by the source / requesting
         node but the properties required to construct an XRO object are
         not fully known. Inter-domain and GMPLS overlay networks can
         present such restrictions.

      This document defines procedures that may be used to exclude the
      path taken by a particular LSP, or the paths taken by all LSPs
      belonging to a single tunnel. The diversity requirements
      considered in this document do not require that the paths in
      question belong to the same tunnel or share the same source or
      destination node.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

      If mutually diverse paths are desired for two LSPs belonging to
      different tunnels, it is recommended that they be signaled with
      XRO LSP subobjects referencing each other. The processing rules
      specified exemplified in this document cover this case.

      The means by which the node calculating or expanding the route of
      the signaled LSP discovers the route of the path(s) Figure 1, where overlay reference
      model from which
      the signaled LSP requires diversity are beyond the scope of this
      document.

      This document addresses only the exclusion of point-to-point
      paths. Exclusion of point-to-multipoint paths [RFC4208] is beyond the scope
      of this document.

   2. RSVP-TE signaling extensions shown.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      Overlay                                                  Overlay

      Network          +----------------------------------+    Network
    +---------+     |                                  |     +---------+
    |  +----+ |     |  +-----+    +-----+    +-----+   |     | +----+  |
    |  |    | | UNI |  |     |    |     |    |     |   | UNI | |    |  |
    | -+ EN1+-+-----+--+ CN1 +----+ CN2 +----+ CN3 +---+-----+-+ EN3+- |
    |  |    | |  +--+--+     |    |     |    |     |   | +---+-|    |  |
    |  +----+ |  |  |  +--+--+    +--+--+    +--+--+   | |   | +----+  |
    +---------+  |  |     |          |          |      | |   +---------+
                 |  |     |          |          |      | |
    +---------+  |  |  +--+--+       |       +--+--+   | |   +---------+
    |  +----+ |  |  |  |     |       +-------+     +-----+   | +----+  |
    |  |    +-+--+  |  | CN4 +---------------+ CN5 |   |     | |    |  |
    | -+ EN2+-+-----+--+     |               |     +---+-----+-+ EN4+- |
    |  |    | | UNI |  +-----+               +-----+   | UNI | |    |  |
    |  +----+ |     |                                  |     | +----+  |
    +---------+     +----------------------------------+     +---------+
      Overlay                 Core Network                     Overlay
      Network                                                  Network

                           Legend:   EN  -  Edge Node
                                     CN  -  Core Node

                  Figure 1:  Overlay Reference Model [RFC4208]

      Figure 1 depicts two types of UNI connectivity: single-homed and
      dual-homed ENs (which also applies to higher order multi-homed
      connectivity.). Single-homed Edge Node (EN) devices are connected
      to a single Core Node (CN) device via a single UNI link. This section describes
      single UNI link may constitute a single point of failure. UNI
      connection between EN1 and CN1 is an example of singled-homed UNI
      connectivity.

      A single point of failure caused by a single-homed UNI can be
      avoided when the EN device is connected to two different CN
      devices, as depicted for EN2 in Figure 1. For the dual-homing
      case, it is possible to establish two different UNI connections
      from the same source EN device to the same destination EN device.
      For example, two connections from EN2 to EN3 may use the two UNI
      links EN2-CN1 and EN2-CN4. To avoid single points of failure
      within the provider network, it is necessary to also ensure path
      (LSP) diversity within the core network.

      In Figure 1, the CNs typically performs path computation.
      Information sharing across the UNI boundary is restricted based
      on the policy rules imposed by the core network. Typically, the

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      core network topology information is not exposed to the ENs. In
      such networks, consider a use case where an LSP from EN2 to EN4
      needs to be SRLG diverse from an LSP from EN1 to EN3. In this
      case, EN2 may not know SRLG attributes of the EN1- EN3 LSP and
      hence cannot construct an XRO to exclude these SRLGs. In this
      example EN2 cannot use procedures described in [RFC4874].
      Similarly, in the context of dual-homed UNI example described
      above, an LSP from EN2 to EN3 going via CN1 needs to be diverse
      from an LSP from EN2 to EN3 going via CN4. Again in this case,
      [RFC4874] based exclusions cannot be used.

      This document addresses these diversity requirements by
      introducing the notion of excluding the path taken by particular
      LSP(s). The reference LSP(s) with which diversity is required is
      identified by an "identifier". The type of identifier to use is
      highly dependent on the networking deployment scenario. For
      example, if the identifier is client initiated, the network
      allocates identifier or a Path Computation Element (PCE) manages
      identifier. Consequently, this document defines three different
      types of identifiers: client initiated identifier, PCE allocated
      Identifier and network allocated Identifier, as detailed in the
      following sections.

   1.1. Client Initiated Identifier

      There are scenarios in which the ENs have the following
      requirements for the diversity identifier:

      -  The identifier is controller by the client side and is
         specified as part of the service request.

      -  Both client and server should understand the identifier.

      -  The identifier needs to be reference able even if the LSP
         referenced by it is not yet signaled.

      -  The identifier should be stable for a long period of time.

      -  The identifier should be stable even when the tunnel is
         rerouted.

      -  The identifier should be human readable.

      The above-mentioned requirements are met by using RSVP tunnel/
      LSP Forwarding Equivalence Class (FEC) as the identifier.
      Consequently, RSVP tunnel/ LSP FEC is used as client initiated
      identifier.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      The usage of the client-initiated identifier is illustrated by
      using Figure 1. Suppose a tunnel from EN2 to EN4 needs to be
      diverse with respect to a tunnel from EN1 to EN3. Lets assume
      tunnel FEC of the EN1-EN3 tunnel is FEC1, where FEC1 is defined
      by the tuple (tunnel-id = T1, source address = EN1.ROUTE
      Identifier (RID), destination address = EN3.RID, extended tunnel-
      id = EN1.RID). Similarly, tunnel FEC of the EN2-EN3 tunnel is
      FEC2, where FEC2 is defined by the tuple (tunnel-id = T2, source
      address = EN2.RID, destination address = EN4.RID, extended
      tunnel-id = EN2.RID). EN1-EN3 tunnel is signaled such that it
      specifies the exclusion requirement from FEC2. Similarly, EN2-EN3
      tunnel is signaled such that it specifies the exclusion
      requirement from FEC1. In order to maintain diversity between
      these two connections within the core network, it is assumed that
      the core network implements Crank back Signaling [RFC4920].
      Similarly, diversity within the core network for a dual homed UNI
      case is satisfied by the use of Crank back Signaling [RFC4920].

   1.2. PCE allocated Identifiers

      In scenarios where a PCE is deployed and used to perform path
      computation, the core edge node (e.g., node CN1 in Figure 1)
      could consult a PCE to allocate identifiers, which are used to
      signal path diversity constraints. In other scenarios a PCE is
      deployed in each border node or a PCE is part of the Network
      Management System (NMS). In all these cases, the Path key as
      defined in [RFC5520] can be used in RSVP signaling as the
      identifier to ensure diversity.

      The usage of specifying LSP diversity using Path Key is
      exemplified in Figure 2, where a simple network with two domains
      is shown. It is desired to set up a pair of path-disjoint LSPs
      from the source in Domain 1 to the destination in Domain 2, but
      the domains keep strict confidentiality about all path and
      topology information.

      The first LSP is signaled by the source with ERO {A, B, loose Dst}
      and is set up with the path {Src, A, B, U, V, W, Dst}. However,
      when sending the RRO out of Domain 2, node U would normally strip
      the path and replace it with a loose hop to the destination. With
      this limited information, the source is unable to include enough
      detail in the ERO of the second LSP to avoid it taking, for
      example, the path {Src, C, D, X, V, W, Dst} for path-disjointness.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

          ---------------------    -----------------------------
         | Domain 1            |  |                    Domain 2 |
         |                     |  |                             |
         |        ---    ---   |  |   ---    ---     ---        |
         |       | A |--| B |--+--+--| U |--| V |---| W |       |
         |      / ---    ---   |  |   ---    ---     --- \      |
         |  ---/               |  |          /       /    \---  |
         | |Src|               |  |         /       /     |Dst| |
         |  ---\               |  |        /       /      /---  |
         |      \ ---    ---   |  |   --- /   --- /  --- /      |
         |       | C |--| D |--+--+--| X |---| Y |--| Z |       |
         |        ---    ---   |  |   ---     ---    ---        |
         |                     |  |                             |
          ---------------------    -----------------------------

                Figure 2: A Simple Multi-Domain Network

      In order to improve the situation, node U performs the PCE
      function and replaces the path segment {U, V, W} in the RRO with
      a Path Key Subobject [RFC5553]. The Path Key Subobject assigns an
      "identifier" to the key. The PCE ID in the message indicates that
      it was node U that made the replacement.

      With this additional information, the source is able to signal
      the subsequent LSPs with the ERO set to {C, D, exclude Path
      Key(EXRS), loose Dst}. When the signaling message reaches node X,
      it can consult node U to expand the Path Key and know how to
      avoid the path of the first LSP. Alternatively, the source could
      use an ERO of {C, D, loose Dst} and include an XRO containing the
      Path Key.

   1.3. Network allocated Identifiers

      There are scenarios in which the network provides diversity
      information for a service that allows the client device to
      include this information in the signaling message. In this
      section two signaling approaches are outlined that use network
      allocated identifiers. While both methods could be implemented in
      the same core network, it is very likely that a core network
      supports only one of the two mechanisms.

      The first method assumes that core network Shared Resource Link
      Group (SRLG) identifier information is both available and
      shareable (by policy) with the ENs. In this case, the procedure
      defined in [DRAFT-SRLG-RECORDING] can be used to collect SRLG
      identifiers associated with an LSP (say LSP1). Suppose that LSP2

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      needs to be diverse with respect to LSP1. When the EN constructs
      the RSVP signaling message for setting up LSP2, it can insert the
      SRLG identifiers associated with LSP1 as diversity constraints
      into the XRO using the procedure described in [RFC4874]. This
      method is not discussed further as it utilizes existing RSVP
      protocol mechanisms for collecting SRLG information and passing
      this diversity information to the CN.

      The second method assumes that core network SRLG identifiers are
      either not available or not shareable with the ENs based on
      policies enforced by core network. In this case, a signaling
      mechanism is defined where information signaled to the CN via the
      UNI does not require shared knowledge of provider SRLG
      information. For this purpose, notion of Path Affinity Set (PAS)
      is used for abstracting SRLG information. The motive behind the
      PAS information is to have as little exchange of diversity
      information as possible between the core network (CNs) and the
      client devices (ENs). I.e., rather than a detailed SRLG list, the
      PAS contains an abstract SRLG identifier associated with a given
      path.

      There are two types of diversity information in the PAS. The
      first type of information is a single PAS identifier. The Second
      part is the optional PATH information, in the form of Source and
      Destination addresses of a path. This mechanism can also be
      applied to L1 VPNs and in this particular case, the identifier
      only needs to be unique within the scope of a particular VPN.

      A CN on the core network boundary interprets the specific PAS
      identifier, for example, "123" as meaning to exclude the core
      network SRLG information (or equivalent) that has been allocated
      by LSPs associated with this PAS identifier value. For example,
      if a Path exists for the LSP with the identifier "123", the CN
      would use local knowledge of the core network SRLGs associated
      with the "123" LSPs and use those SRLGs as constraints for path
      computation.  In other words, two LSPs that need to be diverse
      both signal "123" and the CNs interpret this as meaning not to
      use shared resources.  Alternatively, a CN could use the PAS
      identifier to select from already established LSPs. Once the path
      is established core network allocated the "123" identifier or
      optionally another PAS identifier for that VPN that replaces
      "123".

      The optional PAS source and destination address tuple represents
      one or more source addresses and destination addresses associated
      with the EN PAS identifier. These associated address tuples
      represent paths that use resources that should be excluded for

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      the establishment of the current LSP.  The address tuple
      information gives both finer grain details on the path diversity
      request and serves as an alternative identifier in the case when
      the PAS identifier is not known by the CN.  The address tuples
      used in signaling is within a client network context and its
      interpretation is local to a CN that receives a Path request from
      an EN. The CN can use the address information to relate to CN
      addresses and core network SRLG information.  When a CN satisfies
      a connection setup for a (SRLG) diverse signaled path, the CN may
      optionally record the core network SRLG information for that
      connection in terms of CN based parameters and associates that
      with the EN addresses in the Path message. Specifically for
      L1VPNs, Port Information tables (PIT) [RFC5251] can be leveraged
      to translate between client (EN) based addresses and core network
      based addresses. The PAS and associated core network addresses
      with core network SRLG information can be distributed via the IGP
      in the core network (or by other means such as configuration);
      they can be utilized by other CNs when other ENs are requesting
      paths to be setup that would require path/connection diversity.
      In the VPN case, this information is distributed on a VPN basis
      and contains a PAS identifier, CN addresses and SRLG information.

      If diversity is not signaled, the assumption is that no diversity
      is required and the core network is free to route the LSP to
      optimize traffic. No Path affinity set information needs to be
      recorded for these LSPs.  If a diversity object is included in
      the connection request, the CN in the core network should be able
      to determine (look-up) the existing core network SRLG information
      and choose an LSP that is maximally diverse from other LSPs.

      The Path Affinity Set identifier is independent of the mechanism
      the EN or the CN use for diversity. The Path Affinity Set is a
      single identifier that can be used to request diversity and
      associate diversity.

   2. RSVP-TE signaling extensions

      This section describes the signaling extensions required to
      address the aforementioned requirements and use cases.

   2.1. Diversity XRO Subobject

      New Diversity XRO subobjects are defined by this document as
      follows.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |Attribute Flags|Exclusion Flags|    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            TLVs ...                           |
      //                                                             //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        L:
             The L-flag is used as for the XRO subobjects defined in
             [RFC4874], i.e.,

             0 indicates that the attribute specified MUST be excluded.

             1 indicates that the attribute specified SHOULD be avoided.

        Type

             Type for diversity XRO subobject (to be assigned by IANA;
             suggested value: 37).

        Attribute Flags:

            The Attribute Flags are used to communicate desirable
            attributes of the LSP being signaled. The following flags
            are defined. Each flag acts independently.  Any combination
            of flags is permitted.

            0x01 = Destination node exception

               Indicates that exclusion does not apply to the
               destination node of the LSP being signaled.

            0x02 = Processing node exception

               Indicates that exclusion does not apply to the border
               node(s) performing ERO expansion for the LSP being
               signaled. Ingress UNI-N node is an example of such
               nodes.

            0x04 = Penultimate node exception

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

               Indicates that the penultimate node of the LSP being
               signaled MAY be shared with the excluded path even when
               this violates the exclusion flags.

            0x08 = LSP ID to be ignored

               This flag is only applicable to the IPv4/ IPv6 Point-to-
               Point tunnel identifier TLVs of the Diversity XRO
               subobjects defined in section 2.1.1. In this context,
               the flag indicates tunnel level exclusion. Specifically,
               this flag is used to indicate that the lsp-id field of
               the IPv4/ IPv6 Point-to-Point tunnel identifier TLVs is
               to be ignored and the exclusion applies to any LSP
               matching the rest of the supplied FEC.

        Exclusion Flags

             The Exclusion-Flags are used to communicate the desired
             type(s) of exclusion. The following flags are defined.

             0x01 = SRLG exclusion

                  Indicates that the path of the LSP being signaled is
                  requested to be SRLG diverse from the excluded path
                  specified by the Diversity subobject.

             0x02 = Node exclusion

                  Indicates that the path of the LSP being signaled is
                  requested to be node diverse from the excluded path
                  specified by the Diversity subobject.

                  (Note: the meaning of this flag may be modified by
                  the value of the Attribute-flags.)

             0x04 = Link exclusion

                  Indicates that the path of the LSP being signaled is
                  requested to be link diverse from the path specified
                  by the Diversity subobject.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

         TLVs (Type-Length-Value tuples) have the following format. Only
      one TLV is allowed in the Diversity XRO subobject. However,
      multiple Diversity XRO subobjects may be present in an XRO.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Type             |            Length             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             Value                             |
      //                                                             //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Types (2 bytes): This document defines the following types of
      TLVs:

         -  Type = 1: IPv4 Point-to-Point tunnel identifier.

         -  Type = 2: IPv6 Point-to-Point tunnel identifier.

         -  Type = 3: IPv4 Path Key.

         -  Type = 4: IPv6 Path Key.

         -  Type = 5: IPv4 Path Affinity Set (PAS).

         -  Type = 6: IPv6 Path Affinity Set (PAS).

      Format of the individual TLVs is described in the following.

   2.1.1. Tunnel identifier TLVs

      The IPv4 and IPv6 Point-to-Point (P2P) tunnel identifier TLVs for
      diversity XRO subobjects are defined as follows.

   2.1.1.1. IPv4 Point-to-Point tunnel identifier TLV

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 1            |          Length = 24          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      |          Must Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv4 Point-to-Point tunnel identifier TLV (to be assigned
             by IANA; suggested value: 1).

        Length:

            The length contains the total length of the TLV in bytes,
            including the type and length fields. The length is always
            24.

        The remaining fields are as defined in [RFC3209].

         Please note that the L-bit, exclusion and attribute flags
         defined at the diversity XRO subobject level in Section 2.1
         are equally applicable to the IPv4 Point-to-Point tunnel
         identifier TLV.

   2.1.1.2. IPv6 Point-to-Point tunnel identifier TLV

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 2            |          Length = 60          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |     Tunnel ID                 |

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv6 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv6 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv6 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv6 Point-to-Point tunnel identifier TLV (to be assigned
             by IANA; suggested value: 2).

        Length:

            The length contains the total length of the TLV in bytes,
            including the type and length fields. The length is always
            60.

        The remaining fields are as defined in [RFC3209].

         Please note that the L-bit, exclusion and attribute flags
         defined at the diversity XRO subobject level in Section 2.1
         are equally applicable to the IPv6 Point-to-Point tunnel
         identifier TLV.

   2.1.2. Path Key TLVs

      The IPv4 and IPv6 Path Key TLVs for diversity XRO subobjects are
      defined as follows.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

   2.1.2.1. IPv4 Path Key TLV

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 3            |          Length = 12          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Must Be Zero          |           Path Key            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        PCE ID (4 bytes)                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv4 Path Key TLV (to be assigned by IANA; suggested
             value: 3).

        Length:

            The length contains the total length of the TLV in bytes,
            including the type and length fields. The length is always
            12.

        Path Key:

            Path Key is defined in [RFC5553].

         PCE-ID:

            The IPv4 address of a node that assigned the Path Key
            identifier and that can return an expansion of the Path Key
            or use the Path Key as exclusion in a path computation.

         Please note that exclusion and attribute flags defined at the
         diversity XRO subobject level in Section 2.1 are equally
         applicable to the IPv4 Path Key TLV.

   2.1.2.2. IPv6 Path Key TLV

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 4            |          Length = 24          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      |          Must Be Zero         |           Path Key            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        PCE ID (16 bytes)                      |
      |                                                               |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv4 Path Key TLV (to be assigned by IANA; suggested
             value: 4).

        Length:

            The length contains the total length of the TLV in bytes,
            including the type and length fields. The length is always
            24.

        Path Key:

            Path Key is defined in [RFC5553].

         PCE-ID:

            The IPv6 address of a node that assigned the Path Key
            identifier and that can return an expansion of the Path Key
            or use the Path Key as exclusion in a path computation.

         Please note that the L-bit, exclusion and attribute flags
         defined at the diversity XRO subobject level in Section 2.1
         are equally applicable to the IPv6 Path Key TLV.

   2.1.3. Path Affinity Set TLVs

      The IPv4 and IPv6 Path Affinity Set (PAS) TLVs for diversity XRO
      subobjects are defined as follows.

   2.1.3.1. IPv4 PAS TLV

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      |           Type = 5            |          Length = 16          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Path Affinity Set identifier                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 Path Source Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 Path Destination Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv4 PAS TLV (to be assigned by IANA; suggested value: 5).

        Length:

            The length contains the signaling extensions required total length of the TLV in bytes,
            including the type and length fields. The length is always
            16.

        Path Affinity Set identifier:
            The Path affinity Set identifier (4 bytes) is a single
            number that represents a summarized SRLG for this path.

        IPv4 Path Source Address:

            The IPv4 address of the source node associated with the
            Path.

        IPv4 Path Destination Address:

            The IPv4 address of the destination node associated with
            the Path.

         Please note that L-bit, exclusion and attribute flags defined
         at the diversity XRO subobject level in Section 2.1 are
         equally applicable to the IPv4 PAS TLV.

   2.1.3.2. IPv6 PAS TLV

        0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Type = 6            |          Length = 40          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Path Affinity Set identifier                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv6 Path Source Address                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 Path Source Address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 Path Source Address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 Path Source Address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 Path Destination Address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 Path Destination Address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 Path Destination Address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 Path Destination Address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Type:

             IPv6 PAS TLV (to be assigned by IANA; suggested value: 6).

        Length:

            The length contains the total length of the TLV in bytes,
            including the type and length fields. The length is always
            40.

        Path Affinity Set identifier:
            The Path affinity Set identifier (4 bytes) is a single
            number that represents a summarized SRLG for this path.

        IPv6 Path Source Address:

            The IPv6 address of the source node associated with the
            Path.

        IPv6 Path Destination Address:

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

            The IPv6 address of the destination node associated with
            the Path.

         Please note that the L-bit, exclusion and attribute flags
         defined at the aforementioned requirements. Specifically, this
      document defines a new LSP diversity XRO subobject to be signaled level in Section 2.1
         are equally applicable to the
      EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route
      Subobject (EXRS) defined in [RFC4874]. Inclusion of IPv6 PAS TLV.

   2.2. Processing rules for the LSP Diversity XRO subobject

      The procedure defined in any other RSVP object [RFC4874] for processing XRO and EXRS is
      not defined.

   2.1. Terminology

      In changed by this document, the following terminology is adopted:

      Excluded path: the path from which diversity is required.

      Diverse LSP: document.

      If the LSP being signaled with XRO/ EXRS containing processing node cannot recognize the
      path Diversity XRO
      subobject referencing or the excluded path(s).

      Processing node: TLV contained in it, the node performing a path-calculation involving
      exclusion specified follows procedure
      defined in an [RFC4874].

      An XRO or EXRS.

      Destination node: in object MAY contain multiple Diversity subobjects. However,
      all Diversity subobjects are expected to contain the context of same TLV
      type. If a Path message contains an XRO, this XRO with Diversity subobjects
      with TLVs of different types, the processing node SHOULD return a
      PathErr with the error code "Routing Problem" (24) and error sub-
      code "XRO Too Complex" (68). If the processing node is the
      destination of for the LSP being signaled. In signaled, it SHOULD NOT process a
      Diversity XRO subobject.

      The attribute-flags affect the context processing of an EXRS, the Diversity XRO
      subobject as follows:

           o  When the "destination node exception" flag is not set, the
             exclusion flags SHOULD also be respected for the
             destination node.

           o  When the "processing node exception" flag is not set, the
             exclusion flags SHOULD also be respected for the
             processing node.

           o  When the "penultimate node exception" flag is not set, the
             exclusion flags SHOULD also be respected for the
             penultimate node.

           o  The use of "LSP ID to be ignored" flag is only defined for
             the IPv4 and IPv6 tunnel identifier TLVs. This flag is the last explicit node to which the loose
      hop
             never set and is expanded.

      Penultimate node: always ignored in processing all other
             TLVs. When the context of an XRO, this "LSP ID to be ignored" flag is set, the
      penultimate hop of the LSP being signaled. In the context of an
      EXRS, the penultimate
             processing node is MUST calculate a path based on exclusions

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

             from the penultimate node paths of all known LSPs matching the loose
      hop undergoing expansion.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

   2.2. Path XRO Subobjects

      New IPv4 tunnel-id,
             source, destination and IPv6 Point-to-Point (P2P) Path XRO subobjects are
      defined by this document as follows.

   2.2.1. IPv4 Point-to-Point Path extended tunnel-id specified in
             the subobject

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |Attribute Flags|Exclusion Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 (i.e., tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        L:
             The L-flag level exclusion). When this
             flag is used as for not set, the other XRO subobjects defined
             in [RFC4874].

             0 indicates that lsp-id is not ignored and the attribute specified MUST be excluded.

             1 indicates that
             exclusion applies only to the attribute specified SHOULD be
             avoided.

        Type:

             IPv4 Point-to-Point Path subobject (to be assigned by IANA;
             suggested value: 36).

        Length:

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt LSP (i.e., LSP
             level exclusion).

      The length contains rest of the processing role depends on the TLV carried by the
      object.

   2.2.1. Processing rules for the total length tunnel identifier TLVs

      This section describes processing rules for the IPv4 and IPv6
      tunnel identifier TLVs.

      If the L-flag of the diversity XRO subobject in
            bytes, including the type and length fields. The length is
            always 24.

        Attribute Flags: not set, the
      processing node follows the following procedure:

      -  The Attribute Flags are used to communicate desirable
            attributes of processing node MUST ensure that any path calculated for
         the signaled LSP being signaled. The following flags
            are defined. Each flag acts independently.  Any combination
            of respects the requested exclusion flags is permitted.

            0x01 = LSP ID with
         respect to be ignored

               Indicates tunnel level exclusion. Specifically, this
               flag is used the excluded path referenced by the subobject,
         including local resources.

      -  If the processing node fails to indicate find a path that meets the lsp-id field of
         requested constraint, the
               subobject processing node MUST return a PathErr
         with the error code "Routing Problem" (24) and error sub-code
         "Route blocked by Exclude Route" (67).

      -  If the excluded path referenced in the tunnel identifier TLV
         is unknown to be ignored the processing node, the processing node SHOULD
         ignore the tunnel identifier TLV in the diversity XRO subobject
         of XRO and SHOULD proceed with the exclusion applies signaling request. After
         sending the Resv for the signaled LSP, the processing node
         SHOULD return a PathErr with the error code "Notify Error" (25)
         and error sub-code "Route of XRO tunnel identifier unknown"
         (value to
               any LSP matching be assigned by IANA, suggested value: 13) for the rest
         signaled LSP.

      If the L-flag of the supplied FEC.

            0x02 = Destination diversity XRO subobject is set, the
      processing node exception

               Indicates that exclusion does not apply to follows the
               destination procedure below:

      -  The processing node of SHOULD respect the LSP being signaled.

            0x04 = Processing node exception

               Indicates that requested exclusion does not apply
         flags with respect to the ERO excluded path to the extent possible.

      -  If the processing node of fails to find a path that meets the LSP being signaled.

            0x08 = Penultimate node exception

               Indicates
         requested constraint, it SHOULD proceed with signaling using a
         suitable path that meets the penultimate node of constraint as far as possible.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

         After sending the Resv for the LSP being signaled MAY be shared LSP, it SHOULD return a
         PathErr message with error code "Notify Error" (25) and error
         sub-code "Failed to respect Exclude Route" (value: to be
         assigned by IANA, suggest value: 14) to the source node.

      -  If the excluded path even when
               this violates referenced in the exclusion flags.

               Indicates that exclusion does not apply tunnel identifier TLV
         is unknown to the
               penultimate processing node, the processing node of SHOULD
         ignore the LSP being signaled.

        Exclusion Flags

             The Exclusion-Flags are used to communicate tunnel identifier TLV in the desired
             type(s) diversity XRO subobject
         of exclusion. The following flags are defined.

             0x01 = SRLG exclusion

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

                  Indicates that XRO and SHOULD proceed with the path signaling request. After
         sending the Resv for signaled LSP, the processing node SHOULD
         return a PathErr message with the error code "Notify Error"
         (25) and error sub-code "Route of XRO tunnel identifier
         unknown" for the LSP being signaled is
                  requested LSP.

      If, subsequent to be SRLG diverse from the initial signaling of a diverse LSP:

      -   An excluded path
                  specified by the LSP subobject.

             0x02 = Node exclusion

                  Indicates that the path of referenced in the LSP being signaled is
                  requested diverse LSP's XRO tunnel
         identifier becomes known to be the processing node diverse from (e.g. when the
         excluded path
                  specified by is signaled), or

      -   A change in the LSP subobject.

                  (Note: excluded path becomes known to the meaning of this flag may be modified by processing
         node, the value of processing node SHOULD re-evaluate the Attribute-flags.)

             0x04 = Link exclusion

                  Indicates that the path of the LSP being signaled is and
         diversity constraints requested to be link diverse from the path specified by the diverse LSP subobject.

      The remaining fields to determine
         whether they are as defined in [RFC3209].

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

   2.2.2. IPv6 Point-to-Point Path subobject

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |Attribute Flags|Exclusion Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv6 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             IPv6 tunnel end point address (cont.)             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Extended Tunnel ID (cont.)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv4 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv4 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               IPv4 tunnel sender address (cont.)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        L
             The L-flag is used as still satisfied.

      -   If the requested exclusion constraints for the other XRO subobjects defined
             in [RFC4874].

             0 indicates that diverse LSP
         are no longer satisfied and an alternative path for the attribute specified MUST be excluded.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

             1 indicates diverse
         LSP that can satisfy those constraints exists, the attribute specified processing
         node SHOULD be
             avoided.

        Type

             IPv6 Point-to-Point Path subobject
                       (to send a PathErr message for the diverse LSP with the
         error code "Notify Error" (25) and a new error sub-code
         "compliant path exists" (value: to be assigned by IANA; suggested IANA, suggest
         value: 37).

        Length

            The length contains 15). A source node receiving a PathErr message with this
         error code and sub-code combination MAY try to reoptimize the total length of
         diverse tunnel to the subobject new compliant path.

      -   If the requested exclusion constraints for the diverse LSP
         are no longer satisfied and no alternative path for the diverse
         LSP that can satisfy those constraints exists, then:

           o If the L-flag was not set in
            bytes, including the type original exclusion, the
              processing node MUST send a PathErr message for the
              diverse LSP with the error code "Routing Problem" (24) and length fields. The length is
            always 48.
              error sub-code "Route blocked by Exclude Route" (67). The Attribute Flags and Exclusion Flags are as defined
              PSR flag SHOULD NOT be set.

           o If the L-flag was set in the original exclusion, the
              processing node SHOULD send a PathErr message for the
      IPv4 Point-to-Point LSP

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

              diverse LSP with the error code error code "Notify Error"
              (25) and error sub-code "Failed to respect Exclude Route"
              (value: to be assigned by IANA, suggest value: 14).

      The following rules apply whether or not the L-flag is set:

      -  A source node receiving a PathErr message with the error code
         "Notify Error" (25) and error sub-codes "Route of XRO subobject.

      The remaining fields are as defined in [RFC3209].

   2.3. tunnel
         identifier unknown" or "Failed to respect Exclude Route" MAY
         take no action.

   2.2.2. Processing rules for the Path XRO subobjects

      XRO processing as described in [RFC4874] is unchanged.

      If the Key TLVs

      This section describes processing node is the destination rules for the LSP being
      signaled, it SHOULD NOT process a IPv4 and IPv6
      Path XRO subobject.

      If Key TLVs.

      An EN may include a path-key identifier (PKS) in the L-flag is not set, path-key
      TLVs of the processing node follows diversity XRO subobject to convey diversity
      constraints. In order to exclude multiple PKS, an EN may include
      multiple diversity XRO subobjects each with a different path-key.

      If the
      following procedure:

      -  The processing node MUST ensure that any path calculated for node, receiving the signaled LSP respects path-key TLV, cannot recognize the requested exclusion flags with
         respect
      subobject, it will react according to [RFC4874] and SHOULD ignore
      the excluded path referenced by the subobject,
         including local resources.

      -  If constraint. Otherwise, if it decodes the processing node fails to path-key TLV but
      cannot find a path that meets the
         requested constraint, route/route segment meeting the processing node MUST return constraint:

           -if L flag is set to 0, it will react according to [RFC4874]
           and SHOULD send a PathErr message with the error code
           "Routing Problem" (24) and the error sub-code "Route blocked
           by Exclude Route" (67).

      -  If the excluded path referenced in the LSP subobject

           -if L flag is
         unknown set to 1, which means the processing node, the processing node SHOULD
         ignore try to
           be as much diversified as possible with the LSP subobject in specified
           resource. If it cannot fully support the XRO and constraint, it
           SHOULD proceed send a PathErr message with the

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

         signaling request. After sending the Resv for the signaled LSP, error code/value
           combination "Notify Error" / "Failed to respect Exclude
           Route" (value: to be assigned by IANA, suggest value: 14).

      The following rules apply whether or not the processing L-flag is set:

      -  A source node SHOULD return receiving a PathErr message with the error code
         "Notify Error" (25) and error sub-code "Route of XRO path
         unknown" (value sub-codes "Failed to be assigned by IANA, suggested value: 13)
         for the signaled LSP.

      If the L-flag is set, the processing node follows the procedure
      below:

      -  The processing node SHOULD respect the requested exclusion
         flags
         Exclude Route" MAY take no action.

      This mechanism can work with respect to all the excluded path PKS resolution mechanisms,
      as detailed in [RFC5553] section 3.1. A PCE, co-located or not,
      may be used to resolve the extent possible.

      -  If PKS, but the processing node fails (i.e., a Label

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      Switcher Router (LSR)) can also use the PKS information to find index
      a path Path Segment previously supplied to it by the entity that meets
      originated the
         requested constraint, it SHOULD proceed with signaling using a
         suitable path PKS, for example the LSR that meets inserted the constraint as far as possible.
         After sending PKS in
      the Resv RRO or a management system.

   2.2.3. Processing rules for the signaled LSP, it SHOULD return a
         PathErr message with error code "Notify Error" (25) PAS TLVs

      This section describes processing rules for the IPv4 and error
         sub-code "Failed IPv6 PAS
      TLVs.

      An EN may include a PAS identifier in the PAS TLVs of the
      diversity XRO subobject to respect Exclude Route" (value: convey diversity constraints. In order
      to exclude multiple PAS identifiers, an EN may include multiple
      diversity XRO subobjects each with a different PAS identifier.

      How an EN determines the PAS identifier is a local matter for the
      EN administrator. This identifier is a suggested identifier and
      may be
         assigned overridden by IANA, suggest value: 14) to a CN under some conditions, regardless if L
      bit is set or not. For example, a PAS identifier can be used with
      no prior exchange of PAS information between the source node.

      -  If EN and the excluded path referenced CN.
      Upon reception of the PAS identifier information the CN can infer
      the EN's requirements.  The actual PAS identifier used will be
      returned in the LSP RESV message.

      If the L-flag of the diversity XRO subobject is
         unknown to not set, the
      processing node, node follows the following procedure:

      -  The processing node SHOULD
         ignore MUST ensure that any path calculated for
         the signaled LSP subobject in respects the XRO and SHOULD proceed with requested PAS exclusion,
         including local resources.

      -  If the
         signaling request. After sending processing node fails to find a path that meets the Resv for signaled LSP,
         requested constraint, the processing node SHOULD MUST return a PathErr message
         with the error code "Notify Error" (25) "Routing Problem" (24) and error sub-code
         "Route of XRO path
         unknown" for the signaled LSP.

      If, subsequent to the initial signaling of a diverse LSP: blocked by Exclude Route" (67).

      -   an excluded path  If the PAS value referenced in the diverse LSP's XRO
         subobject becomes known to the processing node (e.g. when the
         excluded path PAS TLV is signaled), or

      -   A change in the excluded path becomes known unknown to the
         processing node, the processing node SHOULD re-evaluate MAY infer the exclusion and diversity constraints requested by the diverse LSP to determine
      whether they are still satisfied.

      -   If the requested exclusion constraints for
         requirement. After sending the diverse LSP
         are no longer satisfied and an alternative path Resv for the diverse
         LSP that can satisfy those constraints exists, signaled LSP, the
         processing node SHOULD send return a PathErr message for the diverse LSP with the error code
         "Notify Error" (25) and a new error sub-code
         "compliant path exists" (value: "XRO PAS value inferred"
         (value to be assigned by IANA, suggest

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

         value: 15). A source node receiving a PathErr message with this
         error code and sub-code combination MAY try to reoptimize the
         diverse tunnel to the new compliant path.

      -   If the requested exclusion constraints for the diverse LSP
         are no longer satisfied and no alternative path for the diverse
         LSP that can satisfy those constraints exists, then:

           o If the L-flag was not set in the original exclusion, the suggested value: TBD). However,
         if processing node fails to infer the diversity requirement
         from PAS value, it MUST send return a PathErr message for the
              diverse LSP with the error code
         "Routing Problem" (24) and error sub-code "Route blocked by
         Exclude Route" (67). The
              PSR flag SHOULD NOT be set.

           o

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      If the L-flag was set in of the original exclusion, diversity XRO subobject is set, the
      processing node follows the procedure below:

      -  The processing node SHOULD send a PathErr message ensure that any path calculated for
         the
              diverse signaled LSP respects the requested PAS exclusion,
         including local resources.

      -  If the processing node fails to find a path that meets the
         requested constraint, it SHOULD proceed with signaling using a
         suitable path that meets the error code constraint as far as possible.
         After sending the Resv for the signaled LSP, it SHOULD return a
         PathErr message with error code "Notify Error" (25) and error
         sub-code "Failed to respect Exclude Route" (value: to be
         assigned by IANA, suggest value: 14).

      The following rules apply whether or not 14) to the L-flag is set: source node.

      -  An XRO object  If the PAS value referenced in the PAS TLV is unknown to the
         processing node, the processing node MAY contain multiple path subobjects.

      -  A source infer the diversity
         requirement. However, if processing node receiving fails to infer the
         diversity requirement it MAY ignore the PAS TLV in the
         diversity XRO subobject of XRO and SHOULD proceed with the
         signaling request. After sending the Resv for signaled LSP, the
         processing node SHOULD return a PathErr message with the error
         code "Notify Error" (25) and error sub-codes "Route of XRO path
         unknown" or sub-code "Failed to respect
         Exclude Route" MAY take no
         action.

      -  The attribute-flags affect (value: to be assigned by IANA, suggest value:
         14) to the processing source node.

      In the context of VPN, upon reception of the XRO subobject
         as follows:

           o  When PAS identifier
      information, the "LSP ID to be ignored" flag CN looks up the CN based addresses in the
      Provider Index Table (PIT). The CN also looks up the SRLG
      information (or equivalent) in the core network that is set,
      associated with LSPs belonging to the same Path Affinity Set and
      exclude those resources from the
             processing node MUST calculate a path based on exclusions computation for this LSP.
      The CN may alternatively choose from an existing path with a
      disjoint set of resources.

      Optionally the paths EN may use a value of all known LSPs matching the tunnel-id,
             source, destination and extended tunnel-id specified zeros in the subobject (i.e., tunnel level exclusion). When this
             flag is not set, PAS
      identifier allowing the lsp-id is not ignored and CN to select an appropriate PAS
      identifier. Also the
             exclusion applies only CN may to override the specified LSP (i.e., LSP
             level exclusion).

           o  When PAS identifier
      allowing the "destination node exception" flag is CN to re-assign the identifier if required. An EN
      should not set, assume that the
             exclusion flags SHOULD also be respected PAS identifier used for setup is the
             destination node.
      actual PAS identifier.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

           o  When      draft-ietf-ccamp-lsp-diversity-04.txt

   2.2.3.1.1. Distribution of the "processing node exception" flag Path Affinity Set Information

      Information about TE link SRLGs is not set, already available in the
             exclusion flags SHOULD also IGP
      TE database. A core network can be respected designed to have additional
      opaque records for the
             processing node.

           o core network paths that distribute EN paths,
      PAS values associated with them and SRLG on a VPN basis. When a
      core network path is setup, the "penultimate node exception" flag following information allows a CN
      to lookup the CN diversity information:

      .  L1 VPN Identifier

      .  Path Affinity Set Identifier

      .  Source CN Address

      .  Destination CN Address

      .  List of core network SRLGs (variable)

      The source CN address and destination CN address are the same
      addresses in the VPN PIT and correspond to the respective EN
      address identifiers.

      Note that all of the information is local to the CN context and
      is not set, shared with the
             exclusion flags SHOULD also be respected for EN. The VPN Identifier is associated with
      an EN. The only value that is signaled from the EN is the
             penultimate node.

   2.4. Path
      Affinity Set and optionally the addresses of an existing LSP. The
      CN stores source and destination CN addresses of the LSP in their
      native format along with the SRLG information. This information
      is internal to the core network and is assumed to be known.

   2.3. Diversity EXRS Subobject

      [RFC4874] defines the EXRS ERO subobject. An EXRS is used to
      identify abstract nodes or resources that must not or should not
      be used on the path between two inclusive abstract nodes or
      resources in the explicit route. An EXRS contains one or more
      subobjects of its own, called EXRS subobjects [RFC4874].

      An EXRS MAY include an IPv4 Point-to-Point (P2P) Path Diversity subobject as specified in section 2.2.1. in this
      document. In this case, the EXRS format would be as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |           Reserved            |

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length     |Attribute Flags|Exclusion Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                            TLVs ...                           |          Must Be Zero
      //                                                             //
      |            LSP ID                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The meanings of respective fields in EXRS header are as defined
      in [RFC4874]. The meanings of respective fields in IPv4 P2P Path Diversity
      subobject are as defined earlier in this document.

      The processing rules for the EXRS object are unchanged from
      [RFC4874]. When the EXRS contains one or more Path Diversity
      subobject(s),

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt the processing rules specified in Section 2.3 apply
      to the node processing the ERO with the EXRS subobject.

      If a loose-hop expansion results in the creation of another
      loose-hop in the outgoing ERO, the processing node MAY include
      the EXRS in the newly-created newly created loose hop for further processing by
      downstream nodes.

      The processing node exception for the EXRS subobject applies to
      the node processing the ERO.

      The destination node exception for the EXRS subobject applies to
      the explicit node identified by the ERO subobject that identifies
      the next abstract node. This flag is only processed if the L bit
      is set in the ERO subobject that identifies the next abstract
      node.

      The penultimate node exception for the EXRS subobject applies to
      the node before the explicit node identified by the ERO subobject
      that identifies the next abstract node. This flag is only
      processed if the L bit is set in the ERO subobject that
      identifies the next abstract node.

   3. Security Considerations

      This document does not introduce any additional security issues
      above those identified in [RFC5920], [RFC2205], [RFC3209],
      [RFC3473] and [RFC4874].

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

   4. IANA Considerations

   4.1. New XRO subobject types

      IANA registry: RSVP PARAMETERS
      Subsection: Class Names, Class Numbers, and Class Types

      This document introduces two new subobjects for the EXCLUDE_ROUTE
      object [RFC4874], C-Type 1.

      Subobject Type                            Subobject Description                Subobject Type
      --------------                                              ---------------------
      To be assigned by IANA                    IPv4 P2P Path
      Diversity subobject
        (suggested value: 36)                  To be assigned by IANA                    IPv6 P2P Path subobject
                                          (suggested value: 37)

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt 36)

   4.2. New EXRS subobject types

      The IPv4 and IPv6 P2P Path diversity XRO subobjects are also defined as new EXRS
      subobjects.

   4.3. TLV types for Diversity XRO and EXRS subobjects

      The following TLV types for Diversity XRO and EXRS subobjects are
      defined.

      TLV Description                         TLV Type
      ---------------                         --------

      IPv4 Point-to-Point tunnel identifier    To be assigned by IANA
                                             (suggested value: 1)
      IPv6 Point-to-Point tunnel identifier    To be assigned by IANA
                                             (suggested value: 2)
      IPv4 Path Key                           To be assigned by IANA
                                             (suggested value: 3)
      IPv6 Path Key                           To be assigned by IANA
                                             (suggested value: 4)
      IPv4 Path Affinity Set                                                To be assigned by IANA
                                             (suggested value: 5)
      IPv6 Path Affinity Set                                                To be assigned by IANA
                                             (suggested value: 6)

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

   4.4. New RSVP error sub-codes

      IANA registry: RSVP PARAMETERS
      Subsection: Error Codes and Globally-Defined Globally Defined Error Value Sub-
      Codes

      For Error Code "Notify Error" (25) (see [RFC3209]) the following
      sub-codes are defined.

         Sub-code                            Value
         --------                            -----

         Route of XRO path unknown                        To be assigned by IANA.
         tunnel identifier unknown           Suggested Value: 13.

         Failed to respect Exclude Route     To be assigned by IANA.
                                             Suggested Value: 14.

         Compliant path exists               To be assigned by IANA.
                                             Suggested Value: 15.

         XRO PAS value inferred              To be assigned by IANA.
                                             Suggested Value: 16

   5. Acknowledgements

      The authors would like to thank Luyuan Fang and Walid Wakim for
      their review comments.

   6. References

   6.1. Normative References

      [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt

      [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
                (GMPLS) Signaling Resource ReserVation Protocol-Traffic
                Engineering (RSVP-TE) Extensions", RFC 3473, January
                2003.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

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

      [RFC5553]   Farrel, A., Ed., Bradford, R., and JP. Vasseur,
      "Resource Reservation Protocol (RSVP) Extensions for Path Key
      Support", RFC 5553, May 2009.

   6.2. Informative References

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

      [RFC4920] Farrel, A., Ed., Satyanarayana, A., Iwata, A., Fujita,
                N., and G. Ash, "Crankback Signaling Extensions for
                MPLS and GMPLS RSVP-TE", RFC 4920, July 2007.

      [RFC5520]   Bradford, R., Ed., Vasseur, JP., and A. Farrel,
                "Preserving Topology Confidentiality in Inter-Domain
                Path Computation Using a Path-Key-Based Mechanism", RFC
                5520, April 2009.

      [DRAFT-SRLG-RECORDING] F. Zhang, D. Li, O. Gonzalez de Dios, C.
                Margaria, "RSVP-TE Extensions for Collecting SRLG
                Information", draft-ietf-ccamp-rsvp-te-srlg-collect.txt,
                work in progress.

      [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and
                S. Jamin, "Resource ReserVation Protocol -- Version 1
                Functional Specification", RFC 2205, September 1997.

      [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
                Virtual Private Network (VPN) Terminology", RFC 4026,
                March 2005.

      [RFC5253] Takeda, T., Ed., "Applicability Statement for Layer 1
                Virtual Private Network (L1VPN) Basic Mode", RFC 5253,
                July 2008.

   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
                Networks", RFC 5920, July 2010.

   Authors'

   Contributor's Addresses

      Zafar Ali
      Cisco Systems.

      Igor Bryskin
      ADVA Optical Networking
      Email: zali@cisco.com ibryskin@advaoptical.com

      Daniele Ceccarelli
      Ericsson
      Email: Daniele.Ceccarelli@ericsson.com

      Dhruv Dhody
      Huawei Technologies
      EMail: dhruv.ietf@gmail.com

      Oscar Gonzalez de Dios
      Telefonica I+D
      Email: ogondio@tid.es

      Don Fedyk
      Hewlett-Packard
      Email: don.fedyk@hp.com

      Clarence Filsfils
      Cisco Systems, Inc.
      Email: cfilsfil@cisco.com

      Xihua Fu
      ZTE
      Email: fu.xihua@zte.com.cn

   Internet Draft      draft-ietf-ccamp-lsp-diversity-03.txt      draft-ietf-ccamp-lsp-diversity-04.txt

      Gabriele Maria Galimberti
      Cisco Systems
      Email: ggalimbe@cisco.com

      Ori Gerstel
      SDN Solutions Ltd.
      Email: origerstel@gmail.com

      Matt Hartley
      Cisco Systems
      Email: mhartley@cisco.com

      Kenji Kumaki
      KDDI Corporation
      Email: ke-kumaki@kddi.com

      Rudiger Kunze
      Deutsche Telekom AG
      Email: Ruediger.Kunze@telekom.de

      Lieven Levrau
      Alcatel-Lucent
      Email: Lieven.Levrau@alcatel-lucent.com

      Cyril Margaria
      cyril.margaria@gmail.com

      Julien Meuric
      France Telecom Orange
      Email: julien.meuric@orange.com

      Yuji Tochio
      Fujitsu
      Email: tochio@jp.fujitsu.com

      Xian Zhang
      Huawei Technologies
      Email: zhang.xian@huawei.com

   Authors' Addresses
   Internet Draft      draft-ietf-ccamp-lsp-diversity-04.txt

      Zafar Ali
      Cisco Systems.
      Email: zali@cisco.com

      Dieter Beller
      Alcatel-Lucent
      Email: Dieter.Beller@alcatel-lucent.com

      George Swallow
      Cisco Systems
      Email: swallow@cisco.com

      Fatai Zhang
      Huawei Technologies
      Email: zhangfatai@huawei.com