I do not recall the exact year; perhaps late 1990 or early 2000, we
worked at Nortel on Policy Enable Networks (PEN) to allow policy
enforcement points (e.g. routers or switches) to make decision based on
policy rules. These rules were enforced through policy decisions point
(PDP) which resided at server or you may call it controller. The
protocol that communicated between PDP and policy enforcement points
(PEP) was known as COPS (Common Open Policy Switching). The COPS also
supported provisioning through COPS-PR. The goal was to create a robust
QoS based network using traffic filtering and processing schema for
Voice, data and other multi service traffics. Today, COPS is used in
conjunction with RSVP protocol to prioritize network traffic.
So, when I first heard about SDN (Software Defined Networking) few years back, it intrigued me to delve further and understand it’s similarity with PEN and the potentials it brings to network virtualization. Our work on PEN did not separate control plane (think of it like advance planning in public transport networks; a set of instructions based on learning to direct/redirect traffic/paths etc) from data plane (synonymous to actual path of buses for public transportation).
In contrast with PEN, software defined networking offers improved programmability and flexibility to network administration and control as oppose simple policy enforcement. SDN essentially decoupled the administrative mechanism of traffic forwarding decisions from network systems (e.g. switch/routers etc) to a centralized server leaving data path elements or packet forwarding mechanism at the network system.
For a network system, two fundamental elements are critical: Network OS and Packet Forwarding (hardware & firmware). In SDN, network OS is removed from switches and routers to centralized controller (please refer to figure below).
Applications such as BGP, OSPF and what you haves can thus be service chained or placed in the same or other servers through “northbound API”. This creates enormous potentials and pitfalls for network virtualization. The term “SDN” is now pervasive extending it’s presence in different types of networking scenarios e.g. enterprise, telecom and data center. There is however, a cautious retort to otherwise encompassing hype. Telecom Service providers seem to prefer a similar yet distinct instrument of virtualization, “NFV (Network Function Virtualization)” and for good reasons. The goal for NFV is to reduce CAPEX while making network functions flexible and scalable without having to relinquish entire control plane at end devices. Think of such solutions as a mix of SDN and traditional networking concept. Service providers at their own discretion to decide where to virtualize what app/services based on what make sense for their network while answering CAPEX, flexibility, security and scalability questions simultaneously. This notion of function virtualization may get a helping hand from FPGA vendors who are working to include capability of traditional SOC (System on Chip), high speed and processing powers with programming flexibility to their latest FPGAs essentially making it possible for service provider to design their own notion of solution and programmability.
This is not to discount the same possibilities in SDN but there remain some iffy factors. I thought of taking this opportunity to highlight those iffy factors here while exploring the potential benefits of SDN. So, let us explore..
The Good
One of the biggest benefits of SDN is that technology transfer from academia to the industry is now much easier given the extent of openness (open source culture of innovation) and programmability nature of networking systems. Academic and technology researchers are now less depended on hardware to conduct their technological experiments rather they could focus on their ingenuity without the impositions of hardware base systems. Secondly, it allows network managers to define network behavior (i.e. traffic engineering) and implement/experiment at will. Third, it brings the ease of network virtualization and service provisioning at fingertips without having to discontent by impositions of proprietary network systems. Additionally, it provides improved control of network and load balancing capability with promise of lowering CAPEX/OPEX. Moreover, network interoperability concern among different vendors hardware is a non-issue now. To this abstraction, SDN is a technology disruptor and thus it offers the promise and benefits of organic network.
The Bad
Well, take it slow; all is not good. Promise is one thing but delivering is other. Today, the best you could do with is a hybrid SDN support in few switches: wider deployment of SDN is rare. To enterprise customer, value proposition is marginal in it’s current state of development, other than “hybrid” configuration. It is what it is and best that enterprise could do given their existing “non-SDN network systems” install base and questionable maturity level in the current state of this technology.
The Ugly
Well there is plenty to talk about here. Security is a major concern: given the nature of deployment and vulnerability in “network element level trust” involved. Let’s take the controller for example, it centralizes network transport behavior and administration increasing the risk for DOS or DDOS type attacks (Scott-Hayward, O’Callaghan & Sezer, 2013). Literatures discussed a range of topics related to security vulnerability of SDN: unauthorized access, data leakage, data modification, Denial of Service and configuration issues are among many (Hu, Hao & Bao, 2014; Klöti, Kotronis & Smith, 2013; Natarajan, 2012; Scott-Hayward, O’Callaghan & Sezer, 2013). An exhaustive list is not possible yet a survey few literatures points out a very ugly security situation here. It is, however, encouraging that researchers are working to find solutions to these otherwise ugly vulnerabilities.
Additionally, there are few more concerns on SDN that worth mentioning here. For example, lack of standards in “Southbound” and “Northbound” API and service control software (Kepes, 2014).
To summarize, SDN offer both promise and pitfall at it’s current state of development. It offers an excellent opportunity for technology researchers to make their marks while opening up a new industry trend that may reshape IT industry. Conversely, it may set the course for an ugly battle in networking industry. We are too familiar with such struggle and witnessed the rise and fall of many promising technologies e.g. ATM (Asynchronous Transfer Mode).
Reference
Hu, F., Hao, Qi & Bao, K., 2014. A Survey on Software-Defined Network (SDN) and OpenFlow: From Concept to Implementation. IEEE Communications Surveys & Tutorials, Vol. PP, Issue: 99.
Kepes, B., 2014. SDN meets the real world: implementation benefits and challenges. GIGAOM Research. Giga Omni Media, Inc.
Klöti, R., Kotronis, V. & Smith, P., 2013. OpenFlow: A Security Analysis. 21st IEEE International Conference on Network Protocols (ICNP), 2013. IEEE.
So, when I first heard about SDN (Software Defined Networking) few years back, it intrigued me to delve further and understand it’s similarity with PEN and the potentials it brings to network virtualization. Our work on PEN did not separate control plane (think of it like advance planning in public transport networks; a set of instructions based on learning to direct/redirect traffic/paths etc) from data plane (synonymous to actual path of buses for public transportation).
In contrast with PEN, software defined networking offers improved programmability and flexibility to network administration and control as oppose simple policy enforcement. SDN essentially decoupled the administrative mechanism of traffic forwarding decisions from network systems (e.g. switch/routers etc) to a centralized server leaving data path elements or packet forwarding mechanism at the network system.
For a network system, two fundamental elements are critical: Network OS and Packet Forwarding (hardware & firmware). In SDN, network OS is removed from switches and routers to centralized controller (please refer to figure below).
Applications such as BGP, OSPF and what you haves can thus be service chained or placed in the same or other servers through “northbound API”. This creates enormous potentials and pitfalls for network virtualization. The term “SDN” is now pervasive extending it’s presence in different types of networking scenarios e.g. enterprise, telecom and data center. There is however, a cautious retort to otherwise encompassing hype. Telecom Service providers seem to prefer a similar yet distinct instrument of virtualization, “NFV (Network Function Virtualization)” and for good reasons. The goal for NFV is to reduce CAPEX while making network functions flexible and scalable without having to relinquish entire control plane at end devices. Think of such solutions as a mix of SDN and traditional networking concept. Service providers at their own discretion to decide where to virtualize what app/services based on what make sense for their network while answering CAPEX, flexibility, security and scalability questions simultaneously. This notion of function virtualization may get a helping hand from FPGA vendors who are working to include capability of traditional SOC (System on Chip), high speed and processing powers with programming flexibility to their latest FPGAs essentially making it possible for service provider to design their own notion of solution and programmability.
This is not to discount the same possibilities in SDN but there remain some iffy factors. I thought of taking this opportunity to highlight those iffy factors here while exploring the potential benefits of SDN. So, let us explore..
The Good
One of the biggest benefits of SDN is that technology transfer from academia to the industry is now much easier given the extent of openness (open source culture of innovation) and programmability nature of networking systems. Academic and technology researchers are now less depended on hardware to conduct their technological experiments rather they could focus on their ingenuity without the impositions of hardware base systems. Secondly, it allows network managers to define network behavior (i.e. traffic engineering) and implement/experiment at will. Third, it brings the ease of network virtualization and service provisioning at fingertips without having to discontent by impositions of proprietary network systems. Additionally, it provides improved control of network and load balancing capability with promise of lowering CAPEX/OPEX. Moreover, network interoperability concern among different vendors hardware is a non-issue now. To this abstraction, SDN is a technology disruptor and thus it offers the promise and benefits of organic network.
The Bad
Well, take it slow; all is not good. Promise is one thing but delivering is other. Today, the best you could do with is a hybrid SDN support in few switches: wider deployment of SDN is rare. To enterprise customer, value proposition is marginal in it’s current state of development, other than “hybrid” configuration. It is what it is and best that enterprise could do given their existing “non-SDN network systems” install base and questionable maturity level in the current state of this technology.
The Ugly
Well there is plenty to talk about here. Security is a major concern: given the nature of deployment and vulnerability in “network element level trust” involved. Let’s take the controller for example, it centralizes network transport behavior and administration increasing the risk for DOS or DDOS type attacks (Scott-Hayward, O’Callaghan & Sezer, 2013). Literatures discussed a range of topics related to security vulnerability of SDN: unauthorized access, data leakage, data modification, Denial of Service and configuration issues are among many (Hu, Hao & Bao, 2014; Klöti, Kotronis & Smith, 2013; Natarajan, 2012; Scott-Hayward, O’Callaghan & Sezer, 2013). An exhaustive list is not possible yet a survey few literatures points out a very ugly security situation here. It is, however, encouraging that researchers are working to find solutions to these otherwise ugly vulnerabilities.
Additionally, there are few more concerns on SDN that worth mentioning here. For example, lack of standards in “Southbound” and “Northbound” API and service control software (Kepes, 2014).
To summarize, SDN offer both promise and pitfall at it’s current state of development. It offers an excellent opportunity for technology researchers to make their marks while opening up a new industry trend that may reshape IT industry. Conversely, it may set the course for an ugly battle in networking industry. We are too familiar with such struggle and witnessed the rise and fall of many promising technologies e.g. ATM (Asynchronous Transfer Mode).
Reference
Hu, F., Hao, Qi & Bao, K., 2014. A Survey on Software-Defined Network (SDN) and OpenFlow: From Concept to Implementation. IEEE Communications Surveys & Tutorials, Vol. PP, Issue: 99.
Kepes, B., 2014. SDN meets the real world: implementation benefits and challenges. GIGAOM Research. Giga Omni Media, Inc.
Klöti, R., Kotronis, V. & Smith, P., 2013. OpenFlow: A Security Analysis. 21st IEEE International Conference on Network Protocols (ICNP), 2013. IEEE.
Comments