[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-leroux-pce-of) 00 01 02 03 04 05 06 RFC 5541

Network Working Group                                      J.L. Le Roux
Internet Draft                                           France Telecom
Category: Standard Track
Expires: January 2009                                      J.P. Vasseur
                                       Cisco System Inc.

                                                  Y. Lee
                                                  Huawei





                                              July 2008


      Encoding of Objective Functions in Path Computation Element
    communication Protocol (PCEP)

     draft-ietf-pce-of-03.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.









Le Roux, Vasseur, Lee  Encoding of Objective Functions in PCEP  [Page 1]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008



Abstract

  The computation of one or a set of Traffic Engineering Label Switched
  Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and
  Generalized MPLS (GMPLS) networks, is subject to a set of one or more
  specific optimization criteria, referred to as an objective function
  (e.g. minimum cost path, widest path, etc.).
  A Path Computation Client (PCC) may want a path to be computed for
  one or more TE LSPs according to a specific objective  function. Thus,
  the PCC needs to instruct the PCE to use the correct objective
  function. Furthermore, it is possible that not all PCEs support the
  same set of objective functions, therefore it is useful for the PCC
  to be able to automatically discover the set of objective functions
  supported by each PCE.
  This document defines extensions to the PCE communication Protocol
  (PCEP) to allow a PCE to indicate the set of objective functions it
  supports. Extensions are also defined so that a PCC can indicate in
  a path computation request the required objective function, and so
  that a PCE can report in a path computation reply the objective
  function that was used for path computation.

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.

Table of Contents

  Terminology.........................................................3
  1.      Introduction................................................3
  2.      Discovery of PCE Objective Functions........................5
  2.1.    OF-List TLV.................................................5
  2.2.    Elements of procedure.......................................6
  3.      Objective Function in PCEP Path Computation Request and
            Reply Messages............................................6
  3.1.    OF Object...................................................6
  3.1.1.  Elements of Procedure.......................................7
  3.2.    Carrying The OF Object In a PCEP Message....................8
  3.3.    New RP Object Flag.........................................10
  3.3.1.  Elements Of Procedure......................................11
  4.      Objective Functions Definition.............................11
  5.      New Metric Types...........................................12
  6.      IANA Considerations........................................13
  6.1.    PCE Objective Function Sub-registry........................13
  6.2.    PCEP Code Points...........................................14
  6.2.1.  OF Object..................................................14
  6.2.2.  OF-List TLV................................................14
  6.2.3.  PCEP Error values..........................................14
  6.2.4.  RP Object Flag.............................................14
  6.2.5.  Metric Types...............................................15

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 2]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  7.      Security Considerations....................................15
  8.      Manageability Considerations...............................15
  8.1.    Control of Function and Policy.............................15
  8.2.    Information and Data Models................................15
  8.3.    Liveness Detection and Monitoring..........................16
  8.4.    Verify Correct Operations..................................16
  8.5.    Requirements On Other Protocols............................16
  8.6.    Impact On Network Operations...............................16
  9.      Acknowledgments............................................16
  10.     References.................................................16
  10.1.   Normative Feferences.......................................16
  10.2.   Informative References.....................................16
  11.     Authors' Addresses.........................................17
  12.     Intellectual Property Statement............................17


Terminology

  Terminology used in this document

     LSR: Label Switching Router.

     OF: Objective Function: A set of one or more optimization
     criteria used for the computation of a single path (e.g. path
     cost minimization), or the synchronized computation of a set of
     paths (e.g. aggregate bandwidth consumption minimization, etc.).

     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.

     PCEP: Path Computation Element communication Protocol.

     TE LSP: Traffic Engineered Label Switched Path.

