by Calvin Chai
There’s a lot of talk about OpenFlow as an evolving architecture for driving software-defined networking (SDN), but so far much of the action has been around development rather than deployments, and most of the deployment activity has been in the data center. In this article, we’ll look at some real-world examples of OpenFlow and SDN in action in the larger network.
Disaggregating the Network
Implementing open networking solutions is a matter of disaggregating the network. Historically, networking has been done through a series of vertically integrated systems. Major networking equipment vendors sell tightly integrated switches, routers, and line cards, and provisioning the network means manually configuring each network element.
In OpenFlow-driven SDN, the model is to disaggregate, to use standardized building blocks to create solutions. End users and subscribers want to change applications, raise or lower bandwidth limits, or choose the speed of their connections, and manually configured networks simply can’t respond quickly enough. OpenFlow-based SDN delivers policy-driven networks where network settings are reconfigured on the fly via the OpenFlow controller, and OpenFlow is the common control protocol between all of the disaggregated parts (network operating system, or NOS, controller, and applications).
Meter, match, and act are the three steps SDN undertakes to execute tasks in a policy- driven network. SDN enables the metering of 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 that are metered against. So, for example, if a customer uses a home interface to ratchet up bandwidth, the OpenFlow controller receives this input and automatically delivers more bandwidth to that subscriber. If a network must scale to support more users, the OpenFlow controller can add routes, VLANs, and flows through the network switches.
In a way, disaggregating the network is tearing it down in order to build it up again in a more useful, flexible, and dynamic way. Now, let’s look at OpenFlow and SDN applications in action.
A Subscriber Control Panel
An Asia-Pacific service provider offers its subscribers a choice of price, performance (bandwidth, latency, and throughput), and security settings. To scale this offering, the provider needed to automate the process so that network throughput, for example, could be changed remotely and quickly through a subscriber action.
Specifically, the service provider wanted to enable:
SDN enables these services because traffic engineering is based on policies derived from inputs to the customer portal. A graphical slider like the one in Figure 1 drives requests to the OpenFlow controller. Moreover, SDN enables seamless public and private cloud-bursting and migration, turning up more capacity automatically as needed.
Figure 1: A self-service control panel allows customers to dial up bandwidth from home or office.
The critical customer requirements for this use case were a combination of OpenFlow and legacy protocol support. Specifically the customer wanted integration between MPLS and hardware-based OpenFlow. The rationale followed what Google published in January 2011. Specifically, OpenFlow reprograms MPLS labels as a result of a policy, triggering the need to change a path for a giving traffic flow. The policy would be governed by the slider input from the control panel. From a traffic engineering perspective, paths would be chosen to ensure the path selected delivered the expected SLA.
The customer had also tracked OpenDaylight (ODL) development and felt that it was the best controller for their needs. Pica8 was the best choice for this SDN project since the Pica8 NOS, PicOS, supports OpenFlow 1.4, is integrated with ODL, and has support for MPLS.
Turning Up Bandwidth to Rural Subscribers
Renewed popularity of fiber to the premises (FTTP) for homes and small businesses is enabling municipalities and regional governments to reduce the “digital divide” and provide high-speed content and services to rural areas. Customers want to apply the “App Store” model at home for selecting content and bandwidth services, but bandwidth requirements and capabilities vary widely across the region.
Rather than manually provisioning VPNs to customer premise equipment (CPE), this regional service provider used OpenFlow to set up virtual CPE (vCPE) that can dynamically adjust bandwidth and services under user control. Two other services users desired were on-demand disaster recovery (disaster recovery as a service, or DRaaS) and hybrid cloud services for small businesses.
In this case, the vCPE can offer advanced firewall services in addition to dynamic VPNs offering DRaaS. Scalable liquid bandwidth is guaranteed as part of an SDN access network.
For this SDN deployment, the customer was keen to offer “smart city” services by leveraging existing infrastructure to minimize CapEx of new SDN services. At a fundamental level, service redundancy was desired to ensure Telco-like resiliency, thus redundant hardware was used throughout the topology. Hardware-based OpenFlow, driven again by ODL, was selected based on the customer’s involvement with this community.
Lastly, PicOS was chosen as it supports a rich set of Layer-2 and routing features including OSPF and BGP. This support ensured integration of the service edge based on white box switches with upstream Cisco and Juniper aggregation and core devices. The integrator for these smart cities additionally leveraged virtual CPEs (vCPEs) on hardened services to deliver high touch services on top of the liquid bandwidth services.
Maintaining Competitive Video Service
A North American satellite broadcast media provider faced increasing competition from over-the-top (OTT) providers and other cable and satellite broadcasters, and wanted to improve the speed, ease, and quality with which its services could be delivered. Customers were demanding an app-store, point-and-click content selection model, but a manually provisioned network couldn’t deliver this functionality. Self-provisioned networks would meet the demand, and they would also reduce the need for truck rolls and significantly lessen churn caused by long waits for new services or upgrades.
The solution was to implement self-service provisioning with point-and-click content selection via OpenFlow. The tight integration of OpenFlow and the current multicast environment drives rapid ROI and ensures smooth integration.
In this last deployment scenario, the customer was particularly interested in leveraging hardware-based OpenFlow in conjunction with the ONOS controller from ON.Labs, now governed by the Linux Foundation. As with the other two examples, integrating the new SDN functionality with legacy protocols was key. Here, since this is a media / video streaming application, multicast support was mandatory and PicOS has a suite of multicast support protocols, including IGMPv3, PIM-SM and PIM-SSM.
Lastly, integrating the new SDN functionality into existing OSS / BSS frameworks was accomplished through standard APIs.
OpenFlow is Driving Real Applications Today
As we have seen, OpenFlow-based SDN applications are increasingly driving customer satisfaction and service provider revenues in the market today. Networks are becoming more flexible in an era of on-demand computing, bandwidth, and services; and megatrends like mobile usage, Big Data, and the Internet of Things will continue to drive a need for network scale and agility. By breaking monolithic networks apart and building solutions with OpenFlow and SDN, network operators can be ready for the future.
About the Author
Calvin Chai is the Head of Product Marketing for Pica8 Inc. Prior to Pica8, Calvin has held numerous leadership roles in product, technical, solution, and corporate marketing. Most recently, he led the cloud product marketing team at Juniper Networks where he was responsible for the marketing strategy focused on the cloud and data center markets. Prior to Juniper, Calvin spent ten years at Cisco focused on various technology initiatives including integrated security, policy, and identity management solutions.
Calvin holds a BS degree in Computer Science and Engineering from the University of California at Berkeley.
There’s a lot of talk about OpenFlow as an evolving architecture for driving software-defined networking (SDN), but so far much of the action has been around development rather than deployments, and most of the deployment activity has been in the data center. In this article, we’ll look at some real-world examples of OpenFlow and SDN in action in the larger network.
Disaggregating the Network
Implementing open networking solutions is a matter of disaggregating the network. Historically, networking has been done through a series of vertically integrated systems. Major networking equipment vendors sell tightly integrated switches, routers, and line cards, and provisioning the network means manually configuring each network element.
In OpenFlow-driven SDN, the model is to disaggregate, to use standardized building blocks to create solutions. End users and subscribers want to change applications, raise or lower bandwidth limits, or choose the speed of their connections, and manually configured networks simply can’t respond quickly enough. OpenFlow-based SDN delivers policy-driven networks where network settings are reconfigured on the fly via the OpenFlow controller, and OpenFlow is the common control protocol between all of the disaggregated parts (network operating system, or NOS, controller, and applications).
Meter, match, and act are the three steps SDN undertakes to execute tasks in a policy- driven network. SDN enables the metering of 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 that are metered against. So, for example, if a customer uses a home interface to ratchet up bandwidth, the OpenFlow controller receives this input and automatically delivers more bandwidth to that subscriber. If a network must scale to support more users, the OpenFlow controller can add routes, VLANs, and flows through the network switches.
In a way, disaggregating the network is tearing it down in order to build it up again in a more useful, flexible, and dynamic way. Now, let’s look at OpenFlow and SDN applications in action.
A Subscriber Control Panel
An Asia-Pacific service provider offers its subscribers a choice of price, performance (bandwidth, latency, and throughput), and security settings. To scale this offering, the provider needed to automate the process so that network throughput, for example, could be changed remotely and quickly through a subscriber action.
Specifically, the service provider wanted to enable:
- Liquid bandwidth – allowing subscribers to dynamically change the speed of their connections
- Metered access – implementing an AWS-like, usage-based billing model
- QoS on Demand – enabling the network to dynamically select the QoS level based on the usage model or application.
SDN enables these services because traffic engineering is based on policies derived from inputs to the customer portal. A graphical slider like the one in Figure 1 drives requests to the OpenFlow controller. Moreover, SDN enables seamless public and private cloud-bursting and migration, turning up more capacity automatically as needed.
The critical customer requirements for this use case were a combination of OpenFlow and legacy protocol support. Specifically the customer wanted integration between MPLS and hardware-based OpenFlow. The rationale followed what Google published in January 2011. Specifically, OpenFlow reprograms MPLS labels as a result of a policy, triggering the need to change a path for a giving traffic flow. The policy would be governed by the slider input from the control panel. From a traffic engineering perspective, paths would be chosen to ensure the path selected delivered the expected SLA.
The customer had also tracked OpenDaylight (ODL) development and felt that it was the best controller for their needs. Pica8 was the best choice for this SDN project since the Pica8 NOS, PicOS, supports OpenFlow 1.4, is integrated with ODL, and has support for MPLS.
Turning Up Bandwidth to Rural Subscribers
Renewed popularity of fiber to the premises (FTTP) for homes and small businesses is enabling municipalities and regional governments to reduce the “digital divide” and provide high-speed content and services to rural areas. Customers want to apply the “App Store” model at home for selecting content and bandwidth services, but bandwidth requirements and capabilities vary widely across the region.
Rather than manually provisioning VPNs to customer premise equipment (CPE), this regional service provider used OpenFlow to set up virtual CPE (vCPE) that can dynamically adjust bandwidth and services under user control. Two other services users desired were on-demand disaster recovery (disaster recovery as a service, or DRaaS) and hybrid cloud services for small businesses.
In this case, the vCPE can offer advanced firewall services in addition to dynamic VPNs offering DRaaS. Scalable liquid bandwidth is guaranteed as part of an SDN access network.
For this SDN deployment, the customer was keen to offer “smart city” services by leveraging existing infrastructure to minimize CapEx of new SDN services. At a fundamental level, service redundancy was desired to ensure Telco-like resiliency, thus redundant hardware was used throughout the topology. Hardware-based OpenFlow, driven again by ODL, was selected based on the customer’s involvement with this community.
Lastly, PicOS was chosen as it supports a rich set of Layer-2 and routing features including OSPF and BGP. This support ensured integration of the service edge based on white box switches with upstream Cisco and Juniper aggregation and core devices. The integrator for these smart cities additionally leveraged virtual CPEs (vCPEs) on hardened services to deliver high touch services on top of the liquid bandwidth services.
Maintaining Competitive Video Service
A North American satellite broadcast media provider faced increasing competition from over-the-top (OTT) providers and other cable and satellite broadcasters, and wanted to improve the speed, ease, and quality with which its services could be delivered. Customers were demanding an app-store, point-and-click content selection model, but a manually provisioned network couldn’t deliver this functionality. Self-provisioned networks would meet the demand, and they would also reduce the need for truck rolls and significantly lessen churn caused by long waits for new services or upgrades.
The solution was to implement self-service provisioning with point-and-click content selection via OpenFlow. The tight integration of OpenFlow and the current multicast environment drives rapid ROI and ensures smooth integration.
In this last deployment scenario, the customer was particularly interested in leveraging hardware-based OpenFlow in conjunction with the ONOS controller from ON.Labs, now governed by the Linux Foundation. As with the other two examples, integrating the new SDN functionality with legacy protocols was key. Here, since this is a media / video streaming application, multicast support was mandatory and PicOS has a suite of multicast support protocols, including IGMPv3, PIM-SM and PIM-SSM.
Lastly, integrating the new SDN functionality into existing OSS / BSS frameworks was accomplished through standard APIs.
OpenFlow is Driving Real Applications Today
As we have seen, OpenFlow-based SDN applications are increasingly driving customer satisfaction and service provider revenues in the market today. Networks are becoming more flexible in an era of on-demand computing, bandwidth, and services; and megatrends like mobile usage, Big Data, and the Internet of Things will continue to drive a need for network scale and agility. By breaking monolithic networks apart and building solutions with OpenFlow and SDN, network operators can be ready for the future.
About the Author
Calvin Chai is the Head of Product Marketing for Pica8 Inc. Prior to Pica8, Calvin has held numerous leadership roles in product, technical, solution, and corporate marketing. Most recently, he led the cloud product marketing team at Juniper Networks where he was responsible for the marketing strategy focused on the cloud and data center markets. Prior to Juniper, Calvin spent ten years at Cisco focused on various technology initiatives including integrated security, policy, and identity management solutions.
Calvin holds a BS degree in Computer Science and Engineering from the University of California at Berkeley.
