Skip to main content

Encoding of Data Structure (DS) in the Path Computation Element Communication Protocol (PCEP)
draft-dhody-pce-pcep-ds-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Dhruv Dhody , Udayasree Palle
Last updated 2012-02-17 (Latest revision 2011-06-29)
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-dhody-pce-pcep-ds-01
PCE Working Group                                               D. Dhody
Internet-Draft                                                  U. Palle
Intended status: Experimental              Huawei Technologies India Pvt
Expires: August 20, 2012                                             Ltd
                                                       February 17, 2012

    Encoding of Data Structure (DS) in the Path Computation Element
                     Communication Protocol (PCEP)
                       draft-dhody-pce-pcep-ds-01

Abstract

   The ability to compute shortest constrained Traffic Engineering Label
   Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks across multiple domains has been
   identified as a key requirement for P2P and P2MP scenarios.
   Backward-Recursive PCE-Based Computation (BRPC) [RFC5441] defines
   VSPT [Virtual Shortest Path Tree] as a default de-facto data
   structure for PCRep message in inter-domain scenarios.

   AS PCE will get used in newer scenarios like inter-domain,
   protection, P2MP etc.  As well as PCE is being explored to be used in
   Cross Stratrum Optimization (CSO) environment (see [CSO-PCE]).
   Limiting PCEP protocol to just one data structure limits the usage of
   PCEP.  Its important to keep PCEP generic enough to use differnt data
   structure and apply different algorithms.

   This document defines extensions to the PCE communication Protocol
   (PCEP) to allow multiple data structures.  Extensions are defined for
   PCE to indicate the set of Data Structure (DS) it supports; also PCC/
   PCE can indicate in a path computation request the required DS, and a
   PCE can report in a path computation reply the Data Structure that
   was used in the path reply message.

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

Dhody & Palle            Expires August 20, 2012                [Page 1]
Internet-Draft                     DS                      February 2012

   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 20, 2012.

Copyright Notice

   Copyright (c) 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.

Dhody & Palle            Expires August 20, 2012                [Page 2]
Internet-Draft                     DS                      February 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Need for multiple Data Structure . . . . . . . . . . . . . . .  5
     3.1.  Point to Multipoint (P2MP) . . . . . . . . . . . . . . . .  5
     3.2.  Synchronized Dependent Path Computations . . . . . . . . .  6
     3.3.  Hierarchical PCE . . . . . . . . . . . . . . . . . . . . .  6
     3.4.  Others . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  PCE in future  . . . . . . . . . . . . . . . . . . . . . .  7
     3.6.  Others Techniques  . . . . . . . . . . . . . . . . . . . .  7
   4.  Discovery of PCE Data Structure  . . . . . . . . . . . . . . .  7
     4.1.  DS-List TLV  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Elements of Procedure  . . . . . . . . . . . . . . . . . .  8
   5.  Data Structure in PCEP Path Computation Request and Reply
       Messages . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  DS Object  . . . . . . . . . . . . . . . . . . . . . . . .  9
       5.1.1.  Elements of Procedure  . . . . . . . . . . . . . . . . 10
     5.2.  Carrying The DS Object In a PCEP Message . . . . . . . . . 11
     5.3.  New RP Object Flag . . . . . . . . . . . . . . . . . . . . 13
       5.3.1.  Elements of Procedure  . . . . . . . . . . . . . . . . 14
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  PCE Data Structure Sub-Registry  . . . . . . . . . . . . . 15
     6.2.  PCEP Code Points . . . . . . . . . . . . . . . . . . . . . 15
       6.2.1.  DS Object  . . . . . . . . . . . . . . . . . . . . . . 15
       6.2.2.  DS-List TLV  . . . . . . . . . . . . . . . . . . . . . 15
       6.2.3.  PCEP Error Values  . . . . . . . . . . . . . . . . . . 16
       6.2.4.  RP Object Flag . . . . . . . . . . . . . . . . . . . . 16
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Manageability Considerations . . . . . . . . . . . . . . . . . 17
     8.1.  Control of Function and Policy . . . . . . . . . . . . . . 17
     8.2.  Information and Data Models  . . . . . . . . . . . . . . . 17
     8.3.  Liveness Detection and Monitoring  . . . . . . . . . . . . 17
     8.4.  Verify Correct Operations  . . . . . . . . . . . . . . . . 17
     8.5.  Requirements On Other Protocols  . . . . . . . . . . . . . 17
     8.6.  Impact On Network Operations . . . . . . . . . . . . . . . 17
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18

