Challenges of OpenFlow Paradigm Expansion

Exploring OpenFlow alternatives: BGP-LS, OpFlex, VxLAN, LISP, I2RS.

The growth of interest to virtualization, cloud computing and continuous market demand of new services is entailed by the discussions on the networking evolution in the nearest future. As a result, more and more telecom market players become fans of Software Defined Networking (SDN), announcing their upcoming solutions that follow this trend. Also, we’re witnessing the evolution of transport protocols that would satisfy the SDN-based requirements of decoupling the control plane operations from the data transfer.

OpenFlow – A “de facto” standard

One of the most promising protocols is OpenFlow, a standardized protocol (currently v.1.4.0) which has evolved over past two years and is starting to support in solutions of some vendors. OpenFlow-based products follow the client-server architecture, thus delegating most complex (and resource consuming) operations to one or a few (in complicated use cases) designated server elements, and hardware running as a thin client (data plane with much simpler software ruled by the server logics). These two components communicate over a Secure Channel and using a standardized messaging protocol, allowing to seamlessly:

• Integrate or test new protocols (e.g. for routing, administration etc.) without impacting live traffic flows;
• Apply changes to network configuration on the LSP;
• Control and visualize the statistics (per link, protocol, traffic type/class and such).

However, despite all the widely-advertised pros of the OpenFlow protocol, many data centers, traffic operators, and other potential customers may feel that it does not satisfy their requirements of transition to SDN. Some of the risks of using OpenFlow are described as CAPEX and OPEX in case of:

• A need to purchase new client and server hardware supporting OpenFlow protocol using ASICs;
• Purchasing licenses for OpenFlow software solutions (hardware dependent) from HW vendors.

According to up-to-date vendor announcements, OpenFlow software is being developed as:

• An application that is basically an abstraction layer wrapping the existing stack of network protocols API (both standardized and proprietary);
• Software with a reworked control mechanism using application layer control (L7 in OSI model) instead of L2-L4 layers.

Looking for other ways

Analyzing these trends, many try to work around OpenFlow protocol and, at the same time, to get the desired bonus SDN services using other control protocols. Below is a brief list of some of the currently available non-OpenFlow protocols for SDN.

BGP link state protocol (BGP-LS)

BGP link state protocol (BGP-LS) – allows high flexibility in network topology setup by allowing an operator to:

• Manually override automatically chosen LSPs;
• Choose a preferred path selection algorithm;
• Support Route Reflection;
• Advertise or hide specific links;
• Build topology without L3 adjacencies;

BGP-LS could be estimated as an SDN messaging protocol candidate due to:

• Its standardized messages;
• Popularity of BGP protocol (many network engineers are BGP-aware);
• Protocol scalability (incremental extensions are possible: NLRI, Path Attributes.

There are some factors that might demotivate customers to implement BGP-LS as an SDN control plane protocol, mainly because it:

• Requires BGP running on the node (expensive hardware with high computing abilities);
• Delegates path computation to a remote/virtualized element (PCE), additional OPEX;
• Proprietary protocol for now, though on its way to standardization (started in 2005).

OpFlex

OpFlex – a protocol suggested by a number of vendors inspired by Cisco. Currently it is under review for IETF standardization. OpFlex idea is to serve as a policy declaring protocol for the intelligent network devices (both physical and virtual). The policy contents are abstract and bear information about the allowed nodes interactions (groups of endpoints and a model of each group participants). Every policy is stored in Policy Repository and transferred to each network node upon request from the endpoint. Once the relevant policy subset is received on the network element, it is rendered by an abstraction layer called Policy Element (PE). This client side application transforms the brief policy contents into a node-specific model (VLANs, links, interfaces) that is then deployed in the device hardware. Another important element in the protocol operation structure is a dedicated server side database collecting OAM&P statistics.

As it seems, one of the bottlenecks of OpFlex is providing a PE application to each endpoint in the network topology. Often it is different vendors that would have to develop such product and incorporate it into their firmware updates for existing or new products. Thus, it may take time for OpFlex controllers to get a fair share of SDN market due to lack of client side solutions. Nevertheless, a number of vendors already pledge to support OpFlex protocol, and invest into the researches.

VxLAN

VxLAN – Virtual eXtensible Local Area Network

The idea beneath VxLAN is to present network nodes as virtual containers that are logically isolated from each other, but share the physical network.

VxLAN is an L2 overlay abstraction over an L3 network using MAC-in-UDP encapsulation. VxLAN allows interconnecting over 16 million virtual L2 segments in the flexible, scalable network by encapsulating data frames in a UDP packet along with a 24-bit segment identifier that provides a logical network (alike VLAN) and defines the bridge domain.

VxLAN tunnel endpoint (VTEP) is a means of interconnecting virtual containers by performing encapsulation of data packets. It uses the IP address designated to the L3 interface to encapsulate data frames and then transmit them to the transport network through the IP interface. Also, VTEP entity is used to discover its neighbors and learn MAC addresses designated to remote VTEPs in the VxLAN segment (VNID).

LISP

LISP – Locator/ID Separation Protocol

The idea of LISP architecture is to encapsulate/decapsulate the data packets using two L3 namespaces: one for the endpoint addresses (EID) database, and another one for IP addresses of the LISP routers (RLOC) designated to specific endpoints. These two namespaces are meant to be mapped accordingly, thus providing a means of forwarding the traffic according to the chosen policy.

The LISP-based infrastructure contains the following entities:

• Ingress Tunnel Router (ITR), LISP edge site device designated to encapsulate packets from internal endpoints (site-facing interfaces) and direct them to remote LISP sites, or natively forward the packets destined to non-LISP sites.
• Egress Tunnel Router (ETR), a device designated to either de-encapsulate LISP packets received from the Internet, or deliver them to local site EIDs.
• Alternative Topology (ALT), a logical topology element that aggregates EID prefixes. It is deployed as a BGP-over-GRE tunnels, using dual-stack L3 (IPv4 and IPv6). The device should support both BGP and GRE protocols.
• Map Server (MS), a LISP network component that controls and authorizes EID prefixes reservation for specific LISP site. In addition, the matching authentication key must be configured on the ETR.
• Map Resolver (MR), a device that operates the map requests from ITRs. It can also be configured in a way to forward map requests to ALT entity. If an ITR queries for non-LISP address, MR responds with a Negative Map-Reply.

Thus, the LISP network helps its users to configure quite flexible, multi-homing, policy-based networking system that can:

• Interconnect IPv4 an IPv6 network segments;
• Enable support of “extended subnets” and “across subnets” (using EID prefixes management);
• Lower the OPEX by using existing networking hardware with most common features support;
• Help to organize high-scale data center virtualization with encryption (VPN support).

Some vendors have already recognized LISP protocol as a transition mechanism to IPv6 networks and making L3 routing easier by reducing routing table size.

What does the LISP map contain?

The map-and-encap idea of LISP protocol is based on registering the following network interface attributes:

• Host addresses
• Routing base
• Traffic engineering policy
• Access control policy.

The Interface to Routing System (I2RS)

The Interface to Routing System (I2RS) initiative, a protocol that opposes OpenFlow (based on centralized decision making), a young SDN market player (started about November 2012). It suggests continuing using the current set of protocols in large-scale networks, and letting decentralized client-side software to control the network configuration parameters by reacting to network events. In order to retrieve the routing information and network topology from the network nodes, the I2RS agent has to be implemented there.

Since the I2RS works in a decentralized way, it requires the agent software to be robust enough to operate hundreds of requests by second with minimum blocking between commands (by locking only the required set of data to perform requested operation) and arbitrate the requests to avoid the conflicts (policy based).

It is still to be estimated if I2RS will be adopted by the vendors and the network society, and if the protocol requirements could be met without a compromise to control, security and usability.

Conclusion

Currently we witness the dynamic growth of SDN networking and the progress in the researches of SDN southbound protocols.

Some protocols are proprietary and do not have an open API. This may slow down their expansion in the global market. Proprietary solutions happen to limit interactions with third-party products due to protocols licensing, and companies target to develop their own brands to the max. But the global tendency seems to be the development of open, standardized protocols that will be integrated by many vendors and thus provide high interoperability of the physical and virtual network elements in the Internet, customer data centers, and large enterprise networks.

In spite of the fact that the SDN paradigm was presented just several years ago, some SDN solutions are already presented. Each of them urges to visualize advantages of SDN usage in their specific southbound implementation. And as they will gain more and more followers, we will notice the preferences of the network society. Only those solutions that stake on proper network-demanded features, will survive the test.