1. Introduction

  The PCE-based network architecture [RFC4655] defines a Path
  Computation Element (PCE) as an entity capable of computing TE LSP
  paths based on a network graph, and applying computational
  constraints.  A PCE services path computation requests sent by Path
  Computation Clients (PCC).

  The PCE communication Protocol (PCEP), defined in [PCEP], allows for
  communication between a PCC and a PCE or between two PCEs, in

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 3]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  compliance with requirements and guidelines set forth in [RFC4657].
  Such interactions include path computation requests and path
  computation replies.

  The computation of one or a set of TE LSPs is subject to a set of one
  or more optimization criteria, called an objective function. An
  objective function is used by the PCE, when it computes a path or a
  set of paths, in order to select the "best" candidate paths. There is
  a variety of objective functions: an objective function could apply
  either to a set of non-synchronized path computation requests, or to
  a set of synchronized path computation requests. In the former case,
  the objective function refers to an individual path computation
  request (e.g. computation of the shortest constrained path where the
  metric is the IGP metric, computation of the least loaded constrained
  path, etc.). Conversely in the latter case, the objective function
  refers to a set of path computation requests the computation of which
  is synchronized (e.g. minimize the aggregate bandwidth consumption of
  all LSPs, minimize the sum of the delays for two diverse paths, or
  the delta between those delays, etc.). Moreover, some objective
  functions relate to the optimization of a single metric and others to
  the optimization of a set of metrics (organized in a hierarchical
  manner, using a weighted function, etc.).

  As spelled out in [RFC4674], it may be useful for a PCC to discover
  the set of objective functions supported by a PCE. Furthermore,
  [RFC4657] requires the ability for a PCC to indicate in a path
  computation request a required/desired objective function, as well as
  optional function parameters.

  For these purposes, this document extends the PCE communication
  Protocol (PCEP). It defines PCEP extensions allowing a PCE to
  advertise a list of supported objective functions, as well as
  extensions to carry the objective function in PCEP request and reply
  messages. It complements the PCEP base specification [PCEP].

  Note that IS-IS and OSPF based PCE Discovery mechanisms are defined
  in ([RFC5089], [RFC5088]). 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.
  Objective functions are in this second category; thus the Objective
  Function discovery procedure is handled by PCEP.

  A new PCEP TLV, named the OF-List TLV is defined in Section 2. The
  OF-List TLV is carried in the PCEP OPEN object and allows a PCE to
  list, during PCEP session setup phase, the objective functions that
  it supports.

  A new PCEP object, the OF object, is defined in Section 3. The OF
  object is carried within a PCReq message to indicate the
  required/desired objective function to be applied by a PCE, or in a
  PCRep message to indicate the objective function that was used for
  path computation.

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 4]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008



  Six mandatory objective functions that must be supported by PCEP are
  listed in [RFC4657]. This document provides, in Section 4, a
  definition of these six mandatory objective functions. Additional
  objective functions may be defined in other documents. Note that
  additional objective functions are defined for PCE Global Concurrent
  Optimization (GCO) application, in [PCE-GCO]. This document also
  provides, in Section 5, the definition of four new metric types that
  apply to a set of synchronized requests.


2. Discovery of PCE Objective Functions

  This section defines PCEP extensions (see [PCEP]) so as to support
  the advertisement of the objective functions supported by a PCE.

  A new PCEP OF-List (Objective Function list) TLV is defined. The PCEP
  OF-List TLV is carried within an OPEN object, in order for a PCE to
  advertise to a PCEP peer the list of objective functions it supports,
  during PCEP session setup phase.

2.1. OF-List TLV

  The PCEP OF-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 objective functions.

  The OF-List TLV format is compliant with the PCEP TLV format defined
  in [PCEP]. 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 four-octet alignment and padding is not included in the Length
  field (e.g. a three octet value would have a length of three, but the
  total size of the TLV would be eight octets).

  The PCEP OF-List TLV has the following format:

        TYPE: To be assigned by IANA  (suggested value = 4 )
        LENGTH: N * 2 (where N is the number of objective functions)
        VALUE: list of 2-bytes objective function code points,
               identifying the objective functions 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             OF Code #1        |      OF Code #2               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 5]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


     |             OF Code #N        |       padding                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  OF Code (2 bytes): Objective Function code point identifier.

  IANA is requested to manage the PCE objective function code point
  registry (see Section 6).


2.2. Elements of procedure

  A PCE MAY include an OF-List TLV within an OPEN object in an Open
  message sent to a PCEP peer, to advertise a set of one or more
  objective functions. The OF-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 OF-List TLV in an OPEN object MUST be interpreted
  as an absence of information on the list of supported objective
  functions by the PCE.

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


3. Objective Function in PCEP Path Computation Request and Reply
   Messages

  This section defines PCEP extensions ([PCEP]) so as to support the
  communication of objective functions in PCEP path computation request
  and reply messages. A new PCEP OF (Objective Function) object is
  defined, to be carried within a PCReq message in order for the PCC to
  indicate the required/desired objective function.

  The PCEP OF Object may also be carried within a PCRep message in
  order for the PCE to indicate the objective function that was used by
  the PCE.

  A new flag is defined in the RP object. The flag is used in a PCReq
  message to indicate that the PCE MUST include an OF object in the
  PCRep message to indicate the objective function that was used during
  path computation.

  Also, new PCEP error types and values are defined.