Dhody & Palle            Expires August 20, 2012                [Page 3]
Internet-Draft                     DS                      February 2012

1.  Introduction

   The Path Computation Element (PCE) architecture is defined in
   [RFC4655].  [RFC5441] describe a PCE-based path computation procedure
   to compute optimal inter-domain constrained (G)MPLS TE LSPs.  It also
   defines VSPT [Virtual Shortest Path Tree] which is the only data
   structure and is used in all inter-domain scenarios.

   This document describes the need for multiple data structure (DS).
   It may be useful for a PCC/PCE to discover the set of Data Structure
   (DS) supported by a PCE.  Furthermore, PCC/PCE requires the ability
   to indicate in a path computation request a required/desired Data
   Structure, as well as optional function parameters.

   For these purposes, this document extends the PCE communication
   Protocol (PCEP).  It defines PCEP extensions that allow a PCE to
   advertise a list of supported Data Structure (DS), as well as
   extensions to carry Data Structure (DS) in PCEP request and reply
   messages.  It complements the PCEP base specification [RFC5440].

   Note that OSPF and IS-IS-based PCE discovery mechanisms are defined
   in [RFC5088] and [RFC5089].  These mechanisms are dedicated to the
   discovery of a few generic parameters, while more detailed PCE
   parameters should be discovered using the PCE communication Protocol.

   Data Structure (DS) are in this second category; thus, the Data
   Structure discovery procedure is handled by PCEP.

   A new PCEP TLV, named the DS-List TLV, is defined in Section 4.  The
   DS-List TLV is carried in the PCEP OPEN object and allows a PCE to
   list, during PCEP session-setup phase, the Data Structure (DS) that
   it supports.

   A new PCEP object, the DS object, is defined in Section 5.  The DS
   object is carried within a PCReq (Path Computation Request) message
   to indicate the required/desired data structure to be applied by a
   PCE, or in a PCRep (Path Computation Reply) message to indicate the
   data structure that was used for path computation and the reply
   message.

1.1.  Requirements Language

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

Dhody & Palle            Expires August 20, 2012                [Page 4]
Internet-Draft                     DS                      February 2012

2.  Terminology

   The following terminology is used in this document.

   BRPC:  Backward Recursive Path Computation.

   DS:  Data Structure.

   H-PCE:  Hierarchical PCE.

   IGP:  Interior Gateway Protocol.  Either of the two routing
      protocols, Open Shortest Path First (OSPF) or Intermediate System
      to Intermediate System (IS-IS).

   IS-IS:  Intermediate System to Intermediate System.

   OF:  Objective Function.

   OSPF:  Open Shortest Path First.

   PCC:  Path Computation Client: any client application requesting a
      path computation to be performed by a Path Computation Element.

   PCE:  Path Computation Element.  An entity (component, application,
      or network node) that is capable of computing a network path or
      route based on a network graph and applying computational
      constraints.

   P2MP:  Point-to-Multipoint

   P2P:  Point-to-Point

   TE LSP:  Traffic Engineering Label Switched Path.

   TLV:  Type-Length-Variable data encoding.

   VSPT:  Virtual Shortest Path Tree as defined in [RFC5441].

3.  Need for multiple Data Structure

3.1.  Point to Multipoint (P2MP)

   [PCE-P2MP-PROCEDURES] describes the need for an extended VSPT for
   computation of the best core-tree.  In case of Core tree based path
   computation, the PCE in a downstream domain does the pruning and
   returns the single optimal sub-path to its previous PCE, BRPC insures
   that the ingress PCE will get all the best optimal sub-paths for each
   LN (Leaf Border Nodes), but the combination of these single optimal

