<?xml version="1.0" encoding="utf-8"?>
<!-- 
     draft-rfcxml-general-template-standard-00
  
     This template includes examples of the most commonly used features of RFCXML with comments 
     explaining how to customise them. This template can be quickly turned into an I-D by editing 
     the examples provided. Look for [REPLACE], [REPLACE/DELETE], [CHECK] and edit accordingly.
     Note - 'DELETE' means delete the element or attribute, not just the contents.
     
     Documentation is at https://authors.ietf.org/en/templates-and-schemas
-->
<?xml-model href="rfc7991bis.rnc"?>  <!-- Required for schema validation and schema-aware editing -->
<!-- <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> -->
<!-- This third-party XSLT can be enabled for direct transformations in XML processors, including most browsers -->


<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<!-- If further character entities are required then they should be added to the DOCTYPE above.
     Use of an external entity file is not recommended. -->

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="exp"
  docName="draft-zhu-qirg-qfcp-00"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">
<!-- [REPLACE] 
       * docName with name of your draft
     [CHECK] 
       * category should be one of std, bcp, info, exp, historic
       * ipr should be one of trust200902, noModificationTrust200902, noDerivativesTrust200902, pre5378Trust200902
       * updates can be an RFC number as NNNN
       * obsoletes can be an RFC number as NNNN 
-->

  <front>
    <title abbrev="Quantum FWM Control Protocol">Quantum FWM Control Protocol (QFCP) for IP Optical Environments</title>
    <!--  [REPLACE/DELETE] abbrev. The abbreviated title is required if the full title is longer than 39 characters -->

    <seriesInfo name="QFCP" value="draft-zhu-qirg-qfcp-00"/>
   
    <author fullname="Alan Zhu" initials="A" surname="Zhu">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
    <!-- all of the following elements are optional -->
      <organization>
        University of Pennsylvania
        School of Engineering and Applied Science
      </organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19104</code>
          <country>United States</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>alzhu@seas.upenn.edu</email>  
      </address>
    </author>
    <author fullname="Yichi Zhang" initials="Y" surname="Zhang">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
    <!-- all of the following elements are optional -->
      <organization>
        University of Pennsylvania
        School of Engineering and Applied Science
      </organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19104</code>
          <country>United States</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>zyc@seas.upenn.edu</email>  
      </address>
    </author>
    <author fullname="Robert Broberg" initials="R" surname="Broberg">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
    <!-- all of the following elements are optional -->
      <organization>
        University of Pennsylvania
        School of Engineering and Applied Science
      </organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19104</code>
          <country>United States</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>rbroberg@seas.upenn.edu</email>  
      </address>
    </author>
    <author fullname="Liang Feng" initials="L" surname="Feng">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
    <!-- all of the following elements are optional -->
      <organization>
        University of Pennsylvania
        School of Engineering and Applied Science
      </organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19104</code>
          <country>United States</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>fenglia@seas.upenn.edu</email>  
      </address>
    </author>
    <author fullname="Jonathan M. Smith" initials="JM" surname="Smith">
      <!-- [CHECK]
             * initials should not include an initial for the surname
             * role="editor" is optional -->
    <!-- Can have more than one author -->
    <!-- all of the following elements are optional -->
      <organization>
        University of Pennsylvania
        School of Engineering and Applied Science
      </organization>
      <address>
        <postal>
          <!-- Reorder these if your country does things differently -->
          <city>Philadelphia</city>
          <region>PA</region>
          <code>19104</code>
          <country>United States</country>
          <!-- Uses two letter country code -->
        </postal>        
        <email>jms@seas.upenn.edu</email>  
      </address>
    </author>
   
    <date year="2025"/>
    <!-- On draft subbmission:
         * If only the current year is specified, the current day and month will be used.
         * If the month and year are both specified and are the current ones, the current day will
           be used
         * If the year is not the current one, it is necessary to specify at least a month and day="1" will be used.
    -->

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <!-- "Internet Engineering Task Force" is fine for individual submissions.  If this element is 
          not present, the default is "Network Working Group", which is used by the RFC Editor as 
          a nod to the history of the RFC Series. -->

    <keyword>Quantum Internet</keyword>
    <keyword>Quantum FWM</keyword>
    <keyword>Quantum Communication</keyword>
    <!-- [REPLACE/DELETE]. Multiple allowed.  Keywords are incorporated into HTML output files for 
         use by search engines. -->

    <abstract>
      <t>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.
        </t>
    </abstract>
 
  </front>

  <middle>
    
    <section>
      <name>Introduction</name>
      <t>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 <xref target="RFC768"/> and supporting modular Type-Length-Value
   (TLV) extensions. QFCP supports applications aligned with scenarios
   defined by the IRTF Quantum Internet Research Group
   (QIRG) <xref target="RFC9583"/>.</t>
      
      <section>
        <name>Requirements Language</name>
        <t>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 <xref target="RFC2119"/>
          <xref target="RFC8174"/> when, and only when, they appear in
          all capitals, as shown here.</t>
      </section>
      <!-- [CHECK] The 'Requirements Language' section is optional -->

    </section>
    
    <section anchor="overview" numbered="true">
  <name>Protocol Overview</name>
  <t>
    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.
  </t>
