RFC 8623
Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
Pages: 33
Proposed Standard
Proposed Standard
Part 3 of 3 – Pages 23 to 33
8. Message Fragmentation
The total PCEP message length, including the common header, is (2^16)-1 bytes. In certain scenarios, the P2MP report and update request may not fit into a single PCEP message (e.g., initial report or update). The F flag is used in the LSP object to signal that the initial report, update, or initiate request was too large to fit into a single PCEP message and will be fragmented into multiple messages. In order to identify the single report or update, each message will use the same PLSP-ID. In order to identify that a series of PCInitiate messages represents a single Initiate, each message will use the same PLSP-ID (in this case 0) and SRP-ID-number. The fragmentation procedure described below for report or update messages is similar to [RFC8306], which describes request and response message fragmentation.8.1. Report Fragmentation Procedure
If the initial report is too large to fit into a single report message, the PCC will split the report over multiple messages. Each message sent to the PCE, except the last one, will have the F flag set in the LSP object to signify that the report has been fragmented into multiple messages. In order to identify that a series of report messages represents a single report, each message will use the same PLSP-ID. The Error-Type value 18 ("P2MP Fragmentation Error") is used to report any error associated with the fragmentation of a P2MP PCEP message. A new error-value 2 indicates "Fragmented report failure" and is used if a PCE does not receive the last part of the fragmented message.8.2. Update Fragmentation Procedure
Once the PCE computes and updates a path for some or all leaves in a P2MP TE LSP, an update message is sent to the PCC. If the update is too large to fit into a single update message, the PCE will split the update over multiple messages. Each update message sent by the PCE, except the last one, will have the F flag set in the LSP object to
signify that the update has been fragmented into multiple messages.
In order to identify that a series of update messages represents a
single update, each message will use the same PLSP-ID and SRP-ID-
number.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 3 indicates "Fragmented update failure"
and is used if a PCC does not receive the last part of the fragmented
message.
8.3. PCInitiate Fragmentation Procedure
Once the PCE initiates to set up a P2MP TE LSP, a PCInitiate message
is sent to the PCC. If the initiate request is too large to fit into
a single PCInitiate message, the PCE will split the initiate request
over multiple messages. Each PCInitiate message sent by the PCE,
except the last one, will have the F flag set in the LSP object to
signify that the PCInitiate has been fragmented into multiple
messages. In order to identify that a series of PCInitiate messages
represents a single Initiate, each message will use the same PLSP-ID
(in this case 0) and SRP-ID-number.
The Error-Type value 18 ("P2MP Fragmentation Error") is used to
report any error associated with the fragmentation of a P2MP PCEP
message. A new error-value 4 indicates "Fragmented instantiation
failure" and is used if a PCC does not receive the last part of the
fragmented message.
9. Nonsupport of P2MP TE LSPs for Stateful PCE
The PCEP extensions described in this document for stateful PCEs with
P2MP capability MUST NOT be used if the PCE has not advertised its
stateful capability with P2MP as per Section 5.2. If the PCC
supports the extensions as per this document (understands the N
(P2MP-CAPABILITY) and M (P2MP-LSP-UPDATE-CAPABILITY) flags in the LSP
object) but did not advertise this capability, then upon receipt of a
PCUpd message from the PCE, it SHOULD generate a PCErr with error-
type 19 ("Invalid Operation"), error-value 12 ("Attempted LSP Update
Request for P2MP if active stateful PCE capability for P2MP was not
advertised"), and terminate the PCEP session. If the PCE supports
the extensions as per this document (understands the N (P2MP-
CAPABILITY) flag in the LSP object) but did not advertise this
capability, then upon receipt of a PCRpt message from the PCC, it
SHOULD generate a PCErr with error-type 19 ("Invalid Operation"),
error-value 11 ("Attempted LSP State Report for P2MP if stateful PCE
capability for P2MP was not advertised"), and it SHOULD terminate the
PCEP session.
If a Stateful PCE receives a P2MP TE LSP report message and the PCE does not understand the N (P2MP-CAPABILITY) flag in the LSP object, and therefore the PCEP extensions described in this document, then the Stateful PCE would act as per Section 6.1 of [RFC8231] (and consider the PCRpt message as invalid). The PCEP extensions described in this document for PCC or PCE with the PCE-Initiation capability for P2MP TE LSPs MUST NOT be used if the PCC or PCE has not advertised its stateful capability with Instantiation and P2MP capability as per Section 5.2. If the PCC supports the extensions as per this document (understands the P (P2MP-LSP-INSTANTIATION-CAPABILITY) flag) but did not advertise this capability, then upon receipt of a PCInitiate message from the PCE, it SHOULD generate a PCErr with error-type 19 ("Invalid Operation"), error-value 13 ("Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised"), and terminate the PCEP session.10. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281] apply to PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.10.1. Control of Function and Policy
A PCE or PCC implementation MUST allow configuration of the stateful PCEP capability, the LSP Update capability, and the LSP Initiation capability for P2MP LSPs.10.2. Information and Data Models
The PCEP YANG module [PCE-PCEP-YANG] can be extended to include advertised P2MP stateful capabilities, P2MP synchronization status, and the delegation status of a P2MP LSP, etc. The statistics module should also count data related to P2MP LSPs.10.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440].
10.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281].10.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements on other protocols.10.6. Impact on Network Operations
Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8306], [RFC8231], and [RFC8281]. Stateful PCE features for P2MP LSPs would help with network operations.11. IANA Considerations
IANA has registered the code points for the protocol elements defined in this document.11.1. PCE Capabilities in IGP Advertisements
IANA has registered the new bits in the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, as follows: Bit Capability Description Reference 13 Active Stateful PCE with P2MP RFC 8623 14 Passive Stateful PCE with P2MP RFC 8623 15 Stateful PCE Initiation with P2MP RFC 862311.2. STATEFUL-PCE-CAPABILITY TLV
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231], and the "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry was created to manage the flags in the TLV. IANA has registered the following code points in the aforementioned registry. Bit Description Reference 23 P2MP-LSP-INSTANTIATION-CAPABILITY RFC 8623 24 P2MP-LSP-UPDATE-CAPABILITY RFC 8623 25 P2MP-CAPABILITY RFC 8623
11.3. LSP Object
The LSP object is defined in [RFC8231], and the "LSP Object Flag Field" subregistry was created to manage the Flags field of the LSP object. IANA has registered the following code points in the aforementioned registry. Bit Description Reference 1 ERO-compression RFC 8623 2 Fragmentation RFC 8623 3 P2MP RFC 862311.4. PCEP-ERROR Object
IANA has registered the new error values within the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry, as follows: Error-Type Meaning 6 Mandatory Object missing [RFC5440] Error-value = 13: S2LS object missing Error-value = 14: P2MP-LSP-IDENTIFIERS TLV missing 10 Reception of an invalid object [RFC5440] Error-value = 22: Mismatch of O field in S2LS and LSP object 18 P2MP Fragmentation Error [RFC8306] Error-value = 2: Fragmented Report failure Error-value = 3: Fragmented Update failure Error-value = 4: Fragmented Instantiation failure 19 Invalid Operation [RFC8231] Error-value = 11: Attempted LSP State Report for P2MP if stateful PCE capability for P2MP was not advertised Error-value = 12: Attempted LSP Update Request for P2MP if active stateful PCE capability for P2MP was not advertised Error-value = 13: Attempted LSP Instantiation Request for P2MP if stateful PCE instantiation capability for P2MP was not advertised The reference for all new Error-values above is RFC 8623.
11.5. PCEP TLV Type Indicators
IANA has registered the following code points in the existing "PCEP TLV Type Indicators" registry as follows: Value Description Reference 32 P2MP-IPV4-LSP-IDENTIFIERS RFC 8623 33 P2MP-IPV6-LSP-IDENTIFIERS RFC 862311.6. PCEP Object
IANA has registered the new object-class values and object types within the "PCEP Objects" subregistry of the PCEP Numbers registry, as follows. Object-Class Value Name Reference 41 S2LS RFC 8623 Object-Type 0: Reserved 1: S2LS11.7. S2LS Object
A new subregistry, named "S2LS Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the 32-bit flag field of the S2LS object. New values are to be assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Bit Description Reference 0-28 Unassigned 29-31 Operational (3 bits) RFC 8623
12. Security Considerations
The stateful operations on P2MP TE LSPs are more CPU intensive and also utilize more bandwidth on the wire (in comparison to P2P TE LSPs). If a rogue PCC were able to request unauthorized stateful PCE operations, then it may be able to mount a DoS attack against a PCE, which would disrupt the network and deny service to other PCCs. Similarly, an attacker may flood the PCC with PCUpd messages at a rate that exceeds either the PCC's ability to process them or the network's ability to signal the changes by either spoofing messages or compromising the PCE itself. Consequently, it is important that implementations conform to the relevant security requirements as listed below: o As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [RFC8253] as per the recommendations and best current practices in [RFC7525] (unless explicitly set aside in [RFC8253]). o Security considerations for path computation requests and responses are as per [RFC8306]. o Security considerations for stateful operations (such as state report, synchronization, delegation, update, etc.) are as per [RFC8231]. o Security considerations for the LSP instantiation mechanism are as per [RFC8231]. o Security considerations as stated in Sections 10.1, 10.6, and 10.7 of [RFC5440] continue to apply.13. References
13.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>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to- Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>. [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>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [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, <https://www.rfc-editor.org/info/rfc8231>. [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <https://www.rfc-editor.org/info/rfc8232>.
[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>. [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, <https://www.rfc-editor.org/info/rfc8281>. [RFC8306] Zhao, Q., Dhody, D., Ed., Palleti, R., and D. King, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 8306, DOI 10.17487/RFC8306, November 2017, <https://www.rfc-editor.org/info/rfc8306>.13.2. Informative References
[PCE-PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-11, March 2019. [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>. [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <https://www.rfc-editor.org/info/rfc5671>. [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>. [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>.
Acknowledgments
Thanks to Quintin Zhao, Avantika, and Venugopal Reddy for the review comments. Thanks to Adrian Farrel (and Jonathan Hardwick) for the review as document shepherds. Thanks to Andy Malis for the RTG-DIR review. Thanks to Donald Eastlake for the SEC-DIR review. Thanks to David Schinazi for the GEN-ART review. Thanks to Suresh Krishnan, Mirja Kuhlewind, Roman Danyliw, and Benjamin Kaduk for the IESG reviews.Contributors
Yuji Kamite NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: y.kamite@ntt.com
Authors' Addresses
Udayasree Palle Huawei Technologies Email: udayasreereddy@gmail.com Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Yosuke Tanaka NTT Communications Corporation Granpark Tower 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan Email: yosuke.tanaka@ntt.com Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net