1
00:00:01,050 --> 00:00:06,510
In our next section we will talk about the northbound and southbound API is

2
00:00:09,370 --> 00:00:16,360
another important terms that we need to know are northbound and the southbound API.

3
00:00:16,390 --> 00:00:20,830
And what role do they play in network automation.

4
00:00:20,830 --> 00:00:22,770
So let's have a look.

5
00:00:23,050 --> 00:00:30,850
In software defined networking centralized controllers talked to the network devices about how they

6
00:00:30,850 --> 00:00:33,030
should handle traffic.

7
00:00:33,070 --> 00:00:39,580
This back and forth between the controller and the forwarding devices throughout or Xstrata.

8
00:00:39,660 --> 00:00:40,140
Why.

9
00:00:40,150 --> 00:00:49,060
And rather was z z in here you can see on the screen and these communication between controller and

10
00:00:49,180 --> 00:01:01,850
those two ways says and from those devices towards the controller are true the southbound API is OK

11
00:01:02,450 --> 00:01:07,220
and the network controllers also talk to the network applications.

12
00:01:07,220 --> 00:01:15,830
There are network applications in here so you can see that and at the network controllers also talk

13
00:01:15,830 --> 00:01:23,960
to the network applications and that define what kinds of services the network should be providing.

14
00:01:24,080 --> 00:01:31,850
And this communication between the applications towards the controller and from controller towards the

15
00:01:31,940 --> 00:01:34,150
application is true.

16
00:01:34,160 --> 00:01:43,190
The northbound API is basically sort bonds API communicate information from the devices to the controller

17
00:01:43,220 --> 00:01:51,640
about things like available link supported functionality and interface that's for a.

18
00:01:51,640 --> 00:02:00,850
For instance if something goes wrong with a rather X it will alert the controller so that they adjustments

19
00:02:00,910 --> 00:02:04,170
can be made in the other direction.

20
00:02:04,180 --> 00:02:12,430
The controller pushes rules to the devices throughout or X Y Z telling them what to do based on information

21
00:02:12,430 --> 00:02:20,500
from the applications on what services the network should provide and information from the devices about

22
00:02:20,500 --> 00:02:29,590
the current state of the network this sort bound to API can be open or proper rarity.

23
00:02:29,600 --> 00:02:32,260
Some examples are open flow.

24
00:02:32,450 --> 00:02:35,900
Net com or the S&P.

25
00:02:35,900 --> 00:02:44,850
So what about the not bound API is just like the device that communicates their status to the controller.

26
00:02:44,930 --> 00:02:52,310
The Controller will use did not bound the API to present the state of network services to the relevant

27
00:02:52,400 --> 00:02:53,900
applications.

28
00:02:53,990 --> 00:03:01,760
If an entire service is unable to work for instance the controller will inform the relevant application

29
00:03:01,760 --> 00:03:06,580
to process as appropriate not bound for API.

30
00:03:06,600 --> 00:03:17,510
Our controller specific such as policy API is billing API or security or APIs so applications are written

31
00:03:17,510 --> 00:03:23,110
for one specific controller in the other direction.

32
00:03:23,240 --> 00:03:32,240
Applications will request network service changes from the controller using information from users on

33
00:03:32,240 --> 00:03:38,720
what they need along with information the controller provides about current capabilities.

34
00:03:38,720 --> 00:03:42,500
So what does it look like in practice guys.

35
00:03:42,620 --> 00:03:51,470
Let's use as simplified example imagine that there is security application responsible for keeping certain

36
00:03:51,470 --> 00:03:55,820
malicious traffic from entering the network.

37
00:03:55,820 --> 00:04:05,390
This application has detected that a particular device with the IP address 1 1 1 1 you can seen here

38
00:04:06,110 --> 00:04:09,740
should be prevented from accessing the network.

39
00:04:09,740 --> 00:04:19,460
The security application will make a request of the controller on it's not bound interface as you can

40
00:04:19,460 --> 00:04:24,440
see in here will ask to block IP address.

41
00:04:24,480 --> 00:04:27,770
1 1 1 month from entering the network.

42
00:04:27,840 --> 00:04:33,710
OK the controller will then use its understanding of the network state.

43
00:04:33,710 --> 00:04:42,140
To translate this request into specific rules for relevant devices on the network and communicate that

44
00:04:42,140 --> 00:04:45,920
with the devices using the southbound API.

45
00:04:46,670 --> 00:04:56,080
So it might for example push out rules on the south while the API to device Z from here right.

46
00:04:56,240 --> 00:05:03,020
And may I ask do I set to block any traffic on a specific part with source IP.

47
00:05:03,020 --> 00:05:06,780
One man my man wants IP address.

48
00:05:06,790 --> 00:05:09,340
1 1 1 1 has been blocked.

49
00:05:09,400 --> 00:05:18,970
The Y Z reports this to controller which reports back to the application that the task has been completed.

50
00:05:19,970 --> 00:05:27,560
If the state of this interface for to change that would also be communicated for the controller to take

51
00:05:27,680 --> 00:05:35,490
appropriate steps to continue the block elsewhere or potentially to report the service issue.