40. IFloodlightModule Interface
1. getModuleDependencies()
Function Description
What services does this moduleWhat services does this
getModuleDependencies()
require?
module require?
2. getModuleServices(), getServiceImpls()
Services does this module provide and how?
getModuleServices() Services does this module
provide and how?
3. init(FloodlightModuleContext context)
Internal, before dependencies have init()’d
init(FloodlightModuleContext context) Internal, before dependencies
have init()’ed
4. startup(FloodlightModuleContext context)
External, with dependencies initialization
startup(FloodlightModuleContext context) External, with dependencies
initialization
Much of traditional networking was designed in the 1970’s. The protocols and standards have evolved and proved amazingly resilient – but they are non-ideal for the challenges of modern datacenters. First, they are based on merged hw and software solutions.Second, they are based on fully distributed protocols. This made tons of sense in the early days of the internet but in a world where a datacenter admin knows every piece of hw and how its connected, distributed protocols are less helpful.
SDN separates networking into 3 tiersA data plane tier responsible for fowarding packets.A controller thatmanagesconections to each forwarding element and acts as a network os.Applications which input control logic.
People often conflate SDN and openflow. They are very different. OpenFlow is a protocol for switches commnicating with a controller. Its often a piece of an sdn architecture but techically isn’t required. In fact, there is also work being done on northbound api as well.
Network virtualization is one of the most interesting examples of SDN in the real world. In involves slicing a physical network into multiple logical networks and offering isolation between. In the server world, this has shown huge operational efficiency gains and it offers similar promise in networking.Network services - Example – instead of inserting and configuring a firewall, you could just tell your controller to automatically provision rulesVM mobility and management – Virtual machines have greatly increased the complexity in the network. They get spun up and down and even can be moved around while running. SDN offers the flexibility to have the network respond quickly to changes in vm state and offers a lot of operational efficiency. CLOS – SDN and Openflow offer very flexible forwarding paradigms. One of the thing is allows is the creation of relatively low cost non-blocking clos networks for high performance environments. Data analysis – OpenFlow also makes it possible, in fact easy, to get lots of real time information about a running network. The switches and controller maintain a rich set of stats but also make it possible to direct traffic to montioring devices much the way tap or span ports would.Networkvirtualiztion - huge operational benefits - puts all policy in one place. Great for audit. - also manages p and v togetherVirtual machine management - makes it eaier to tie polcies to a vm because you can track a mac trhoughout the network - IP address is stored in the vm. Can’t change it. SDN makes it easier to alter the network around this.Vlans – still require administration
Lets look a little more deeply at the OpenFlow protocol. It has 3 main componentsA controller, which we’ll talk a lot more about in detail. The controller handles all the control logic for the network.A potentially encrypted control channel to a switch.An openflow client running on a switch. This handles controlling the openflowdatapath.
Many people ask us why OpenFlow is used so heavily in SDN. Essentially,OpenFlow is one of the simplest lowest level abstractions available. It allows very fine grained control over forwarding and separates control and data.
OpenFlow 1.0 was the initial openflow spec. Its largely what is supported today in hardware and vswitches. OpenFlow 1.1 introduced a new concept of multipe tables that could be processed sequentially. This solved some of the space explosion problems the intial spec had but introduced new problems in hw.1.2 – ipv6. Generalized match – TLV based
How of works with non oF?Think through control network and data path. Have a separate network for controlUse vlans to separate control and data.Switches supported today:Stanford: - HP, nec,ibm, prontoWifi – meraki, othersWhat openflow provides that non-OF provides- Visibility- Managebility – scripts running along with OF controller to monitor packetin rates, flow mods, flow table size. Cpu usage, datapath throughput. Can monitor who is connected and how many users in network. With meraki, can know what type of devices in network, throughputHow reseasrchers can benefit?Primary reason for stanford. Enable sdn-based research. Link to internet2/geni. Migration process? Strategy?Understand traffic pattern first. Current hw has limitations on throughput (esp true of hp) on the control plane side. Flow set up rate, etc. HP offers only IP matching only in hw. Deploy from edge to core. We support switchclusters. Do it floor by floor essentially. Stanford runs two networks in parallelVoip and other key services is non-OF at least. Start with non-ciritcal traffic. Security?Highlight new visibility capabilitiesDenial of service on controller, etc.Encrypted control channels – no one does this todayInteropability of openflow and wifi? - mesh networks and host mobility create tricky situations.
Our topology, device manager know about host attachment points and make it possible to deal with integrating openflow and non openflow networks.