Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8233

Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)

Pages: 31
Proposed Standard
Errata
Part 1 of 2 – Pages 1 to 16
None   None   Next

Top   ToC   RFC8233 - Page 1
Internet Engineering Task Force (IETF)                          D. Dhody
Request for Comments: 8233                                         Q. Wu
Category: Standards Track                                         Huawei
ISSN: 2070-1721                                                V. Manral
                                                             Nano Sec Co
                                                                  Z. Ali
                                                           Cisco Systems
                                                               K. Kumaki
                                                        KDDI Corporation
                                                          September 2017


Extensions to the Path Computation Element Communication Protocol (PCEP)
          to Compute Service-Aware Label Switched Paths (LSPs)

Abstract

In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8233.
Top   ToC   RFC8233 - Page 2
Copyright Notice

   Copyright (c) 2017 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
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

1. Introduction ....................................................3 1.1. Requirements Language ......................................4 2. Terminology .....................................................4 3. PCEP Extensions .................................................5 3.1. Extensions to METRIC Object ................................5 3.1.1. Path Delay Metric ...................................6 3.1.1.1. Path Delay Metric Value ....................7 3.1.2. Path Delay Variation Metric .........................7 3.1.2.1. Path Delay Variation Metric Value ..........8 3.1.3. Path Loss Metric ....................................8 3.1.3.1. Path Loss Metric Value .....................9 3.1.4. Non-Understanding / Non-Support of Service-Aware Path Computation ......................9 3.1.5. Mode of Operation ..................................10 3.1.5.1. Examples ..................................11 3.1.6. Point-to-Multipoint (P2MP) .........................11 3.1.6.1. P2MP Path Delay Metric ....................11 3.1.6.2. P2MP Path Delay Variation Metric ..........12 3.1.6.3. P2MP Path Loss Metric .....................12 3.2. Bandwidth Utilization .....................................12 3.2.1. Link Bandwidth Utilization (LBU) ...................12 3.2.2. Link Reserved Bandwidth Utilization (LRBU) .........13 3.2.3. Bandwidth Utilization (BU) Object ..................13 3.2.3.1. Elements of Procedure .....................14 3.3. Objective Functions .......................................15 4. Stateful PCE and PCE Initiated LSPs ............................16 5. PCEP Message Extension .........................................17 5.1. The PCReq Message .........................................17 5.2. The PCRep Message .........................................18 5.3. The PCRpt Message .........................................19 6. Other Considerations ...........................................20
Top   ToC   RFC8233 - Page 3
      6.1. Inter-domain Path Computation .............................20
           6.1.1. Inter-AS Links .....................................20
           6.1.2. Inter-Layer Path Computation .......................20
      6.2. Reoptimizing Paths ........................................21
   7. IANA Considerations ............................................21
      7.1. METRIC Types ..............................................21
      7.2. New PCEP Object ...........................................22
      7.3. BU Object .................................................22
      7.4. OF Codes ..................................................22
      7.5. New Error-Values ..........................................23
   8. Security Considerations ........................................23
   9. Manageability Considerations ...................................24
      9.1. Control of Function and Policy ............................24
      9.2. Information and Data Models ...............................24
      9.3. Liveness Detection and Monitoring .........................24
      9.4. Verify Correct Operations .................................24
      9.5. Requirements on Other Protocols ...........................24
      9.6. Impact on Network Operations ..............................24
   10. References ....................................................25
      10.1. Normative References .....................................25
      10.2. Informative References ...................................26
   Appendix A. PCEP Requirements .....................................28
   Acknowledgments ...................................................29
   Contributors ......................................................30
   Authors' Addresses ................................................31

1. Introduction

