1 Introduction↩︎

Packet routing in the emerging Quantum Internet can occur via quantum processes that are simply impossible on the Classical Internet. Foremost among these are quantum teleportation, and quantum routing - the quantum superposition of routes through the network.³ In this work, we introduce within the context of the Open Systems Interconnection (OSI) model [1], a modified Internet Protocol (IP) packet format that seamlessly allows quantum teleportation and quantum routing, as well as superpositions of both quantum processes.

The packet switching procedures that underpin routing in the Classical Internet were devised around the 1970’s. In search of a means to withstand significant interruptions in communication networks, packet switching without centralized control was proposed [2]. Subsequently, the Classical Internet was born and expanded to encompass the World Wide Web, a sophisticated communication system that went well beyond what anyone originally imagined. Routing through the IP remains a critical component of this Web [3].

As was the case for the Classical Internet, we predict that the Quantum Internet will evolve and lead to new communication scenarios that are not currently imagined. It is therefore important that the operational protocols that are being developed for this new Internet accommodate all possibilities allowed by quantum mechanics.

The question we attempt to answer here is simple. If we were to adopt a layered approach based on the OSI Internet design, what minimum additions would be required to accommodate quantum teleportation, quantum routing, and superpositions thereof? This is a pragmatic question faced by current network operators who wish to slowly migrate into quantum networking, whilst being backward compatible with their classical infrastructure. We answer our question by building on the spectacularly successful IP packet format used in classical networks, adopting as a starting point IPv6 [4].

2 Related Work↩︎

It is important to clarify that we do not claim that our approach is the optimal way forward for quantum packet routing. Indeed, counter arguments have been made as to why any traditional layered approach based on Classical Internet design should not be followed [5]–[9], durno1?. In [5], the issue of scalability was first raised as an argument against maintaining a layered approach for quantum networks. In [6], the notion of native quantum routing was introduced in which the packet header information becomes quantum, which, when coupled with an entanglement-defined controller, allows scalable quantum control operations [7]. In durno1?, a resource-centric task-based scheme was proposed where a node that initiates the service requirement creates a distributed workflow. The work of [8] drew attention to the global coordination required by a resource-centric scheme, which makes implementation challenging, and instead proposed a new architecture centered on packets with an in-band control containing the service information. In the architecture of [8], a pathway to scalability was offered - as the packet traverses the network, successive nodes construct local actions only. In [9], the notion of an entanglement-based switching fabric within a router was presented, leading to a hardware-agnostic solution.

Notwithstanding the above comments, other workers have considered a layered approach to quantum networking, [10]–[13] being among many notable examples. In [10], a new 4-layer quantum network stack was offered; while in [11] a system design was offered for a network of quantum repeaters within a layered approach. In [12], a link layer protocol for quantum networks was offered within a layered approach; and in [13] a quantum data plane protocol was proposed, providing a building block for a layered quantum network. Other works specifically focused on packet switching architectures within a layered approach [14]–[17]. In [14], a specific frame structure was offered, while in [15] Quantum Key Distribution (QKD) within a packet switching framework was studied. In [16], the concept of ‘quantum wrapper networking’ was introduced for control and management, with [17] providing an experimental demonstration of this concept. Some previous studies entirely focused on the management of the entanglement distribution, a critical feature of future quantum networks (but a feature not required for all communication scenarios). Rather than any discussion on interaction between other layers, many of these studies largely described the functionality of the link layer [18], [19].

However, none of the above-mentioned works focused on the quantum-based routing possibilities we consider here, especially within the context of IPv6. The architecture we propose is the first attempt to include quantum routing and superpositions of this process with other quantum processes within a layered approach.

Our study is timely: the experimental implementation of a quantum packet transfer based on the time synchronization of quantum and classical data (a model that we assume for direct transmissions) has recently been carried out [20]; and technical expositions of the quantum mechanics we utilize in our study are established, namely, quantum teleportation [21], [22], quantum routing [23]–[26] and superpositions of quantum processes in general [27]. The reader is referred directly to these references (and references therein) for technical details on the assumed quantum processes.

