ALTO Extension: Path VectorSichuan UniversityNo.24 South Section 1, Yihuan RoadChengdu610000Chinakaigao@scu.edu.cnSamsungSouth Koreayounglee.tx@gmail.comNokia Bell LabsRoute de VillejustNozay91460Francesabine.randriamasy@nokia-bell-labs.comYale University51 Prospect StreetNew HavenCTUSAyry@cs.yale.eduTongji University4800 Caoan RoadShanghai201804Chinajingxuan.n.zhang@gmail.com
Application
ALTOThis document is an extension to the base Application-Layer Traffic Optimization
(ALTO) protocol. It extends the ALTO Cost Map service and ALTO Property Map
service so that the application can decide which endpoint(s) to connect based on
not only numerical/ordinal cost values but also details of the paths. This is
useful for applications whose performance is impacted by specified 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 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.IntroductionNetwork performance metrics are crucial to the Quality of Experience (QoE) of
today's applications. The ALTO protocol allows Internet Service Providers (ISPs)
to provide guidance, such as topological distance between different end
hosts, to overlay applications. Thus, the overlay applications can potentially
improve the QoE by better orchestrating their traffic to utilize the resources
in the underlying network infrastructure.Existing ALTO Cost Map and Endpoint Cost Service provide only cost information
on an end-to-end path defined by its <source, destination> endpoints: The base
protocol 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
, to query multiple costs simultaneously
, and to obtain the time-varying values
.While the existing extensions are sufficient for many overlay applications,
the QoE of some overlay applications depends not only on the cost
information of end-to-end paths, but also on particular components of a network
on the paths and their properties. 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 (ANE).Predicting such information can be very complex without the help of the ISP
. 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 benefits, ISPs are not likely to expose details on their
network paths: first for the sake of confidentiality, second because it may
result in an increase in volume and computation overhead, and last because it is
difficult for ISPs to figure out what information and what details an
application needs. Likewise, applications do not necessarily need all the
network path details and are likely not able to understand them.Therefore, it is beneficial for both parties if an ALTO server provides ALTO
clients with an "abstract network state" that provides the necessary details to
applications, while hiding the network complexity and confidential information.
An "abstract network state" is a selected set of abstract representations of
Abstract Network Elements traversed by the paths between <source, destination>
pairs combined with properties of these Abstract Network Elements 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 Abstract Network
Elements. The requirements on the server scalability can also be reduced by
combining Abstract Network Elements and their properties in a single response.This document extends 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 "Path Vector". A Path Vector is an
array of identifiers that identifies an Abstract Network Element, which can
be associated with various properties. The associations between ANEs and their
properties are encoded in an ALTO information resource called Unified Property
Map, which is specified in .For better confidentiality, this document aims to minimize information exposure.
In particular, this document enables and recommends that first ANEs are
constructed on demand, and second an ANE is only associated with properties that
are requested by an ALTO client. A Path Vector response involves two ALTO Maps:
the Cost Map that contains the Path Vector results and the up-to-date Unified
Property Map that contains the properties requested for these ANEs. To enforce
consistency and improve server scalability, this document uses the
multipart/related message defined in to return the two maps in a
single response.The rest of the document is organized as follows. introduces the extra
terminologies that are used in this document. uses an illustrative
example to introduce the additional requirements of the ALTO framework, and
discusses potential use cases. gives an overview of the protocol
design. and specify the extension to the ALTO IRD and the
information resources, with some concrete examples presented in .
discusses the backward compatibility with the base protocol
and existing extensions. Security and IANA considerations are discussed in
and respectively.Requirements LanguagesThe 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
when, and only when, they appear in all capitals, as shown here.When the words appear in lower case, they are to be interpreted with their
natural language meanings.TerminologyNOTE: This document depends on the Unified Property Map extension
and should be processed after the Unified
Property Map document.This document extends the ALTO base protocol and the Unified
Property Map extension . In addition to
the terms defined in these documents, this document also uses the following
additional terms:
Abstract Network Element (ANE): An Abstract Network Element is an abstract
representation for a component in a network that handle 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 Abstract Network Element is similar to Network Element
defined in in the sense that they both provide an abstract
representation of particular components of a network. However, they have
different criteria on how these particular components are selected.
Specifically, Network Element requires the components to be potentially
capable of exercising QoS control, while Abstract Network Element only
requires the components to have an impact on the end-to-end performance.
ANE Name: 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 .
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: A Path Vector, or an ANE Path Vector, is a JSON array of ANE
Names. It is a generalization of BGP path vector. While standard BGP path
vector specifies a sequence of autonomous systems for a destination IP prefix,
the Path Vector defined in this extension specifies a sequence of ANEs either
for a source PID and a destination PID as in a cost map, or for a source
endpoint and a destination endpoint as in an endpoint cost map.
Path Vector resource: A Path Vector resource refers to an ALTO resource which
supports the extension defined in this document.
Path Vector cost type: The Path Vector cost type is a special cost type, which
is specified in . When this cost type is present in an IRD
entry, it indicates that the information resource is a Path Vector resource.
When this cost type is present in a Cost Map or an Endpoint Cost Map, it
indicates each cost value must be interpreted as a Path Vector.
Path Vector request: A Path Vector request refers to the POST message sent to
an ALTO Path Vector resource.
Path Vector response: A Path Vector response refers to the multipart/related
message returned by a Path Vector resource.
Problem StatementDesign RequirementsThis 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 or switches and share bottlenecks. The application hopes to
schedule the traffic among multiple flows to get better performance. The
capacity region information for those flows will benefit the scheduling.
However, existing cost maps can not reveal such information.Specifically, consider a network as shown in . The network has 7
switches (sw1 to sw7) forming a dumb-bell topology. Switches sw1/sw3 provide
access on one side, sw2/sw4 provide access on the other side, and sw5-sw7 form
the backbone. Endhosts eh1 to eh4 are connected to access switches sw1 to sw4
respectively. Assume that the bandwidth of link eh1 -> sw1 and link sw1 -> sw5
are 150 Mbps, and the bandwidth of the other links are 100 Mbps.The single-node ALTO topology abstraction of the network is shown in
. Assume the cost map returns a hypothetical cost type representing
the available bandwidth between a source and a destination.Now assume the application wants to maximize the total rate of the traffic among
a set of end host <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 isWith the ALTO Cost Map, the cost between PID1 and PID2 and between PID1 and PID4 will
be 100 Mbps. And the client can get a capacity
region ofWith this information, the client may mistakenly think it can achieve a maximum
total rate of 200 Mbps. However, one can easily see that 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
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
and the real optimal total rate is 100 Mbps.
Clearly, with more accurate and fine-grained information, the application can
gain a better prediction of its traffic and may orchestrate its own resources
accordingly. However, to provide such information, the network needs to expose
more details beyond the simple cost map abstraction. In particular:
The ALTO server must give more details 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
Case 1 and Case 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 give details on the properties of the ANEs used by eh1 ->
eh2 and eh1 -> eh4, e.g., 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.
In general, we can conclude that to support the multiple flow scheduling
use case, the ALTO framework must be extended to satisfy the following
additional requirements:
AR1:
An ALTO server must provide essential information on ANEs on the
path of a <source, destination> pair that are critical to the QoE of the
overlay application.
AR2:
An ALTO server must provide essential information on how the paths of
different <source, destination> pairs share a common ANE.
AR3:
An ALTO server must provide essential information on the properties associated
to the ANEs.
The extension defined in this document propose a solution to provide these
details.Use CasesWhile the multiple flow scheduling problem 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 real use cases
that are reported.Large-scale Data AnalyticsOne potential use case of the extension defined in this document is for
large-scale data analytics such as and , where data of
gigabytes, terabytes and even petabytes are transferred. For these applications,
the QoE is usually measured as the job completion time, which is related to the
completion time of all the data transfers belonging to the job. With the
extension defined in this document, an ALTO client can identify bottlenecks
inside the network. Therefore, the overlay application can make optimal traffic
distribution or resource reservation (i.e., proportional to the size of the
transferred data), leading to optimal job completion time and network resource
utilization.Context-aware Data TransferIt is important to know the capabilities of various ANEs between two end
hosts, especially in the mobile environment. With the extension defined in this
document, an ALTO client may query the "network context" information, i.e.,
whether the two hosts are connected to the access network through a wireless
link or a wire, and the capabilities of the access network. Thus, the client may
use different data transfer mechanisms, or even deploy different 5G User Plane
Functions (UPF) to optimize the data
transfer.CDN and Service EdgeA growing trend in today's applications is to bring storage and computation
closer to the end user for better QoE, such as Content Delivery Network (CDN),
AR/VR, and cloud gaming, as reported in various documents
(,
, and
).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,
together with their properties such as capabilities (e.g., storage, GPU) and
available Service Level Agreement (SLA) plans. Thus, an ALTO client may leverage
the information to better conduct CDN request routing or offload functionalities
from the user equipment to the service edge, with considerations on different
resource constraints.Path Vector Extension: OverviewThis section gives a non-normative overview of the extension defined in this
document. It is assumed that readers are familiar with both the base protocol
and the Unified Property Map extension
.To satisfies the additional requirements, this extension:
introduces Abstract Network Element (ANE) as the abstraction of components in
a network whose properties may have an impact on the end-to-end performance
of the traffic handled by those component,
extends the Cost Map and Endpoint Cost Service to convey the ANEs traversed
by the path of a <source, destination> pair as Path Vectors,
uses the Unified Property Map to convey the association between the
ANEs and their properties.
Thus, an ALTO client can learn about the ANEs that are critical to the QoE of a
<source, destination> pair by investigating the corresponding Path Vector value
(AR1), identify common ANEs if an ANE appears in the Path Vectors of multiple
<source, destination> pairs (AR2), and retrieve the properties of the ANEs by
searching the Unified Property Map (AR3).Abstract Network ElementThis extension introduces Abstract Network Element (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 the end-to-end performance for
traffic between a source and a destination.When an ANE is defined by the ALTO server, it is assigned an identifier, i.e.,
string of type ANEName as specified in , and a set of
associated properties.ANE DomainIn this extension, the associations between ANE and the properties are conveyed
in a Unified Property Map. Thus, ANEs must constitute an entity domain (Section
5.1 of ), and each ANE property must be an
entity property (Section 5.2 of ).Specifically, this document defines a new entity domain called ane as
specified in and defines two initial properties for the ane
domain.Ephemeral ANE and Persistent ANEFor different requests, there can be different ways of grouping components of a
network and assigning ANEs. For example, an ALTO server may define an ANE for
each aggregated bottleneck link between the sources and destinations specified
in the request. As the aggregated bottleneck links vary for different
combinations of sources and destinations, the ANEs are ephemeral and are no
longer valid after the request completes. Thus, the scope of ephemeral ANEs are
limited to the corresponding Path Vector response.While ephemeral ANEs returned by a Path Vector response do not exist beyond that
response, some of them may represent entities that are persistent and defined in
a standalone Property Map. Indeed, it may be useful for clients to occasionally
query properties on persistent entities, without caring about the path that
traverses them. 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. Persistent entities have
a persistent ID that is registered in a Property Map, together with their
properties. See and for more
detailed instructions on how to identify ephemeral ANEs and persistent ANEs.Property FilteringResource-constrained ALTO clients 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 as a new capability called ane-property-names.
The selected properties are specified in a filter called ane-property-names in
the request body, and the response includes and only includes the selected
properties for the ANEs in the response.The ane-property-names capability for Cost Map and for Endpoint Cost Service
are specified in and respectively. The
ane-property-names filter for Cost Map and Endpoint Cost Service are specified
in and accordingly.Path Vector Cost TypeFor an ALTO client to correctly interpret the Path Vector, this extension
specifies a new cost type called the Path Vector cost type, which must be
included both in the Information Resource Directory and the ALTO Cost Map or
Endpoint Cost Map so that an ALTO client can correctly interpret the cost values.The Path Vector cost type must convey both the interpretation and semantics in
the "cost-mode" and "cost-metric" 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++, a Path Vector will 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 the value is a JSON array. Then, an
ALTO client must check the value of the "cost-metric". 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 .Multipart Path Vector ResponseFor a basic ALTO information resource, a response contains only one type of
ALTO resources, 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 .The extension defined in this document, on the other hand, involves two types of information
resources: Path Vectors conveyed in a Cost Map or an Endpoint Cost Map, and ANE
properties conveyed in a Unified Property Map. 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 .
Since the two parts are bundled together in one response message, their orders
are interchangeable. See and for details.This design is based on the following considerations:
Since ANEs may be constructed on demand, and potentially based on the
requested properties (See 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.
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. The "stateful" behavior may substantially harm the
server scalability and potentially lead to Denial-of-Service attacks.
One approach to realize 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 multipart/related media type defined
in to elegantly combine the objects. Path Vectors are encoded as a
Cost Map or an Endpoint Cost Map, and the Property Map is encoded as a Unified
Propert Map. They are encapsulated as parts of a multipart message. The 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.Identifying the Media Type of the Root ObjectALTO uses media type to indicate the type of an entry in the Information
Resource Directory (IRD) (e.g., application/alto-costmap+json for Cost Map
and application/alto-endpointcost+json for Endpoint Cost Map). Simply
putting 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
root object of a multipart/related message. For a Cost Map resource, the
media-type 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.References to Part MessagesAs 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 designs of , this extension requires that an ALTO
server assigns a unique identifier to each part of the multipart/related
response message. This identifier, referred to as a Part Resource ID (See
for details), is present in the part message's Content-ID
header. 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.Specification: Basic Data TypesANE NameAn ANE Name is encoded as a JSON string with the same format as that of the type
PIDName (Section 10.1 of ).The type ANEName is used in this document to indicate a string of this
format.ANE DomainThe ANE domain associates property values with the Abstract Network Elements in
a Property Map. Accordingly, the ANE domain always depends on a Property Map.Entity Domain TypeaneDomain-Specific Entity IdentifierThe entity identifiers are the ANE Names in the associated Property Map.Hierarchy and InheritanceThere is no hierarchy or inheritance for properties associated with ANEs.Media Type of Defining ResourceWhen resource specific domains are defined with entities of domain type ane,
the defining resource for entity domain type pid MUST be a Property Map. The
media type of defining resources for the ane domain is: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
persistent ANEs whose entity domain name has the format of "PROPMAP.ane" where
PROPMAP is the name of a Property Map resource, PROPMAP is the defining resource
of these ANEs. Persistent entities are persistent because standalone queries
can be made by an ALTO client to their defining resources 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".ANE Property NameAn ANE Property Name is encoded as a JSON string with the same format as that of
Entity Property Name (Section 5.2.2 of ).Initial ANE Property TypesIn this document, two initial ANE property types are specified,
max-reservable-bandwidth and persistent-entity-id.Note that the two property types defined in this document do not depend on any
information resource, so their ResourceID part must be empty.In this document, is used to illustrate the use of the two initial
ANE property types. There are 3 sub-networks (NET1, NET2 and NET3) and two
interconnection links (L1 and L2). It is assumed that each sub-network has
sufficiently large bandwidth to be reserved.New ANE Property Type: Maximum Reservable Bandwidth
Identifier:
max-reservable-bandwidth
Intended Semantics:
The maximum reservable bandwidth property 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 and the unit is bit per second. If this property is
requested but not present in an ANE, it MUST be interpreted as that the ANE
does not support bandwidth reservation.
Security Considerations:
ALTO entity properties expose information to ALTO clients. ALTO service
providers should be made aware of the security ramifications related to the
exposure of an entity property.
To illustrate the use of max-reservable-bandwidth, consider the network in
. An ALTO server can create an ANE for each interconnection link,
where the initial value for max-reservable-bandwidth is the link capacity.New ANE Property Type: Persistent Entity ID
Identifier:
persistent-entity-id
Intended Semantics:
The persistent entity ID property is the entity identifier of the persistent
ANE which an ephemeral ANE presents (See for details). The value of
this property is encoded with the format defined in Section 5.1.3 of
.
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 defining the
ANE as a persistent entity, together with the properties
the persistent name of the ANE in this property map
With this format, the client has all the needed information for further
standalone query properties on the persistent ANE.
Security Considerations:
ALTO entity properties expose information to ALTO clients. ALTO service
providers should be made aware of the security ramifications related to the
exposure of an entity property.
To illustrate the use of persistent-entity-id, consider the network in
. Assume the ALTO server has a Property Map resource called
"mec-props" that defines persistent ANEs "MEC1" and "MEC2" that represent the
corresponding mobile edge computing (MEC) clusters. Since MEC1 is associated
with NET1, the persistent-entity-id of the ephemeral ANE .ane:NET1 is the
persistent entity id mec-props.ane:MEC1.Path Vector Cost TypeThis 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.Cost Metric: ane-pathThe cost metric "ane-path" indicates 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.Cost Mode: arrayThe cost mode "array" indicates that every cost value in a Cost Map or an
Endpoint Cost Map MUST be interpreted as a JSON array object.Note that this cost mode only requires the cost value to be a JSON array of
JSONValue. However, an ALTO server that enables this extension MUST return a
JSON array of ANEName () when the cost metric is
"ane-path".Part Resource IDA Part Resource ID is encoded as a JSON string with the same format as that of the
type ResourceID (Section 10.2 of ).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 ) 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 resource ID and
client ID related to a Path Vector resource to 31 characters.Specification: Service ExtensionsNotationsThis document uses the same syntax and notations as introduced in Section 8.2 of
RFC 7285 to specify the extensions to existing ALTO resources and
services.Multipart Filtered Cost Map for Path VectorThis document introduces a new ALTO resource called multipart filtered cost map
resource, which allows an ALTO server to provide other ALTO resources associated
to the cost map resource in the same response.Media TypeThe media type of the multipart filtered cost map resource is
multipart/related;type=application/alto-costmap+json.HTTP MethodThe multipart filtered cost map is requested using the HTTP POST method.Accept Input ParametersThe 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 11.3.2.3 of RFC 7285 , with a data
format indicated by the media type application/alto-costmapfilter+json, which
is a JSON object of type PVReqFilteredCostMap, where:;]
} PVReqFilteredCostMap : ReqFilteredCostMap;
]]>with fields:
ane-property-names:
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 (See ). If the
field is NOT present, it MUST be interpreted as an empty list.
Example: Consider the network in . If an ALTO client wants to
query the max-reservable-bandwidth between PID1 and PID2, it can submit the
following request.CapabilitiesThe multipart filtered cost map resource extends the capabilities defined
in Section 11.3.2.4 of . The capabilities are defined by a JSON
object of type PVFilteredCostMapCapabilities:;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
]]>with fields:
cost-type-names:
The cost-type-names field MUST only 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 Information
Resource Directory's meta field.
cost-constraints:
If the cost-type-names field includes the Path Vector cost type,
cost-constraints field MUST be false or not present unless specifically
instructed by a future document.
testable-cost-type-names:
If the cost-type-names field includes the Path Vector cost type, the Path
Vector cost type MUST NOT be included in the testable-cost-type-names field
unless specifically instructed by a future document.
ane-property-names:
Defines a list of ANE properties that can be returned. If the field is NOT
present, it MUST be interpreted as an empty list, indicating the ALTO server
cannot provide any ANE property.
UsesThis 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.ResponseThe response MUST indicate an error, using ALTO protocol error handling, as
defined in Section 8.5 of , if the request is invalid.The "Content-Type" header of the response MUST be multipart/related as defined
by with the following parameters:
type:
The type parameter MUST be "application/alto-costmap+json". Note that
permits both parameters with and without the double quotes.
start:
The start parameter is as defined in . If present, it MUST have the
same value as the Content-ID header of the Path Vector part.
boundary:
The boundary parameter is as defined in .
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 value of Content-ID MUST has the format of a Part Resource ID.
The Content-Type MUST be application/alto-costmap+json.
The body of the Path Vector part MUST be a JSON object with the same format as
defined in Section 11.2.3.6 of . The JSON object MUST include the
vtag field in the meta field, which provides the version tag of the
returned cost map. The resource ID of the version tag MUST follow the format of
where resource-id is the resource Id of the Path Vector resource, and
part-resource-id has the same value as 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 IRD.
The Unified Property Map part MUST also include Content-ID and
Content-Type in its header. The value of Content-ID has the format of a
Part Resource ID. The Content-Type MUST be application/alto-propmap+json.
The body of the Unified Property Map part is a JSON object with the same
format as defined in Section 4.6 of . 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 . The vtag of the Path Vector part MUST
be included in the dependent-vtags. 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 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
. The EntityProps 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 in the request.
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.According to , the Path Vector part, whose media type is
the same as the type parameter of the multipart response message, is the root
object. Thus, it is the element 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 put as the first part, followed by the Property
Map part. When doing so, an ALTO server MAY NOT set the start parameter, which
implies the first part is the root object.Example: Consider the network in . The response of the example
request in is as follows, where ANE1 represents the
aggregation of all the switches in the network.Multipart Endpoint Cost Service for Path VectorThis document introduces a new ALTO resource called multipart endpoint cost
resource, which allows an ALTO server to provide other ALTO resources associated
to the endpoint cost resource in the same response.Media TypeThe media type of the multipart endpoint cost resource is
multipart/related;type=application/alto-endpointcost+json.HTTP MethodThe multipart endpoint cost resource is requested using the HTTP POST method.Accept Input ParametersThe input parameters of the multipart endpoint cost resource are supplied in the
body of an HTTP POST request. This document extends the input parameters to an
endpoint cost map, which is defined as a JSON object of type ReqEndpointCost in
Section 11.5.1.3 in RFC 7285 , with a data format indicated by the
media type application/alto-endpointcostparams+json, which is a JSON object of
type PVEndpointCostParams, where;]
} PVReqEndpointcost : ReqEndpointcost;
]]>with fields:
ane-property-names:
This document defines the ane-property-names in PVReqEndpointcost as the
same as in PVReqFilteredCostMap. See .
Example: Consider the network in . If an ALTO client wants to
query the max-reservable-bandwidth between eh1 and eh2, it can submit the
following request.CapabilitiesThe capabilities of the multipart endpoint cost resource are defined by a JSON
object of type PVEndpointcostCapabilities, which is defined as the same as
PVFilteredCostMapCapabilities. See .UsesIf this resource supports persistent-entity-id, it MUST also include the
defining resources of persistent ANEs that may appear in the response.ResponseThe response MUST indicate an error, using ALTO protocol error handling, as
defined in Section 8.5 of , if the request is invalid.The "Content-Type" header of the response MUST be multipart/related as defined
by with the following parameters:
type:
The type parameter MUST be "application/alto-endpointcost+json".
start:
The start parameter is as defined in .
boundary:
The boundary parameter is as defined in .
The body MUST consist of two parts:
The Path Vector part MUST include Content-ID and Content-Type in its
header. The value of Content-ID MUST has the format of a Part Resource ID.
The Content-Type MUST be application/alto-endpointcost+json.
The body of the Path Vector part MUST be a JSON object with the same format as
defined in Section 11.5.1.6 of . The JSON object MUST include the
vtag field in the meta field, which provides the version tag of the returned
endpoint cost map. The resource ID of the version tag MUST follow the format of
where resource-id is the resource Id of the Path Vector resource, and
part-resource-id has the same value as the Content-ID of the Path Vector
part.
The Unified Property Map part MUST also include Content-ID and
Content-Type in its header. The value of Content-ID MUST has the format
of a Part Resource ID. The Content-Type MUST be
application/alto-propmap+json.
The body of the Unified Property Map part MUST be a JSON object with the same
format as defined in Section 4.6 of . 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 . The vtag of the Path Vector part MUST
be included in the dependent-vtags. 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 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
. The EntityProps 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 in the request.
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.According to , the Path Vector part, whose media type is
the same as the type parameter of the multipart response message, is the root
object. Thus, it is the element 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 put as the first part, followed by the Property
Map part. When doing so, an ALTO server MAY NOT set the start parameter, which
implies the first part is the root object.Example: Consider the network in . The response of the example
request in is as follows.ExamplesThis section lists some examples of Path Vector queries and the corresponding
responses. Some long lines are truncated for better readability.Example: Information Resource DirectoryTo give a comprehensive example of the extension defined in this document, we
consider the network in . Assume that the ALTO server provides the
following information resources:
my-default-networkmap: A Network Map resource which contains the PIDs in the
network.
filtered-cost-map-pv: A Multipart Filtered Cost Map resource for Path Vector,
which exposes the max-reservable-bandwidth property for the PIDs in
my-default-networkmap.
ane-props: A filtered Unified Property resource that exposes the
information for persistent ANEs in the network.
endpoint-cost-pv: A Multipart Endpoint Cost Service for Path Vector, which
exposes the max-reservable-bandwidth and the persistent-entity-id properties.
update-pv: An Update Stream service, which provides the incremental update
service for the endpoint-cost-pv service.
Below is the Information Resource Directory of the example ALTO server. To
enable the extension defined in this document, the path-vector cost type
() is defined in the cost-types of the meta field, and is
included in the cost-type-names of resources filetered-cost-map-pv and
endpoint-cost-pv.Example: Multipart Filtered Cost MapThe 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
for the Path Vector but not the ANE properties.The response consists of two parts. The first part returns the array of ANEName
for each source and destination pair. There are two ANEs, where L1 represents
the interconnection link L1, and L2 represents the interconnection link L2.The second part returns an empty Property Map. Note that the ANE entries are
omitted since they have no properties (See Section 3.1 of
).Example: Multipart Endpoint Cost ResourceThe 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
property for two source and destination pairs: 192.0.4.2 -> 192.0.2.2 and
192.0.4.2 -> 192.0.5.2.The response consists of two parts. The first part returns the array of ANEName
for each valid source and destination pair. As one can see in , flow
192.0.4.2 -> 192.0.2.2 traverses NET2, L1 and NET1, and flow 192.0.4.2 ->
192.0.5.2 traverses NET2, L2 and NET3.The second part returns the requested properties of ANEs. Assume NET1, NET2 and NET3 has
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 there are no
prior reservation 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 the ANEName 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 of NET1 and NET3 are ane-props.ane:MEC1 and
ane-props.ane:MEC2 respectively.As mentioned in , an advanced ALTO server may obfuscate the
response in order 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 of AGGR1 takes the value of L1, which
is smaller than that of NET1, and the persistent-entity-id of AGGR1 takes
the value of NET1. The properties of AGGR2 are computed in a similar way and
the obfuscated response is as shown below. Note that the obfuscation of Path
Vector responses is implementation-specific and is out of the scope of this
document, and developers may refer to for further references.Example: Incremental UpdatesIn this example, an ALTO client subscribes to the incremental update for the
multipart endpoint cost resource endpoint-cost-pv.
}
}
}
]]>Based on the server-side process defined in , the ALTO server will
send the control-uri first using Server-Sent Event (SSE), followed by the full
response of the multipart message.
data: --example-3
data: Content-ID: propmap
data: Content-Type: application/alto-propmap+json
data:
data:
data: --example-3--
]]>When the contents change, the ALTO server will publish the updates for each node
in this tree separately.
event: application/merge-patch+json, ecspvsub1.propmap
data:
]]>Compatibility with Other ALTO ExtensionsCompatibility with Legacy ALTO Clients/ServersThe multipart filtered cost map resource and the multipart endpoint cost
resource has no backward compatibility issue 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 problem.Compatibility with Multi-Cost ExtensionThe extension defined in this document is NOT compatible with the multi-cost
extension . The reason is that if a resource supports both the
extension defined in this document and the multi-cost extension, the media type
of this resource depends on the selection of cost types: if the path vector cost
type is selected, the media type of the response is either multipart/related;
type=application/alto-costmap+json or multipart/related;
type=application/alto-endpointcost+json; if the path vector cost type is not
selected, the media type of the response is either
application/alto-costmap+json or application/alto-endpointcost+json.Note that this problem may happen when an ALTO information resource supports
multiple cost types, even if it does not enable the multi-cost extension. Thus,
has specified that if an ALTO information resource enables the
extension defined in this document, the path vector cost type MUST be the only
cost type in the cost-type-names capability of this resource.Compatibility with Incremental UpdateALTO clients and servers MUST follow the specifications given in Section 5.2 of
{{RFC8895} to support incremental updates for a Path Vector resource.Compatibility with Cost CalendarThe extension specified in this document is compatible with the Cost Calendar
extension . 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
(maxresbw), 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
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 for details).General DiscussionsConstraint Tests for General Cost TypesThe constraint test is a simple approach to query the data. It allows users to
filter the query result by specifying some boolean tests. This approach is
already used in the ALTO protocol. and allow ALTO
clients to specify the constraints and or-constraints tests to better
filter the result.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 there are some existing
implementations already (the authors have not done an exhaustive search to
determine whether there are such implementations). One avenue to develop such a
language may be to explore extending current query languages like XQuery
or 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.General Multi-Resource QueryQuerying multiple ALTO information resources continuously is a general
requirement. Enabling such a capability, however, must address the general
issues like efficiency and consistency. The incremental update extension
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.This extension gives an example of using a multipart message to encode two
specific ALTO information resources: a filtered cost map or an endpoint cost
map, 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 the direction of extending the SSE mechanism as
used in the incremental update extension , or upgrading to HTTP/2
and HTTP/3 , which provides the ability to
multiplex queries and to allow servers proactively send related information
resources.Defining a general multi-resource query mechanism is out of the scope of this
document.Security ConsiderationsThis document is an extension of the base ALTO protocol, so the Security
Considerations of the base ALTO protocol fully apply when this
extension is provided by an ALTO server.The Path Vector extension requires additional scrutiny on three security
considerations discussed in the base protocol: confidentiality of ALTO
information (Section 15.3 of ), potential undesirable guidance from
authenticated ALTO information (Section 15.2 of ), and availability
of ALTO service (Section 15.5 of ).For confidentiality of ALTO information, a network operator should be aware of
that this extension may introduce a new risk: the Path Vector information 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
ALTO client may detect the bottleneck link and start a distributed
denial-of-service (DDoS) attack involving minimal flows to conduct the
in-network congestion.To mitigate this risk, the ALTO server should consider protection mechanisms to
reduce information exposure or obfuscate the real information, in particular,
in settings where the network and the application do not belong to the same
trust domain. For example, in the multi-flow bandwidth reservation use case as
introduced in , only the available bandwidth of the shared
bottleneck link is crucial, and the ALTO server may only preserve the critical
bottlenecks and can change the order of links appearing in the Path Vector
response.However, arbitrary reduction and obfuscation of information exposure may
potentially introduce a risk on the integrity of the ALTO information, leading to
infeasible or suboptimal decisions of ALTO clients,To mitigate this risk, if an ALTO client finds that the traffic distribution
based on the Path Vector information is not feasible (e.g., causing constant
congestion) or not better than a distribution which does not fully conform to
the information (e.g., by randomly choosing the source/destination for certain
flows), it can follow the protection strategies for potential undesirable
guidance from authenticated ALTO information, specified in Section 15.2.2 of RFC
7285 . While repeatedly sending the same query can potentially detect
the integrity problem for certain obfuscation methods (e.g., those based on time
or randomness) under certain network conditions (e.g., where the routing and ANE
properties are stable), an ALTO client must be aware that this behavior may be
considered as a denial-of-service attack on the server and may lead to
the rejection of further requests from the client.On the other hand, this risk can also be mitigated from the server side. While
the implementation of an ALTO server is beyond the scope of this document,
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 or obfuscation protocols
.For availability of ALTO service, an ALTO server should be cognizant that using
Path Vector extension might have a new risk: frequent requesting for Path
Vectors might conduct intolerable increment of the server-side computation and
storage, which can break the ALTO server. For example, if an ALTO server
implementation dynamically computes the Path Vectors for each requests, the
service providing 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 optimizations such as
precomputation-and-projection mechanisms to reduce the overhead for
processing each query. Also, an ALTO server may also protect itself from
malicious clients by monitoring the behaviors of clients and stopping serving
clients with suspicious behaviors (e.g., sending requests at a high frequency).IANA ConsiderationsALTO Entity Domain Type RegistryThis document registers a new entry to the ALTO Domain Entity Type Registry, as
instructed by Section 12.2 of . The new entry
is as shown below in .
ALTO Entity Domain Type Registry
Identifier
Entity Address Encoding
Hierarchy & Inheritance
ane
See
None
Identifier:
See .
Entity Identifier Encoding:
See .
Hierarchy:
None
Inheritance:
None
Media Type of Defining Resource:
See .
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.
Applications and ALTO service providers using addresses of ANEs will be made
aware of how (or if) the addressing scheme relates to private information and
network proximity, in further iterations of this document.
ALTO Entity Property Type RegistryTwo initial entries are registered to the ALTO Domain ane in the ALTO Entity
Property Type Registry, as instructed by Section 12.3 of
. The two new entries are shown below in
.
Initial Entries for ane Domain in the ALTO Entity Property Types Registry
Identifier
Intended Semantics
max-reservable-bandwidth
See
persistent-entity-id
See
AcknowledgmentsThe authors would like to thank discussions with Andreas
Voellmy, Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Qiao Xiang, Tianyuan Liu,
Xiao Shi, Xin Wang, and Yan Luo. The authors thank Greg Bernstein (Grotto Networks),
Dawn Chen (Tongji University), Wendy Roome, and Michael Scharf for
their contributions to earlier drafts.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Application-Layer Traffic Optimization (ALTO) ProtocolApplications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps.This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks.The MIME Multipart/Related Content-typeThis document defines the Multipart/Related content-type and provides examples of its use. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Multi-Cost Application-Layer Traffic Optimization (ALTO)The Application-Layer Traffic Optimization (ALTO) protocol, specified in RFC 7285, defines several services that return various metrics describing the costs between network endpoints.This document defines a new service that allows an ALTO Client to retrieve several cost metrics in a single request for an ALTO filtered cost map and endpoint cost map. In addition, it extends the constraints to further filter those maps by allowing an ALTO Client to specify a logical combination of tests on several cost metrics.Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.Application-Layer Traffic Optimization (ALTO) Cost CalendarThis document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.ALTO extension: Entity Property MapsThis document extends the base Application-Layer Traffic Optimization (ALTO) Protocol by generalizing the concept of "endpoint properties" to generic types of entities, and by presenting those properties as maps, similar to the network and cost maps in the base ALTO protocol. The protocol is extended in two major directions. First, from endpoints restricted to IP addresses to entities covering a wider and extensible set of objects; second, from properties on specific endpoints to entire entity property maps. These extensions introduce additional features allowing entities and property values to be specific to a given information resource. This is made possible by a generic and flexible design of entity and property types.Informative ReferencesNetwork Element Service Specification TemplateThis document defines a framework for specifying services provided by network elements, and available to applications, in an internetwork which offers multiple qualities of service. The document first provides some necessary context -- including relevant definitions and suggested data formats -- and then specifies a "template" which service specification documents should follow. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.Hypertext Transfer Protocol Version 2 (HTTP/2)This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.Hypertext Transfer Protocol Version 3 (HTTP/3)The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3. DO NOT DEPLOY THIS VERSION OF HTTP DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This version is still a work in progress. For trial deployments, please use earlier versions. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-http.ALTO Performance Cost MetricsCost metric is a basic concept in Application-Layer Traffic Optimization (ALTO), and different applications may use different cost metrics. Since the ALTO base protocol (RFC 7285) defines only a single cost metric (i.e., the generic "routingcost" metric), if an application wants to issue a cost map or an endpoint cost request to determine the resource provider that offers better delay performance, the base protocol does not define the cost metric to be used. This document addresses the issue by introducing network performance metrics, including network delay, jitter, packet loss rate, hop count, and bandwidth. There are multiple sources (e.g., estimation based on measurements or service-level agreement) to derive a performance metric. This document introduces an additional "cost-context" field to the ALTO "cost-type" field to convey the source of a performance metric.User Plane Protocol and Architectural Analysis on 3GPP 5G SystemThis document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side.Use of ALTO for Determining Service EdgeService providers are starting to deploy and interconnect computing capabilities across the network for hosting network functions and applications. In distributed computing environments, both computing and topological information are necessary in order to determine the more convenient infrastructure where to deploy such a service or application. This document raises an initial approach towards the use of ALTO to provide such information and assist in the selection of proper execution environments.Delivering Functions over Networks: Traffic and Performance Optimization for Edge Computing using ALTOAs the rapid development of the Internet, huge amounts of data are being generated. To satisfy user demands, service providers deploy services near the edge networks. In order to achieve better performances, computing functions and user traffic need to be scheduled properly. However, it is challenging to efficiently schedule resources among the distributed edge servers due to the lack of underlying information, e.g., network topology, traffic distribution, link delay/bandwidth, utilization/capability of computing servers. In this document, we employ the ALTO protocol to help deliver functions and schedule traffic within the edge computing platform. The protocol will provide information of multiple resources for the distributed edge computing platform. The usage of ALTO will improve the efficiency of function delivery in edge computing.MoWIE for Network Aware ApplicationWith the quick deployment of 5G networks in the world, cloud based interactive services such as clouding gaming have gained substantial attention and are regarded as potential killer applications. To ensure users' quality of experience (QoE), a cloud interactive service may require not only high bandwidth (e.g., high-resolution media transmission) but also low delay (e.g., low latency and low lagging). However, the bandwidth and delay experienced by a mobile and wireless user can be dynamic, as a function of many factors, and unhandled changes can substantially compromise users' QoE. In this document, we investigate network-aware applications (NAA), which realize cloud based interactive services with improved QoE, by efficient utilization of Mobile and Wireless Information Exposure (MoWIE) . In particular, this document demonstrates, through realistic evaluations, that mobile network information such as MCS (Modulation and Coding Scheme) can effectively expose the dynamicity of the underlying network and can be made available to applications through MoWIE; using such information, the applications can then adapt key control knobs such as media codec scheme, encapsulation and application logical function to minimize QoE deduction. Based on the evaluations, we discuss how MoWIE can be a systematic extension of the ALTO protocol, to expose more lower-layer and finer grain network dynamics.XQuery 3.1: An XML Query LanguageThe JSON Query languageToward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource DiscoveryYale UniversityTongji UniversityTongji UniversityTongji UniversityESNetIBM T.J. Watson Research CenterESNetCaltechYale UniversityAn objective-driven on-demand network abstraction for adaptive applicationsSichuan UniversityYale UniversityTongji UniversityYale UniversityTsinghua UniversityFine-grained, multi-domain network resource abstraction as a fundamental primitive to enable high-performance, collaborative data sciencesYale UniversityTongji UniversityTongji UniversityTongji UniversityESNetIBM T.J. Watson Research CenterESNetCaltechYale UniversityOptimizing in the dark: Learning an optimal solution through a simple request interfaceYale UniversityTongji UniversityYale UniversityIBM T.J. Watson Research CenterShanghai Jiao Tong UniversityYale UniversityServices - SENSECERN - LHCChanges since -12Revision -13
changes the abstract based on the chairs' reviews
integrates Richard's responds to WGLC reviews
Changes since -11Revision -12
clarifies the definition of ANEs in a similar way as how Network Elements is
defined in
restructures several paragraphs that are not clear (Sec 3, Path Vector bullet, Sec 4.2, Sec 5.1.3, Sec 6.2.4, Sec 6.4.2, Sec 9.3)
uses ALTO Entity Domain Type Registry
Changes since -10Revision -11
replaces "part" with "components" in the abstract;
identifies additional requirements (AR) derived from the flow scheduling
example, and introduces how the extension addresses the additional
requirements
fixes the inconsistent use of "start" parameter in multipart responses;
specifies explicitly how to handle "cost-constraints";
uses the latest IANA registration mechanism defined in
;
renames persistent-entities to persistent-entity-id;
makes application/alto-propmap+json as the media type of defining resources
for the ane domain;
updates the examples;
adds the discussion on ephemeral and persistent ANEs.
Changes since -09Revision -10
revises the introduction which
extends the scope where the PV extension can be applied beyond the "path
correlation" information
brings back the capacity region use case to better illustrate the problem
revises the overview to explain and defend the concepts and decision choices
fixes inconsistent terms, typos
Changes since -08This revision
fixes a few spelling errors
emphasizes that abstract network elements can be generated on demand in both
introduction and motivating use cases
Changes Since Version -06
We emphasize the importance of the path vector extension in two aspects:
It expands the problem space that can be solved by ALTO, from preferences
of network paths to correlations of network paths.
It is motivated by new usage scenarios from both application's and
network's perspectives.
More use cases are included, in addition to the original capacity region use
case.
We add more discussions to fully explore the design space of the path vector
extension and justify our design decisions, including the concept of abstract
network element, cost type (reverted to -05), newer capabilities and the
multipart message.
Fix the incremental update process to be compatible with SSE -16 draft, which
uses client-id instead of resource-id to demultiplex updates.
Register an additional ANE property (i.e., persistent-entities) to cover all
use cases mentioned in the draft.