| Internet-Draft | Quantum FWM Control Protocol | October 2025 |
| Zhu, et al. | Expires 4 April 2026 | [Page] |
This document specifies the Quantum Four-Wave Mixing Control Protocol (QFCP), a lightweight transport protocol designed to operate over UDP in IP optical environments. QFCP enables the transmission of control- plane parameters required for quantum four-wave mixing (FWM) processes and associated optical configurations, including polarization stabilization, timestamp alignment, ROADM port selection, and spectral parameters. The protocol uses a Type-Length-Value (TLV) structure to support versioning and extensibility. This work is motivated by recent demonstrations of a classical-decisive quantum internet using integrated photonics.¶
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 4 April 2026.¶
Copyright (c) 2025 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 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Hybrid quantum-classical networking is emerging as a foundation for distributed quantum information processing. Recent experiments on commercial fiber networks have shown that quantum states can be dynamically routed by classical headers embedded in IP-like packets. To configure downstream optical switches and mitigate errors, a lightweight, extensible protocol is needed. QFCP is intended to be that protocol, running over UDP [RFC768] and supporting modular Type-Length-Value (TLV) extensions. QFCP supports applications aligned with scenarios defined by the IRTF Quantum Internet Research Group (QIRG) [RFC9583].¶
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.¶
QFCP defines a fixed header followed by TLV-encoded fields. The header carries version and flag information; TLVs encode control-plane parameters such as quantum link layer protocol, polarization state, center frequency, or error-mitigation metadata. UDP provides transport simplicity and compatibility with existing IP infrastructure. Unknown TLVs MUST be ignored to ensure forward compatibility.¶
The QFCP packet consists of a fixed header followed by a sequence of Type-Length-Value (TLV) payloads.¶
Packet Format:¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLV Payloads ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each TLV consists of a type, a reserved field, a length (in bytes), and a value. All fields are in network byte order.¶
TLV Format:¶
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 | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Defined TLV Types:¶
Type Name Value Format ---- ------------------------- ------------------------------ 0x01 Quantum Protocol 32-bit float (e.g., encoding) 0x02 Polarization State 32-bit float 0x03 Local Timestamp 32-bit int (ns) 0x04 ROADM Output Port ID 32-bit int 0x05 Photon Arrival Timestamp 32-bit int (ns) 0x06 Center Frequency (GHz) 32-bit float 0x07 Optical Linewidth (GHz) 32-bit float 0x08 Error Mitigation Vector Variable (SU(2) parameters) 0x09 Future Extension TLV-defined
This section illustrates how the Quantum FWM Control Protocol (QFCP) can be applied in practical network environments.¶
QFCP packets carrying TLVs for ROADM Output Port ID ([RFC4950]) allow classical headers to steer entangled photons through commercial reconfigurable optical add-drop multiplexers (ROADMs). This enables dynamic path selection across metro and campus-scale optical networks, as demonstrated in recent hybrid IP packet experiments ([Zhang2025]).¶
TLVs containing polarization parameters and error-mitigation vectors (Type 0x08) allow active compensation of SU(2) rotations induced by deployed fiber ([ZhangSM2025]). Classical light encodes detection signals in the header, enabling dynamic updates to the error mitigator without disturbing quantum states.¶
The QFCP framework aligns with the IRTF QIRG goals and use-cases ([RFC9583]). By transporting control-plane metadata in TLVs, classical headers and quantum payloads can be synchronized and routed through existing IP infrastructure.¶
TLVs carrying local and photon arrival timestamps can provide synchronization similar to RTP ([RFC3550]). This enables sub-nanosecond correlation of entangled photon arrivals across nodes.¶
Additional TLVs may specify per-wavelength parameters, enabling wavelength-division multiplexing (WDM) or time-division multiplexing (TDM) of entangled states ([ZhangSM2025]). This supports scaling of quantum internet bandwidth across multiple frequency channels while preserving compatibility with ITU-T DWDM grids ([ITU-T.G694.1]).¶
Implementations SHOULD use a configurable default port. IANA is requested to allocate a well-known port for QFCP.¶
- Allocate a UDP port for QFCP.¶
- IANA is also requested to establish a QFCP TLV Types Registry with initial assignments as defined in Section 4.¶
QFCP inherits the risks of UDP: spoofing, injection, replay. It MUST be run in trusted environments or protected by DTLS/IPsec. TLVs may reveal network state information and SHOULD be protected if confidentiality is required.¶