Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route
draft-ietf-ccamp-lsp-diversity-04

The information below is for an old version of the document
Document Type Active Internet-Draft (ccamp WG)
Authors Zafar Ali  , George Swallow  , Fatai Zhang  , Dieter Beller 
Last updated 2014-07-04
Replaces draft-ali-ccamp-xro-lsp-subobject, draft-fedyk-ccamp-uni-extensions
Replaced by RFC 8390, RFC 8390
Stream Internet Engineering Task Force (IETF)
Formats plain text pdf htmlized bibtex
Stream WG state WG Document
Other - see Comment Log
Document shepherd No shepherd assigned
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
CCAMP Working Group                                   Zafar Ali, Ed. 
   Internet Draft                                   George Swallow, Ed. 
   Intended status: Standard Track                        Cisco Systems 
   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-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 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.
    
    
   Ali, Swallow, Zhang, Beller, et al   Expires January 2015   [Page 1] 
    


   Internet Draft      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 procedures for additional route exclusion 
   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
         1.1. Client Initiated Identifier ........................ 5
         1.2. PCE allocated Identifiers 
.......................... 6
         1.3. UNI-N allocated Identifiers 
........................ 7
   2. RSVP-TE signaling extensions 
............................... 9
         2.1. Diversity XRO Subobject ............................ 9
         2.1.1. Tunnel identifier TLVs ........................... 12
         2.1.2. Path Key TLVs .................................... 14
         2.1.3. Path Affinity Set TLVs ........................... 16
         2.2. Processing rules for the Diversity XRO 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 ........................... 25
   3. Security Considerations .................................... 27
   4. IANA Considerations 
