Internet Engineering Task Force (IETF)                    S. Randriamasy
Request for Comments: 8896                               Nokia Bell Labs
Category: Standards Track                                        Y. Yang
ISSN: 2070-1721                                          Yale University
                                                                   Q. Wu
                                                                 L. Deng
                                                            China Mobile
                                                               N. Schwan
                                                      Thales Deutschland
                                                           November 2020

Application-Layer Traffic Optimization (ALTO) Cost Calendar




This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.

この文書は、基本アプリケーション層トラフィック最適化(ALTO)プロトコルの拡張です。Alto Cost Information Serviceを拡張して、アプリケーションは「どこで」接続するだけでなく「いつ」も決定します。これは、バルクデータ転送を実行する必要があるアプリケーションであり、ピーク時にこれらの転送をスケジュールしたいと考えています。この拡張子は、ALTOサーバがJSONアレイ内のALTOコスト値を公開するALTOコストカレンダを紹介し、各値が所与の時間間隔に対応する。時間間隔、および他のカレンダー属性は、情報リソースディレクトリとALTOサーバーの応答に指定されています。

Status of This Memo


This is an Internet Standards Track document.


This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ(IESG)による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

Copyright(C)2020 IETFの信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、この文書の公開日に有効なIETF文書(に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。

Table of Contents


   1.  Introduction
     1.1.  Some Recent Known Uses
     1.2.  Terminology
   2.  Requirements Language
   3.  Overview of ALTO Cost Calendars and Terminology
     3.1.  ALTO Cost Calendar Overview
     3.2.  ALTO Cost Calendar Information Features
     3.3.  ALTO Calendar Design Characteristics
       3.3.1.  ALTO Cost Calendar for All Cost Modes
       3.3.2.  Compatibility with Legacy ALTO Clients
   4.  ALTO Calendar Specification: IRD Extensions
     4.1.  Calendar Attributes in the IRD Resource Capabilities
     4.2.  Calendars in a Delegate IRD
     4.3.  Example IRD with ALTO Cost Calendars
   5.  ALTO Calendar Specification: Service Information Resources
     5.1.  Calendar Extensions for Filtered Cost Maps (FCM)
       5.1.1.  Calendar Extensions in Filtered Cost Map Requests
       5.1.2.  Calendar Extensions in Filtered Cost Map Responses
       5.1.3.  Use Case and Example: FCM with a Bandwidth Calendar
     5.2.  Calendar Extensions in the Endpoint Cost Service
       5.2.1.  Calendar-Specific Input in Endpoint Cost Requests
       5.2.2.  Calendar Attributes in the Endpoint Cost Response
       5.2.3.  Use Case and Example: ECS with a routingcost Calendar
       5.2.4.  Use Case and Example: ECS with a Multi-cost Calendar
               for routingcost and owdelay
   6.  IANA Considerations
   7.  Security Considerations
   8.  Operational Considerations
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Authors' Addresses
1. Introduction
1. はじめに

The base Application-Layer Traffic Optimization (ALTO) protocol specified in [RFC7285] provides guidance to overlay applications that need to select one or several hosts from a set of candidates able to provide a desired resource. This guidance is based on parameters that affect performance and efficiency of the data transmission between the hosts, such as the topological distance. The goal of ALTO is to improve the Quality of Experience (QoE) in the application while optimizing resource usage in the underlying network infrastructure.


The ALTO protocol in [RFC7285] specifies a network map that defines groupings of endpoints in provider-defined network regions identified by Provider-defined Identifiers (PIDs). The Cost Map Service, Endpoint Cost Service (ECS), and Endpoint Ranking Service then provide ISP-defined costs and rankings for connections among the specified endpoints and PIDs and thus incentives for application clients to connect to ISP-preferred locations, for instance, to reduce their costs. For the reasons outlined in the ALTO problem statement [RFC5693] and requirement AR-14 of [RFC6708], ALTO does not disseminate network metrics that change frequently. In a network, the costs can fluctuate for many reasons having to do with instantaneous traffic load or diurnal patterns of traffic demand or planned events, such as network maintenance, holidays, or highly publicized events. Thus, an ALTO application wishing to use the Cost Map and Endpoint Cost Service at some future time will have to estimate the state of the network at that time, a process that is, at best, fragile and brittle, since the application does not have any visibility into the state of the network. Providing network costs for only the current time thus may not be sufficient, in particular for applications that can schedule their traffic in a span of time, for example, by deferring backups or other background traffic to off-peak hours.

[RFC7285]のALTOプロトコルは、プロバイダー定義識別子(PID)によって識別されるプロバイダー定義ネットワーク領域内のエンドポイントのグループを定義するネットワークマップを指定します。コストマップサービス、エンドポイントコストサービス(ECS)、およびエンドポイントランキングサービスは、指定されたエンドポイントとPIDの間の接続のためにISP定義コストとランキング、したがって、アプリケーションクライアントにISP優先されている場所に接続するためのインセンティブを提供します。彼らのコストを削減します。 ALTO問題ステートメント[RFC5693]と[RFC6708]の[RFC5693]の[RFC5693]に概説されている理由で、Altoは頻繁に変化するネットワークメトリックを普及させません。ネットワークでは、コストは、瞬間的な交通荷重や交通需要の日周のパターンやネットワークのメンテナンス、休日、または高さの公表されたイベントなど、さまざまな理由で変動する可能性があります。したがって、いくつかの将来の時間にコストマップおよびエンドポイントコストサービスを使用することを望むALTOアプリケーションは、その時点でネットワークの状態を推定しなければならないでしょう。アプリケーションは持っていないため、最良の、脆弱で脆くなっているプロセスネットワークの状態への可視性。したがって、現在時刻のみのネットワークコストを提供することは、特に、例えばバックアップまたは他のバックグラウンドトラフィックをオフピーク時間に延期することによって、時間の間でそれらのトラフィックをスケジュールできるアプリケーションでは十分ではないかもしれない。

In case the ALTO cost value changes are predictable over a certain period of time and the application does not require immediate data transfer, it can save time to get the whole set of cost values over this period in one single ALTO response. Using this set to schedule data transfers allows optimizing the network resources usage and QoE. ALTO Clients and Servers can also minimize their workload by reducing and accordingly scheduling their data exchanges.


This document extends [RFC7285] to allow an ALTO Server to provide network costs for a given duration of time. A sequence of network costs across a time span for a given pair of network locations is named an "ALTO Cost Calendar". The Filtered Cost Map Service and Endpoint Cost Service are extended to provide Cost Calendars. In addition to this functional ALTO enhancement, we expect to further save network and storage resources by gathering multiple cost values for one cost type into one single ALTO Server response.

この文書は[RFC7285]を拡張して、ALTOサーバーが特定の期間のネットワークコストを提供できるようにします。所与のネットワーク位置対の期間にわたる一連のネットワークコストは、「Alto Cost Calendar」と命名されている。フィルタリングされたコストマップサービスとエンドポイントコストサービスは、コストカレンダーを提供するために拡張されています。この機能ALTOの向上に加えて、1つのコストタイプの複数のコスト値を1つのALTOサーバーの応答に集めることで、ネットワークとストレージリソースをさらに保存することを期待します。

In this document, an "ALTO Cost Calendar" is specified in terms of information resource capabilities that are applicable to time-sensitive ALTO metrics. An ALTO Cost Calendar exposes ALTO cost values in JSON arrays, see [RFC8259], where each value corresponds to a given time interval. The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory (IRD) and in the Server response to allow the ALTO Client to interpret the received ALTO values. Last, the extensions for ALTO Calendars are applicable to any cost mode, and they ensure backwards compatibility with legacy ALTO Clients -- those that only support [RFC7285].

この文書では、「Alto Cost Calendar」は、時間依存ALTOメトリックに適用可能な情報リソース機能の観点から指定されています。ALTOコストカレンダーは、JSONアレイでALTOコスト値を公開し、各値は指定された時間間隔に対応する[RFC8259]を参照してください。ALTOクライアントが受信されたALTO値を解釈できるように、Information Resourcesディレクトリ(IRD)およびサーバーの応答には、時間間隔、およびその他のカレンダー属性が指定されています。最後に、ALTOカレンダーの拡張はどのコストモードにも適用され、レガシーALTOクライアントとの下位互換性を保証します - [RFC7285]をサポートするだけです。

In the rest of this document, Section 3 provides the design characteristics. Sections 4 and 5 define the formal specifications for the IRD and the information resources. IANA, security considerations, and operational considerations are addressed respectively in Sections 6, 7, and 8.


1.1. Some Recent Known Uses
1.1. いくつかの最近の知られている用途

A potential use case is implementing smart network services that allow applications to dynamically build end-to-end, virtual networks to satisfy given demands with no manual intervention. For example, data-transfer automation applications may need a network service to determine the availability of bandwidth resources to decide when to transfer their data sets. The SENSE project [SENSE] supports such applications by requiring that a network provides services such as the Time-Bandwidth-Product (TBP) service, which informs applications of bandwidth availability during a specific time period. ALTO Calendars can support this service if the Calendar start date and duration cover the period of interest of the requesting application.

潜在的なユースケースは、取扱説明書を手動の介入なしに満足するために、アプリケーションがエンドツーエンドの仮想ネットワークを動的に構築することを可能にするスマートネットワークサービスを実装しています。例えば、データ転送自動化アプリケーションは、データセットを転送するときを決定するための帯域幅リソースの可用性を決定するためにネットワークサービスを必要とするかもしれない。Sense Project [Sense]は、ネットワークがタイムバンド幅 - 製品(TBP)サービスなどのサービスを提供することで、そのようなアプリケーションをサポートしています。これは、特定の期間中に帯域幅の可用性の応用を提供する。カレンダー開始日と期間が要求側アプリケーションの関心のある期間をカバーする場合、Altoカレンダーはこのサービスをサポートできます。

The need of future scheduling of large-scale traffic that can be addressed by the ALTO protocol is also motivated by Unicorn, a unified resource orchestration framework for multi-domain, geo-distributed data analytics, see [UNICORN-FGCS].


1.2. Terminology
1.2. 用語

ALTO transaction: A request/response exchange between an ALTO Client and an ALTO Server.


Client: When used with a capital "C", this term refers to an ALTO Client.


Calendar, Cost Calendar, ALTO Calendar: When used with capitalized words, these terms refer to an ALTO Cost Calendar.


Calendared: This adjective qualifies information resources providing Cost Calendars and information on costs that are provided in the form of a Cost Calendar.


Endpoint (EP): An endpoint is defined as in Section 2.1 of [RFC7285]. It can be, for example, a peer, a CDN storage location, a physical server involved in a virtual server-supported application, a party in a resource-sharing swarm such as a computation grid, or an online multi-party game.


ECM: An abbreviation for Endpoint Cost Map.


FCM: An abbreviation for Filtered Cost Map.


Server: When used with a capital "S", this term refers to an ALTO Server.


2. Requirements Language
2. 要件言語

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.

「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。

When the words appear in lower case, they are to be interpreted with their natural language meanings.


3. Overview of ALTO Cost Calendars and Terminology
3. アルトコストカレンダーと用語の概要

This section gives a high-level overview of the design. It assumes the reader is familiar with the ALTO protocol [RFC7285] and its Multi-Cost ALTO extension [RFC8189].


3.1. ALTO Cost Calendar Overview
3.1. アルトコストカレンダーの概要

An ALTO Cost Calendar provided by the ALTO Server provides 2 information items:

Alto Serverによって提供されるALTOコストカレンダーは、2つの情報項目を提供します。

* an array of values for a given metric, where each value specifies the metric corresponding to a time interval, where the value array can sometimes be a cyclic pattern that repeats a certain number of times and

* 与えられたメトリックの値の配列。各値は時間間隔に対応するメトリックを指定します。ここで、値配列は一定回数を繰り返す周期パターンになることがあります。

* attributes describing the time scope of the Calendar, including the size and number of the intervals and the date of the starting point of the Calendar, allowing an ALTO Client to interpret the values properly.

* ターゲットの時間範囲を記述する属性は、区間のサイズと数を含むカレンダーの始点とカレンダーの開始点の日付を含む属性で、ALTOクライアントが値を正しく解釈できるようにします。

An ALTO Cost Calendar can be used like a "time table" to figure out the best time to schedule data transfers and also to proactively manage application traffic given predictable events, such as an expected spike in traffic due to crowd gathering (concerts, sports, etc.), traffic-intensive holidays, and network maintenance. A Calendar may be viewed as a synthetic abstraction of, for example, real measurements gathered over previous periods on which statistics have been computed. However, like for any schedule, unexpected network incidents may require the current ALTO Calendar to be updated and resent to the ALTO Clients needing it. The "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service [RFC8895] can be used to directly update the Calendar upon value changes if supported by both the Server and the Client.

Alto Costカレンダーは、データ転送をスケジュールするための最良の時間を把握するための最良の時間を把握することができ、また、群衆の集まり(コンサート、スポーツ、スポーツ、スポーツ、など)、交通集約祝日、およびネットワークメンテナンス。カレンダーは、例えば、統計が計算された以前の期間にわたって収集された実測値の合成抽象化と見なすことができる。ただし、スケジュールのように、予期しないネットワークインシデントには現在のALTOカレンダーを更新し、必要なALTOクライアントに再送信する必要があります。「サーバー送信イベント(SSE)」サービス[RFC8895]を使用すると、サーバーとクライアントの両方でサポートされている場合は、値の変更時にカレンダーを直接更新できます。

Most likely, the ALTO Cost Calendar would be used for the Endpoint Cost Service, assuming that a limited set of feasible endpoints for a non-real time application is already identified, and that those endpoints do not need to be accessed immediately and that their access can be scheduled within a given time period. The Filtered Cost Map Service is also applicable as long as the size of the Map allows it.


3.2. ALTO Cost Calendar Information Features
3.2. アルトコストカレンダー情報の特徴

The Calendar attributes are provided in the Information Resources Directory (IRD) and in ALTO Server responses. The IRD announces attributes without date values in its information resources capabilities, whereas attributes with time-dependent values are provided in the "meta" section of Server responses. The ALTO Cost Calendar attributes provide the following information:


* attributes to describe the time scope of the Calendar value array:

* カレンダー値配列の時間範囲を記述する属性:

- "time-interval-size": the applicable time interval size for each Calendar value, defined in seconds, that can cover a wide range of values.

- "time-interval-size":秒単位で定義された各カレンダー値の適用可能時間間隔サイズは、広範囲の値をカバーできます。

- "number-of-intervals": the number of intervals provided in the Calendar.

- 「間隔」:カレンダーに提供されている間隔の数。

* "calendar-start-time": specifying when the Calendar starts; that is, to which date the first value of the Cost Calendar is applicable.

* "calendar-start-time":カレンダーが起動したときの指定。すなわち、どの日付は原価カレンダの第1の値が適用可能である。

* "repeated": an optional attribute indicating how many iterations of the provided Calendar will have the same values. The Server may use it to allow the Client to schedule its next request and thus save its own workload by reducing processing of similar requests.

* 「繰り返し」:提供されたカレンダーの繰り返しの数を示すオプションの属性が同じ値を持つことを示します。サーバは、クライアントがその次の要求をスケジュールすることを可能にし、したがって同様の要求の処理を減らすことによってそれ自身の作業負荷を保存することを可能にし得る。

Attribute "repeated" may take a very high value if a Calendar represents a cyclic value pattern that the Server considers valid for a long period. In this case, the Server will only update the Calendar values once this period has elapsed or if an unexpected event occurs on the network. See Section 8 for more discussion.

属性 "繰り返し"カレンダーがサーバーが長期間にわたって有効になると考える巡回値パターンを表す場合、非常に高い値を取ります。この場合、サーバーは、この期間が経過した後、またはネットワーク上で予期しないイベントが発生した場合にのみカレンダー値を更新します。詳細についてはセクション8を参照してください。

3.3. ALTO Calendar Design Characteristics
3.3. アルトカレンダーデザイン特性

The present document uses the notations defined in "Notation" (Section 8.2 of [RFC7285]).


The extensions in this document encode requests and responses using JSON [RFC8259].

この文書の拡張機能は、JSON [RFC8259]を使用して要求と応答をエンコードします。

In the base protocol [RFC7285], an ALTO cost is specified as a generic JSONValue [RFC8259] to allow extensions. However, that section (Section of [RFC7285]) states:

基本プロトコル[RFC7285]では、ALTO COSTが一般的なJSONVALUE [RFC8259]として指定されています。ただし、そのセクション([RFC7285]の11.2.3.6項)は次のように述べています。

   |  An implementation of the protocol in this document SHOULD assume
   |  that the cost is a JSONNumber and fail to parse if it is not,
   |  unless the implementation is using an extension to this document
   |  that indicates when and how costs of other data types are
   |  signaled.

The present document extends the definition of a legacy cost map given in [RFC7285] to allow a cost entry to be an array of values, with one value per time interval, instead of being just one number, when the Cost Calendar functionality is activated on this cost. Therefore, the implementor of this extension MUST consider that a cost entry is an array of values if this cost has been queried as a Calendar.


Specifically, an implementation of this extension MUST parse the "number-of-intervals" attribute of the Calendar attributes in an IRD entry announcing a service providing a Cost Calendar for a given cost type. The implementation then will know that a cost entry of the service will be an array of values, and the expected size of the array is that specified by the "number-of-intervals" attribute. The following rules attempt to ensure consistency between the array size announced by the Server and the actual size of the array received by the Client:


* The size of the array of values conveyed in a Cost Calendar and received by the Client MUST be equal to the value of attribute "number-of-intervals" indicated in the IRD for the requested cost type.

* コストカレンダーで伝達され、クライアントによって受信された値の配列のサイズは、要求されたコストタイプのIRDに示されている属性「間隔」の値に等しくなければなりません。

* When the size of the array received by the Client is different from the expected size, the Client SHOULD ignore the received array.

* クライアントによって受信された配列のサイズが予想サイズと異なる場合、クライアントは受信した配列を無視してください。

To realize an ALTO Calendar, this document extends the IRD and the ALTO requests and responses for Cost Calendars.


This extension is designed to be lightweight and to ensure backwards compatibility with base protocol ALTO Clients and with other extensions. It relies on "Parsing of Unknown Fields" (Section 8.3.7 of [RFC7285]), which states: "Extensions may include additional fields within JSON objects defined in this document. ALTO implementations MUST ignore unknown fields when processing ALTO messages."

この拡張機能は、軽量であり、基本プロトコルALTOクライアントと他の拡張機能との互換性を確保するように設計されています。「未知のフィールドの解析」([RFC7285]のセクション8.3.7)に依存しています。 "拡張子はこのドキュメントで定義されているJSONオブジェクト内の追加のフィールドを含めることができます。ALTO実装は、ALTOメッセージを処理するときに未知のフィールドを無視する必要があります。

The Calendar-specific capabilities are integrated in the information resources of the IRD and in the "meta" member of ALTO responses to Cost Calendars requests. A Calendar and its capabilities are associated with a given information resource and within this information resource with a given cost type. This design has several advantages:


* it does not introduce a new mode,

* 新しいモードを導入していません。

* it does not introduce new media types, and

* 新しいメディアタイプを導入していません

* it allows an ALTO Server to offer, for a cost type, different Calendars with attributes that are specific to the information resources providing a Calendar for this cost type, instead of being globally specific to the cost type.

* これにより、Alto Serverは、コストタイプのための属性と異なるカレンダーが、このコストタイプのカレンダーを提供する属性を持つ異なるカレンダーを、コストタイプにグローバルに固有のものではなく)を提供します。

