Evolving 5G network scenarios will have to deal with new multiple administrative domain (aka multi-domain) orchestration models. Based on a new broker-plane approach on top of per-domain management and orchestration functions, we present a Multi-domain orchestration prototype capable to coordinate the delivery of a multi-operator End-to-End Network Service (E2ENS) that combines per-domain paths and network functions for a given service request. Our prototype implementation retrieves local information about topology and resources from each Multi-domain Orchestrator (MdO) to offer after inter-domain added value services in the form of abstract Map Services. These map abstractions are easily consumable through developer-friendly REST APIs based on the Application-Layer Traffic Optimization (ALTO) standard protocol.

1. V Workshop pre-IETF - CSBC 2018
July 26, 2018
Natal
Danny Alex Lachos Perez
Christian Esteve Rothenberg
(University of Campinas, Brazil)
Multi-domain Orchestration
leveraging the
Application-Layer Traffic
Optimization Protocol

2. Agenda
1. Multi-domain Orchestration (MdO)
2. Broker-assisted Multi-domain Orchestration Approach
3. Required ALTO Extension
4. PoC Implementation
5. Benefits / Open Issues
6. Future Work
2

3. Multi-domain Orchestration
(MdO)
3

4. Motivation
4
❖ The new 5G network architectures imply collaboration between different
network operators in order to enable flexible services spanning over
multiple domains.
❖ Collaboration between different network operators envision the potential
introduction of new business model approaches:
➢ E.g., the introduction of 3rd parties (brokers) to provide or to assist coordinate E2E network
services spanning over multi-operator multi-domain networks.
❖ Multi-provider orchestration operations will require the information
exchange across Multi-domain Orchestrators (MdOs).
❖ Key Information to be exchanged:
➢ Abstract network topology
➢ Resource availability (e.g., CPUs, Memory, and Storage)
➢ IT Capabilities (e.g., supported network functions)
➢ Orchestrator entry points

5. Challenges
5
Lack of
abstractions
Adequately represent in confidentiality-preserving fashion the resource and topology information
from different administrative domains.
Discovery of
candidate domains
Refers to the discovery mechanism to pre-select a (sorted) list of candidate, accounting for
resources and capabilities, necessary for an E2E network service deployment.
Scalability Involves the distribution of topology and resource information in a peer-to-peer fashion
(MdO-to-MdO). Multi-operator multi-domain environments where the information distribution is
advertised in a peer-to-peer model scales linearly.
Flexibility Considers that a distributed approach does not allow domains without physical infrastructure to
advertise resource capabilities and networking resources. Such procedures consist in deploying
and configuring physical peering points for these domains.

6. ALTO for Multi-domain Orchestration
6
❖ The ALTO protocol [RFC7285] provides abstract network information in the
form of map services that can be consumed by applications in order to become
network-aware and to take optimized decisions regarding traffic flows.
❖ WHY ALTO?
➢ The WG is discussing the use of ALTO as an information model for representing network,
resource, and services in multi-domain scenarios.
■ The Broker-assisted architecture for multi-domain orchestration in 5G networks [draft-alto-brokermdo-01]
■ The Unicorn architecture for multi-domain, geo-distributed data analytics
[draft-alto-multidomain-analytics-01]
❖ Some advantages:
➢ Use the ALTO Property Map service to get a clear global view (resource and service information)
of other potential candidates domains.
➢ Use the ALTO Cost Map service (and extensions) to compute inter-domain service function
paths.

7. ALTO-based Broker-assisted
Multi-domain Orchestration
7

8. Proposed Approach
❖ Proposal:
➢ A federation networking paradigm where a broker-plane works on top of the management
and orchestration plane.
❖ Main Goal:
➢ Discover resource, service and topology information from different domains involved in the
federation.
❖ ALTO-based:
➢ The ALTO services (with the proposed protocol extensions) offer abstract maps with a
simplified view, yet enough information about MdOs involved in the federation.
8
ALTO-based Broker-assisted Multi-domain Orchestration: https://tools.ietf.org/html/draft-lachosrothenberg-alto-brokermdo-01

9. Architecture
❖ Inter-domain Resource (IdR)
➢ Resource availability
➢ VNFs/PNFs
➢ SAPs
❖ Inter-domain Topology (IdT)
➢ Hierarchical TED
❖ ALTO Server
➢ Property Map
➢ Cost Map
9
ALTO-based Broker-assisted Multi-domain Orchestration: https://tools.ietf.org/html/draft-lachosrothenberg-alto-brokermdo-01

10. ALTO Extension
10

11. Filtered Cost Map Extension
❖ The ALTO server MUST provide connectivity
information for every SG link in the SG path for an E2E
requirement.
➢ This information is the AS-level topological distance in the form
of path vector, and it includes all possible ways for each (source
node, destination node) pair in the SG link.
❖ Specifications (based on Section 6.1 of [DRAFT-PV]):
➢ The specifications for the "Media Types", "HTTP method",
"Capabilities" and "Uses" are unchanged.
➢ "Accept Input Parameters" Specification: If “sg” is present, the
ALTO Server MUST allow the request input to include an SG with
a formatted body as an NFFG object. 11

