The Application-Layer Traffic Optimization (ALTO) Transport Information Publication Service (TIPS) Sichuan University
No.24 South Section 1, Yihuan Road Chengdu 610000 China kaigao@scu.edu.cn
Deutsche Telekom
Deutsche-Telekom-Allee 9 Darmstadt 64295 Germany Roland.Schott@telekom.de
Yale University
51 Prospect Street New Haven 06511 CT United States of America yry@cs.yale.edu
Yale University
51 Prospect Street New Haven CT 06511 United States of America lauren.delwiche@yale.edu
Yale University
51 Prospect Street New Haven CT 06511 United States of America lachlan.keller@aya.yale.edu
Transport Area ALTO "Application-Layer Traffic Optimization (ALTO) Protocol" (RFC 7285) leverages HTTP/1.1 and is designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources and the server responds with the complete content of each resource, one at a time. RFC 8895, which describes ALTO incremental updates using Server-Sent Events (SSE), defines a multiplexing protocol on top of HTTP/1.x, so that an ALTO server can incrementally push resource updates to clients whenever monitored network information resources change, allowing the clients to monitor multiple resources at the same time. However, HTTP/2 and later versions already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. To take advantage of newer HTTP features, this document introduces the ALTO Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to give an ALTO client the new capability to explicitly and concurrently (in a non-blocking manner) request (or pull) specific incremental updates using HTTP/2 or HTTP/3, while still functioning for HTTP/1.1.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
    • .  Requirements Language
    • .  Notations
  • .  TIPS Overview
    • .  Transport Requirements
    • .  TIPS Terminology
  • .  TIPS Updates Graph
    • .  Basic Data Model of an Updates Graph
    • .  Updates Graph Modification Invariants
  • .  TIPS Workflow and Resource Location Schema
    • .  Workflow
    • .  Resource Location Schema
  • .  TIPS Information Resource Directory (IRD) Announcement
    • .  Media Type
    • .  Capabilities
    • .  Uses
    • .  An Example
  • .  TIPS Management
    • .  Open Request
    • .  Open Response
    • .  Open Example
      • .  Basic Example
      • .  Example Using Digest Authentication
      • .  Example Using ALTO/SSE
  • .  TIPS Data Transfers - Client Pull
    • .  Request
    • .  Response
    • .  Example
    • .  New Next Edge Recommendation
      • .  Request
      • .  Response
      • .  Example
  • .  Operation and Processing Considerations
    • .  Considerations for Load Balancing
    • .  Considerations for Cross-Resource Dependency Scheduling
    • .  Considerations for Managing Shared TIPS Views
    • .  Considerations for Offering Shortcut Incremental Updates
  • .  Security Considerations
    • .  TIPS: Denial-of-Service Attacks
    • .  ALTO Client: Update Overloading or Instability
  • . IANA Considerations
    • .  application/alto-tips+json Media Type
    • .  application/alto-tipsparams+json Media Type
  • . References
    • .  Normative References
    • .  Informative References
  • .  A High-Level Deployment Model
  • .  Conformance with "Building Protocols with HTTP" (RFC 9205) Best Current Practices
  • .  Push-Mode TIPS Using HTTP Server Push
  • .  Persistent HTTP Connections
  • Acknowledgments
  • Authors' Addresses
Introduction The Application-Layer Traffic Optimization (ALTO) protocol provides means for network applications to obtain network status information. So far, the ALTO information can be transported in two ways:
  1. Using the ALTO base protocol , which is designed for the simple use case in which an ALTO client requests a network information resource and the server sends the complete content of the requested information (if any) resource to the client.
  2. Using ALTO incremental updates using Server-Sent Events (ALTO/SSE) ; this method is designed for an ALTO client to indicate to the server that it wants to receive updates for a set of resources, and the server can then concurrently and incrementally push updates to that client whenever monitored resources change.
Both protocols are designed for HTTP/1.1 . While they still work with HTTP/2 and HTTP/3 , ALTO and ALTO/SSE cannot take full advantage of new features offered by HTTP/2 and HTTP/3.
  • First, consider the ALTO base protocol, which is designed to transfer only complete information resources. A client can run the base protocol on top of HTTP/2 or HTTP/3 to request multiple information resources in concurrent streams, but each request must be for a complete information resource: there is no capability for the server to transmit incremental updates. Hence, there can be a large overhead when the client already has an information resource and then there are small changes to the resource.
  • Next, consider ALTO/SSE . Although ALTO/SSE can transfer incremental updates, it introduces a customized multiplexing protocol on top of HTTP, assuming a total-order message channel from the server to the client. The multiplexing design does not provide naming (i.e., a resource identifier) to individual incremental updates. Such a design cannot use concurrent data streams available in HTTP/2 and HTTP/3 because both cases require a resource identifier. Additionally, ALTO/SSE is a push-only protocol, which denies the client flexibility in choosing how and when it receives updates.
To mitigate these concerns, this document introduces a new ALTO service called the Transport Information Publication Service (TIPS). TIPS uses an incremental RESTful design to provide an ALTO client with a new capability to explicitly, concurrently issue non-blocking requests for specific incremental updates using HTTP/2 or HTTP/3, while still functioning for HTTP/1.1. While both ALTO/SSE and TIPS can transport incremental updates of ALTO information resources to clients, they have different design goals. The TIPS extension enables more scalable and robust distribution of incremental updates but is missing the session management and built-in server push capabilities of ALTO/SSE. From the performance perspective, TIPS is optimizing throughput by leveraging concurrent and out-of-order transport of data, while ALTO/SSE is optimizing latency as new events can be immediately transferred to the clients without waiting for another round of communication when there are multiple updates. Thus, we do not see TIPS as a replacement for ALTO/SSE, but as a complement to it. One example of combining these two extensions is shown in . Note that future extensions may leverage server push, a feature of HTTP/2 and HTTP/3 , as an alternative of SSE. We discuss why this alternative design is not ready at the time of writing in . Specifically, this document specifies:
  • Extensions to the ALTO Protocol for dynamic subscription and efficient uniform update delivery of an incrementally changing network information resource.
  • A new resource type that indicates the TIPS updates graph model for a resource.
  • URI patterns to fetch the snapshots or incremental updates.
Some operational complexities that must be taken into consideration when implementing this extension are discussed in : these include load balancing in and fetching and processing incremental updates of dependent resources in . discusses to what extent the TIPS design adheres to the best current practices for building protocols with HTTP .
Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.
Notations This document uses the same syntax and notations as introduced in to specify the extensions to existing ALTO resources and services.
TIPS Overview
Transport Requirements The ALTO Protocol and its extensions support two transport mechanisms:
  1. A client can directly request an ALTO resource and obtain a complete snapshot of that ALTO resource, as specified in the base protocol ;
  2. A client can subscribe to incremental changes of one or multiple ALTO resources using the incremental update extension , and a server pushes the updates to the client through SSE.