The applicable Calendared information resources are:


* the Filtered Cost Map and

* フィルタリングされたコストマップと

* the Endpoint Cost Map.

* エンドポイントコストマップ

The ALTO Server can choose in which frequency it provides cost Calendars to ALTO Clients. It may either provide Calendar updates starting at the request date or carefully schedule its updates so as to take profit from a potential repetition/periodicity of Calendar values.


Since Calendar attributes are specific to an information resource, a Server may adapt the granularity of the calendared information so as to moderate the volume of exchanged data. For example, suppose a Server provides a Calendar for cost type name "routingcost". The Server may offer a Calendar in a Cost Map resource, which may be a voluminous resource, as an array of 6 intervals lasting each 4 hours. It may also offer a Calendar in an Endpoint Cost Map resource, which is potentially less voluminous, as a finer-grained array of 24 intervals lasting 1 hour each.

カレンダ属性は情報リソースに固有のものであるため、サーバは交換されたデータの量を中断するようにカレンダー情報の粒度を適応させることができる。たとえば、サーバーがコストタイプ名 "routingcost"のカレンダーを提供するとします。サーバはコストマップリソースでカレンダーを提供することができ、これは4時間の6時間続く6つの間隔の配列として、膨大なリソースであり得る。それはまた、それぞれ1時間続く24の間隔のより細かい粒度のアレイとして、潜在的に膨大ではないエンドポイントコストマップリソースにカレンダーを提供することができる。

The ALTO Server does not support constraints on Calendars, provided Calendars are requested for numerical values, for two main reasons:


* Constraints on an array of values may be various. For instance, some Clients may refuse Calendars with one single value violating a constraint, whereas other ones may tolerate Calendars with values violating constraints, for example, at given times. Therefore, expressing constraints in a way that covers all possible Client preferences is challenging.

* 値の配列に対する制約は様々であり得る。たとえば、一部のクライアントは、制約に違反する1つの値でカレンダーを拒否することができますが、他のものは、たとえば制約に違反している値でカレンダーを許容することがあります。したがって、すべての可能なクライアント設定をカバーするような方法で制約を表現することは困難です。

* If constraints were to be supported, the processing overhead would be substantial for the Server as it would have to parse all the values of the Calendar array before returning a response.

* 制約がサポートされることになっている場合、処理のオーバーヘッドは、応答を返す前にカレンダー配列のすべての値を解析する必要があるため、サーバーにとってはかなりのものになります。

As providing the constraint functionality in conjunction with the Calendar functionality is not feasible for the reasons described above, the two features are mutually exclusive. The absence of constraints on Filtered Cost Map and Endpoint Cost Map Calendars reflects a divergence from the non-calendared information resources defined in [RFC7285] and extended in [RFC8189], which support optional constraints.


