PCEP over QUIC
draft-yang-pce-pcep-over-quic-01
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-10-21 | ||
| 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-01
PCEP F. Yang
Internet-Draft China Mobile
Intended status: Standards Track C. Lin
Expires: 25 March 2025 New H3C Technologies
T. Han
China Mobile
October 21, 2024
PCEP over QUIC
draft-yang-pce-pcep-over-quic-01
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 April 21, 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
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Yang, et al. Expires April 25, 2025 [Page 1]
Internet-Draft PCEP over QUIC October 2024
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
1. Introduction...................................................2
1.1. Requirements Language.....................................3
2. Terminology....................................................3
3. Summary of Operations..........................................3
3.1. Establish PCEP/QUIC Connection............................3
3.2. Establish PCEP/QUIC Control Channel.......................4
3.3. Establish PCEP/QUIC data Channel..........................4
4. Protocol Definitions...........................................4
4.1. PCEP Over QUIC Capability.................................4
4.2. Maintenance of control channel............................5
4.3. PCEPoQ Connection Termination.............................6
4.4. PCEPoQ Framing Layer......................................6
4.5. Path Computation Request and Reply........................8
5. PCEPoQ Finite State Machine (FSM)..............................8
6. Stream multiplexing...........................................16
7. Network Migration.............................................16
8. Flow Control..................................................17
9. Security Considerations.......................................17
10. IANA Considerations..........................................17
10.1. UDP Port for PCEPoQ.....................................17
10.2. Registration of the PCEP Identification String..........17
10.3. PCEPoQ Capability TLV...................................18
11. References...................................................18
11.1. Normative References....................................18
11.2. Informative References..................................18
Authors' Addresses...............................................19
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:
Yang, et al. Expires April 28, 2025 [Page 2]
Internet-Draft PCEP over QUIC October 2024
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.
3. Summary of Operations
3.1. Establish PCEP/QUIC Connection
The process of establishing a PCEP session is described in
[RFC5440].
Before two PCEPoQ speakers start exchanging routing information,
they must establish a PCEP session. It is established in two
phases:
First, a QUIC connection is established at the transport layer as
described in [RFC9000]. 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.
Yang, et al. Expires April 28, 2025 [Page 3]
Internet-Draft PCEP over QUIC October 2024
Second, Establish a PCEPoQ session over this transport connection.
PCC over QUIC acts as the QUIC client, and PCE over QUIC serves as
the QUIC server.
3.2. Establish PCEP/QUIC Control Channel
After PCEPoQ session established, 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. OPEN messages are used to establish the
PCEPoQ control channel. After the channel is established, KeepAlive
messages are sent to maintain the control channel. Close messages
are used to terminate the control channel. Notify messages are used
to send specified notifications. When an error occurs, a PCEErr
message is sent through the PCEPoQ control channel to notify the
PCEPoQ peer.
3.3. Establish PCEP/QUIC data Channel
After establishing the control channel, each PCEPoQ speaker may
create data channels using unidirectional QUIC streams. These data
channels are used to carry PCEReq and PCERep 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.
4. Protocol Definitions
4.1. PCEP Over QUIC Capability
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
carried within 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
Yang, et al. Expires April 28, 2025 [Page 4]
Internet-Draft PCEP over QUIC October 2024
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 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.
4.2. Maintenance of control channel
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 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.
The 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 control 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
Yang, et al. Expires April 28, 2025 [Page 5]
Internet-Draft PCEP over QUIC October 2024
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.
4.3. PCEPoQ Connection Termination
When one of the PCEP over QUIC peers wishes to terminate a PCEPoQ
session, it first sends a 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 sessions, 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.
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).
This message is transmitted through the PCEPoQ control channel.
4.4. PCEPoQ Framing Layer
Some PCEPoQ messages, although sent in the control channel, are
meant for a function channel, such as the responding OPEN message or
KEEPALIVE message for a function channel. These messages need to
carry the corresponding function channel/stream ID information.
There are two types of PCEPoQ Frames: Control Data and Data.
Data frames have the following format:
PCEPoQ Data Frame Format {
Type (16) = 0,
Yang, et al. Expires April 28, 2025 [Page 6]
Internet-Draft PCEP over QUIC October 2024
Length (16),
Frame Payload (...)
}
PCEPoQ Control Data Frame Format {
Type (16) = 1,
Length (16),
Stream ID (62),
padding (2) = 0,
Frame Payload (...)
}
Type: two octets, identifying the frame type.
Length: The two-byte unsigned integer that describes the length in
bytes of the frame payload.
Stream ID: A 62-bit integer indicating the receiving stream ID of
this message.
Frame Payload: PCEP messages.
The following table lists the frame type to be used when BGP
messages are sent in different channels.
Yang, et al. Expires April 28, 2025 [Page 7]
Internet-Draft PCEP over QUIC October 2024
+===============+=================+=====================+
| | Control Channel | Function Channel |
+===============+=================+=====================+
| OPEN | Control | Data |
+---------------+-----------------+---------------------+
| KEEPALIVE | Control | Data |
+---------------+-----------------+---------------------+
| NOTIFICATION | Control | Data |
+---------------+-----------------+---------------------+
| PCErr | Control | Data |
+---------------+-----------------+---------------------+
| PCReq | / | Data |
+---------------+-----------------+---------------------+
| PCRep | / | Data |
+---------------+-----------------+---------------------+
| Close | Control | Data |
+---------------+-----------------+---------------------+
PCEPoQ Frame Type Mapping
4.5. Path Computation Request and Reply
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.
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.
5. 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:
Connection Maintenance: PCEP requires maintaining a TCP connection
and responding to changes in its state. In contrast, PCEPoQ
Yang, et al. Expires April 28, 2025 [Page 8]
Internet-Draft PCEP over QUIC October 2024
maintains a QUIC connection, which doesn't require responding to
state changes after it's established.
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.
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.
The new events about QUIC as followed:
o Event QUICConnection_Valid:
Definition: Event indicating the PCE reception of a QUIC
connection request from PCC with a valid source IP address, UDP
port, destination IP address, and UDP Port. The definition of
invalid source and invalid destination IP address is determined
by the implementation.
o Event QUIC_CR_Invalid:
Definition: Event indicating the PCE reception of a QUIC
connection request from PCC with either an invalid source address
or port number, or an invalid destination address or port number.
o Event QUIC_CR_Acked:
Definition: Event indicating the PCC request to establish a QUIC
connection to the PCE has been completed.
o Event QUICConnectionConfirmed:
Definition: Event indicating that PCE has received a
confirmation that the QUIC connection has been established by
the remote PCC.
o Event QUICConnectionFails:
Definition: Event indicating that the PCC/PCE has received a
QUIC connection failure notice. This event only applies to the
control channel.
o Event QUICStreamOpen:
Definition: Event indicating that the PCC/PCE request to
open a QUIC stream to the remote PCC/PCP has been completed.
Yang, et al. Expires April 28, 2025 [Page 9]
Internet-Draft PCEP over QUIC October 2024
o Event QUICStreamClose
Definition: Event indicating that the PCC/PCE has received a
QUIC stream close notice.
+-+-+-+-+-+-+<------+
+------| 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.
Yang, et al. Expires April 28, 2025 [Page 10]
Internet-Draft PCEP over QUIC October 2024
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 Open message from the PCEPoQ 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 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 Open message.
LocalOK: a boolean that is set to 1 if the system has received a
Keepalive message acknowledging that the PCEPoQ Open message sent to
the peer was valid.
Idle State:
The idle state is the initial 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.
Yang, et al. Expires April 28, 2025 [Page 11]
Internet-Draft PCEP over QUIC October 2024
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,
or receive event QUICConnection_Valid), the system:
o Initiates a QUIC connection,
o Starts the Connect timer,
o Moves to the Pending state.
Upon receiving a PCEPoQ QUIC connection establishment succeeds(Event
QUIC_CR_Acked by PCC and event QUICConnectionConfirmed by PCE), the
system:
o Creates an PCEPoQ control channel,
o Sends an Open message,
o Starts the OpenWait timer,
o Moves to the OpenWait state.
If the QUIC connection establishment fails(Event
QUICConnectionFails), 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(Event QUIC_CR_Acked
by PCC and event QUICConnectionConfirmed by PCE), the system:
o Createss an PCEPoQ control channel,
o Sends an Open message,
o Starts the OpenWait timer,
o Moves to the OpenWait state.
Yang, et al. Expires April 28, 2025 [Page 12]
Internet-Draft PCEP over QUIC October 2024
If the PCEPoQ QUIC connection establishment fails(Event
QUICConnectionFails) 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.
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 create data channel.
If receive QUICStreamOpen, Then the system waits for an Open message
from its PCEPoQ peer.
If the system receives an 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.).
Yang, et al. Expires April 28, 2025 [Page 13]
Internet-Draft PCEP over QUIC October 2024
If an error is detected (e.g., malformed Open message, reception of
a message that is not an 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 PCEPoQ peer,
o Starts the Keepalive timer,
o Sets the RemoteOK variable to 1.
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 PCErr 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 PCErr message with Error-Type=1 and
Yang, et al. Expires April 28, 2025 [Page 14]
Internet-Draft PCEP over QUIC October 2024
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 Open message or a
PCErr message in response to unacceptable PCEPoQ session
characteristics proposed in the Open message.
If an error is detected (e.g., malformed Keepalive message), PCEPoQ
generates an error notification, the PCEPoQ peer sends a PCErr
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 Keepalive message is received before the expiration of the
KeepWait timer, then the system sets LocalOK=1 and:
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 PCErr message is received before the expiration of the KeepWait
timer:
1. If the proposed values are unacceptable, the PCEPoQ peer sends a
PCErr 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 PCErr message, restarts the KeepWait timer, and
sends a new 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 Keepalive nor a PCErr is received after the expiration
of the KeepWait timer, the PCEPoQ peer sends a PCErr message with
Error-Type=1 and Error-value=7, and the system releases the PCEPoQ
Yang, et al. Expires April 28, 2025 [Page 15]
Internet-Draft PCEP over QUIC October 2024
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.
PCReq and PCRep 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 (Keepalive, PCReq, PCRep, PCNtf) 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.
If receive QUICStreamClose, Then the system moves to Idle State.
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.
6. 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.
7. 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
Yang, et al. Expires April 28, 2025 [Page 16]
Internet-Draft PCEP over QUIC October 2024
network address but rather use connection identifiers to recognize
different PCC over QUIC instances.
8. 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.
9. 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].
10. IANA Considerations
10.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:
+---------------------------+----------------+
| Service Name | PCEPoQ |
+---------------------------+----------------+
| Port Number | TBD1 |
+---------------------------+----------------+
| Transport Protocol | udp |
+---------------------------+----------------+
| Description | PCEP over QUIC |
+---------------------------+----------------+
10.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
Yang, et al. Expires April 28, 2025 [Page 17]
Internet-Draft PCEP over QUIC October 2024
10.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
Capability:
D: Bit 0, support data channel, this document
11. References
11.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>.
11.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 April 28, 2025 [Page 18]
Internet-Draft PCEP over QUIC October 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 April 28, 2025 [Page 19]