50/ 50

Software Defined Networking - a definitive guide

Rajesh Kumar

Published by Rajesh Kumar at Smashwords

Copyright (c) 2013 Rajesh Kumar

***~~~***

All rights reserved. Without limiting the rights under copyright reserved above, no part of this publication may be reproduced, stored in or introduced into a retrieval system, or transmitted, in any form, or by any means (electronic, mechanical, photocopying, recording, or otherwise) without the prior written permission of the copyright owners. The authors acknowledge the trademarked status and trademark owners of various products referenced, which have been used with or without permission. The publication / use of these trademarks is not authorized, associated with, or sponsored by the trademark owners.

***~~~***

Smashwords Edition, License Notes

This ebook is licensed for your personal reading and reference only. This ebook may not be resold or given away to other people. If you would like to share this book with another person, please purchase an additional copy for each person you share it with. If you’re reading this book and did not purchase it, or it was not purchased for your use only, then please return to the source and purchase your own copy. Thank you for respecting the hard work of the author and the publishers.

Preface

If you are trying to understand Software Defined Networking (SDN), this book is for you. If you are grappling with what it means to your business or organization so that you can make informed decisions, this book is for you. This book give you a comprehensive summary of SDN technology, the solutions being proposed, the practical reasons for the solutions and the meaning of different technological terms. There is much hype about SDN and its many variants, OpenFlow, Network Functions Virtualization (NFV) etc. This book tries to keep the marketing out and to focus solely on capability and value. This is born out of market need. Decision makers struggle to understand their position on various issues surrounding SDN. This book is a valuable tool for those decision makers. The information is kept crisp without burdening you with unnecessary buzz. This is written from the position of a knowledgeable insider who has been “in” it and has been part of the networking and telecommunications revolution for the past 20+ years.

If you would like to share your feedback about this book, or discuss other questions on this topic, do write to me at rajesh@kloudspun.com.

Table of Contents

Preface

Copyright notice

Chapter 1: Introduction - Why SDN?

Chapter 2: What is SDN? (The “software” in SDN)

Chapter 3: Flavors of SDN

Chapter 4: SDN in different networks

Chapter 5: Security considerations in SDN

Chapter 6: SDN and Network Virtualization

Chapter 7: Network Functions Virtualization

Chapter 8: SDN tiered network architecture

Chapter 9: Telecom process flows and SDN

Chapter 10: Orchestration and process change

Chapter 11: Computing power and impact

Chapter 12: Scale, impact and overlays

Chapter 13: Protocols in the context of SDN

Chapter 14: Buyer’s guide- What to look for

Chapter 15: Standards bodies governing SDN

Chapter 16: Open source community efforts

Chapter 17: Netconf - Transactional network setup

Chapter 18: GMPLS, PCE and SDN

Chapter 19: Benefits of SDN

Chapter 20: Universities and Government

Chapter 21: SDN glossary

References

About the author

Chapter 1: Introduction - Why SDN?

Software Defined Networking (SDN) is an emerging technology trend which is driven by the need to abstract and redefine network constructs. Its goal is to manage better, networks of greater scale and complexity. Data and Telecom Networking has grown over the past few decades. Standards have been evolving to fit and add functions to the network - Evolution has been the name of the game. While this has been happening, there was not enough attention paid to the overall architecture of data/telecom networks that evolved. The resultant networks are a mix of control and data plane constructs with no clear delineation in functionality between them. Network elements like switches have evolved to support a variety of protocols, making their cost of development, deployment very high. During this evolution, lack of computing resources also led to the creation of distributed protocols which worked well within small confines. With the scale of networks today and with computing power available at a bargain, it is now viable to look at abstraction of network architecture to simplify network operations. To say the least, cost of network operations is a very large part of the expenses incurred by network operators. Network evolution to support multi-various quadruple play services necessitates definition of sensible layers of abstraction to simplify, reduce cost and increase agility of network operations by network orchestration of various policy level decisions.

SDN is a solution to at least a few of these operational problems in certain types of networks. At the time of this writing, SDN continues to evolve at a rapid pace.

Greenfield datacenter networks have embraced SDN technology, as the cost benefits were very clear. Brownfield Telecom and Enterprise architectures in existence today have huge capital investments and incur very large operational costs year over year. SDN penetration of such brownfield environs will be at a slower pace to ensure service continuity. Disruptive changes will be seen in newer network build-outs and service offerings. Incumbent suppliers of networking gear have also been slow to adopt SDN architectures in their offerings and have taken a wait and watch approach. Their view of change is more of an integration effort into existing networks as they have a huge installed base to support.

Chapter 2: What is SDN? (The “software” in SDN)

To understand this, it helps to step back a little bit. Isn’t networking already software intensive? After all, the average router or switch, has anywhere between 2 to 10 million lines of software depending upon the functionality it delivers. So, yes, there is already a lot of software “in” networking. The key is that software does not really “define” two key requirements that network operators want from the networking technology.

(a) The ability to rapidly change the network to adapt to usage needs (higher speeds, different types of path computation, different ways of treating end users, etc)

(b) Optimal cost

You cannot simply write new code and expect a radically different network. The reason lies in how the network is built. A network broadly has three components.

(a) End users - like web servers, storage devices, our mobile phones, and so on.

(b) Network infrastructure equipment – base stations, routers, switches, and so on.

(c) Access Links (wired or wireless) that interconnect the end users and the infrastructure

From hardware defined networks to software defined networks

The last decade has seen an extraordinary revolution in end user equipment. Our phones and servers have grown a thousand-fold (or more!) in their intelligence and computing capacity. The links have also undergone similar transformation. We have wireless being delivered at gigabits per second and wired link speeds are pushing upwards of 100Gbps. But the network infrastructure (the switches and routers) have only adapted incrementally. The reasons are multiple.

Network infrastructure (routers and switches) have been built around so-called embedded processors, and components that work with these embedded processors. These components had been chosen for an optimal combination of power consumption, cooling costs, and interfaces with hardware switching devices, etc. These are not necessarily the fastest and most powerful components available. Quite often these embedded processors may have lesser speeds than the processors on smart phones!! Today’s infrastructure transports much more data over much bigger networks, with enormously complex algorithms and functions needing a lot more processing power. But existing processors cannot be replaced with the fastest processors because legacy software has been written to work with the existing embedded processor architecture and the existing processor architecture is different from the mainstream processors used for computing intensive applications. Replacing the software is also not a viable option as the network comprises equipment from different vendors which must interoperate and this has been achieved painstakingly through several months or years of testing, and trial-and-error. This limits the evolution and innovation that is otherwise possible in the control plane (intelligence) for the network. And, the key reason is the hardware on the network infrastructure equipment seems to decide the intelligence that the network equipment is capable of, that is, networking is “hardware defined”.

A radical shift from this arises by asking a few fundamental questions.

- Can I move the algorithms and computation out from the networking hardware?

- Can I use devices which give me processing capability that is orders of magnitude higher?

- If I did that, can I not create a much more flexible and intelligent network?

Doing this, brings about the shift from the current networking model to “software defined” networking where the intelligence that runs the network is moved into servers which therefore become network controllers or SDN controllers. These controllers can manipulate hardware, memory and other resources in the routers and switches to achieve the behavior needed from the network. Thus, the network becomes a tool that applications can manipulate optimally.

To understand this better let’s take a very simple network and a very simplistic view of what a router / switch does in a network. Our simplistic view of the routers / switches in the network is shown in Figure 1 below. Our simple network is shown in Figure 2 further below.

Within this network, the switches/routers perform the following functions:

(i) Exchange information with other switches / routers

(i - a) Advertise their own capabilities and connections

(i - b) Learn capabilities and connections of others

(ii) Compute paths based on the learnt information

(iii) Transport data based on the computed paths

The first two functions are “intelligence” functions and performed by the software in the equipment. The third is a “labor” function and performed by hardware in the equipment.

As the primary function is the transport of data, these devices must be optimized for this function. What this results in is constraints in the other two functions. Thus, networking is “hardware defined”. SDN attempts to change this to an alternative shown in Figure 3 below.