Although we will utilize IPv6 Extension Headers to invoke new routing layer features in the quantum domain, similar ideas have previously been utilized in the classical-only domain. A good example of this is the work of [28] in which the Extension Headers are used to enhance data sovereignty at the routing layer. Security issues raised by reading (and dropping) IPv6 Extension Headers are discussed in [29]. The reader is referred to [28], [29] for a more extensive explanation, than that offered here, of the structure and interplay between the Base Header and the Extension Headers within IPv6.

3 System Model↩︎

To provide clarity in our exposition, we will adopt the system model shown in Fig.1, where a satellite S1 sends a quantum state to a router (node) C on Earth, but is passed through routers A and B to reach C. We note S1 and S2 need not be satellites in general, and our system can readily be adapted to fiber only system, or terrestrial free space systems, or some combination thereof. However, space-based quantum communications are now a reality, and we anticipate such communications to play a pivotal role in the emerging Quantum Internet [30].

3.1 Assumptions↩︎

Our focus is on the IP header information used in the IP layer (also called the network layer or simply layer 3) in our quantum-enabled IP stack, shown in Fig.2.⁴ To simplify our exposition, the following assumptions are adopted in the system model.

1. Quantum memory is available on all routers. Incoming quantum information can be stored and retrieved locally.⁵ The router itself manages the details of the ingress/egress of information to/from quantum memory.

2. Quantum information is encoded in a single ‘pulse’ of light, which could be a Discrete Variable (DV) single photon state or a multi-photon Continuous Variable (CV) state. Classical information is also encoded in (separate) light pulses.⁶ In direct transmissions, pulses of classical and quantum information are scheduled to arrive in the required order, so a router knows which pulse to store in quantum memory and which pulse to read classically. More specifically, all information arrives at each router in sequence; classical header first, followed by payload (the quantum data). The combined classical and quantum information is called a quantum packet.⁷

3. For transmission via teleportation, an evolved version of the quantum state is transferred (teleported) via quantum measurements at the sender to a stored quantum state in the receiver’s memory, which is then manipulated at the receiver based on classical data transmitted by the sender. The classical data transmitted indicates which quantum state held by the receiver (the local memory address) is to be manipulated and how.⁸ In teleportation, the quantum data indicated in Fig.2 is replaced by the classical data required for the quantum state manipulation at the receiver.⁹

4. All classical communication is flawless. 5. A link layer protocol is in place and the link layer transfers quantum information via direct transmissions.¹⁰

6. A reliable entanglement distribution protocol is in place. We discuss this in more detail later.

3.2 IPv6 Headers↩︎

The IPv6 Base Header field is the first four rows of data shown in Fig.2. This data is non-optional; it is always present in an IPv6 packet. The Base Header is of length 40 octets, followed by the Extension Headers. The combined information in the Base and Extension Headers is followed by data in the form of an upper layer Protocol Data Unit (PDU). The PDU contains the upper-layer protocol header and its payload, which could be a Transmission Control Packet (TCP) or a User Datagram Protocol (UDP) packet. in IPv6, the Extension Headers plus the upper-layer PDU are considered to be the payload of the packet.

Most of the fields in the Base Header are self-evident (see [4] for details), and here we discuss only some of them. One field refers to a quality-of-service paradigm referred to as Differentiated Services, and for our purposes we will assume that all packets have the same service. The Flow field is important as this allows different packets to be assigned to the same ‘flow.’ This does not mean that IPv6 will force all packets in the same flow to pass through exactly the same path, but it allows processing such as re-sequencing. We will label all packets from a given source to a given destination with the same flow identifier. The Hop Limit field is always important in avoiding loops (see later discussion).

The ‘Next Header’ field (8 bits) in the Base Header indicates what happens next. If this points to a known protocol (such as 6 for TCP), the router knows that there are no Extension Headers to be read. If it points to a known (standardized) Extension Header field, the router knows it is to read that new header and act on it.