3.3.1. ALTO Cost Calendar for All Cost Modes
3.3.1. すべてのコストモードのためのアルトコストカレンダー

An ALTO Cost Calendar is well suited for values encoded in the "numerical" mode. Actually, a Calendar can also represent metrics in other modes considered as compatible with time-varying values. For example, types of cost values (such as JSONBool) can also be calendared (as their value may be 'true' or 'false' depending on given time periods or likewise) values represented by strings, such as "medium", "high", "low", "blue", and "open".

ALTOコストカレンダーは、「数値」モードで符号化された値に適している。実際には、カレンダーは、時変数と互換性があると考えられる他のモードのメトリックを表すこともできます。たとえば、コスト値の種類(JSONBOOLなど)をカレンダー化することもできます(それらの値が与えられた期間または同様に、または「媒体」、 "medium"などの文字列によって表される値に応じて 'false'である可能性がある)「、「低」、「青」、「開く」。

Note also that a Calendar is suitable as well for time-varying metrics provided in the "ordinal" mode if these values are time-varying and the ALTO Server provides updates of cost-value-based preferences.


3.3.2. Compatibility with Legacy ALTO Clients
3.3.2. レガシーALTOクライアントとの互換性

The ALTO protocol extensions for Cost Calendars have been defined so as to ensure that Calendar-capable ALTO Servers can provide legacy ALTO Clients with legacy information resources as well. That is, a legacy ALTO Client can request resources and receive responses as specified in [RFC7285].


A Calendar-aware ALTO Server MUST implement the base protocol specified in [RFC7285].


A Calendar-aware ALTO Client MUST implement the base protocol specified in [RFC7285].


As a consequence, when a metric is available as a Calendar array, it also MUST be available as a single value, as required by [RFC7285]. The Server, in this case, provides the current value of the metric to either Calendar-aware Clients not interested in future or time-based values or Clients implementing [RFC7285] only.


For compatibility with legacy ALTO Clients specified in [RFC7285], calendared information resources are not applicable for full cost maps for the following reason: a legacy ALTO Client would receive a calendared cost map via an HTTP 'GET' command. As specified in Section 8.3.7 of [RFC7285], it will ignore the Calendar attributes indicated in the "meta" of the responses. Therefore, lacking information on Calendar attributes, it will not be able to correctly interpret and process the values of the received array of Calendar cost values.

[RFC7285]で指定されたレガシーALTOクライアントとの互換性のために、カレンダーの情報リソースは次の理由でフルコストマップに適用されません.Regacy Altoクライアントは、HTTP 'get'コマンドを介してカレンダーコストマップを受信します。[RFC7285]の8.3.7項で指定されているように、応答の「メタ」に示されているカレンダー属性を無視します。したがって、カレンダー属性に関する情報を欠いているため、受信したカレンダーコスト値の配列の値を正しく解釈して処理することはできません。

Therefore, calendared information resources MUST be requested via the Filtered Cost Map Service or the Endpoint Cost Service using a POST method.


4. ALTO Calendar Specification: IRD Extensions
4. アルトカレンダー仕様:IRD Extensions.

The Calendar attributes in the IRD information resources capabilities carry dateless values. A Calendar is associated with an information resource rather than a cost type. For example, a Server can provide a "routingcost" Calendar for the Filtered Cost Map Service at a granularity of one day and a "routingcost" Calendar for the Endpoint Cost Service at a finer granularity but for a limited number of endpoints. An example IRD with Calendar-specific features is provided in Section 4.3.


4.1. Calendar Attributes in the IRD Resource Capabilities
4.1. IRDリソース機能のカレンダー属性

A Cost Calendar for a given cost type MUST be indicated in the IRD by an object of type CalendarAttributes. A CalendarAttributes object is represented by the "calendar-attributes" member of a resource entry. Member "calendar-attributes" is an array of CalendarAttributes objects. Each CalendarAttributes object lists a set of one or more cost types it applies to. A cost type name MUST NOT appear more than once in the "calendar-attributes" member of a resource entry; multiple appearances of a cost type name in the CalendarAttributes object of the "calendar-attributes" member MUST cause the ALTO Client to ignore any occurrences of this name beyond the first encountered occurrence. The Client SHOULD consider the CalendarAttributes object in the array containing the first encountered occurrence of a cost type as the valid one for this cost type. As an alternative, the Client may want to avoid the risks of erroneous guidance associated to the use of potentially invalid Calendar values. In this case, the Client MAY ignore the totality of occurrences of CalendarAttributes objects containing the cost type name and query the cost type using [RFC7285].

指定されたコストタイプのコストカレンダーは、CalendarAttributes型のオブジェクトによってIRDに表示されなければなりません。 CalendarAttributesオブジェクトは、リソースエントリの「calendar-attributes」メンバによって表されます。メンバー「calendar-attributes」は、CalendarAttributesオブジェクトの配列です。各CalendarAttributesオブジェクトには、適用される1つ以上のコストタイプのセットが一覧表示されます。コストタイプ名は、リソースエントリの「calendar-attributes」メンバに複数回表示されてはいけません。 「calendar-attributes」メンバーのCalendarAttributesオブジェクトのコストタイプ名の複数の外観は、ALTOクライアントに最初の遭遇したオカレンスを超えてこの名前の発生を無視するようにする必要があります。クライアントは、このコストタイプの有効なコストタイプの最初の発生の発生を含む配列内のCalendarAttributesオブジェクトを検討する必要があります。代替として、クライアントは、潜在的に無効なカレンダー値の使用に関連する誤った案内のリスクを回避することを望むかもしれない。この場合、クライアントは、コストタイプ名を含むCalendarAttributesオブジェクトの発生全体を無視し、[RFC7285]を使用してコストタイプを照会することができます。

The encoding format for object CalendarAttributes using JSON [RFC8259] is as follows:

JSON [RFC8259]を使用したオブジェクトCalendarAttributesのエンコード形式は次のとおりです。

   CalendarAttributes calendar-attributes <1..*>;
     JSONString cost-type-names <1..*>;
     JSONNumber time-interval-size;
     JSONNumber number-of-intervals;
   } CalendarAttributes;

"cost-type-names": An array of one or more elements indicating the cost type names in the IRD entry to which the values of "time-interval-size" and "number-of-intervals" apply.


"time-interval-size": The duration of an ALTO Calendar time interval in a unit of seconds. A "time-interval-size" value contains a non-negative JSONNumber. Example values are 300 and 7200, meaning that each Calendar value applies on a time interval that lasts 5 minutes and 2 hours, respectively. Since an interval size (e.g., 100 ms) can be smaller than the unit, the value specified may be a floating point (e.g., 0.1). Both ALTO Clients and Servers should be aware of potential precision issues caused by using floating point numbers; for example, the floating number 0.1 cannot be represented precisely using a finite number of binary bits. To improve interoperability and be consistent with [RFC7285] on the use of floating point numbers, the Server and the Client SHOULD use IEEE 754 double-precision floating point [IEEE.754.2019] to store this value.

"time-interval-size":Altoカレンダー時間間隔の単位単位の時間。「time-interval-size」値には、否定的なJSONNUMBERが含まれています。例の値は300と7200です。つまり、各カレンダー値は、それぞれ5分と2時間続く時間間隔に適用されます。間隔サイズ(例えば100ms)は単位よりも小さくすることができるので、指定された値は浮動小数点(例えば、0.1)であり得る。Altoクライアントとサーバーの両方を浮動小数点数を使用することによって引き起こされる潜在的な精度の問題を認識する必要があります。例えば、浮動数0.1は、有限数の2値ビットを使用して正確に表すことはできない。浮動小数点数を使用すると、相互運用性を向上させ、[RFC7285]と一致するために、サーバーとクライアントはこの値を格納するためにIEEE 754倍精度浮動小数点[IEEE.754.2019]を使用する必要があります。

"number-of-intervals": A strictly positive integer (greater or equal to 1) that indicates the number of values of the Cost Calendar array.


* An ALTO Server SHOULD specify the "time-interval-size" in the IRD as the smallest it is able to provide. A Client that needs a longer interval can aggregate multiple cost values to obtain it.

* ALTOサーバーは、IRDの「時間間隔サイズ」を指定できるようにする必要があります。長い間隔を必要とするクライアントは、それを取得するために複数のコスト値を集約できます。

* Attribute "cost-type-names" is associated with "time-interval-size" and "number-of-intervals", because multiple cost types may share the same values for attributes "time-interval-size" and "number-of-intervals". To avoid redundancies, cost type names sharing the same values for "time-interval-size" and "number-of-intervals" are grouped in the "cost-type-names" attribute. In the example IRD provided in Section 4.3, the information resource "filtered-cost-map-calendar" provides a Calendar for cost type names "num-routingcost", "num-throughputrating", and "string-servicestatus". Cost type names "num-routingcost" and "num-throughputrating" are grouped in the "cost-type-names" attribute because they share the same values for "time-interval-size" and "number-of-intervals", which are respectively 7200 and 12.

* 属性 "費用タイプ名"は、複数のコストタイプが属性 "time-interval-size"と "数字に共有することができるため、" time-interval-size "と" interval数 "に関連付けられています。 - インターバルス」冗長性を避けるために、「時間間隔サイズ」および「間隔」の同じ値を共有するコストタイプ名は、「コストタイプ名」属性にまとめられています。4.3節で提供されるIRDの例では、情報リソース「フィルタコストマップカレンダー」は、コストタイプ名「NUM-ROUTINGCOST」、「NUM-SERSUPERATION」、「STRING-ServiceStatus」のカレンダーを提供します。コストタイプ名「NUM-ROUTINGCOST」と「NUM-SPENPUTATION」は、「時間間隔サイズ」と「間隔枚数」に同じ値を共有するため、「コストタイプ名」属性にグループ化されています。それぞれ7200と12です。

* Multiplying "time-interval-size" by "number-of-intervals" provides the duration of the provided Calendar. For example, an ALTO Server may provide a Calendar for ALTO values changing every "time-interval-size" equal to 5 minutes. If "number-of-intervals" has the value 12, then the duration of the provided Calendar is 1 hour.

* 「時間間隔サイズ」を「間隔で」掛けると、提供されたカレンダの期間が提供されます。例えば、ALTOサーバは、5分に等しい「時間間隔サイズ」を変更するALTO値のカレンダーを提供することができる。「間隔」が値12を有する場合、提供されたカレンダの持続時間は1時間である。

4.2. Calendars in a Delegate IRD
4.2. デリゲートIRDのカレンダー

It may be useful to distinguish IRD resources supported by the base ALTO protocol from resources supported by its extensions. To achieve this, one option is that a "root" ALTO Server implementing [RFC7285] resources and running at a given domain delegates "specialized" information resources, such as the ones providing Cost Calendars, to another ALTO Server running in a subdomain. The "root" ALTO Server can provide a Calendar-specific resource entry that has a media-type of "application/alto-directory+json" and that specifies the URI allowing to retrieve the location of a Calendar-aware Server and discover its resources. This option is described in "Delegation Using IRD" (Section 9.2.4 of [RFC7285]).