The information gathering and computation functions are moved to a network controller. Routers / switches focus only on the transport function. This allows the “intelligence” function to be placed on devices with high computing capacity and thus allows improvement of the algorithms and intelligence that define the network. As these algorithms and intelligence tend to be software intensive, networking becomes “software defined” and we have the concept of SDN.

Principles of Software Defined Networking

SDN is defined by three fundamental principles which differentiate it from traditional networking.

(1) Control and forwarding planes

Traditional – Control and forwarding planes are co-located in network elements.

SDN - Control plane is separated from forwarding plane and moved to SDN controller.

(2) Control intelligence

Traditional – Control intelligence is distributed in each network element.

SDN - Control intelligence is centralized at the SDN controller.

(3) Network programmability by applications

Traditional – Network cannot be programmed by applications. Each network element must be separately configured.

SDN - Network can be programmed by applications. Controller can expose application interfaces to manipulate network.

Chapter 3: Flavors of SDN

Depending on the deployment and network management approach, SDN models can be broadly grouped based on three attributes.

- Overlay (host-based) or intrusive (network-centric). In the overlay networking model the controller reacts to every change at the end-points (like change in an IP address or MAC address or movement of virtual machine - virtual or physical - from one location to another), by provisioning tunnels between the endpoints, to achieve the required connectivity and traffic flow. In the intrusive networking model, the controller reacts to the changes by provisioning the routers, switches and other such network infrastructure devices to achieve the required connectivity and traffic flow. Thus, overlay networking is host-based by making configuration changes at the hosts (endpoints) while intrusive networking is network centric by making configuration changes in the network infrastructure devices, to achieve the same connectivity goal. Overlay solutions take advantage of, but also mandate, greater computing power in the hosts, and for this reason, provide for much greater scale in datacenter networks. Examples of overlay strategies are NVGRE, STT and VxLAN. Figures 4a and 4b show an example of a controller working in the intrusive mode dealing with the case of virtual machine movement in a network. Figures 4c and 4d show the example with the controller working in the overlay mode. We discuss overlays in more detail in the chapter titled “Scale, its impact and overlay strategies”. Intrusive network controllers take the concept of building logical networks to the next level and may provide a layer of abstraction to the network operator, but they directly configure switches to achieve the desired effect.

- Floodless or flood-based. When a new address (IP address or MAC address etc) tries to communicate through a network, there are fundamentally two ways of making this known to all the other devices in the network. The first way is to flood (broadcast or multicast) the initial packet from the address so that all devices which receive the flood can learn this address. The second way, which avoids flooding and is therefore “floodless”, is to send the initial packet only to the controller or to make the new device known to the controller in some other manner, after which the controller programs the necessary tables in other devices to let the new address communicate through the network with other devices. The floodless model conserves network bandwidth at the cost of increasing the time to set up new flows through the network. The floodless model also requires more computing power at the controller.

- Asymmetric or Symmetric. At the edges of a network where host traffic enters the network, the access switches typically authenticate the host. This authentication could be performed at the edge switch itself thus creating an asymmetric network model where the edge devices are expected to do more than core devices in the network. Alternatively all authentication could be centralized at the controller thus creating a symmetric network model where all network devices are expected to perform the same simple functions. A similar choice has to be made for functions other than authentication, for example, address learning, security session establishment, tunnel establishment, subscriber flow establishment, etc. In all cases, the choice is between an asymmetric model or a symmetric model for the network. The asymmetric model reduces the load on the controller and thereby allows greater scale in terms of network size that the same controller can handle. The symmetric model reduces the complexity in the network equipment and optimizes costs by making equipment more uniform and standardized.

Much of the categorization and explanation in this chapter is based on the article http://en.wikipedia.org/wiki/Software-defined_networking.

Chapter 4: SDN in different networks

The concept of SDN is generic enough to be applied to a variety of networks. However, its applicability to each situation and the deployment in each type of network will vary. Here we look at the actual and potential uses of SDN in a few different types of networks.

SDN in campus and research networks. SDN was born in campus networks in North America. Now, it is being adopted in campus networks in all continents. The emphasis in these networks is on cost and versatility. Campus networks are much smaller than datacenter, enterprise or service provider networks and the demands on availability as well as service levels are not stringent. This allows a fertile ground for experimentation and innovation. In campuses, the focus has been on replacing more expensive traditional routers and access devices like WiFi access points using devices from alternative vendors offering higher capacity devices at much lower costs.

SDN in datacenter networks. The datacenter operators have been the first to adopt SDN in commercial networks. Many campus and research network experiments had involvement and some funding from datacenter operators and their suppliers. The single biggest factor driving SDN adoption in datacenters has been the availability of simpler and often cheaper options for handling virtualization, virtual machine migration, multi tenant hosting, etc solutions to which may have otherwise involved enormously expensive network upgrades and equipment replacement costing several 10s or 100s of millions of dollars. The concept of overlay networking, using methods like NVGRE or VxLAN, was born out of these needs in the datacenter, and these methods find their predominant applicability in datacenters. The diversity of network equipment is lesser in magnitude in datacenters than in service provider networks. This facilitates more rapid introduction of new technology like SDN since issues of interoperability and testing are less complex, solely because they involve fewer varieties of network components. The economies of scale are also much more promising. Datacenter networks have a smaller geographical spread than service provider networks. This makes changes to the network easier to handle. Datacenter networks also had a much greater need for SDN, coming as it does in the wake of cloud computing and virtualization which are demanding changes to the datacenter anyway. The cost justification and business case for SDN in datacenters has therefore been very easy for operators to see.

SDN in enterprise networks. Enterprise IT network administrators are adopting a wait and watch approach. This is partly because enterprise networks are much smaller than datacenters or transport networks. So, administrators could manually setup the required connections and paths from a central NMS. This made network management simpler. So, enterprise IT managers do not see the same cost benefits and business case justifications from SDN adoption. Another factor is that many enterprises are in the midst of their study or migration to adopt the advantages of cloud computing which in many cases shifts the SDN adoption question to a datacenter operator. Because of these factors, the adoption of SDN in enterprise networks has been very little and almost insignificant.

SDN in home networks. Home networks are dominated by consumer devices and have unitary or single digit numbers of network infrastructure. Because of this nature, there is nil interest for SDN in home networks. The CPEs in homes that are used to connect to the service provider access devices are already enabled with technology like TR-069 that performs auto-provisioning and therefore avoid similar problems like in other networks. However this could change with more internet access devices like smart phones and smart TVs proliferating. Functions like firewall and anti-malware could be concentrated in datacenters by service providers and offered as value-added services to consumers thus providing a case for extending NFV into this segment of networking.

SDN in telecom / service provider networks. Telecom / service provider networks face different challenges than datacenters or enterprises. Diversity in proprietary networking gear has resulted in extensively elongated time cycles to change or introduce services. This, coupled with rising energy costs from legacy equipment, has caused operators to look for alternatives. After grappling with the question of SDN applicability to telecom networks, many operators have converged on NFV as a promising answer. NFV is described in a little more detail in another section in this book.

Chapter 5: Security considerations in SDN

SDN brings in a lot of positives with regard to securing a network but does introduce some new concerns as well. Broadly, we list the pros and cons below starting first with the pros.

Single point of control makes the network more secure. Since the controller has a singular unified network view, it is easier to define where firewalls and IPS devices are. A single control point can ensure that all intended traffic is redirected to the firewall / IPS without having to worry about multiple boundaries that have to be secured and about all the boundaries having to be configured uniformly for security policies.

Single point of control simplifies policy enforcement. Every single flow is matched to a set policy since the IT administrator or operator does not have to install configurations and policies at a multitude of devices. Upgrades to anti-malware programs can be much easier and more comprehensive. Policies can be defined at a network level instead of at firewall / router level. NAC (Network Access Control) is more comprehensive by avoiding distribution to several access devices.

For the above reasons, it is even thought that security could be the killer application for SDN adoption. However, SDN does not come without some additional and different security concerns.

Single point of greater vulnerability. The recommendations for the controller include using a secure channel (SSL – Secure Socket Layer) between the controller and the controlled elements. While this is secure enough, based on proven cryptographically sound algorithms, the concern arises from the fact that if the connection from the controller is compromised, the entire network is compromised. In the traditional network, when a router / switch is compromised, the vulnerability is localized. With SDN, the vulnerability of the controller is the vulnerability of the entire network. Thus, it becomes important to choose algorithms and methods that can guarantee a very high level of security for the controller.