Real-time network performance information is becoming critical in the path computation in some networks. Mechanisms to measure latency, delay variation, and packet loss in an MPLS network are described in [RFC6374]. It is important that latency, delay variation, and packet loss are considered during the path selection process, even before the Label Switched Path (LSP) is set up. Link bandwidth utilization based on real-time traffic along the path is also becoming critical during path computation in some networks. Thus, it is important that the link bandwidth utilization is factored in during the path computation. The Traffic Engineering Database (TED) is populated with network performance information like link latency, delay variation, packet loss, as well as parameters related to bandwidth (residual bandwidth, available bandwidth, and utilized bandwidth) via TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810] or via a management system. [RFC7823] describes how a Path Computation Element (PCE) [RFC4655] can use that information for path selection for explicitly routed LSPs.
Top   ToC   RFC8233 - Page 4
   A Path Computation Client (PCC) can request a PCE to provide a path
   meeting end-to-end network performance criteria.  This document
   extends the Path Computation Element Communication Protocol (PCEP)
   [RFC5440] to handle network performance constraints that include any
   combination of latency, delay variation, packet loss, and bandwidth
   utilization constraints.

   [RFC7471] and [RFC7810] describe various considerations regarding:

   o  Announcement thresholds and filters

   o  Announcement suppression

   o  Announcement periodicity and network stability

   The first two provide configurable mechanisms to bound the number of
   re-advertisements in IGP.  The third provides a way to throttle
   announcements.  Section 1.2 of [RFC7823] also describes the
   oscillation and stability considerations while advertising and
   considering service-aware information.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. Terminology

The following terminology is 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). IS-IS: Intermediate System to Intermediate System LBU: Link Bandwidth Utilization (see Section 3.2.1) LRBU: Link Reserved Bandwidth Utilization (see Section 3.2.2) MPLP: Minimum Packet Loss Path (see Section 3.3) MRUP: Maximum Reserved Under-Utilized Path (see Section 3.3) MUP: Maximum Under-Utilized Path (see Section 3.3)
Top   ToC   RFC8233 - Page 5
   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.).  (See [RFC5541].)

   OSPF:     Open Shortest Path First

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

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

   RSVP:     Resource Reservation Protocol

   TE:       Traffic Engineering

   TED:      Traffic Engineering Database

3. PCEP Extensions

This section defines PCEP extensions (see [RFC5440]) for requirements outlined in Appendix A. The proposed solution is used to support network performance and service-aware path computation.

3.1. Extensions to METRIC Object

The METRIC object is defined in Section 7.8 of [RFC5440], comprising metric-value and metric-type (T field), and a flags field, comprising a number of bit flags (B bit and P bit). This document defines the following types for the METRIC object. o T=12: Path Delay metric (Section 3.1.1) o T=13: Path Delay Variation metric (Section 3.1.2) o T=14: Path Loss metric (Section 3.1.3) o T=15: P2MP Path Delay metric (Section 3.1.6.1) o T=16: P2MP Path Delay Variation metric (Section 3.1.6.2) o T=17: P2MP Path Loss metric (Section 3.1.6.3)
Top   ToC   RFC8233 - Page 6
   The following terminology is used and expanded along the way.

   o  A network comprises of a set of N links {Li, (i=1...N)}.

   o  A path P of a point-to-point (P2P) LSP is a list of K links
      {Lpi,(i=1...K)}.

3.1.1. Path Delay Metric

The Link Delay metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Link Delay". The Path Delay metric type of the METRIC object in PCEP represents the sum of the Link Delay metric of all links along a P2P path. Specifically, extending on the above- mentioned terminology: o A Link Delay metric of link L is denoted D(L). o A Path Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}. This is as per the sum of means composition function (Section 4.2.5 of [RFC6049]). Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail. Metric Type T=12: Path Delay metric A PCC MAY use the Path Delay metric in a Path Computation Request (PCReq) message to request a path meeting the end-to-end latency requirement. In this case, the B bit MUST be set to suggest a bound (a maximum) for the Path Delay metric that must not be exceeded for
Top   ToC   RFC8233 - Page 7
   the PCC to consider the computed path as acceptable.  The Path Delay
   metric must be less than or equal to the value specified in the
   metric-value field.

   A PCC can also use this metric to ask PCE to optimize the path delay
   during path computation.  In this case, the B bit MUST be cleared.

   A PCE MAY use the Path Delay metric in a Path Computation Reply
   (PCRep) message along with a NO-PATH object in the case where the PCE
   cannot compute a path meeting this constraint.  A PCE can also use
   this metric to send the computed Path Delay metric to the PCC.