........................................ 27
   6. References ................................................. 28
         6.1. Normative References ............................... 28
         6.2. Informative References ............................. 29

   1. Introduction 

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

    
    
                       Expires January 2015                 [Page 2] 
       


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

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

    When a source node has full topological knowledge and is permitted 
    to signal an Explicit Route 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 constraints to be communicated to those nodes. 
    These include (but are not limited to): 

      .  LSPs with loose hops in the ERO, e.g. inter-domain LSPs;   

      .  Generalized Multi-Protocol Label Switching (GMPLS) User-
        Network Interface (UNI) where path computation may be performed 
        by the 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). 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 is exemplified in the Figure 1, where overlay reference 
      model from [RFC4208] is shown.  

    
    
                       Expires January 2015                 [Page 3] 
       


   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 
      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 
    
    
                       Expires January 2015                 [Page 4] 
       


   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.   
    
    
                       Expires January 2015                 [Page 5] 
       


   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. 

    
    
                       Expires January 2015                 [Page 6] 
       


   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 
    
    
                       Expires January 2015                 [Page 7] 
       


   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 
    
    
                       Expires January 2015                 [Page 8] 
       


   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. 

       

    
    
                       Expires January 2015                 [Page 9] 
       


   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 

    
    
                       Expires January 2015                 [Page 10] 
       


   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.  
       

    
    
                       Expires January 2015                 [Page 11] 
       


   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                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
                       Expires January 2015                 [Page 12] 
       


   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                 | 

    
    
                       Expires January 2015                 [Page 13] 
       


   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. 

    
    
                       Expires January 2015                 [Page 14] 
       


   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          | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
                       Expires January 2015                 [Page 15] 
       


   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  
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
    
                       Expires January 2015                 [Page 16] 
       


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

    
    
                       Expires January 2015                 [Page 17] 
       


   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: 

    
    
                       Expires January 2015                 [Page 18] 
       


   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 diversity XRO subobject level in Section 2.1 
         are equally applicable to the IPv6 PAS TLV.  

    
   2.2. Processing rules for the Diversity XRO subobject 

      The procedure defined in [RFC4874] for processing XRO and EXRS is 
      not changed by this document.  

      If the processing node cannot recognize the Diversity XRO 
      subobject or the TLV contained in it, the node follows procedure 
      defined in [RFC4874].  

      An XRO object MAY contain multiple Diversity subobjects. However, 
      all Diversity subobjects are expected to contain the same TLV 
      type. If a Path message contains an 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 for the LSP being signaled, it SHOULD NOT process a 
      Diversity XRO subobject.  

      The attribute-flags affect the processing of 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 
             never set and is always ignored in processing all other 
             TLVs. When the "LSP ID to be ignored" flag is set, the 
             processing node MUST calculate a path based on exclusions 

    
    
                       Expires January 2015                 [Page 19] 
       


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

             from the paths of all known LSPs matching the tunnel-id, 
             source, destination and extended tunnel-id specified in 
             the subobject (i.e., tunnel level exclusion). When this 
             flag is not set, the lsp-id is not ignored and the 
             exclusion applies only to the specified LSP (i.e., LSP 
             level exclusion). 

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

   2.2.1. Processing rules for the 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 is not set, the 
      processing node follows the following procedure:  

      -  The processing node MUST ensure that any path calculated for 
         the signaled LSP respects the requested exclusion flags with 
         respect to the excluded path referenced by the subobject, 
         including local resources.  

      -  If the processing node fails to find a path that meets the 
         requested constraint, the 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 the processing node, the processing node SHOULD 
         ignore the tunnel identifier TLV in the diversity XRO subobject 
         of XRO and SHOULD proceed with the 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 be assigned by IANA, suggested value: 13) for the 
         signaled LSP.  

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

      -  The processing node SHOULD respect the requested exclusion 
         flags with respect to the excluded path to the extent possible.  

      -  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 constraint as far as possible. 
    
    
                       Expires January 2015                 [Page 20] 
       


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

         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) to the source node.  

      -  If the excluded path referenced in the tunnel identifier TLV 
         is unknown to the processing node, the processing node SHOULD 
         ignore the tunnel identifier 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-code "Route of XRO tunnel identifier 
         unknown" for the signaled LSP.  

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

      -   An excluded path referenced in the diverse LSP's XRO tunnel 
         identifier becomes known to the processing node (e.g. when the 
         excluded path is signaled), or  

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

      -   If the requested exclusion constraints for the diverse LSP 
         are no longer satisfied and an alternative path for the diverse 
         LSP that can satisfy those constraints exists, the processing 
         node SHOULD 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, suggest 
         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 
              processing node MUST send 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 If the L-flag was set in the original exclusion, the 
              processing node SHOULD send a PathErr message for the 
    
    
                       Expires January 2015                 [Page 21] 
       


   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 tunnel 
         identifier unknown" or "Failed to respect Exclude Route" MAY 
         take no action. 

   2.2.2. Processing rules for the Path Key TLVs 

      This section describes processing rules for the IPv4 and IPv6 
      Path Key TLVs.  

      An EN may include a path-key identifier (PKS) in the path-key 
      TLVs of the 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 node, receiving the path-key TLV, cannot recognize the 
      subobject, it will react according to [RFC4874] and SHOULD ignore 
      the constraint. Otherwise, if it decodes the path-key TLV but 
      cannot find a route/route segment meeting the 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 L flag is set to 1, which means the node SHOULD try to 
           be as much diversified as possible with the specified 
           resource. If it cannot fully support the constraint, it 
           SHOULD send a PathErr message with the 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 L-flag is set:  

      -  A source node receiving a PathErr message with the error code 
         "Notify Error" (25) and error sub-codes "Failed to respect 
         Exclude Route" MAY take no action. 

      This mechanism can work with all the PKS resolution mechanisms, 
      as detailed in [RFC5553] section 3.1. A PCE, co-located or not, 
      may be used to resolve the PKS, but the node (i.e., a Label 
    
    
                       Expires January 2015                 [Page 22] 
       


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

      Switcher Router (LSR)) can also use the PKS information to index 
      a Path Segment previously supplied to it by the entity that 
      originated the PKS, for example the LSR that inserted the PKS in 
      the RRO or a management system. 

   2.2.3. Processing rules for the PAS TLVs 

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

      An EN may include a PAS identifier in the PAS TLVs of the 
      diversity XRO subobject to 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 overridden by 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 EN and the 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 RESV message. 

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

      -  The processing node MUST ensure that any path calculated for 
         the signaled LSP respects the requested PAS exclusion, 
         including local resources.  

      -  If the processing node fails to find a path that meets the 
         requested constraint, the 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 PAS value referenced in the PAS TLV is unknown to the 
         processing node, the processing node MAY infer the diversity 
         requirement. 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 "XRO PAS value inferred" 
         (value to be assigned by IANA, suggested value: TBD). However, 
         if processing node fails to infer the diversity requirement 
         from PAS value, it MUST return a PathErr with the error code 
         "Routing Problem" (24) and error sub-code "Route blocked by 
         Exclude Route" (67). 

    
    
                       Expires January 2015                 [Page 23] 
       


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

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

      -  The processing node SHOULD ensure that any path calculated for 
         the 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 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) to the source node.  

      -  If the PAS value referenced in the PAS TLV is unknown to the 
         processing node, the processing node MAY infer the diversity 
         requirement. However, if processing node 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-code "Failed to respect 
         Exclude Route" (value: to be assigned by IANA, suggest value: 
         14) to the source node.   

      In the context of VPN, upon reception of the PAS identifier 
      information, the 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 
      associated with LSPs belonging to the same Path Affinity Set and 
      exclude those resources from the path computation for this LSP.  
      The CN may alternatively choose from an existing path with a 
      disjoint set of resources.  

      Optionally the EN may use a value of all zeros in the PAS 
      identifier allowing the CN to select an appropriate PAS 
      identifier. Also the CN may to override the PAS identifier 
      allowing the CN to re-assign the identifier if required. An EN 
      should not assume that the PAS identifier used for setup is the 
      actual PAS identifier. 

       

    
    
                       Expires January 2015                 [Page 24] 
       


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

   2.2.3.1.1. Distribution of the Path Affinity Set Information 

      Information about TE link SRLGs is already available in the IGP 
      TE database. A core network can be designed to have additional 
      opaque records for 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 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 shared with the EN. The VPN Identifier is associated with 
      an EN. The only value that is signaled from the EN is the 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 Diversity subobject as specified 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            | 

    
    
                       Expires January 2015                 [Page 25] 
       


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

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |L|    Type     |Attribute Flags|Exclusion Flags|    Reserved   | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                            TLVs ...                           | 
      //                                                             // 
      |                                                               | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
       
      The meanings of respective fields in EXRS header are as defined 
      in [RFC4874]. The meanings of respective fields in 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 Diversity 
      subobject(s), 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 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].  

    
    
                       Expires January 2015                 [Page 26] 
       


   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 Description                Subobject Type  
      --------------   
                                           ---------------------  
      Diversity subobject                  To be assigned by IANA                   
                                          (suggested value: 36) 
       
       
   4.2. New EXRS subobject types 

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

    
    
                       Expires January 2015                 [Page 27] 
       


   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 Error Value Sub-
      Codes  
       
      For Error Code "Notify Error" (25) (see [RFC3209]) the following 
      sub-codes are defined. 
       
         Sub-code                            Value 
         --------                            ----- 
    
         Route of XRO                        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. 

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

    
    
                       Expires January 2015                 [Page 28] 
       


   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. 

       

    
    
                       Expires January 2015                 [Page 29] 
       


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

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

       

   Contributor's Addresses 

      Igor Bryskin 
      ADVA Optical Networking 
      Email: 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 

    
    
                       Expires January 2015                 [Page 30] 
       


   Internet Draft      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 

    
    
                       Expires January 2015                 [Page 31] 
       


   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 
       
    
       

    
    
                       Expires January 2015                 [Page 32]