Subject: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

From: Wojciech Kozlowski <[email-masked]>
Date: Tue, 1 Oct 2019 11:35:21 +0000

Dear QIRG,

For the first item of discussion for the "Architectural Principles for a Quantum Internet" draft we will start with the topic that generated the most discussion on the call namely:

The relation between classical and quantum networks.

Within this I also want to cover two related issues:

  *   the definition and relation of two coexisting data planes
  *   what do we have instead of a packet in a quantum network

Datatracker version: https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
GitHub version: https://github.com/Wojtek242/draft-irtf-qirg-principles

Here, I will propose a bullet point outline for the contents of a new section. This new section will replace/expand the existing section 5.1 "Model of a quantum network" (therefore, it assumes the reader has read sections 1-4). Please use this opportunity to make sure that everything is covered in these bullet points, because if it isn't, you can assume it won't make it into the final version. Feel free to add your own points below!

What feedback am I looking for:

  *   is the abstract model of the network clear from the description below?
  *   if something is not clear and you think it deserves more attention, please make a note of it by replying to the mailing list.
  *   there was mention of referring to the time and spatial relations between the data planes. I'm not sure that's covered below so I could use some help with this. Even phrasing the problem as a series of more specific questions would be useful.
  *   I vaguely mention mention naming below and this was a point raised below. One possibility is to reuse classical naming mechanisms since a quantum network will coexist with a classical network. This may be sufficient.
  *   there was also a question of drawing analogies to the physical layer in a classical network - is this covered sufficiently below or should more information be added or clarified?
  *   If you have something to add, please just add it to the list below.
  *   If you have questions that are not directly related to the content below, please start a new e-mail thread.

Important dates for this discussion:

  *   2019-10-01: discussion opened on QIRG mailing list.
  *   2019-10-08: please try to send any comments you have by this day to allow for some discussion and reactions before the next call.
  *   2019-10-14: the next call to discuss the draft - aim will be to consolidate discussions on the topic below. If there is rough consensus I will then work on writing up the discussion and adding it to the draft. Otherwise, we will proceed on the mailing list.

Proposed new content for section 5.1:

  1.  Challenges
     *   Goal of this section is to give the reader a good abstract model of what a quantum network looks like. Amongst other things it must answer the question "why can we not just build a quantum network in the same way we built classical networks".
     *   There is no quantum equivalent of a payload-carrying packet. The basic unit is entanglement in the form of entangled qubits. Entanglement is a generic resource distributed to end-nodes which is consumed by applications. Teleportation, the mechanism for transporting quantum data, is one such application.
     *   Entanglement is a phenomenon in which two or more qubits exist in a physically distributed state. This property exists at the physical level and requires that the location and state of its constituent qubits be known. This is in contrast to classical signals at the physical layer which proceed statelessly from sender to receiver.
     *   Entangled qubits do not carry control information. Therefore, a quantum router must manage two data planes in parallel, a classical one, which carries the control information, and a quantum one, which carries entangled qubits. It must also be able to correlate the classical control information with the appropriate entangled pairs.
     *   Setting up end-to-end entanglement necessarily requires temporary state in the intermediate nodes beyond forwarding tables. At the very least all qubits will need some local metadata associated with them to allow routers to correlate them with the relevant control information.
     *   Creating a longer end-to-end pair is a spatially parallelisable operation unlike packet forwarding. The generation of entangled pairs on each individual link can happen in parallel (perhaps even as a background process) and the entanglement swaps can also be done independently of each other. What is important is that at the end of the day, the control plane can unambiguously identify which qubits in the network are paired up in an entangled pair state. This implies that the forwarding mechanisms may be very different.
  2.  Abstract model of the network
     *   In a quantum network will consist of quantum channels which serve to generate entanglement on individual links and classical channels which are used to transmit control information (in the conventional way - as packets).
     *   Not all routers will have both - some devices may only have a classical data plane. Some devices may only have a quantum data plane (in this case the entanglement generation and swapping will be fully automated).
     *   Decision making nodes necessarily have both data planes.
     *   It is beyond the scope of this draft to propose concrete mechanisms for correlating control information with qubits. However, it is worth outlining some possibilities. For example, an entangled pair can have metadata associated with it, such as the time it was generated at. If time is discretised into time bins and only one such pair at most is generated in each time bin this can be used to uniquely identify a particular entangled qubit. This is the mechanism used in the recently proposed link layer protocol.
     *   Because a classical network is part of a quantum network, we can use several basic mechanisms from classical networks, such as: routing protocols (for distributing topology information - actual routing decisions will be more involved), IP addresses and ports for naming, GMPLS was also mentioned which may be relevant in some situations. I think Rodney did some work in this area in the past - perhaps something could be added here.

