Software Networks. Guy Pujolle

Чтение книги онлайн.

      Figure 2.9. NFV machines

2.4. OPNFV

      OPNFC, or Open 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:

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:

      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, СКАЧАТЬ