Dhody & Palle            Expires August 20, 2012                [Page 5]
Internet-Draft                     DS                      February 2012

   sub-paths into a P2MP tree is not necessarily optimal even if each
   S2L (Source-to-Leaf) sub-path is optimal.  Without trimming, the
   ingress PCE will get all the possible S2L sub-paths set for LN, and
   eventually by looking through all the combinations, and taking one
   sub-path from each set to built one P2MP tree it finds the optimal
   tree.  Note that if the OF is SPT, VSPT is enough for computing core-
   tree and downstream PCE can continue to do the pruning.

3.2.  Synchronized Dependent Path Computations

   [RFC6007] describes the need for disjoint VSPT in case of
   Synchronized Dependent Path Computations.

   The BRPC procedure constructs a VSPT to inform the enquiring PCE of
   potential paths to the destination node.

   In the end-to-end diverse path computation, diversity (or
   disjointness) information among the potential paths must be preserved
   in the VSPT to ensure an end-to-end disjoint path.  In order to
   preserve diversity (or disjointness) information, disjoint VSPTs are
   sent in the PCEP PCRep message.  The PCReq containing a SVEC object
   with the appropriate diverse flag set would signal that the PCE
   should compute a disjoint VSPT.

   A definition of the disjoint VSPT is a collection of VSPTs, in which
   each VSPT contains a potential set of primary and secondary paths.

3.3.  Hierarchical PCE

   In Hierarchical PCE model ([PCE-HIERARCHY-FWK]), Parent PCE MAY be
   used to return the domain-sequence which may be further applied by
   the ingress PCE to do the BRPC path computation; or Parent PCE MAY do
   the full end to end path computation.

   In full end to end path computation model, Parent PCE MAY ask the
   child PCE to do the intra domain path computation between -

   o  Ingress Domain: Ingress to Exit Boundary Nodes

   o  Transit Domain(s): Entry Boundary Nodes to Exit Boundary Nodes

   o  Egress Domain: Entry Boundary Nodes to Egress

   Cannot use VSPT, which clearly defines it self as a P2MP Tree from
   entry boundary nodes to egress.

Dhody & Palle            Expires August 20, 2012                [Page 6]
Internet-Draft                     DS                      February 2012

3.4.  Others

   VSPT does not work well with boundary constraints like HOP-LIMIT in
   inter-domain scenarios.  Since there maybe a not-the-best-path in a
   domain which would have satisfied the end to end contraint, but was
   prunded.

   Since PCEP allow multiple Objective Function (OF); it is natural to
   extend PCEP to support multiple Data Structure based on path
   computation scenarios.

3.5.  PCE in future

   [CSO-PCE] describes the use of PCE in Cross Stratrum Optimization
   (CSO) environment.  A request can be made to the PCE with different
   sets of computation mode that are not currently supported by PCE.
   For instance, NCG may request PCE a multi-destination and multi-
   source path computation request.  This scenario arises when there are
   many possible Data Center choices for a given application request and
   there could be multiple sources for this request.  Multi-destination
   with a single source (aka., anycast) is a default case for multi-
   destination and multi-source path computation.

   In addition, with this architecture, NCG may have different sets of
   objectives and constraints than typical path computation requests.
   For instance, multi-criteria objective functions that combine the
   bandwidth requirement and latency may be very useful for some
   applications.

   Its important to keep PCEP generic to support new requirements in the
   future.

3.6.  Others Techniques

   This is being achieved in some extent by an RP object bit.

   For example, if P2MP bit is set and Objective function (OF) is
   Minimum Cost Tree (MCT), the extended VSPT should be used.  We
   beleive this not a sustainable mechanism.

   Making PCEP generic allowing use of multiple DS will make PCEP
   protocol behave in a better way.

4.  Discovery of PCE Data Structure

   This section defines PCEP extensions (see [RFC5440]) so as to support
   the advertisement of the Data Structure (DS) supported by a PCE.

