Planned routing features/models

[amar-ox]

This issue summarizes routing models to implement next and is intended to coordinate development efforts.

A baseline/static reactive-centralized-synchronous routing has been implemented. A few simple mechanisms have been identified for exploration to enable a fair and more complete comparison of routing approaches, summarized in the following:

• Only centralized routing is considered.
• Task 1: ProactiveRoutingController: dynamic path installation/removal #124 Add a dynamic path installation/removal for proactive routing (in the controller app). A traffic matrix should be defined and used to create and delete S-D requests during the simulation. More details below.
• Task 2: ProactiveRoutingController: dynamically adapt buffer-space multiplexing to active requests #125 Extend proactive controller app to dynamically adapt buffer-space multiplexing to active requests.
• Task 3: ReactiveRoutingController: dynamic path computation #126 Make path computation in reactive routing dynamic.
• Task 4: Entanglement multi-slot carryover in synchronous timing #127 In synchronous timing (both proactive and reactive): implement entanglement multi-slot carryover; i.e., elementary entanglements can be kept at the end of a time slot to the next one(s).
• Task 5: reactive-centralized-asynchronous via a simple continuous entanglement generation #128 Support reactive-centralized-asynchronous via a simple continuous entanglement generation.

More details will be shared for Tasks 4 and 5 as implementation progresses.

Traffic-matrix–driven request generation in the simulator:

• Introduce a traffic matrix 𝑇[𝑖,𝑗] where each entry defines the probability that node i initiates a request to node j. The matrix should be normalized (sum = 1).
• Implement a request generator (or extend the current random request generation) that samples source–destination pairs according to this distribution.
• Generate requests at a configurable Poisson process (e.g., rate = 10 Hz), with each request specifying: source, destination, number of entangled pairs (default: 1) or request duration, optional min fidelity.

@yoursunny would you like to take Task 1 and 2 since they are related to the existing proactive controller app?