3.1.1.1. Path Delay Metric Value
[RFC7471] and [RFC7810] define "Unidirectional Link Delay Sub-TLV" to advertise the link delay in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.

3.1.2. Path Delay Variation Metric

The Link Delay Variation metric is defined in [RFC7471] and [RFC7810] as "Unidirectional Delay Variation". The Path Delay Variation metric type of the METRIC object in PCEP encodes the sum of the Link Delay Variation metric of all links along the path. Specifically, extending on the above-mentioned terminology: o A delay variation of link L is denoted DV(L) (average delay variation for link L). o A Path Delay Variation metric for the P2P path P = Sum {DV(Lpi), (i=1...K)}. Section 1.2 of [RFC7823] describes oscillation and stability considerations, and Section 2.1 of [RFC7823] describes the calculation of the end-to-end Path Delay Variation metric. Further, Section 4.2.9 of [RFC6049] states when this composition function may fail. Note that the IGP advertisement for link attributes includes the average delay variation over a period of time. An implementation, therefore, MAY use the sum of the average delay variation of links along a path to derive the delay variation of the path. An end-to-end bound on delay variation is typically used as constraint
Top   ToC   RFC8233 - Page 8
   in the path computation.  An implementation MAY also use some
   enhanced composition function for computing the delay variation of a
   path with better accuracy.

   Metric Type T=13: Path Delay Variation metric

   A PCC MAY use the Path Delay Variation metric in a PCReq message to
   request a path meeting the path delay variation requirement.  In this
   case, the B bit MUST be set to suggest a bound (a maximum) for the
   Path Delay Variation metric that must not be exceeded for the PCC to
   consider the computed path as acceptable.  The path delay variation
   must be less than or equal to the value specified in the metric-value
   field.

   A PCC can also use this metric to ask the PCE to optimize the path
   delay variation during path computation.  In this case, the B flag
   MUST be cleared.

   A PCE MAY use the Path Delay Variation metric in a PCRep message
   along with a NO-PATH object in the case where the PCE cannot compute
   a path meeting this constraint.  A PCE can also use this metric to
   send the computed end-to-end Path Delay Variation metric to the PCC.

3.1.2.1. Path Delay Variation Metric Value
[RFC7471] and [RFC7810] define "Unidirectional Delay Variation Sub-TLV" to advertise the link delay variation in microseconds in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Delay Variation metric value is quantified in units of microseconds and encoded in IEEE floating point format. The conversion from 24-bit integer to 32-bit IEEE floating point could introduce some loss of precision.

3.1.3. Path Loss Metric

[RFC7471] and [RFC7810] define "Unidirectional Link Loss". The Path Loss (as a packet percentage) metric type of the METRIC object in PCEP encodes a function of the unidirectional loss metrics of all links along a P2P path. The end-to-end packet loss for the path is represented by this metric. Specifically, extending on the above mentioned terminology: o The percentage link loss of link L is denoted PL(L). o The fractional link loss of link L is denoted FL(L) = PL(L)/100.
Top   ToC   RFC8233 - Page 9
   o  The percentage Path Loss metric for the P2P path P = (1 -
      ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100 for a path P
      with links Lp1 to LpK.

   This is as per the composition function described in Section 5.1.5 of
   [RFC6049].

   Metric Type T=14: Path Loss metric

   A PCC MAY use the Path Loss metric in a PCReq message to request a
   path meeting the end-to-end packet loss requirement.  In this case,
   the B bit MUST be set to suggest a bound (a maximum) for the Path
   Loss metric that must not be exceeded for the PCC to consider the
   computed path as acceptable.  The Path Loss metric must be less than
   or equal to the value specified in the metric-value field.

   A PCC can also use this metric to ask the PCE to optimize the path
   loss during path computation.  In this case, the B flag MUST be
   cleared.

   A PCE MAY use the Path Loss metric in a PCRep message along with a
   NO-PATH object in the case where the PCE cannot compute a path
   meeting this constraint.  A PCE can also use this metric to send the
   computed end-to-end Path Loss metric to the PCC.

3.1.3.1. Path Loss Metric Value
[RFC7471] and [RFC7810] define "Unidirectional Link Loss Sub-TLV" to advertise the link loss in percentage in a 24-bit field. [RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754]). Consequently, the encoding for the Path Loss metric value is quantified as a percentage and encoded in IEEE floating point format.

