The Road to SDN
Computer networking has undergone monumental changes in the last few decades. The next networking evolution is here and it's Software Defined Networking, or SDN, enabled by OpenFlow. Here's what SDN means and how OpenFlow can be implemented in the real world.
Over the last several decades there have been a large number of changes in networking technology that led to the development of Software Defined Networking (SDN). This layered evolution, along with other advances in data center technologies, would produce the underlying foundations needed to support today's infrastructures.
The lower layers have evolved from slow Time Division Multiplexing (TDM) circuits to high speed optical and copper Ethernet on the Wide Area Network (WAN). And from thick coax-based shared Ethernet and Token Ring networks to Unshielded Twisted Pair (UTP) and fiber based full duplex dedicated 1, 10 and 100 Gigabit Ethernet on Local Area Networks (LANs).
At the upper layers, this has included the Internet Protocol Version 6 (IPv6) and a flurry of different protocols, such as Open Shortest Path First (OSPF), Spanning Tree Protocol (STP), and Multiprotocol BGP (MP-BGP), to manage the ever changing requirements of highly networked enterprise infrastructures and end-user devices.
When configured, these technologies outside of the modern world of regulations and ever changing service requirements work very well. As the networks of the last twenty years have changed, they have been modified by the wide scale use of technologies like STP, Virtual LAN (VLAN), OSPF, Border Gateway Protocol (BGP), and more recently technologies like Virtual Private Networks (VPN), Virtual Routing and Forwarding (VRF), Multiprotocol Label Switching (MPLS) and MP-BGP.
While these technologies work well on their own, they all require some amount of individual node configuration, including a high level of local computing capacity to operate and manage their functions, adding even more overhead to growing networks.
Software Defined Networking is an evolving data center solution that moves most of the local complexities back to a centralized, controlling device or devices. With SDN the software that resides on these controllers makes the higher level decisions and sends this information down to each physical device.
SDN, OpenFlow and APIs
As there are a number of different definitions for SDN, for the purpose of this article, it will be defined as a method of network management that decouples the control and data plane functionalities of a network device.
The control plane functions of these network devices include processes like making frame routing decisions by STP and packet routing decisions by BGP and OSPF. It also includes other things like controlling buffers and queues as well as traffic separation with technologies like VPNs, VLANs, VRF and MPLS. On modern networks, all of these are typically configured and decisions are made at the network device itself (locally). Once these different technologies do their work, the device is also tasked with performing the process of switching and/or routing the traffic based on those decisions that are made; this movement (and sometimes short term storage) of traffic happens at the data plane.
SDN allows this control plane functionality to be copied and/or moved to a centralized controller; this controller -- the software in software defined networking -- is then responsible for making the initial decisions as to how traffic is switched or routed. This behavior is then sent to the data plane device (typically a switch at the moment) where it is cached and performed.
OpenFlow is the main interface protocol that handles communication between the control and data layer devices (the controller and the switch) and defines how a controller and device will communicate with each other to ensure that the traffic flow is switched/routed and/or controlled as expected. Keeping in mind that the controller can be configured as broadly, altering the behavior of whole subnets, or as narrowly, altering the behavior of a single device, as is required for a specific flow of traffic.
SDN is also behind a new and fast evolving trend that revolves around the use and availability of application layer interfaces (APIs) which are specifically developed to allow organizations to granularly control vendor devices. The Open Network Foundation (ONF) is at the center of the SDN movement and has provided a well-designed illustration of the API-integrated SDN architecture shown in Figure 1:
As illustrated, APIs provide direct access to the controller, and in turn the switching and/or routing device. The uses of these APIs are rather infinite, assuming support is offered for the specific platform deployed. As many of these APIs are still young, the real power that they can provide will most likely not be seen in the short term as they continue to be developed, tested and as they go through some limited deployment. But if they continue to be developed and supported, then the room for their expansion is not to be underestimated.
The big thing to follow at this point is whether the larger vendors will continue their support for this process and provide for comprehensive API support into their hardware. The problem with SDN is the suggestion that many parts of these vendor’s product lines become redundant and unneeded, and what takes their place is a comprehensively programmed and managed controller platform. Since many of these vendors have a lot of their intellectual property tied up in device software, this can be a problem. The smart money will be on a hybrid solution being developed that enables the benefits of SDN while also leveraging the power of some devices having local device intelligence.
SDN and OpenFlow Use Cases
There are certainly a large number of use cases for Software Defined Networking that illustrate multiple ways problems can be addressed by using SDN with OpenFlow; the next couple of sections will describe some of them.
Cloud Backbone Provider
The design of networks within data centers has advanced over the last several years; platforms have changed considerably (from physical to virtual) and the shear amount of traffic that is required to be moved has grown exponentially. Traditionally, methods of network design work rather well within a data center as most of these locations are interconnected with fiber already, making intra-data center bandwidth reasonably cheap.
But modern network traffic flows are not limited to a single data center's infrastructure. A lot of traffic not only flows from the data center to a host workstation (or PC), but between data centers (inter-data center) as well.
Traditionally the WAN connectivity between data centers has been provisioned in one of two ways:
The problem with waiting until the capacity is needed is that, traditionally, the process of provisioning takes time, and often the amount of time that it takes is too long for the corporate end-users waiting on their traffic. On the other hand, the problem with overprovisioning the capacity is that often this part of the network remains in a dormant state and is not used and becomes a waste of money.
What if a cloud service provider could implement an SDN solution which allows a company to provision their needed capacity in a very small window of time (thus reducing the need to buy excessive unused capacity)? This could even be something that is built-in to a providers' management portal.
On the providers' network, the whole network could be interconnected with OpenFlow capable devices which are centrally managed; if a business customer asks for an additional 10 Mbps of capacity to be allocated from data center X to data center Y, then the central management system would communicate to the OpenFlow devices and allocate the capacity on-the-fly without any access to the individual devices being required. Keep in mind that this is not limited to just bandwidth, but could also be implemented with Quality of Service (QoS).
Private and Hybrid Cloud
The private cloud is another topic that has gotten a lot of attention lately. Many organizations are changing the way that they implement and manage their IT departments by consolidating the operations into a single private cloud of potential services. This private cloud is then used as an internal service provider which individual departments provision services from. This is compared against IT departments that are tasked with providing many different solutions to multiple departments, making it almost impossible to adequately support all types of services out of the same department.
The use of SDN-enabled components within a private cloud makes a lot of sense in these implementations as they allow an organization to specifically tailor the services that will be offered to the interior departments (the same way a public cloud provider tailors theirs); this can include everything from services like bandwidth management to QoS to Security. When implemented correctly, it certainly has the potential to lower the IT departments administrative overhead and bring down department response and ticket resolution times.
On the other hand, hybrid cloud comes in when an infrastructure needs to extend to a public cloud for some of its services. Using this traditionally can run into the same problems that were addressed in the private cloud, but what if the services could be provisioned on-the-fly as well; for example what if a public store was going to be used for external storage or for offsite resource expansion?
An SDN approach would allow the internal private cloud operations to communicate with the public cloud operations to statically or dynamically set up these resources as needed, saving time and money.
Computer networking has undergone monumental changes in the last few decades. The next networking evolution is here and it's Software Defined Networking, or SDN, enabled by OpenFlow. Here's what SDN means and how OpenFlow can be implemented in the real world.
Over the last several decades there have been a large number of changes in networking technology that led to the development of Software Defined Networking (SDN). This layered evolution, along with other advances in data center technologies, would produce the underlying foundations needed to support today's infrastructures.
The lower layers have evolved from slow Time Division Multiplexing (TDM) circuits to high speed optical and copper Ethernet on the Wide Area Network (WAN). And from thick coax-based shared Ethernet and Token Ring networks to Unshielded Twisted Pair (UTP) and fiber based full duplex dedicated 1, 10 and 100 Gigabit Ethernet on Local Area Networks (LANs).
At the upper layers, this has included the Internet Protocol Version 6 (IPv6) and a flurry of different protocols, such as Open Shortest Path First (OSPF), Spanning Tree Protocol (STP), and Multiprotocol BGP (MP-BGP), to manage the ever changing requirements of highly networked enterprise infrastructures and end-user devices.
When configured, these technologies outside of the modern world of regulations and ever changing service requirements work very well. As the networks of the last twenty years have changed, they have been modified by the wide scale use of technologies like STP, Virtual LAN (VLAN), OSPF, Border Gateway Protocol (BGP), and more recently technologies like Virtual Private Networks (VPN), Virtual Routing and Forwarding (VRF), Multiprotocol Label Switching (MPLS) and MP-BGP.
While these technologies work well on their own, they all require some amount of individual node configuration, including a high level of local computing capacity to operate and manage their functions, adding even more overhead to growing networks.
Software Defined Networking is an evolving data center solution that moves most of the local complexities back to a centralized, controlling device or devices. With SDN the software that resides on these controllers makes the higher level decisions and sends this information down to each physical device.
SDN, OpenFlow and APIs
As there are a number of different definitions for SDN, for the purpose of this article, it will be defined as a method of network management that decouples the control and data plane functionalities of a network device.
The control plane functions of these network devices include processes like making frame routing decisions by STP and packet routing decisions by BGP and OSPF. It also includes other things like controlling buffers and queues as well as traffic separation with technologies like VPNs, VLANs, VRF and MPLS. On modern networks, all of these are typically configured and decisions are made at the network device itself (locally). Once these different technologies do their work, the device is also tasked with performing the process of switching and/or routing the traffic based on those decisions that are made; this movement (and sometimes short term storage) of traffic happens at the data plane.
SDN allows this control plane functionality to be copied and/or moved to a centralized controller; this controller -- the software in software defined networking -- is then responsible for making the initial decisions as to how traffic is switched or routed. This behavior is then sent to the data plane device (typically a switch at the moment) where it is cached and performed.
OpenFlow is the main interface protocol that handles communication between the control and data layer devices (the controller and the switch) and defines how a controller and device will communicate with each other to ensure that the traffic flow is switched/routed and/or controlled as expected. Keeping in mind that the controller can be configured as broadly, altering the behavior of whole subnets, or as narrowly, altering the behavior of a single device, as is required for a specific flow of traffic.
SDN is also behind a new and fast evolving trend that revolves around the use and availability of application layer interfaces (APIs) which are specifically developed to allow organizations to granularly control vendor devices. The Open Network Foundation (ONF) is at the center of the SDN movement and has provided a well-designed illustration of the API-integrated SDN architecture shown in Figure 1:
As illustrated, APIs provide direct access to the controller, and in turn the switching and/or routing device. The uses of these APIs are rather infinite, assuming support is offered for the specific platform deployed. As many of these APIs are still young, the real power that they can provide will most likely not be seen in the short term as they continue to be developed, tested and as they go through some limited deployment. But if they continue to be developed and supported, then the room for their expansion is not to be underestimated.
The big thing to follow at this point is whether the larger vendors will continue their support for this process and provide for comprehensive API support into their hardware. The problem with SDN is the suggestion that many parts of these vendor’s product lines become redundant and unneeded, and what takes their place is a comprehensively programmed and managed controller platform. Since many of these vendors have a lot of their intellectual property tied up in device software, this can be a problem. The smart money will be on a hybrid solution being developed that enables the benefits of SDN while also leveraging the power of some devices having local device intelligence.
There are certainly a large number of use cases for Software Defined Networking that illustrate multiple ways problems can be addressed by using SDN with OpenFlow; the next couple of sections will describe some of them.
Cloud Backbone Provider
The design of networks within data centers has advanced over the last several years; platforms have changed considerably (from physical to virtual) and the shear amount of traffic that is required to be moved has grown exponentially. Traditionally, methods of network design work rather well within a data center as most of these locations are interconnected with fiber already, making intra-data center bandwidth reasonably cheap.
But modern network traffic flows are not limited to a single data center's infrastructure. A lot of traffic not only flows from the data center to a host workstation (or PC), but between data centers (inter-data center) as well.
Traditionally the WAN connectivity between data centers has been provisioned in one of two ways:
- Capacity is ordered as needed.
- Capacity is ordered initially with a good amount of it being overprovisioned compared with the current needs of the system.
The problem with waiting until the capacity is needed is that, traditionally, the process of provisioning takes time, and often the amount of time that it takes is too long for the corporate end-users waiting on their traffic. On the other hand, the problem with overprovisioning the capacity is that often this part of the network remains in a dormant state and is not used and becomes a waste of money.
What if a cloud service provider could implement an SDN solution which allows a company to provision their needed capacity in a very small window of time (thus reducing the need to buy excessive unused capacity)? This could even be something that is built-in to a providers' management portal.
On the providers' network, the whole network could be interconnected with OpenFlow capable devices which are centrally managed; if a business customer asks for an additional 10 Mbps of capacity to be allocated from data center X to data center Y, then the central management system would communicate to the OpenFlow devices and allocate the capacity on-the-fly without any access to the individual devices being required. Keep in mind that this is not limited to just bandwidth, but could also be implemented with Quality of Service (QoS).
Private and Hybrid Cloud
The private cloud is another topic that has gotten a lot of attention lately. Many organizations are changing the way that they implement and manage their IT departments by consolidating the operations into a single private cloud of potential services. This private cloud is then used as an internal service provider which individual departments provision services from. This is compared against IT departments that are tasked with providing many different solutions to multiple departments, making it almost impossible to adequately support all types of services out of the same department.
The use of SDN-enabled components within a private cloud makes a lot of sense in these implementations as they allow an organization to specifically tailor the services that will be offered to the interior departments (the same way a public cloud provider tailors theirs); this can include everything from services like bandwidth management to QoS to Security. When implemented correctly, it certainly has the potential to lower the IT departments administrative overhead and bring down department response and ticket resolution times.
On the other hand, hybrid cloud comes in when an infrastructure needs to extend to a public cloud for some of its services. Using this traditionally can run into the same problems that were addressed in the private cloud, but what if the services could be provisioned on-the-fly as well; for example what if a public store was going to be used for external storage or for offsite resource expansion?
An SDN approach would allow the internal private cloud operations to communicate with the public cloud operations to statically or dynamically set up these resources as needed, saving time and money.
No comments:
Post a Comment