2/18

Mininet Simulator (Control Plane)

The switches are referred to as "dumb" because they need to be programmed.

Need common language to communicate between the switch and controller.

Within each switch, you need a client that can talk to the controller.

The flow table (in the switch) can support parameters (e.g., MAC, IP, TCP). These headers can determine how to process. This is followed by the action.

The first version of open flow:

• supported 10 parameters.

Recall the layers:

• layer 2 (switching): mac is the hard coded thing on the link layer
• routing: IP layer- specify which protocol you are on ipv4 or ipv6
• TCP: specifies the socket

dpctl is the control channel used to communicate with switches:

• fill out the tables in the switch. You can inspect flow table entries, modify flows, etc.
• switches will listen on port 6634

Walk through

mn --topo single,3 --mac --switch ovsk --controller remote

• one switch connecting three hosts.
• saying controller should be remote will use the default one (which means the switches will have no rows in the table)
• will still make the topology

dpctl dump-flows tcp:127.0.0.1:6634

• tcp:127.0.0.1:6634 is the local address that the port is listening to the control channel.
• the result is that there are no rows

h1 ping -c 3 h2

• the host will be unavailable (because there is no rule within the switch to tell it how to process the packet).

dpctl add-flow in_port=1,action=output:2
dpctl add-flow in_port=2,action=output:1

• what ever you get in port 1 should be sent to port 2.
• the match (we use the port) and then the action (we use output)
• after this, when we ping, it will be reachable.
• if you send something from host 1 to 3 it will be dropped because there are no connections.

dpctl dump-flows

• shows all the details about the switch

SDN Controllers

There are many SDN controllers: NOX/POX, Ryu, Floodlight, OpenDaylight

• Your choice can depend on the desired performance, the programming language you are familiar with, learning curve, user base and community support. Southbound API and Northbound API / policy layer. Education, research, or production?

NOX:

• first gen openflow controller
  • open source, stable, widely used
• Event based.
  • fill in the methods of each event your controller supports
• c++, fast, clean codebase, well maintained, and supported
• Use if:
  • you know c++
  • willing to use low-level facilities and semantics of OpenFlow
  • good performance

POX:

• advantages: widely used, maintained, and supported. easy to read and write code
• disadvantage: performance
• good for:
  • research, demonstration

Floodlight:

• Open source java controller
• good northbound api
• good integration with REST API
  • pluggable with industry
• production-level performance
• disadvantage: steep learning curve
• when to use:
  • java
  • production performance and support
  • use REST API to interact with the controller

Writing a Hub in POX

A hub is a dumb switch. When it gets a packet, it doesn't know where it should be sent so it will be flooded to all ports.

• no forwarding information at the switch
• cd pox && ./pox.py forwarding.hub

def _handle_ConnectionUp (event):  
	msg = of.ofp_flow_mod()  
	msg.actions.append(of.ofp_action_output(port = of.OFPP_FLOOD))  
	event.connection.send(msg)  
	log.info("Hubifying %s", dpidToStr(event.dpid))  
def launch ():  
	core.openflow.addListenerByName("ConnectionUp", _handle_ConnectionUp)  

• launch() function calls ConnectionUp.
• To insert a rule we need ConnectionUp, which is the first event that happens. With this, it knows that there is a connection that needs to be set up. The first function
• In this handler, there is no match parameter
• ofp_action_output specifies the type of action. of.OFPP_FLOOD is pre specified to flood.
• We specify the output name
• there exists a connection between the controller and switch. event.connection.send will use that connection to communicate.
• When ever a switch gets a packet they don't know how to route, they will forward it to the controller.

A Learning Switch

The hub doesn't store information in the switch. it simply floods. what if we want to learn? What if we want a layer 2 switch? reads the MAC address.

• you want to have a table that maps the mac addresses to the port number that the hosts are connected to.
• whenever you receive a packet, you know the source mac address and port. this is what you should store.

Implementation:

• switch table is initially empty
• for each incoming frame, store
  • the incoming interface from which the frame arrived
  • the time at which the frame arrived.