Network Service Innovation with SDN and OpenFlow

In an age where subscribers want to be able to dial up new services in minutes, the Layer 2-Layer 3 networking model doesn’t work very well, and it’s expensive for service providers. While it works to connect people to each other, it doesn’t work for adding or changing services.

For service providers, automation and self-service portals are the key to reducing operating expenses (OpEx). If customers could be empowered with self-service dashboards (see Figure 1, previous page) where they could dial up services, service providers would gain the ultimate in service agility while reducing their own spend on re-configuring the network. Policy-driven networking makes that possible.

SDN and OpenFlow are the basis of policy-driven networking. Building upon the foundation of Layer 2-Layer 3 networking, SDN is an additive technology that allows network administrators to solve problems that are difficult to solve with switching and routing. For example, SDN can drastically simplify the implementation of policy-based networking by letting a service provider apply a specific policy for a specific person or application.

SDN: Meter, Match and Act

Meter, match, and act are the three steps SDN takes to do something in a policy-driven network. SDN allows providers to meter traffic conditions, application and user behavior; to match those conditions against a set of pre-defined criteria; and then to act on the match according to a policy. Part of a policy framework is to pre-set conditions you meter against.

Figure 2: OSI Model and Policy-Based Networking

Service providers are looking at SDN and OpenFlow to achieve this level of automation and granular control. The network uses Layer 2 and Layer 3 protocols as the baseline transport, and OpenFlow rules are used to define the exception-based forwarding that end users want (Figure 2).

At the end of the day, networks are traffic engineered to drive behavior, paths or quality of service. A VPN between a private and public cloud or a disaster recovery (DR) as a Service (DRaaS) overlay are good examples of services that today depend on good old traffic engineering. Today this is done through BGP confederations or MPLS FEC marking. They work, yes, but these processes are manual and time-consuming to change. Therefore, they are not dynamic or easily modified on demand.

How SDN Helps

Software-defined networking (SDN) delivers the ability to dynamically and externally program network devices in real time, through emerging standards like OpenFlow. Traffic engineering can now be taken to a new real-time level, where it implements a method of optimizing network performance by analyzing, predicting and regulating the behavior of data transmitted over the network. For latency-sensitive applications such as voice traffic, SDN-driven traffic engineering ensures good QoS by dynamically programming the fastest path for that application’s traffic flows to traverse.