The OCSA exam tests your understanding of components in an SDN framework, your ability to articulate the fundamental workings of networking and the OpenFlow protocol, as well as your knowledge of vendors, solutions and projects available in the SDN landscape.

This is the fourth part in a series of posts that review the blueprint for the OCSA exam and provide descriptions and resources to help you achieve the certification. The posts are broken down by the sections detailed in the OCSA blueprint.

Part 1
Part 2
Part 3

Domain 4: SDN Architecture and Ecosystem

From the Blueprint:

Understand and Identify SDN architectural components, standards bodies, controller design, API’s and applications.

• SDN Layers
• SDN Architecture compared to Traditional Network Architectures
• Northbound API’s
• Southbound API’s
• East/West API’s
• Security and Availability
• Packet and Optical Integration methods
• Migration Strategies
• Hybrid Mode Switches
• Organization in the SDN Ecosystem
• Standards Bodies and Industry alliances
• Network Operators and Enterprises
• Network Equipment Manufacturers
• Software vendors
• Academic and Industry research institutions and labs
• Open Source Initiatives
• Who is the ONF and what do they do?
• Purpose
• Structure
• Technical Working Groups
• Open Source Software Development
• Activities and Initiatives
• Controller Placement and Redundancy
• SDN Applications (service chaining, virtualized network functions, analytics)

SDN Layers

Understand the layers of SDN: Application, Control, Data.

SDN Architecture compared to Traditional Network Architectures

Know the difference between a traditional system with individualized control planes interacting in some hierarchy, and that of an SDN architecture where control and data planes are decoupled. This isn’t to say you can’t have a controller hierarchy because you can, thanks to the beauty of northbound APIs.

NSEW APIs

APIs in all cardinal directions! North, South, East & West.

Security & Availability

Can you have multiple controllers? Of course!
Can you secure the communication between controllers and switches? Of course! TLS is your friend.

Packet and Optical Integration methods

Most WANs employ SONET/SDN or OTN circuit-switching elements, which are not technologies supported by OpenFlow’s packet-based methodologies. The ONF Optical Transport Working Group (OTWG) got together to find a solution for the challenge which impacts Service Providers. Through the OTWG, OpenFlow has been extended to support Layer 0 (photonic) and Layer 2 (SONET/SDH,OTN) networks in the same centralized control manner it does for packet switched Layer 2 and Layer 3 networks. In short, there are solutions for hybrid models where optical networks and packet networks can coexist and be managed by OpenFlow controllers.

Read this solution brief, it’s mind-blowing:

Click to access sb-of-enabled-transport-sdn.pdf

Migration Strategies

Read this solution brief:

Click to access sb-sdn-migration-use-cases.pdf

Hybrid Mode Switches

In my last blog post, I quickly mentioned the fact you could have hybrid switches in your environment, where some ports are configured for OpenFlow and use a remote controller, and other ports are local to the switch and controlled by the local switch’s control plane. This is a completely supported model and widely adopted in migration strategies.

To communicate between these ports on the same switch, OpenFlow will use what’s called a NORMAL port. This tells the entry in the flow table to go to the pipeline of the local switch for further processing. This is detailed in section 5.1 of the OpenFlow Switch Specification document.

Organizations in the SDN Ecosystem

Standards Bodies and Industry alliances

I recommend knowing everything on this page:

Network Operators and Enterprises

Likely nothing too crazy to know here other than the various components of the Operator Area exist:

• Carrier Grade SDN
• Data Center
• Enterprise
• Migration

More information here: https://www.opennetworking.org/technical-communities/areas/operator

Network Equipment Manufacturers & Software Vendors

Honestly, almost every network equipment manufacturer out there has support for OpenFlow in some form. For a full list managed by ONF, check out this page:

https://www.opennetworking.org/sdn-openflow-products

If there are networking vendors out there that do not have SDN strategies, they’re in trouble.

Open Source Initiatives

• OpenSourceSDN.org
• SDN community and software repository
• Atrium
• An open SDN software distribution to overcome challenges faced by network operators
• Aspen + Boulder
• Intent-driven projects surrounding the challenge of agility and portability
• OpenFlow Driver
• Open source code developed by CPqD to address another potential layer of abstraction: data plane <> hardware

More information here: https://www.opennetworking.org/sdn-resources/opensource-sdn

Onward

Continue on to Part 5, the last post in this series which covers Domain 5 of the blueprint.