Скачать книгу

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).

      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.

       – 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.

images

      Figure 2.10. The signaling protocol OpenFlow

      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.

images

      Figure 2.11. The control layer and its interfaces

images

      Figure 2.12. The load balancing protocol

      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).

       – 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.

      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

Скачать книгу