Konstantin Sutyagin - Fotolia
Creating new services for end-user customers in metropolitan area networks has traditionally been a slow process. Something as basic as connecting a bank branch across town to the bank's central office could take as long as three months. A change such as adding bandwidth or upgrading quality of service (QoS) on an existing contract could also be a slow process.
The delay is due to the long series of manual steps required. Networks include equipment from a variety of vendors, and each component has its own vendor-specific command syntax. Network managers must accurately type in a sequence of commands appropriate for that component, and any error can cause serious problems that could impact existing services. The new or modified service must be carefully tested before being released to the customer. Records of the allocated network resources are also recorded manually, further raising the risk of error.
Multiple-year service commitments and months-long delays may have been acceptable in the past when traffic was relatively static, but this is no longer true. The advent of network video, public clouds and the wide adoption of "everything as a service" has brought rapidly changing demands.
SDN benefits in metropolitan area networks
SDN accelerates service creation in metropolitan area networks by eliminating manual device configuration. It also solves the problem of inaccurate resource allocation records. Currently, records of which resources are allocated to which customer are often kept on paper or even in Excel spreadsheets. Updating records is also a manual operation, and is therefore prone to error. With SDN, however, all directives pass through the OSS/BSS or some other software component, such as a cloud orchestrator, and are automatically recorded there. Resource allocation records exactly mirror the network configuration.
Both network service providers and equipment vendors have recognized the benefits of SDN for metropolitan area networks. A group of service providers and vendors have joined forces to develop the Open Network Operating System (ONOS), which is designed to operate within network service provider facilities.
ONOS acts as an SDN controller but adds operating system functions. It isolates customer environments so it appears to each as if the entire network and all of its resources are dedicated to it alone. ONOS multiplexes between customer applications so each receives the appropriate level of service.
CORD (Central Office Re-architected as a Datacenter) was developed as a proof-of-concept within the ONOS project. The purpose is to demonstrate how service providers can add value by utilizing SDN, network functions virtualization (NFV), virtualization, and the economies of commodity processors and white box network devices.
The project developed the XOS orchestrator. It calls on ONOS to manage virtualized network services and on OpenStack to manage compute facilities. The developers demonstrated CORD at the Open Network Summit in June 2015. They are planning trial deployments in June 2016 and service provider deployments in 2017.
Equipment vendors are also developing SDN frameworks for metropolitan area networks. Infinera Corporation and Corsa Technology Inc. have combined efforts to create and demonstrate an architecture connecting an SDN switch with an optical network interface. Infinera offers a range of optical interface products supporting long haul and metropolitan area networks, as well as data center interconnect.
The Corsa Data Plane SDN switch was designed and built to offer extremely high performance. It supports line rate 100G traffic and provides QoS services in addition to basic switching functions. QoS parameters such as maximum bandwidth and priority can be assigned on a per flow basis. Deep packet buffers reduce packet loss when higher priority traffic impacts lower priority flows.
The Infinera and Corsa products, along with an SDN controller and management application, have demonstrated how customers can request and receive bandwidth on demand to support requirements, such as transferring a very large data set across the network. Corsa's QoS capabilities provide guaranteed bandwidth without starving other traffic.
Ciena Corporation recently acquired Cyan Inc. to create a combined offering that provides an end-to-end solution for network operators. Ciena has been primarily known for its optical network components. Cyan's Blue Planet software is focused higher in the network.
Blue Planet includes an orchestration suite driven by the service provider's OSS/BSS. The orchestrator manages physical and virtual resources throughout the network. It interfaces to an SDN controller to manage network devices, creates and manages network resident NFV functions. Ciena participates in the ONOS and CORD efforts, and Blue Planet will include these components in future offerings.
Brocade Communications Systems has long recognized the importance of SDN, but views SDN as just one component that will aid service provider in quickly creating and managing services. It early on developed Vyatta, a quality-assured edition of the OpenDaylight SDN controller, and built SDN interfaces into its hardware products. Brocade now focuses on the other necessary components -- the software layers above the controller and hardware.
Open interfaces are key to supporting SDN in metropolitan area networks. Brocade understands that networks are and will continue to be multivendor. Orchestration and OSS/BSS software must be able to call upon the underlying hardware as a virtual service without any information about how the hardware is implemented. Brocade also emphasizes that providers will not abandon their existing networks and develop new ones from scratch. They are developing software and interfaces that provide service providers with a way to transition networks in a step-by-step manner.
Both open source industry efforts and vendor-specific solutions point the way for service providers. Those that can make the transition to SDN and supporting elements earlier will enjoy the benefits, while other providers will lag behind. The change will not be easy. Older equipment and software must be replaced. Employees will need retraining. New components must be carefully tested. Despite the difficulties, however, the transition will be required to meet customers' rapidly changing needs.
No rip-and-replace for providers adopting NFV
SDN means changes in service chain provisioning
What service providers need to know about SDN