5GEx Functional Architecture

Highlights

• 5GEx proposes a first detailed functional architecture for the provision of NFV-based services in multiple-administrative domains
• The 5GEx architecture is an extension of the ETSI NFV framework for multi-domain
• A Multi-Domain Orchestrator (MdO) is proposed as key element for governing the orchestration of services and resources in the multi-domain environment

Introduction
The 5GEx reference framework is shown in Figure 1. At the bottom there are Resource Domains, exposing a resource abstraction to the domain orchestrators. In the middle, Domain Orchestrators perform Resource Orchestration and/or Service Orchestration exploiting the abstractions exposed by Resource Domains.
A Multi-provider Multi-domain Orchestrator (MdO) coordinates resource and/or service orchestration at multi-domain level, where multi-domain may refer to multi-technology (orchestrating resources and/or services using multiple Domain Orchestrators) or multi-operator (orchestrating resources and/or services using Domain Orchestrators belonging to multiple administrative domains). The MdO interacts with Domain Orchestrators via I3 interface APIs to orchestrate resources and services within the same administrative domains. The MdO interacts with other MdOs via I2 interface APIs (business-to-business, B2B) to request and orchestrate resources and services across administrative domains. Finally, the MdO exposes on interface I1 service specification APIs (Business-to-Customer, B2C) that allow business customers to specify their requirements for a service.
This framework also considers third party MdO service providers, which does not own resource domains but operate a multi-domain orchestrator level to trade resources and services from other providers (the ones actually owning such resources).

This framework also considers third party MdO service providers, which does not own resource domains but operate a multi-domain orchestrator level to trade resources and services from other providers (the ones actually owning such resources).

5GEx reference architectural framework

Figure 1: 5GEx reference architectural framework

This approach allows for a clear separation between the multi-domain elements and the local elements, while still ensuring the flexibility to handle both multi-technology and keeping local infrastructure details confidential. The multi-domain orchestrator is in charge of abstracting the underlying infrastructure before it announces what utility and functions the operator is capable of to its neighbouring operators. Using such an inter-working architecture for multi-domain orchestration will make possible use-cases that are nowadays hard to tackle due to the interactions of multiple heterogeneous actors and technologies.

5GEx Functional Architecture

5GEx extends the ETSI MANO NFV management and orchestration framework to implement Network Service and resource orchestration across multiple administrative domains, which may belong to different infrastructure operators or service providers, hereby referred as “providers”. For multi provider Network Service orchestration, a multi domain orchestrator (MdO) offers Network Services by exposing an OSS/BSS – NFVO interface to other multi domain orchestrators belonging to other providers. For multi provider resource orchestration, a multi domain orchestrator presents a VIM-like view and exposes an extended NFVO – VIM interface to other multi domain orchestrators.
The functional blocks of the multi domain orchestrator are shown in Figure 2. The MdO on the left consumes interfaces to other MdO-s. In addition, the right MdOs may also consume the same interfaces offered by the left MdO (symmetric interfaces, consumer – provider role is situational), but for this case the corresponding arrows are not depicted for simplicity.

Functional model of multi domain orchestration

Figure 2: Functional model of multi domain orchestration

 

The main components proposed by 5GEx are:

  • The Inter-Provider NFVO is the NFVO implements multi-provider service decomposition, responsible of performing the end-to-end network service orchestration.
  • The Topology Abstraction module performs topology abstraction elaborating the information stored in the Resource Repository and Topology Distribution modules
  • The Topology Distribution module exchanges topology information with its peer MdOs
  • The Resource Repository that keeps an abstracted view of the resources at the disposal of each one of the domains reachable by the MdO
  • The SLA Manager is responsible for reporting on the performance of its own partial service graph (its piece of the multi-domain service)
  • The Policy Database which contains policy information
  • The Resource Monitoring module dynamically instantiates monitoring probes on the resources of each technological domain involved in the implementation of a given service instance
  • The Service Catalogue in charge of exposing available services to customers and to other MdO from other providers
  • The MD-PCE (Multi-Domain Path Computation Element) devoted to make the necessary path computations and setting up the connection between domains

