CCAMP Working Group                                        Zafar Ali
   Internet Draft                                        George Swallow
   Intended status: Standard Track                    Clarence Filsfils
   Expires: August 11, 17, 2013                                Matt Hartley
                                                             Ori Gerstel
                                               Gabriele Maria Galimberti
                                                           Cisco Systems
                                                            Kenji Kumaki
                                                        KDDI Corporation
                                                          Ruediger Kunze
                                                     Deutsche Telekom AG
                                                           Julien Meuric
                                                   France Telecom Orange
                                                       February 12, 18, 2013

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

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

                     draft-ietf-ccamp-lsp-diversity-01.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 11, 17, 2013.

   Copyright Notice

   Copyright (c) 2013 2012 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-00.txt

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.

   Abstract

   [RFC4874]

   RFC 4874 specifies methods by which route exclusions may be
   communicated during RSVP-TE signaling in networks where precise
   explicit paths are not computed by the LSP ingress source node. This
   document specifies signaling for additional route exclusions based
   on LSPs 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 ...............................................3
         1.1. Requirements Notation .................................5 ..................................................3
   2. RSVP-TE signaling extensions ...............................5 ..................................5
   2.1. Terminology ...........................................5 .................................................5
   2.2. LSP Subobject .........................................5
         2.3. Processing rules for the LSP subobject ...............10
         2.4. LSP Subobject in Explicit Exclusion Route Subobject ..11
            2.4.1. Processing Rules for the EXRS with LSP subobject.12
      4. IANA Considerations .......................................12
         4.1. New Path XRO subobject type ...............................12
         4.2. New EXRS subobject type ..............................12
         4.3. New RSVP error sub-code ..............................12
      5. Acknowledgement ...........................................13
      6. References ................................................13
         6.1. Normative References .................................13
         6.2. Informative References ...............................13

      1. Introduction ...............................................3
         1.1. Requirements Notation .................................5
      2. RSVP-TE signaling extensions ...............................5
         2.1. Terminology ...........................................5
         2.2. LSP Subobjects ........................................5 .........................................5
   2.2.1. IPv4 Point-to-Point LSP Path subobject ............... ....................... 5
   2.2.2. IPv6 Point-to-Point LSP Path subobject ............... ....................... 9
   2.3. Processing rules for the LSP subobject ...............10 Path XRO subobjects  ..............10
   2.4. LSP Subobject in Explicit Exclusion Route Path EXRS Subobject
         (EXRS) ....................................................13 ........................................13
   2.4.1. Processing Rules for the EXRS with LSP Path subobject ....... 14
   3. Security Considerations ...................................14  .....................................14
   4. IANA Considerations .......................................14  .........................................14
   4.1. New XRO subobject type ...............................14

   Internet Draft       draft-ietf-ccamp-lsp-diversity-00.txt types ....................................14
   4.2. New EXRS subobject type ..............................14 types ...................................15
   4.3. New RSVP error sub-code ..............................14 sub-codes....................................15

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

   5. Acknowledgement ...........................................15 Acknowledgements .............................................15
   6. References ................................................15 ...................................................15
         6.1. Normative References .................................15
         6.2. Informative References ...............................15 ...............................16

   1. Introduction

      Label-Switched

      Path (LSP) diversity is a well-known requirement from Service Providers.
      Such diversity is required to ensure LSPs Label-Switched Path (LSPs)
      may be established without sharing resources, thus greatly
      reducing the probability of simultaneous connection failures.

      LSP diversity is a well-known requirement from Service Providers.

      When route computation for LSPs paths that need to be diverse is
      performed at ingress the LSP's source node, this requirement can be met by
      a local decision at that node. However, there are scenarios when
      route computations are performed by remote nodes, in which case there is a need
      for relevant diversity requirements to be communicated to those
      nodes. These include (but are not limited to):

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

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

      The eXclude Route Object (XRO) and Explicit Exclusion Route
      Subobject (EXRS) specification

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

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

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

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

      .  Exclusion of the route of a LSP path which, while known at the
         ingress source node of
         the diverse LSP, has incomplete or unavailable route
         information, e.g. due to confidentiality of the LSP route path

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

         attributes. In other words, the scenario in which the reference
         LSP
         path is hosted by the ingress/ source / requesting node but the
         properties required to construct an XRO object are not known to
         ingress/
         source / requesting node. Inter-domain and GMPLS overlay
         networks may present such restrictions.

      .  If the source node knows the route of the reference LSP path from
         which diversity is
         required (e.g. LSP1) is known to the ingress node, that node required, it can use this information to
         construct an XRO and send it in the path message during the
         signaling of a diverse LSP (LSP2). LSP. However, if the route of LSP1 the
         excluded path changes (e.g. due to re-
         optimization re-optimization or failure
         in the network), the ingress source node would need to change the
         diverse path of LSP2 to ensure that it remains diverse from LSP1. the
         excluded path. It is preferable to have this decision made by
         the node that calculated performed the path path-calculation for LSP2. the diverse
         path. For example, in the case of GMPLS-UNI, it is better to
         have such responsibility at the server layer as opposed to at
         the client layer so that the diversity requirements are
         transparent to the client layer. Furthermore, in all networking
         scenarios, if the node performing the route computation/
         expansion is aware of the diversity requirements of LSP1 and LSP2, the two
         paths, it may consider joint re-optimization of the diverse LSPs.
         paths.

      This document addresses such scenarios and defines procedures
      that may be used to exclude the route taken by a particular LSP,
      or the route routes taken by all LSPs belonging to a single tunnel.
      Note that this diversity requirement is different from the
      diversity requirements of path protection where both the
      reference and diverse LSPs belong to the same tunnel. The
      diversity requirements considered in this document do not require
      that the
      LSPs paths in question belonging to the same tunnel or share an ingress
      the same source or destination node.

      The means by which the node calculating or expanding the route of
      the signaled LSP discovers the route of the LSPs path(s) from which
      the signaled LSP requires diversity is are beyond the scope of this
      document. However, in most cases the LSPs with route diversity
      requirements may transit the node expanding the route.

      This document addresses only the exclusion of point-to-point
      tunnels;
      paths; point-to-multipoint tunnels paths will be addressed in a future
      version. Similarly, at present only IPv4 addresses

      If mutually diverse routes are
      considered; support desired for IPv6 addresses will be added in a future
      version.

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

   1.1. Requirements Notation two LSPs belonging to
      different tunnels, it is recommended that they be signaled with
      XRO LSP subobjects referencing each other. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
      "OPTIONAL" processing rules
      specified in this document are to be interpreted as described in
      [RFC2119]. cover this case.

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

   2. RSVP-TE signaling extensions

      This section describes the signaling extensions required to
      address the aforementioned requirements. Specifically, this
      document defines a new LSP subobject to be signaled in the
      EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route
      Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP
      subobject in any other RSVP object is not defined.

   2.1. Terminology

      In this document, the following terminology is adopted:

      LSP1/TUNNEL1: LSP1/TUNNEL1 is

      Excluded path: the LSP/tunnel path from which diversity is required.

      LSP2/TUNNEL2: The term LSP2/TUNNEL2 is used to refer

      Diverse LSP: the LSP being signaled with XRO/ EXRS containing the LSP
      path subobject referencing LSP1/TUNNEL1.

      CircuitID: The term CircuitID refers to the LSP Forwarding
      Equivalence Class (FEC) (LSP ID field excluded path(s).

      Processing node: the node performing a path-calculation involving
      an exclusion specified in an XRO or EXRS.

      Destination node: in the context of an XRO, this is the
      destination of the FEC may be ignored
      depending on LSP being signaled. In the context of an EXRS,
      the CircuitID term destination node is used).

      CircuitIDx: The term CicuitIDx refers the last explicit node to CircuitID which the loose
      hop is expanded.

      Penultimate node: in the context of
      LSPx/TUNNELx.

   2.2. an XRO, this is the
      penultimate hop of the LSP being signaled. In the context of an
      EXRS, the penultimate node is the penultimate node of the loose
      hop undergoing expansion.

   2.2. Path XRO Subobjects

      New IPv4 and IPv6 Point-to-Point (P2P) LSP subobject Path XRO subobjects are
      defined by this document as follows.

   2.2.1. IPv4 Point-to-Point LSP 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Internet Draft       draft-ietf-ccamp-lsp-diversity-00.txt
      |L|    Type     |     Length    |Attribute Flags|Exclusion Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |

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

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

        L
             The L-flag is used as for the other XRO subobjects defined
             in [RFC4874].

             0 indicates that the attribute specified MUST be excluded.

             1 indicates that the attribute specified SHOULD be
             avoided.

        Type

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

        Length

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

        Attribute Flags

            The Attribute Flags are used to communicate desirable
            attributes of the LSP being signaled (In the following, the
            term LSP2 is used to reference the LSP being signaled;
            please refer to Section 2.1 for definition of LSP2). signaled. The following flags
            are defined. None, all or multiple attribute flags MAY be
            set within the same subobject.

            0x01 = LSP ID to be ignored

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

               This flag is used to indicate tunnel level exclusion.
               Specifically, this flag is used to indicate that the
               lsp-id field of the subobject is to be ignored and the

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

               exclusion applies to any LSP matching the rest of the
               supplied FEC. In other words, if this

            0x02 = Destination node exception

               This flag is set, used to indicate that the
               processing destination node MUST calculate a route based on
               exclusions from the routes
               of all known LSPs matching the tunnel-id, source, destination and extended tunnel-
               id specified in LSP being signaled MAY be shared with the subobject.

               When
               excluded path even when this flag is not set, the lsp-id is not ignored and violates the exclusion applies only
               flags.

            0x04 = Processing node exception

               This flag is used to the specified LSP (i.e.,
               LSP level exclusion). In other words, when this flag is
               not set, route exclusions MUST respect the specified LSP
               (i.e. the lsp-id, the tunnel-id, source, destination and
               extended tunnel-id specified needs to be respected
               during exclusion).

            0x02 = Destination node exception

               This flag is used to indicate that the destination node
               may be shared even when sharing of the said node
               violates the exclusion flags. When this flag is not set,
               the exclusion flags SHOULD also be respected for the
               destination node.

            0x04 = Processing node exception

               This flag is used to indicate that indicate that the processing node
               may
               MAY be shared with the excluded path even when sharing of the said node this
               violates the exclusion flags. When this flag is not set,
               the exclusion flags SHOULD also be respected for the
               processing node.

            0x08 = Penultimate node exception

               This flag is used to indicate that the penultimate node
               may
               of the LSP being signaled MAY be shared with the
               excluded path even when sharing of the said node this violates the exclusion
               flags. When this flag is not set,
               the exclusion flags SHOULD also be respected for the
               penultimate node.

        Exclusion Flags

             The Exclusion-Flags are used to communicate desirable
             types of exclusion. The following flags are defined.

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

             0x01 = SRLG exclusion

                  This flag is used to indicate that the route of the
                  LSP being signaled is requested to be SRLG diverse
                  from the route of the LSP or tunnel excluded path specified by the LSP
                  subobject.

             0x02 = Node exclusion

                  This flag is used to indicate that the route of the
                  LSP being signaled is requested to be node diverse
                  from the route of the LSP or tunnel excluded path specified by the LSP
                  subobject. The node exclusion is subobject to

                  (Note: the
                  setting meaning of this flag may be modified by
                  the "Processing node exception", the
                  "Penultimate node exception" and value of the "Destination
                  node exception" Attribute Flags. Attribute-flags.)

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

             0x04 = Link exclusion

                  This flag is used to indicate that the route of the
                  LSP being signaled is requested to be link diverse
                  from the route of the LSP or tunnel path specified by the LSP subobject.

      The remaining fields are as defined in [RFC3209].

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

   2.2.2. IPv6 Point-to-Point LSP 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 for the other XRO subobjects defined
             in [RFC4874].

             0 indicates that the attribute specified MUST be excluded.

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

             1 indicates that the attribute specified SHOULD be
             avoided.

        Type

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

        Length

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

      The Attribute Flags and Exclusion Flags are as defined for the
      IPv4 Point-to-Point LSP XRO subobject.

      The remaining fields are as defined in [RFC3209].

   2.3. Processing rules for the LSP subobject Path XRO subobjects

      XRO processing as described in [RFC4874] is unchanged.

      If the processing node is the destination for the LSP being
      signaled, it SHOULD NOT process a LSP Path XRO subobject.

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

      -  The processing node MUST ensure that any route calculated for
         the signaled LSP (LSP2) respects the requested exclusion flags with
         respect to the route traversed by the LSP(s) excluded path referenced by the LSP subobject (LSP1/TUNNEL1), subobject,
         including local resources.

      -  If the processing node fails to find a route that meets the
         requested constraint, the processing node SHOULD MUST return a PathErr
         with the error code "Routing Problem (24)" Problem" (24) and error
         value sub-code
         "Route blocked by Exclude Route (67)". Route" (67).

      -  If the route of the LSP or tunnel (LSP1/TUNNEL1) excluded path referenced in the LSP subobject is
         unknown to the processing node, the processing node SHOULD
         ignore the LSP subobject in the XRO and SHOULD proceed with the
         signaling request (for LSP2). However,

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

         in this case, after request. After sending the Resv for LSP2, the signaled LSP,
         the processing node SHOULD return a PathErr with the error code
         "Notify Error (25)" Error" (25) and error value sub-code "Route of XRO LSP unknown (value: path
         unknown" (value to be assigned by IANA, suggest suggested value: 13)" for LSP2.

      -  If latter, the route of the LSP or tunnel (LSP1/TUNNEL1)
         referenced in the LSP subobject becomes known (e.g. when LSP1
         is signaled) or the TUNNEL1 is re-optimized to a different
         route, such that the requested exclusion/ diversity constraints
         are no longer satisfied and a path that can satisfy the
         requested constraints exists, the node calculating or expanding
         the path SHOULD send a PathErr message 13)
         for LSP2 with the error
         code "Notify Error (25)" and error value "Preferable path
         exists (6)". An ingress node receiving this error code/value
         combination MAY try to reoptimize the LSP2 to the new preferred
         path.

      -  Route computation for the LSP or tunnel (LSP1/ TUNNEL1)
         referenced in the LSP subobject for new setup or for re-
         optimization LSP SHOULD be performed to avoid situation where
         the requested exclusion/ diversity constraints are no longer
         satisfied and a path that can satisfy the requested constraints
         does not exist. However, if such situation arises the node that
         computed or expanded the route for LSP2 SHOULD send a PathErr
         message for LSP2 with the error code "Routing Problem (24)" and
         error value "Route blocked by Exclude Route (67)". signaled LSP.

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

      -  The processing node SHOULD respect the requested exclusion
         flags with respect to the route traversed by the referenced
         LSP(s) (LSP1/TUNNEL1) excluded path as far as possible.

      -  If the processing node fails to find a route that meets the
         requested constraint, it SHOULD proceeds proceed with signaling using a
         suitable route that best meets the constraint, but after completion of
         signaling setup, 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)" Error" (25) and error value
         sub-code "Failed to respect Exclude Route Route" (value: to be
         assigned by IANA, suggest value: 14)" 14) to the ingress source node.

      -  If the route of the LSP or tunnel (LSP1/TUNNEL1) excluded path referenced in the LSP subobject is
         unknown to the processing node, the processing node SHOULD
         ignore the LSP subobject in the XRO and SHOULD proceed with the
         signaling request (for LSP2). However,
         in this case, after request. After sending the Resv for LSP2, signaled LSP, the
         processing node

   Internet Draft       draft-ietf-ccamp-lsp-diversity-00.txt SHOULD return a PathErr message with the error
         code "Notify Error" (25) and error value sub-code "Route to of XRO LSP path
         unknown" for LSP2.

      -  If latter, the route of signaled LSP.

      If, subsequent to the LSP or tunnel (LSP1/TUNNEL1) initial signaling of a diverse LSP:

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

      -   A change in the TUNNEL1 is re-optimized excluded path becomes known to a different
         route, such that the requested exclusion/ 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 a path an alternative route for the
         diverse LSP that can satisfy the
         requested those constraints exists, the
         processing node calculating or expanding
         the path SHOULD send a PathErr message for LSP2 the diverse
         LSP with the error code "Notify Error (25)" Error" (25) and error value sub-code
         "Preferable path
         exists". An ingress exists" (6). A source node receiving a PathErr
         message with this error code/value code and sub-code combination MAY try
         to reoptimize the LSP2 diverse tunnel to the new preferred compliant path.

      -  Route computation for the LSP or tunnel (LSP1/ TUNNEL1)
         referenced in the LSP subobject for new setup or for re-
         optimization LSP SHOULD be performed to avoid situation where   If the requested exclusion/ diversity exclusion constraints for the diverse LSP
         are no longer satisfied and a no alternative path for the diverse
         LSP that can satisfy the requested those constraints
         does exists, then:

           o If the L-flag was not exist. However, if such situation arises set in the node that
         computed or expanded original exclusion, the route
              processing node MUST send a PathErr message for LSP2 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 LSP2 the
              diverse LSP with the error code error code "Notify Error"
              (25) and error
         value sub-code "Failed to respect Exclude Route". Route"
              (value: to be assigned by IANA, suggest value: 14).

      The following rules apply equally to L = 0 and L = 1 case: whether or not the L-flag is set:

      -  An XRO object MAY contain multiple LSP path subobjects. In this case,
         the processing node A

      -  As specified in [RFC4874], a node receiving a Path message
         carrying an XRO MAY reject the message if the XRO is too large
         or complicated for the local implementation or the rules of
         local
         policy, as per the roles of XRO defined in [RFC4874]. policy. In this case, the node MUST send a PathErr
         message with the error code "Routing Error" (24) and error value sub-
         code "XRO Too Complex".  An
         ingress Complex" (68).  A source node receiving this
         error code/value code/sub-code combination MAY reduce the complexity of
         the XRO or route around the node that rejected the XRO.

      -  An ingress  A source node receiving a PathErr message with the error code
         "Notify Error" (25) and error values sub-codes "Route to of XRO LSP path
         unknown" or "Failed to respect Exclude Route" MAY take no action other than simply
         logging these notifications.

      Note that LSP1 may be signaled with an XRO LSP subobject
      referencing CircuitID2 (LSP2 FEC) and LSP2 may be signaled with
      an XRO LSP subobject referencing CircuitID1 (LSP1 FEC).
         action.

      -  The
      above-mentioned attribute-flags affect the processing rules cover this case. In fact, if

   Internet Draft       draft-ietf-ccamp-lsp-diversity-00.txt of the XRO subobject
         as follows:

           o  When the "LSP ID to be ignored" attribute flag is set when LSP1 is
      signaled with an XRO LSP subobject referencing CircuitID2, it set, the
             processing node MUST calculate a route based on exclusions
             from the routes of all known LSPs matching the tunnel-id,
             source, destination and extended tunnel-id specified in
             the subobject. 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).

           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
      RECOMMENDED that LSP2 not set, the
             exclusion flags SHOULD also be respected for the
             processing node.

           o  When the "penultimate node exception" flag is signaled with an XRO LSP subobject
      referencing CircuitID1. not set, the
             exclusion flags SHOULD also be respected for the
             penultimate node.

   2.4. LSP Subobject in Explicit Exclusion Route Path EXRS Subobject (EXRS)

      [RFC4874] defines an the EXRS ERO subobject called Explicit Exclusion
      Route Subobject (EXRS). 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) LSP subobject. Path subobject
      as specified in section 2.2.1. In this case, the EXRS format
      would look 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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|    Type     |     Length    |Attribute Flags|Exclusion Flags|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 IPv4 tunnel end point address                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |     Tunnel ID                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Extended Tunnel ID                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   IPv4 tunnel sender address                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Must Be Zero         |            LSP ID             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The meaning of respective fields in EXRS header is as defined in
      [RFC4874]. Similarly, the The meaning of respective fields in IPv4 P2P LSP Path
      subobject is as defined earlier in this document. This is with
      the exceptions that:

      -  Processing  The processing node exception applies to the node processing
         the ERO.

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

      -  If the L bit in the ERO header is not set (ERO.L = 0), the
         IPv4 P2P LSP Path subobject is processed against the LSPs path(s) for
         which the processing node is ingress, egress or a source, destination or transit
         node.

      -  Penultimate  The penultimate node exception applies to the penultimate node
         of the loose hop. This flag is only processed if EXRS.L the ERO.L bit
         is set, i.e., i.e. in the loose ERO hop case.

      -  Destination  The destination node exception applies to the abstract last explicit
         node to which the route loose hop is expanded. This flag is only
         processed if
         EXRS.L ERO.L bit is set, i.e., in the loose ERO hop case.

   2.4.1. Processing Rules for the EXRS with LSP Path subobject

      Processing

      The processing rules for the EXRS object are same as processing rules
      as described in unchanged from
      [RFC4874]. When the EXRS contains one or more LSP Path subobject(s),
      the processing rule rules specified in Section 2.3 applies apply to the node
      processing the ERO with the EXRS subobject.

      The EXRS scope is limited to the loose hop in which the EXRS
      appears. If 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.

   3. Security Considerations

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

   4. IANA Considerations

   4.1. New XRO subobject type types

      IANA registry: RSVP PARAMETERS
      Subsection: Class Names, Class Numbers, and Class Types
      This document introduces a two new subobject subobjects for the EXCLUDE_ROUTE
      object [RFC4874], C-Type 1.

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

   4.2. New EXRS subobject type types

      The IPv4 and IPv6 P2P LSP subobject is Path subobjects are also defined as a new
      EXRS subobject. subobjects.

   4.3. New RSVP error sub-code sub-codes

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

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

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

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

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

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

   5. Acknowledgement

      Authors Acknowledgements

      The authors would like to thanks 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.

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

   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.

      [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol
                (RSVP) -- Version 1 Message Processing Rules", RFC
                2209, September 1997.

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

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

   Authors' Addresses

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

      George Swallow
      Cisco Systems
      swallow@cisco.com

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

      Ori Gerstel
      Cisco Systems
      ogerstel@cisco.com

      Gabriele Maria Galimberti
      Cisco Systems
      ggalimbe@cisco.com

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

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

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