Network Working Group                                     E. Oki
   Internet Draft                                               NTT
   Category: Standards Track                               A. Farrel
   Expires: January 2008                         Old Dog Consulting

                                                         July 2007

    Extensions to the Path Computation Element Communication Protocol
                       (PCEP) for Route Exclusions

                      draft-ietf-pce-pcep-xro-01.txt

   Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Abstract

   The Path Computation Element (PCE) provides functions of path
   computation in support of traffic engineering in Multi-Protocol
   Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.

   When a Path Computation Client (PCC) requests a PCE for a route, it
   may be useful for the PCC to specify, as constraints to the path
   computation abstract nodes, resources, and Shared Risk Link Groups
   (SRLGs) that are to be explicitly excluded from the computed route.
   Such constraints are termed route exclusions.

   The PCE Communication Protocol (PCEP) is designed as a communication
   protocol between PCCs and PCEs. This document presents PCEP
   extensions for route exclusions.

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


   Oki and Farrel          Expires January 2008               [Page 1]

          Extensions to PCEP for Route Exclusions   July 2007

   Table of Contents

   1. Introduction...................................................2
   2. Protocol Procedures and Extensions.............................3
   2.1.  Exclude Route Object (XRO)..................................3
   2.1.1.  Definition................................................3
   2.1.2.  Processing Rules..........................................7
   2.2.  Explicit Route Exclusion....................................8
   2.2.1. Definition..................................................8
   2.2.2. Processing Rules............................................8
   3. Exclude Route with Confidentiality.............................9
   3.1.  Exclude Route Object (XRO) carrying Path Key................9
   3.3.1. Definition..................................................9
   3.3.2. Processing Rules...........................................10
   4. IANA Considerations...........................................10
   4.1.  PCEP Objects...............................................10
   4.2.  Error Object Field Values..................................11
   5. Manageability considerations..................................11
   6. Security Considerations.......................................11
   7. References....................................................11
   7.1.  Normative Reference........................................11
   7.2.  Informative Reference......................................12
   8. Acknowledgements..............................................12
   9. AuthorsEAddresses............................................12
   10.  Intellectual Property Statement.............................12



1. Introduction

   The Path Computation Element (PCE) defined in [RFC4655] is an entity
   that is capable of computing a network path or route based on a
   network graph, and applying computational constraints. A Path
   Computation Client (PCC) may make requests to a PCE for paths to be
   computed.

   When a PCC requests a PCE for a route, it may be useful for the PCC
   to specify abstract nodes, resources, and Shared Risk Link Groups
   (SRLGs) that are to be explicitly excluded from the route.

   For example, disjoint paths for inter-domain LSPs may be computed by
   cooperation between PCEs, each of which computes segments of the
   paths across one domain. In order to achieve path computation for a
   secondary (backup) path, a PCE may act as a PCC to request another
   PCE for a route that must be a node/link/SRLG disjoint from the
   primary (working) path. Another example is where a network operator
   wants a path to avoid specified nodes for administrative reasons,
   perhaps because the specified nodes will be out-of-services in the
   near future.

   [RFC4657] specifies generic requirements for a communication
   protocol between PCCs and PCEs. Generic constraints described in
   [RFC4657] include route exclusions for links, nodes, and SRLGs. That
   is, the requirement for support of route exclusions within the PCC-
   PCE communication protocol is already established.


   Oki and Farrel        Expires January 2008                        2
          Extensions to PCEP for Route Exclusions   July 2007

   The PCE communication protocol (PCEP) is designed as a communication
   protocol between PCCs and PCEs and is defined in [PCEP]. This
   document presents PCEP extensions to satisfy the requirements for
   route exclusions as described in Sections 5.1.4 and 5.1.16 of
   [RFC4657].

   Note that MPLS-TE and GMPLS signaling extensions for communicating
   route exclusions between network nodes for specific Label Switched
   Paths (LSPs) are described in [RFC4874]. Route exclusions may be
   specified during provisioning requests for specific LSPs setting the
   mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812]
   to false.

