1.1.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119][RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2.Notations

This document uses the same syntax and notations as introduced inSection 8.2 of [RFC7285] to specify the extensions to existing ALTO resources and services.¶

2.1.Transport Requirements

The ALTO Protocol and its extensions support two transport mechanisms:¶

1. A client can directly request an ALTO resource and obtain a completesnapshot of that ALTO resource, as specified in the base protocol[RFC7285];¶
2. A client can subscribe to incremental changes of one or multiple ALTOresources using the incremental update extension[RFC8895], and a server pushesthe updates to the client through SSE.¶

However, the current transport mechanisms are not optimized for storing,transmitting, and processing (incremental) updates of ALTO informationresources. Specifically, the new transport mechanism must satisfy the followingrequirements:¶

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 protocoldoes not support incremental updates and the current incremental updatemechanism in[RFC8895] has limitations (as discussed below).¶

Concurrent, non-blocking update transmission:

When a client needs to receive and apply multiple incremental updates, it isdesired to transmit the updates concurrently to fully utilize the bandwidthand to reduce head-of-line blocking. Unfortunately, the ALTO incremental update extension[RFC8895] does not satisfy this requirement. Even thoughthe updates can be multiplexed by the server to avoid head-of-line blockingbetween multiple resources, the updates are delivered sequentially and cansuffer from head-of-line blocking inside the connection (for example, whenthere is a packet loss).¶

Long polling updates:

Long polling updates can reduce the time to send the request, making itpossible to achieve sub-RTT transmission of ALTO incremental updates. In[RFC8895], this requirement is fulfilled using SSE andis still desired in the new ALTO transport.¶

Backward compatibility:

While some of the previous requirements are offered by HTTP/2[RFC9113] andHTTP/3[RFC9114], it is desired that the new ALTO transport mechanism canwork with HTTP/1.1 as many development tools and current ALTO implementationsare based on HTTP/1.1.¶

The new ALTO transport specified in this document satisfies all of the following designrequirements above by:¶

• Reusing the data format introduced in[RFC8895] that enablesincremental 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 inAppendix A.¶

2.2.TIPS Terminology

In addition to the terms defined in[RFC7285], this document uses the following terms:¶

Transport Information Publication Service (TIPS):

A new type of ALTO service, as specified in this document, to enable auniform transport mechanism for updates of an incrementally changing ALTOnetwork information resource.¶

Network information resource:

A piece of retrievable information about network state, per[RFC7285].¶

TIPS view (tv):

The container of incremental transportinformation about the network information resource. The TIPS view has onebasic component, the updates graph (ug), but may include other transportinformation.¶

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 inSection 6.1.¶

Version:

The representation of a historical content of an information resource. For an informationresource, each version is associated with and uniquely identified by amonotonically and consecutively increased sequence number. This document usesthe term "version s" to refer to the version associated with sequence number"s". The version is encoded as a JSONNumber, as specified inSection 6.1.¶

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 asnapshot 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 asnapshot 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 transitionfrom version i to version j, where i and j are the sequence numbers of thesource node and the target node of the edge, respectively.¶

                                   +-------------+    +-----------+ +--------------+ |  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 itvi/ug = incremental updates graph associated with tvi

Figure 1 shows an example illustrating an overview of the ALTO TIPSextension. The server provides TIPS for two information resources (#1and #2) where #1 is an ALTO map service and #2 is a filterableservice. There are three ALTO clients (Client 1, Client 2, and Client 3) that areconnected 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. Forthe filtering service #2, two different TIPS views (tv2 and tv3) are created upondifferent client requests with different filter sets.¶

3.1.Basic Data Model of an Updates Graph

For each resource (e.g., a cost map or a network map), the incremental updates andsnapshots can be represented using the following directed acyclic graph model,where the server tracks the change of the resource maps with version IDs that areassigned sequentially (i.e., incremented by one each time):¶

• Each node in the graph is a version of the resource, which is identified by asequence number (defined as a JSONNumber). Version 0 is reserved as theinitial state (empty/null).¶
• A tag identifies the content of a node. A tag has the same format as the"tag" field inSection 10.3 of [RFC7285] and is valid only within thescope of the resource.¶
• Each edge is an update item. In particular, the edge from i to j is the updateitem 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 versionhave the same content.¶

A concrete example is shown inFigure 2. There are seven nodes in the graph,representing seven different versions of the resource. Edges in the figure representthe updates from the source version to the target version. Thick lines representmandatory incremental updates (e.g., ID103-104), dotted lines represent optionalincremental 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 canbe 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 baseversion of the client is 103 as it serves as a base upon which incrementalupdates 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.¶

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

3.2.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 makesavailable is reachable by clients, either directly via a snapshot(that is, relative to 0) or indirectly by requesting an earliersnapshot and a contiguous set of incremental updates. Additionally,to allow clients to proactively construct URIs for future updateitems, the ID of each added node in the updates graph will need to incrementcontiguously by 1. More specifically, the updates graphMUST satisfythe 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 neMUST also exist. This impliesthat 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 serverMUSTprovide a snapshot of ns; in other words, there is always a direct linkto ns in the updates graph.¶

"Right shift" only:

Assume a server provides versions in [n1, n2] at time tand 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 graphto conserve space, using the example model inSection 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} and {105, 106} are valid sets. However, {102,103, 104, 105, 106} and {104, 105, 106} are not valid sets as there is nosnapshot to version 102 or 104 in the updates graph. Thus, there is a risk thatthe right content of version 102 (in the first example) or 104 (in the secondexample) cannot be obtained by a client that does not have the previous version101 or 103, respectively.¶

4.1.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 clientwants to monitor. For each requested resource, the server returns a JSON objectthat contains a URI, which points to the root of a TIPS view (denoted asTIPS-V), and a summary of the current view, which contains the information tocorrectly interact with the current view. With the URI to the root of a TIPSview, clients can construct URIs (seeSection 4.2) to fetch incremental updates.¶

An example workflow is shown inFigure 3. After the TIPS-F receives the request from the client to monitor the updates of an ALTOresource, it creates a TIPS view resource and returns the correspondinginformation to the client. The URI points to that specific TIPS-V instance, andthe summary contains the <start-seq> and <end-seq> of the updates graph and aserver-recommended edge to consume first (e.g., from i to j).¶

An ALTO client can then continuously pull each additional update with theinformation. For example, the client inFigure 3 first fetches theupdate 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 therequest until the update becomes available (i.e., long polling).¶

A serverMAY close a TIPS view at any time (e.g., under high system load or dueto client inactivity). In the event that a TIPS view is closed, an edge requestwill receive error code 404 (Not Found) in response, and the client will have to request anew TIPS view URI.¶

If resources allow, a serverSHOULD avoid closing TIPS views that have activepolling edge requests or have recently served responses until clients have had areasonable interval to request the next update, unless guided by specificcontrol policies.¶

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

4.2.Resource Location Schema

The resource location schema defines how a client constructs URIs to fetchincremental updates.¶

To access each update in an updates graph, consider the modelrepresented as a "virtual" file system (adjacency list), contained within theroot of a TIPS view URI (seeSection 6.2 for the definition of tips-view-uri).For example, assuming that the updates graph of a TIPS view is as shown inFigure 2, the location schema of this TIPS view will have the format as inFigure 4.¶

  <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 allowclients to construct the location of incremental updates after receiving thetips-view-uri from the server. The generic template for the location of theupdate 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 afuture update that does not yet exist (e.g., the incremental update from 106 to107). This can be done by constructing the URI for the next edge that will be added, starting fromthe sequence number of the current last node (denoted as <end-seq>) in the graphto 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 usingthe HTTP GET method.¶

5.1.Media Type

The media type of the Transport Information Publication Service (TIPS) resource is"application/alto-tips+json".¶

5.2.Capabilities

The "capabilities" field of a TIPS information resource is modeled on that defined inSection 6.3 of [RFC8895].¶

Specifically, the capabilities are defined as an object of the TIPSCapabilities type:¶

     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 aresource, the "incremental-change-media-types" field has an entrywhose key is the ID of the resource and the value is the supported media typesof incremental changes, separated by commas. For the implementation of thisspecification, thisMUST be "application/merge-patch+json","application/json-patch+json", or"application/merge-patch+json,application/json-patch+json", unless defined bya future extension.¶

When choosing the media types to encode incremental updates for aresource, the serverMUST consider the limitations of theencoding. For example, when a JSON merge patch specifies that thevalue of a field is null, its semantics are that the field isremoved from the target; hence, the field is no longer defined(i.e., undefined). However, this may not be the intended resultfor the resource, when null and undefined have different semanticsfor the resource. In such a case, the serverMUST choose JSONpatch 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.¶

5.3.Uses

The "uses" attributeMUST be an array with the resource IDs of everynetwork information resource for which this TIPS information resource can provide service.¶

This setMAY be any subset of the ALTO server's network information resourcesandMAY include resources defined in linked IRDs. However, it isRECOMMENDEDthat the ALTO server selects a set that is closed under the resource dependencyrelationship. That is, if a TIPS information resource's "uses" set includes resource R1, and resourceR1 depends on ("uses") resource R0, then the "uses" set should include R0as well as R1. For example, if a TIPS information resource provides a TIPS view for a cost map, itshould also provide a TIPS view for the network map upon which that cost mapdepends.¶

If the set is not closed, at least one resource R1 in the "uses" field of a TIPS information resourcedepends on another resource R0 that is not in the "uses" field of the sameTIPS 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 forR0 has changed, it must request the full content of R0, which is likely to beless efficient than receiving the incremental updates of R0.¶

5.4.An Example

Extending the IRD example inSection 8.1 of [RFC8895],Figure 6 is the IRD of anALTO 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 andsupport 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 isindicated by the media type "application/alto-tips+json".¶

6.1.Open Request

An ALTO client requests that the server provide a TIPS view for a given resourceby sending an HTTP POST body with the media type"application/alto-tipsparams+json". That body contains a JSON object of the TIPSReq type, where:¶

    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, whichMUST be in the TIPS information resource's "uses" list(Section 5). If a client does not support all incremental methods from the setannounced in the server's capabilities, the clientMUST NOT use the TIPSinformation resource.¶

tag:

If the "resource-id" is associated with a GET-mode resource with a version tag (or"vtag"), as defined inSection 10.3 of [RFC7285], and the ALTOclient has previously retrieved a version of that resource fromALTO, the ALTO clientMAY set the "tag" field to the tag part ofthe client's version of that resource. The serverMAY use the tagwhen calculating a recommended starting edge for the client toconsume. Note that the clientMUST support all incrementalmethods from the set announced in the server's capabilities forthis resource.¶

input:

If the resource is a POST-mode service that requires input, theALTO clientMUST set the "input" field to a JSON object with theparameters that the resource expects.¶

6.2.Open Response

The response to a valid requestMUST be a JSON object of the AddTIPSResponse type, denoted as media type "application/alto-tips+json":¶

    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 fieldMUST have thefollowing format:¶

    scheme "://" tips-view-host "/" tips-view-path    tips-view-host = host [ ":" port]    tips-view-path = path

¶

where schemeMUST be "http" or "https" unless specified by a futureextension, and host, port, and path are as specified in Sections3.2.2,3.2.3, and3.3 in[RFC3986]. An ALTO serverSHOULD use the "https" scheme unlessthe contents of the TIPS view are intended to be publicly accessible and donot raise security concerns. The fieldMUST contain only ASCII characters. Incase the original URL contains international characters (e.g., in the domainname), the ALTO server implementationMUST properly encode the URL into theASCII format (e.g., using the "urlencode" function).¶

A serverMUST NOT use the same URI for different TIPS views, either fordifferent resources or for different request bodies to the same resource. URIgeneration is implementation specific; for example, one may compute aUniversally Unique Identifier (UUID)[RFC9562] or a hash value based onthe request and append it to a base URL. For performance considerations, itisNOT RECOMMENDED to use properties that are not included in the requestbody to determine the URI of a TIPS view, such as cookies or the client's IPaddress, which may result in duplicated TIPS views in cases such as mobileclients. However, this is not mandatory as a server might intentionally useclient information to compute the TIPS view URI to provide service isolationbetween 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> thatis 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 serverMUST recommend the edge of the latest available snapshot.If the client provides a version tag, the serverMUST either recommendthe first incremental update edge starting from the client's tagged versionor recommend the edge of the latest snapshot: which edge is selected depends on theimplementation. For example, a serverMAY calculate the cumulative size ofthe incremental updates available from that version onward and compare it tothe size of the complete resource snapshot. If the snapshot is bigger, theserver recommends the first incremental update edge starting from theclient's tagged version. Otherwise, the server recommends the latest snapshotedge.¶

If the request has any errors, the ALTO serverMUST return an HTTP400 (Bad Request) error code to the ALTO client; the body of the responsefollows the generic ALTO error response format specified inSection 8.5.2 of [RFC7285]. Hence, an example ALTO error responsehas the format shown inFigure 9.¶

    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" fieldMUST exist.¶

• If the TIPS request does not have a "resource-id" field, the error code ofthe error messageMUST be "E_MISSING_FIELD" and the "field" field, ifpresent,MUST be "resource-id". The ALTO serverMUST NOT create any TIPSview.¶
• If the "resource-id" field is invalid or is not associated with the TIPS information resource, theerror code of the error messageMUST be "E_INVALID_FIELD_VALUE". If present,the "field" fieldMUST be the full path of the "resource-id" field, and the"value" fieldMUST be the value of the "resource-id" field in the request.¶
• If the resource is a POST-mode service that requires input, the clientMUSTset the "input" field to a JSON object with the parameters that resourceexpects. If the "input" field is missing or invalid, the ALTO serverMUST return thesame error response that resource would return for missing or invalid inputs(see[RFC7285]).¶

Furthermore, it isRECOMMENDED that the server use the following HTTP code toindicate other errors, with the media type "application/alto-error+json".¶

429 (Too Many Requests):

Indicates when the number of TIPS views open requests exceedsthe server threshold. The serverMAY indicate when to retry the request inthe "Re-Try After" headers.¶

It isRECOMMENDED that the server provide the ALTO/SSE support for the TIPSresource. Thus, the client can be notified of the version updates of all theTIPS views that it monitors and make better cross-resource transport decisions(seeSection 8.2 for related considerations).¶

6.3.Open Example

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

    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    {....}

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

 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: }

    event: application/merge-patch+json,tips-123    data: {    data:   "tips-view-summary": {    data:     "updates-graph-summary": {    data:       "end-seq": 107    data:     }    data:   }    data: }

