Everyone who is hearing about SDN should ask the question why we are talking about SDN? What problem is it trying to solve?

If we look at traditional networking (layer 2 and layer 3 with routing protocols such as BGP and OSPF), we are completely dominated by what is called protocols.

These protocols in fact have been very helpful to the industry. They are mostly standard. Different vendors and products can communicate using standard protocols with each other. A Cisco router can establish a BGP session with a Huawei switch or an open source Quagga router can exchange OSPF routes with a Juniper firewall.

The routing protocol is a constant standard with solid bases. If you need to override something in your network routing, you have to find a trick to use protocols, even by using a static route.

Further more the legacy networking and switching gears are based on a tied control plane and forwarding plane on a single box. Each switch or router runs a control software (AKA firmware or operating system) which includes components such as spanning tree, BGP, OSPF, link aggregation, LLD, and so on. Each device uses these protocols to build a network from its own perspective.

This tide integration between software and hardware, or control and data plane limits the scalability of the network because of a lack of having a single, know all, network brain.

This integration also has a cost impact as each vendor will charge extra for a software running on their switches.

One of the main objectives of SDN is to dis-aggregate the control and data plane. That means to have a single control plane software (the SDN controller) and multiple bare metal SDN-enabled data plane gears (such as pure OpenFlow switches).

SDN can help us to come out of the routing protocol cage, look at different ways to forward traffic. SDN can directly program each switch or even override a route that is installed by routing protocols.

There are high-level benefits of using SDN, a few of which we have explained in the following list:

• An integrated network: We used to have a standalone concept in traditional networks. Each switch was managed separately; each switch was running its own routing protocol instance and was processing routing information messages from other neighbors. In SDN, we are migrating to a centralized model, where the SDN controller becomes the single point of configuration of the network, where you will apply the policies and configuration.
• Scalable layer 2 across layer 3: Having a layer 2 network across multiple layer 3 networks is something that all network architects are interested in and until now we have been using proprietary methods such as OTV or by using a service provider VPLS service. With SDN, we can create layer 2 networks across multiple switches or layer 3 domains (using VXLAN) and expand the layer 2 networks. In many cloud environments, where the virtual machines are distributed across different hosts in different data centers, this is a major requirement.
• Third-party application programmability: This is a very generic term, isn't it? But what I'm referring to is to let other applications communicate with your network. For example, in many new distributed IP storage systems, the IP storage controller has the ability to talk to networks to provide the best, shortest path to the storage node. With SDN we are letting other applications control the network. Of course this control has limitations and SDN doesn't allow an application to scrap the whole network.
• Flexible application based network: In SDN, everything is an application. L2/L3, BGP, VMware Integration, and so on all are applications running in the SDN controller.
• Service chaining: On the fly you add a firewall in the path or a load balancer. This is service insertion.
• Unified wired and wireless: This is an ideal benefit, to have a controller that supports both wired and wireless network. OpenDaylight is the only controller that supports CAPWAP protocols that allows integration with wireless access points.

A software-defined network infrastructure has two main key components:

• The SDN controller (only one, could be deployed in a highly available cluster)
• The SDN-enabled switches (multiple switches, mostly in a Clos topology in a data center) as shown in the following figure:

An SDN controller is the single brain of the SDN domain. In fact, an SDN domain is very similar to a chassis-based switch. You can imagine the supervisor or management module of a chassis-based switch as an SDN controller and the rest of the line card and I/O cards as SDN switches. The main difference between an SDN network and a chassis-based switch is that you can scale out the SDN with multiple switches, where in a chassis-based switch you are limited to the number of slots in that chassis:

It is very important that you understand the main technologies involved in SDN. These methods are used by SDN controllers to manage and control the SDN network.

In general, there are two methods available for controlling the fabric:

• Direct fabric programming: In this method, the SDN controller directly communicates with SDN-enabled switches via southbound protocols such as OpenFlow, NETCONF, and OVSDB. The SDN controller programs each switch member with related information about fabric, and how to forward the traffic. Direct fabric programming is the method used by OpenDaylight.
• Overlay: In the overlay method, the SDN controller doesn't rely on programming the network switches and routers. Instead it builds a virtual overlay network on top of the existing underlay network. The underlay network can be an L2 or L3 network with traditional network switches and router, just providing IP connectivity. The SDN controller uses this platform to build the overlay using encapsulation protocols such as VXLAN and NVGRE. VMware NSX uses overlay technology to build and control the virtual fabric.

Let's look at how the standard switch or router performs a frame forwarding. For our understanding we will look at a generic layer 3 switch (1G or 10G) from any vendor:

An Ethernet switch is a very simple device, it's just a silicon chipset, which is from one of the large silicon manufacturers such as Broadcom or Marvel, a CPU (which is either a x86 or a low power ARM-based processor), which runs the vendor's software (vendor here is referring to switch vendor such as Cisco or Juniper or Arista, and so on.):