DDoS (Distributed Denial of Service) attacks on controller. This arises from the fundamental fact that the controller is the brain and intelligence of the network. Potential hackers could concentrate attacks on the controller alone rather than having to look for vulnerable points in the network. One example is to generate a whole lot of new flow notifications / requests to the controller seemingly from the network infrastructure. Logically, it should take less time to expose vulnerabilities in a single device than in a few 10s or 100s of devices. This will require mitigation by careful definition of policies for traffic (including notifications) in and out of the controller.

Access to the controller. Since SDN is new, policies for access to the controller are yet to evolve. These require careful attention in order to provide the right level of flexibility by way of interfaces to applications to manipulate the network without exposure which can compromise the network. One of the greatest benefits touted for SDN is the ability for machine-to-machine interfaces for applications to manipulate the network according to the network operator’s needs. This same facility comes with the risk of malicious groups and systems that could misuse such interfaces.

High availability at the controller. One benefit from SDN is that high availability designs for networks can focus on the controller instead of having to design high availability into every network infrastructure component. This can be a tremendous advantage in simplifying the network and optimizing cost. At the same time, high availability of the controller becomes critical since the entire network can be brought down by a controller outage.

Auditing and logging.

Network administrators will need to install auditing mechanisms, alerting systems and logging procedures at controllers similar to those available at firewalls, IPS devices and NACs. In addition, the logs and alerts will need to be correlated between the controllers and the security devices (like firewalls and IPS) that actually implement the policies.

Chapter 6: SDN and Network Virtualization

Strictly speaking, SDN and virtualization are different topics. However, these have become almost synonymous today. This is because SDN appears to be the only viable answer to challenges thrown up by cloud computing as well as virtualization of servers and storage in datacenters and enterprises. As the control plane intelligence of the network becomes concentrated in one or a few servers, it then becomes possible to extend the same virtualization concepts to the network as well by building abstracts and different logical views of the network into software applications at the servers. Thus, in a way, network virtualization is possible only with SDN. Network infrastructure based or hardware based solutions would be impractical and economically unviable.

We explain network virtualization with a simple example below in Figure 5.

The figure above shows 3 servers and 5 switches in a network. 2 of the servers host multiple virtual machines and a virtual switch. The 3rd server hosts firewall programs. The resources for one enterprise (let’s call it Enterprise 1) are hosted across the servers. These are VM 1a (Virtual Machine 1a) and VM 1b in the 1st server, VM 1c and VM 1d in the 2nd server, and a firewall in the 3rd server. Similarly Enterprise 2 has resources hosted in the same physical network. The virtual switches are used to set up any desired connectivity between the virtual machines across the servers through the physical switches. The physical switches are used simply to provide the connectivity between the physical servers. Each enterprise network is layered as a separate logical (virtual) network on top of the physical network.

The virtual networks for the 2 enterprises may look like in the Figure 6 drawn below.

By defining additional constructs for devices like routers, proxy systems, etc that are used in networks, the simple example shown above, can be extrapolated to bigger and more complex networks. A network management or IT application can be presented only the virtual network A or virtual network B as an entity to manage. This same concept can also be applied to the control plane functions of telecom networks such as DSLAMs, PON aggregation systems, access devices, eNodeBs etc.

If this kind of network virtualization were attempted in the hardware equipment, it would be impractically complex to manage and would require extensive capital outlays to replace existing network infrastructure equipment and network management systems. SDN allows a much simpler and far more economical way to realize this by moving as much of the control plane and intelligence functions into software programs in powerful computers which may be aided by hardware capabilities in the processors within these computers.

Chapter 7: Network Functions Virtualization

Another key idea that has emerged along with SDN is the concept of Network Functions Virtualization (NFV). The concept of SDN was first created in university campuses and then adopted by datacenter networks. The definition of SDN, for a brief while, became datacenter network centric. When service providers tried to apply the same concept to the carrier and transport networks, a new concept called NFV (Network Functions Virtualization) was born.

The predominant concern for datacenter operators was to simplify the network infrastructure components (the routers and switches) where there was already a lot of homogeneity in the installed component base. But, service providers faced a different problem. Their networks have a wide variety of hardware and appliances from diverse vendors. Introducing changes in services or introducing new services involved and extensive amount of skilled labor in terms of provisioning different types of equipment and extensive testing in making an increasing amount of functionality in the different appliances to interoperate. Challenges of space requirements, power consumption, capital expenditure and technical skill needed to introduce services, made it difficult for service providers to quickly monetize new technological concepts and user demands.

NFV tries to apply virtualization technology that has been established in IT infrastructure, to address this challenge to service providers. This is done by 2 types of consolidation.

- Consolidating the computing intensive functions from different network nodes into powerful servers and storage devices in datacenters

- Consolidating any complex dataplane processing from network nodes (for example customer premise devices) into powerful switches located in datacenters or central office type locations

We provide an example below of NFV in a service provider network.

A CPE (Customer Premises Equipment) device, like a DSL modem, is authenticated by the service provider device, like a DSLAM (called the PE – Provider Edge – in the picture above). To do this, the CPE device sends some authentication credentials to the PE. The PE may send the same credentials in another encapsulated packet to the AAA (Authentication, Authorization and Accounting) server which matches the credentials with stored information in a database. To do this, all the PE devices must have the AAA client installed in them and the client must interoperate with the AAA server. The processing involved in this, at the PE, is all done in a host processor (CPU) within the PE device. This can very well be moved into a server in a datacenter freeing up the CPUs in the PEs from doing this processing. The PEs can simply redirect all authentication packets (after adding some minimal additional information) to the server / controller. We list below some other examples of such functions at the PE, which could be candidates for moving into servers / controllers.

- DHCP relay agent

- DHCP snooping

- Firewall

- NAT

- PPPoE intermediate agent

There could be functions in the CPE also which can be moved into servers. We list some examples below.

- Firewall

- IPS

- NAT

Thus, NFV promises service providers the opportunity to reduce the diversity in their network infrastructure and thus achieve better economics from the network as well as enable service providers to roll out service enhancements much more rapidly.

Chapter 8: SDN tiered network architecture

The way a traditional network functions in terms of how services are provisioned, how paths are set up, etc, is shown in the picture below. Customer / end user applications require network services. The user’s IT and procurement groups work with the network service provider’s business process group with specific service needs. After processing, the specification is given to a network administrator who provisions various network elements to achieve the desired service specification. This procedure involves multiple manual steps and is a time consuming exercise. Applications do not directly make the needed requests to the network to get the services they want and they must simply use the services that have been provisioned by the administrator. The network is a static entity and the time between an application’s need for a service and the availability of the service can be many days or weeks at times.

SDN attempts to change this model. The SDN network model is shown below. The network controller provides a programmatic M2M (machine-to-machine) interface to applications to request services dynamically from the network. The controller can program the network elements, or work through the NMS to program the network elements, to change the paths in the network to realize the service request. Since the entire process can be automated, the time between the application request and the service realization is reduced to seconds. This, when further linked to business process tools and billing systems, promises tremendous efficiencies proportional to the size of a network that a service provider operates.

The comparison between a traditional network model and SDN is shown with another picture (below) which shows the difference between various tiers / layers in the network model.

Next, we look at how business and order satisfaction processes can change to benefit from this.

Chapter 9: Telecom process flows and SDN

We saw, in the previous section, how SDN changes the model of usage of the network. The network is presented as a resource for the application to customize dynamically and use optimally. This will require many changes in the business processes and IT processes in both users and service providers. Datacenters and enterprises are already in the midst of a lot of changes in their processes thanks to cloud computing and virtualization. The telecom world has largely been insulated from these changes so far. This is set to change in a huge way. SDN promises to change telecom business processes and service delivery in a similar way that ATMs (Any Time Machines) and NetBanking have changed banking and financial systems. Businesses and enterprises will be able to order and use services in a similar way that mobile phone users are able to order and use cellular services. Telecom service ordering and order satisfaction times for businesses will shrink from weeks and days to hours or minutes. A lot more automation becomes possible and soon inevitable. Many manual procedures and man-machine interfaces will be replaced by automated procedures and machine-to-machine interfaces like we have seen very briefly in the previous section.