ベースALTOプロトコルによってサポートされているIRDリソースをその拡張によってサポートされているリソースから区別することは有用であり得る。これを達成するために、1つのオプションは、[RFC7285]リソースを実装し、所与のドメインの委任の「特殊な」情報リソースを、サブドメイン内で実行されている別のALTOサーバに専門的な情報リソースを委任します。「ルート」ALTOサーバは、メディアタイプの「application / alto-directory JSON」を持つカレンダー固有のリソースエントリを提供し、カレンダー対応サーバーの場所を取得してそのリソースを検出することを可能にするURIを指定できます。このオプションは「IRDを使用した委任」([RFC7285]のセクション9.2.4)で説明されています。

This document provides an example where a "root" ALTO Server runs in a domain called "". It delegates the announcement of Calendars capabilities to an ALTO Server running in a subdomain called "". The location of the "delegate Calendar IRD" is assumed to be indicated in the "root" IRD by the resource entry: "custom-calendared-resources".

このドキュメントでは、 "root" ALTOサーバが ""というドメイン内で実行される例を示します。カレンダー機能の発表を「」と呼ばれるサブドメインで実行されているALTOサーバーに委任します。「代理カレンダーIRD」の場所は、リソースエントリによって「root」IRDに表示されていると見なされます。 "Custom-Calendared-Resources"。

Another benefit of delegation is that some cost types for some resources may be more advantageous as Cost Calendars, and it makes little sense to get them as a single value. For example, if a cost type has predictable and frequently changing values calendared in short time intervals, such as a minute, it saves time and network resources to track the cost values via a focused delegate Server rather than the more general "root" Server.


4.3. Example IRD with ALTO Cost Calendars
4.3. アルトコストカレンダーを備えたIRDの例

This section provides an example ALTO Server IRD that supports various cost metrics and cost modes. In particular, since [RFC7285] makes it mandatory, the Server uses metric "routingcost" in the "numerical" mode.

このセクションでは、さまざまなコストメトリクスとコストモードをサポートするALTOサーバーIRDの例を示します。特に、[RFC7285]が必須になるため、サーバーは「数値」モードでメトリック "routingcost"を使用しています。

For illustrative purposes, this section introduces 3 other fictitious example metrics and modes that should be understood as examples and should not be used or considered as normative.


The cost type names used in the example IRD are as follows:


"num-routingcost": Refers to metric "routingcost" in the numerical mode, as defined in [RFC7285] and registered with IANA.

"Num-RoutingCost":[RFC7285]で定義されているように、数値モードのメトリック "routingcost"を参照してIANAに登録されます。

"num-owdelay": Refers to fictitious performance metric "owdelay" in the "numerical" mode to reflect the one-way packet transmission delay on a path. A related performance metric is currently under definition in [ALTO_METRICS].


"num-throughputrating": Refers to fictitious metric "throughputrating" in the "numerical" mode to reflect the provider preference in terms of end-to-end throughput.


"string-servicestatus": Refers to fictitious metric "servicestatus" containing a string to reflect the availability, defined by the provider, of, for instance, path connectivity.

"string-serviceStatus":プロバイダによって定義された、例えばPath Connectivityの可用性を反映するための文字列を含む架空のメトリック "serviceStatus"を参照します。

The example IRD includes 2 particular URIs providing Calendars:


      A Filtered Cost Map in which Calendar capabilities are indicated
      for cost type names "num-routingcost", "num-throughputrating", and
      "string-servicestatus" and

"": An Endpoint Cost Map in which Calendar capabilities are indicated for cost type names "num-routingcost", "num-owdelay", "num-throughputrating", and "string-servicestatus".

"":カレンダー機能がコストタイプ名 "num-routingcost"、 "num-rowdelay"、 "num-supraphetratingのためのエンドポイントコストマップです。"、および" string-serviceStatus "。

