[要約] RFC 8896は、ALTO Cost Calendarに関する標準化されたプロトコル仕様です。このRFCの目的は、ネットワークリソースのコスト情報を提供し、アプリケーションレイヤーのトラフィック最適化を支援することです。
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
Huawei
L. Deng
China Mobile
N. Schwan
Thales Deutschland
November 2020
Application-Layer Traffic Optimization (ALTO) Cost Calendar
アプリケーションレイヤトラフィック最適化（ALTO）コストカレンダー
Abstract
概要
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 https://www.rfc-editor.org/info/rfc8896.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https：//www.rfc-editor.org/info/rfc8896で取得できます。
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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include 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文書（https://truste.ietf.org/License-info）に関する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
Acknowledgments
Authors' Addresses
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.
[RFC7285]で指定された基本アプリケーションレイヤトラフィック最適化（ALTO）プロトコルは、所望のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるオーバーレイアプリケーションへのガイダンスを提供します。このガイダンスは、トポロジ距離などのホスト間のデータ伝送のパフォーマンスと効率に影響を与えるパラメータに基づいています。アルトの目的は、基礎となるネットワークインフラストラクチャのリソース使用量を最適化しながら、アプリケーション内の経験の質（QoE）の質を向上させることです。
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.
ALTO原価値の変更が一定期間にわたって予測可能であり、アプリケーションは即時データ転送を必要としない場合、1つのALTO応答でこの期間にわたって一連のコスト値のセットを取得するための時間を節約できます。このセットを使用してデータ転送をスケジュールすることで、ネットワークリソースの使用量とQoEを最適化できます。ALTOクライアントおよびサーバーはまた、それらのデータ交換をスケジューリングすることによってそれらのワークロードを最小限に抑えることができます。
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.
この文書の残りの部分では、セクション3は設計特性を提供します。セクション4および5は、IRDおよび情報リソースの正式な仕様を定義します。IANA、セキュリティ上の考慮事項、および運用上の考慮事項は、セクション6,7、および8でそれぞれ対処されています。
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].
ALTOプロトコルによって対処できる大規模トラフィックの将来のスケジューリングの必要性も、マルチドメイン、地理分散データ分析のための統一されたリソースオーケストレーションフレームワーク、[Unicorn-FGC]を参照してください。
ALTO transaction: A request/response exchange between an ALTO Client and an ALTO Server.
ALTOトランザクション：ALTOクライアントとALTOサーバ間の要求/応答交換。
Client: When used with a capital "C", this term refers to an ALTO Client.
クライアント：首都「C」で使用すると、この用語はALTOクライアントを指します。
Calendar, Cost Calendar, ALTO Calendar: When used with capitalized words, these terms refer to an ALTO Cost Calendar.
カレンダー、コストカレンダー、ALTOカレンダー：大文字の単語で使用されると、これらの用語はALTOコストカレンダーを参照しています。
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.
エンドポイント（EP）：[RFC7285]のセクション2.1の項でエンドポイントを定義します。それは、例えば、仮想サーバがサポートされているアプリケーションに関与する物理サーバ、計算グリッド、またはオンラインマルチパーティゲームのようなパーティーである。
ECM: An abbreviation for Endpoint Cost Map.
ECM：エンドポイントコストマップの略語。
FCM: An abbreviation for Filtered Cost Map.
FCM：フィルタリングコストマップの略語。
Server: When used with a capital "S", this term refers to an ALTO Server.
サーバー：首都の「S」で使用すると、この用語はALTOサーバーを指します。
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.
単語が小文字に表示されたら、それらは自然な言語の意味と解釈されます。
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].
このセクションでは、設計の高度な概要を説明します。これは、読者がALTOプロトコル[RFC7285]に精通していると仮定しています[RFC8189]。
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.
ほとんどの場合、非リアルタイムアプリケーションのための実現可能なエンドポイントの制限されたセットがすでに識別されていると仮定して、ALTOコストカレンダーがエンドポイントコストサービスに使用され、それらのエンドポイントをすぐにアクセスする必要がなく、そのアクセス一定期間内にスケジュールすることができます。マップのサイズがそれを許容する限り、フィルタリングされたコストマップサービスも適用されます。
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:
カレンダー属性は、情報リソースディレクトリ（IRD）およびALTOサーバーの応答にあります。IRDは、情報リソース機能のある日付の値なしの属性を発表しますが、時間依存値の属性はサーバーの応答の「メタ」セクションに表示されます。ALTO原価カレンダー属性は、次の情報を提供します。
* 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を参照してください。
The present document uses the notations defined in "Notation" (Section 8.2 of [RFC7285]).
本文書は、「表記」で定義されている表記法（RFC7285のセクション8.2）を使用しています。
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 11.2.3.6 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.
本文書は、[RFC7285]で与えられたレガシーコストマップの定義を拡張して、コストエントリが値の配列になることを可能にし、1つの数値に1つの値を持ち、1つの数値だけでなく、コストカレンダー機能が有効になっている場合この費用。したがって、この拡張機能の実装者は、このコストがカレンダーとして照会された場合、コストエントリが値の配列であると考える必要があります。
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:
具体的には、この拡張の実装は、所与のコストタイプのコストカレンダーを提供するサービスをアラウンスするIRDエントリ内のカレンダ属性の「間隔枚数」属性を解析する必要があります。その場合、実装は、サービスのコストエントリが値の配列になることを知っており、配列の予想サイズは「間隔枚数」属性で指定されているものです。次の規則は、サーバーによって発表された配列サイズとクライアントによって受信された配列のサイズとの間の一貫性を確保しようとします。
* 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.
ALTOカレンダーを実現するために、この文書はIRDとALTOの要求とコストカレンダーの応答を拡張します。
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:
カレンダー固有の機能は、IRDの情報リソースと、ALTOレスポンスの「メタ」メンバーに、原価カレンダー要求に統合されています。カレンダーとその機能は、特定の情報リソースと、この情報リソース内で、特定のコスト・タイプを持つこの情報リソースに関連付けられています。このデザインにはいくつかの利点があります。
* 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.
Altoサーバーは、ALTOクライアントにコストカレンダーを提供する頻度で選択できます。カレンダー値の繰り返し/周期性から利益を得るように、要求日からカレンダーアップデートを提供するか、更新を慎重にスケジュールすることができます。
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:
ALTOサーバーはカレンダー上の制約をサポートしていません。提供されたカレンダーは数値に対して要求され、2つの主な理由で、
* 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.
カレンダー機能と組み合わせて制約機能を提供することは、上記の理由で実行可能ではないが、2つの機能は相互に排他的である。フィルタリングされたコストマップとエンドポイントコストマップカレンダーに対する制約がないことは、[RFC7285]で定義されていて[RFC8189]で拡張された[RFC8189]では、オプションの制約をサポートする[RFC8189]に拡張された[RFC8189]からの発散を反映しています。
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.
これらの値が時変なら、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].
Calendar対応のALTOサーバーがレガシ情報リソースでレガシーALTOクライアントを提供できるように、コストカレンダーのALTOプロトコル拡張機能は定義されています。つまり、レガシーALTOクライアントは[RFC7285]で指定されているようにリソースを要求し、応答を受信できます。
A Calendar-aware ALTO Server MUST implement the base protocol specified in [RFC7285].
カレンダー対応のALTOサーバーは[RFC7285]で指定された基本プロトコルを実装する必要があります。
A Calendar-aware ALTO Client MUST implement the base protocol specified in [RFC7285].
カレンダー対応のALTOクライアントは[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.
結果として、メトリックがカレンダ配列として使用可能な場合は、[RFC7285]で必要に応じて単一の値として利用できる必要があります。サーバーは、この場合は、将来のカレンダー対応クライアントまたは[RFC7285]のみを実装するクライアントに興味のないカレンダー対応クライアントに、メトリックの現在の値を提供します。
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.
したがって、カレンダーの情報リソースは、フィルタ処理されたコストマップサービスまたはPOSTメソッドを使用してエンドポイントコストサービスを介して要求されなければなりません。
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.
IRD情報リソース機能のカレンダー属性は、無地の値を運ぶ。カレンダーはコストタイプではなく情報リソースに関連付けられています。例えば、サーバは、1日の粒度でフィルタ処理されたコストマップサービスの「routingCost」カレンダーを提供することができ、より細かい粒度でのエンドポイントコストサービスのための「ルーチンコスト」カレンダーは、限られた数のエンドポイントのために提供され得る。カレンダー固有の機能を備えたIRDの例を4.3節に示します。
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..*>;
object{
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.
「コストタイプ名」：「時間間隔サイズ」と「間隔枚数」の値が適用されるIRDエントリ内のコストタイプ名を示す1つ以上の要素の配列。
"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.
「間隔の数」：コストカレンダー配列の値の数を示す厳密に正の整数（1以上）。
* 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時間である。
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 "alto.example.com". It delegates the announcement of Calendars capabilities to an ALTO Server running in a subdomain called "custom.alto.example.com". 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.example.com"というドメイン内で実行される例を示します。カレンダー機能の発表を「custom.alto.example.com」と呼ばれるサブドメインで実行されている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.
委任のもう1つの利点は、いくつかのリソースのためのいくつかのコストタイプが原価カレンダーとしてより有利であり、それらを単一の値として取得することはほとんど意味がありません。たとえば、コストタイプが1分などの短い時間間隔で予測可能で頻繁に変更される値を持つ場合、より一般的な「ルート」サーバーではなく、焦点のあるデリゲートサーバーを介してコスト値を追跡するように時間とネットワークリソースを保存します。
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.
例示の目的のために、このセクションでは、例として理解されるべきである他の3つの架空の例示的な測定基準とモードを紹介し、正規として使用するか、または見なされるべきではありません。
The cost type names used in the example IRD are as follows:
IRDの例で使用されているコストタイプ名は次のとおりです。
"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-OWDELAY」：経路上の一方向パケット伝送遅延を反映するための「数値」モードの架空のパフォーマンスメトリック「OWDELAY」を指す。関連するパフォーマンスメトリックは現在[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.
「Num-Serpetrating」：「数値」モードでは、エンドツーエンドのスループットの観点からプロバイダの好みを反映するように、架空のメトリック「スケジュール設定」を指します。
"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:
IRDの例には、カレンダーを提供する2つの特定のURIが含まれています。
"https://custom.alto.example.com/calendar/costmap/filtered":
A Filtered Cost Map in which Calendar capabilities are indicated
for cost type names "num-routingcost", "num-throughputrating", and
"string-servicestatus" and
"https://custom.alto.example.com/calendar/endpointcost/lookup": An Endpoint Cost Map in which Calendar capabilities are indicated for cost type names "num-routingcost", "num-owdelay", "num-throughputrating", and "string-servicestatus".
"https://custom.alto.example.com/calendar/endpointcost/lookup"：カレンダー機能がコストタイプ名 "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".
カレンダー機能の設計により、カレンダー属性が異なるいくつかの情報リソースで同じコストタイプ名を持ついくつかのカレンダーを使用できます。これは、フィルタリングされたコストマップとエンドポイントコストサービスの両方で、「Num-Servetrating」のための時間間隔サイズで使用可能な「Num-RoutingCost」、「Num-ServiceStatus」のカレンダーの場合です。"string-serviceStatus"。
--- Client to Server request for IRD ----------
GET /calendars-directory HTTP/1.1
Host: custom.alto.example.com
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" :
"https://custom.alto.example.com/calendar/costmap/filtered",
"media-type" : "application/alto-costmap+json",
"accepts" : "application/alto-costmapfilter+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routingcost",
"num-throughputrating",
"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" :
"https://custom.alto.example.com/calendar/endpointcost/lookup",
"media-type" : "application/alto-endpointcost+json",
"accepts" : "application/alto-endpointcostparams+json",
"capabilities" : {
"cost-constraints" : true,
"cost-type-names" : [ "num-routingcost",
"num-owdelay",
"num-throughputrating",
"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]で指定されている原価タイプの制約をサポートしている必要があります。
This section documents extensions to two basic ALTO information resources (Filtered Cost Maps and Endpoint Cost Service) to provide calendared information services for them.
このセクションでは、カレンダー付きの情報サービスを提供するために、2つの基本ALTO情報リソース（フィルタリングコストマップとエンドポイントコストサービス）への拡張機能を説明します。
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 7.1.1.1 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
A legacy ALTO Client requests and gets Filtered Cost Map responses, as specified in [RFC7285].
レガシALTOクライアントは、[RFC7285]で指定されているように、フィルタリングコストマップの応答を要求します。
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].
このフィールドは1対Nのブール値の配列です。ここで、nは要求されたメトリックの数です。クライアントとサーバーが[RFC8189]を実装すると、nが1より大きい。
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.
各エントリは、同じ配列位置の要求されたメトリックに対応します。各ブール値値は、ALTOサーバがこのコストタイプの値をカレンダーとして指定するかどうかを示します。配列には正確にNブール値を含める必要があります。それ以外の場合、サーバーはエラーを返します。
This field MUST NOT be included if no member "calendar-attributes" is specified in this information resource.
この情報リソースにメンバー「calendar-attributes」が指定されていない場合は、このフィールドを含めてはいけません。
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].
カレンダー属性が指定されていないコストタイプ名のフィールドの値が指定されている場合は、ALTOサーバがこの文書の拡張機能を実装しているか、または実装のみを実装しているか、[RFC7285]を無視する必要があります。[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:
1つのコストタイプのみの要求をサポートし、カレンダーを要求したいカレンダーを対象としたALTOクライアントは、1つの要素の配列を提供する必要があります。
"calendared" : [true],
「カレンダー」：[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値の配列を指定する必要があります。単一またはカレンダー値として値を入力します。
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.
カレッサ付きのALTOフィルタコストマップでは、ソースと宛先との間のコスト値がJSON値のJSON配列です。ALTOカレンダー値配列は、IRDに示されているカレンダー属性のメンバー「間隔」の値に等しい数の値を有する。これらの属性は、フィルタ処理されたコストマップ応答でメタデータとして伝達されます。配列の各要素は、その配列位置に一致する時間間隔に有効です。
The FCM response conveys metadata, among which:
FCMレスポンスはメタデータを伝えます。
* 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].
クライアント要求がメンバー「カレンダー」を提供しない場合、またはすべての要求された原価タイプに対して「false」に等しい値で提供されている場合、ALTOサーバーの応答は[RFC7285]と[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.
メンバー「Calendared」の値が、特定の要求されたコスト・タイプに対して「TRUE」に等しい場合、ALTOサーバーは、このコスト・タイプで、このセクションで上記のようにコスト値カレンダーを返します。上記の非カレンダー固有の「メタ」メンバーに加えて、サーバーはカレンダー固有のメタデータフィールドを提供する必要があります。
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:
カレンダー付きフィルタコストマップ応答に含まれる必要があるカレンダー固有の「Meta」フィールドは、カレンダーのプロパティと場所を説明する「calendar-response-attributes」というメンバーです。
* 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..*>;
object{
[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.
「コストタイプ名」：CalendAlsAlseAttributesの他のメンバーの値が適用され、カレンダーが要求された1つ以上のコストタイプ名の配列。このメンバーの値は、IRDの「calendar-attributes」アレイ・メンバー内の上述の対応する「CalendarAttributes」オブジェクトの「コスト・タイプ名」メンバーのサブセットです。コストカレンダーが複数のコストタイプのために提供されている場合、このメンバーは存在しなければなりません。
"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 7.1.1.1 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.
「間隔」：セクション4.1で指定され、上述の対応する「CalendarAttributes」オブジェクトと同じ値で指定されています。
"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.
「繰り返す」：カレンダーに提供されているオプションのフィールド。「calendar-start-time」で示される日付から始まるカレンダー値配列の繰り返しが同じ値を持つことを示す整数nである。数Nには、返された応答にある反復が含まれています。
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の「運用上の考慮事項」の説明も参照してください。
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.
カレンダーにプロビジョニングできる非リアルタイム情報の例は、予想されるパススループットです。送信速度をエンドシステムによってリアルタイムで測定することができるが、データセンターのオペレータは、経由州使用パターンによるトラフィックピークを回避するために所与の期間に与えられた経路の嗜好の策定の位置にある。この例では、ALTOクライアントがIRDで指定されているネットワークプロバイダー定義のスループット定義のカレンダーを要求して、ユースケースで説明されているようにバルクデータ転送をスケジュールします。
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.
この例では、2019年7月13日火曜日にAltoクライアントがその要求を送信することを想定しています。サーバーは、各ソースペアと宛先ペアごとに12個の数字の配列でカレンダーを返します。この例では、メトリックの「スケープレーション」の値は2桁でエンコードされると想定されています。
POST /calendar/costmap/filtered HTTP/1.1
Host: custom.alto.example.com
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] }
}
}
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 11.5.1.1 of [RFC7285]) and HTTP method (Section 11.5.1.2 of [RFC7285]) are unchanged.
この文書は、[RFC7285]のセクション11.5.1で定義されているように、新しい入力パラメータと機能を追加し、JSONNUMBERSの代わりにJSONNUnumberの代わりにJSONARRAYをコスト値として返すことによって、エンドポイントコストサービスを拡張します。メディアタイプ（[RFC7285]のセクション11.5.1.1）とHTTPメソッド（[RFC7285]のセクション11.5.1.2）は変更されません。
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.
カレンダーエンドポイント原価マップの要求への拡張は、このドキュメントのセクション5.1.1で指定されたフィルタコストマップサービスと同じです。同様に、ECM要求に対する拡張機能の周囲に定義された規則は、FCM要求については5.1.1項で定義されているものと同じです。
The ReqEndpointCostMap object for a calendared ECM request will have the following format:
カレンダーECM要求のReqenDPointCostMapオブジェクトは、次の形式です。
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".
この文書のReqenDpointCostmapオブジェクト定義では、メンバー「cost-type」はオプションです。[RFC8189]では、メンバー「コストタイプ」と「マルチコストタイプ」はどちらもオプションで、「クライアントはどちらかを指定する必要がある」と述べている[RFC8189]のセクション4.1.2で指定されたルールに従わなければなりません。「または「マルチコストタイプ」が「両方を指定してはいけません」。
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.
セクション3.3で説明されている理由で、カレンダー対応ALTOサーバーは制約をサポートしません。したがって、メンバー「[制約]]がReqenDpointCostMapオブジェクトには存在しないため、エンドポイント原価カレンダーの要求の入力パラメーターに「制約」が存在してはいけません。このメンバーが存在する場合、サーバーはそれを無視する必要があります。
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 11.5.1.6 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].
クライアント要求がメンバー「カレンダー」を提供しない場合、またはすべての要求された原価タイプについて、「False」に等しい値で提供されていない場合、ALTOサーバーの応答は[RFC7285]と[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]で指定されている単一の原価値を返さなければなりません。
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.
アプリケーションクライアントがリソースが限られているエンドシステムに配置され、断続的であるか、または予測可能な期間に許容可能な品質を提供するネットワークへのアクセスを持っていると仮定します。したがって、リソース貪欲なネットワーキング活動とそのALTOトランザクションの両方をスケジュールする必要があります。
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.
「routingcost」値は3桁でエンコードされていると見なされます。
POST /calendar/endpointcost/lookup HTTP/1.1
Host: custom.alto.example.com
Content-Length: 304
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,
application/alto-error+json
{
"cost-type" : {"cost-mode" : "numerical",
"cost-metric" : "routingcost"},
"calendared" : [true],
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45",
"ipv6:2001:db8::10"
]
}
}
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:192.0.2.2": {
"ipv4:192.0.2.89" : [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:198.51.100.34" : [ 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:203.0.113.45" : [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.
この例では、ALTOサーバは[RFC8189]で指定されているように、マルチコスト機能を実装していると仮定する。つまり、ALTOクライアントは、1つのトランザクションでいくつかのコストタイプの値を要求および受信できます。ユースケースの説明は、2つのメトリックに基づいて行われたパス選択です.routingCostと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.
前の例と同様に、IRDは、ALTOサーバーがそれぞれ1時間（3600秒）の24時間間隔で「RoutingCost」カレンダーを提供することを示しています。
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
Host: custom.alto.example.com
Content-Length: 390
Content-Type: application/alto-endpointcostparams+json
Accept: application/alto-endpointcost+json,
application/alto-error+json
{
"cost-type" : {},
"multi-cost-types" : [
{"cost-mode" : "numerical", "cost-metric" : "routingcost"},
{"cost-mode" : "numerical", "cost-metric" : "owdelay"}
],
"calendared" : [true, true],
"endpoints" : {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [
"ipv4:192.0.2.89",
"ipv4:198.51.100.34",
"ipv4:203.0.113.45",
"ipv6:2001:db8::10"
]
}
}
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:192.0.2.2": {
"ipv4:192.0.2.89" : [[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:198.51.100.34" : [[ 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:203.0.113.45" : [[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.
ALTOカレンダー拡張なしでは、ALTOクライアントはメトリック値の変化の動的に手がかりを持たず、不適切なペースで値を要求する必要性が要求されます。さらに、マルチコストALTO機能がないと、ALTOクライアントはコストメトリックに1回の要求を送信する必要があるため、この時間の無駄を重複します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
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.
基本ALTOプロトコル[RFC7285]の拡張として、この文書は基本プロトコルのアーキテクチャに適合し、この拡張がALTOサーバによって提供されている場合にはセキュリティ上の考慮事項（RFC7285]のセクション15）が適用される。たとえば、同じ信憑性と整合性の考慮事項（[RFC7285のセクション15.1）がまだ完全に適用されます。ALTOユーザーのプライバシーに関する同じ考察（[RFC7285のセクション15.4）もまだ完全に適用されます。
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.
この拡張機能によって提供されるカレンダー情報には、[RFC7285]で説明した3つのセキュリティ上の考慮事項についての追加の考慮事項が必要です。Alto（RFC7285のセクション15.5）。例えば、カレンダ内の将来ネットワーク情報を提供することによって、Altoサーバが利用できないが、関連情報がカレンダに既に提供されている場合、この拡張機能はALTOの可用性を改善することができる。
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.
ALTO情報の機密性のために、オペレータはこの拡張機能が新しいリスクを導入する可能性があることが認識しているべきであるため、悪意のあるALTOクライアントは、カレンダーを通じて予定されている将来のイベントのための情報を得ることができます。このような情報を所有すると、悪意のあるクライアントは、その負荷が高いと予想される時にネットワークへの大規模な接続を生成するためにそれを使用することができる。
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]".
このリスクを軽減するために、オペレータは悪意のあるクライアントまたは第三者に漏洩しているALTO情報のリスクを取ります。「保護戦略」（[RFC7285]のセクション15.3.2）で指定されているように、ALTOサーバはALTOクライアントを認証し、Man-In-The-Middle（MITM）攻撃を攻撃するようにトランスポート層セキュリティ（TLS）プロトコルを使用する必要があります。アルトカレンダーは不可能です。「認証と暗号化」（[RFC7285のセクション8.3.5]）このような解決策の可用性を確保します。「ALTOサーバの実装とALTOクライアントの実装と同様に、[RFC2818]の「HTTPS」URIスキームと[RFC5246]の[TLS）]をサポートする必要があることを指定します。
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.
前のメカニズムがすべてのセキュリティリスクに対処しないことを認識している必要があります。特に、有効な認証資格情報を所有している「悪意のあるクライアント」の場合には役立ちません。ここでの脅威は、正当なクライアントが攻撃者によって覆われているようになったことが、DDOS攻撃に参加するように依頼されているようになっていることです。カレンダー情報は、DDOS攻撃をPerpetateする場合を正確に知ることで貴重になります。異常な挙動を検出する監視システムなどのメカニズムが依然として必要とされている可能性があります。
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].
サーバーが、情報リソースに関連付けられているカレンダーオブジェクト配列の異なる要素でサーバーが同じコストタイプ名の発生を公開すると表示されます。この場合、アレイ内のどのカレンダオブジェクトが有効であるかをクライアントに理解する方法はありません。この文書の仕様は、この場合、クライアントがコストタイプ名を含む最初の遭遇カレンダーオブジェクト発生を使用することをお勧めします。しかしながら、クライアントは、無効なカレンダー値の使用に関連する誤ったガイダンスのリスクを回避することを望むかもしれない。このために、この文書の推奨事項の代わりとして、クライアントはコストタイプ名を含むCalendarAttributesオブジェクトの発生の全体を無視し、[RFC7285]を使用してこのコストタイプを照会することができます。
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.
次に、予測面を検討してください。ALTOコストカレンダーを搬送すると、複数の単価ALTOトランザクションと比較して、電線データ交換量を減らす傾向があります。カレンダーを使用したアプリケーションには、ALTOクライアントが毎回情報を照会する必要がなく、事前に接続を計画できる一連の時間依存値があります。さらに、カレンダー応答属性「繰り返し」は、提供されたときに、ALTOクライアントがこの属性によって示された期間中にカレンダーを照会する必要がないことを示すという追加のデータ交換を保存します。「事故」が起こらない場合にのみ当てはまります。
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.
個々のネットワーク事業者とアプリケーション事業者が前述の問題に対処するための独自のアプローチを選択することができるが、この文書は以下の考慮事項を推奨している。第1に、不安定性および取り扱いの不確実性を低減するための典型的なアプローチは、情報のタイムリーな更新を確実にすることである。セクション7で説明したように、SSEサービスは、サーバーとクライアントの両方でサポートされている場合に更新を処理できます。第二に、ネットワーク事業者が原価カレンダーを更新し、アプリケーションが更新に反応するときに、フィードバック効果を考慮する必要があります。これは、理論的解析[SelfiSh_RTG_2002]とインターネットベースの評価がある場合でも、協和的な動作が常に実質的な最適な結果を引き起こすわけではないことを示しています。
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エンコーディングに切り替わる必要があります。
[IEEE.754.2019] IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE 754-2019, DOI 10.1109/IEEESTD.2019.8766229, June 2019, <https://doi.org/10.1109/IEEESTD.2019.8766229>.
[IEEE.754.2019] IEEE、「浮動小数点演算のためのIEEE規格」、IEEE 754-2019、DOI 10.1109 / IEEESTD.2019.8766229、2019年6月、<https：//doi.org/10.1109/ieeEestd.2019.8766229>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T.およびE. Rescorla、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https：//www.rfc-editor.org/info/ 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, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[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, <https://www.rfc-editor.org/info/rfc7285>.
[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月、<https：//www.rfc-editor.org/info/rfc7285>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8189] Randriamasy, S., Roome, W., and N. Schwan, "Multi-Cost Application-Layer Traffic Optimization (ALTO)", RFC 8189, DOI 10.17487/RFC8189, October 2017, <https://www.rfc-editor.org/info/rfc8189>.
[RFC8189] Randriamasy、S.、Roomy、W.、およびSchwan、「多価格アプリケーション層交通最適化（ALTO）」、RFC 8189、DOI 10.17487 / RFC8189、2017年10月、<https：// www。rfc-editor.org/info/rfc8189>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[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, <https://www.rfc-editor.org/info/rfc8895>.
[RFC8895] Roome、W.およびY。ヤン、「アプリケーションレイヤトラフィック最適化（ALTO）」イベント（SSE） "、RFC 8895、DOI 10.17487 / RFC8895、2020年11月、<https：// www.rfc-editor.org / info / rfc8895>。
[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, <https://tools.ietf.org/html/ 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日、<https：//tools.ietf.org/html/ 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, <https://doi.org/10.1287/trsc.17.3.301>.
[BRAESS_PARADOX] Steinberg、R.およびW. Zangwill、「Braess 'Paradoxの有病率」、交通科学Vol。17、No.3、DOI 10.1287 / TRSC.17.3.301,1983、<https：//doi.org/10.1287/trsc.17.3.301>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] RESCORLA、E.、「HTTP over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https：//www.rfc-editor.org/info/rfc2818>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <https://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J.およびE.バーガー、「アプリケーションレイヤトラフィック最適化（ALTO）問題ステートメント」、RFC 5693、DOI 10.17487 / RFC 5693、2009年10月、<https：//www.rfc-editor.org/info/ 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, <https://www.rfc-editor.org/info/rfc6708>.
[RFC6708]キセル、S、ED。、PREVIDI、S.、Stiemerling、M.、Insight、R.、およびY. Yang、「アプリケーション層交通最適化（ALTO）要件」、RFC 6708、DOI 10.17487 / RFC6708、2012年9月、<https://www.rfc-editor.org/info/rfc6708>。
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7159] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、RFC 7159、DOI 10.17487 / RFC7159、2014年3月、<https：//www.rfc-editor.org/info/RFC7159>。
[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, <https://doi.org/10.1145/863955.863974>.
[Selfish_RTG_2003] Qiu、L.、Yang、Y.、Zhang、Y.、およびS.シェンカー、「インターネットのような環境での利己的なルーティング」、SIGCOMM '03、DOI 10.1145 / 863955.863974、<https：//doi.org/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)", <http://sense.es.net/overview>.
[Sense]科学高度科学計算研究（ASCR）プログラムのエネルギーオフィス、「エクスカルケル（SENSE）」、<http://sense.es.net/overview>。
[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, <https://doi.org/10.1016/j.future.2018.09.048>.
[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月、<https：//doi.org/10.1016/j.future.2018.09.048>。
Acknowledgments
謝辞
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フランス
Email: Sabine.Randriamasy@nokia-bell-labs.com
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アメリカ合衆国
Email: yry@cs.yale.edu
Qin Wu Huawei Yuhua District 101 Software Avenue Nanjing Jiangsu, 210012 China
Qin Wu Huawei Yuhua District 101ソフトウェアアベニュー南京江蘇省、210012中国
Email: sunseawq@huawei.com
Lingli Deng China Mobile China
Lingli Deng China Mobile China
Email: denglingli@chinamobile.com
Nico Schwan Thales Deutschland Lorenzstrasse 10 70435 Stuttgart Germany
Nico Schwan Thales Deutschland Lorenzstrasse 10 70435 Stuttgartドイツ
Email: nico.schwan@thalesgroup.com