Routing and openflow

[markh1289]

This document,
http://archive.openflow.org/documents/openflow-wp-latest.pdf

Under the example of Amy-OSPF it says,

"When her packets reach
a controller, her new protocol chooses a route and adds a
new flow-entry (for the application flow) to every switch
along the chosen path."

I understand that,
1) the only protocol going between the controller and the switches is openflow.
2) openflow essentially only carries,
    2a) information pertaining to the data-plane traffic which wants to be switched
    2b) information for populating the tables in the switches with flow-entries.
So my question  is, for the packets egressing Amy's PC and then ingressing the openflow network, how does the controller learn enough about where that packet destination resides in the network to be able to populate the flow tables correctly in every switch on the path to the destination IP address?

Regards, MH

[dave_tucker]

It depends... Let's take HP's SDN controller as an example

The controller provides a number of network services that handle topology and node discovery.

So if you were implementing Amy-OSPF on HP controller...

1) Packet arrives at the OF switch

2) OF switch encapsulates the packet and sends to the SDN controller

3) Amy-OSPF application inspects the packet 

    - We can query the node database to find the location of the destination 

    - We can run Amy-OSPF over the topology to compute the shortest path

4) Amy-OSPF application sends OF messages to program the flows on the OF switches in the path

Hope this helps

-- Dave

[markh1289]

Thanks for your reply, Dave.

- We can query the node database to find the location of the destination

1) Please clarify what you are refering to by "the node" - is it the OF switch?

2) What protocol is being used to 'query the node database' - openflow?

Regards, MH

[dave_tucker]

A node would be something connected to a switch with a MAC address or IP address, like a PC.

As the forwarding decision is being made on the controller (where the node database is), no protocol needs to be used to query the database as such... its just a database query from within the application.

Hope this helps!

-- Dave

[markh1289]

Thanks Dave.

Are you saying,

1) The controller has a database of all nodes including their MAC address and IP address and what switch and physical port they are connected to?

2) That the controller acquired this information from the switch by openflow?

Regards, MH

[dave_tucker]

Yes on both counts...

See the HP Network Services Modules TSG for more information

[markh1289]

Thanks very much Dave ... I'll read it.

[michaelhenkel]

Generic routing in OpenFlow only networks works this way:

1. a northbound app on the controller maintains routing/arp table entries and subnet gateway interface configuration (IP/MAC address). The routing table can be populated manually through configuration or dynamically by providing an interface to dynamic routing protocols. The arp table is populated by receiving arp replies and sending out arp requests (and then receive the arp reply). Let's assume two hosts in different subnets are powered on with no arp entry. If host1 tries to communicate with host2 the very first thing it does is broadcasting an arp packet asking for a MAC for its configured gateway in the subnet. As there is no OpenFlow rule on the switch this arp request broadcast is sent to the controller and received by the northbound app which does three things:

  a. it generates an arp reply using a gateway IP and a MAC address and sends it to the outport to which host1 is connected to

  b. it stores host1 IP and MAC in its internal arp table

  c. it looks its internal arp table up for the destination IP address of the IP packet (host2s IP address). If there is nothing in the arp table it generates an arp request packet using the subnets gatway IP and MAC and broadcasts it to all outports on the switches. Host2 will reply with an arp reply which is then stored in the apps arp table.

2. next in sequence is the very first IP packet. All prerequisites are in place, arp tables on host1, 2 and the app are populated with the required MAC - IP information but there is still no OpenFlow rule on any of the switches. So the first IP packet is again sent to the app. The app now needs to do again a couple of routing things:

  a. it takes the incoming IP packet and changes the original source and destination MAC address to the MAC address of the destination subnets gateway interface.

  b. it sends the modified IP packet to the outport host 2 is connected to.

  b. it implements a rule on the ingress switch which will do the exact same thing for all subsequent packets

So all following packets will now be directly forwarded on the switches for the lifetime of the rule. Once the rule times out, the sequence starts again. The trick is that the installed rule needs to replace src and dst mac addresses matching the arp information for the gateway stored in the hosts local arp table.