However, the current transport mechanisms are not optimized for storing, transmitting, and processing (incremental) updates of ALTO information resources. Specifically, the new transport mechanism must satisfy the following requirements:
Incremental updates:
Incremental updates only maintain and transfer the "diff" upon changes. Thus, it is more efficient than storing and transferring the full updates, especially when the change of an ALTO resource is minor. The base protocol does not support incremental updates and the current incremental update mechanism in has limitations (as discussed below).
Concurrent, non-blocking update transmission:
When a client needs to receive and apply multiple incremental updates, it is desired to transmit the updates concurrently to fully utilize the bandwidth and to reduce head-of-line blocking. Unfortunately, the ALTO incremental update extension does not satisfy this requirement. Even though the updates can be multiplexed by the server to avoid head-of-line blocking between multiple resources, the updates are delivered sequentially and can suffer from head-of-line blocking inside the connection (for example, when there is a packet loss).
Long polling updates:
Long polling updates can reduce the time to send the request, making it possible to achieve sub-RTT transmission of ALTO incremental updates. In , this requirement is fulfilled using SSE and is still desired in the new ALTO transport.
Backward compatibility:
While some of the previous requirements are offered by HTTP/2 and HTTP/3 , it is desired that the new ALTO transport mechanism can work with HTTP/1.1 as many development tools and current ALTO implementations are based on HTTP/1.1.
The new ALTO transport specified in this document satisfies all of the following design requirements above by:
  • Reusing the data format introduced in that enables incremental updates using JSON patches or merge patches.
  • Introducing a unified data model to describe the changes (snapshots and incremental updates) of an ALTO resource, referred to as a "TIPS view". In the data model, snapshots and incremental updates are indexed as individual HTTP resources following a unified naming convention, independent of the HTTP version. Thus, these updates can be concurrently requested and be transferred in a non-blocking manner either by using multiple connections or leveraging multiplexed data transfer offered by HTTP/2 or HTTP/3.
  • Basing the unified naming convention on a monotonically increasing sequence number, making it possible for a client to construct the URL of a future update and send a long polling request.
  • Making the unified naming convention independent of the HTTP versions and able to operate atop HTTP/1.1, HTTP/2, or HTTP/3.