Chapter 10: Orchestration and process change

We saw, in the previous section, how SDN changes the model of management and usage of the network. The traditional network model comprises an administrator configuring network elements through an NMS. SDN changes this by placing this configuration responsibility on the SDN controller. Networks and NMSs have evolved over decades and stabilized in field deployments. This poses a very difficult problem for an operator wanting to bring in benefits from SDN without having to rip apart existing management models with inherent risks in the process. The solution comes from the concept of orchestration. The SDN controller still maintains the complete network picture, and still computes paths through the network and still generates the requirement network element configurations. However, the SDN controller does not directly interact with the network elements. Instead, the controller interacts with the NMS through a machine-to-machine interface to realize the same objectives resulting in NMS orchestrated SDN. This is shown in the Figure 11 below.

Chapter 11: Computing power and impact

Were NFV and SDN possible a few years or a decade earlier? The answer is (arguably) negative. Two factors have been instrumental in making the NFV and SDN concepts possible today. These are, the multifold increase in computing power coupled with the steady rise in networking bandwidth. In this light, it is pertinent to cite the basic factors that have made SDN possible.

Computing power

- Moore’s law (computers double in capability every 18 months) has broadly held true

- Computing power has increased approximately 600-fold over the past 15 years.

Networking bandwidth

- Nielson’s law (high end internet connection speed increases roughly 50% every year) has broadly held true

- Network connection speeds grew approximately 100,000 times over the past 17 years

When computing power available at a single point is less, distributed computations for finding paths through networks (essentially a control plane distributed across the network elements in a network) were a better way to build networks. A single point controller would have become a bottleneck preventing any network larger than a few nodes or 10s of nodes. It is tempting to think of a cluster of controllers as an alternative. But this would have immediately hit the problem of the networking bandwidth between the controllers limiting the capacity to synchronize information, thereby making it impossible to provide a unified control of the network. In addition, a network element’s ability to respond to changes in the network or requests for paths would have been limited by the speed of communication between the controller and the network elements. This is the reason why networking has evolved the way it has. The enormous increase in computing power at a single together with the vastly increased connection speeds between network elements, and between controllers and network elements has made several new networking concepts technologically feasible and economically viable. These include cloud computing, NFV, SDN, virtualization, etc. Thus, it is not surprising that all these evolutions are taking place one after the other quickly, and close on the heels of general easy availability of multicore processors and huge amounts of storage availability.

Chapter 12: Scale, impact and overlays

In an earlier chapter titled “Flavors of SDN”, we discussed the intrusive vs overlay models of networking. In this chapter, we look at why the overlay model is necessary. The advent of virtualization created a significant challenge. An average datacenter could have about 50 racks with 30 servers (or storage nodes) per rack. With virtualization, each server can pack about 30 VMs (virtual machines). This adds up to close to 1000 logical machines on a rack and 50000 logical machines in the datacenter. Public clouds could be orders of magnitude larger than this example. As enterprises move applications into the datacenter cloud, a new challenge emerged. The same physical node could host logical nodes from different groups (or businesses or enterprises). For seamless migration, existing applications cannot be renumbered (i.e. IP or MAC addresses of endpoints have to be preserved). So, VMs within a physical node can have the same IP or MAC addresses provided these private addresses are used within the private network (also called tenant network). This breaks how datacenter networks have been set up since the switches and routers operate on learning (or configuration) of unique MAC addresses and IP addresses. SDN solutions have evolved to solve these cloudscale problems.

There were two types of solutions to this problem – one is host centric and the other is network centric.

Network based solutions. These involve making switches and routers aware of private address spaces with additional headers in the packets that the switches / routers process. Solutions in this category are EVB (Edge Virtual Bridging), TRILL (Transparent Interconnection of Lot of Links) and VEPA (Virtual Ethernet Port Aggregator). These required replacement of the network infrastructure which involved huge capital expenditure outlays and many long months (maybe upwards of a year also) for the replacement. Moreover, the solutions were not deterministic because different vendors were proposing different alternatives which would not interoperate with each other.

End point based / host based solutions. These leave the network infrastructure as it is and use additional headers for virtual machines at the origin and destination physical machines, or to be more specific, the hypervisors, as shown in the picture below. This has multiple advantages. The encapsulation and decapsulation could be built into the hypervisor. The solution could be implemented in software without any network replacement. The resulting costs were therefore much smaller than the network based solutions and could be implemented much more rapidly. The additional processing involved in encapsulating and decapsulating each packet is considered negligible considering the enormously higher processing power on the CPUs available today. The leading solutions in this category are NVGRE (Network Virtualized Generic Routing Encapsulation) and VxLAN (Virtual eXtended Local Area Network). Of these, VxLAN has become the defacto standard, mainly because of its capability to provide multiple paths between endpoints which was necessary in datacenters. Since these leave the network infrastructure untouched, these are called “overlay” solutions.

Overlay SDN

Overlay networking is not new. It has been around for a long time. In the context of SDN, overlays allow creation of L2 networks on top of IP networks and allow for addressing various Tenant needs. Overlay Networks provide additional encapsulation that abstracts traffic and allow forwarding and orchestration decisions to be made using rules desired by Network Operators. Most early SDN controllers were overlay network controllers with some of them implementing forwarding planes in software. Overlay support is provided using datacenter switches today. There have been competing proposals made to the IETF’s NV03 working group for overlay networking as applicable to Datacenter networks. All the overlays described below attempt to solve the below.

- Allow for massive scale L2 networks

- Allow L2 domains spanning L3 networks

- Identify tenant networks in L2 domain

- Co-exist with existing networking gear

Networking Virtualization using GRE (NVGRE)

This seeks to extend GRE to support Network Virtualization and hence the name Networking Virtualization using GRE (NVGRE). A 24 bit Tenant Network Identifier is added to the GRE in each packet. The significance of NVGRE is the fact that it supports L2 networks where there is no broadcast to learn MAC addresses (ex: Amazon EC2). Broadcast is avoided by pre-provisioning each host with the list of other hosts which house virtual machines in the same tenant network. The pre-provisioning is kept out of the standard and left to each network implementation.

Stateless Transport Tunneling (STT)

STT is another overlay technology alternative to NVGRE and VxLAN. The STT encapsulation header includes a Context ID similar to the Tenant-ID or VxLAN-ID. The Context ID is 64 bits in length and therefore provides room for a larger number of virtual networks within a single physical network. STT also leaves the ContextID open to application interpretation instead of specifying the field to be used only for tenant network identification. In contrast to NVGRE and VxLAN, STT uses a TCP like header in the encapsulation. This is designed to be take advantage of TCP segmentation offload capabilities in NICs (Network Interface Cards). This is expected to dramatically improve performance for applications that use large TCP packet sizes. Significantly, STT assumes the payload (which is encapsulated) to be an Ethernet frame while NVGRE and VxLAN allow different other frame types.

VXLAN

This is the predominant overlay in datacenter networking today. Backed by Cisco, Citrix, RedHat and VMWare this overlay is primarily targeted at creating Layer 2 networks that can be scaled to very large multi-tenant needs. VXLAN is being standardized by the IETF. In essence, this involves padding Ethernet frames with a 24 bit VXLAN header called VNI and adding additional IP and Ethernet headers to allow Ethernet networks to be built on top of IP networks. See below a logical view of VXLAN technology. The final IP frame can, after the below encapsulation, be sent over either Ethernet or other Layer 2 technologies like PPP or GFP. The IP frames are addressed to and from VxLAN Tunnel End Points (VTEPs). A perceived shortcoming is that current standards use VTEPs with IPV4 addresses. Hosts use multicast, which can be contained to other hosts within the same tenant network, in order to discover where a specific tenant virtual machine resides. This is another difference with NVGRE.

SDN solutions in general, and overlay solutions in particular, promise to solve network upgrade issues by providing the ability to roll out features one shot across the entire network. This reduces upgrade cycles and allows operators to embrace newer efficient technologies more rapidly as portions of the network can be "instantaneously" upgraded to try new features. These address cloudscale, redundancy and upgrade issues like none of the legacy solutions do.