7.1.Request

The client sends an HTTP GET request, where the media type of anupdate item resourceMUST be the same as the "media-type" field ofthe update item on the specified edge in the updates graph.¶

The GET requestMUST have the following format:¶

    GET /<tips-view-path>/ug/<i>/<j>    HOST: <tips-view-host>

For example, consider the updates graph inFigure 4. If the clientwants to query the content of the first update item (0 -> 101) whose media typeis "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". SeeSection 7.3for a concrete example.¶

7.2.Response

If the request is valid (i.e., "ug/<i>/<j>" exists), the response is encodedas a JSON object whose data format is indicated by the media type.¶

A clientMAY conduct proactive fetching of future updates, by long pollingupdates that have not been provided in the directory yet. For such updates, theclientMUST indicate all media types that might appear. It isRECOMMENDED that theserver allow for at least the long polling of <end-seq> -> <end-seq + 1>.¶

Hence, the server processing logicMUST 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 abacklog queue, then either a response is triggered when the content is readyor the request is interrupted (e.g., by a network error).¶
• Else, return error.¶

It isRECOMMENDED that the server use the following HTTP codes toindicate 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 requestedTIPS 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 theclient does not include the media type of the update chosen by theserver.¶

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 serverMAY indicate when to retrythe request in the "Re-Try After" headers.¶

