SDN Terminology from RFCs?

Wendell Odom
By Wendell Odom April 23, 2015 09:05

80% of your job in networking is getting you and your co-worker to agree to what the terms mean.

That paraphrase comes from one of my three networking profs in college, from literally 30 years ago. But that statement is still true today. Getting to a shared understanding of what we mean helps in any conversation about networking, and failing to truly understand the terminology can cause problems.

SDN promises many things, but it certainly has a big impact on networking terminology. SDN introduces many new terms, but it also redefines some terms and reemphasizes the underlying concepts behind other long-used terms.

And then there are no terminology police to run around and make us all use terms the same way. It’s enough to drive you crazy!

Today’s post (and possibly a few more) explores some attempts to answer some of the questions about what SDN terms to use and what they mean. In this post, I’ll look at a relatively new Internet RFC: the SDN Layers and Architecture Terminology RFC.


Overview: Terminology is a Challenge

What’s a network? Is it a class A, B, or C network, as defined by IPv4? Any subset of an IPv4 class A, B, or C network – in other words, a subnet? Is a “network” a bunch of routers, switches, cables, access points, and so on? Is it a wireless LAN, defined by SSID? Is “network” defined by who owns what – my network is this stuff, your network is that stuff?

In computer networking, the term “network” can actually be one of the squishiest terms we use. It can used generally, specifically, and within different contexts.

As another example: what is a “switch”? Or even within this context: “OpenFlow creates an abstraction of a switch”. Do you still picture a pizza box made of teal blue sheet metal? A soft switch? Forwarding based on destination MAC? Routing? Firewalls, policers? Any thought towards how the abstraction connects to the real? Clearly, one little word can imply a lot depending on who’s talking and who’s listening.

And then there are always the terms that have multiple meanings – sometimes there is a different general vs literal meaning, and sometimes just a completely different use in the same industry. Just for fun, I Tweeted to ask the world, thought of a few myself, and came up with this list of common networking terms with common double meanings:

  • Domain
  • Routing
  • Segment
  • Classless
  • Packet
  • Port
  • AD
  • Cloud
  • SDN
  • Interface
  • Trunk
  • VDC
  • Fabric
  • DCE
  • RIP
  • Full mesh

And on that last one, as an example… a few years back, a highly-trusted tech editor reviewed a book I was writing, and we disagreed about the meaning of “full mesh”. I have great respect for this particular person, and still do. We both have decades of experience, and had both used the term “full mesh” for a long time. But we both had come to use that fairly common term to mean two things, with a different enough meaning to matter.

(And for the first time, I’m editing someone else’s new book right now… and the #1 theme for my tech edit comments? Disagreements about what the terms really mean.)


Avoiding Such Problems with SDN: Docs from IETF, ITU-T, and ETSI ISG

How can we avoid (as much as possible) the terminology mish mash with SDN? How can we define a common framework and lexicon? How can we do that without simply following one vendor’s effort, an effort that may cause us to lean toward that vendor’s view of the world? When do different standards use terms that already bump into each other, or use different terms for similar concepts?

Well, I’ve bumped into a few docs that I think help answer those questions. Some work better as reference, some work better as a document to read a few times, but all provide some context about terms to use. And the one I’ll focus upon today, RFC 7426, looks squarely at the issue of terms related to SDN.


RFC 7426 – SDN: Layers and Architecture Terminology

What are the fundamental elements of SDN? What in fact is SDN? What components exist? What architecture does one use to create an SDN network? What interfaces exist between different components?

Those are all great questions. But the question we’ll begin to answer today: What terms should we use for the components of the SDN architectural cake?

RFC 7426 makes an attempt at answering the above questions. It took SDN as it existed in 2014 (the RFC released in Jan 2015), analyzed the state of existing SDN standards and practices, with a fair amount of analysis and review. Then, the group working on the project got approval to publish this informational RFC that:

  • Describes a SDN architecture.
  • Defines layers, including the usual “planes” (eg, control plane), interfaces (eg, APIs), and abstractions.
  • Defines the terms for use with each.
  • Lists a large number of reference documents used as the basis for choosing the details in the RFC (over 70 references cited).

Also, it attempts to avoid any one particular view of SDN. In fact, quoting from the RFC:

“…the aim of this document is not to standardize any particular layer or interface but rather to provide a concise reference that reflects current approaches regarding the SDN layer architecture. We expect that this document would be useful to upcoming work in SDNRG as well as future discussions within the SDN community as a whole.”

(The RFC itself comes from a branch of the IETF called the Internet Research Task Force (IRTF), specifically the SDN Research Group (SDNRG) of the IRTF. The IRTF researches topics, and occasionally publishes informational RFCs, RFC 7236 being once such RFC.)

In short, this RFC provides a concise reference for SDN architecture and its terms, intending to be a practical help to those of us who care about SDN.


A Quick Look at the Architecture

If you’ve ever looked at an architectural diagram that featured open SDN w/ OpenFlow, or at the architecture of an SDN controller (for example, OpenDaylight), then much of the RFC 7426 architecture should look familiar. But it does use a little different terminology as well as some fundamental differences in the architecture as compared with how you may have thought about SDN before. Here’s a color version of the substance of the architecture as found in the RFC:


Figure 1: The RFC 7426 SDN Architectural Model

First, for the familiar, the architecture uses the usual Application plane above, control plane in the middle, with the device’s data plane at the bottom.

However, rather than a single concept of the data plane, this RFC separates the architecture into both a forwarding plane and an operational plane. The forwarding plane performs all message processing (forwarding, header changes, filtering, metering…), while the operational plane handles device details, for instance, the list of ports and their state.

Within the context of the architecture, the RFC walks through the terminology, and lists references… and that’s it!


RFC 7426 as a Roadmap (but not a Tutorial)

The RFC does not attempt to teach you everything about what the terms mean. However, it can act as a great roadmap for anyone learning SDN.

First, it hits the highlights of the architectural model, and clearly defines terms. That’s always a great place to start.

Additionally, it has tons of good references. Don’t know what else to go read? Want to really dig in? This isn’t a bad place to start. For instance, quoting another short section from the RFC, this time about those forwarding and operational planes inside an SDN device:

The forwarding and the operational planes are exposed via the Device and resource Abstraction Layer (DAL), which may be expressed by one or more abstraction models. Examples of forwarding-plane abstraction models are Forwarding and Control Element Separation (ForCES) [RFC5812], OpenFlow [OpenFlow], YANG model [RFC6020],and SNMP MIBs [RFC3418]. Examples of the operational-plane abstraction model include the ForCES model [RFC5812], the YANG model [RFC6020], and SNMP MIBs [RFC3418].

That one paragraphs give you a great list of documents and standards that RFC 7426 says fits into those parts of the architecture; all you have to do is go find them and read some more.


Cuppa Joe (w/ Refill) and Read the RFC

Care about SDN? Want to learn more? I think this RFC is worth a full read, at least up to where the list of 70+ references begins. That’s about 20 pages of RFC to read. Grab a cuppa joe, grab a seat, and enjoy! Let me know what terms you found particularly interesting or useful.

SDN Terminology from Layered Models
The Cisco Network Programmability (SDN) Intro Course
Wendell Odom
By Wendell Odom April 23, 2015 09:05
Write a comment

1 Comment

  1. January 19, 09:25

    It’s great that you are getting ideas from this piece of writing as
    well as from our dialogue made here.

    Reply to this comment
View comments

Write a comment

Your e-mail address will not be published.
Required fields are marked*


Subscribe to our mailing list and get interesting stuff and updates to your email inbox.