ALTO Working Group R. Schott Internet-Draft Deutsche Telekom Intended status: Standards Track Y. Yang Expires: 9 August 2023 Yale University K. Gao Sichuan University L. Keller Yale University 5 February 2023 ALTO Transport Information Publication Service draft-ietf-alto-new-transport-05 Abstract The ALTO base protocol [RFC7285] is based on HTTP/1.x, designed for the simple, sequential request-reply use case, in which an ALTO client requests a sequence of information resources, and the server sends the complete content of each information resource to the client one by one. To support the use case that an ALTO client can monitor multiple resources at the same time and the ALTO server sends only their updates, the ALTO Working Group introduced ALTO/SSE [RFC8895], which defines a new, SSE-based multiplexing protocol on top of HTTP/1.x, to allow the server to concurrently, and incrementally push updates to the client whenever monitored network information resources change. However, newer versions of HTTP (e.g., HTTP/2 [RFC7540]) already support concurrent, non-blocking transport of multiple streams in the same HTTP connection. This document introduces the ALTO transport information publication service (TIPS), which allows the naming of (i.e., assigning resource identifiers to) individual incremental updates to multiple ALTO information resources and the distribution of the naming, enabling ALTO to take advantage of newer HTTP versions. In particular, it gives an ALTO client the new capability to explicitly request (pull) a specific incremental update. It also provides an ALTO server the new capability to push a specific incremental update using native HTTP/2 or HTTP/3 server push. This document defines TIPS as a service, independent of client pull or server push. A companion document [draft-schott-alto-new-transport-push] defines the complete server- push ALTO transport based on ALTO TIPS. Requirements Language Schott, et al. Expires 9 August 2023 [Page 1] Internet-Draft ALTO TIPS February 2023 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 9 August 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. TIPS Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. TIPS Information . . . . . . . . . . . . . . . . . . . . 5 2.2. TIPS Work Flow . . . . . . . . . . . . . . . . . . . . . 7 3. TIPS Information Resources . . . . . . . . . . . . . . . . . 8 3.1. Notations . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Transport Information Publication Service . . . . . . . . . . 9 4.1. TIPS IRD . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . 9 Schott, et al. Expires 9 August 2023 [Page 2] Internet-Draft ALTO TIPS February 2023 4.1.2. Capabilities . . . . . . . . . . . . . . . . . . . . 9 4.1.3. Uses . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Create Transport State using TIPS . . . . . . . . . . . . 10 4.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Response . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Read Transport State using TIPS . . . . . . . . . . . . . 13 4.4. Delete Transport State using TIPS . . . . . . . . . . . . 14 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. TIPS Queue State Service (QSS) . . . . . . . . . . . . . . . 15 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. IRD Capabilities and Uses . . . . . . . . . . . . . . . . 15 5.4. Request . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 16 5.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. TIPS Update Read Service (URS) . . . . . . . . . . . . . . . 17 6.1. Path . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 18 6.3. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 18 6.4. Capabilities and Uses . . . . . . . . . . . . . . . . . . 18 6.5. Response . . . . . . . . . . . . . . . . . . . . . . . . 18 6.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. TIPS Update Push Service (UPS) . . . . . . . . . . . . . . . 19 8. ALTO TIPS Resource Directory (IRD) . . . . . . . . . . . . . 19 9. Operation and Processing Considerations . . . . . . . . . . . 22 9.1. Considerations for Choosing Updates . . . . . . . . . . . 22 9.2. Considerations for Client Processing Updates . . . . . . 23 9.3. Considerations for Updates to Filtered Cost Maps . . . . 24 9.4. Considerations for Updates to Ordinal Mode Costs . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.1. TIPS: Denial-of-Service Attacks . . . . . . . . . . . . 25 10.2. ALTO Client: Update Overloading or Instability . . . . . 25 10.3. Spoofed URI . . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11.1. application/alto-tips+json Media Type . . . . . . . . . 26 11.2. application/alto-tipsparams+json Media Type . . . . . . 27 11.3. application/alto-tipsqueue+json Media Type . . . . . . . 28 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 13.1. Normative References . . . . . . . . . . . . . . . . . . 30 13.2. Informative References . . . . . . . . . . . . . . . . . 30 Appendix A. Outlook to ALTO with HTTP/3 . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Schott, et al. Expires 9 August 2023 [Page 3] Internet-Draft ALTO TIPS February 2023 1. Introduction Application-Layer Traffic Optimization (ALTO) provides means for network applications to obtain network status information. So far, two transport protocols have been designed: (1) The ALTO base protocol [RFC7285], which is designed for the simple use case in which an ALTO client requests a network information resource, and the server sends the complete content of the requested information resource to the client; and (2) ALTO/SSE (ALTO Incremental Update based on Server-Sent-Event) [RFC8895], which is designed for the use case that an ALTO client indicates to the server that it wants to receive updates for a set of resources, and the server can then concurrently, and incrementally push updates to the client whenever monitored resources change. Both protocols are designed for HTTP/1.x [RFC7230] and ideally, they should be able to automatically take advantage of newer HTTP versions such as HTTP/2 [RFC7540]) and HTTP/3 [RFC9114]. However, there are issues with both protocols when HTTP moves to higher versions. First consider the ALTO base protocol, which is designed to transfer only complete information resources. Hence, a client can run the base protocol on top of HTTP/2 or HTTP/3 to request multiple information resources concurrently, in concurrent streams, but each request must be for a complete information resource; there is no capability of transferring incremental updates. Hence there can be large overhead when the client already has an information resource and then there are small changes to the resource. Next consider ALTO/SSE. Although ALTO/SSE can transfer incremental updates, it introduces a customized multiplexing protocol on top of HTTP, assuming a total-order message channel from the server to the client. The multiplexing design does not provide naming (i.e., providing resource identifier) to individual incremental updates. Hence, the design cannot use concurrent per-stream server push or non-blocking per-stream client pull, available in HTTP/2 and HTTP/3, because both cases require the resource identifier. This document introduces a new ALTO service called the transport information publication service (TIPS), which allows an ALTO server to publish the naming of individual incremental updates to multiple ALTO information resources. TIPS gives an ALTO client the new capability to explicitly, concurrently (non-blocking) request (pull) specific incremental updates using native HTTP/2 or HTTP/3. It also provides an ALTO server the new capability to concurrently push specific incremental updates using native HTTP/2 or HTTP/3 server push. 2. TIPS Overview Schott, et al. Expires 9 August 2023 [Page 4] Internet-Draft ALTO TIPS February 2023 2.1. TIPS Information A key design of the ALTO TIPS is to distinguish between network information resource and the transport information (referred to as transport state). * A transport state is always created for a network information resource. * The basic component of a transport state is an updates queue, which contains a sequence of incremental updates about the network information resource. Each incremental update is assigned a sequence number, and a URI can be constructed using the sequence number. * A static network information resource (e.g., Cost Map, Network Map) may need only a single updates queue, and a dynamic network information resource (e.g., Filtered Cost Map) may create an updates queue for each unique filter request. * A transport state is a container that may include other transport information beyond the updates queue. This document also defines the push updates state, to support server push updates. Figure 2 shows an example illustrating the aforementioned components. Each ALTO client (Client 1, Client 2, or Client 3) maintains a single HTTP connection with the ALTO server. Schott, et al. Expires 9 August 2023 [Page 5] Internet-Draft ALTO TIPS February 2023 Network Information Resource: a) Static resource (#1) such as NetworkMap b) Filterable resource (#3) such as FilteredCostMap +-------------+ | | +--------------------| ALTO Server |-----------+ | +-| |-+ | | | +-------------+ | | | | | | ---------|------------------|-----------------|---------|------------ | | | | Network | | | | Information +-------------+ +-------------+ +-------------+ +-------------+ | Information | | Information | | Information | | Information | | Resource #1 | | Resource #2 | | Resource #3 | | Resource #4 | +-------------+ +-------------+ +-------------+ +-------------+ | / \ -------|-----------------------------/------\------------------------ | / \ Transport | +----/ \------+ Information | | | +--------+ +--------+ +--------+ | ts1 |-----+ | ts2 |-----+ | ts3 |-----+ +----|---+ | +----|---+ | +----|---+ | | | | | | | +----|---+ +---|----+ +----|---+ +---|----+ +----|---+ +---|----+ | ts1/uq | | ts1/sp | | ts2/uq | | ts2/sp | | ts3/uq | | ts3/sp | +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ |\ /\ | / | | -------|-\-----/--\-------------|--------/------------|----------|--- | \ / +-------+ | / | | | +-/-----------+ \ | / | | | / \ \ | / A + + | / +--\--\-|----/--+ single \ / | / +---\--\|---/---+ http2/3 \ / +----------+ +----------+ connection +----------+ | Client 1 | | Client 2 | | Client 3 | +----------+ +------- --+ +----------+ tsi = transport information resource i tsi/uq = incremental-updates queue of transport information resource tsi tsi/sp = server push state associated with tsi Figure 1: ALTO Transport Information. Schott, et al. Expires 9 August 2023 [Page 6] Internet-Draft ALTO TIPS February 2023 2.2. TIPS Work Flow The intended use case of TIPS is to run it as a service inside an HTTP/2 or HTTP/3 connection. Specifically, an ALTO client opens an HTTP connection with an ALTO server, and uses TIPS to create a transport state at the server for each network information resource that the client wants to monitor. The transport state provides (1) the base URI that the server will host incremental updates for the information resource and (2) the start sequence number that the server will order the updates. The server will assign each additional update with a consecutive sequence number. In the simplest use case, the transport state provides enough information for the client to continuously pull each additional update, resulting in the following work flow: Client TIPS URS o . . | Open HTTP connection . . |-------------------------------------->| . | . . | Create Transport state for resource 1 . . | ------------------------------------> | . | , . . |<------------------------------------- | . | . . | GET /content/ . | ------------------------------------------------->| | update content . . |<------------------------------------------------->| | . . | GET /content/ . | ------------------------------------------------->| | update content . . |<------------------------------------------------->| | | DELETE transport state for resource 1 . |-------------------------------------> | | | Close HTTP connection . |-------------------------------------->| o TIPS: Transport Information Publication Service URS : Update Read Service Figure 2: ALTO TIPS Work flow supporting client pull. Schott, et al. Expires 9 August 2023 [Page 7] Internet-Draft ALTO TIPS February 2023 A client that prefers server push can use the following work flow: Client TIPS UPS o . . | Open HTTP connection . . |-------------------------------------->| . | . . | Create Transport state for resource 1 . . | indicate receiving server push . . | ------------------------------------> | . | , . . |<------------------------------------- | . | . . | PUSH /content/ . | <------------------------------------------------ | | . . | PUSH /content/ . | <------------------------------------------------ | | | DELETE transport state for resource 1 . |-------------------------------------> | | | Close HTTP connection . |-------------------------------------->| o TIPS: Transport Information Publication Service UPS : Update Push Service Figure 3: ALTO TIPS Work flow supporting server push. 3. TIPS Information Resources The complete framework of TIPS defines 3 types of services: Transport Information Publication Service (TIPS), TIPS Queue State Service (QSS), TIPS Update Read Service (URS), and TIPS Update Push Service (UPS). This document defines the first two. 3.1. Notations This document uses the same syntax and notations as introduced in Section 8.2 of RFC 7285 [RFC7285] to specify the extensions to existing ALTO resources and services. Schott, et al. Expires 9 August 2023 [Page 8] Internet-Draft ALTO TIPS February 2023 4. Transport Information Publication Service An TIPS service allows an ALTO client to create transport state, read transport state and delete the transport state for an ALTO information resource. 4.1. TIPS IRD An ALTO server's IRD (Information Resource Directory) MAY define one or more transport information publication services, which ALTO clients use to request new TIPS instances. An IRD entry defining a TIPS MUST declare the "media-type", and specify "capabilities" and "uses" as follows. 4.1.1. Media Type The media type of the Transport Information Publication Service resource is "application/alto-tips+json". 4.1.2. Capabilities The capabilities declaration of TIPS is motivated by that defined in Section 6.3 of [RFC8895]. Specifically, the capabilities are defined as an object of type TIPSCapabilities: object { IncrementalUpdateMediaTypes incremental-change-media-types; Boolean support-server-push; } TIPSCapabilities; object-map { ResourceID -> String; } IncrementalUpdateMediaTypes; If a TIPS can provide updates with incremental changes for a resource, the "incremental-change-media-types" field has an entry for that resource-id, and the value is the supported media types of the incremental change separated by commas. Normally, this will be "application/merge-patch+json", "application/json-patch+json", or "application/merge-patch+json,application/json-patch+json". Future extensions may define other types of incremental changes. When choosing the media types to encode incremental updates for a resource, the server MUST consider the limitations of the encoding. For example, when a JSON merge patch specifies that the value of a field is null, its semantics are that the field is removed from the Schott, et al. Expires 9 August 2023 [Page 9] Internet-Draft ALTO TIPS February 2023 target and hence the field is no longer defined (i.e., undefined). This, however, may not be the intended result for the resource, when null and undefined have different semantics for the resource. In such a case, the server MUST choose JSON patch over JSON merge patch if JSON patch is indicated as a capability of the TIPS. If the server does not support JSON patch to handle such a case, the server then need to send a full replacement. The "support-server-push" field specifies whether the given TIPS supports server push. If the "support-server-push" field is "true", this TIPS will allow a client to start or stop server push. 4.1.3. Uses The "uses" attribute MUST be an array with the resource-ids of every resource for which this TIPS can provide service. This set may be any subset of the ALTO server's resources and may include resources defined in linked IRDs. However, it is RECOMMENDED that the ALTO server selects a set that is closed under the resource dependency relationship. That is, if a TIPS' "uses" set includes resource R1 and resource R1 depends on ("uses") resource R0, then the TIPS' "uses" set SHOULD include R0 as well as R1. For example, a TIPS for a cost map SHOULD also provide transport state for the network map upon which that cost map depends. 4.2. Create Transport State using TIPS 4.2.1. Request An ALTO client requests that the server sets up transport state for a given resource by sending an HTTP POST body with the media type "application/alto-tipsparams+json". That body contains a JSON object of type TIPSReq, where: object { ResourceID resource-id; [JSONString tag;] [Object input;] } TIPSReq; with field: resource-id/tag: The resource-id of an ALTO resource and MUST be in the TIPS' "uses" list (Section 4.1). If the resource-id is a GET- mode resource with a version tag (or "vtag"), as defined in Sections 6.3 and 10.3 of [RFC7285], and the ALTO client has Schott, et al. Expires 9 August 2023 [Page 10] Internet-Draft ALTO TIPS February 2023 previously retrieved a version of that resource from ALTO, the ALTO client MAY set the "tag" field to the tag part of the client's version of that resource. The server MAY use the tag when creating the updates queue.Note that the client MUST support all incremental methods from the set announced in the server's capabilities for this resource. If a client does not support all incremental methods from the set announced in the server's capabilities, the client MUST NOT use the TIPS service. input: If the resource is a POST-mode service that requires input, the ALTO client MUST set the "input" field to a JSON object with the parameters that the resource expects. 4.2.2. Response If request has any errors, the TIPS service MUST return an HTTP "400 Bad Request" to the ALTO client; the body of the response follows the generic ALTO error response format specified in Section 8.5.2 of [RFC7285]. Hence, an example ALTO error response has the format: HTTP/1.1 400 Bad Request Content-Length: 131 Content-Type: application/alto-error+json Connection: Closed { "meta":{ "code": "E_INVALID_FIELD_VALUE", "field": "resource-id", "value": "my-networkmap/#" } } Note that "field" and "value" are optional fields. If the "value" field exists, the "field" field MUST exist. * If the TIPS request does not have a "resource-id" field, the error code of the error message MUST be E_MISSING_FIELD and the "field" field SHOULD be "resource-id". The TIPS service MUST NOT create any transport state. * If the "resource-id" field is invalid or is not associated with the TIPS, the error code of the error message MUST be E_INVALID_FIELD_VALUE. The "field" field SHOULD be the full path of the "resource-id" field, and the "value" field SHOULD be the invalid resource-id. Schott, et al. Expires 9 August 2023 [Page 11] Internet-Draft ALTO TIPS February 2023 * If the resource is a POST-mode service that requires input, the client MUST set the "input" field to a JSON object with the parameters that that resource expects. If the "input" field is missing or invalid, TIPS MUST return the same error response that resource would return for missing or invalid input (see [RFC7285]). The response to a valid request MUST be a JSON object of type AddTIPSResponse, denoted as media type "application/alto-tips+json": object { JSONString transport-state-uri; TransportState transport-state; } AddTIPSResponse; object { UpdatesQueueMeta updates-queue-meta; [PushUpdatesMeta push-updates-meta;] } TransportState; object { JSONString uri; UpdatesQueueStateSummary state-summary; } UpdateQueueMeta; object { JSONNumber start-seq; } UpdatesQueueStateSummary; object { JSONString uri; PushUpdatesState state; } PushUpdatesMeta; object { Boolean push-enabled; [JSONNumber next-seq;] } PushUpdatesState; with field: transport-state-uri: The ALTO client MUST evaluate the URI according to [RFC3986]. Hence, the transport state may be located at the same host as the invoking TIPS or on a different host. Let absolute-transport-state-uri as the absolute URI after resolution. Schott, et al. Expires 9 August 2023 [Page 12] Internet-Draft ALTO TIPS February 2023 When creating the URI for the transport state, The TIPS service MUST NOT use other properties of an HTTP request, such as cookies or the client's IP address, to determine the transport state. Furthermore, TIPS MUST NOT reuse a URI for a different object in the same connection. It is expected that there is an internal mechanism to map a transport-state-uri to the unique transport state to be accessed. For example, TIPS may assign a unique, internal state id to each transport state instance. However, the exact mechanism is left to the TIPS provider. To prevent an attacker from forging a transport-state-uri and sending bogus requests, the service should consider two security issues. First, if http, not https, is used, the transport-state- uri can be exposed to an on-path attacker. To address this issue, in a setting where the path from the server to the client can traverse such an attacker, the server SHOULD use https. Second, even without direct exposure, an off-path attacker may guess valid transport-state-uri. To address this issue, the server SHOULD choose URIs with enough randomness to make guessing difficult; the server SHOULD introduce mechanisms that detect repeated guesses indicating an attack (e.g., keeping track of the number of failed stream control attempts). Please see the W3C' "Good Practices for Capability URLs" https://www.w3.org/TR/capability-urls/. transport-state/updates-queue-meta/uri: This must be a relative URI segment. Specifically, let uq-uri denote transport-state/updates- queue-meta/uri and define absolute-transport-state-uri/uq-uri absolute-transport-state-uri/uq-uri/number absolute-transport- state-uri/uq-uri/content/number. Each of them MUST be a valid URI. transport-state/updates-queue-meta/state-summary/start-seq: This MUST be a valid non-negative integer. 4.3. Read Transport State using TIPS An ALTO client can read the transport state using the returned absolute-transport-state-uri (See Section 4.2.2) using the HTTP GET method. For example, if it is on the same connection as that of the invoking TIPS, it is GET The response to a valid request MUST be a JSON object of type TransportState defined in Section 4.2, denoted as media type "application/alto-tips+json". Schott, et al. Expires 9 August 2023 [Page 13] Internet-Draft ALTO TIPS February 2023 4.4. Delete Transport State using TIPS An ALTO client can delete the transport state using the returned absolute-transport-state-uri using the HTTP DELETE method. If it is on the same connection as that of the invoking TIPS, it is DELETE The response to a valid request MUST be 200 if success, and the corresponding error code if there is any error. 4.5. Example For simplicity, assume the ALTO server is using the Basic authentication. If a client with username "client1" and password "helloalto" wants to create a transport queue of an ALTO Cost Map resource with resource ID "my-routingcost-map", it can send the following request: 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: [TBD] { "resource-id": "my-routingcost-map" } If the operation is successful, the ALTO server returns the following message: Schott, et al. Expires 9 August 2023 [Page 14] Internet-Draft ALTO TIPS February 2023 HTTP/1.1 200 OK Content-Type: application/alto-tips+json Content-Length: [TBD] { "transport-state-uri": “/tips/2718281828459”, "transport-state": { "updates-queue-meta" : { "uri": "uq", "state-summary": { "start-seq": 101 } }, "push-updates-meta" : { "uri": "sp", "state": { "push-enabled" : false, "next-seq" : -1 } }, } } 5. TIPS Queue State Service (QSS) The TIPS QSS service allows an ALTO client to read the updates queue. It uses the URI returned in Section 4. 5.1. Media Type A QSS response uses "application/alto-tipsqueue+json" media type. 5.2. HTTP Method An ALTO QSS resource is requested using the HTTP GET method. 5.3. IRD Capabilities and Uses None (QSS does not appear in the IRD). 5.4. Request An ALTO client reads the queue state using an HTTP GET method, with the path constructed as: Schott, et al. Expires 9 August 2023 [Page 15] Internet-Draft ALTO TIPS February 2023 := / specified in Section 4. 5.5. Response If the transport state is closed, the ALTO server MUST return an error HTTP message with status code 404 (Not Found) and media type "application/alto-error+json". The response from the server, if no error, is the UpdatesQueue object indicated as "application/alto-tipsqueue+json" media type: object-map { Seq -> UpdateItem; } UpdatesQueue; object-map { JSONString media-type; JSONString tag; [JSONString link;] } UpdateItem; with field: Seq: A required, positive JSON integer indicating the sequence number of the incremental update. As JSON allows a large integer space, when the server reaches the largest integer, the server SHOULD close the incremental update queue. media-type: A required JSON string giving the type of the incremental update (see ALTO/SSE). tag: A required JSON string which is defined the same way as the "tag" field of VersionTag (see Section 10.3 of [RFC7285]). link: An optional JSON string giving an optional link for a client to directly request a resource as a complete snapshot (not through incremental updates). 5.6. Example Schott, et al. Expires 9 August 2023 [Page 16] Internet-Draft ALTO TIPS February 2023 GET /tips/2718281828459/uq HTTP/1.1 Host: alto.example.com Accept: application/alto-tipsqueue+json, application/alto-error+json Authorization: Basic Y2xpZW50MTpoZWxsb2FsdG8K HTTP/1.1 200 OK Content-Type: application/alto-tipsqueue+json Content-Length: [TBD] { 101 : { "media-type": "application/alto-costmap+json", “tag”: "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe" }, 102 : { "media-type": "application/merge-patch+json", “tag”: "cdf0222x59740b0b2e3f8eb1d4785acd42231bfe" }, 103 : { "media-type": "application/merge-patch+json", “tag”: "8eb1d4785acd42231bfecdf0222x59740b0b2e3f", "link": "/tips/2718281828459/snapshot/2e3f" } } An ALTO client can also read the (meta data) of an individual element in the updates queue. The HTTP method MUST also be GET, and the URI is constructed by appending the seq at the end of the preceding URI. 6. TIPS Update Read Service (URS) The TIPS URS service allows an ALTO client to read the content of a an update element from the updates queue. 6.1. Path The path to the content of an update item resource has the following format: := /content/ where updates-queue-complete-uri is specified in Section 5.4. Schott, et al. Expires 9 August 2023 [Page 17] Internet-Draft ALTO TIPS February 2023 For example, if the client wants to query the content of the first update item (with sequence number 101), it can send a request to "/tips/2718281828459/uq/101". 6.2. Media Type The media type of an Update Item resource MUST be the same as the "media-type" field of the update item with sequence number seq in the updates queue. For example, if the client wants to query the content of the first update item (with sequence number 101) whose media type is "application/alto-costmap+json", it must set the "Accept" header to "application/alto-costmap+json, application/alto-error+json" in the request. 6.3. HTTP Method The Update Read Service resource must be requested using the HTTP GET method. 6.4. Capabilities and Uses None 6.5. Response If the transport state is closed, the ALTO server MUST return an error HTTP message with status code 404 (Not Found) and media type "application/alto-error+json". Otherwise, let LOW_SEQ and HIGH_SEQ represent the smallest and largest sequence number in the updates queue of the transport state respectively. If seq is smaller than LOW_SEQ, the ALTO server MUST return an error HTTP message with status code 410 (Gone) and media type "application/alto-error+json". If seq is greater than HIGH_SEQ, the ALTO server MAY either treat the request as a long polling request and save it as a pending request; if the server wants to conduct resource control, the server can return an error code and indicate the "Re-Try After" headers. If the request is valid, the response is encoded as a JSON object whose data format is indicated by the media type. 6.6. Example Assume the client wants to get the contents of updates 101, the request is: Schott, et al. Expires 9 August 2023 [Page 18] Internet-Draft ALTO TIPS February 2023 GET /tips/2718281828459/uq/content/101 HTTP/1.1 Host: alto.example.com Accept: application/alto-costmap+json, application/alto-error+json And the response will be HTTP/1.1 200 OK Content-Type: application/alto-costmap+json Content-Length: [TBD] { ... full replacement of my-routingcost-map ... } 7. TIPS Update Push Service (UPS) The TIPS UPS service allows an ALTO client to receive an element pushed by the ALTO server. We leave the specification to a companion document. 8. ALTO TIPS Resource Directory (IRD) Extending the IRD example in Section 8.1 of [RFC8895], below is the IRD of an ALTO server supporting ALTO base protocol, ALTO/SSE, and ALTO TIPS. In particular, "my-network-map": { "uri": "https://alto.example.com/networkmap", "media-type": "application/alto-networkmap+json", }, "my-routingcost-map": { "uri": "https://alto.example.com/costmap/routingcost", "media-type": "application/alto-costmap+json", "uses": ["my-networkmap"], "capabilities": { "cost-type-names": ["num-routingcost"] } }, "my-hopcount-map": { "uri": "https://alto.example.com/costmap/hopcount", "media-type": "application/alto-costmap+json", "uses": ["my-networkmap"], "capabilities": { "cost-type-names": ["num-hopcount"] } }, "my-filtered-cost-map": { Schott, et al. Expires 9 August 2023 [Page 19] Internet-Draft ALTO TIPS February 2023 "uri": "https://alto.example.com/costmap/filtered/constraints", "media-type": "application/alto-costmap+json", "accepts": "application/alto-costmapfilter+json", "uses": ["my-networkmap"], "capabilities": { "cost-type-names": ["num-routingcost", "num-hopcount"], "cost-constraints": true } }, "my-simple-filtered-cost-map": { "uri": "https://alto.example.com/costmap/filtered/simple", "media-type": "application/alto-costmap+json", "accepts": "application/alto-costmapfilter+json", "uses": ["my-networkmap"], "capabilities": { "cost-type-names": ["num-routingcost", "num-hopcount"], "cost-constraints": false } }, "my-props": { "uri": "https://alto.example.com/properties", "media-type": "application/alto-endpointprops+json", "accepts": "application/alto-endpointpropparams+json", "capabilities": { "prop-types": ["priv:ietf-bandwidth"] } }, "my-pv": { "uri": "https://alto.example.com/endpointcost/pv", "media-type": "multipart/related; type=application/alto-endpointcost+json", "accepts": "application/alto-endpointcostparams+json", "capabilities": { "cost-type-names": [ "path-vector" ], "ane-properties": [ "maxresbw", "persistent-entities" ] } }, "update-my-costs": { "uri": "https://alto.example.com/updates/costs", "media-type": "text/event-stream", "accepts": "application/alto-updatestreamparams+json", "uses": [ "my-network-map", "my-routingcost-map", Schott, et al. Expires 9 August 2023 [Page 20] Internet-Draft ALTO TIPS February 2023 "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" }, "server-push": true } }, "update-my-props": { "uri": "https://alto.example.com/updates/properties", "media-type": "text/event-stream", "uses": [ "my-props" ], "accepts": "application/alto-updatestreamparams+json", "capabilities": { "incremental-change-media-types": { "my-props": "application/merge-patch+json" }, "support-stream-control": true } }, "update-my-pv": { "uri": "https://alto.example.com/updates/pv", "media-type": "text/event-stream", Schott, et al. Expires 9 August 2023 [Page 21] Internet-Draft ALTO TIPS February 2023 "uses": [ "my-pv" ], "accepts": "application/alto-updatestreamparams+json", "capabilities": { "incremental-change-media-types": { "my-pv": "application/merge-patch+json" }, "support-stream-control": true } } Note that it is straightforward for an ALTO sever to run HTTP/2 and support concurrent retrieval of multiple resources such as "my- network-map" and "my-routingcost-map" using multiple HTTP/2 streams. The resource "update-my-costs-tips" provides an ALTO TIPS based connection, and this is indicated by the media-type "application/ alto-tips+json". 9. Operation and Processing Considerations 9.1. Considerations for Choosing Updates TIPS should be cognizant of the effects of its update schedule, which includes both the choice of timing (i.e., when/what to trigger an update on the updates queue) and the choice of message format (i.e., given an update, send a full replacement or an incremental change). In particular, the update schedule can have effects on both the overhead and the freshness of information. To minimize overhead, TIPS may choose to batch a sequence of updates for resources that frequently change by cumulative updates or a full replacement after a while. TIPS should be cognizant that batching reduces the freshness of information. The server should also consider the effect of such delays on client behaviors (see below on client timeout on waiting for updates of dependent resources). For incremental updates, this design allows both JSON patch and JSON merge patch for incremental changes. JSON merge patch is clearly superior to JSON patch for describing incremental changes to cost maps, endpoint costs, and endpoint properties. For these data structures, JSON merge patch is more space efficient, as well as simpler to apply. There is no advantage allowing a server to use JSON patch for those resources. The case is not as clear for incremental changes to network maps. First, consider small changes, such as moving a prefix from one PID to another. JSON patch could encode that as a simple insertion and deletion, while JSON merge patch would have to replace the entire Schott, et al. Expires 9 August 2023 [Page 22] Internet-Draft ALTO TIPS February 2023 array of prefixes for both PIDs. On the other hand, to process a JSON patch update, the ALTO client would have to retain the indexes of the prefixes for each PID. Logically, the prefixes in a PID are an unordered set, not an array; aside from handling updates, a client has no need to retain the array indexes of the prefixes. Hence, to take advantage of JSON patch for network maps, ALTO clients would have to retain additional, otherwise unnecessary, data. Second, consider more involved changes, such as removing half of the prefixes from a PID. JSON merge patch would send a new array for that PID, while JSON patch would have to send a list of remove operations and delete the prefix one by one. Therefore, each TIPS may decide on its own whether to use JSON merge patch or JSON patch according to the changes in network maps. 9.2. Considerations for Client Processing Updates In general, when an ALTO client receives a full replacement for a resource, the ALTO client should replace the current version with the new version. When an ALTO client receives an incremental change for a resource, the ALTO client should apply those patches to the current version of the resource. However, because resources can depend on other resources (e.g., cost maps depend on network maps), an ALTO client MUST NOT use a dependent resource if the resource on which it depends has changed. There are at least two ways an ALTO client can do that. The following paragraphs illustrate these techniques by referring to network and cost map messages, although these techniques apply to any dependent resources. Note that when a network map changes, the update stream server MUST send the network map update message before sending the updates for the dependent cost maps (see Section 6.7.1). One approach is for the ALTO client to save the network map update message in a buffer and continue to use the previous network map and the associated cost maps until the ALTO client receives the update messages for all dependent cost maps. The ALTO client then applies all network and cost map updates atomically. Schott, et al. Expires 9 August 2023 [Page 23] Internet-Draft ALTO TIPS February 2023 Alternatively, the ALTO client MAY update the network map immediately. In this case, the cost maps using the network map become invalid because they are inconsistent with the current network map; hence, the ALTO client MUST mark each such dependent cost map as temporarily invalid and MUST NOT use each such cost map until the ALTO client receives a cost map update indicating that it is based on the new network map version tag. When implementing server push, the server SHOULD send updates for dependent resource (i.e., the cost maps in the preceding example) in a timely fashion. However, if the ALTO client does not receive the expected updates, a simple recovery method is that the ALTO client uses client pull to request the missing update. The ALTO client MAY retain the version tag of the last version of any tagged resources and search those version tags when identifying the new updates to pull. Although not as efficient as possible, this recovery method is simple and reliable. 9.3. Considerations for Updates to Filtered Cost Maps If TIPS provides updates to a Filtered Cost Map that allows constraint tests, then an ALTO client MAY request updates to a Filtered Cost Map request with a constraint test. In this case, when a cost changes, the updates queue MUST have an update if the new value satisfies the test. If the new value does not, whether there is an update depends on whether the previous value satisfied the test. If it did not, the updates queue SHOULD NOT have an update. But if the previous value did, then the updates queue MUST add an update with a "null" value to inform the ALTO client that this cost no longer satisfies the criteria. TIPS can avoid having to handle such a complicated behavior by offering TIPS only for Filtered Cost Maps that do not allow constraint tests. 9.4. Considerations for Updates to Ordinal Mode Costs For an ordinal mode cost map, a change to a single cost point may require updating many other costs. As an extreme example, suppose the lowest cost changes to the highest cost. For a numerical mode cost map, only that one cost changes. But for an ordinal mode cost map, every cost might change. While this document allows TIPS to offer incremental updates for ordinal mode cost maps, TIPS implementors should be aware that incremental updates for ordinal costs are more complicated than for numerical costs, and ALTO clients should be aware that small changes may result in large updates. Schott, et al. Expires 9 August 2023 [Page 24] Internet-Draft ALTO TIPS February 2023 A TIPS can avoid this complication by only offering full replacements as updates in the updates queue for ordinal cost maps. 10. Security Considerations The security considerations (Section 15 of [RFC7285]) of the base protocol fully apply to this extension. For example, the same authenticity and integrity considerations (Section 15.1 of [RFC7285]) still fully apply; the same considerations for the privacy of ALTO users (Section 15.4 of [RFC7285]) also still fully apply. The additional services (addition of update read service and update push service) provided by this extension extend the attack surface described in Section 15.1.1 of [RFC7285]. Below, we discuss the additional risks and their remedies. 10.1. TIPS: Denial-of-Service Attacks Allowing persistent TIPS states enables a new class of Denial-of- Service attacks. In particular, For the TIPS server, an ALTO client might create an unreasonable number of transport states. To avoid these attacks on the TIPS server, the server SHOULD choose to limit the number of active states and reject new requests when that threshold is reached. The Update Read Service allows predicative fetching and the server SHOULD also choose to limit the number of pending requests. In these cases, the update stream server SHOULD return the HTTP status "503 Service Unavailable". It is important to note that the preceding approaches are not the only possibilities. For example, it may be possible for TIPS to use somewhat more clever logic involving IP reputation, rate-limiting, and compartmentalization of the overall threshold into smaller thresholds that apply to subsets of potential clients. 10.2. ALTO Client: Update Overloading or Instability The availability of continuous updates, when the client indicates receiving server push, can also cause overload for an ALTO client, in particular, an ALTO client with limited processing capabilities. The current design does not include any flow control mechanisms for the client to reduce the update rates from the server. Under overloading, the client MAY choose to remove the information resources with high update rates. Schott, et al. Expires 9 August 2023 [Page 25] Internet-Draft ALTO TIPS February 2023 Also, under overloading, the client may no longer be able to detect whether information is still fresh or has become stale. In such a case, the client should be careful in how it uses the information to avoid stability or efficiency issues. 10.3. Spoofed URI An outside party that can read the TIPS response or that can observe TIPS requests can obtain the transport state URI and use that to send a fraudulent "DELETE" requests, thus disabling the service for the valid ALTO client. This can be avoided by encrypting the requests and responses (see Section 15 of [RFC7285]). In general, as the architecture allows the possibility for TIPS, URS and UPS to be different entities, the additional risks should be evaluated and remedied. For example, the private communication path between the servers may be attacked, resulting in a risk of communications breakdown between them, as well as invalid or spoofed messages claiming to be on that private communications path. Proper security mechanisms, including confidentiality, authenticity, and integrity mechanisms, should be considered. 11. IANA Considerations IANA will need to register the following media type under ALTO registry as defined in [RFC7285]: * application/alto-tips+json: as described in Section 4.2.2; * application/alto-tipsparams+json: as described in Section 4.2.1; * application/alto-tipsqueue+json: as described in Section 5.5 11.1. application/alto-tips+json Media Type Type name: application Subtype name: alto-tips+json Required parameters: N/A Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259]. Security considerations: Security considerations relating to the Schott, et al. Expires 9 August 2023 [Page 26] Internet-Draft ALTO TIPS February 2023 generation and consumption of ALTO Protocol messages are discussed in Section 10 of [RFC8895] and Section 15 of [RFC7285]. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: Section 4.2.2 of this document. Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): This document uses the media type to refer to protocol messages and thus does not require a file extension. Macintosh file type code(s): N/A Person and email address to contact for further information: See Aut hors' Addresses section. Intended usage: COMMON Restrictions on usage: N/A Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 11.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 Schott, et al. Expires 9 August 2023 [Page 27] Internet-Draft ALTO TIPS February 2023 those specified for the "application/json" media type. See [RFC8259]. Security considerations: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of [RFC8895] and Section 15 of [RFC7285]. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: Section 4.2.1 of this document. Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): This document uses the media type to refer to protocol messages and thus does not require a file extension. Macintosh file type code(s): N/A Person and email address to contact for further information: See Aut hors' Addresses section. Intended usage: COMMON Restrictions on usage: N/A Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 11.3. application/alto-tipsqueue+json Media Type Type name: application Subtype name: alto-tipsqueue+json Required parameters: N/A Schott, et al. Expires 9 August 2023 [Page 28] Internet-Draft ALTO TIPS February 2023 Optional parameters: N/A Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259]. Security considerations: Security considerations relating to the generation and consumption of ALTO Protocol messages are discussed in Section 10 of [RFC8895] and Section 15 of [RFC7285]. Interoperability considerations: This document specifies format of conforming messages and the interpretation thereof. Published specification: Section 5.5 of this document. Applications that use this media type: ALTO servers and ALTO clients either stand alone or are embedded within other applications. Fragment identifier considerations: N/A Additional information: Deprecated alias names for this type: N/A Magic number(s): N/A File extension(s): This document uses the media type to refer to protocol messages and thus does not require a file extension. Macintosh file type code(s): N/A Person and email address to contact for further information: See Aut hors' Addresses section. Intended usage: COMMON Restrictions on usage: N/A Author: See Authors' Addresses section. Change controller: Internet Engineering Task Force (mailto:iesg@ietf.org). 12. Acknowledgments The authors of this document would also like to thank many for the reviews and comments. Schott, et al. Expires 9 August 2023 [Page 29] Internet-Draft ALTO TIPS February 2023 13. References 13.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November 2020, . 13.2. Informative References [draft-schott-alto-new-transport-push] Schott, R. and Y. Yang, "ALTO New Transport: Server Push", Internet Draft ID, October 2022, . Schott, et al. Expires 9 August 2023 [Page 30] Internet-Draft ALTO TIPS February 2023 [RFC7971] Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and S. Previdi, "Application-Layer Traffic Optimization (ALTO) Deployment Considerations", RFC 7971, DOI 10.17487/RFC7971, October 2016, . Appendix A. Outlook to ALTO with HTTP/3 This draft is focusing on HTTP/2 enhancement of the ALTO protocol and the design takes advantage of HTTP/2 design features such as parallel transfer and respects HTTP/2 semantics (e.g., PUSH_PROMISE). Since QUIC and HTTP/3 respectively are coming up for various protocols on the Internet it is understandable that the question arises, if ATLO could also take advantage of the advantages of HTTP/3. QUIC can be seen as a replacement for TCP+TLS+HTTP2. HTTP/3 bases on the QUIC transport protocol and uses UDP instead of a TCP connection. QUIC has been developed by the IETF QUIC Working Group with the following goals: * Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2 * Providing multiplexing without head-of-line blocking * Requiring only changes to path endpoints to enable deployment * Enabling multipath and forward error correction extensions * Providing always-secure transport, using TLS 1.3 by default If HTTP/3 is not supported, it automatically runs on HTTP/2. The prerequisite for HTTP/3 is that both client and server support it. The basic assumption is that an implementation that runs on HTTP/2 should also run-on HTTP/3. This should be transparent. HTTP/3 uses "well known port" UDP 443 analogous to TCP 443. The network between client and server must not filter HTTP/3. Since many applications still using HTTP/2 it is mandatory for ALTO to support this protocol first. This ensures compatibility. Therefore, this document describes the update of ALTO from HTTP/1.x to HTTP/2. The usage of HTTP/3 will be described in a separate document so that compatibility of ALTO with HTTP/3 will be ensured in a later stage. Authors' Addresses Schott, et al. Expires 9 August 2023 [Page 31] Internet-Draft ALTO TIPS February 2023 Roland Schott Deutsche Telekom Heinrich-Hertz-Strasse 3-7 64295 Darmstadt Germany Email: Roland.Schott@telekom.de Y. Richard Yang Yale University 51 Prospect St New Haven, CT 06520 United States of America Email: yry@cs.yale.edu Kai Gao Sichuan University Chengdu 201804 China Email: kgao@scu.edu.cn Lachlan Keller Yale University 51 Prospect Street New Haven, 06511 United States of America Email: lachlan.keller@yale.edu Schott, et al. Expires 9 August 2023 [Page 32]