PCEP over QUIC
draft-yang-pce-pcep-over-quic-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Feng Yang , Changwang Lin , HAN TINGTING | ||
| Last updated | 2024-09-25 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yang-pce-pcep-over-quic-00
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, <https://www.rfc-
editor.org/rfc/rfc2119>.
[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>.
[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>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, DOI
10.17487/RFC9000, May 2021, <https://www.rfc-
editor.org/info/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/info/rfc9001>.
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, <https://www.rfc-editor.org/info/rfc7301>.
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]