2. Protocol Procedures and Extensions

   This section describes the procedures adopted by a PCE handling a
   request for path computation with route exclusions received from a
   PCC, and defines how those exclusions are encoded.

   There are two types of route exclusion described in [RFC4874].

   1. Exclusion of certain abstract nodes or resources on the whole
      path. This set of abstract nodes is referred to as the Exclude
      Route List.

   2. Exclusion of certain abstract nodes or resources between a
      specific pair of abstract nodes present in an explicit path. Such
      specific exclusions are referred to as an Explicit Route
      Exclusion.

   This document defines protocol extensions to allow a PCC to specify
   both types of route exclusions to a PCE on a path computation
   request.

   A new PCEP object is defined as the Exclude Route Object (XRO) to
   convey the Exclude Route List. The existing Include Route Object
   (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject,
   the Explicit Exclusion Route Subobject (EXRS), to convey Explicit
   Route Exclusions.

2.1.  Exclude Route Object (XRO)

 2.1.1. Definition

   The XRO is OPTIONAL and MAY be carried within PCReq and PCRep
   messages.

   When present in a PCReq message, the XRO provides a list of network
   resources that the PCE is requested to exclude from the path that it
   computes. Flags associated with each list member instruct the PCE as
   to whether the network resources must be excluded from the computed
   path or whether the PCE should make best efforts to exclude the
   resources from the computed path.



   Oki and Farrel        Expires January 2008                        3
          Extensions to PCEP for Route Exclusions   July 2007

   The XRO MAY be used on PCRep message with the NO-PATH object to
   indicate the set of elements of the original XRO that prevented the
   PCE from finding a path. The XRO MAY also be used on a PCRep message
   for a successful path computation when the PCE wishes to provide a
   set of exclusions to be signaled during LSP setup using the
   extensions to RSVP-TE [RFC4874].

   The XRO Object-Class is to be assigned by IANA (recommended
   value=17)

   The XRO Object-Type is to be assigned by IANA (recommended value=1)

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Reserved                |   Flags                     |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //                        (Subobjects)                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 1: XRO body format


   Flags: 16 bits - The following flags are currently defined:

   F (Fail - 1 bit): when set, the requesting PCC requires the
   computation of a new path for an existing TE LSP that has failed. If
   the F bit is set, the path of the existing TE LSP MUST be provided
   in the PCReq message by means of an RRO object defined in [PCEP].
   This allows the path computation to take into account the previous
   path and reserved resources to avoid double bandwidth booking should
   the TED have not yet been updated or the corresponding resources not
   be yet been released. This will usually be used in conjunction with
   the exclusion from the path computation of the failed resource that
   caused the LSP to fail.

   Subobjects. The XRO is up made of one or more subobject(s). An XRO
   with no subobjects MUST NOT be sent and SHOULD be ignored on receipt.

   In the following subobject definitions a set of fields have
   consistent meaning as follows:

      X
        The X-bit indicates whether the exclusion is mandatory or
        desired. 0 indicates that the resource specified MUST be
        excluded from the path computed by the PCE. 1 indicates that
        the resource specified SHOULD be excluded from the path
        computed by the PCE, but MAY be included subject to PCE policy
        and the absence of a viable path that meets the other
        constraints and excludes the resource.



   Oki and Farrel        Expires January 2008                        4
          Extensions to PCEP for Route Exclusions   July 2007

      Type
        The type of the subobject. The following subobject types are
        defined.

        Type           Subobject
        -------------+-------------------------------
        1              IPv4 prefix
        2              IPv6 prefix
        3              Unnumbered Interface ID
        4              Autonomous system number
        5              SRLG

      Length
        The length of the subobject including the Type and Length
        fields.

      Prefix Length
        Where present, this field can be used to indicate a set of
        addresses matching a prefix. If the subobject indicates a
        single address, the prefix length MUST be set to the full
        length of the address.

      Attribute
        The Attribute field indicates how the exclusion subobject is to
        be interpreted.

        0 Interface
          The subobject is to be interpreted as an interface or set of
          interfaces. All interfaces identified by the subobject are to
          be excluded from the computed path according to the setting
          of the X-bit. This value is valid only for subobject types 1,
          2, and 3.

        1 Node
          The subobject is to be interpreted as a node or set of nodes.
         All nodes identified by the subobject are to be excluded from
         the computed path according to the setting of the X-bit. This
         value is valid only for subobject types 1, 2, 3, and 4.

        2 SRLG
          The subobject identifies an SRLG explicitly or indicates all
         of the SRLGs associated with the resource or resources
         identified by the subobject. Resources that share any SRLG
         with those identified are to be excluded from the computed
         path according to the setting
          of the X-bit. This value is valid for all subobjects.

      Reserved
        Reserved fields MUST be transmitted as zero and SHOULD be
        ignored on receipt.

   The subobjects are encoded as follows:




   Oki and Farrel        Expires January 2008                        5
          Extensions to PCEP for Route Exclusions   July 2007

      IPv4 prefix 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |X|  Type = 1   |     Length    | IPv4 address (4 bytes)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | IPv4 address (continued)      | Prefix Length |   Attribute   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      IPv6 prefix 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|  Type = 2   |     Length    | IPv6 address (16 bytes)       |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IPv6 address (continued)                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IPv6 address (continued)                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IPv6 address (continued)                                      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | IPv6 address (continued)      | Prefix Length |   Attribute   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Unnumbered Interface ID 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|  Type = 3   |     Length    |    Reserved   |  Attribute    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        TE Router ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                        Interface ID                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       The TE Router ID and Interface ID fields are as defined in
       [RFC3477].

    Autonomous System Number 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |X|  Type = 4   |     Length    |    Reserved   |  Attribute    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Optional AS Number High Octets|      2-Octet AS Number        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      If a two-octet AS number is used, the optional AS Number High
      Octets MUST be set to zero.



   Oki and Farrel        Expires January 2008                        6
          Extensions to PCEP for Route Exclusions   July 2007

      SRLG 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |X|  Type = 5   |     Length    |       SRLG Id (4 bytes)       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      SRLG Id (continued)      |    Reserved   |  Attribute    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    The Attribute SHOULD be set to two (2) and SHOULD be ignored on
   receipt.

 2.1.2. Processing Rules

   A PCC builds an XRO to encode all of the resources that it wishes
   the PCE to exclude from the path that it is requested to compute.
   For each exclusion, the PCC clears the X-bit to indicate that the
   PCE is required to exclude the resources, or sets the X-bit to
   indicate that the PCC simply desires that the resources are excluded.
   For each exclusion, the PCC also sets the Attribute field to
   indicate how the PCE should interpret the contents of the exclusion
   subobject.

   When a PCE receives a PCReq message it looks for an XRO to see if
   exclusions are required. If the PCE finds more than one XRO it MUST
   use the first one in the message and MUST ignore subsequent
   instances.

   If the PCE does not recognize the XRO it MUST return a PCErr message
   with Error-Type "Unknown Object" as described in [PCEP].

   If the PCE is unwilling on unable to process the XRO it MUST return
   a PCErr message with the Error-Type "Not supported object" and
   follow the relevant procedures described in [PCEP].

   If the PCE processes the XRO and attempts to compute a path, it MUST
   adhere to the requested exclusions as expressed in the XRO. That is,
   the returned path MUST NOT include any resources encoded with the X-
   bit clear, and SHOULD NOT include any with the X-bit set unless
   alternate paths that match the other constraints expressed in the
   PCReq are unavailable.

   When a PCE returns a path in a PCRep it MAY also supply an XRO. An
   XRO in a PCRep message with the NO-PATH object indicates that the
   set of elements of the original XRO prevented the PCE from finding a
   path. On the other hand, if an XRO is present in a PCRep message
   without a NO-PATH object, the PCC SHOULD apply the contents using
   the same rules as in [RFC4874] and the PCC or a corresponding LSR
   SHOULD signal an RSVP-TE XRO to indicate the exclusions that
   downstream LSRs should apply. This may be particularly useful in
   per-domain path computation scenarios.


   Oki and Farrel        Expires January 2008                        7
          Extensions to PCEP for Route Exclusions   July 2007

   In the event that no suitable path can be computed and the PCE
   returns a PCRep message containing a NO-PATH object, the PCE MAY
   also include an XRO that lists one or more subobjects from the
   original XRO that have contributed to the PCE's inability to select
   a path.

2.2.  Explicit Route Exclusion

 2.2.1. Definition
   Explicit Route Exclusion defines network elements that must not or
   should not be used on the path between two abstract nodes or
   resources explicitly indicated in the Include Route Object (IRO)
   [PCEP]. This information is encoded by defining a new subobject for
   the IRO.

   The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS),
   has type defined by IANA (see Section 3.). The EXRS contains one or
   more subobjects in its own right. An EXRS MUST NOT be sent with no
   subobjects, and if received with no subobjects MUST be ignored.

   The format of the EXRS is 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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     //                One or more EXRS subobjects                  //
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       L
         MUST be set to zero on transmission and MUST be ignored on
         receipt.

       Reserved
         MUST be set to zero on transmission and MUST be ignored on
         receipt.

   The EXRS subobject may carry any of the subobjects defined for
   inclusion in the XRO by this document or by future documents. The
   meanings of the fields of the XRO subobjects are unchanged when the
   subobjects are included in an EXRS, except that scope of the
   exclusion is limited to the single hop between the previous and
   subsequent elements in the IRO.

 2.2.2. Processing Rules

   A PCC that supplies a partial explicit route to a PCE in an IRO MAY
   also specify explicit exclusions by including one or more EXRSes in
   the IRO.

   If a PCE parses an IRO in a received PCReq message and encounters an
   EXRS and does not recognize the subobject it MUST respond with a
   PCErr message using the Error-Type "Unrecognized IRO subobject" and
   set the Error-Value to the subobject type code of the EXRS (see
   Section 3).

   Oki and Farrel        Expires January 2008                        8
          Extensions to PCEP for Route Exclusions   July 2007

   If a PCE parses an IRO and encounters an EXRS that it recognizes,
   but detects an EXRS subobject that it does not recognize it MUST act
   according to the setting of the X-bit in the subobject. If the X-bit
   is clear, the PCE MUST respond with a PCErr with Error-Type
   "Unrecognized EXRS subobject" and set the Error-Value to the EXRS
   subobject type code (see Section 3). If the X-bit is set, the PCE
   MAY respond with a PCErr as already stated or MAY ignore the EXRS
   subobject: this choice is a local policy decision.

   If a PCE parses an IRO and encounters an EXRS subobject that it
   recognizes, it MUST act according to the requirements expressed in
   the subobject. That is, if the X-bit is clear, the PCE MUST NOT
   produce a path that includes any resource identified by the EXRS
   subobject in the path between the previous abstract node in the IRO
   and the next abstract node in the IRO. If the X-bit is set, the PCE
   SHOULD NOT produce a path that includes any resource identified by
   the EXRS subobject in the path between the previous abstract node in
   the IRO and the next abstract node in the IRO unless it is not
   possible to construct a path that avoids that resource while still
   complying with the other constraints expressed in the PCReq message.

   A successful path computation reported in a PCRep message MUST
   include an ERO to specify the path that has been computed. That ERO
   MAY contain specific route exclusions using the EXRS as specified in
   [RFC4874].

   If the path computation fails and a PCErr is returned with a NO-PATH
   object, the PCE MAY include an IRO to report the hops that could not
   be complied with, and that IRO MAY include EXRSes.