Dhody & Palle            Expires August 20, 2012                [Page 7]
Internet-Draft                     DS                      February 2012

   A new PCEP DS-List (Data Structure list) TLV is defined.  The PCEP
   DS-List TLV is carried within an OPEN object.  This way, during PCEP
   session-setup phase, a PCE can advertise to a PCEP peer the list of
   data structure it supports.

4.1.  DS-List TLV

   The PCEP DS-List TLV is optional.  It MAY be carried within an OPEN
   object sent by a PCE in an Open message to a PCEP peer so as to
   indicate the list of supported data structures.

   The DS-List TLV format is compliant with the PCEP TLV format defined
   in [RFC5440].  That is, the TLV is composed of 2 octets for the type,
   2 octets specifying the TLV length, and a Value field.  The Length
   field defines the length of the value portion in octets.  The TLV is
   padded to 4-octet alignment, and padding is not included in the
   Length field (e.g., a 3-octet value would have a length of three, but
   the total size of the TLV would be eight octets).

       The PCEP DS-List TLV has the following format:
       TYPE: 4
       LENGTH: N * 2 (where N is the number of Data Structures)
       VALUE: list of 2-byte data structure code points, identifying the
       data structures supported by the sender of the Open message.

        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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             DS Code #1        |      DS Code #2               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //                                                             //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |             DS Code #N        |       padding                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       DS Code (2 bytes): Data Structure code point identifier. IANA
       manages the "PCE Data Structure" code point registry
       (see Section 6).

4.2.  Elements of Procedure

   A PCE MAY include a DS-List TLV within an OPEN object in an Open
   message sent to a PCEP peer in order to advertise a set of one or
   more supported Data Structures.  The DS-List TLV MUST NOT appear more
   than once in an OPEN object.  If it appears more than once, the PCEP
   session MUST be rejected with error type 1 and error value 1 (PCEP
   session establishment failure / Reception of an invalid Open
   message).  The absence of the DS-List TLV in an OPEN object MUST be

Dhody & Palle            Expires August 20, 2012                [Page 8]
Internet-Draft                     DS                      February 2012

   interpreted as an absence of information on the list of supported
   data structures by the PCE, default data stricture VSPT is always
   supported.

   As specified in [RFC5440], a PCEP peer that does not recognize the
   DS-List TLV will silently ignore it.

5.  Data Structure in PCEP Path Computation Request and Reply Messages

   This section defines PCEP extensions [RFC5440] so as to support the
   communication of Data Structure (DS) in PCEP path computation request
   and reply messages.  A new PCEP DS (Data Structure) object is
   defined, to be carried within a PCReq message in order for the PCC/
   PCE to indicate the required/desired data structure.

   The PCEP DS object may also be carried within a PCRep message in
   order for the PCE to indicate the data structure that was used by the
   PCE and used in the reply message.

   A new flag is defined in the RP (Request Parameters) object.  The
   flag is used in a PCReq message to indicate that the PCE MUST include
   a DS object in the PCRep message to indicate the data structure that
   was used during path computation and encoded in the reply message.

   Also, new PCEP error types and values are defined.

5.1.  DS Object

   The PCEP DS (Data Structure) object is optional.  It MAY be carried
   within a PCReq message so as to indicate the desired/required data
   structure to be applied by the PCE during path computation or within
   a PCRep message so as to indicate the data structure that was used by
   the PCE during path computation and in the reply message.

   The DS object format is compliant with the PCEP object format defined
   in [RFC5440].

Dhody & Palle            Expires August 20, 2012                [Page 9]
Internet-Draft                     DS                      February 2012

      The DS Object-Class is <TBA by IANA>.

      The DS Object-Type is 1.

      The format of the DS object body is:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  DS Code                      |     Reserved                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      //              Optional TLV(s)                                //
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      DS Code (2 bytes): The identifier of the Data Structure. IANA
      manages the "PCE Data Structure" code point registry

      Reserved (2 bytes): This field MUST be set to zero on transmission
      and MUST be ignored on receipt.

      Optional TLVs may be defined in the future.