3.1.4. Non-Understanding / Non-Support of Service-Aware Path Computation

If a PCE receives a PCReq message containing a METRIC object with a type defined in this document, and the PCE does not understand or support that metric type, and the P bit is clear in the METRIC object header, then the PCE SHOULD simply ignore the METRIC object as per the processing specified in [RFC5440]. If the PCE does not understand the new METRIC type, and the P bit is set in the METRIC object header, then the PCE MUST send a PCEP Error (PCErr) message containing a PCEP-ERROR Object with Error-Type = 4 (Not supported object) and Error-value = 4 (Unsupported parameter) [RFC5440][RFC5441].
Top   ToC   RFC8233 - Page 10
   If the PCE understands but does not support the new METRIC type, and
   the P bit is set in the METRIC object header, then the PCE MUST send
   a PCErr message containing a PCEP-ERROR Object with Error-Type = 4
   (Not supported object) with Error-value = 5 (Unsupported network
   performance constraint).  The path computation request MUST then be
   canceled.

   If the PCE understands the new METRIC type, but the local policy has
   been configured on the PCE to not allow network performance
   constraint, and the P bit is set in the METRIC object header, then
   the PCE MUST send a PCErr message containing a PCEP-ERROR Object with
   Error-Type = 5 (Policy violation) with Error-value = 8 (Not allowed
   network performance constraint).  The path computation request MUST
   then be canceled.

3.1.5. Mode of Operation

As explained in [RFC5440], the METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects: o To indicate the metric that MUST be optimized by the path computation algorithm (path delay, path delay variation, or path loss). o To indicate a bound on the METRIC (path delay, path delay variation, or path loss) that MUST NOT be exceeded for the path to be considered as acceptable by the PCC. In a PCRep message, the PCE MAY insert the METRIC object with an Explicit Route Object (ERO) so as to provide the METRIC (path delay, path delay variation, or path loss) for the computed path. The PCE MAY also insert the METRIC object with a NO-PATH object to indicate that the metric constraint could not be satisfied. The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this document. All the rules of processing the METRIC object as explained in [RFC5440] are applicable to the new metric types as well.
Top   ToC   RFC8233 - Page 11
3.1.5.1. Examples
If a PCC sends a path computation request to a PCE where the metric to optimize is the path delay and the path loss must not exceed the value of M, then two METRIC objects are inserted in the PCReq message: o First METRIC object with B=0, T=12, C=1, metric-value=0x0000 o Second METRIC object with B=1, T=14, metric-value=M As per [RFC5440], if a path satisfying the set of constraints can be found by the PCE and there is no policy that prevents the return of the computed metric, then the PCE inserts one METRIC object with B=0, T=12, metric-value= computed path delay. Additionally, the PCE MAY insert a second METRIC object with B=1, T=14, metric-value=computed path loss.

3.1.6. Point-to-Multipoint (P2MP)

