Entangled Resource Naming

[Naphann]

Currently, everything relies on the fact that the participant nodes of RuleSet always pick the same order of entangled resources (currently only Bell pair) by their creation time. Since there are no mechanics for sophisticated multiplexing yet, we won't know if there would be later problems or not.

Since the entangled resources are short-lived, and to prevent releasing too much information about inside of the node, the scheme where partner nodes know which qubit address the entangled pair share doesn't satisfy this requirement and also can lead to problems where the qubit address requested is actually entangled with someone but not the right qubit pair the requesting node thought.

I propose that we name the entangled resource using a unique identifier, the two parties refer to the said resource via this name and translate this name to its physical qubit addressing on its own maintaining some fashion of name translation table. This proposed naming can also be extended to logical resources as well. The name should originate from the one creating the new resource (i.e. MIM link - at HoM, MM link - at the node housing internal HoM, entanglement swapping - at the swapper node)

One straightforward way to achieve this, using heralded entanglement generation as link generation (MIM, MM), is to

• let the HoM sending BSA results (with sequence number or timestamp) or it can be sent with BSM notification
• the name of the bell pair is then defined by <sequence>:<order_of_the_qubits_in_the_photon_train> so the two nodes know the same name without having to know which addressing scheme the partner node is using.

For entanglement swapping

• since the swapper should know the naming of the two pairs (left/right)
• the name of the lengthened Bell pair (resource) can then be defined as <time_stamp>:<some_uuid>

This would let us reconcile the order of pairs to be consumed if in some certain scenarios (when multiplexing is involved) one of the partner nodes tries to use a resource that is already thrown away or consumed by past RuleSet.

The reconciliation mechanism can be another issue.