5.1.1.  Elements of Procedure

   To request the use of a specific data structure by the PCE, a PCC/PCE
   includes a DS object in the PCReq message.

   [RFC5440] specifies a bit flag, referred to as the P bit, carried in
   the common PCEP object header.  The P bit is set by a PCC/PCE to
   mandate that a PCE must take the information carried in the object
   into account during the path computation.

   If the P bit is set in the DS object, the data structure is mandatory
   (required data structure) and the PCE MUST use the data structure
   during path computation.  If the P bit is clear in the DS object, the
   data structure is optional (desired data structure) and the PCE
   SHOULD apply the data structure if it is supported but MAY choose to
   apply a different data structure, according to local capabilities and
   policies.

   On receipt of a PCReq message with a DS object, a PCE MUST proceed as
   follows:

   o  If the DS object is unknown/unsupported, the PCE MUST follow
      procedures defined in [RFC5440].  That is, if the P bit is set,
      the PCE sends a PCErr message with error type 3 or 4 (Unknown /

Dhody & Palle            Expires August 20, 2012               [Page 10]
Internet-Draft                     DS                      February 2012

      Not supported object) and error value 1 or 2 (unknown /
      unsupported object class / object type), and the related path
      computation request MUST be discarded.  If the P bit is cleared,
      the PCE is free to ignore the object.

   o  If the data structure is unknown/unsupported and the P bit is set,
      the PCE MUST send a PCErr message with error type 3 or 4 (Unknown
      / Not supported object) and error value 4 (Unrecognized/
      Unsupported parameter), and the related path computation request
      MUST be discarded.

   o  If the data structure is unknown/unsupported and the P bit is
      cleared, the PCE SHOULD apply another (default) data structure.

   o  If the data structure is supported but policy does not permit
      applying it and if the P bit is set, the PCE MUST send a PCErr
      message with the PCEP error type "policy-violation" (type 5) and a
      new error value, "data structure not allowed", which is defined in
      this document.

   o  If the data structure is supported but policy does not allow
      applying it and if the P bit is cleared, the PCE SHOULD apply
      another (default) data structure.

   o  If the data structure is supported and policy allows applying it
      and if the P bit is set, the PCE MUST apply the requested data
      structure.  Otherwise, if the P bit is cleared, the PCE is free to
      apply any other data structure.

   The default data structure is VSPT or may be locally configured.

5.2.  Carrying The DS Object In a PCEP Message

   The DS object MAY be carried within a PCReq message.  If a data
   structure is to be applied to a set of synchronized path computation
   requests, the DS object MUST be carried just after the corresponding
   SVEC (Synchronization VECtor) object and MUST NOT be repeated for
   each elementary request.

   A DS object specifying a data structure that applies to an individual
   path computation request (non-synchronized case) MUST follow the RP
   object for which it applies.

   The format of the PCReq message is updated as follows.

Dhody & Palle            Expires August 20, 2012               [Page 11]
Internet-Draft                     DS                      February 2012

       <PCReq Message> ::= <Common Header>
                           [<svec-list>]
                           <request-list>
      where:
           <svec-list> ::= <SVEC>
                           [<OF>]
                           [<DS>]
                           [<metric-list>]
                           [<svec-list>]

           <request-list> ::= <request> [<request-list>]

           <request> ::= <RP>
                         <END-POINTS>
                         [<LSPA>]
                         [<BANDWIDTH>]
                         [<metric-list>]
                         [<OF>]
                         [<DS>]
                         [<RRO>[<BANDWIDTH>]]
                         [<IRO>]
                         [<LOAD-BALANCING>]

      and where:

           <metric-list> ::= <METRIC>[<metric-list>]

   The DS object MAY be carried within a PCRep message to indicate the
   data structure used by the PCE during path computation and in the
   reply message.

   When the PCE wants to indicate to the PCC/PCE the data structure that
   was used for the synchronized computation of a set of paths, the
   PCRep message MUST include the corresponding SVEC object directly
   followed by the DS object, which MUST NOT be repeated for each
   elementary request.

   A DS object specifying a data structure used for an individual path
   computation (non-synchronized case) MUST follow the RP object for
   which it applies.

   The format of the PCRep message is updated as follows.