12. Example: Filtered Cost Map (1/2)
❖ The ALTO client requests the path vector for a
given E2E requirement:
➢ SAP1->NF1->NF2->NF3->SAP2
❖ SG Request:
➢ Three NFs (NF1, NF2, and NF3) .
➢ Two SAPs (SAP1 and SAP2).
➢ Four Links connecting the NFs and SAPs ("sg_links" tag).
➢ An E2E requirement ("reqs" tag) with information about the
order in which NFs are traversed from SAP1 to SAP2.
12

13. Example: Filtered Cost Map (2/2)
❖ The ALTO server returns connectivity
information for the E2E requirement.
❖ The response includes Property Map
information for each element in the path vector.
➢ In this case, it is retrieved a Property Map with the
"entry-point" property, i.e., the URL of the MdO entry point
for the corresponding network.
13

14. Strawman Use Case
Implementation
14

15. 5GEx Scenario
15
5GEx Functional Architecture: https://www.5gex.eu/wp/?page_id=510

16. 5GEx Scenario
16
Server Front-End
ALTO OpenDaylight
Server Back-End
Neo4j Graph Database
ESCAPE
Extensible Service ChAin Prototyping Environment
Netphony-topology

17. Functional Evaluation
❖ Filtered Property Map Service
➢ The ALTO client wants to retrieve
the Property Map for PID entities
with the “unifyslor” (or MdO
entry-point), “cpu”, “mem”,
“storage”, “port” and “nf” properties.
➢ The PIDs entities are MdO SP1
(0.0.0.1), MdO TP3 (0.0.0.123), MdO
SP2 (0.0.0.2) and MdO SP3
(0.0.0.3).

18. Functional Evaluation
❖ Filtered Cost Map Service (Request)
➢ The SG request information is composed of
three NFs:
■ (NF1)“COMPRESSOR”
■ (NF2) “FORWARDER”
■ (NF3) “DECOMPRESSOR”
➢ Two SAPs (SAP1 and SAP3)
➢ Links connecting the NFs and SAPs (“sg
links” tag)
➢ An E2E requirement (“reqs” tag) with
information about the order in which NFs
are traversed from SAP1 to SAP3.
➢ A constraint (“constraints” : [ “= 9”])

19. Functional Evaluation
❖ Filtered Cost Map Service (Response)
➢ For each SG link in the E2E requirement:
■ SAP1->COMPRESOR,
■ COMPRESOR->FORWARDER,
■ FORWARDER->DECOMPRESOR,
■ DECOMPRESOR->SAP3
➢ The ALTO server returns sub-arrays
indicating potential candidate paths
calculated as the AS-level topological
distance corresponding to the amount of
traversing domains.
➢ This AS-level distance is limited to 9
domains as defined by the HTTP request.

20. Discussion
20

21. Benefits
❖ Avoid the distribution of topology and resource information in a
peer-to-peer fashion (MdO-to-MdO).
❖ The (abstracted) information and offered resources/services are
maintained in each local MdO.
❖ An ALTO-based privacy-preserving information model to provide
topology/resource/service info.
❖ An MdO discovery method to determine the underlying network graph and a
potential set of paths before bilateral negotiation between MdOs is started.
21

22. Open Issues
❖ What kind of organization will manage and support the operation of a
broker entity?
➢ Future deployment of SDN at IXPs can be used as a trusted third-party platform to support
rich business models between different operators [DRAFT-HHSFC]
❖ The broker entity maintains a centralized database and hence it could a
point of failure. How avoid this single point of failure?
➢ Local restoration/replication options may be applied.
❖ How is the fine-grained/coarse-grained information exchange handled?
➢ It requires much more complex database handling and information exchange with the MdOs
depending on the policies.
22

23. Future Work
23

24. Road Ahead
24
❖ This proposal may potentially introduce a new service to ALTO (in the
context of Multi-domain orchestration scenarios).
➢ There is an interest in adopting the proposed extension in ALTO WG
➢ Use case examples are needed to support the creation of a new ALTO service
❖ What is still missing in the document?
➢ Identify which issues need further discussion.
■ Performance evaluation
■ Problem Statement, Challenges, Terminology, etc.
➢ Define a more elaborated NFFG object to support extended parameters. (E.g., Monitoring
parameters, Resource requirements, etc.)
➢ Security/Privacy considerations
❖ Gather feedback from the ALTO WG
➢ -01 version reviewed by Richard Yang (Yale University)
■ Comments addressed in -02
❖ Publish the PoC source code in our public repository.

25. Thanks!
● The authors would like to thank the support of Ericsson Research, Brazil.
● Thanks to Robert Szabo (Ericsson Research, Hungary) for the contribution and substantial
feedback and suggestions in this document.
● Many thanks to Richard Yang, Dawn Chan, Jensen Zhang, Shawn Lin, Qiao Xiang, Sabine
Randriamasy for their feedback on this work. 25