ALTO Transport Information Publication Service
draft-ietf-alto-new-transport-06
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Roland Schott , Y. Richard Yang , Kai Gao , Lauren Delwiche , Lachlan Keller | ||
| Last updated | 2023-02-23 (Latest revision 2023-02-21) | ||
| Replaces | draft-schott-alto-new-transport, draft-schott-alto-new-transport-push | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews |
IOTDIR Telechat review
(of
-17)
by Wesley Eddy
Ready w/issues
GENART Last Call review
(of
-15)
by Linda Dunbar
Ready w/issues
ARTART Early review
(of
-07)
by Spencer Dawkins
Ready w/issues
ARTART Early review
(of
-01)
by Spencer Dawkins
Ready w/issues
|
||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Associated WG milestone |
|
||
| Document shepherd | Mohamed Boucadair | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | mohamed.boucadair@orange.com |
draft-ietf-alto-new-transport-06
ALTO Working Group R. Schott
Internet-Draft Deutsche Telekom
Intended status: Standards Track Y. Yang
Expires: 24 August 2023 Yale University
K. Gao
Sichuan University
L. Delwiche
L. Keller
Yale University
20 February 2023
ALTO Transport Information Publication Service
draft-ietf-alto-new-transport-06
Abstract
The ALTO protocol (RFC 7285) leverages HTTP/1.x and is designed for
the simple, sequential request-reply use case, in which an ALTO
client requests a sequence of information resources, and the server
responds with the complete content of each resource one at a time.
ALTO/SSE (RFC 8895) defines a multiplexing protocol on top of
HTTP/1.x, so that the server can incrementally push resource updates
to the client whenever monitored network information resources
change, allowing the client to monitor multiple resources at the same
time. However, HTTP/2 and later versions already support concurrent,
non-blocking transport of multiple streams in the same HTTP
connection.
To take advantage of newer HTTP features, this document introduces
the ALTO Transport Information Publication Service (TIPS). TIPS
allows the naming of (i.e., assigning resource identifiers to)
individual incremental updates to multiple ALTO information
resources, and the distribution of those names. It gives an ALTO
client the capability to explicitly request (pull) a specific
incremental update. It also provides an ALTO server the capability
to push a specific incremental update. This document defines TIPS as
a service, with client pull and server push.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Schott, et al. Expires 24 August 2023 [Page 1]
Internet-Draft ALTO TIPS February 2023
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 August 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. TIPS Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Component Terminology . . . . . . . . . . . . . . . . . . 5
2.2. TIPS Workflow . . . . . . . . . . . . . . . . . . . . . . 7
2.3. TIPS With HTTP/1.x . . . . . . . . . . . . . . . . . . . 9
3. TIPS Information Resources . . . . . . . . . . . . . . . . . 9
3.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Transport Information Publication Service . . . . . . . . . . 10
4.1. TIPS Information Resource Directory . . . . . . . . . . . 10
4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 10
4.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . 10
4.1.3. Uses . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4. Example . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Create Transport State using TIPS . . . . . . . . . . . . 14
4.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Read Transport State using TIPS . . . . . . . . . . . . . 18
4.4. Delete Transport State using TIPS . . . . . . . . . . . . 18
4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18
Schott, et al. Expires 24 August 2023 [Page 2]
Internet-Draft ALTO TIPS February 2023
5. TIPS Queue State Service (QSS) . . . . . . . . . . . . . . . 19
5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19
5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 19
5.3. IRD Capabilities and Uses . . . . . . . . . . . . . . . . 20
5.4. Request . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 20
5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 21
6. TIPS Update Read Service (URS) . . . . . . . . . . . . . . . 21
6.1. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22
6.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22
6.4. Capabilities and Uses . . . . . . . . . . . . . . . . . . 22
6.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 22
6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23
7. TIPS Update Push Service (UPS) . . . . . . . . . . . . . . . 23
7.1. Manage Server Push: Receiver Set . . . . . . . . . . . . 23
7.1.1. Receiver Set Operations . . . . . . . . . . . . . . . 23
7.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Server Push of Incremental Updates . . . . . . . . . . . 27
7.2.1. Server Push . . . . . . . . . . . . . . . . . . . . . 27
7.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . 27
7.3. Server Push Stream Management . . . . . . . . . . . . . . 29
7.3.1. Server -> Client [PUSH_PROMISE for Transport Queue on
Stream SID_tq] . . . . . . . . . . . . . . . . . . . 29
8. Operation and Processing Considerations . . . . . . . . . . . 29
8.1. Considerations for Choosing Updates . . . . . . . . . . . 29
8.2. Considerations for Client Processing Updates . . . . . . 30
8.3. Considerations for Updates to Filtered Cost Maps . . . . 31
8.4. Considerations for Updates to Ordinal Mode Costs . . . . 31
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9.1. TIPS: Denial-of-Service Attacks . . . . . . . . . . . . . 32
9.2. ALTO Client: Update Overloading or Instability . . . . . 32
9.3. Spoofed URI . . . . . . . . . . . . . . . . . . . . . . . 33
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1. application/alto-tips+json Media Type . . . . . . . . . 33
10.2. application/alto-tipsparams+json Media Type . . . . . . 34
10.3. application/alto-tipsqueue+json Media Type . . . . . . . 35
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
12.1. Normative References . . . . . . . . . . . . . . . . . . 36
12.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
Schott, et al. Expires 24 August 2023 [Page 3]
Internet-Draft ALTO TIPS February 2023
1. Introduction
Application-Layer Traffic Optimization (ALTO) provides means for
network applications to obtain network status information. So far,
two transport protocols have been designed: (1) The ALTO base
protocol [RFC7285], which is designed for the simple use case in
which an ALTO client requests a network information resource, and the
server sends the complete content of the requested information
resource to the client; and (2) ALTO/SSE (ALTO Incremental Updates
Using Server-Sent Events) [RFC8895], which is designed for the use
case that an ALTO client indicates to the server that it wants to
receive updates for a set of resources, and the server can then
concurrently, and incrementally push updates to the client whenever
monitored resources change.
Both protocols are designed for HTTP/1.x [RFC9112] and, ideally, they
should be able to automatically take advantage of newer HTTP versions
such as HTTP/2 [RFC9113] and HTTP/3 [RFC9114]. However, there are
issues with both protocols when HTTP moves to higher versions. First
consider the ALTO base protocol, which is designed to transfer only
complete information resources. Hence, a client can run the base
protocol on top of HTTP/2 or HTTP/3 to request multiple information
resources concurrently, in concurrent streams, but each request must
be for a complete information resource; there is no capability of
transferring incremental updates. Hence, there can be large overhead
when the client already has an information resource and then there
are small changes to the resource. Next, consider ALTO/SSE.
Although ALTO/SSE can transfer incremental updates, it introduces a
customized multiplexing protocol on top of HTTP, assuming a total-
order message channel from the server to the client. The
multiplexing design does not provide naming (i.e., providing resource
identifier) to individual incremental updates. Hence, the design
cannot use concurrent per-stream server push or non-blocking per-
stream client pull, available in HTTP/2 and HTTP/3, because both
cases require the resource identifier. Additionally, ALTO/SSE is a
push-only protocol, which denies the client flexibility in choosing
how and when it receives updates.
This document introduces a new ALTO service called the transport
information publication service (TIPS), which allows an ALTO server
to publish the naming of individual incremental updates to multiple
ALTO information resources. TIPS gives an ALTO client the new
capability to explicitly, concurrently (non-blocking) request (pull)
specific incremental updates using native HTTP/2 or HTTP/3, while
still functioning for HTTP/1.x. It also provides an ALTO server the
new capability to concurrently push specific incremental updates
using native HTTP/2 or HTTP/3 server push.
Schott, et al. Expires 24 August 2023 [Page 4]
Internet-Draft ALTO TIPS February 2023
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. TIPS Overview
2.1. Component Terminology
This document uses the following components:
Network information resource:
A piece of retrievable information about network state, per
[RFC7285].
Transport state (ts):
Defined in this document to be the container of transport
information that is information about the network information
resource. Though the transport state may include other transport
information, it has two basic components: updates queue (uq) and
receiver set (rs).
Updates queue (uq):
Contains a sequence of incremental updates about a network
information resource. Each incremental update is assigned a
sequence number, and a URI can be constructed using the sequence
number. A static network information resource (e.g., Cost Map,
Network Map) may need only a single updates queue. A dynamic
network information resource (e.g., Filtered Cost Map) may create
an updates queue within the transport state for each unique filter
request.
Receiver set (rs):
The receiver set contains the set of clients who have requested to
receive server push updates.
Information Resource Directory (IRD):
Requested by an ALTO client to discover available information
resources provided by an ALTO server, per [RFC7285]. Each entry
in an IRD indicates a URI at which an ALTO server accepts
requests, and returns either an information resource or an
information resource directory that references additional
information resources. An ALTO server's IRD MAY define one or
more transport information publication services, which ALTO
clients use to request new TIPS instances.
Schott, et al. Expires 24 August 2023 [Page 5]
Internet-Draft ALTO TIPS February 2023
Transport Information Publication Service (TIPS):
Allows an ALTO client to create transport state, read transport
state, and delete the transport state (from client's view) for an
ALTO information resource.
TIPS Queue State Service (QSS):
Allows an ALTO client to read the updates queue.
TIPS Update Read Service (URS):
Allows an ALTO client to read the content of a an update item from
the updates queue
TIPS Update Push Service (UPS):
Allows an ALTO client to receive an element pushed by the ALTO
server.
Figure 1 shows an example illustrating the TIPS abstraction. Each
ALTO client (Client 1, Client 2, or Client 3) maintains a single HTTP
connection with the ALTO server.
Network Information Resource:
a) Static resource (#1) such as NetworkMap
b) Filterable resource (#3) such as FilteredCostMap
+-------------+
+-----------+ +--------------+ | Dynamic | +-----------+
| Routing | | Provisioning | | Network | | External |
| Protocols | | Policy | | Information | | Interface |
+-----------+ +--------------+ +-------------+ +-----------+
| | | |
| | | |
+----------------------------------------------------------------------+
| ALTO Server |
| |
| +------------------------------------------------------------------+ |
| | Network Information | |
| | | |
| | +-------------+ +-------------+ +-------------+ | |
| | | Information | | Information | | Information | | |
| | | Resource #1 | | Resource #2 | | Resource #3 | | |
| | +-------------+ +-------------+ +-------------+ | |
| | | / \ | |
| +-----|--------------------------------------/-------\-------------+ |
| | / \ |
| +-----|------------------------------------/-----------\-----------+ |
| | | Transport Information / \ | |
Schott, et al. Expires 24 August 2023 [Page 6]
Internet-Draft ALTO TIPS February 2023
| | | / \ | |
| | +--------+ +--------+ +--------+ | |
| | | ts1 |----+ +-----| ts2 | | ts3 |---+ | |
| | +--------+ | | +--------+ +--------+ | | |
| | | | | | | | | |
| | +--------+ +--------+ +--------+ +--------+ +--------+ +--------+| |
| | | ts1/uq | | ts1/rs | | ts2/uq | | ts2/rs | | ts3/uq | | ts3/rs || |
| | +--------+ +--------+ +--------+ +--------+ +--------+ +--------+| |
| +----|\---------/\---------|---------/---------------|-------------+ |
| | \ / \ | / | |
+------|--\-----/----\-------|-------/-----------------|---------------+
| \ / \ | / |
| +-/-----+ \ | / |
| / \ \ | / A single | A single
| / ==\==\===|===/== HTTP/2 or /3 ==|== HTTP/1.x
| / \ \ | / connection | connection
+----------+ +----------+ +----------+
| Client 1 | | Client 2 | | Client 3 |
+----------+ +----------+ +----------+
tsi = transport state information i
tsi/uq = incremental updates queue associated with tsi
tqi/rs = receiver set of transport queue i (for server push)
Figure 1: ALTO Transport Information.
2.2. TIPS Workflow
The intended use case of TIPS is to run it as a service inside an
HTTP/2 or HTTP/3 connection (though it can run inside an HTTP/1.x
connection, without server push functionality). Specifically, an
ALTO client opens an HTTP connection with an ALTO server, and uses
TIPS to create (or at least receive a view of) a transport state at
the server for each network information resource that the client
wants to monitor. The transport state provides (1) the base URI that
the server will host incremental updates for the information resource
and (2) the start sequence number that the server will order the
updates. The server will assign each additional update with a
consecutive sequence number.
In the simplest use case, the transport state provides enough
information for the client to continuously pull each additional
update, resulting in the following workflow:
Schott, et al. Expires 24 August 2023 [Page 7]
Internet-Draft ALTO TIPS February 2023
Client TIPS URS
o . .
| Open HTTP connection . .
|-------------------------------------->| .
| . .
| POST to create/receive transport . .
| state for resource 1 . .
| ------------------------------------> | .
| <updates-queue-uri1>, <start-seq> . .
|<------------------------------------- | .
| . .
| GET <updates-queue-uri1>/content/<start-seq> .
| ------------------------------------------------->|
| update <start-seq> content . .
|<------------------------------------------------->|
| . .
| GET <updates-queue-uri1>/content/<start-seq+1> .
| ------------------------------------------------->|
| update <start-seq+1> content . .
|<------------------------------------------------->|
|
| DELETE transport state for resource 1 .
|-------------------------------------> |
|
| Close HTTP connection .
|-------------------------------------->|
o
TIPS: Transport Information Publication Service
URS : Update Read Service
Figure 2: ALTO TIPS Workflow Supporting Client Pull.
A client that prefers server push can use the following workflow:
Schott, et al. Expires 24 August 2023 [Page 8]
Internet-Draft ALTO TIPS February 2023
Client TIPS UPS
o . .
| Open HTTP connection . .
|-------------------------------------->| .
| . .
| POST to create/receive transport . .
| state for resource 1 and add . .
| self to receiver set . .
| ------------------------------------> | .
| <updates-queue-uri1>, <start-seq> . .
|<------------------------------------- | .
| . .
| PUSH <updates-queue-uri1>/content/<start-seq> .
| <------------------------------------------------ |
| . .
| PUSH <updates-queue-uri1>/content/<start-seq+1> .
| <------------------------------------------------ |
|
| DELETE self from receiver set of .
| resource 1 .
|-------------------------------------> |
|
| Close HTTP connection .
|-------------------------------------->|
o
TIPS: Transport Information Publication Service
UPS : Update Push Service
Figure 3: ALTO TIPS Workflow Supporting Server Push.
2.3. TIPS With HTTP/1.x
While TIPS is designed to take advantage of newer HTTP features, TIPS
still functions with HTTP/1.x for client pull functionality only,
with the limitation that to cancel a long pull request for a resource
update, it cannot send a DELETE request. Additionally, only one
request can be outstanding at a time due to the blocking nature of
HTTP/1.x.
3. TIPS Information Resources
The TIPS framework defines 4 types of service: Transport Information
Publication Service (TIPS), the TIPS Queue State Service (QSS), the
TIPS Update Read Service (URS), and the TIPS Update Push Service
(UPS). This document defines TIPS (Section 4), the QSS (Section 5),
the URS (Section 6), and the UPS (Section 7).
Schott, et al. Expires 24 August 2023 [Page 9]
Internet-Draft ALTO TIPS February 2023
3.1. Notations
This document uses the same syntax and notations as introduced in
Section 8.2 of RFC 7285 [RFC7285] to specify the extensions to
existing ALTO resources and services.
4. Transport Information Publication Service
A TIPS service allows an ALTO client to create transport state, read
transport state and delete the transport state for an ALTO
information resource.
4.1. TIPS Information Resource Directory
An ALTO server's IRD (Information Resource Directory) MAY define one
or more transport information publication services, which ALTO
clients use to request new TIPS instances. An IRD entry defining a
TIPS MUST declare the "media-type", and specify "capabilities" and
"uses" as follows.
4.1.1. Media Type
The media type of the Transport Information Publication Service
resource is "application/alto-tips+json".
4.1.2. Capabilities
The capabilities declaration of TIPS is modelled on that defined in
Section 6.3 of [RFC8895].
Specifically, the capabilities are defined as an object of type
TIPSCapabilities:
object {
IncrementalUpdateMediaTypes incremental-change-media-types;
Boolean support-server-push;
} TIPSCapabilities;
object-map {
ResourceID -> String;
} IncrementalUpdateMediaTypes;
with field:
incremental-change-media-types: If a TIPS can provide updates with
incremental changes for a resource, the "incremental-change-media-
types" field has an entry for that resource-id, and the value is
the supported media types of the incremental change separated by
Schott, et al. Expires 24 August 2023 [Page 10]
Internet-Draft ALTO TIPS February 2023
commas. For the implementation of this specification, this will
be "application/merge-patch+json", "application/json-patch+json",
or "application/merge-patch+json,application/json-patch+json".
Future extensions may define other types of incremental changes.
When choosing the media types to encode incremental updates for a
resource, the server MUST consider the limitations of the
encoding. For example, when a JSON merge patch specifies that the
value of a field is null, its semantics are that the field is
removed from the target and hence the field is no longer defined
(i.e., undefined). This, however, may not be the intended result
for the resource, when null and undefined have different semantics
for the resource. In such a case, the server MUST choose JSON
patch over JSON merge patch if JSON patch is indicated as a
capability of the TIPS. If the server does not support JSON patch
to handle such a case, the server then needs to send a full
replacement.
support-server-push: The "support-server-push" field specifies
whether the given TIPS supports server push. If the "support-
server-push" field is "true", this TIPS will allow a client to
start or stop server push.
4.1.3. Uses
The "uses" attribute MUST be an array with the resource-ids of every
network information resource for which this TIPS can provide service.
This set may be any subset of the ALTO server's network information
resources and may include resources defined in linked IRDs. However,
it is RECOMMENDED that the ALTO server selects a set that is closed
under the resource dependency relationship. That is, if a TIPS'
"uses" set includes resource R1 and resource R1 depends on ("uses")
resource R0, then the TIPS' "uses" set SHOULD include R0 as well as
R1. For example, a TIPS for a cost map SHOULD also provide transport
state for the network map upon which that cost map depends.
4.1.4. Example
Extending the IRD example in Section 8.1 of [RFC8895], below is the
IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and
ALTO TIPS.
Schott, et al. Expires 24 August 2023 [Page 11]
Internet-Draft ALTO TIPS February 2023
"my-network-map": {
"uri": "https://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json",
},
"my-routingcost-map": {
"uri": "https://alto.example.com/costmap/routingcost",
"media-type": "application/alto-costmap+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost"]
}
},
"my-hopcount-map": {
"uri": "https://alto.example.com/costmap/hopcount",
"media-type": "application/alto-costmap+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-hopcount"]
}
},
"my-filtered-cost-map": {
"uri":
"https://alto.example.com/costmap/filtered/constraints",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": true
}
},
"my-simple-filtered-cost-map": {
"uri": "https://alto.example.com/costmap/filtered/simple",
"media-type": "application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"uses": ["my-networkmap"],
"capabilities": {
"cost-type-names": ["num-routingcost", "num-hopcount"],
"cost-constraints": false
}
},
"my-props": {
"uri": "https://alto.example.com/properties",
"media-type": "application/alto-endpointprops+json",
"accepts": "application/alto-endpointpropparams+json",
Schott, et al. Expires 24 August 2023 [Page 12]
Internet-Draft ALTO TIPS February 2023
"capabilities": {
"prop-types": ["priv:ietf-bandwidth"]
}
},
"my-pv": {
"uri": "https://alto.example.com/endpointcost/pv",
"media-type": "multipart/related;
type=application/alto-endpointcost+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"cost-type-names": [ "path-vector" ],
"ane-properties": [ "maxresbw", "persistent-entities" ]
}
},
"update-my-costs": {
"uri": "https://alto.example.com/updates/costs",
"media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json"
},
"support-stream-control": true
}
},
"update-my-costs-tips": {
"uri": "https://alto.example.com/updates-new/costs",
"media-type": "application/alto-tips+json",
"accepts": "application/alto-tipsparams+json",
"uses": [
"my-network-map",
"my-routingcost-map",
"my-hopcount-map",
"my-simple-filtered-cost-map"
],
"capabilities": {
"incremental-change-media-types": {
Schott, et al. Expires 24 August 2023 [Page 13]
Internet-Draft ALTO TIPS February 2023
"my-network-map": "application/json-patch+json",
"my-routingcost-map": "application/merge-patch+json",
"my-hopcount-map": "application/merge-patch+json",
"my-simple-filtered-cost-map":
"application/merge-patch+json"
},
"support-server-push": true
}
},
"update-my-props": {
"uri": "https://alto.example.com/updates/properties",
"media-type": "text/event-stream",
"uses": [ "my-props" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"incremental-change-media-types": {
"my-props": "application/merge-patch+json"
},
"support-stream-control": true
}
},
"update-my-pv": {
"uri": "https://alto.example.com/updates/pv",
"media-type": "text/event-stream",
"uses": [ "my-pv" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"incremental-change-media-types": {
"my-pv": "application/merge-patch+json"
},
"support-stream-control": true
}
}
Note that it is straightforward for an ALTO sever to run HTTP/2 and
support concurrent retrieval of multiple resources such as "my-
network-map" and "my-routingcost-map" using multiple HTTP/2 streams.
The resource "update-my-costs-tips" provides an ALTO TIPS based
connection, and this is indicated by the media-type "application/
alto-tips+json".
4.2. Create Transport State using TIPS
Schott, et al. Expires 24 August 2023 [Page 14]
Internet-Draft ALTO TIPS February 2023
4.2.1. Request
An ALTO client requests that the server sets up transport state for a
given resource by sending an HTTP POST body with the media type
"application/alto-tipsparams+json". That body contains a JSON object
of type TIPSReq, where:
object {
ResourceID resource-id;
[JSONString tag;]
[Object input;]
} TIPSReq;
with the following fields:
resource-id/tag: The resource-id of an ALTO resource and MUST be in
the TIPS' "uses" list (Section 4.1). If the resource-id is a GET-
mode resource with a version tag (or "vtag"), as defined in
Sections 6.3 and 10.3 of [RFC7285], and the ALTO client has
previously retrieved a version of that resource from ALTO, the
ALTO client MAY set the "tag" field to the tag part of the
client's version of that resource. The server MAY use the tag
when creating the updates queue. Note that the client MUST
support all incremental methods from the set announced in the
server's capabilities for this resource. If a client does not
support all incremental methods from the set announced in the
server's capabilities, the client MUST NOT use the TIPS service.
input: If the resource is a POST-mode service that requires input,
the ALTO client MUST set the "input" field to a JSON object with
the parameters that the resource expects.
4.2.2. Response
If the request has any errors, the TIPS service MUST return an HTTP
"400 Bad Request" to the ALTO client; the body of the response
follows the generic ALTO error response format specified in
Section 8.5.2 of [RFC7285]. Hence, an example ALTO error response
has the format:
Schott, et al. Expires 24 August 2023 [Page 15]
Internet-Draft ALTO TIPS February 2023
HTTP/1.1 400 Bad Request
Content-Length: 131
Content-Type: application/alto-error+json
Connection: Closed
{
"meta":{
"code": "E_INVALID_FIELD_VALUE",
"field": "resource-id",
"value": "my-networkmap/#"
}
}
Note that "field" and "value" are optional fields. If the "value"
field exists, the "field" field MUST exist.
* If the TIPS request does not have a "resource-id" field, the error
code of the error message MUST be E_MISSING_FIELD and the "field"
field SHOULD be "resource-id". The TIPS service MUST NOT create
any transport state.
* If the "resource-id" field is invalid or is not associated with
the TIPS, the error code of the error message MUST be
E_INVALID_FIELD_VALUE. The "field" field SHOULD be the full path
of the "resource-id" field, and the "value" field SHOULD be the
invalid resource-id.
* If the resource is a POST-mode service that requires input, the
client MUST set the "input" field to a JSON object with the
parameters that that resource expects. If the "input" field is
missing or invalid, TIPS MUST return the same error response that
resource would return for missing or invalid input (see
[RFC7285]).
The response to a valid request MUST be a JSON object of type
AddTIPSResponse, denoted as media type "application/alto-tips+json":
Schott, et al. Expires 24 August 2023 [Page 16]
Internet-Draft ALTO TIPS February 2023
object {
JSONString transport-state-uri;
TransportState transport-state;
} AddTIPSResponse;
object {
UpdatesQueueMeta updates-queue-meta;
[PushUpdatesMeta push-updates-meta;]
} TransportState;
object {
JSONString uri;
UpdatesQueueStateSummary state-summary;
} UpdatesQueueMeta;
object {
JSONNumber start-seq;
} UpdatesQueueStateSummary;
object {
JSONString uri;
PushUpdatesState state;
} PushUpdatesMeta;
object {
Boolean push-enabled;
[JSONNumber next-seq;]
} PushUpdatesState;
with field:
transport-state-uri: The ALTO client MUST evaluate the URI according
to [RFC3986]. Hence, the transport state may be located at the
same host as the invoking TIPS or on a different host. Let
absolute-transport-state-uri be the absolute URI after resolution.
When creating the URI for the transport state, the TIPS service
MUST NOT use other properties of an HTTP request, such as cookies
or the client's IP address, to determine the transport state.
Furthermore, TIPS MUST NOT reuse a URI for a different object in
the same connection.
It is expected that there is an internal mechanism to map a
transport-state-uri to the transport state to be accessed. For
example, TIPS may assign a unique, internal state id to each
transport state instance. However, the exact mechanism is left to
the TIPS provider.
Schott, et al. Expires 24 August 2023 [Page 17]
Internet-Draft ALTO TIPS February 2023
transport-state/updates-queue-meta/uri: This must be a relative URI
segment. Specifically, let uq-uri denote transport-state/updates-
queue-meta/uri and define absolute-transport-state-uri/uq-uri
absolute-transport-state-uri/uq-uri/number absolute-transport-
state-uri/uq-uri/content/number. Each of them MUST be a valid
URI.
transport-state/updates-queue-meta/state-summary/start-seq: This
MUST be a valid non-negative integer. The start-seq tells the
client where to start reading from the updates queue.
4.3. Read Transport State using TIPS
An ALTO client can read the transport state using the returned
absolute-transport-state-uri (see Section 4.2.2) using the HTTP GET
method. For example, if it is on the same connection as that of the
invoking TIPS, it is
GET <transport-state-uri>
The response to a valid request MUST be a JSON object of type
TransportState defined in Section 4.2, denoted as media type
"application/alto-tips+json".
4.4. Delete Transport State using TIPS
An ALTO client can delete the transport state (from its view) using
the returned absolute-transport-state-uri using the HTTP DELETE
method. Whether or not the server actually deletes the transport is
implementation dependent. A server will not want to delete a
transport state if another client is using it. If the transport
state is on the same connection as that of the invoking TIPS, the
DELETE request looks like:
DELETE <transport-state-uri>
The response to a valid request MUST be 200 if success, and the
corresponding error code if there is any error.
4.5. Example
For simplicity, assume that the ALTO server is using the Basic
authentication. If a client with username "client1" and password
"helloalto" wants to create a transport state of an ALTO Cost Map
resource with resource ID "my-routingcost-map", it can send the
following request:
Schott, et al. Expires 24 August 2023 [Page 18]
Internet-Draft ALTO TIPS February 2023
POST /tips HTTP/1.1
Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json
Content-Length: 41
{
"resource-id": "my-routingcost-map"
}
If the operation is successful, the ALTO server returns the following
message:
HTTP/1.1 200 OK
Content-Type: application/alto-tips+json
Content-Length: 291
{
"transport-state-uri": "/tips/2718281828459",
"transport-state": {
"updates-queue-meta" : {
"uri": "uq",
"state-summary": {
"start-seq": 101
}
},
"push-updates-meta" : {
"uri": "rs",
"state-summary": ["self"],
},
}
}
5. TIPS Queue State Service (QSS)
The TIPS QSS service allows an ALTO client to read the updates queue.
It uses the URI returned in Section 4.
5.1. Media Type
A QSS response uses "application/alto-tipsqueue+json" media type.
5.2. HTTP Method
An ALTO QSS resource is requested using the HTTP GET method.
Schott, et al. Expires 24 August 2023 [Page 19]
Internet-Draft ALTO TIPS February 2023
5.3. IRD Capabilities and Uses
None (QSS does not appear in the IRD).
5.4. Request
An ALTO client reads the queue state using an HTTP GET method, with
the path constructed as:
<updates-queue-complete-uri> :=
<transport-state-uri>/<updates-queue-meta.uri>
specified in Section 4.
5.5. Response
If the transport state is closed, the ALTO server MUST return an
error HTTP message with status code 404 (Not Found) and media type
"application/alto-error+json".
The response from the server, if no error, is the UpdatesQueue object
indicated as "application/alto-tipsqueue+json" media type:
object-map {
Seq -> UpdateItem;
} UpdatesQueue;
object-map {
JSONString media-type;
JSONString tag;
[JSONString link;]
} UpdateItem;
with field:
Seq: A required, positive JSON integer indicating the sequence
number of the incremental update. As JSON allows a large integer
space, when the server reaches the largest integer, the server
SHOULD close the incremental updates queue.
media-type: A required JSON string giving the type of the
incremental update (see [RFC8895]).
tag: A required JSON string which is defined the same way as the
"tag" field of VersionTag (see Section 10.3 of [RFC7285]).
link: An optional JSON string giving an optional link for a client
to directly request a resource as a complete snapshot (not through
incremental updates).
Schott, et al. Expires 24 August 2023 [Page 20]
Internet-Draft ALTO TIPS February 2023
5.6. Example
GET /tips/2718281828459/uq HTTP/1.1
Host: alto.example.com
Accept: application/alto-tipsqueue+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
HTTP/1.1 200 OK
Content-Type: application/alto-tipsqueue+json
Content-Length: 488
{
101 : {
"media-type": "application/alto-costmap+json",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
},
102 : {
"media-type": "application/merge-patch+json",
"tag": "cdf0222x59740b0b2e3f8eb1d4785acd42231bfe"
},
103 : {
"media-type": "application/merge-patch+json",
"tag": "8eb1d4785acd42231bfecdf0222x59740b0b2e3f",
"link": "/tips/2718281828459/snapshot/2e3f"
}
}
An ALTO client can also read the (meta data) of an individual element
in the updates queue. The HTTP method is a GET, and the URI is
constructed by appending the corresponding seq to preceding URI:
<uq-elem-seq-meta> := <updates-queue-complete-uri>/<seq>
6. TIPS Update Read Service (URS)
The TIPS URS service allows an ALTO client to read the content of an
update item from the updates queue.
6.1. Path
The path to the content of an update item resource has the following
format:
<uq-elem-seq> := <updates-queue-complete-uri>/content/<seq>
Schott, et al. Expires 24 August 2023 [Page 21]
Internet-Draft ALTO TIPS February 2023
where updates-queue-complete-uri is specified in Section 5.4.
For example, if the client wants to query the content of the first
update item (with sequence number 101), it can send a request to
"/tips/2718281828459/uq/content/101".
6.2. Media Type
The media type of an Update Item resource MUST be the same as the
"media-type" field of the update item with sequence number seq in the
updates queue.
For example, if the client wants to query the content of the first
update item (with sequence number 101) whose media type is
"application/alto-costmap+json", it must set the "Accept" header to
"application/alto-costmap+json, application/alto-error+json" in the
request.
6.3. HTTP Method
The Update Read Service resource is requested using the HTTP GET
method.
6.4. Capabilities and Uses
None
6.5. Response
If the transport state is closed, the ALTO server MUST return an
error HTTP message with status code 404 (Not Found) and media type
"application/alto-error+json".
Otherwise, let LOW_SEQ and HIGH_SEQ represent the smallest and
largest sequence number in the updates queue of the transport state
respectively. If seq is smaller than LOW_SEQ, the ALTO server MUST
return an error HTTP message with status code 410 (Gone) and media
type "application/alto-error+json". If seq is greater than HIGH_SEQ,
the ALTO server MAY either treat the request as a long polling
request and save it as a pending request; if the server wants to
conduct resource control, the server can return an error code and
indicate the "Re-Try After" headers.
If the request is valid, the response is encoded as a JSON object
whose data format is indicated by the media type.
Schott, et al. Expires 24 August 2023 [Page 22]
Internet-Draft ALTO TIPS February 2023
When a client reads an entry from the updates queue, that entry is
not removed from the queue. This is particularly important if two
clients have access to the same updates queue, as they may be reading
from different places in the queue (depending on the frequency of
client pull and the starting seq the server determined for each
client).
6.6. Example
Assume the client wants to get the contents of updates item 101, the
request is:
GET /tips/2718281828459/uq/content/101 HTTP/1.1
Host: alto.example.com
Accept: application/alto-costmap+json, application/alto-error+json
And the response will be
HTTP/1.1 200 OK
Content-Type: application/alto-costmap+json
Content-Length: 50
{ ... full replacement of my-routingcost-map ... }
7. TIPS Update Push Service (UPS)
The TIPS UPS service allows an ALTO client to receive an element
pushed by the ALTO server.
If a client registers for UPS, it should not request updates via URS
to avoid receiving the same information twice, unless the client does
not receive the expected updates (see Section 9.2).
7.1. Manage Server Push: Receiver Set
7.1.1. Receiver Set Operations
A client starts to receive server push when it is added to the
receiver set. A client can add itself to the receiver set when
creating the transport queue, or add itself explicitly to the
receiver set. A client can read the status of the receiver set and
delete itself from the receiver set to stop server push.
Implicit Create: As a short cut, when creating a transport queue, an
ALTO client can start server push by setting the "incremental-
changes" field to be true when creating a transport queue using the
HTTP POST method with ALTO SSE AddUpdateReq ([RFC8895] Sec. 6.5) as
the parameter:
Schott, et al. Expires 24 August 2023 [Page 23]
Internet-Draft ALTO TIPS February 2023
object {
ResourceID resource-id;
[JSONString tag;]
[Boolean incremental-changes;]
[Object input;]
} AddUpdateReq;
PUT Create: A client can add itself in the receiver set by using the
HTTP PUT method: PUT transport-queue/rs/self
Read: A client can see only itself in the receiver set. The
appearance of self in the receiver set (read does not return "not
exists" error) is an indication that push starts.
Delete: A client can delete itself (stops receiving push) either
explicitly or implicitly.
* Explicit delete: A client deletes itself using the HTTP DELETE
method: DELETE transport-queue/rs/self.
* Implicit delete: Transport queue is connection ephemeral: the
close of connection or stream for the transport queue deletes the
transport queue (from the view) for the client.
7.1.2. Examples
The first example is a client creating a transport queue and starting
server push.
Schott, et al. Expires 24 August 2023 [Page 24]
Internet-Draft ALTO TIPS February 2023
Client -> server request
HEADERS
- END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /tqs
host = alto.example.com
accept = application/alto-error+json,
application/alto-transport+json
content-type = application/alto-transport+json
content-length = 69
DATA
- END_STREAM
{
"resource-id": "my-routingcost-map",
["incremental-push": true]
}
Server -> client response:
HEADERS
- END_STREAM
+ END_HEADERS
:status = 200
content-type = application/alto-transport+json
content-length = 28
DATA
- END_STREAM
{"tq": "/tqs/2718281828459"}
If the client reads the status of the transport queue created above
using the read operation (GET) in the same HTTP connection, the
client should see itself in the receiver set:
Schott, et al. Expires 24 August 2023 [Page 25]
Internet-Draft ALTO TIPS February 2023
Client -> server request
HEADERS
- END_STREAM
+ END_HEADERS
:method = GET
:scheme = https
:path = /tqs/2718281828459
host = alto.example.com
accept = application/alto-error+json,
application/alto-transport+json
Server -> client response:
HEADERS
- END_STREAM
+ END_HEADERS
:status = 200
content-type = application/alto-transport+json
content-length = 519
DATA
- END_STREAM
{ "uq":
[
{"seq": 101,
"media-type": "application/alto-costmap+json",
"tag": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"},
{"seq": 102,
"media-type": "application/merge-patch+json",
"tag": "cdf0222x59740b0b2e3f8eb1d4785acd42231bfe"},
{"seq": 103,
"media-type": "application/merge-patch+json",
"tag": "8eb1d4785acd42231bfecdf0222x59740b0b2e3f",
"link": "/tqs/2718281828459/snapshot/2e3f"}
],
"rs": ["self"]
}
A client can stop incremental push updates from the server to itself
by sending the request:
Schott, et al. Expires 24 August 2023 [Page 26]
Internet-Draft ALTO TIPS February 2023
DELETE /tqs/2718281828459/rs/self HTTP/2
Accept: application/alto-transport+json
HTTP/2 200 OK
7.2. Server Push of Incremental Updates
7.2.1. Server Push
The work flow of server push of individual updates is the following:
* Initialization: the first update pushed from the server to the
client MUST be the later of the following two: (1) the last
independent update in the incremental updates queue; and (2) the
following entry of the entry that matches the tag when the client
creates the transport queue. The client MUST set
SETTINGS_ENABLE_PUSH to be consistent.
* Push state: the server MUST maintain the last entry pushed to the
client (and hence per client, per connection state) and schedule
next update push accordingly.
* Push management: The client MUST NOT cancel (RST_STREAM) a
PUSH_PROMISE to avoid complex server state management.
7.2.2. Examples
A client can wait for the server for incremental push, where the
server first sends PUSH_PROMISE, for the first example in Sec. 2.2:
Server -> client PUSH_PROMISE in current stream:
PUSH_PROMISE
- END_STREAM
Promised Stream 4
HEADER BLOCK
:method = GET
:scheme = https
:path = /tqs/2718281828459/uq/101
host = alto.example.com
accept = application/alto-error+json,
application/alto-costmap+json
Server -> client content Stream 4:
HEADERS
+ END_STREAM
Schott, et al. Expires 24 August 2023 [Page 27]
Internet-Draft ALTO TIPS February 2023
+ END_HEADERS
:status = 200
content-type = application/alto-costmap+json
content-length = 539
DATA
+ END_STREAM
{
"meta" : {
"dependent-vtags" : [{
"resource-id": "my-network-map",
"tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
}],
"cost-type" : {
"cost-mode" : "numerical",
"cost-metric": "routingcost"
},
"vtag": {
"resource-id" : "my-routingcost-map",
"tag" : "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
}
},
"cost-map" : {
"PID1": { "PID1": 1, "PID2": 5, "PID3": 10 },
"PID2": { "PID1": 5, "PID2": 1, "PID3": 15 },
"PID3": { "PID1": 20, "PID2": 15 }
}
}
Server -> client PUSH_PROMISE in current stream:
PUSH_PROMISE
- END_STREAM
Promised Stream 6
HEADER BLOCK
:method = GET
:scheme = https
:path = /tqs/2718281828459/uq/102
host = alto.example.com
accept = application/alto-error+json,
application/merge-patch+json
Server -> client content Stream 6
HEADERS
+ END_STREAM
+ END_HEADERS
:status = 200
Schott, et al. Expires 24 August 2023 [Page 28]
Internet-Draft ALTO TIPS February 2023
content-type = application/merge-patch+json
content-length = 7
DATA
+ END_STREAM
{ ... }
7.3. Server Push Stream Management
7.3.1. Server -> Client [PUSH_PROMISE for Transport Queue on Stream
SID_tq]
The server push MUST satisfy the following requirements:
* PUSH_PROMISE MUST be sent in stream SID_tq to serialize to allow
the client to know the push order;
* Each PUSH_PROMISE chooses a new server-selected stream ID, and the
stream is closed after push.
8. Operation and Processing Considerations
8.1. Considerations for Choosing Updates
TIPS should be cognizant of the effects of its update schedule, which
includes both the choice of timing (i.e., when/what to trigger an
update on the updates queue) and the choice of message format (i.e.,
given an update, send a full replacement or an incremental change).
In particular, the update schedule can have effects on both the
overhead and the freshness of information. To minimize overhead,
TIPS may choose to batch a sequence of updates for resources that
frequently change by cumulative updates or a full replacement after a
while. TIPS should be cognizant that batching reduces the freshness
of information. The server should also consider the effect of such
delays on client behaviors.
For incremental updates, this design allows both JSON patch and JSON
merge patch for incremental changes. JSON merge patch is clearly
superior to JSON patch for describing incremental changes to cost
maps, endpoint costs, and endpoint properties. For these data
structures, JSON merge patch is more space efficient, as well as
simpler to apply. There is no advantage allowing a server to use
JSON patch for those resources.
The case is not as clear for incremental changes to network maps.
Schott, et al. Expires 24 August 2023 [Page 29]
Internet-Draft ALTO TIPS February 2023
First, consider small changes, such as moving a prefix from one PID
to another. JSON patch could encode that as a simple insertion and
deletion, while JSON merge patch would have to replace the entire
array of prefixes for both PIDs. On the other hand, to process a
JSON patch update, the ALTO client would have to retain the indexes
of the prefixes for each PID. Logically, the prefixes in a PID are
an unordered set, not an array; aside from handling updates, a client
has no need to retain the array indexes of the prefixes. Hence, to
take advantage of JSON patch for network maps, ALTO clients would
have to retain additional, otherwise unnecessary, data.
Second, consider more involved changes, such as removing half of the
prefixes from a PID. JSON merge patch would send a new array for
that PID, while JSON patch would have to send a list of remove
operations and delete the prefix one by one.
Therefore, each TIPS may decide on its own whether to use JSON merge
patch or JSON patch according to the changes in network maps.
8.2. Considerations for Client Processing Updates
In general, when an ALTO client receives a full replacement for a
resource, the ALTO client should replace the current version with the
new version. When an ALTO client receives an incremental change for
a resource, the ALTO client should apply those patches to the current
version of the resource.
However, because resources can depend on other resources (e.g., cost
maps depend on network maps), an ALTO client MUST NOT use a dependent
resource if the resource on which it depends has changed. There are
at least two ways an ALTO client can do that. The following
paragraphs illustrate these techniques by referring to network and
cost map messages, although these techniques apply to any dependent
resources.
Note that when a network map changes, the update stream server MUST
send the network map update message before sending the updates for
the dependent cost maps.
One approach is for the ALTO client to save the network map update
message in a buffer and continue to use the previous network map and
the associated cost maps until the ALTO client receives the update
messages for all dependent cost maps. The ALTO client then applies
all network and cost map updates atomically.
Alternatively, the ALTO client MAY update the network map
immediately. In this case, the cost maps using the network map
become invalid because they are inconsistent with the current network
Schott, et al. Expires 24 August 2023 [Page 30]
Internet-Draft ALTO TIPS February 2023
map; hence, the ALTO client MUST mark each such dependent cost map as
temporarily invalid and MUST NOT use each such cost map until the
ALTO client receives a cost map update indicating that it is based on
the new network map version tag.
When implementing server push, the server SHOULD send updates for
dependent resource (i.e., the cost maps in the preceding example) in
a timely fashion. However, if the ALTO client does not receive the
expected updates, a simple recovery method is that the ALTO client
uses client pull to request the missing update. The ALTO client MAY
retain the version tag of the last version of any tagged resources
and search those version tags when identifying the new updates to
pull. Although not as efficient as possible, this recovery method is
simple and reliable.
8.3. Considerations for Updates to Filtered Cost Maps
If TIPS provides updates to a Filtered Cost Map that allows
constraint tests, then an ALTO client MAY request updates to a
Filtered Cost Map request with a constraint test. In this case, when
a cost changes, the updates queue MUST have an update if the new
value satisfies the test. If the new value does not, whether there
is an update depends on whether the previous value satisfied the
test. If it did not, the updates queue SHOULD NOT have an update.
But if the previous value did, then the updates queue MUST add an
update with a "null" value to inform the ALTO client that this cost
no longer satisfies the criteria.
TIPS can avoid having to handle such a complicated behavior by
offering TIPS only for Filtered Cost Maps that do not allow
constraint tests.
8.4. Considerations for Updates to Ordinal Mode Costs
For an ordinal mode cost map, a change to a single cost point may
require updating many other costs. As an extreme example, suppose
the lowest cost changes to the highest cost. For a numerical mode
cost map, only that one cost changes. But for an ordinal mode cost
map, every cost might change. While this document allows TIPS to
offer incremental updates for ordinal mode cost maps, TIPS
implementors should be aware that incremental updates for ordinal
costs are more complicated than for numerical costs, and ALTO clients
should be aware that small changes may result in large updates.
A TIPS can avoid this complication by only offering full replacements
as updates in the updates queue for ordinal cost maps.
Schott, et al. Expires 24 August 2023 [Page 31]
Internet-Draft ALTO TIPS February 2023
9. Security Considerations
The security considerations (Section 15 of [RFC7285]) of the base
protocol fully apply to this extension. For example, the same
authenticity and integrity considerations (Section 15.1 of [RFC7285])
still fully apply; the same considerations for the privacy of ALTO
users (Section 15.4 of [RFC7285]) also still fully apply.
The additional services (addition of update read service and update
push service) provided by this extension extend the attack surface
described in Section 15.1.1 of [RFC7285]. Below, we discuss the
additional risks and their remedies.
9.1. TIPS: Denial-of-Service Attacks
Allowing persistent TIPS states enables a new class of Denial-of-
Service attacks. In particular, For the TIPS server, an ALTO client
might create an unreasonable number of transport states.
To avoid these attacks on the TIPS server, the server SHOULD choose
to limit the number of active states and reject new requests when
that threshold is reached. The Update Read Service allows predictive
fetching and the server SHOULD also choose to limit the number of
pending requests. In these cases, the update stream server SHOULD
return the HTTP status "503 Service Unavailable".
It is important to note that the preceding approaches are not the
only possibilities. For example, it may be possible for TIPS to use
somewhat more clever logic involving IP reputation, rate-limiting,
and compartmentalization of the overall threshold into smaller
thresholds that apply to subsets of potential clients.
9.2. ALTO Client: Update Overloading or Instability
The availability of continuous updates, when the client indicates
receiving server push, can also cause overload for an ALTO client, in
particular, an ALTO client with limited processing capabilities. The
current design does not include any flow control mechanisms for the
client to reduce the update rates from the server. Under
overloading, the client MAY choose to remove the information
resources with high update rates.
Also, under overloading, the client may no longer be able to detect
whether information is still fresh or has become stale. In such a
case, the client should be careful in how it uses the information to
avoid stability or efficiency issues.
Schott, et al. Expires 24 August 2023 [Page 32]
Internet-Draft ALTO TIPS February 2023
9.3. Spoofed URI
An outside party that can read the TIPS response or that can observe
TIPS requests can obtain the transport state URI and use that to send
fraudulent "DELETE" requests, thus disabling the service for the
valid ALTO client. This can be avoided by encrypting the requests
and responses (see Section 15 of [RFC7285]).
In general, as the architecture allows the possibility for TIPS, URS
and UPS to be different entities, the additional risks should be
evaluated and remedied. For example, the private communication path
between the servers may be attacked, resulting in a risk of
communications breakdown between them, as well as invalid or spoofed
messages claiming to be on that private communications path. Proper
security mechanisms, including confidentiality, authenticity, and
integrity mechanisms, should be considered.
10. IANA Considerations
IANA is requested to register the following media type under ALTO
registry as defined in [RFC7285]:
* application/alto-tips+json: as described in Section 4.2.2;
* application/alto-tipsparams+json: as described in Section 4.2.1;
* application/alto-tipsqueue+json: as described in Section 5.5
10.1. application/alto-tips+json Media Type
Type name: application
Subtype name: alto-tips+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
[RFC8259].
Security considerations: Security considerations relating to the
generation and consumption of ALTO Protocol messages are discussed
in Section 10 of [RFC8895] and Section 15 of [RFC7285].
Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof.
Schott, et al. Expires 24 August 2023 [Page 33]
Internet-Draft ALTO TIPS February 2023
Published specification: Section 4.2.2 of this document.
Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): This document uses the media type to refer to
protocol messages and thus does not require a file extension.
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut
hors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
10.2. application/alto-tipsparams+json Media Type
Type name: application
Subtype name: alto-tipsparams+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
[RFC8259].
Security considerations: Security considerations relating to the
generation and consumption of ALTO Protocol messages are discussed
in Section 10 of [RFC8895] and Section 15 of [RFC7285].
Schott, et al. Expires 24 August 2023 [Page 34]
Internet-Draft ALTO TIPS February 2023
Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof.
Published specification: Section 4.2.1 of this document.
Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): This document uses the media type to refer to
protocol messages and thus does not require a file extension.
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut
hors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
10.3. application/alto-tipsqueue+json Media Type
Type name: application
Subtype name: alto-tipsqueue+json
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
[RFC8259].
Security considerations: Security considerations relating to the
Schott, et al. Expires 24 August 2023 [Page 35]
Internet-Draft ALTO TIPS February 2023
generation and consumption of ALTO Protocol messages are discussed
in Section 10 of [RFC8895] and Section 15 of [RFC7285].
Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof.
Published specification: Section 5.5 of this document.
Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications.
Fragment identifier considerations: N/A
Additional information:
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): This document uses the media type to refer to
protocol messages and thus does not require a file extension.
Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut
hors' Addresses section.
Intended usage: COMMON
Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
11. Acknowledgments
The authors of this document would also like to thank Adrian Farrel,
Qin Wu, Jordi Ros Giralt, and the many others who reviewed and
commented on previous drafts of this document.
12. References
12.1. Normative References
Schott, et al. Expires 24 August 2023 [Page 36]
Internet-Draft ALTO TIPS February 2023
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/info/rfc8895>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/info/rfc9114>.
12.2. Informative References
[draft-schott-alto-new-transport-push]
Schott, R. and Y. Yang, "ALTO New Transport: Server Push",
Internet Draft ID, October 2022,
<https://datatracker.ietf.org/doc/draft-schott-alto-new-
transport-push/>.
Schott, et al. Expires 24 August 2023 [Page 37]
Internet-Draft ALTO TIPS February 2023
[RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
S. Previdi, "Application-Layer Traffic Optimization (ALTO)
Deployment Considerations", RFC 7971,
DOI 10.17487/RFC7971, October 2016,
<https://www.rfc-editor.org/info/rfc7971>.
Authors' Addresses
Roland Schott
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
64295 Darmstadt
Germany
Email: Roland.Schott@telekom.de
Y. Richard Yang
Yale University
51 Prospect St
New Haven, CT 06520
United States of America
Email: yry@cs.yale.edu
Kai Gao
Sichuan University
Chengdu
201804
China
Email: kgao@scu.edu.cn
Lauren Delwiche
Yale University
51 Prospect St
New Haven, CT 06520
United States of America
Email: lauren.delwiche@yale.edu
Lachlan Keller
Yale University
51 Prospect Street
New Haven, 06511
United States of America
Email: lachlan.keller@yale.edu
Schott, et al. Expires 24 August 2023 [Page 38]