This document assumes the deployment model discussed in .
TIPS Terminology In addition to the terms defined in , this document uses the following terms:
Transport Information Publication Service (TIPS):
A new type of ALTO service, as specified in this document, to enable a uniform transport mechanism for updates of an incrementally changing ALTO network information resource.
Network information resource:
A piece of retrievable information about network state, per .
TIPS view (tv):
The container of incremental transport information about the network information resource. The TIPS view has one basic component, the updates graph (ug), but may include other transport information.
Updates graph (ug):
A directed, acyclic graph whose nodes represent the set of versions of an information resource and whose edges represent the set of update items to compute these versions. An ALTO map service (e.g., a cost map or a network map) may need only a single updates graph. A dynamic network information service (e.g., a filtered cost map) may create an updates graph (within a new TIPS view) for each unique request. The encoding of an updates graph is specified in .
Version:
The representation of a historical content of an information resource. For an information resource, each version is associated with and uniquely identified by a monotonically and consecutively increased sequence number. This document uses the term "version s" to refer to the version associated with sequence number "s". The version is encoded as a JSONNumber, as specified in .
Start sequence number (<start-seq>):
The smallest non-zero sequence number in an updates graph.
End sequence number (<end-seq>):
The largest sequence number in an updates graph.
Snapshot:
A full replacement of a resource that is contained within an updates graph.
Incremental update:
A partial replacement of a resource contained within an updates graph, codified in this document as a JSON merge patch or a JSON patch. An incremental update is mandatory if the source version (i) and the target version (j) are consecutive (i.e., i + 1 = j); otherwise, it is optional (or a shortcut). Mandatory incremental updates are always in an updates graph, while optional/shortcut incremental updates may or may not be included in an updates graph.
Update item:
The content on an edge of the updates graph, which can be either a snapshot or an incremental update. An update item can be considered to be a pair (op, data) where op denotes whether the item is an incremental update or a snapshot and data is the content of the item.
ID#i-#j:
Denotation of the update item on a specific edge in the updates graph to transition from version i to version j, where i and j are the sequence numbers of the source node and the target node of the edge, respectively.
Overview of ALTO TIPS +-------------+ +-----------+ +--------------+ | Dynamic | +-----------+ | Routing | | Provisioning | | Network | | External | | Protocols | | Policy | | Information | | Interface | +-----------+ +--------------+ +-------------+ +-----------+ | | | | +-----------------------------------------------------------------+ | ALTO Server | | +-------------------------------------------------------------+ | | | Network Information | | | | +-------------+ +-------------+ | | | | | Information | | Information | | | | | | Resource #1 | | Resource #2 | | | | | +-------------+ +-------------+ | | | +-----|--------------------------------------/-------\--------+ | | | / \ | | +-----|------------------------------------/-----------\------+ | | | | Transport Information / \ | | | | +--------+ +--------+ +--------+ | | | | | tv1 | | tv2 | | tv3 | | | | | +--------+ +--------+ +--------+ | | | | | / | | | | | +--------+ +--------+ +--------+ | | | | | tv1/ug | | tv2/ug | | tv3/ug | | | | | +--------+ +--------+ +--------+ | | | +----|----\----------------|-------------------------|--------+ | | | \ | | | +------|------\--------------|-------------------------|----------+ | +------+ | | | \ | | +----------+ +----------+ +----------+ | Client 1 | | Client 2 | | Client 3 | +----------+ +----------+ +----------+ tvi = TIPS view i tvi/ug = incremental updates graph associated with tvi
shows an example illustrating an overview of the ALTO TIPS extension. The server provides TIPS for two information resources (#1 and #2) where #1 is an ALTO map service and #2 is a filterable service. There are three ALTO clients (Client 1, Client 2, and Client 3) that are connected to the ALTO server. 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 multiple clients. For the filtering service #2, two different TIPS views (tv2 and tv3) are created upon different client requests with different filter sets.
TIPS Updates Graph In order to provide incremental updates for a resource, an ALTO server creates an updates graph, which is a directed acyclic graph that contains a sequence of incremental updates and snapshots (collectively called "update items") of a network information resource.
Basic Data Model of an Updates Graph For each resource (e.g., a cost map or a network map), the incremental updates and snapshots can be represented using the following directed acyclic graph model, where the server tracks the change of the resource maps with version IDs that are assigned sequentially (i.e., incremented by one each time):
  • Each node in the graph is a version of the resource, which is identified by a sequence number (defined as a JSONNumber). Version 0 is reserved as the initial state (empty/null).
  • A tag identifies the content of a node. A tag has the same format as the "tag" field in and is valid only within the scope of the resource.
  • 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.
  • The version is path independent, i.e., different paths arriving at the node associated with the same version have the same content.
A concrete example is shown in . There are seven nodes in the graph, representing seven different versions of the resource. Edges in the figure represent the updates from the source version to the target version. Thick lines represent mandatory incremental updates (e.g., ID103-104), dotted lines represent optional incremental updates (e.g., ID103-105), and thin lines represent snapshots (e.g., ID0-103). Note that node content is path independent: the content of node v can be obtained by applying the updates from any path that ends at v. For example, assume the latest version is 105 and a client already has version 103. The base version of the client is 103 as it serves as a base upon which incremental updates can be applied. The target version 105 can be:
  • 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.
TIPS Model Example +======+ ------| 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 | +======+
Updates Graph Modification Invariants A server might change its updates graph (to compact it, to add nodes, etc.), but it will need to ensure that any resource state that it makes available is reachable by clients, either directly via a snapshot (that is, relative to 0) or indirectly by requesting an earlier snapshot and a contiguous set of incremental updates. Additionally, to allow clients to proactively construct URIs for future update items, the ID of each added node in the updates graph will need to increment contiguously by 1. More specifically, the updates graph MUST satisfy the following invariants:
Continuity:
At any time, let ns denote the smallest non-zero version (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 and ne MUST also exist. This implies that the incremental update from ni to ni + 1 exists for any ns <= ni <= ne, and all the version numbers in the updates graph (except 0) constitute exactly the integer interval [ns, ne].
Feasibility:
Let ns denote <start-seq> in the updates graph. The server MUST provide a snapshot of ns; in other words, there is always a direct link to ns in the updates graph.
"Right shift" only:
Assume a server provides versions in [n1, n2] at time t and versions in [n1', n2'] at time t'. If t' > t, then n1' >= n1 and n2' >= n2.
For example, consider the case that a server compacts a resource's updates graph to conserve space, using the example model in . Assume at time 0, the server provides the versions {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 {104, 105, 106} are not valid sets as there is no snapshot to 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 second example) cannot be obtained by a client that does not have the previous version 101 or 103, respectively.
TIPS Workflow and Resource Location Schema
Workflow At a high level, an ALTO client first requests the TIPS information resource (denoted as TIPS-F, where F is for frontend) to indicate the information resource or resources that the client wants to monitor. For each requested resource, the server returns a JSON object that contains a URI, which points to the root of a TIPS view (denoted as TIPS-V), and a summary of the current view, which contains the information to correctly interact with the current view. With the URI to the root of a TIPS view, clients can construct URIs (see ) to fetch incremental updates. An example workflow is shown in . After the TIPS-F receives the request from the client to monitor the updates of an ALTO resource, it creates a TIPS view resource and returns the corresponding information to the client. The URI points to that specific TIPS-V instance, and the summary contains the <start-seq> and <end-seq> of the updates graph and a server-recommended edge to consume first (e.g., from i to j). An ALTO client can then continuously pull each additional update with the information. For example, the client in first fetches 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>" might not yet exist, so the 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 load or due to client inactivity). In the event that a TIPS view is closed, an edge request will receive error code 404 (Not Found) in response, and the client will have to request a new TIPS view URI. If resources allow, a server SHOULD avoid closing TIPS views that have active polling edge requests or have recently served responses until clients have had a reasonable interval to request the next update, unless guided by specific control policies.
ALTO TIPS Workflow Supporting Client Pull Client TIPS-F TIPS-V o . . | POST to create/receive a TIPS view . Create TIPS . | for resource 1 . View . |-------------------------------------> |.-.-.-.-.-.-.-> | | <tips-view-uri>, <tips-view-summary> . | | <-------------------------------------| <-.-.-.-.-.-.-.| | . | GET /<tips-view-path>/ug/<i>/<j> . |------------------------------------------------------> | | content on edge i to j | | <------------------------------------------------------| | . | GET /<tips-view-path>/ug/<j>/<j+1> . |------------------------------------------------------> | . . . . | content on edge j to j+1 | | <------------------------------------------------------| | . o . . TIPS View Closed o
Resource Location Schema The resource location schema defines how a client constructs URIs to fetch incremental updates. To access each update in an updates graph, consider the model represented as a "virtual" file system (adjacency list), contained within the root of a TIPS view URI (see for the definition of tips-view-uri). For example, assuming that the updates graph of a TIPS view is as shown in , the location schema of this TIPS view will have the format as in .
Location Schema Example <tips-view-path> // root path to a TIPS view |_ ug // updates graph | |_ 0 | | |_ 101 // full 101 snapshot | | |_ 103 | | \_ 105 | |_ 101 | | \_ 102 // 101 -> 102 incremental update | |_ 102 | | \_ 103 | |_ 103 | | |_ 104 | | \_ 105 // optional shortcut 103 -> 105 incr. update | |_ 104 | | \_ 105 | \_ 105 | \_ 106 \_ ...
TIPS uses this directory schema to generate template URIs that allow clients to construct the location of incremental updates after 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 'j' in the updates graph is: <tips-view-uri>/ug/<i>/<j> 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 incremental update from 106 to 107). This can be done by constructing the URI for the next edge that will be added, starting from the sequence number of the current last node (denoted as <end-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> Incremental updates of a TIPS view are read-only. Thus, they are fetched using the HTTP GET method.
TIPS Information Resource Directory (IRD) Announcement To announce a TIPS information resource in the IRD, an ALTO server MUST specify "media-type", "capabilities", and "uses" as follows.
Media Type The media type of the Transport Information Publication Service (TIPS) resource is "application/alto-tips+json".
Capabilities The "capabilities" field of a TIPS information resource is modeled on that defined in . Specifically, the capabilities are defined as an object of the TIPSCapabilities type:
TIPSCapabilities object { IncrementalUpdateMediaTypes incremental-change-media-types; } TIPSCapabilities; object-map { ResourceID -> String; } IncrementalUpdateMediaTypes;
with the field:
incremental-change-media-types:
If a TIPS information resource can provide updates with incremental changes for a resource, the "incremental-change-media-types" field has an entry whose key is the ID of the resource and the value is the supported media types of incremental changes, separated by commas. For the implementation of this specification, this MUST be "application/merge-patch+json", "application/json-patch+json", or "application/merge-patch+json,application/json-patch+json", unless defined by a future extension. When choosing the media types to encode incremental updates for a resource, the server MUST consider the limitations of the encoding. For example, when a JSON merge patch specifies that the value of a field is null, its semantics are that the field is removed from the target; hence, the field is no longer defined (i.e., undefined). However, this may not be the intended result for the resource, when null and undefined have different semantics for the resource. In such a case, the server MUST choose JSON patch encoding over JSON merge patch encoding for the incremental update if both media types "application/json-patch+json" and "application/merge-patch" are supported by the TIPS information resource.
Uses The "uses" attribute MUST be an array with the resource IDs of every 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 resources and MAY include resources defined in linked IRDs. However, it is RECOMMENDED that the ALTO server selects a set that is closed under the resource dependency relationship. That is, if a TIPS information resource's "uses" set includes resource R1, and resource R1 depends on ("uses") resource R0, then the "uses" set should include R0 as well as R1. For example, if a TIPS information resource provides a TIPS view for a cost map, it should also provide 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" field of a TIPS information resource depends on another resource R0 that is not in the "uses" field of the same TIPS information resource. Thus, a client cannot receive incremental updates for another resource R0 that is not in the "uses" field of the same TIPS information resource. If the client observes in an update of R1 that 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.
An Example Extending the IRD example in , is the IRD of an ALTO server supporting the ALTO base protocol, ALTO/SSE, and ALTO TIPS.
Example of an ALTO Server Supporting the ALTO Base Protocol, ALTO/⁠SSE, and ALTO TIPS "my-network-map": { "uri": "https://alto.example.com/networkmap", "media-type": "application/alto-networkmap+json" }, "my-routingcost-map": { "uri": "https://alto.example.com/costmap/routingcost", "media-type": "application/alto-costmap+json", "uses": ["my-network-map"], "capabilities": { "cost-type-names": ["num-routingcost"] } }, "my-hopcount-map": { "uri": "https://alto.example.com/costmap/hopcount", "media-type": "application/alto-costmap+json", "uses": ["my-network-map"], "capabilities": { "cost-type-names": ["num-hopcount"] } }, "my-simple-filtered-cost-map": { "uri": "https://alto.example.com/costmap/filtered/simple", "media-type": "application/alto-costmap+json", "accepts": "application/alto-costmapfilter+json", "uses": ["my-network-map"], "capabilities": { "cost-type-names": ["num-routingcost", "num-hopcount"], "cost-constraints": false } }, "update-my-costs": { "uri": "https://alto.example.com/updates/costs", "media-type": "text/event-stream", "accepts": "application/alto-updatestreamparams+json", "uses": [ "my-network-map", "my-routingcost-map", "my-hopcount-map", "my-simple-filtered-cost-map" ], "capabilities": { "incremental-change-media-types": { "my-network-map": "application/json-patch+json", "my-routingcost-map": "application/merge-patch+json", "my-hopcount-map": "application/merge-patch+json" }, "support-stream-control": true } }, "update-my-costs-tips": { "uri": "https://alto.example.com/updates-new/costs", "media-type": "application/alto-tips+json", "accepts": "application/alto-tipsparams+json", "uses": [ "my-network-map", "my-routingcost-map", "my-hopcount-map", "my-simple-filtered-cost-map" ], "capabilities": { "incremental-change-media-types": { "my-network-map": "application/json-patch+json", "my-routingcost-map": "application/merge-patch+json", "my-hopcount-map": "application/merge-patch+json", "my-simple-filtered-cost-map": "application/merge-patch+json" } } }, "tips-sse": { "uri": "https://alto.example.com/updates/tips", "media-type": "text/event-stream", "accepts": "application/alto-updatestreamparams+json", "uses": [ "update-my-costs-tips" ], "capabilities": { "incremental-change-media-types": { "update-my-costs-tips": "application/merge-patch+json" } } }
Note that it is straightforward for an ALTO server to run HTTP/2 and support concurrent retrieval of multiple resources such as "my-network-map" and "my-routingcost-map" using multiple HTTP/2 streams. The resource "update-my-costs-tips" provides an ALTO TIPS information resource, and this is indicated by the media type "application/alto-tips+json".
TIPS Management Upon request, a server sends a TIPS view to a client. This TIPS view might be created at the time of the request or might already exist (either because another client has already created a TIPS view for the same requested network resource or because the server perpetually maintains a TIPS view for an often-requested resource).
Open Request 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 "application/alto-tipsparams+json". That body contains a JSON object of the TIPSReq type, where:
TIPSReq object { ResourceID resource-id; [JSONString tag;] [Object input;] } TIPSReq;
with the following fields:
resource-id:
This field contains the resource ID of an ALTO resource to be monitored, which MUST be in the TIPS information resource's "uses" list (). If a client does not support all incremental methods from the set announced in the server's capabilities, the client MUST NOT use the TIPS information resource.
tag:
If the "resource-id" is associated with a GET-mode resource with a version tag (or "vtag"), as defined in , and the ALTO client has previously retrieved a version of that resource from ALTO, the ALTO client MAY set the "tag" field to the tag part of the client's version of that resource. The server MAY use the tag when calculating a recommended starting edge for the client to consume. Note that the client MUST support all incremental methods from the set announced in the server's capabilities for this resource.
input:
If the resource is a POST-mode service that requires input, the ALTO client MUST set the "input" field to a JSON object with the parameters that the resource expects.
Open Response The response to a valid request MUST be a JSON object of the AddTIPSResponse type, denoted as media type "application/alto-tips+json":
AddTIPSResponse object { URI tips-view-uri; TIPSViewSummary tips-view-summary; } AddTIPSResponse; object { UpdatesGraphSummary updates-graph-summary; } TIPSViewSummary; object { JSONNumber start-seq; JSONNumber end-seq; StartEdgeRec start-edge-rec; } UpdatesGraphSummary; object { JSONNumber seq-i; JSONNumber seq-j; } StartEdgeRec;
with the following fields:
tips-view-uri:
This is the URI to the requested TIPS view. The value of this field MUST have the following format: scheme "://" tips-view-host "/" tips-view-path tips-view-host = host [ ":" port] tips-view-path = path where scheme MUST be "http" or "https" unless specified by a future extension, and host, port, and path are as specified in Sections , , and in . An ALTO server SHOULD use the "https" scheme unless the contents of the TIPS view are intended to be publicly accessible and do not raise security concerns. The field MUST contain only ASCII characters. In case the original URL contains international characters (e.g., in the domain name), the ALTO server implementation MUST properly encode the URL into the ASCII format (e.g., using the "urlencode" function). A server MUST NOT use the same URI for different TIPS views, either for different resources or for different request bodies to the same resource. URI generation is implementation specific; for example, one may compute a Universally Unique Identifier (UUID) or a hash value based on the request and append it to a base URL. For performance considerations, it is NOT RECOMMENDED 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 IP address, which may result in duplicated TIPS views in cases such as mobile clients. However, this is not mandatory as a server might intentionally use client information to compute the TIPS view URI to provide service isolation between clients.
tips-view-summary:
Contains an updates-graph-summary. The "updates-graph-summary" field contains the <start-seq> of the updates graph (in the "start-seq" field) and the <end-seq> that is currently available (in the "end-seq" field), along with a recommended edge to consume (in the "start-edge-rec" field). If the client does not provide a version tag, the server MUST recommend the edge of the latest available snapshot. If the client provides a version tag, the server MUST either recommend the first incremental update edge starting from the client's tagged version or recommend the edge of the latest snapshot: which edge is selected depends on the implementation. For example, a server MAY calculate the cumulative size of the incremental updates available from that version onward and compare it to the size of the complete resource snapshot. If the snapshot is bigger, the server recommends the first incremental update edge starting from the client's tagged version. Otherwise, the server recommends the latest snapshot edge.
If the request has any errors, the ALTO server MUST return an HTTP 400 (Bad Request) error code to the ALTO client; the body of the response follows the generic ALTO error response format specified in . Hence, an example ALTO error response has the format shown in .
ALTO Error Example HTTP/1.1 400 Bad Request Content-Length: 131 Content-Type: application/alto-error+json { "meta":{ "code": "E_INVALID_FIELD_VALUE", "field": "resource-id", "value": "my-network-map/#" } }
Note that "field" and "value" are optional fields. If the "value" field exists, the "field" field MUST exist.
  • If the TIPS request does not have a "resource-id" field, the error code of the error message MUST be "E_MISSING_FIELD" and the "field" field, if present, MUST be "resource-id". The ALTO server MUST NOT create any TIPS view.
  • If the "resource-id" field is invalid or is not associated with the TIPS information resource, the error code of the error message MUST be "E_INVALID_FIELD_VALUE". If present, the "field" field MUST be the full path of the "resource-id" field, and the "value" 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 client MUST set the "input" field to a JSON object with the parameters that resource expects. If the "input" field is missing or invalid, the ALTO server MUST return the same error response that resource would return for missing or invalid inputs (see ).
Furthermore, it is RECOMMENDED that the server use the following HTTP code to indicate other errors, with the media type "application/alto-error+json".
429 (Too Many Requests):
Indicates when the number of TIPS views open requests exceeds the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers.
It is RECOMMENDED that the server provide the ALTO/SSE support for 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-resource transport decisions (see for related considerations).
Open Example
Basic Example For simplicity, assume that the ALTO server is using Basic authentication . If a client with username "client1" and password "helloalto" wants to create a TIPS view of an ALTO cost map resource with the resource ID "my-routingcost-map", it can send the request depicted in .
Request Example of Opening a TIPS View POST /tips HTTP/1.1 Host: alto.example.com Accept: application/alto-tips+json, application/alto-error+json Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Content-Type: application/alto-tipsparams+json Content-Length: 41 { "resource-id": "my-routingcost-map" }
If the operation is successful, the ALTO server returns the message shown in .
Response Example of Opening a TIPS View HTTP/1.1 200 OK Content-Type: application/alto-tips+json Content-Length: 255 { "tips-view-uri": "https://alto.example.com/tips/2718281828", "tips-view-summary": { "updates-graph-summary": { "start-seq": 101, "end-seq": 106, "start-edge-rec" : { "seq-i": 0, "seq-j": 105 } } } }
Example Using Digest Authentication Below is another example of the same query using Digest authentication, a mandatory authentication method of ALTO servers as defined in . The content of the response is the same as in ; thus, it has been omitted for simplicity.
Open Example with Digest Authentication POST /tips HTTP/1.1 Host: alto.example.com Accept: application/alto-tips+json, application/alto-error+json Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K Content-Type: application/alto-tipsparams+json Content-Length: 41 { "resource-id": "my-routingcost-map" } HTTP/1.1 401 UNAUTHORIZED WWW-Authenticate: Digest realm="alto.example.com", qop="auth", algorithm="MD5", nonce="173b5aba4242409ee2ac3a4fd797f9d7", opaque="a237ff9ab865379a69d9993162ef55e4" POST /tips HTTP/1.1 Host: alto.example.com Accept: application/alto-tips+json, application/alto-error+json Authorization: Digest username="client1", realm="alto.example.com", uri="/tips", qop=auth, algorithm=MD5, nonce="173b5aba4242409ee2ac3a4fd797f9d7", nc=00000001, cnonce="ZTg3MTI3NDFmMDQ0NzI1MDQ3MWE3ZTFjZmM5MTNiM2I=", response="8e937ae696c1512e4f990fa21c7f9347", opaque="a237ff9ab865379a69d9993162ef55e4" Content-Type: application/alto-tipsparams+json Content-Length: 41 { "resource-id": "my-routingcost-map" } HTTP/1.1 200 OK Content-Type: application/alto-tips+json Content-Length: 258 {....}
Example Using ALTO/SSE This section gives an example of receiving incremental updates of the TIPS view summary using ALTO/SSE . Consider the "tips-sse" resource, as announced by the IRD in , which provides ALTO/SSE for the "update-my-cost-tips" resource; a client might send the following request to receive updates of the TIPS view (authentication is omitted for simplicity).
Example of Monitoring TIPS View with ALTO/SSE POST /updates/tips HTTP/1.1 Host: alto.example.com Accept: text/event-stream,application/alto-error+json Content-Type: application/alto-updatestreamparams+json Content-Length: 76 { "add": { "tips-123": { "resource-id": "update-my-cost-tips" } } }
Then, the client will be able to receive the TIPS view summary as follows. HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream event: application/alto-tips+json,tips-123 data: { data: "tips-view-uri": "https://alto.example.com/tips/2718281828", data: "tips-view-summary": { data: "updates-graph-summary": { data: "start-seq": 101, data: "end-seq": 106, data: "start-edge-rec" : { data: "seq-i": 0, data: "seq-j": 105 data: } data: } data: } data: } When there is an update to the TIPS view (for example, when the "end-seq" field is increased by 1), the client will be able to receive the incremental update of the TIPS view summary as follows. event: application/merge-patch+json,tips-123 data: { data: "tips-view-summary": { data: "updates-graph-summary": { data: "end-seq": 107 data: } data: } data: }
TIPS Data Transfers - Client Pull TIPS allows an ALTO client to retrieve the content of an update item from the updates graph, with an update item defined as the content (incremental update or snapshot) on an edge in the updates graph.
Request The client sends an HTTP GET request, where the media type of an update item resource MUST be the same as the "media-type" field of the update item on the specified edge in the updates graph. The GET request MUST have the following format: GET /<tips-view-path>/ug/<i>/<j> HOST: <tips-view-host> For example, consider the updates graph in . If the client 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 "/tips/2718281828/ug/0/101" and sets the "Accept" header to "application/alto-costmap+json,application/alto-error+json". See for a concrete example.
Response If the request is valid (i.e., "ug/<i>/<j>" exists), the response is 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 polling updates that have not been provided in the directory yet. For such updates, the client MUST indicate all media types that might appear. It is RECOMMENDED that the server allow for at least the long polling of <end-seq> -> <end-seq + 1>. Hence, the server processing logic MUST be:
  • 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 backlog queue, then either a response is triggered when the content is ready or the request is interrupted (e.g., by a network error).
  • Else, return error.
It is RECOMMENDED that the server use the following HTTP codes to indicate errors, with the media type "application/alto-error+json", regarding update item requests.
404 (Not Found):
Indicates that the requested update does not exist or the requested TIPS view does not exist or is closed by the server.
410 (Gone):
Indicates an update has a seq that is smaller than the <start-seq>.
415 (Unsupported Media Type):
Indicates the media type (or types) accepted by the client does not include the media type of the update chosen by the server.
425 (Too Early):
Indicates the seq exceeds the server long polling window.
429 (Too Many Requests):
Indicates the number of pending (long poll) requests exceeds the server threshold. The server MAY indicate when to retry the request in the "Re-Try After" headers.
Example 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 .
GET Example GET /tips/2718281828/ug/0/101 HTTP/1.1 Host: alto.example.com Accept: application/alto-costmap+json, \ application/alto-error+json
The response is shown in .
Response to a GET Request HTTP/1.1 200 OK Content-Type: application/alto-costmap+json Content-Length: 50 { ... full replacement of my-routingcost-map ... }
New Next Edge Recommendation While intended TIPS usage is for the client to receive a recommended starting edge in the TIPS summary, consume that edge, and then construct all future URIs by incrementing the sequence count by one, there may be cases in which the client needs to request a new next edge to consume. For example, if a client has an open TIPS view but has not polled in a while, the client might request the next logical incremental URI; however, the server has compacted the updates graph, so it no longer exists. Thus, the client MAY request a new next edge to consume based on its current version of the resource.
Request An ALTO client requests that the server provide a next edge recommendation for a given TIPS view by sending an HTTP POST request with the media type "application/alto-tipsparams+json". The URL of the request MUST have the following format: <tips-view-path>/ug and the "HOST" field MUST be "<tips-view-host>". The POST body has the same format as the TIPSReq in . The "resource-id" field MUST be the same as the resource ID used to create the TIPS view, and the optional "input" field MUST NOT be present.
Response The response to a valid request MUST be a JSON merge patch to the object of the AddTIPSResponse type (defined in ), denoted as media type "application/merge-patch+json". The "updates-graph-summary" field MUST be present in the response; hence, its parent field "tips-view-summary" MUST be present as well. If the "tag" field is present in the request, the server MUST check if any version within the range [<start-seq>, <end-seq>] has the same tag value. If the version exists (e.g., denoted as <tag-seq>), the server MUST compute the paths from both <tag-seq> and 0 to the <end-seq> and choose the one with the minimal cost. The cost MAY be implementation specific (e.g., number of messages, accumulated data size, etc.). The first edge of the selected path MUST be returned as the recommended next edge. If the "tag" field is not present, the interpretation MUST be that the <tag-seq> is 0. It is RECOMMENDED that the server use the following HTTP code to indicate errors, with the media type "application/alto-error+json", regarding new next edge requests.
404 (Not Found):
Indicates that the requested TIPS view does not exist or has been closed by the server.
Example In this section, we give an example of the new next edge recommendation service. Assume that a client already creates a TIPS view (as in ) whose updates graph is as shown in . Now assume that the client already has tag 0881080, whose corresponding sequence number is 103, and sends the following new next edge recommendation request (authentication is omitted for simplicity): POST /tips/2718281828/ug HTTP/1.1 HOST alto.example.com Accept: application/merge-patch+json, application/alto-error+json Content-Type: application/alto-tipsparams+json Content-Length: 62 { "resource-id": "my-routingcost-map", "tag": "0881080" } According to , there are three potential paths: 103 -> 104 -> 105 -> 106, 103 -> 105 -> 106, and 0 -> 105 -> 106. Assume that the server chooses the shortest update path by the accumulated data size and the best path is 103 -> 105 -> 106. Thus, the server responds with the following message: HTTP/1.1 200 OK Content-Type: application/merge-patch+json Content-Length: 193 { "tips-view-summary": { "updates-graph-summary": { "start-seq": 101, "end-seq": 106, "start-edge-rec": { "seq-i": 103, "seq-j": 105 } } } }
Operation and Processing Considerations TIPS has some common operational considerations as ALTO/SSE , including:
  • the server choosing update messages ();
  • the client processing update messages ();
  • the updates of filtered map services (); and
  • the updates of ordinal mode costs ().
There are also some operational considerations specific to TIPS, which we discuss below.
Considerations for Load Balancing There are two levels of load balancing in TIPS: the first level is to balance the load of TIPS views for different clients and the second is to balance the load of incremental updates. Load balancing of TIPS views can be achieved either at the application layer or at the infrastructure layer. For example, an ALTO server MAY set <tips-view-host> to different subdomains to distribute TIPS views or simply use the same host of the TIPS information resource and rely on load balancers to distribute the load. TIPS allows a client to make concurrent pulls of incremental updates for the same TIPS view, potentially through different HTTP connections. As a consequence, TIPS introduces additional complexities when the ALTO server balances the load by distributing the requests to a set of backend servers. For example, a request might be directed to the wrong backend server and get processed incorrectly if the following two conditions both hold:
  • these backend servers are stateful (i.e., the TIPS view is created and stored only on a single server); and
  • the ALTO server is using Layer 4 load balancing (i.e., the requests are distributed based on the TCP 5-tuple).
Thus, additional considerations are required to enable correct load balancing for TIPS, including:
Using a stateless architecture:
One solution is to follow the stateless computing pattern: states about the TIPS view are not maintained by the backend servers but are stored in a distributed database. Thus, concurrent requests to the same TIPS view can be processed on arbitrary stateless backend servers, which all fetch data from the same database.
Configuring the load balancers properly:
In the case that the backend servers are stateful, the load balancers must be properly configured to guarantee that requests of the same TIPS view always arrive at the same server. For example, an operator or a provider of an ALTO server MAY configure Layer 7 load balancers that distribute requests based on the tips-view-path component in the URI.
Considerations for Cross-Resource Dependency Scheduling Dependent ALTO resources result in cross-resource dependencies in TIPS. Consider the following pair of resources, where my-cost-map (C) is dependent on my-network-map (N). The updates graph for each resource is shown, along with links between the respective updates graphs to show dependency:
Example Dependency Model +---+ +---+ +---+ +---+ +---+ my-network-map (N) | 0 |-->|89 |-->|90 |-->|91 |-->|92 | +---+ +---+ +---+ +---+ +---+ | \ \ \ | \ \ \ +---+ +---+ +---+ +---+ +---+ my-cost-map (C) | 0 |-->|101|-->|102|-->|103|-->|104| +---+ +---+ +---+ +---+ +---+ |_______________________|
In , the cost-map versions 101 and 102 (denoted as C101 and C102) are dependent on the network-map version 89 (denoted as N89). The cost-map version 103 (C103) is dependent on the network-map version 90 (N90), and so on. 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 consistent view and how long the client needs to buffer the update.
Example 1:
The client requests N89, N90, N91, C101, C102 in that order. The client either gets no consistent view of the resources or has to buffer N90 and N91.
Example 2:
The client requests C101, C102, C103, N89. The client either gets no consistent view or has to buffer C103.
To get consistent ALTO information, a client must process the updates following the guidelines specified in . If resources permit (i.e., sufficient updates can be buffered), an ALTO client can safely use long polling to fetch all the updates. This allows a client to build consistent views quickly as the updates are already stored in the buffer. Otherwise, it is RECOMMENDED to request a full snapshot if the client does not have enough local resources to buffer and process the incremental updates.
Considerations for Managing Shared TIPS Views 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 implementation options, especially for common resources (e.g., network maps or cost maps) that may be frequently queried by many clients. Some potential options are listed below:
  • An ALTO server creates one TIPS view of the common resource for each client.
  • An ALTO server maintains one copy of the TIPS view for each common resource and all clients requesting the same resources use the same copy. There are two ways to manage the storage for the shared copy:
    • the ALTO server maintains the set of clients that have sent a polling request to the TIPS view and only removes the view from the storage when the set becomes empty and no client immediately issues a new edge request; or
    • the TIPS view is never removed from the storage.
Developers may choose different implementation options depending on criteria such as request frequency, available resources of the ALTO server, the ability to scale, and programming complexity.
Considerations for Offering Shortcut Incremental Updates Besides the mandatory stepwise incremental updates (from i to i+1), an ALTO server MAY optionally offer shortcut incremental updates, or simple shortcuts, between two non-consecutive versions i and i+k (k > 1). Such shortcuts offer alternative paths in the updates graph and can potentially speed up the transmission and processing of incremental updates, leading to faster synchronization of ALTO information, especially when the client has limited bandwidth and computation. However, implementors of an ALTO server must be aware that:
  1. optional shortcuts may increase the size of the updates graph, worst case scenario being the square of the number of updates (i.e., when a shortcut is offered for each version to all future versions).
  2. optional shortcuts require additional storage on the ALTO server.
  3. optional shortcuts may reduce concurrency when the updates do not overlap (e.g., when the updates apply to different parts of an 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 can be transmitted concurrently while the shortcut is transmitted in a single connection.
Security Considerations The security considerations of the base protocol () fully apply to this extension. For example, the same authenticity and integrity considerations () still fully apply; the same considerations for the privacy of ALTO users () also still fully apply. Additionally, operators of the ALTO servers MUST follow the guidelines in to avoid new TLS vulnerabilities discovered after was published. The additional services (the addition of update read service and update push service) provided by this extension extend the attack surface described in . The following subsections discuss the additional risks and their remedies.
TIPS: Denial-of-Service Attacks Allowing TIPS views enables new classes of DoS attacks. In particular, for the TIPS server, one or multiple malicious ALTO clients might create an excessive number of TIPS views, to exhaust the server resource and/or to block normal users from accessing the service. To avoid such attacks, the server MAY choose to limit the number of active views and reject new requests when that threshold is reached. TIPS allows predictive fetching and the server MAY also choose to limit the number of pending requests. If a new request exceeds the threshold, the server MAY log the event and return the HTTP status 429 (Too Many Requests). It is important to note that the preceding approaches are not the only possibilities. For example, it might be possible for a TIPS server to use somewhat more clever logic involving TIPS view eviction policies, IP reputation, rate-limiting, and compartmentalization of the overall threshold into smaller thresholds that apply to subsets of potential clients. If service availability is a concern, ALTO clients MAY establish service level agreements with the ALTO server.
ALTO Client: Update Overloading or Instability The availability of continuous updates can also cause overload for an ALTO client, in particular, an ALTO client with limited processing capabilities. The current design does not include any flow control mechanisms for the client to reduce the update rates from the server. For example, TCP, HTTP/2, and QUIC provide stream and connection flow control data limits, which might help prevent the client from being overloaded. Under overloading, the client MAY choose to remove the information resources with high update rates. Also, under overloading, the client might no longer be able to detect whether information is still fresh or has become stale. In such a case, the client should be careful in how it uses the information to avoid stability or efficiency issues.
IANA Considerations IANA has registered the following media types from the registry available at :
  • application/alto-tips+json: as described in ;
  • application/alto-tipsparams+json: as described in ;
application/alto-tips+json Media Type
Type name:
application
Subtype name:
alto-tips+json
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
Encoding considerations are identical to those specified for the "application/json" media type. See .
Security considerations:
See the Security Considerations section of RFC 9569.
Interoperability considerations:
N/A
Published specification:
of RFC 9569.
Applications that use this media type:
ALTO servers and ALTO clients either stand alone or are embedded within other applications.
Fragment identifier considerations:
N/A
Additional information:
Deprecated alias names for this type:
N/A
Magic number(s):
N/A
File extension(s):
RFC 9569 uses the media type to refer to protocol messages; thus, it does not require a file extension.
Macintosh file type code(s):
N/A
Person & email address to contact for further information:

See the Authors' Addresses section of RFC 9569.
Intended usage:
COMMON
Restrictions on usage:
N/A
Author:
See the Authors' Addresses section of RFC 9569.
Change controller:
Internet Engineering Task Force (iesg@ietf.org).
application/alto-tipsparams+json Media Type
Type name:
application
Subtype name:
alto-tipsparams+json
Required parameters:
N/A
Optional parameters:
N/A
Encoding considerations:
Encoding considerations are identical to those specified for the "application/json" media type. See .
Security considerations:
See the Security Considerations section of RFC 9569.
Interoperability considerations:
N/A
Published specification:
of RFC 9569.
Applications that use this media type:
ALTO servers and ALTO clients either stand alone or are embedded within other applications.
Fragment identifier considerations:
N/A
Additional information:
Deprecated alias names for this type:
N/A
Magic number(s):
N/A
File extension(s):
RFC 9569 uses the media type to refer to protocol messages; thus, it does not require a file extension.
Macintosh file type code(s):
N/A
Person & email address to contact for further information:

See the Authors' Addresses section of RFC 9569.
Intended usage:
COMMON
Restrictions on usage:
N/A
Author:
See the Authors' Addresses section of RFC 9569.
Change controller:
Internet Engineering Task Force (iesg@ietf.org).
 References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Application-Layer Traffic Optimization (ALTO) Protocol Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks. For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients. What is missing is knowledge of the underlying network topologies from the point of view of ISPs. In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it. The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance. The basic information of ALTO is based on abstract maps of a network. These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them. Additional services are built on top of the maps. This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services. Applications that could use the ALTO services are those that have a choice to which end points to connect. Examples of such applications are peer-to-peer (P2P) and content delivery networks. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The JavaScript Object Notation (JSON) Data Interchange Format JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE) The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available. HTTP/1.1 The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. HTTP/2 This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740. HTTP/3 The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks. Informative References Media Types IANA The 'Basic' HTTP Authentication Scheme This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/ password pairs, encoded using Base64. Building Protocols with HTTP Applications often use HTTP as a substrate to create HTTP-based APIs. This document specifies best practices for writing specifications that use HTTP to define new application protocols. It is written primarily to guide IETF efforts to define application protocols using HTTP for deployment on the Internet but might be applicable in other situations. This document obsoletes RFC 3205. Universally Unique IDentifiers (UUIDs) This specification defines UUIDs (Universally Unique IDentifiers) -- also known as GUIDs (Globally Unique IDentifiers) -- and a Uniform Resource Name namespace for UUIDs. A UUID is 128 bits long and is intended to guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System (NCS), later in the Open Software Foundation's (OSF's) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms. This specification is derived from the OSF DCE specification with the kind permission of the OSF (now known as "The Open Group"). Information from earlier versions of the OSF DCE specification have been incorporated into this document. This document obsoletes RFC 4122.
A High-Level Deployment Model Conceptually, the TIPS system consists of three types of resources:
(R1):
The TIPS frontend to create TIPS views.
(R2):
The TIPS view directory, which provides metadata (e.g., references) about the network resource data.
(R3):
The actual network resource data, encoded as complete ALTO network resources (e.g., a cost map or a network map) or incremental updates.
Sample TIPS Deployment Model +------------------------------------------------+ | | +------+ |R1: Frontend/Open R2: Directory/Meta R3: Data | | | "iget" base | +-----+ +-----+ +-----+ | | | resource 1 | | | | | | | | | |-------------|---->| | | | | | | | | incremental | | | | |-------->| | | | | transfer | | | | | | | | | | resource | | | | | | | | | |<------------|-----------------------| | | | | |Client| | | | +-----+ +-----+ | | | "iget" base | | | | | | resource 2 | | | +-----+ +-----+ | | |-------------|---->| | | | | | | | | incremental | | | | | | | | | | transfer | +-----+ | | ------->| | | | | resource | | | | | | | |<------------|-----------------------| | | | | +------+ | +-----+ +-----+ | | | +------------------------------------------------+
Design Point: Component Resource Location
Design 1 (Single):
all the three resource types at the same single server (accessed via relative reference).
Design 2 (Flexible):
all three resource types can be at their own server (accessed via absolute reference).
Design 3 (Dir + Data):
R2 and R3 must remain together, though R1 might not be on the same server.
This document supports Designs 1 and 3. For Design 1, the ALTO server simply needs to always use the same host for the TIPS views. For Design 3, the ALTO server can set tips-view-host to a different server. Note that the deployment flexibility is at the logical level, as these services can be distinguished by different paths and potentially be routed to different physical servers by Layer 7 load balancing. See for a discussion on load balancing considerations. Future documents could extend the protocol to support Design 2.
Conformance with "Building Protocols with HTTP" (RFC 9205) Best Current Practices This specification adheres fully to as further elaborated below:
  • TIPS does not (as described in ):
    ...redefine, refine, or overlay the semantics of generic protocol elements such as methods, status codes, or existing 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 ().
  • No minimum version of HTTP is specified by TIPS, which is recommended (in ).
  • The TIPS design follows the advice (in ) that:
    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 ).
  • TIPS follows the pattern (in ) that:
    Generally, a client will begin interacting with a given application server by requesting an initial document that contains information about that particular deployment, potentially including links to other relevant resources. Doing so ensures that the deployment is as flexible as possible (potentially 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 ().
  • TIPS defines its errors "to use the most applicable status code" ().
  • TIPS does not (as in ):
    ...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 .
Push-Mode TIPS Using HTTP Server Push TIPS allows ALTO clients to subscribe to incremental updates of an ALTO resource, and the specification in this document is based on the current best practice of building such a service using basic HTTP. Earlier versions of this document had investigated the possibility of enabling push-mode TIPS (i.e., by taking advantage of the server push feature in HTTP/2 and HTTP/3). In the ideal case, push-mode TIPS can potentially improve performance (e.g., latency) in more dynamic environments and use cases with wait-free message delivery. Using the built-in HTTP server push also results in minimal changes to the current protocol. While not adopted due to the lack of server push support and increased protocol complexity, push-mode TIPS remains a potential direction of protocol improvement.
Persistent HTTP Connections Previous draft versions of this document use persistent HTTP connections to detect the liveness of clients. However, this design does not conform well with the best current practices of HTTP. For example, if an ALTO client is accessing a TIPS view over an HTTP proxy, the connection is not established directly between the ALTO client and the ALTO server, but between the ALTO client and the proxy and between the proxy and the ALTO server. Thus, using persistent connections might not correctly detect the right liveness state.
Acknowledgments The authors of this document would like to thank and for providing invaluable reviews of earlier draft versions of this document; , , and for their continuous feedback; , , , , , , and for the directorate reviews; for the area director review; , , , , and for the telechat and IESG reviews; and for shepherding the document.
Authors' Addresses Sichuan University
No.24 South Section 1, Yihuan Road Chengdu 610000 China kaigao@scu.edu.cn
Deutsche Telekom
Deutsche-Telekom-Allee 9 Darmstadt 64295 Germany Roland.Schott@telekom.de
Yale University
51 Prospect Street New Haven 06511 CT United States of America yry@cs.yale.edu
Yale University
51 Prospect Street New Haven CT 06511 United States of America lauren.delwiche@yale.edu
Yale University
51 Prospect Street New Haven CT 06511 United States of America lachlan.keller@aya.yale.edu