Click Here for SDN Essentials - Part 1
Programmability of SDN Networks
The promise of SDN Networks or software-defined networking (SDN) is to create an infrastructure that is much more agile and flexible to drive network automation and orchestration that better supports the ever-changing demands of all the users, devices and data accessing the network. One of the ways SDN delivers this agility and flexibility is by making the network more programmable, however, that can mean different things to different organizations.
There are three use cases to defining what programmability means for SDN Networks:
- Adjusting the Flows – this use case is focused on the ability SDN delivers to program the flows of the network. They are developing protocols, such as OpenFlow, that enable SDN controllers to interact with the routers and switches in the forwarding plane to make adjustments to how the traffic flows through SDN networks to respond to changing demands. Some people feels the network is working as it should, however, they want the ability to define and make exceptions, based on business policy by using, for example, Cisco’s onePK.
- Supporting the Applications – this use case is interested in the coordination, automation and exception handling of a network to better align with the needs of the applications running on it. They are looking to develop the capabilities of the network to configure the routers and switches in a scalable manner to support the rapid deployment of new applications, services and infrastructure to quickly meet an organization’s requirements as they change. Nick Lippis, co-founder of the Open Networking Users Group (ONUG) points out “Since we are moving into a model of automated workload creation, enterprises want to do what you can do in Amazon [Web Services] – put up a workload and configure storage and network [and] the whole cloud infrastructure. But they can’t because…they need a way in which a dependency map gets created automatically.” There needs to be a language, such as Javascript Object Notation (JSON) or Extensible Messaging and Presence Protocol (XMPP) that can be shared to generate a ‘cross-domain’ response to these needs.
- Automating SDN Networks (Network Automation) – this use case is where the SDN network should just do what it’s supposed to do (network automation), without interference from a network administrator. When something changes, they want the network to figure out how to handle it, automatically.
Much of the programmability of the network relies on the northbound and southbound open application programmable interfaces (API) communications between the SDN Controller and the applications and switches/routers, respectively. Regardless of which camp an organization fits into, additional programmability of the network can enable better bandwidth utilization, improved application performance and maximum operational efficiency.
What are SDN Northbound APIs (Application Programming Interfaces)?
In a software-defined network (SDN) architecture, the northbound APIs (northbound application programming interfaces) are used to communicate between the SDN Controller and the services and applications running over the network. The northbound APIs can be used to facilitate innovation and enable efficient orchestration and automation of the network to align with the needs of different applications via SDN network programmability. These are probably the most critical APIs in the SDN environment, since the value of SDN is tied to the innovative applications it can potentially support and enable. Because they are so critical, they must support a wide variety of applications, so one size will likely not fit all. This is probably why SDN northbound APIs are currently the most nebulous component in a SDN environment – a variety of possible interfaces exist in different places up the stack to control different types of applications via an SDN Controller. We will likely see quite a few different northbound APIs before consolidation occurs – not unlike the early days of the mobile operating system (OS) wars. Examples of the types of network applications that could be optimized via the north bound interface include load balancers, firewalls or other software-defined security (SDSec) services, or orchestration applications across cloud resources. SDN Northbound APIs are also used to integrate the SDN Controller with automation stacks, such as Puppet, Chef, SaltStack, Ansible and CFEngine, as well as orchestration platforms, such as OpenStack, VMware’s vCloudDirector or the open source CloudStack. The goal is to abstract the inner-workings of the network, so that application developers can ‘hook’ into the network and make changes to accommodate the needs of the application without having to understand exactly what that means for the network. Recently, the Open Networking Foundation (ONF) turned its focus to the SDN northbound api. They have established a Northbound Working Group that will write code, develop prototypes and look at whether or not to create standards for the interface (they will make the decision in 2014) to drive clarity around what it is and what it can do.
What are SDN Southbound APIs (or Application Programmatic Interfaces)?
In a software-defined network (SDN) architecture, southbound APIs or (application programmatic interfaces) are used to communicate between the SDN Controller and the switches and routers of the network. They can be open or proprietary. Southbound APIs facilitate efficient control over the network and enable the SDN Controller to dynamically make changes according to real-time demands and needs. OpenFlow, which was developed by the Open Networking Foundation (ONF) is the first and probably most well-known southbound interface. It is an industry standard that defines the way the SDN Controller should interact with the forwarding plane to make adjustments to the network, so it can better adapt to changing business requirements. With OpenFlow, entries can be added and removed to the internal flow-table of switches and potentially routers to make the network more responsive to real-time traffic demands.
What are White Box Switches?
White box switches rely on an operating system (OS), which may come already installed or can be purchased from a software vendor and loaded separately, to integrate with the deploying organization’s layer 2/layer 3 topology and support a set of basic networking features. A common operating system for white box switches is Linux-based because of the many open and free Linux tools available that help administrators customize the devices to their needs.
Unlike traditional switches and routers that generate and maintain their own forwarding and routing tables, which they broadcast to neighboring switches and routers, generally speaking, white box switching devices are devoid of this level of intelligence. Within an SDN environment, the apps running on top of the SDN Controller are what provide the higher level orchestration and programmability of the network. The SDN Controller uses OpenFlow (or another southbound application programmatic interfaces (APIs)) to program the forwarding table of the white box switches and dictate how to route connections to accomplish the appropriate tasks for the apps.
Some industry onlookers have questioned the market potential of white box switches, noting they are likely attractive to organizations who are looking to extract value out of their infrastructure and drive revenues versus those who are running the network as a tool and IT expense. Examples of vendors offering white box switches include Accton, Celestica, and Quanta Computer.
Who is the Open Networking Foundation (ONF)?
The Open Networking Foundation (ONF) is a user-driven organization focused on promoting the adoption of software-defined network (SDN) through open standards development. Its flagship contribution has been the OpenFlow Standard, which enables the control plane (SDN Controller) to interact with the forwarding plane (Switch/Router/Chip Set/etc.) in a SDN environment.
The OpenFlow standard was introduced in 2008 to provide an alternative to proprietary solutions that limit flexibility and create vendor lock-in. The specification was designed to allow researchers to run experiments on heterogeneous switches and routers in a uniform way, without requiring vendors to expose the internal workings of their products or requiring researchers to write vendor-speciļ¬c control software.
With OpenFlow, the Controller can push down changes to the forwarding devices to make the overall network more programmable and responsive to business demands.
OpenFlow’s Basic Operation
Today, ONF paves the way for interoperable solutions with the OpenFlow Standard and the OpenFlow Configuration and Management Protocol Standard. They are also working on creating test and integration standards that can be used by the industry.
The ONF maintains several working groups currently looking at evolving the OpenFlow standard to address the needs of new use cases and production deployments. ONF also receives high-level guidance from its Technical Advisory Group (TAG) and Chipmakers’ Advisory Board (CAB):
– TAG provides multi-vendor perspectives and industry-specific knowledge regarding technical issues related to next-generation software-defined networks.
– CAB serves as a forum for chipmakers to advise ONF on the best ways to promote the hardware ecosystem and supply chain.
OpenStack Networking: What is Quantum and Neutron?
OpenStack Networking: What is Neutron?
Neutron is an OpenStack networking project focused on delivering networking as a service. Neutron has replaced the original networking application program interface (API) in OpenStack. Neutron is designed to address deficiencies in “baked-in” networking technology found in cloud environments, as well as the lack of tenant control (in multi-tenant environments) over the network topology and addressing, which makes it hard to deploy advanced networking services.
The massive scale of high-density, multi-tenancy cloud environments is putting enormous strain on networks. They are simply struggling to keep up with the explosive, dynamic nature of these virtualized environments, where workloads are moved, added or removed on the fly to address new requirements; and where multiple tenants are leveraging shared resources to drive their business.
New technologies, including software-defined networking (SDN), and network functions virtualization (NFV) are emerging to increase the flexibility and agility of the network, decoupling the control from the forwarding plane to make it easier to provision, automate and orchestrate network services. Network virtualization is attempting to align network resources to be able to better address the requirements of rich multi-tenant environments.
OpenStack Networking: Neutron’s Approach
Neutron provides a way for organizations to relieve the stress on the network in cloud environments to make it easier to deliver networking as a service in the cloud. It’s designed to provide a “plugin” mechanism that will provide an option for network operators to enable different technologies via the Quantum API. It also lets tenants create multiple private networks and control the IP addressing on them. As a result of API extensions, organizations have additional control over security and compliance policies, quality of service [QoS] and monitoring and troubleshooting, as well as the ability to easily deploy advanced network services, such as a firewall, intrusion detection or VPN.
The OpenStack Networking community is actively working on Neutron enhancements in the upcoming Havana release. Neutron (known as Quantum then) was incorporated into the mainline project during the Folsom release.
What is Network Virtualization?
Network Virtualization (NV) creates logical, virtual networks that are decoupled from the underlying network hardware to ensure the network can better integrate with and support increasingly virtual environments. Over the past decade, organizations have been adopting virtualization technologies at an accelerated rate to take advantage of the efficiencies and agility of software-based compute and storage resources. While networks have been moving towards greater virtualization, it is only recently, with the true decoupling of the control and forwarding planes, as advocated by software-defined networking (SDN) and network functions virtualization (NFV), that network virtualization has become more of a focus.
What Exactly is Virtualization?
Virtualization is the ability to simulate a hardware platform, such as a server, storage device or network resource, in software. Basically all the functionality is separated from the hardware and simulated as a “virtual instance,” with the ability to operate just like the traditional, hardware solution would. Of course, somewhere there is host hardware supporting the virtual instances of these resources, but this hardware can be general, off-the-shelf platforms. In addition, a single hardware platform can be used to support multiple virtual devices or machines, which are easy to spin up or down as needed. As a result, a virtualized solution is typically much more portable, scalable and cost-effective than a traditional hardware-based solution.
Applying Virtualization to the Network
When applied to a network, virtualization creates a logical software-based view of the hardware and software networking resources (switches, routers, etc.). The physical networking devices are simply responsible for the forwarding of packets, while the virtual network (software) provides an intelligent abstraction that makes it easy to deploy and manage network services and underlying network resources. As a result, NV can align the network to better support virtualized environments.
Virtual Networks
NV can be used to create virtual networks within a virtualized infrastructure. This enables NV to support the complex requirements in multi-tenancy environments. NV can deliver a virtual network within a virtual environment that is truly separate from other network resources. In these instances, NV can separate traffic into a zone or container to ensure traffic does not mix with other resources or the transfer of other data.
Security Challenges in SDN (Software-defined Networks)
Security needs to be everywhere within a software-defined network (SDN). It needs to be built into the architecture, as well as delivered as a service to protect the availability, integrity and privacy of all connected resources and information.
Within the architecture, you need to:
- Secure the Controller: as the centralized decision point, access to the controller needs to be tightly controlled.
- Protect the Controller: if the controller goes down (for example, because of a DDoS attack), so goes the network, which means the availability of the controller needs to be maintained.
- Establish Trust: protecting the communications throughout the network is critical. This means ensuring the controller, the applications loaded on it, and the devices it manages are all trusted entities that are operating as they should.
- Create a Robust Policy Framework: what’s needed is a system of checks and balances to make sure the controllers are doing what you actually want them to do.
- Conduct Forensics and Remediation: when an incident happens, you must be able to determine what it was, recover, potentially report on it, and then protect against it in the future.
Beyond the architecture, itself, how security should be deployed, managed, and controlled in an SDN environment is still very much up for grabs. There are competing approaches – some believe security is best embedded within the network, others feel it is best embedded in servers, storage and other computing devices. Regardless, the solutions need to be designed to create an environment that is more scalable, efficient and secure. They must be:
- Simple – to deploy, manage and maintain in the highly dynamic SDN environment.
- Cost – effective – to ensure security can be deployed everywhere.
- Secure – to protect against the latest advanced, targeted threats facing your organization.
A new category is emerging for security within next-generation environments, called software-defined security (SDSec), which delivers network security enforcement by separating the security control plane from the security processing and forwarding planes, similar to the way SDNs abstract the network control plane from the forwarding plane. The result is a dynamic distributed system that virtualizes the network security enforcement function, scales like virtual machines and is managed as a single, logical system.
SDSec is an example of network functions virtualization (NFV), which offers a new way to design, deploy and manage networking services by decoupling the network function, such as firewalling and intrusion detection, from proprietary hardware appliances, so they can run in software. It’s designed to consolidate and deliver the networking components needed to support a fully virtualized infrastructure – including virtual servers, storage and even other networks.
No comments:
Post a Comment