• 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.

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 [RFC 2216] 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 RFC 4271) 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 RFC 7285) or 2) a source endpoint and a destination endpoint, as in the EndpointCostMapData object (Section 11.5.1.6 of RFC 7285).

Path Vector resource:

An ALTO information resource (Section 8.1 of RFC 7285) 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.

                              +-----+
                              |     |
                            --+ 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

                          +----------------------+
                 {eh1}    |                      |     {eh2}
                 PID1     |                      |     PID2
                   +------+                      +------+
                          |                      |
                          |                      |
                 {eh3}    |                      |     {eh4}
                 PID3     |                      |     PID4
                   +------+                      +------+
                          |                      |
                          +----------------------+

    max(x + y).

    x <= 100 Mbps
    y <= 100 Mbps.

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.

• 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.

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.

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.

  ALTO client                              ALTO server
       |-------------- Request ---------------->|
       |<------------- Response ----------------|

  ALTO client                              ALTO server
       |------------- PV Request -------------->|
       |<----- PV Response (Cost Map Part) -----|
       |<--- PV Response (Property Map Part) ---|

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.

• 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.

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 RFC 5322. It must be the domain name of the ALTO server.

object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVReqFilteredCostMap : ReqFilteredCostMap;

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.

   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" ]
   }

object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;

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.

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 RFC 8189):

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.

type:

The "type" parameter is mandatory and MUST be "application/alto-costmap+json". Note that [RFC 2387] permits parameters both with and without double quotes.

start:

The "start" parameter is as defined in [RFC 2387] 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 RFC 2046 and is mandatory.

• 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 RFC 7285 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 RFC 8189 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 RFC 9240. 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 RFC 7285. 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 RFC 9240. 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 ({}).

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

object {
  [EntityPropertyName ane-property-names<0..*>;]
} PVReqEndpointCostMap : ReqEndpointCostMap;

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.

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" ]
}

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 RFC 2046 and is mandatory.

• 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 RFC 7285 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 RFC 8189 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 RFC 9240. 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 RFC 7285. 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 RFC 9240. 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 ({}).

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

"my-default-networkmap":

A network map resource that contains the PIDs in thenetwork.

"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 theinformation 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 updateservice for the "endpoint-cost-pv" service.

"multicost-pv":

A multipart Endpoint Cost Service with both the Multi-Cost extension and Path Vector extension enabled.

{
  "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" ]
    }
  }
}

• 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 RFC 9240).

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

• 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).

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

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

• 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

(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.

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.

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.

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 RFC 9240, the entity IDs may reveal sensitive information about the underlying network. An ALTO server should follow the security considerations provided in Section 11 of RFC 9240.

[RFC2046]

N. Freed, 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]

S. Bradner, "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]

E. Levinson, "The MIME Multipart/Related Content-type", RFC 2387, DOI 10.17487/RFC2387, August 1998,
<https://www.rfc-editor.org/info/rfc2387>.

[RFC5322]

P. Resnick, "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.

[RFC7285]

R. Alimi, R. Penno, Y. Yang, S. Kiesel, S. Previdi, W. Roome, S. Shalunov, 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]

B. Leiba, "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]

S. Randriamasy, W. Roome, 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]

W. Roome, 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]

S. Randriamasy, R. Yang, Q. Wu, L. Deng, 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]

W. Roome, S. Randriamasy, Y. Yang, J. Zhang, 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]

M. Boucadair, 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>.

[ALTO-PERF-METRICS]

Telefonica, Q Wu, Y Yang, Y Lee, D Dhody, S Randriamasy, and L Contreras, "ALTO Performance Cost Metrics", Internet-Draft draft-ietf-alto-performance-metrics-28, March 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-28>.

[BONDY]

Vanderbilt University, J.A. Bondy, and R.L. Hemminger, "Graph reconstruction--a survey", DOI 10.1002/jgt.3190010306, 1977,
<https://onlinelibrary.wiley.com/doi/10.1002/jgt.3190010306>.

[BOXOPT]

Yale University, Q. Xiang, H. Yu, J. Aspnes, F. Le, L. Kong, and Y.R. Yang, "Optimizing in the Dark: Learning an Optimal Solution through a Simple Request Interface", DOI 10.1609/aaai.v33i01.33011674, July 2019,
<https://ojs.aaai.org//index.php/AAAI/article/view/3984>.

[CLARINET]

