Cisco CCIE Security 350-701 – SDN Models – Architecture

1. SDN – Imperative Model

The next thing we’ll try to understand the Sdn approach or Sdn models the way you separate the control plane and the data plane. Now, for implementing these Sdn controllers, we have two models like Imperative Approach or Imperative Model or Declarative approach. Now, this is a common terminology you will hear especially when you talk to different Sdn providers and then different vendors you discuss with them while you are implementing the SDL networks.

So they say what approach they actually support. So there are some vendors approach provides Imperative approach and there are some vendors provides you something called decoratory approach. So both uses the controllers but the way slightly they differ. So we’ll try to understand the difference. What is the difference between the imperative model or the declarative model here.

So first we’ll try to understand the imperative model. Now the previously whatever the control plane data plane job, what I discussed, that is an example of your empirical model. So which means now the devices will be doing the data plane job, they do forward, whereas the complete job of a control plane is handled by the controller. So there is a separation of your data plane and the control plane. So all the functions of the control plane resides on the controller and your networking devices they just do forwarding. So there is a complete separation of your control plane and the data plan.

We call this approach as an Imperative approach. Like I said already, controller will decide the best routes and how to power the traffic, which interface to use. So the controller is going to program all the routing and routers and the features directly. And whereas the routers and the switches devices, they don’t have any brain or they are just like the devices, they just listen to the controller and forward where they cannot build any kind of information or they cannot learn any information. So all the functions resides on the control plane.

That’s what I said, including the routing tables, Mac table or learning any information which is required. Everything resides on the control plane. And networking devices, as I said, they don’t have any print means, just like the devices empty tables.

So they just have an empty tables and they simply forward the traffic or they just talk to the controller and then ask how exactly they should forward or what exactly they should do in order to forward this particular packet or particular data from this point to another point. Now, one of the issue, as I said, the controllers can directly program the database of the devices.

The same thing when I discussed. Now one of the issue or one of the problem we can say with this kind of approach is what if the controller is not reachable? Then again, probably if the controller is not reachable, then that is one more problem.

Of course we need to make sure that the controller should be always up and running. So you can configure something like controller cluster where you can have multiple controllers and then you can have multiple parts connecting to controller so that you have reach ability all the time. But again, if there is any kind of reachable issues to the controller, then that is going to impact the future packets because the future packets may not know exactly where to send because the controller is not reachable. So that is one kind of limitation. One of the example of this approach is like open Flow protocol. So open Flow protocol basically uses this model and Cisco doesn’t use this model, cisco uses the other one. That is the declarator approach. And one more point I would like to discuss here. There is something called called stateful SDM. Now, stateful SDM means like stateful represents something like mentoring the information about how the packets are being forwarded or which path are exactly used.

2. SDN – Declarative Model

Now next thing coming to the declarative model. Now when it comes to declarative model is a little bit different to the previous one. Now how it differs is in this model both the control plane and the data plane resides on the devices, which means every device works just like a normal device. Now Cisco uses this model because, because the Cisco has been developing the devices like routers switches, firewalls. Now these devices already have lots of things they can do.

They can do a lot of things, they can build the routing tables. So already there are inbuilt features in that and suddenly removing those features and then moving on to the control plane, the controller is not really an easy job. So now the Cisco model here says that okay, you still keep your control plane and based on this control plane you can still build the routing tables, you can still learn the macro service, you can still decide your own forwarding mechanisms. So we are not moving these things.

So every device have their own capabilities where they can decide how to forward, how to forward, where to forward, all the things just like a normal device is what we use. But again with SGN controller, now we have an SGN controller, but if the devices can learn the information and forward on their own, then what is the job of the controller here? Now the job of the controller here is now the controller is going to talk to the application. So basically the controller is going to talk to the applications and interact with the applications.

And according to the interaction, let’s say I’m running some VYP application, the controller is going to learn the requirement of that application. The controller says okay, there is a new VYP application is running, maybe there are this many users and this particular VYP traffic must get a minimum of this much of bandwidth, let’s say maybe 128 KPP is additional and I want this particular traffic should be sent over the path which are least congested. Now these are like the requirements.

Now the controller is going to learn the requirements from the applications or whatever the bandwidth required or which path you should use. Probably this is like an information it is going to learn and once the controller is going to learn the information, the application requirement, now the controller is going to talk to the devices, the controller is going to say talk to the device and say this is what I need. So it’s going to instruct the devices saying that okay, I don’t know what you’re going to do, but this is something what I want.

And now these devices is going to listen to those requirements and they’re going to change the behavior of the forwarding. Maybe they will install a new route. They say normally we use this route, but as per this requirement I had to use the second route. Or as per the requirement, maybe it can change the existing quality of service policy. So the devices, they have the preconfigured quality of service policy.

They say that OK, as per this requirement. Now the devices do on their own changes their own policies or changes the best route, something like temporary. Okay, so here the complete changes. Everything is done by the devices, but again, the controller is acting as an intermediate to learn the information or to learn the requirements of the applications and pass on to the devices. And those devices are going to change, change the things, change the behavior of the forwarding according to the requirements.

So that is something you can say, you can compare this more like you can take an example of an a traffic controller. So generally a traffic controller, like generally the eight traffic controllers are going to tell the pilots to generally they will instruct the pilots to take off, when to take off, when to land, and particular place where they should land.

Probably these are the things they will provide the information. Now it’s up to the job of the pilot to decide what is the speed it is going to adjust or what is the landing is. There are plenty of things they will do, they will manage on their own. So the traffic control is not exactly giving instructions how to do the traffic control is just giving the instructions to the pilot saying that this is what you have to do, this is what we want. And the pilot, obviously he should be intelligent.

Again, according to the given information, he is going to take an appropriate action according to that the same thing you can compare. So the controller, air traffic controller is like your Sdn controller sending an instructions or the requirements to the pilot, that is to the networking device. So same thing here.

The controller is going to declare, just a summary, the controller is going to declare the requirements because it is going to talk to the applications and it’s going to learn the requirements. And based on that requirements it is going to instruct or tell the networking devices this is what exactly we require. Now these networking devices are going to take an appropriate action or translated action we can say, to meet those particular requirements.

Now, this is how the Cisco Sdn works, because the Cisco Sdn works uses the declarative model, declarative approach of Sdn, where individual devices have the capability to learn the information and to take an action. So the controller is just giving or sharing the requirements in general. Okay, the same thing here. The controller declares how it wishes the network to function based on the application requirements.

Now the networking devices, as I said, they decide how to translate that particular requirement into actions. So they program their own into individual data planes. So this is the Cisco approach of SGN controllers and we call this as stateless SGN because the controller is actually not aware or not have any information of what is the actual path which is being used by this particular device.

• Category: Uncategorized