Original subtitles

In our next section we will talk about the northbound and southbound API is

another important terms that we need to know are northbound and the southbound API.

And what role do they play in network automation.

So let's have a look.

In software defined networking centralized controllers talked to the network devices about how they

should handle traffic.

This back and forth between the controller and the forwarding devices throughout or Xstrata.

Why.

And rather was z z in here you can see on the screen and these communication between controller and

those two ways says and from those devices towards the controller are true the southbound API is OK

and the network controllers also talk to the network applications.

There are network applications in here so you can see that and at the network controllers also talk

to the network applications and that define what kinds of services the network should be providing.

And this communication between the applications towards the controller and from controller towards the

application is true.

The northbound API is basically sort bonds API communicate information from the devices to the controller

about things like available link supported functionality and interface that's for a.

For instance if something goes wrong with a rather X it will alert the controller so that they adjustments

can be made in the other direction.

The controller pushes rules to the devices throughout or X Y Z telling them what to do based on information

from the applications on what services the network should provide and information from the devices about

the current state of the network this sort bound to API can be open or proper rarity.

Some examples are open flow.

Net com or the S&P.

So what about the not bound API is just like the device that communicates their status to the controller.

The Controller will use did not bound the API to present the state of network services to the relevant

applications.

If an entire service is unable to work for instance the controller will inform the relevant application

to process as appropriate not bound for API.

Our controller specific such as policy API is billing API or security or APIs so applications are written

for one specific controller in the other direction.

Applications will request network service changes from the controller using information from users on

what they need along with information the controller provides about current capabilities.

So what does it look like in practice guys.

Let's use as simplified example imagine that there is security application responsible for keeping certain

malicious traffic from entering the network.

This application has detected that a particular device with the IP address 1 1 1 1 you can seen here

should be prevented from accessing the network.

The security application will make a request of the controller on it's not bound interface as you can

see in here will ask to block IP address.

1 1 1 month from entering the network.

OK the controller will then use its understanding of the network state.

To translate this request into specific rules for relevant devices on the network and communicate that

with the devices using the southbound API.

So it might for example push out rules on the south while the API to device Z from here right.

And may I ask do I set to block any traffic on a specific part with source IP.

One man my man wants IP address.

1 1 1 1 has been blocked.

The Y Z reports this to controller which reports back to the application that the task has been completed.

If the state of this interface for to change that would also be communicated for the controller to take

appropriate steps to continue the block elsewhere or potentially to report the service issue.