Introduction

The result of explosive growth in mobile devices has directly hit the growth in  bandwidth demand, which has taken a toll on the mobile network infrastructure. In the data center environment, creating monolithic server platforms to support traffic growth was simply not a scalable solution. To address this issue in the networking world, many researches were going on, and among them SDN  was one of the project that started at Stanford University in 2007. This essay discusses on what is SDN and the challenges faced by SDN. It also discusses on the implications of adapting SDN by ISP’s.

So what is SDN? The core concept behind SDN is that it decouple the control layer from the data layer. The control layer manages network devices by means of signaling. Although the original intent of SDN was primarily focused on services, all aspects of device management can be done at this layer. The data layer, of course, is the layer where the actual traffic flows. By separating the two, the control layer can use a different distribution model than the data layer. It also means that by not running things like path computation on the network devices, the network elements can be a less expensive device that focus on the job of transporting traffic. This leaves the network management job in software that runs on more powerful machines (computers).

Key attributes of SDN include: separation of data and control planes; a uniform vendor-agnostic interface between control and data planes called OpenFlow; a logically centralized control plane; and slicing and virtualization of the underlying network. To put it simply, SDN removes the need for network control functions and intelligence from the network elements as these functions are provided by an SDN controller. This simplifies the data center network elements, simplifies operations and makes multi-vendor networks considerably easier to manage.

Challenges faced by SDN

(CPU/GPP), Network Flow Processor (NPU/NFP), Programmable Logic Device (PLD), Application Specific Standard Product (ASSP), Application Specific Integrated Circuit (ASIC). The GPP requires High-level programming languages and design tools, which enable the highest design abstraction and the rapid development of complex packet processing functions.

The limitation of CPU implementation,however, is its performance and power dissipation, constrained by the general purpose architecture. Nevertheless, multi-core processors such as those of the Intel Xeon family [6] can achieve several tens of Gigabits of throughput by load balancing traffic onto multiple cores. The NFP is optimized processor architectures for network processing. Instructions and interconnects are tailored for processing packetized data. Dedicated hardware accelerators and various interface technologies are used for acceleration while reducing power dissipation. However, the accessibility of implementation is reduced as more detailed knowledge of the device is required in order to define the packet flow processing function, and to take full advantage of the device’s parallel processing capabilities. State-of-the-art  NPUs  such as the Netronome NFP6xxx [6] offer 216 micro-cores promising flow processing performance of over 200 Gbps line-rate per device and well over 100 Mpps. The PLD’s have evolved into a technology for telecommunication and network processing. In comparison to microprocessors, PLDs are configured using hardware design tools. This technology is ideal for implementing highly parallel and pipelined data paths that are tailored for individual network processing functions. PLD technologies such as the Tabula ABAX2 [13] can achieve custom data-path processing of over 200 Gbps per device e.g. 200 Mpps switching. The ASSP is the cornerstone of high-performance networks.They are designed and optimized for widely used functions or products aiming for high-volume. The drawback of ASSPs is their limited exibility. Core ASSP domains are physical and data-link layer products, switching and wireless products. In recent years, SDN-specific ASSPs have been introduced by Intel, Broadcom and Marvell are targeting primarily high-performance Ethernet switching with virtualization and OpenFlow support for over 500 Gbps switching. The ASIC are proprietary devices custom-built by system vendors (e.g. Cisco, Huawei, Juniper etc.) when standard products are unavailable and programmable solutions are unable to meet performance constraints. As an application-specific solution, ASICs offers the lowest exibility while providing the highest performance, power and cost benefits. SDN products are expected to be consisted of proprietary ASICs to implement the SDN data plane.

Taking into account the programmability/performance trade-off of data processing technologies, it is evident that only a hybrid approach will provide an effective technology solution for SDN. Main SDN node functions can be decomposed into clusters of sub-functions such that feature-specific technologies (within or across nodes) are used to satisfy the best performance versus programmability trade-off in terms of power dissipation, cost and scalability. One goal of SDN is to develop networks built on general purpose hardware. The combination of technologies as described in the hybrid architecture supports this goal. With a programmable interface built on standard hardware, a multi-vendor equipped network becomes a  possibility. Assuming that the performance requirements can be achieved within the hybrid