This section defines the following types for the METRIC object to be used for the P2MP TE LSPs.
3.1.6.1. P2MP Path Delay Metric
The P2MP Path Delay metric type of the METRIC object in PCEP encodes the Path Delay metric for the destination that observes the worst delay metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology: o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}. o The P2P Path Delay metric of the path to destination Dest_j is denoted by PDM(Dest_j). o The P2MP Path Delay metric for the P2MP tree T = Maximum {PDM(Dest_j), (j=1...M)}. The value for the P2MP Path Delay metric type (T) = 15.
Top   ToC   RFC8233 - Page 12
3.1.6.2. P2MP Path Delay Variation Metric
The P2MP Path Delay Variation metric type of the METRIC object in PCEP encodes the Path Delay Variation metric for the destination that observes the worst delay variation metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology: o A P2MP tree T comprises a set of M destinations {Dest_j, (j=1...M)}. o The P2P Path Delay Variation metric of the path to the destination Dest_j is denoted by PDVM(Dest_j). o The P2MP Path Delay Variation metric for the P2MP tree T = Maximum {PDVM(Dest_j), (j=1...M)}. The value for the P2MP Path Delay Variation metric type (T) = 16.
3.1.6.3. P2MP Path Loss Metric
The P2MP Path Loss metric type of the METRIC object in PCEP encodes the path packet loss metric for the destination that observes the worst packet loss metric among all destinations of the P2MP tree. Specifically, extending on the above-mentioned terminology: o A P2MP tree T comprises of a set of M destinations {Dest_j, (j=1...M)}. o The P2P Path Loss metric of the path to destination Dest_j is denoted by PLM(Dest_j). o The P2MP Path Loss metric for the P2MP tree T = Maximum {PLM(Dest_j), (j=1...M)}. The value for the P2MP Path Loss metric type (T) = 17.

3.2. Bandwidth Utilization

3.2.1. Link Bandwidth Utilization (LBU)

The LBU on a link, forwarding adjacency, or bundled link is populated in the TED ("Unidirectional Utilized Bandwidth Sub-TLV" in [RFC7471] and [RFC7810]). For a link or forwarding adjacency, the bandwidth utilization represents the actual utilization of the link (i.e., as measured in the router). For a bundled link, the bandwidth
Top   ToC   RFC8233 - Page 13
   utilization is defined to be the sum of the component link bandwidth
   utilization.  This includes traffic for both RSVP-TE and non-RSVP-TE
   label switched path packets.

   The LBU in percentage is described as the (utilized bandwidth /
   maximum bandwidth) * 100.

   The "maximum bandwidth" is defined in [RFC3630] and [RFC5305] and
   "utilized bandwidth" in [RFC7471] and [RFC7810].

3.2.2. Link Reserved Bandwidth Utilization (LRBU)

The LRBU on a link, forwarding adjacency, or bundled link can be calculated from the TED. The utilized bandwidth includes traffic for both RSVP-TE and non-RSVP-TE LSPs; the reserved bandwidth utilization considers only the RSVP-TE LSPs. The reserved bandwidth utilization can be calculated by using the residual bandwidth, available bandwidth, and utilized bandwidth described in [RFC7471] and [RFC7810]. The actual bandwidth by non-RSVP-TE traffic can be calculated by subtracting the available bandwidth from the residual bandwidth ([RFC7471] and [RFC7810]), which is further deducted from utilized bandwidth to get the reserved bandwidth utilization. Thus, reserved bandwidth utilization = utilized bandwidth - (residual bandwidth - available bandwidth) The LRBU in percentage is described as the (reserved bandwidth utilization / maximum reservable bandwidth) * 100. The "maximum reservable bandwidth" is defined in [RFC3630] and [RFC5305]. The "utilized bandwidth", "residual bandwidth", and "available bandwidth" are defined in [RFC7471] and [RFC7810].

3.2.3. Bandwidth Utilization (BU) Object

The BU object is used to indicate the upper limit of the acceptable link bandwidth utilization percentage. The BU object MAY be carried within the PCReq message and PCRep messages. BU Object-Class is 35. BU Object-Type is 1.
Top   ToC   RFC8233 - Page 14
   The format of the BU object body is as follows:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |              Reserved                         |    Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bandwidth Utilization                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           BU Object Body Format

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

   Type (8 bits):  Represents the bandwidth utilization type.  Two
      values are currently defined.

      *  Type 1 is LBU (Link Bandwidth Utilization)

      *  Type 2 is LRBU (Link Residual Bandwidth Utilization)

   Bandwidth Utilization (32 bits):  Represents the bandwidth
      utilization quantified as a percentage (as described in Sections
      3.2.1 and 3.2.2) and encoded in IEEE floating point format (see
      [IEEE.754]).

   The BU object body has a fixed length of 8 bytes.