7.3.Example

Assume the client wants to get the contents of the update item onedge 0 to 101. The format of the request is shown inFigure 14.¶

    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 inFigure 15.¶

    HTTP/1.1 200 OK    Content-Type: application/alto-costmap+json    Content-Length: 50    { ... full replacement of my-routingcost-map ... }

7.4.New Next Edge Recommendation

While intended TIPS usage is for the client to receive a recommendedstarting edge in the TIPS summary, consume that edge, and then constructall future URIs by incrementing the sequence count by one, there may becases in which the client needs to request a new next edge toconsume. For example, if a client has an open TIPS view but has notpolled in a while, the client might request the next logicalincremental URI; however, the server has compacted the updates graph, so itno longer exists. Thus, the clientMAY request a new next edge toconsume based on its current version of the resource.¶

    <tips-view-path>/ug

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

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

8.1.Considerations for Load Balancing

There are two levels of load balancing in TIPS: the first level is to balancethe load of TIPS views for different clients and the second is to balance theload of incremental updates.¶

Load balancing of TIPS views can be achieved either at the application layer orat the infrastructure layer. For example, an ALTO serverMAY set<tips-view-host> to different subdomains to distribute TIPS views or simplyuse 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 thesame 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 andget processed incorrectly if the following two conditions both hold:¶

