 | Issue: | EMEA 2014 |
| Article no.: | 9 | |
| Topic: | Defining SDN – remodeling the network | |
| Author: | Mervyn Kelly | |
| Title: | EMEA Marketing Director | |
| Organisation: | Ciena | |
| PDF size: | 197KB |
About author
Mervyn Kelly is EMEA Marketing Director for Ciena, responsible for helping customers improve their business through modernising their packet optical networks and delivering new revenue streams such as high performance on demand cloud services.
He has been in the Telecoms industry for over 20 years, and prior to his current role Mervyn held EMEA Product Marketing and Business Development senior management positions in the industry covering Carrier Ethernet, Optical, OTN, fibre to the home and IP routing market segments.
Mervyn is a Chartered Engineer and holds a BSc (Hons) degree in Microelectronic Engineering from the University of Ulster.
Article abstract
Software-Defined Networking (SDN) will radically change the networking industry landscape. But what it will mean in different contexts remains unclear.
However, with the inexhaustible processing power of cloud computing, an SDN-powered network is achievable.
Full Article
There is no denying the fact that Software-Defined Networking (SDN) will radically change the networking industry landscape. But what it will mean in different contexts remains unclear. What we do know is that SDN is not a one-size-fits-all proposition. There are considerable differences between the various types of networks and domains, such as data centre, research and education, enterprise campus, and service provider WANs, all of which will be affected by SDN.
It is also important to note that openness is central to SDN. After all, its primary imperative is to unleash productivity and innovation by allowing network behaviors to be programmed by software. And software is relatively malleable, accessible, and quick to change. For these properties to be fully exploited openness is critical; there is very little point in moving to software that remains as closed and locked as hardware-based systems are today.
Cutting through the layers
Up until this point SDN has predominately been focused on the packet layer and the data centre use case, but SDN is now expanding to optical layers, including optical transport networking (OTN) and photonics, as well as packet-optical integration. SDN’s logically centralised network intelligence, and ability to leverage cloud computing for practically unlimited compute power, enables it to assess all layers of the network concurrently to improve agility and efficiency. However the use cases in the different network domains are rather distinct and require different views of the control and application layers in the SDN architectural diagram.
For data centre and enterprise networking SDN will be concentrated on delivering seamless public, private and hybrid cloud environments through integration of virtualised computing, storage and connectivity environments. This will entail the virtualisation of WAN bandwidth for both efficiency and to facilitate a multivendor network for the accelerated deployment and management of new applications that need carrier grade WAN connectivity. This virtualised network will improve the time it takes to enable new capabilities and scalability, and the ability to customise the network forwarding behaviour to improve security and differentiation.
Service providers face a different picture. They work with multiple-layer networks, such as packet and transport (optical circuits and/or wavelengths), and multiple network domains spanning broad geographical areas. The network is often both a cost centre and a source of revenue. These networks support multiple service frameworks and types, and are continually evolving in the pursuit of new revenues, as well as serving many customers on each service. The provider does not control customer behaviors, except through policies and indirectly through pricing.
In the service provider WAN context, ‘applications’ are customer-facing, revenue-generating service applications. These applications use network connection services, but at best are only partly defined by them. SDN should enable the software that instantiates such service applications to be portable from one network platform to another, and to remain stable in the face of continuing network platform evolutions.
The service provider WAN equipment layer is also relatively complex, comprising multiple, evolving networks and domains spanning multiple network layers. This in turn suggests a complicated and expansive control layer. Logically, the control layer assumes complete responsibility for path and flow connection control, management and related functions, freeing the application layer from responsibility for such functions, even as the latter may come to encompass various functions—such as customer management, customer interface, billing and payment—that today live in other parts of the total back office system environment.
The need for Openness
The complexities faced by service providers spell a need for openness southbound from the control layer. The control layer—thick and completely encompassing of network control functionality—is as much the potential home of differentiating business value as is the application layer. For example, network optimisation functions, which seek to constrain capital costs by consistently satisfying the greatest volume of service application needs from the smallest set of equipment layer resources, should be open to innovation by individual service providers. Service providers want expanded access to such innovation-driven control of the path to their business bottom line.
However, such innovation is only possible when service providers can innovate within the control layer. This imposes certain characteristics—such as modularity for practical evolution—on the control layer architecture. But it also absolutely requires openness between the control and equipment layers: Without such openness, the control and equipment layers cannot be changed independently of each other. Software ‘driven’ networking paradigms, which glue control layer systems to physical networks, neglect this point entirely when positioned as final-form architectures, ultimately serving the interests of vendors better than those of service providers. While OpenFlow technology is a good start at ‘southbound openness’, it is incomplete. OpenFlow, as currently standardised, governs only packet equipment and operations, whereas service provider WANs also include transport networks. NFV platforms are further WAN-oriented resource domains desirably co-controlled by control layer software systems.
On the other hand, the interface between the application and control layers naturally assumes a particular form. In this scenario, the application layer “knows” what it needs from the network in basic terms— what, when, for whom, and why—and requests accordingly, but it is structurally relieved of any role in specifically how those requests are fulfilled using the physical network.
In both contrast and complement, the control layer assumes complete responsibility for the actualisation and related functions, such as the assurance of resource efficiency throughout the continuing connectivity fulfillment process. But it is structurally separated from the sources and logic of why, when, and for whom network services are needed. The application layer says what it needs from the network, but does not specify how those needs should be satisfied. The control layer handles all the mechanics of instantiating such requests without knowing how or why they have come about.
In this context, the natural language for communication between application and control layers is abstracted and parametrically oriented. In other words, network service requests both can and should be reduced to an elementary, and fully network technology- and implementation independent, form. The natural language is: Connect these endpoints—physical or virtual—and/or flows, at these times, potentially for not more than this allowable price; and provide these connection attributes: bandwidth, latency, quality, availability, etc.—expressed in essentially scalar, purely parametric terms.
The advantage of multi-layer networks
While certainly challenging, the advantages of a multi-layer SDN network are numerous. A key advantage is the ability to control network behaviour across network layers rather than simply within network layers. Consequently, services can be transported over the most efficient technology, not just the predefined transport technology. For example, a switched Ethernet service could traverse the network partially over OTN and then over Multiprotocol Label Switching (MPLS) before being handed off as Ethernet, if that were most efficient. If bandwidth at a particular layer is exhausted in some portion of the network, multi-layer SDN can evaluate options and dynamically add bandwidth from a lower layer – or reroute traffic from upper layers – around the point of congestion.
In most networks today, the ability to alleviate congestion by obtaining bandwidth from a lower layer takes days, weeks, or months as the administrators for each layer must negotiate and execute the new capacity request through multiple emails and network management system (NMS) screens. Intelligent multi-layer SDN can free the network and its operations team from this work and make the best path determination – weighing layer tradeoffs – in milliseconds.
In addition, multi-layer SDN networks can eliminate the need for hold down timers. Hold down timers are provisioned waiting periods used by upper layers to enable lower layers to react to failures before the upper layer. Instead, the SDN controller will simply address the failure immediately at the most appropriate layer, which will result in shorter downtimes.
Further, applications could be written to provide:
• Automated Congestion Management – Recognises prolonged congestion in the network and works with the controller to add bandwidth at a lower layer to alleviate the congestion or asks an upper layer to reroute traffic around the congestion
• Dynamic Pricing – Analyses a service request in the context of current and predicted service demand, and network resource supply, at multiple network layers and offers different service options at different pricing levels. This helps to maximise revenue per connection and to minimise resources consumed by incenting customers to select off-peak periods
• Network Optimisation – Evaluates network resource use at all layers and recommends or executes service path changes while ensuring SLA compliance to make more effective use of the network, and relieve current or potential congestion
With the inexhaustible processing power of cloud computing, an SDN-powered network is achievable. Service providers and enterprise can reap the rewards of a network that uses between 15 to 60 percent less bandwidth, reduces operational expenses through intelligent automation, and supports the delivery of new services with far greater agility.
