Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5541

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

Pages: 23
Proposed Standard

Top   ToC   RFC5541 - Page 1
Network Working Group                                        JL. Le Roux
Request for Comments: 5541                                France Telecom
Category: Standards Track                                    JP. Vasseur
                                                       Cisco System Inc.
                                                                  Y. Lee
                                                                  Huawei
                                                               June 2009


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

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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

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. 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 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 requirements work, and provides the definition of four new metric types that apply to a set of synchronized requests.
Top   ToC   RFC5541 - Page 3

Table of Contents

1. Introduction ....................................................3 1.1. Conventions Used in This Document ..........................5 1.2. Terminology ................................................5 1.3. Message Formats ............................................6 2. Discovery of PCE Objective Functions ............................6 2.1. OF-List TLV ................................................6 2.2. Elements of Procedure ......................................7 3. Objective Function in PCEP Path Computation Request and Reply Messages ........................................................7 3.1. OF Object ..................................................7 3.1.1. Elements of Procedure ...............................8 3.2. Carrying The OF Object In a PCEP Message ...................9 3.3. New RP Object Flag ........................................12 3.3.1. Elements Of Procedure ..............................12 4. Objective Functions Definition .................................13 5. New Metric Types ...............................................14 6. IANA Considerations ............................................15 6.1. PCE Objective Function Sub-Registry .......................15 6.2. PCEP Code Points ..........................................16 6.2.1. OF Object ..........................................16 6.2.2. OF-List TLV ........................................16 6.2.3. PCEP Error Values ..................................16 6.2.4. RP Object Flag .....................................17 6.2.5. Metric Types .......................................17 7. Security Considerations ........................................17 8. Manageability Considerations ...................................18 8.1. Control of Function and Policy ............................18 8.2. Information and Data Models ...............................18 8.3. Liveness Detection and Monitoring .........................18 8.4. Verify Correct Operations .................................18 8.5. Requirements On Other Protocols ...........................19 8.6. Impact On Network Operations ..............................19 9. Acknowledgments ................................................19 10. References ....................................................19 10.1. Normative References .....................................19 10.2. Informative References ...................................19 Appendix A. RBNF Code Fragments ...................................21

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 of applying computational constraints. A PCE services path computation requests that are sent by Path Computation Clients (PCC).
Top   ToC   RFC5541 - Page 4
   The PCE communication Protocol (PCEP), defined in [RFC5440], 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
   of 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 that allow 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 [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.
   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.
Top   ToC   RFC5541 - Page 5
   A new PCEP object, the OF object, is defined in Section 3.  The OF
   object is carried within a PCReq (Path Computation Request) message
   to indicate the required/desired objective function to be applied by
   a PCE, or in a PCRep (Path Computation Reply) 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 the 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. 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.2. 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 for 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 of applying computational constraints. PCEP: Path Computation Element communication Protocol. TE LSP: Traffic Engineered Label Switched Path.
Top   ToC   RFC5541 - Page 6

1.3. Message Formats

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

2. Discovery of PCE Objective Functions

This section defines PCEP extensions (see [RFC5440]) 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. This way, during PCEP session-setup phase, a PCE can advertise to a PCEP peer the list of objective functions it supports.

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 [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 OF-List TLV has the following format: TYPE: 4 LENGTH: N * 2 (where N is the number of objective functions) VALUE: list of 2-byte 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Top   ToC   RFC5541 - Page 7
   OF Code (2 bytes): Objective Function code point identifier.  IANA
   manages 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 in order 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 [RFC5440], 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 [RFC5440] 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 (Request Parameters) 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.
Top   ToC   RFC5541 - Page 8
   The OF object format is compliant with the PCEP object format defined
   in [RFC5440].

   The OF Object-Class is 21.
   The OF Object-Type is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  OF Code                      |     Reserved                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   //              Optional TLV(s)                                //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   OF Code (2 bytes): The identifier of the objective function.  IANA
   manages 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. [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 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.
Top   ToC   RFC5541 - Page 9
   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 [RFC5440].  That is, if the P bit is set, the
     PCE 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, the PCE 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 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, "objective function not allowed", which is defined
     in this document.

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

   - If the objective function is supported and policy allows applying
     it and if the P bit is set, the PCE MUST apply the requested
     objective function.  Otherwise, 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 (Synchronization VECtor) object and MUST NOT be repeated for each elementary request.
Top   ToC   RFC5541 - Page 10
   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.  Please see
   Appendix A for a full set of RBNF fragments defined in this document
   and the necessary code license.

    <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>[<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.
Top   ToC   RFC5541 - Page 11
   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.  Please see
   Appendix A for a full set of RBNF fragments defined in this document
   and the necessary code license.

   <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>]
                       [<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.
Top   ToC   RFC5541 - Page 12

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: The Supply OF on response flag (bit number 24). 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. 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", which is 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 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 an OF object. In this case, the PCC's behavior 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.
Top   ToC   RFC5541 - Page 13
   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 implementation 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 repertoire 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 have been assigned by IANA and are described 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)}. - 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 Name: Minimum Cost Path (MCP) Description: Find a path P such that C(P) is minimized.
Top   ToC   RFC5541 - Page 14
   Objective Function Code: 2
   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
   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
   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
   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
   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: Aggregate bandwidth consumption. Type 5: Load of the most loaded link. Type 6: Cumulative IGP cost. Type 7: Cumulative TE cost.
Top   ToC   RFC5541 - Page 15
   These metrics may be used in a PCReq to indicate a bound (B bit set
   in the METRIC object) or to request the computation of a metric (C
   bit set in the METRIC object), or in a PCRep to indicate a computed
   metric.

   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, and also defines the PCEP OF- List TLV. IANA created and now manages 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 that are 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 assigned as follows: o Function code values 1 through 1023 are assigned by IANA using the "IETF Review" policy. o Function code values 1024 through 32767 are assigned by IANA, using the "First Come First Served" policy. o Function code values in the range 32768-65535 are for "Private Use".
Top   ToC   RFC5541 - Page 16
   Six objective functions are defined in Section 4 of this document and
   have been assigned by IANA:

      Code Point           Name                     Reference
      -------------------------------------------------------
          1                MCP                       RFC 5541
          2                MLP                       RFC 5541
          3                MBP                       RFC 5541
          4                MBC                       RFC 5541
          5                MLL                       RFC 5541
          6                MCC                       RFC 5541

6.2. PCEP Code Points

6.2.1. OF 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 OF object, to be carried in PCReq and PCRep messages. IANA has made the following allocation: Object Name Object Name Reference Class Type ------------------------------------------------------------ 21 OF 1 Objective Function RFC 5541

6.2.2. OF-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 OF-List TLV, to be carried in the OPEN object. IANA has made the following allocation: Type TLV name References ----------------------------------------------- 4 OF-List RFC 5541

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.
Top   ToC   RFC5541 - Page 17
   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     RFC 5541
                      allowed (request rejected)

                      Error-value=4: OF bit of the RP object    RFC 5541
                      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 has made the following allocation: Bit Description Reference ------------------------------------------- 24 Supply OF on response RFC 5541

6.2.5. Metric Types

Four new metric types are defined in this document for the METRIC object (specified in [RFC5440]). 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 has made the following allocations: - 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

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.
Top   ToC   RFC5541 - Page 18
   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 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 [RFC5440], a PCEP implementation SHOULD allow configuring a list of authorized objective functions 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 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 [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].
Top   ToC   RFC5541 - Page 19

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

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., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.

10.2. Informative References

[RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC4674] Le Roux, J., Ed., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
Top   ToC   RFC5541 - Page 20
   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [PCE-GCO]  Lee, Y., Le Roux, JL., King, D., and E. Oki, "Path
              Computation Element Communication Protocol (PCEP)
              Requirements and Protocol Extensions in Support of Global
              Concurrent Optimization", Work in Progress, March 2009.

   [PCEP-MIB] Koushik, K., and E. Stephan, "PCE Communication Protocol
              (PCEP) Management Information Base", Work in Progress,
              January 2009.

   [RFC5511]     Farrel, A., "Routing Backus-Naur Form (RBNF) - A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009.
Top   ToC   RFC5541 - Page 21

Appendix A. RBNF Code Fragments

This appendix contains the full set of code fragments defined in this document. Copyright (c) 2009 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: o Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. o Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. o Neither the name of Internet Society, IETF or IETF Trust, nor the names of specific contributors, may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. <PCReq Message> ::= <Common Header> [<svec-list>] <request-list> <PCRep Message> ::= <Common Header> [<svec-list>] <response-list>
Top   ToC   RFC5541 - Page 22
       <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>]

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

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

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

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

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

       <attribute-list> ::= [<OF>]
                            [<LSPA>]
                            [<BANDWIDTH>]
                            [<metric-list>]
                            [<IRO>]
Top   ToC   RFC5541 - Page 23

Authors' Addresses

JL Le Roux France Telecom 2, Avenue Pierre-Marzin Lannion 22307 France EMail: jeanlouis.leroux@orange-ftgroup.com Jean-Philippe Vasseur Cisco Systems, Inc 11, Rue Camille Desmoulins L'Atlantis 92782 Issy Les Moulineaux France EMail: jpv@cisco.com Young Lee Huawei Technologies, LTD. 1700 Alma Drive, Suite 100 Plano, TX 75075 USA EMail: ylee@huawei.com