3.1. OF Object

  The PCEP OF (Objective Function) object is optional. It MAY be
  carried within a PCReq message so as to indicate the desired/required
  objective function to be applied by the PCE during path computation,


Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 6]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  or within a PCRep message so as to indicate the objective function
  that was used by the PCE during path computation.

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

  The OF Object-Class is to be assigned by IANA (recommended value=21).
  The OF Object-Type is to be assigned by IANA (recommended value=1).


  The format of the OF 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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Objective Function Code(IANA)  |     Reserved                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  //              Optional TLV(s)                                //
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


  Objective Function Code (2 bytes): The identifier of the Objective
  Function. The IANA is requested to manage the PCE objective function
  code point registry (see Section 6).

  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 so as to encode objective
  function parameters.

3.1.1. Elements of Procedure

  To request the use of a specific objective function by the PCE, a
  PCC includes an OF object in the PCReq message.

  [PCEP] 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 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 OF object, the objective function is
  mandatory (required objective function) and the PCE MUST use the
  objective function during path computation. If the P bit is clear
  in the OF object, the objective function is optional (desired
  objective function) and the PCE SHOULD apply the function if it is
  supported, but MAY choose to apply a different objective function
  according to local capabilities and policies.



Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 7]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


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

       - If the OF object is unknown/unsupported, the PCE MUST follow
         procedures defined in [PCEP], that is if the P bit is set, it
         sends a PCErr message with error type 3 or 4
         (Unknown / 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 it is free to ignore the object.

       - If the objective function 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.

       - If the objective function is unknown / unsupported and the P
         bit is cleared, the PCE SHOULD apply another (default)
         objective function.

       - If the objective function is supported but policy does not
         permit applying it, and 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 "objective function not
         allowed" (defined in this document).

       - If the objective function is supported but policy does not
          allow applying it, and the P bit is cleared, the PCE SHOULD
          apply another (default) objective function.

       - If the objective function is supported and policy allows
         applying it, then if the P bit is set the PCE MUST apply the
         requested objective function, else if the P bit is cleared the
         PCE is free to apply any other objective function.

       The default objective function may be locally configured.


3.2. Carrying The OF Object In a PCEP Message

  The OF object MAY be carried within a PCReq message. If an objective
  function is to be applied to a set of synchronized path computation
  requests, the OF object MUST be carried just after the corresponding
  SVEC object, and MUST NOT be repeated for each elementary request.

  Similarly if a metric is to be applied to a set of synchronized
  requests, the METRIC object MUST follow the SVEC object and MUST not
  be repeated for each elementary request. Note that metrics applied to
  a set of synchronized requests are defined in section 5.



Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 8]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  An OF object specifying an objective function 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:

    <PCReq Message>::= <Common Header>
         [<SVEC-list>]
         <request-list>

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

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

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

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


  The OF object MAY be carried within a PCRep message to indicate the
  objective function used by the PCE during path computation.

  When the PCE wants to indicate to the PCC the objective function 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 OF object, which MUST NOT be repeated for each
  elementary request. If a metric is applicable to the set of paths,
  the METRIC object MUST directly follow the SVEC object and MUST NOT
  be repeated for each elementary request.
  An OF object specifying an objective function used for an individual
  path computation (non synchronized case) MUST follow the RP object
  for which it applies.







Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 9]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  The format of the PCRep message is updated as follows:

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

       <response-list>

     where:

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

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

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

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

        <path>::= <ERO>
        [<OF>]
        [<LSPA>]
        [<BANDWIDTH>]
        [<metric-list>]
        [<IRO>]

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


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

3.3. New RP Object Flag

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

  The following new bit flag of the RP object is defined:

  Objective Function (OF) flag (1 bit): 0x200 (bit number 16)
  (suggested value, to be assigned by IANA).  When set in a PCReq
  message, this indicates that the PCE MUST provide the applied

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 10]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  objective function (should a path satisfying the constraints be found)
  in the PCRep message. When set in a PCRep message this indicates that
  the Objective Function that was used during path computation is
  included.


3.3.1. Elements Of Procedure

  If the PCC wants to know the objective function used by the PCE
  during path computation for a given request, it sets the OF flag in
  the RP object.

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

       - If policy permits it MUST include in the PCRep message an OF
         object indicating the objective function it used during path
         computation.

       - 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 "objective function indication not allowed"
         (defined in this document).

