OpenFlow Service Chaining

OpenFlow and SDN Adoption

 

SDN Adoption report

 

SDN Adoption

In networking, OpenFlow and Software-Defined Networking (SDN) have emerged as groundbreaking technologies that are transforming how networks are designed, managed, and operated. This blog post aims to provide a comprehensive understanding of OpenFlow and SDN adoption, shedding light on their benefits, challenges, and the future of network infrastructure.

 

Highlights: SDN Adoption

  • The Role of OpenFlow

Firstly, the basis of the SDN adoption report is the OpenFlow protocol, an existing technology derived from academic labs. Its origins can be traced back to 2006 when Martin Casado, part of the “Clean Slate” program, developed Ethane. They were trying to figure out ways to manage the network states via a centrally managed global policy.

The idea that networks are dynamic and non-symmetrical poses challenges in keeping track of their state to enforce programmability. The program has stopped but produced several follow-up programs, including OpenFlow and SDN.

SDN OpenFlow is not something that is revolutionary new. Similar ideas have been available, and previous projects tried to solve the same problems OpenFlow is trying to solve today. Besides the central viewpoint use case, whatever you can do with OpenFlow today is possible with Policy Based Routing (PBR) and ACL. The problem is that these tools are clumsy and do not scale well.

 

You may find the following useful for pre-information:

  1. Virtual Overlay Network
  2. SDN Router
  3. What is OpenFlow
  4. BGP SDN
  5. SDN BGP
  6. Hyperscale Networking
  7. SDN Data Center

 



SDN Adoption Report.

Key SDN Adoption Discussion Points:


  • Introduction to SDN OpenFlow and what is involved.

  • Highlighting the SDN architecture.

  • Critical points on the virtual switching fabric.

  • Technical details on the use of OSPF.

  • Technical details for programming the forwarding paths.

  • Final comments on SDN OpenFlow.

 

Back to basics with the SDN.

What is OpenFlow?

OpenFlow is an open standard that enables the separation of the control plane and the data plane in network devices. It allows network administrators to centrally control and manage the behavior of network switches and routers, resulting in increased network programmability, flexibility, and scalability. OpenFlow provides a standardized protocol that facilitates communication between the control and data planes, enabling the network to be programmed and controlled through software.

Understanding SDN Adoption:

SDN is a paradigm shift in network architecture that leverages OpenFlow and other technologies to virtualize and abstract network resources. With SDN, the control plane is decoupled from the underlying physical infrastructure, allowing network administrators to configure and manage networks through a centralized controller dynamically. This centralized control simplifies network operations, enhances automation, and creates innovative network services.

The use of APIs

Besides the network abstraction, the SDN architecture will deliver a set of APIs that streamline the implementation of standard network services. These network services include routing, security, access control, and traffic engineering. Consequently, we can achieve exceptional programmability, automation, and network control, enabling us to build highly scalable and flexible networks that readily adapt to changing business needs. Then we have OpenFlow and the SDN story. OpenFlow is the first standard interface explicitly designed for SDN, providing high-performance and granular traffic control across multiple networking devices.

 

Benefits of OpenFlow and SDN Adoption:

The adoption of OpenFlow and SDN comes with numerous benefits for organizations of all sizes:

1. Enhanced Network Programmability: OpenFlow and SDN enable network administrators to program and control networks through software, making implementing new network services and policies easier.

2. Increased Flexibility and Scalability: SDN allows for dynamic network reconfiguration and resource allocation, ensuring networks can adapt to changing requirements and scale efficiently.

3. Centralized Network Management: With SDN, network administrators can manage and configure multiple network devices from a centralized controller, simplifying network operations and reducing the complexity of managing traditional networks.

4. Improved Network Security: SDN facilitates the implementation of granular security policies, enabling network administrators to detect and respond to security threats quickly, enhancing overall network security.

Challenges and Considerations:

While OpenFlow and SDN offer significant advantages, their adoption comes with a few challenges that organizations need to address:

1. Compatibility: Not all network devices and vendors fully support OpenFlow and SDN, requiring organizations to consider device compatibility carefully before implementation.

2. Skillset and Training: SDN introduces new concepts and requires network administrators to acquire skills and knowledge to deploy and manage SDN-based networks effectively.

3. Transition from Legacy Infrastructure: Migrating from traditional networking solutions to SDN-based architectures requires careful planning and a phased approach to minimize disruptions and ensure a smooth transition.

 

Starting Points for SDN Adoption

SDN Architectures and OpenFlow

SDN architectures and OpenFlow offer several advantages. You can influence traffic forwarding behavior at a more granular flow level. A holistic view instead of a partial view of distributed devices simplifies the network. Traffic engineering with SDN becomes easier to implement when you have a centralized view; this is how Google implemented SDN. Google has two network backbones; Internet-facing and data center backbone. 