3. Exclude Route with Confidentiality

3.1.  Exclude Route Object (XRO) carrying Path Key

 3.3.1. Definition

   In PCE-based inter-domain diverse path computation, an XRO may be
   used to find a backup (secondary) path. A sequential path
   computation approach may be applied for this purpose, where a
   working (primary) path route is computed first and a backup path
   route that must be a node/link/SRLG disjoint route from the working
   path is then computed [INTER-DOMAIN-REC-ANA]. Backward Recursive
   Path Computation (BRPC) may be used for inter-domain path
   computation [BRPC].

   In some cases of inter-domain computation (e.g., where domains are
   administered by different service providers), confidentiality must
   be kept. For primary path computation, to preserve confidentiality,
   instead of explicitly expressing the computed route, Path Key
   Subobjects (PKSs) [PCE-PATH-KEY] are carried in the Explicit Route
   Object (ERO) in the PCRep Message.

   Therefore, during inter-domain diverse path computation, it may be
   necessary to request diversity from a path that is not fully known
   and where a segment of the path is represented by a PKS. This means
   that a PKS may be present as a subobject of the XRO on a PCReq
   message.

   Oki and Farrel        Expires January 2008                        9
          Extensions to PCEP for Route Exclusions   July 2007

   The format and definition of PKS when it appears as an XRO subobject
   are as defined in [PCE-PATH-KEY], except for the definition of L bit.
   The L bit of the PKS subobject in the XRO is defined as follows.

   L
     The L bit MUST be ignored.

 3.3.2. Processing Rules

   Consider that BRPC is applied for both working and backup path
   computation in a sequential manner. First, PCC requests PCE for the
   computation of a working path. After BRPC processing has completed,
   the PCC receives the results of the working-path computation
   expressed in an ERO in a PCRep message. The ERO may include PKSs if
   certain segments of the path are to be kept confidential.

   For backup path computation, when the PCC constructs a PCReq Message,
   it includes the entire working-path in the XRO so that the computed
   path is node/link disjoint from the working path. The XRO may also
   include SRLGs to ensure SRLG diversity from the working path. If the
   working path ERO includes PKS subobjects, these are also included in
   the XRO to allow the PCE to ensure diversity.

   A set of PCEs for backup path computation may be the same as ones
   for working path computation, or they may be different.

   - Identical PCEs

      In the case where the same PCEs are used for both path
   computations, the processing is as follows. During the process of
   BRPC for backup path computation, a PCE may encounter a PKS as it
   processes the XRO when it creates a virtual path tree (VPT) in its
   own domain. The PCE retrieves the PCE-ID from the PKS, recognizes
   itself, and converts the PKS into a set of XRO subobjects which it
   uses for the local calculation to create the VPT. The XRO subobjects
   created in this way MUST NOT be shared with other PCEs. Other
   operations are the same as BRPC.

   - Different PCEs

      In the case where a set of PCEs for bakup path computation is
   different from the ones used for working path computation, the
   processing is as follows. If a PCE encounters a PKS in an XRO when
   it is creating a virtual path tree in its own domain, the PCE
   retrieves the PCE-ID from the PKS and sends a PCReq message to the
   identified PCE to expand the PKS. The PCE computing the VPT treats
   the path segment in the response as a set of XRO subobjects in
   performing its path computation. The XRO subobjects determined in
   this way MUST NOT be shared with other PCEs.