• these backend servers are stateful (i.e., the TIPS view is createdand stored only on a single server); and¶
• the ALTO server is using Layer 4 load balancing (i.e., therequests are distributed based on the TCP 5-tuple).¶

Thus, additional considerations are required to enable correct loadbalancing for TIPS, including:¶

Using a stateless architecture:

One solution is to follow thestateless computing pattern: states about the TIPS view are notmaintained by the backend servers but are stored in a distributeddatabase. Thus, concurrent requests to the same TIPS view can beprocessed on arbitrary stateless backend servers, which allfetch data from the same database.¶

Configuring the load balancers properly:

In the case that the backendservers are stateful, the load balancers must be properlyconfigured to guarantee that requests of the same TIPS view alwaysarrive at the same server. For example, an operator or a providerof an ALTO serverMAY configure Layer 7 load balancers thatdistribute requests based on the tips-view-path component in the URI.¶

8.2.Considerations for Cross-Resource Dependency Scheduling

Dependent ALTO resources result in cross-resource dependencies inTIPS. Consider the following pair of resources, where my-cost-map(C) is dependent on my-network-map (N). The updates graph for eachresource is shown, along with links between the respective updatesgraphs to show dependency:¶

                       +---+   +---+   +---+   +---+   +---+  my-network-map (N)   | 0 |-->|89 |-->|90 |-->|91 |-->|92 |                       +---+   +---+   +---+   +---+   +---+                                 |   \       \       \                                 |    \       \       \                       +---+   +---+   +---+   +---+   +---+  my-cost-map (C)      | 0 |-->|101|-->|102|-->|103|-->|104|                       +---+   +---+   +---+   +---+   +---+                        |_______________________|

