SDN is about making networking more flexible and agile through programming network elements.
Such programming needs to be done in a standard way.
Hence, standardizing the southbound protocol that directly commands a network element to forward traffic is important. So is the northbound protocol through which different applications tell an SDN controller the WHAT and HOW of what it wants to achieve from the network.
That is, not only the app has to tell its intent (the WHAT), but the way to achieve it (the HOW).
A simple example of HOW and WHAT in normal networking would be trying to send traffic from Point A to Point B between the routers of a certain vendor.
- WHAT: Here would be the intent of sending traffic from A to B.
- HOW: Here would be to configure certain parameters (for example, using certain commands on CLI of certain vendor X) on certain transport (MPLS, optical).
It is clear that in this case, both WHAT and HOW would be needed to configure the traffic successfully.
It is apparent, further, that the user has to understand the CLI of a particular vendor to configure such a scenario. And the user has understood a different set of CLI if the networking vendor or equipment is changed.
This is not a flexible enough environment.
SDN, though, allows for abstractions that are not available in normal networking environments.
The highest level of such abstractions are achieved when an app in SDN just specifies the intent, but not the way to achieve the desired outcome.
Networking based on intent has recently become the focus of the Northbound Working Group in Open Networking Foundation (ONF) and is generally referred to as Intent-based Networking (IBN). The working group has been formed to standardize models and interfaces based on IBN. (Other standard bodies are also working on standardizing IBN in one way or another.)
In IBN, the user or application has to specify the intent only. For example:
- I need a low latency path from A to B.
- I need a bandwidth of 40 MB from Time A to B, else 100 MB.
- If Jitter increases on the link, change the route to Path X and once it becomes normal bring it back to the original path.
The SDN controller, which is intelligent enough, then takes these commands and translates them into low level infrastructure commands and actions.
Therefore, this removes the pressure off the app to understand the underlying low level infrastructure details and opens up new flexibility for app developers.
The advantages of intent-based networking
Scalable
IBN is more scalable compared to non-intent based protocols. As the app developer does not need to be aware of the infrastructure environment, the flexibility to scale the app will increase tremendously. Also, introduction of new apps becomes quick when the app developer has to focus more on the applications rather than understanding how the applications work with the infrastructure.
Portable and vendor-agnostic
IBN is portable and vendor-agnostic. An app developed for one SDN environment can be easily ported to another SDN environment without the app developer having to be involved. This also means that an app developed for one SDN controller can be run on another vendor’s controller.
Coherent
IBN will bring coherence to and remove conflicts from multiple apps. In the past, there was always a problem when multiple applications pushed commands to an SDN controller. There was always a risk of conflict as it was not possible to decode the low level changes that multiple apps caused in the network, leaving the controller unable to understand the intent of the applications.
Conclusion
It is clear that without intent-based networking, SDN would not be flexible, scalable, or portable. Without it, there will always be complications to deal with. And, in its absence, there will be a need to run SDN in a more controlled environment so that multiple apps do not interfere and create conflict with one another.
Therefore, for SDN to succeed, IBN is a must, not an option.