PCEP F. Yang Internet-Draft China Mobile Intended status: Standards Track C. Lin Expires: 25 March 2025 New H3C Technologies T. Han China Mobile September 25, 2024 PCEP over QUIC draft-yang-pce-pcep-over-quic-00 Abstract This document specifies the use of QUIC streams to implement the PCEP protocol for efficient and secure data transmission. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 25, 2025. Copyright Notice Copyright (c) 2024 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 (http://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 Yang, et al. Expires March 25, 2025 [Page 1] Internet-Draft PCEP over QUIC September 2024 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.....................................3 2. Terminology....................................................3 3. PCEPoQ Process.................................................4 3.1. Connection establishment..................................4 3.2. PCEPoQ Open Message.......................................4 3.3. PCEPoQ KeepAlive Message..................................5 3.4. PCEPoQ Path Computation Request (PCEPoQReq)...............6 3.5. PCEPoQ Path Computation Reply (PCEPoQRep).................6 3.6. PCEPoQ Notification (PCEPoQNtf)...........................6 3.7. PCEPoQ Error (PCEPoQrr)...................................6 3.8. PCEPoQ Connection Termination.............................7 4. PCEPoQ Finite State Machine (FSM)..............................7 5. Stream multiplexing...........................................14 6. Network migration.............................................14 7. Flow Control..................................................14 8. Security Considerations.......................................14 9. IANA Considerations...........................................14 9.1. UDP Port for PCEPoQ......................................14 9.2. Registration of the PCEP Identification String...........15 9.3. PCEPoQ Capability TLV....................................15 10. References...................................................16 10.1. Normative References....................................16 10.2. Informative References..................................16 Authors' Addresses...............................................17 Yang, et al. Expires March 25, 2025 [Page 2] Internet-Draft PCEP over QUIC September 2024 1. Introduction The Path Computation Element Communication Protocol (PCEP) [RFC5440] facilitates communication between Path Computation Clients (PCCs) and Path Computation Elements (PCEs) to optimize network routing and resource utilization. QUIC (Quick UDP Internet Connections) ([RFC9000][RFC9001]) is a transport protocol based on UDP, offering low-latency connections, multiplexing, improved congestion control, and built-in encryption, similar to TLS. Implementing PCEP over QUIC offers several key benefits: o Faster Connection Establishment: QUIC's quick handshake reduces connection setup times. o No Head-of-Line Blocking: Multiple PCEP sessions can run concurrently over a single connection. o Improved Packet Loss Recovery: QUIC's efficient mechanisms ensure reliable data transmission. o Enhanced Security: Built-in encryption ensures the confidentiality and integrity of PCEP messages. o High Resiliency: Support for multiple sessions within a single connection enhances system reliability. In summary, using QUIC for PCEP enhances efficiency, security, and reliability in network routing communications. This document primarily describes the protocol adaptations necessary for using a QUIC connection with the PCEP protocol. The protocol process fully adheres to the specifications described in [RFC5440]. 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 PCEPoQ, PCEP using QUIC. Yang, et al. Expires March 25, 2025 [Page 3] Internet-Draft PCEP over QUIC September 2024 3. PCEPoQ Process 3.1. Connection establishment The process of establishing a PCEP session is described in [RFC5440]. The establishment of a PCEPoQ connection involves three stages: First, a QUIC connection is established at the transport layer as described in [RFC9000]. PCC over QUIC acts as the QUIC client, and PCE over QUIC serves as the QUIC server. When setting up a QUIC connection, PCEPoQ uses UDP port number TBD1 and employs TLS for security. During the TLS handshake, the Application-Layer Protocol Negotiation (ALPN) token "pcepoq" is used. Second, based on the transport layer QUIC connection, the PCEPoQ speaker establishes a bidirectional stream for the "PCEPoQ control channel." The control channel is used to establish a PCEPoQ relationship between the PCC and the PCE over QUIC. PCEPoQ OPEN messages are used to establish the PCEPoQ control channel. After the channel is established, PCEPoQ KeepAlive messages are sent to maintain the control channel. PCEPoQ Close messages are used to terminate the control channel. PCEPoQ Notify messages are used to send specified notifications. When an error occurs, a PCEPoQErr message is sent through the PCEPoQ control channel to notify the PCEPoQ peer. Third, after establishing the control channel, each PCEPoQ speaker may create data channels using unidirectional QUIC streams. These data channels are used to carry PCEPoQReq and PCEPoQRep messages. For IPv4 and IPv6 address families, separate data channels can also be established. The advantage of separating the control channel from the data channels is that it allows for higher priority handling of the control channel's traffic, ensuring timely processing of control messages without delay caused by handling data messages. Moreover, if PCEPoQ supports other address families in the future, using separate data channels can ensure that different address families do not interfere with each other. For different PCEPoQ sessions, the same QUIC connection is used. The "pcepoq" ALPN token is not session-specific. 3.2. PCEPoQ Open Message Once a QUIC connection is established, the PCC and PCE over QUIC initiate the PCEPoQ session establishment process, during which various session parameters are negotiated. These parameters are Yang, et al. Expires March 25, 2025 [Page 4] Internet-Draft PCEP over QUIC September 2024 carried within PCEPoQ Open messages and include the Keepalive timer, DeadTimer, and policy rules that specify the conditions under which path computation requests may be sent to the PCE, as well as the supported PCEPoQ capabilities and other detailed capabilities. If the PCEPoQ session establishment phase fails because the PCEPoQ peers disagree on the session parameters or one of the PCEPoQ peers does not respond after the expiration of the establishment timer, successive retries are permitted. However, an implementation should use an exponential back-off procedure for session establishment retries. To negotiate PCEPoQ-related capabilities, this document extends the PCEPoQ Capability TLV[this document 6.3]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD2) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability |D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCEPoQ capability: Type : 2 bytes (TBD2) Length : 2 bytes (4) Capability: D: Bit 0, support data channel, this document When sending an PCEPoQ OPEN message to establish a PCEPoQ session, the local PCEPoQ capabilities are included. If the capability negotiation fails, the PCEPoQ session establishment fails. After a failure, After a failure, if no other sessions exist, a QUIC connection may choose to remain open or close based on specific implementation, though this document does not elaborate further. 3.3. PCEPoQ KeepAlive Message Once a PCEPoQ session has been established, a PCE or PCC over QUIC may want to know that its PCEPoQ peer is still available for use. PCEPoQ includes a keepalive mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive message. The PCEP KeepAlive message is sent through the PCEPoQ control channel. If no PCEPoQ KeepAlive message is received within the DeadTimer period, the PCEPoQ session should be reset and a new session should be attempted. While resetting the PCEPoQ session, the corresponding PCEPoQ data channel should also be reset. Yang, et al. Expires March 25, 2025 [Page 5] Internet-Draft PCEP over QUIC September 2024 3.4. PCEPoQ Path Computation Request (PCEPoQReq) Once a PCC has successfully established a PCEPoQ session with one or more PCEs, if an event is triggered that requires the computation of a set of paths, the PCC first selects one or more PCEs. Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message) by PCEPoQ connection. The PCReq message can only be sent and received through the PCEPoQ data channel. If this message is received on the control channel, it will be ignored. 3.5. PCEPoQ Path Computation Reply (PCEPoQRep) Upon receiving a path computation request from a PCC, the PCE initiates a path computation. The result is then sent to the PCC via a PCRep message through the PCEPoQ data channel. The PCRep message can only be sent and received through the PCEPoQ data channel. If this message is received on the control channel, it will be ignored. 3.6. PCEPoQ Notification (PCEPoQNtf) The PCEPoQ Notification message can be sent by either a PCE to a PCC, or by a PCC to a PCE, to notify of a specific event. This message is transmitted through the PCEPoQ channel. There are several circumstances in which a PCE over QUIC may want to notify a PCC over QUIC of a specific event. For example, suppose that the PCE over QUIC suddenly gets overloaded, potentially leading to unacceptable response times. The PCE over QUIC may want to notify one or more PCCs over QUIC that some of their requests (listed in the notification) will not be satisfied or may experience unacceptable delays. Upon receiving such notification, the PCC over QUIC may decide to redirect its path computation requests to another PCE over QUIC should an alternate PCE be available. Similarly, a PCC over QUIC may desire to notify a PCE over QUIC of a particular event such as the cancellation of pending requests. 3.7. PCEPoQ Error (PCEPoQrr) The PCEP over QUIC Error message is sent in several situations: when a protocol error condition is met or when the request is not compliant with the PCEP over QUIC specification (e.g., capability not supported, reception of a message with a mandatory missing object, policy violation, unexpected message, unknown request reference). Yang, et al. Expires March 25, 2025 [Page 6] Internet-Draft PCEP over QUIC September 2024 This message is transmitted through the PCEPoQ control channel. 3.8. PCEPoQ Connection Termination When one of the PCEP over QUIC peers wishes to terminate a PCEPoQ session, it first sends a PCEP Close message. This message is transmitted through the PCEPoQ control channel. The sender then closes the PCEPoQ session. Upon receiving the Close Message, the recipient closes the corresponding PCEPoQ session. If there are no other PCEPoQ connections, the QUIC connection can be closed or kept permanently active depending on the implementation. This document assumes that the QUIC connection remains open, and the following sections on the state machine are based on this assumption and will not repeat it. 4. PCEPoQ Finite State Machine (FSM) The section describes the PCEPoQ finite state machine (FSM). The main differences between the PCEPoQ and PCEP state machines are as follows: o Connection Maintenance: PCEP requires maintaining a TCP connection and responding to changes in its state. In contrast, PCEPoQ maintains a QUIC connection, which doesn't require responding to state changes after it's established. o Session Correspondence: PCEP has each session corresponding to a separate TCP connection. PCEPoQ, however, maintains a single QUIC connection for all sessions, with a shared control channel and individual data channels for each session. o State Machine Handling: In the PCEPoQ state machine, the creation and closure of control and data channels need to be handled when there are state changes. Yang, et al. Expires March 25, 2025 [Page 7] Internet-Draft PCEP over QUIC September 2024 +-+-+-+-+-+-+<------+ +------| SessionUP |<---+ | | +-+-+-+-+-+-+ | | | | | | +->+-+-+-+-+-+-+ | | | | | KeepWait |----+ | | +--| |<---+ | |+-----+-+-+-+-+-+-+ | | || | | | || | | | || V | | || +->+-+-+-+-+-+-+----+ | || | | OpenWait |-------+ || +--| |<------+ ||+----+-+-+-+-+-+-+<---+ | ||| | | | ||| | | | ||| V | | ||| +->+-+-+-+-+-+-+ | | ||| | |Pending |----+ | ||| +--| | | |||+---+-+-+-+-+-+-+<---+ | |||| | | | |||| | | | |||| V | | |||+--->+-+-+-+-+ | | ||+---->| Idle |-------+ | |+----->| |----------+ +------>+-+-+-+-+ Figure: PCEPoQ Finite State Machine PCEPoQ defines the following set of variables: Connect: the timer (in seconds) started after having initialized a QUIC connection using the PCEPoQ-registered UDP port. The value of the Connect timer is 60 seconds. ConnectRetry: the number of times the system has tried to establish a QUIC connection with a PCEPoQ peer without success. ConnectMaxRetry: the maximum number of times the system tries to establish a QUIC connection using the PCEPoQ-registered UDP port before going back to the Idle state. The value of the ConnectMaxRetry is 5. OpenWait: the timer that corresponds to the amount of time a PCEPoQ peer will wait to receive an PCEPoQ Open message from the PCEPoQ Yang, et al. Expires March 25, 2025 [Page 8] Internet-Draft PCEP over QUIC September 2024 peer after the expiration of which the system releases the PCEPoQ resource and goes back to the Idle state. The OpenWait timer has a fixed value of 60 seconds. KeepWait: the timer that corresponds to the amount of time a PCEPoQ peer will wait to receive a Keepalive or a PCEoQErr message from the PCEPoQ peer after the expiration of which the system releases the PCEPoQ resource and goes back to the Idle state. The KeepWait timer has a fixed value of 60 seconds. OpenRetry: the number of times the system has received an PCEPoQ Open message with unacceptable PCEPoQ session characteristics. The following two state variables are defined: RemoteOK: a boolean that is set to 1 if the system has received an acceptable PCEPoQ Open message. LocalOK: a boolean that is set to 1 if the system has received a PCEPoQ Keepalive message acknowledging that the PCEPoQ Open message sent to the peer was valid. Idle State: The idle state is the initial PCEPoQ state where the PCEPoQ (also referred to as "the system") waits for an initialization event that can either be manually triggered by the user (configuration) or automatically triggered by various events. In Idle state, PCEPoQ resources are allocated (memory, potential process, etc.) but no PCEPoQ messages are accepted from any PCEPoQ peer. The following set of variables are initialized: QUICRetry=0, LocalOK=0, RemoteOK=0, OpenRetry=0. Upon detection of a local initialization event (e.g., user configuration to establish a PCEPoQ session with a particular PCEPoQ peer, local event triggering the establishment of a PCEPoQ session with a PCEPoQ peer such as the automatic detection of a PCEPoQ peer), the system: o Initiates a QUIC connection, o Starts the Connect timer, Yang, et al. Expires March 25, 2025 [Page 9] Internet-Draft PCEP over QUIC September 2024 o Moves to the Pending state. Upon receiving a PCEPoQ QUIC connection establishment succeeds, the system: o Creates an PCEPoQ control channel, o Sends an PCEPoQ Open message, o Starts the OpenWait timer, o Moves to the OpenWait state. If the QUIC connection establishment fails, the system remains in the Idle state. Any other event received in the Idle state is ignored. It is expected that an implementation will use an exponentially increasing timer between automatically generated Initialization events and between retries of PCEPoQ QUIC connection establishment. Pending State: If the PCEPoQ connection establishment succeeds, the system: o Createss an PCEPoQ control channel, o Sends an PCEPoQ Open message, o Starts the OpenWait timer, o Moves to the OpenWait state. If the PCEPoQ QUIC connection establishment fails or the Connect timer expires: o If ConnectRetry = ConnectMaxRetry, the system moves to the Idle State. o If ConnectRetry < ConnectMaxRetry, the system: 1. Initiates of a PCEPoQ QUIC connection, 2. Increments the ConnectRetry variable, 3. Restarts the Connect timer, 4. Stays in the Pending state. Yang, et al. Expires March 25, 2025 [Page 10] Internet-Draft PCEP over QUIC September 2024 In response to any other event, the system releases the PCEPoQ resources for that peer and moves back to the Idle state. OpenWait State: In the OpenWait state, the system waits for an PCEPoQ Open message from its PCEPoQ peer. If the system receives an PCEPoQ Open message from the PCEPoQ peer before the expiration of the OpenWait timer, the system first examines all of its sessions that are in the OpenWait or KeepWait state. If another session with the same PCEPoQ peer already exists (same IP address), then the system performs the following collision- resolution procedure: o If the system has initiated the current session and it has a lower IP address than the PCEPoQ peer, the system closes the PCEPoQ control channel, releases the PCEPoQ resources for the pending session, and moves back to the Idle state. o If the session was initiated by the PCEPoQ peer and the system has a higher IP address that the PCEPoQ peer, the system closes the PCEPoQ control channel, releases the PCEPoQ resources for the pending session, and moves back to the Idle state. o Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, etc.). If an error is detected (e.g., malformed Open message, reception of a message that is not an PCEPoQ Open message, presence of two OPEN objects), PCEPoQ generates an error notification, the PCEPoQ peer sends a PCEoQErr message with Error-Type=1 and Error-value=1. The system releases the PCEPoQ resources for the PCEPoQ peer, closes the PCEPoQ control channel and data channel, and moves to the Idle state. If no errors are detected, OpenRetry=1, and the session characteristics are unacceptable, the PCEPoQ peer sends a PCEPoQErr with Error-Type=1 and Error-value=5, and the system releases the PCEPoQ resources for that peer and moves back to the Idle state. If no errors are detected, and the session characteristics are acceptable to the local system, the system: o Sends a Keepalive message to the PCEP peer, o Starts the Keepalive timer, o Sets the RemoteOK variable to 1. Yang, et al. Expires March 25, 2025 [Page 11] Internet-Draft PCEP over QUIC September 2024 If LocalOK=1, the system clears the OpenWait timer and moves to the UP state. If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state. If no errors are detected, but the session characteristics are unacceptable and non-negotiable, the PCEPoQ peer sends a PCEPoQErr with Error-Type=1 and Error-value=3, and the system releases the PCEPoQ resources for that peer and moves back to the Idle state. If no errors are detected, and OpenRetry is 0, and the session characteristics are unacceptable but negotiable (such as, the Keepalive period or the DeadTimer), then the system: o Increments the OpenRetry variable, o Sends a PCEPoQErr message with Error-Type=1 and Error-value=4 that contains proposed acceptable session characteristics, o If LocalOK=1, the system restarts the OpenWait timer and stays in the OpenWait state. o If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state. If no Open message is received before the expiration of the OpenWait timer, the PCEPoQ peer sends a PCEPoQErr message with Error-Type=1 and Error-value=2, the system releases the PCEPoQ resources for the PCEPoQ peer, closes the control channel and data channel, and moves to the Idle state. In response to any other event, the system releases the PCEPoQ resources for that peer and moves back to the Idle state. KeepWait State: In the Keepwait state, the system waits for the receipt of a Keepalive from its PCEPoQ peer acknowledging its PCEPoQ Open message or a PCEPoQErr message in response to unacceptable PCEPoQ session characteristics proposed in the PCEPoQ Open message. If an error is detected (e.g., malformed PCEPoQ Keepalive message), PCEPoQ generates an error notification, the PCEPoQ peer sends a PCEPoQErr message with Error-Type=1 and Error-value=1. The system releases the PCEPoQ resources for the PCEPoQ peer, closes the PCEPoQ control channel and data channel, and moves to the Idle state. If a PCEPoQ Keepalive message is received before the expiration of the KeepWait timer, then the system sets LocalOK=1 and: Yang, et al. Expires March 25, 2025 [Page 12] Internet-Draft PCEP over QUIC September 2024 o If RemoteOK=1, the system clears the KeepWait timer and moves to the UP state. Creates data channel for the PCEPoQ peer. o If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait State. If a PCEPoQErr message is received before the expiration of the KeepWait timer: 1. If the proposed values are unacceptable, the PCEPoQ peer sends a PCEPoQErr message with Error-Type=1 and Error-value=6, and the system releases the PCEPoQ resources for that PCEP peer, closes the control channel and data channel, and moves to the Idle state. 2. If the proposed values are acceptable, the system adjusts its PCEPoQ session characteristics according to the proposed values received in the PCEPoQErr message, restarts the KeepWait timer, and sends a new PCEPoQ Open message. If RemoteOK=1, the system restarts the KeepWait timer and stays in the KeepWait state. If RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait state. If neither a PCEPoQ Keepalive nor a PCEPoQErr is received after the expiration of the KeepWait timer, the PCEPoQ peer sends a PCEPoQErr message with Error-Type=1 and Error-value=7, and the system releases the PCEPoQ resources for that PCEPoQ peer, closes the control channel and data channel connection, and moves to the Idle State. In response to any other event, the system releases the PCEPoQ resources for that peer and moves back to the Idle state. UP State: In the UP state, the PCEP peer starts exchanging PCEPoQ messages according to the session characteristics. PCEPoQReq and PCEPoQRep are send through data channel, other messages are send through control channel. If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message. If no PCEPoQ message (PCEPoQ Keepalive, PCEPoQReq, PCEPoQRep, PCEPoQNtf) is received from the PCEPoQ peer before the expiration of the DeadTimer, the system terminates the PCEPoQ session according to the procedure, releases the PCEPoQ resources for that PCEPoQ peer, closes the PCEPoQ control channel and PCEPoQ data channel, and moves to the Idle State. Yang, et al. Expires March 25, 2025 [Page 13] Internet-Draft PCEP over QUIC September 2024 If a malformed message is received, the system terminates the PCEPoQ session, releases the PCEPoQ resources for that PCEPoQ peer, closes the PCEPoQ control channel and data channel and moves to the Idle State. 5. Stream multiplexing QUIC offers stream multiplexing but does not provide a mechanism for exchanging stream priority information. Instead, it relies on receiving priority information from the application. PCEPoQ separates streams into control and data channels, assigning different priorities to each, ensuring that control messages receive higher priority processing. 6. Network migration QUIC connections are not strictly bound to a single network path. Connection migration uses connection identifiers to allow connections to transfer to a new network path. In the current version of QUIC, only clients can migrate. The PCEPoQ protocol inherits this feature, allowing PCC over QUIC to conduct network migration. PCE over QUIC should not identify PCC over QUIC by network address but rather use connection identifiers to recognize different PCC over QUIC instances. 7. Flow Control QUIC's flow control mechanism manages individual streams as well as the entire connection. A QUIC receiver controls the maximum amount of data a sender can transmit on any single stream and across all streams at any given time. PCEPoQ utilizes QUIC's flow control mechanism, separating control streams from data streams by using a control channel and a data channel. 8. Security Considerations Security considerations for the QUIC protocol are described in the corresponding section in [RFC9000]. Security considerations for the TLS handshake used to secure QUIC are described in [RFC9001]. 9. IANA Considerations 9.1. UDP Port for PCEPoQ IANA is requested to assign a UDP port (TBD1) from the "Service Name and Transport Protocol Port Number Registry" as follows: Yang, et al. Expires March 25, 2025 [Page 14] Internet-Draft PCEP over QUIC September 2024 +---------------------------+----------------+ | Service Name | PCEPoQ | +---------------------------+----------------+ | Port Number | TBD1 | +---------------------------+----------------+ | Transport Protocol | udp | +---------------------------+----------------+ | Description | PCEP over QUIC | +---------------------------+----------------+ 9.2. Registration of the PCEP Identification String This document creates a new registration for the identification of PCEP in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry. The "pcepoq" string identifies PCEP over QUIC: protocol: PCEP over QUIC Identification Sequence: "pcepoq" Specification: This document 9.3. PCEPoQ Capability TLV IANA is asked to assign a new TLV code from PCEP TLV Type Indicators [RFC5440] for the PCEP over QUIC Capability as follows: +-------------------+-------------------+ | Value | TBD2 | +-------------------+-------------------+ | Description | PCEPoQ Capability | +-------------------+-------------------+ | Reference | [This Document] | +-------------------+-------------------+ | Change Controller | IETF | +-------------------+-------------------+ PCEPoQ Capability Registration Yang, et al. Expires March 25, 2025 [Page 15] Internet-Draft PCEP over QUIC September 2024 Capability: D: Bit 0, support data channel, this document 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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . 10.2. Informative References [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . Yang, et al. Expires March 25, 2025 [Page 16] Internet-Draft PCEP over QUIC September 2024 Authors' Addresses Feng Yang China Mobile Beijing China Email: yangfeng@chinamobile.com Changwang Lin New H3C Technologies Beijing China Email: linchangwang.04414@h3c.com Tingting Han China Mobile Beijing China Email: hantingting@chinamobile.com Yang, et al. Expires March 25, 2025 [Page 17]