</section>

<section anchor="packet-format" numbered="true">
  <name>QFCP Packet Format</name>
  <t>
    The QFCP packet consists of a fixed header followed by a sequence
    of Type-Length-Value (TLV) payloads.
  </t>
  <t>Packet Format:</t>
  <figure>
    <name>QFCP Packet Header and TLV Payloads</name>
    <artwork><![CDATA[
 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                         ~
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
  </figure>
  <ul>
    <li>Version (4 bits): Protocol version number (currently 0x1).</li>
    <li>Flags (4 bits): Reserved for future use.</li>
    <li>Reserved (24 bits): Set to zero; ignored on receipt.</li>
    <li>TLV Payloads: Sequence of variable-length TLVs.</li>
  </ul>
</section>

<section anchor="tlv-structures" numbered="true">
  <name>TLV Structures</name>
  <t>
    Each TLV consists of a type, a reserved field, a length (in bytes),
    and a value. All fields are in network byte order.
  </t>
  <t>TLV Format:</t>
  <figure>
    <name>TLV Format</name>
    <artwork><![CDATA[
  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)                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
  </figure>
  <t>Defined TLV Types:</t>
  <figure>
    <name>Initial TLV Type Assignments</name>
    <artwork><![CDATA[
 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
]]></artwork>
  </figure>
</section>

<section anchor="use-cases" numbered="true">
  <name>Example Use Cases</name>
  <t>
    This section illustrates how the Quantum FWM Control Protocol (QFCP)
    can be applied in practical network environments.
  </t>

  <section anchor="uc-roadm" numbered="true">
    <name>Dynamic ROADM Configuration</name>
    <t>
      QFCP packets carrying TLVs for ROADM Output Port ID
      (<xref target="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
      (<xref target="Zhang2025"/>).
    </t>
  </section>

  <section anchor="uc-mitigation" numbered="true">
    <name>Real-Time Error Mitigation</name>
    <t>
      TLVs containing polarization parameters and error-mitigation vectors
      (Type 0x08) allow active compensation of SU(2) rotations induced by
      deployed fiber (<xref target="ZhangSM2025"/>). Classical light encodes
      detection signals in the header, enabling dynamic updates to the error
      mitigator without disturbing quantum states.
    </t>
  </section>

  <section anchor="uc-orchestration" numbered="true">
    <name>Hybrid IP Packet Orchestration</name>
    <t>
      The QFCP framework aligns with the IRTF QIRG goals and use-cases
      (<xref target="RFC9583"/>). By transporting control-plane
      metadata in TLVs, classical headers and quantum payloads can be
      synchronized and routed through existing IP infrastructure.
    </t>
  </section>

  <section anchor="uc-timestamp" numbered="true">
    <name>Timestamp Alignment</name>
    <t>
      TLVs carrying local and photon arrival timestamps can provide
      synchronization similar to RTP (<xref target="RFC3550"/>). This enables
      sub-nanosecond correlation of entangled photon arrivals across nodes.
    </t>
  </section>

  <section anchor="uc-wdm-tdm" numbered="true">
    <name>WDM/TDM Extensions</name>
    <t>
      Additional TLVs may specify per-wavelength parameters, enabling
      wavelength-division multiplexing (WDM) or time-division multiplexing (TDM)
      of entangled states (<xref target="ZhangSM2025"/>). This supports scaling
      of quantum internet bandwidth across multiple frequency channels while
      preserving compatibility with ITU-T DWDM grids (<xref target="ITU-T.G694.1"/>).
    </t>
  </section>
</section>

<section anchor="udp-port" numbered="true">
  <name>UDP Port Assignment</name>
  <t>
    Implementations SHOULD use a configurable default port. IANA is requested
    to allocate a well-known port for QFCP.
  </t>
</section>
  
    
    <section anchor="IANA">
    <!-- All drafts are required to have an IANA considerations section. See RFC 8126 for a guide.-->
      <name>IANA Considerations</name>
      <t>
      - Allocate a UDP port for QFCP.</t>
      <t>
        - IANA is also requested to establish a QFCP TLV Types Registry with
        initial assignments as defined in Section 4.</t>
    </section>
    
    <section anchor="Security">
      <!-- All drafts are required to have a security considerations section. See RFC 3552 for a guide. -->
      <name>Security Considerations</name>
      <t>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.</t>
    </section>
    
    <!-- NOTE: The Acknowledgements and Contributors sections are at the end of this template -->
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.768.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4950.xml"/>
        
        <!-- The recommended and simplest way to include a well known reference -->
        
      </references>
 
      <references>
        <name>Informative References</name>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9583.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml"/>

        <reference anchor="ITU-T.G694.1" target="https://www.itu.int/rec/T-REC-G.694.1/en">
            <front>
                <title>Spectral grids for WDM applications: DWDM frequency grid</title>
                <author>
                <organization>International Telecommunication Union (ITU-T)</organization>
                </author>
                <date month="February" year="2012"/>
            </front>
            <seriesInfo name="Recommendation" value="G.694.1"/>
            </reference>

        <reference anchor="Zhang2025" target="https://doi.org/10.1126/science.adx6176">
            <front>
                <title>Classical-decisive quantum internet by integrated photonics</title>
                <author initials="Y." surname="Zhang"/>
                <author initials="R." surname="Broberg"/>
                <author initials="A." surname="Zhu"/>
                <author initials="G." surname="Li"/>
                <author initials="L." surname="Ge"/>
                <author initials="J.M." surname="Smith"/>
                <author initials="L." surname="Feng"/>
                <date month="August" year="2025"/>
            </front>
            <seriesInfo name="Science" value="Vol. 389, pp. 940-944"/>
            <refcontent>DOI: 10.1126/science.adx6176</refcontent>
            </reference>

        <reference anchor="ZhangSM2025">
            <front>
                <title>Supplementary Materials for Classical-decisive quantum internet by integrated photonics</title>
                <author initials="Y." surname="Zhang"/>
                <author initials="R." surname="Broberg"/>
                <author initials="A." surname="Zhu"/>
                <author initials="G." surname="Li"/>
                <author initials="L." surname="Ge"/>
                <author initials="J.M." surname="Smith"/>
                <author initials="L." surname="Feng"/>
                <date month="August" year="2025"/>
            </front>
            <seriesInfo name="Science" value="Supplementary Materials"/>
            </reference>


      
       
      </references>
    </references>
    
 </back>
</rfc>

