In collaboration with Cisco Systems, ConteXtream has contributed a LISP-based mapping service to the open source SDN project OpenDaylight that enables the federation of SDN controllers across a WAN.
ConteXtream is an Israel-based SDN startup whose business focuses on service provider networks, and which modified Cisco's Location/ID Separation Protocol (LISP) and built the LISP-based mapping service to enable network functions virtualization (NFV) orchestration through federated SDN controllers.
Cisco created LISP to support the mobility of networked devices and objects on a routed network. With LISP, those objects, whether they're virtual machines or smartphones, don't need to receive new IP addresses when their physical location changes. Routers can use LISP to maintain maps of the locations of mobile devices and virtual machines, and they can consult those maps to create new packet headers before forwarding packets to the device or object that has moved. ConteXtream is embedding the mapping capabilities of LISP into SDN controllers for NFV orchestration.
LISP mapping for NFV orchestration and scale
NFV allows service providers to run network functions on commodity servers rather than on large dedicated appliances, which saves money and improves network agility. On the flipside, NFV also makes the network more complex. Once those network functions have been removed from large appliances, service providers need a way to direct traffic through the right chain of virtualized network functions.
Service providers use large appliances, like those supporting the Evolved Packet Core architecture in an LTE network, because they are natural junctions on networks, said Sharon Barkai, co-founder of ConteXtream. Traffic from millions of subscribers passes through a single box, so it makes sense to apply as many network functions as possible as the traffic passes through it. With NFV, virtualized network functions are no longer directly in the traffic stream.
"[Virtual network functions] are not network junctions. They are compute clusters that you need to steer traffic to and away from," Barkai said.
Service providers can use SDN controllers to steer traffic to the right NFV functions, but scale and resiliency remain challenging.
"A centralized controller in SDN pushes commands to links hop by hop," Barkai said. "That kind of design has a lot of fragility and scaling issues, while a distributed model that has a lot of smaller, local controllers making local decisions based on global mapping information is a lot more resilient."
ConteXtream has adapted LISP for mapping virtual network functions on service provider networks. Embedding a LISP-mapping service into an SDN controller, in this case the OpenDaylight controller, allows multiple controllers to share information with each other and map each other's locations and activities. The network can learn which controllers are managing which services and functions on the network.
Other contributions to OpenDaylight Project
Plexxi contributes application affinity service to OpenDaylight
Engineers contribute Open vSwitch management to OpenDaylight
Radware contributes anti-DDoS technology to OpenDaylight
In other words, while a southbound protocol like OpenFlow allows a controller to issue flow definitions to a switch or router, the LISP-based mapping service allows a controller to share what it's doing with other controllers.
Service providers can federate their SDN controllers with the LISP-based mapping service in OpenDaylight. That federation adds resiliency to the network by enabling failover between controllers, but it also allows controllers to specialize in various functions, Barkai said. One controller on the network can devote itself to orchestrating NFV for content, while another can orchestrate NFV for mobile subscriber information.
"If I have an OpenFlow controller and there is traffic arriving for a mobility service, I need to look up where the mobility services [are]," Barkai said. "I need to access [the map of those services], but how does the data get there? Who puts it in there? The answer is other controllers."
Components of LISP mapping service in OpenDaylight
ConteXtream has contributed two pieces of code to OpenDaylight to make this technology work. The first is a mapping system embedded into the heart of the controller, enabling it to pull mapping information from other controllers to build a global, LISP-based map. The second piece of code is a series of plug-ins that helps a controller make decisions about specific applications as traffic arrives.
ConteXtream built its OpenDaylight contribution to be extensible so other vendors can build and enhance the technology and create their own product offerings.
"We put in a basic mapping system that will scale out to hundreds of nodes and multiple geo-locations, but people have the ability to plug in other database technologies underneath. Do you want mapping distribution to be a directory like DNS, or do you want it to behave more like a distributed hash table? We also gave a basic flow handler [plug-in] that gives you the ability to manage virtual Layer 2 and Layer 3 -- the classic use case of SDN that allows you to move VMs [virtual machines] around within the data center and across data centers," Barkai said. "We didn't give, for example, specific flow handles to virtualize Evolved Packet Core or to virtualize elastic caching or machine-to-machine applications."