Dhody & Palle            Expires August 20, 2012               [Page 12]
Internet-Draft                     DS                      February 2012

      <PCRep Message> ::= <Common Header>
                          [<svec-list>]
                          <response-list>

      where:

            <svec-list> ::= <SVEC>
                            [<OF>]
                            [<DS>]
                            [<metric-list>]
                            [<svec-list>]

           <response-list> ::= <response> [<response-list>]

           <response> ::= <RP>
                          [<NO-PATH>]
                          [<attribute-list>]
                          [<path-list>]

           <path-list> ::= <path> [<path-list>]

           <path> ::= <ERO>
                      <attribute-list>

      and where:

           <attribute-list> ::= [<OF>]
                                [<DS>]
                                [<LSPA>]
                                [<BANDWIDTH>]
                                [<metric-list>]
                                [<IRO>]

           <metric-list> ::= <METRIC> [<metric-list>]

   Note: The DS object MAY be associated to a negative reply, i.e., a
   reply with a NO-PATH object.

5.3.  New RP Object Flag

   In some cases, where no data structure is specified in the request or
   an optional data structure is desired (P flag cleared in the DS
   object common header) but the PCE does not follow the request, the
   PCC/PCE may desire to know the data structure that was used by the
   PCE during path computation.  To that end, a new flag is defined in
   the RP object, named the DS flag, allowing a PCC/PCE to request for
   the inclusion in the path computation reply of the data structure
   that was used by the PCE during path computation.

Dhody & Palle            Expires August 20, 2012               [Page 13]
Internet-Draft                     DS                      February 2012

   The following new bit flag of the RP object is defined: The Supply DS
   on response flag (bit number <TBA>).  When set in a PCReq message,
   this indicates that the PCE MUST provide the applied data structure
   in the PCRep message.  When set in a PCRep message, this indicates
   that the data structure that was used during path computation is
   included.

5.3.1.  Elements of Procedure

   If the PCC/PCE wants to know the data structure used by the PCE
   during path computation for a given request, it sets the DS flag in
   the RP object.

   On receipt of a PCReq message with the DS flag in the RP object set,
   the PCE proceeds as follows:

   o  If policy permits, it MUST include in the PCRep message a DS
      object indicating the data structure it used during path
      computation.

   o  If policy does not permit, it MUST send a PCErr message with the
      PCEP error code "policy-violation" (type 5) and a new error value,
      "data structure indication not allowed", which is defined in this
      document.

   Note that a legacy PCE might not recognize the DS flag in the RP
   object.  According to the definition of the Flags field for the RP
   object (Section 7.4.1 of [RFC5440]), the legacy PCE will ignore the
   unknown flag, resulting in it sending a PCRep that does not contain a
   DS object.  In this case, the PCC/PCE's behavior is an implementation
   choice.  It might:

   o  Discard the PCRep because it really wanted the DS object returned.

   o  Accept the PCRep without the knowledge of the DS that was applied.

   Note also that these procedures can give rise to the situation where
   a PCC/PCE receives a PCRep that contains a DS object with a data
   structure identifier that the PCC/PCE does not recognize.  In this
   situation, the PCC/PCE behavior is dependent on implementation and
   configuration.  The PCC/PCE could choose any of the following (or
   some other action):

   o  Ignore the DS object and use the computed path.

   o  Add the data structure to its view of the PCE's repertoire for
      inclusion in future computation requests.

Dhody & Palle            Expires August 20, 2012               [Page 14]
Internet-Draft                     DS                      February 2012

   o  Discard the PCRep (i.e., the computed path) and send a PCReq to
      another PCE.

   o  Discard the PCRep (i.e., the computed path) and send another PCReq
      to the same PCE explicitly requiring the use of some other data
      structure (i.e., by setting the P bit in the DS object).

6.  IANA Considerations

