Contributions to standards – ETSI NFV IFA028


THE ETSI NFV ISG, namely the IFA (Interface and Architecture) Working Group, has recently taken on a specification thread looking at support of management and orchestration functions across multiple administrative domains – i.e., 5GEx main scope. The IFA028 is the first item produced within this thread. This information capsule wraps up what 5GEx has contributed to the released version of IFA028 report.


The ETSI NFV ISG has been the first standardization body to tackle the specification effort for the NFV Management and Orchestration functional layers. Its work began back in 2012, with the publishing of the first NFV white paper [1], and moved forward until the current days, producing an impressive number of specification documents and reports. The ETSI MANO model has been widely recognized as a foundational reference in the scientific and industrial community for implementing NFV platforms providing VNF orchestration capabilities. After its initial design investigation phase, 5GEx decided to adopt the ETSI NFV MANO model (Figure 1) as baseline for its architecture, setting out the goal to support its evolution towards a multiple-domain landscape [2].


Figure 1- ETSI NFV MANO framework

After releasing the MANO specification at the end of 2014, in 2016 the ETSI NFV IFA WG started to work on possible architectural options to be considered for a MANO evolution. The Report on Architectural Options [3] envisioned an architectural enhancement where the NFV Orchestrator was split into a Network Service Orchestrator and a Resource Orchestrator, and an “Umbrella NFVO” component could in turn orchestrate services over different domains. This was on full par with the architectural design that 5GEx had meanwhile laid down for its Multi-domain Orchestrator (MdO) orchestrator. On the other hand, the inception of a multi-domain working thread inside the IFA WG confirmed the key importance of enabling creation of services getting through administrative boundaries.

The IFA028 report

In 2017, the IFA WG moved forward on the multi-domain service path, setting out a new informative report named IFA028, currently in draft publishing [4] and slated to be finally published on November 3rd, 2017. With his report, the multi-domain case becomes fully part of the NFV release 3 specification wave. IFA028 starts considering as initial multi-domain use cases two options: (i) NFVI as a Service (NFVIaaS), (ii) Network Services over multiple administrative domains. (i) treats the case when a service provider runs a VNF instance in the NFVI of another provider (Figure 2). (ii) describes the case of a service provider orchestrating and provisioning Network Services composed with other NSs ran by different providers (Figure 3).


Figure 2- Multi-domain NFVIaaS


Figure 3- Multi-domain Network Services

The report investigates the interactions occurring between functional blocks located in different administrative domains, basically corresponding to the functional flows on top of 5GEx I2-x interfaces. It looks for all the points where the current MANO architecture falls short of supporting the multi-domain cases, and tries to figure out what architectural enhancements can fill such gaps. Architectural options are taken in to account, e.g. considering direct vs indirect resource management, single vs multiple logical points of contact [4]). It also goes through the functional enhancements requested inside the individual blocks (NFVO, VNFM,..) to comply with the multi-domain requirements. Finally, it looks for the new reference points and interfaces to be added between the functional blocks, as well as the requested enhancements/extensions to the pre-existing interfaces. The impact on previous IFA specifications is also assessed.

The IFA028 report takes as instrumental both cross-domain connectivity management (treated in the IFA022) and security (allocated to IFA026), hence 5GEx could not provide its contributions on these specific aspects.

5GEx contribution

5GEx brought contributions to the IFA028 report concerning two specific aspects:
1. Multi-domain operation
2. Information exchange between domains

Multi-domain operation

5GEx proposed the inclusion of an additional clause (it will be 4.2 in the final IFA028 version) to offer some hint about the characteristics and requirements of the interconnection between different service providers, instrumental to enable the multi-domain functional flows depicted by the IFA028. This input is intended as fuel for future recommendations, since IFA028 doesn’t directly deal with the inter-connectivity topic (as said, it is part of IFA022). In clause 4.2, 5GEx describes:

  • The type of domain discovery mechanism: static, pre-configuration driven vs dynamic, automatic discovery of domains participating to a 5GEx-type ecosystem;
  • The session management problem in domain-to-domain interconnection (resilience aspect);
  • The need of exchanging information (in particular monitoring data) to enable the actual provision of multi-domain services, as well as the compliance to Service Level Agreements;
  • The need to enhance the functional blocks in case of automatic discovery of domains, to embed the due mechanisms and protocols to be enacted over the I2-x interfaces.

Furthermore, 5GEx proposed extensions to the sections 5.3 and 6.3, treating the needed enhancements to the MANO architecture in order to support multi-domain cases, respectively for the NFVIaaS and cross-domain NS use cases. Namely, 5GEx suggested add-ons to the changes requested at interfaces Or-Vi, Vi-Vnfm and Or-Or, for support of session maintenance and of auto-discovery mechanisms, especially in support of direct operation mode and of Single Logical Point of Contact configuration.
The VNFM functional block is also directly impacted by the aforementioned interface enhancements, and needs itself a functional update. The top-level NFVO must become the actual MANO Monitor, as described in the IFA021 specification in case of single domain services.

Information exchange between domains

The interoperation between domains requires a shared information model, specifying the set of information that different domains must put in common, for the multi-domain service ecosystem to properly work. 5GEx suggested to add a sub-section (8.3), and to extend the use case descriptions to cope with the information sharing requirements.

In section 5.1, 5GEx highlighted as, for the NFVIaaS use case, the “consumer” domain (i.e., the top-level one in the situational hierarchy) must get all the needed information to define the optimal resource allocation. In particular, 5GEx reminds that such information must include a certain level of topology view. Furthermore, there is the need to expose some capacity/capability information, as well as all the information needed for a proper service monitoring (fitting the enacted SLA).

In section 6.3, 5GEx highlighted some requirements of the newly introduced Or-Or reference point. In particular, these concern (i) the need to share the Network Service Descriptors of the nested NSs, (ii) the exposure of the lifecycle management interfaces to be accessed in nested NSs at the lower layers.

In section 8.2, 5GEx reminded the possible existence of issues when sensitive parameter measurements should be shared for monitoring and SLA enforcement purposes.

Finally, the new section 8.3 outlines a full list of information to be shared across domains, regardless the specificities of the particular use case taken into account. Particular emphasis was put on geo-localization information (where relevant to meet particular service constraints) and on minimal inter-connectivity information.


[1] ETSI NFV ISG: “Network Functions Virtualisation – An Introduction, Benefits, Enablers, Challenges & Call for Action”. Available at
[2] 5GEx Project deliverable D2.1: “5GEx Initial System Requirements and Architecture”. Available at
[3] ETSI NFV IFA. “Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options” Available at
[4] ETSI NFV IFA. “Network Functions Virtualisation (NFV) Release 3; Management and Orchestration Report on architecture options to support multiple administrative domains”. Available at