What is a Model Driven Network?
We have all heard about SDN lately, but what is it exactly? Well, this concept refers to software-defined networks and the fundamental concept to understand it is the intention to abstract the control layer from the forwarding layer… but what does this mean?
Technically, in traditional networks, the elements that made it up had to include all protocols and communication between them in order to have a complete view of the network. With this view, each element was responsible for applying the necessary calculations to solve, for example, routing from origin to destination. Now, in SDN networks, the goal is to delegate all control to a central element, which will be responsible for knowing the entire network and making all the necessary calculations before transmitting them to the network elements. Now, the responsibility of these elements is to transmit the data (forwarding layer), which is their main responsibility.
The complexity of achieving this goal arose after the IETF standardized the Netconf protocol in 2006 but without defining a model that represented the data, so each hardware vendor developed its own XML models, which were proprietary and incompatible with other vendors.
Around 2010, the IETF established YANG data modeling as the standard for the Netconf protocol, and technically this is when MDN was born.
The first controllers that tried to program the network ran into layers and layers of abstraction that had to be modeled according to protocol, vendor, etc. A common example is like if in a class the teacher spoke English and each student spoke a different language, one translator would be required for each student.To remedy this, YANG was defined, which is a common data modeling language, and in the previous example it is like the teacher continues to speak English, but all the students also speak it (as a second language), no matter that they still speak their own languages.
Usually, YANG models have 3 main publishers.
- Vendors (each vendor publishes its own models to configure and operate the devices)
- IETF (It defines certain standards such as interfaces or data types like ipv4)
- Open Config (an initiative launched by Google and other operators that boost critical feature models (eg. BGP, VLANs, OSFP, etc) and every vendor should support)
Organization of the models of a network element
With these data models and Netconf/Restconf protocols, the MDN is now feasible.When starting a Netconf session, for example, with a network device, the first thing that happens is a hello message where the device informs the controller of its capabilities (which is nothing more than informing which YANG models it has). Based on this information, the controller searches among its models which ones to use for communication (standard or proprietary).
Among the main advantages of having data models are:
- It is not necessary to parse console outputs, which are ambiguous since their objective is human reading and understanding.
- We can obtain accurate sensor data through the model being used to monitor, without the need to bring the complete data set (Telemetry).
- By using standard models to configure parameters or services, we avoid having to adapt each configuration according to certain vendor’s syntax.
- The models (standard or proprietary) usually do not have changes in what is already defined, but only tend to be added. This avoids complex automation maintenance due to a change in a console character.
- The structures of YANG models are compatible and similar to those used in any programming language.
Everything described above allows all kinds of new technologies and techniques like SR-TE, PCE, Telemetry, traffic on demand, slicing, etc.[/vc_column_text]