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.
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: F1 (S1, D1) and F2 (S2, D2). 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, F1 and F2, 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 F1 and F2 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.
|Conceptual query interfaces and data representation|
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).|
Danny Alex Lachos Perez is a Ph.D. candidate in the Faculty of Electrical and Computer Engineering at University of Campinas (UNICAMP), Brazil.
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.