Software Networks. Guy Pujolle
Читать онлайн книгу.
NFV, is a new movement that is a collaborative project from the Linux Foundation. The objective is to create a platform to speed up the rise of NFV. Another objective of OPNFV is to increase the agility of services by facilitating better usage of the underlying functions. Telecom operators are particularly interested by this initiative; they hope to obtain a referential open source platform to validate the interoperability of NFVs in a multi-provider context. OPNFV is also an excellent opportunity for the creation of an open platform that could be used by all participants. OPNFV also encourages cooperation between manufacturers, with the aim of driving NFV forward and ensuring consistency, performance and interoperability between virtualized network infrastructures. The OPNFV project is in close cooperation with the NFV program at ETSI to ensure a coherent implementation of the NFV standard. The first thing that is expected of OPNFV is to provide an NFV Infrastructure (NFVI), Virtualized Infrastructure Management (VIM) and APIs to other NFV elements. This collection forms the basic software necessary for Management and Network Orchestration (MANO). The standards are being drawn up in collaboration with the main open source projects. OPNFV is working with a large number of these projects to coordinate the integration of NFV. We will go through a more detailed study of this platform in the chapter on open source software (Chapter 4).
2.5. Southbound interface
The southbound interface is situated between the controller and the devices on the virtualization plane. This signaling protocol passes the configuration commands in one direction and manages the statistical information feedback in the other. There are many open source proposals for some under development. An initial list of protocols for this southbound interface is:
– OpenFlow from the ONF;
– I2RS (Interface to Routing Systems) from the IETF;
– Open vSwitch Data Base (OvSDB);
– NetConf;
– SNMP;
– LISP;
– BGP.
We will detail the most significant protocols in Chapter 4. However, to introduce this southbound interface, let us look at the most iconic protocol: OpenFlow. This signaling is shown in Figure 2.10. It takes place between the controller and the network devices. The data transported obey the trilogy “match-action-statistics” – in other words, we need to:
– determine the streams uniquely by matching a certain number of elements such as addresses or port numbers;
– specify the actions transmitted from the controller to the networking devices, such as updating a forwarding table or switch table, or, more generally, a forwarding device;
– transfer tables containing statistics on the degree of use of the ports, transmission lines and nodes, such as the number of bytes sent through a given port.
This solution has been standardized by the ONF (Open Network Foundation), and we will describe it in greater detail in Chapter 4.
Figure 2.10. The signaling protocol OpenFlow
2.6. The controller
The controller, as its name indicates, is designed to control the data plane and receives from the application layer the necessary elements to determine the type of control that needs to be exerted. This position is shown in Figure 2.11. Thus, the controller must receive policy rules to be respected. On the basis of the description of the applications to be taken into account, it deduces the actions needed on the networking equipment. The actions can be carried out on routers, switches, firewalls, load balancers, virtual VPNs and on any other hardware that is necessary to the good functioning of the network.
A very great many open source controllers have been developed. OpenDaylight represents a good example; this open source software was developed by the Linux foundation. A good 40 companies devoted experienced developers to the project. The controller as such has numerous decision-making modules and various northbound and southbound interfaces. We will describe the latest release of OpenDaylight hereinafter.
Figure 2.11. The control layer and its interfaces
The controller contains modules that handle different functions necessary for the proper operation of the network. Of these functions, one of the most important is that of a “load balancer”. In fact, this term denotes algorithms that determine the best paths to follow on the data plane. This module must decide, on the basis of the statistics received, which nodes in the network infrastructure the packets should be sent through. This decision should optimize the user demands or, more specifically, the user applications. Load balancing is essentially valid during peak hours. During other times, the load balancer must determine the most appropriate paths, on the basis of the users’ requirements. Load balancing becomes load unbalancing: unlike at peak times, we need to channel as many streams as possible through common paths so as to be able to shut down the maximum possible number of intermediary nodes. This function is represented diagrammatically in Figure 2.12.
Figure 2.12. The load balancing protocol
2.7. Northbound interface
The northbound interface between the application plane and controller passes information pertaining to the applications’ needs so that the controller can open up the best possible software network with the appropriate qualities of service, adequate security and the essential management for the operations to be able to be carried with no problems. The basic protocol for these transmissions is based on the REST (Representative State Transfer) API. This application interface must enable us to send the information necessary for the configuration, the operations and the measurement report. We find this protocol, based on RESTful, integrated into numerous Cloud management systems, and in particular, in the interfaces of most of these systems, such as:
– OpenStack, in which the REST API is integrated;
– those of the service providers;
– the API Virtual Private Cloud (VPC).
The representations facilitated by the REST protocol enable us to pass the information over the northbound interface with the following properties:
– each resource is identified individually;
– the resources can be manipulated by representations;
– the messages are self-descriptive: they explain their nature by themselves;
– each access to the subsequent states of the application is described in the present message.
2.8. Application layer
The application layer is essentially formed of Clouds that contain the application virtual machines. These may be business machines or network element management machines – responsible, for instance, for the managing of handovers or determination of the best access, at any given time, for a multi-technology terminal. Thus, this layer essentially contains the operating systems for the Cloud. The best-known such system is, undoubtedly, OpenStack. It is a Cloud management system that controls large sets of resource offering processing power, storage and network resources. OpenStack has already