InFigure 16, 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-mapversion 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 theupdates. The order may affect how fast the client can build a consistent viewand how long the client needs to buffer the update.¶

Example 1:

The client requests N89, N90, N91, C101, C102 in thatorder. The client either gets no consistent view of the resourcesor has to buffer N90 and N91.¶

Example 2:

The client requests C101, C102, C103, N89. The clienteither gets no consistent view or has to buffer C103.¶

To get consistent ALTO information, a client must process the updates followingthe guidelines specified inSection 9.2 of [RFC8895]. If resources permit(i.e., sufficient updates can be buffered), an ALTO client can safely use longpolling to fetch all the updates. This allows a client to build consistent viewsquickly as the updates are already stored in the buffer. Otherwise, it isRECOMMENDED to 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

From a client's point of view, it sees only one copy of the TIPS viewfor any resource. However, on the server side, there are differentimplementation options, especially for common resources (e.g.,network maps or cost maps) that may be frequently queried by manyclients. Some potential options are listed below:¶

• An ALTO server creates one TIPS view of the common resource foreach client.¶

• An ALTO server maintains one copy of the TIPS view for each commonresource and all clients requesting the same resources use thesame copy. There are two ways to manage the storage for theshared copy:¶

  • the ALTO server maintains the set of clients that have sent a pollingrequest to the TIPS view and only removes the view from the storage whenthe 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 oncriteria such as request frequency, available resources of the ALTOserver, the ability to scale, and programming complexity.¶

