Extending SDN Architectures with F5's L4-7 Application and Gateway Services

Introduction

Delivering applications with software-defined networking (SDN) architectures requires more than the packet-oriented delivery capabilities provided by L2–3 and overlay networking SDN technologies. To deliver and secure applications, a network built using SDN principles must be able to act based on the constantly changing state of flows (for example, TCP), the application-layer messages transiting the network, and the semantics of communications. F5's complete portfolio of L4–7 application and gateway services extends the capabilities available to architects who are designing and implementing their networks using SDN architectural principles.

What Is SDN?

Many organizations have become interested in software-defined networking, but don't have a clear understanding of what comprises an SDN architecture or why the architecture is the way it is. The challenge is that the market's attention on individual technologies such as OpenFlow and overlay networking has limited the conversation—to fully understand SDN, one needs to examine the architecture as a whole. The most important thing to comprehend is that SDN is an architecture, not a technology. It is a way of systematically designing networks from the ground up based on the key concept of centralized control over forwarding elements. For example, one cannot simply add an SDN component such as VXLAN to an existing network and call it SDN if the rest of the network doesn't implement SDN architectural concepts.

The Open Networking Foundation (ONF) defines an SDN architecture as being directly programmable, agile, centrally managed, programmatically configured, and based on open standards that are vendor-neutral. All of these attributes are important building blocks for implementing an SDN architecture, but they fail to deliver a clear understanding of the value that an SDN architecture brings to an organization.

After listening to customers and the market, F5 defines SDN as an architecture for designing networks that reduces operating expenses by centralizing control into a distinct control plane (controller) that programmatically configures and extends all network data path elements and services via an open API.

Note that both definitions are deliberately neutral with respect to technologies as well as what layers of the network the architecture applies to.

Extending SDN Architectures

Recently, the market and the ONF have begun to expand the dialogue around SDN, from defining and implementing the building blocks for L2–3 networking and overlay networking to including the additional capabilities that exist beyond layer 4. The ONF's Architecture Working Group has a project specifically looking at the requirements for L4–7 SDN in order to define the attributes necessary for networks built using pure SDN architectural principles to have parity with networks built without them.

The big question is how do you meet the open API requirement encouraged by the ONF given the complexity of services operating at L4–7?

The answer lies in F5's application and gateway services. These L4-7 services have offered publicly documented APIs for complete programmatic configuration (F5 iControl and iControl REST) since 2001 and have been directly programmable (F5 iRules) since 2004. These APIs have allowed F5 products to be integrated into a variety of orchestration and management systems—that is, controllers with awareness beyond the network.

F5 also offers a broad spectrum of services deployable using SDN architectural principles, from application delivery to security at all layers of the network stack. SDN-specific services include:

• SDN controllable/orchestrateable APIs

  F5 products built on its TMOS operating system support the iControl, iControl REST, and F5 iCall APIs. The iControl pair of APIs allows the control plane to directly interact with the system by pushing configuration and pulling telemetry. The iCall API allows the system to call out directly to the control plane—similar to OpenFlow's controller-callout hook. Non TMOS-based F5 products support equivalent APIs (e.g., REST) for remote control/orchestration.

• Integration

  The F5 family of APIs (iControl, iCall, REST) allows F5 products to be fully integrated with 3rd-party orchestration systems. For example, F5 and VMware have integrated F5 Enterprise Manager with vShield Manager so that configuration information can be controlled by vShield. Additionally, IBM recently released their Content Pack for F5 BIG-IP Load Balancer for their IBM SmartCloud Orchestrator (SCO), which allows the SCO system to programmatically control F5 BIG-IP Local Traffic Manager.

• Extensible/programmable data path API

  TMOS-based products support iRules, which allows the control system to push specialized business logic that can modify and extend data path capabilities (making the network directly programmable). Other offerings have integrated the more vendor-neutral node.js JavaScript API or Groovy as their extensibility API, which facilitates the insertion of advanced capabilities into the data path. It is an important tenet of the ONF's definition to expose the underlying data path elements to the control plane.

• Overlay networking bridge/gateway

  TMOS-based products are the first in the industry to natively integrate with many major overlay networking technologies, including VXLANs. This allows F5 to act as a bridge between networks (including pure Ethernet networks), between each other, or to local services.

Conclusion

As SDN discussions move to include production deployments involving applications, the dialogue has naturally broadened to encompass the direct integration of higher-layer services (layer 4 and beyond).

F5 has been delivering the core principles behind SDN architectures as common features (iControl, iRules) across their entire product portfolio since 2001. Recently, the addition and integration of overlay networking (for example, VXLAN), push-based notifications to the control plane (iCall), REST-based APIs including iControl-REST, and extensibility (via node.js, Groovy) has extended their history of helping organizations implement SDN architectures.