As SDN becomes more widely adopted and further refined, new solutions are proposed and new challenges arise. One fundamental challenge of SDN is how to handle high touch, high security, high performance packet processing flows in an efficient manner. So efficiency in programmability and performance  is the biggest challenge of SDN. There are a number of initiatives  [3, 4] underway to allow programmability of existing network technologies in a manner conformance with the goals of SDN. Beyond these, the SDN programmability and performance problem remains a challenge to achieve node bandwidth beyond 100 Gbps.

The main technology used for network processing are General Purpose processors(CPU/GPP),Network Flow Processor(NPU/NFP), Programmable Logic Device(PLD), Application Specific Standard Product(ASSP), Application Specific Integrated Circuit(ASIC).The GPP requires High-level programming languages and design tools, which enable the highest design abstraction and the rapid development of complex packet processing functions. The limitation of CPU implementation,however, is its performance and power dissipation, constrained by the general purpose architecture. Nevertheless, multi-core processors such as those of the Intel Xeon family [6] can achieve several tens of Gigabits of throughput by load balancing traffic onto multiple cores.

The NFP is optimized processor architectures for network processing. Instructions and interconnects are tailored for processing packetized data. Dedicated hardware accelerators and various interface technologies are used for acceleration while reducing power dissipation. However, the exibility of implementation is reduced as more detailed knowledge of the device is required in order to define the packet flow processing function, and to take full advantage of the device’s parallel processing capabilities. State-of-the-art  NPUs  such as the Netronome NFP6xxx [6] offer 216 micro-cores promising flow processing performance of over 200 Gbps line-rate per device and well over 100 Mpps. The PLD’s have evolved into a technology for telecommunication and network processing. In comparison to microprocessors, PLDs are configured using hardware design tools. This technology is ideal for implementing highly parallel and pipelined data paths that are tailored for individual network processing functions. PLD technologies such as the Tabula ABAX2 [13] can achieve custom data-path processing of over 200 Gbps per device e.g. 200 Mpps switching. The ASSP are the cornerstone of high-performance networks.They are designed and optimized for widely used functions or products aiming for high-volume. The drawback of ASSPs is their limited exibility. Core ASSP domains are physical and data-link layer products, switching and wireless products. In recent years, SDN-specific ASSPs have been introduced by Intel, Broadcom and Marvell targeting primarily high-performance Ethernet switching with virtualization and OpenFlow support for over 500 Gbps switching. The ASIC are proprietary devices custom-built by system vendors (e.g. Cisco, Huawei, Juniper etc.) when standard products are unavailable and programmable solutions are unable to meet performance constraints. As an application-specific solution, ASICs offer the lowest exibility while providing the highest performance, power and cost benefits. SDN products are expected to be consisted of proprietary ASICs to implement the SDN data plane. Taking into account the programmability/performance trade-off of data processing technologies, it is evident that only a hybrid approach will provide an effective technology solution for SDN. Main SDN node functions can be decomposed into clusters of sub-functions such that feature-specific technologies (within or across nodes) are used to satisfy the best performance versus programmability trade-off in terms of power dissipation, cost and scalability. One goal of SDN is to develop networks built on general purpose hardware. The combination of technologies as described in the hybrid architecture supports this goal. With a programmable interface built on standard hardware, a multi-vendor equipped network becomes a  possibility. Assuming that the performance requirements can be achieved within the hybrid programmable architecture, a further issue that has seen some discussion but limited solution is scalability in SDN. The issue can loosely be split into controller scalability and network node scalability. The focus here is on controller scalability in which three specific challenges are identified. The first is the latency introduced by exchanging network information between multiple nodes and a single controller. The second is how SDN controllers communicate with other controllers using the east and west bound APIs. The third challenge is the size and operation of the controller back-end database. Considering the first issue, a distributed or peer-to-peer controller infrastructure would share the communication burden of the controller. However, this approach does not eliminate the second challenge of controller-to-controller interactions for which an overall network view is required. Traditional packet networks lend themselves to scalable solutions because they do not require extensive state to be held between system units. Each network node is autonomous, requiring only limited knowledge of its neighbors.