8.4.Considerations for Offering Shortcut Incremental Updates

Besides the mandatory stepwise incremental updates (from i to i+1),an ALTO serverMAY optionally offer shortcut incremental updates, orsimple shortcuts, between two non-consecutive versions i and i+k (k >1). Such shortcuts offer alternative paths in the updates graph andcan potentially speed up the transmission and processing ofincremental updates, leading to faster synchronization of ALTOinformation, especially when the client has limited bandwidth andcomputation. However, implementors of an ALTO server must be awarethat:¶

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 futureversions).¶
2. optional shortcuts require additional storage on the ALTO server.¶
3. optional shortcuts may reduce concurrency when the updates do notoverlap (e.g., when the updates apply to different parts of anALTO resource). In such a case, the total size of the originalupdates is close to the size of the shortcut, but the originalupdates can be transmitted concurrently while the shortcut istransmitted in a single connection.¶

9.1.TIPS: Denial-of-Service Attacks

Allowing TIPS views enables new classes of DoS attacks. Inparticular, for the TIPS server, one or multiple malicious ALTO clients mightcreate an excessive number of TIPS views, to exhaust the server resource and/orto block normal users from accessing the service.¶

To avoid such attacks, the serverMAY choose to limit the number of activeviews and reject new requests when that threshold is reached. TIPS allowspredictive fetching and the serverMAY also choose to limit the number ofpending requests. If a new request exceeds the threshold, the serverMAY logthe event and return the HTTP status 429 (Too Many Requests).¶

It is important to note that the preceding approaches are not the onlypossibilities. For example, it might be possible for a TIPS server to use somewhat moreclever logic involving TIPS view eviction policies, IP reputation,rate-limiting, and compartmentalization of the overall threshold into smallerthresholds that apply to subsets of potential clients. If service availabilityis a concern, ALTO clientsMAY establish service level agreements with the ALTOserver.¶

9.2.ALTO Client: Update Overloading or Instability

The availability of continuous updates can also cause overload for an ALTOclient, in particular, an ALTO client with limited processing capabilities. Thecurrent design does not include any flow control mechanisms for the client toreduce the update rates from the server. For example, TCP, HTTP/2, and QUICprovide stream and connection flow control data limits, which might help preventthe client from being overloaded. Under overloading, the clientMAY choose toremove the information resources with high update rates.¶

Also, under overloading, the client might no longer be able to detectwhether information is still fresh or has become stale. In such acase, the client should be careful in how it uses the information toavoid stability or efficiency issues.¶

10.1.application/alto-tips+json Media Type

Type name:

application¶

Subtype name:

alto-tips+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

Encoding considerations are identical to those specified for the"application/json" media type. See[RFC8259].¶

Security considerations:

See the Security Considerations section of RFC 9569.¶

Interoperability considerations:

N/A¶

Published specification:

Section 6.2 of RFC 9569.¶

Applications that use this media type:

ALTO servers and ALTO clients either stand alone or are embedded within otherapplications.¶

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

10.2.application/alto-tipsparams+json Media Type

Type name:

application¶

Subtype name:

alto-tipsparams+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

Encoding considerations are identical to those specified for the "application/json" media type. See[RFC8259].¶

Security considerations:

See the Security Considerations section of RFC 9569.¶

Interoperability considerations:

N/A¶

Published specification:

Section 6.1 of RFC 9569.¶

Applications that use this media type:

ALTO servers and ALTO clients either stand alone or are embedded within otherapplications.¶

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