OpenDaylight as an SDN controller

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:

Microservices architecture

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.

Traditional networking terms and features in the world of SDN

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.

Summary

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.