summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9275.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9275.txt')
-rw-r--r--doc/rfc/rfc9275.txt2856
1 files changed, 2856 insertions, 0 deletions
diff --git a/doc/rfc/rfc9275.txt b/doc/rfc/rfc9275.txt
new file mode 100644
index 0000000..59418ed
--- /dev/null
+++ b/doc/rfc/rfc9275.txt
@@ -0,0 +1,2856 @@
+
+
+
+
+Internet Engineering Task Force (IETF) K. Gao
+Request for Comments: 9275 Sichuan University
+Category: Experimental Y. Lee
+ISSN: 2070-1721 Samsung
+ S. Randriamasy
+ Nokia Bell Labs
+ Y. Yang
+ Yale University
+ J. Zhang
+ Tongji University
+ September 2022
+
+
+ An Extension for Application-Layer Traffic Optimization (ALTO):
+ Path Vector
+
+Abstract
+
+ This document is an extension to the base Application-Layer Traffic
+ Optimization (ALTO) protocol. It extends the ALTO cost map and ALTO
+ property map services so that an application can decide to which
+ endpoint(s) to connect based not only on numerical/ordinal cost
+ values but also on fine-grained abstract information regarding the
+ paths. This is useful for applications whose performance is impacted
+ by specific components of a network on the end-to-end paths, e.g.,
+ they may infer that several paths share common links and prevent
+ traffic bottlenecks by avoiding such paths. This extension
+ introduces a new abstraction called the "Abstract Network Element"
+ (ANE) to represent these components and encodes a network path as a
+ vector of ANEs. Thus, it provides a more complete but still abstract
+ graph representation of the underlying network(s) for informed
+ traffic optimization among endpoints.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This document is a product of the Internet Engineering
+ Task Force (IETF). It represents the consensus of the IETF
+ community. It has received public review and has been approved for
+ publication by the Internet Engineering Steering Group (IESG). Not
+ all documents approved by the IESG are candidates for any level of
+ Internet Standard; see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9275.
+
+Copyright Notice
+
+ Copyright (c) 2022 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Revised BSD License text as described in Section 4.e of the
+ Trust Legal Provisions and are provided without warranty as described
+ in the Revised BSD License.
+
+Table of Contents
+
+ 1. Introduction
+ 2. Requirements Language
+ 3. Terminology
+ 4. Requirements and Use Cases
+ 4.1. Design Requirements
+ 4.2. Sample Use Cases
+ 4.2.1. Exposing Network Bottlenecks
+ 4.2.2. Resource Exposure for CDNs and Service Edges
+ 5. Path Vector Extension: Overview
+ 5.1. Abstract Network Element (ANE)
+ 5.1.1. ANE Entity Domain
+ 5.1.2. Ephemeral and Persistent ANEs
+ 5.1.3. Property Filtering
+ 5.2. Path Vector Cost Type
+ 5.3. Multipart Path Vector Response
+ 5.3.1. Identifying the Media Type of the Object Root
+ 5.3.2. References to Part Messages
+ 6. Specification: Basic Data Types
+ 6.1. ANE Name
+ 6.2. ANE Entity Domain
+ 6.2.1. Entity Domain Type
+ 6.2.2. Domain-Specific Entity Identifier
+ 6.2.3. Hierarchy and Inheritance
+ 6.2.4. Media Type of Defining Resource
+ 6.3. ANE Property Name
+ 6.4. Initial ANE Property Types
+ 6.4.1. Maximum Reservable Bandwidth
+ 6.4.2. Persistent Entity ID
+ 6.4.3. Examples
+ 6.5. Path Vector Cost Type
+ 6.5.1. Cost Metric: "ane-path"
+ 6.5.2. Cost Mode: "array"
+ 6.6. Part Resource ID and Part Content ID
+ 7. Specification: Service Extensions
+ 7.1. Notation
+ 7.2. Multipart Filtered Cost Map for Path Vector
+ 7.2.1. Media Type
+ 7.2.2. HTTP Method
+ 7.2.3. Accept Input Parameters
+ 7.2.4. Capabilities
+ 7.2.5. Uses
+ 7.2.6. Response
+ 7.3. Multipart Endpoint Cost Service for Path Vector
+ 7.3.1. Media Type
+ 7.3.2. HTTP Method
+ 7.3.3. Accept Input Parameters
+ 7.3.4. Capabilities
+ 7.3.5. Uses
+ 7.3.6. Response
+ 8. Examples
+ 8.1. Sample Setup
+ 8.2. Information Resource Directory
+ 8.3. Multipart Filtered Cost Map
+ 8.4. Multipart Endpoint Cost Service Resource
+ 8.5. Incremental Updates
+ 8.6. Multi-Cost
+ 9. Compatibility with Other ALTO Extensions
+ 9.1. Compatibility with Legacy ALTO Clients/Servers
+ 9.2. Compatibility with Multi-Cost Extension
+ 9.3. Compatibility with Incremental Update Extension
+ 9.4. Compatibility with Cost Calendar Extension
+ 10. General Discussion
+ 10.1. Constraint Tests for General Cost Types
+ 10.2. General Multi-Resource Query
+ 11. Security Considerations
+ 12. IANA Considerations
+ 12.1. "ALTO Cost Metrics" Registry
+ 12.2. "ALTO Cost Modes" Registry
+ 12.3. "ALTO Entity Domain Types" Registry
+ 12.4. "ALTO Entity Property Types" Registry
+ 12.4.1. New ANE Property Type: Maximum Reservable Bandwidth
+ 12.4.2. New ANE Property Type: Persistent Entity ID
+ 13. References
+ 13.1. Normative References
+ 13.2. Informative References
+ Acknowledgments
+ Authors' Addresses
+
+1. Introduction
+
+ Network performance metrics are crucial for assessing the Quality of
+ Experience (QoE) of applications. The Application-Layer Traffic
+ Optimization (ALTO) protocol allows Internet Service Providers (ISPs)
+ to provide guidance, such as topological distances between different
+ end hosts, to overlay applications. Thus, the overlay applications
+ can potentially improve the perceived QoE by better orchestrating
+ their traffic to utilize the resources in the underlying network
+ infrastructure.
+
+ The existing ALTO cost map (Section 11.2.3 of [RFC7285]) and Endpoint
+ Cost Service (Section 11.5 of [RFC7285]) provide only cost
+ information for an end-to-end path defined by its <source,
+ destination> endpoints: the base protocol [RFC7285] allows the
+ services to expose the topological distances of end-to-end paths,
+ while various extensions have been proposed to extend the capability
+ of these services, e.g., to express other performance metrics
+ [ALTO-PERF-METRICS], to query multiple costs simultaneously
+ [RFC8189], and to obtain time-varying values [RFC8896].
+
+ While numerical/ordinal cost values for end-to-end paths provided by
+ the existing extensions are sufficient to optimize the QoE of many
+ overlay applications, the QoE of some overlay applications also
+ depends on the properties of particular components on the paths. For
+ example, job completion time, which is an important QoE metric for a
+ large-scale data analytics application, is impacted by shared
+ bottleneck links inside the carrier network, as link capacity may
+ impact the rate of data input/output to the job. We refer to such
+ components of a network as Abstract Network Elements (ANEs).
+
+ Predicting such information can be very complex without the help of
+ ISPs; for example, [BOXOPT] has shown that finding the optimal
+ bandwidth reservation for multiple flows can be NP-hard without
+ further information than whether a reservation succeeds. With proper
+ guidance from the ISP, an overlay application may be able to schedule
+ its traffic for better QoE. In the meantime, it may be helpful as
+ well for ISPs if applications could avoid using bottlenecks or
+ challenging the network with poorly scheduled traffic.
+
+ Despite the claimed benefits, ISPs are not likely to expose raw
+ details on their network paths: first because ISPs have requirements
+ to hide their network topologies, second because these details may
+ increase volume and computation overhead, and last because
+ applications do not necessarily need all the network path details and
+ are likely not able to understand them.
+
+ Therefore, it is beneficial for both ISPs and applications if an ALTO
+ server provides ALTO clients with an "abstract network state" that
+ provides the necessary information to applications, while hiding
+ network complexity and confidential information. An "abstract
+ network state" is a selected set of abstract representations of ANEs
+ traversed by the paths between <source, destination> pairs combined
+ with properties of these ANEs that are relevant to the overlay
+ applications' QoE. Both an application via its ALTO client and the
+ ISP via the ALTO server can achieve better confidentiality and
+ resource utilization by appropriately abstracting relevant ANEs.
+ Server scalability can also be improved by combining ANEs and their
+ properties in a single response.
+
+ This document extends the ALTO base protocol [RFC7285] to allow an
+ ALTO server to convey "abstract network state" for paths defined by
+ their <source, destination> pairs. To this end, it introduces a new
+ cost type called a "Path Vector", following the cost metric
+ registration specified in [RFC7285] and the updated cost mode
+ registration specified in [RFC9274]. A Path Vector is an array of
+ identifiers that identifies an ANE, which can be associated with
+ various properties. The associations between ANEs and their
+ properties are encoded in an ALTO information resource called the
+ "entity property map", which is specified in [RFC9240].
+
+ For better confidentiality, this document aims to minimize
+ information exposure of an ALTO server when providing Path Vector
+ services. In particular, this document enables the capability, and
+ also recommends that 1) ANEs be constructed on demand and 2) an ANE
+ only be associated with properties that are requested by an ALTO
+ client. A Path Vector response involves two ALTO maps: the cost map,
+ which contains the Path Vector results; and the up-to-date entity
+ property map, which contains the properties requested for these ANEs.
+ To enforce consistency and improve server scalability, this document
+ uses the "multipart/related" content type as defined in [RFC2387] to
+ return the two maps in a single response.
+
+ As a single ISP may not have knowledge of the full Internet paths
+ between arbitrary endpoints, this document is mainly applicable when
+
+ * there is a single ISP between the requested source and destination
+ Provider-defined Identifiers (PIDs) or endpoints -- for example,
+ ISP-hosted Content Delivery Network (CDN) / edge, tenant
+ interconnection in a single public cloud platform, etc., or
+
+ * the Path Vectors are generated from end-to-end measurement data.
+
+2. Requirements Language
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Terminology
+
+ This document extends the ALTO base protocol [RFC7285] and the entity
+ property map extension [RFC9240]. In addition to the terms defined
+ in those documents, this document also uses the following terms:
+
+ Abstract Network Element (ANE): An abstract representation for a
+ component in a network that handles data packets and whose
+ properties can potentially have an impact on the end-to-end
+ performance of traffic. An ANE can be a physical device such as a
+ router, a link, or an interface; or an aggregation of devices such
+ as a subnetwork or a data center.
+
+ The definition of an ANE is similar to that for a network element
+ as defined in [RFC2216] in the sense that they both provide an
+ abstract representation of specific components of a network.
+ However, they have different criteria on how these particular
+ components are selected. Specifically, a network element requires
+ the components to be capable of exercising QoS control, while an
+ ANE only requires the components to have an impact on end-to-end
+ performance.
+
+ ANE name: A string that uniquely identifies an ANE in a specific
+ scope. An ANE can be constructed either statically in advance or
+ on demand based on the requested information. Thus, different
+ ANEs may only be valid within a particular scope, either ephemeral
+ or persistent. Within each scope, an ANE is uniquely identified
+ by an ANE name, as defined in Section 6.1. Note that an ALTO
+ client must not assume ANEs in different scopes but with the same
+ ANE name refer to the same component(s) of the network.
+
+ Path Vector (or ANE Path Vector): Refers to a JSON array of ANE
+ names. It is a generalization of a BGP path vector. While a
+ standard BGP path vector (Section 5.1.2 of [RFC4271]) specifies a
+ sequence of Autonomous Systems (ASes) for a destination IP prefix,
+ the Path Vector defined in this extension specifies a sequence of
+ ANEs for either 1) a source PID and a destination PID, as in the
+ CostMapData object (Section 11.2.3.6 of [RFC7285]) or 2) a source
+ endpoint and a destination endpoint, as in the EndpointCostMapData
+ object (Section 11.5.1.6 of [RFC7285]).
+
+ Path Vector resource: An ALTO information resource (Section 8.1 of
+ [RFC7285]) that supports the extension defined in this document.
+
+ Path Vector cost type: A special cost type, which is specified in
+ Section 6.5. When this cost type is present in an Information
+ Resource Directory (IRD) entry, it indicates that the information
+ resource is a Path Vector resource. When this cost type is
+ present in a filtered cost map request or an Endpoint Cost Service
+ request, it indicates that each cost value must be interpreted as
+ a Path Vector.
+
+ Path Vector request: The POST message sent to an ALTO Path Vector
+ resource.
+
+ Path Vector response: Refers to the multipart/related message
+ returned by a Path Vector resource.
+
+4. Requirements and Use Cases
+
+4.1. Design Requirements
+
+ This section gives an illustrative example of how an overlay
+ application can benefit from the extension defined in this document.
+
+ Assume that an application has control over a set of flows, which may
+ go through shared links/nodes and share bottlenecks. The application
+ seeks to schedule the traffic among multiple flows to get better
+ performance. The constraints of feasible rate allocations of those
+ flows will benefit the scheduling. However, cost maps as defined in
+ [RFC7285] cannot reveal such information.
+
+ Specifically, consider the example network shown in Figure 1. The
+ network has seven switches ("sw1" to "sw7") forming a dumbbell
+ topology. Switches "sw1", "sw2", "sw3", and "sw4" are access
+ switches, and "sw5-sw7" form the backbone. End hosts "eh1" to "eh4"
+ are connected to access switches "sw1" to "sw4", respectively.
+ Assume that the bandwidth of link "eh1 -> sw1" and link "sw1 -> sw5"
+ is 150 Mbps and the bandwidth of the other links is 100 Mbps.
+
+ +-----+
+ | |
+ --+ sw6 +--
+ / | | \
+ PID1 +-----+ / +-----+ \ +-----+ PID2
+ eh1__| |_ / \ ____| |__eh2
+ 192.0.2.2 | sw1 | \ +--|--+ +--|--+ / | sw2 | 192.0.2.3
+ +-----+ \ | | | |/ +-----+
+ \_| sw5 +---------+ sw7 |
+ PID3 +-----+ / | | | |\ +-----+ PID4
+ eh3__| |__/ +-----+ +-----+ \____| |__eh4
+ 192.0.2.4 | sw3 | | sw4 | 192.0.2.5
+ +-----+ +-----+
+
+ bw(eh1--sw1) = bw(sw1--sw5) = 150 Mbps
+ bw(eh2--sw2) = bw(eh3--sw3) = bw(eh4--sw4) = 100 Mbps
+ bw(sw1--sw5) = bw(sw3--sw5) = bw(sw2--sw7) = bw(sw4--sw7) = 100 Mbps
+ bw(sw5--sw6) = bw(sw5--sw7) = bw(sw6--sw7) = 100 Mbps
+
+ Figure 1: Raw Network Topology
+
+ The base ALTO topology abstraction of the network is shown in
+ Figure 2. Assume that the cost map returns a hypothetical cost type
+ representing the available bandwidth between a source and a
+ destination.
+
+ +----------------------+
+ {eh1} | | {eh2}
+ PID1 | | PID2
+ +------+ +------+
+ | |
+ | |
+ {eh3} | | {eh4}
+ PID3 | | PID4
+ +------+ +------+
+ | |
+ +----------------------+
+
+ Figure 2: Base Topology Abstraction
+
+ Now, assume that the application wants to maximize the total rate of
+ the traffic among a set of <source, destination> pairs -- say, "eh1
+ -> eh2" and "eh1 -> eh4". Let "x" denote the transmission rate of
+ "eh1 -> eh2" and "y" denote the rate of "eh1 -> eh4". The objective
+ function is
+
+ max(x + y).
+
+ With the ALTO cost map, the costs between PID1 and PID2 and between
+ PID1 and PID4 will both be 100 Mbps. The client can get a capacity
+ region of
+
+ x <= 100 Mbps
+ y <= 100 Mbps.
+
+ With this information, the client may mistakenly think it can achieve
+ a maximum total rate of 200 Mbps. However, this rate is infeasible,
+ as there are only two potential cases:
+
+ Case 1: "eh1 -> eh2" and "eh1 -> eh4" take different path segments
+ from "sw5" to "sw7". For example, if "eh1 -> eh2" uses path "eh1
+ -> sw1 -> sw5 -> sw6 -> sw7 -> sw2 -> eh2" and "eh1 -> eh4" uses
+ path "eh1 -> sw1 -> sw5 -> sw7 -> sw4 -> eh4", then the shared
+ bottleneck links are "eh1 -> sw1" and "sw1 -> sw5". In this case,
+ the capacity region is:
+
+ x <= 100 Mbps
+ y <= 100 Mbps
+ x + y <= 150 Mbps
+
+ and the real optimal total rate is 150 Mbps.
+
+ Case 2: "eh1 -> eh2" and "eh1 -> eh4" take the same path segment
+ from "sw5" to "sw7". For example, if "eh1 -> eh2" uses path "eh1
+ -> sw1 -> sw5 -> sw7 -> sw2 -> eh2" and "eh1 -> eh4" also uses
+ path "eh1 -> sw1 -> sw5 -> sw7 -> sw4 -> eh4", then the shared
+ bottleneck link is "sw5 -> sw7". In this case, the capacity
+ region is:
+
+ x <= 100 Mbps
+ y <= 100 Mbps
+ x + y <= 100 Mbps
+
+ and the real optimal total rate is 100 Mbps.
+
+ Clearly, with more accurate and fine-grained information, the
+ application can better predict its traffic and may orchestrate its
+ resources accordingly. However, to provide such information, the
+ network needs to expose abstract information beyond the simple cost
+ map abstraction. In particular:
+
+ * The ALTO server must expose abstract information about the network
+ paths that are traversed by the traffic between a source and a
+ destination beyond a simple numerical value, which allows the
+ overlay application to distinguish between Cases 1 and 2 and to
+ compute the optimal total rate accordingly.
+
+ * The ALTO server must allow the client to distinguish the common
+ ANE shared by "eh1 -> eh2" and "eh1 -> eh4", e.g., "eh1--sw1" and
+ "sw1--sw5" in Case 1.
+
+ * The ALTO server must expose abstract information on the properties
+ of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4". For example,
+ an ALTO server can either expose the available bandwidth between
+ "eh1--sw1", "sw1--sw5", "sw5--sw7", "sw5--sw6", "sw6--sw7",
+ "sw7--sw2", "sw7--sw4", "sw2--eh2", "sw4--eh4" in Case 1 or expose
+ three abstract elements "A", "B", and "C", which represent the
+ linear constraints that define the same capacity region in Case 1.
+
+ In general, we can conclude that to support the use case for multiple
+ flow scheduling, the ALTO framework must be extended to satisfy the
+ following additional requirements (ARs):
+
+ AR1: An ALTO server must provide the ANEs that are important for
+ assessing the QoE of the overlay application on the path of a
+ <source, destination> pair.
+
+ AR2: An ALTO server must provide information to identify how ANEs
+ are shared on the paths of different <source, destination> pairs.
+
+ AR3: An ALTO server must provide information on the properties that
+ are important for assessing the QoE of the application for ANEs.
+
+ The extension defined in this document specifies a solution to expose
+ such abstract information.
+
+4.2. Sample Use Cases
+
+ While the problem related to multiple flow scheduling is used to help
+ identify the additional requirements, the extension defined in this
+ document can be applied to a wide range of applications. This
+ section highlights some of the reported use cases.
+
+4.2.1. Exposing Network Bottlenecks
+
+ One important use case for the Path Vector extension is to expose
+ network bottlenecks. Applications that need to perform large-scale
+ data transfers can benefit from being aware of the resource
+ constraints exposed by this extension even if they have different
+ objectives. One such example is the Worldwide LHC Computing Grid
+ (WLCG) (where "LHC" means "Large Hadron Collider"), which is the
+ largest example of a distributed computation collaboration in the
+ research and education world.
+
+ Figure 3 illustrates an example of using an ALTO Path Vector as an
+ interface between the job optimizer for a data analytics system and
+ the network manager. In particular, we assume that the objective of
+ the job optimizer is to minimize the job completion time.
+
+ In such a setting, the network-aware job optimizer (e.g., [CLARINET])
+ takes a query and generates multiple query execution plans (QEPs).
+ It can encode the QEPs as Path Vector requests that are sent to an
+ ALTO server. The ALTO server obtains the routing information for the
+ flows in a QEP and finds links, routers, or middleboxes (e.g., a
+ stateful firewall) that can potentially become bottlenecks for the
+ QEP (e.g., see [NOVA] and [G2] for mechanisms to identify bottleneck
+ links under different settings). The resource constraint information
+ is encoded in a Path Vector response and returned to the ALTO client.
+
+ With the network resource constraints, the job optimizer may choose
+ the QEP with the optimal job completion time to be executed. It must
+ be noted that the ALTO framework itself does not offer the capability
+ to control the traffic. However, certain network managers may offer
+ ways to enforce resource guarantees, such as on-demand tunnels (e.g.,
+ [SWAN]), demand vectors (e.g., [HUG], [UNICORN]), etc. The traffic
+ control interfaces and mechanisms are out of scope for this document.
+
+ Data schema Queries
+ | |
+ \ /
+ +-------------+ +-----------------+
+ | ALTO Client | <===============> | Job Optimizer |
+ +-------------+ +-----------------+
+ PV | ^ PV |
+ Request | | Response |
+ | | On-demand resource |
+ (Potential | | (Network allocation, demand |
+ Data | | Resource vectors, etc. |
+ Transfers) | | Constraints) (Non-ALTO interfaces)|
+ v | v
+ +-------------+ +-----------------+
+ | ALTO Server | <===============> | Network Manager |
+ +-------------+ +-----------------+
+ / | \
+ | | |
+ WAN DC1 DC2
+
+ Figure 3: Example Use Case for Data Analytics
+
+ Another example is illustrated in Figure 4. Consider a network
+ consisting of multiple sites and a non-blocking core network, i.e.,
+ the links in the core network have sufficient bandwidth that they
+ will not become a bottleneck for the data transfers.
+
+ Ongoing transfers New transfer requests
+ \----\ |
+ | |
+ v v
+ +-------------+ +---------------+
+ | ALTO Client | <===========> | Data Transfer |
+ +-------------+ | Scheduler |
+ ^ | ^ | PV Request +---------------+
+ | | | \--------------\
+ | | \--------------\ |
+ | v PV Response | v
+ +-------------+ +-------------+
+ | ALTO Server | | ALTO Server |
+ +-------------+ +-------------+
+ || ||
+ +---------+ +---------+
+ | Network | | Network |
+ | Manager | | Manager |
+ +---------+ +---------+
+ . .
+ . _~_ __ . . .
+ . ( )( ) .___
+ ~v~v~ /--( )------------( )
+ ( )-----/ ( ) ( )
+ ~w~w~ ~^~^~^~ ~v~v~
+ Site 1 Non-blocking Core Site 2
+
+ Figure 4: Example Use Case for Cross-Site Bottleneck Discovery
+
+ With the Path Vector extension, a site can reveal the bottlenecks
+ inside its own network with necessary information (such as link
+ capacities) to the ALTO client, instead of providing the full
+ topology and routing information, or no bottleneck information at
+ all. The bottleneck information can be used to analyze the impact of
+ adding/removing data transfer flows, e.g., using the framework
+ defined in [G2]. For example, assume that hosts "a", "b", and "c"
+ are in Site 1 and hosts "d", "e", and "f" are in Site 2, and there
+ are three flows in two sites: "a -> b", "c -> d", and "e -> f"
+ (Figure 5).
+
+ Site 1:
+
+ [c]
+ .
+ ........................................> [d]
+ +---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps
+ | A |---------| B |---------| GW |--------- Core
+ +---+ +---+ +----+
+ ...................
+ . .
+ . v
+ [a] [b]
+
+ Site 2:
+
+ [d] <........................................ [c]
+ +---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
+ | X |--------| Y |---------| GW |--------- Core
+ +---+ +---+ +----+
+ ....................
+ . .
+ . v
+ [e] [f]
+
+ Figure 5: Example: Three Flows in Two Sites
+
+ For these flows, Site 1 returns:
+
+ a: { b: [ane1] },
+ c: { d: [ane1, ane2, ane3] }
+
+ ane1: bw = 10 Gbps (link: A->B)
+ ane2: bw = 10 Gbps (link: B->GW)
+ ane3: bw = 50 Gbps (link: GW->Core)
+
+ and Site 2 returns:
+
+ c: { d: [anei, aneii, aneiii] }
+ e: { f: [aneiv] }
+
+ anei: bw = 5 Gbps (link Y->X)
+ aneii: bw = 10 Gbps (link GW->Y)
+ aneiii: bw = 20 Gbps (link Core->GW)
+ aneiv: bw = 10 Gbps (link Y->GW)
+
+ With this information, the data transfer scheduler can use algorithms
+ such as the theory on bottleneck structure [G2] to predict the
+ potential throughput of the flows.
+
+4.2.2. Resource Exposure for CDNs and Service Edges
+
+ At the time of this writing, a growing trend in today's applications
+ is to bring storage and computation closer to the end users for
+ better QoE, such as CDNs, augmented reality / virtual reality, and
+ cloud gaming, as reported in various documents (e.g., [SEREDGE] and
+ [MOWIE]). ISPs may deploy multiple layers of CDN caches or, more
+ generally, service edges, with different latencies and available
+ resources, including the number of CPU cores, memory, and storage.
+
+ For example, Figure 6 illustrates a typical edge-cloud scenario where
+ memory is measured in gigabytes (GB) and storage is measured in
+ terabytes (TB). The "on-premise" edge nodes are closest to the end
+ hosts and have the lowest latency, and the site-radio edge node and
+ access central office (CO) have higher latencies but more available
+ resources.
+
+ +-------------+ +----------------------+
+ | ALTO Client | <==========> | Application Provider |
+ +-------------+ +----------------------+
+ PV | ^ PV |
+ Request | | Response | Resource allocation,
+ | | | service establishment,
+ (End hosts | | (Edge nodes | etc.
+ and cloud | | and metrics) |
+ servers) | | |
+ v | v
+ +-------------+ +---------------------+
+ | ALTO Server | <=========> | Cloud-Edge Provider |
+ +-------------+ +---------------------+
+ ____________________________________/\___________
+ / \
+ | (((o |
+ |
+ /_\ _~_ __ __
+ a (/\_/\) ( ) ( )~( )_
+ \ /------( )---------( )----\\---( )
+ _|_ / (______) (___) ( )
+ |_| -/ Site-radio Access CO (__________)
+ /---\ Edge Node 1 | Cloud DC
+ On premise |
+ /---------/
+ (((o /
+ | /
+ Site-radio /_\ /
+ Edge Node 2(/\_/\)-----/
+ /(_____)\
+ ___ / \ ---
+ b--|_| -/ \--|_|--c
+ /---\ /---\
+ On premise On premise
+
+ Figure 6: Example Use Case for Service Edge Exposure
+
+ With the extension defined in this document, an ALTO server can
+ selectively reveal the CDNs and service edges that reside along the
+ paths between different end hosts and/or the cloud servers, together
+ with their properties (e.g., storage capabilities or Graphics
+ Processing Unit (GPU) capabilities) and available Service Level
+ Agreement (SLA) plans. See Figure 7 for an example where the query
+ is made for sources [a, b] and destinations [b, c, DC]. Here, each
+ ANE represents a service edge, and the properties include access
+ latency, available resources, etc. Note that the properties here are
+ only used for illustration purposes and are not part of this
+ extension.
+
+ a: { b: [ane1, ane2, ane3, ane4, ane5],
+ c: [ane1, ane2, ane3, ane4, ane6],
+ DC: [ane1, ane2, ane3] }
+ b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] }
+
+ ane1: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
+ (On premise, a)
+
+ ane2: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
+ (Site-radio Edge Node 1)
+
+ ane3: latency = 100 ms cpu = 8 memory = 128 GB storage = 100 TB
+ (Access CO)
+
+ ane4: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
+ (Site-radio Edge Node 2)
+
+ ane5: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
+ (On premise, b)
+
+ ane6: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
+ (On premise, c)
+
+ Figure 7: Example Service Edge Query Results
+
+ With the service edge information, an ALTO client may better conduct
+ CDN request routing or offload functionalities from the user
+ equipment to the service edge, with considerations in place for
+ customized quality of experience.
+
+5. Path Vector Extension: Overview
+
+ This section provides a non-normative overview of the Path Vector
+ extension defined in this document. It is assumed that readers are
+ familiar with both the base protocol [RFC7285] and the entity
+ property map extension [RFC9240].
+
+ To satisfy the additional requirements listed in Section 4.1, this
+ extension:
+
+ 1. introduces the concept of an ANE as the abstraction of components
+ in a network whose properties may have an impact on end-to-end
+ performance of the traffic handled by those components,
+
+ 2. extends the cost map and Endpoint Cost Service to convey the ANEs
+ traversed by the path of a <source, destination> pair as Path
+ Vectors, and
+
+ 3. uses the entity property map to convey the association between
+ the ANEs and their properties.
+
+ Thus, an ALTO client can learn about the ANEs that are important for
+ assessing the QoE of different <source, destination> pairs by
+ investigating the corresponding Path Vector value (AR1) and can also
+ (1) identify common ANEs if an ANE appears in the Path Vectors of
+ multiple <source, destination> pairs (AR2) and (2) retrieve the
+ properties of the ANEs by searching the entity property map (AR3).
+
+5.1. Abstract Network Element (ANE)
+
+ This extension introduces the ANE as an indirect and network-agnostic
+ way to specify a component or an aggregation of components of a
+ network whose properties have an impact on end-to-end performance for
+ application traffic between endpoints.
+
+ ANEs allow ALTO servers to focus on common properties of different
+ types of network components. For example, the throughput of a flow
+ can be constrained by different components in a network: the capacity
+ of a physical link, the maximum throughput of a firewall, the
+ reserved bandwidth of an MPLS tunnel, etc. In the example below,
+ assume that the throughput of the firewall is 100 Mbps and the
+ capacity for link (A, B) is also 100 Mbps; they result in the same
+ constraint on the total throughput of f1 and f2. Thus, they are
+ identical when treated as an ANE.
+
+ f1 | ^ f1
+ | | ----------------->
+ +----------+ +---+ +---+
+ | Firewall | | A |-----| B |
+ +----------+ +---+ +---+
+ | | ----------------->
+ v | f2 f2
+
+ When an ANE is defined by an ALTO server, it is assigned an
+ identifier by the ALTO server, i.e., a string of type ANEName as
+ specified in Section 6.1, and a set of associated properties.
+
+5.1.1. ANE Entity Domain
+
+ In this extension, the associations between ANEs and their properties
+ are conveyed in an entity property map. Thus, ANEs must constitute
+ an "entity domain" (Section 5.1 of [RFC9240]), and each ANE property
+ must be an entity property (Section 5.2 of [RFC9240]).
+
+ Specifically, this document defines a new entity domain called "ane"
+ as specified in Section 6.2; Section 6.4 defines two initial property
+ types for the ANE entity domain.
+
+5.1.2. Ephemeral and Persistent ANEs
+
+ By design, ANEs are ephemeral and not to be used in further requests
+ to other ALTO resources. More precisely, the corresponding ANE names
+ are no longer valid beyond the scope of a Path Vector response or the
+ incremental update stream for a Path Vector request. Compared with
+ globally unique ANE names, ephemeral ANEs have several benefits,
+ including better privacy for the ISP's internal structure and more
+ flexible ANE computation.
+
+ For example, an ALTO server may define an ANE for each aggregated
+ bottleneck link between the sources and destinations specified in the
+ request. For requests with different sources and destinations, the
+ bottlenecks may be different but can safely reuse the same ANE names.
+ The client can still adjust its traffic based on the information, but
+ it is difficult to infer the underlying topology with multiple
+ queries.
+
+ However, sometimes an ISP may intend to selectively reveal some
+ "persistent" network components that, as opposed to being ephemeral,
+ have a longer life cycle. For example, an ALTO server may define an
+ ANE for each service edge cluster. Once a client chooses to use a
+ service edge, e.g., by deploying some user-defined functions, it may
+ want to stick to the service edge to avoid the complexity of state
+ transition or synchronization, and continuously query the properties
+ of the edge cluster.
+
+ This document provides a mechanism to expose such network components
+ as persistent ANEs. A persistent ANE has a persistent ID that is
+ registered in a property map, together with its properties. See
+ Sections 6.2.4 and 6.4.2 for more detailed instructions on how to
+ identify ephemeral ANEs and persistent ANEs.
+
+5.1.3. Property Filtering
+
+ Resource-constrained ALTO clients (see Section 4.1.2 of [RFC7285])
+ may benefit from the filtering of Path Vector query results at the
+ ALTO server, as an ALTO client may only require a subset of the
+ available properties.
+
+ Specifically, the available properties for a given resource are
+ announced in the Information Resource Directory (IRD) as a new
+ filtering capability called "ane-property-names". The properties
+ selected by a client as being of interest are specified in the
+ subsequent Path Vector queries using the "ane-property-names" filter.
+ The response only includes the selected properties for the ANEs.
+
+ The "ane-property-names" capability for the cost map and the Endpoint
+ Cost Service is specified in Sections 7.2.4 and 7.3.4, respectively.
+ The "ane-property-names" filter for the cost map and the Endpoint
+ Cost Service is specified in Sections 7.2.3 and 7.3.3 accordingly.
+
+5.2. Path Vector Cost Type
+
+ For an ALTO client to correctly interpret the Path Vector, this
+ extension specifies a new cost type called the "Path Vector cost
+ type".
+
+ The Path Vector cost type must convey both the interpretation and
+ semantics in the "cost-mode" and "cost-metric" parameters,
+ respectively. Unfortunately, a single "cost-mode" value cannot fully
+ specify the interpretation of a Path Vector, which is a compound data
+ type. For example, in programming languages such as C++, if there
+ existed a JSON array type named JSONArray, a Path Vector would have
+ the type of JSONArray<ANEName>.
+
+ Instead of extending the "type system" of ALTO, this document takes a
+ simple and backward-compatible approach. Specifically, the "cost-
+ mode" of the Path Vector cost type is "array", which indicates that
+ the value is a JSON array. Then, an ALTO client must check the value
+ of the "cost-metric" parameter. If the value is "ane-path", it means
+ that the JSON array should be further interpreted as a path of
+ ANENames.
+
+ The Path Vector cost type is specified in Section 6.5.
+
+5.3. Multipart Path Vector Response
+
+ For a basic ALTO information resource, a response contains only one
+ type of ALTO resource, e.g., network map, cost map, or property
+ map. Thus, only one round of communication is required: an ALTO
+ client sends a request to an ALTO server, and the ALTO server returns
+ a response, as shown in Figure 8.
+
+ ALTO client ALTO server
+ |-------------- Request ---------------->|
+ |<------------- Response ----------------|
+
+ Figure 8: A Typical ALTO Request and Response
+
+ The extension defined in this document, on the other hand, involves
+ two types of information resources: Path Vectors conveyed in an
+ InfoResourceCostMap data component (defined in Section 11.2.3.6 of
+ [RFC7285]) or an InfoResourceEndpointCostMap data component (defined
+ in Section 11.5.1.6 of [RFC7285]), and ANE properties conveyed in an
+ InfoResourceProperties data component (defined in Section 7.6 of
+ [RFC9240]).
+
+ Instead of two consecutive message exchanges, the extension defined
+ in this document enforces one round of communication. Specifically,
+ the ALTO client must include the source and destination pairs and the
+ requested ANE properties in a single request, and the ALTO server
+ must return a single response containing both the Path Vectors and
+ properties associated with the ANEs in the Path Vectors, as shown in
+ Figure 9. Since the two parts are bundled together in one response
+ message, their orders are interchangeable. See Sections 7.2.6 and
+ 7.3.6 for details.
+
+ ALTO client ALTO server
+ |------------- PV Request -------------->|
+ |<----- PV Response (Cost Map Part) -----|
+ |<--- PV Response (Property Map Part) ---|
+
+ Figure 9: The Path Vector Extension Request and Response
+
+ This design is based on the following considerations:
+
+ 1. ANEs may be constructed on demand and, potentially, based on the
+ requested properties (see Section 5.1 for more details). If
+ sources and destinations are not in the same request as the
+ properties, an ALTO server either cannot construct ANEs on demand
+ or must wait until both requests are received.
+
+ 2. As ANEs may be constructed on demand, mappings of each ANE to its
+ underlying network devices and resources can be specific to the
+ request. In order to respond to the property map request
+ correctly, an ALTO server must store the mapping of each Path
+ Vector request until the client fully retrieves the property
+ information. This "stateful" behavior may substantially harm
+ server scalability and potentially lead to denial-of-service
+ attacks.
+
+ One approach for realizing the one-round communication is to define a
+ new media type to contain both objects, but this violates modular
+ design. This document follows the standard-conforming usage of the
+ "multipart/related" media type as defined in [RFC2387] to elegantly
+ combine the objects. Path Vectors are encoded in an
+ InfoResourceCostMap data component or InfoResourceEndpointCostMap
+ data component, and the property map is encoded in an
+ InfoResourceProperties data component. They are encapsulated as
+ parts of a multipart message. This modular composition allows ALTO
+ servers and clients to reuse the data models of the existing
+ information resources. Specifically, this document addresses the
+ following practical issues using "multipart/related".
+
+5.3.1. Identifying the Media Type of the Object Root
+
+ ALTO uses a media type to indicate the type of an entry in the IRD
+ (e.g., "application/alto-costmap+json" for the cost map and
+ "application/alto-endpointcost+json" for the Endpoint Cost Service).
+ Simply using "multipart/related" as the media type, however, makes it
+ impossible for an ALTO client to identify the type of service
+ provided by related entries.
+
+ To address this issue, this document uses the "type" parameter to
+ indicate the object root of a multipart/related message. For a cost
+ map resource, the "media-type" field in the IRD entry is "multipart/
+ related" with the parameter "type=application/alto-costmap+json"; for
+ an Endpoint Cost Service, the parameter is "type=application/alto-
+ endpointcost+json".
+
+5.3.2. References to Part Messages
+
+ As the response of a Path Vector resource is a multipart message with
+ two different parts, it is important that each part can be uniquely
+ identified. Following the design provided in [RFC8895], this
+ extension requires that an ALTO server assign a unique identifier to
+ each part of the multipart response message. This identifier,
+ referred to as a Part Resource ID (see Section 6.6 for details), is
+ present in the part message's "Content-ID" header field. By
+ concatenating the Part Resource ID to the identifier of the Path
+ Vector request, an ALTO server/client can uniquely identify the Path
+ Vector part or the property map part.
+
+6. Specification: Basic Data Types
+
+6.1. ANE Name
+
+ An ANE name is encoded as a JSON string with the same format as that
+ of the type PIDName (Section 10.1 of [RFC7285]).
+
+ The type ANEName is used in this document to indicate a string of
+ this format.
+
+6.2. ANE Entity Domain
+
+ The ANE entity domain associates property values with the ANEs in a
+ property map. Accordingly, the ANE entity domain always depends on a
+ property map.
+
+ It must be noted that the term "domain" here does not refer to a
+ network domain. Rather, it is inherited from the entity domain as
+ defined in Section 3.2 of [RFC9240]; the entity domain represents the
+ set of valid entities defined by an ALTO information resource (called
+ the "defining information resource").
+
+6.2.1. Entity Domain Type
+
+ The entity domain type is "ane".
+
+6.2.2. Domain-Specific Entity Identifier
+
+ The entity identifiers are the ANE names in the associated property
+ map.
+
+6.2.3. Hierarchy and Inheritance
+
+ There is no hierarchy or inheritance for properties associated with
+ ANEs.
+
+6.2.4. Media Type of Defining Resource
+
+ The defining resource for entity domain type "ane" MUST be a property
+ map, i.e., the media type of defining resources is:
+
+ application/alto-propmap+json
+
+ Specifically, for ephemeral ANEs that appear in a Path Vector
+ response, their entity domain names MUST be exactly ".ane", and the
+ defining resource of these ANEs is the property map part of the
+ multipart response. Meanwhile, for any persistent ANE whose defining
+ resource is a property map resource, its entity domain name MUST have
+ the format of "PROPMAP.ane", where PROPMAP is the resource ID of the
+ defining resource. Persistent entities are "persistent" because
+ standalone queries can be made by an ALTO client to their defining
+ resource(s) when the connection to the Path Vector service is closed.
+
+ For example, the defining resource of an ephemeral ANE whose entity
+ identifier is ".ane:NET1" is the property map part that contains this
+ identifier. The defining resource of a persistent ANE whose entity
+ identifier is "dc-props.ane:DC1" is the property map with the
+ resource ID "dc-props".
+
+6.3. ANE Property Name
+
+ An ANE property name is encoded as a JSON string with the same format
+ as that of an entity property name (Section 5.2.2 of [RFC9240]).
+
+6.4. Initial ANE Property Types
+
+ Two initial ANE property types are specified: "max-reservable-
+ bandwidth" and "persistent-entity-id".
+
+ Note that these property types do not depend on any information
+ resources. As such, the "EntityPropertyName" parameter MUST only
+ have the EntityPropertyType part.
+
+6.4.1. Maximum Reservable Bandwidth
+
+ The maximum reservable bandwidth property ("max-reservable-
+ bandwidth") stands for the maximum bandwidth that can be reserved for
+ all the traffic that traverses an ANE. The value MUST be encoded as
+ a non-negative numerical cost value as defined in Section 6.1.2.1 of
+ [RFC7285], and the unit is bits per second (bps). If this property
+ is requested by the ALTO client but is not present for an ANE in the
+ server response, it MUST be interpreted as meaning that the property
+ is not defined for the ANE.
+
+ This property can be offered in a setting where the ALTO server is
+ part of a network system that provides on-demand resource allocation
+ and the ALTO client is part of a user application. One existing
+ example is [NOVA]: the ALTO server is part of a Software-Defined
+ Networking (SDN) controller and exposes a list of traversed network
+ elements and associated link bandwidth to the client. The encoding
+ in [NOVA] differs from the Path Vector response defined in this
+ document in that the Path Vector part and property map part are
+ placed in the same JSON object.
+
+ In such a framework, the ALTO server exposes resource availability
+ information (e.g., reservable bandwidth) to the ALTO client. How the
+ client makes resource requests based on the information, and how the
+ resource allocation is achieved, respectively, depend on interfaces
+ between the management system and the users or a higher-layer
+ protocol (e.g., SDN network intents [INTENT-BASED-NETWORKING] or MPLS
+ tunnels), which are out of scope for this document.
+
+6.4.2. Persistent Entity ID
+
+ This document enables the discovery of a persistent ANE by exposing
+ its entity identifier as the persistent entity ID property of an
+ ephemeral ANE in the path vector response. The value of this
+ property is encoded with the EntityID format defined in Section 5.1.3
+ of [RFC9240].
+
+ In this format, the entity ID combines:
+
+ * a defining information resource for the ANE on which a
+ "persistent-entity-id" is queried, which is the property map
+ resource defining the ANE as a persistent entity, together with
+ the properties.
+
+ * the persistent name of the ANE in that property map.
+
+ With this format, the client has all the needed information for
+ further standalone query properties on the persistent ANE.
+
+6.4.3. Examples
+
+ To illustrate the use of "max-reservable-bandwidth", consider the
+ following network with five nodes. Assume that the client wants to
+ query the maximum reservable bandwidth from H1 to H2. An ALTO server
+ may split the network into two ANEs: "ane1", which represents the
+ subnetwork with routers A, B, and C; and "ane2", which represents the
+ subnetwork with routers B, D, and E. The maximum reservable
+ bandwidth for "ane1" is 15 Mbps (using path A->C->B), and the maximum
+ reservable bandwidth for "ane2" is 20 Mbps (using path B->D->E).
+
+ 20 Mbps 20 Mbps
+ 10 Mbps +---+ +---+ +---+
+ /----| B |---| D |----| E |---- H2
+ +---+/ +---+ +---+ +---+
+ H1 ----| A | 15 Mbps|
+ +---+\ +---+
+ \----| C |
+ 15 Mbps +---+
+
+ To illustrate the use of "persistent-entity-id", consider the
+ scenario in Figure 6. As the life cycles of service edges are
+ typically long, the service edges may contain information that is not
+ specific to the query. Such information can be stored in an
+ individual entity property map and can later be accessed by an ALTO
+ client.
+
+ For example, "ane1" in Figure 7 represents the on-premise service
+ edge closest to host "a". Assume that the properties of the service
+ edges are provided in an entity property map called "se-props" and
+ the ID of the on-premise service edge is "9a0b55f7-7442-4d56-8a2c-
+ b4cc6a8e3aa1"; the "persistent-entity-id" setting for "ane1" will be
+ "se-props.ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1". With this
+ persistent entity ID, an ALTO client may send queries to the "se-
+ props" resource with the entity ID ".ane:9a0b55f7-7442-4d56-8a2c-
+ b4cc6a8e3aa1".
+
+6.5. Path Vector Cost Type
+
+ This document defines a new cost type, which is referred to as the
+ Path Vector cost type. An ALTO server MUST offer this cost type if
+ it supports the extension defined in this document.
+
+6.5.1. Cost Metric: "ane-path"
+
+ The cost metric "ane-path" indicates that the value of such a cost
+ type conveys an array of ANE names, where each ANE name uniquely
+ represents an ANE traversed by traffic from a source to a
+ destination.
+
+ An ALTO client MUST interpret the Path Vector as if the traffic
+ between a source and a destination logically traverses the ANEs in
+ the same order as they appear in the Path Vector.
+
+ When the Path Vector procedures defined in this document are in use,
+ an ALTO server using the "ane-path" cost metric and the "array" cost
+ mode (see Section 6.5.2) MUST return as the cost value a JSON array
+ of data type ANEName, and the client MUST also check that each
+ element contained in the array is an ANEName (Section 6.1).
+ Otherwise, the client MUST discard the response and SHOULD follow the
+ guidance in Section 8.3.4.3 of [RFC7285] to handle the error.
+
+6.5.2. Cost Mode: "array"
+
+ The cost mode "array" indicates that every cost value in the response
+ body of a (filtered) cost map or an Endpoint Cost Service MUST be
+ interpreted as a JSON array object. While this cost mode can be
+ applied to all cost metrics, additional specifications will be needed
+ to clarify the semantics of the "array" cost mode when combined with
+ cost metrics other than "ane-path".
+
+6.6. Part Resource ID and Part Content ID
+
+ A Part Resource ID is encoded as a JSON string with the same format
+ as that of the type ResourceID (Section 10.2 of [RFC7285]).
+
+ Even though the "client-id" assigned to a Path Vector request and the
+ Part Resource ID MAY contain up to 64 characters by their own
+ definition, their concatenation (see Section 5.3.2) MUST also conform
+ to the same length constraint. The same requirement applies to the
+ resource ID of the Path Vector resource, too. Thus, it is
+ RECOMMENDED to limit the length of the resource ID and client ID
+ related to a Path Vector resource to 31 characters.
+
+ A Part Content ID conforms to the format of "msg-id" as specified in
+ [RFC2387] and [RFC5322]. Specifically, it has the following format:
+
+ "<" PART-RESOURCE-ID "@" DOMAIN-NAME ">"
+
+ PART-RESOURCE-ID: PART-RESOURCE-ID has the same format as the Part
+ Resource ID. It is used to identify whether a part message is a
+ Path Vector or a property map.
+
+ DOMAIN-NAME: DOMAIN-NAME has the same format as "dot-atom-text" as
+ specified in Section 3.2.3 of [RFC5322]. It must be the domain
+ name of the ALTO server.
+
+7. Specification: Service Extensions
+
+7.1. Notation
+
+ This document uses the same syntax and notation as those introduced
+ in Section 8.2 of [RFC7285] to specify the extensions to existing
+ ALTO resources and services.
+
+7.2. Multipart Filtered Cost Map for Path Vector
+
+ This document introduces a new ALTO resource called the "multipart
+ filtered cost map resource", which allows an ALTO server to provide
+ other ALTO resources associated with the cost map resource in the
+ same response.
+
+7.2.1. Media Type
+
+ The media type of the multipart filtered cost map resource is
+ "multipart/related", and the required "type" parameter MUST have a
+ value of "application/alto-costmap+json".
+
+7.2.2. HTTP Method
+
+ The multipart filtered cost map is requested using the HTTP POST
+ method.
+
+7.2.3. Accept Input Parameters
+
+ The input parameters of the multipart filtered cost map are supplied
+ in the body of an HTTP POST request. This document extends the input
+ parameters to a filtered cost map, which is defined as a JSON object
+ of type ReqFilteredCostMap in Section 4.1.2 of [RFC8189], with a data
+ format indicated by the media type "application/alto-
+ costmapfilter+json", which is a JSON object of type
+ PVReqFilteredCostMap:
+
+ object {
+ [EntityPropertyName ane-property-names<0..*>;]
+ } PVReqFilteredCostMap : ReqFilteredCostMap;
+
+ with field:
+
+ ane-property-names: This field provides a list of selected ANE
+ properties to be included in the response. Each property in this
+ list MUST match one of the supported ANE properties indicated in
+ the resource's "ane-property-names" capability (Section 7.2.4).
+ If the field is not present, it MUST be interpreted as an empty
+ list.
+
+ Example: Consider the network in Figure 1. If an ALTO client wants
+ to query the "max-reservable-bandwidth" setting between PID1 and
+ PID2, it can submit the following request.
+
+ POST /costmap/pv HTTP/1.1
+ Host: alto.example.com
+ Accept: multipart/related;type=application/alto-costmap+json,
+ application/alto-error+json
+ Content-Length: 212
+ Content-Type: application/alto-costmapfilter+json
+
+ {
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ },
+ "pids": {
+ "srcs": [ "PID1" ],
+ "dsts": [ "PID2" ]
+ },
+ "ane-property-names": [ "max-reservable-bandwidth" ]
+ }
+
+7.2.4. Capabilities
+
+ The multipart filtered cost map resource extends the capabilities
+ defined in Section 4.1.1 of [RFC8189]. The capabilities are defined
+ by a JSON object of type PVFilteredCostMapCapabilities:
+
+ object {
+ [EntityPropertyName ane-property-names<0..*>;]
+ } PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
+
+ with field:
+
+ ane-property-names: This field provides a list of ANE properties
+ that can be returned. If the field is not present, it MUST be
+ interpreted as an empty list, indicating that the ALTO server
+ cannot provide any ANE properties.
+
+ This extension also introduces additional restrictions for the
+ following fields:
+
+ cost-type-names: The "cost-type-names" field MUST include the Path
+ Vector cost type, unless explicitly documented by a future
+ extension. This also implies that the Path Vector cost type MUST
+ be defined in the "cost-types" of the IRD's "meta" field.
+
+ cost-constraints: If the "cost-type-names" field includes the Path
+ Vector cost type, the "cost-constraints" field MUST be either
+ "false" or not present, unless specifically instructed by a future
+ document.
+
+ testable-cost-type-names (Section 4.1.1 of [RFC8189]): If the "cost-
+ type-names" field includes the Path Vector cost type and the
+ "testable-cost-type-names" field is present, the Path Vector cost
+ type MUST NOT be included in the "testable-cost-type-names" field
+ unless specifically instructed by a future document.
+
+7.2.5. Uses
+
+ This member MUST include the resource ID of the network map based on
+ which the PIDs are defined. If this resource supports "persistent-
+ entity-id", it MUST also include the defining resources of persistent
+ ANEs that may appear in the response.
+
+7.2.6. Response
+
+ The response MUST indicate an error, using ALTO Protocol error
+ handling as defined in Section 8.5 of [RFC7285], if the request is
+ invalid.
+
+ The "Content-Type" header field of the response MUST be "multipart/
+ related" as defined by [RFC2387], with the following parameters:
+
+ type: The "type" parameter is mandatory and MUST be "application/
+ alto-costmap+json". Note that [RFC2387] permits parameters both
+ with and without double quotes.
+
+ start: The "start" parameter is as defined in [RFC2387] and is
+ optional. If present, it MUST have the same value as the
+ "Content-ID" header field of the Path Vector part.
+
+ boundary: The "boundary" parameter is as defined in Section 5.1.1 of
+ [RFC2046] and is mandatory.
+
+ The body of the response MUST consist of two parts:
+
+ * The Path Vector part MUST include "Content-ID" and "Content-Type"
+ in its header. The "Content-Type" MUST be "application/alto-
+ costmap+json". The value of "Content-ID" MUST have the same
+ format as the Part Content ID as specified in Section 6.6.
+
+ The body of the Path Vector part MUST be a JSON object with the
+ same format as that defined in Section 11.2.3.6 of [RFC7285] when
+ the "cost-type" field is present in the input parameters and MUST
+ be a JSON object with the same format as that defined in
+ Section 4.1.3 of [RFC8189] if the "multi-cost-types" field is
+ present. The JSON object MUST include the "vtag" field in the
+ "meta" field, which provides the version tag of the returned
+ CostMapData object. The resource ID of the version tag MUST
+ follow the format of
+
+ resource-id '.' part-resource-id
+
+ where "resource-id" is the resource ID of the Path Vector resource
+ and "part-resource-id" has the same value as the PART-RESOURCE-ID
+ in the "Content-ID" of the Path Vector part. The "meta" field
+ MUST also include the "dependent-vtags" field, whose value is a
+ single-element array to indicate the version tag of the network
+ map used, where the network map is specified in the "uses"
+ attribute of the multipart filtered cost map resource in the IRD.
+
+ * The entity property map part MUST also include "Content-ID" and
+ "Content-Type" in its header. The "Content-Type" MUST be
+ "application/alto-propmap+json". The value of "Content-ID" MUST
+ have the same format as the Part Content ID as specified in
+ Section 6.6.
+
+ The body of the entity property map part is a JSON object with the
+ same format as that defined in Section 7.6 of [RFC9240]. The JSON
+ object MUST include the "dependent-vtags" field in the "meta"
+ field. The value of the "dependent-vtags" field MUST be an array
+ of VersionTag objects as defined by Section 10.3 of [RFC7285].
+ The "vtag" of the Path Vector part MUST be included in the
+ "dependent-vtags" field. If "persistent-entity-id" is requested,
+ the version tags of the dependent resources that may expose the
+ entities in the response MUST also be included.
+
+ The PropertyMapData object has one member for each ANEName that
+ appears in the Path Vector part, which is an entity identifier
+ belonging to the self-defined entity domain as defined in
+ Section 5.1.2.3 of [RFC9240]. The EntityProps object for each ANE
+ has one member for each property that is both 1) associated with
+ the ANE and 2) specified in the "ane-property-names" field in the
+ request. If the Path Vector cost type is not included in the
+ "cost-type" field or the "multi-cost-type" field, the "property-
+ map" field MUST be present and the value MUST be an empty object
+ ({}).
+
+ A complete and valid response MUST include both the Path Vector part
+ and the property map part in the multipart message. If any part is
+ *not* present, the client MUST discard the received information and
+ send another request if necessary.
+
+ The Path Vector part, whose media type is the same as the "type"
+ parameter of the multipart response message, is the root body part as
+ defined in [RFC2387]. Thus, it is the element that the application
+ processes first. Even though the "start" parameter allows it to be
+ placed anywhere in the part sequence, it is RECOMMENDED that the
+ parts arrive in the same order as they are processed, i.e., the Path
+ Vector part is always placed as the first part, followed by the
+ property map part. When doing so, an ALTO server MAY choose not to
+ set the "start" parameter, which implies that the first part is the
+ object root.
+
+ Example: Consider the network in Figure 1. The response to the
+ example request in Section 7.2.3 is as follows, where "ANE1"
+ represents the aggregation of all the switches in the network.
+
+ HTTP/1.1 200 OK
+ Content-Length: 911
+ Content-Type: multipart/related; boundary=example-1;
+ type=application/alto-costmap+json
+
+ --example-1
+ Content-ID: <costmap@alto.example.com>
+ Content-Type: application/alto-costmap+json
+
+ {
+ "meta": {
+ "vtag": {
+ "resource-id": "filtered-cost-map-pv.costmap",
+ "tag": "fb20b76204814e9db37a51151faaaef2"
+ },
+ "dependent-vtags": [
+ {
+ "resource-id": "my-default-networkmap",
+ "tag": "75ed013b3cb58f896e839582504f6228"
+ }
+ ],
+ "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
+ },
+ "cost-map": {
+ "PID1": { "PID2": [ "ANE1" ] }
+ }
+ }
+ --example-1
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "filtered-cost-map-pv.costmap",
+ "tag": "fb20b76204814e9db37a51151faaaef2"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
+ }
+ }
+ --example-1
+
+7.3. Multipart Endpoint Cost Service for Path Vector
+
+ This document introduces a new ALTO resource called the "multipart
+ Endpoint Cost Service", which allows an ALTO server to provide other
+ ALTO resources associated with the Endpoint Cost Service resource in
+ the same response.
+
+7.3.1. Media Type
+
+ The media type of the multipart Endpoint Cost Service resource is
+ "multipart/related", and the required "type" parameter MUST have a
+ value of "application/alto-endpointcost+json".
+
+7.3.2. HTTP Method
+
+ The multipart Endpoint Cost Service resource is requested using the
+ HTTP POST method.
+
+7.3.3. Accept Input Parameters
+
+ The input parameters of the multipart Endpoint Cost Service resource
+ are supplied in the body of an HTTP POST request. This document
+ extends the input parameters to an Endpoint Cost Service, which is
+ defined as a JSON object of type ReqEndpointCostMap in Section 4.2.2
+ of [RFC8189], with a data format indicated by the media type
+ "application/alto-endpointcostparams+json", which is a JSON object of
+ type PVReqEndpointCostMap:
+
+ object {
+ [EntityPropertyName ane-property-names<0..*>;]
+ } PVReqEndpointCostMap : ReqEndpointCostMap;
+
+ with field:
+
+ ane-property-names: This document defines the "ane-property-names"
+ field in PVReqEndpointCostMap as being the same as in
+ PVReqFilteredCostMap. See Section 7.2.3.
+
+ Example: Consider the network in Figure 1. If an ALTO client wants
+ to query the "max-reservable-bandwidth" setting between "eh1" and
+ "eh2", it can submit the following request.
+
+ POST /ecs/pv HTTP/1.1
+ Host: alto.example.com
+ Accept: multipart/related;type=application/alto-endpointcost+json,
+ application/alto-error+json
+ Content-Length: 238
+ Content-Type: application/alto-endpointcostparams+json
+
+ {
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ },
+ "endpoints": {
+ "srcs": [ "ipv4:192.0.2.2" ],
+ "dsts": [ "ipv4:192.0.2.18" ]
+ },
+ "ane-property-names": [ "max-reservable-bandwidth" ]
+ }
+
+7.3.4. Capabilities
+
+ The capabilities of the multipart Endpoint Cost Service resource are
+ defined by a JSON object of type PVEndpointCostCapabilities, which is
+ defined as being the same as PVFilteredCostMapCapabilities. See
+ Section 7.2.4.
+
+7.3.5. Uses
+
+ If this resource supports "persistent-entity-id", it MUST also
+ include the defining resources of persistent ANEs that may appear in
+ the response.
+
+7.3.6. Response
+
+ The response MUST indicate an error, using ALTO Protocol error
+ handling as defined in Section 8.5 of [RFC7285], if the request is
+ invalid.
+
+ The "Content-Type" header field of the response MUST be "multipart/
+ related" as defined by [RFC2387], with the following parameters:
+
+ type: The "type" parameter MUST be "application/alto-
+ endpointcost+json" and is mandatory.
+
+ start: The "start" parameter is as defined in Section 7.2.6.
+
+ boundary: The "boundary" parameter is as defined in Section 5.1.1 of
+ [RFC2046] and is mandatory.
+
+ The body of the response MUST consist of two parts:
+
+ * The Path Vector part MUST include "Content-ID" and "Content-Type"
+ in its header. The "Content-Type" MUST be "application/alto-
+ endpointcost+json". The value of "Content-ID" MUST have the same
+ format as the Part Content ID as specified in Section 6.6.
+
+ The body of the Path Vector part MUST be a JSON object with the
+ same format as that defined in Section 11.5.1.6 of [RFC7285] when
+ the "cost-type" field is present in the input parameters and MUST
+ be a JSON object with the same format as that defined in
+ Section 4.2.3 of [RFC8189] if the "multi-cost-types" field is
+ present. The JSON object MUST include the "vtag" field in the
+ "meta" field, which provides the version tag of the returned
+ EndpointCostMapData object. The resource ID of the version tag
+ MUST follow the format of
+
+ resource-id '.' part-resource-id
+
+ where "resource-id" is the resource ID of the Path Vector resource
+ and "part-resource-id" has the same value as the PART-RESOURCE-ID
+ in the "Content-ID" of the Path Vector part.
+
+ * The entity property map part MUST also include "Content-ID" and
+ "Content-Type" in its header. The "Content-Type" MUST be
+ "application/alto-propmap+json". The value of "Content-ID" MUST
+ have the same format as the Part Content ID as specified in
+ Section 6.6.
+
+ The body of the entity property map part MUST be a JSON object
+ with the same format as that defined in Section 7.6 of [RFC9240].
+ The JSON object MUST include the "dependent-vtags" field in the
+ "meta" field. The value of the "dependent-vtags" field MUST be an
+ array of VersionTag objects as defined by Section 10.3 of
+ [RFC7285]. The "vtag" of the Path Vector part MUST be included in
+ the "dependent-vtags" field. If "persistent-entity-id" is
+ requested, the version tags of the dependent resources that may
+ expose the entities in the response MUST also be included.
+
+ The PropertyMapData object has one member for each ANEName that
+ appears in the Path Vector part, which is an entity identifier
+ belonging to the self-defined entity domain as defined in
+ Section 5.1.2.3 of [RFC9240]. The EntityProps object for each ANE
+ has one member for each property that is both 1) associated with
+ the ANE and 2) specified in the "ane-property-names" field in the
+ request. If the Path Vector cost type is not included in the
+ "cost-type" field or the "multi-cost-type" field, the "property-
+ map" field MUST be present and the value MUST be an empty object
+ ({}).
+
+ A complete and valid response MUST include both the Path Vector part
+ and the property map part in the multipart message. If any part is
+ *not* present, the client MUST discard the received information and
+ send another request if necessary.
+
+ The Path Vector part, whose media type is the same as the "type"
+ parameter of the multipart response message, is the root body part as
+ defined in [RFC2387]. Thus, it is the element that the application
+ processes first. Even though the "start" parameter allows it to be
+ placed anywhere in the part sequence, it is RECOMMENDED that the
+ parts arrive in the same order as they are processed, i.e., the Path
+ Vector part is always placed as the first part, followed by the
+ property map part. When doing so, an ALTO server MAY choose not to
+ set the "start" parameter, which implies that the first part is the
+ object root.
+
+ Example: Consider the network in Figure 1. The response to the
+ example request in Section 7.3.3 is as follows.
+
+ HTTP/1.1 200 OK
+ Content-Length: 899
+ Content-Type: multipart/related; boundary=example-1;
+ type=application/alto-endpointcost+json
+
+ --example-1
+ Content-ID: <ecs@alto.example.com>
+ Content-Type: application/alto-endpointcost+json
+
+ {
+ "meta": {
+ "vtag": {
+ "resource-id": "ecs-pv.ecs",
+ "tag": "ec137bb78118468c853d5b622ac003f1"
+ },
+ "dependent-vtags": [
+ {
+ "resource-id": "my-default-networkmap",
+ "tag": "677fe5f4066848d282ece213a84f9429"
+ }
+ ],
+ "cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
+ },
+ "cost-map": {
+ "ipv4:192.0.2.2": { "ipv4:192.0.2.18": [ "ANE1" ] }
+ }
+ }
+ --example-1
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "ecs-pv.ecs",
+ "tag": "ec137bb78118468c853d5b622ac003f1"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
+ }
+ }
+ --example-1
+
+8. Examples
+
+ This section lists some examples of Path Vector queries and the
+ corresponding responses. Some long lines are truncated for better
+ readability.
+
+8.1. Sample Setup
+
+ Figure 10 illustrates the network properties and thus the message
+ contents. There are three subnetworks (NET1, NET2, and NET3) and two
+ interconnection links (L1 and L2). It is assumed that each
+ subnetwork has sufficiently large bandwidth to be reserved.
+
+ ----- L1
+ /
+ PID1 +----------+ 10 Gbps +----------+ PID3
+ 192.0.2.0/28+-+ +------+ +---------+ +--+192.0.2.32/28
+ | | MEC1 | | | | 2001:db8::3:0/16
+ | +------+ | +-----+ |
+ PID2 | | | +----------+
+ 192.0.2.16/28+-+ | | NET3
+ | | | 15 Gbps
+ | | | \
+ +----------+ | -------- L2
+ NET1 |
+ +----------+
+ | +------+ | PID4
+ | | MEC2 | +--+192.0.2.48/28
+ | +------+ | 2001:db8::4:0/16
+ +----------+
+ NET2
+
+ Figure 10: Examples of ANE Properties
+
+8.2. Information Resource Directory
+
+ To give a comprehensive example of the extension defined in this
+ document, we consider the network in Figure 10. Assume that the ALTO
+ server provides the following information resources:
+
+ "my-default-networkmap": A network map resource that contains the
+ PIDs in the network.
+
+ "filtered-cost-map-pv": A multipart filtered cost map resource for
+ the Path Vector. Exposes the "max-reservable-bandwidth" property
+ for the PIDs in "my-default-networkmap".
+
+ "ane-props": A filtered entity property resource that exposes the
+ information for persistent ANEs in the network.
+
+ "endpoint-cost-pv": A multipart Endpoint Cost Service for the Path
+ Vector. Exposes the "max-reservable-bandwidth" and "persistent-
+ entity-id" properties.
+
+ "update-pv": An update stream service that provides the incremental
+ update service for the "endpoint-cost-pv" service.
+
+ "multicost-pv": A multipart Endpoint Cost Service with both the
+ Multi-Cost extension and Path Vector extension enabled.
+
+ Below is the IRD of the example ALTO server. To enable the extension
+ defined in this document, the Path Vector cost type (Section 6.5),
+ represented by "path-vector" below, is defined in the "cost-types" of
+ the "meta" field and is included in the "cost-type-names" of
+ resources "filtered-cost-map-pv" and "endpoint-cost-pv".
+
+ {
+ "meta": {
+ "cost-types": {
+ "path-vector": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ },
+ "num-rc": {
+ "cost-mode": "numerical",
+ "cost-metric": "routingcost"
+ }
+ }
+ },
+ "resources": {
+ "my-default-networkmap": {
+ "uri": "https://alto.example.com/networkmap",
+ "media-type": "application/alto-networkmap+json"
+ },
+ "filtered-cost-map-pv": {
+ "uri": "https://alto.example.com/costmap/pv",
+ "media-type": "multipart/related;
+ type=application/alto-costmap+json",
+ "accepts": "application/alto-costmapfilter+json",
+ "capabilities": {
+ "cost-type-names": [ "path-vector" ],
+ "ane-property-names": [ "max-reservable-bandwidth" ]
+ },
+ "uses": [ "my-default-networkmap" ]
+ },
+ "ane-props": {
+ "uri": "https://alto.example.com/ane-props",
+ "media-type": "application/alto-propmap+json",
+ "accepts": "application/alto-propmapparams+json",
+ "capabilities": {
+ "mappings": {
+ ".ane": [ "cpu" ]
+ }
+ }
+ },
+ "endpoint-cost-pv": {
+ "uri": "https://alto.exmaple.com/endpointcost/pv",
+ "media-type": "multipart/related;
+ type=application/alto-endpointcost+json",
+ "accepts": "application/alto-endpointcostparams+json",
+ "capabilities": {
+ "cost-type-names": [ "path-vector" ],
+ "ane-property-names": [
+ "max-reservable-bandwidth", "persistent-entity-id"
+ ]
+ },
+ "uses": [ "ane-props" ]
+ },
+ "update-pv": {
+ "uri": "https://alto.example.com/updates/pv",
+ "media-type": "text/event-stream",
+ "uses": [ "endpoint-cost-pv" ],
+ "accepts": "application/alto-updatestreamparams+json",
+ "capabilities": {
+ "support-stream-control": true
+ }
+ },
+ "multicost-pv": {
+ "uri": "https://alto.exmaple.com/endpointcost/mcpv",
+ "media-type": "multipart/related;
+ type=application/alto-endpointcost+json",
+ "accepts": "application/alto-endpointcostparams+json",
+ "capabilities": {
+ "cost-type-names": [ "path-vector", "num-rc" ],
+ "max-cost-types": 2,
+ "testable-cost-type-names": [ "num-rc" ],
+ "ane-property-names": [
+ "max-reservable-bandwidth", "persistent-entity-id"
+ ]
+ },
+ "uses": [ "ane-props" ]
+ }
+ }
+ }
+
+8.3. Multipart Filtered Cost Map
+
+ The following examples demonstrate the request to the "filtered-cost-
+ map-pv" resource and the corresponding response.
+
+ The request uses the "path-vector" cost type in the "cost-type"
+ field. The "ane-property-names" field is missing, indicating that
+ the client only requests the Path Vector and not the ANE properties.
+
+ The response consists of two parts:
+
+ * The first part returns the array of data type ANEName for each
+ source and destination pair. There are two ANEs, where "L1"
+ represents interconnection link L1 and "L2" represents
+ interconnection link L2.
+
+ * The second part returns the property map. Note that the
+ properties of the ANE entries are equal to the literal string "{}"
+ (see Section 8.3 of [RFC9240]).
+
+ POST /costmap/pv HTTP/1.1
+ Host: alto.example.com
+ Accept: multipart/related;type=application/alto-costmap+json,
+ application/alto-error+json
+ Content-Length: 163
+ Content-Type: application/alto-costmapfilter+json
+
+ {
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ },
+ "pids": {
+ "srcs": [ "PID1" ],
+ "dsts": [ "PID3", "PID4" ]
+ }
+ }
+
+ HTTP/1.1 200 OK
+ Content-Length: 952
+ Content-Type: multipart/related; boundary=example-1;
+ type=application/alto-costmap+json
+
+ --example-1
+ Content-ID: <costmap@alto.example.com>
+ Content-Type: application/alto-costmap+json
+
+ {
+ "meta": {
+ "vtag": {
+ "resource-id": "filtered-cost-map-pv.costmap",
+ "tag": "d827f484cb66ce6df6b5077cb8562b0a"
+ },
+ "dependent-vtags": [
+ {
+ "resource-id": "my-default-networkmap",
+ "tag": "c04bc5da49534274a6daeee8ea1dec62"
+ }
+ ],
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ }
+ },
+ "cost-map": {
+ "PID1": {
+ "PID3": [ "L1" ],
+ "PID4": [ "L1", "L2" ]
+ }
+ }
+ }
+ --example-1
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "filtered-cost-map-pv.costmap",
+ "tag": "d827f484cb66ce6df6b5077cb8562b0a"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:L1": {},
+ ".ane:L2": {}
+ }
+ }
+ --example-1
+
+8.4. Multipart Endpoint Cost Service Resource
+
+ The following examples demonstrate the request to the "endpoint-cost-
+ pv" resource and the corresponding response.
+
+ The request uses the "path-vector" cost type in the "cost-type" field
+ and queries the maximum reservable bandwidth ANE property and the
+ persistent entity ID property for two IPv4 source and destination
+ pairs (192.0.2.34 -> 192.0.2.2 and 192.0.2.34 -> 192.0.2.50) and one
+ IPv6 source and destination pair (2001:db8::3:1 -> 2001:db8::4:1).
+
+ The response consists of two parts:
+
+ * The first part returns the array of data type ANEName for each
+ valid source and destination pair. As one can see in Figure 10,
+ flow 192.0.2.34 -> 192.0.2.2 traverses NET3, L1, and NET1; and
+ flows 192.0.2.34 -> 192.0.2.50 and 2001:db8::3:1 -> 2001:db8::4:1
+ traverse NET2, L2, and NET3.
+
+ * The second part returns the requested properties of ANEs. Assume
+ that NET1, NET2, and NET3 have sufficient bandwidth and their
+ "max-reservable-bandwidth" values are set to a sufficiently large
+ number (50 Gbps in this case). On the other hand, assume that
+ there are no prior reservations on L1 and L2 and their "max-
+ reservable-bandwidth" values are the corresponding link capacity
+ (10 Gbps for L1 and 15 Gbps for L2).
+
+ Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1
+ and MEC2 in NET2. Assume that the ANEName values for MEC1 and MEC2
+ are "MEC1" and "MEC2" and their properties can be retrieved from the
+ property map "ane-props". Thus, the "persistent-entity-id" property
+ values for NET1 and NET2 are "ane-props.ane:MEC1" and "ane-
+ props.ane:MEC2", respectively.
+
+ POST /endpointcost/pv HTTP/1.1
+ Host: alto.example.com
+ Accept: multipart/related;
+ type=application/alto-endpointcost+json,
+ application/alto-error+json
+ Content-Length: 383
+ Content-Type: application/alto-endpointcostparams+json
+
+ {
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ },
+ "endpoints": {
+ "srcs": [
+ "ipv4:192.0.2.34",
+ "ipv6:2001:db8::3:1"
+ ],
+ "dsts": [
+ "ipv4:192.0.2.2",
+ "ipv4:192.0.2.50",
+ "ipv6:2001:db8::4:1"
+ ]
+ },
+ "ane-property-names": [
+ "max-reservable-bandwidth",
+ "persistent-entity-id"
+ ]
+ }
+
+ HTTP/1.1 200 OK
+ Content-Length: 1508
+ Content-Type: multipart/related; boundary=example-2;
+ type=application/alto-endpointcost+json
+
+ --example-2
+ Content-ID: <ecs@alto.example.com>
+ Content-Type: application/alto-endpointcost+json
+
+ {
+ "meta": {
+ "vtags": {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
+ },
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ }
+ },
+ "endpoint-cost-map": {
+ "ipv4:192.0.2.34": {
+ "ipv4:192.0.2.2": [ "NET3", "L1", "NET1" ],
+ "ipv4:192.0.2.50": [ "NET3", "L2", "NET2" ]
+ },
+ "ipv6:2001:db8::3:1": {
+ "ipv6:2001:db8::4:1": [ "NET3", "L2", "NET2" ]
+ }
+ }
+ }
+ --example-2
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
+ },
+ {
+ "resource-id": "ane-props",
+ "tag": "bf3c8c1819d2421c9a95a9d02af557a3"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:NET1": {
+ "max-reservable-bandwidth": 50000000000,
+ "persistent-entity-id": "ane-props.ane:MEC1"
+ },
+ ".ane:NET2": {
+ "max-reservable-bandwidth": 50000000000,
+ "persistent-entity-id": "ane-props.ane:MEC2"
+ },
+ ".ane:NET3": {
+ "max-reservable-bandwidth": 50000000000
+ },
+ ".ane:L1": {
+ "max-reservable-bandwidth": 10000000000
+ },
+ ".ane:L2": {
+ "max-reservable-bandwidth": 15000000000
+ }
+ }
+ }
+ --example-2
+
+ In certain scenarios where the traversal order is not crucial, an
+ ALTO server implementation may choose not to strictly follow the
+ physical traversal order and may even obfuscate the order
+ intentionally to preserve its own privacy or conform to its own
+ policies. For example, an ALTO server may choose to aggregate NET1
+ and L1 as a new ANE with ANE name "AGGR1" and aggregate NET2 and L2
+ as a new ANE with ANE name "AGGR2". The "max-reservable-bandwidth"
+ property of "AGGR1" takes the value of L1, which is smaller than that
+ of NET1, and the "persistent-entity-id" property of "AGGR1" takes the
+ value of NET1. The properties of "AGGR2" are computed in a similar
+ way; the obfuscated response is as shown below. Note that the
+ obfuscation of Path Vector responses is implementation specific and
+ is out of scope for this document. Developers may refer to
+ Section 11 for further references.
+
+ HTTP/1.1 200 OK
+ Content-Length: 1333
+ Content-Type: multipart/related; boundary=example-2;
+ type=application/alto-endpointcost+json
+
+ --example-2
+ Content-ID: <ecs@alto.example.com>
+ Content-Type: application/alto-endpointcost+json
+
+ {
+ "meta": {
+ "vtags": {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "bb975862fbe3422abf4dae386b132c1d"
+ },
+ "cost-type": {
+ "cost-mode": "array",
+ "cost-metric": "ane-path"
+ }
+ },
+ "endpoint-cost-map": {
+ "ipv4:192.0.2.34": {
+ "ipv4:192.0.2.2": [ "NET3", "AGGR1" ],
+ "ipv4:192.0.2.50": [ "NET3", "AGGR2" ]
+ },
+ "ipv6:2001:db8::3:1": {
+ "ipv6:2001:db8::4:1": [ "NET3", "AGGR2" ]
+ }
+ }
+ }
+ --example-2
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "bb975862fbe3422abf4dae386b132c1d"
+ },
+ {
+ "resource-id": "ane-props",
+ "tag": "bf3c8c1819d2421c9a95a9d02af557a3"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:AGGR1": {
+ "max-reservable-bandwidth": 10000000000,
+ "persistent-entity-id": "ane-props.ane:MEC1"
+ },
+ ".ane:AGGR2": {
+ "max-reservable-bandwidth": 15000000000,
+ "persistent-entity-id": "ane-props.ane:MEC2"
+ },
+ ".ane:NET3": {
+ "max-reservable-bandwidth": 50000000000
+ }
+ }
+ }
+ --example-2
+
+8.5. Incremental Updates
+
+ In this example, an ALTO client subscribes to the incremental update
+ for the multipart Endpoint Cost Service resource "endpoint-cost-pv".
+
+ POST /updates/pv HTTP/1.1
+ Host: alto.example.com
+ Accept: text/event-stream
+ Content-Type: application/alto-updatestreamparams+json
+ Content-Length: 120
+
+ {
+ "add": {
+ "ecspvsub1": {
+ "resource-id": "endpoint-cost-pv",
+ "input": <ecs-input>
+ }
+ }
+ }
+
+ Based on the server-side process defined in [RFC8895], the ALTO
+ server will send the "control-uri" first, using a Server-Sent Event
+ (SSE) followed by the full response of the multipart message.
+
+ HTTP/1.1 200 OK
+ Connection: keep-alive
+ Content-Type: text/event-stream
+
+ event: application/alto-updatestreamcontrol+json
+ data: {"control-uri": "https://alto.example.com/updates/streams/123"}
+
+ event: multipart/related;boundary=example-3;
+ type=application/alto-endpointcost+json,ecspvsub1
+ data: --example-3
+ data: Content-ID: <ecsmap@alto.example.com>
+ data: Content-Type: application/alto-endpointcost+json
+ data:
+ data: <endpoint-cost-map-entry>
+ data: --example-3
+ data: Content-ID: <propmap@alto.example.com>
+ data: Content-Type: application/alto-propmap+json
+ data:
+ data: <property-map-entry>
+ data: --example-3--
+
+ When the contents change, the ALTO server will publish the updates
+ for each node in this tree separately, based on Section 6.7.3 of
+ [RFC8895].
+
+ event: application/merge-patch+json,
+ ecspvsub1.ecsmap@alto.example.com
+ data: <Merge patch for endpoint-cost-map-update>
+
+ event: application/merge-patch+json,
+ ecspvsub1.propmap@alto.example.com
+ data: <Merge patch for property-map-update>
+
+8.6. Multi-Cost
+
+ The following examples demonstrate the request to the "multicost-pv"
+ resource and the corresponding response.
+
+ The request asks for two cost types: the first is the Path Vector
+ cost type, and the second is a numerical routing cost. It also
+ queries the maximum reservable bandwidth ANE property and the
+ persistent entity ID property for two IPv4 source and destination
+ pairs (192.0.2.34 -> 192.0.2.2 and 192.0.2.34 -> 192.0.2.50) and one
+ IPv6 source and destination pair (2001:db8::3:1 -> 2001:db8::4:1).
+
+ The response consists of two parts:
+
+ * The first part returns a JSONArray that contains two JSONValue
+ entries for each requested source and destination pair: the first
+ JSONValue is a JSONArray of ANENames, which is the value of the
+ Path Vector cost type; and the second JSONValue is a JSONNumber,
+ which is the value of the routing cost.
+
+ * The second part contains a property map that maps the ANEs to
+ their requested properties.
+
+ POST /endpointcost/mcpv HTTP/1.1
+ Host: alto.example.com
+ Accept: multipart/related;
+ type=application/alto-endpointcost+json,
+ application/alto-error+json
+ Content-Length: 454
+ Content-Type: application/alto-endpointcostparams+json
+
+ {
+ "multi-cost-types": [
+ { "cost-mode": "array", "cost-metric": "ane-path" },
+ { "cost-mode": "numerical", "cost-metric": "routingcost" }
+ ],
+ "endpoints": {
+ "srcs": [
+ "ipv4:192.0.2.34",
+ "ipv6:2001:db8::3:1"
+ ],
+ "dsts": [
+ "ipv4:192.0.2.2",
+ "ipv4:192.0.2.50",
+ "ipv6:2001:db8::4:1"
+ ]
+ },
+ "ane-property-names": [
+ "max-reservable-bandwidth",
+ "persistent-entity-id"
+ ]
+ }
+
+ HTTP/1.1 200 OK
+ Content-Length: 1419
+ Content-Type: multipart/related; boundary=example-4;
+ type=application/alto-endpointcost+json
+
+ --example-4
+ Content-ID: <ecs@alto.example.com>
+ Content-Type: application/alto-endpointcost+json
+
+ {
+ "meta": {
+ "vtags": {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "84a4f9c14f9341f0983e3e5f43a371c8"
+ },
+ "multi-cost-types": [
+ { "cost-mode": "array", "cost-metric": "ane-path" },
+ { "cost-mode": "numerical", "cost-metric": "routingcost" }
+ ]
+ },
+ "endpoint-cost-map": {
+ "ipv4:192.0.2.34": {
+ "ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 3],
+ "ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 2]
+ },
+ "ipv6:2001:db8::3:1": {
+ "ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 2]
+ }
+ }
+ }
+ --example-4
+ Content-ID: <propmap@alto.example.com>
+ Content-Type: application/alto-propmap+json
+
+ {
+ "meta": {
+ "dependent-vtags": [
+ {
+ "resource-id": "endpoint-cost-pv.ecs",
+ "tag": "84a4f9c14f9341f0983e3e5f43a371c8"
+ },
+ {
+ "resource-id": "ane-props",
+ "tag": "be157afa031443a187b60bb80a86b233"
+ }
+ ]
+ },
+ "property-map": {
+ ".ane:AGGR1": {
+ "max-reservable-bandwidth": 10000000000,
+ "persistent-entity-id": "ane-props.ane:MEC1"
+ },
+ ".ane:AGGR2": {
+ "max-reservable-bandwidth": 15000000000,
+ "persistent-entity-id": "ane-props.ane:MEC2"
+ },
+ ".ane:NET3": {
+ "max-reservable-bandwidth": 50000000000
+ }
+ }
+ }
+ --example-4
+
+9. Compatibility with Other ALTO Extensions
+
+9.1. Compatibility with Legacy ALTO Clients/Servers
+
+ The multipart filtered cost map resource and the multipart Endpoint
+ Cost Service resource have no backward-compatibility issues with
+ legacy ALTO clients and servers. Although these two types of
+ resources reuse the media types defined in the base ALTO Protocol for
+ the "Accept" input parameters, they have different media types for
+ responses. If the ALTO server provides these two types of resources
+ but the ALTO client does not support them, the ALTO client will
+ ignore the resources without incurring any incompatibility problems.
+
+9.2. Compatibility with Multi-Cost Extension
+
+ The extension defined in this document is compatible with the multi-
+ cost extension [RFC8189]. Such a resource has a media type of either
+ "multipart/related; type=application/alto-costmap+json" or
+ "multipart/related; type=application/alto-endpointcost+json". Its
+ "cost-constraints" field must be either "false" or not present, and
+ the Path Vector cost type must be present in the "cost-type-names"
+ capability field but must not be present in the "testable-cost-type-
+ names" field, as specified in Sections 7.2.4 and 7.3.4.
+
+9.3. Compatibility with Incremental Update Extension
+
+ This extension is compatible with the incremental update extension
+ [RFC8895]. ALTO clients and servers MUST follow the specifications
+ given in Sections 5.2 and 6.7.3 of [RFC8895] to support incremental
+ updates for a Path Vector resource.
+
+9.4. Compatibility with Cost Calendar Extension
+
+ The extension specified in this document is compatible with the Cost
+ Calendar extension [RFC8896]. When used together with the Cost
+ Calendar extension, the cost value between a source and a destination
+ is an array of Path Vectors, where the k-th Path Vector refers to the
+ abstract network paths traversed in the k-th time interval by traffic
+ from the source to the destination.
+
+ When used with time-varying properties, e.g., maximum reservable
+ bandwidth, a property of a single ANE may also have different values
+ in different time intervals. In this case, if such an ANE has
+ different property values in two time intervals, it MUST be treated
+ as two different ANEs, i.e., with different entity identifiers.
+ However, if it has the same property values in two time intervals, it
+ MAY use the same identifier.
+
+ This rule allows the Path Vector extension to represent both changes
+ of ANEs and changes of the ANEs' properties in a uniform way. The
+ Path Vector part is calendared in a compatible way, and the property
+ map part is not affected by the Cost Calendar extension.
+
+ The two extensions combined together can provide the historical
+ network correlation information for a set of source and destination
+ pairs. A network broker or client may use this information to derive
+ other resource requirements such as Time-Block-Maximum Bandwidth,
+ Bandwidth-Sliding-Window, and Time-Bandwidth-Product (TBP) (see
+ [SENSE] for details).
+
+10. General Discussion
+
+10.1. Constraint Tests for General Cost Types
+
+ The constraint test is a simple approach for querying the data. It
+ allows users to filter query results by specifying some boolean
+ tests. This approach is already used in the ALTO Protocol. ALTO
+ clients are permitted to specify either the "constraints" test
+ [RFC7285] [RFC8189] or the "or-constraints" test [RFC8189] to better
+ filter the results.
+
+ However, the current syntax can only be used to test scalar cost
+ types and cannot easily express constraints on complex cost types,
+ e.g., the Path Vector cost type defined in this document.
+
+ In practice, developing a bespoke language for general-purpose
+ boolean tests can be a complex undertaking, and it is conceivable
+ that such implementations already exist (the authors have not done an
+ exhaustive search to determine whether such implementations exist).
+ One avenue for developing such a language may be to explore extending
+ current query languages like XQuery [XQuery] or JSONiq [JSONiq] and
+ integrating these with ALTO.
+
+ Filtering the Path Vector results or developing a more sophisticated
+ filtering mechanism is beyond the scope of this document.
+
+10.2. General Multi-Resource Query
+
+ Querying multiple ALTO information resources continuously is a
+ general requirement. Enabling such a capability, however, must
+ address general issues like efficiency and consistency. The
+ incremental update extension [RFC8895] supports submitting multiple
+ queries in a single request and allows flexible control over the
+ queries. However, it does not cover the case introduced in this
+ document where multiple resources are needed for a single request.
+
+ The extension specified in this document gives an example of using a
+ multipart message to encode the responses from two specific ALTO
+ information resources: a filtered cost map or an Endpoint Cost
+ Service, and a property map. By packing multiple resources in a
+ single response, the implication is that servers may proactively push
+ related information resources to clients.
+
+ Thus, it is worth looking into extending the SSE mechanism as used in
+ the incremental update extension [RFC8895]; or upgrading to HTTP/2
+ [RFC9113] and HTTP/3 [RFC9114], which provides the ability to
+ multiplex queries and to allow servers to proactively send related
+ information resources.
+
+ Defining a general multi-resource query mechanism is out of scope for
+ this document.
+
+11. Security Considerations
+
+ This document is an extension of the base ALTO Protocol, so the
+ security considerations provided for the base ALTO Protocol [RFC7285]
+ fully apply when this extension is provided by an ALTO server.
+
+ The Path Vector extension requires additional scrutiny of three
+ security considerations discussed in the base protocol:
+ confidentiality of ALTO information (Section 15.3 of [RFC7285]),
+ potential undesirable guidance from authenticated ALTO information
+ (Section 15.2 of [RFC7285]), and availability of ALTO services
+ (Section 15.5 of [RFC7285]).
+
+ For confidentiality of ALTO information, a network operator should be
+ aware that this extension may introduce a new risk: the Path Vector
+ information, when used together with sensitive ANE properties such as
+ capacities of bottleneck links, may make network attacks easier. For
+ example, as the Path Vector information may reveal more fine-grained
+ internal network structures than the base protocol, an attacker may
+ identify the bottleneck link or links and start a distributed denial-
+ of-service (DDoS) attack involving minimal flows, triggering in-
+ network congestion. Given the potential risk of leaking sensitive
+ information, the Path Vector extension is mainly applicable in
+ scenarios where 1) the ANE structures and ANE properties do not
+ impose security risks on the ALTO service provider (e.g., they do not
+ carry sensitive information) or 2) the ALTO server and client have
+ established a reliable trust relationship (e.g., they operate in the
+ same administrative domain or are managed by business partners with
+ legal contracts).
+
+ Three risk types are identified in Section 15.3.1 of [RFC7285]:
+
+ (1) excess disclosure of the ALTO service provider's data to an
+ unauthorized ALTO client,
+
+ (2) disclosure of the ALTO service provider's data (e.g., network
+ topology information or endpoint addresses) to an unauthorized
+ third party, and
+
+ (3) excess retrieval of the ALTO service provider's data by
+ collaborating ALTO clients.
+
+ To mitigate these risks, an ALTO server MUST follow the guidelines in
+ Section 15.3.2 of [RFC7285]. Furthermore, an ALTO server MUST follow
+ the following additional protections strategies for risk types (1)
+ and (3).
+
+ For risk type (1), an ALTO server MUST use the authentication methods
+ specified in Section 15.3.2 of [RFC7285] to authenticate the identity
+ of an ALTO client and apply access control techniques to restrict the
+ retrieval of sensitive Path Vector information by unprivileged ALTO
+ clients. For settings where the ALTO server and client are not in
+ the same trust domain, the ALTO server should reach agreements with
+ the ALTO client regarding protection of confidentiality before
+ granting access to Path Vector services with sensitive information.
+ Such agreements may include legal contracts or Digital Rights
+ Management (DRM) techniques. Otherwise, the ALTO server MUST NOT
+ offer Path Vector services that carry sensitive information to the
+ clients, unless the potential risks are fully assessed and mitigated.
+
+ For risk type (3), an ALTO service provider must be aware that
+ persistent ANEs may be used as "landmarks" in collaborative
+ inferences. Thus, they should only be used when exposing public
+ service access points (e.g., API gateways, CDN Interconnections) and/
+ or when the granularity is coarse grained (e.g., when an ANE
+ represents an AS, a data center, or a WAN). Otherwise, an ALTO
+ server MUST use dynamic mappings from ephemeral ANE names to
+ underlying physical entities. Specifically, for the same physical
+ entity, an ALTO server SHOULD assign a different ephemeral ANE name
+ when the entity appears in the responses to different clients or even
+ for different requests from the same client. A RECOMMENDED
+ assignment strategy is to generate ANE names from random numbers.
+
+ Further, to protect the network topology from graph reconstruction
+ (e.g., through isomorphic graph identification [BONDY]), the ALTO
+ server SHOULD consider protection mechanisms to reduce information
+ exposure or obfuscate the real information. When doing so, the ALTO
+ server must be aware that information reduction/obfuscation may lead
+ to a potential risk of undesirable guidance from authenticated ALTO
+ information (Section 15.2 of [RFC7285]).
+
+ Thus, implementations of ALTO servers involving reduction or
+ obfuscation of the Path Vector information SHOULD consider reduction/
+ obfuscation mechanisms that can preserve the integrity of ALTO
+ information -- for example, by using minimal feasible region
+ compression algorithms [NOVA] or obfuscation protocols [RESA]
+ [MERCATOR]. However, these obfuscation methods are experimental, and
+ their practical applicability to the generic capability provided by
+ this extension has not been fully assessed. The ALTO server MUST
+ carefully verify that the deployment scenario satisfies the security
+ assumptions of these methods before applying them to protect Path
+ Vector services with sensitive network information.
+
+ For availability of ALTO services, an ALTO server should be cognizant
+ that using a Path Vector extension might introduce a new risk:
+ frequent requests for Path Vectors might consume intolerable amounts
+ of server-side computation and storage. This behavior can break the
+ ALTO server. For example, if an ALTO server implementation
+ dynamically computes the Path Vectors for each request, the service
+ that provides the Path Vectors may become an entry point for denial-
+ of-service attacks on the availability of an ALTO server.
+
+ To mitigate this risk, an ALTO server may consider using such
+ optimizations as precomputation-and-projection mechanisms [MERCATOR]
+ to reduce the overhead for processing each query. An ALTO server may
+ also protect itself from malicious clients by monitoring client
+ behavior and stopping service to clients that exhibit suspicious
+ behavior (e.g., sending requests at a high frequency).
+
+ The ALTO service providers must be aware that providing incremental
+ updates of "max-reservable-bandwidth" may provide information about
+ other consumers of the network. For example, a change in value may
+ indicate that one or more reservations have been made or changed. To
+ mitigate this risk, an ALTO server can batch the updates and/or add a
+ random delay before publishing the updates.
+
+12. IANA Considerations
+
+12.1. "ALTO Cost Metrics" Registry
+
+ This document registers a new entry in the "ALTO Cost Metrics"
+ registry, per Section 14.2 of [RFC7285]. The new entry is as shown
+ below in Table 1.
+
+ +============+====================+===========+
+ | Identifier | Intended Semantics | Reference |
+ +============+====================+===========+
+ | ane-path | See Section 6.5.1 | RFC 9275 |
+ +------------+--------------------+-----------+
+
+ Table 1: "ALTO Cost Metrics" Registry
+
+12.2. "ALTO Cost Modes" Registry
+
+ This document registers a new entry in the "ALTO Cost Modes"
+ registry, per Section 5 of [RFC9274]. The new entry is as shown
+ below in Table 2.
+
+ +============+=========================+=============+===========+
+ | Identifier | Description | Intended | Reference |
+ | | | Semantics | |
+ +============+=========================+=============+===========+
+ | array | Indicates that the cost | See Section | RFC 9275 |
+ | | value is a JSON array | 6.5.2 | |
+ +------------+-------------------------+-------------+-----------+
+
+ Table 2: "ALTO Cost Modes" Registry
+
+12.3. "ALTO Entity Domain Types" Registry
+
+ This document registers a new entry in the "ALTO Entity Domain Types"
+ registry, per Section 12.3 of [RFC9240]. The new entry is as shown
+ below in Table 3.
+
+ +============+============+=============+===================+=======+
+ | Identifier |Entity |Hierarchy and| Media Type of |Mapping|
+ | |Identifier |Inheritance | Defining Resource |to ALTO|
+ | |Encoding | | |Address|
+ | | | | |Type |
+ +============+============+=============+===================+=======+
+ | ane |See Section |None | application/alto- |false |
+ | |6.2.2 | | propmap+json | |
+ +------------+------------+-------------+-------------------+-------+
+
+ Table 3: "ALTO Entity Domain Types" Registry
+
+ Identifier: See Section 6.2.1.
+
+ Entity Identifier Encoding: See Section 6.2.2.
+
+ Hierarchy: None
+
+ Inheritance: None
+
+ Media Type of Defining Resource: See Section 6.2.4.
+
+ Mapping to ALTO Address Type: This entity type does not map to an
+ ALTO address type.
+
+ Security Considerations: In some usage scenarios, ANE addresses
+ carried in ALTO Protocol messages may reveal information about an
+ ALTO client or an ALTO service provider. If a naming schema is
+ used to generate ANE names, either used privately or standardized
+ by a future extension, how (or if) the naming schema relates to
+ private information and network proximity must be explained to
+ ALTO implementers and service providers.
+
+12.4. "ALTO Entity Property Types" Registry
+
+ Two initial entries -- "max-reservable-bandwidth" and "persistent-
+ entity-id" -- are registered for the ALTO domain "ane" in the "ALTO
+ Entity Property Types" registry, per Section 12.4 of [RFC9240]. The
+ two new entries are shown below in Table 4, and their details can be
+ found in Sections 12.4.1 and 12.4.2 of this document.
+
+ +==========================+====================+===================+
+ | Identifier | Intended | Media Type of |
+ | | Semantics | Defining Resource |
+ +==========================+====================+===================+
+ | max-reservable-bandwidth | See Section | application/alto- |
+ | | 6.4.1 | propmap+json |
+ +--------------------------+--------------------+-------------------+
+ | persistent-entity-id | See Section | application/alto- |
+ | | 6.4.2 | propmap+json |
+ +--------------------------+--------------------+-------------------+
+
+ Table 4: Initial Entries for the "ane" Domain in the "ALTO Entity
+ Property Types" Registry
+
+12.4.1. New ANE Property Type: Maximum Reservable Bandwidth
+
+ Identifier: "max-reservable-bandwidth"
+
+ Intended Semantics: See Section 6.4.1.
+
+ Media Type of Defining Resource: application/alto-propmap+json
+
+ Security Considerations: To make better choices regarding bandwidth
+ reservation, this property is essential for applications such as
+ large-scale data transfers or an overlay network interconnection.
+ It may reveal the bandwidth usage of the underlying network and
+ can potentially be leveraged to reduce the cost of conducting
+ denial-of-service attacks. Thus, the ALTO server MUST consider
+ such protection mechanisms as providing the information to
+ authorized clients only and applying information reduction and
+ obfuscation as discussed in Section 11.
+
+12.4.2. New ANE Property Type: Persistent Entity ID
+
+ Identifier: "persistent-entity-id"
+
+ Intended Semantics: See Section 6.4.2.
+
+ Media Type of Defining Resource: application/alto-propmap+json
+
+ Security Considerations: This property is useful when an ALTO server
+ wants to selectively expose certain service points whose detailed
+ properties can be further queried by applications. As mentioned
+ in Section 12.3.2 of [RFC9240], the entity IDs may reveal
+ sensitive information about the underlying network. An ALTO
+ server should follow the security considerations provided in
+ Section 11 of [RFC9240].
+
+13. References
+
+13.1. Normative References
+
+ [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part Two: Media Types", RFC 2046,
+ DOI 10.17487/RFC2046, November 1996,
+ <https://www.rfc-editor.org/info/rfc2046>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC2387] Levinson, E., "The MIME Multipart/Related Content-type",
+ RFC 2387, DOI 10.17487/RFC2387, August 1998,
+ <https://www.rfc-editor.org/info/rfc2387>.
+
+ [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+ Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+ "Application-Layer Traffic Optimization (ALTO) Protocol",
+ RFC 7285, DOI 10.17487/RFC7285, September 2014,
+ <https://www.rfc-editor.org/info/rfc7285>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost
+ Application-Layer Traffic Optimization (ALTO)", RFC 8189,
+ DOI 10.17487/RFC8189, October 2017,
+ <https://www.rfc-editor.org/info/rfc8189>.
+
+ [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
+ Optimization (ALTO) Incremental Updates Using Server-Sent
+ Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
+ 2020, <https://www.rfc-editor.org/info/rfc8895>.
+
+ [RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N.
+ Schwan, "Application-Layer Traffic Optimization (ALTO)
+ Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November
+ 2020, <https://www.rfc-editor.org/info/rfc8896>.
+
+ [RFC9240] Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K.
+ Gao, "An Extension for Application-Layer Traffic
+ Optimization (ALTO): Entity Property Maps", RFC 9240,
+ DOI 10.17487/RFC9240, July 2022,
+ <https://www.rfc-editor.org/info/rfc9240>.
+
+ [RFC9274] Boucadair, M. and Q. Wu, "A Cost Mode Registry for the
+ Application-Layer Traffic Optimization (ALTO) Protocol",
+ RFC 9274, DOI 10.17487/RFC9274, July 2022,
+ <https://www.rfc-editor.org/info/rfc9274>.
+
+13.2. Informative References
+
+ [ALTO-PERF-METRICS]
+ Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
+ L. Contreras, "ALTO Performance Cost Metrics", Work in
+ Progress, Internet-Draft, draft-ietf-alto-performance-
+ metrics-28, 21 March 2022,
+ <https://datatracker.ietf.org/doc/html/draft-ietf-alto-
+ performance-metrics-28>.
+
+ [BONDY] Bondy, J.A. and R.L. Hemminger, "Graph reconstruction--a
+ survey", Journal of Graph Theory, Volume 1, Issue 3, pp.
+ 227-268, DOI 10.1002/jgt.3190010306, 1977,
+ <https://onlinelibrary.wiley.com/doi/10.1002/
+ jgt.3190010306>.
+
+ [BOXOPT] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R.
+ Yang, "Optimizing in the Dark: Learning an Optimal
+ Solution through a Simple Request Interface", Proceedings
+ of the AAAI Conference on Artificial Intelligence 33,
+ 1674-1681, DOI 10.1609/aaai.v33i01.33011674, July 2019,
+ <https://ojs.aaai.org//index.php/AAAI/article/view/3984>.
+
+ [CLARINET] Viswanathan, R., Ananthanarayanan, G., and A. Akella,
+ "CLARINET: WAN-aware optimization for analytics queries",
+ Proceedings of the 12th USENIX conference on Operating
+ Systems Design and Implementation (OSDI'16), Savannah, GA,
+ pp. 435-450, November 2016,
+ <https://dl.acm.org/doi/abs/10.5555/3026877.3026911>.
+
+ [G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., Langston,
+ M.H., Lethin, R., Jiang, Y., Tassiulas, L., Li, J., Tan,
+ Y., and M. Veeraraghavan, "On the Bottleneck Structure of
+ Congestion-Controlled Networks", Proceedings of the ACM on
+ Measurement and Analysis of Computing Systems, Volume 3,
+ Issue 3, pp. 1-31, DOI 10.1145/3366707, December 2019,
+ <https://dl.acm.org/doi/10.1145/3366707>.
+
+ [HUG] Chowdhury, M., Liu, Z., Ghodsi, A., and I. Stoica, "HUG:
+ multi-resource fairness for correlated and elastic
+ demands", Proceedings of the 13th USENIX Conference on
+ Networked Systems Design and Implementation (NSDI'16),
+ Santa Clara, CA, pp. 407-424, March 2016,
+ <https://dl.acm.org/doi/10.5555/2930611.2930638>.
+
+ [INTENT-BASED-NETWORKING]
+ Clemm, A., Ciavaglia, L., Granville, L. Z., and J.
+ Tantsura, "Intent-Based Networking - Concepts and
+ Definitions", Work in Progress, Internet-Draft, draft-
+ irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022,
+ <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-
+ ibn-concepts-definitions-09>.
+
+ [JSONiq] JSONiq, "The JSON Query Language", 2022,
+ <https://www.jsoniq.org/>.
+
+ [MERCATOR] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F.,
+ MacAuley, J., Newman, H., and Y.R. Yang, "Toward Fine-
+ Grained, Privacy-Preserving, Efficient Multi-Domain
+ Network Resource Discovery", IEEE/ACM, IEEE Journal on
+ Selected Areas in Communications, Volume 37, Issue 8, pp.
+ 1924-1940, DOI 10.1109/JSAC.2019.2927073, August 2019,
+ <https://ieeexplore.ieee.org/document/8756056>.
+
+ [MOWIE] Zhang, Y., Li, G., Xiong, C., Lei, Y., Huang, W., Han, Y.,
+ Walid, A., Yang, Y.R., and Z. Zhang, "MoWIE: Toward
+ Systematic, Adaptive Network Information Exposure as an
+ Enabling Technique for Cloud-Based Applications over 5G
+ and Beyond", Proceedings of the Workshop on Network
+ Application Integration/CoDesign (NAI '20), ACM, Virtual
+ Event USA, pp. 20-27, DOI 10.1145/3405672.3409489, August
+ 2020, <https://dl.acm.org/doi/10.1145/3405672.3409489>.
+
+ [NOVA] Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi, "An
+ Objective-Driven On-Demand Network Abstraction for
+ Adaptive Applications", IEEE/ACM Transactions on
+ Networking (TON) Vol. 27, Issue 2, pp. 805-818,
+ DOI 10.1109/TNET.2019.2899905, April 2019,
+ <https://doi.org/10.1109/TNET.2019.2899905>.
+
+ [RESA] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F.,
+ MacAuley, J., Newman, H., and Y.R. Yang, "Fine-Grained,
+ Multi-Domain Network Resource Abstraction as a Fundamental
+ Primitive to Enable High-Performance, Collaborative Data
+ Sciences", SC18: International Conference for High
+ Performance Computing, Networking, Storage and Analysis,
+ pp. 58-70, DOI 10.1109/SC.2018.00008, November 2018,
+ <https://ieeexplore.ieee.org/document/8665783>.
+
+ [RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service
+ Specification Template", RFC 2216, DOI 10.17487/RFC2216,
+ September 1997, <https://www.rfc-editor.org/info/rfc2216>.
+
+ [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
+ Border Gateway Protocol 4 (BGP-4)", RFC 4271,
+ DOI 10.17487/RFC4271, January 2006,
+ <https://www.rfc-editor.org/info/rfc4271>.
+
+ [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
+ DOI 10.17487/RFC9113, June 2022,
+ <https://www.rfc-editor.org/info/rfc9113>.
+
+ [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
+ June 2022, <https://www.rfc-editor.org/info/rfc9114>.
+
+ [SENSE] ESnet, "Software Defined Networking (SDN) for End-to-End
+ Networked Science at the Exascale", 2019,
+ <https://www.es.net/network-r-and-d/sense/>.
+
+ [SEREDGE] Contreras, L., Baliosian, J., Martínez-Julia, P., and J.
+ Serrat, "Computing at the Edge: But, what Edge?",
+ Proceedings of NOMS 2020 - 2020 IEEE/IFIP Network
+ Operations and Management Symposium, pp. 1-9,
+ DOI 10.1109/NOMS47738.2020.9110342, April 2020,
+ <https://ieeexplore.ieee.org/document/9110342>.
+
+ [SWAN] Hong, C., Kandula, S., Mahajan, R., Zhang, M., Gill, V.,
+ Nanduri, M., and R. Wattenhofer, "Achieving high
+ utilization with software-driven WAN", Proceedings of the
+ ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), New
+ York, NY, pp. 15-26, DOI 10.1145/2486001.2486012, August
+ 2013, <https://dl.acm.org/doi/10.1145/2486001.2486012>.
+
+ [UNICORN] Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, Y.R.,
+ and Y. Liu, "Unicorn: Unified resource orchestration for
+ multi-domain, geo-distributed data analytics", Future
+ Generation Computer Systems, Volume 93, pp. 188-197,
+ DOI 10.1016/j.future.2018.09.048, April 2019,
+ <https://www.sciencedirect.com/science/article/abs/pii/
+ S0167739X18302413?via%3Dihub>.
+
+ [XQuery] Robie, J., Ed., Dyck, M., Ed., and J. Spiegel, Ed.,
+ "XQuery 3.1: An XML Query Language", W3C Recommendation,
+ March 2017, <https://www.w3.org/TR/xquery-31/>.
+
+Acknowledgments
+
+ The authors would like to thank Andreas Voellmy, Erran Li, Haibin
+ Song, Haizhou Du, Jiayuan Hu, Tianyuan Liu, Xiao Shi, Xin Wang, and
+ Yan Luo for fruitful discussions. The authors thank Greg Bernstein,
+ Dawn Chen, Wendy Roome, and Michael Scharf for their contributions to
+ earlier draft versions of this document.
+
+ The authors would also like to thank Tim Chown, Luis Contreras, Roman
+ Danyliw, Benjamin Kaduk, Erik Kline, Suresh Krishnan, Murray
+ Kucherawy, Warren Kumari, Danny Lachos, Francesca Palombini, Éric
+ Vyncke, Samuel Weiler, and Qiao Xiang, whose feedback and suggestions
+ were invaluable for improving the practicability and conciseness of
+ this document; and Mohamed Boucadair, Martin Duke, Vijay Gurbani, Jan
+ Seedorf, and Qin Wu, who provided great support and guidance.
+
+Authors' Addresses
+
+ Kai Gao
+ Sichuan University
+ No.24 South Section 1, Yihuan Road
+ Chengdu
+ 610000
+ China
+ Email: kaigao@scu.edu.cn
+
+
+ Young Lee
+ Samsung
+ Republic of Korea
+ Email: younglee.tx@gmail.com
+
+
+ Sabine Randriamasy
+ Nokia Bell Labs
+ Route de Villejust
+ 91460 Nozay
+ France
+ Email: sabine.randriamasy@nokia-bell-labs.com
+
+
+ Yang Richard Yang
+ Yale University
+ 51 Prospect Street
+ New Haven, CT 06511
+ United States of America
+ Email: yry@cs.yale.edu
+
+
+ Jingxuan Jensen Zhang
+ Tongji University
+ 4800 Caoan Road
+ Shanghai
+ 201804
+ China
+ Email: jingxuan.n.zhang@gmail.com