6.1.  PCE Data Structure Sub-Registry

   This document defines a 16-bit PCE data structure identifier to be
   carried within the PCEP DS object, and also defines the PCEP DS-List
   TLV.  IANA should create and manages the 16-bit "PCE Data Structure"
   code point registry.  Values are TBD.

6.2.  PCEP Code Points

6.2.1.  DS Object

   IANA manages the PCEP Objects code point registry (see [RFC5440]).
   This is maintained as the "PCEP Objects" sub-registry of the "Path
   Computation Element Protocol (PCEP) Numbers" registry.  This document
   defines a new PCEP object, the DS object, to be carried in PCReq and
   PCRep messages.

         IANA should make the following allocation:

         Object    Name     Object    Name                  Reference
         Class              Type
         ------------------------------------------------------------
          TBA      DS        1       Data Structure         This Doc

6.2.2.  DS-List TLV

   IANA manages the PCEP TLV code point registry (see [RFC5440]).  This
   is maintained as the "PCEP TLV Type Indicators" sub-registry of the
   "Path Computation Element Protocol (PCEP) Numbers" registry.  This
   document defines a new PCEP TLV, the DS-List TLV, to be carried in
   the OPEN object.

         IANA should make the following allocation:

         Type      TLV name                   References
         -----------------------------------------------
          TBA      DS-List                     This Doc

Dhody & Palle            Expires August 20, 2012               [Page 15]
Internet-Draft                     DS                      February 2012

6.2.3.  PCEP Error Values

   IANA maintains a registry of Error-types and Error-values for use in
   PCEP messages.  This is maintained as the "PCEP-ERROR Object Error
   Types and Values" sub-registry of the "Path Computation Element
   Protocol (PCEP) Numbers" registry.

      Two new Error-values are defined for the Error-type "policy
      violation" (type 5):

      Error-type      Meaning and error values                 Reference
      ------------------------------------------------------------------
         5            Policy violation

                      Error-value=TBA: data structure not      This Doc
                      allowed (request rejected)

                      Error-value=TBA: DS bit of the RP        This Doc
                      object set (request rejected)

6.2.4.  RP Object Flag

   A new flag of the RP object (specified in [RFC5440]) is defined in
   this document.  IANA maintains a registry of RP object flags in the
   "RP Object Flag Field" sub-registry of the "Path Computation Element
   Protocol (PCEP) Numbers" registry.

         IANA should make the following allocation:

         Bit      Description                Reference
         ----------------------------------------------
         TBA      Supply DS on response      This Doc

7.  Security Considerations

   PCEP security mechanisms are described in [RFC5440] and are used to
   secure entire PCEP messages.  Nothing in this document changes the
   message flows or introduces any new messages, so the security
   mechanisms set out in [RFC5440] continue to be applicable.

   This document introduces a single new object that may optionally be
   carried on PCEP messages and will be automatically secured using the
   mechanisms described in [RFC5440].

   If a PCEP message is vulnerable to attack (for example, because the
   security mechanisms are not used), then the DS object could be used
   as part of an attack; however, it is likely that other objects will
   provide far more significant ways of attacking a PCE or PCC in this

Dhody & Palle            Expires August 20, 2012               [Page 16]
Internet-Draft                     DS                      February 2012

   case.

8.  Manageability Considerations

8.1.  Control of Function and Policy

   It MUST be possible to configure the activation/deactivation of data
   structure discovery in PCEP.  In addition to the parameters already
   listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD
   allow configuring a list of authorized data structure on a PCE.  This
   may apply to any session the PCEP speaker participates in, to a
   specific session with a given PCEP peer, or to a specific group of
   sessions with a specific group of PCEP peers.  Note that it is not
   mandatory for an implementation to support all data structure
   defined.  It MUST be possible to configure a default data structure
   used for path computation when a path request is received that
   requests to use an optional data structure.

8.2.  Information and Data Models

   The PCEP MIB Module defined in [PCEP-MIB] could be extended to
   include data structure.

