[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: March 2008                                         J.P. Vasseur
                                                       Cisco System Inc.

                                                                  Y. Lee
                                                                  Huawei





                                                          September 2007


       Encoding of Objective Functions in Path Computation Element (PCE)
               communication and discovery protocols

                   draft-ietf-pce-of-00.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     PCE Objective Functions Encoding      [Page 1]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007



Abstract

   The computation of one or a series of Traffic Engineering Label
   Switched Paths (TE LSP) in MultiProtocol Label Switching (MPLS) and
   Generalized MPLS (GMPLS) networks, is subject to a set of one or more
   specific optimization criteria(s), referred to as an objective
   function (e.g. minimum cost path, widest path, etc.). A Path
   Computation Element (PCE) may support one or multiple objective
   functions, and it is desired for a Path Computation Client (PCC) to
   automatically discover the set of objective functions supported by a
   PCE. Furthermore, it may be useful for a PCC to specify in a path
   computation request the required objective function used by the PCE
   to compute a TE LSP or a set of TE LSPs. Thus the aim of this
   document is to define extensions to the PCE Discovery (PCED) TLV
   carried within the IS-IS Router Capability TLV and the OSPF Router
   Information LSA so as to allow a PCC to discover the set of objective
   functions supported by a PCE. Extensions to the PCE communication
   Protocol (PCEP) are also specified allowing a PCC to indicate in a
   path computation request the required objective function and a PCE to
   indicate in a path computation reply the objective function actually
   applied.

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

   1.      Terminology.................................................3
   2.      Introduction................................................4
   3.      PCE Discovery Extensions....................................5
   3.1.    IS-IS PCED Extensions.......................................5
   3.1.1.  IS-IS OF-List sub-TLV.......................................5
   3.1.2.  Elements of Procedure.......................................6
   3.2.    OSPF PCED Extensions........................................6
   3.2.1.  OSPF OF-List sub-TLV........................................6
   3.2.2.  Elements of procedure.......................................7
   4.      PCEP Extensions.............................................7
   4.1.    OF Object...................................................8
   4.1.1.  Elements of procedure.......................................8
   4.2.    Carrying the OF object in a PCEP message....................9
   4.3.    New RP object flag.........................................11
   4.3.1.  Elements of procedure......................................11
   5.      Objective Functions definition.............................11
   6.      IANA Considerations........................................13
   6.1.    PCE Objective Function registry............................13
   6.2.    PCEP code points...........................................14
   6.2.1.  OF Object..................................................14
   6.2.2.  OF Object TLV Space........................................14

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 2]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   6.2.3.  PCEP Error values..........................................14
   6.2.4.  RP Object flag.............................................15
   6.3.    IS-IS OF-List sub-TLV......................................15
   6.4.    OSPF OF-List sub-TLV.......................................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..................................16
   8.5.    Requirements on other protocols............................17
   8.6.    Impact on network operations...............................17
   9.      Acknowledgments............................................17
   10.     References.................................................17
   10.1.   Normative references.......................................17
   10.2.   Informative references.....................................18
   11.     Author's Addresses:........................................18
   12.     Intellectual Property Statement............................18


 1. Terminology

   Terminology used in this document

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

      LSR: Label Switching Router.

      OF: Objective Function: A set of one or more optimization
      criteria(s) 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.

      PCED: PCE Discovery: Generic term to refer to a PCE Discovery
      Mechanism.

      IS-IS PCED: IS-IS based PCE Discovery.



Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 3]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


      OSPF PCED: OSPF based PCE Discovery.

      PCEP: Path Computation Element communication Protocol.

      TE LSP: Traffic Engineered Label Switched Path.

 2. 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 serves 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 IS-IS based PCE Discovery and OSPF based PCE Discovery mechanisms
   defined respectively in [ISIS-PCED] and [OSPF-PCED], allow a PCC to
   automatically discover a set of PCEs as well as some information
   required for PCE selection, in compliance with requirements set forth
   in [RFC4674].

   The computation of one or a set of TE LSPs is subject to a set of one
   or more optimization criteria(s), 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 path(s). 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
   applies to a set of path computation requests the computation of
   which is synchronized (e.g. minimize the aggregate bandwidth
   consumption of all links, 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. For that purpose
   this document specifies PCE Discovery (PCED) extensions in order to
   allow a PCE advertising a list of supported objective functions.



Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 4]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   As spelled out in [RFC4657], a PCC must be able to indicate in a path
   computation request a required/desired objective function, as well as
   optional function parameters. For that purpose this document extends
   the PCE communication Protocol (PCEP), so as to carry the objective
   function as well as function parameters. It thus complements the PCEP
   specification.

   Extensions to IS-IS and OSPF based PCE Discovery ([ISIS-PCED], [OSPF-
   PCED]) are defined in section 3. A new sub-TLV, the OF-List sub-TLV
   is defined, to be carried within the PCED TLV. It allows advertising
   the list of objective functions supported by a PCE.

   Extensions to PCEP ([PCEP]) are defined in section 4. A new PCEP
   object, the OF object is defined, to be 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 actually applied by the PCE.

   A common PCE Objective Function code point registry is defined for
   both PCEP and PCED protocols, to be managed by IANA.

   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.


 3. PCE Discovery Extensions

 3.1. IS-IS PCED Extensions

 3.1.1. IS-IS OF-List sub-TLV

   The IS-IS Objective Function List (OF-List) sub-TLV is a new sub-TLV
   carried within the IS-IS PCED sub-TLV defined in [ISIS-PCED]. It
   allows advertising the list of objective functions supported by a
   PCE.

   The OF-List sub-TLV is an optional sub-TLV. It MAY be present
   within the PCED sub-TLV. It MUST NOT be present more than once.
   If present more than once, all instances except the first one MUST be
   ignored.

   The format of the IS-IS OF-List sub-TLV is the identical to the TLV
   format used by the Traffic Engineering Extensions to IS-IS [RFC3784].
   That is, the TLV is composed of 1 octet for the type, 1 octet
   specifying the TLV length, and a value field. The Length field
   defines the length of the value portion in octets.


   The IS-IS OF-List sub-TLV has the following format:

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 5]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007



         TYPE: To be assigned by IANA  (suggested value = 6)
         LENGTH: N * 2 (where N is the number of objective functions)
         VALUE: list of 2-bytes objective function code points,
                identifying the supported objective functions.



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

   OF Code (2 bytes): Objective Function Identifier

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

 3.1.2. Elements of Procedure

   The OF-List sub-TLV is advertised within an IS-IS PCED sub-TLV
   defined in [ISIS-PCED]. As such, elements of procedures are inherited
   from those defined in [ISIS-PCED].

   The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV
   within the PCED sub-TLV so as to advertise a set of one or more
   objective functions. When a PCED sub-TLV does not contain any OF-List
   sub-TLV this means that the supported objective functions of that PCE
   are unknown.


 3.2. OSPF PCED Extensions

 3.2.1. OSPF OF-List sub-TLV

   The OSPF Objective Function List (OF-List) sub-TLV is a new sub-TLV
   carried within the OSPF PCED TLV defined in [OSPF-PCED]. It allows
   advertising the objective functions supported by a PCE. It includes a
   list of 2-bytes objective function identifiers.

   The OF-List sub-TLV is an optional TLV. It MAY be present
   within the PCED TLV. It MUST NOT be present more than once.
   If present more than once, all instances except the first one MUST be
   ignored.


Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 6]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   The format of the OSPF OF-List sub-TLV is the identical to the TLV
   format used by the Traffic Engineering Extensions to OSPF
   [RFC3630]. 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; padding is not included in the Length field
   (so a two octet value would have a length of two, but the total size
   of the TLV would be eight octets).

   The OSPF OF-List sub-TLV has the following format:

         TYPE: To be assigned by IANA  (suggested value = 6)
         LENGTH: N * 2 (where N is the number of objective functions)
         VALUE: list of 2-bytes objective function code points,
                identifying the supported objective functions.

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

   OF Code (2 bytes): Objective Function Identifier

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


 3.2.2. Elements of procedure

   The OF-List sub-TLV is advertised within an OSPF PCED TLV defined in
   [OSPF-PCED]. As such, elements of procedures are inherited from those
   defined in [OSPF-PCED].

   The OF-List sub-TLV is OPTIONAL. A PCE MAY include an OF-List sub-TLV
   within the PCED TLV so as to advertise a set of one or more objective
   functions. When a PCED TLV does not contain any OF-List sub-TLV this
   means that the supported objective functions of that PCE are unknown.

 4. PCEP Extensions

   This section defines extensions to PCEP ([PCEP]) so as to support the
   communication of objective functions. 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
   and within a PCRep message in order for the PCE to indicate the
   objective function that has actually been applied by the PCE. A new

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 7]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   flag is defined in the RP object, so as to indicate in a PCRep
   message that the inclusion of the objective function actually applied
   by the PCE is required in the response. Also new PCEP error type and
   value are defined.

 4.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 has been actually applied by the PCE.

   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=18).
   The OF Object-Types 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 IANA section).

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

   Optional TLVs may be defined so as to encode objective function
   parameters. The IANA is requested to create a registry for this TLVs'
   name space.

 4.1.1. Elements of procedure

   To specify an objective function to be applied by a PCE, a PCC MUST
   include an OF object in the PCReq message.

   A bit flag referred to as the P bit is defined in the common header
   of each PCEP object that can be set by a PCC to enforce a PCE to take
   into account the related information during the path computation. If
   the objective function is mandatory (required objective function),

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 8]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   the P bit in the OF object MUST be set, else if it is optional
   (desired objective function) the P bit MUST be cleared.

   On receipt of a PCReq message with an OF object, a PCE has to 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 unknown/unsupported
          object (type 3 and 4) else 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 a new PCEP
          error type "objective function error" and error value
          "unknown/unsupported objective function" (defined in this
          document), 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.


 4.2. Carrying the OF object in a PCEP message

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

   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:

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding     [Page 9]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007



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

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

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

         <request>::= <RP>
                      <END-POINTS>
                      [<OF>]
                      [<LSPA>]
                      [<BANDWIDTH>]
                      [<metric-list>]
                      [<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 that was actually applied by the PCE.

   The format of the PCRep message is updated as follows:

   <PCRep Message> ::= <Common Header>
                       <response-list>

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

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 10]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 4.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 bit cleared
   in the OF object header) but the PCE does not follow the
   recommendation, the PCC may desire to know the objective function
   actually applied by the PCE. For that purpose, a new flag is defined
   in the RP object, the OF flag, allowing a PCC to request for the
   inclusion in the reply of the objective function actually applied by
   the PCE.

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

   Objective Function (OF) flag (1 bit): 0x200 (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 applied
   by the PCE is included.

 4.3.1. Elements of procedure

   If the PCC wants to know the objective function actually applied by a
   PCE for a given request, it MUST set the OF flag in the RP object.

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

        - If policy permits it MUST include in the PCRep message an OF
          object indicating the objective function it actually applied.

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

 5. 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)
        - Speed of link L is noted B(L)


Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 11]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007



   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 {(B(Lpi) - R(Lpi)) /
   B(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 {B(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 { B(Li) - R(Li)) /
   B(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.















Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 12]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 6. IANA Considerations

 6.1. PCE Objective Function registry

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

   The 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 PCEP OF object and the ISIS
   and OSPF OF-List sub-TLVs defined in this document.

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

      - Function code value 0 is reserved.
      - Function code value 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 5 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    PCE Objective Functions Encoding    [Page 13]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 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

        18       OF        1       Objective    (this document)
                                   Function

 6.2.2. OF Object TLV Space

   The new PCEP OF object referenced above includes optional TLVs that
   encode objective function parameters. Each TLV includes a 16-bit type
   identifier.

   The IANA is requested to create a new registry, the "PCEP OF TLV"
   registry, and manage TLV type identifiers as follows:

      - TLV Type value
      - TLV Name
      - Defining RFC

   Type values in the range 1-32767 are to be assigned as follows:
       - Values 1 through 1023 are to be assigned by IANA using the
         "IETF Consensus" policy.
       - Values 1024 through 32767 are to be assigned by IANA, using the
         "First Come First Served" policy.

   Type values in the range 32768-65535 are for "Private Use".

 6.2.3. PCEP Error values

   A new PCEP Error-Type is defined in this document, with two error
   values (Error-Type and Error-value to be assigned by IANA):

    Error-type      Meaning and error values                Reference

        14           Objective Function Error                (this doc)
                     Error-value=1: unknown objective function
                     (request rejected)
                     Error-value=2: unsupported objective function
                     (request rejected)



Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 14]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


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

   Bit      Hex     Name      Reference
   Number

    08      0x200   OF       (this document)

   When set, this indicates that the PCC requests the inclusion, in the
   PCRep message, of the objective function actually used to compute the
   path.

 6.3. IS-IS OF-List sub-TLV

   Once a registry for the IS-IS PCED sub-TLV defined in [ISIS-PCED]
   will have been assigned, IANA will assign a new sub-TLV code-point
   for the OF-List sub-TLV carried in the PCED sub-TLV. Here is the
   suggested value:

      Value      TLV name                   References
      -----     --------                   ----------
       6         OF-List                   (This document)

 6.4. OSPF OF-List sub-TLV

   Once a registry for the OSPF PCED TLV defined in [OSPF-PCED] will
   have been assigned, IANA will assign a new sub-TLV code-point for the
   OF-List sub-TLV carried in the PCED TLV. Here is the suggested value:

      Value      TLV name                   References
      -----     --------                   ----------
       6         OF-List                    (This document)





Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 15]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 7. Security Considerations

Mechanisms discussed in [ISIS-PCED] and [OSPF-PCED] to secure the PCED
TLV can be used to secure the PCED sub-TLV as well.

Mechanisms discussed in [PCEP] to secure a PCEP session can be used to
secure the PCEP OF object 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 the PCED protocol.

   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 an implementation may support the specification of the OF
   to be used in PCEP without supporting the discovery of the set of
   OF via the IGP.

   Also note that it is not mandatory for an implementation to support
   all objective functions defined in section 5.

 8.2. Information and Data Models

   The PCED MIB Module defined in [PCED-MIB] MUST be extended to include
   Objective Functions.

   The PCEP MIB Module defined in [PCEP-MIB] MUST 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], [ISIS-PCED] and [OSPF-PCED].

 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], [ISIS-PCED] and [OSPF-PCED].




Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 16]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 8.5. Requirements on other protocols

   Mechanisms defined in this draft do not imply any requirements on
   other protocols in addition to those already listed in [PCEP], [ISIS-
   PCED] and [OSPF-PCED].

 8.6. Impact on network operations

   Mechanisms defined in this document do not imply any impact on
   network operations in addition to those already listed in [PCEP],
   [ISIS-PCED] and [OSPF-PCED].


 9. Acknowledgments

   The authors would like to thank Jerry Ash for his 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.

   [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
   RFC 2740, December 1999.

   [RFC3630] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
   Extensions to OSPF Version 2", RFC 3630, September 2003.

   [RFC3784] Li, T., Smit, H., "IS-IS extensions for Traffic
   Engineering", RFC 3784, June 2004.

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

   [ISIS-PCED] Le Roux, Vasseur, et al. "IS-IS protocol extensions for
   Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
   proto-isis, work in progress.

   [OSPF-PCED] Le Roux, Vasseur, et al. "OSPF protocol extensions for
   Path Computation Element (PCE) Discovery", draft-ietf-pce-disco-
   proto-ospf, work in progress.






Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 17]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


 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.


 11. Author's 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
   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

Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 18]

Internet Draft         draft-ietf-pce-of-00.txt         September 2007


   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

   Disclaimer of Validity

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

   Copyright Statement

   Copyright (C) The IETF Trust (2007). This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.
































Le Roux, Vasseur, Lee    PCE Objective Functions Encoding    [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/