Given the assumptions embedded in our system model, an IPv6 header consisting only of a Base Header (but with quantum payload) should allow for a direct transfer of a quantum state through the network via a single path from the source to the destination with only the slightest modifications to the network. This raises the question; is there any circumstance that an IPv6 header containing only a Base Header could NOT easily accommodate the routing of quantum information? The answer to this question is clear: yes. The superposition of routing paths is one clear example.

That a photon can simultaneously be on two different paths brings a multitude of benefits that are not possible otherwise, including improved quantum information throughput [24], [33], two-way communication with a single particle [34], teleportation using separable states [27], accessing quantum information stored in superposition at different sites [35], and the in-principle ability to communicate over infinite length communication channels [36]. To access these non-intuitive quantum advantages within the IPv6 framework, we require new Extension Headers.¹¹

Extension Headers have a ‘Next Header’ field (8 bits), a ‘Header Extension Length’ field (8 bits), and then a field to contain data (variable length). This latter field contains different data depending on the specific Extension Header, but is related to information that allows specific instructions to be set (also called ‘Options’ in some headers). The structure of these data, and any padding, must be defined for each Extension Header, indicating the length of fields and the mapping of these fields to specific instructions. As noted above, the Extension Header configures its own Next Header field, and the chain continues until an Extension Header points to a known transport protocol like TCP or UDP.

Many Extension Headers in the classical-only domain have been standardized, despite being unused by many current routers [29]. These include the Hop-by-Hop Header (field value 0), and the Routing Header (field value 43) [39]. For this work, one of the most important headers is the Hop-by-Hop Extension Header. This header forces the instruction data to be read by every router on the path, and this can be useful in aiding the router to behave in a non-classical manner. This header uses Type–Length–value (TLV) coding to map the Option bits to specific instructions. The reader is referred to [4] for more details on Extension Header usage in the classical-only domain.

Some in the community consider IPv6 Extension Headers as the only ‘design flaw’ of the original IPv6 protocol. Initially intended as vehicles for additional functionality (that would be discovered by future research) without requiring the introduction of an entirely new protocol, 25 years of usage have shown Extension Headers to be largely of niche value. In fact, most routers on the Internet will simply ignore them. The situation has progressed to the point that in some online blogs, arguments for their deprecation are presented. However, here we argue for continued usage of the IPv6 Extension Headers in the context of hybrid classical-quantum networks. Through them, many quantum-only aspects of information transfer can be salvaged from a slightly modified IPv6-enabled network.

4 The Quantum Extension Headers↩︎

There is no definitive pathway to implement the effects of quantum mechanics within IPv6. One pathway would be to define new Option fields within the Hop-by-Hop Extension Header. This modified header would then need to be standardized by the Internet Engineering Task Force (IETF) and registered with the Internet Assigned Number Authority (IANA). Similarly, the current Routing Extension Header could be modified and standardized. We should warn the would-be designer; however, the sequential order of current Extension Headers must be enforced as per the standard [4]. Beyond this, completely new ‘Quantum Extension’ Headers could be proposed and standardized - and we follow this pathway here. These headers are to be all classical, with the quantum data communicated separately as previously outlined.

Our new headers would have a similar format to Extension Headers in the classical domain; the first field would be a Next Header (8 bits), with the second field being the Header Extension Length (8 bits). This would include the length of the Data field (variable length) and the number of pulses containing the quantum information so that a router knows when the current quantum packet ends. The Data field would be where the new data (the instruction set or a mapping to an instruction set) would be designed. This instruction set could inform the router to carry out specific instructions through software or inform the router to trigger some embedded hardware. In the following, we focus on the structure of this Data field, bearing in mind that this same structure could also be envisaged as new instruction sets within current Extension Headers.