Thanks,
Wojtek

---

From: Gelard Patrick <[email-masked]>
Date: Tue, 1 Oct 2019 12:59:33 +0000

Hi,

My comments in bleu [PG]

Thanks
/Patrick

De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : mardi 1 octobre 2019 13:35
À : [email-masked]
Objet : [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

Dear QIRG,

  1.  Challenges
     *   Goal of this section is to give the reader a good abstract model of what a quantum network looks like. Amongst other things it must answer the question "why can we not just build a quantum network in the same way we built classical networks".
[PG] Internet is not a network. It is a network of network.  So by similarity should not we talk about an interconnected network of quantum networks in which all parties can perform quantum information processing and quantum computing tasks ? The promise of this “quantum internet” is the ability to perform quantum information processing tasks, such as quantum teleportation , quantum key distribution, quantum clock synchronization , distributed quantum computation , and distributed quantum metrology and sensing , on a global scale !

     *   There is no quantum equivalent of a payload-carrying packet. The basic unit is entanglement in the form of entangled qubits. Entanglement is a generic resource distributed to end-nodes which is consumed by applications. Teleportation, the mechanism for transporting quantum data, is one such application.
[PG] Entanglement is a generic resource distributed to end-nodes which is request and consumed by applications.

     *   Entanglement is a phenomenon in which two or more qubits exist in a physically distributed state. This property exists at the physical level and requires that the location and state of its constituent qubits be known. This is in contrast to classical signals at the physical layer which proceed statelessly from sender to receiver.
     *   Entangled qubits do not carry control information. Therefore, a quantum router must manage two data planes in parallel, a classical one, which carries the control information, and a quantum one, which carries entangled qubits. It must also be able to correlate the classical control information with the appropriate entangled pairs.
[PG] Is it really up to the quantum router to manage the control plan of the classic network used ? This is very well managed by the classical network. I would tend to say the opposite. Update  exiting classical control plane  (MPLS-TE, SDN/Openflow, Netconf, MP-BGP, …) to manage quantum  network.

     *   Setting up end-to-end entanglement necessarily requires temporary state in the intermediate nodes beyond forwarding tables. At the very least all qubits will need some local metadata associated with them to allow routers to correlate them with the relevant control information.
     *   Creating a longer end-to-end pair is a spatially parallelisable operation unlike packet forwarding. The generation of entangled pairs on each individual link can happen in parallel (perhaps even as a background process) and the entanglement swaps can also be done independently of each other. What is important is that at the end of the day, the control plane can unambiguously identify which qubits in the network are paired up in an entangled pair state. This implies that the forwarding mechanisms may be very different.
  1.  Abstract model of the network
     *   In a quantum network will consist of quantum channels which serve to generate entanglement on individual links and classical channels which are used to transmit control information (in the conventional way - as packets).
[PG] The quantum channel can be integrated/hybrid with optical classical.

[PG] There are different kind of networks LAN, MAN or WAN.

Thanks,
Wojtek

---

From: Patrick Gelard <[email-masked]>
Date: Thu, 3 Oct 2019 06:48:38 +0200

Dear all,

I just read this article of synthesis "Towards Large-Scale Quantum 
Networks" ( https://arxiv.org/pdf/1909.08396.pdf )  and it seemto be a 
good complement to sections 1 - 4 to know about, in order to approach 
the discussions.

 >>There is no quantum equivalent of a payload-carrying packet. The 
basic unit is entanglement in the form of entangled qubits.

What I understand :

I seem that distributed quantum application need to processing 
distributed of register of entangled qubits ( e.g 
https://arxiv.org/abs/quant-ph/0403146 ). Thus, one goal of the quantum 
network is to distributed entangled qubits to the application that 
requested  it. This is the network layer of the quantum network that is 
the counterpart of the network packet layer of classical network.

Distributed quantum network need a end to end transport network to build 
a graph of distributed of register of entangled qubits. it is the 
teleportation service that acts as the transport layer.

Thus, it seems to me that it is important to know beforehand the quantum 
communication requirements of quantum applications in order to be able 
to decline "Architectural Principles for a Quantum Internet".

/Patrick

Le 01/10/2019 à 14:59, Gelard Patrick a écrit :
>
> Hi,
>
> My comments in bleu [PG]
>
> Thanks
>
> /Patrick
>
> *De :*Qirg <[email-masked]> *De la part de* Wojciech Kozlowski
> *Envoyé :* mardi 1 octobre 2019 13:35
> *À :* [email-masked]
> *Objet :* [Qirg] draft-irtf-qirg-principles: Relation to Classical 
> Networks
>
> Dear QIRG,
>
> For the first item of discussion for the "Architectural Principles for 
> a Quantum Internet" draft we will start with the topic that generated 
> the most discussion on the call namely:
>
> *The relation between classical and quantum networks. *
>
> Datatracker version: 
> https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
>
> GitHub version: 
> https://github.com/Wojtek242/draft-irtf-qirg-principles 
> <https://github.com/Wojtek242/draft-irtf-qirg-principles>
>
> Here, I will propose a bullet point outline for the contents of a new 
> section. This new section will replace/expand the existing section 5.1 
> "Model of a quantum network" (therefore, it assumes the reader has 
> read sections 1-4). Please use this opportunity to make sure that 
> everything is covered in these bullet points, because if it isn't, you 
> can assume it won't make it into the final version. _Feel free to add 
> your own points below!_
>
> *What feedback am I looking for:*
>
>   * if something is not clear and you think it deserves more
>     attention, please make a note of it by replying to the mailing list.
>   * there was mention of referring to the time and spatial relations
>     between the data planes. I'm not sure that's covered below so I
>     could use some help with this. Even phrasing the problem as a
>     series of more specific questions would be useful.
>   * I vaguely mention mention naming below and this was a point raised
>     below. One possibility is to reuse classical naming mechanisms
>     since a quantum network will coexist with a classical network.
>     This may be sufficient.
>   * there was also a question of drawing analogies to the physical
>     layer in a classical network - is this covered sufficiently below
>     or should more information be added or clarified?
> *Important dates for this discussion:*
>
>   * 2019-10-08: please try to send any comments you have by this day
>     to allow for some discussion and reactions before the next call.
>   * 2019-10-14: the next call to discuss the draft - aim will be to
>     consolidate discussions on the topic below. If there is rough
>     consensus I will then work on writing up the discussion and adding
>     it to the draft. Otherwise, we will proceed on the mailing list.
>
> *Proposed new content for section 5.1:*
>
>  1. Challenges
>       * Goal of this section is to give the reader a good abstract
>         model of what a quantum network looks like. Amongst other
>         things it must answer the question "why can we not just build
>         a quantum network in the same way we built classical networks".
>
> [PG] Internet is not a network. It is a network of network.  So by 
> similarity should not we talk about an interconnected network of 
> quantum networks in which all parties can perform quantum information 
> processing and quantum computing tasks ? The promise of this “quantum 
> internet” is the ability to perform quantum information processing 
> tasks, such as quantum teleportation , quantum key distribution, 
> quantum clock synchronization , distributed quantum computation , and 
> distributed quantum metrology and sensing , on a global scale !
>
>       * There is no quantum equivalent of a payload-carrying packet.
>         The basic unit is entanglement in the form of entangled
>         qubits. Entanglement is a generic resource distributed to
>         end-nodes which is consumed by applications. Teleportation,
>         the mechanism for transporting quantum data, is one such
>         application.
>
> [PG] Entanglement is a generic resource distributed to end-nodes which 
> is *request and*consumed by applications.
>
>       * Entanglement is a phenomenon in which two or more qubits exist
>         in a physically distributed state. This property exists at the
>         physical level and requires that the location and state of its
>         constituent qubits be known. This is in contrast to classical
>         signals at the physical layer which proceed statelessly from
>         sender to receiver.
>       * Entangled qubits do not carry control information. Therefore,
>         a quantum router must manage two data planes in parallel, a
>         classical one, which carries the control information, and a
>         quantum one, which carries entangled qubits. It must also be
>         able to correlate the classical control information with the
>         appropriate entangled pairs.
>
> [PG]Is it really up to the quantum router to manage the control plan 
> of the classic network used ? This is very well managed by the 
> classical network. I would tend to say the opposite. Update  exiting 
> classical control plane  (MPLS-TE, SDN/Openflow, Netconf, MP-BGP, …) 
> to manage quantum  network.
>
>       * Setting up end-to-end entanglement necessarily requires
>         temporary state in the intermediate nodes beyond forwarding
>         tables. At the very least all qubits will need some local
>         metadata associated with them to allow routers to correlate
>         them with the relevant control information.
>       * Creating a longer end-to-end pair is a spatially
>         parallelisable operation unlike packet forwarding. The
>         generation of entangled pairs on each individual link can
>         happen in parallel (perhaps even as a background process) and
>         the entanglement swaps can also be done independently of each
>         other. What is important is that at the end of the day, the
>         control plane can unambiguously identify which qubits in the
>         network are paired up in an entangled pair state. This implies
>         that the forwarding mechanisms may be very different.
>       * In a quantum network will consist of quantum channels which
>         serve to generate entanglement on individual links and
>         classical channels which are used to transmit control
>         information (in the conventional way - as packets).
>
>       * Not all routers will have both - some devices may only have a
>         classical data plane. Some devices may only have a quantum
>         data plane (in this case the entanglement generation and
>         swapping will be fully automated).
>       * It is beyond the scope of this draft to propose concrete
>         mechanisms for correlating control information with qubits.
>         However, it is worth outlining some possibilities. For
>         example, an entangled pair can have metadata associated with
>         it, such as the time it was generated at. If time is
>         discretised into time bins and only one such pair at most is
>         generated in each time bin this can be used to uniquely
>         identify a particular entangled qubit. This is the mechanism
>         used in the recently proposed link layer protocol.
>       * Because a classical network is part of a quantum network, we
>         can use several basic mechanisms from classical networks, such
>         as: routing protocols (for distributing topology information -
>         actual routing decisions will be more involved), IP addresses
>         and ports for naming, GMPLS was also mentioned which may be
>         relevant in some situations. I think Rodney did some work in
>         this area in the past - perhaps something could be added here.
>
> _______________________________________________
> Qirg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/qirg

---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus

---

From: Wojciech Kozlowski <[email-masked]>
Date: Wed, 9 Oct 2019 13:00:00 +0000

Dear QIRG,

A reminder that the call to discuss the issues below will happen at 11:00 GMT on 14 October.

The agenda will be:
1. Allow for any additional feedback in addition to what was raised on the mailing list.
2. Discuss issues that were raised on the mailing list and any other issues people might have on the call.
3. Decide if rough consensus exists on the contents below.

If you have any additional feedback you would like to give on the below before then, please go ahead.

Thanks to all who have already returned some feedback! 

Thanks,
Wojtek
________________________________________
From: Qirg [[email-masked]] on behalf of Wojciech Kozlowski [[email-masked]]
Sent: 01 October 2019 13:35
To: [email-masked]
Subject: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

Dear QIRG,

  1.  Challenges

Thanks,
Wojtek

---

From: Wojciech Kozlowski <[email-masked]>
Date: Thu, 10 Oct 2019 12:53:09 +0000

Hi,

Some answers in-line to questions you asked. The other comments were good as well so thank you for the contribution!

Thanks,
Wojtek

  1.  Challenges
     *   Goal of this section is to give the reader a good abstract model of what a quantum network looks like. Amongst other things it must answer the question "why can we not just build a quantum network in the same way we built classical networks".
[PG] Internet is not a network. It is a network of network.  So by similarity should not we talk about an interconnected network of quantum networks in which all parties can perform quantum information processing and quantum computing tasks ? The promise of this “quantum internet” is the ability to perform quantum information processing tasks, such as quantum teleportation , quantum key distribution, quantum clock synchronization , distributed quantum computation , and distributed quantum metrology and sensing , on a global scale !
[WK] In this draft I have not touched upon how one would combine different networks. For the most part I don't think that's a good question to address in this draft since it is not immediately clear how to do that and we have mentioned wanting to avoid the kitchen sink approach. However, anything in the current draft should apply to internetworks as well. It may be worth making this point somewhere.

     *   Entangled qubits do not carry control information. Therefore, a quantum router must manage two data planes in parallel, a classical one, which carries the control information, and a quantum one, which carries entangled qubits. It must also be able to correlate the classical control information with the appropriate entangled pairs.
[PG] Is it really up to the quantum router to manage the control plan of the classic network used ? This is very well managed by the classical network. I would tend to say the opposite. Update  exiting classical control plane  (MPLS-TE, SDN/Openflow, Netconf, MP-BGP, …) to manage quantum  network.
[WK] A quantum router will have a control plane that runs both quantum and control plane protocols. The classical control plane protocols can be the same ones as you mentioned (perhaps with some quantum extensions like the currently dormant ISIS-TE draft). I don't think it's anyone's intention to reinvent protocols for managing the classical control plane. This is a good point to clarify and make clearer in the draft.

---

From: Gelard Patrick <[email-masked]>
Date: Thu, 10 Oct 2019 15:41:48 +0000

Hi,

For the debate, some remarks in line.

Thanks
/Patrick

De : Qirg <[email-masked]> De la part de Wojciech Kozlowski
Envoyé : jeudi 10 octobre 2019 14:53
À : [email-masked]
Objet : Re: [Qirg] draft-irtf-qirg-principles: Relation to Classical Networks

Hi,

Thanks,
Wojtek

  1.  Challenges

[PG] My goal is not to define detailed network architecture, neither a network architecture at all.
What i understand about the goal of the document is to define “Architectural Principles for a Quantum Internet”. Hence the first questions that arises are :

1/ What is a “quantum internet” for which it is question of defining the architecture principles ?
2/ What is the scope of the document in the context of IETF/IRTF ?

If we look at the RFC 1598 https://tools.ietf.org/html/rfc1958 :

2        Is there an Internet Architecture?

However, in very general terms, the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network.

The key to global connectivity is the inter-networking layer.  The key to exploiting this layer over diverse hardware providing global connectivity is the "end to end argument".
There are three key principle connectivity, inter-networking and end-to-end communication

Another rfc that can be interesting to know  : https://tools.ietf.org/html/rfc3439

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 14 Oct 2019 07:33:52 +0000

A reminder that the fortnightly call to discuss the "Architectural
Principles for a Quantum Internet" draft is today at 11:00 GMT.

The agenda is
1. A GitHub project page was setup by Stephen Diadamo so a quick update
on this.
2. Allow for any additional feedback in addition to what was raised on
the mailing list on the topic of relation to classical networks.
3. Discuss issues that were raised on the mailing list and any other
issues people might have on the call on the topic of relation to
classical networks.
4. Decide if rough consensus exists on the proposed changes.

The length of the call will depend on how much there is to discuss.

Thank you,
Wojtek

On Wed, 2019-10-09 at 13:00 +0000, Wojciech Kozlowski wrote:
> For the first item of discussion for the "Architectural Principles
> for a Quantum Internet" draft we will start with the topic that
> generated the most discussion on the call namely:
> 
> section. This new section will replace/expand the existing section
> 5.1 "Model of a quantum network" (therefore, it assumes the reader
> has read sections 1-4). Please use this opportunity to make sure that
> everything is covered in these bullet points, because if it isn't,
> you can assume it won't make it into the final version. Feel free to
> add your own points below!
> 
>   *   there was mention of referring to the time and spatial
> relations between the data planes. I'm not sure that's covered below
> so I could use some help with this. Even phrasing the problem as a
>   *   I vaguely mention mention naming below and this was a point
> raised below. One possibility is to reuse classical naming mechanisms
> since a quantum network will coexist with a classical network. This
> may be sufficient.
> layer in a classical network - is this covered sufficiently below or
> should more information be added or clarified?
>   *   If you have questions that are not directly related to the
> content below, please start a new e-mail thread.
> 
>   *   2019-10-08: please try to send any comments you have by this
> day to allow for some discussion and reactions before the next call.
> consensus I will then work on writing up the discussion and adding it
> to the draft. Otherwise, we will proceed on the mailing list.
> 
> model of what a quantum network looks like. Amongst other things it
> must answer the question "why can we not just build a quantum network
> in the same way we built classical networks".
> The basic unit is entanglement in the form of entangled qubits.
> Entanglement is a generic resource distributed to end-nodes which is
> consumed by applications. Teleportation, the mechanism for
> transporting quantum data, is one such application.
>      *   Entanglement is a phenomenon in which two or more qubits
> exist in a physically distributed state. This property exists at the
> constituent qubits be known. This is in contrast to classical signals
> at the physical layer which proceed statelessly from sender to
> receiver.
>      *   Entangled qubits do not carry control information.
> Therefore, a quantum router must manage two data planes in parallel,
> a classical one, which carries the control information, and a quantum
> one, which carries entangled qubits. It must also be able to
> correlate the classical control information with the appropriate
> entangled pairs.
> temporary state in the intermediate nodes beyond forwarding tables.
> At the very least all qubits will need some local metadata associated
> with them to allow routers to correlate them with the relevant
> control information.
> parallelisable operation unlike packet forwarding. The generation of
> entangled pairs on each individual link can happen in parallel
> (perhaps even as a background process) and the entanglement swaps can
> also be done independently of each other. What is important is that
> at the end of the day, the control plane can unambiguously identify
> which qubits in the network are paired up in an entangled pair state.
> This implies that the forwarding mechanisms may be very different.
> serve to generate entanglement on individual links and classical
> channels which are used to transmit control information (in the
> conventional way - as packets).
>      *   Not all routers will have both - some devices may only have
> a classical data plane. Some devices may only have a quantum data
> plane (in this case the entanglement generation and swapping will be
> fully automated).
> mechanisms for correlating control information with qubits. However,
> it is worth outlining some possibilities. For example, an entangled
> pair can have metadata associated with it, such as the time it was
> generated at. If time is discretised into time bins and only one such
> pair at most is generated in each time bin this can be used to
> uniquely identify a particular entangled qubit. This is the mechanism
> can use several basic mechanisms from classical networks, such as:
> routing protocols (for distributing topology information - actual
> routing decisions will be more involved), IP addresses and ports for
> naming, GMPLS was also mentioned which may be relevant in some
> situations. I think Rodney did some work in this area in the past -
> perhaps something could be added here.
> 
> Thanks,
> Wojtek
> 
>

---

From: JW λ John Woodworth <[email-masked]>
Date: Mon, 14 Oct 2019 04:01:12 -0400

Hi Wojtek,Can you please forward bridge details for this call?/John 
-------- Original message --------From: Wojciech Kozlowski <[email-masked]>A reminder that the fortnightly call to discuss the "ArchitecturalPrinciples for a Quantum Internet" draft is today at 11:00 GMT.The agenda is1. A GitHub project page was setup by Stephen Diadamo so a quick updateon this.2. Allow for any additional feedback in addition to what was raised onthe mailing list on the topic of relation to classical networks.3. Discuss issues that were raised on the mailing list and any otherissues people might have on the call on the topic of relation toclassical networks.4. Decide if rough consensus exists on the proposed changes.The length of the call will depend on how much there is to discuss.Thank you,WojtekOn Wed, 2019-10-09 at 13:00 +0000, Wojciech Kozlowski wrote:> Dear QIRG,> > A reminder that the call to discuss the issues below will happen at> 11:00 GMT on 14 October.> > The agenda will be:> 1. Allow for any additional feedback in addition to what was raised> on the mailing list.> 2. Discuss issues that were raised on the mailing list and any other> issues people might have on the call.> 3. Decide if rough consensus exists on the contents below.> > If you have any additional feedback you would like to give on the> below before then, please go ahead.> > Thanks to all who have already returned some feedback! > > Thanks,> Wojtek> ________________________________________> From: Qirg [[email-masked]] on behalf of Wojciech Kozlowski [> [email-masked]]> Sent: 01 October 2019 13:35> To: [email-masked]> Subject: [Qirg] draft-irtf-qirg-principles: Relation to Classical> Networks> > Dear QIRG,> > For the first item of discussion for the "Architectural Principles> for a Quantum Internet" draft we will start with the topic that> generated the most discussion on the call namely:> > The relation between classical and quantum networks.> > Within this I also want to cover two related issues:> >   *   the definition and relation of two coexisting data planes>   *   what do we have instead of a packet in a quantum network> > Datatracker version: > https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/> GitHub version: > https://github.com/Wojtek242/draft-irtf-qirg-principles> > Here, I will propose a bullet point outline for the contents of a new> section. This new section will replace/expand the existing section> 5.1 "Model of a quantum network" (therefore, it assumes the reader> has read sections 1-4). Please use this opportunity to make sure that> everything is covered in these bullet points, because if it isn't,> you can assume it won't make it into the final version. Feel free to> add your own points below!> > What feedback am I looking for:> >   *   is the abstract model of the network clear from the description> below?>   *   if something is not clear and you think it deserves more> attention, please make a note of it by replying to the mailing list.>   *   there was mention of referring to the time and spatial> relations between the data planes. I'm not sure that's covered below> so I could use some help with this. Even phrasing the problem as a> series of more specific questions would be useful.>   *   I vaguely mention mention naming below and this was a point> raised below. One possibility is to reuse classical naming mechanisms> since a quantum network will coexist with a classical network. This> may be sufficient.>   *   there was also a question of drawing analogies to the physical> layer in a classical network - is this covered sufficiently below or> should more information be added or clarified?>   *   If you have something to add, please just add it to the list> below.>   *   If you have questions that are not directly related to the> content below, please start a new e-mail thread.> > Important dates for this discussion:> >   *   2019-10-01: discussion opened on QIRG mailing list.>   *   2019-10-08: please try to send any comments you have by this> day to allow for some discussion and reactions before the next call.>   *   2019-10-14: the next call to discuss the draft - aim will be to> consolidate discussions on the topic below. If there is rough> consensus I will then work on writing up the discussion and adding it> to the draft. Otherwise, we will proceed on the mailing list.> > Proposed new content for section 5.1:> > >   1.  Challenges>      *   Goal of this section is to give the reader a good abstract> model of what a quantum network looks like. Amongst other things it> must answer the question "why can we not just build a quantum network> in the same way we built classical networks".>      *   There is no quantum equivalent of a payload-carrying packet.> The basic unit is entanglement in the form of entangled qubits.> Entanglement is a generic resource distributed to end-nodes which is> consumed by applications. Teleportation, the mechanism for> transporting quantum data, is one such application.>      *   Entanglement is a phenomenon in which two or more qubits> exist in a physically distributed state. This property exists at the> physical level and requires that the location and state of its> constituent qubits be known. This is in contrast to classical signals> at the physical layer which proceed statelessly from sender to> receiver.>      *   Entangled qubits do not carry control information.> Therefore, a quantum router must manage two data planes in parallel,> a classical one, which carries the control information, and a quantum> one, which carries entangled qubits. It must also be able to> correlate the classical control information with the appropriate> entangled pairs.>      *   Setting up end-to-end entanglement necessarily requires> temporary state in the intermediate nodes beyond forwarding tables.> At the very least all qubits will need some local metadata associated> with them to allow routers to correlate them with the relevant> control information.>      *   Creating a longer end-to-end pair is a spatially> parallelisable operation unlike packet forwarding. The generation of> entangled pairs on each individual link can happen in parallel> (perhaps even as a background process) and the entanglement swaps can> also be done independently of each other. What is important is that> at the end of the day, the control plane can unambiguously identify> which qubits in the network are paired up in an entangled pair state.> This implies that the forwarding mechanisms may be very different.>   2.  Abstract model of the network>      *   In a quantum network will consist of quantum channels which> serve to generate entanglement on individual links and classical> channels which are used to transmit control information (in the> conventional way - as packets).>      *   Not all routers will have both - some devices may only have> a classical data plane. Some devices may only have a quantum data> plane (in this case the entanglement generation and swapping will be> fully automated).>      *   Decision making nodes necessarily have both data planes.>      *   It is beyond the scope of this draft to propose concrete> mechanisms for correlating control information with qubits. However,> it is worth outlining some possibilities. For example, an entangled> pair can have metadata associated with it, such as the time it was> generated at. If time is discretised into time bins and only one such> pair at most is generated in each time bin this can be used to> uniquely identify a particular entangled qubit. This is the mechanism> used in the recently proposed link layer protocol.>      *   Because a classical network is part of a quantum network, we> can use several basic mechanisms from classical networks, such as:> routing protocols (for distributing topology information - actual> routing decisions will be more involved), IP addresses and ports for> naming, GMPLS was also mentioned which may be relevant in some> situations. I think Rodney did some work in this area in the past -> perhaps something could be added here.> > Thanks,> Wojtek> > > _______________________________________________> Qirg mailing list> [email-masked]> https://www.irtf.org/mailman/listinfo/qirg_______________________________________________Qirg mailing [email-masked]://www.irtf.org/mailman/listinfo/qirg

---

From: Wojciech Kozlowski <[email-masked]>
Date: Mon, 14 Oct 2019 08:29:31 +0000

Thanks for reminding me I forgot to attach the bridge details (if you
accepted the calendar event, the link should be there as well):

"Architectural Principles for a Quantum Internet" Call
Meeting URL: https://meet.jit.si/QirgDraftPrinciples 

*** Please only use Chrome/Chromium based browser to join ***
(jitsi doesn't work as reliably in Firefox and Safari)

When: 11:00 GMT 30 Sep
Recurrence: 14 Oct, 28 Oct, 11 Nov
Draft URL (datatracker): 
https://datatracker.ietf.org/doc/draft-irtf-qirg-principles/
Draft URL (GitHub): 
https://github.com/Wojtek242/draft-irtf-qirg-principles

On Mon, 2019-10-14 at 07:33 +0000, Wojciech Kozlowski wrote:
> > 2. Discuss issues that were raised on the mailing list and any
> > other
> > issues people might have on the call.
> > From: Qirg [[email-masked]] on behalf of Wojciech Kozlowski
> > [
> > [email-masked]]
> >   *   is the abstract model of the network clear from the
> > description
> > below?
> > or
> > it
> > signals
> > However,