8.3.  Liveness Detection and Monitoring

   Mechanisms defined in this document do not imply any new liveness
   detection and monitoring requirements in addition to those already
   listed in [RFC5440].

8.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements in addition to those already listed in
   [RFC5440].

8.5.  Requirements On Other Protocols

   Mechanisms defined in this document do not imply any requirements on
   other protocols in addition to those already listed in [RFC5440].

8.6.  Impact On Network Operations

   Mechanisms defined in this document do not have any impact on network
   operations in addition to those already listed in [RFC5440].

Dhody & Palle            Expires August 20, 2012               [Page 17]
Internet-Draft                     DS                      February 2012

9.  Acknowledgments

   We would like to thank Pradeep Shastry, Suresh babu, Quintin Zhao and
   Chen Huaimo for their useful comments and suggestions.

10.  References

10.1.  Normative References

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

10.2.  Informative References

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

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

   [RFC4674]              Le Roux, J., "Requirements for Path
                          Computation Element (PCE) Discovery",
                          RFC 4674, October 2006.

   [RFC5088]              Le Roux, JL., Vasseur, JP., Ikejiri, Y., and
                          R. Zhang, "OSPF Protocol Extensions for Path
                          Computation Element (PCE) Discovery",
                          RFC 5088, January 2008.

   [RFC5089]              Le Roux, JL., Vasseur, JP., Ikejiri, Y., and
                          R. Zhang, "IS-IS Protocol Extensions for Path
                          Computation Element (PCE) Discovery",
                          RFC 5089, January 2008.

   [RFC5440]              Vasseur, JP. and JL. Le Roux, "Path
                          Computation Element (PCE) Communication
                          Protocol (PCEP)", RFC 5440, March 2009.

   [RFC5441]              Vasseur, JP., Zhang, R., Bitar, N., and JL. Le
                          Roux, "A Backward-Recursive PCE-Based
                          Computation (BRPC) Procedure to Compute
                          Shortest Constrained Inter-Domain Traffic
                          Engineering Label Switched Paths", RFC 5441,
                          April 2009.

Dhody & Palle            Expires August 20, 2012               [Page 18]
Internet-Draft                     DS                      February 2012

   [RFC5541]              Le Roux, JL., Vasseur, JP., and Y. Lee,
                          "Encoding of Objective Functions in the Path
                          Computation Element Communication Protocol
                          (PCEP)", RFC 5541, June 2009.

   [RFC6007]              Nishioka, I. and D. King, "Use of the
                          Synchronization VECtor (SVEC) List for
                          Synchronized Dependent Path Computations",
                          RFC 6007, September 2010.

   [PCE-P2MP-PROCEDURES]  Zhao, Q., Dhody, D., Ali, Z., Saad,, T.,
                          Sivabalan,, S., and R. Casellas, "PCE-based
                          Computation Procedure To Compute Shortest
                          Constrained P2MP Inter-domain Traffic
                          Engineering Label Switched Paths (draft-ietf-
                          pce-pcep-inter-domain-p2mp-procedures-02)",
                          February 2012.

   [PCE-HIERARCHY-FWK]    King, D. and A. Farrel, "The Application of
                          the Path Computation Element Architecture to
                          the Determination of a Sequence of Domains in
                          MPLS and GMPLS.
                          (draft-ietf-pce-hierarchy-fwk-00)",
                          October 2011.

   [CSO-PCE]              Dhody, D. and Y. Lee, "Cross Stratum
                          Optimization enabled Path Computation. (draft-
                          dhody-pce-cso-enabled-path-computation-00)",
                          February 2012.

Authors' Addresses

   Dhruv Dhody
   Huawei Technologies India Pvt Ltd
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: dhruv.dhody@huawei.com

Dhody & Palle            Expires August 20, 2012               [Page 19]
Internet-Draft                     DS                      February 2012

   Udayasree Palle
   Huawei Technologies India Pvt Ltd
   Leela Palace
   Bangalore, Karnataka  560008
   INDIA

   EMail: udayasree.palle@huawei.com

Dhody & Palle            Expires August 20, 2012               [Page 20]