SDN basics for service providers
A comprehensive collection of articles, videos and more, hand-picked by our editors
The mission of an OpenFlow software-defined networking (SDN) controller in a standard architecture is to convert
a route -- a path between two points in a network over which traffic can flow -- or related sequence of device-forwarding behavior into specific forwarding changes.
All SDN controller applications will require a network map of the domain the controller manages. This map would be used to identify the specific devices in the network so that when a route is created, it can be dissected into an ordered list of devices. Using that ordered list of devices, the SDN controller is then able to thread the route through the network. The network map must logically show the device and connecting trunk topology of the network, and for some applications, it should also record the status of each device and trunk. How the application uses that map is what dictates the service SDN can provide.
More on SDN for cloud providers
Learn the three primary models of SDN
What's holding up SDN adoption by cloud providers?
Why SDN may hold the key to hybrid cloud networking
There are three broad sources for route information that could drive an SDN controller application: explicit provisioning instructions, "route sniffing" from adjacent network components and path computation. It's very possible that all of these route sources might be present in a single network, so it's important that all these SDN controller application types be considered and supported, at least by the controller's northbound application programming interfaces (APIs).
It is worth noting, however, that because there are currently no standards for northbound APIs and no completely accepted standards for network status monitoring or control of SDN devices, SDN controller applications are likely to be specific to the controllers for which they are written. Until a broader set of standards emerges, cloud providers will have to be careful in selecting controller and application packages that fit their needs.
Route provisioning is the easiest of the SDN controller applications. A network operator could use a simple graphical application to identify a string of device or trunk hops that create a route. Such an application could be driven from a cabling diagram in a data center to create a software-defined data center network, for example.
The route-provisioning application could also be used to create SDN-controlled trunks provisioned as part of network services. If network status information is available in the map, the application could alert the operator to route hops that might involve congested or failed resources. Route provisioning is also the basis for network segmentation, or "slicing," which is the subdivision of a network into independent subnetworks. This application is crucial to networking in cloud data centers and may also have value in VPN/VLAN applications.
Route sniffing is the process of learning route requirements from adjacent devices or higher protocol layers. In controller applications where SDN technology forms the core or lower layers of a network, the software-defined network can appear either as a transit network (a core IP element) or a physical layer path. If the software-defined network "edge" can read the route advertisements of external networks connected to it, then an SDN controller application can construct the routes needed to connect each neighbor network with the others and advertise these routes. This is essentially the SDN application Google uses in its well-known SDN deployment.
There are several approaches to route-sniffing, including having the software-defined network's edge elements emulate a router and receive route advertisements. Another approach is to have a software element in the router send router advertisements to a central SDN controller application. There are also enhancements proposed to the Border Gateway Protocol (BGP) to allow it to be used to "sniff" route data and even to create a central route reflector, in which route information can be collected and distributed. The SDN controller application would use these enhancements to BGP to build routes in the SDN portion of the network.
It's critical that any user of an SDN controller understand how control paths will be maintained.
The most complex SDN controller application is one that actually does path computation, which determines a route based on service needs, network topology and resource status. For this type of application to work, it's necessary not only to have a network map, but also to populate the map with information on where users are connected and the status and traffic loads on devices and trunks. The map may gather this type of telemetry from current management systems and device interfaces like SNMP and RMON, and also from probes inserted at various points in the network.
A current IETF project called Infrastructure to Application Information Exposure is seeking ways to deliver information from network infrastructure to an application, which in this case would be the application creating and maintaining the network map. The same project could also provide network state or status data for the other SDN controller applications discussed above, which would enable automatic routing or route verification based on network data.
Early SDN controller applications are almost completely confined to the data center, where providers can use OpenFlow to create partitioned and traffic-engineered virtual LANs for the purpose of containing users and applications and limiting interaction. Some controller vendors also provide monitoring applications, which can tap flows for analysis and improved network visibility.
The monitoring application highlights a potential issue that all SDN controller applications must address: maintaining control paths through network startup, device configuration and failures. Because centrally controlled networks don't automatically adapt to topology changes, it's possible that a new device or a network failure would result in one or more devices with no OpenFlow path back to the SDN controller. This would make it impossible to update the device's forwarding table, which might then make it impossible to create a path to the device over which OpenFlow could pass.
It's critical that any user of an SDN controller understand how control paths will be maintained. Even starting the network from scratch might require extensive coordinated action to instruct each node how to forward commands to the next.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecom and data communications since 1982.