In discussing new IPv6 Extension Headers for the quantum domain, we will provide some detailed specification for the first of these we specify, highlighting only the major conceptual issues in the others as we progress through the paper. Our aim here is to highlight the broad role new IPv6 Extension Headers may be able to play in the emerging Quantum Internet, and any specific formatting we provide is to be taken as suggestive rather than definitive. In this vein, we do not categorically state the size of any fixed length field, or the structure and form of the padding and coding used to specify instruction sets or Options. This level of detail will require wide-spread participation of the community followed by a rigorous standardization process.

It becomes a matter of design in how to best construct a new Extension Header for IPv6 that encompasses as much non-classical behavior as possible. In the following any field should not be used in a circumstance where it makes no sense (e.g., the time to send field in superpositions of quantum processes).

4.1 Quantum Routing↩︎

The order in which these new headers appear will be important. As we discuss later, the header that supports the superposition of paths in most circumstances should come before the header that supports teleportation. As such, we first discuss the former, referring to it as the ‘Quantum Routing’ Header. A suggested design for the Data field of this new header is shown in Fig. 3. We focus on the broad sub-fields that need defined, bearing in mind that the detailed structure and inclusion of any additional sub-fields are left to standardization submission stages. Note that there are countless scenarios that a quantum routing header must encompass. So, design of such a header requires a minimum set of base rules that supersede any setting of any field. The most important of these is that no action by any router on any path is to destroy any requested superposition of paths.¹² The suggested sub-fields are as follows.

Type (TY) Field: This field indicates the type of data in the quantum payload, DV (and its dimension), CV, or some hybrid combination. It can also stipulate whether the data are entangled or not (if known). We set the Type setting to the number one for a DV state of dimension two.¹³

Time to Send (TS) Field: A router uses this field to mark the time it received (X) and sent (Y) the quantum packet, plus an increment \(\delta\). A non-zero \(\delta\) indicates the time the next router should hold the quantum packet before sending. It is assumed that all routers on the network are synchronized with some global reference (time units picoseconds). The format shown in Fig.4 (a) is to be followed by the router sending the quantum packet. The specific values shown indicate that a current router received this packet at time X and sent the packet at time Y and expects that the next router will store the quantum information for 500 units of time before resending. All data by default in this field are initially set to -1,-1,-1, which means that a router does not act on the field (and is not updated). If it is to be used, the initial values should be set to \(t\), 0, \(\delta\), where \(t\) is the current time. By default \(\delta=0\) (the packet is to be sent as soon as possible).

Path List (PL) Field: This field lists all addresses where path splitting (superposition of paths) is to occur and then concatenates the next hop IP addresses. By default, it is set to zero and no splitting of paths is invoked. After splitting, all paths must be routed to the original destination IPv6 address. The format shown in Fig.4 (b) is to be followed for this process. This example would have a two-path splitting at the router …7334, with one path directed to router …7335 and the other path directed to router …7336. The format shown in Fig.4 (c) would have a four-path splitting at the router …7334, with the other two paths directed to router …7337 and the other additional path directed to router …7338. If the next hop router IP address has no listing in the local router table (or channel deemed invalid), the router itself is to pick the next hop IPv6 address - consistent with any constraint imposed by the routing algorithm (e.g. in a location-based algorithm the router is to pick the next router deemed closest to destination). Each router will be forced to inspect this PL field, which allows multiple splittings along the paths (even different types and numbers of splittings on the different paths).

Note that in the splitting of paths, the classical header field is to be copied into all paths and sent separately to the quantum payload. It is only the quantum payload that is to be placed into a superposition of paths. At each router, the classical header information is propagated to the IP layer and acted upon. The quantum payload is meanwhile stored in local memory at the router. This creates a superposition of quantum memories and therefore a mechanism for invoking QRAM.

Quantum Multicast (QM) Field: If this field is set to the address of some router (i.e non-zero), the quantum state is to be put into a superposition of all possible single-hop paths emanating from that router. We refer to this outcome as Quantum Multicast.¹⁴ The format shown in Fig.4 (d) is to be followed for this process. This specific setting would initiate a quantum multicast at router …7334 and also at router …7335. Again, all paths must lead to the original final destination. By default, the ingress path to a router is not to be included in the superposition (this is overridden by adding an asterisk at the end of an address). The initial Hop Limit field in the Base Header should be set with particular thought for this setting (noting that it is likely decremented to different values in different paths). This field supersedes the Path List field.

