RFC 8233
Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
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
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]
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]
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.
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.
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
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 82337.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 82337.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.
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
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].
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>.
[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>.
[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>.
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.
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.
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
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