RFC 9275: An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector

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

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

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]

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

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)

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.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.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.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.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:¶

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.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".¶

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:¶

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.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:¶

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

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].¶