From the interfaces perspective, the functional split considered is related to service management (-S functionality), VNF lifecycle management (-F), catalogues (-C), resource topology (-RT), resource control (-RC) and monitoring (-Mon). Table I summarizes the functional needs for the interfaces in the scope if 5GEx as well as potential candidate solutions for their implementation. The identification and specification of these interfaces is currently being defined.

Functional split I1 I2 I3 Candidate solutions (under evaluation)

-S

Service management

TOSCA, Openstack Heat, SUPA, etc

-F

VNF lifecycle management

Openstack Tacker, OpenMANO APIs, etc

-C

Catalogues

TOSCA, Openstack Heat, etc

-RT

Resource topology

BGP-LS, NSI, ReST APIs, etc

-RC

Resource control

Openstack Neutron, NETCONF, PCEP, etc

-Mon

Monitoring

SNMP, ReST APIs, etc

Table I. Functional split of 5GEx interfaces and candidate solutions
The Inter-Provider NFVO implements service decomposition by mapping Network Service components on its current resource view. The resource view consists of the Inter-Provider topology, potentially augmented with detailed provider internal topologies and resource locations and capabilities. At first, the Inter-Provider NFVO selects providers that may need to be involved in delivering the Network Service. This decision is policy based considering the Inter-Provider topology and service catalogues advertised by other service providers on interface I2-RTadvertise (resource topology) and I2-Cadvertise (service catalogues). If needed, the multi provider NFVO may collect further details on charging, offered capabilities, Network Services, resources and topology from selected providers and may establish / update bilateral (or direct) business relationship to some of them as decided / necessary. Then, the Network Service components are mapped on the inter-provider, or optionally on more detailed topology, based on the information collected bilaterally from involved providers. Then, the multi provider NFVO sends the Network Service/resource requests to other providers using the I2-S/I2-RC interfaces.
The service catalogue contains information on the Network Services and VNFs provided by various other domains. Furthermore, due to potentially different charging and/or different implementation templates and/or different flavours, the same VNF may be included multiple times as per flavour at virtual host at virtual provider. Scalability of the service catalogue and methods that allow querying remote domains for service capabilities and attributes on demand may be required.
The multi provider NFVO also implements policy enforcement points on behalf of its administrative domain to profile incoming requests received from other providers. Policy enforcement is needed to allow authorised providers to implement resource orchestration (I2-RC) and/or lifecycle management (I2-F) in their own domain. Administrative domain wide policy enforcement is needed to enforce aggregate resource limits.
Functionality of SLA management is defined as collecting and aggregating quality measurement reports from probes provided by the (virtual) infrastructure or initiated by the Inter-Provider NFVO as part of the service setup. Depending on the already deployed provider internal management and orchestration structure, measurement results may already represent aggregated views. In a multi provider setup, parts of the SLA management are delegated to the remote domain as the Inter-Provider NFVO defines requirements with the Network Service/resource request. In addition, the SLA manager correlates faults (alarms) and performance degradation events and may report SLA violations to remote multi provider orchestrators or directly to customers if it was requested as part of the service request.

Next steps

The 5GEx functional architecture is being implemented on Prototype 1 of 5GEx. This prototype will be deployed on top of 5GEx Sandbox for experimentation. As result, refinements of 5GEx functional architecture could be expected.

Related material

A survey on existing multi-domain management and orchestration frameworks can be found at [ETT]. A complete description of 5GEx architecture can be found in 5GEx deliverable 2.1 [D2.1].

References

[ETT] R. Guerzoni et al., “Analysis of end-to-end multi-domain management and orchestration frameworks for software defined infrastructures: an architectural survey”, to be published in Transactions on Emerging Telecommunications Technologies (available at http://onlinelibrary.wiley.com/doi/10.1002/ett.3103/epdf)
[D21] 5GEx Deliverable 2.1, “5GEx Initial System Requirements and Architecture”, 2016.