Routing protocols have been designed to control traffic . In order to create resilient networks, alternative paths and secondary equipment are required. Typical systems that require this functionality include network elements such as Load Balancers and Firewalls. Within a pure SDN environment, a single controller or group of controllers would provide control plane services for a wider number of data-forwarding nodes, thus allowing a system-wide view of network resources. Other approaches that match the goals of SDN with existing routing protocols involve addition of an orchestration layer exposing an API that application elements may use to request desired performance from the transport layer. An extension to the Application Layer Traffic Optimization (ALTO) data model has been proposed by various organizations in which the ALTO server hosts aggregated information to which each controller has a link. The goal of ALTO is to guide applications in their selection of one of several hosts capable of providing the desired resource. A vertical architecture with bi-directional information flow between each SDN controller and the ALTO server is proposed in [15] to support the global network view. In terms of improving application performance,ALTO with SDN would be a powerful tool.

A specific solution to controller scalability is HyperFlow [14]. HyperFlow is a controller application that sits on the NOX controller and works with an event propagation system. The HyperFlow application selectively publishes events that change the state of the system and other controllers replay all the published events to reconstruct the state. By this means all the controllers share the same consistent network-wide view.Indeed, this concept of providing the network view by distributing the state over multiple controllers is highlighted in [16] in which a series of solutions to controller scalability are described. Notably, in [16], the authors conclude that the exibility of SDN provides an opportunity in terms of network manageability and functional scalability.On the way to achieving full scalability for SDN, an evolutionary approach to network programmability will be necessary. For example, with the hybrid architecture a volume of queries can be resolved in the node CPU, which would otherwise be transferred to the controller for processing. This can potentially reduce the database size at the controller and simultaneously reduce communication between the controller and its nodes.

SDN simplifies the software to improve service delivery times. The second goal is to improve the use of network resources, thereby reducing costs (both OpEx and CapEx), and/or increasing revenues. SDN has created a lot of excitement in the telecoms industry and offers the possibility of greatly simplified network automation and in some higher layer systems, the possibility of simplified and lower cost hardware.However with the adaptation of SDN it may lower cost but initially moving from present design to SDN will require a great challenge in the Cost of initial investments for the change to bring in by the ISP’s. Another challenge that SDN can experience is the security where there has been a limited industry and research community discussion on it. Potential security vulnerabilities exist across the SDN platform.

At the controller-application level, questions have been raised around authentication and authorization mechanisms to enable multiple organizations to access network resources while providing the appropriate protection of these resources [9]. Not all applications require the same network privileges and a security model must be put in place to isolate applications and support network protection.One potential solution is role-based authorization. FortNox [8] is proposed to resolve the situation when a controller receives conflicting flow rules from two different applications. Role based authorization alone, however, does not present a solution for the complexity of SDN requiring isolation of applications or resources.The controllers are a particularly attractive target for attack in the SDN architecture open to unauthorized access and exploitation. Furthermore, in the absence of a robust, secure controller platform, it is possible for an attacker to imitate as a controller and carry out malicious activities. In the past, such attacks have targeted DNS servers e.g. Kaminsky DNS attack [3]. With a single controller controlling a set of network nodes, implementation of authentication with TLS may provide the necessary security. However, with multiple controllers, communicating with a single node or multiple control processes communicating with a single, centralized controller, authorization and access control becomes more complex. One potential malicious attack is the Denial of Service (DoS) attack.  As the memory element of the node can be a bottleneck due to high cost, an attacker could potentially overload the switch memory.

Furthermore, with the introduction in SDN of open interfaces and known protocols to simplify network programming by any application provider, the door is thrown open to attackers.With full knowledge of how to control the network, with access to the controller, the operation of the network can quickly and easily be subverted to the benefit of the attacker. Even at a lower level, individual network nodes, hosts or users could be targeted undermining the desired network performance. Interoperability and standardization to support the transition from the traditional network model to SDN is also another challenge. It would be straightforward to deploy a completely new infrastructure based on SDN technology. For this, all elements and devices in the network would be SDN-enabled. However,there exists a vast, installed-base of networks supporting vital systems and businesses today.To simply swap-out these networks for new infrastructure is not going to be possible and is only well suited for closed environments such as data centres and campus networks. The migration to SDN therefore requires simultaneous support of SDN and legacy equipment. The IETF Path Computation Element (PCE) [7] could help in gradual or partial migration to SDN. With PCE, the path computation component of the network is moved from the networking node to a centralized role while traditional network nodes not using PCE continue to use their existing path computation function. A specific protocol (PCEP) enables communication between the network elements. However, PCE does not provide complete SDN.The centralized SDN controller supports complete path computation for the ow across multiple network nodes.

