Routing – Default routing protocol used by SDN controllers

I think you've mostly got it.

There are a few points I would make though.

3. The path P_0, from R to C_1, is often (but not always) implemented 'out-of-band', as a separate network.

4. Only one, or a handful, of packets for each network flow should reach C_1. As soon as the flows are inserted by the AmyOSPF controller, they are simply forwarded according to that routing logic. This is what the second quote says.

5. No. AmyOSPF computes the best path P_1 from R to the destination of the packets, wherever that may be. It can do this without talking to the switches.

The flow entries that make up the path P_1 is then sent to the routers on P_1, so that all traffic coming from Amy's machine to a particular destination are sent along that path, without having to go to the controller. In the case of R, this new flow entry must have higher priority than the one that says to send all traffic from that port to the controller.

6. It's not really a multicast, the controller has a separate connection to each switch/router. The flow entries may be slightly different for each router too.

7. The point is that it doesn't matter what 'view' the router has, as all of the routing is done in the controller. But C_0 does have a global view.

This will have to be repeated for each new network flow originating from Amy's machine. It wouldn't make sense to create a path from R to X and then send packets destined for Y along it. Having said that, flow entries can be aggregated.

This is a nice idea. We are using Floodlight for our SDN experiments. At the point in time we started, it was much more mature than the OpenDaylight software. As this has been more than a year ago, it might not be true anymore.

SDN offers you the following features that should be helpful to your use case:

• Link parameter measurements to find such paths:
  • Delay by using customly crafted probe packets and correlate timestamps
  • Loss can be done by sampling the port statistics
  • Bandwidth is still something we are working on
• As you are implementing reactive routing, you are most likely going to react on the packet_in event. In this case, you have two options:
  • Simple: use the transport protocol and port to deduce the app
  • Difficult: do some kind of deep-packet inspection to deduce the traffic type