4. Objective Functions Definition

  Six objective functions that must be supported by PCEP are listed in
  [RFC4657]. Objective function codes should be assigned by IANA and
  are suggested below.

  Objective functions are formulated using the following terminology:
       - a network comprises a set of N links {Li, (i=1...N)}
       - a path P is a list of K links {Lpi,(i=1...K)}
       - metric of link L is noted M(L), this can be the IGP metric the
         TE metric, or any other metric.
       - the cost of a path P is noted C(P),
         C(P) = sum {M(Lpi), (i=1...K)}.
       - residual bandwidth on link L is noted r(L)
       - maximum reservable bandwidth on link L is noted R(L).

  There are three objective functions that apply to the computation of
  a single path:

  Objective Function Code: 1 (suggested value, to be assigned by IANA)
  Name: Minimum Cost Path (MCP)
  Description: Find a path P such that C(P) is minimized.

  Objective Function Code: 2 (suggested value, to be assigned by IANA)
  Name: Minimum Load Path (MLP)
  Description: Find a path P such that ( Max {(R(Lpi) - r(Lpi)) /
  R(Lpi), i=1...K } ) is minimized


Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 11]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  Objective Function Code: 3 (suggested value, to be assigned by IANA)
  Name: Maximum residual Bandwidth Path (MBP)
  Description: Find a path P such that ( Min { r(Lpi)), i=1...K } )  is
  maximized.

  There are three objective functions that apply to a set of path
  computation requests the computation of which is synchronized:

  Objective Function Code: 4 (suggested value, to be assigned by IANA)
  Name: Minimize aggregate Bandwidth Consumption (MBC)
  Description: Find a set of paths such that ( Sum {R(Li) - r(Li),
  i=1...N} ) is minimized.

  Objective Function Code: 5 (suggested value, to be assigned by IANA)
  Name: Minimize the Load of the most loaded Link (MLL)
  Description: Find a set of paths such that ( Max { (R(Li) - r(Li)) /
  R(Li), i=1...N}) is minimized.

  Objective Function Code: 6 (suggested value, to be assigned by IANA)
  Name: Minimize the Cumulative Cost of a set of paths (MCC)
  Description: Find a set of paths {P1...Pm} such that (Sum { C(Pi),
  i=1...m}) is minimized.

  Other objective functions may be defined in separate documents.


5. New Metric Types

  Three metric types are defined in PCEP for the METRIC object: TE
  metric, IGP metric and hop count. These metric types apply to an
  individual request. Here we define four new metric types that apply
  to a set of synchronized requests:

  Type 4 (suggested value to be assigned by IANA) : Aggregate bandwidth
  consumption
  Type 5 (suggested value to be assigned by IANA) : Load of the most
  loaded link
  Type 6 (suggested value to be assigned by IANA) :  Cumulative IGP
  cost
  Type 7 (suggested value to be assigned by IANA) :  Cumulative TE cost

  These metrics may be used to indicate a bound (B bit set in the
  METRIC object) or a computed metric (C bit set in the METRIC object).

  A METRIC object with one of these four types follows the SVEC object
  for which it applies.







Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 12]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


6. IANA Considerations

6.1. PCE Objective Function Sub-registry

  This document defines a 16-bit PCE Objective Function identifier to
  be carried within the PCEP OF object, as well as the PCEP OF-List TLV.

  IANA is requested to create and manage the 16-bit "PCE Objective
  Function" code point registry, starting from 1 and continuing through
  32767, as follows:

  - Objective Function code point value
  - Objective Function name
  - Defining RFC

  The same registry is applicable to the OF object and the OF-List TLV
  defined in this document.

  The guidelines (using terms defined in [RFC5226]) for the
  assignment of objective function code point values are as follows:

     - Function code value 0 is reserved.
     - Function code values in the range 1-32767 are to be assigned as
       follows:
           - Function code values 1 through 1023 are to be assigned by
             IANA using the "IETF Consensus" policy.
           - Function code values 1024 through 32767 are to be
             assigned by IANA, using the "First Come First Served"
             policy.
      - Function code values in the range 32768-65535 are for
        "Private Use".

  Six objective functions are defined in Section 4 of this document and
  should be assigned by IANA:

  Code Point           Name                    Defining RFC

      1                MCP                       this doc
      2                MLP                       this doc
      3                MBP                       this doc
      4                MBC                       this doc
      5                MLL                       this doc
      6                MCC                       this doc









Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 13]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