Quantum Multicast Switch (QMS) Field: By default, set to zero, but if set to 1, the Quantum Multicast field is ignored, and a quantum multicast is to take place at all routers on the paths. The final destination for all paths remains the original destination. The ingress path to a router is not included in the superposition. This field also supersedes the Path List field.

Change of Destination Address (CDA) Field: This indicates if a change of final destination is to occur and can be set on any router. By default, this is set to zero (indicating that the original destination address in the IPv6 header remains untouched). If not set to zero, the new destination address is listed in this field and is to be inserted into the IPv6 Header. This allows for the different paths to now have different destinations (i.e., have different header information).

The above fields accommodate most scenarios that could be envisaged for quantum routing.¹⁵ Given the flexibility offered by IPv6, additional fields could be added. However, it is also possible to create entirely separate Extension Headers that compliment the above functionality, adding them into processes at the router via the Next Header field. Of course, here it is assumed that the target router has the hardware functionality to invoke the required operations. Classical-only routers will not be affected by the passage of any Quantum Header as they will be pre-programmed to simply ignore these Extension Headers.

4.2 Teleportation↩︎

We now discuss the Quantum Header required for teleportation, which we refer to as the ‘Quantum Teleportation’ header. Quantum networks will depend at some level (i.e., not always) on the quantum entanglement distributed throughout the network. Many nodes will share entanglement, but every node will not share entanglement with every other node. This paradigm offers another quantum-only aspect of the network, teleportation. We delegate to the IP layer (or higher layers) decisions whether to teleport directly to nodes beyond the current one. The main reason for this is that, in general, requests for path superposition at certain nodes would need to take preference over teleportation direct to a receiving address. This is one reason why the Quantum Teleportation Header may need to be added to the Base IPv6 Header after the Quantum Routing Header.¹⁶ Note, in the following, we assume that the link layer can intelligently adopt to information in this new header and override previous settings to transmit directly to the next router on a physical path. ‘Point-to-point’ communication when teleportation is involved refers to communication via any viable quantum channel. Any required manipulation of entanglement may be made at other layers,¹⁷ but all routers will continuously update their routing tables, not only for classical communications as they currently do, but also for the availability of point-to-point quantum channels through teleportation.

A suggested format for this header is shown in Fig.5.

Again, we focus on the broad inputs that likely need to be defined.

The Teleportation (TEL) Field : The TEL field will have a fixed-bit number associated with it, allowing for mapping to a wide range of instruction sets. Most of these mappings are left open for future use, development, and standardization. However, we list a few sets of instructions that we believe will be of particular value and widely used. Note also that the Quantum Teleportation Header is copied and passed through all superpositions of paths (if any such paths are invoked by the Quantum Routing Header). The quantum state to be teleported is the state taken directly from memory. Recall that memory now may be entangled with other memory addresses across the network.¹⁸ A few specific settings of the TEL field are now described.

TEL=0 The default value is zero, which means that teleportation of the quantum state is to supersede all other instructions in the Quantum Routing Header if a ‘teleportation path’ exists through the network. The router is to take the sender-receiver IP addresses from the Base IPv6 header and then make its best effort to teleport the quantum state in the minimum number of teleportation steps. If no teleportation is available along the path (and cannot be made available), then the network is to use direct transmission, if available, as required.

TEL=1: This allows for specific teleportation transmissions rather than allowing the system to determine paths. For each pair of sender-receiver addresses input, the other layers again attempt to teleport in the minimum number of teleportation steps between those addressees. The pair of sender-receiver addresses to be input is provided in the header’s Sub Data field (defined below). This setting supersedes instructions in the Quantum Routing Header.

TEL=2: This is the same as stipulated above for the TEL=1 setting, but this time the information in the Quantum Routing Header will take precedence.