4. IANA Considerations

  4.1. PCEP Objects

   The "PCEP Parameters" registry contains a subregistry "PCEP Objects".
   IANA is requested to make the following allocations from this
   registry.

   Oki and Farrel        Expires January 2008                       10
          Extensions to PCEP for Route Exclusions   July 2007

   Object  Name          Object  Name
   Class                 Type
     17    XRO             1     Route exclusion

  4.2. Error Object Field Values.

   The "PCEP Parameters" registry contains a subregistry "PCEP Errors".
   IANA is requested to make the following allocations from this
   registry.

   Values in this section are recommended and to be confirmed by IANA.

      Error   Meaning and Error-Values
      Type

      11      Unrecognized IRO subobject
   Note that this Error-Type has been omitted from [PCEP] where it is
   required. It is expected that it will be added to a later version of
   [PCEP] and removed from this document.

      12      Unrecognized EXRS subobject

5. Manageability considerations

   A MIB module for management of the PCEP is specified in a separate
   document. This MIB module allows examination of individual PCEP
   messages, in particular requests, responses and errors.

   The MIB module MUST be extended to include the ability to view the
   route exclusion extensions defined in this document.

6. Security Considerations

   The new exclude route mechanisms defined in this document allow
   finer and more specific control of the path computed by a PCE. Such
   control increases the risk if a PCEP message is intercepted,
   modified, or spoofed. Therefore, the security techniques described
   in [PCEP] are considered more important.