Further development is required to achieve a hybrid SDN infrastructure in which traditional,SDN-enabled and hybrid network nodes can operate in harmony. Such interoperability requires the support of an appropriate protocol which both introduces the requirements for SDN communication interfaces and provides backward compatibility with existing IP routing and MPLS control plane technologies. Such a solution would reduce the cost, risk and disruption for enterprise and carrier networks transitioning to SDN. Introducing a new protocol requires consideration of standardization and where this standardization will be of most benefit. ETSI Network Function Virtualisation (NFV) Industry Specification Group [5] intends to standardize components within the core network that may be virtualized to provide efficient scalability and placement of those services. IETF’s Forwarding and Control Element Separation (ForCES) has been working on standardizing interfaces,mechanisms and protocols with the goal of separating the control plane from the forwarding plane of IP routers. ONF is standardizing OpenFlow as a communication protocol within the network and is driving the standards of related protocols, such as the OpenFlow management and configuration protocol. Many programming languages such as Frenetic, Procera etc. are also being proposed to resolve the northbound API link.The work of the IETF, ETSI, ONF and other industry working groups must be coordinated in order to take advantage of existing standards in networking while proposing and developing the most effective standards to support migration from the traditional network model to SDN.

Implications of SDN adaptation by ISP’s

Network adds, moves, and changes are time-consuming and burdensome in an ever-changing world where dynamic bandwidth needs are no longer negotiable. What is truly needed is the ability to respond to this demand in real-time, where one individual can provision the bandwidth using the power of abstraction. The infrastructure must be enabled to move at a pace that is closer to the one-click world we live in today. SDN provides the framework required to make this happen. In effect, SDN serves as a middleware layer that allows users to write applications that sit on the northbound side and speak, via the southbound interfaces, to the devices. It leverages the same abstraction concept that the computer world has been using for so long. This means communications networks can transition from the technician-provisioned model to Web 2.0 programmable networks. One common application will be path computation, or end-to-end provisioning. Over the years there have been many methods that have sought to provide a PCE. One attempt was to embed the PCE into the NE’s. This idea is, in fact, the opposite concept from SDN, because it mingles the control and data layers. From a practical standpoint, merging these two layers has several limitations. One is that, because the hardware on the NE’s is limited, the scale of the domain this hardware manages is also limited. SDN overcomes this issue by the very nature of the hardware it runs on, specifically a server. Should the server become unable to manage the network due to size, additional capacity can be added by simply increasing the hardware (e.g. adding a blade or hard drive) or, if running on an elastic computing platform, by simply requesting additional computing resources. Another limitation of merged control and data layers is interoperability with other devices via the control layer. Since not all systems share common signaling protocols, the systems with embedded controls will become isolated. In the case of SDN, the southbound adaptors mitigate this issue by not only being able to work with disparate protocols but also by being able to manage systems that do not have embedded controllers. With the ability to compute a path across the network, another logical application is workflow or flow-through provisioning. Order entry systems can query the SDN layer to see what resources are available. These are real-time queries of the actual network, and not just of a database that could potentially have out-of-date information. This means the network is used more efficiently. The order system can then pragmatically build the RESTful commands needed to tell the SDN orchestrate or controller what the endpoints, bandwidth demands, and restrictions of the needed services are, and the SDN layer can automatically provision them. Additionally the SDN system can interface with the billing system for auditing purposes.  Another area where SDN can improve network utilization is by optimizing the network so that over time, it can make better use of resources. Again, using the example of OTN, SDN applications can be used to reroute OTN paths to minimize latency, to prepare for cut-overs, or based on churn in demand. The application can run as a background scheduled task to automatically look for opportunities to perform optimizations. It can then generate executive reports showing how it has performed the optimization.

