summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8233.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8233.txt')
-rw-r--r--doc/rfc/rfc8233.txt1739
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]
+