3.2.3.1. Elements of Procedure
A PCC that wants the PCE to factor in the bandwidth utilization during path computation includes a BU object in the PCReq message. A PCE that supports this object MUST ensure that no link on the computed path has the LBU or LRBU percentage exceeding the given value. A PCReq or PCRep message MAY contain multiple BU objects so long as each is for a different bandwidth utilization type. If a message contains more than one BU object with the same bandwidth utilization type, the first MUST be processed by the receiver and subsequent instances MUST be ignored. If the BU object is unknown/unsupported, the PCE is expected to 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
Top   ToC   RFC8233 - Page 15
   object class / object type), and the related path computation request
   will be discarded.  If the P bit is cleared, the PCE is free to
   ignore the object.

   If the PCE understands but does not support path computation requests
   using the BU object, and the P bit is set in the BU object header,
   then the PCE MUST send a PCErr message with a PCEP-ERROR Object
   Error-Type = 4 (Not supported object) with Error-value = 5
   (Unsupported network performance constraint), and the related path
   computation request MUST be discarded.

   If the PCE understands the BU object but the local policy has been
   configured on the PCE to not allow network performance constraint,
   and the P bit is set in the BU object header, then the PCE MUST send
   a PCErr message with a PCEP-ERROR Object Error-Type = 5 (Policy
   violation) with Error-value = 8 (Not allowed network performance
   constraint).  The path computation request MUST then be canceled.

   If path computation is unsuccessful, then a PCE MAY insert a BU
   object (along with a NO-PATH object) into a PCRep message to indicate
   the constraints that could not be satisfied.

   Usage of the BU object for P2MP LSPs is outside the scope of this
   document.

3.3. Objective Functions

[RFC5541] defines a mechanism to specify an objective function that is used by a PCE when it computes a path. The new metric types for path delay and path delay variation can continue to use the existing objective function -- Minimum Cost Path (MCP) [RFC5541]. For path loss, the following new OF is defined. o A network comprises a set of N links {Li, (i=1...N)}. o A path P is a list of K links {Lpi,(i=1...K)}. o The percentage link loss of link L is denoted PL(L). o The fractional link loss of link L is denoted FL(L) = PL(L) / 100. o The percentage path loss of a path P is denoted PL(P), where PL(P) = (1 - ((1-FL(Lp1)) * (1-FL(Lp2)) * .. * (1-FL(LpK)))) * 100. Objective Function Code: 9 Name: Minimum Packet Loss Path (MPLP) Description: Find a path P such that PL(P) is minimized.
Top   ToC   RFC8233 - Page 16
   Two additional objective functions -- namely, the Maximum Under-
   Utilized Path (MUP) and the Maximum Reserved Under-Utilized Path
   (MRUP) are needed to optimize bandwidth utilization.  These two new
   objective function codes are defined below.

   These objective functions are formulated using the following
   additional terminology:

   o  The bandwidth utilization on link L is denoted u(L).

   o  The reserved bandwidth utilization on link L is denoted ru(L).

   o  The maximum bandwidth on link L is denoted M(L).

   o  The maximum reservable bandwidth on link L is denoted R(L).

   The description of the two new objective functions is as follows.

   Objective Function Code:  10
   Name: Maximum Under-Utilized Path (MUP)
   Description: Find a path P such that (Min {(M(Lpi)- u(Lpi))
   / M(Lpi), i=1...K } ) is maximized.

   Objective Function Code:  11
   Name: Maximum Reserved Under-Utilized Path (MRUP)
   Description: Find a path P such that (Min {(R(Lpi)- ru(Lpi))
   / R(Lpi), i=1...K } ) is maximized.

   These new objective functions are used to optimize paths based on the
   bandwidth utilization as the optimization criteria.

   If the objective functions defined in this document are unknown/
   unsupported by a PCE, then the procedure as defined in Section 3.1.1
   of [RFC5541] is followed.



(page 16 continued on part 2)

Next Section