Multi-domain service specification and catalogue management

Introduction and highlights

Multi-domain service specification and catalogue are important points addressed by 5GEx. In this information capsule we summarise our conclusions regarding what is needed to fully support multi-provider, multi-domain orchestration. While it is done having in mind the 5GEx architecture and interfaces, results can also be helpful for other related efforts.

In order to keep this capsule short we just focus on the I2 interface between Multi-provider Multi-domain Orchestrators (MdOs), which is a business-to-business (B2B) to request and orchestrate resources and services across administrative domains. Specifically, we focus on the I2-C interface, which is defined as the interface between two different MdOs through which all the information related to their catalogues (containing Network Services and Network Functions [VNFs]) is exchanged, connecting the local Catalogue Management module to its homonym in the neighbour domain.

I2-C functional description

In the architecture diagram, this interface is split in two: I2-Cadvertised and I2-Cbilateral. The first one is the one used for the catalogue exchange and the second one, for a bilateral negotiation processes.

interfaces_multi-domain_catalogue_subsystem Figure 1. Interfaces of 5GEx Multi-domain catalogue subsystem – I1C/I2C

It is assumed that the domains that use this interface are pre-connected, and there is an agreement between them for the sharing of the elements referred inside the catalogues.

Type of data that is sent using this interface:

  • Catalogue import requests
  • Description of the shared catalogue items
Functional gaps not covered by existing protocols

In 5GEx we have analysed existing related approaches (more details can be found in D2.1 and D2.2): MEF SONATA (BUS:BUS) [1], TMF product catalogue management [2][3], ETSI NFV reference architectural framework [4], work done in the FP7 T-NOVA project [5]. We next summarise the gaps we have identified on those approaches from the point of view of 5GEx system needs.

TM Forum handles the catalogues across domains (BUS-BUS) the same way it handles them between the provider and the customer (CUS-BUS), therefore it lacks information that is useful for the exchange of external catalogue elements. T-NOVA does not either implement I2, so T-NOVA information model is suitable to be used here but with multi-domain additions. Next, we identify the requirements needed to support multi-domain capabilities, so they are current gaps in the existing solutions.

Gaps due to the support of different coordination models

It is important for I2-C to be able to support multiple coordination models, so as for the architecture to be able to support multiple business models on top of the same interfaces and API specifications. From the 5GEx coordination models we have the following requirements for I2-C:

• Distributed pull
o A Provider should be able to push service capabilities to other Providers.
o A Provider should be able to retrieve service/SLA offers from the service catalogues of           other Providers.

• Distributed push
o A Provider should be able to push service/SLA request to other Providers.

• Centralised pull
o A Provider should be able to push service capabilities to an Aggregator.
o An Aggregator should be able to retrieve service/SLA offers from the service                                  catalogues of other Providers.

• Centralised push
o  A Provider should be able to push service/SLA request to other Providers.

Therefore, in order for I2-C to be functional, we need to be able to support both Capability and Service request objects. Capabilities are expected to be of higher granularity than Service requests (also in line with the ALTO [6] approach where some aggregate metrics are provided). Service requests on the other hand are more specific and can have some tolerance in the respective value fields (e.g. price, delay, time to spawn a VNF can have some lower/upper bound). Allowing for such bounds will minimize the message overhead on top of I2-C. But there is more that needs to be done for an efficient and generic I2-C operation, as explained next.


In order to further increase the efficiency of the catalogue (capability and service request) announcements, we need also to consider the following:

  • I2-C should/could support the bundling of service/SLA offers.
  • I2-C should/could support the bundling of service capabilities.

This bundling is two-fold: Firstly, to aggregate information on how much compute, storage, net resources are available in a region, rather than reporting per each location which is both cumbersome and a confidentiality issue for the providers. For instance, in a bilateral cascading set up an NSP capabilities may be bundled by the upstream NSP in order to provide an announcement of what is the QoS metric/capability to traverse both domains from its set of ingress points. Secondly, due to business reason in order to create attractive offerings (by means of enhancing its announced capabilities) for specific verticals: for example one NSP may create point-to-region ASQ offerings bundled with VNFs (e.g. firewall, vCache) so as to attract demand from content providers e.g. for premium content delivery. The bundled offering reduces the exposure risk of the buyer (he is certain he can get all the needed resources from one-stop shop) but may damage the business of infrastructure providers if their individual offerings are not propagated to the 5GEx community.

Publication policies

I2-C should also support and enforce publication policies for the catalogue entries: This means that such policy objects for the management of catalogue information could be exchanged on top of I2-C and also architecture functional blocks should allow for the i) creation of policies; ii) update/altering of policies by the owner of catalogue entries; and iii) delete of these objects either by their owners of the respective catalogue entries or when they are obsolete (e.g. a service capability expires).

The aforementioned issues are similar to those in multicast, RSVP or BGP for aggregating, pruning and managing information but here we have an additional level of complexity due to the multi-provider setting.

Negotiation (I2-Cbilateral)

It is possible to envision a (bilateral) negotiation process of certain service/SLA offer entries such as price, QoS level, availability level etc. Therefore, in addition to the publication policies, we also need similar policies for the negotiable entries that should be defined during the service catalogue template specification process. This could be part of the service template, which is currently lacking hence a potential gap here that 5GEx could fill-in.

Finally, due to the fact that we want to support negotiation objects (new quotation, offer, counter-offer, etc.) we will need to define an ontology of object types identified by a separate id for all the various I2-C objects that will be propagated on top of I2-C (hence, each catalogue “entry” is also complemented with an “object type id” indicating if it is a SLA request, a counter offer for an SLA request and so on).

Next steps

5GEx is refining its functional architecture and providing a specification of I2, which is being partially implemented in the Integrated Prototype.


[1] MEF 55, Lifecycle Service Orchestration (LSO); Reference Architecture and Framework, March 2016.

[2] TMF620, Product Catalog Management API REST Specification, R14.5.1

[3] TMF637, Product Inventory Management API REST Specification, R14.5.1.

[4] ETSI – GS NFV-IFA 014, Network Functions Virtualisation (NFV); Management and Orchestration; Network Service Templates Specification, v2.1.1, October 2016.

[5] T-NOVA, D6.1 – Service Description Framework, December 2015.

[6] RFC 7285, Application-Layer Traffic Optimization (ALTO) Protocol.