7. References

7.1.  Normative Reference

   [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
   requirements levels", RFC 2119, March 1997.

   [PCEP] JP. Vasseur et al, "Path Computation Element (PCE)
   communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep
   (work in progress).

   [INTER-DOMAIN-REC-ANA] T. Takeda et al., "Analysis of Inter-domain
   Label Switched Path (LSP) Recovery" draft-ietf-ccamp-inter-domain-
   recovery-analysis (work in progress).

   [PCE-PATH-KEY] R. Bradford, JP Vasseur, and A. Farrel, "Preserving
   Topology Confidentiality in Inter-Domain Path Computation using a
   key based mechanism", draft-ietf-pce-path-key (work in progress).

   Oki and Farrel        Expires January 2008                       11
          Extensions to PCEP for Route Exclusions   July 2007

   [BRPC] JP. Vasseur et al, "A Backward Recursive PCE-based
   Computation (BRPC) procedure to compute shortest inter-domain
   Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc
   (work in progress).

7.2.  Informative Reference

   [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links
   in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)",
   RFC 3477, January 2003.

   [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
   "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE)
   Management Information Base (MIB)", RFC 3812, June 2004.

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

   [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE)
   Communication Protocol Generic Requirements", RFC 4657, September
   2006.

   [RFC4874] Lee et al, "Exclude Routes - Extension to Resource
   ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April
   2007.

8. Acknowledgements

   Authors would like to thank Tomonori Takeda for valuable comments on
   inter-domain path computation.

9. Authors' Addresses

   Eiji Oki
   NTT
   3-9-11 Midori-cho,
   Musashino-shi, Tokyo 180-8585, Japan
   Email: oki.eiji@lab.ntt.co.jp

   Adrian Farrel
   Old Dog Consulting
   Email: adrian@olddog.co.uk

10.     Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   Oki and Farrel        Expires January 2008                       12           Extensions to PCEP for Route Exclusions   July 2007


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

   Disclaimer of Validity

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

   Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.











   Oki and Farrel        Expires January 2008                       13