However, there is one significant problem with overlay solutions. The existing network monitoring and troubleshooting tools won’t work since the packet headers have been modified. So, these will need upgrades, even if these are software upgrades and not hardware upgrades. Security policies have to be redefined since these were written based on the unmodified packet headers.

It may seem that these challenges are relevant only to enterprise networks and enterprise applications. However, NFV brings in similar problems to telecom networks. Take the example of a cellular network delivering mobile phone services. NFV attempts to move functions from devices line base stations, RNC (radio network controllers) and NodeBs / eNodeBs into servers in datacenters. A single physical server may be tasked to perform tasks that were being handled by multiple base stations or multiple NodeBs. These may belong to different service providers in a situation where the datacenter operator is different from the telecom service provider, which is the most likely scenario.

Chapter 13: Protocols in the context of SDN

Networking protocols are set to undergo a sea change with the advent of SDN. It is expected that many protocols currently used in networks may not be needed any more, at least not in their current form and usage, primarily those used to find or establish paths through networks. We take some examples to show why.

Spanning tree. For almost 2 decades, this protocol has been a fundamental building block in switches and routers in Ethernet networks. Besides the basic spanning tree protocol, there are variants like rapid spanning tree protocol (RSTP), multiple spanning tree protocol (MSTP), per VLAN rapid spanning tree protocol (PVRST), etc. The fundamental function of the spanning tree protocol was to provide loop free connectivity through a set of network elements. This is done by electing a root node, and computing reachability to the root from every other node. At any node, if there was reachability to the root through more than one port, the protocol would block traffic through the additional ports than the one providing reachability at the lowest cost. The protocol continuously monitors connectivity between adjacent nodes, and adapt to changes by immediately advertising the changes to all the adjacent nodes, and recomputing both the root node and the reachability to the root node. The variants either made the basic protocol operate faster (RSTP) or enhanced the basic algorithm to provide such loop-free connectivity for a single VLAN (PVRST) or a set of VLANs (MSTP). Since an SDN controller has visibility to all the nodes and connections in the network, there is no need to elect a root and compute reachability to a root at every switch. This can be done at the controller alone and the switches can simply be programmed based on the result of the computation at the controller. Doing so eliminates the spanning tree protocol as a mandatory building block for every switch.

Although this seems simple, there may be other difficulties in practice. More likely than not, SDN will be introduced into pockets of networks so that the switches / routers at the edge of these pockets will have to continue to support such legacy protocols until such a time that the entire network is controlled by the SDN controller. Such a hybrid situation is shown in Figure 13 below.

The use of the protocol in such a scenario throws up some interesting possibilities.

- Option 1: Run the protocol at the edge / border nodes in a similar fashion like switches do today but inject information into it (like the best node to be root within the SDN pocket) from the controller. This allows the controller to manipulate the protocol to achieve desired connectivity.

- Option 2: Run the protocol at the controller and send only the periodic keep alive messages from the edge / border nodes. Further, from the edge / border nodes, send all received protocol messages to the controller for processing.

- Option 3: Run multiple processes at the controller one for each of the switches / nodes, essentially replicating the control plane for each of the switches / nodes at the controller.

Routing protocols – ISIS, OSPF, and RIP. These have been the mainstay for IP networks for computing and establishing paths through a network. Fundamentally, each of these protocols comprises the following broad functionalities.

Discovery.

Each router makes itself known to its neighbors and also gets to know its neighbors.

Keep alive.

Each router monitors whether each previously known neighbor is still operational or not.

Advertisement.

Each router advertises to its neighbors, its known connected networks and also the connectivity information it has received from other neighbors.

Route computation.

Each router computes the way to reach every known network based on the advertisements and connectivity information it has gathered.

Since an SDN controller has visibility to all the routers and connections in the network, there is no need for individual routers to advertise the same connectivity information to each other and to compute routes to every network at every router. This can be done at the controller alone and the switches can simply be programmed based on the result of the computation at the controller. Doing so can eliminate these routing protocols from the routers / switches. So, the routers only need to perform the discovery and keep alive functions. When this simplification is done, the next opportunity presents itself to unify the discovery and keep alive mechanisms of different protocols into a common way since every other protocol does the same. For example, all these routers anyway have a BFD or LLDP implementation that discovers the neighbors and does the keep alive function. The same can be reused and the result fed into the routing protocol if things are unified at the SDN controller.