The design of the Calendar capabilities allows some Calendars with the same cost type name to be available in several information resources with different Calendar attributes. This is the case for Calendars on "num-routingcost", "num-throughputrating", and "string-servicestatus", available in both the Filtered Cost Map and Endpoint Cost Service but with different time interval sizes for "num-throughputrating" and "string-servicestatus".


   --- Client to Server request for IRD ----------
   GET /calendars-directory HTTP/1.1
   Accept: application/alto-directory+json,application/alto-error+json
   --- Server response to Client -----------------
   HTTP/1.1 200 OK
   Content-Length: 2622
   Content-Type: application/alto-directory+json
     "meta" : {
       "default-alto-network-map" : "my-default-network-map",
       "cost-types": {
         "num-routingcost": {
           "cost-mode" : "numerical",
           "cost-metric" : "routingcost"
         "num-owdelay": {
           "cost-mode"  : "numerical",
           "cost-metric": "owdelay"
         "num-throughputrating": {
           "cost-mode"  : "numerical",
           "cost-metric": "throughputrating"
         "string-servicestatus": {
           "cost-mode"  : "string",
           "cost-metric": "servicestatus"
     "resources" : {
       "filtered-cost-map-calendar" : {
         "uri" :
         "media-type" : "application/alto-costmap+json",
         "accepts" : "application/alto-costmapfilter+json",
         "capabilities" : {
           "cost-constraints" : true,
           "cost-type-names"  : [ "num-routingcost",
                                  "string-servicestatus" ],
           "calendar-attributes" : [
             {"cost-type-names" : [ "num-routingcost",
                                    "num-throughputrating" ],
              "time-interval-size" : 7200,
              "number-of-intervals" : 12
             {"cost-type-names" : [ "string-servicestatus" ],
              "time-interval-size" : 1800,
              "number-of-intervals" : 48
         "uses": [ "my-default-network-map" ]
       "endpoint-cost-map-calendar" : {
         "uri" :
         "media-type" : "application/alto-endpointcost+json",
         "accepts" : "application/alto-endpointcostparams+json",
         "capabilities" : {
           "cost-constraints" : true,
           "cost-type-names" : [ "num-routingcost",
                                 "string-servicestatus" ],
           "calendar-attributes" : [
             {"cost-type-names" : [ "num-routingcost" ],
              "time-interval-size" : 3600,
              "number-of-intervals" : 24
             {"cost-type-names" : [ "num-owdelay" ],
              "time-interval-size" : 300,
              "number-of-intervals" : 12
             {"cost-type-names" : [ "num-throughputrating" ],
              "time-interval-size" : 60,
              "number-of-intervals" : 60
             {"cost-type-names" : [ "string-servicestatus" ],
              "time-interval-size" : 120,
              "number-of-intervals" : 30

In this example IRD, for the Filtered Cost Map Service:


* the Calendar for "num-routingcost" and "num-throughputrating" is an array of 12 values, each provided on a time interval lasting 7200 seconds (2 hours) and

* "num-routingcost"と "num-stral retation"のカレンダーは、7200秒(2時間)続く時間間隔で提供された12の値の配列です。

* the Calendar for "string-servicestatus" is an array of 48 values, each provided on a time interval lasting 1800 seconds (30 minutes).

* "string-serviceStatus"のカレンダーは48の値の配列です。それぞれ1800秒(30分)の時間間隔で提供されます。

For the Endpoint Cost Service:


* the Calendar for "num-routingcost" is an array of 24 values, each provided on a time interval lasting 3600 seconds (1 hour),

* "num-routingcost"のカレンダーは、3600秒(1時間)の時間間隔で提供されている24の値の配列です。

* the Calendar for "num-owdelay" is an array of 12 values, each provided on a time interval lasting 300 seconds (5 minutes),

* "num-owdelay"のカレンダーは12の値の配列です。

* the Calendar for "num-throughputrating" is an array of 60 values, each provided on a time interval lasting 60 seconds (1 minute), and

* 「numスループット化」のカレンダーは、60秒(1分)の時間間隔で提供されている60の値の配列です。

* the Calendar for "string-servicestatus" is an array of 30 values, each provided on a time interval lasting 120 seconds (2 minutes).

* "string-serviceStatus"のカレンダーは30の値の配列です。それぞれ120秒間持続している時間間隔(2分)です。

Note that in this example IRD, member "cost-constraints" is present with a value set to "true" in both information resources "filtered-cost-map-calendar" and "endpoint-cost-map-calendar". Although a Calendar-aware ALTO Server does not support constraints for the reasons explained in Section 3.3, it MUST support constraints on cost types that are not requested as Calendars but are requested as specified in [RFC7285] and [RFC8189].

この例では、IRDの例では、情報リソース「フィルタリングコストマップ - カレンダー」と「エンドポイントコストマップカレンダー」の両方で「TRUE」に設定されている値が存在します。カレンダー対応のALTOサーバはセクション3.3で説明されている理由についての制約をサポートしていませんが、カレンダーとして要求されていないが[RFC7285]と[RFC8189]で指定されている原価タイプの制約をサポートしている必要があります。

5. ALTO Calendar Specification: Service Information Resources
5. アルトカレンダー仕様:サービス情報リソース

This section documents extensions to two basic ALTO information resources (Filtered Cost Maps and Endpoint Cost Service) to provide calendared information services for them.


Both extensions return calendar start time (calendar-start-time, a point in time), which MUST be specified as an HTTP "Date" header field using the IMF-fixdate format specified in Section of [RFC7231]. Note that the IMF-fixdate format uses "GMT", not "UTC", to designate the time zone, as in this example:

両方の拡張子はカレンダーの開始時刻(calendar-start-time、時点)を返します。[RFC7231]のセクション7.1.1.1のセクション7.1.1.1で指定されているIMF-FixDate形式を使用して、HTTP "日付"ヘッダーフィールドとして指定する必要があります。この例のように、IMF-FixDateフォーマットは "utc"ではなく "GMT"を使ってタイムゾーンを指定します。

                    Date: Tue, 15 Nov 2019 08:12:31 GMT
5.1. Calendar Extensions for Filtered Cost Maps (FCM)
5.1. フィルタリングコストマップのカレンダー拡張(FCM)

A legacy ALTO Client requests and gets Filtered Cost Map responses, as specified in [RFC7285].


5.1.1. Calendar Extensions in Filtered Cost Map Requests
5.1.1. フィルタ処理されたコストマップ要求におけるカレンダー拡張

The input parameters of a "legacy" request for a Filtered Cost Map, defined by object ReqFilteredCostMap in Section 11.3.2 of [RFC7285], are augmented with one additional member. The same augmentation applies to object ReqFilteredCostMap defined in Section 4.1.2 of [RFC8189].

[RFC7285]のセクション11.3.2のObject ReqFilteredCostMapによって定義されたフィルタリングされたコストマップの「レガシー」要求の入力パラメータは、追加のメンバーで拡張されます。同じ増大は、[RFC8189]のセクション4.1.2で定義されているObject ReqFilteredCostMapに適用されます。

A Calendar-aware ALTO Client requesting a Calendar on a given cost type for a Filtered Cost Map resource having Calendar capabilities MUST add the following field to its input parameters:

カレンダのコストマップリソースのカレンダーを要求するカレンダーALTO ALTOクライアントは、カレンダー機能を持つカレンダー・コスト・マップ・リソースを入力パラメーターに次のフィールドを追加する必要があります。

                          JSONBoolean calendared<1..*>;

This field is an array of 1 to N boolean values, where N is the number of requested metrics. N is greater than 1 when the Client and the Server also implement [RFC8189].


Each entry corresponds to the requested metric at the same array position. Each boolean value indicates whether or not the ALTO Server should provide the values for this cost type as a Calendar. The array MUST contain exactly N boolean values, otherwise, the Server returns an error.


This field MUST NOT be included if no member "calendar-attributes" is specified in this information resource.


If a value of field "calendared" is 'true' for a cost type name for which no Calendar attributes have been specified, an ALTO Server, whether it implements the extensions of this document or only implements [RFC7285], MUST ignore it and return a response with a single cost value, as specified in [RFC7285].


If this field is not present, it MUST be assumed to have only values equal to 'false'.

このフィールドが存在しない場合は、 'false'に等しい値のみがあると仮定する必要があります。

A Calendar-aware ALTO Client that supports requests for only one cost type at a time and wants to request a Calendar MUST provide an array of 1 element:


"calendared" : [true],


A Calendar-aware ALTO Client that supports requests for more than one cost type at a time, as specified in [RFC8189], MUST provide an array of N values set to 'true' or 'false', depending whether it wants the applicable cost type values as a single or calendared value.

[RFC8189]で指定されているように、1回以上のコストタイプの要求をサポートするカレンダーALTO ALTOクライアントは、適切なコストを望むかどうかに応じて、「true」または「false」に設定されているN値の配列を指定する必要があります。単一またはカレンダー値として値を入力します。

5.1.2. Calendar Extensions in Filtered Cost Map Responses
5.1.2. フィルタリングコストマップ応答におけるカレンダー拡張

In a calendared ALTO Filtered Cost Map, a cost value between a source and a destination is a JSON array of JSON values. An ALTO Calendar values array has a number of values equal to the value of member "number-of-intervals" of the Calendar attributes that are indicated in the IRD. These attributes will be conveyed as metadata in the Filtered Cost Map response. Each element of the array is valid for the time interval that matches its array position.


The FCM response conveys metadata, among which:


* some are not specific to Calendars and ensure compatibility with [RFC7285] and [RFC8189] and

* いくつかはカレンダーに固有のものではなく、[RFC7285]と[RFC8189]との互換性を保証します。

* some are specific to Calendars.

* いくつかはカレンダーに固有のものです。

The non-Calendar-specific "meta" fields of a calendared Filtered Cost Map response MUST include at least:


* if the ALTO Client requests cost values for one cost type at a time, only the "meta" fields specified in [RFC7285] for these information service responses:

* ALTOクライアントが一度に1コストタイプのコスト値を要求した場合は、[RFC7285]で指定された[Meta]フィールドのみがこれらの情報サービスの応答に対して指定されています。

- "dependent-vtags" and

- 「依存vTAG」および

- "cost-type" field.

- 「コストタイプ」フィールド。

* if the ALTO Client implements the Multi-Cost ALTO extension specified in [RFC8189] and requests cost values for several cost types at a time, the "meta" fields specified in [RFC8189] for these information service responses:

* ALTOクライアントが[RFC8189]で指定されたマルチコストALTO拡張を実装し、一度に複数のコストタイプのコスト値を要求する場合は、[RFC8189]で指定された「メタ」フィールドをこれらの情報処理応答に指定します。

- "dependent-vtags",

- 「依存vTAG」、

- "cost-type" field with value set to '{}', for backwards compatibility with [RFC7285], and

- [RFC7285]との下位互換性のために、値を持つ "費用タイプ"フィールド、 '{}'に設定し、

- "multi-cost-types" field.

- 「マルチコストタイプ」フィールド。

If the Client request does not provide member "calendared" or if it provides it with a value equal to 'false' for all the requested cost types, then the ALTO Server response is exactly as specified in [RFC7285] and [RFC8189].


If the value of member "calendared" is equal to 'false' for a given requested cost type, the ALTO Server MUST return, for this cost type, a single cost value as specified in [RFC7285].

与えられた要求コスト・タイプに対して「Calendared」メンバーの値が 'false'に等しい場合、ALTOサーバーは、このコスト・タイプの場合は、[RFC7285]で指定されている単一の原価値を返さなければなりません。

If the value of member "calendared" is equal to 'true' for a given requested cost type, the ALTO Server returns, for this cost type, a cost value Calendar, as specified above in this section. In addition to the above cited non-Calendar-specific "meta" members, the Server MUST provide a Calendar-specific metadata field.


The Calendar-specific "meta" field that a calendared Filtered Cost Map response MUST include is a member called "calendar-response-attributes", which describes properties of the Calendar and where:


* member "calendar-response-attributes" is an array of one or more objects of type "CalendarResponseAttributes",

* メンバー「calendar-response-attributes」は、「CalendAlsActonseAttributes」タイプの1つ以上のオブジェクトの配列です。

* each "CalendarResponseAttributes" object in the array is specified for one or more cost types for which the value of member "calendared", in object ReqFilteredCostMap provided in the Client request, is equal to 'true' and for which a Calendar is provided for the requested information resource, and

* アレイ内の各「CalendArseArseAttributes」オブジェクトは、クライアント要求で提供されているオブジェクトReqFilteredCostMapのメンバー "calendared"の値が「true」に等しく、カレンダーが提供されている1つ以上のコストタイプに指定されています。要求された情報リソース、および

* the "CalendarResponseAttributes" object that applies to a cost type name has a corresponding "CalendarAttributes" object defined for this cost type name in the IRD capabilities of the requested information resource. This object is the entry in the "calendar-attributes" array member of the IRD resource entry, which includes the name of the requested cost type. This corresponding "CalendarAttributes" object has the same values as object "CalendarResponseAttributes" for members "time-interval-size" and "number-of-intervals". The members of the "CalendarResponseAttributes" object include all the members of the corresponding "CalendarAttributes" object.

* コストタイプ名に適用される「CalendArsArseAttributes」オブジェクトには、要求された情報リソースのIRD機能内のこのコストタイプ名に対して定義された対応する「CalendarAttributes」オブジェクトがあります。このオブジェクトは、要求されたコストタイプの名前を含む、IRDリソースエントリの「calendar-attributes」アレイメンバ内のエントリです。この対応する「CalendarAttributes」オブジェクトは、メンバー「time-interval-size」および「間隔枚数」に対して、オブジェクト「CalendAlseAttributes」と同じ値を持ちます。「CalendArsArseAttributes」オブジェクトのメンバーには、対応する "CalendarAttributes"オブジェクトのすべてのメンバーが含まれています。

The format of member "CalendarResponseAttributes is defined as follows:

メンバーのフォーマット "CalendArsArseAttributesは次のように定義されています。

   CalendarResponseAttributes calendar-response-attributes <1..*>;
     [JSONString cost-type-names <1..*>;]
     JSONString calendar-start-time;
     JSONNumber time-interval-size;
     JSONNumber number-of-intervals;
     [JSONNumber repeated;]
   } CalendarResponseAttributes;

Object CalendarResponseAttributes has the following attributes:

Object CalendAlsAlsAtoneAttributesには、次の属性があります。

"cost-type-names": An array of one or more cost type names to which the value of the other members of CalendarResponseAttributes apply and for which a Calendar has been requested. The value of this member is a subset of the "cost-type-names" member of the abovementioned corresponding "CalendarAttributes" object in the "calendar-attributes" array member in the IRD. This member MUST be present when Cost Calendars are provided for more than one cost type.


"calendar-start-time": Indicates the date at which the first value of the Calendar applies. The value is a string that, as specified in Section 5, contains an HTTP "Date" header field using the IMF-fixdate format specified in Section of [RFC7231]. The value provided for attribute "calendar-start-time" SHOULD NOT be later than the request date.

"calendar-start-time":カレンダーの最初の値が適用される日付を示します。値は、セクション5で指定されているように、[RFC7231]のセクション7.1.1.1で指定されているIMF-FixDateフォーマットを使用したHTTP "日付"ヘッダーフィールドが含まれている文字列です。属性 "calendar-start-time"に指定された値は、要求日より遅くしないでください。

"time-interval-size": As specified in Section 4.1 and with the same value as in the abovementioned corresponding "CalendarAttributes" object.

"time-interval-size":セクション4.1で指定され、上記の対応する "CalendarAttributes"オブジェクトと同じ値です。

"number-of-intervals": As specified in Section 4.1 and with the same value as in the abovementioned corresponding "CalendarAttributes" object.


"repeated": An optional field provided for Calendars. It is an integer N greater or equal to '1' that indicates how many iterations of the Calendar value array starting at the date indicated by "calendar-start-time" have the same values. The number N includes the iteration provided in the returned response.


For example, suppose the "calendar-start-time" member has value "Mon, 30 Jun 2019 00:00:00 GMT", the "time-interval-size" member has value '3600', the "number-of-intervals" member has value '24', and the value of member "repeated" is equal to '4'. This means that the Calendar values are the same on Monday, Tuesday, Wednesday, and Thursday on a period of 24 hours starting at 00:00:00 GMT. The ALTO Client thus may use the same Calendar for the next 4 days starting at "calendar-start-time" and will only need to request a new one for Friday, July 4th at 00:00:00 GMT.

たとえば、 "calendar-start-time"メンバーが "mon、2019年6月30日00:00:00 GMT"にあると仮定して、 "Time-Interval-size"メンバーは値 '3600'を持ち、間隔 "メンバーは値 '24'を持ち、メンバー"繰り返し "の値は '4'に等しいです。つまり、カレンダーの値は、月曜日、火曜日、水曜日、および木曜日の00:00:00 GMTから24時間の期間で同じです。このように、Altoクライアントは、「calendar-start-time」から次の4日間同じカレンダーを使用し、7月4日(金曜日)00:00:00 GMTで新しいものをリクエストする必要があります。

Attribute "repeated" may take a very high value if a Calendar represents a cyclic value pattern that the Server considers valid for a long period and hence will only update once this period has elapsed or if an unexpected event occurs on the network. In the latter case, the Client will be notified if it uses the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service, specified in [RFC8895]. To this end, it is RECOMMENDED that ALTO Servers providing ALTO Calendars also provide the "ALTO Incremental Updates Using Server-Sent Events (SSE)" Service, which is specified in [RFC8895]. Likewise, ALTO Clients capable of using ALTO Calendars SHOULD also use the SSE Service. See also discussion in Section 8 "Operational Considerations".

カレンダが長期間にわたって有効になっていることを考慮して、この期間が経過したら、またはネットワーク上で予期している場合にのみ更新されると、カレンダがサーバーが長期間有効であると更新されるだけである場合、属性 "繰り返し"は非常に高い値を取ります。後者の場合、[RFC8895]で指定されている「サーバー送信イベント(SSE)」サービスを使用している「ALTOインクリメンタルアップデートを使用している場合、クライアントに通知されます。この目的のために、ALTOカレンダーを提供するALTOサーバは、[RFC8895]で指定されている「サーバ送信イベント(SSE)」サービスを使用しているALTOインクリメンタルアップデートも提供することをお勧めします。同様に、ALTOカレンダーを使用することができるALTOクライアントもSSEサービスを使用する必要があります。セクション8の「運用上の考慮事項」の説明も参照してください。

5.1.3. Use Case and Example: FCM with a Bandwidth Calendar
5.1.3. ユースケースと例:帯域幅カレンダー付きFCM

An example of non-real-time information that can be provisioned in a Calendar is the expected path throughput. While the transmission rate can be measured in real time by end systems, the operator of a data center is in the position of formulating preferences for given paths at given time periods to avoid traffic peaks due to diurnal usage patterns. In this example, we assume that an ALTO Client requests a Calendar of network-provider-defined throughput ratings as specified in the IRD to schedule its bulk data transfers as described in the use cases.


In the example IRD, Calendars for cost type name "num-throughputrating" are available for the information resources "filtered-cost-calendar-map" and "endpoint-cost-map-calendar". The ALTO Client requests a Calendar for "num-throughputrating" via a POST request for a Filtered Cost Map.

IRDの例では、情報リソース「フィルタリングコスト - カレンダーマップ」と「エンドポイントコストマップカレンダー」には、コストタイプ名「Num-Sorputrating」のカレンダーがあります。ALTOクライアントは、フィルタリングされたコストマップのPOST要求を介して「Num-Servetrating」のカレンダーを要求します。

We suppose in the present example that the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15. The Server returns Calendars with arrays of 12 numbers for each source and destination pair. The values for metric "throughputrating", in this example, are assumed to be encoded in 2 digits.


     POST /calendar/costmap/filtered HTTP/1.1
     Content-Length: 217
     Content-Type: application/alto-costmapfilter+json
     Accept: application/alto-costmap+json,application/alto-error+json
       "cost-type" : {"cost-mode" : "numerical",
                      "cost-metric" : "throughputrating"},
       "calendared" : [true],
       "pids" : {
         "srcs" : [ "PID1", "PID2" ],
         "dsts" : [ "PID1", "PID2", "PID3" ]
     HTTP/1.1 200 OK
     Content-Length: 1043
     Content-Type: application/alto-costmap+json
       "meta" : {
         "dependent-vtags" : [
           {"resource-id": "my-default-network-map",
            "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
         "cost-type" : {"cost-mode" : "numerical",
                        "cost-metric" : "throughputrating"},
         "calendar-response-attributes" : [
           {"calendar-start-time" : "Tue, 1 Jul 2019 13:00:00 GMT",
            "time-interval-size" : 7200,
            "number-of-intervals" : 12}
       "cost-map" : {
         "PID1": { "PID1": [ 1, 12, 14, 18, 14, 14,
                            14, 18, 19, 20, 11, 12],
                   "PID2": [13,  4, 15, 16, 17, 18,
                            19, 20, 11, 12, 13, 14],
                   "PID3": [20, 20, 18, 14, 12, 12,
                            14, 14, 12, 12, 14, 16] },
         "PID2": { "PID1": [17, 18, 19, 10, 11, 12,
                            13, 14, 15, 16, 17, 18],
                   "PID2": [20, 20, 18, 16, 14, 14,
                            14, 16, 16, 16, 14, 16],
                   "PID3": [20, 20, 18, 14, 12, 12,
                            14, 14, 12, 12, 14, 16] }
5.2. Calendar Extensions in the Endpoint Cost Service
5.2. エンドポイント原価サービスのカレンダー拡張

This document extends the Endpoint Cost Service, as defined in Section 11.5.1 of [RFC7285], by adding new input parameters and capabilities and by returning JSONArrays instead of JSONNumbers as the cost values. The media type (Section of [RFC7285]) and HTTP method (Section of [RFC7285]) are unchanged.


5.2.1. Calendar-Specific Input in Endpoint Cost Requests
5.2.1. エンドポイントコスト要求におけるカレンダー固有の入力

The extensions to the requests for calendared Endpoint Cost Maps are the same as for the Filtered Cost Map Service, specified in Section 5.1.1 of this document. Likewise, the rules defined around the extensions to ECM requests are the same as those defined in Section 5.1.1 for FCM requests.


The ReqEndpointCostMap object for a calendared ECM request will have the following format:


   object {
     [CostType cost-type;]
     [CostType multi-cost-types<1..*>;]
     [JSONBoolean calendared<1..*>;]
     EndpointFilter endpoints;
   } ReqEndpointCostMap;
   object {
     [TypedEndpointAddr srcs<0..*>;]
     [TypedEndpointAddr dsts<0..*>;]
   } EndpointFilter;

Member "cost-type" is optional because, in the ReqEndpointCostMap object definition of this document, it is jointly present with member "multi-cost-types" to ensure compatibility with [RFC8189]. In [RFC8189], members "cost-type" and "multi-cost-types" are both optional and have to obey the rule specified in Section 4.1.2 of [RFC8189] stating that "the Client MUST specify either "cost-type" or "multi-cost-types" but MUST NOT specify both".


The interpretation of member "calendared" is the same as for the ReqFilteredCostMap object defined in Section 5.1.1 of this document. The interpretation of the other members is the same as for object ReqEndpointCostMap defined in [RFC7285] and [RFC8189]. The type TypedEndpointAddr is defined in Section 10.4.1 of [RFC7285].

メンバー「Calendared」の解釈は、このドキュメントのセクション5.1.1で定義されているReqFilteredCostMapオブジェクトと同じです。他のメンバーの解釈は、[RFC7285]と[RFC8189]で定義されているObject ReqenDpointCostMapと同じです。型TypeDendPointAddrは、[RFC7285]の10.4.1項で定義されています。

For the reasons explained in Section 3.3, a Calendar-aware ALTO Server does not support constraints. Therefore, member "[constraints]" is not present in the ReqEndpointCostMap object, and member "constraints" MUST NOT be present in the input parameters of a request for an Endpoint Cost Calendar. If this member is present, the Server MUST ignore it.


5.2.2. Calendar Attributes in the Endpoint Cost Response
5.2.2. エンドポイントコスト応答のカレンダー属性

The "meta" field of a calendared Endpoint Cost response MUST include at least:


* if the ALTO Client supports cost values for one cost type at a time only, the "meta" fields specified in Section of [RFC7285] for the Endpoint Cost response:

* ALTOクライアントが一度に1コストタイプのコスト値のみをサポートしている場合は、エンドポイントコストの応答については、[RFC7285]のセクション11.5.1.6で指定された「メタ」フィールドがあります。

- "cost-type" field.

- 「コストタイプ」フィールド。

* if the ALTO Client supports cost values for several cost types at a time, as specified in [RFC8189], the "meta" fields specified in [RFC8189] for the Endpoint Cost response:

* ALTOクライアントが[RFC8189]で指定されているときに、エンドポイントコストの応答について[RFC8189]で指定された「メタ」フィールドを一度にコストタイプのコスト値をサポートしている場合

- "cost-type" field with value set to '{}', for backwards compatibility with [RFC7285].

- [RFC7285]との下位互換性については、値を持つ「コストタイプ」フィールド。

- "multi-cost-types" field.

- 「マルチコストタイプ」フィールド。

If the Client request does not provide member "calendared" or if it provides it with a value equal to 'false', for all the requested cost types, then the ALTO Server response is exactly as specified in [RFC7285] and [RFC8189].


If the ALTO Client provides member "calendared" in the input parameters with a value equal to 'true' for given requested cost types, the "meta" member of a calendared Endpoint Cost response MUST include, for these cost types, an additional member "calendar-response-attributes", the contents of which obey the same rules as for the Filtered Cost Map Service, specified in Section 5.1.2. The Server response is thus changed as follows, with respect to [RFC7285] and [RFC8189]:

ALTOクライアントが、指定された要求原価タイプに対して「TRUE」に等しい値で入力パラメータにメンバー「カレンダー」を提供する場合、カレンダーエンドポイントコストの応答の「メタ」メンバーには、これらのコストタイプの追加メンバーが含まれていなければなりません。5.1.2項で指定されたフィルタコストマップサービスと同じ規則に従う内容は、calendar-response-attributes "。したがって、サーバの応答は、[RFC7285]と[RFC8189]に関して次のように変更されます。

* the "meta" member has one additional field "CalendarResponseAttributes", as specified for the Filtered Cost Map Service, and

* 「メタ」メンバーには、フィルタリングされたコストマップサービスに指定されているように、1つの追加フィールド「CalendArseAtoneAttributes」が1つあります。

* the calendared costs are JSONArrays instead of the JSONNumbers format used by legacy ALTO implementations. All arrays have a number of values equal to 'number-of-intervals'. Each value corresponds to the cost in that interval.

* カレンダーコストは、従来のALTO実装で使用されるJSonNumbersフォーマットの代わりにJSONARRARYです。すべての配列には、「間隔の数」に等しい数の値があります。各値はその間隔のコストに対応します。

If the value of member "calendared" is equal to 'false' for a given requested cost type, the ALTO Server MUST return, for this cost type, a single cost value as specified in [RFC7285].

与えられた要求コスト・タイプに対して「Calendared」メンバーの値が 'false'に等しい場合、ALTOサーバーは、このコスト・タイプの場合は、[RFC7285]で指定されている単一の原価値を返さなければなりません。

5.2.3. Use Case and Example: ECS with a routingcost Calendar
5.2.3. ユースケースと例:routingCostカレンダー付きのECS

Let us assume an Application Client is located in an end system with limited resources and has access to the network that is either intermittent or provides an acceptable quality in limited but predictable time periods. Therefore, it needs to schedule both its resource-greedy networking activities and its ALTO transactions.


The Application Client has the choice to trade content or resources with a set of endpoints and needs to decide with which one it will connect and at what time. For instance, the endpoints are spread in different time zones or have intermittent access. In this example, the 'routingcost' is assumed to be time-varying, with values provided as ALTO Calendars.

アプリケーションクライアントは、一連のエンドポイントを持つコンテンツまたはリソースを取引することを選択し、それがどの1つと接続されるのかを決定する必要があります。たとえば、エンドポイントは異なるタイムゾーンに拡散したり、断続的なアクセス権を持ちます。この例では、 'routingcost'は時変動し、値はALTOカレンダーとして提供されています。

The ALTO Client associated with the Application Client queries an ALTO Calendar on 'routingcost' and will get the Calendar covering the 24-hour time period "containing" the date and time of the ALTO Client request.

アプリケーションクライアントに関連付けられているALTOクライアントは、ALTOカレンダーを 'routingcost'で照会し、Altoクライアント要求の日時を含む24時間の期間をカレントするカレンダーを獲得します。

For cost type "num-routingcost", the solicited ALTO Server has defined 3 different daily patterns, each represented by a Calendar to cover the week of Monday, June 30th at 00:00 to Sunday, July 6th 23:59:

コストタイプ "num-routingcost"の場合、勧誘ALTOサーバーは3つの異なる毎日のパターンを定義しており、6月30日月曜日、6月30日月曜日から7月6日日曜日にカレンダーが表彰されました。

* C1 for Monday, Tuesday, Wednesday, and Thursday (weekdays)

* 月曜日、火曜日、水曜日、木曜日(平日)

* C2 for Saturday and Sunday (weekends)

* 土曜日と日曜日のC2(週末)

* C3 for Friday (maintenance outage on July 4, 2019 from 02:00:00 GMT to 04:00:00 GMT or a big holiday that is widely celebrated and generates a large number of connections).

* 金曜日のC3(2019年7月4日、2019年7月4日から02:00:00 GMT、GMTまたは大きく祝い、多数の接続を生成する)。

In the following example, the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15.

次の例では、Alto Clientは2019年7月13分に要求を送信します。

The "routingcost" values are assumed to be encoded in 3 digits.


   POST /calendar/endpointcost/lookup HTTP/1.1
   Content-Length: 304
   Content-Type: application/alto-endpointcostparams+json
   Accept: application/alto-endpointcost+json,
     "cost-type" : {"cost-mode" : "numerical",
                    "cost-metric" : "routingcost"},
     "calendared" : [true],
     "endpoints" : {
       "srcs": [ "ipv4:" ],
       "dsts": [

HTTP/1.1 200 OK

HTTP / 1.1 200 OK.

   Content-Length: 1351
   Content-Type: application/alto-endpointcost+json
     "meta" : {
       "cost-type" : {"cost-mode" : "numerical",
                      "cost-metric" : "routingcost"},
       "calendar-response-attributes" : [
         {"calendar-start-time" : "Mon, 30 Jun 2019 00:00:00 GMT",
          "time-interval-size" : 3600,
          "number-of-intervals" : 24,
          "repeated": 4
     "endpoint-cost-map" : {
       "ipv4:": {
         "ipv4:"    : [100, 100, 100, 100, 100, 150,
                                 200, 300, 300, 300, 300, 250,
                                 250, 300, 300, 300, 300, 300,
                                 400, 250, 250, 200, 150, 150],
         "ipv4:" : [ 80,  80,  80,  80, 150, 150,
                                 250, 400, 400, 450, 400, 200,
                                 200, 350, 400, 400, 400, 350,
                                 500, 200, 200, 200, 100, 100],
         "ipv4:"  : [300, 400, 250, 250, 200, 150,
                                 150, 100, 100, 100, 100, 100,
                                 100, 100, 100, 100, 100, 150,
                                 200, 300, 300, 300, 300, 250],
         "ipv6:2001:db8::10"  : [200, 250, 300, 300, 300, 300,
                                 250, 300, 300, 300, 300, 350,
                                 300, 400, 250, 150, 100, 100,
                                 100, 150, 200, 250, 250, 300]

When the Client gets the Calendar for "routingcost", it sees that the "calendar-start-time" is Monday at 00h00 GMT and member "repeated" is equal to '4'. It understands that the provided values are valid until Thursday and will only need to get a Calendar update on Friday.

クライアントが「routingcost」のカレンダーを取得すると、「calendar-start-time」は00H00 GMTの月曜日、メンバー「繰り返し」は '4'です。提供された値は木曜日まで有効であり、金曜日にカレンダーアップデートを入手するだけでよいことを理解しています。

5.2.4. Use Case and Example: ECS with a Multi-cost Calendar for routingcost and owdelay

5.2.4. ユースケースと例:routingcostとOWDelayのための多原価カレンダーを持つECS

In this example, it is assumed that the ALTO Server implements multi-cost capabilities, as specified in [RFC8189] . That is, an ALTO Client can request and receive values for several cost types in one single transaction. An illustrating use case is a path selection done on the basis of 2 metrics: routingcost and owdelay.


As in the previous example, the IRD indicates that the ALTO Server provides "routingcost" Calendars in terms of 24 time intervals of 1 hour (3600 seconds) each.


For metric "owdelay", the IRD indicates that the ALTO Server provides Calendars in terms of 12 time interval values lasting 5 minutes (300 seconds) each.

メトリック "OWDelay"の場合、IRDはALTOサーバーがそれぞれ5分(300秒)続く12の時間間隔値の観点からカレンダーを提供することを示します。

In the following example transaction, the ALTO Client sends its request on Tuesday, July 1st 2019 at 13:15.

次のトランザクションの例では、Alto Clientは2019年7月13日火曜日にその要求を送信します。

This example assumes that the values of metric "owdelay" and "routingcost" are encoded in 3 digits.

この例では、メトリック "owdelay"と "routingcost"の値が3桁でエンコードされていると想定しています。

   POST calendar/endpointcost/lookup HTTP/1.1
   Content-Length: 390
   Content-Type: application/alto-endpointcostparams+json
   Accept: application/alto-endpointcost+json,
     "cost-type" : {},
     "multi-cost-types" : [
       {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
       {"cost-mode" : "numerical", "cost-metric" : "owdelay"}
     "calendared" : [true, true],
     "endpoints" : {
       "srcs": [ "ipv4:" ],
       "dsts": [
   HTTP/1.1 200 OK
   Content-Length: 2165
   Content-Type: application/alto-endpointcost+json
     "meta" : {
       "multi-cost-types" : [
         {"cost-mode" : "numerical", "cost-metric" : "routingcost"},
         {"cost-mode" : "numerical", "cost-metric" : "owdelay"}
       "calendar-response-attributes" : [
         {"cost-type-names" : [ "num-routingcost" ],
            "calendar-start-time" : "Mon, 30 Jun 2019 00:00:00 GMT",
            "time-interval-size" : 3600,
            "number-of-intervals" : 24,
            "repeated": 4 },
         {"cost-type-names" : [ "num-owdelay" ],
            "calendar-start-time" : "Tue, 1 Jul 2019 13:00:00 GMT",
            "time-interval-size" : 300,
            "number-of-intervals" : 12}
     "endpoint-cost-map" : {
       "ipv4:": {
         "ipv4:"    : [[100, 100, 100, 100, 100, 150,
                                  200, 300, 300, 300, 300, 250,
                                  250, 300, 300, 300, 300, 300,
                                  400, 250, 250, 200, 150, 150],
                                 [ 20, 400,  20,  80,  80,  90,
                                  100,  90,  60,  40,  30,  20]],
         "ipv4:" : [[ 80,  80,  80,  80, 150, 150,
                                  250, 400, 400, 450, 400, 200,
                                  200, 350, 400, 400, 400, 350,
                                  500, 200, 200, 200, 100, 100],
                                 [ 20,  20,  50,  30,  30,  30,
                                   30,  40,  40,  30,  20,  20]],
         "ipv4:"  : [[300, 400, 250, 250, 200, 150,
                                  150, 100, 100, 100, 100, 100,
                                  100, 100, 100, 100, 100, 150,
                                  200, 300, 300, 300, 300, 250],
                                 [100,  90,  80,  60,  50,  50,
                                   40,  40,  60,  90, 100,  80]],
         "ipv6:2001:db8::10"  : [[200, 250, 300, 300, 300, 300,
                                  250, 300, 300, 300, 300, 350,
                                  300, 400, 250, 150, 100, 100,
                                  100, 150, 200, 250, 250, 300],
                                 [ 40,  40,  40,  40,  50,  50,
                                   50,  20,  10,  15,  30,  40]]

When receiving the response, the Client sees that the Calendar values for metric "routingcost" are repeated for 4 iterations. Therefore, in its next requests until the "routingcost" Calendar is expected to change, the Client will only need to request a Calendar for "owdelay".

応答を受信すると、クライアントは、メトリック "routingcost"のカレンダー値が4回の反復のために繰り返されることを示しています。したがって、 "routingcost"カレンダーが変更されることが予想されるまでの次の要求では、クライアントは "OWDelay"のカレンダーを要求するだけです。

Without the ALTO Calendar extensions, the ALTO Client would have no clue on the dynamicity of the metric value change and would spend needless time requesting values at an inappropriate pace. In addition, without the Multi-Cost ALTO capabilities, the ALTO Client would duplicate this waste of time as it would need to send one request per cost metric.


6. IANA Considerations
6. IANAの考慮事項

This document has no IANA actions.


7. Security Considerations
7. セキュリティに関する考慮事項

As an extension of the base ALTO protocol [RFC7285], this document fits into the architecture of the base protocol and hence the security considerations (Section 15 of [RFC7285]) fully apply when this extension is provided by an ALTO Server. 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 calendaring information provided by this extension requires additional considerations on three security considerations discussed in [RFC7285]: potential undesirable guidance to Clients (Section 15.2 of [RFC7285]), confidentiality of ALTO information (Section 15.3 of [RFC7285]), and availability of ALTO (Section 15.5 of [RFC7285]). For example, by providing network information in the future in a Calendar, this extension may improve availability of ALTO when the ALTO Server is unavailable but related information is already provided in the Calendar.


For confidentiality of ALTO information, an operator should be cognizant that this extension may introduce a new risk, a malicious ALTO Client may get information for future events that are scheduled through Calendaring. Possessing such information, the malicious Client may use it to generate massive connections to the network at times where its load is expected to be high.


To mitigate this risk, the operator should address the risk of ALTO information being leaked to malicious Clients or third parties. As specified in "Protection Strategies" (Section 15.3.2 of [RFC7285]), the ALTO Server should authenticate ALTO Clients and use the Transport Layer Security (TLS) protocol so that man-in-the-middle (MITM) attacks to intercept an ALTO Calendar are not possible. "Authentication and Encryption" (Section 8.3.5 of [RFC7285]) ensures the availability of such a solution. It specifies that "ALTO Server implementations as well as ALTO Client implementations MUST support the "https" URI scheme of [RFC2818] and Transport Layer Security (TLS) of [RFC5246]".


Section 1 of TLS 1.3 [RFC8446] states: "While TLS 1.3 is not directly compatible with previous versions, all versions of TLS incorporate a versioning mechanism which allows Clients and Servers to interoperably negotiate a common version if one is supported by both peers". ALTO Clients and Servers SHOULD support both TLS 1.3 [RFC8446] and TLS 1.2 [RFC5246] and MAY support and use newer versions of TLS as long as the negotiation process succeeds.

TLS 1.3のセクション1.3 [RFC8446]状態: "TLS 1.3は以前のバージョンと直接互換性がありませんが、すべてのバージョンのTLSは、クライアントとサーバーが両方のピアでサポートされている場合は共通バージョンとサーバーを相互運用できるバージョン管理メカニズムを組み込んでいます。ALTOクライアントとサーバーは、TLS 1.3 [RFC8446]とTLS 1.2 [RFC5246]の両方をサポートし、ネゴシエーションプロセスが成功した限り、新しいバージョンのTLSをサポートして使用することができます。

The operator should be cognizant that the preceding mechanisms do not address all security risks. In particular, they will not help in the case of "malicious Clients" possessing valid authentication credentials. The threat here is that legitimate Clients have become subverted by an attacker and are now 'bots' being asked to participate in a DDoS attack. The Calendar information now becomes valuable in knowing exactly when to perpetrate a DDoS attack. A mechanism, such as a monitoring system that detects abnormal behaviors, may still be needed.


To avoid malicious or erroneous guidance from ALTO information, an ALTO Client should be cognizant that using calendaring information can have risks: (1) Calendar values, especially in "repeated" Calendars, may be only statistical and (2) future events may change. Hence, a more robust ALTO Client should adapt and extend protection strategies specified in Section 15.2 of [RFC7285]. For example, to be notified immediately when a particular ALTO value that the Client depends on changes, it is RECOMMENDED that both the ALTO Client and ALTO Server using this extension support "Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)" [RFC8895].

ALTO情報から悪意のあるものまたは誤ったガイダンスを避けるために、ALTOクライアントは、カレンダー情報を使用することができることを認識しているべきである:(1)カレンダー値、特に「繰り返し」カレンダーでは、統計的なイベントが変わる可能性があります。したがって、より堅牢なALTOクライアントは、[RFC7285]のセクション15.2で指定された保護戦略を適応させ拡張する必要があります。たとえば、クライアントが変更に依存する特定のALTO値がすぐに通知されるには、サーバー送信イベントを使用したApplication-SupportsのApplication-Supports Optimization(ALTO)の増分更新を使用するALTOクライアントとALTOサーバの両方が推奨されます。(SSE)」[RFC8895]。

Another risk of erroneous guidance appears when the Server exposes an occurrence of a same cost type name in different elements of the Calendar objects array associated to an information resource. In this case, there is no way for the Client to figure out which Calendar object in the array is valid. The specification in this document recommends, in this case, that the Client uses the first encountered Calendar object occurrence containing the cost type name. However, the Client may want to avoid the risks of erroneous guidance associated to the use of potentially invalid Calendar values. To this end, as an alternative to the recommendation in this document, the Client MAY ignore the totality of occurrences of CalendarAttributes objects containing the cost type name and query this cost type using [RFC7285].


8. Operational Considerations
8. 運用上の考慮事項

It is important that both the operator of the network and the operator of the applications consider both the feedback aspect and the prediction-based (uncertainty) aspect of using the Cost Calendar.


First, consider the feedback aspect and consider the Cost Calendar as a traffic-aware map service (e.g., Google Maps). Using the service without considering its own effect, a large fleet can turn a not-congested road into a congested one; a large number of individual cars each choosing a road with light traffic ("cheap link") can also result in congestion or result in a less-optimal global outcome (e.g., the Braess' Paradox [BRAESS_PARADOX]).

まず、フィードバックの態様を検討し、トラフィック認識マップサービス(例えば、Googleマップ)としてコストカレンダーを考慮してください。それ自身の効果を考慮せずにサービスを使用すると、大きな艦隊が混雑していない道を渋滞したものに変えることができます。軽い交通(「安いリンク」)を使って道を選ぶ多数の個々の車はまた渋滞をもたらし、または最適ではないグローバルな結果(例えば、Braess 'Paradox [Braess_Paradox])をもたらすことができる。

Next, consider the prediction aspect. Conveying ALTO Cost Calendars tends to reduce the on-the-wire data exchange volume compared to multiple single-cost ALTO transactions. An application using Calendars has a set of time-dependent values upon which it can plan its connections in advance with no need for the ALTO Client to query information at each time. Additionally, the Calendar response attribute "repeated", when provided, saves additional data exchanges in that it indicates that the ALTO Client does not need to query Calendars during a period indicated by this attribute. The preceding is true only when "accidents" do not happen.


Although individual network operators and application operators can choose their own approaches to address the aforementioned issues, this document recommends the following considerations. First, a typical approach to reducing instability and handling uncertainty is to ensure timely update of information. The SSE Service, as discussed in Section 7, can handle updates if supported by both the Server and the Client. Second, when a network operator updates the Cost Calendar and when an application reacts to the update, they should consider the feedback effects. This is the best approach even though there is theoretical analysis [SELFISH_RTG_2002] and Internet-based evaluation [SELFISH_RTG_2003] showing that uncoordinated behaviors do not always cause substantial suboptimal results.


High-resolution intervals may be needed when values change, sometimes during very small time intervals but in a significant manner. A way to avoid conveying too many entries is to leverage on the "repeated" feature. A Server can smartly set the Calendar start time and number of intervals so as to declare them "repeated" for a large number of periods until the Calendar values change and are conveyed to requesting Clients.


The newer JSON Data Interchange Format specification [RFC8259] used in ALTO Calendars replaces the older one [RFC7159] used in the base ALTO protocol [RFC7285]. The newer JSON mandates UTF-8 text encoding to improve interoperability. Therefore, ALTO Clients and Servers implementations using UTF-{16,32} need to be cognizant of the subsequent interoperability risks and MUST switch to UTF-8 encoding if they want to interoperate with Calendar-aware Servers and Clients.

ALTOカレンダーで使用されている新しいJSONデータ交換フォーマット仕様[RFC8259]は、基本ALTOプロトコル[RFC7285]で使用されている[RFC7159]の古い[RFC7159]を置き換えます。新しいJSONは、相互運用性を向上させるためにUTF-8テキストエンコーディングを義務付けます。したがって、UTF - {16,32}を使用したALTOクライアントおよびサーバー実装は、後続の相互運用性リスクを認識しており、カレンダー対応のサーバーやクライアントと相互運用したい場合はUTF-8エンコーディングに切り替わる必要があります。

9. References
9. 参考文献
9.1. Normative References
9.1. 引用文献

[IEEE.754.2019] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019, <>.

[IEEE.754.2019] IEEE、「浮動小数点演算のためのIEEE規格」、IEEE 754-2019、DOI 10.1109 / IEEESTD.2019.8766229、2019年6月、<>。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <>.

[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<>。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <>.

[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ(TLS)プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、< RFC5246>。

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <>.

[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol(HTTP / 1.1):セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<>。

[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, <>.

[RFC7285] Alimi、R.、Ed。、Penno、R.、Ed。、Yang、Y、Ed。、Kiesel、S.、Previdi、S.、Roome、W.、Shalunov、S.、およびR。不安、「アプリケーション層交通最適化(ALTO)プロトコル」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<>。

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <>.

[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<>。

[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost Application-Layer Traffic Optimization (ALTO)", RFC 8189, DOI 10.17487/RFC8189, October 2017, <>.

[RFC8189] Randriamasy、S.、Roomy、W.、およびSchwan、「多価格アプリケーション層交通最適化(ALTO)」、RFC 8189、DOI 10.17487 / RFC8189、2017年10月、<https:// www。>。

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <>.

[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、< info / rfc8259>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <>.

[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ(TLS)プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<>。

[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, <>.

[RFC8895] Roome、W.およびY。ヤン、「アプリケーションレイヤトラフィック最適化(ALTO)」イベント(SSE) "、RFC 8895、DOI 10.17487 / RFC8895、2020年11月、<https:// / info / rfc8895>。

9.2. Informative References
9.2. 参考引用

[ALTO_METRICS] Wu, Q., Yang, Y. R., Dhody, D., Randriamasy, S., and L. M. Contreras, "ALTO Performance Cost Metrics", Work in Progress, Internet-Draft, draft-ietf-alto-performance-metrics-09, 9 March 2020, < draft-ietf-alto-performance-metrics-09>.

[alto_metrics]呉、Q.、Yang、Yr、Dhody、D.、Randriamasy、S.、LM Contrass、「Alto Performance Cost Metrics」、進行中の作業、インターネットドラフト、ドラフト - IETF-ALTO - パフォーマンス測定基準-09,200月9日、< romft-ietf-alto-performance-metrics-09>。

[BRAESS_PARADOX] Steinberg, R. and W. Zangwill, "The Prevalence of Braess' Paradox", Transportation Science Vol. 17, No. 3, DOI 10.1287/trsc.17.3.301, 1 August 1983, <>.

[BRAESS_PARADOX] Steinberg、R.およびW. Zangwill、「Braess 'Paradoxの有病率」、交通科学Vol。17、No.3、DOI 10.1287 / TRSC.17.3.301,1983、<>。

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <>.

[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<>。

[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <>.

[RFC5693] Seedorf、J.およびE.バーガー、「アプリケーションレイヤトラフィック最適化(ALTO)問題ステートメント」、RFC 5693、DOI 10.17487 / RFC 5693、2009年10月、< RFC5693>。

[RFC6708] Kiesel, S., Ed., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, DOI 10.17487/RFC6708, September 2012, <>.

[RFC6708]キセル、S、ED。、PREVIDI、S.、Stiemerling、M.、Insight、R.、およびY. Yang、「アプリケーション層交通最適化(ALTO)要件」、RFC 6708、DOI 10.17487 / RFC6708、2012年9月、<>。

[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <>.

[RFC7159] Bray、T.、ED。、「JavaScriptオブジェクト表記(JSON)データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<>。

[SELFISH_RTG_2002] Roughgarden, T., "Selfish Routing", Dissertation Thesis, Cornell, May 2002.

[selfish_rtg_2002] Rafdengen、T.、「利己的なルーティング」、論文論文、Cornell、2002年5月。

[SELFISH_RTG_2003] Qiu, L., Yang, Y., Zhang, Y., and S. Shenker, "Selfish Routing in Internet-Like Environments", Proceedings of SIGCOMM '03, DOI 10.1145/863955.863974, August 2003, <>.

[Selfish_RTG_2003] Qiu、L.、Yang、Y.、Zhang、Y.、およびS.シェンカー、「インターネットのような環境での利己的なルーティング」、SIGCOMM '03、DOI 10.1145 / 863955.863974、<>。

[SENSE] Department of Energy Office of Science Advanced Scientific Computing Research (ASCR) Program, "SDN for End-to-End Networked Science at the Exascale (SENSE)", <>.


[UNICORN-FGCS] Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, Y., and Y. Liu, "Unicorn: Unified resource orchestration for multi-domain, geo-distributed data analytics", Future Generation Computer Systems (FGCS), Vol. 93, Pages 188-197, DOI 10.1016/j.future.2018.09.048, ISSN 0167-739X, March 2019, <>.

[Unicorn-FGCS] Xiang、Q.、Wang、T.、Zhang、J.、Newman、H.、Yang、Y.、Y。Liu、 "Unicorn:マルチドメインの統一リソースオーケストレーション、地理分散データAnalytics」、将来の世代のコンピュータシステム(FGCS)、Vol。93、Pages 188-197、DOI 10.1016 / J.Future.2018.09.048、ISSN 0167-739x、2019年3月、<>。



The authors would like to thank Fred Baker, Li Geng, Diego Lopez, He Peng, and Haibin Song for fruitful discussions and feedback on earlier draft versions. Dawn Chan, Kai Gao, Vijay Gurbani, Yichen Qian, Jürgen Schönwälder, Brian Weis, and Jensen Zhang provided substantial review feedback and suggestions to the protocol design.

著者らは、Fred Baker、Li Geng、Diego Lopez、He Peng、そしてHaibin Songの歌を述べています。夜明けちゃん、Kai Gao、Vijay Gurbani、Yichen Qian、JürgenSchönwerder、Brian Weis、Jensen Zhangは、プロトコルデザインへのフィードバックと提案を実質的なレビューしました。

Authors' Addresses


Sabine Randriamasy Nokia Bell Labs Route de Villejust 91460 Nozay France

Sabine Randriamasy Nokia Bell Labs Route de Villejust 91460 Nozayフランス


Y. Richard Yang Yale University 51 Prospect St. New Haven, CT 06520 United States of America

Y. Richard Yang Yale University 51 ProSpect St. New Haven、CT 06520アメリカ合衆国


Qin Wu Huawei Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China

Qin Wu Huawei Yuhua District 101ソフトウェアアベニュー南京江蘇省、210012中国


Lingli Deng China Mobile China

Lingli Deng China Mobile China


Nico Schwan Thales Deutschland Lorenzstrasse 10 70435 Stuttgart Germany

Nico Schwan Thales Deutschland Lorenzstrasse 10 70435 Stuttgartドイツ