SDN startup Plexxi has contributed code to the OpenDaylight Project, which enables networks to understand application requirements.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"Our goal with our commercial product was always to allow people to describe their [networking requirements] in the terms of application loads and not networking speak," said Mat Mathews, co-founder of Plexxi. "The metadata service is essentially that aspect of our technology -- the ability to describe the needs of the [application] workload in those terms."
The affinity metadata service functions like a northbound application programming interface on the OpenDaylight SDN controller. It is the front-end language that Plexxi built to allow applications to communicate with networks via an SDN controller. This language consists of three general constructs that enable applications to describe themselves and their needs to the network.
"There are affinity endpoints which could be compute nodes or storage nodes. There are links, which are the relationships between those endpoints. Then there are attributes, which are the qualities of those links that need to be adhered to by the infrastructure. You can think of it as a schema and a way to populate the schema through a semantic language."
Network infrastructure can potentially use affinity metadata on the OpenDaylight controller to create VXLAN or NVGRE tunnels automatically for specific applications. Applications could also request configuration changes to VLANs or trigger the provisioning of new Layer 4-7 services.
"Once you have affinity metadata, certain infrastructure will have capabilities that other infrastructure doesn't have. For example, our infrastructure can change physical topologies by moving light waves around and making low-latency hops for certain workloads," Mathews said.
Metadata may sound daunting to some network engineers, who may resist working with systems engineers to manually populate databases with application requirements.
More on OpenDaylight
Big Switch Networks pulls out of OpenDaylight's inner circle
Maintaining transparency at OpenDaylight
"Affinity can be done manually or auto-populated based on information that already exists," Mathews said. "Affinity knowledge is really nothing new if we're capturing that information when we do things like orchestration. If I set up an [Information as a Service] portal and give my users the ability to set up a workload with virtual machines and storage resources, those are things that naturally have an affinity to each other. You can capture that these things are related to each other and anything that might be specific to their requirements. That can be automatically imported into the [affinity] database."
Affinity metadata opens up a new field for competition among networking vendors. For instance, Plexxi writes algorithms for taking advantage of that metadata. Then it builds switches that can respond to instructions generated by those algorithms. Other vendors can do the same. While Plexxi's technology uses affinities to manipulate the lower layers of the OSI stack, other vendors might develop algorithms that manipulate Layer 4-7 services such as load balancing and application acceleration.
"Just understanding the data model is pretty interesting. We don't think about data models in networking today," Mathews said. "We think about packets, protocols and headers. We've taken out the context for what we're trying to do."
Affinity networking allows you to have that context. "Say I'm building a load balancer service in OpenDaylight. Instead of just looking at the packet to figure out how to intelligently distribute flows across a set of servers, why don't I look in the database and see what things are related … and use that information to do load balancing," explained Mathews. "It's not just that these things need to be evenly distributed across the servers. Affinity might give me additional information about what those services are and what they might expect from an end user's [service-level agreement] perspective."