Similar to what we saw with spanning tree, practical difficulties arise when there is a mixture of SDN controlled elements and non SDN controlled elements in a hybrid network. Similar options present themselves but dealing with the routing protocol message elements instead of spanning tree message elements. Similarly Option 2 seems to be the most optimal combination of simplicity, scalability and extensibility. The RouteFlow experiment (https://sites.google.com/site/routeflow/) is an example of an actual Option 3 implementation but in a very small network.

Chapter 14: Buyers guide - What to look for

SDN being a relatively new technology and with the lack of standardization, business executives and managers who need to make choices and selections for their business find it hard to differentiate one offering from the other. In this section, we attempt to breakdown the necessary components of any SDN solution so that readers can ask the right questions to make the right choices for their networking needs.

Northbound interface. This is the interface that the controller exposes to applications / business applications. Common methods for this interface are REST APIs or XML. This interface allows business or IT applications to directly make service requests to the controller.

Service compiler. The controller needs to provide a translation from service constructs (example – requirement for a redundant leased line) to a network construct (example – 1:1 bidirectional redundant EVC – Ethernet Virtual Circuit). This hides the network type from the service and allows an operator to make network upgrades seamlessly.

Network compiler. The controller needs to take in the existing topology information of the network in terms of nodes and connections, and must transform this into a network level construct. The controller must also provide the translation from a configuration required in the network to the configuration that must be applied in individual nodes to realize the network construct.

OAM (Operations, Administration and Maintenance). The controller must have a view of the status of every link and node in the network complete with fault information, performance information and connectivity information. Optionally, this can be fetched from the existing NMS if the NMS already this view. This is also sometimes variably referred to as Health Monitoring.

Path computation. This module computes the path from one end of a service to another, through the network. The most commonly used set of algorithms for path computation are the Dijkstra algorithm with its many variants. It is expected that with the path computation moving into servers, there will be a lot of innovation in this area. For this reason, the controller must allow a user to be able to plug-in proprietary algorithm implementations.

Topology discovery and topology management. The controller mist be able to learn the topology of an existing network when connected into it. The controller must keep itself updated of any changes in the topology. There are various possibilities for this, the most common being the use of LLDP for topology discovery and updates. Other protocols such as EOAM, LMP, etc may also be used since these have methods for nodes at 2 ends of a link to find each other.

Network element configuration and monitoring. The controller must convert the result of path computations into configurations to be applied at each network element. This configuration can either be dispatched to the NMS from where the configuration is actually applied to the network elements, or the controller can directly apply the configuration to the network elements. Any notifications and state changes from the network elements must be updated to the controller (either directly or via the NMS) so that the controller is able to re-compute and re-apply service constructs where necessary.

Network element configuration and monitoring protocol – CLI / NetConf / OpenFlow / SNMP. The controller must dispatch the configuration for each network element to the network element through the management protocol that the network element supports. The traditional options of CLI or SNMP can still be used where devices do not support OpenFlow or NetConf. NetConf has been recommended by the ONF as the preferred way for telecom networks.

NMS (or other management system) plug-in. Especially in telecom networks, since the NMS interoperability with the network elements has been established and field proven, operators may want to continue managing the network elements through the installed NMS. The controller will then have to work with the NMS or be integrated into the NMS as an additional module with a plug-in.

There are some other critical attributes required from a controller which operators and OEMs with a networking background will be familiar with.

Distributed and hierarchical functioning. For small or simple networks, a single controller may be sufficient for the computes required. For larger networks, comprising 10s of 1000s of endpoints, and maybe 100s or 1000s of switches, a single physical node will be unable to satisfy the requirements for computation and performance. So, controllers must be designed for distributed processing with the load being shared across multiple servers / nodes. The network could be segmented into some logical partition with each partition being controlled by a controller. These controllers of parts of the network could then be controlled by a next higher level controller giving rise to the concept of hierarchical controllers. Standards for this are not yet even being debated leave alone being defined though some products claim to support this in proprietary ways.

High availability. Since the availability and integrity of the network is completely dependent on the controller, the controller is a single point of failure, redundancy and availability needs are stringent even for the smallest networks. Quite often, load sharing and high availability could be built into controllers in a combined way so that 2 controllers can load share and provide redundancy for each other in small networks.

Security. The controller is a single point of vulnerability for the entire network. If the controller is compromised, the entire network is compromised. Malicious attacks could be concentrated on the controller instead of trying to find weak points in a network of devices. Thus, it is both easier to attack a SDN network and easier to safeguard it since attacks and protection schemes could both be focused on the controller alone.

Chapter 15: Standards bodies governing SDN

There are 2 key standards bodies at the forefront of the SDN movement – ETSI and ONF.

ETSI (European Telecommunications Standards Institute). The ETSI is a well known institution created in 1988. It has 700+ members from 60+ countries and is officially responsible for standardization for ICT (Information and Communication Technologies) in Europe. The ETSI’s focus in the SDN area is on telecom and specifically NFV (Network Functions Virtualization). More information is available at the ETSI’s portal http://portal.etsi.org/portal/server.pt/community/NFV/367. The standards are all in the draft stage, and attempt to layout requirements and architecture for NFV.

(Open Networking Foundation). This group was created in 2011 and is specifically focused on SDN. Though members include representation from a variety of industries, the predominant tilt is towards datacenters in the various discussion groups and writings. The ONF published the specification for the OpenFlow protocol which is the very first formal protocol standard defined for programming network elements from a controller. More information is available at the ONF’s portal https://www.opennetworking.org/about/onf-overview.

The IETF has been a relatively late entrant into SDN. A working group has been created and work is ongoing to debate and evolve drafts / RFCs for NFV and SDN. At the time of this publication, only presentations of the working group discussions are available.

At the time of writing of this book, there are very few standards. Even the standards that exist do not address SDN directly but only one or other small aspect of SDN. The only standards that currently help developers are listed below.

OpenFlow. This is defined by the ONF. There are 2 standards.

- The OpenFlow protocol specification defines the communication channel and the messages between the controller and controlled network elements.

- The OpenFlow config defines a model, metadata and data elements to transform network configuration into a series of network element configurations using existing configuration methods to program the network elements. A key point to note is the stress on NetConf as opposed to SNMP or CLI as the configuration method.

NFV. This is expected to be a whole set of standards. Currently only 2 are documented in draft form – one laying out NFV requirements and the second describing an end to end architecture for NFV.

Netconf. This is an IETF defined network management protocol standardized in 2006. It was evolved in response to shortcomings in the SNMP/SMI model of management of network elements. The protocol includes some key concepts of configuration change transactions, management of multiple configuration data stores, distinction between configuration and state date, streaming & playback of event notifications, etc. The ONF has endorsed the use of NetConf as the recommended method for managing OpenFlow and SDN based networks, as opposed to SNMP or proprietary CLIs.

Yang. This is the data modeling language defined for use with Netconf and standardized by the IETF in RFC 6020. The key advantages of Yang include human readability, hierarchical configuration data models, data modularity through modules and submodules, well-defined versioning rules and extensibility through augmentation methods.

Frenetic. While on standards, it is useful to mention this programming language. This is meant to allow network operators to program the network as a whole instead of manually configuring individual network elements. This was designed to solve challenges with the use of OpenFlow based models by working with an abstraction at the network level as opposed to OpenFlow which directly goes down to the network element level. More details are available at http://www.frenetic-lang.org/.

Chapter 16: Open source community efforts

Why open source?

Open Source paradigms have undergone a change in the past decade.

- What started off as a model for sharing source code has evolved to a model for bringing the best minds across the world together to solve problems.

- Open Source also lends itself to adoption by universities and such institutions that will use it to further research.

SDN being a cutting edge technology requires both of the above. Companies have come forth to release Open Source versions of their products, with many seeing this as a marketing tool, while also providing a separate commercial version with more or differentiating features.

Commercial vs open source versions

As is well understood, support of source code is an issue in Open Source. Given the plethora of Open Source projects, evaluation and comparison of functionality and stability is a big task. Companies that have opensourced their code are well aware of this and continue to have commercial versions of their product offerings.

Open source evolution

Efforts for evolution of SDN and OpenFlow evolved out of academic research. Universities have created several open source projects on SDN and associated technologies like OpenFlow. While academia was heavily involved in the development of the first open source controllers and associated technologies, this has changed dramatically over the past couple of years with companies opensourcing their controllers. Adara, Bigswitch, NEC etc are examples of companies that have released open source versions of their controllers. The evolution of SDN has blurred lines with the evolution of its southbound interface, OpenFlow. Most open source efforts are coupled to Linux with openVswitch developed during this time.

Over the past few months, there has been significant progress in the overall definition of SDN technologies. Listed below are some of the more significant open source projects.

Beacon: Open source controller project founded by Stanford University.

Floodlight: This is the open source version of the controller created by Big Switch Networks. This is a more generic controller and is not very specific to IP networks.

FlowScale: This is an application, built in Indiana University, to traffic load balance from a controller for open flow enabled switches.

FlowVisor: FlowVisor was created by Big Switch and allows the network to be partitioned using rules. This allows experimental network setups with isolation.

Indigo: This is a switch side implementation, created by Big Switch, which enables open flow on switches controlled by a controller.

OFTest: This is a test suite to test open flow compliance in switches. At the time of this writing OFTest addresses OF Spec version 1.0 and 1.1.

Open Daylight: This is an open source controller project founded by the Linux foundation. This project attempts to address all layers needed for deploying SDN from applications to the south bound interface.

RouteFlow: RouteFlow, created by CPqD, aims to create a clear separation of control and forwarding planes for IP forwarding. Protocols continue to exist as defined earlier. Each physical switch has its control layer protocols running on a remote virtual machine. A route flow controller manages association between the open flow enabled switches and the remote virtual machines that run protocols.

Ryu: Apache licensed controller open source project, part founded by NTT

SNAC: Simple Network Access Control (SNAC) is an OpenFlow controller, written in C++ and built on NOX. It provides a web-based policy manager to manage the network. Through the UI, a user can configure devices and monitor devices. A user can define policies with a flexible policy definition language inbuilt in SNAC. Various policy management functions are grouped into high-level categories and made available through icons in the user interface. SNAC is copyrighted by Nicira Networks, Inc, which is now a part of VMWare since an acquisition in 2012.Nicira made SNAC binaries and documentation available for use in universities, in corporate labs and in corporate testing environments.

Trema: This is an open source (GPLv2) controller framework that can be used to write controllers. It is written using Ruby scripts.

Cloud computing, OpenStack and its impact

Compute and storage management in enterprises has undergone a significant revolution. Some of the significant changes are:

- Remote compute resource management

- Custom remote deployment of application stacks for various users based on need

- Remote backup and storage management

All this is still managed in part through multi-various vendor specific application tools. This has created strong vendor lockins in the enterprise. Besides this, vendor exported APIs are also used by scripts and programs cobbled together by IT departments to simplify and streamline their operations. This paradigm became significantly more complex with compute virtualization. Around this same time, computing and storage resource usage exploded. The coincidence of both usage explosion as well as compute and storage virtualization created a need for innovating in compute and storage management. Companies like VMWare emerged to address these needs, allowing cloud computing to take off.

However this created different vendor lockin as these companies grew become strong monopolies in this segment. In parallel, the US government took several steps to enable cloud computing and funded a project out of NASA. The result was an Apache 2.0 licensed platform for management of cloud computing resources. This was furthered by companies like Rackspace.com with key contributors from the earlier NASA project culminating in the creation of OpenStack.

Before the advent of CloudStack, OpenStack and VMWare, compute resources, storage resources and virtualization were managed using bunches of scripts and disparate applications. CloudStack and OpenStack evolved out of the open source community to address rapid orchestration and management of compute, storage and network in multi-tenant and cloud provider domains. OpenStack and Cloudstack have been well accepted and used for public cloud infrastructure as well.

A point to note is that OpenStack is not the typical OpenSource project. While code base is open, there are several companies that have differentiated themselves by providing production quality code base with other essentials for cloud computing such as scale, security, ease of configuration etc.

Virtual networks in cloud computing environs

Compute virtualization and Hadoop in public and private datacenters require networks capable of rapid reconfiguration at real time on an unprecedented scale. Reconfigurations of the physical network at this pace, is not a viable option. Virtual networks play an important role here and SDN is particularly well suited to manage this. Many SDN features and architectural constructs have a very strong datacenter flavor. Datacenters also have a huge installed base of switches and routers that SDN can marshal to greatest advantage.

SDN controllers interface into OpenStack using a plugin called Quantum. Several major network controller vendors provide readymade Quantum plugins, for ex: Ryu, Floodlight etc. OpenStack and CloudStack have garnered widespread acceptance as an orchestration mechanism for datacenters and certain enterprise networks.

Chapter 17: Netconf - Transactional network setup

SNMP, developed by the IETF in the late 1980s, is the official standard for a network management protocol. However, over the last ten to fifteen years, it turns out, that, despite the original intent at standardization, SNMP is not being used to configure network equipment. It is used predominantly for network monitoring only while operators primarily use some proprietary CLI (Command Line Interface) for configuration of network equipment. The extent is such that a lot of equipment, especially from vendors with large market share, lack the capability to be completely configurable through SNMP.

We list below key reasons for the preference of a CLI for configuration, as opposed to SNMP.

- CLI is text based and therefore human readable as well as human editable. SNMP uses a BER-encoding scheme which is not really friendly for reading or editing by a human.

- SNMP does not lend itself to scripting. CLI allows scripting capabilities and therefore allows operators to batch a lot of commands together in files and apply them conveniently.

- CLI has a concept of a transaction. Each command for configuration is a configuration operation. With SNMP, there is no concept of a transaction (unless we consider each request on each object as a transaction). So, capabilities like accepting or rejecting an entire set of configurations are better handled with a CLI.

- CLIs distinguished between different configuration stores, for example running configuration, saved configuration, etc. SNMP does not provide such distinction.

However, CLIs had their own drawbacks, the primary ones being:

- Lack of uniformity – each vendor provided their own CLI. Operators must lear several different formats and syntaxes and each could take months of trial and error to master.

- The output, whether it is for notifications or for results of a management request, was non-uniform since each vendor had their own proprietary definition.

Based on these experiences, the IETF created a new protocol, NETCONF, for network management which promises to be better aligned to current needs of network operators and their suppliers. The 1st NETCONF standard was RFC 4741 which was obsoleted by RFC 6241. It provides mechanisms to install, manipulate and delete the configuration of network devices. It uses an XML (eXtensible Markup Language) based data encoding for configuration data as well as for protocol messages. The protocol operations are realized as RPCs (Remote Procedure Calls) over a transport protocol such as SSH or SSL.

Along with the OpenFlow protocol specification, a network management protocol was needed to manage OpenFlow capable network elements. Considering the flow based nature of the elements to be managed, the ONF recommended NETCONF as a preferred way to manage these. This makes NETCONF a vital part of a overall SDN solution.

The controller or NMS has a NETCONF client which peers with a NETCONF server on each managed network element. The client sends messages to the server with request to install, modify or delete configuration while the server sends responses and event notifications to the client. This is shown in the Figure 15 below.

NETCONF uses a simple RPC-based mechanism to facilitate communication between the client and server. The client can be a script or application in the NMS / controller. A NETCONF session is the logical connection between the client and the server. NETCONF is conceptually partitioned into four layers as shown in the Figure 16 below.

Secure Transport layer - provides the communication path between client and server.

Message layer - provides a transport-independent framing mechanism for encoding RPCs and notifications.

Operations layer - defines a set of base protocol operations invoked as RPC methods with XML-encoded parameters.

Content layer – defines data models for configuration of various network equipment.

Chapter 18: GMPLS, PCE and SDN

Telecom networks have traditionally relied extensively on provisioning of circuits through the networks from a NMS. This approach is similar to what SDN attempts to do. When telecom networks adopted packet transport technology, MPLS came into prominence. This introduced two key aspects into the network – routing protocols to find the route through the network between any two given points and signaling protocols to set up the paths (label switched paths, virtual circuits, tunnels, etc) through the network. This is shown in the figure below. Each switch / router executes the routing protocol (OSPF or ISIS) along with the extensions for traffic engineering (OSPF-TE or ISIS-TE) to find routes through the network satisfying criteria for bandwidth availability, fault tolerance, etc. These protocols construct constraint routed paths through the network and maintain them in a TE database. The signaling protocol (RSVP-TE) then looks up the TE database to signal between the routers to actual setup the tunnel or label switched path between desired endpoints.

This has been very stable and functioning quite well. With the advent of MPLS-TP and OTN, and with the increase in the size of networks, the size of the TE database increases dramatically. As the number of neighbors and label switched paths increases, the load on the processor at each router increases significantly. The TE database also becomes much larger and places a much higher computing power demand on each router. PCE (Path Computation Element) proposes a solution to this problem. PCE is standardized in an RFC from the IETF. Since the TE database calculation, the routing protocol keep-alive messages between the routers and the network connectivity information exchange between the routers was a major part of the computing load, PCE proposes to move the routing protocol and the path computation to a single central entity called the PCE (Path Computation Element). Each router executes a path computation client (PCC) that maintains a session with the PCE. The PCC updates the PCE with the connectivity information for the router. Based on the connectivity information from each router, the PCE maintains the active topology of the network and performs the TE database and path computations. Whenever a label switched path is to be set up, the PCC fetches the required information from the PCC for the signaling protocol (RSVP-TE) to use. This is shown in the Figure 18 below. Each router still performs the required MPLS signaling.

SDN goes one step further. The signaling between the routers and the refresh / keep-alive messages for the label switched paths is still a significant load on the processor at each router. The SDN approach is to eliminate this signaling also. Instead the SDN controller provisions the label switched path by configuring each router appropriately. This is shown in Figure 19 below.

Chapter 19: Benefits of SDN

In the previous sections of this book, we looked at various aspects of SDN and what it promises. From the initial days of campus experiments and lab research, SDN has become mainstream. All leading equipment vendors and service providers in the networking space have launched products and solutions for SDN. Here we summarize the benefits that SDN promises.

- Removes hardware barriers to the speed of software innovation

- Accelerates pace of networking innovation especially in the control plane

- Optimizes cost of networking hardware

- Simplifies network infrastructure equipment

- Opens up more choices of processors for networking computations

- Enables much greater computing power for complex networking algorithms

- Decouples algorithms and intelligence from networking hardware and enables innovation

- Reduces entry barrier for innovators, pioneers, and researchers

- Provides motivation for incumbents to innovate

- Simplifies networking infrastructure to enable much greater increases in data path speed

- Enables integration of service satisfaction processes

- Promises to (drastically) reduces service satisfaction time cycles

- Enables innovation for better traffic routing algorithms and higher network capacity utilization

Chapter 20: Universities & Government

As we saw in the section on “SDN in different networks”, campus networks were the fertile ground for initial SDN experimentation and innovation. In parallel with SDN’s tremendous adoption in datacenters and serious contention in carrier networks, campuses and research facilities continue to be involved in very significant ways. Academic research has helped evolve the view of the network to a layered model that provides sufficient abstraction and scale.

Here we list some universities with significant SDN activity.

- Berkeley University (USA) – established the Open Networking Research Center (onrc.net) in collaboration with Stanford University and founding members from the industry

- Clemson University (USA) - has a GENI sponsored OpenFlow deployment

- Georgia Institute of Technology (USA) – offers a course on SDN

- Indiana State University (USA) - has a GENI sponsored OpenFlow deployment; offers a course on SDN; operates a SDN interoperability lab (InCNTRE)

- Kansas State University (USA)

- Leibniz Universität Hannover (Germany)

- Princeton University (USA) - has a GENI sponsored OpenFlow deployment

- Rutgers University (USA) – has a GENI sponsored OpenFlow deployment

- Stanford University (USA) – established the Open Networking Research Center (onrc.net) in collaboration with Berkeley University and founding members from the industry; has a production network based on OpenFlow

- University of Amazonas (Brazil)

- University of Campinas (Brazil)

- University of Rio de Janeiro (Brazil)

- University of Toronto (Canada)

- University of Washington (USA) - has a GENI sponsored OpenFlow deployment

- University of Wisconsin (USA) - has a GENI sponsored OpenFlow deployment

- VNIT (India)

At the time of this publication, there are many experimental and research facilities with SDN activity.

- CHANGE (Europe) – with participants from many European nations

- CERN (Switzerland)

- ESNet / Energy Sciences Network (USA) - provides facilities linking scientists, national laboratories, universities and research institutions across the USA, operates research facilities and computing resources; demonstrated SDN Open Transport Switch in collaboration with Infinera (a telecom OEM)

- Global Environment for Network Innovation / GENI (USA) - proof-of-concept project that links many universities in the USA, with funding from NSF (National Science Foundation, USA); allows researchers to test new ideas at scale with real traffic in the GENI backbone

- Global Research Network Operations Center / GlobalNOC (USA) –- INCNTRE is operated by GlobalNOC and Indiana State University in collaboration

- JGN-X (Japan)

- OFELIA (Europe) – with participants from many European nations

- SPARC (Europe) – with participants from many European nations

- T-Labs (Germany)

Several of these institutions have recognized the importance of SDN and have labs setup with a focus for SDN experimentation.

Chapter 21: SDN glossary

In this section we provide a summary of the various new terminology that is coming into use to describe or present products or solutions in the SDN space.

Abstraction. A simplified and generalized view of any entity deliberately leaving out details, in order to allow another entity to be able to understand it and deal with it. For example, an abstraction of a network can simply show the endpoints that are connected and how they are connected (point to point or point to multipoint) without getting into the details of the intermediate nodes, links, etc within the network.

Cloudscale. A datacenter or a network is said to be cloudscale if the number of endpoints that are connected goes into the 10s of 1000s even up to 1 million or more. Interestingly, Cloudscale Inc is also a company providing big data analytic solutions.

East and West bound interfaces. Network elements talk to other network elements through eastbound and westbound interfaces. An eastbound interface is the interface through which a network element joins a larger network through the westbound interface of the next higher level aggregation element. For example, A CPE (Customer Premises Equipment) device (like a modem) has an eastbound interface to a PE (provider edge) like a DSLAM. Conversely, the westbound interface of the DSLAM talks to the eastbound interface of the CPE.

Hypervisor. A hypervisor is the entity that creates, executes and manages virtual machines within a physical machine. The physical machine on which the hypervisor executes is called the host machine. Each virtual machine that the hypervisor creates and manages is called a guest machine. A hypervisor may be implemented in hardware, firmware or software.

Logical topology. The logical topology is an abstracted or simplified view of the physical topology of the network either in its entirety or in parts that are relevant to each logical view. One example of a logical topology is to show end-points of a single customer (user) of the network with only the virtual circuits between the user endpoints instead of the physical connections. Another example is to show each VLAN or each VxLAN as a logical network.

Orchestration. When a controller or management system breaks down management operations and directs appropriate operations to other next level management systems which manage different parts or entities in the network, the management is said to be orchestrated. For example, assume a network comprising equipment from 2 vendors, vendor A and vendor B. Further assume that NMS A manages all the equipment for vendor A and NMS B manages all the equipment for vendor B. When a new management system is introduced, management using this new system is “orchestrated” by making the new system talk to the existing NMS A and NMS B, by directing the management operations for equipment A to NMS A and directing the management operations for equipment B to NMS B.

Network compiler. A network compiler is a software program that is able to transform between network level constructs and network element level constructs. It can convert operations or instructions provided at a network level into configurations applicable to individual network elements, and can convert network element level statistics as well as notifications into network level statistics and alarms / events.

Network Operating System (NOS). A NOS is a library of utilities, tools and constructs that applications can use to manipulate the resources in a network. The objective for the application is to manipulate the network to achieve some desired behavior or change in behavior from the network, most often affecting one or more services.

Network Programming Language. A set of constructs that can allow a developer or an application (software program) to change the behavior of a network. The behavior of a network is, fundamentally, how packets are handled in the network from the point that they enter the network to the point that they are sent out of the network or are dropped by the network.

Network Virtualization. The method or technique of segmenting a single physical network into multiple logical networks is called network virtualization. This helps applications to deal only with parts or aspects of the network that the application is interested and avoiding every application from having to deal with the full physical network detail or complexity. For example, in a datacenter using virtual machines and VxLANs, each VxLAN is a virtual network.

NetConf. This is an IETF defined network management protocol first standardized in RFC 4741 and later updated in RFC 6241. It was evolved in response to shortcomings in the SNMP/SMI model of management of network elements.

Northbound interface. In computer networking and computer architecture, a northbound interface of a component is an interface that conceptualizes the lower level details (e.g., data or functions) used by, or in, the component. It is used to interface with higher level layers. In architectural overview the northbound interface is normally drawn at the top of the component it is defined in, hence the name northbound interface. For a SDN controller, the northbound interface is the interface to business or IT applications that wish to use the services provided by the controller. For a controlled element in the network, the northbound interface is the interface to the controller. The northbound interface of a lower level component usually talks to the southbound interface of a higher level component and vice versa.

Nypervisor. A hypervisor that presents multiple virtual networks from a single physical network is called a nypervisor. Nypervisor = network hypervisor.

OpenFlow controller. A network controller that controls a network element using the OpenFlow protocol for messages between the controller and the controlled elements.

Physical topology. This is the actual physical connectivity of a network comprising the hosts / users, infrastructure (hubs, repeaters, routers, switches, etc) and the links between them. Users accessing the network and the network elements in the infrastructure have to be configured and managed at the physical topology level to be able to realize the required behavior and services from the network. The logical topology is an abstracted or simplified view of the physical topology either in its entirety or in parts that are relevant to each logical view.

SDN controller. A SDN controller is a system, usually a computer, that performs all (or most of) the intelligent functions required in a network which are traditionally done in software in individual network infrastructure equipment. These functions include, but need not be limited to, discovering the connectivity / topology, maintaining the connectivity / topology information updated periodically, computing (and recomputing) paths, installing / modifying tunnels, installing /modifying virtual / logical circuits, managing security policies, monitoring resources periodically.

Southbound interface. In computer networking and computer architecture, a southbound interface of a component is an interface that decomposes concepts into technical level details to be delivered by lower level components. It is used to interface with lower level layers. In architectural overview the southbound interface is normally drawn at the bottom of the component it is defined in, hence the name southbound interface. For a SDN controller, the southbound interface is the interface to the controlled elements (like routers, switches or virtual machines) that the controller controls. The southbound interface of a higher level component usually talks to the northbound interface of a lower level component and vice versa.

Yang. This is the data modeling language defined for use with Netconf and standardized by the IETF in RFC 6020.

References

(1) http://www.bigswitch.com/sites/default/files/sdnresources/bncdatasheet_0.pdf

(2) http://www.tail-f.com/the-anatomy-of-an-sdn-control-system-part-2/

(3) https://sites.google.com/site/routeflow/ - The RouteFlow project

(4) http://www.frenetic-lang.org/publications.php

(5) http://yuba.stanford.edu/~casado/of-sw.html

(6) http://en.wikipedia.org/wiki/Software-defined_networking

(7) https://www.opennetworking.org/

(8) http://www.openflow.org/

(9) http://www.ietf.org/proceedings/82/sdn.html

About the author

Rajesh Kumar has been in the communication networks industry since 1992 after a Masters degree in telecommunication systems engineering from the Indian Institute of Technology, Kharagpur, India. During this period, Rajesh has worked on a variety of aspects including network planning, product planning, product engineering and sustaining. Rajesh has been instrumental in the planning, development and sustaining of software that runs in the infrastructure of networks across the world. Rajesh lives in Chennai, India, with his wife Charu and their two children. Rajesh runs his own company, KloudSpun, providing consulting knowhow on networking topics including SDN, besides other SDN products.