University of Wisconsin-Madison, R. Viswanathan, G. Ananthanarayanan, and A. Akella, "CLARINET: WAN-aware optimization for analytics queries", November 2016,
<https://dl.acm.org/doi/abs/10.5555/3026877.3026911>.

[G2]

University of Virginia, J. Ros-Giralt, A. Bohara, S. Yellamraju, M.H. Langston, R. Lethin, Y. Jiang, L. Tassiulas, J. Li, Y. Tan, and M. Veeraraghavan, "On the Bottleneck Structure of Congestion-Controlled Networks", DOI 10.1145/3366707, December 2019,
<https://dl.acm.org/doi/10.1145/3366707>.

[HUG]

UC Berkeley, Databricks Inc., M. Chowdhury, Z. Liu, A. Ghodsi, and I. Stoica, "HUG: multi-resource fairness for correlated and elastic demands", March 2016,
<https://dl.acm.org/doi/10.5555/2930611.2930638>.

[INTENT-BASED-NETWORKING]

Microsoft, A Clemm, L Ciavaglia, L. Z. Granville, and J Tantsura, "Intent-Based Networking - Concepts and Definitions", Internet-Draft draft-irtf-nmrg-ibn-concepts-definitions-09, 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]

Yale University, Q. Xiang, J. Zhang, X. Wang, Y. Liu, C. Guok, F. Le, J. MacAuley, H. Newman, and Y.R. Yang, "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", DOI 10.1109/JSAC.2019.2927073, August 2019,
<https://ieeexplore.ieee.org/document/8756056>.

[MOWIE]

University of Minnesota, Y. Zhang, G. Li, C. Xiong, Y. Lei, W. Huang, Y. Han, A. Walid, Y.R. Yang, and Z. Zhang, "MoWIE: Toward Systematic, Adaptive Network Information Exposure as an Enabling Technique for Cloud-Based Applications over 5G and Beyond", DOI 10.1145/3405672.3409489, August 2020,
<https://dl.acm.org/doi/10.1145/3405672.3409489>.

[NOVA]

Tsinghua University, K. Gao, Q. Xiang, X. Wang, Y.R. Yang, and J. Bi, "An Objective-Driven On-Demand Network Abstraction for Adaptive Applications", DOI 10.1109/TNET.2019.2899905, April 2019,
<https://doi.org/10.1109/TNET.2019.2899905>.

[RESA]

Yale University, Q. Xiang, J. Zhang, X. Wang, Y. Liu, C. Guok, F. Le, J. MacAuley, H. Newman, and Y.R. Yang, "Fine-Grained, Multi-Domain Network Resource Abstraction as a Fundamental Primitive to Enable High-Performance, Collaborative Data Sciences", DOI 10.1109/SC.2018.00008, November 2018,
<https://ieeexplore.ieee.org/document/8665783>.

[RFC2216]

S. Shenker, and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, DOI 10.17487/RFC2216, September 1997,
<https://www.rfc-editor.org/info/rfc2216>.

[RFC4271]

Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.

[RFC9113]

M. Thomson, and C. Benfield, "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.

[RFC9114]

M. Bishop, "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]

Universitat Politcnica de Catalunya, L. Contreras, J. Baliosian, P. Martínez-Julia, and J. Serrat, "Computing at the Edge: But, what Edge?", DOI 10.1109/NOMS47738.2020.9110342, April 2020,
<https://ieeexplore.ieee.org/document/9110342>.

[SWAN]

ETH, C. Hong, S. Kandula, R. Mahajan, M. Zhang, V. Gill, M. Nanduri, and R. Wattenhofer, "Achieving high utilization with software-driven WAN", DOI 10.1145/2486001.2486012, August 2013,
<https://dl.acm.org/doi/10.1145/2486001.2486012>.

[UNICORN]

Tongji University, Q. Xiang, T. Wang, J. Zhang, H. Newman, Y.R. Yang, and Y. Liu, "Unicorn: Unified resource orchestration for multi-domain, geo-distributed data analytics", DOI 10.1016/j.future.2018.09.048, April 2019,
<https://www.sciencedirect.com/science/article/abs/pii/S0167739X18302413?via%3Dihub>.

[XQuery]

J. Robie, M. Dyck, and J. Spiegel, "XQuery 3.1: An XML Query Language", March 2017,
<https://www.w3.org/TR/xquery-31/>.

Kai Gao

Young Lee

Sabine Randriamasy

Yang Richard Yang

Jingxuan Jensen Zhang