Multi-domain information exposure using ALTO: The good, the bad and the solution

A common setting in many emerging applications, including data-intensive science applications, flexible inter-domain routing and multi-domain service function chaining, is to route traffic from a source to a destination via multiple network domains. Such applications can benefit substantially from the network information exposure they gain from this to improve their performance.

The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) already provides a generic framework to expose network information for applications. However, exposing multi-domain network information to support emerging use cases introduces issues to be considered in the current ALTO design.

Read: ALTO: Application-Layer Traffic Optimization Protocol

I and my fellow researchers from the University of Campinas, Yale University, Ericsson, Nokia Bell Labs, Telefonica and Sichuan University, have recently concluded a study to better understand these ALTO design issues, the results of which we presented at the Applied Networking Research Workshop 2020 (ANRW’20), as well as solution mechanisms to design a multi-domain ALTO framework. Here is a quick summary of what we discovered and recommend going forward.

What information do applications need?

Applications interact with the network providing the required properties and characteristics needed to be supported by the network. The network then exposes appropriate information for applications to adapt or refine their requests.

For example, consider a collaboration network composed of three-member domains, as shown in Figure 1 above. An application (for example, a large data analysis system) wants to reserve bandwidth for two flows: F₁ (S1, D₁) and F₂ (S₂, D₂). Before the application can run a resource allocation algorithm to execute such submitted flows, it needs to gather some information from the network domains, including the:

• End-to-end cost across multiple domains. This cost may be expressed in terms of resource availability and sharing (for example, network bandwidth) for the set of requested flows to be reserved. In our presented scenario, for example, both flows, F₁ and F₂, are sharing the same network path in domain A. It means that they share a common resource, the network bandwidth.
• Sequence of domains and candidate paths. In multi-domain use cases, each flow will consume networking resources of multiple domains (if the source node and destination node are located in different domains). Therefore, the application needs to discover a sequence of domains and candidate paths between source nodes and destination nodes, that is, which domains are involved for the different traffic flows. In our example, the multi-domain network paths for F₁ and F₂ are [A,B] and [A,C], respectively.

What are the ALTO issues of gathering multi-domain information?

ALTO already introduces basic mechanisms (for example, modularity, dependency) and abstractions (for example, map services) for applications to improve their performance. However, as we’ve mentioned, the current ALTO base protocol is not designed for a multi-domain setting of exposing network information. 

There are, as such, several design issues with using ALTO to provide multi-domain information, which can be roughly categorized into three aspects: (i) communication mechanisms; (ii) conceptual query interfaces and data representation; and (iii) computation model.

Communication mechanisms

Server-to-client ALTO communication: In multi-domain scenarios, it is not possible to optimize the traffic with only locally available network information. Therefore, communications among multiple ALTO servers are necessary to exchange detailed network information of multiple domains. Domain connectivity discovery: To find the resources shared by different source/destination pairs, an application needs to discover which domains are involved in the data movement of each node pair. Besides, a set of candidate paths need to be computed to know how to reach a remote destination node. The current ALTO extensions do not have this feature. ALTO server discovery: Once the multi-domain connectivity discovery is performed, an application needs to be aware of the presence and the location of ALTO servers to get appropriate guidance. Those ALTO servers will be located in different domains, so that multi-domain ALTO server discovery mechanisms are also needed.

Conceptual query interfaces and data representation

Single-domain composition: In the current ALTO framework, each domain can have its own representation of the same network information. Therefore, it is necessary to design multi-domain composition mechanisms, so that network information in multiple domains are adapted together to a single and consistent ‘virtual’ abstraction. Simple resource query language: Applications also need to express their requirements in a query (for example, reachability requirements, blacklist of devices, QoS metrics and so forth). The current query interface in ALTO (for example, filtered network/cost map) cannot express such flexible queries.

Computation model

Scalability: Resource-filtering mechanisms may effectively reduce the redundancy in the network view. ALTO must have the capability to solve the optimization problems specified by the applications’ requirements, which can be computationally expensive and time-consuming. Security and Privacy: The information provided by the ALTO protocol is considered coarse-grained. New ALTO extensions have been designed to provide fine-grained network information to the applications. Using these ALTO extension services for multi-domain scenarios would raise new security and privacy concerns.

How to design a whole ALTO framework?

To address the above-mentioned issues, I’ve summarized below the envisioned solutions and ongoing efforts we recommended in our paper, to allow ALTO to expose network information across multiple domains.

Current Issue	Ongoing efforts and envisioned solutions
Server-to-client ALTO communication	ALTO server communication: ALTO servers may consider a hierarchical or mesh architectural deployment (INTER-ALTO, MD-ANALY, BROKER, SFC-MD). In a hierarchical design, ALTO servers in domain partitions gather local information and send it to the central server. In a mesh deployment, ALTO servers may be set up in each domain independently to gather the network information from other connected domains.
Domain connectivity discovery	Multi-domain connectivity discovery: Multi-domain mechanisms combining domains sequence computation and paths computation need to be defined, or standardized computation protocols could be leveraged for inspiring this design requirement such as Border Gateway Protocol (RFC4 271), BGP-LS (RFC 7752), and Path Computation Elements (RFC 5441, RFC 6805).
ALTO server discovery	Multi-domain ALTO server discovery: The ALTO cross-domain server discovery document specifies a procedure for identifying ALTO servers outside of the ALTO client’s own network domain. Other mechanisms could also be leveraged, such as those based on Path Computation Elements (RFC 4674) or BGP achitectures.
Single-domain composition	Unified Resource Representation: Multi-domain composition mechanisms are necessary, so that network information from ALTO servers in multiple domains can fit into a single and consistent ‘virtual’ domain abstraction. UNI-REPRE, UNICORN, and MERCATOR propose the use of mathematical programming constraints for multi-domain composition.
Simple resource query language	Generic/flexible query language: With a flexible/generic query language, the network can filter out a large number of unqualified domains. The language specification could be inspired by standard (for example, 5G Slice Templates or ETSI NFV Network Service Descriptor) or pre-standard (for example, Socket Intents or Intent-based networking) mechanisms, implemented with user-friendly grammar (for example, SQL-style query).
Scalability	Computation complexity optimization: ALTO servers need to support mechanisms to improve scalability and performance. A possible optimization consists in using equivalent transformation algorithms that identify/remove redundant information to obtain a more compact view. Another alternative to explore is to proactively discover network resource information, and quickly project those pre-computed abstractions.
Security and privacy	Security-/privacy-preserving: ALTO needs mechanisms (with little overhead) that provide accurate network information sharing capabilities, and at the same time, protects each member domain. This privacy-preserving multi-domain information process may consider, for instance, a secure multi-party computation (SMPC) protocol (MD-ANALYTICS, MERCATOR).

To learn more about our study, watch our presentation at the ANRW’20 or read our position paper.

Danny Alex Lachos Perez is a Ph.D. candidate in the Faculty of Electrical and Computer Engineering at University of Campinas (UNICAMP), Brazil.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.