[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
Created: December 27, 2008                                 J.P. Vasseur
Expires: June 27, 2009                                Cisco System Inc.

                                                                 Y. Lee
                                                                 Huawei


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

                      draft-ietf-pce-of-06.txt


Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and 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 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 objective functions
   (e.g. minimum cost path, widest path, etc.).

   In the Path Computation Element (PCE) architecture, 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.

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   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.

   This document defines objective function code types for six
   objective functions previously listed in the PCE requirments work,
   and provides the definition of four new metric types that apply to a
   set of synchronized requests.

Table of Contents

   1.      Introduction................................................3
   1.1.    Terminology.................................................4
   1.2.    Message Formats.............................................5
   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......................................10
   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..........................................15
   6.2.4.  RP Object Flag.............................................15
   6.2.5.  Metric Types...............................................15
   7.      Security Considerations....................................16
   8.      Manageability Considerations...............................16
   8.1.    Control of Function and Policy.............................16
   8.2.    Information and Data Models................................16
   8.3.    Liveness Detection and Monitoring..........................16
   8.4.    Verify Correct Operations..................................17
   8.5.    Requirements On Other Protocols............................17
   8.6.    Impact On Network Operations...............................17
   9.      Acknowledgments............................................17
   10.     References.................................................17
   10.1.   Normative Feferences.......................................17
   10.2.   Informative References.....................................17
   11.     Authors' Addresses.........................................18

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

1. Introduction

   The Path Computation Element-based network architecture [RFC4655]
   defines a Path Computation Element (PCE) as an entity capable of
   computing the paths of Traffic Engineered Label Switched Paths (TE
   LSPs) 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
   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

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   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.

   Six mandatory objective functions that must be supported by PCEP are
   listed in [RFC4657]. This document provides 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 the definition of four new metric types
   that apply to a set of synchronized requests.

1.1. Terminology

   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.


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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

1.2. Message Formats

   Message formats in this document are expressed using Reduced BNF as
   used in [PCEP] and defined in [RBNF].

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               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     //                                                             //
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             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).

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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,
   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).



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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

   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.


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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

   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>




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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

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

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

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

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


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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

        <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>]
                             [<LSPA>]
                             [<BANDWIDTH>]
                             [<metric-list>]
                             [<IRO>]

        <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 (bit number 24) (suggested value, to be
   assigned by IANA).  When set in a PCReq message, this indicates that
   the PCE MUST provide the applied 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.

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

   Note that a legacy PCE might not recognize the OF flag in the RP
   object. According to the definition of the RP object Flag Field in
   Section 7.4.1 of [PCEP], the legacy PCE will ignore the unknown flag
   resulting in it sending a PCRep that does not contain an OF object.
   In this case, the PCC's beahvior is an implementation choice. The PCC
   might:
   - Discard the PCRep because it really wanted the OF object returned.
   - Accept the PCRep without the knowledge of the OF that was applied.

   Note also that these procedures can give rise to the situation where
   a PCC receives a PCRep that contains an OF object with an Objective
   Function identifier that the PCC does not recognize. In this
   situation the PCC behavior is dependent on implementaiton and
   configuration. The PCC could choose any of the following (or some
   other action):

   - Ignore the OF object and use the computed path.
   - Add the Objective Function to its view of the PCE's repetoire for
     inclusion in future computation requests.
   - Discard the PCRep (i.e., the computed path) and send a PCReq to
     another PCE.
   - Discard the PCRep (i.e., the computed path) and send another PCReq
     to the same PCE explicitly requiring the use of some other
     Objective Function (i.e., by setting the P bit in the OF object).

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 denoted M(L), this can be the IGP metric the TE
     metric, or any other metric.
   - the cost of a path P is denoted C(P), where
     C(P) = sum {M(Lpi), (i=1...K)}.

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   - residual bandwidth on link L is denoted r(L)
   - maximum reservable bandwidth on link L is denoted 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.

   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.


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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

     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.

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




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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   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

6.2. PCEP Code Points

6.2.1. OF Object

   IANA manages the PCEP Objects code point registry (see [PCEP]). 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 OF object, to be carried
   in PCReq and PCRep messages. IANA is requested to make the following
   allocation (suggested value):

     Object    Name     Object    Name                  Reference
     Class              Type

       21       OF        1       Objective Function    (this document)

6.2.2. OF-List TLV

   IANA manages the PCEP TLV code point registry (see [PCEP]). 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 OF-List TLV, to be carried
   in the OPEN object. IANA is requested to make the following
   allocation (suggested value):

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









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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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=3: objective function not      (this doc)
                   allowed (request rejected)

                   Error-value=4: OF bit of the RP object     (this doc)
                   set (request rejected)

6.2.4. RP Object Flag

   A new flag of the RP object (specified in [PCEP]) 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 is requested to make the following allocation (suggested value):

     Bit      Description              Reference

      24      Supply OF on response    This document

6.2.5. Metric Types

   Four new metric types are defined in this document for the METRIC
   object (specified in [PCEP]). IANA maintains a registry of metric
   types in the "METRIC Object T Field" sub-registry of the "Path
   Computation Element Protocol (PCEP) Numbers" registry.

   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




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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

7. Security Considerations

   PCEP security mechanisms are described in [PCEP] 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 [PCEP] 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
   mechanims described in [PCEP].

   If a PCEP message is vulnerable to attack, for example because the
   security mechanisms are not used, then the OF 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
   case.

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] could be extended to
   include Objective Functions.

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



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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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,
   Robert Sparks, 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.

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




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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

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

   [RFC5226] Narten, T. and Alverstrand, H., "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226, May
             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.

   [PCEP-MIB] Koushik, K., and Stephan, E., "PCE communication protocol
             (PCEP) Management Information Base", draft-kkoushik-pce-
             pcep-mib, work in progress.

   [RBNF]    A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax Used
             in Various Protocol Specifications", draft-farrel-rtg-
             common-bnf, 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

Full Copyright Statement

   Copyright (c) 2008 IETF Trust and the persons identified as the
   document authors. All rights reserved.


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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   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.

   All IETF Documents and the information contained therein 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 THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF Trust 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 any IETF 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.

   Copies of Intellectual Property 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

   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
   any standard or specification contained in an IETF Document. Please
   address the information to the IETF at ietf-ipr@ietf.org.

   The definitive version of an IETF Document is that published by, or
   under the auspices of, the IETF. Versions of IETF Documents that are
   published by third parties, including those that are translated into
   other languages, should not be considered to be definitive versions
   of IETF Documents. The definitive version of these Legal Provisions
   is that published by, or under the auspices of, the IETF. Versions of
   these Legal Provisions that are published by third parties, including
   those that are translated into other languages, should not be
   considered to be definitive versions of these Legal Provisions.

   For the avoidance of doubt, each Contributor to the IETF Standards

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

Internet Draft           draft-ietf-pce-of-06.txt          December 2008

   Process licenses each Contribution that he or she makes as part of
   the IETF Standards Process to the IETF Trust pursuant to the
   provisions of RFC 5378. No language to the contrary, or terms,
   conditions or rights that differ from or are inconsistent with the
   rights and licenses granted under RFC 5378, shall have any effect and
   shall be null and void, whether published or posted by such
   Contributor, or included with or in such Contribution.












































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


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