6.2. PCEP Code Points

6.2.1. OF Object

    The IANA has been requested to manage the PCEP Objects code point
    registry (see [PCEP]).

    This document defines a new PCEP object, the OF object, to be
    carried in PCReq and PCRep messages. The IANA is requested to make
    the following allocation (suggested value):

     Object    Name     Object    Name         Reference
     Class              Type

       21       OF        1       Objective    (this document)
                   Function

6.2.2. OF-List TLV

  IANA is requested to manage the PCEP TLV code point registry (see
  [PCEP]).
  This document defines a new PCEP TLV, the OF-List TLV, to be carried
  in the OPEN object. The IANA is requested to make the following
  allocation (suggested value):

     Type      TLV name                   References
     -----     --------                   ----------
      4         OF-List                   (This document)


6.2.3. PCEP Error values


  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=3: objective function not allowed (this doc)
  (request rejected)
   Error-value=4: OF bit of the RP object set    (this doc)
  (request rejected)


6.2.4. RP Object Flag

  A new flag of the RP object (specified in [PCEP]) is defined in this
  document. The IANA is requested to make the following allocation
  (suggested value):



Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 14]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008



  Bit      Hex     Name      Reference
  Number

   16      0x200   OF       (this document)

6.2.5. Metric Types

  Four new metric types are defined in this document for the METRIC
  object (specified in [PCEP]). The IANA is requested to make the
  following allocation (suggested values):

       -Type 4 : Aggregate bandwidth consumption
       -Type 5 : Load of the most loaded link
       -Type 6 : Cumulative IGP cost
       -Type 7 : Cumulative TE cost


7. Security Considerations

  Mechanisms discussed in [PCEP] to secure a PCEP session can be used to
  secure the PCEP OF object and OF list TLV as well.

8. Manageability Considerations

8.1. Control of Function and Policy

  It MUST be possible to configure the activation/deactivation of
  Objective Function Discovery in PCEP.

  In addition to the parameters already listed in section 8.1 of [PCEP],
  a PCEP implementation SHOULD allow configuring on a PCE a list of
  authorized objective functions. 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
  objective functions defined in Section 4.

  It MUST be possible to configure a default objective function used
  for path computation when a path request is received that requests to
  use an optional objective function.

8.2. Information and Data Models

  The PCEP MIB Module defined in [PCEP-MIB] SHOULD be extended to
  include Objective Functions.




Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 15]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008



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

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

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

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


9. Acknowledgments

  The authors would like to thank Jerry Ash, Fabien Verhaeghe and
  Adrian Farrel for their useful comments.

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.

  [RFC4655] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation
  Element (PCE)-based Architecture", RFC4655, august 2006.

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


10.2. Informative References

  [RFC4657] Ash, J., Le Roux, J.L., " PCE Communication Protocol
  Generic Requirements", RFC4657, September 2006.

  [RFC4674] Le Roux, J.L., et al. "Requirements for PCE discovery",
  RFC4674, October 2006.


Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 16]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  [RFC5089] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
  Path Computation Element (PCE) Discovery", RFC5088, January 2008.

  [RFC5088] Le Roux, Vasseur, et al. "OSPF protocol extensions for
  Path Computation Element (PCE) Discovery", RFC5088, January 2008.

  [PCE-GCO] Y. Lee, J.L. Le Roux, D. King, and E. Oki, "Path
  Computation Element Communication Protocol (PCECP) Requirements and
  Protocol Extensions In Support of Global Concurrent Optimization",
  draft-ietf-pce-global-concurrent-optimization, work in
  progress.



11. Authors' Addresses

  Jean-Louis Le Roux
  France Telecom
  2, avenue Pierre-Marzin
  22307 Lannion Cedex
  FRANCE
  Email: jeanlouis.leroux@orange-ftgroup.com

  Jean-Philippe Vasseur
  Cisco Systems, Inc.
  1414 Massachusetts avenue
  Boxborough , MA - 01719
  USA
  Email: jpv@cisco.com

  Young Lee
  Huawei Technologies, LTD.
  1700 Alma Drive, Suite 100
  Plano, TX  75075
  USA
  Email: ylee@huawei.com


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

Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 17]

Internet Draft         draft-ietf-pce-of-03.txt              July 2008


  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.

  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 (2008). 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.


























Le Roux, Vasseur, Lee Encoding of Objective Functions in PCEP  [Page 18]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/