SDN Terminology from Layered Models

Wendell Odom
By Wendell Odom May 13, 2015 09:05

Even though we don’t build networks with OSI products, we still use terms from the OSI model. What terms will we end up using for SDN, once the dust settles?

The previous post introduced one document that attempts to define terms and architecture, and today’s post introduces another: the ITU-T Y.3300 document. But how do these documents fit in with our fast-changing networking landscape – and what words should we use? Today’s post looks at the Y.3300 doc, and explores a few of the terms.

Other posts in this series:


Big Picture First: ITU-T Y-Series

Most of us don’t have a reason to read docs from standards bodies unless we’re looking for a particular standard or fact. But as long as we’re talking about one doc from the ITU-T Y-series, it’s worth a minute to set the context of what these documents are.

First off, the topic area for the Y-series is broad, but it’s all networking! The title for the ITU-T’s Y-series of documents spells out the big items:

Global information infrastructure, Internet protocol aspects and next-generation networks

Great, so the topic is global network, IP, including next-generation networks. It’s networking! But what kind of docs? Doesn’t the IETF define IP in RFCs, by the way? What do we need these ITU-T Y-series docs for, if the standards sit somewhere else?

Well, these Y-series docs aren’t standards. Rather they are meant as a practical help for those working in a particular area, as stated clearly in the introductory doc for the entire series (Y.100):

“It is intended to be a practical, educational and insightful guide for leaders and participants in GII-related standardization.”

(Aside: GII = Global Information Infrastructure, from the Y-series title.)

OK, leaders and participants in networking, the ITU-T gives you lots of documents in the Y-series to help. If you’ve got a few minutes, it’s interesting just to look around and see what’s defined here. And you guessed it – they’ve got a couple of SDN docs. Just go to the page for the ITU-T Y-series, and search for “software” rather than SDN.


The ITU-T Y.3300 and an SDN Architectural Model

This particular ITU-T doc takes a short 8 pages (ignoring the appendix) to define software-defined networking and an associated architectural model. So grab a cup of coffee and take a read. It’s a bit theoretical, but worth a few minutes.

The architectural model shown in Y.3300 is the most interesting material in the document. In fact, the document claims to define one term (software-defined networking), and does so by using an architectural model as the backdrop. The model from Y.3300 looks like this:

Figure 1: ITU-T Y.3300 SDN Model


The model has three layers, but in some ways looks like 6 layers with one extra sideways management layer. A 7-layer model you say? Well, not really. It keeps the traditional SDN 3-layer concept of app, controller, and element, top to bottom.

For a little more detail, examine the terms with “Layer” in them on the right of the model, which defines the three (literal) layers: Application, Control, and Resource. Then, looking inside each layer, some layers have multiple components or functions. These functions are not labeled as “layers” – so for you networking model purists, it truly is a 3-layer model. But those inner functions tell us more about what the layers do.

(Aside: for those of you also new-ish to networking, rather than simply new to SDN… note that the OSI and TCP/IP models show a model of layers that could be implemented on one host or device. The model shown here, and in RFC 7426, is a system architecture model, in which layers are implemented on some devices, some on others – so we’re not headed towards an apples-oranges comparison even. More like apples and 3-course meal comparison.)

Next, notice the functions inside the middle and bottom layers, but at the top of each. Both end with the word “Support”. These functions support the layer above (conceptually), and fill the role of whatever that layer’s APIs support. For example:

Control layer “Application Support”: For applications that run on a separate host, the controller will support some APIs, often RESTful APIs. Per this architectural model, the controller’s APIs sit in the control layer’s application support function.

Resource layer “Control Support”: For example, for a network element’s function of implementing OpenFlow, the part of the device that provides an API and interface to the controller is part of the control support function of the resource layer per the architecture.

Finally, the model also defines a management function that spans all layers. Not to be too picky about wording, but it’s called a function (not layer), but has the word “multi-layer” in the name. From a practical perspective, it’s a catch-all for anything unrelated to the packet forwarding part of the story.


Some brief Opinions of Terms

I was tempted to do a bit of tongue-in-cheek prediction that RFC 7426 vs. Y.3300 will become the next networking generation’s TCP/IP vs. OSI model. I seriously doubt that will be the case. But both are intended to be useful references to those out there doing SDN – so take advantage to whatever extent that it’s useful to you, and ignore these documents otherwise.

Personally, I wonder which of these documents might end up having a noticeable effect on the industry? And if only one of these docs, which one? They differ enough with each other in architecture and in the use of small but important terms that (in my opinion) we would be better with one or the other, and not both. (Here’s a repeat of the RFC 7426 architecture, from an earlier blog post.)

Figure 2: RFC 7426 SDN Model


For instance, what term do you use for a networking device that forwards messages in an SDN network?

RFC 7426: “device” or “resource”

Y.3300: “resource”, or “element” (to a small extent)

OpenFlow: “switch”

Purely from a learning perspective, I dislike the use of the word “switch” for the forwarding function in SDN. But that’s purely as someone who teaches people – the old ideas about switches tend to get in the way of learning what an SDN switch is and does. But do we replace the use of the word “switch” with the strongest overlapping term between RFC 7426 and Y.3300 (“resource”)? Or “device”?

What do you think?

I hope to do one more in this series – stay tuned!

NFV Terminology and Architecture from ETSI
SDN Terminology from RFCs?
Wendell Odom
By Wendell Odom May 13, 2015 09:05
Write a comment

No Comments

No Comments Yet!

Let me tell You a sad story ! There are no comments yet, but You can be first one to comment this article.

Write a 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.