Interfaces description approach

5.8.1 Overview

This clause describes the interface design approach in NFV-MANO architectural framework. The detailed description of the interfaces is the subject of clause 7.

While reference points are a good way to identify peer-to-peer relationships between functional blocks, descriptions of the interfaces provide a deeper understanding of how capabilities provided by "producer" functional blocks are exposed to "consumer" functional blocks. This approach allows to:

• Facilitate analysis of requirements against existing standardized interfaces, leading to identification of gaps and subsequent recommendations on how to address them.

• Lead to exposure of the appropriate level of abstraction via the interfaces, in such a way that it: - Provides guidance to bring consistency among existing and future interfaces to be standardized. - Provides the functional definitions, without limiting implementation choices of the functional blocks. - Emphasizes contract-based and producer-consumer interface paradigm to support the dynamic nature of

the interfaces among functional blocks, without limiting the design and implementation options. - Illustrates that the same function may be provided by a functional block to several other functional

blocks without restricting the communication paths between functional blocks, within the boundaries of the NFV architectural framework.

- Illustrates that different functional blocks can expose the same functionality in an abstracted manner to support different implementation options.

• Help define functional blocks' capabilities in such a way that orchestration of different entities is provided in multiple functional blocks, if appropriate; those functional blocks should offer abstracted services to other functional blocks.

• Emphasise the value of designing granular functions that can be performed via atomic transactions using the exposed interfaces.

• Recommend the use of configuration and authorization policies to play a role in implementing the path that an operational flow may take, when multiple alternatives are possible.

• Enable configuration and re-configuration of the levels of granularity, frequency and types of information being collected for fault, performance management and event data at runtime.

5.8.2 Producer-consumer paradigm

A functional block may play the role of a producer, or the role of a consumer or both. Interfaces represent a published contract offered by a producer functional block, exposing externally the functions produced. They can be consumed by any other consumer functional block that is authenticated and authorized to access and consume the functions offered; authentication mechanisms and authorization policies are defined to control access to and consumption of functions produced by a functional block, to the level of granularity desired by the owner of the producer functional block. A producer functional block may offer different functions, and may offer different levels of granularity within each function; authorization policies should reflect such granularity because different access and consumption rights may be granted to different consumer functional blocks.

A consumer functional block may also have a choice of sending requests to several producer functional blocks offering the same function; in some cases the function offered may be completely identical, in other cases one producer functional block may offer the function with optional extensions. Depending on implementation choices, configuration policies may be used to determine which producer functional block may be invoked by a consumer functional block to provide the desired function.

For notification interfaces, the general paradigm used is a publish/subscribe where the publishers issue notifications through the interface without knowledge of what if any subscribers there may be. Subscribers using the notification interface express interest in some notifications or groups of notifications and only receive those of interest. For a notification interface, the publisher plays the producer role and the subscriber the consumer role.

Between the choices dictated by configuration policies available at the consuming functional block, the implementation choices of manufacturers offering the functions and the choices dictated by authorization policies at the producing functional block, the ability to support some preferred operational flows, and disallow other operational flows in the service provider's environment becomes straightforward.

Functional Block X

(consumes A) Functional Block Y(consumes A&B)

Functional Block V (produces A&C) Functional Block Z (consumes A&C, produces A&B) i/f A i/f C i/f A i/f B 1a.1 1a.2 1b Authorization policy determines the access rights Configuration policy determines the request path Authorization policy determines the access rights

Figure 5.4: Interface concept in a Producer-Consumer paradigm

Figure 5.4 illustrates the notion of producer and consumer functional blocks, and the interfaces that the producer functional blocks expose, through which the consumer functional blocks consumes the functions provided. The following are noticeable:

• The same interface may be exposed by different producer functional blocks (e.g. interface A). It is also possible (not shown) that functional block Z may expose interface A with additional extensions or additional behaviours (e.g. which can be provided by producer functional block Z, but perhaps not by producer functional block V).

• A functional block can be at the same time a producer and a consumer of the same interface (e.g. functional block Z both produces and consumes interface A, or of different interfaces (e.g. functional block Z produces interface A and consumes interface C).

• The design supports multiple flow alternatives that can be directed by the use of policies. In the figure, consumer functional block X may be configured to request a certain function from either producer functional block Z (via flow 1a) or from producer functional block V (via flow 1b). Access to either of the functions is controlled by authorization policies associated with interface A on each of producer functional blocks Z and V. In operational flow 1.a, producer functional block Z processes the request and adds value (it could offer functional extensions or additional behaviour (e.g. implementing some global policies) via interface A, or it could provide additional services based on other information it has access to, e.g. policies, which may not be available to producer functional block V) before sub-contracting the function to producer functional block V for completion.

• Each producer functional block in NFV-MANO may maintain a set of policy enforcement rules. These rules may enumerate the list of other entities that are authorised to consume and perform specific operations over an interface; additionally, these policies may be defined on a per VNF basis. The actual development and implementation of policy rules are highly implementation specific and out of scope for the present document.