doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc8233.txt b/doc/rfc/rfc8233.txt
new file mode 100644
index 0000000..7798ecc
--- /dev/null
+++ b/doc/rfc/rfc8233.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+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.
+
+
+
+Dhody, et al.                Standards Track                    [Page 1]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+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
+
+
+
+Dhody, et al.                Standards Track                    [Page 2]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+      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.
+
+
+
+Dhody, et al.                Standards Track                    [Page 3]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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)
+
+
+
+Dhody, et al.                Standards Track                    [Page 4]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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)
+
+
+
+
+Dhody, et al.                Standards Track                    [Page 5]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                    [Page 6]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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
+
+
+
+Dhody, et al.                Standards Track                    [Page 7]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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.
+
+
+
+
+
+Dhody, et al.                Standards Track                    [Page 8]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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].
+
+
+
+Dhody, et al.                Standards Track                    [Page 9]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 10]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 11]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+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
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 12]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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.
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 13]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 14]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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.
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 15]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   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.
+
+4.  Stateful PCE and PCE Initiated LSPs
+
+   [RFC8231] specifies a set of extensions to PCEP to enable stateful
+   control of MPLS-TE and GMPLS LSPs via PCEP and the maintaining of
+   these LSPs at the stateful PCE.  It further distinguishes between an
+   active and a passive stateful PCE.  A passive stateful PCE uses LSP
+   state information learned from PCCs to optimize path computations but
+   does not actively update LSP state.  In contrast, an active stateful
+   PCE utilizes the LSP delegation mechanism to update LSP parameters in
+   those PCCs that delegated control over their LSPs to the PCE.
+   [PCE-INITIATED] describes the setup, maintenance, and teardown of
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 16]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   PCE-initiated LSPs under the stateful PCE model.  The document
+   defines the PCInitiate message that is used by a PCE to request a PCC
+   to set up a new LSP.
+
+   The new metric type and objective functions defined in this document
+   can also be used with the stateful PCE extensions.  The format of
+   PCEP messages described in [RFC8231] and [PCE-INITIATED] uses
+   <intended-attribute-list> and <attribute-list>, respectively, (where
+   the <intended-attribute-list> is the attribute-list defined in
+   Section 6.5 of [RFC5440] and extended in Section 5.2 of this
+   document) for the purpose of including the service-aware parameters.
+
+   The stateful PCE implementation MAY use the extension of PCReq and
+   PCRep messages as defined in Sections 5.1 and 5.2 to enable the use
+   of service-aware parameters during passive stateful operations.
+
+5.  PCEP Message Extension
+
+   Message formats in this document are expressed using Routing Backus-
+   Naur Form (RBNF) as used in [RFC5440] and defined in [RFC5511].
+
+5.1.  The PCReq Message
+
+   The extensions to the PCReq message are:
+
+   o  new metric types using existing METRIC object
+
+   o  a new optional BU object
+
+   o  new objective functions using existing OF object [RFC5541]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 17]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   The format of the PCReq message (with [RFC5541] and [RFC8231] as a
+   base) is updated as follows:
+
+      <PCReq Message> ::= <Common Header>
+                           [<svec-list>]
+                           <request-list>
+      where:
+           <svec-list> ::= <SVEC>
+                           [<OF>]
+                           [<metric-list>]
+                           [<svec-list>]
+
+           <request-list> ::= <request> [<request-list>]
+
+           <request> ::= <RP>
+                         <END-POINTS>
+                         [<LSP>]
+                         [<LSPA>]
+                         [<BANDWIDTH>]
+                         [<bu-list>]
+                         [<metric-list>]
+                         [<OF>]
+                         [<RRO>[<BANDWIDTH>]]
+                         [<IRO>]
+                         [<LOAD-BALANCING>]
+
+      and where:
+           <bu-list>::=<BU>[<bu-list>]
+           <metric-list> ::= <METRIC>[<metric-list>]
+
+5.2.  The PCRep Message
+
+   The extensions to the PCRep message are:
+
+   o  new metric types using existing METRIC object
+
+   o  a new optional BU object (during unsuccessful path computation, to
+      indicate the bandwidth utilization as a reason for failure)
+
+   o  new objective functions using existing OF object [RFC5541]
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 18]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   The format of the PCRep message (with [RFC5541] and [RFC8231] as a
+   base) is updated as follows:
+
+      <PCRep Message> ::= <Common Header>
+                          [<svec-list>]
+                          <response-list>
+
+      where:
+
+            <svec-list> ::= <SVEC>
+                            [<OF>]
+                            [<metric-list>]
+                            [<svec-list>]
+
+           <response-list> ::= <response> [<response-list>]
+
+           <response> ::= <RP>
+                          [<LSP>]
+                          [<NO-PATH>]
+                          [<attribute-list>]
+                          [<path-list>]
+
+           <path-list> ::= <path> [<path-list>]
+
+           <path> ::= <ERO>
+                      <attribute-list>
+
+      and where:
+
+           <attribute-list> ::= [<OF>]
+                                [<LSPA>]
+                                [<BANDWIDTH>]
+                                [<bu-list>]
+                                [<metric-list>]
+                                [<IRO>]
+
+           <bu-list>::=<BU>[<bu-list>]
+           <metric-list> ::= <METRIC> [<metric-list>]
+
+5.3.  The PCRpt Message
+
+   A Path Computation LSP State Report message (also referred to as
+   PCRpt message) is a PCEP message sent by a PCC to a PCE to report the
+   current state or delegate control of an LSP.  The BU object in a
+   PCRpt message specifies the upper limit set at the PCC at the time of
+   LSP delegation to an active stateful PCE.
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 19]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   The format of the PCRpt message is described in [RFC8231], which uses
+   the <intended-attribute-list>, which is the attribute-list defined in
+   Section 6.5 of [RFC5440] and extended by PCEP extensions.
+
+   The PCRpt message can use the updated <attribute-list> (as extended
+   in Section 5.2) for the purpose of including the BU object.
+
+6.  Other Considerations
+
+6.1.  Inter-domain Path Computation
+
+   [RFC5441] describes the Backward Recursive PCE-Based Computation
+   (BRPC) procedure to compute an end-to-end optimized inter-domain path
+   by cooperating PCEs.  The new metric types defined in this document
+   can be applied to end-to-end path computation, in a similar manner to
+   the existing IGP or TE metrics.  The new BU object defined in this
+   document can be applied to end-to-end path computation, in a similar
+   manner to a METRIC object with its B bit set to 1.
+
+   All domains should have the same understanding of the METRIC (path
+   delay variation, etc.) and the BU object for end-to-end inter-domain
+   path computation to make sense.  Otherwise, some form of metric
+   normalization as described in [RFC5441] MUST be applied.
+
+6.1.1.  Inter-AS Links
+
+   The IGP in each neighbor domain can advertise its inter-domain TE
+   link capabilities.  This has been described in [RFC5316] (IS-IS) and
+   [RFC5392] (OSPF).  The network performance link properties are
+   described in [RFC7471] and [RFC7810].  The same properties must be
+   advertised using the mechanism described in [RFC5392] (OSPF) and
+   [RFC5316] (IS-IS).
+
+6.1.2.  Inter-Layer Path Computation
+
+   [RFC5623] provides a framework for PCE-based inter-layer MPLS and
+   GMPLS traffic engineering.  Lower-layer LSPs that are advertised as
+   TE links into the higher-layer network form a Virtual Network
+   Topology (VNT).  The advertisement into the higher-layer network
+   should include network performance link properties based on the
+   end-to-end metric of the lower-layer LSP.  Note that the new metrics
+   defined in this document are applied to end-to-end path computation,
+   even though the path may cross multiple layers.
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 20]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+6.2.  Reoptimizing Paths
+
+   [RFC6374] defines the measurement of loss, delay, and related metrics
+   over LSPs.  A PCC can utilize these measurement techniques.  In case
+   it detects a degradation of network performance parameters relative
+   to the value of the constraint it gave when the path was set up, or
+   relative to an implementation-specific threshold, it MAY ask the PCE
+   to reoptimize the path by sending a PCReq with the R bit set in the
+   RP object, as per [RFC5440].
+
+   A PCC may also detect the degradation of an LSP without making any
+   direct measurements, by monitoring the TED (as populated by the IGP)
+   for changes in the network performance parameters of the links that
+   carry its LSPs.  The PCC can issue a reoptimization request for any
+   impacted LSPs.  For example, a PCC can monitor the link bandwidth
+   utilization along the path by monitoring changes in the bandwidth
+   utilization parameters of one or more links on the path in the TED.
+   If the bandwidth utilization percentage of any of the links in the
+   path changes to a value less than that required when the path was set
+   up, or otherwise less than an implementation-specific threshold, then
+   the PCC can issue a reoptimization request to a PCE.
+
+   A stateful PCE can also determine which LSPs should be reoptimized
+   based on network events or triggers from external monitoring systems.
+   For example, when a particular link deteriorates and its loss
+   increases, this can trigger the stateful PCE to automatically
+   determine which LSPs are impacted and should be reoptimized.
+
+7.  IANA Considerations
+
+7.1.  METRIC Types
+
+   IANA maintains the "Path Computation Element Protocol (PCEP) Numbers"
+   registry at <http://www.iana.org/assignments/pcep>.  Within this
+   registry, IANA maintains a subregistry for "METRIC Object T Field".
+   Six new metric types are defined in this document for the METRIC
+   object (specified in [RFC5440]).
+
+   IANA has made the following allocations:
+
+        Value       Description                        Reference
+        ----------------------------------------------------------
+        12          Path Delay metric                  RFC 8233
+        13          Path Delay Variation metric        RFC 8233
+        14          Path Loss metric                   RFC 8233
+        15          P2MP Path Delay metric             RFC 8233
+        16          P2MP Path Delay variation metric   RFC 8233
+        17          P2MP Path Loss metric              RFC 8233
+
+
+
+Dhody, et al.                Standards Track                   [Page 21]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+7.2.  New PCEP Object
+
+   IANA maintains Object-Types within the "PCEP Objects" registry.  IANA
+   has made the following allocation:
+
+          Object    Object     Name                  Reference
+          Class     Type
+          ------------------------------------------------------
+          35        0          Reserved              RFC 8233
+                    1          BU                    RFC 8233
+
+7.3.  BU Object
+
+   IANA has created a new subregistry, named "BU Object Type Field",
+   within the "Path Computation Element Protocol (PCEP) Numbers"
+   registry to manage the Type field of the BU object.  New values are
+   to be assigned by Standards Action [RFC8126].  Each value should be
+   tracked with the following qualities:
+
+   o  Type
+
+   o  Name
+
+   o  Reference
+
+   The following values are defined in this document:
+
+      Type    Name                                        Reference
+      ---------------------------------------------------------------
+      0       Reserved                                    RFC 8233
+
+      1       LBU (Link Bandwidth Utilization)            RFC 8233
+
+      2       LRBU (Link Residual Bandwidth Utilization)  RFC 8233
+
+7.4.  OF Codes
+
+   IANA maintains the "Objective Function" subregistry (described in
+   [RFC5541]) within the "Path Computation Element Protocol (PCEP)
+   Numbers" registry.  Three new objective functions have been defined
+   in this document.
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 22]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   IANA has made the following allocations:
+
+     Code     Name                                         Reference
+     Point
+     -----------------------------------------------------------------
+     9        Minimum Packet Loss Path (MPLP)              RFC 8233
+
+     10       Maximum Under-Utilized Path (MUP)            RFC 8233
+
+     11       Maximum Reserved Under-Utilized Path (MRUP)  RFC 8233
+
+7.5.  New 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" subregistry of the "Path Computation Element
+   Protocol (PCEP) Numbers" registry.
+
+   IANA has made the following allocations:
+
+   Two new Error-values are defined for the Error-Type "Not supported
+   object" (type 4) and "Policy violation" (type 5).
+
+       Error-Type     Meaning and error values           Reference
+       -------------------------------------------------------------
+          4           Not supported object
+
+                      Error-value
+                      5: Unsupported network             RFC 8233
+                      performance constraint
+
+          5           Policy violation
+
+                      Error-value
+                      8: Not allowed network             RFC 8233
+                      performance constraint
+
+8.  Security Considerations
+
+   This document defines new METRIC types, a new BU object, and new OF
+   codes that do not add any new security concerns beyond those
+   discussed in [RFC5440] and [RFC5541] in itself.  Some deployments may
+   find the service-aware information like delay and packet loss to be
+   extra sensitive and could be used to influence path computation and
+   setup with adverse effect.  Additionally, snooping of PCEP messages
+   with such data or using PCEP messages for network reconnaissance may
+   give an attacker sensitive information about the operations of the
+   network.  Thus, such deployment should employ suitable PCEP security
+
+
+
+Dhody, et al.                Standards Track                   [Page 23]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   mechanisms like TCP Authentication Option (TCP-AO) [RFC5925] or
+   [PCEPS].  The procedure based on Transport Layer Security (TLS) in
+   [PCEPS] is considered a security enhancement and thus is much better
+   suited for the sensitive service-aware information.
+
+9.  Manageability Considerations
+
+9.1.  Control of Function and Policy
+
+   The only configurable item is the support of the new constraints on a
+   PCE, which MAY be controlled by a policy module on an individual
+   basis.  If the new constraint is not supported/allowed on a PCE, it
+   MUST send a PCErr message accordingly.
+
+9.2.  Information and Data Models
+
+   [RFC7420] describes the PCEP MIB.  There are no new MIB Objects for
+   this document.
+
+9.3.  Liveness Detection and Monitoring
+
+   The mechanisms defined in this document do not imply any new liveness
+   detection and monitoring requirements in addition to those already
+   listed in [RFC5440].
+
+9.4.  Verify Correct Operations
+
+   The mechanisms defined in this document do not imply any new
+   operation verification requirements in addition to those already
+   listed in [RFC5440].
+
+9.5.  Requirements on Other Protocols
+
+   The PCE requires the TED to be populated with network performance
+   information like link latency, delay variation, packet loss, and
+   utilized bandwidth.  This mechanism is described in [RFC7471] and
+   [RFC7810].
+
+9.6.  Impact on Network Operations
+
+   The mechanisms defined in this document do not have any impact on
+   network operations in addition to those already listed in [RFC5440].
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 24]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3630]  Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
+              (TE) Extensions to OSPF Version 2", RFC 3630,
+              DOI 10.17487/RFC3630, September 2003,
+              <https://www.rfc-editor.org/info/rfc3630>.
+
+   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
+              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
+              2008, <https://www.rfc-editor.org/info/rfc5305>.
+
+   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              DOI 10.17487/RFC5440, March 2009,
+              <https://www.rfc-editor.org/info/rfc5440>.
+
+   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+              Used to Form Encoding Rules in Various Routing Protocol
+              Specifications", RFC 5511, DOI 10.17487/RFC5511, April
+              2009, <https://www.rfc-editor.org/info/rfc5511>.
+
+   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+              Objective Functions in the Path Computation Element
+              Communication Protocol (PCEP)", RFC 5541,
+              DOI 10.17487/RFC5541, June 2009,
+              <https://www.rfc-editor.org/info/rfc5541>.
+
+   [RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
+              Previdi, "OSPF Traffic Engineering (TE) Metric
+              Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
+              <https://www.rfc-editor.org/info/rfc7471>.
+
+   [RFC7810]  Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and
+              Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions",
+              RFC 7810, DOI 10.17487/RFC7810, May 2016,
+              <https://www.rfc-editor.org/info/rfc7810>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 25]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
+              Computation Element Communication Protocol (PCEP)
+              Extensions for Stateful PCE", RFC 8231,
+              DOI 10.17487/RFC8231, September 2017,
+              <http://www.rfc-editor.org/info/rfc8231>.
+
+10.2.  Informative References
+
+   [IEEE.754]
+              IEEE, "Standard for Binary Floating-Point Arithmetic",
+              IEEE Standard 754-2008, DOI 10.1109/IEEESTD.2008.4610935,
+              August 2008.
+
+   [PCE-INITIATED]
+              Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP
+              Extensions for PCE-initiated LSP Setup in a Stateful PCE
+              Model", Work in Progress,
+              draft-ietf-pce-pce-initiated-lsp-10, June 2017.
+
+   [PCEPS]    Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure
+              Transport for PCEP", Work in Progress,
+              draft-ietf-pce-pceps-16, September 2017.
+
+   [RFC4655]  Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
+              Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <https://www.rfc-editor.org/info/rfc4655>.
+
+   [RFC5316]  Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
+              Support of Inter-Autonomous System (AS) MPLS and GMPLS
+              Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
+              December 2008, <https://www.rfc-editor.org/info/rfc5316>.
+
+   [RFC5392]  Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
+              Support of Inter-Autonomous System (AS) MPLS and GMPLS
+              Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
+              January 2009, <https://www.rfc-editor.org/info/rfc5392>.
+
+   [RFC5441]  Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
+              "A Backward-Recursive PCE-Based Computation (BRPC)
+              Procedure to Compute Shortest Constrained Inter-Domain
+              Traffic Engineering Label Switched Paths", RFC 5441,
+              DOI 10.17487/RFC5441, April 2009,
+              <https://www.rfc-editor.org/info/rfc5441>.
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 26]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+   [RFC5623]  Oki, E., Takeda, T., Le Roux, JL., and A. Farrel,
+              "Framework for PCE-Based Inter-Layer MPLS and GMPLS
+              Traffic Engineering", RFC 5623, DOI 10.17487/RFC5623,
+              September 2009, <https://www.rfc-editor.org/info/rfc5623>.
+
+   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
+              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+              June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+   [RFC6049]  Morton, A. and E. Stephan, "Spatial Composition of
+              Metrics", RFC 6049, DOI 10.17487/RFC6049, January 2011,
+              <https://www.rfc-editor.org/info/rfc6049>.
+
+   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
+              Measurement for MPLS Networks", RFC 6374,
+              DOI 10.17487/RFC6374, September 2011,
+              <https://www.rfc-editor.org/info/rfc6374>.
+
+   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
+              Hardwick, "Path Computation Element Communication Protocol
+              (PCEP) Management Information Base (MIB) Module",
+              RFC 7420, DOI 10.17487/RFC7420, December 2014,
+              <https://www.rfc-editor.org/info/rfc7420>.
+
+   [RFC7823]  Atlas, A., Drake, J., Giacalone, S., and S. Previdi,
+              "Performance-Based Path Selection for Explicitly Routed
+              Label Switched Paths (LSPs) Using TE Metric Extensions",
+              RFC 7823, DOI 10.17487/RFC7823, May 2016,
+              <https://www.rfc-editor.org/info/rfc7823>.
+
+   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+              Writing an IANA Considerations Section in RFCs", BCP 26,
+              RFC 8126, DOI 10.17487/RFC8126, June 2017,
+              <https://www.rfc-editor.org/info/rfc8126>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 27]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+Appendix A.  PCEP Requirements
+
+   End-to-end service optimization based on latency, delay variation,
+   packet loss, and link bandwidth utilization are key requirements for
+   service providers.  The following associated key requirements are
+   identified for PCEP:
+
+   1.  A PCE supporting this specification MUST have the capability to
+       compute end-to-end paths with latency, delay variation, packet
+       loss, and bandwidth utilization constraints.  It MUST also
+       support the combination of network performance constraints
+       (latency, delay variation, loss,...) with existing constraints
+       (cost, hop-limit,...).
+
+   2.  A PCC MUST be able to specify any network performance constraint
+       in a PCReq message to be applied during the path computation.
+
+   3.  A PCC MUST be able to request that a PCE optimizes a path using
+       any network performance criteria.
+
+   4.  A PCE that supports this specification is not required to provide
+       service-aware path computation to any PCC at any time.
+
+       Therefore, it MUST be possible for a PCE to reject a PCReq
+       message with a reason code that indicates service-aware path
+       computation is not supported.  Furthermore, a PCE that does not
+       support this specification will either ignore or reject such
+       requests using pre-existing mechanisms; therefore, the requests
+       MUST be identifiable to legacy PCEs, and rejections by legacy
+       PCEs MUST be acceptable within this specification.
+
+   5.  A PCE SHOULD be able to return end-to-end network performance
+       information of the computed path in a PCRep message.
+
+   6.  A PCE SHOULD be able to compute multi-domain (e.g., Inter-AS,
+       Inter-Area, or Multi-Layer) service-aware paths.
+
+   Such constraints are only meaningful if used consistently: for
+   instance, if the delay of a computed path segment is exchanged
+   between two PCEs residing in different domains, a consistent way of
+   defining the delay must be used.
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 28]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+Acknowledgments
+
+   We would like to thank Alia Atlas, John E. Drake, David Ward, Young
+   Lee, Venugopal Reddy, Reeja Paul, Sandeep Kumar Boina, Suresh Babu,
+   Quintin Zhao, Chen Huaimo, Avantika, and Adrian Farrel for their
+   useful comments and suggestions.
+
+   Also, the authors gratefully acknowledge reviews and feedback
+   provided by Qin Wu, Alfred Morton, and Paul Aitken during performance
+   directorate review.
+
+   Thanks to Jonathan Hardwick for shepherding this document and
+   providing valuable comments.  His help in fixing the editorial and
+   grammatical issues is also appreciated.
+
+   Thanks to Christian Hopps for the routing directorate review.
+
+   Thanks to Jouni Korhonen and Alfred Morton for the operational
+   directorate review.
+
+   Thanks to Christian Huitema for the security directorate review.
+
+   Thanks to Deborah Brungard for being the responsible AD.
+
+   Thanks to Ben Campbell, Joel Jaeggli, Stephen Farrell, Kathleen
+   Moriarty, Spencer Dawkins, Mirja Kuehlewind, Jari Arkko, and Alia
+   Atlas for the IESG reviews.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 29]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+Contributors
+
+   Clarence Filsfils
+   Cisco Systems
+   Email: cfilsfil@cisco.com
+
+   Siva Sivabalan
+   Cisco Systems
+   Email: msiva@cisco.com
+
+   George Swallow
+   Cisco Systems
+   Email: swallow@cisco.com
+
+   Stefano Previdi
+   Cisco Systems, Inc
+   Via Del Serafico 200
+   Rome  00191
+   Italy
+   Email: sprevidi@cisco.com
+
+   Udayasree Palle
+   Huawei Technologies
+   Divyashree Techno Park, Whitefield
+   Bangalore, Karnataka  560066
+   India
+   Email: udayasree.palle@huawei.com
+
+   Avantika
+   Huawei Technologies
+   Divyashree Techno Park, Whitefield
+   Bangalore, Karnataka  560066
+   India
+   Email: avantika.sushilkumar@huawei.com
+
+   Xian Zhang
+   Huawei Technologies
+   F3-1-B R&D Center, Huawei Base Bantian, Longgang District
+   Shenzhen, Guangdong  518129
+   China
+   Email: zhang.xian@huawei.com
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 30]
+
+RFC 8233                   Service-Aware LSPs             September 2017
+
+
+Authors' Addresses
+
+   Dhruv Dhody
+   Huawei Technologies
+   Divyashree Techno Park, Whitefield
+   Bangalore, Karnataka  560066
+   India
+
+   Email: dhruv.ietf@gmail.com
+
+
+   Qin Wu
+   Huawei Technologies
+   101 Software Avenue, Yuhua District
+   Nanjing, Jiangsu  210012
+   China
+
+   Email: bill.wu@huawei.com
+
+
+   Vishwas Manral
+   Nano Sec Co
+   3350 Thomas Rd.
+   Santa Clara, CA
+   United States of America
+
+   Email: vishwas@nanosec.io
+
+
+   Zafar Ali
+   Cisco Systems
+
+   Email: zali@cisco.com
+
+
+   Kenji Kumaki
+   KDDI Corporation
+
+   Email: ke-kumaki@kddi.com
+
+
+
+
+
+
+
+
+
+
+
+
+Dhody, et al.                Standards Track                   [Page 31]
+