Automated Testing

Once the system has created the end-to-end service, another application (or perhaps part of the turn-up application) can perform automated testing. Where software test connections are possible, the system can not only turn up the cross connects for the test but can activate the testing protocols. For example, as part of turning up an Ethernet service, the system could create a Y.1564 service “birth certificate.” Once the test is complete, the SDN system can take the report that is generated on the test gear and, if it fails, notify a technician that there is a problem with the circuit. If the circuit passes the test, the system can send the report to the inventory database, where it can be archived with the other circuit information.

Protection and Restoration

Another application that can be built is for protection and restoration. As mentioned earlier, in order to meet the required 50 ms protection needed in carrier-class networks much of the switching must take place in the hardware on the NEs. This means the SDN controller will be passing to the hardware messages that define the protection path. One advantage is that the SDN system can systematically search for the best possible restoration paths, even as new links are added to the existing network. It can search and find the most efficient path as they become available. This means the system could discover and utilize a 1:n protection scheme instead of using a less effective one-for-one method. It also means that if there is a failure, the system can dynamically compute additional protection paths. Today there are systems that can do this using embedded controllers. Unfortunately, after multiple failures, the network becomes fragmented as the system moves services to different links. This can be thought of as being similar to the fragmentation of a hard drive. Typically, tools need to be run to optimize the network, much like the manual de-fragmentation process that needed to be run on older versions of Windows. Like the newer versions of Windows, SDN can automatically “defragment” to optimize the network as part of the protection application.

SLA Management

Another possible application is SLA management, which has become a key challenge for many customers. End customers have SLA requirements associated with the services they have purchased, and they want to have a Web portal to view conformance data. The Web portal can be of great benefit, premiums are charged for both the SLA and the Web portal. If the user thinks they are having an issue and they look at their portal they may find that they have more traffic than what is covered by the SLA. This means more than just saving a troubleshooting call to the service department. It means that the customer may look at adding additional bandwidth, driving new revenue for the service provider. It is important to understand, whether adding an SLA portal or using an existing system, pulling the information via SDN is simpler, especially given the fact that REST is a web interface.

Custom Applications

Custom applications can also be written to meet a service provider’s specific needs. One example might be an application to back up large databases without affecting traffic. Using SDN you can not only schedule the backup itself, but also an increase in available bandwidth during the file transfer. The timing can be set to a known off-peak time when transport bandwidth is underutilized. After the transfer is over the bandwidth can be restored to the original size, causing no impact to customer traffic.

Network Function Virtualization (NFV)

In addition to applications, SDN becomes an enabler of NFV. NFV allows companies to provide services that currently run on dedicated hardware located on the end-user’s premises by moving the functionality to the network. Content delivery, such as Netflix video on demand, is a prime example of this. Content (movies) that was once delivered exclusively on VCR, DVDs and Blu-Ray, can now be streamed over the network with full pause, rewind, and fast-forward functions. An example of an NFV function that service providers can deliver in the context of network services would be a firewall. Instead of a customer (who is using a service-provider Internet connection) setting up and maintaining a firewall in their office, they could subscribe to the service. In NFV this is known as a virtual appliance.

The Transmode approach to SDN provides network operators from data center owners and large enterprises through to service providers of all sizes with the ability to perform multi-layer path selection with centralized hierarchical control. It provides collapsed and integrated restoration and protection functions for Layer 1 optical, Layer 2 Ethernet and MPLS-TP services while fulfilling OAM and SLA functions. One additional key capability is the interoperability with the IP service layer through the virtual routing functionality and the hierarchical architecture addresses the challenges of controlling distance and scalability.

This results in simplified and automated end-to-end service provisioning, better interoperability with other networks and better utilization of network resources.

Conclusion

