Application-Layer Traffic Optimization (ALTO) Cost Calendar
Extracted elements (30)
A Server SHOULD advertise the smallest 'time-interval-size' it can provide in the IRD, because Clients requiring coarser granularity can aggregate multiple values, but Clients requiring finer granularity cannot subdivide them. This maximizes the utility of a single IRD announcement.
Calendared resources are not applicable to full cost maps (fetched via HTTP GET) because a legacy ALTO Client receiving a calendared cost map would ignore the Calendar 'meta' attributes per RFC 7285 Section 8.3.7, leaving it unable to correctly interpret the array values. POST-based Filtered Cost Map and Endpoint Cost Service are used instead.
Constraints are explicitly excluded from Calendar requests because (1) clients have diverse preferences about how many constraint violations are acceptable across a time-array, making a universal constraint model impractical, and (2) evaluating constraints over an entire Calendar array would impose substantial processing overhead on the Server before it can return a response.
Cost Calendars are applicable to all cost modes—not just 'numerical'—because string values (e.g., 'high', 'low', 'open') and boolean values can also be time-varying. The 'ordinal' mode is also compatible if its values change over time.
The Calendar extension intentionally introduces no new media types, no new cost modes, and no new IRD structure, relying on RFC 7285's 'unknown fields MUST be ignored' rule for backwards compatibility. Calendar capabilities are embedded in existing resource capabilities under a 'calendar-attributes' member.
The 'repeated' attribute allows a Server to signal that the same Calendar values are valid across N consecutive iterations starting from 'calendar-start-time', enabling Clients to schedule future requests rather than re-querying unnecessarily, thereby reducing workload for both parties.
Legacy ALTO Clients (RFC 7285 only) can co-exist with Calendar-aware Servers because: unknown fields in JSON objects MUST be ignored per RFC 7285 Section 8.3.7, and Calendar resources require POST, so a legacy Client using GET on a full cost map will never receive Calendar arrays it cannot interpret.
RFC 8259 (used by ALTO Calendars) mandates UTF-8 encoding and replaces RFC 7159 (used by base ALTO RFC 7285). Implementations using UTF-16 or UTF-32 will not interoperate with Calendar-aware peers without switching encoding.
A Calendar-aware ALTO Server and a Calendar-aware ALTO Client MUST both implement the base ALTO protocol specified in RFC 7285.
A cost type name MUST NOT appear more than once in the 'calendar-attributes' member of a resource entry. Multiple appearances MUST cause the Client to ignore occurrences beyond the first encountered. As an alternative, the Client MAY ignore all CalendarAttributes objects containing that name and fall back to RFC 7285.
ALTO Clients and Servers implementations using UTF-16 or UTF-32 MUST switch to UTF-8 encoding to interoperate with Calendar-aware implementations, as RFC 8259 mandates UTF-8.
ALTO Clients and Servers SHOULD use IEEE 754 double-precision floating point to store 'time-interval-size' to improve interoperability and be consistent with RFC 7285 on floating-point number usage.
An implementor of this extension MUST treat a cost entry as a JSON array of values (not a single number) if that cost type was queried as a Calendar. The expected array length is the 'number-of-intervals' value announced in the IRD.
Calendared information resources MUST be requested via the Filtered Cost Map Service or the Endpoint Cost Service using the HTTP POST method. Full cost map Calendar resources requested via GET are incompatible with legacy ALTO clients.
If 'calendared' is 'true' for a cost type with no defined Calendar attributes, the Server MUST ignore it and return a single cost value per RFC 7285. If 'calendared' is 'false' for a given cost type, the Server MUST return a single cost value for that type.
It is RECOMMENDED that ALTO Servers providing Cost Calendars also provide the ALTO Incremental Updates Using SSE Service (RFC 8895), and ALTO Clients using Calendars SHOULD also use the SSE Service to receive timely Calendar updates when network conditions change unexpectedly.
The 'calendar-start-time' attribute in Calendar responses MUST be specified as an HTTP 'Date' header field using the IMF-fixdate format defined in Section 7.1.1.1 of RFC 7231, expressed in GMT. Its value SHOULD NOT be later than the request date.
The 'calendared' boolean array in a request MUST contain exactly N boolean values (N = number of requested cost types); otherwise the Server returns an error. The field MUST NOT be included if no 'calendar-attributes' member is specified for the information resource.
The 'constraints' member MUST NOT be present in the input parameters of a request for an Endpoint Cost Calendar. If present, the Server MUST ignore it. Constraints are mutually exclusive with Calendar functionality.
The size of the cost value array received by the Client MUST equal the 'number-of-intervals' attribute in the IRD for the requested cost type. When the received array size differs, the Client SHOULD ignore the received array.
When a metric is available as a Calendar array, it also MUST be available as a single value as required by RFC 7285. The Server provides the current value to legacy or non-Calendar-interested Clients.
An ALTO Cost Calendar provides two items: an array of cost values where each value applies to a specific time interval, and attributes describing the time scope (interval size, count, and start time). It enables applications to schedule data transfers based on predicted future network conditions.
CalendarAttributes is an IRD object identified by the 'calendar-attributes' member of a resource entry. It groups one or more cost type names sharing the same 'time-interval-size' (seconds, JSONNumber) and 'number-of-intervals' (strictly positive integer) values. Multiple CalendarAttributes objects may appear in the array to handle cost types with different interval parameters.
CalendarResponseAttributes is a metadata object returned in ALTO Server responses to Calendar requests. It extends CalendarAttributes with 'calendar-start-time' (IMF-fixdate string) and an optional 'repeated' field (integer >= 1) indicating how many consecutive iterations of the Calendar have identical values, allowing clients to avoid redundant requests.
Calendar values, especially those marked 'repeated', are statistical predictions; future events may invalidate them. Clients should treat Calendar values as advisory, and it is RECOMMENDED that both Clients and Servers support ALTO SSE (RFC 8895) to receive immediate updates when Calendar values change.
Calendaring information exposes future scheduled network events, giving a malicious Client foreknowledge to generate massive connections precisely when network load is expected to be high, potentially orchestrating a DDoS attack. Operators should deploy monitoring systems to detect abnormal behavior in addition to standard ALTO authentication and TLS.
To prevent MITM interception of ALTO Calendars, the ALTO Server SHOULD authenticate Clients and MUST support the 'https' URI scheme. ALTO Clients and Servers SHOULD support both TLS 1.3 (RFC 8446) and TLS 1.2 (RFC 5246) and MAY support newer versions.
CalendarAttributes JSON object contains: 'cost-type-names' (array of JSONString, 1 or more), 'time-interval-size' (JSONNumber, non-negative, in seconds, may be floating point), and 'number-of-intervals' (strictly positive JSONNumber integer). It appears in the 'calendar-attributes' array member of an IRD resource entry.
CalendarResponseAttributes JSON object contains: optional 'cost-type-names' (array of JSONString, required when multiple cost types), 'calendar-start-time' (JSONString in IMF-fixdate format), 'time-interval-size' (JSONNumber), 'number-of-intervals' (JSONNumber), and optional 'repeated' (JSONNumber integer >= 1). It is conveyed in the 'calendar-response-attributes' 'meta' member of FCM and ECS responses.
The 'calendared' request field is a JSONBoolean array of exactly N elements (where N equals the number of requested cost metrics). Each boolean indicates whether the corresponding cost type should be returned as a Calendar array. When absent, it is assumed to be all-false.