They noticed that the cost/bit was not decreasing as the network grew. It was doing the opposite. Their solution was to implement a centralized controller and manage the WAN as a fabric, not as a collection of individual nodes.

 

SDN adoption report: Virtual switching fabric

SDN architectures allow networks to move from loosely coupled systems to a virtual switching fabric. One extensive flat virtualized network that appears and can be managed as a single switch has many operational advantages. The switch fabric consists of multiple physical nodes but behaves like one big switch. For example, a port on any underlying switch fabric nodes or virtual switch appears as a port to the single switching fabric.

The entire data plane becomes an abstraction. By employing this architecture, we manage the data plane as a whole entity instead of a set of loosely coupled connected devices. The control and data planes are distributed to the same locations if we study existing networks. No central point controls individual nodes, resulting in complex cross-network interactions.

 

sdn adoption

Open Shortest Path First (OSPF)

Open Shortest Path First (OSPF) calculates the shortest path tree from each node to every other node. Each OSPF neighbor must establish an adjacency, build, and synchronize the link-state databases (LSB). The complexity can be reduced by designing OSPF areas with ABRs, but by sacrificing some precision of route information. Imagine that every node reports and synchronizes its LSB to a central controller with an OSPF SDN application instead of individual nodes.

The controller can perform the Shortest Path First (SPF) calculation and directly update each node’s forwarding information base (FIB). The network now becomes programmable. While it does bring advantages, the laws of physics have not changed.

OpenFlow does not decrease latency or let you push more bits through a link. It does, however, let you manage and control your network better. It removes the box-by-box mentality and introduces automation and programmability.

SDN CONTROLLER

Do you think OpenFlow will be derailed?

SDN OpenFlow has come up against some market adoption barriers, such as silicon challenges and numerous vendor-specific extensions. In addition, the lack of conformance tests has led to some inconsistencies. It depends on how you define it. To explain it, you need to know what it is not. It is not a controller or a forwarding switch but a communication between the two.

It has a distinct place in the SDN architecture and does not run anywhere except between the control (controller) and the data plane, such as the OVS bridge acting as the switch infrastructure. SDN OpenFlow is also not alone in this space; other technologies provide control and data plane communications, such as BGP, Open vSwitch Database Management Protocol (OVSDB), NETCONF, and Extensible Message and Presence Protocol (XMPP).

Juniper’s OpenContrail uses XMPP.

 

SDN ADOPTION

It is evolving, and emerging technologies are sometimes slow to adopt. For example, in the early days of Novell networks, there were 4-frame types. Likewise, OpenFlow is changing and adapting as time progresses. For example, the original version of OpenFlow did not have multiple flow tables; now, versions 1.3 and 1.4 have multiple tables with various actions and many additional features.

 

Will it be used for program forwarding paths instead of BGP? 

Probably not, but it will augment BGP and other traditional technologies. It is not strictly a YES or NO answer as the SDN adoption falls into two buckets: one with OpenFlow and one without. Take the IPv6 adaptations as the IPv4 “replacement.” There was a “D” day of IPv4 address exhaustion, but IPv4 is still widely used. New “transition” mechanisms such as 6to4 and NAT64 are still widely deployed. It is the same with SDN and OpenFlow.

There will be ways to make traditional networks communicate with SDN and OpenFlow. BGP was invented as an EBGP, but people use EBGP Internal in their network. BGP is also used as an SDN control plane. It will be the case that you have controllers that provide automation and a holistic view but can speak BGP or OSPF to program the forwarding devices. SDN migrations will come incrementally, similar to what we see with IPv4 and IPv6

The lack of clarity in the controller space has limited the progress in OpenFlow. But; now, the controller market is consolidating, which gives users a clear path forward. This emergence is a good thing and will move OpenFlow forward. Maintaining SDN applications on different controllers is a dead-end, but now that OpenDaylight is emerging, we have controller unity.

A market with numerous open-source controllers would make SDN application development difficult. There will always be business drivers for proprietary controllers serving a particular niche and corner case problems the open community did not invest in. Even today, specialized UNIX platforms exist when you look at open Linux. Similarly, this flow of technology adoption will be evident for OpenFlow controllers.

 

The Future of OpenFlow and SDN:

The adoption of OpenFlow and SDN has gained significant momentum in recent years, and the future looks promising for these technologies. With the increasing demand for flexible, scalable, and programmable networks, OpenFlow and SDN are vital in deploying 5G networks, Internet of Things (IoT) applications, and network virtualization.

Conclusion:

OpenFlow and SDN adoption revolutionizes network infrastructure, offering increased programmability, flexibility, and centralized management. While challenges exist, the benefits of OpenFlow and SDN far outweigh the drawbacks. As organizations continue to embrace digital transformation, OpenFlow and SDN will continue to shape the future of networking, enabling agile, scalable, and secure networks that can adapt to the evolving needs of modern businesses.

 

 

SDN Adoption report