The switch silicon is like a comparison table. It maps the frames to ports. When a switch receives a packet, it looks into its content-addressable memory (CAM) table to find out what needs to be done to this frame received on port X. The CAM table, which is already programmed and filled by the switch software, will have an entry to tell the switch silicon what needs to be done on that frame. For example, send it out of port Y and change the destination MAC to switch burned in MAC. Or any other decision such as sending it to the switch CPU for processing (if it's a routing protocol packet, for example an OSPF LSA).

So in simple terms, in standard switches the CAM table of a switch is filled by entries that are programmed and controlled by switch CPU or switch software.

In SDN, we have a slightly different scenario, you can imagine that the SDN controller will control the CAM table of all switches. The terms are changed slightly and it is called a flow table. A flow table is nothing but the same CAM entries in the switch, but it's called a flow table and each entry is called a flow entry.

SDN controller programs each switch CAM table via a protocol that is called southbound protocol. There are multiple southbound protocols where the most famous and standard one is OpenFlow; however, the others such as NETCONF and OVSDB also exist in standard protocol groups. Cisco's OpFlex (https://tools.ietf.org/html/draft-smith-opflex-03) is also an open source protocol which is a southbound protocol between Cisco APIC controller and Cisco Nexus switches. OpFlex is also supported on OpenDaylight.

OpenFlow is a protocol that allows SDN controller to program each switch in the SDN network. Please remember that the OpenFlow is a piece of software, it's a protocol. The OpenFlow agent runs on each switch and starts communicating with the OpenFlow server piece on SDN controller.

You may have heard about overlays. Especially if you have heard about the SD-WAN, which is completely based on overlay networking. An overlay is a network built on top of an underlay network. Seems complex? Let me provide a more familiar example. An SSL VPN tunnel is an overlay on top of a IP network. In SSL VPN, the underlay is IP, and an overlay is an SSL.

The real packets are encapsulated as new payload inside the SSL packets. You can make more examples of overlays, GRE, IPSEC, and also the new overlays such as VXLAN and NVGRE:

Overlays are also considered as part of the SDN family. Yes, they are software defined. They are created and managed by software. Overlays are not dependent on the underlay IP network; therefore deploying an overlay network is much easier than deploying a full SDN with SDN controller and switches. In data center overlay networks there are two main protocols used for encapsulation: VXLAN and NVGRE.

VXLAN is a UDP packet, which encapsulates the whole IP packet as a UDP payload and sends over the other end. VXLAN endpoints are called Virtual Tunnel End Points (VTEP). VTEPs create virtual tunnels between each other and transmit the UDP packets that are all having the packets encapsulated inside the UDP payload.

VXLAN uses an identification number for networks called virtual network ID (VNID), which identifies which packet belongs to which virtual network.

VXLAN is very common between most of the vendors and are very well supported.

Network Virtualization using GRE (NVGRE) is another protocol similar to VXLAN, but it is not very popular. Microsoft is one of the promoters of NVGRE on their SONIC switch operating system.

The most important overlay solution on the market is VMware NSX.

Now we have learned very briefly about SDN and overlays, let's have a comparison between these two technologies:

In summary, SDN and overlays are somehow completing each other, but they are different. Some people don't consider overlays as SDN, and some do.

OpenDaylight is an SDN controller, it is not an overlay.

The future of SDN might be a generic platform on which the network application would be written and create a new industry of network application service. We may expect different network applications to be released, which all tend to add intelligence to the network and get integrated with other applications and software. Many services are changing to some kind of anycast that requires an intelligent network to decide which client's request must be directed to which server. Some of these services are available now, for example the new NAS servers with anycast support integration with OpenFlow to the SDN network (products from Coho Data).

Similar to a computer operating system that delivers computing resources to an application, an SDN network operating system might be able to deliver packets to the application. The application decides how they would like to use the services.

With popularity of VMware and OpenStack as well as cloud services such as Amazon AWS and Azure, we expect that the SDN platforms in the future will support such integration natively. SDN platforms will be able to extend the local networks toward the AWS cloud virtual network and provide a seamless network from user premises to the cloud. They will handle all type of API integrations and creation of the required overlay or VPNs between sites and manage the packet delivery (a.k.a. routing in the legacy world).

SDN as it stands for Software-Defined Network, will get more visibility on applications. SDN platform will be able to understand the applications by integration with other platforms. SDN will know a Hadoop HDFS replication running between servers, and knows what priority it has and how to deal with it to ensure the application performance, while at the same time deals with a telepresence call between multiple parties and manages the real-time traffic and ensures no disruption on real-time traffic.

We have been using the IP addressing schema for many years. IP subnets are always used for grouping the networks and hosts and they are the key for routing decisions. All routing protocols exchange the subnets and prefixes to perform routing and build their routing tables. In an SDN enabled network there is no routing and this may change the way we used to perform IP address assignments. In a legacy network we understand the layer 2 broadcast very well. A host with an IP address of 192.168.1.1/24 will be able to reach another host with the IP address of 192.168.1.2/24 on the same network. The host sends an ARP request, the legacy switch broadcasts the ARP and destination replied back the ARP with its MAC address and finally the communication happens as both hosts find out the MAC addresses of each other.

Our defined rules of hosts on the same subnets or in different subnets doesn't apply in an SDN network. The SDN controller is the god of the network and decides which hosts shall be able to communicate with each other, regardless of their IP address or subnet mask. For example, imagine two hosts with IP details as follows:

• Host A: 192.168.1.1/24
• Host B: 192.168.2.2/24

Normally if host A needs to communicate with host B, it needs to send its traffic to its default gateway and default gateways should perform a routing to reach the destination network.

In the SDN platform, the SDN controller knows where both host A and host B are connected. Once host A needs to send a packet to host B, it's the SDN controllers job to cheat and reply back the ARP request of host A, and enable a direct communication between host A and host B although they are not in the same subnet.

This may sound freaky as SDN can destroy all the rules and laws of networking, but remember that you should compare the SDN with a chassis-based switch. SDN has a domain and out of that domain it follows the legacy network rules and protocols. In a chassis based switch when a packet enters from port 1 on line card 3 and the destination is a host connected to port 2 on line card 2, the switch management module as well as the FIB memory on line cards has visibility on where the destination is connected, similar to SDN the switch may just forward the packet out of its port 2 on line card 2 where it is required.

It is highly likely that all of the aforementioned imaginations and scenarios will occur to some degree, but it will be mainly depending on business cases, vendors, and how customers demand such services from vendors.

BUM is the acronym for Broadcast, Unknown, Multicast in layer 2 frames. I know you all know about them very well, and in fact BUM is something that network engineers don't deal with on a daily basis. In traditional networking, BUM is the pure job of switch silicon.

But in an SDN world, BUM is a key element for system robustness, a very important factor. Let's look at why we need to deal with BUM carefully.

In traditional networking, a very basic layer 2 switch, regardless of its speed of 10 Mbps to 100 Gbps, has the basic capability to switch the traffic based on layer 2 information of a frame (frame is a layer 2 message, which holds the layer 3 packet encapsulated inside the frame's payload). When a layer 2 switch receives a frame, it builds a simple table mapping between the source MAC address and the port the frame has arrived.

The preceding table is called a TCAM or MAC address table, or other names (by different vendors).

If a switch receives a frame destined for a MAC address that doesn't exist in its MAC address table, or it is a broadcast frame (that is ARP, destined for FF;FF:FF:FF:FF:FF), or a multicast frame, the layer 2 switch by default copies the frame over all of its ports, except the port the frame has arrived.

This is the way a basic layer 2 switch deals with BUM in the background where the network engineer doesn't notice.

In the SDN world, as I explained previously, we are living in a world where a single controller knows the whole network and hosts. The switches are not intelligent enough to deal with a frame that they don't know where to send it to. What will happen to a frame that enters an SDN switch with broadcast MAC or a destination MAC address unknown to the switch (not listed in its flow table)?

The SDN switch needs to send this frame to the SDN controller and ask the controller where to send this frame. This also can be a packet. SDN switch uses the southbound protocol to request the controller about how to deal with this packet or frame.

SDN controller receives the frame from the SDN switch and it needs to react and tell the switch what needs to be done for the frame. This is a very important process and if the SDN controller fails to respond to the switch within a specific time, the frames will not pass and the source will keep waiting.

An ideal SDN controller should be very proactive by filling the flow tables of the switches in such a way that the number of requests from the switch to the SDN controller for BUM is reduced.

One of the key fundamentals of SDN is disaggregation. Disaggregation of software and hardware in a network and also disaggregation of control and forwarding planes.

The SDN controller is the main brain and controller of an SDN environment. It's a strategic control point within the network and it is responsible for communicating information to:

• Routers and switches and other network devices behind them. SDN controllers uses APIs or protocols (such as OpenFlow or NETCONF) to communicate with these devices. This communication is known as southbound.
• Upstream switches, routers or applications, and the aforementioned business logic (via APIs or protocols). This communication is known as northbound. An example of a northbound communication is a BGP session between a legacy router and SDN controller.

If you are familiar with chassis based switches such as Cisco Catalyst 6500 or Nexus 7k chassis, you can imagine an SDN network as a chassis, with switches and routers as its I/O line cards and SDN controller as its supervisor or management module. In fact SDN is similar to a very scalable chassis where you don't have any limitation on the number of physical slots.

SDN controller is similar to the role of the management module of a chassis-based switch and it controls all switches via its southbound protocols and APIs.

The following table compares the SDN controller and a chassis based switch:

The first protocol that popularized the concept behind SDN was OpenFlow. When conceptualized by networking researchers at Stanford back in 2008, it was meant to manipulate the data plane to optimize traffic flows and make adjustments, so the network could quickly adapt to changing requirements. Version 1.0 of the OpenFlow specification was released in December of 2009; it continues to be enhanced under the management of the Open Networking Foundation, which is a user-led organization focused on advancing the development of open standards and the adoption of SDN technologies.

OpenFlow protocol was the first protocol that helped in popularizing SDN. OpenFlow is a protocol designed to update the flow tables in a switch. Allowing the SDN controller to access the forwarding table of each member switch or in other words to connect control plane and data plane in the SDN world. Back in 2008, OpenFlow was conceptualized by networking researchers at Stanford University, the initial use of OpenFlow was to alter the switch forwarding tables to optimize traffic flows and make adjustments, so the network could quickly adapt to changing requirements.

After the introduction of OpenFlow, NOX was introduced as an original OpenFlow controller (there still wasn't a concept of the SDN controller). NOX was providing a high-level API capable of managing and also developing network control applications. Separate applications were required to run on top of NOX to manage the network. NOX was initially developed by Nicira networks (which was acquired by VMware, and finally became part of VMware NSX). NOX was introduced along with OpenFlow in 2009. NOX was a closed source product, but ultimately it was donated to the SDN community, which led to multiple forks and sub projects out of original NOX. For example, POX is a sub project of NOX, which provides Python support. Both NOX and POX were early controllers. NOX appears an inactive development, however POX is still in use by the research community as it is a Python-based project and can be easily deployed.

NOX apart from being the first OpenFlow or SDN controller also established a programming model that is inherited by other subsequent controllers. The model was based on processing of OpenFlow messages, with each incoming OpenFlow message triggering an event that had to be processed individually. This model was simple to implement, but not efficient and robust and couldn't scale.

Nicira along with NTT and Google started developing ONIX, which was meant to be more abstract and scalable for large deployments. ONIX became the base for Nicira (the core of VMware NSX or network virtualization platform) and there are rumors that it is also the base for Google WAN controller. ONIX was planned to become open source and donated to the community, but for some reasons the main contributors decided to not do it, which forced the SDN community to focus on developing other platforms.

Starting in 2010, a new controller was introduced. It was called the Beacon controller and it became one of the most popular controllers. It was born due to the contribution of developers from Stanford University. Beacon is a Java-based open source OpenFlow controller created in 2010. It has been widely used for teaching, research, and as the basis of Floodlight. Beacon had the first built-in web user-interface, which was a huge step forward in the market of SDN controllers. Also it provided an easier method to deploy and run compared to NOX. Beacon was an influence for design of later controllers after it; however, it was only supporting star topologies, which was one of the limitations of this controller.

Floodlight was a successful SDN controller that was built as a fork of Beacon. Big Switch networks are developing Floodlight along with other developers. In 2013, Beacon popularity started to shrink and Floodlight started to gain popularity. Floodlight had fixed many issues of Beacon and added lots of additional features, which made it one of the most feature rich controllers available. It also had a web interface, a Java-based GUI, and it also could get integrated with OpenStack using the quantum plugin. Integration with OpenStack was a big step forward as it could be used to provide networking to a large pool of virtual machines, compute, and storage. Floodlight adoption increased by evolution of OpenStack and OpenStack adopters. This gave Floodlight greater popularity and applicability than other controllers that came before. Most of the controllers that came after Floodlight also supported OpenStack integration.

Floodlight is still supported and developed by community and Big Switch networks, and it is a base for Big Cloud Fabric (the Big Switch's commercial SDN controller).

There are other open source SDN controllers that are introduced such as Trema (ruby-based from NEC), Ryu (supported by NTT), FlowER, LOOM, and the recent OpenMUL.

The following table shows the current open source SDN controllers:

OpenDaylight started in early 2013, and it was originally led by IBM and Cisco. It was a new collaborative open source project. OpenDaylight is hosted under Linux Foundation and it draws support and interest from many developers and adopters. OpenDaylight is a platform to provide common foundations and a robust array of services for SDN environments. OpenDaylight uses a controller model that supports OpenFlow as well as other southbound protocols. It is the first open source controller capable of employing non-OpenFlow proprietary control protocols, which eventually lets OpenDaylight to integrate with modern and multi-vendor networks.

The first release of OpenDaylight was in February 2014 with the code name Hydrogen, followed by Helium in September 2014. The Helium release was significant because it marked a change in direction for the platform that has influenced the way subsequent controllers have been architected. The main change was in the service abstraction layer, which is the part of the controller platform that resides just above the southbound protocols, such as OpenFlow, isolating them from the northbound side and where the applications reside.

Hydrogen used an API-driven Service Abstraction Layer (AD-SAL), which had limitations, specifically it meant the controller needed to know about every type of device in the network AND have an inventory of drivers to support them.

Helium introduced a Model-driven service abstraction layer (MD-SAL), which meant the controller didn't have to account for all the types of equipment installed in the network, allowing it to manage a wide range of hardware and southbound protocols.

The Helium release made the framework much more agile and adaptable to changes in the applications; an application could now request changes to the model, which would be received by the abstraction layer and forwarded to the network devices.

The OpenDaylight platform built on this advancement in its third release, Lithium, was introduced in June of 2015. This release focused on broadening the programmability of the network, enabling organizations to create their own service architectures to deliver dynamic network services in a cloud environment, and craft intent-based policies.

The Lithium release was worked on by more than 400 individuals, and contributions from Big Switch Networks, Cisco, Ericsson, HP, NEC, and so on, making it one of the fastest growing open source projects ever. The fourth release, Beryllium, came out in February of 2016 and the most recent fifth release, Boron, was released in September 2016.

Many vendors have built and developed commercial SDN controller solutions based on OpenDaylight. Each product has enhanced or added features to OpenDaylight to have some differentiating factor. The use of OpenDaylight in different vendor products are:

• A base, but also sell a commercial version with additional proprietary functionality-for example: Brocade, Ericsson, Ciena, and so on
• Part of their infrastructure in their Network as a Service (or XaaS) offerings-for example: Telstra, IBM, and so on
• Elements for use in their solution-for example: ConteXtream (now part of HP)

Open Networking Operating System (ONOS), which was open sourced in December 2014, is focused on serving the needs of service providers. It is not as widely adopted as OpenDaylight; ONOS has been finding success and gaining momentum around WAN use cases. ONOS is backed by numerous organizations including AT&T, Cisco, Fujitsu, Ericsson, Ciena, Huawei, NTT, SK Telecom, NEC, and Intel, many of whom are also participants in and supporters of OpenDaylight.

Apart from open source SDN controllers, there are many commercial, proprietary controllers available on the market. Products such as VMware NSX, Cisco APIC, Big Switch Big Cloud Fabric, HP VAN, and NEC ProgrammableFlow are examples of commercial and proprietary products.

The following table lists the commercially available controllers and their relationship to OpenDaylight:

Regardless of an open source or a proprietary SDN platform, there are core features and capabilities that require the SDN platform to support. These capabilities include:

• Fabric programmability: Providing the ability to redirect traffic, apply filters to packets (dynamically), and leverage templates to streamline the creation of custom applications. Ensuring northbound APIs allows the control information centralized in the controller available to be changed by SDN applications. This will ensure that the controller can dynamically adjust the underlying network to optimize traffic flows to use the least expensive path, take into consideration varying bandwidth constraints, and meet the quality of service (QoS) requirements.
• Southbound protocol support: Enabling the controller to communicate to switches and routers and manipulate and optimize how they manage the flow of traffic. Currently OpenFlow is the most standard protocol used between different networking vendors, while there are other southbound protocols that can be used. An SDN platform should support different versions of OpenFlow in order to provide compatibility with different switching equipments.
• External API support: Ensuring the controller can be used within the varied orchestration and cloud environments such as VMware vSphere, OpenStack, and so on. By using APIs the orchestration platform can communicate with the SDN platform in order to publish network policies. For example, VMware vSphere shall talk to the SDN platform to extend the virtual distributed switches (vDS) from virtual environment to the physical underlay network without any requirement from an network engineer to configure the network.
• Centralized monitoring and visualization: Since the SDN controller has a full visibility over the network, it can offer end-to-end visibility of the network and centralized management to improve overall performance, simplify the identification of issues, and accelerate troubleshooting. The SDN controller will be able to discover and present a logical abstraction of all the physical links in the network, also it can discover and present a map of connected devices (MAC addresses), which are related to virtual or physical devices connected to the network. The SDN controller support monitoring protocols, such as syslog, snmp, and APIs in order to integrate with third-party management and monitoring systems.
• Performance: Performance in an SDN environment mainly depends on how fast the SDN controller fills the flow tables of SDN enabled switches. Most SDN controllers pre-populate the flow tables on switches to minimize the delay. When an SDN enabled switch receives a packet that doesn't find a matching entry in its flow table, it sends the packet to the SDN controller in order to find where the packet needs to get forwarded to. A robust SDN solution should ensure that the number of requests from switches are minimum and the SDN controller doesn't become a bottleneck in the network.
• High availability and scalability: Controllers must support high availability clusters to ensure reliability and service continuity in case of failure of a controller. Clustering in the SDN controller expands to scalability. A modern SDN platform should support scalability in order to add more controller nodes with load balancing in order to increase the performance and availability. Modern SDN controllers support clustering across multiple different geographical locations.
• Security: Since all switches communicate with SDN controller, the communication channel needs to be secured to ensure unauthorized devices doesn't compromise the network. SDN controller should secure the southbound channels, use encrypted messaging, and mutual authentication to provide access control. Apart from that the SDN controller must implement preventive mechanisms to prevent from denial of services attacks. Also deployment of authorization levels and level controls for multi-tenant SDN platforms is a key requirement.

Apart from the aforementioned features SDN controllers are likely to expand their function in future. They may become a network operating system and change the way we used to build networks with hardware, switches, SFPs, and gigs of bandwidth. The future will look more software defined, as the silicon and hardware industry has already delivered their promises for high performance networking chips of 40G, 100G. The industry needs more time to digest the new hardware and silicons and refresh the equipment with new gears supporting 10 times the current performance.

This topic is very crucial, as in many cases stakeholders think why do they have to invest in SDN? What can SDN provide that the legacy network cannot? That's a valid question to ask.

There are multiple good use cases where SDN can add value:

• A network operating system: The SDN platform can act as a network operating system, providing packet delivery to other applications. SDN is a platform and allows other applications to drive, use the network for their specific requirements. Always remember that SDN doesn't do any packet delivery on its own, but it requires SDN applications (many of them) to define how packets needs to get delivered in a network.
• Network Access Control: One of the SDN use cases is NAC. The SDN controller can identify the newly connected devices and checks what this new device is, and what it needs to access and push the flow settings back to the SDN enabled switches. This method eliminates the use of 802.1x and VLAN assignments.

This diagram illustrates the use of SDN to enforce Network Admission Control (NAC) :

• Anycast applications: Anycast applications are referred to as distributed systems, which are built with multipole service nodes in a network. For example, streaming servers and file and object servers. With the change of the way application servers are built to a scale-out model, most modern service applications architecture is based on a distributed scale out model that all operates independently. An SDN platform is able to deliver the user requests to the closest, or better saying the best service node of an application. Other than being close there are other parameters such as load, bandwidth, and data availability. As an example an object storage platform might have multiple service nodes distributed in different location in the network and all working at the same time, using a single IP address. SDN networks will be able to understand where the service nodes are located (connected to which switch at what port) and will route the client requests to a particular network node that is considered as its best choice based on different parameters.
• Integration with private cloud (VMware, OpenStack): With increased use of VMware vSphere and OpenStack in data centers, the need to integrate the network with cloud infrastructure is increasing. An SDN network can get integrated with cloud application and provide the ability to create virtual networks, tenant isolation, and even create overlay networks using VXLAN. Also it can support service chaining to insert L4-L7 services.

The controller is the key component to integrate with cloud application via APIs.

• Virtual CPE and virtual CE: In a service provider environment, normally service providers install a dedicated router in each customer premises, which is always a rigid expensive box forced to clients. With the introduction of SDN, many service providers found this momentum and started using the opportunity window in order to build their SDN CPE, moving out from a dedicated router, replacing it with a commodity hardware (x86), which can run multiple virtual machines for network functions virtualization (NFV). AT&T and NTT have been successful in this area while others such as Verizon are also building their portfolio. Using SDN, the service provider will be able to use an edge SD-WAN enabled virtual machine to connect the customer to the network.

Another change in WAN and SD-WAN is the increase of reliability of consumer grade Internet connections. Many organizations prefer to use multiple cheap, high bandwidth Internet links instead of using an expensive limited bandwidth MPLS connection from their service provider. To answer this trend, which leads to popping up of SD-WAN products and vendors, service providers started to standardize a provisioning method of delivering an MPLS link and a (or more) Internet links to clients, which is called local Internet breakout. SD-WAN utilizes the local Internet breakout to build a secure tunnel to service provider networks and runs an SDN software with enough intelligence to understand what traffic should be routed via MPLS and via the Internet link.

SD-WAN is currently started to boom and there are many vendors such as Silver Peak, Riverbed, VeloCloud, Citrix, and so on, providing competitive and interesting products to enable enterprises to reduce their WAN costs and increase the quality of services.

• Service providers: In a service provider network where there are multiple geographical routers to provide backbone connectivity to clients, an SDN enabled network allows injecting and overriding the policies over the provider routers. In service provider networks the southbound protocols are normally BGP-PCEP, which is being promoted and used in many SP proof of concept installations. With SDN, a service provider will be able to override the MPLS or BGP decisions and route the specific traffic in a different way other than what has been determined by routing protocol. Cisco has done some progress in this area, remember that Cisco is one of the contributors to OpenDaylight and in fact the ODL web interface (Next) is donated by Cisco. You can find the Cisco service provider SDN example here:

https://github.com/CiscoDevNet/opendaylight-sample-apps

https://developer.cisco.com/site/opendaylight/discover/odl-at-cisco/build-apps-on-top-of-odl/

Although the SDN concept is still young and it is still within the hype, as you realized there are multiple SDN controllers and platforms available on the market. The available solutions in the market have different features and capabilities, which you need to understand before deciding on which controller or platform to choose and build your network on it. There are also products that use the marketing buzz words of SDN and try to pitch a legacy solution, which you need to be careful while evaluating them.

I have collected some key differentiators of SDN platforms and will take you through each as follows:

• Fabric or overlay: This is one of the most important attributes to look at and make the decision. Overlays are also considered as key drivers for network virtualization. Overlays are not dependent on underlay networks, meaning an overlay SDN can build an overlay SDN on top of a mesh IP underlay. Looking at SDN products in the market, some of them are basically an overlay, such as VMware NSX and Juniper Contrail. On the other hand the SDN fabric products are a full SDN aware underlay, which means that the SDN controller can communicate with all SDN switches in the network and control and program their flow and CAM tables. Solutions such as Cisco ACI and OpenDaylight are examples of a full fabric SDN platform.
• Open source versus proprietary: This attribute should only be important if you are considering extending the controller or have proprietary modifications specific to your business. In general and based on our studies, service providers are more interested in open source solutions as they use their tools and resources to productize and provide an SDN as a service to their customers. AT&T and NTT are good examples of service providers who took OpenDaylight and build their offerings based on that.

On the other hand, enterprises are interested in commercial and business supported products with specific SLA and support levels. Enterprises use SDN to run their business better. They are not interested to downgrade their network from a legacy L2/L3 to an SDN platform with no business case. Based on our studies, many enterprises have looked at and adopted Cisco ACI, VMWare NSX, and Big Switch Big Cloud Fabric, which are good commercial SDN platforms. When looking at commercial products, you need to always be careful about the vendor lock-in and find a solution that lets you scale and expand or even change your controller without impacting the switches in the network.

Openness in the SDN platform doesn't mean that you will be supported by the community. Commercial SDN controllers are based on OpenDaylight and are supported by companies such as Brocade and they are all open source as well as commercially supported.

• Application ecosystem and maturity of northbound APIs: SDN don't forget that an SDN platform doesn't work without SDN applications. SDN controller is a platform to run SDN applications. Without SDN applications the network doesn't forward any packet. A very basic SDN application is L2 switching, where you need to load and run the L2 application on a controller in order to have the very basic L2 switching (MAC learning) on your network. This may seem funny for some readers that the SDN has no built-in features; however, you should think that SDN is a methodology; it's a platform that allows you to build network applications and decide how you want the network to forward, route, or drop the packets.

Going back to our topic, while looking for an SDN solution you should consider choosing a SDN controller that provides a rich, complete, and developer friendly application environment. Many SDN platforms support Yet Another Next Generation (YANG) language, which is used for data modeling and also it is used as payload for NETCONF protocol.

• Where to deploy: You should consider your main use cases and compare against the capabilities and features of the SDN controllers in the market. For example, a controller designed for a campus network is not a good fit for a data center application. Or an SDN platform that doesn't have any plugin or capability to integrate with OpenStack is not a good fit for deploying in a OpenStack environment.

You should take into consideration your business use cases to find the best fit platform and controller for your business.

• Compatibility, reliability, and maturity of the platform: Although the SDN platform is a game changer in networking world, but it is still in its early stages and it's hard to find a solution that is deployed and worked for couple to years or find strong case studies. This is one of the key show stoppers for many enterprises trying to find a SDN solution that has a proven track record and has been deployed with multiple clients. CIOs and procurement look for proven solutions that have been used or certified.

Even standard protocols such as OpenFlow or OVSDB have different implementation between vendors and they might not be compatible with each other (for example, an OpenFlow switch from vendor A may not be compatible with an SDN controller from vendor B). These are challenges that require your attention prior to deciding which SDN platform you are going to live with.

• Smoothness of integration into orchestration platforms: Almost every commercial controller and many open source controllers provide OpenStack support in the data center. If you have a data center deployment and have picked a specific cloud management or orchestration platform (OpenStack, VMware vRealize, CloudStack, or others), check with the vendor or evaluate the open source distribution to ensure seamless integration into your orchestration environment.
• Integration with cloud and orchestration platforms: Nowadays almost every private cloud platform is built on VMware or some flavor of OpenStack or CloudStack. The SDN platform in data centers needs to integrate with OpenStack of VMware vSphere, and you need to check and ensure the level of integration and capabilities of the SDN solution with your choice of orchestration platform. Normally in data center environments, the SDN platforms provide direct integration with VMware vSphere and the SDN solution becomes part of the VMware virtual network and virtual distributed switches. The same applies to OpenStack and SDN solutions that will integrate with OpenStack via some kind of plugin (such as ML2 or other kinds of integrations).

If you are planning your SDN platform for a campus topology you need to check with your orchestration and policy tool about the integration with the SDN platform. Many SDN platforms provide such orchestration and tools along with their products; however, if you are using a specific orchestration tool you need to ensure how it is going to integrate with your SDN platform.

• Open APIs: Regardless of being open source of a proprietary closed source solution, you need to ensure that the SDN platform provides some kind of open APIs for integration with other tools. Other tools such as monitoring, orchestration tools, billing, abstract UIs, compute and storage tools, and so on. Normally APIs are not considered as a critical factor to make decisions and normally there is no day zero requirements for APIs, however, after deployment of the SDN platform slowly you will realize the requirement for integration with other systems. A very basic example is the cloud providers, where they need to have a single web interface for customers in order to create their tenant networks, subnets, and service insertion.
• A customer should be able to use the web interface of the platform to design and build his virtual network, add virtual routers, firewalls, and load balancers in their network while it is isolated and doesn't disturb other tenants or user traffic.

You should understand that the SDN market is still in its early stages. OpenDaylight has helped to change the landscape and also other open source projects such as ONOS OpenContrail and Calico which are mainly driving use cases is service provider networks.

You need to find the real need for going the SDN way and understand the capabilities of each SDN platform to make the correct decision. Remember in order to move to SDN you don't need to migrate everything and throw away your whole legacy network, No, you can build a SDN network for a POD (in a data center) or a building (in a campus) or a path (in a service provider).

In this section, I'm putting the different SDN controllers in a table. This will help you to understand the current market players in SDN and how OpenDaylight relates to them:

In previous sections, we went through the role of the SDN controller, and a brief history of ODL. ODL is a modular open SDN platform that allows developers to build any network or business application on top of it to drive the network in the way they want.

Currently OpenDaylight has reached its fifth release (Boron, which is the fifth element in the periodic table). ODL releases are named based on periodic table elements, started from the first release, Hydrogen. ODL has a six month release period, with many developers working on expanding the ODL, two releases per year is expected from the community.

For technical readers to understand it more clearly, the following diagram will help:

The ODL platform has a broad set of use cases for multivendor, brown field, green fields, service providers, and enterprises. ODL is a foundation for networks of the future.

Service providers are using ODL to migrate their services to a software enabled level with automatic service delivery and coming out of a circuit-based mindset of service delivery.

Also they work on providing a virtualized CPE with NFV support in order to provide flexible offerings.

Enterprises use ODL for many use cases, from data center networking, Cloud and NFS, network automation and resource optimization, visibility, control, to deploying a full SDN campus network.

ODL uses an MD-SAL, which makes it very scalable and lets it incorporate new applications and protocols faster. We will cover more details about MD-SAL in upcoming chapters where we will dive into ODL.

ODL supports multiple standard and proprietary southbound protocols, for example, with full support of OpenFlow and OVSDB, ODL can communicate with any standard hardware (or even the virtual switches such as Open vSwitch (OVS) supporting such protocols). With such support, ODL can be deployed and used in multivendor environments and control hardware from different vendors from a single console no matter what the vendor and what device it is, as long as they support standard southbound protocols.

ODL uses a micro service architecture model, which allows users to control applications, protocols, and plugins while deploying SDN applications. Also ODL is able to manage the connection between external consumers and providers.

The following diagram explains the ODL footprint and different components and projects within the ODL:

ODL stores its YANG data structure in a common data store and uses messaging infrastructure between different components to enable a model-driven approach to describe the network and functions.

In ODL MD-SAL, any SDN application can be integrated as a service and then loaded into the SDN controller. These services (apps) can be chained together in any number and ways to match the application needs.

This concept allows users to only install and enable the protocols and services they need, which makes the system light and efficient.

Also services and applications created by users can be shared among others in the ecosystem since the SDN application deployment for ODL follows a modular design.

ODL supports multiple southbound protocols. OpenFlow and OpenFlow extensions such as Table Type Patterns (TTP), as well as other protocols including NETCONF, BGP/PCEP, CAPWAP, and OVSDB. Also ODL supports the Cisco OpFlex protocol:

The ODL platform provides a framework for Authentication, Authorization, and Accounting (AAA), as well as automatic discovery and securing of network devices and controllers.

Another key area in security is to use encrypted and authenticated communication through southbound protocols with switches and routers within the SDN domain. Most southbound protocols support security encryption mechanisms.

As a network professional, you will have been involved with day to day networking tasks. Tasks such as creating and managing VLANs and ports, trunking (802.1q), managing spanning trees, link aggregation, routing, accessing lists, troubleshooting, and logging.

Let's have a look at what happens to these fundamentals in SDN:

• Spanning tree: Spanning tree has been always a painful protocol to manage for all network professionals. Spanning tree is a complex (when it comes to per VLAN, MSTP, RSTAP, compatibility, and so on) mechanism to create a loop-free layer 2 network. Spanning tree is not efficient as it disabled the links that may create a loop.

In recent years, many organizations have tried to eliminate the spanning tree by migrating to a full layer 3 routed fabric or using proprietary multi-chassis link aggregation technologies.

Anyhow, the good news is that in SDN, there is no need for spanning trees. The SDN controller, as the brain of the whole network knows how each switch in the network should send and receive packets in order to have a complete loop-free network.

Also remember that BUM is managed and handled by the SDN controller, which reduces the risk of loops.

The required features of spanning trees are also included in the L2 switching application of ODL.

• VLANs: Let's review our traditional understanding of VLANs. A virtual LAN (VLAN) is a method to divide a basic layer 2 switch into multiple standalone switches. Ports in different VLANs will not be able to communicate with each other. Technically the VLAN concept is implemented in the switch's silicon, and doesn't allow any entry in the TCAM table where the source and destination ports belong to different VLANs (that's a simple implementation in silicon).

In the world of SDN, as all forwarding is controlled by the SDN controller, the concept of VLAN is managed by the SDN controller. In ODL it is managed by the L2 application.

• Trunking (802.1q): Trunking and the concept of tagged and untagged frames exists in SDN very similar to the traditional world. In traditional layer 2, a switch was able to send a packet untagged (access-port) or with a tag that can only be the VLAN ID of that frame.

In the world of SDN, a switch will send a frame with any 802.1q tag, which the SDN controller decides. For example, a switch might receive a frame with VLAN tag of 100, and then sends it out with the VLAN ID of 200. This is something that is beyond the concepts of traditional 802.1q and VLANs.

• Link aggregation: Link aggregation uses standard protocols such as LACP. Link aggregation exists in SDN similar to the traditional networking world. Link aggregation is supported by most SDN controllers, as well as ODL. ODL includes specific modules to support link aggregation.

Technically, when you configure two ports as a link aggregation using the ODL interface, the ODL SDN controller sends the required configuration to the related switch using a southbound protocol (for example, NETCONF) and tells that switch hardware to configure the ports in link aggregation mode.

• Routing: Routing between the switches within the SDN domain is not required. It is managed by the SDN controller. However, the SDN controller supports routing protocols such as BGP and OSPF to communicate outside of the world of SDN.

In this chapter, we learned about SDN and why it is important. We reviewed the SDN controller products, the ODL history, as well as core features of SDN controllers and market leader controllers. We managed to look at aspects of SDN in detail such as BUM and flow tables and, at the end, we reviewed how the traditional concepts and protocols function in the world of SDN.

In the next chapter, we will start looking at ODL components and modules.