TEL=3: This forces the routers indicated to perform specific instructions regarding teleportation. Again, the instructions and routers requested to act are listed in the SD field. This generic setting allows for any possibility and is akin to a control message within an SDN type configuration. The information in the Data field can also request which information in different headers take precedence to each other, thereby offering a rich variation of possibilities.

Type (TY) Field: This field is the same as that in the router header.

Time to Send (TS) Field: This field is the same as that in the router header.

Sub Data (SD) Field: This is where additional information and instructions related to the other header types is to be located.

Regarding the update of quantum teleportation channels in routing tables, we expect a process similar to that described for location-based routing in [40]. This involves routers periodically announcing hello packets and constructing pathways based on these packets. Individual routers in the network will be pre-programmed as to whether they will or will not participate in this process. If they are part of the process, the individual router may also set the value of how often they will participate (setting the period of their announcements). Upon receiving a request for teleportation to a specific destination, the other layers may respond by performing a sequence of entanglement swaps to establish a direct channel. This process is managed according to the detailed entanglement distribution protocol adopted.

Routing via teleportation obviously represents one of the key new features that will make quantum networks truly distinct from their classical counterparts, and a feature that is likely to be widely utilized. In our process outlined, with the TEL field set to its default value, the network will make its best effort to transport the quantum state through the network using the minimum number of teleportation steps possible. It is possible that no teleportation steps are actually invoked (e.g., due to failures at the other layers in setting up teleportation channels) and direct transmission proceeds or some combination of direct transmission and teleportation occurs.

There are other quantum processes beyond quantum routing and teleportation that can also affect IP routing in the quantum context. One such process is the superposition of time orders (also commonly referred to as indefinite causal orders), whereby the temporal order of paths taken through a network is placed in superposition - a process known to enhance communication outcomes [41]. We will not detail the header format required to invoke such processes within the IPv6 Extension Header format - suffice to say that it will follow similar structures to those outlined for quantum teleportation, particularly in the use of an equivalent to the TEL=3 field.

Note that it is also the case that combinations of existing classical IPv6 Extension Headers can be layered with the Quantum Extension Headers to form more complex routing behavior. As mentioned earlier, an example of this would be the classical Hop-by-Hop Extension Header, a means of forcing every router on a path to inspect the IP header. If this were to be implemented, the strict ordering rules of the classical headers need to be enforced. It is also possible that the classical ICMP header within IPv6 could be used for additional control features that could assist in the implementation of the new quantum aspects of the network.

4.3 Superposition of Quantum Processes↩︎

It is now well established that the superposition of quantum processes can give rise to enhanced communication outcomes. This includes the superposition of quantum routing and quantum teleportation [27]. Let us consider how such a superposition of different quantum processes can be enacted within the IPv6 framework.

Given the flexibility already available through the Quantum Routing Header and the Quantum Teleportation Header (with the TEL=3 setting), a superposition of both quantum processes could be invoked using these new headers. One pathway for this would be to invoke new instructions set in the SDF of the Quantum Teleportation Header to instruct a particular router to trigger the hardware that places the routing request in the previous Extension Router Header into a superposition with information in the Quantum Teleportation Header fields.¹⁹ A schematic of such a process is shown in Fig.6.

However, as mentioned earlier, other quantum processes beyond quantum routing and teleportation can be envisaged, in which we may also like to form superpositions.²⁰. This suggests a better pathway would be the introduction of a ‘Quantum Superposition’ Extension Header. We will not delve into details of such a header field, suffice to say that it will have many of the usual fields such as length of data, but it will have a special ‘SUP’ field, which indicates the processes to be put into superposition. This header will also have its own SDF which stipulates any additional information needed that was not available from the fields set in each process, or required clarifications on how exactly the superposition is to proceed (e.g., where and when such superpositions are to occur). A new header is likely a better way to handle the superposition of the quantum processes, as it allows future outcomes motivated by future research to be readily integrated into the network.