SDN has created a lot of excitement in the telecoms industry and offers the possibility of greatly simplified network automation and in some higher layer systems, the possibility of simplified and lower cost hardware. Transmode has taken a pragmatic and transport oriented approach to this opportunity by creating an SDN environment that is optimized for packet-optical networks, clearly addresses the challenges that transport networks pose and can be easily evolved to when the network operator is ready. SDN has emerged as a means to improve programmability within the network to support the dynamic nature of future network functions. As bandwidth demand escalates, the provision of additional capabilities and processing power with support for multiple 100GE channels will be seamless through an SDN-based update and/or upgrade. SDN promises exibility, centralized control and open interfaces between nodes enabling an efficient, adaptive network. In order to achieve this goal, a number of outstanding challenges must be resolved. In this article we have presented a discussion of a number of challenges in the area of performance, scalability, security and interoperability. Existing research and industry solutions could resolve some of these problems and a number of working groups are also discussing potential solutions.In addition to these, the hybrid programmable architecture could be a means to counter performance and scalability issues introduced by SDN. The future of networks will be shaped around this progression. The goal is to provide effective communications and services where network, data and computation are fused into a service architecture. In the future, for a specific process, data will request the computing, storage and connection that it requires before launching the application. The location of the network elements might be distributed physically and virtually but this will be entirely opaque to the end-user. All the user will observe is the quality of delivery of the requested service. SDN will contribute to this vision of future communications. However, significant issues must be addressed in order to meet expectations. Indeed consideration of the potential for application-driven networks might lead us to wonder whether SDN as currently envisioned is even sufficient. Nevertheless, it is certain that SDN is here to stay as an evolutionary step for paving the way for a highly optimized ubiquitous service architecture.

References

[1] “Interface to the Routing System,” IRTF Working Group. [Online]. Available:https://datatracker.ietf.org/wg/irs/charter/

[2] “ITU.T Recommendation Y.1731 OAM Functions and Mechanisms for Ethernet based Networks”. [Online]. Available: http://www.itu.int/itudoc/itu-t

[3] “Kaminsky DNS Attack.” [Online]. Available:  http://dankaminsky.com

[4] “Netronome NFP6XXX Flow Processor.” [Online]. Available: http://netronome.com/pages/ow-processors/

[5] “Network Function Virtualisation,” ETSI Industry Speci_cation Group. [Online].Available: http://portal.etsi.org/portal/server.pt/community/NFV/367

[6] “Ozdag,R.,Intel Ethernet Switch FM6000 Series – Software De_ned Networking.” [Online].Available:  http://www.intel.co.uk/content/dam/www/public/us/en/documents/white-papers/ethernet-switch-fm6000-sdn-paper.pdf

[7]  “Path Computation Element,” IETF Working Group. [Online]. Available: http://datatracker.ietf.org/wg/pce/charter/

[8] P. Porras, S. Shin, V. Yegneswaran, M. Fong, M. Tyson, and G. Gu, “A Security Enforce-ment Kernel for OpenFlow Networks,” in Proceedings of the 1st Workshop on Hot topics in Software De_ned Networks. ACM, 2012, pp. 121-126.

[9] “Security Requirements in the Software De_ned Networking Model”,IETF NetworkWorking Group Internet-Draft. [Online]. Available: https://datatracker.ietf.org/doc/draft-hartman-sdnsec-requirements/

[10]Software-defined_networking.[Online].Available: http://en.wikipedia.org/wiki/Software-defined_networking

[11] Software-Defined Networking: The New Norm for Networks,” Open Networking Foundation, White Paper. [Online]. Available: https://www.opennetworking.org

[12] Stevens,W.E.(1998)UNIX Network Programming. 3rd edn. Delhi,India: Prentice-HallofIndia

[13] Tabula.,[Online]. Available: http://www.tabula.com

[14] Tootoonchian,A.,Ganjali,Y., “HyperFlow: A Distributed Control Plane for Open-Flow,” in Proceedings of the 2010 Internet Network Management Conference on Research on Enterprise Networking, 2010.

[15] “Use Cases for ALTO with Software De_ned Networks,” Internet Engineering Task Force ALTO Working Group. [Online]. Available: http://tools.ietf.org/pdf/draft-xie-alto-sdn-use-cases-01.pdf

[16]Yeganeh,S.,Tootoonchian,A.,Ganjali,Y., “On scalability of software-de_ned networking,” IEEE Communications Magazine, vol. 51, no. 2, pp. 136{141, February 2013.