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.
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.
Thanks for the deatils. Some of the links mentioned seem to have moved or deleted
https://www.opennetworking.org/about/liaisons
https://www.opennetworking.org/technical-communities/areas/operator
https://www.opennetworking.org/sdn-openflow-products
https://www.opennetworking.org/sdn-resources/opensource-sdn
Hi,
I am looking for answer of these question for many days:
Which version of Openflow supports IPV6?
Which version of openflow supports MPLS.
Which version is backward compatable?
openflow 1.2 support ipv6.
openflow 1.1 support vlan and mpls.
i think every version is backward compatible to the version that before.