5 Entanglement Distribution↩︎

We have left a substantial amount of ‘heavy lifting’ within our architecture to a presumed operational entanglement distribution process within the network, especially in regard to teleportation requests. As discussed earlier, many works have discussed how this may be handled directly via sophisticated link layer protocols, and these may indeed prove ultimately successful. However, in the spirit of the IP approach we have adopted here, we prefer to ascribe to the link layer protocol the same responsibility assumed in the OSI model (transmissions between two nodes). We will assume the link layer adopts direct transmission for the transfer of the quantum information, but do note that this is not an absolute. Teleportation at the link layer is also possible, but care must be taken in the release of the classical outcome of the required quantum measurements. Note that teleportation within path superpositions will be a superposition of quantum processes.

In some architectures for the Quantum Internet, the complex entanglement swapping, fidelity measurements, retransmission (if required), and entanglement distribution is assigned to processes occurring directly in the Application and/or Transport layers, perhaps coupled to a software defined networking (SDN) architecture. In this regard, we note the architecture proposed in [43] where satellites control the entanglement distribution on Earth directly from space. With quantum memory in place, we can envisage this type of architecture widely distributing entanglement to many pairs of ground stations, which can then re-distribute the entanglement via direct transmission to those stations fiber linked within \(\sim100\) km. In this architecture, the application layer requests a teleportation channel, and the network checks if available, and if not, creates, on-demand, the teleportation channel through direct transmission from space coupled with local direct transmissions.

6 Discussion↩︎

Our discussion above has developed a hybrid classical-quantum header for next-generation quantum networks. We have described how current IPv6 frameworks can encapsulate a surprisingly wide range of possible quantum processes of import at the IP layer. By slowly enhancing routers with the appropriate software and hardware, a pathway to the inclusion of quantum-only effects can be added to existing infrastructure. The architecture proposed is backward compatible with existing network hardware, as routers ill-equipped for quantum processing will simply ignore the Quantum Extension Headers.

We have not seriously considered the role to be played by a quantum software defined network (QSDN) arrangement [44]. Although complex, this form of quantum software-based solution leads in some circumstances to new network functionality over the use of hybrid classical-quantum headers discussed here. Given that QSDN could play a role in many functions, such as entanglement swapping, and QKD enhanced security; going forward we believe it possible that quantum networks may well operate based on some form of quantum enabled IPv6 Extension Headers and QSDN.

We note that it is also possible to have some header information in the form of quantum states [6]. This again would likely require the intervention of a QSDN to assist controlling information transfer as that quantum information could not be read by all routers on route.

Finally, beyond the many advantages to communication systems we have previously noted, the wider quantum-enabled functionality allowed by our proposed framework should allow for new or improved applications demonstrating a quantum advantage. We refer the reader to recent reviews that present many new applications for quantum networks that the framework presented here could potentially assist with[45]–[48]. We believe that these exciting new quantum-enabled networks will provide opportunities for scenarios and applications that have not yet been discovered.

7 Conclusion↩︎

The Global Quantum Internet is emerging, but much work is still required to finalize the rules and protocols for its operation. Many interesting works attempting to set these rules abound, ranging from traditional layered approaches, to radical new designs which completely abandon the architecture on which the Classical Internet is built. In this work, we highlighted how a wide range of quantum-only processes can be accommodated at the IP layer via some modifications to the IPv6 Extension Header model.

Our framework allows for future ‘simple’ functionality such as direct transfer of a quantum state, the teleportation of a quantum state, and the superposition of two routes. Beyond this, a plethora of complexity is also allowed for, such as web-like superpositions of many routes extending over the entire network, and even superpositions of different quantum processes at different routers in the network. This allowed complexity provides for significant future proofing of the proposed architecture as these exciting new networks develop.

The framework we have outlined requires further detail and consideration. Future community involvement and a rigorous standardization process will be needed before the concepts proposed here or elsewhere can be put into widespread practice.

Acknowledgments↩︎

