rfc9569.original   rfc9569.txt 
ALTO K. Gao Internet Engineering Task Force (IETF) K. Gao
Internet-Draft Sichuan University Request for Comments: 9569 Sichuan University
Intended status: Standards Track R. Schott Category: Standards Track R. Schott
Expires: 6 July 2024 Deutsche Telekom ISSN: 2070-1721 Deutsche Telekom
Y. R. Yang Y. R. Yang
L. Delwiche L. Delwiche
L. Keller L. Keller
Yale University Yale University
3 January 2024 August 2024
The ALTO Transport Information Publication Service The Application-Layer Traffic Optimization (ALTO) Transport Information
draft-ietf-alto-new-transport-22 Publication Service (TIPS)
Abstract Abstract
The ALTO Protocol (RFC 7285) leverages HTTP/1.1 and is designed for "Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285)
the simple, sequential request-reply use case, in which an ALTO leverages HTTP/1.1 and is designed for the simple, sequential
client requests a sequence of information resources and the server request-reply use case, in which an ALTO client requests a sequence
responds with the complete content of each resource one at a time. of information resources and the server responds with the complete
content of each resource, one at a time.
ALTO incremental updates using Server-Sent Events (SSE) (RFC 8895) RFC 8895, which describes ALTO incremental updates using Server-Sent
defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO Events (SSE), defines a multiplexing protocol on top of HTTP/1.x, so
server can incrementally push resource updates to clients whenever that an ALTO server can incrementally push resource updates to
monitored network information resources change, allowing the clients clients whenever monitored network information resources change,
to monitor multiple resources at the same time. However, HTTP/2 and allowing the clients to monitor multiple resources at the same time.
later versions already support concurrent, non-blocking transport of However, HTTP/2 and later versions already support concurrent, non-
multiple streams in the same HTTP connection. blocking transport of multiple streams in the same HTTP connection.
To take advantage of newer HTTP features, this document introduces To take advantage of newer HTTP features, this document introduces
the ALTO Transport Information Publication Service (TIPS). TIPS uses the ALTO Transport Information Publication Service (TIPS). TIPS uses
an incremental RESTful design to give an ALTO client the new an incremental RESTful design to give an ALTO client the new
capability to explicitly, concurrently (non-blocking) request (pull) capability to explicitly and concurrently (in a non-blocking manner)
specific incremental updates using native HTTP/2 or HTTP/3, while request (or pull) specific incremental updates using HTTP/2 or
still functioning for HTTP/1.1. HTTP/3, while still functioning for HTTP/1.1.
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the Application-Layer
Traffic Optimization Working Group mailing list (alto@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/alto/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-wg-alto/draft-ietf-alto-new-transport.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 July 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9569.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language
1.2. Notations . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Notations
2. TIPS Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 2. TIPS Overview
2.1. Transport Requirements . . . . . . . . . . . . . . . . . 6 2.1. Transport Requirements
2.2. TIPS Terminology . . . . . . . . . . . . . . . . . . . . 7 2.2. TIPS Terminology
3. TIPS Updates Graph . . . . . . . . . . . . . . . . . . . . . 10 3. TIPS Updates Graph
3.1. Basic Data Model of Updates Graph . . . . . . . . . . . . 10 3.1. Basic Data Model of an Updates Graph
3.2. Updates Graph Modification Invariants . . . . . . . . . . 11 3.2. Updates Graph Modification Invariants
4. TIPS Workflow and Resource Location Schema . . . . . . . . . 12 4. TIPS Workflow and Resource Location Schema
4.1. Workflow . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Workflow
4.2. Resource Location Schema . . . . . . . . . . . . . . . . 14 4.2. Resource Location Schema
5. TIPS Information Resource Directory (IRD) Announcement . . . 15 5. TIPS Information Resource Directory (IRD) Announcement
5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Media Type
5.2. Capabilities . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Capabilities
5.3. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Uses
5.4. An Example . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. An Example
6. TIPS Management . . . . . . . . . . . . . . . . . . . . . . . 18 6. TIPS Management
6.1. Open Request . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Open Request
6.2. Open Response . . . . . . . . . . . . . . . . . . . . . . 19 6.2. Open Response
6.3. Open Example . . . . . . . . . . . . . . . . . . . . . . 22 6.3. Open Example
6.3.1. Basic Example . . . . . . . . . . . . . . . . . . . . 22 6.3.1. Basic Example
6.3.2. Example using Digest Authentication . . . . . . . . . 23 6.3.2. Example Using Digest Authentication
6.3.3. Example using ALTO/SSE . . . . . . . . . . . . . . . 25 6.3.3. Example Using ALTO/SSE
7. TIPS Data Transfers - Client Pull . . . . . . . . . . . . . . 26 7. TIPS Data Transfers - Client Pull
7.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Request
7.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Response
7.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 27 7.3. Example
7.4. New Next Edge Recommendation . . . . . . . . . . . . . . 28 7.4. New Next Edge Recommendation
7.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 28 7.4.1. Request
7.4.2. Response . . . . . . . . . . . . . . . . . . . . . . 28 7.4.2. Response
7.4.3. Example . . . . . . . . . . . . . . . . . . . . . . . 29 7.4.3. Example
8. Operation and Processing Considerations . . . . . . . . . . . 30 8. Operation and Processing Considerations
8.1. Considerations for Load Balancing . . . . . . . . . . . . 30 8.1. Considerations for Load Balancing
8.2. Considerations for Cross-Resource Dependency 8.2. Considerations for Cross-Resource Dependency Scheduling
Scheduling . . . . . . . . . . . . . . . . . . . . . . . 31 8.3. Considerations for Managing Shared TIPS Views
8.3. Considerations for Managing Shared TIPS Views . . . . . . 32 8.4. Considerations for Offering Shortcut Incremental Updates
8.4. Considerations for Offering Shortcut Incremental 9. Security Considerations
Updates . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. TIPS: Denial-of-Service Attacks
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9.2. ALTO Client: Update Overloading or Instability
9.1. TIPS: Denial-of-Service Attacks . . . . . . . . . . . . . 34 10. IANA Considerations
9.2. ALTO Client: Update Overloading or Instability . . . . . 34 10.1. application/alto-tips+json Media Type
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10.2. application/alto-tipsparams+json Media Type
10.1. application/alto-tips+json Media Type . . . . . . . . . 35 11. References
10.2. application/alto-tipsparams+json Media Type . . . . . . 36 11.1. Normative References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 11.2. Informative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 37 Appendix A. A High-Level Deployment Model
11.2. Informative References . . . . . . . . . . . . . . . . . 38 Appendix B. Conformance with "Building Protocols with HTTP" (RFC
Appendix A. A High-Level Deployment Model . . . . . . . . . . . 38 9205) Best Current Practices
Appendix B. Conformance to "Building Protocols with HTTP" Best Appendix C. Push-Mode TIPS Using HTTP Server Push
Current Practices . . . . . . . . . . . . . . . . . . . . 40 Appendix D. Persistent HTTP Connections
Appendix C. Push-mode TIPS using HTTP Server Push . . . . . . . 41 Acknowledgments
Appendix D. Persistent HTTP Connections . . . . . . . . . . . . 41 Authors' Addresses
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Application-Layer Traffic Optimization (ALTO) provides means for The Application-Layer Traffic Optimization (ALTO) protocol provides
network applications to obtain network status information. So far, means for network applications to obtain network status information.
the ALTO information can be transported in two ways: So far, the ALTO information can be transported in two ways:
1. The ALTO base protocol [RFC7285], which is designed for the 1. Using the ALTO base protocol [RFC7285], which is designed for the
simple use case in which an ALTO client requests a network simple use case in which an ALTO client requests a network
information resource, and the server sends the complete content information resource and the server sends the complete content of
of the requested information (if any) resource to the client. the requested information (if any) resource to the client.
2. ALTO incremental updates using Server-Sent Events (ALTO/SSE) 2. Using ALTO incremental updates using Server-Sent Events (ALTO/
[RFC8895], which is designed for an ALTO client to indicate to SSE) [RFC8895]; this method is designed for an ALTO client to
the server that it wants to receive updates for a set of indicate to the server that it wants to receive updates for a set
resources and the server can then concurrently and incrementally of resources, and the server can then concurrently and
push updates to that client whenever monitored resources change. incrementally push updates to that client whenever monitored
resources change.
Both protocols are designed for HTTP/1.1 [RFC9112], but HTTP/2 Both protocols are designed for HTTP/1.1 [RFC9112]. While they still
[RFC9113] and HTTP/3 [RFC9114] can support HTTP/1.1 workflows. work with HTTP/2 [RFC9113] and HTTP/3 [RFC9114], ALTO and ALTO/SSE
However, HTTP/2 and HTTP/3 provide features that can improve certain cannot take full advantage of new features offered by HTTP/2 and
properties of ALTO and ALTO/SSE. HTTP/3.
* First, consider the ALTO base protocol, which is designed to * First, consider the ALTO base protocol, which is designed to
transfer only complete information resources. A client can run transfer only complete information resources. A client can run
the base protocol on top of HTTP/2 or HTTP/3 to request multiple the base protocol on top of HTTP/2 or HTTP/3 to request multiple
information resources in concurrent streams, but each request must information resources in concurrent streams, but each request must
be for a complete information resource: there is no capability for be for a complete information resource: there is no capability for
the server to transmit incremental updates. Hence, there can be a the server to transmit incremental updates. Hence, there can be a
large overhead when the client already has an information resource large overhead when the client already has an information resource
and then there are small changes to the resource. and then there are small changes to the resource.
* Next, consider ALTO/SSE [RFC8895]. Although ALTO/SSE can transfer * Next, consider ALTO/SSE [RFC8895]. Although ALTO/SSE can transfer
incremental updates, it introduces a customized multiplexing incremental updates, it introduces a customized multiplexing
protocol on top of HTTP, assuming a total-order message channel protocol on top of HTTP, assuming a total-order message channel
from the server to the client. The multiplexing design does not from the server to the client. The multiplexing design does not
provide naming (i.e., a resource identifier) to individual provide naming (i.e., a resource identifier) to individual
incremental updates. Such a design cannot use concurrent data incremental updates. Such a design cannot use concurrent data
streams available in HTTP/2 and HTTP/3, because both cases require streams available in HTTP/2 and HTTP/3 because both cases require
a resource identifier. Additionally, ALTO/SSE is a push-only a resource identifier. Additionally, ALTO/SSE is a push-only
protocol, which denies the client flexibility in choosing how and protocol, which denies the client flexibility in choosing how and
when it receives updates. when it receives updates.
To mitigate these concerns, this document introduces a new ALTO To mitigate these concerns, this document introduces a new ALTO
service called the Transport Information Publication Service (TIPS). service called the Transport Information Publication Service (TIPS).
TIPS uses an incremental RESTful design to provide an ALTO client TIPS uses an incremental RESTful design to provide an ALTO client
with a new capability to explicitly, concurrently issue non-blocking with a new capability to explicitly, concurrently issue non-blocking
requests for specific incremental updates using native HTTP/2 or requests for specific incremental updates using HTTP/2 or HTTP/3,
HTTP/3, while still functioning for HTTP/1.1. while still functioning for HTTP/1.1.
While ALTO/SSE [RFC8895] and TIPS both can transport incremental While both ALTO/SSE [RFC8895] and TIPS can transport incremental
updates of ALTO information resources to clients, they have different updates of ALTO information resources to clients, they have different
design goals. The TIPS extension enables more scalable and robust design goals. The TIPS extension enables more scalable and robust
distribution of incremental updates, but is missing the session distribution of incremental updates but is missing the session
management and built-in server push capabilities of ALTO/SSE. From management and built-in server push capabilities of ALTO/SSE. From
the performance perspective, TIPS is optimizing throughput by the performance perspective, TIPS is optimizing throughput by
leveraging concurrent and out-of-order transport of data, while ALTO/ leveraging concurrent and out-of-order transport of data, while ALTO/
SSE is optimizing latency as new events can be immediately SSE is optimizing latency as new events can be immediately
transferred to the clients without waiting for another round of transferred to the clients without waiting for another round of
communication when there are multiple updates. Thus, we do not see communication when there are multiple updates. Thus, we do not see
TIPS as a replacement but as a complement of ALTO/SSE. One example TIPS as a replacement for ALTO/SSE, but as a complement to it. One
of combining these two extensions is as shown in Section 6.3.3. example of combining these two extensions is shown in Section 6.3.3.
Note that future extensions may leverage server push, a feature of Note that future extensions may leverage server push, a feature of
HTTP/2 [RFC9113] and HTTP/3 [RFC9114], as an alternative of SSE. We HTTP/2 [RFC9113] and HTTP/3 [RFC9114], as an alternative of SSE. We
discuss why this alternative design is not ready in Appendix C. discuss why this alternative design is not ready at the time of
writing in Appendix C.
Specifically, this document specifies: Specifically, this document specifies:
* Extensions to the ALTO Protocol for dynamic subscription and * Extensions to the ALTO Protocol for dynamic subscription and
efficient uniform update delivery of an incrementally changing efficient uniform update delivery of an incrementally changing
network information resource. network information resource.
* A new resource type that indicates the TIPS updates graph model * A new resource type that indicates the TIPS updates graph model
for a resource. for a resource.
* URI patterns to fetch the snapshots or incremental updates. * URI patterns to fetch the snapshots or incremental updates.
Some operational complexities that must be taken into consideration Some operational complexities that must be taken into consideration
when implementing this extension are discussed in Section 8, when implementing this extension are discussed in Section 8: these
including load balancing Section 8.1, fetching and processing include load balancing in Section 8.1 and fetching and processing
incremental updates of dependent resources Section 8.2 incremental updates of dependent resources in Section 8.2.
Appendix B discusses to what extent the TIPS design adheres to the Appendix B discusses to what extent the TIPS design adheres to the
Best Current Practices for building protocols with HTTP [RFC9205]. best current practices for building protocols with HTTP [RFC9205].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
1.2. Notations 1.2. Notations
This document uses the same syntax and notations as introduced in This document uses the same syntax and notations as introduced in
Section 8.2 of [RFC7285] to specify the extensions to existing ALTO Section 8.2 of [RFC7285] to specify the extensions to existing ALTO
resources and services. resources and services.
2. TIPS Overview 2. TIPS Overview
2.1. Transport Requirements 2.1. Transport Requirements
The ALTO Protocol and its extensions support two transport The ALTO Protocol and its extensions support two transport
mechanisms: First, a client can directly request an ALTO resource and mechanisms:
obtain a complete snapshot of that ALTO resource, as specified in the
base protocol [RFC7285]; Second, a client can subscribe to 1. A client can directly request an ALTO resource and obtain a
incremental changes of one or multiple ALTO resources using the complete snapshot of that ALTO resource, as specified in the base
incremental update extension [RFC8895], and a server pushes the protocol [RFC7285];
updates to the client through Server Sent Events (SSE).
2. A client can subscribe to incremental changes of one or multiple
ALTO resources using the incremental update extension [RFC8895],
and a server pushes the updates to the client through SSE.
However, the current transport mechanisms are not optimized for However, the current transport mechanisms are not optimized for
storing, transmitting, and processing (incremental) updates of ALTO storing, transmitting, and processing (incremental) updates of ALTO
information resources. Specifically, the new transport mechanism information resources. Specifically, the new transport mechanism
must satisfy the following requirements: must satisfy the following requirements:
Incremental updates: Incremental updates only maintain and transfer Incremental updates: Incremental updates only maintain and transfer
the "diff" upon changes. Thus, it is more efficient than storing the "diff" upon changes. Thus, it is more efficient than storing
and transferring the full updates, especially when the change of and transferring the full updates, especially when the change of
an ALTO resource is minor. The base protocol does not support an ALTO resource is minor. The base protocol does not support
incremental updates and the current incremental update mechanism incremental updates and the current incremental update mechanism
in [RFC8895] has limitations (as discussed below). in [RFC8895] has limitations (as discussed below).
Concurrent, non-blocking update transmission: When a client needs to Concurrent, non-blocking update transmission: When a client needs to
receive and apply multiple incremental updates, it is desired to receive and apply multiple incremental updates, it is desired to
transmit the updates concurrently to fully utilize the bandwidth transmit the updates concurrently to fully utilize the bandwidth
and to reduce head-of-line blocking. The ALTO incremental update and to reduce head-of-line blocking. Unfortunately, the ALTO
extension [RFC8895], unfortunately, does not satisfy this incremental update extension [RFC8895] does not satisfy this
requirement -- even though the updates can be multiplexed by the requirement. Even though the updates can be multiplexed by the
server to avoid head-of-line blocking between multiple resources, server to avoid head-of-line blocking between multiple resources,
the updates are delivered sequentially and can suffer from head- the updates are delivered sequentially and can suffer from head-
of-line blocking inside the connection, for example, when there is of-line blocking inside the connection (for example, when there is
a packet loss. a packet loss).
Long-polling updates: Long-polling updates can reduce the time to Long polling updates: Long polling updates can reduce the time to
send the request, making it possible to achieve sub-RTT send the request, making it possible to achieve sub-RTT
transmission of ALTO incremental updates. In [RFC8895], this transmission of ALTO incremental updates. In [RFC8895], this
requirement is fulfilled using server-sent event (SSE) and is requirement is fulfilled using SSE and is still desired in the new
still desired in the ALTO new transport. ALTO transport.
Backward compatibility: While some of the previous requirements are Backward compatibility: While some of the previous requirements are
offered by HTTP/2 [RFC9113] and HTTP/3 [RFC9114], it is desired offered by HTTP/2 [RFC9113] and HTTP/3 [RFC9114], it is desired
that the ALTO new transport mechanism can work with HTTP/1.1 as that the new ALTO transport mechanism can work with HTTP/1.1 as
many development tools and current ALTO implementations are based many development tools and current ALTO implementations are based
on HTTP/1.1. on HTTP/1.1.
The ALTO new transport specified in this document satisfies all the The new ALTO transport specified in this document satisfies all of
design requirements: the following design requirements above by:
* This document reuses the data format introduced in [RFC8895] that * Reusing the data format introduced in [RFC8895] that enables
enables incremental updates using JSON patches or merge patches. incremental updates using JSON patches or merge patches.
* This document introduce a unified data model to describe the * Introducing a unified data model to describe the changes
changes (snapshots and incremental updates) of an ALTO resource, (snapshots and incremental updates) of an ALTO resource, referred
referred to as a TIPS view. In the data model, snapshots and to as a "TIPS view". In the data model, snapshots and incremental
incremental updates are indexed as individual HTTP resources updates are indexed as individual HTTP resources following a
following a unified naming convention, independent of the HTTP unified naming convention, independent of the HTTP version. Thus,
version. Thus, these updates can be concurrently requested and be these updates can be concurrently requested and be transferred in
transferred in a non-blocking manner either by using multiple a non-blocking manner either by using multiple connections or
connections or leveraging multiplexed data transfer offered by leveraging multiplexed data transfer offered by HTTP/2 or HTTP/3.
HTTP/2 or HTTP/3.
* The unified naming convention is based on a monotonically * Basing the unified naming convention on a monotonically increasing
increasing sequence number, making it possible for a client to sequence number, making it possible for a client to construct the
construct the URL of a future update and send a long-polling URL of a future update and send a long polling request.
request.
* The unified naming convention is independent of the HTTP versions * Making the unified naming convention independent of the HTTP
and can operate atop HTTP/1.1, HTTP/2 or HTTP/3. versions and able to operate atop HTTP/1.1, HTTP/2, or HTTP/3.
This document assumes the deployment model discussed in Appendix A. This document assumes the deployment model discussed in Appendix A.
2.2. TIPS Terminology 2.2. TIPS Terminology
In addition to the terms defined in [RFC7285], this document uses the In addition to the terms defined in [RFC7285], this document uses the
following terms: following terms:
Transport Information Publication Service (TIPS): Is a new type of Transport Information Publication Service (TIPS): A new type of ALTO
ALTO service, as specified in this document, to enable a uniform service, as specified in this document, to enable a uniform
transport mechanism for updates of an incrementally changing ALTO transport mechanism for updates of an incrementally changing ALTO
network information resource. network information resource.
Network information resource: Is a piece of retrievable information Network information resource: A piece of retrievable information
about network state, per [RFC7285]. about network state, per [RFC7285].
TIPS view (tv): Is defined in this document to be the container of TIPS view (tv): The container of incremental transport information
incremental transport information about the network information about the network information resource. The TIPS view has one
resource. The TIPS view has one basic component, updates graph basic component, the updates graph (ug), but may include other
(ug), but may include other transport information. transport information.
Updates graph (ug): Is a directed, acyclic graph whose nodes Updates graph (ug): A directed, acyclic graph whose nodes represent
represent the set of versions of an information resource, and the set of versions of an information resource and whose edges
edges the set of update items to compute these versions. An ALTO represent the set of update items to compute these versions. An
map service (e.g., Cost Map, Network Map) may need only a single ALTO map service (e.g., a cost map or a network map) may need only
updates graph. A dynamic network information service (e.g., a single updates graph. A dynamic network information service
Filtered Cost Map) may create an updates graph (within a new TIPS (e.g., a filtered cost map) may create an updates graph (within a
view) for each unique request. Encoding of a updates graph is new TIPS view) for each unique request. The encoding of an
specified in Section 6.1. updates graph is specified in Section 6.1.
Version: Represents a historical content of an information resource. Version: The representation of a historical content of an
For an information resource, each version is associated with and information resource. For an information resource, each version
uniquely identified by a monotonically and consecutively increased is associated with and uniquely identified by a monotonically and
sequence number. This document uses the term "version s" to refer consecutively increased sequence number. This document uses the
to the version associated with sequence number "s". Version is term "version s" to refer to the version associated with sequence
encoded as a JSONNumber, as specified in Section 6.1. number "s". The version is encoded as a JSONNumber, as specified
in Section 6.1.
Start sequence number (start-seq): Is the smallest non-zero sequence Start sequence number (<start-seq>): The smallest non-zero sequence
number in an updates graph. number in an updates graph.
End sequence number (end-seq): Is the largest sequence number in an End sequence number (<end-seq>): The largest sequence number in an
updates graph. updates graph.
Snapshot: Is a full replacement of a resource and is contained Snapshot: A full replacement of a resource that is contained within
within an updates graph. an updates graph.
Incremental update: Is a partial replacement of a resource contained Incremental update: A partial replacement of a resource contained
within an updates graph, codified in this document as a JSON Merge within an updates graph, codified in this document as a JSON merge
Patch or JSON Patch. An incremental update is mandatory if the patch or a JSON patch. An incremental update is mandatory if the
source version (i) and target version (j) are consecutive, i.e., i source version (i) and the target version (j) are consecutive
+ 1 = j, and optional or a shortcut otherwise. Mandatory (i.e., i + 1 = j); otherwise, it is optional (or a shortcut).
incremental updates are always in an updates graph, while Mandatory incremental updates are always in an updates graph,
optional/shortcut incremental updates may or may not be included while optional/shortcut incremental updates may or may not be
in an updates graph. included in an updates graph.
Update item: Refers to the content on an edge of the updates graph, Update item: The content on an edge of the updates graph, which can
which can be either a snapshot or an incremental update. An be either a snapshot or an incremental update. An update item can
update item can be considered as a pair (op, data) where op be considered to be a pair (op, data) where op denotes whether the
denotes whether the item is an incremental update or a snapshot, item is an incremental update or a snapshot and data is the
and data is the content of the item. content of the item.
ID#i-#j: Denotes the update item on a specific edge in the updates ID#i-#j: Denotation of the update item on a specific edge in the
graph to transition from version i to version j, where i and j are updates graph to transition from version i to version j, where i
the sequence numbers of the source node and the target node of the and j are the sequence numbers of the source node and the target
edge, respectively. node of the edge, respectively.
+-------------+ +-------------+
+-----------+ +--------------+ | Dynamic | +-----------+ +-----------+ +--------------+ | Dynamic | +-----------+
| Routing | | Provisioning | | Network | | External | | Routing | | Provisioning | | Network | | External |
| Protocols | | Policy | | Information | | Interface | | Protocols | | Policy | | Information | | Interface |
+-----------+ +--------------+ +-------------+ +-----------+ +-----------+ +--------------+ +-------------+ +-----------+
| | | | | | | |
+-----------------------------------------------------------------+ +-----------------------------------------------------------------+
| ALTO Server | | ALTO Server |
| +-------------------------------------------------------------+ | | +-------------------------------------------------------------+ |
skipping to change at page 9, line 45 skipping to change at line 402
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
| Client 1 | | Client 2 | | Client 3 | | Client 1 | | Client 2 | | Client 3 |
+----------+ +----------+ +----------+ +----------+ +----------+ +----------+
tvi = TIPS view i tvi = TIPS view i
tvi/ug = incremental updates graph associated with tvi tvi/ug = incremental updates graph associated with tvi
Figure 1: Overview of ALTO TIPS Figure 1: Overview of ALTO TIPS
Figure 1 shows an example illustrating an overview of the ALTO TIPS Figure 1 shows an example illustrating an overview of the ALTO TIPS
service. The server provides the TIPS service of two information extension. The server provides TIPS for two information resources
resources (#1 and #2) where #1 is an ALTO map service, and #2 is a (#1 and #2) where #1 is an ALTO map service and #2 is a filterable
filterable service. There are 3 ALTO clients (Client 1, Client 2, service. There are three ALTO clients (Client 1, Client 2, and
and Client 3) that are connected to the ALTO server. Client 3) that are connected to the ALTO server.
Each client uses the TIPS view to retrieve updates. Specifically, a Each client uses the TIPS view to retrieve updates. Specifically, a
TIPS view (tv1) is created for the map service #1, and is shared by TIPS view (tv1) is created for the map service #1 and is shared by
multiple clients. For the filtering service #2, two different TIPS multiple clients. For the filtering service #2, two different TIPS
views (tv2 and tv3) are created upon different client requests with views (tv2 and tv3) are created upon different client requests with
different filter sets. different filter sets.
3. TIPS Updates Graph 3. TIPS Updates Graph
In order to provide incremental updates for a resource, an ALTO In order to provide incremental updates for a resource, an ALTO
server creates an updates graph, which is a directed, acyclic graph server creates an updates graph, which is a directed acyclic graph
that contains a sequence of incremental updates and snapshots that contains a sequence of incremental updates and snapshots
(collectively called update items) of a network information resource. (collectively called "update items") of a network information
resource.
3.1. Basic Data Model of Updates Graph 3.1. Basic Data Model of an Updates Graph
For each resource (e.g., a cost map, a network map), the incremental For each resource (e.g., a cost map or a network map), the
updates and snapshots can be represented using the following directed incremental updates and snapshots can be represented using the
acyclic graph model, where the server tracks the change of the following directed acyclic graph model, where the server tracks the
resource maps with version IDs that are assigned sequentially (i.e., change of the resource maps with version IDs that are assigned
incremented by 1 each time): sequentially (i.e., incremented by one each time):
* Each node in the graph is a version of the resource, which is * Each node in the graph is a version of the resource, which is
identified by a sequence number (defined as a JSONNumber). identified by a sequence number (defined as a JSONNumber).
Version 0 is reserved as the initial state (empty/null). Version 0 is reserved as the initial state (empty/null).
* A tag identifies the content of a node. A tag has the same format * A tag identifies the content of a node. A tag has the same format
as the "tag" field in Section 10.3 of [RFC7285] and is valid only as the "tag" field in Section 10.3 of [RFC7285] and is valid only
within the scope of resource. within the scope of the resource.
* Each edge is an update item. In particular, the edge from i to j * Each edge is an update item. In particular, the edge from i to j
is the update item to transit from version i to version j. is the update item to transit from version i to version j.
* Version is path-independent (different paths arrive at the same * The version is path independent, i.e., different paths arriving at
version/node has the same content) the node associated with the same version have the same content.
A concrete example is shown in Figure 2. There are 7 nodes in the A concrete example is shown in Figure 2. There are seven nodes in
graph, representing 7 different versions of the resource. Edges in the graph, representing seven different versions of the resource.
the figure represent the updates from the source version to the Edges in the figure represent the updates from the source version to
target version. Thick lines represent mandatory incremental updates the target version. Thick lines represent mandatory incremental
(e.g., ID103-104), dotted lines represent optional incremental updates (e.g., ID103-104), dotted lines represent optional
updates (e.g., ID103-105), and thin lines represent snapshots (e.g., incremental updates (e.g., ID103-105), and thin lines represent
ID0-103). Note that node content is path independent: the content of snapshots (e.g., ID0-103). Note that node content is path
node v can be obtained by applying the updates from any path that independent: the content of node v can be obtained by applying the
ends at v. For example, assume the latest version is 105 and a updates from any path that ends at v. For example, assume the latest
client already has version 103. The base version of the client is version is 105 and a client already has version 103. The base
103 as it serves as a base upon which incremental updates can be version of the client is 103 as it serves as a base upon which
applied. The target version 105 can either be directly fetched as a incremental updates can be applied.
snapshot, computed incrementally by applying the incremental updates
between 103 and 104, then 104 and 105, or if the optional update from
103 to 105 exists, computed incrementally by taking the "shortcut"
path from 103 to 105.
+======+ The target version 105 can be:
------| 0 |
/ +======+
ID0-101 / | |
|/__ | |
+======+ | |
tag: 3421097 -> | 101 | | |
+======+ | |
ID101-102 || | |
\/ | |
+======+ | |
tag: 6431234 -> | 102 | | |
+======+ | |
ID102-103 || | |
\/ | |
+======+ / |
+--------------+ tag: 0881080 -> | 103 |<--------/ |
| Base Version | =======> +======+ ID0-103 |
+--------------+ 103-104 || .. |
\/ .. |
+======+ .. |
tag: 6452654 -> | 104 | .. ID103 |
+======+ .. -105 |
ID104-105 || .. | ID0-105
\/ |._ /
+======+ /
tag: 7838392 -> | 105 |<-----------/
+======+
ID105-106 ||
\/
+======+
tag: 6470983 -> | 106 |
+======+
Figure 2: TIPS Model Example * directly fetched as a snapshot;
* computed incrementally by applying the incremental updates between
103 and 104, then 104 and 105; or,
* computed incrementally by taking the "shortcut" path from 103 to
105 if the optional update from 103 to 105 exists.
+======+
------| 0 |
/ +======+
ID0-101 / | |
|/__ | |
+======+ | |
tag: 3421097 -> | 101 | | |
+======+ | |
ID101-102 || | |
\/ | |
+======+ | |
tag: 6431234 -> | 102 | | |
+======+ | |
ID102-103 || | |
\/ | |
+======+ / |
+--------------+ tag: 0881080 -> | 103 |<--------/ |
| Base Version | =======> +======+ ID0-103 |
+--------------+ 103-104 || .. |
\/ .. |
+======+ .. |
tag: 6452654 -> | 104 | .. ID103 |
+======+ .. -105 |
ID104-105 || .. | ID0-105
\/ |._ /
+======+ /
tag: 7838392 -> | 105 |<-----------/
+======+
ID105-106 ||
\/
+======+
tag: 6470983 -> | 106 |
+======+
Figure 2: TIPS Model Example
3.2. Updates Graph Modification Invariants 3.2. Updates Graph Modification Invariants
A server may change its updates graph (to compact, to add nodes, A server might change its updates graph (to compact it, to add nodes,
etc.), but it must ensure that any resource state that it makes etc.), but it will need to ensure that any resource state that it
available is reachable by clients, either directly via a snapshot makes available is reachable by clients, either directly via a
(that is, relative to 0) or indirectly by requesting an earlier snapshot (that is, relative to 0) or indirectly by requesting an
snapshot and a contiguous set of incremental updates. Additionally, earlier snapshot and a contiguous set of incremental updates.
to allow clients to proactively construct URIs for future update Additionally, to allow clients to proactively construct URIs for
items, the ID of each added node in the updates graph must increment future update items, the ID of each added node in the updates graph
contiguously by 1. More specifically, the updates graph MUST satisfy will need to increment contiguously by 1. More specifically, the
the following invariants: updates graph MUST satisfy the following invariants:
* Continuity: At any time, let ns denote the smallest non-zero Continuity: At any time, let ns denote the smallest non-zero version
version (i.e., start-seq) in the update graph and ne denote the (i.e., <start-seq>) in the updates graph and let ne denote the
latest version (i.e., end-seq). Then any version in between ns latest version (i.e., <end-seq>). Then, any version in between ns
and ne MUST also exist. This implies that the incremental update and ne MUST also exist. This implies that the incremental update
from ni to ni + 1 exists for any ns <= ni <= ne, and all versions from ni to ni + 1 exists for any ns <= ni <= ne, and all the
in the update graph (except 0) is an integer interval [ns, ne]. version numbers in the updates graph (except 0) constitute exactly
the integer interval [ns, ne].
* Feasibility: Let ns denote the start-seq in the update graph. The Feasibility: Let ns denote <start-seq> in the updates graph. The
server MUST provide a snapshot of ns and, in other words, there is server MUST provide a snapshot of ns; in other words, there is
always a direct link to ns in the update graph. always a direct link to ns in the updates graph.
* "Right shift" only: Assume a server provides versions in [n1, n2] "Right shift" only: Assume a server provides versions in [n1, n2] at
at time t and versions in [n1', n2'] at time t'. If t' > t, then time t and versions in [n1', n2'] at time t'. If t' > t, then n1'
n1' >= n1 and n2' >= n2. >= n1 and n2' >= n2.
For example, consider the case that a server compacts a resource's For example, consider the case that a server compacts a resource's
updates graph to conserve space, using the example model in updates graph to conserve space, using the example model in
Section 3.1. Assume at time 0, the server provides the versions Section 3.1. Assume at time 0, the server provides the versions
{101, 102, 103, 104, 105, 106}. At time 1, both {103, 104, 105, 106} {101, 102, 103, 104, 105, 106}. At time 1, both {103, 104, 105, 106}
and {105, 106} are valid sets. However, {102, 103, 104, 105, 106} and {105, 106} are valid sets. However, {102, 103, 104, 105, 106}
and {104, 105, 106} are not valid sets as there is no snapshot to and {104, 105, 106} are not valid sets as there is no snapshot to
version 102 or 104 in the update graph. Thus, there is a risk that version 102 or 104 in the updates graph. Thus, there is a risk that
the right content of version 102 (in the first example) or 104 (in the right content of version 102 (in the first example) or 104 (in
the second example) cannot be obtained by a client that does not have the second example) cannot be obtained by a client that does not have
the previous version 101 or 103, respectively. the previous version 101 or 103, respectively.
4. TIPS Workflow and Resource Location Schema 4. TIPS Workflow and Resource Location Schema
4.1. Workflow 4.1. Workflow
At a high level, an ALTO client first uses the TIPS service (denoted At a high level, an ALTO client first requests the TIPS information
as TIPS-F and F is for frontend) to indicate the information resource (denoted as TIPS-F, where F is for frontend) to indicate the
resource(s) that the client wants to monitor. For each requested information resource or resources that the client wants to monitor.
resource, the server returns a JSON object that contains a URI, which For each requested resource, the server returns a JSON object that
points to the root of a TIPS view (denoted as TIPS-V), and a summary contains a URI, which points to the root of a TIPS view (denoted as
of the current view, which contains the information to correctly TIPS-V), and a summary of the current view, which contains the
interact with the current view. With the URI to the root of a TIPS information to correctly interact with the current view. With the
view, clients can construct URIs (see Section 4.2) to fetch URI to the root of a TIPS view, clients can construct URIs (see
incremental updates. Section 4.2) to fetch incremental updates.
An example workflow is shown in Figure 3. After the TIPS-F service An example workflow is shown in Figure 3. After the TIPS-F receives
receives the request from the client to monitor the updates of an the request from the client to monitor the updates of an ALTO
ALTO resource, it creates a TIPS view service and returns the resource, it creates a TIPS view resource and returns the
corresponding information to the client. The URI points to that corresponding information to the client. The URI points to that
specific TIPS-V instance and the summary contains the start-seq and specific TIPS-V instance, and the summary contains the <start-seq>
end-seq of the update graph, and a server-recommended edge to consume and <end-seq> of the updates graph and a server-recommended edge to
first, e.g., from i to j. consume first (e.g., from i to j).
An ALTO client can then continuously pull each additional update with An ALTO client can then continuously pull each additional update with
the information. For example, the client in Figure 3 first fetches the information. For example, the client in Figure 3 first fetches
the update from i to j, and then from j to j+1. Note that the update the update from i to j and then from j to j+1. Note that the update
item at <tips-view-uri>/ug/<j>/<j+1> may not yet exist, so the server item at "<tips-view-uri>/ug/<j>/<j+1>" might not yet exist, so the
holds the request until the update becomes available (long polling). server holds the request until the update becomes available (i.e.,
long polling).
A server MAY close a TIPS view at any time, e.g., under high system A server MAY close a TIPS view at any time (e.g., under high system
load or due to client inactivity. In the event that a TIPS view is load or due to client inactivity). In the event that a TIPS view is
closed, an edge request will receive error code 404 in response, and closed, an edge request will receive error code 404 (Not Found) in
the client will have to request a new TIPS view URI. response, and the client will have to request a new TIPS view URI.
If resources allow, a server SHOULD avoid closing TIPS views that If resources allow, a server SHOULD avoid closing TIPS views that
have active polling edge requests or have recently served responses have active polling edge requests or have recently served responses
until clients have had a reasonable interval to request the next until clients have had a reasonable interval to request the next
update, unless guided by specific control policies. update, unless guided by specific control policies.
Client TIPS-F TIPS-V Client TIPS-F TIPS-V
o . . o . .
| POST to create/receive a TIPS view . Create TIPS . | POST to create/receive a TIPS view . Create TIPS .
| for resource 1 . View . | for resource 1 . View .
skipping to change at page 14, line 7 skipping to change at line 608
| <------------------------------------------------------| | <------------------------------------------------------|
| . | .
o . o .
. .
TIPS View Closed o TIPS View Closed o
Figure 3: ALTO TIPS Workflow Supporting Client Pull Figure 3: ALTO TIPS Workflow Supporting Client Pull
4.2. Resource Location Schema 4.2. Resource Location Schema
The resource location schema defines how a client constructs URI to The resource location schema defines how a client constructs URIs to
fetch incremental updates. fetch incremental updates.
To access each update in an updates graph, consider the model To access each update in an updates graph, consider the model
represented as a "virtual" file system (adjacency list), contained represented as a "virtual" file system (adjacency list), contained
within the root of a TIPS view URI (see Section 6.2 for the within the root of a TIPS view URI (see Section 6.2 for the
definition of tips-view-uri). For example, assuming that the update definition of tips-view-uri). For example, assuming that the updates
graph of a TIPS view is as shown in Figure 2, the location schema of graph of a TIPS view is as shown in Figure 2, the location schema of
this TIPS view will have the format as in Figure 4. this TIPS view will have the format as in Figure 4.
<tips-view-path> // root path to a TIPS view <tips-view-path> // root path to a TIPS view
|_ ug // updates graph |_ ug // updates graph
| |_ 0 | |_ 0
| | |_ 101 // full 101 snapshot | | |_ 101 // full 101 snapshot
| | |_ 103 | | |_ 103
| | \_ 105 | | \_ 105
| |_ 101 | |_ 101
skipping to change at page 14, line 38 skipping to change at line 639
| | |_ 104 | | |_ 104
| | \_ 105 // optional shortcut 103 -> 105 incr. update | | \_ 105 // optional shortcut 103 -> 105 incr. update
| |_ 104 | |_ 104
| | \_ 105 | | \_ 105
| \_ 105 | \_ 105
| \_ 106 | \_ 106
\_ ... \_ ...
Figure 4: Location Schema Example Figure 4: Location Schema Example
TIPS uses this directory schema to generate template URIs which allow TIPS uses this directory schema to generate template URIs that allow
clients to construct the location of incremental updates after clients to construct the location of incremental updates after
receiving the tips-view-uri from the server. The generic template receiving the tips-view-uri from the server. The generic template
for the location of the update item on the edge from node 'i' to node for the location of the update item on the edge from node 'i' to node
'j' in the updates graph is: 'j' in the updates graph is:
<tips-view-uri>/ug/<i>/<j> <tips-view-uri>/ug/<i>/<j>
Due to the sequential nature of the update item IDs, a client can Due to the sequential nature of the update item IDs, a client can
long poll a future update that does not yet exist (e.g., the long poll a future update that does not yet exist (e.g., the
incremental update from 106 to 107) by constructing the URI for the incremental update from 106 to 107). This can be done by
next edge that will be added, starting from the sequence number of constructing the URI for the next edge that will be added, starting
the current last node (denoted as end-seq) in the graph to the next from the sequence number of the current last node (denoted as <end-
sequential node (with the sequence number of end-seq + 1): seq>) in the graph to the next sequential node (with the sequence
number of <end-seq + 1>):
<tips-view-uri>/ug/<end-seq>/<end-seq + 1> <tips-view-uri>/ug/<end-seq>/<end-seq + 1>
Incremental updates of a TIPS view are read-only. Thus, they are Incremental updates of a TIPS view are read-only. Thus, they are
fetched using the HTTP GET method. fetched using the HTTP GET method.
5. TIPS Information Resource Directory (IRD) Announcement 5. TIPS Information Resource Directory (IRD) Announcement
To announce a TIPS information resource in the information resource To announce a TIPS information resource in the IRD, an ALTO server
directory (IRD), an ALTO server MUST specify the "media-type", MUST specify "media-type", "capabilities", and "uses" as follows.
"capabilities" and "uses" as follows.
5.1. Media Type 5.1. Media Type
The media type of the Transport Information Publication Service The media type of the Transport Information Publication Service
resource is "application/alto-tips+json". (TIPS) resource is "application/alto-tips+json".
5.2. Capabilities 5.2. Capabilities
The capabilities field of TIPS is modeled on that defined in The "capabilities" field of a TIPS information resource is modeled on
Section 6.3 of [RFC8895]. that defined in Section 6.3 of [RFC8895].
Specifically, the capabilities are defined as an object of type Specifically, the capabilities are defined as an object of the
TIPSCapabilities: TIPSCapabilities type:
object { object {
IncrementalUpdateMediaTypes incremental-change-media-types; IncrementalUpdateMediaTypes incremental-change-media-types;
} TIPSCapabilities; } TIPSCapabilities;
object-map { object-map {
ResourceID -> String; ResourceID -> String;
} IncrementalUpdateMediaTypes; } IncrementalUpdateMediaTypes;
Figure 5: TIPSCapabilities Figure 5: TIPSCapabilities
with field: with the field:
incremental-change-media-types: If a TIPS can provide updates with incremental-change-media-types: If a TIPS information resource can
incremental changes for a resource, the "incremental-change-media- provide updates with incremental changes for a resource, the
types" field has an entry for that resource-id, and the value is "incremental-change-media-types" field has an entry whose key is
the supported media types of incremental changes, separated by the ID of the resource and the value is the supported media types
commas. For the implementation of this specification, this MUST of incremental changes, separated by commas. For the
be "application/merge-patch+json", "application/json-patch+json", implementation of this specification, this MUST be "application/
or "application/merge-patch+json,application/json-patch+json", merge-patch+json", "application/json-patch+json", or "application/
unless defined by a future extension. merge-patch+json,application/json-patch+json", unless defined by a
future extension.
When choosing the media types to encode incremental updates for a When choosing the media types to encode incremental updates for a
resource, the server MUST consider the limitations of the resource, the server MUST consider the limitations of the
encoding. For example, when a JSON merge patch specifies that 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 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 removed from the target; hence, the field is no longer defined
(i.e., undefined). This, however, may not be the intended result (i.e., undefined). However, this may not be the intended result
for the resource, when null and undefined have different semantics for the resource, when null and undefined have different semantics
for the resource. In such a case, the server MUST choose JSON for the resource. In such a case, the server MUST choose JSON
patch over JSON merge patch if JSON patch is indicated as a patch encoding over JSON merge patch encoding for the incremental
capability of the TIPS. If the server does not support JSON patch update if both media types "application/json-patch+json" and
to handle such a case, the server then needs to send a full "application/merge-patch" are supported by the TIPS information
replacement. resource.
5.3. Uses 5.3. Uses
The "uses" attribute MUST be an array with the resource-ids of every The "uses" attribute MUST be an array with the resource IDs of every
network information resource for which this TIPS can provide service. network information resource for which this TIPS information resource
can provide service.
This set MAY be any subset of the ALTO server's network information This set MAY be any subset of the ALTO server's network information
resources and MAY include resources defined in linked IRDs. However, resources and MAY include resources defined in linked IRDs. However,
it is RECOMMENDED that the ALTO server selects a set that is closed it is RECOMMENDED that the ALTO server selects a set that is closed
under the resource dependency relationship. That is, if a TIPS' under the resource dependency relationship. That is, if a TIPS
"uses" set includes resource R1 and resource R1 depends on ("uses") information resource's "uses" set includes resource R1, and resource
resource R0, then the TIPS' "uses" set should include R0 as well as R1 depends on ("uses") resource R0, then the "uses" set should
R1. For example, if a TIPS provides a TIPS view for a cost map, it include R0 as well as R1. For example, if a TIPS information
should also provide a TIPS view for the network map upon which that resource provides a TIPS view for a cost map, it should also provide
cost map depends. a TIPS view for the network map upon which that cost map depends.
If the set is not closed, at least one resource R1 in the "uses" If the set is not closed, at least one resource R1 in the "uses"
field of a TIPS depends on another resource R0 which is not in the field of a TIPS information resource depends on another resource R0
"uses" field of the same TIPS. Thus, a client cannot receive that is not in the "uses" field of the same TIPS information
incremental updates for R0 from the same TIPS service. If the client resource. Thus, a client cannot receive incremental updates for
observes in an update of R1 that the version tag for R0 has changed, another resource R0 that is not in the "uses" field of the same TIPS
it must request the full content of R0, which is likely to be less information resource. If the client observes in an update of R1 that
efficient than receiving the incremental updates of R0. the version tag for R0 has changed, it must request the full content
of R0, which is likely to be less efficient than receiving the
incremental updates of R0.
5.4. An Example 5.4. An Example
Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is Extending the IRD example in Section 8.1 of [RFC8895], Figure 6 is
the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, the IRD of an ALTO server supporting the ALTO base protocol, ALTO/
and ALTO TIPS. SSE, and ALTO TIPS.
"my-network-map": { "my-network-map": {
"uri": "https://alto.example.com/networkmap", "uri": "https://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json" "media-type": "application/alto-networkmap+json"
}, },
"my-routingcost-map": { "my-routingcost-map": {
"uri": "https://alto.example.com/costmap/routingcost", "uri": "https://alto.example.com/costmap/routingcost",
"media-type": "application/alto-costmap+json", "media-type": "application/alto-costmap+json",
"uses": ["my-network-map"], "uses": ["my-network-map"],
"capabilities": { "capabilities": {
skipping to change at page 18, line 27 skipping to change at line 825
"media-type": "text/event-stream", "media-type": "text/event-stream",
"accepts": "application/alto-updatestreamparams+json", "accepts": "application/alto-updatestreamparams+json",
"uses": [ "update-my-costs-tips" ], "uses": [ "update-my-costs-tips" ],
"capabilities": { "capabilities": {
"incremental-change-media-types": { "incremental-change-media-types": {
"update-my-costs-tips": "application/merge-patch+json" "update-my-costs-tips": "application/merge-patch+json"
} }
} }
} }
Figure 6: Example of an ALTO Server Supporting ALTO Base Figure 6: Example of an ALTO Server Supporting the ALTO Base
Protocol, ALTO/SSE, and ALTO TIPS Protocol, ALTO/SSE, and ALTO TIPS
Note that it is straightforward for an ALTO server to run HTTP/2 and Note that it is straightforward for an ALTO server to run HTTP/2 and
support concurrent retrieval of multiple resources such as "my- support concurrent retrieval of multiple resources such as "my-
network-map" and "my-routingcost-map" using multiple HTTP/2 streams. network-map" and "my-routingcost-map" using multiple HTTP/2 streams.
The resource "update-my-costs-tips" provides an ALTO TIPS service, The resource "update-my-costs-tips" provides an ALTO TIPS information
and this is indicated by the media-type "application/alto-tips+json". resource, and this is indicated by the media type "application/alto-
tips+json".
6. TIPS Management 6. TIPS Management
Upon request, a server sends a TIPS view to a client. This TIPS view Upon request, a server sends a TIPS view to a client. This TIPS view
may be created at the time of the request or may already exist might be created at the time of the request or might already exist
(either because another client has already created a TIPS view for (either because another client has already created a TIPS view for
the same requested network resource or because the server perpetually the same requested network resource or because the server perpetually
maintains a TIPS view for an often-requested resource). maintains a TIPS view for an often-requested resource).
6.1. Open Request 6.1. Open Request
An ALTO client requests that the server provide a TIPS view for a An ALTO client requests that the server provide a TIPS view for a
given resource by sending an HTTP POST body with the media type given resource by sending an HTTP POST body with the media type
"application/alto-tipsparams+json". That body contains a JSON object "application/alto-tipsparams+json". That body contains a JSON object
of type TIPSReq, where: of the TIPSReq type, where:
object { object {
ResourceID resource-id; ResourceID resource-id;
[JSONString tag;] [JSONString tag;]
[Object input;] [Object input;]
} TIPSReq; } TIPSReq;
Figure 7: TIPSReq Figure 7: TIPSReq
with the following fields: with the following fields:
resource-id: The resource-id of an ALTO resource and MUST be in the resource-id: This field contains the resource ID of an ALTO resource
TIPS' "uses" list (Section 5). If a client does not support all to be monitored, which MUST be in the TIPS information resource's
"uses" list (Section 5). If a client does not support all
incremental methods from the set announced in the server's incremental methods from the set announced in the server's
capabilities, the client MUST NOT use the TIPS service. capabilities, the client MUST NOT use the TIPS information
resource.
tag: If the resource-id is a GET-mode resource with a version tag tag: If the "resource-id" is associated with a GET-mode resource
(or "vtag"), as defined in Section 10.3 of [RFC7285], and the ALTO with a version tag (or "vtag"), as defined in Section 10.3 of
client has previously retrieved a version of that resource from [RFC7285], and the ALTO client has previously retrieved a version
ALTO, the ALTO client MAY set the "tag" field to the tag part of of that resource from ALTO, the ALTO client MAY set the "tag"
the client's version of that resource. The server MAY use the tag field to the tag part of the client's version of that resource.
when calculating a recommended starting edge for the client to The server MAY use the tag when calculating a recommended starting
consume. Note that the client MUST support all incremental edge for the client to consume. Note that the client MUST support
methods from the set announced in the server's capabilities for all incremental methods from the set announced in the server's
this resource. capabilities for this resource.
input: If the resource is a POST-mode service that requires input, 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 ALTO client MUST set the "input" field to a JSON object with
the parameters that the resource expects. the parameters that the resource expects.
6.2. Open Response 6.2. Open Response
The response to a valid request MUST be a JSON object of type The response to a valid request MUST be a JSON object of the
AddTIPSResponse, denoted as media type "application/alto-tips+json": AddTIPSResponse type, denoted as media type "application/alto-
tips+json":
object { object {
URI tips-view-uri; URI tips-view-uri;
TIPSViewSummary tips-view-summary; TIPSViewSummary tips-view-summary;
} AddTIPSResponse; } AddTIPSResponse;
object { object {
UpdatesGraphSummary updates-graph-summary; UpdatesGraphSummary updates-graph-summary;
} TIPSViewSummary; } TIPSViewSummary;
skipping to change at page 20, line 29 skipping to change at line 912
object { object {
JSONNumber seq-i; JSONNumber seq-i;
JSONNumber seq-j; JSONNumber seq-j;
} StartEdgeRec; } StartEdgeRec;
Figure 8: AddTIPSResponse Figure 8: AddTIPSResponse
with the following fields: with the following fields:
tips-view-uri: URI to the requested TIPS view. The value of this tips-view-uri: This is the URI to the requested TIPS view. The
field MUST have the following format: value of this field MUST have the following format:
scheme "://" tips-view-host "/" tips-view-path scheme "://" tips-view-host "/" tips-view-path
tips-view-host = host [ ":" port] tips-view-host = host [ ":" port]
tips-view-path = path tips-view-path = path
where scheme MUST be "http" or "https" unless specified by a where scheme MUST be "http" or "https" unless specified by a
future extension, and host, port and path are as specified in future extension, and host, port, and path are as specified in
Sections 3.2.2, 3.2.3, and 3.3 in [RFC3986]. An ALTO server Sections 3.2.2, 3.2.3, and 3.3 in [RFC3986]. An ALTO server
SHOULD use the "https" scheme unless the contents of the TIPS view SHOULD use the "https" scheme unless the contents of the TIPS view
are intended to be publicly accessible and does not raise security are intended to be publicly accessible and do not raise security
concerns. The field MUST contain only ASCII characters. In case concerns. The field MUST contain only ASCII characters. In case
the original URL contains international characters (e.g., in the the original URL contains international characters (e.g., in the
domain name), the ALTO server implementation MUST properly encode domain name), the ALTO server implementation MUST properly encode
the URL into the ASCII format (e.g., using the "urlencode" the URL into the ASCII format (e.g., using the "urlencode"
function). function).
A server MUST NOT use the same URI for different TIPS views, A server MUST NOT use the same URI for different TIPS views,
either for different resources or different request bodies to the either for different resources or for different request bodies to
same resource. URI generation is implementation specific, for the same resource. URI generation is implementation specific; for
example, one may compute a Universally Unique Identifier (UUID, example, one may compute a Universally Unique Identifier (UUID)
[RFC4122]) or a hash value based on the request, and append it to [RFC9562] or a hash value based on the request and append it to a
a base URL. For performance considerations, it is NOT RECOMMENDED base URL. For performance considerations, it is NOT RECOMMENDED
to use properties that are not included in the request body to to use properties that are not included in the request body to
determine the URI of a TIPS view, such as cookies or the client's determine the URI of a TIPS view, such as cookies or the client's
IP address, which may result in duplicated TIPS views in cases IP address, which may result in duplicated TIPS views in cases
such as mobile clients. However, this is not mandatory as a such as mobile clients. However, this is not mandatory as a
server may intentionally use client information to compute the server might intentionally use client information to compute the
TIPS view URI to provide service isolation between clients. TIPS view URI to provide service isolation between clients.
tips-view-summary: Contains an updates-graph-summary. tips-view-summary: Contains an updates-graph-summary.
The updates-graph-summary field contains the starting sequence The "updates-graph-summary" field contains the <start-seq> of the
number (start-seq) of the updates graph and the last sequence updates graph (in the "start-seq" field) and the <end-seq> that is
number (end-seq) that is currently available, along with a currently available (in the "end-seq" field), along with a
recommended edge to consume (start-edge-rec). If the client does recommended edge to consume (in the "start-edge-rec" field). If
NOT provide a version tag, the server MUST recommend the edge of the client does not provide a version tag, the server MUST
the latest snapshot available. If the client does provide a recommend the edge of the latest available snapshot. If the
version tag, the server MUST either recommend the first client provides a version tag, the server MUST either recommend
incremental update edge starting from the client's tagged version the first incremental update edge starting from the client's
or the edge of the latest snapshot. Which edge is selected tagged version or recommend the edge of the latest snapshot: which
depends on the implementation. For example, a server MAY edge is selected depends on the implementation. For example, a
calculate the cumulative size of the incremental updates available server MAY calculate the cumulative size of the incremental
from that version onward and compare it to the size of the updates available from that version onward and compare it to the
complete resource snapshot. If the snapshot is bigger, the server size of the complete resource snapshot. If the snapshot is
recommends the first incremental update edge starting from the bigger, the server recommends the first incremental update edge
client's tagged version. Otherwise, the server recommends the starting from the client's tagged version. Otherwise, the server
latest snapshot edge. recommends the latest snapshot edge.
If the request has any errors, the TIPS service MUST return an HTTP If the request has any errors, the ALTO server MUST return an HTTP
"400 Bad Request" to the ALTO client; the body of the response 400 (Bad Request) error code to the ALTO client; the body of the
follows the generic ALTO error response format specified in response follows the generic ALTO error response format specified in
Section 8.5.2 of [RFC7285]. Hence, an example ALTO error response Section 8.5.2 of [RFC7285]. Hence, an example ALTO error response
has the format shown in Figure 9. has the format shown in Figure 9.
HTTP/1.1 400 Bad Request HTTP/1.1 400 Bad Request
Content-Length: 131 Content-Length: 131
Content-Type: application/alto-error+json Content-Type: application/alto-error+json
{ {
"meta":{ "meta":{
"code": "E_INVALID_FIELD_VALUE", "code": "E_INVALID_FIELD_VALUE",
skipping to change at page 22, line 9 skipping to change at line 987
"value": "my-network-map/#" "value": "my-network-map/#"
} }
} }
Figure 9: ALTO Error Example Figure 9: ALTO Error Example
Note that "field" and "value" are optional fields. If the "value" Note that "field" and "value" are optional fields. If the "value"
field exists, the "field" field MUST exist. field exists, the "field" field MUST exist.
* If the TIPS request does not have a "resource-id" field, the error * 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" code of the error message MUST be "E_MISSING_FIELD" and the
field, if present, MUST be "resource-id". The TIPS service MUST "field" field, if present, MUST be "resource-id". The ALTO server
NOT create any TIPS view. MUST NOT create any TIPS view.
* If the "resource-id" field is invalid or is not associated with * If the "resource-id" field is invalid or is not associated with
the TIPS, the error code of the error message MUST be the TIPS information resource, the error code of the error message
E_INVALID_FIELD_VALUE. If present, the "field" field MUST be the MUST be "E_INVALID_FIELD_VALUE". If present, the "field" field
full path of the "resource-id" field, and the "value" field MUST MUST be the full path of the "resource-id" field, and the "value"
be the invalid resource-id. field MUST be the value of the "resource-id" field in the request.
* If the resource is a POST-mode service that requires input, the * If the resource is a POST-mode service that requires input, the
client MUST set the "input" field to a JSON object with the client MUST set the "input" field to a JSON object with the
parameters that that resource expects. If the "input" field is parameters that resource expects. If the "input" field is missing
missing or invalid, TIPS MUST return the same error response that or invalid, the ALTO server MUST return the same error response
resource would return for missing or invalid input (see that resource would return for missing or invalid inputs (see
[RFC7285]). [RFC7285]).
Furthermore, it is RECOMMENDED that the server uses the following Furthermore, it is RECOMMENDED that the server use the following HTTP
HTTP codes to indicate other errors, with the media type code to indicate other errors, with the media type "application/alto-
"application/alto-error+json". error+json".
* 429 (Too Many Requests): when the number of TIPS views open 429 (Too Many Requests): Indicates when the number of TIPS views
requests exceeds the server threshold. The server MAY indicate open requests exceeds the server threshold. The server MAY
when to re-try the request in the "Re-Try After" headers. indicate when to retry the request in the "Re-Try After" headers.
It is RECOMMENDED that the server provide the ALTO/SSE support for It is RECOMMENDED that the server provide the ALTO/SSE support for
the TIPS resource. Thus, the client can be notified of the version the TIPS resource. Thus, the client can be notified of the version
updates of all the TIPS views that it monitors and make better cross- updates of all the TIPS views that it monitors and make better cross-
resource transport decisions (see Section 8.2 for related resource transport decisions (see Section 8.2 for related
considerations). considerations).
6.3. Open Example 6.3. Open Example
6.3.1. Basic Example 6.3.1. Basic Example
For simplicity, assume that the ALTO server is using the Basic For simplicity, assume that the ALTO server is using Basic
authentication. If a client with username "client1" and password authentication [RFC7617]. If a client with username "client1" and
"helloalto" wants to create a TIPS view of an ALTO Cost Map resource password "helloalto" wants to create a TIPS view of an ALTO cost map
with resource ID "my-routingcost-map", it can send the request resource with the resource ID "my-routingcost-map", it can send the
depicted in Figure 10. request depicted in Figure 10.
POST /tips HTTP/1.1 POST /tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 41 Content-Length: 41
{ {
"resource-id": "my-routingcost-map" "resource-id": "my-routingcost-map"
skipping to change at page 23, line 41 skipping to change at line 1064
"start-edge-rec" : { "start-edge-rec" : {
"seq-i": 0, "seq-i": 0,
"seq-j": 105 "seq-j": 105
} }
} }
} }
} }
Figure 11: Response Example of Opening a TIPS View Figure 11: Response Example of Opening a TIPS View
6.3.2. Example using Digest Authentication 6.3.2. Example Using Digest Authentication
Below is another example of the same query using Digest Below is another example of the same query using Digest
authentication, a mandatory authentication method of ALTO servers as authentication, a mandatory authentication method of ALTO servers as
defined in Section 8.3.5 of [RFC7285]. The content of the response defined in Section 8.3.5 of [RFC7285]. The content of the response
is the same as in Figure 11 and thus omitted for simplicity. is the same as in Figure 11; thus, it has been omitted for
simplicity.
POST /tips HTTP/1.1 POST /tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-tips+json, application/alto-error+json Accept: application/alto-tips+json, application/alto-error+json
Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 41 Content-Length: 41
{ {
"resource-id": "my-routingcost-map" "resource-id": "my-routingcost-map"
skipping to change at page 25, line 5 skipping to change at line 1120
} }
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/alto-tips+json Content-Type: application/alto-tips+json
Content-Length: 258 Content-Length: 258
{....} {....}
Figure 12: Open Example with Digest Authentication Figure 12: Open Example with Digest Authentication
6.3.3. Example using ALTO/SSE 6.3.3. Example Using ALTO/SSE
This section gives an example of receiving incremental updates of the This section gives an example of receiving incremental updates of the
TIPS view summary using ALTO/SSE [RFC8895]. Consider the tips-sse TIPS view summary using ALTO/SSE [RFC8895]. Consider the "tips-sse"
resource, as announced by the IRD in Figure 6, which provides ALTO/ resource, as announced by the IRD in Figure 6, which provides ALTO/
SSE for the update-my-cost-tips resource, a client may send the SSE for the "update-my-cost-tips" resource; a client might send the
following request to receive updates of the TIPS view (authentication following request to receive updates of the TIPS view (authentication
is omitted for simplicity). is omitted for simplicity).
POST /updates/tips HTTP/1.1 POST /updates/tips HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: text/event-stream,application/alto-error+json Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json Content-Type: application/alto-updatestreamparams+json
Content-Length: 76 Content-Length: 76
{ {
"add": { "add": {
"tips-123": { "resource-id": "update-my-cost-tips" } "tips-123": { "resource-id": "update-my-cost-tips" }
} }
} }
Figure 13: Example of Monitoring TIPS view with ALTO/SSE Figure 13: Example of Monitoring TIPS View with ALTO/SSE
Then, the client will be able to receive the TIPS view summary as Then, the client will be able to receive the TIPS view summary as
follows. follows.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Connection: keep-alive Connection: keep-alive
Content-Type: text/event-stream Content-Type: text/event-stream
event: application/alto-tips+json,tips-123 event: application/alto-tips+json,tips-123
data: { data: {
skipping to change at page 25, line 50 skipping to change at line 1165
data: "start-seq": 101, data: "start-seq": 101,
data: "end-seq": 106, data: "end-seq": 106,
data: "start-edge-rec" : { data: "start-edge-rec" : {
data: "seq-i": 0, data: "seq-i": 0,
data: "seq-j": 105 data: "seq-j": 105
data: } data: }
data: } data: }
data: } data: }
data: } data: }
When there is an update to the TIPS view, for example, the end-seq is When there is an update to the TIPS view (for example, when the "end-
increased by 1, the client will be able to receive the incremental seq" field is increased by 1), the client will be able to receive the
update of the TIPS view summary as follows. incremental update of the TIPS view summary as follows.
event: application/merge-patch+json,tips-123 event: application/merge-patch+json,tips-123
data: { data: {
data: "tips-view-summary": { data: "tips-view-summary": {
data: "updates-graph-summary": { data: "updates-graph-summary": {
data: "end-seq": 107 data: "end-seq": 107
data: } data: }
data: } data: }
data: } data: }
skipping to change at page 26, line 40 skipping to change at line 1204
For example, consider the updates graph in Figure 4. If the client For example, consider the updates graph in Figure 4. If the client
wants to query the content of the first update item (0 -> 101) whose wants to query the content of the first update item (0 -> 101) whose
media type is "application/alto-costmap+json", it sends a request to media type is "application/alto-costmap+json", it sends a request to
"/tips/2718281828/ug/0/101" and sets the "Accept" header to "/tips/2718281828/ug/0/101" and sets the "Accept" header to
"application/alto-costmap+json,application/alto-error+json". See "application/alto-costmap+json,application/alto-error+json". See
Section 7.3 for a concrete example. Section 7.3 for a concrete example.
7.2. Response 7.2. Response
If the request is valid (ug/<i>/<j> exists), the response is encoded If the request is valid (i.e., "ug/<i>/<j>" exists), the response is
as a JSON object whose data format is indicated by the media type. encoded as a JSON object whose data format is indicated by the media
type.
A client MAY conduct proactive fetching of future updates, by long A client MAY conduct proactive fetching of future updates, by long
polling updates that have not been provided in the directory yet. polling updates that have not been provided in the directory yet.
For such updates, the client MUST indicate all media types that may For such updates, the client MUST indicate all media types that might
appear. It is RECOMMENDED that the server allows for at least the appear. It is RECOMMENDED that the server allow for at least the
long polling of <end-seq> -> <end-seq + 1>. long polling of <end-seq> -> <end-seq + 1>.
Hence, the server processing logic MUST be: Hence, the server processing logic MUST be:
* If ug/<i>/<j> exists: return content using encoding. * If a resource with path "ug/<i>/<j>" exists, return content using
encoding.
* Else if long polling ug/<i>/<j> is acceptable: put request in a * Else, if long polling "ug/<i>/<j>" is acceptable, put request in a
backlog queue, then either a response is triggered when the backlog queue, then either a response is triggered when the
content is ready or the request is interrupted, e.g., by a network content is ready or the request is interrupted (e.g., by a network
error. error).
* Else: return error. * Else, return error.
It is RECOMMENDED that the server uses the following HTTP codes to It is RECOMMENDED that the server use the following HTTP codes to
indicate errors, with the media type "application/alto-error+json", indicate errors, with the media type "application/alto-error+json",
regarding update item requests. regarding update item requests.
* 404 (Not Found): if the requested update does not exist, or the 404 (Not Found): Indicates that the requested update does not exist
requested TIPS view does not exist or is closed by the server. or the requested TIPS view does not exist or is closed by the
server.
* 410 (Gone): if an update has a seq that is smaller than the start- 410 (Gone): Indicates an update has a seq that is smaller than the
seq. <start-seq>.
* 415 (Unsupported Media Type): if the media type(s) accepted by the 415 (Unsupported Media Type): Indicates the media type (or types)
client does not include the media type of the update chosen by the accepted by the client does not include the media type of the
server. update chosen by the server.
* 425 (Too Early): if the seq exceeds the server long-polling window 425 (Too Early): Indicates the seq exceeds the server long polling
window.
* 429 (Too Many Requests): when the number of pending (long-poll) 429 (Too Many Requests): Indicates the number of pending (long poll)
requests exceeds the server threshold. The server MAY indicate requests exceeds the server threshold. The server MAY indicate
when to re-try the request in the "Re-Try After" headers. when to retry the request in the "Re-Try After" headers.
7.3. Example 7.3. Example
Assume the client wants to get the contents of the update item on Assume the client wants to get the contents of the update item on
edge 0 to 101. The format of the request is shown in Figure 14. edge 0 to 101. The format of the request is shown in Figure 14.
GET /tips/2718281828/ug/0/101 HTTP/1.1 GET /tips/2718281828/ug/0/101 HTTP/1.1
Host: alto.example.com Host: alto.example.com
Accept: application/alto-costmap+json, \ Accept: application/alto-costmap+json, \
application/alto-error+json application/alto-error+json
skipping to change at page 28, line 8 skipping to change at line 1273
Content-Type: application/alto-costmap+json Content-Type: application/alto-costmap+json
Content-Length: 50 Content-Length: 50
{ ... full replacement of my-routingcost-map ... } { ... full replacement of my-routingcost-map ... }
Figure 15: Response to a GET Request Figure 15: Response to a GET Request
7.4. New Next Edge Recommendation 7.4. New Next Edge Recommendation
While intended TIPS usage is for the client to receive a recommended While intended TIPS usage is for the client to receive a recommended
starting edge in the TIPS summary, consume that edge, then construct starting edge in the TIPS summary, consume that edge, and then
all future URIs by incrementing the sequence count by 1, there may be construct all future URIs by incrementing the sequence count by one,
cases in which the client needs to request a new next edge to there may be cases in which the client needs to request a new next
consume. For example, if a client has an open TIPS view yet has not edge to consume. For example, if a client has an open TIPS view but
polled in a while, the client may request the next logical has not polled in a while, the client might request the next logical
incremental URI but the server has compacted the updates graph so it incremental URI; however, the server has compacted the updates graph,
no longer exists. Thus, the client MAY request a new next edge to so it no longer exists. Thus, the client MAY request a new next edge
consume based on its current version of the resource. to consume based on its current version of the resource.
7.4.1. Request 7.4.1. Request
An ALTO client requests that the server provide a next edge An ALTO client requests that the server provide a next edge
recommendation for a given TIPS view by sending an HTTP POST request recommendation for a given TIPS view by sending an HTTP POST request
with the media type "application/alto-tipsparams+json". The URL of with the media type "application/alto-tipsparams+json". The URL of
the request MUST have the format of the request MUST have the following format:
<tips-view-path>/ug <tips-view-path>/ug
and the HOST field MUST be the <tips-view-host>. and the "HOST" field MUST be "<tips-view-host>".
The POST body has the same format as the TIPSReq Figure 7. The The POST body has the same format as the TIPSReq in Figure 7. The
resource-id MUST be the same as the resource ID used to create the "resource-id" field MUST be the same as the resource ID used to
TIPS view, and the optional input field MUST NOT be present. create the TIPS view, and the optional "input" field MUST NOT be
present.
7.4.2. Response 7.4.2. Response
The response to a valid request MUST be a JSON merge patch to the The response to a valid request MUST be a JSON merge patch to the
object of type AddTIPSResponse (defined in Section 6.2), denoted as object of the AddTIPSResponse type (defined in Section 6.2), denoted
media type "application/merge-patch+json". The "update-graph- as media type "application/merge-patch+json". The "updates-graph-
summary" field MUST be present in the response and hence its parent summary" field MUST be present in the response; hence, its parent
field "tips-view-summary" MUST be present as well. field "tips-view-summary" MUST be present as well.
If the tag field is present in the request, the server MUST check if If the "tag" field is present in the request, the server MUST check
any version within the range [start-seq, end-seq] has the same tag if any version within the range [<start-seq>, <end-seq>] has the same
value. If the version exists, e.g., denoted as tag-seq, the server tag value. If the version exists (e.g., denoted as <tag-seq>), the
MUST compute the paths from both tag-seq and 0 to the end-seq, and server MUST compute the paths from both <tag-seq> and 0 to the <end-
choose the one with the minimal cost. The cost MAY be implementation seq> and choose the one with the minimal cost. The cost MAY be
specific, e.g., number of messages, accumulated data size, etc. The implementation specific (e.g., number of messages, accumulated data
first edge of the selected path MUST be returned as the recommended size, etc.). The first edge of the selected path MUST be returned as
next edge. the recommended next edge.
If the tag field is NOT present, it MUST be interpreted as the tag- If the "tag" field is not present, the interpretation MUST be that
seq is 0. the <tag-seq> is 0.
It is RECOMMENDED that the server uses the following HTTP codes to It is RECOMMENDED that the server use the following HTTP code to
indicate errors, with the media type "application/alto-error+json", indicate errors, with the media type "application/alto-error+json",
regarding new next edge requests. regarding new next edge requests.
* 404 (Not Found): if the requested TIPS view does not exist or is 404 (Not Found): Indicates that the requested TIPS view does not
closed by the server. exist or has been closed by the server.
7.4.3. Example 7.4.3. Example
We give an example of the new next edge recommendation service. In this section, we give an example of the new next edge
Assume that a client already creates a TIPS view as in Section 6.3, recommendation service. Assume that a client already creates a TIPS
whose updates graph is as shown in Figure 2. Now assume that the view (as in Section 6.3) whose updates graph is as shown in Figure 2.
client already has tag 0881080 whose corresponding sequence number is Now assume that the client already has tag 0881080, whose
103, and sends the following new next edge recommendation request corresponding sequence number is 103, and sends the following new
(authentication is omitted for simplicity): next edge recommendation request (authentication is omitted for
simplicity):
POST /tips/2718281828/ug HTTP/1.1 POST /tips/2718281828/ug HTTP/1.1
HOST alto.example.com HOST alto.example.com
Accept: application/merge-patch+json, application/alto-error+json Accept: application/merge-patch+json, application/alto-error+json
Content-Type: application/alto-tipsparams+json Content-Type: application/alto-tipsparams+json
Content-Length: 62 Content-Length: 62
{ {
"resource-id": "my-routingcost-map", "resource-id": "my-routingcost-map",
"tag": "0881080" "tag": "0881080"
} }
According to Figure 2, there are 3 potential paths: 103 -> 104 -> 105 According to Figure 2, there are three potential paths: 103 -> 104 ->
-> 106, 103 -> 105 -> 106, and 0 -> 105 -> 106. Assume that the 105 -> 106, 103 -> 105 -> 106, and 0 -> 105 -> 106. Assume that the
server chooses shortest update path by the accumulated data size and server chooses the shortest update path by the accumulated data size
the best path is 103 -> 105 -> 106. Thus, the server responds with and the best path is 103 -> 105 -> 106. Thus, the server responds
the following message: with the following message:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/merge-patch+json Content-Type: application/merge-patch+json
Content-Length: 193 Content-Length: 193
{ {
"tips-view-summary": { "tips-view-summary": {
"updates-graph-summary": { "updates-graph-summary": {
"start-seq": 101, "start-seq": 101,
"end-seq": 106, "end-seq": 106,
skipping to change at page 30, line 27 skipping to change at line 1374
} }
} }
} }
} }
8. Operation and Processing Considerations 8. Operation and Processing Considerations
TIPS has some common operational considerations as ALTO/SSE TIPS has some common operational considerations as ALTO/SSE
[RFC8895], including: [RFC8895], including:
* server choosing update messages (Section 9.1 of [RFC8895]); * the server choosing update messages (Section 9.1 of [RFC8895]);
* client processing update messages (Section 9.2 of [RFC8895]); * the client processing update messages (Section 9.2 of [RFC8895]);
* updates of filtered map services (Section 9.3 of [RFC8895]); * the updates of filtered map services (Section 9.3 of [RFC8895]);
and
* updates of ordinal mode costs (Section 9.4 of [RFC8895]). * the updates of ordinal mode costs (Section 9.4 of [RFC8895]).
There are also some operation considerations specific to TIPS, which There are also some operational considerations specific to TIPS,
we discuss below. which we discuss below.
8.1. Considerations for Load Balancing 8.1. Considerations for Load Balancing
There are two levels of load balancing in TIPS. The first level is There are two levels of load balancing in TIPS: the first level is to
to balance the load of TIPS views for different clients, and the balance the load of TIPS views for different clients and the second
second is to balance the load of incremental updates. is to balance the load of incremental updates.
Load balancing of TIPS views can be achieved either at the Load balancing of TIPS views can be achieved either at the
application layer or at the infrastructure layer. For example, an application layer or at the infrastructure layer. For example, an
ALTO server MAY set <tips-view-host> to different subdomains to ALTO server MAY set <tips-view-host> to different subdomains to
distribute TIPS views, or simply use the same host of the TIPS distribute TIPS views or simply use the same host of the TIPS
service and rely on load balancers to distribute the load. information resource and rely on load balancers to distribute the
load.
TIPS allows a client to make concurrent pulls of incremental updates TIPS allows a client to make concurrent pulls of incremental updates
for the same TIPS view potentially through different HTTP for the same TIPS view, potentially through different HTTP
connections. As a consequence, it introduces additional complexities connections. As a consequence, TIPS introduces additional
when the ALTO server is being load balanced. For example, a request complexities when the ALTO server balances the load by distributing
may be directed to a wrong backend server and get incorrectly the requests to a set of backend servers. For example, a request
processed if the following two conditions both hold: might be directed to the wrong backend server and get processed
incorrectly if the following two conditions both hold:
* the backend servers are stateful, i.e., the TIPS view is created * these backend servers are stateful (i.e., the TIPS view is created
and stored only on a single server; and stored only on a single server); and
* the ALTO server is using layer-4 load balancing, i.e., the * the ALTO server is using Layer 4 load balancing (i.e., the
requests are distributed based on the TCP 5-tuple. requests are distributed based on the TCP 5-tuple).
Thus, additional considerations are required to enable correct load Thus, additional considerations are required to enable correct load
balancing for TIPS, including: balancing for TIPS, including:
* Use a stateless architecture: One solution is to follow the Using a stateless architecture: One solution is to follow the
stateless computing pattern: states about the TIPS view are not stateless computing pattern: states about the TIPS view are not
maintained by the backend servers but are stored in a distributed maintained by the backend servers but are stored in a distributed
database. Thus, concurrent requests to the same TIPS view can be database. Thus, concurrent requests to the same TIPS view can be
processed on arbitrary stateless backend servers, which all processed on arbitrary stateless backend servers, which all fetch
fetches data from the same database. data from the same database.
* Configure the load balancers properly: In case when the backend Configuring the load balancers properly: In the case that the
servers are stateful, the load balancers must be properly backend servers are stateful, the load balancers must be properly
configured to guarantee that requests of the same TIPS view always configured to guarantee that requests of the same TIPS view always
arrive at the same server. For example, an operator or a provider arrive at the same server. For example, an operator or a provider
of an ALTO server MAY configure layer-7 load balancers that of an ALTO server MAY configure Layer 7 load balancers that
distribute requests based on the tips-view-path component in the distribute requests based on the tips-view-path component in the
URI. URI.
8.2. Considerations for Cross-Resource Dependency Scheduling 8.2. Considerations for Cross-Resource Dependency Scheduling
Dependent ALTO resources result in cross-resource dependencies in Dependent ALTO resources result in cross-resource dependencies in
TIPS. Consider the following pair of resources, where my-cost-map TIPS. Consider the following pair of resources, where my-cost-map
(C) is dependent on my-network-map (N). The updates graph for each (C) is dependent on my-network-map (N). The updates graph for each
resource is shown, along with links in between the respective updates resource is shown, along with links between the respective updates
graphs to show dependency: graphs to show dependency:
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 | my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| \ \ \ | \ \ \
| \ \ \ | \ \ \
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
my-cost-map (C) | 0 |-->|101|-->|102|-->|103|-->|104| my-cost-map (C) | 0 |-->|101|-->|102|-->|103|-->|104|
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
skipping to change at page 32, line 14 skipping to change at line 1460
In Figure 16, the cost-map versions 101 and 102 (denoted as C101 and In Figure 16, the cost-map versions 101 and 102 (denoted as C101 and
C102) are dependent on the network-map version 89 (denoted as N89). C102) are dependent on the network-map version 89 (denoted as N89).
The cost-map version 103 (C103) is dependent on the network-map The cost-map version 103 (C103) is dependent on the network-map
version 90 (N90), and so on. version 90 (N90), and so on.
Thus, the client must decide the order in which to receive and apply Thus, the client must decide the order in which to receive and apply
the updates. The order may affect how fast the client can build a the updates. The order may affect how fast the client can build a
consistent view and how long the client needs to buffer the update. consistent view and how long the client needs to buffer the update.
* Example 1: The client requests N89, N90, N91, C101, C102 in that Example 1: The client requests N89, N90, N91, C101, C102 in that
order. The client either gets no consistent view of the resources order. The client either gets no consistent view of the resources
or has to buffer N90 and N91. or has to buffer N90 and N91.
* Example 2: The client requests C101, C102, C103, N89. The client Example 2: The client requests C101, C102, C103, N89. The client
either gets no consistent view or has to buffer C103. either gets no consistent view or has to buffer C103.
To get consistent ALTO information, a client must process the updates To get consistent ALTO information, a client must process the updates
following the guidelines specified in Section 9.2 of [RFC8895]. If following the guidelines specified in Section 9.2 of [RFC8895]. If
resource permits (i.e., sufficient updates can be buffered), an ALTO resources permit (i.e., sufficient updates can be buffered), an ALTO
client can safely use long polling to fetch all the updates. This client can safely use long polling to fetch all the updates. This
allows a client to build consistent views quickly as the updates are allows a client to build consistent views quickly as the updates are
already stored in the buffer. Otherwise, it is RECOMMENDED to already stored in the buffer. Otherwise, it is RECOMMENDED to
request request a full snapshot if the client does not have enough local
resources to buffer and process the incremental updates.
8.3. Considerations for Managing Shared TIPS Views 8.3. Considerations for Managing Shared TIPS Views
From a client's point of view, it sees only one copy of the TIPS view From a client's point of view, it sees only one copy of the TIPS view
for any resource. However, on the server side, there are different for any resource. However, on the server side, there are different
implementation options, especially for common resources (e.g., implementation options, especially for common resources (e.g.,
network map or cost map) that may be frequently queried by many network maps or cost maps) that may be frequently queried by many
clients. Some potential options are listed below: clients. Some potential options are listed below:
* An ALTO server creates one TIPS view of the common resource for * An ALTO server creates one TIPS view of the common resource for
each client. each client.
* An ALTO server maintains one copy of the TIPS view for each common * An ALTO server maintains one copy of the TIPS view for each common
resource and all clients requesting the same resources use the resource and all clients requesting the same resources use the
same copy. There are two ways to manage the storage for the same copy. There are two ways to manage the storage for the
shared copy: shared copy:
- the ALTO server maintains the set of clients that have sent a - the ALTO server maintains the set of clients that have sent a
polling request to the TIPS view, and only removes the view polling request to the TIPS view and only removes the view from
from the storage when the set becomes empty and no client the storage when the set becomes empty and no client
immediately issues a new edge request; immediately issues a new edge request; or
- the TIPS view is never removed from the storage. - the TIPS view is never removed from the storage.
Developers may choose different implementation options depending on Developers may choose different implementation options depending on
criteria such as request frequency, available resources of the ALTO criteria such as request frequency, available resources of the ALTO
server, the ability to scale, and programming complexity. server, the ability to scale, and programming complexity.
8.4. Considerations for Offering Shortcut Incremental Updates 8.4. Considerations for Offering Shortcut Incremental Updates
Besides the mandatory stepwise incremental updates (from i to i+1), Besides the mandatory stepwise incremental updates (from i to i+1),
an ALTO server MAY optionally offer shortcut incremental updates, or an ALTO server MAY optionally offer shortcut incremental updates, or
simple shortcuts, between two non-consecutive versions i and i+k (k > simple shortcuts, between two non-consecutive versions i and i+k (k >
1). Such shortcuts offer alternative paths in the update graph and 1). Such shortcuts offer alternative paths in the updates graph and
can potentially speed up the transmission and processing of can potentially speed up the transmission and processing of
incremental updates, leading to faster synchronization of ALTO incremental updates, leading to faster synchronization of ALTO
information, especially when the client has limited bandwidth and information, especially when the client has limited bandwidth and
computation. However, implementors of an ALTO server must be aware computation. However, implementors of an ALTO server must be aware
that: that:
1. Optional shortcuts may increase the size of the update graph, in 1. optional shortcuts may increase the size of the updates graph,
the worst case being the square of the number of updates (i.e., worst case scenario being the square of the number of updates
when a shortcut is offered for each version to all future (i.e., when a shortcut is offered for each version to all future
versions). versions).
2. Optional shortcuts require additional storage on the ALTO server. 2. optional shortcuts require additional storage on the ALTO server.
3. Optional shortcuts may reduce concurrency when the updates do not 3. optional shortcuts may reduce concurrency when the updates do not
overlap, e.g., when the updates apply to different parts of an overlap (e.g., when the updates apply to different parts of an
ALTO resource. In such a case, the total size of the original ALTO resource). In such a case, the total size of the original
updates is close to the size of the shortcut, but the original updates is close to the size of the shortcut, but the original
updates can be transmitted concurrently while the shortcut is updates can be transmitted concurrently while the shortcut is
transmitted in a single connection. transmitted in a single connection.
9. Security Considerations 9. Security Considerations
The security considerations (Section 15 of [RFC7285]) of the base The security considerations of the base protocol (Section 15 of
protocol fully apply to this extension. For example, the same [RFC7285]) fully apply to this extension. For example, the same
authenticity and integrity considerations (Section 15.1 of [RFC7285]) authenticity and integrity considerations (Section 15.1 of [RFC7285])
still fully apply; the same considerations for the privacy of ALTO still fully apply; the same considerations for the privacy of ALTO
users (Section 15.4 of [RFC7285]) also still fully apply. users (Section 15.4 of [RFC7285]) also still fully apply.
Additionally, operators of the ALTO servers MUST follow the Additionally, operators of the ALTO servers MUST follow the
guidelines in [RFC9325] to avoid new TLS vulnerabilities discovered guidelines in [RFC9325] to avoid new TLS vulnerabilities discovered
after [RFC7285] was published. after [RFC7285] was published.
The additional services (addition of update read service and update The additional services (the addition of update read service and
push service) provided by this extension extend the attack surface update push service) provided by this extension extend the attack
described in Section 15.1.1 of [RFC7285]. The following sub-sections surface described in Section 15.1.1 of [RFC7285]. The following
discuss the additional risks and their remedies. subsections discuss the additional risks and their remedies.
9.1. TIPS: Denial-of-Service Attacks 9.1. TIPS: Denial-of-Service Attacks
Allowing TIPS views enables new classes of Denial-of-Service attacks. Allowing TIPS views enables new classes of DoS attacks. In
In particular, for the TIPS server, one or multiple malicious ALTO particular, for the TIPS server, one or multiple malicious ALTO
clients might create an excessive number of TIPS views, to exhaust clients might create an excessive number of TIPS views, to exhaust
the server resource and/or to block normal users from the accessing the server resource and/or to block normal users from accessing the
the service. service.
To avoid such attacks, the server MAY choose to limit the number of To avoid such attacks, the server MAY choose to limit the number of
active views and reject new requests when that threshold is reached. active views and reject new requests when that threshold is reached.
TIPS allows predictive fetching and the server MAY also choose to TIPS allows predictive fetching and the server MAY also choose to
limit the number of pending requests. If a new request exceeds the limit the number of pending requests. If a new request exceeds the
threshold, the server MAY log the event and return the HTTP status threshold, the server MAY log the event and return the HTTP status
"429 Too many requests". 429 (Too Many Requests).
It is important to note that the preceding approaches are not the It is important to note that the preceding approaches are not the
only possibilities. For example, it may be possible for TIPS to use only possibilities. For example, it might be possible for a TIPS
somewhat more clever logic involving TIPS view eviction policies, IP server to use somewhat more clever logic involving TIPS view eviction
reputation, rate-limiting, and compartmentalization of the overall policies, IP reputation, rate-limiting, and compartmentalization of
threshold into smaller thresholds that apply to subsets of potential the overall threshold into smaller thresholds that apply to subsets
clients. If service availability is a concern, ALTO clients MAY of potential clients. If service availability is a concern, ALTO
establish service level agreements with the ALTO server. clients MAY establish service level agreements with the ALTO server.
9.2. ALTO Client: Update Overloading or Instability 9.2. ALTO Client: Update Overloading or Instability
The availability of continuous updates can also cause overload for an The availability of continuous updates can also cause overload for an
ALTO client, in particular, an ALTO client with limited processing ALTO client, in particular, an ALTO client with limited processing
capabilities. The current design does not include any flow control capabilities. The current design does not include any flow control
mechanisms for the client to reduce the update rates from the server. mechanisms for the client to reduce the update rates from the server.
For example, TCP, HTTP/2 and QUIC provide stream and connection flow For example, TCP, HTTP/2, and QUIC provide stream and connection flow
control data limits, which might help prevent the client from being control data limits, which might help prevent the client from being
overloaded. Under overloading, the client MAY choose to remove the overloaded. Under overloading, the client MAY choose to remove the
information resources with high update rates. information resources with high update rates.
Also, under overloading, the client may no longer be able to detect Also, under overloading, the client might no longer be able to detect
whether information is still fresh or has become stale. In such a 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 case, the client should be careful in how it uses the information to
avoid stability or efficiency issues. avoid stability or efficiency issues.
10. IANA Considerations 10. IANA Considerations
IANA is requested to register the following media types from the IANA has registered the following media types from the registry
registry available at [IANA-Media-Type]: available at [IANA-Media-Type]:
* application/alto-tips+json: as described in Section 6.2; * application/alto-tips+json: as described in Section 6.2;
* application/alto-tipsparams+json: as described in Section 6.1; * application/alto-tipsparams+json: as described in Section 6.1;
Note to the RFC Editor: Please replace This-Document with the RFC
number to be assigned to this document.
10.1. application/alto-tips+json Media Type 10.1. application/alto-tips+json Media Type
Type name: application Type name: application
Subtype name: alto-tips+json Subtype name: alto-tips+json
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: Encoding considerations are identical to Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See those specified for the "application/json" media type. See
[RFC8259]. [RFC8259].
Security considerations: See the Security Considerations section of Security considerations: See the Security Considerations section of
This-Document. RFC 9569.
Interoperability considerations: N/A. Interoperability considerations: N/A
Published specification: Section 6.2 of This-Document. Published specification: Section 6.2 of RFC 9569.
Applications that use this media type: ALTO servers and ALTO clients Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications. either stand alone or are embedded within other applications.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): RFC 9569 uses the media type to refer to
File extension(s): This document uses the media type to refer to protocol messages; thus, it does not require a file extension.
protocol messages and thus does not require a file extension.
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut Person & email address to contact for further information:
hors' Addresses section. See the Authors' Addresses section of RFC 9569.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section. Author: See the Authors' Addresses section of RFC 9569.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
Provisional registration?: No Change controller: Internet Engineering Task Force (iesg@ietf.org).
10.2. application/alto-tipsparams+json Media Type 10.2. application/alto-tipsparams+json Media Type
Type name: application Type name: application
Subtype name: alto-tipsparams+json Subtype name: alto-tipsparams+json
Required parameters: N/A Required parameters: N/A
Optional parameters: N/A Optional parameters: N/A
Encoding considerations: Encoding considerations are identical to Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See those specified for the "application/json" media type. See
[RFC8259]. [RFC8259].
Security considerations: See the Security Considerations section of Security considerations: See the Security Considerations section of
This-Document. RFC 9569.
Interoperability considerations: N/A. Interoperability considerations: N/A
Published specification: Section 6.1 of This-Document. Published specification: Section 6.1 of RFC 9569.
Applications that use this media type: ALTO servers and ALTO clients Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications. either stand alone or are embedded within other applications.
Fragment identifier considerations: N/A Fragment identifier considerations: N/A
Additional information: Additional information:
Deprecated alias names for this type: N/A Deprecated alias names for this type: N/A
Magic number(s): N/A Magic number(s): N/A
File extension(s): RFC 9569 uses the media type to refer to
File extension(s): This document uses the media type to refer to protocol messages; thus, it does not require a file extension.
protocol messages and thus does not require a file extension.
Macintosh file type code(s): N/A Macintosh file type code(s): N/A
Person and email address to contact for further information: See Aut Person & email address to contact for further information:
hors' Addresses section. See the Authors' Addresses section of RFC 9569.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: N/A Restrictions on usage: N/A
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force Author: See the Authors' Addresses section of RFC 9569.
(mailto:iesg@ietf.org).
Provisional registration?: No Change controller: Internet Engineering Task Force (iesg@ietf.org).
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/rfc/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/rfc/rfc8895>. 2020, <https://www.rfc-editor.org/info/rfc8895>.
[RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9112] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112, Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/rfc/rfc9112>. June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, [RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022, DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/rfc/rfc9113>. <https://www.rfc-editor.org/info/rfc9113>.
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
June 2022, <https://www.rfc-editor.org/rfc/rfc9114>. June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/rfc/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
11.2. Informative References 11.2. Informative References
[IANA-Media-Type] [IANA-Media-Type]
"Media Types", June 2023, IANA, "Media Types",
<https://www.iana.org/assignments/media-types/media- <https://www.iana.org/assignments/media-types>.
types.xhtml>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
Unique IDentifier (UUID) URN Namespace", RFC 4122, RFC 7617, DOI 10.17487/RFC7617, September 2015,
DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc7617>.
<https://www.rfc-editor.org/rfc/rfc4122>.
[RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56, [RFC9205] Nottingham, M., "Building Protocols with HTTP", BCP 56,
RFC 9205, DOI 10.17487/RFC9205, June 2022, RFC 9205, DOI 10.17487/RFC9205, June 2022,
<https://www.rfc-editor.org/rfc/rfc9205>. <https://www.rfc-editor.org/info/rfc9205>.
[RFC9562] Davis, K., Peabody, B., and P. Leach, "Universally Unique
IDentifiers (UUIDs)", RFC 9562, DOI 10.17487/RFC9562, May
2024, <https://www.rfc-editor.org/info/rfc9562>.
Appendix A. A High-Level Deployment Model Appendix A. A High-Level Deployment Model
Conceptually, the TIPS system consists of three types of resources: Conceptually, the TIPS system consists of three types of resources:
* (R1) TIPS frontend to create TIPS views. (R1): The TIPS frontend to create TIPS views.
* (R2) TIPS view directory, which provides metadata (e.g., (R2): The TIPS view directory, which provides metadata (e.g.,
references) about the network resource data. references) about the network resource data.
* (R3) The actual network resource data, encoded as complete ALTO (R3): The actual network resource data, encoded as complete ALTO
network resources (e.g., cost map, network map) or incremental network resources (e.g., a cost map or a network map) or
updates. incremental updates.
+------------------------------------------------+ +------------------------------------------------+
| | | |
+------+ |R1: Frontend/Open R2: Directory/Meta R3: Data | +------+ |R1: Frontend/Open R2: Directory/Meta R3: Data |
| | "iget" base | +-----+ +-----+ +-----+ | | | "iget" base | +-----+ +-----+ +-----+ |
| | resource 1 | | | | | | | | | | resource 1 | | | | | | | |
| |-------------|---->| | | | | | | | |-------------|---->| | | | | | |
| | incremental | | | | |-------->| | | | | incremental | | | | |-------->| | |
| | transfer | | | | | | | | | | transfer | | | | | | | |
| | resource | | | | | | | | | | resource | | | | | | | |
skipping to change at page 39, line 31 skipping to change at line 1791
| | resource | | | | | | | | resource | | | | | |
| |<------------|-----------------------| | | | | | |<------------|-----------------------| | | | |
+------+ | +-----+ +-----+ | +------+ | +-----+ +-----+ |
| | | |
+------------------------------------------------+ +------------------------------------------------+
Figure 17: Sample TIPS Deployment Model Figure 17: Sample TIPS Deployment Model
Design Point: Component Resource Location Design Point: Component Resource Location
* Design 1 (Single): all the three resource types at the same, Design 1 (Single): all the three resource types at the same single
single server (accessed via relative reference) server (accessed via relative reference).
* Design 2 (Flexible): all three resource types can be at their own Design 2 (Flexible): all three resource types can be at their own
server (accessed via absolute reference) server (accessed via absolute reference).
* Design 3 (Dir + Data): R2 and R3 must remain together, though R1 Design 3 (Dir + Data): R2 and R3 must remain together, though R1
might not be on the same server might not be on the same server.
This document supports Design 1 and Design 3. For Design 1, the TIPS This document supports Designs 1 and 3. For Design 1, the ALTO
service simply needs to always use the same host for the TIPS views. server simply needs to always use the same host for the TIPS views.
For Design 3, the TIPS service can set tips-view-host to a different For Design 3, the ALTO server can set tips-view-host to a different
server. Note that the deployment flexibility is at the logical server. Note that the deployment flexibility is at the logical
level, as these services can be distinguished by different paths and level, as these services can be distinguished by different paths and
potentially be routed to different physical servers by layer-7 load potentially be routed to different physical servers by Layer 7 load
balancing. See Section 8.1 for a discussion on load balancing balancing. See Section 8.1 for a discussion on load balancing
considerations. Future documents may extend the protocol to support considerations. Future documents could extend the protocol to
Design 2. support Design 2.
Appendix B. Conformance to "Building Protocols with HTTP" Best Current Appendix B. Conformance with "Building Protocols with HTTP" (RFC 9205)
Practices Best Current Practices
This specification adheres fully to [RFC9205] as further elaborated This specification adheres fully to [RFC9205] as further elaborated
below: below:
* TIPS does not "redefine, refine, or overlay the semantics of * TIPS does not (as described in Section 3.1 of [RFC9205]):
generic protocol elements such as methods, status codes, or
existing header fields" and instead focuses on "protocol elements | ...redefine, refine, or overlay the semantics of generic
that are specific to [the TIPS] application -- namely, [its] HTTP | protocol elements such as methods, status codes, or existing
resources" (Section 3.1 of [RFC9205]). | header fields.
and instead focuses on
| ...protocol elements that are specific to [the TIPS]
| application -- namely, [its] HTTP resources.
* There are no statically defined URI components (Section 3.2 of * There are no statically defined URI components (Section 3.2 of
[RFC9205]). [RFC9205]).
* No minimum version of HTTP is specified by TIPS which is * No minimum version of HTTP is specified by TIPS, which is
recommended (Section 4.1 of [RFC9205]). recommended (in Section 4.1 of [RFC9205]).
* The TIPS design follows the advice that "When specifying examples * The TIPS design follows the advice (in Section 4.1 of [RFC9205])
of protocol interactions, applications should document both the that:
request and response messages with complete header sections,
preferably in HTTP/1.1 format" (Section 4.1 of [RFC9205]).
* TIPS uses URI templates which is recommended (Section 4.2 of | When specifying examples of protocol interactions, applications
| should document both the request and response messages with
| complete header sections, preferably in HTTP/1.1 format...
* TIPS uses URI templates, which is recommended (in Section 4.2 of
[RFC9205]). [RFC9205]).
* TIPS follows the pattern that "a client will begin interacting * TIPS follows the pattern (in Section 4.4.1 of [RFC9205]) that:
with a given application server by requesting an initial document
that contains information about that particular deployment, | Generally, a client will begin interacting with a given
potentially including links to other relevant resources. Doing so | application server by requesting an initial document that contains
ensures that the deployment is as flexible as possible | information about that particular deployment, potentially
(potentially spanning multiple servers), allows evolution, and | including links to other relevant resources. Doing so ensures
also allows the application to tailor the "discovery document" to | that the deployment is as flexible as possible (potentially
the client" (Section 4.4.1 of [RFC9205]). | spanning multiple servers), allows evolution, and also gives the
| application the opportunity to tailor the "discovery document" to
| the client.
* TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]). * TIPS uses existing HTTP schemes (Section 4.4.2 of [RFC9205]).
* TIPS defines its errors "to use the most applicable status code" * TIPS defines its errors "to use the most applicable status code"
(Section 4.6 of [RFC9205]). (Section 4.6 of [RFC9205]).
* TIPS does not "make assumptions about the relationship between * TIPS does not (as in Section 4.11 of [RFC9205]):
separate requests on a single transport connection; doing so
breaks many of the assumptions of HTTP as a stateless protocol and
will cause problems in interoperability, security, operability,
and evolution" (Section 4.11 of [RFC9205]). The only relationship
between requests is that a client must first discover where a TIPS
view of a resource will be served, which is consistent with the
URI discovery in Section 4.4.1 of [RFC9205].
Appendix C. Push-mode TIPS using HTTP Server Push | ...make assumptions about the relationship between separate
| requests on a single transport connection; doing so breaks many of
| the assumptions of HTTP as a stateless protocol and will cause
| problems in interoperability, security, operability, and
| evolution.
The only relationship between requests is that a client has to
first discover where a TIPS view of a resource will be served,
which is consistent with the URI discovery in Section 4.4.1 of
[RFC9205].
Appendix C. Push-Mode TIPS Using HTTP Server Push
TIPS allows ALTO clients to subscribe to incremental updates of an TIPS allows ALTO clients to subscribe to incremental updates of an
ALTO resource, and the specification in this document is based on the ALTO resource, and the specification in this document is based on the
current best practice of building such a service using native HTTP. current best practice of building such a service using basic HTTP.
Earlier versions of this document had investigated the possibility of Earlier versions of this document had investigated the possibility of
enabling push-mode TIPS, i.e., by taking advantage of the server push enabling push-mode TIPS (i.e., by taking advantage of the server push
feature in HTTP/2 and HTTP/3. feature in HTTP/2 and HTTP/3).
In the ideal case, push-mode TIPS can potentially improve performance In the ideal case, push-mode TIPS can potentially improve performance
(e.g., latency) in more dynamic environments and use cases, with (e.g., latency) in more dynamic environments and use cases with wait-
wait-free message delivery. Using native server push also results in free message delivery. Using the built-in HTTP server push also
minimal changes to the current protocol. While not adopted due to results in minimal changes to the current protocol. While not
the lack of server push support and increased protocol complexity, adopted due to the lack of server push support and increased protocol
push-mode TIPS remains a potential direction of protocol improvement. complexity, push-mode TIPS remains a potential direction of protocol
improvement.
Appendix D. Persistent HTTP Connections Appendix D. Persistent HTTP Connections
Previous versions of this document use persistent HTTP connections to Previous draft versions of this document use persistent HTTP
detect the liveness of clients. This design, however, does not connections to detect the liveness of clients. However, this design
conform well with the best current practice of HTTP. For example, if does not conform well with the best current practices of HTTP. For
an ALTO client is accessing a TIPS view over an HTTP proxy, the example, if an ALTO client is accessing a TIPS view over an HTTP
connection is not established directly between the ALTO client and proxy, the connection is not established directly between the ALTO
the ALTO server, but between the ALTO client and the proxy and client and the ALTO server, but between the ALTO client and the proxy
between the proxy and the ALTO server. Thus, using persistent and between the proxy and the ALTO server. Thus, using persistent
connections may not correctly detect the right liveness state. connections might not correctly detect the right liveness state.
Acknowledgments Acknowledgments
The authors of this document would like to thank Mark Nottingham and The authors of this document would like to thank Mark Nottingham and
Spencer Dawkins for providing invaluable reviews of earlier versions Spencer Dawkins for providing invaluable reviews of earlier draft
of this document, Adrian Farrel, Qin Wu, and Jordi Ros Giralt for versions of this document; Adrian Farrel, Qin Wu, and Jordi Ros
their continuous feedback, Russ White, Donald Eastlake, Martin Giralt for their continuous feedback; Russ White, Donald Eastlake
Thomson, Bernard Adoba, Spencer Dawkins, Linda Dunbar and Sheng Jiang 3rd, Martin Thomson, Bernard Adoba, Spencer Dawkins, Linda Dunbar,
for the directorate reviews, Martin Duke for the Area Director and Sheng Jiang for the directorate reviews; Martin Duke for the area
review, Francesca Palombini, Wesley Eddy, Roman Danyliw, Murray director review; Francesca Palombini, Wesley Eddy, Roman Danyliw,
Kucherawy and Zaheduzzaman Sarker for the telechat and IESG reviews, Murray Kucherawy, and Zaheduzzaman Sarker for the telechat and IESG
and Mohamed Boucadair for shepherding the document. reviews; and Mohamed Boucadair for shepherding the document.
Authors' Addresses Authors' Addresses
Kai Gao Kai Gao
Sichuan University Sichuan University
No.24 South Section 1, Yihuan Road No.24 South Section 1, Yihuan Road
Chengdu Chengdu
610000 610000
China China
Email: kaigao@scu.edu.cn Email: kaigao@scu.edu.cn
skipping to change at page 42, line 4 skipping to change at line 1921
Authors' Addresses Authors' Addresses
Kai Gao Kai Gao
Sichuan University Sichuan University
No.24 South Section 1, Yihuan Road No.24 South Section 1, Yihuan Road
Chengdu Chengdu
610000 610000
China China
Email: kaigao@scu.edu.cn Email: kaigao@scu.edu.cn
Roland Schott Roland Schott
Deutsche Telekom Deutsche Telekom
Ida-Rhodes-Straße 2 Deutsche-Telekom-Allee 9
64295 Darmstadt 64295 Darmstadt
Germany Germany
Email: Roland.Schott@telekom.de Email: Roland.Schott@telekom.de
Yang Richard Yang Yang Richard Yang
Yale University Yale University
51 Prospect Street 51 Prospect Street
New Haven, CT New Haven, CT 06511
United States of America United States of America
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Lauren Delwiche Lauren Delwiche
Yale University Yale University
51 Prospect Street 51 Prospect Street
New Haven, 3408 New Haven, CT 06511
United States of America United States of America
Email: lauren.delwiche@yale.edu Email: lauren.delwiche@yale.edu
Lachlan Keller Lachlan Keller
Yale University Yale University
51 Prospect Street 51 Prospect Street
New Haven, 3408 New Haven, CT 06511
United States of America United States of America
Email: lachlan.keller@yale.edu Email: lachlan.keller@aya.yale.edu
 End of changes. 230 change blocks. 
693 lines changed or deleted 715 lines changed or added

This html diff was produced by rfcdiff 1.48.