The author thanks Professors Angela Sara Cacciapuoti and Marcello Caleffi for their valuable comments on this work. The author also thanks the University of Naples Federico II for hosting a sabbatical visit during which this work was conducted.

References↩︎

---

2. The author is with the School of Electrical Engineering and Telecommunications, University of New South Wales, Sydney, Australia. email: r.malaney@unsw.edu.au↩︎

3. In many works, the term ‘quantum routing’ is taken to simply mean the distribution of quantum entanglement through a network using single-path routing; here we take this term to mean the full superposition of routing paths allowed for by quantum mechanics.↩︎

4. Multiplexing the classical and quantum signaling in other modes such as frequency or polarization is also possible. For clarity we consider here only multiplexing in the time domain, given the recent experimental development of a chip designed specifically for that purpose [20].↩︎

5. In principle, this requirement for quantum memory could be dropped, but this would require additional synchronization of network infrastructure and resources, however, we note that the required memory timescale that allows for IP processing (including optical to electrical conversion) is already available via circulation in small optical fiber loops [31].↩︎

6. The use of radio for the classical data could be readily accommodated.↩︎

7. Here, we will not add any trailer after the quantum payload to remain faithful to the IPv6 standard [4], however, given the complexity of quantum networks, the use of a trailer may be useful in future applications.↩︎

8. In port-based teleportation, no manipulation of the quantum state is required, the classical data indicate which port the receiver is to read the quantum state from [32].↩︎

9. The information held in this classical data requires thought when superpositions of quantum processes involving teleportation are used; see later discussion.↩︎

10. Transmission via teleportation at the link layer is possible, but care is needed when some superpositions are involved; see later discussion.↩︎

11. As an aside, we note that the notion of addresses being in the form of a quantum state, specifically the supposition of addresses, is something required for quantum random access memory (QRAM), a feature likely required by future quantum computers [35], [37]. Attempts have already been made to implement QRAM in current noisy quantum computers [38].↩︎

12. An example of this is when a setting would lead to a router revealing ‘which-way’ information on the paths. Any setting which leads to an unintended destruction of any requested superposition (of paths or processes) is to be avoided - the designs outlined do not automatically guarantee maintenance of superposition for all setting combinations.↩︎

13. Single photon DV input states and corresponding Bell-State photon-pairs as entanglement resources are likely to be widely used in the Quantum Internet. However, new Extension Headers can cover any input state, and any entanglement resource state including a Two-Mode Squeezed Vacuum (TMSV) state and a hybrid DV-CV state.↩︎

14. It is assumed that the first eight bits in the IPv6 addresses used are not fixed to ff00::/8 (binary 11111111) as would be the case for classical multicast within IPv6.↩︎

15. Some of the combinations of these fields currently have no identified network purpose but are accommodated in case future research leads to new motivations.↩︎

16. This is not an absolute requirement. A specific configuration for the superposition of routing and teleportation is that of Eq. (7) of [27], where two individual teleportation maps are invoked. Various combinations of the Quantum Extension Headers (including modifications to the Quantum Routing Header) can accommodate that configuration.↩︎

17. We use the phrase ‘other layers’ to mean either the link layer, Application layer, or the TCP layer - or a combination thereof. It remains an open debate as to how exactly quantum networks will manage entanglement distribution (see later discussion).↩︎

18. Retrieving memory from a superposition of addresses, most of which are not local to a specific router, in itself sets up a need for a new network protocol that allows such access. We do not discuss the details of that new access protocol, but it should be clear that this could also be built within the IPv6 Extension Header architecture and even in part built using some of the new headers we are describing.↩︎

19. Note, any measurement of a control qubit (either directly or indirectly (e.g., via Bell measurements) can collapse the superposition unless that classical information is stored (unread) in some ancilla state, an issue that does not necessarily hamper the application being pursued.↩︎

20. For example, the work of [42] a superposition of teleportation and classical communication is presented; also, superposition of a process with the previously mentioned process of indefinite causal orders is also possible.↩︎