[要約] RFC 9275 は、ALTO プロトコルの拡張であり、アプリケーションが数値/順序コスト値だけでなく、パスに関する詳細な情報に基づいてエンドポイントに接続することを可能にします。この拡張は、特定のネットワークコンポーネントによってパフォーマンスが影響を受けるアプリケーションにとって有用であり、トラフィックのボトルネックを回避するために共通リンクを避けることができます。
Internet Engineering Task Force (IETF) K. Gao
Request for Comments: 9275 Sichuan University
Category: Experimental Y. Lee
ISSN: 2070-1721 Samsung
S. Randriamasy
Nokia Bell Labs
Y. Yang
Yale University
J. Zhang
Tongji University
September 2022
An Extension for Application-Layer Traffic Optimization (ALTO): Path Vector
アプリケーション層トラフィック最適化の拡張（ALTO）：パスベクトル
Abstract
概要
This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost map and ALTO property map services so that an application can decide to which endpoint(s) to connect based not only on numerical/ordinal cost values but also on fine-grained abstract information regarding the paths. This is useful for applications whose performance is impacted by specific components of a network on the end-to-end paths, e.g., they may infer that several paths share common links and prevent traffic bottlenecks by avoiding such paths. This extension introduces a new abstraction called the "Abstract Network Element" (ANE) to represent these components and encodes a network path as a vector of ANEs. Thus, it provides a more complete but still abstract graph representation of the underlying network(s) for informed traffic optimization among endpoints.
このドキュメントは、基本アプリケーション層トラフィック最適化（ALTO）プロトコルの拡張です。ALTOコストマップとALTOプロパティマップサービスを拡張して、アプリケーションが数値/順序コスト値だけでなく、パスに関する微細に輝く抽象情報にも基づいて接続するエンドポイントを決定できるようにします。これは、エンドツーエンドのパス上のネットワークの特定のコンポーネントによってパフォーマンスが影響を受けるアプリケーションに役立ちます。たとえば、いくつかのパスが共通のリンクを共有し、そのようなパスを避けることでトラフィックのボトルネックを防ぐことができます。この拡張機能は、「抽象ネットワーク要素」（ANE）と呼ばれる新しい抽象化を導入して、これらのコンポーネントを表し、ANEのベクトルとしてネットワークパスをエンコードします。したがって、エンドポイント間の情報に基づいたトラフィック最適化のために、基礎となるネットワークのより完全ではあるが抽象的なグラフ表現を提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットコミュニティの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9275.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9275で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Terminology
4. Requirements and Use Cases
4.1. Design Requirements
4.2. Sample Use Cases
4.2.1. Exposing Network Bottlenecks
4.2.2. Resource Exposure for CDNs and Service Edges
5. Path Vector Extension: Overview
5.1. Abstract Network Element (ANE)
5.1.1. ANE Entity Domain
5.1.2. Ephemeral and Persistent ANEs
5.1.3. Property Filtering
5.2. Path Vector Cost Type
5.3. Multipart Path Vector Response
5.3.1. Identifying the Media Type of the Object Root
5.3.2. References to Part Messages
6. Specification: Basic Data Types
6.1. ANE Name
6.2. ANE Entity Domain
6.2.1. Entity Domain Type
6.2.2. Domain-Specific Entity Identifier
6.2.3. Hierarchy and Inheritance
6.2.4. Media Type of Defining Resource
6.3. ANE Property Name
6.4. Initial ANE Property Types
6.4.1. Maximum Reservable Bandwidth
6.4.2. Persistent Entity ID
6.4.3. Examples
6.5. Path Vector Cost Type
6.5.1. Cost Metric: "ane-path"
6.5.2. Cost Mode: "array"
6.6. Part Resource ID and Part Content ID
7. Specification: Service Extensions
7.1. Notation
7.2. Multipart Filtered Cost Map for Path Vector
7.2.1. Media Type
7.2.2. HTTP Method
7.2.3. Accept Input Parameters
7.2.4. Capabilities
7.2.5. Uses
7.2.6. Response
7.3. Multipart Endpoint Cost Service for Path Vector
7.3.1. Media Type
7.3.2. HTTP Method
7.3.3. Accept Input Parameters
7.3.4. Capabilities
7.3.5. Uses
7.3.6. Response
8. Examples
8.1. Sample Setup
8.2. Information Resource Directory
8.3. Multipart Filtered Cost Map
8.4. Multipart Endpoint Cost Service Resource
8.5. Incremental Updates
8.6. Multi-Cost
9. Compatibility with Other ALTO Extensions
9.1. Compatibility with Legacy ALTO Clients/Servers
9.2. Compatibility with Multi-Cost Extension
9.3. Compatibility with Incremental Update Extension
9.4. Compatibility with Cost Calendar Extension
10. General Discussion
10.1. Constraint Tests for General Cost Types
10.2. General Multi-Resource Query
11. Security Considerations
12. IANA Considerations
12.1. "ALTO Cost Metrics" Registry
12.2. "ALTO Cost Modes" Registry
12.3. "ALTO Entity Domain Types" Registry
12.4. "ALTO Entity Property Types" Registry
12.4.1. New ANE Property Type: Maximum Reservable Bandwidth
12.4.2. New ANE Property Type: Persistent Entity ID
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
Network performance metrics are crucial for assessing the Quality of Experience (QoE) of applications. The Application-Layer Traffic Optimization (ALTO) protocol allows Internet Service Providers (ISPs) to provide guidance, such as topological distances between different end hosts, to overlay applications. Thus, the overlay applications can potentially improve the perceived QoE by better orchestrating their traffic to utilize the resources in the underlying network infrastructure.
ネットワークパフォーマンスメトリックは、アプリケーションの経験の質（QOE）を評価するために重要です。アプリケーション層トラフィック最適化（ALTO）プロトコルにより、インターネットサービスプロバイダー（ISP）は、異なるエンドホスト間のトポロジ距離などのガイダンスを提供して、アプリケーションをオーバーレイできます。したがって、オーバーレイアプリケーションは、トラフィックをより適切に調整して、基礎となるネットワークインフラストラクチャのリソースを利用することにより、知覚されるQOEを改善する可能性があります。
The existing ALTO cost map (Section 11.2.3 of [RFC7285]) and Endpoint Cost Service (Section 11.5 of [RFC7285]) provide only cost information for an end-to-end path defined by its <source, destination> endpoints: the base protocol [RFC7285] allows the services to expose the topological distances of end-to-end paths, while various extensions have been proposed to extend the capability of these services, e.g., to express other performance metrics [ALTO-PERF-METRICS], to query multiple costs simultaneously [RFC8189], and to obtain time-varying values [RFC8896].
既存のALTOコストマップ（[RFC7285]のセクション11.2.3）およびエンドポイントコストサービス（[RFC7285]のセクション11.5）は、<ソース、宛先>エンドポイントによって定義されたエンドツーエンドパスのコスト情報のみを提供します。ベースプロトコル[RFC7285]により、サービスはエンドツーエンドパスのトポロジ距離を公開することができますが、これらのサービスの能力を拡張するために、他のパフォーマンスメトリックを表現するためにこれらのサービスの機能を拡張するためにさまざまな拡張が提案されています。複数のコストを同時に照会し[RFC8189]、時変値[RFC8896]を取得します。
While numerical/ordinal cost values for end-to-end paths provided by the existing extensions are sufficient to optimize the QoE of many overlay applications, the QoE of some overlay applications also depends on the properties of particular components on the paths. For example, job completion time, which is an important QoE metric for a large-scale data analytics application, is impacted by shared bottleneck links inside the carrier network, as link capacity may impact the rate of data input/output to the job. We refer to such components of a network as Abstract Network Elements (ANEs).
既存の拡張機能によって提供されるエンドツーエンドパスの数値/順序コスト値は、多くのオーバーレイアプリケーションのQOEを最適化するのに十分ですが、一部のオーバーレイアプリケーションのQOEは、パス上の特定のコンポーネントのプロパティにも依存します。たとえば、大規模なデータ分析アプリケーションの重要なQOEメトリックであるジョブ完了時間は、リンク容量がジョブへのデータ入力/出力のレートに影響を与える可能性があるため、キャリアネットワーク内の共有ボトルネックリンクの影響を受けます。ネットワークのそのようなコンポーネントを抽象的なネットワーク要素（ANE）と呼びます。
Predicting such information can be very complex without the help of ISPs; for example, [BOXOPT] has shown that finding the optimal bandwidth reservation for multiple flows can be NP-hard without further information than whether a reservation succeeds. With proper guidance from the ISP, an overlay application may be able to schedule its traffic for better QoE. In the meantime, it may be helpful as well for ISPs if applications could avoid using bottlenecks or challenging the network with poorly scheduled traffic.
そのような情報を予測することは、ISPの助けがなければ非常に複雑です。たとえば、[Boxopt]は、複数のフローの最適な帯域幅予約を見つけることは、予約が成功するかどうかよりも詳細な情報なしでNPハードになる可能性があることを示しています。ISPからの適切なガイダンスにより、オーバーレイアプリケーションはトラフィックをスケジュールすることができる場合があります。それまでの間、アプリケーションがボトルネックの使用やスケジュールの低いトラフィックでネットワークに挑戦することを避けることができない場合、ISPにとっても役立つかもしれません。
Despite the claimed benefits, ISPs are not likely to expose raw details on their network paths: first because ISPs have requirements to hide their network topologies, second because these details may increase volume and computation overhead, and last because applications do not necessarily need all the network path details and are likely not able to understand them.
主張された利点にもかかわらず、ISPはネットワークパスの生の詳細を公開する可能性は低いです。1つ目は、ISPがネットワークトポロジを隠すための要件を持っているためです。ネットワークパスの詳細であり、それらを理解できない可能性があります。
Therefore, it is beneficial for both ISPs and applications if an ALTO server provides ALTO clients with an "abstract network state" that provides the necessary information to applications, while hiding network complexity and confidential information. An "abstract network state" is a selected set of abstract representations of ANEs traversed by the paths between <source, destination> pairs combined with properties of these ANEs that are relevant to the overlay applications' QoE. Both an application via its ALTO client and the ISP via the ALTO server can achieve better confidentiality and resource utilization by appropriately abstracting relevant ANEs. Server scalability can also be improved by combining ANEs and their properties in a single response.
したがって、ALTOサーバーがALTOクライアントに必要な情報をアプリケーションに提供し、ネットワークの複雑さと機密情報を隠している「抽象ネットワーク状態」を提供する場合、ISPとアプリケーションの両方にとって有益です。「抽象ネットワーク状態」は、オーバーレイアプリケーションのQOEに関連するこれらのANEのプロパティと組み合わせた<ソース、宛先>ペアの間のパスによって横断されるANEの抽象表現の選択されたセットです。ALTOクライアントを介したアプリケーションとALTOサーバーを介したISPの両方は、適切に関連するANEを適切に抽象化することにより、より良い機密性とリソース利用を実現できます。サーバーのスケーラビリティは、ANEとその特性を単一の応答で組み合わせることで改善することもできます。
This document extends the ALTO base protocol [RFC7285] to allow an ALTO server to convey "abstract network state" for paths defined by their <source, destination> pairs. To this end, it introduces a new cost type called a "Path Vector", following the cost metric registration specified in [RFC7285] and the updated cost mode registration specified in [RFC9274]. A Path Vector is an array of identifiers that identifies an ANE, which can be associated with various properties. The associations between ANEs and their properties are encoded in an ALTO information resource called the "entity property map", which is specified in [RFC9240].
このドキュメントは、ALTOベースプロトコル[RFC7285]を拡張して、ALTOサーバーが<Source、Destination>ペアで定義されたパスの「抽象ネットワーク状態」を伝達できるようにします。この目的のために、[RFC7285]で指定されたコストメトリック登録と[RFC9274]で指定された更新されたコストモード登録に続いて、「パスベクトル」と呼ばれる新しいコストタイプを導入します。パスベクトルは、さまざまな特性に関連付けられる可能性のあるANEを識別する識別子の配列です。ANEとそのプロパティとの関連は、[RFC9240]で指定されている「エンティティプロパティマップ」と呼ばれるALTO情報リソースにエンコードされています。
For better confidentiality, this document aims to minimize information exposure of an ALTO server when providing Path Vector services. In particular, this document enables the capability, and also recommends that 1) ANEs be constructed on demand and 2) an ANE only be associated with properties that are requested by an ALTO client. A Path Vector response involves two ALTO maps: the cost map, which contains the Path Vector results; and the up-to-date entity property map, which contains the properties requested for these ANEs. To enforce consistency and improve server scalability, this document uses the "multipart/related" content type as defined in [RFC2387] to return the two maps in a single response.
より良い機密性を得るために、このドキュメントは、パスベクトルサービスを提供する際にALTOサーバーの情報露出を最小限に抑えることを目的としています。特に、このドキュメントは機能を有効にし、1）ANEをオンデマンドで構築することを推奨し、2）ANEはALTOクライアントによって要求されるプロパティにのみ関連付けられます。パスベクトル応答には、2つのALTOマップが含まれます。パスベクトルの結果を含むコストマップ。また、これらのANEに要求されたプロパティを含む最新のエンティティプロパティマップ。一貫性を実施し、サーバーのスケーラビリティを向上させるために、このドキュメントでは、[RFC2387]で定義されている「マルチパート/関連」コンテンツタイプを使用して、単一の応答で2つのマップを返します。
As a single ISP may not have knowledge of the full Internet paths between arbitrary endpoints, this document is mainly applicable when
単一のISPは、任意のエンドポイント間の完全なインターネットパスの知識を持っていない可能性があるため、このドキュメントは主に適用可能です
* there is a single ISP between the requested source and destination Provider-defined Identifiers (PIDs) or endpoints -- for example, ISP-hosted Content Delivery Network (CDN) / edge, tenant interconnection in a single public cloud platform, etc., or
* 要求されたソースと宛先プロバイダー定義の識別子（PIDS）またはエンドポイントの間には単一のISPがあります。たとえば、ISPホストコンテンツ配信ネットワーク（CDN） /エッジ、単一のパブリッククラウドプラットフォームでのテナント相互接続、または
* the Path Vectors are generated from end-to-end measurement data.
* パスベクトルは、エンドツーエンドの測定データから生成されます。
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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document extends the ALTO base protocol [RFC7285] and the entity property map extension [RFC9240]. In addition to the terms defined in those documents, this document also uses the following terms:
このドキュメントは、ALTOベースプロトコル[RFC7285]とエンティティプロパティマップ拡張[RFC9240]を拡張します。これらのドキュメントで定義されている用語に加えて、このドキュメントは次の用語も使用しています。
Abstract Network Element (ANE): An abstract representation for a component in a network that handles data packets and whose properties can potentially have an impact on the end-to-end performance of traffic. An ANE can be a physical device such as a router, a link, or an interface; or an aggregation of devices such as a subnetwork or a data center.
要約ネットワーク要素（ANE）：データパケットを処理するネットワーク内のコンポーネントの要約表現と、そのプロパティがトラフィックのエンドツーエンドのパフォーマンスに影響を与える可能性があります。ANEは、ルーター、リンク、インターフェイスなどの物理デバイスにすることができます。または、サブネットワークやデータセンターなどのデバイスの集約。
The definition of an ANE is similar to that for a network element as defined in [RFC2216] in the sense that they both provide an abstract representation of specific components of a network. However, they have different criteria on how these particular components are selected. Specifically, a network element requires the components to be capable of exercising QoS control, while an ANE only requires the components to have an impact on end-to-end performance.
ANEの定義は、ネットワークの特定のコンポーネントの抽象表現を提供するという意味で、[RFC2216]で定義されているネットワーク要素の定義と類似しています。ただし、これらの特定のコンポーネントがどのように選択されているかについては、異なる基準があります。具体的には、ネットワーク要素にはコンポーネントがQoS制御を行使できるようにする必要がありますが、ANEはコンポーネントにエンドツーエンドのパフォーマンスに影響を与えるだけです。
ANE name: A string that uniquely identifies an ANE in a specific scope. An ANE can be constructed either statically in advance or on demand based on the requested information. Thus, different ANEs may only be valid within a particular scope, either ephemeral or persistent. Within each scope, an ANE is uniquely identified by an ANE name, as defined in Section 6.1. Note that an ALTO client must not assume ANEs in different scopes but with the same ANE name refer to the same component(s) of the network.
ANE名：特定の範囲でANEを一意に識別する文字列。ANEは、要求された情報に基づいて、静的に事前またはオンデマンドで構築できます。したがって、異なるANEは、一時的または永続的な特定の範囲内でのみ有効である可能性があります。各スコープ内で、セクション6.1で定義されているように、ANEはANE名によって一意に識別されます。ALTOクライアントは、異なるスコープでANEを想定してはなりませんが、同じANE名でネットワークの同じコンポーネントを参照することに注意してください。
Path Vector (or ANE Path Vector): Refers to a JSON array of ANE names. It is a generalization of a BGP path vector. While a standard BGP path vector (Section 5.1.2 of [RFC4271]) specifies a sequence of Autonomous Systems (ASes) for a destination IP prefix, the Path Vector defined in this extension specifies a sequence of ANEs for either 1) a source PID and a destination PID, as in the CostMapData object (Section 11.2.3.6 of [RFC7285]) or 2) a source endpoint and a destination endpoint, as in the EndpointCostMapData object (Section 11.5.1.6 of [RFC7285]).
Path Vector（またはANE PATH VECTOR）：ANE名のJSON配列を指します。これは、BGPパスベクトルの一般化です。標準のBGPパスベクトル（[RFC4271]のセクション5.1.2）は、宛先IPプレフィックスの自律システム（ASES）のシーケンスを指定しますが、この拡張機能で定義されているパスベクトルは、いずれかのANESのシーケンスを指定します。宛先PID（[RFC7285]のセクション11.2.3.6）または2）のように、エンドポイントコストマプダタオブジェクト（[RFC7285]のセクション11.5.1.6）のようなソースエンドポイントと宛先エンドポイント。
Path Vector resource: An ALTO information resource (Section 8.1 of [RFC7285]) that supports the extension defined in this document.
パスベクトルリソース：このドキュメントで定義されている拡張機能をサポートするALTO情報リソース（[RFC7285]のセクション8.1）。
Path Vector cost type: A special cost type, which is specified in Section 6.5. When this cost type is present in an Information Resource Directory (IRD) entry, it indicates that the information resource is a Path Vector resource. When this cost type is present in a filtered cost map request or an Endpoint Cost Service request, it indicates that each cost value must be interpreted as a Path Vector.
パスベクトルコストタイプ：セクション6.5で指定されている特別なコストタイプ。このコストタイプが情報リソースディレクトリ（IRD）エントリに存在する場合、情報リソースがパスベクトルリソースであることを示します。このコストタイプがフィルタリングされたコストマップリクエストまたはエンドポイントコストサービスリクエストに存在する場合、各コスト値をパスベクトルとして解釈する必要があることを示します。
Path Vector request: The POST message sent to an ALTO Path Vector resource.
パスベクトルリクエスト：Alto Path Vectorリソースに送信された投稿メッセージ。
Path Vector response: Refers to the multipart/related message returned by a Path Vector resource.
パスベクトル応答：パスベクトルリソースによって返されるマルチパート/関連メッセージを指します。
This section gives an illustrative example of how an overlay application can benefit from the extension defined in this document.
このセクションでは、オーバーレイアプリケーションがこのドキュメントで定義されている拡張機能からどのように利益を得るかを示す例を示します。
Assume that an application has control over a set of flows, which may go through shared links/nodes and share bottlenecks. The application seeks to schedule the traffic among multiple flows to get better performance. The constraints of feasible rate allocations of those flows will benefit the scheduling. However, cost maps as defined in [RFC7285] cannot reveal such information.
アプリケーションが一連のフローを制御していると仮定します。これは、共有リンク/ノードを通過してボトルネックを共有する場合があります。このアプリケーションは、パフォーマンスを向上させるために、複数のフロー間のトラフィックをスケジュールしようとしています。これらのフローの実行可能レート割り当ての制約は、スケジューリングに利益をもたらします。ただし、[RFC7285]で定義されているコストマップは、そのような情報を明らかにすることはできません。
Specifically, consider the example network shown in Figure 1. The network has seven switches ("sw1" to "sw7") forming a dumbbell topology. Switches "sw1", "sw2", "sw3", and "sw4" are access switches, and "sw5-sw7" form the backbone. End hosts "eh1" to "eh4" are connected to access switches "sw1" to "sw4", respectively. Assume that the bandwidth of link "eh1 -> sw1" and link "sw1 -> sw5" is 150 Mbps and the bandwidth of the other links is 100 Mbps.
具体的には、図1に示す例の例を考えてみましょう。ネットワークには、ダンベルトポロジーを形成する7つのスイッチ（「SW1」から「SW7」）があります。スイッチ「SW1」、「SW2」、「SW3」、および「SW4」はアクセススイッチ、「SW5-SW7」がバックボーンを形成します。エンドホスト「EH1」から「EH4」は、それぞれアクセススイッチ「SW1」から「SW4」に接続されています。リンク「EH1-> SW1」とリンク「SW1-> SW5」の帯域幅が150 Mbpsであり、他のリンクの帯域幅が100 Mbpsであると仮定します。
+-----+
| |
--+ sw6 +--
/ | | \
PID1 +-----+ / +-----+ \ +-----+ PID2
eh1__| |_ / \ ____| |__eh2
192.0.2.2 | sw1 | \ +--|--+ +--|--+ / | sw2 | 192.0.2.3
+-----+ \ | | | |/ +-----+
\_| sw5 +---------+ sw7 |
PID3 +-----+ / | | | |\ +-----+ PID4
eh3__| |__/ +-----+ +-----+ \____| |__eh4
192.0.2.4 | sw3 | | sw4 | 192.0.2.5
+-----+ +-----+
bw(eh1--sw1) = bw(sw1--sw5) = 150 Mbps
bw(eh2--sw2) = bw(eh3--sw3) = bw(eh4--sw4) = 100 Mbps
bw(sw1--sw5) = bw(sw3--sw5) = bw(sw2--sw7) = bw(sw4--sw7) = 100 Mbps
bw(sw5--sw6) = bw(sw5--sw7) = bw(sw6--sw7) = 100 Mbps
Figure 1: Raw Network Topology
図1：Raw Networkトポロジ
The base ALTO topology abstraction of the network is shown in Figure 2. Assume that the cost map returns a hypothetical cost type representing the available bandwidth between a source and a destination.
ネットワークのベースALTOトポロジの抽象化を図2に示します。コストマップが、ソースと宛先の間の利用可能な帯域幅を表す仮想コストタイプを返すと仮定します。
+----------------------+
{eh1} | | {eh2}
PID1 | | PID2
+------+ +------+
| |
| |
{eh3} | | {eh4}
PID3 | | PID4
+------+ +------+
| |
+----------------------+
Figure 2: Base Topology Abstraction
図2：基本トポロジの抽象化
Now, assume that the application wants to maximize the total rate of
the traffic among a set of <source, destination> pairs -- say, "eh1
-> eh2" and "eh1 -> eh4". Let "x" denote the transmission rate of
"eh1 -> eh2" and "y" denote the rate of "eh1 -> eh4". The objective
function is
max(x + y).
max（x y）。
With the ALTO cost map, the costs between PID1 and PID2 and between PID1 and PID4 will both be 100 Mbps. The client can get a capacity region of
ALTOコストマップでは、PID1とPID2とPID1とPID4の間のコストは両方とも100 Mbpsになります。クライアントは容量領域を取得できます
x <= 100 Mbps y <= 100 Mbps.
x <= 100 mbps y <= 100 mbps。
With this information, the client may mistakenly think it can achieve a maximum total rate of 200 Mbps. However, this rate is infeasible, as there are only two potential cases:
この情報を使用すると、クライアントは誤って200 Mbpsの最大合計率を達成できると考える場合があります。ただし、潜在的なケースは2つしかないため、このレートは実行不可能です。
Case 1: "eh1 -> eh2" and "eh1 -> eh4" take different path segments from "sw5" to "sw7". For example, if "eh1 -> eh2" uses path "eh1 -> sw1 -> sw5 -> sw6 -> sw7 -> sw2 -> eh2" and "eh1 -> eh4" uses path "eh1 -> sw1 -> sw5 -> sw7 -> sw4 -> eh4", then the shared bottleneck links are "eh1 -> sw1" and "sw1 -> sw5". In this case, the capacity region is:
ケース1：「EH1-> EH2」および「EH1-> EH4」は、「SW5」から「SW7」までの異なるパスセグメントを取ります。たとえば、「eh1-> eh2」がパスを使用する場合、 "eh1-> sw1-> sw5-> sw6-> sw7-> sw7-> sw2-> eh2"および「eh1-> eh4」はパスを使用します "eh1-> sw5> sw5 - > sw7-> sw4-> eh4 "、共有されたボトルネックリンクは「eh1-> sw1」および「sw1-> sw5」です。この場合、容量領域は次のとおりです。
x <= 100 Mbps
y <= 100 Mbps
x + y <= 150 Mbps
and the real optimal total rate is 150 Mbps.
そして、実際の最適な合計率は150 Mbpsです。
Case 2: "eh1 -> eh2" and "eh1 -> eh4" take the same path segment from "sw5" to "sw7". For example, if "eh1 -> eh2" uses path "eh1 -> sw1 -> sw5 -> sw7 -> sw2 -> eh2" and "eh1 -> eh4" also uses path "eh1 -> sw1 -> sw5 -> sw7 -> sw4 -> eh4", then the shared bottleneck link is "sw5 -> sw7". In this case, the capacity region is:
ケース2：「EH1-> EH2」および「EH1-> EH4」は、「SW5」から「SW7」に同じパスセグメントを取ります。たとえば、「eh1-> eh2」がパスを使用する場合、 "eh1-> sw1-> sw5-> sw7-> sw2-> eh2"および「eh1-> eh4」もパスを使用します "eh1-> sw1-> sw5->SW7-> SW4-> EH4 "、共有ボトルネックリンクは「SW5-> SW7」です。この場合、容量領域は次のとおりです。
x <= 100 Mbps
y <= 100 Mbps
x + y <= 100 Mbps
and the real optimal total rate is 100 Mbps.
そして、実際の最適な総レートは100 Mbpsです。
Clearly, with more accurate and fine-grained information, the application can better predict its traffic and may orchestrate its resources accordingly. However, to provide such information, the network needs to expose abstract information beyond the simple cost map abstraction. In particular:
明らかに、より正確で微調整された情報により、アプリケーションはそのトラフィックをよりよく予測することができ、それに応じてリソースを調整することができます。ただし、そのような情報を提供するには、ネットワークは単純なコストマップ抽象化を超えて抽象情報を公開する必要があります。特に：
* The ALTO server must expose abstract information about the network paths that are traversed by the traffic between a source and a destination beyond a simple numerical value, which allows the overlay application to distinguish between Cases 1 and 2 and to compute the optimal total rate accordingly.
* ALTOサーバーは、ソースと宛先の間のトラフィックが単純な数値値を超えて横断するネットワークパスに関する抽象情報を公開する必要があります。これにより、オーバーレイアプリケーションはケース1と2を区別し、それに応じて最適な総レートを計算できます。
* The ALTO server must allow the client to distinguish the common ANE shared by "eh1 -> eh2" and "eh1 -> eh4", e.g., "eh1--sw1" and "sw1--sw5" in Case 1.
* ALTOサーバーは、クライアントが「EH1-> EH2」および「EH1-> EH4」、例えば「EH1 - SW1」および「SW1 - SW5」で共有される一般的なANEを区別できるようにする必要があります。
* The ALTO server must expose abstract information on the properties of the ANEs used by "eh1 -> eh2" and "eh1 -> eh4". For example, an ALTO server can either expose the available bandwidth between "eh1--sw1", "sw1--sw5", "sw5--sw7", "sw5--sw6", "sw6--sw7", "sw7--sw2", "sw7--sw4", "sw2--eh2", "sw4--eh4" in Case 1 or expose three abstract elements "A", "B", and "C", which represent the linear constraints that define the same capacity region in Case 1.
* ALTOサーバーは、「EH1-> EH2」および「EH1-> EH4」で使用されるANEのプロパティに関する抽象情報を公開する必要があります。たとえば、ALTOサーバーは、「eh1 - sw1」、「sw1 - sw5」、「sw5」、「sw7」、 "sw5、sw6"、 "sw6、sw7"、 "sw7の間で利用可能な帯域幅を公開できます。-SW2 "、" sw7 - sw4 "、" sw2-eh2 "、" sw4-eh4 "on case 1または露出" a "、" b "、および" c "、線形を表す「c」ケース1で同じ容量領域を定義する制約。
In general, we can conclude that to support the use case for multiple flow scheduling, the ALTO framework must be extended to satisfy the following additional requirements (ARs):
一般に、複数のフロースケジューリングのユースケースをサポートするには、以下の追加要件（ARS）を満たすためにALTOフレームワークを拡張する必要があると結論付けることができます。
AR1: An ALTO server must provide the ANEs that are important for assessing the QoE of the overlay application on the path of a <source, destination> pair.
AR1：ALTOサーバーは、<ソース、宛先>ペアのパスでオーバーレイアプリケーションのQOEを評価するために重要なANEを提供する必要があります。
AR2: An ALTO server must provide information to identify how ANEs are shared on the paths of different <source, destination> pairs.
AR2：ALTOサーバーは、異なる<ソース、宛先>ペアのパスでANEがどのように共有されるかを特定するための情報を提供する必要があります。
AR3: An ALTO server must provide information on the properties that are important for assessing the QoE of the application for ANEs.
AR3：ALTOサーバーは、ANESのアプリケーションのQOEを評価するために重要なプロパティに関する情報を提供する必要があります。
The extension defined in this document specifies a solution to expose such abstract information.
このドキュメントで定義されている拡張機能は、このような抽象情報を公開するソリューションを指定しています。
While the problem related to multiple flow scheduling is used to help identify the additional requirements, the extension defined in this document can be applied to a wide range of applications. This section highlights some of the reported use cases.
複数のフロースケジューリングに関連する問題は、追加の要件を特定するために使用されますが、このドキュメントで定義されている拡張機能は、広範囲のアプリケーションに適用できます。このセクションでは、報告されたユースケースの一部を強調しています。
One important use case for the Path Vector extension is to expose network bottlenecks. Applications that need to perform large-scale data transfers can benefit from being aware of the resource constraints exposed by this extension even if they have different objectives. One such example is the Worldwide LHC Computing Grid (WLCG) (where "LHC" means "Large Hadron Collider"), which is the largest example of a distributed computation collaboration in the research and education world.
パスベクトル拡張の重要なユースケースの1つは、ネットワークボトルネックを公開することです。大規模なデータ転送を実行する必要があるアプリケーションは、異なる目的がある場合でも、この拡張機能によって公開されるリソースの制約を認識することで利益を得ることができます。そのような例の1つは、世界のLHCコンピューティンググリッド（WLCG）（「LHC」は「大型ハドロンコリダー」を意味する）です。これは、研究と教育の世界で分散した計算コラボレーションの最大の例です。
Figure 3 illustrates an example of using an ALTO Path Vector as an interface between the job optimizer for a data analytics system and the network manager. In particular, we assume that the objective of the job optimizer is to minimize the job completion time.
図3は、データ分析システムとネットワークマネージャーのジョブオプティマイザー間のインターフェイスとしてALTO PATHベクトルを使用する例を示しています。特に、ジョブオプティマイザーの目的は、ジョブの完了時間を最小限に抑えることであると想定しています。
In such a setting, the network-aware job optimizer (e.g., [CLARINET]) takes a query and generates multiple query execution plans (QEPs). It can encode the QEPs as Path Vector requests that are sent to an ALTO server. The ALTO server obtains the routing information for the flows in a QEP and finds links, routers, or middleboxes (e.g., a stateful firewall) that can potentially become bottlenecks for the QEP (e.g., see [NOVA] and [G2] for mechanisms to identify bottleneck links under different settings). The resource constraint information is encoded in a Path Vector response and returned to the ALTO client.
このような設定では、ネットワーク認識ジョブオプティマイザー（[クラリネット]など）がクエリを取得し、複数のクエリ実行計画（QEPS）を生成します。QEPSをALTOサーバーに送信するPATHベクトル要求としてエンコードできます。ALTOサーバーは、QEPのフローのルーティング情報を取得し、QEPのボトルネックになる可能性のあるリンク、ルーター、またはミドルボックス（ステートフルファイアウォールなど）を見つけます（例：[NOVA]および[G2]を参照してください。さまざまな設定でボトルネックリンクを識別します）。リソース制約情報は、パスベクトル応答でエンコードされ、ALTOクライアントに返されます。
With the network resource constraints, the job optimizer may choose the QEP with the optimal job completion time to be executed. It must be noted that the ALTO framework itself does not offer the capability to control the traffic. However, certain network managers may offer ways to enforce resource guarantees, such as on-demand tunnels (e.g., [SWAN]), demand vectors (e.g., [HUG], [UNICORN]), etc. The traffic control interfaces and mechanisms are out of scope for this document.
ネットワークリソースの制約により、ジョブオプティマイザーは、実行する最適なジョブ完了時間を備えたQEPを選択できます。ALTOフレームワーク自体は、トラフィックを制御する機能を提供しないことに注意する必要があります。ただし、特定のネットワークマネージャーは、オンデマンドトンネル（[スワン]など）、需要ベクトル（[hug]、[unicorn]）などのリソース保証を実施する方法を提供する場合があります。トラフィックコントロールインターフェイスとメカニズムはこのドキュメントの範囲外。
Data schema Queries
| |
\ /
+-------------+ +-----------------+
| ALTO Client | <===============> | Job Optimizer |
+-------------+ +-----------------+
PV | ^ PV |
Request | | Response |
| | On-demand resource |
(Potential | | (Network allocation, demand |
Data | | Resource vectors, etc. |
Transfers) | | Constraints) (Non-ALTO interfaces)|
v | v
+-------------+ +-----------------+
| ALTO Server | <===============> | Network Manager |
+-------------+ +-----------------+
/ | \
| | |
WAN DC1 DC2
Figure 3: Example Use Case for Data Analytics
図3：データ分析の例のユースケース
Another example is illustrated in Figure 4. Consider a network consisting of multiple sites and a non-blocking core network, i.e., the links in the core network have sufficient bandwidth that they will not become a bottleneck for the data transfers.
別の例を図4に示します。複数のサイトと非ブロッキングコアネットワークで構成されるネットワークを検討します。つまり、コアネットワークのリンクには、データ転送のボトルネックにならないほど十分な帯域幅があります。
Ongoing transfers New transfer requests
\----\ |
| |
v v
+-------------+ +---------------+
| ALTO Client | <===========> | Data Transfer |
+-------------+ | Scheduler |
^ | ^ | PV Request +---------------+
| | | \--------------\
| | \--------------\ |
| v PV Response | v
+-------------+ +-------------+
| ALTO Server | | ALTO Server |
+-------------+ +-------------+
|| ||
+---------+ +---------+
| Network | | Network |
| Manager | | Manager |
+---------+ +---------+
. .
. _~_ __ . . .
. ( )( ) .___
~v~v~ /--( )------------( )
( )-----/ ( ) ( )
~w~w~ ~^~^~^~ ~v~v~
Site 1 Non-blocking Core Site 2
Figure 4: Example Use Case for Cross-Site Bottleneck Discovery
図4：クロスサイトのボトルネックの発見のためのユースケースの例
With the Path Vector extension, a site can reveal the bottlenecks inside its own network with necessary information (such as link capacities) to the ALTO client, instead of providing the full topology and routing information, or no bottleneck information at all. The bottleneck information can be used to analyze the impact of adding/removing data transfer flows, e.g., using the framework defined in [G2]. For example, assume that hosts "a", "b", and "c" are in Site 1 and hosts "d", "e", and "f" are in Site 2, and there are three flows in two sites: "a -> b", "c -> d", and "e -> f" (Figure 5).
パスベクトル拡張機能を使用すると、サイトは、完全なトポロジとルーティング情報を提供する代わりに、またはボトルネック情報をまったく提供する代わりに、必要な情報（リンク容量など）を使用して、独自のネットワーク内のボトルネットをALTOクライアントに表示することができます。ボトルネック情報は、[G2]で定義されたフレームワークを使用して、データ転送フローの追加/削除の影響を分析するために使用できます。たとえば、ホスト「A」、「B」、および「C」がサイト1にあり、「D」、「E」をホストし、「F」がサイト2にあると仮定し、2つのサイトに3つのフローがあります。「A-> B」、「C-> D」、および「E-> F」（図5）。
Site 1:
サイト1：
[c]
.
........................................> [d]
+---+ 10 Gbps +---+ 10 Gbps +----+ 50 Gbps
| A |---------| B |---------| GW |--------- Core
+---+ +---+ +----+
...................
. .
. v
[a] [b]
Site 2:
サイト2：
[d] <........................................ [c]
+---+ 5 Gbps +---+ 10 Gbps +----+ 20 Gbps
| X |--------| Y |---------| GW |--------- Core
+---+ +---+ +----+
....................
. .
. v
[e] [f]
Figure 5: Example: Three Flows in Two Sites
図5：例：2つのサイトに3つのフローが流れます
For these flows, Site 1 returns:
これらのフローの場合、サイト1が返されます。
a: { b: [ane1] },
c: { d: [ane1, ane2, ane3] }
ane1: bw = 10 Gbps (link: A->B)
ane2: bw = 10 Gbps (link: B->GW)
ane3: bw = 50 Gbps (link: GW->Core)
and Site 2 returns:
およびサイト2の返品：
c: { d: [anei, aneii, aneiii] }
e: { f: [aneiv] }
anei: bw = 5 Gbps (link Y->X)
aneii: bw = 10 Gbps (link GW->Y)
aneiii: bw = 20 Gbps (link Core->GW)
aneiv: bw = 10 Gbps (link Y->GW)
With this information, the data transfer scheduler can use algorithms such as the theory on bottleneck structure [G2] to predict the potential throughput of the flows.
この情報を使用すると、データ転送スケジューラは、ボトルネック構造の理論[G2]などのアルゴリズムを使用して、フローの潜在的なスループットを予測できます。
At the time of this writing, a growing trend in today's applications is to bring storage and computation closer to the end users for better QoE, such as CDNs, augmented reality / virtual reality, and cloud gaming, as reported in various documents (e.g., [SEREDGE] and [MOWIE]). ISPs may deploy multiple layers of CDN caches or, more generally, service edges, with different latencies and available resources, including the number of CPU cores, memory, and storage.
この執筆時点で、今日のアプリケーションの成長傾向は、さまざまなドキュメントで報告されているように、CDN、拡張現実 /仮想現実、クラウドゲームなど、より良いQOEのためにエンドユーザーにストレージと計算を近づけることです（例えば、[Seredge]および[Mowie]）。ISPは、CPUコア、メモリ、ストレージの数を含むさまざまなレイテンシと利用可能なリソースを備えた、CDNキャッシュの複数の層、またはより一般的にはサービスエッジを展開する場合があります。
For example, Figure 6 illustrates a typical edge-cloud scenario where memory is measured in gigabytes (GB) and storage is measured in terabytes (TB). The "on-premise" edge nodes are closest to the end hosts and have the lowest latency, and the site-radio edge node and access central office (CO) have higher latencies but more available resources.
たとえば、図6は、ギガバイト（GB）でメモリが測定され、ストレージがテラバイト（TB）で測定される典型的なエッジクラウドシナリオを示しています。「オンプレミス」エッジノードは、エンドホストに最も近く、最低のレイテンシを持ち、サイトラジオエッジノードとアクセスセントラルオフィス（CO）はレイテンシが高くなりますが、より多くのリソースがあります。
+-------------+ +----------------------+
| ALTO Client | <==========> | Application Provider |
+-------------+ +----------------------+
PV | ^ PV |
Request | | Response | Resource allocation,
| | | service establishment,
(End hosts | | (Edge nodes | etc.
and cloud | | and metrics) |
servers) | | |
v | v
+-------------+ +---------------------+
| ALTO Server | <=========> | Cloud-Edge Provider |
+-------------+ +---------------------+
____________________________________/\___________
/ \
| (((o |
|
/_\ _~_ __ __
a (/\_/\) ( ) ( )~( )_
\ /------( )---------( )----\\---( )
_|_ / (______) (___) ( )
|_| -/ Site-radio Access CO (__________)
/---\ Edge Node 1 | Cloud DC
On premise |
/---------/
(((o /
| /
Site-radio /_\ /
Edge Node 2(/\_/\)-----/
/(_____)\
___ / \ ---
b--|_| -/ \--|_|--c
/---\ /---\
On premise On premise
Figure 6: Example Use Case for Service Edge Exposure
図6：サービスエッジ露出のためのユースケースの例
With the extension defined in this document, an ALTO server can selectively reveal the CDNs and service edges that reside along the paths between different end hosts and/or the cloud servers, together with their properties (e.g., storage capabilities or Graphics Processing Unit (GPU) capabilities) and available Service Level Agreement (SLA) plans. See Figure 7 for an example where the query is made for sources [a, b] and destinations [b, c, DC]. Here, each ANE represents a service edge, and the properties include access latency, available resources, etc. Note that the properties here are only used for illustration purposes and are not part of this extension.
このドキュメントで拡張機能が定義されているため、ALTOサーバーは、異なるエンドホストおよび/またはクラウドサーバーの間のパスに沿って存在するCDNとサービスエッジを選択的に明らかにし、プロパティ（例：ストレージ機能またはグラフィックス処理ユニット（GPU））機能）および利用可能なサービスレベル契約（SLA）計画。ソース[A、B]および宛先[B、C、DC]のクエリが作成されている例については、図7を参照してください。ここでは、各ANEはサービスエッジを表し、プロパティにはアクセスレイテンシ、利用可能なリソースなどが含まれます。ここのプロパティは、イラストの目的でのみ使用され、この拡張機能の一部ではないことに注意してください。
a: { b: [ane1, ane2, ane3, ane4, ane5],
c: [ane1, ane2, ane3, ane4, ane6],
DC: [ane1, ane2, ane3] }
b: { c: [ane5, ane4, ane6], DC: [ane5, ane4, ane3] }
ane1: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(On premise, a)
ane2: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
(Site-radio Edge Node 1)
ane3: latency = 100 ms cpu = 8 memory = 128 GB storage = 100 TB
(Access CO)
ane4: latency = 20 ms cpu = 4 memory = 8 GB storage = 10 TB
(Site-radio Edge Node 2)
ane5: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(On premise, b)
ane6: latency = 5 ms cpu = 2 memory = 8 GB storage = 10 TB
(On premise, c)
Figure 7: Example Service Edge Query Results
図7：サンプルサービスエッジクエリの結果
With the service edge information, an ALTO client may better conduct CDN request routing or offload functionalities from the user equipment to the service edge, with considerations in place for customized quality of experience.
サービスエッジ情報を使用すると、ALTOクライアントは、カスタマイズされた経験のために考慮事項があり、ユーザー機器からサービスエッジまでのCDN要求ルーティングまたはオフロード機能をより適切に実施する場合があります。
This section provides a non-normative overview of the Path Vector extension defined in this document. It is assumed that readers are familiar with both the base protocol [RFC7285] and the entity property map extension [RFC9240].
このセクションでは、このドキュメントで定義されているパスベクトル拡張の非規範的な概要を示します。読者は、基本プロトコル[RFC7285]とエンティティプロパティマップ拡張[RFC9240]の両方に精通していると想定されています。
To satisfy the additional requirements listed in Section 4.1, this extension:
セクション4.1にリストされている追加要件を満たすために、この拡張機能：
1. introduces the concept of an ANE as the abstraction of components in a network whose properties may have an impact on end-to-end performance of the traffic handled by those components,
1. ANEの概念は、それらのコンポーネントによって処理されるトラフィックのエンドツーエンドのパフォーマンスにプロパティが影響を与える可能性のあるネットワーク内のコンポーネントの抽象として紹介します。
2. extends the cost map and Endpoint Cost Service to convey the ANEs traversed by the path of a <source, destination> pair as Path Vectors, and
2. コストマップとエンドポイントのコストサービスを拡張して、A <ソースのパス、宛先>ペアのパスベクトル、およびパスベクトル、および
3. uses the entity property map to convey the association between the ANEs and their properties.
3. エンティティプロパティマップを使用して、ANEとそのプロパティとの関連性を伝えます。
Thus, an ALTO client can learn about the ANEs that are important for assessing the QoE of different <source, destination> pairs by investigating the corresponding Path Vector value (AR1) and can also (1) identify common ANEs if an ANE appears in the Path Vectors of multiple <source, destination> pairs (AR2) and (2) retrieve the properties of the ANEs by searching the entity property map (AR3).
したがって、ALTOクライアントは、対応するパスベクトル値（AR1）を調査することにより、異なる<ソース、宛先>ペアのQOEを評価するために重要なANEについて学ぶことができ、（1）ANEが表示される場合、一般的なANEを識別することもできます。エンティティプロパティマップ（AR3）を検索して、複数の<ソース、宛先>ペア（AR2）および（2）のパスベクトル（2）のANEのプロパティを取得します。
This extension introduces the ANE as an indirect and network-agnostic way to specify a component or an aggregation of components of a network whose properties have an impact on end-to-end performance for application traffic between endpoints.
この拡張機能により、ANEは、エンドポイント間のアプリケーショントラフィックのエンドツーエンドのパフォーマンスにプロパティが影響を与えるコンポーネントまたはコンポーネントのコンポーネントまたは集約を指定する間接的およびネットワークに依存しない方法として導入されます。
ANEs allow ALTO servers to focus on common properties of different types of network components. For example, the throughput of a flow can be constrained by different components in a network: the capacity of a physical link, the maximum throughput of a firewall, the reserved bandwidth of an MPLS tunnel, etc. In the example below, assume that the throughput of the firewall is 100 Mbps and the capacity for link (A, B) is also 100 Mbps; they result in the same constraint on the total throughput of f1 and f2. Thus, they are identical when treated as an ANE.
ANEにより、ALTOサーバーは、さまざまなタイプのネットワークコンポーネントの共通プロパティに焦点を当てることができます。たとえば、フローのスループットは、ネットワーク内のさまざまなコンポーネントによって制約される可能性があります。物理リンクの容量、ファイアウォールの最大スループット、MPLSトンネルの予約帯域幅など。以下の例では、以下の例では、ファイアウォールのスループットは100 Mbpsで、リンクの容量（a、b）も100 mbpsです。これらは、F1とF2の合計スループットに同じ制約をもたらします。したがって、それらはANEとして扱われると同一です。
f1 | ^ f1
| | ----------------->
+----------+ +---+ +---+
| Firewall | | A |-----| B |
+----------+ +---+ +---+
| | ----------------->
v | f2 f2
When an ANE is defined by an ALTO server, it is assigned an identifier by the ALTO server, i.e., a string of type ANEName as specified in Section 6.1, and a set of associated properties.
ANEがALTOサーバーによって定義されると、ALTOサーバーによって識別子、つまりセクション6.1で指定されているタイプANENAMEの文字列と、関連するプロパティのセットが割り当てられます。
In this extension, the associations between ANEs and their properties are conveyed in an entity property map. Thus, ANEs must constitute an "entity domain" (Section 5.1 of [RFC9240]), and each ANE property must be an entity property (Section 5.2 of [RFC9240]).
この拡張では、ANEとそれらのプロパティとの関連がエンティティプロパティマップで伝えられます。したがって、ANEは「エンティティドメイン」（[RFC9240]のセクション5.1）を構成する必要があり、各ANEプロパティはエンティティプロパティ（[RFC9240]のセクション5.2）でなければなりません。
Specifically, this document defines a new entity domain called "ane" as specified in Section 6.2; Section 6.4 defines two initial property types for the ANE entity domain.
具体的には、このドキュメントでは、セクション6.2で指定されている「ANE」と呼ばれる新しいエンティティドメインを定義します。セクション6.4は、ANEエンティティドメインの2つの初期プロパティタイプを定義します。
By design, ANEs are ephemeral and not to be used in further requests to other ALTO resources. More precisely, the corresponding ANE names are no longer valid beyond the scope of a Path Vector response or the incremental update stream for a Path Vector request. Compared with globally unique ANE names, ephemeral ANEs have several benefits, including better privacy for the ISP's internal structure and more flexible ANE computation.
設計上、ANEは一時的であり、他のALTOリソースへのさらなる要求には使用されません。より正確には、対応するANE名は、パスベクトル応答の範囲またはパスベクトル要求の増分更新ストリームを超えて有効ではなくなりました。グローバルに一意のANE名と比較して、はかないANEには、ISPの内部構造のプライバシーの改善や、より柔軟なANE計算など、いくつかの利点があります。
For example, an ALTO server may define an ANE for each aggregated bottleneck link between the sources and destinations specified in the request. For requests with different sources and destinations, the bottlenecks may be different but can safely reuse the same ANE names. The client can still adjust its traffic based on the information, but it is difficult to infer the underlying topology with multiple queries.
たとえば、ALTOサーバーは、リクエストで指定されたソースと目的地の間に集約された各ボトルネックリンクのANEを定義できます。さまざまなソースや目的地を持つリクエストの場合、ボトルネックは異なる場合がありますが、同じANE名を安全に再利用できます。クライアントは引き続き情報に基づいてトラフィックを調整できますが、複数のクエリを使用して基礎となるトポロジを推測することは困難です。
However, sometimes an ISP may intend to selectively reveal some "persistent" network components that, as opposed to being ephemeral, have a longer life cycle. For example, an ALTO server may define an ANE for each service edge cluster. Once a client chooses to use a service edge, e.g., by deploying some user-defined functions, it may want to stick to the service edge to avoid the complexity of state transition or synchronization, and continuously query the properties of the edge cluster.
ただし、ISPは、一時的ではなく、より長いライフサイクルを持つ「永続的な」ネットワークコンポーネントを選択的に明らかにすることを意図する場合があります。たとえば、ALTOサーバーは、各サービスエッジクラスターのANEを定義できます。クライアントがサービスエッジを使用することを選択したら、たとえば、ユーザー定義の関数を展開することにより、状態遷移または同期の複雑さを回避し、エッジクラスターのプロパティを継続的に照会するためにサービスエッジに固執することができます。
This document provides a mechanism to expose such network components as persistent ANEs. A persistent ANE has a persistent ID that is registered in a property map, together with its properties. See Sections 6.2.4 and 6.4.2 for more detailed instructions on how to identify ephemeral ANEs and persistent ANEs.
このドキュメントは、そのようなネットワークコンポーネントを永続的なANEとして公開するメカニズムを提供します。永続的なANEには、プロパティとともにプロパティマップに登録されている永続的なIDがあります。短命のANEと永続的なANEを識別する方法の詳細については、セクション6.2.4および6.4.2を参照してください。
Resource-constrained ALTO clients (see Section 4.1.2 of [RFC7285]) may benefit from the filtering of Path Vector query results at the ALTO server, as an ALTO client may only require a subset of the available properties.
ALTOクライアントには、使用可能なプロパティのサブセットのみが必要な場合があるため、リソースが制約したALTOクライアント（[RFC7285]のセクション4.1.2を参照）は、ALTOサーバーでのパスベクトルクエリ結果のフィルタリングの恩恵を受ける可能性があります。
Specifically, the available properties for a given resource are announced in the Information Resource Directory (IRD) as a new filtering capability called "ane-property-names". The properties selected by a client as being of interest are specified in the subsequent Path Vector queries using the "ane-property-names" filter. The response only includes the selected properties for the ANEs.
具体的には、特定のリソースの利用可能なプロパティは、「ANE-Property-Names」と呼ばれる新しいフィルタリング機能として情報リソースディレクトリ（IRD）で発表されます。クライアントによって選択されたプロパティは、「ANE-Property-Names」フィルターを使用して、後続のパスベクトルクエリで指定されます。応答には、ANESの選択されたプロパティのみが含まれます。
The "ane-property-names" capability for the cost map and the Endpoint Cost Service is specified in Sections 7.2.4 and 7.3.4, respectively. The "ane-property-names" filter for the cost map and the Endpoint Cost Service is specified in Sections 7.2.3 and 7.3.3 accordingly.
コストマップとエンドポイントコストサービスの「ane-property-names」機能は、それぞれセクション7.2.4と7.3.4で指定されています。コストマップとエンドポイントコストサービスの「ANE-Property-Names」フィルターは、それに応じてセクション7.2.3および7.3.3で指定されています。
For an ALTO client to correctly interpret the Path Vector, this extension specifies a new cost type called the "Path Vector cost type".
ALTOクライアントがパスベクトルを正しく解釈するために、この拡張機能は「パスベクトルコストタイプ」と呼ばれる新しいコストタイプを指定します。
The Path Vector cost type must convey both the interpretation and semantics in the "cost-mode" and "cost-metric" parameters, respectively. Unfortunately, a single "cost-mode" value cannot fully specify the interpretation of a Path Vector, which is a compound data type. For example, in programming languages such as C++, if there existed a JSON array type named JSONArray, a Path Vector would have the type of JSONArray<ANEName>.
パスベクトルコストタイプは、それぞれ「コストモード」と「コストメトリック」パラメーターで解釈とセマンティクスの両方を伝える必要があります。残念ながら、単一の「コストモード」値は、複合データ型であるパスベクトルの解釈を完全に指定できません。たとえば、Cなどのプログラミング言語では、JSonArrayという名前のJSONアレイタイプが存在する場合、パスベクトルにはjsonArray <anename>のタイプがあります。
Instead of extending the "type system" of ALTO, this document takes a simple and backward-compatible approach. Specifically, the "cost-mode" of the Path Vector cost type is "array", which indicates that the value is a JSON array. Then, an ALTO client must check the value of the "cost-metric" parameter. If the value is "ane-path", it means that the JSON array should be further interpreted as a path of ANENames.
ALTOの「タイプシステム」を拡張する代わりに、このドキュメントはシンプルで後方互換のアプローチを採用します。具体的には、パスベクトルコストタイプの「コストモード」は「配列」であり、値がJSONアレイであることを示します。次に、ALTOクライアントは「コスト計量」パラメーターの値を確認する必要があります。値が「ane-path」の場合、JSONアレイをさらにナーネームの経路としてさらに解釈する必要があることを意味します。
The Path Vector cost type is specified in Section 6.5.
パスベクトルコストタイプは、セクション6.5で指定されています。
For a basic ALTO information resource, a response contains only one type of ALTO resource, e.g., network map, cost map, or property map. Thus, only one round of communication is required: an ALTO client sends a request to an ALTO server, and the ALTO server returns a response, as shown in Figure 8.
基本的なALTO情報リソースの場合、応答には、ネットワークマップ、コストマップ、またはプロパティマップなど、1つのタイプのALTOリソースのみが含まれています。したがって、通信のラウンドのみが必要です。ALTOクライアントはALTOサーバーにリクエストを送信し、ALTOサーバーは図8に示すように応答を返します。
ALTO client ALTO server
|-------------- Request ---------------->|
|<------------- Response ----------------|
Figure 8: A Typical ALTO Request and Response
図8：典型的なALTOリクエストと応答
The extension defined in this document, on the other hand, involves two types of information resources: Path Vectors conveyed in an InfoResourceCostMap data component (defined in Section 11.2.3.6 of [RFC7285]) or an InfoResourceEndpointCostMap data component (defined in Section 11.5.1.6 of [RFC7285]), and ANE properties conveyed in an InfoResourceProperties data component (defined in Section 7.6 of [RFC9240]).
一方、このドキュメントで定義されている拡張には、InforeourcostMapデータコンポーネント（[RFC7285]のセクション11.2.3.6で定義）で伝達されるパスベクトルの2種類の情報リソースが含まれます。[RFC7285]の1.6）、およびInforeSourcePropertiesデータコンポーネントで伝えられたANEプロパティ（[RFC9240]のセクション7.6で定義）。
Instead of two consecutive message exchanges, the extension defined in this document enforces one round of communication. Specifically, the ALTO client must include the source and destination pairs and the requested ANE properties in a single request, and the ALTO server must return a single response containing both the Path Vectors and properties associated with the ANEs in the Path Vectors, as shown in Figure 9. Since the two parts are bundled together in one response message, their orders are interchangeable. See Sections 7.2.6 and 7.3.6 for details.
2つの連続したメッセージ交換の代わりに、このドキュメントで定義されている拡張機能は、1ラウンドの通信を実施します。具体的には、ALTOクライアントには、単一の要求にソースと宛先のペアと要求されたANEプロパティを含める必要があり、ALTOサーバーは、パスベクトル内のANEに関連付けられたPATHベクターとプロパティの両方を含む単一の応答を返す必要があります。図9. 2つの部分は1つの応答メッセージにまとめられているため、注文は交換可能です。詳細については、セクション7.2.6および7.3.6を参照してください。
ALTO client ALTO server
|------------- PV Request -------------->|
|<----- PV Response (Cost Map Part) -----|
|<--- PV Response (Property Map Part) ---|
Figure 9: The Path Vector Extension Request and Response
図9：パスベクトル拡張リクエストと応答
This design is based on the following considerations:
この設計は、次の考慮事項に基づいています。
1. ANEs may be constructed on demand and, potentially, based on the requested properties (see Section 5.1 for more details). If sources and destinations are not in the same request as the properties, an ALTO server either cannot construct ANEs on demand or must wait until both requests are received.
1. ANEは、要求されたプロパティに基づいて、潜在的には潜在的には、潜在的に構築される場合があります（詳細については、セクション5.1を参照）。ソースと宛先がプロパティと同じ要求にない場合、ALTOサーバーはオンデマンドでANEを構築することも、両方のリクエストを受信するまで待機する必要があります。
2. As ANEs may be constructed on demand, mappings of each ANE to its underlying network devices and resources can be specific to the request. In order to respond to the property map request correctly, an ALTO server must store the mapping of each Path Vector request until the client fully retrieves the property information. This "stateful" behavior may substantially harm server scalability and potentially lead to denial-of-service attacks.
2. ANEはオンデマンドで構築される可能性があるため、各ANEの基礎となるネットワークデバイスとリソースへのマッピングは、リクエストに固有のものです。プロパティマップ要求に正しく応答するために、ALTOサーバーは、クライアントがプロパティ情報を完全に取得するまで、各パスベクトル要求のマッピングを保存する必要があります。この「ステートフル」な動作は、サーバーのスケーラビリティを大幅に害し、サービス拒否攻撃につながる可能性があります。
One approach for realizing the one-round communication is to define a new media type to contain both objects, but this violates modular design. This document follows the standard-conforming usage of the "multipart/related" media type as defined in [RFC2387] to elegantly combine the objects. Path Vectors are encoded in an InfoResourceCostMap data component or InfoResourceEndpointCostMap data component, and the property map is encoded in an InfoResourceProperties data component. They are encapsulated as parts of a multipart message. This modular composition allows ALTO servers and clients to reuse the data models of the existing information resources. Specifically, this document addresses the following practical issues using "multipart/related".
1ラウンドの通信を実現するための1つのアプローチは、両方のオブジェクトを含むように新しいメディアタイプを定義することですが、これはモジュラー設計に違反します。このドキュメントは、[RFC2387]で定義されている「マルチパート/関連」メディアタイプの標準的な構成の使用に従って、オブジェクトをエレガントに組み合わせます。パスベクトルは、InforeourcostMapデータコンポーネントにエンコードされるか、InforeSourceEndpointCostMapデータコンポーネントでエンコードされ、プロパティマップはInforeSourcePropertiesデータコンポーネントにエンコードされています。それらは、マルチパートメッセージの一部としてカプセル化されています。このモジュラー構成により、ALTOサーバーとクライアントは既存の情報リソースのデータモデルを再利用できます。具体的には、このドキュメントでは、「MultiPart/関連」を使用して、次の実用的な問題に対応しています。
ALTO uses a media type to indicate the type of an entry in the IRD (e.g., "application/alto-costmap+json" for the cost map and "application/alto-endpointcost+json" for the Endpoint Cost Service). Simply using "multipart/related" as the media type, however, makes it impossible for an ALTO client to identify the type of service provided by related entries.
Altoはメディアタイプを使用して、IRDのエントリのタイプを示します（例：コストマップの「アプリケーション/ALTO-COSTMAP JSON」、およびエンドポイントコストサービスの「アプリケーション/ALTO-ENDPOINTCOST JSON」）。ただし、「MultiPart/関連」をメディアタイプとして使用するだけで、ALTOクライアントが関連するエントリが提供するサービスの種類を特定することができなくなります。
To address this issue, this document uses the "type" parameter to indicate the object root of a multipart/related message. For a cost map resource, the "media-type" field in the IRD entry is "multipart/ related" with the parameter "type=application/alto-costmap+json"; for an Endpoint Cost Service, the parameter is "type=application/alto-endpointcost+json".
この問題に対処するために、このドキュメントは「タイプ」パラメーターを使用して、マルチパート/関連メッセージのオブジェクトルートを示します。コストマップリソースの場合、IRDエントリの「メディアタイプ」フィールドは、パラメーター「Type = Application/ ALTO-COSTMAP JSON」を使用して「MultiPart/関連」です。エンドポイントコストサービスの場合、パラメーターは「type = application/alto-endpointcost json」です。
As the response of a Path Vector resource is a multipart message with two different parts, it is important that each part can be uniquely identified. Following the design provided in [RFC8895], this extension requires that an ALTO server assign a unique identifier to each part of the multipart response message. This identifier, referred to as a Part Resource ID (see Section 6.6 for details), is present in the part message's "Content-ID" header field. By concatenating the Part Resource ID to the identifier of the Path Vector request, an ALTO server/client can uniquely identify the Path Vector part or the property map part.
パスベクトルリソースの応答は、2つの異なる部分を持つマルチパートメッセージであるため、各部分を一意に識別できることが重要です。[RFC8895]で提供されている設計に続いて、この拡張機能では、ALTOサーバーがマルチパート応答メッセージの各部分に一意の識別子を割り当てる必要があります。パーツリソースIDと呼ばれるこの識別子（詳細については、セクション6.6を参照）は、パーツメッセージの「コンテンツID」ヘッダーフィールドに存在します。パートベクトル要求の識別子に部品リソースIDを連結することにより、ALTOサーバー/クライアントは、パスベクトルパーツまたはプロパティマップパーツを一意に識別できます。
An ANE name is encoded as a JSON string with the same format as that of the type PIDName (Section 10.1 of [RFC7285]).
ANE名は、タイプPIDNAME（[RFC7285]のセクション10.1）の形式と同じ形式のJSON文字列としてエンコードされます。
The type ANEName is used in this document to indicate a string of this format.
このドキュメントでは、このドキュメントで使用されて、この形式の文字列を示すために使用されます。
The ANE entity domain associates property values with the ANEs in a property map. Accordingly, the ANE entity domain always depends on a property map.
ANEエンティティドメインは、プロパティ値をプロパティマップ内のANESに関連付けます。したがって、ANEエンティティドメインは常にプロパティマップに依存します。
It must be noted that the term "domain" here does not refer to a network domain. Rather, it is inherited from the entity domain as defined in Section 3.2 of [RFC9240]; the entity domain represents the set of valid entities defined by an ALTO information resource (called the "defining information resource").
ここでの「ドメイン」という用語は、ネットワークドメインを参照していないことに注意する必要があります。むしろ、[RFC9240]のセクション3.2で定義されているように、エンティティドメインから継承されます。エンティティドメインは、ALTO情報リソース（「情報リソースの定義」と呼ばれる）で定義された有効なエンティティのセットを表します。
The entity domain type is "ane".
エンティティドメインタイプは「ANE」です。
The entity identifiers are the ANE names in the associated property map.
エンティティ識別子は、関連するプロパティマップのANE名です。
There is no hierarchy or inheritance for properties associated with ANEs.
ANEに関連するプロパティの階層または継承はありません。
The defining resource for entity domain type "ane" MUST be a property map, i.e., the media type of defining resources is:
エンティティドメインタイプ「ANE」の定義リソースは、プロパティマップでなければなりません。つまり、メディアタイプの定義リソースは次のとおりです。
application/alto-propmap+json
アプリケーション/ALTO-PROPMAP JSON
Specifically, for ephemeral ANEs that appear in a Path Vector response, their entity domain names MUST be exactly ".ane", and the defining resource of these ANEs is the property map part of the multipart response. Meanwhile, for any persistent ANE whose defining resource is a property map resource, its entity domain name MUST have the format of "PROPMAP.ane", where PROPMAP is the resource ID of the defining resource. Persistent entities are "persistent" because standalone queries can be made by an ALTO client to their defining resource(s) when the connection to the Path Vector service is closed.
具体的には、パスベクトル応答に表示される一時的なANEの場合、それらのエンティティドメイン名は正確に「.AN」でなければならず、これらのANEの定義リソースはマルチパート応答のプロパティマップ部分です。一方、定義リソースがプロパティマップリソースである永続的なANEの場合、そのエンティティドメイン名には「propmap.ane」の形式が必要です。プロップマップは定義リソースのリソースIDです。パスベクトルサービスへの接続が閉じられている場合、スタンドアロンクライアントはALTOクライアントが定義するリソースに作成できるため、永続的なエンティティは「永続的」です。
For example, the defining resource of an ephemeral ANE whose entity identifier is ".ane:NET1" is the property map part that contains this identifier. The defining resource of a persistent ANE whose entity identifier is "dc-props.ane:DC1" is the property map with the resource ID "dc-props".
たとえば、エンティティ識別子が「.ane：net1」である一時的なaneの定義リソースは、この識別子を含むプロパティマップ部分です。エンティティ識別子が「dc-props.ane：dc1」である永続的なANEの定義リソースは、リソースID「DC-props」のプロパティマップです。
An ANE property name is encoded as a JSON string with the same format as that of an entity property name (Section 5.2.2 of [RFC9240]).
ANEプロパティ名は、エンティティプロパティ名と同じ形式のJSON文字列としてエンコードされます（[RFC9240]のセクション5.2.2）。
Two initial ANE property types are specified: "max-reservable-bandwidth" and "persistent-entity-id".
2つの初期ANEプロパティタイプが指定されています：「Max-Reservable-BandWidth」と「Persistent-Entity-ID」。
Note that these property types do not depend on any information resources. As such, the "EntityPropertyName" parameter MUST only have the EntityPropertyType part.
これらのプロパティタイプは、情報リソースに依存しないことに注意してください。そのため、「EntityPropertyName」パラメーターには、EntityPropertyTypeパーツのみが必要です。
The maximum reservable bandwidth property ("max-reservable-bandwidth") stands for the maximum bandwidth that can be reserved for all the traffic that traverses an ANE. The value MUST be encoded as a non-negative numerical cost value as defined in Section 6.1.2.1 of [RFC7285], and the unit is bits per second (bps). If this property is requested by the ALTO client but is not present for an ANE in the server response, it MUST be interpreted as meaning that the property is not defined for the ANE.
最大予約可能な帯域幅プロパティ（「MAX-Reservable BandWidth」）は、ANEを横断するすべてのトラフィックのために予約できる最大帯域幅を表します。値は、[RFC7285]のセクション6.1.2.1で定義されている非陰性数値コスト値としてエンコードする必要があり、ユニットは1秒あたりのビット（BPS）です。このプロパティがALTOクライアントによって要求されているが、サーバー応答のANEに存在しない場合、ANEに対してプロパティが定義されていないことを意味すると解釈する必要があります。
This property can be offered in a setting where the ALTO server is part of a network system that provides on-demand resource allocation and the ALTO client is part of a user application. One existing example is [NOVA]: the ALTO server is part of a Software-Defined Networking (SDN) controller and exposes a list of traversed network elements and associated link bandwidth to the client. The encoding in [NOVA] differs from the Path Vector response defined in this document in that the Path Vector part and property map part are placed in the same JSON object.
このプロパティは、ALTOサーバーがオンデマンドリソース割り当てを提供するネットワークシステムの一部であり、ALTOクライアントがユーザーアプリケーションの一部である設定で提供できます。既存の例の1つは[NOVA]です。ALTOサーバーは、ソフトウェア定義ネットワーク（SDN）コントローラーの一部であり、通信ネットワーク要素と関連するリンク帯域幅のリストをクライアントに公開します。[nova]でのエンコードは、パスベクトルパーツとプロパティマップパーツが同じJSONオブジェクトに配置されているという点で、このドキュメントで定義されているパスベクトル応答とは異なります。
In such a framework, the ALTO server exposes resource availability information (e.g., reservable bandwidth) to the ALTO client. How the client makes resource requests based on the information, and how the resource allocation is achieved, respectively, depend on interfaces between the management system and the users or a higher-layer protocol (e.g., SDN network intents [INTENT-BASED-NETWORKING] or MPLS tunnels), which are out of scope for this document.
このようなフレームワークでは、ALTOサーバーはリソースの可用性情報（予約可能な帯域幅など）をALTOクライアントに公開します。クライアントが情報に基づいてリソース要求を行う方法と、それぞれリソース割り当てがそれぞれ管理システムとユーザー間のインターフェイスまたは高層プロトコル（例えば、SDNネットワーク意図[Intent Based-Networking]」に依存する方法またはMPLSトンネル）、このドキュメントの範囲外です。
This document enables the discovery of a persistent ANE by exposing its entity identifier as the persistent entity ID property of an ephemeral ANE in the path vector response. The value of this property is encoded with the EntityID format defined in Section 5.1.3 of [RFC9240].
このドキュメントにより、パスベクトル応答のはかないANEの永続的エンティティIDプロパティとしてそのエンティティ識別子を公開することにより、永続的なANEの発見を可能にします。このプロパティの値は、[RFC9240]のセクション5.1.3で定義されているentityID形式でエンコードされます。
In this format, the entity ID combines:
この形式では、エンティティIDが組み合わされます。
* a defining information resource for the ANE on which a "persistent-entity-id" is queried, which is the property map resource defining the ANE as a persistent entity, together with the properties.
* 「永続的エンティティID」が照会されたANEの定義された情報リソースは、プロパティとともに、ANEを永続的なエンティティとして定義するプロパティマップリソースです。
* the persistent name of the ANE in that property map.
* そのプロパティマップのANEの永続的な名前。
With this format, the client has all the needed information for further standalone query properties on the persistent ANE.
この形式を使用すると、クライアントは、永続的なANE上のさらにスタンドアロンクエリプロパティに必要なすべての情報を持っています。
To illustrate the use of "max-reservable-bandwidth", consider the following network with five nodes. Assume that the client wants to query the maximum reservable bandwidth from H1 to H2. An ALTO server may split the network into two ANEs: "ane1", which represents the subnetwork with routers A, B, and C; and "ane2", which represents the subnetwork with routers B, D, and E. The maximum reservable bandwidth for "ane1" is 15 Mbps (using path A->C->B), and the maximum reservable bandwidth for "ane2" is 20 Mbps (using path B->D->E).
「Max-Reservable-BandWidth」の使用を説明するには、5つのノードを持つ次のネットワークを検討してください。クライアントがH1からH2までの最大予約可能帯域幅を照会したいと仮定します。ALTOサーバーは、ネットワークを2つのANESに分割する場合があります。「ANE1」は、ルーターA、B、およびCを使用したサブネットワークを表します。ルーターB、D、およびEを備えたサブネットワークを表す「ANE2」は、「ANE1」の最大予約可能帯域幅は15 Mbps（パスA-> C-> Bを使用）、および「ANE2」の最大予約可能帯域幅です。20 mbpsです（パスb-> d-> eを使用）。
20 Mbps 20 Mbps
10 Mbps +---+ +---+ +---+
/----| B |---| D |----| E |---- H2
+---+/ +---+ +---+ +---+
H1 ----| A | 15 Mbps|
+---+\ +---+
\----| C |
15 Mbps +---+
To illustrate the use of "persistent-entity-id", consider the scenario in Figure 6. As the life cycles of service edges are typically long, the service edges may contain information that is not specific to the query. Such information can be stored in an individual entity property map and can later be accessed by an ALTO client.
「永続的エンティティID」の使用を説明するために、図6のシナリオを考慮してください。サービスエッジのライフサイクルが通常長いため、サービスエッジにはクエリに固有の情報が含まれている場合があります。このような情報は、個々のエンティティプロパティマップに保存でき、後でALTOクライアントがアクセスできます。
For example, "ane1" in Figure 7 represents the on-premise service edge closest to host "a". Assume that the properties of the service edges are provided in an entity property map called "se-props" and the ID of the on-premise service edge is "9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1"; the "persistent-entity-id" setting for "ane1" will be "se-props.ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1". With this persistent entity ID, an ALTO client may send queries to the "se-props" resource with the entity ID ".ane:9a0b55f7-7442-4d56-8a2c-b4cc6a8e3aa1".
たとえば、図7の「ANE1」は、ホスト「A」に最も近いオンプレミスサービスエッジを表しています。サービスエッジのプロパティが「SEプロップ」と呼ばれるエンティティプロパティマップで提供され、オンプレミスサービスエッジのIDが「9A0B55F7-7442-4D56-8A2C-B4CC6A8E3AA1」であると仮定します。「ANE1」の「永続的エンティティID」設定は、「SE-PROPS.AN：9A0B5F7-7442-4D56-8A2C-B4CC6A8E3AA1」になります。この永続的なエンティティIDを使用すると、ALTOクライアントは、エンティティIDを使用して「SEプロップ」リソースにクエリを送信できます。
This document defines a new cost type, which is referred to as the Path Vector cost type. An ALTO server MUST offer this cost type if it supports the extension defined in this document.
このドキュメントでは、パスベクトルコストタイプと呼ばれる新しいコストタイプを定義します。ALTOサーバーは、このドキュメントで定義されている拡張機能をサポートする場合は、このコストタイプを提供する必要があります。
The cost metric "ane-path" indicates that the value of such a cost type conveys an array of ANE names, where each ANE name uniquely represents an ANE traversed by traffic from a source to a destination.
コストメトリック「ane-path」は、このようなコストタイプの値がANE名の配列を伝えることを示しています。ここでは、各ANE名はソースから宛先へのトラフィックによって横断されるANEを一意に表します。
An ALTO client MUST interpret the Path Vector as if the traffic between a source and a destination logically traverses the ANEs in the same order as they appear in the Path Vector.
ALTOクライアントは、ソースと宛先の間のトラフィックが、パスベクトルに表示されるのと同じ順序でANEを論理的に横断するかのように、パスベクトルを解釈する必要があります。
When the Path Vector procedures defined in this document are in use, an ALTO server using the "ane-path" cost metric and the "array" cost mode (see Section 6.5.2) MUST return as the cost value a JSON array of data type ANEName, and the client MUST also check that each element contained in the array is an ANEName (Section 6.1). Otherwise, the client MUST discard the response and SHOULD follow the guidance in Section 8.3.4.3 of [RFC7285] to handle the error.
このドキュメントで定義されているパスベクトル手順が使用されている場合、「ane-path」コストメトリックと「配列」コストモード（セクション6.5.2を参照）を使用するALTOサーバーは、データのJSONアレイのコスト値として返す必要があります。タイプのaneName、およびクライアントは、配列に含まれる各要素がAnenameであることを確認する必要があります（セクション6.1）。それ以外の場合、クライアントは応答を廃棄する必要があり、[RFC7285]のセクション8.3.4.3のガイダンスに従ってエラーを処理する必要があります。
The cost mode "array" indicates that every cost value in the response body of a (filtered) cost map or an Endpoint Cost Service MUST be interpreted as a JSON array object. While this cost mode can be applied to all cost metrics, additional specifications will be needed to clarify the semantics of the "array" cost mode when combined with cost metrics other than "ane-path".
コストモードの「配列」は、（フィルタリングされた）コストマップまたはエンドポイントコストサービスの応答ボディのすべてのコスト値がJSONアレイオブジェクトとして解釈する必要があることを示します。このコストモードはすべてのコストメトリックに適用できますが、「ane-path」以外のコストメトリックと組み合わせると、「配列」コストモードのセマンティクスを明確にするために追加の仕様が必要になります。
A Part Resource ID is encoded as a JSON string with the same format as that of the type ResourceID (Section 10.2 of [RFC7285]).
パーツリソースIDは、型ResourceID（[RFC7285]のセクション10.2）の形式と同じ形式のJSON文字列としてエンコードされます。
Even though the "client-id" assigned to a Path Vector request and the Part Resource ID MAY contain up to 64 characters by their own definition, their concatenation (see Section 5.3.2) MUST also conform to the same length constraint. The same requirement applies to the resource ID of the Path Vector resource, too. Thus, it is RECOMMENDED to limit the length of the resource ID and client ID related to a Path Vector resource to 31 characters.
パスベクトル要求に割り当てられた「クライアントID」とパーツリソースIDには、独自の定義により最大64文字が含まれる場合がありますが、連結（セクション5.3.2を参照）も同じ長さの制約に適合する必要があります。同じ要件も、Path VectorリソースのリソースIDにも当てはまります。したがって、パスベクトルリソースに関連するリソースIDとクライアントIDの長さを31文字に制限することをお勧めします。
A Part Content ID conforms to the format of "msg-id" as specified in [RFC2387] and [RFC5322]. Specifically, it has the following format:
部品コンテンツIDは、[RFC2387]および[RFC5322]で指定されている「MSG-ID」の形式に準拠しています。具体的には、次の形式があります。
"<" PART-RESOURCE-ID "@" DOMAIN-NAME ">"
PART-RESOURCE-ID: PART-RESOURCE-ID has the same format as the Part Resource ID. It is used to identify whether a part message is a Path Vector or a property map.
Part-Resource-ID：Part-Resource-IDは、部品リソースIDと同じ形式を持っています。パーツメッセージがパスベクトルかプロパティマップかを識別するために使用されます。
DOMAIN-NAME: DOMAIN-NAME has the same format as "dot-atom-text" as specified in Section 3.2.3 of [RFC5322]. It must be the domain name of the ALTO server.
ドメイン名：ドメイン名は、[RFC5322]のセクション3.2.3で指定されている「dot-atom-text」と同じ形式を持っています。ALTOサーバーのドメイン名でなければなりません。
This document uses the same syntax and notation as those introduced in Section 8.2 of [RFC7285] to specify the extensions to existing ALTO resources and services.
このドキュメントでは、[RFC7285]のセクション8.2で導入された構文と同じ構文と表記を使用して、既存のALTOリソースとサービスの拡張を指定します。
This document introduces a new ALTO resource called the "multipart filtered cost map resource", which allows an ALTO server to provide other ALTO resources associated with the cost map resource in the same response.
このドキュメントでは、「マルチパートフィルター処理されたコストマップリソース」と呼ばれる新しいALTOリソースを紹介します。これにより、ALTOサーバーは、同じ応答でコストマップリソースに関連付けられた他のALTOリソースを提供できます。
The media type of the multipart filtered cost map resource is "multipart/related", and the required "type" parameter MUST have a value of "application/alto-costmap+json".
マルチパートフィルタリングコストマップリソースのメディアタイプは「マルチパート/関連」であり、必要な「タイプ」パラメーターには「Application/ALTO-COSTMAP JSON」の値が必要です。
The multipart filtered cost map is requested using the HTTP POST method.
HTTP POSTメソッドを使用して、マルチパートフィルターコストマップが要求されます。
The input parameters of the multipart filtered cost map are supplied in the body of an HTTP POST request. This document extends the input parameters to a filtered cost map, which is defined as a JSON object of type ReqFilteredCostMap in Section 4.1.2 of [RFC8189], with a data format indicated by the media type "application/alto-costmapfilter+json", which is a JSON object of type PVReqFilteredCostMap:
MultiPartフィルタリングコストマップの入力パラメーターは、HTTP POSTリクエストの本文で提供されます。このドキュメントは、入力パラメーターをフィルタリングされたコストマップに拡張します。これは、[RFC8189]のセクション4.1.2のタイプreqfilteredCostmapのJSONオブジェクトとして定義され、メディアタイプの「Application/Alto-Costmapfilter JSON」で示されます。これは、pvreqfilteredcostmapのタイプのJSONオブジェクトです。
object {
[EntityPropertyName ane-property-names<0..*>;]
} PVReqFilteredCostMap : ReqFilteredCostMap;
with field:
フィールドで：
ane-property-names: This field provides a list of selected ANE properties to be included in the response. Each property in this list MUST match one of the supported ANE properties indicated in the resource's "ane-property-names" capability (Section 7.2.4). If the field is not present, it MUST be interpreted as an empty list.
ANE-Property-Names：このフィールドは、応答に含まれる選択したANEプロパティのリストを提供します。このリストの各プロパティは、リソースの「ANE-Property-Names」機能（セクション7.2.4）に示されているサポートされているANEプロパティの1つと一致する必要があります。フィールドが存在しない場合は、空のリストとして解釈する必要があります。
Example: Consider the network in Figure 1. If an ALTO client wants to query the "max-reservable-bandwidth" setting between PID1 and PID2, it can submit the following request.
例：図1のネットワークを検討してください。ALTOクライアントが、PID1とPID2の間の「最大復元可能バンド幅」設定をクエリしたい場合は、次のリクエストを送信できます。
POST /costmap/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json,
application/alto-error+json
Content-Length: 212
Content-Type: application/alto-costmapfilter+json
{
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"pids": {
"srcs": [ "PID1" ],
"dsts": [ "PID2" ]
},
"ane-property-names": [ "max-reservable-bandwidth" ]
}
The multipart filtered cost map resource extends the capabilities defined in Section 4.1.1 of [RFC8189]. The capabilities are defined by a JSON object of type PVFilteredCostMapCapabilities:
マルチパートフィルタリングコストマップリソースは、[RFC8189]のセクション4.1.1で定義された機能を拡張します。機能は、型pvfilteredcostmapcapabilityのタイプのJSONオブジェクトによって定義されます。
object {
[EntityPropertyName ane-property-names<0..*>;]
} PVFilteredCostMapCapabilities : FilteredCostMapCapabilities;
with field:
フィールドで：
ane-property-names: This field provides a list of ANE properties that can be returned. If the field is not present, it MUST be interpreted as an empty list, indicating that the ALTO server cannot provide any ANE properties.
ANE-Property-Names：このフィールドは、返品できるANEプロパティのリストを提供します。フィールドが存在しない場合、ALTOサーバーがANEプロパティを提供できないことを示す空のリストとして解釈する必要があります。
This extension also introduces additional restrictions for the following fields:
この拡張機能は、次のフィールドに追加の制限を導入します。
cost-type-names: The "cost-type-names" field MUST include the Path Vector cost type, unless explicitly documented by a future extension. This also implies that the Path Vector cost type MUST be defined in the "cost-types" of the IRD's "meta" field.
コストタイプ名：「コストタイプ」フィールドには、将来の拡張機能によって明示的に文書化されていない限り、パスベクトルコストタイプを含める必要があります。これは、IRDの「メタ」フィールドの「コストタイプ」でパスベクトルコストタイプを定義する必要があることも意味します。
cost-constraints: If the "cost-type-names" field includes the Path Vector cost type, the "cost-constraints" field MUST be either "false" or not present, unless specifically instructed by a future document.
コスト制約：「コストタイプ」フィールドにパスベクトルコストタイプが含まれている場合、将来のドキュメントで具体的に指示されない限り、「コスト制約」フィールドが「虚偽」または存在しないかのいずれかでなければなりません。
testable-cost-type-names (Section 4.1.1 of [RFC8189]): If the "cost-type-names" field includes the Path Vector cost type and the "testable-cost-type-names" field is present, the Path Vector cost type MUST NOT be included in the "testable-cost-type-names" field unless specifically instructed by a future document.
テスト可能なコストタイプ名（[RFC8189]のセクション4.1.1）：「コストタイプ」フィールドにパスベクトルコストタイプと「テスト可能なコストタイプ」フィールドが存在する場合、パスベクトルコストタイプは、将来のドキュメントで具体的に指示されていない限り、「テスト可能なコストタイプ」フィールドに含めてはなりません。
This member MUST include the resource ID of the network map based on which the PIDs are defined. If this resource supports "persistent-entity-id", it MUST also include the defining resources of persistent ANEs that may appear in the response.
このメンバーは、PIDが定義されているに基づいて、ネットワークマップのリソースIDを含める必要があります。このリソースが「永続的なエンティティID」をサポートする場合、応答に表示される可能性のある永続的なANEの定義リソースも含める必要があります。
The response MUST indicate an error, using ALTO Protocol error handling as defined in Section 8.5 of [RFC7285], if the request is invalid.
応答は、要求が無効な場合、[RFC7285]のセクション8.5で定義されているALTOプロトコルエラー処理を使用してエラーを示す必要があります。
The "Content-Type" header field of the response MUST be "multipart/ related" as defined by [RFC2387], with the following parameters:
応答の「コンテンツタイプ」ヘッダーフィールドは、次のパラメーターを使用して[RFC2387]で定義されている「マルチパート/関連」でなければなりません。
type: The "type" parameter is mandatory and MUST be "application/ alto-costmap+json". Note that [RFC2387] permits parameters both with and without double quotes.
タイプ：「タイプ」パラメーターは必須であり、「アプリケーション/ ALTO-COSTMAP JSON」でなければなりません。[RFC2387]は、二重引用符のある場合とない場合の両方のパラメーターを許可することに注意してください。
start: The "start" parameter is as defined in [RFC2387] and is optional. If present, it MUST have the same value as the "Content-ID" header field of the Path Vector part.
開始：「start」パラメーターは[RFC2387]で定義されており、オプションです。存在する場合、パスベクトル部分の「コンテンツID」ヘッダーフィールドと同じ値を持たなければなりません。
boundary: The "boundary" parameter is as defined in Section 5.1.1 of [RFC2046] and is mandatory.
境界：「境界」パラメーターは、[RFC2046]のセクション5.1.1で定義されており、必須です。
The body of the response MUST consist of two parts:
応答の本文は、次の2つの部分で構成されている必要があります。
* The Path Vector part MUST include "Content-ID" and "Content-Type" in its header. The "Content-Type" MUST be "application/alto-costmap+json". The value of "Content-ID" MUST have the same format as the Part Content ID as specified in Section 6.6.
* パスベクトル部分には、ヘッダーに「コンテンツID」と「コンテンツタイプ」を含める必要があります。「コンテンツタイプ」は「アプリケーション/ALTO-COSTMAP JSON」でなければなりません。「Content-ID」の値には、セクション6.6で指定された部品コンテンツIDと同じ形式が必要です。
The body of the Path Vector part MUST be a JSON object with the same format as that defined in Section 11.2.3.6 of [RFC7285] when the "cost-type" field is present in the input parameters and MUST be a JSON object with the same format as that defined in Section 4.1.3 of [RFC8189] if the "multi-cost-types" field is present. The JSON object MUST include the "vtag" field in the "meta" field, which provides the version tag of the returned CostMapData object. The resource ID of the version tag MUST follow the format of
パスベクトル部分の本体は、[RFC7285]のセクション11.2.3.6で定義されている形式と同じ形式を持つJSONオブジェクトでなければなりません。[RFC8189]のセクション4.1.3で「マルチコストタイプ」フィールドが存在する場合、同じ形式と同じ形式。JSONオブジェクトには、返されたCostmapDataオブジェクトのバージョンタグを提供する「メタ」フィールドに「VTAG」フィールドを含める必要があります。バージョンタグのリソースIDは、
resource-id '.' part-resource-id
Resource-ID '。'Part-Resource-id
where "resource-id" is the resource ID of the Path Vector resource and "part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID" of the Path Vector part. The "meta" field MUST also include the "dependent-vtags" field, whose value is a single-element array to indicate the version tag of the network map used, where the network map is specified in the "uses" attribute of the multipart filtered cost map resource in the IRD.
ここで、「Resource-ID」はパスベクトルリソースのリソースIDであり、「Part-Resource-ID」は、パスベクトル部分の「コンテンツID」のパートリソース-IDと同じ値を持っています。「メタ」フィールドには、「依存vtags」フィールドも含める必要があります。その値は、マルチパートの「使用」属性でネットワークマップが指定されているネットワークマップのバージョンタグを示すためのシングルエレメントアレイです。IRDのフィルターコストマップリソース。
* The entity property map part MUST also include "Content-ID" and "Content-Type" in its header. The "Content-Type" MUST be "application/alto-propmap+json". The value of "Content-ID" MUST have the same format as the Part Content ID as specified in Section 6.6.
* エンティティプロパティマップパーツには、ヘッダーに「コンテンツID」と「コンテンツタイプ」も含める必要があります。「コンテンツタイプ」は「アプリケーション/ALTO-PROPMAP JSON」でなければなりません。「Content-ID」の値には、セクション6.6で指定された部品コンテンツIDと同じ形式が必要です。
The body of the entity property map part is a JSON object with the same format as that defined in Section 7.6 of [RFC9240]. The JSON object MUST include the "dependent-vtags" field in the "meta" field. The value of the "dependent-vtags" field MUST be an array of VersionTag objects as defined by Section 10.3 of [RFC7285]. The "vtag" of the Path Vector part MUST be included in the "dependent-vtags" field. If "persistent-entity-id" is requested, the version tags of the dependent resources that may expose the entities in the response MUST also be included.
エンティティプロパティマップパーツの本文は、[RFC9240]のセクション7.6で定義されている形式と同じ形式を持つJSONオブジェクトです。JSONオブジェクトには、「メタ」フィールドに「従属VTAG」フィールドを含める必要があります。[RFC7285]のセクション10.3で定義されているように、「従属VTAGS」フィールドの値は、バージョンタグオブジェクトの配列でなければなりません。パスベクトル部分の「VTAG」は、「従属VTAG」フィールドに含める必要があります。「永続的エンティティID」が要求されている場合、応答内のエンティティを公開する可能性のある依存リソースのバージョンタグも含める必要があります。
The PropertyMapData object has one member for each ANEName that appears in the Path Vector part, which is an entity identifier belonging to the self-defined entity domain as defined in Section 5.1.2.3 of [RFC9240]. The EntityProps object for each ANE has one member for each property that is both 1) associated with the ANE and 2) specified in the "ane-property-names" field in the request. If the Path Vector cost type is not included in the "cost-type" field or the "multi-cost-type" field, the "property-map" field MUST be present and the value MUST be an empty object ({}).
PropertyMapDataオブジェクトには、[RFC9240]のセクション5.1.2.3で定義されている自己定義のエンティティドメインに属するエンティティ識別子であるパスベクトル部分に表示される各aneNameに1つのメンバーがあります。各ANEのEntityPropsオブジェクトには、各プロパティに1つのメンバーがあり、1）ANEに関連付けられており、2）リクエストの「ANE-Property-Names」フィールドで指定されています。パスベクトルコストタイプが「コストタイプ」フィールドまたは「マルチコストタイプ」フィールドに含まれていない場合、「プロパティマップ」フィールドが存在する必要があり、値は空のオブジェクトでなければなりません（{}）。
A complete and valid response MUST include both the Path Vector part and the property map part in the multipart message. If any part is *not* present, the client MUST discard the received information and send another request if necessary.
完全かつ有効な応答には、マルチパートメッセージのパスベクトルパーツとプロパティマップパーツの両方を含める必要があります。いずれかの部分が *存在しない場合、クライアントは受信した情報を破棄し、必要に応じて別のリクエストを送信する必要があります。
The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root body part as defined in [RFC2387]. Thus, it is the element that the application processes first. Even though the "start" parameter allows it to be placed anywhere in the part sequence, it is RECOMMENDED that the parts arrive in the same order as they are processed, i.e., the Path Vector part is always placed as the first part, followed by the property map part. When doing so, an ALTO server MAY choose not to set the "start" parameter, which implies that the first part is the object root.
メディアタイプがマルチパート応答メッセージの「タイプ」パラメーターと同じであるパスベクトル部分は、[RFC2387]で定義されているルート本体部分です。したがって、アプリケーションが最初に処理するのは要素です。「start」パラメーターをパーツシーケンスのどこにでも配置できますが、パーツが処理されるのと同じ順序で到着することをお勧めします。プロパティマップパーツ。その場合、ALTOサーバーは「start」パラメーターを設定しないことを選択できます。これは、最初の部分がオブジェクトルートであることを意味します。
Example: Consider the network in Figure 1. The response to the example request in Section 7.2.3 is as follows, where "ANE1" represents the aggregation of all the switches in the network.
例：図1のネットワークを考慮してください。セクション7.2.3の例の要求に対する応答は次のとおりです。ここで、「ANE1」はネットワーク内のすべてのスイッチの集約を表します。
HTTP/1.1 200 OK
Content-Length: 911
Content-Type: multipart/related; boundary=example-1;
type=application/alto-costmap+json
--example-1
Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json
{
"meta": {
"vtag": {
"resource-id": "filtered-cost-map-pv.costmap",
"tag": "fb20b76204814e9db37a51151faaaef2"
},
"dependent-vtags": [
{
"resource-id": "my-default-networkmap",
"tag": "75ed013b3cb58f896e839582504f6228"
}
],
"cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
},
"cost-map": {
"PID1": { "PID2": [ "ANE1" ] }
}
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "filtered-cost-map-pv.costmap",
"tag": "fb20b76204814e9db37a51151faaaef2"
}
]
},
"property-map": {
".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
}
}
--example-1
This document introduces a new ALTO resource called the "multipart Endpoint Cost Service", which allows an ALTO server to provide other ALTO resources associated with the Endpoint Cost Service resource in the same response.
このドキュメントでは、「マルチパートエンドポイントコストサービス」と呼ばれる新しいALTOリソースを紹介します。これにより、ALTOサーバーは、エンドポイントコストサービスリソースに関連する他のALTOリソースを同じ応答で提供できます。
The media type of the multipart Endpoint Cost Service resource is "multipart/related", and the required "type" parameter MUST have a value of "application/alto-endpointcost+json".
マルチパートエンドポイントコストサービスリソースのメディアタイプは「マルチパート/関連」であり、必要な「タイプ」パラメーターには「Application/Alto-EndpointCost JSON」の値が必要です。
The multipart Endpoint Cost Service resource is requested using the HTTP POST method.
HTTP POSTメソッドを使用して、マルチパートエンドポイントコストサービスリソースが要求されます。
The input parameters of the multipart Endpoint Cost Service resource are supplied in the body of an HTTP POST request. This document extends the input parameters to an Endpoint Cost Service, which is defined as a JSON object of type ReqEndpointCostMap in Section 4.2.2 of [RFC8189], with a data format indicated by the media type "application/alto-endpointcostparams+json", which is a JSON object of type PVReqEndpointCostMap:
MultiPartエンドポイントコストサービスリソースの入力パラメーターは、HTTP POSTリクエストの本文で提供されます。このドキュメントは、入力パラメーターをエンドポイントコストサービスに拡張します。これは、[RFC8189]のセクション4.2.2のタイプReqendPointCostmapのJSONオブジェクトとして定義されています。これは、pvreqendpointCostmapのタイプのJSONオブジェクトです。
object {
[EntityPropertyName ane-property-names<0..*>;]
} PVReqEndpointCostMap : ReqEndpointCostMap;
with field:
フィールドで：
ane-property-names: This document defines the "ane-property-names" field in PVReqEndpointCostMap as being the same as in PVReqFilteredCostMap. See Section 7.2.3.
Ane-Property-names：このドキュメントは、pvreqendpointCostmapの「ane-property-names」フィールドをpvreqfilteredcostmapと同じと定義しています。セクション7.2.3を参照してください。
Example: Consider the network in Figure 1. If an ALTO client wants to query the "max-reservable-bandwidth" setting between "eh1" and "eh2", it can submit the following request.
例：図1のネットワークを検討してください。ALTOクライアントが「EH1」と「EH2」の間の「Max-Reservable-BandWidth」設定をクエリしたい場合は、次のリクエストを送信できます。
POST /ecs/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-endpointcost+json,
application/alto-error+json
Content-Length: 238
Content-Type: application/alto-endpointcostparams+json
{
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"endpoints": {
"srcs": [ "ipv4:192.0.2.2" ],
"dsts": [ "ipv4:192.0.2.18" ]
},
"ane-property-names": [ "max-reservable-bandwidth" ]
}
The capabilities of the multipart Endpoint Cost Service resource are defined by a JSON object of type PVEndpointCostCapabilities, which is defined as being the same as PVFilteredCostMapCapabilities. See Section 7.2.4.
マルチパートエンドポイントコストサービスリソースの機能は、PVFilteredCostMapCapabilityと同じと定義されるPVENDPOINTCOSTCAPABILISTYのJSONオブジェクトによって定義されます。セクション7.2.4を参照してください。
If this resource supports "persistent-entity-id", it MUST also include the defining resources of persistent ANEs that may appear in the response.
このリソースが「永続的なエンティティID」をサポートする場合、応答に表示される可能性のある永続的なANEの定義リソースも含める必要があります。
The response MUST indicate an error, using ALTO Protocol error handling as defined in Section 8.5 of [RFC7285], if the request is invalid.
応答は、要求が無効な場合、[RFC7285]のセクション8.5で定義されているALTOプロトコルエラー処理を使用してエラーを示す必要があります。
The "Content-Type" header field of the response MUST be "multipart/ related" as defined by [RFC2387], with the following parameters:
応答の「コンテンツタイプ」ヘッダーフィールドは、次のパラメーターを使用して[RFC2387]で定義されている「マルチパート/関連」でなければなりません。
type: The "type" parameter MUST be "application/alto-endpointcost+json" and is mandatory.
タイプ：「タイプ」パラメーターは「Application/Alto-EndpointCost JSON」でなければならず、必須です。
start: The "start" parameter is as defined in Section 7.2.6.
開始：「開始」パラメーターは、セクション7.2.6で定義されています。
boundary: The "boundary" parameter is as defined in Section 5.1.1 of [RFC2046] and is mandatory.
境界：「境界」パラメーターは、[RFC2046]のセクション5.1.1で定義されており、必須です。
The body of the response MUST consist of two parts:
応答の本文は、次の2つの部分で構成されている必要があります。
* The Path Vector part MUST include "Content-ID" and "Content-Type" in its header. The "Content-Type" MUST be "application/alto-endpointcost+json". The value of "Content-ID" MUST have the same format as the Part Content ID as specified in Section 6.6.
* パスベクトル部分には、ヘッダーに「コンテンツID」と「コンテンツタイプ」を含める必要があります。「コンテンツタイプ」は「アプリケーション/Alto-EndpointCost JSON」でなければなりません。「Content-ID」の値には、セクション6.6で指定された部品コンテンツIDと同じ形式が必要です。
The body of the Path Vector part MUST be a JSON object with the same format as that defined in Section 11.5.1.6 of [RFC7285] when the "cost-type" field is present in the input parameters and MUST be a JSON object with the same format as that defined in Section 4.2.3 of [RFC8189] if the "multi-cost-types" field is present. The JSON object MUST include the "vtag" field in the "meta" field, which provides the version tag of the returned EndpointCostMapData object. The resource ID of the version tag MUST follow the format of
パスベクトル部分の本体は、[RFC7285]のセクション11.5.1.6で定義されている形式と同じ形式を持つJSONオブジェクトでなければなりません。[RFC8189]のセクション4.2.3で「マルチコストタイプ」フィールドが存在する場合、同じ形式と同じ形式。JSONオブジェクトには、返されたEndpointCostmapDataオブジェクトのバージョンタグを提供する「メタ」フィールドに「VTAG」フィールドを含める必要があります。バージョンタグのリソースIDは、
resource-id '.' part-resource-id
Resource-ID '。'Part-Resource-id
where "resource-id" is the resource ID of the Path Vector resource and "part-resource-id" has the same value as the PART-RESOURCE-ID in the "Content-ID" of the Path Vector part.
ここで、「Resource-ID」はパスベクトルリソースのリソースIDであり、「Part-Resource-ID」は、パスベクトル部分の「コンテンツID」のパートリソース-IDと同じ値を持っています。
* The entity property map part MUST also include "Content-ID" and "Content-Type" in its header. The "Content-Type" MUST be "application/alto-propmap+json". The value of "Content-ID" MUST have the same format as the Part Content ID as specified in Section 6.6.
* エンティティプロパティマップパーツには、ヘッダーに「コンテンツID」と「コンテンツタイプ」も含める必要があります。「コンテンツタイプ」は「アプリケーション/ALTO-PROPMAP JSON」でなければなりません。「Content-ID」の値には、セクション6.6で指定された部品コンテンツIDと同じ形式が必要です。
The body of the entity property map part MUST be a JSON object with the same format as that defined in Section 7.6 of [RFC9240]. The JSON object MUST include the "dependent-vtags" field in the "meta" field. The value of the "dependent-vtags" field MUST be an array of VersionTag objects as defined by Section 10.3 of [RFC7285]. The "vtag" of the Path Vector part MUST be included in the "dependent-vtags" field. If "persistent-entity-id" is requested, the version tags of the dependent resources that may expose the entities in the response MUST also be included.
エンティティプロパティマップパーツの本文は、[RFC9240]のセクション7.6で定義されている形式と同じ形式を持つJSONオブジェクトでなければなりません。JSONオブジェクトには、「メタ」フィールドに「従属VTAG」フィールドを含める必要があります。[RFC7285]のセクション10.3で定義されているように、「従属VTAGS」フィールドの値は、バージョンタグオブジェクトの配列でなければなりません。パスベクトル部分の「VTAG」は、「従属VTAG」フィールドに含める必要があります。「永続的エンティティID」が要求されている場合、応答内のエンティティを公開する可能性のある従属リソースのバージョンタグも含める必要があります。
The PropertyMapData object has one member for each ANEName that appears in the Path Vector part, which is an entity identifier belonging to the self-defined entity domain as defined in Section 5.1.2.3 of [RFC9240]. The EntityProps object for each ANE has one member for each property that is both 1) associated with the ANE and 2) specified in the "ane-property-names" field in the request. If the Path Vector cost type is not included in the "cost-type" field or the "multi-cost-type" field, the "property-map" field MUST be present and the value MUST be an empty object ({}).
PropertyMapDataオブジェクトには、[RFC9240]のセクション5.1.2.3で定義されている自己定義のエンティティドメインに属するエンティティ識別子であるパスベクトル部分に表示される各aneNameに1つのメンバーがあります。各ANEのEntityPropsオブジェクトには、各プロパティに1つのメンバーがあり、1）ANEに関連付けられており、2）リクエストの「ANE-Property-Names」フィールドで指定されています。パスベクトルコストタイプが「コストタイプ」フィールドまたは「マルチコストタイプ」フィールドに含まれていない場合、「プロパティマップ」フィールドが存在する必要があり、値は空のオブジェクトでなければなりません（{}）。
A complete and valid response MUST include both the Path Vector part and the property map part in the multipart message. If any part is *not* present, the client MUST discard the received information and send another request if necessary.
完全かつ有効な応答には、マルチパートメッセージのパスベクトルパーツとプロパティマップパーツの両方を含める必要があります。いずれかの部分が *存在しない場合、クライアントは受信した情報を破棄し、必要に応じて別のリクエストを送信する必要があります。
The Path Vector part, whose media type is the same as the "type" parameter of the multipart response message, is the root body part as defined in [RFC2387]. Thus, it is the element that the application processes first. Even though the "start" parameter allows it to be placed anywhere in the part sequence, it is RECOMMENDED that the parts arrive in the same order as they are processed, i.e., the Path Vector part is always placed as the first part, followed by the property map part. When doing so, an ALTO server MAY choose not to set the "start" parameter, which implies that the first part is the object root.
メディアタイプがマルチパート応答メッセージの「タイプ」パラメーターと同じであるパスベクトル部分は、[RFC2387]で定義されているルート本体部分です。したがって、アプリケーションが最初に処理するのは要素です。「start」パラメーターをパーツシーケンスのどこにでも配置できますが、パーツが処理されるのと同じ順序で到着することをお勧めします。プロパティマップパーツ。その場合、ALTOサーバーは「start」パラメーターを設定しないことを選択できます。これは、最初の部分がオブジェクトルートであることを意味します。
Example: Consider the network in Figure 1. The response to the example request in Section 7.3.3 is as follows.
例：図1のネットワークを考えてみましょう。セクション7.3.3の例の要求に対する応答は次のとおりです。
HTTP/1.1 200 OK
Content-Length: 899
Content-Type: multipart/related; boundary=example-1;
type=application/alto-endpointcost+json
--example-1
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json
{
"meta": {
"vtag": {
"resource-id": "ecs-pv.ecs",
"tag": "ec137bb78118468c853d5b622ac003f1"
},
"dependent-vtags": [
{
"resource-id": "my-default-networkmap",
"tag": "677fe5f4066848d282ece213a84f9429"
}
],
"cost-type": { "cost-mode": "array", "cost-metric": "ane-path" }
},
"cost-map": {
"ipv4:192.0.2.2": { "ipv4:192.0.2.18": [ "ANE1" ] }
}
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "ecs-pv.ecs",
"tag": "ec137bb78118468c853d5b622ac003f1"
}
]
},
"property-map": {
".ane:ANE1": { "max-reservable-bandwidth": 100000000 }
}
}
--example-1
This section lists some examples of Path Vector queries and the corresponding responses. Some long lines are truncated for better readability.
このセクションには、パスベクトルクエリと対応する応答の例をいくつか示します。いくつかの長い線は、読みやすくするために切り捨てられます。
Figure 10 illustrates the network properties and thus the message contents. There are three subnetworks (NET1, NET2, and NET3) and two interconnection links (L1 and L2). It is assumed that each subnetwork has sufficiently large bandwidth to be reserved.
図10は、ネットワークのプロパティとメッセージの内容を示しています。3つのサブネットワーク（Net1、Net2、およびNet3）と2つの相互接続リンク（L1およびL2）があります。各サブネットワークには、予約するのに十分な大きな帯域幅があると想定されています。
----- L1
/
PID1 +----------+ 10 Gbps +----------+ PID3
192.0.2.0/28+-+ +------+ +---------+ +--+192.0.2.32/28
| | MEC1 | | | | 2001:db8::3:0/16
| +------+ | +-----+ |
PID2 | | | +----------+
192.0.2.16/28+-+ | | NET3
| | | 15 Gbps
| | | \
+----------+ | -------- L2
NET1 |
+----------+
| +------+ | PID4
| | MEC2 | +--+192.0.2.48/28
| +------+ | 2001:db8::4:0/16
+----------+
NET2
Figure 10: Examples of ANE Properties
図10：ANEプロパティの例
To give a comprehensive example of the extension defined in this document, we consider the network in Figure 10. Assume that the ALTO server provides the following information resources:
このドキュメントで定義されている拡張機能の包括的な例を示すために、図10のネットワークを検討します。ALTOサーバーが次の情報リソースを提供していると仮定します。
"my-default-networkmap": A network map resource that contains the PIDs in the network.
「My-Default-NetworkMap」：ネットワーク内のPIDを含むネットワークマップリソース。
"filtered-cost-map-pv": A multipart filtered cost map resource for the Path Vector. Exposes the "max-reservable-bandwidth" property for the PIDs in "my-default-networkmap".
「Filtered-Cost-Map-PV」：パスベクトルのマルチパートフィルタリングコストマップリソース。「My-Default-NetworkMap」のPIDSの「Max-Reservable-BandWidth」プロパティを公開します。
"ane-props": A filtered entity property resource that exposes the information for persistent ANEs in the network.
「ANE-Props」：ネットワーク内の永続的なANEの情報を公開するフィルタリングされたエンティティプロパティリソース。
"endpoint-cost-pv": A multipart Endpoint Cost Service for the Path Vector. Exposes the "max-reservable-bandwidth" and "persistent-entity-id" properties.
「Endpoint-Cost-PV」：パスベクトルのマルチパートエンドポイントコストサービス。「Max-Reservable-BandWidth」および「永続的エンティティID」プロパティを公開します。
"update-pv": An update stream service that provides the incremental update service for the "endpoint-cost-pv" service.
「Update-PV」：「Endpoint-Cost-PV」サービスの増分更新サービスを提供する更新ストリームサービス。
"multicost-pv": A multipart Endpoint Cost Service with both the Multi-Cost extension and Path Vector extension enabled.
「Multicost-PV」：マルチコスト拡張機能とパスベクトル拡張機能の両方を備えたマルチパートエンドポイントコストサービス。
Below is the IRD of the example ALTO server. To enable the extension defined in this document, the Path Vector cost type (Section 6.5), represented by "path-vector" below, is defined in the "cost-types" of the "meta" field and is included in the "cost-type-names" of resources "filtered-cost-map-pv" and "endpoint-cost-pv".
以下は、ALTOサーバーの例のIRDです。このドキュメントで定義されている拡張機能を有効にするために、以下の「パスベクトル」で表されるパスベクトルコストタイプ（セクション6.5）は、「メタ」フィールドの「コストタイプ」で定義され、「コストに含まれています。-Type-Names「Filtered-Cost-Map-PV」および「Endpoint-Cost-PV」の「フィルタリング」。
{
"meta": {
"cost-types": {
"path-vector": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"num-rc": {
"cost-mode": "numerical",
"cost-metric": "routingcost"
}
}
},
"resources": {
"my-default-networkmap": {
"uri": "https://alto.example.com/networkmap",
"media-type": "application/alto-networkmap+json"
},
"filtered-cost-map-pv": {
"uri": "https://alto.example.com/costmap/pv",
"media-type": "multipart/related;
type=application/alto-costmap+json",
"accepts": "application/alto-costmapfilter+json",
"capabilities": {
"cost-type-names": [ "path-vector" ],
"ane-property-names": [ "max-reservable-bandwidth" ]
},
"uses": [ "my-default-networkmap" ]
},
"ane-props": {
"uri": "https://alto.example.com/ane-props",
"media-type": "application/alto-propmap+json",
"accepts": "application/alto-propmapparams+json",
"capabilities": {
"mappings": {
".ane": [ "cpu" ]
}
}
},
"endpoint-cost-pv": {
"uri": "https://alto.exmaple.com/endpointcost/pv",
"media-type": "multipart/related;
type=application/alto-endpointcost+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"cost-type-names": [ "path-vector" ],
"ane-property-names": [
"max-reservable-bandwidth", "persistent-entity-id"
]
},
"uses": [ "ane-props" ]
},
"update-pv": {
"uri": "https://alto.example.com/updates/pv",
"media-type": "text/event-stream",
"uses": [ "endpoint-cost-pv" ],
"accepts": "application/alto-updatestreamparams+json",
"capabilities": {
"support-stream-control": true
}
},
"multicost-pv": {
"uri": "https://alto.exmaple.com/endpointcost/mcpv",
"media-type": "multipart/related;
type=application/alto-endpointcost+json",
"accepts": "application/alto-endpointcostparams+json",
"capabilities": {
"cost-type-names": [ "path-vector", "num-rc" ],
"max-cost-types": 2,
"testable-cost-type-names": [ "num-rc" ],
"ane-property-names": [
"max-reservable-bandwidth", "persistent-entity-id"
]
},
"uses": [ "ane-props" ]
}
}
}
The following examples demonstrate the request to the "filtered-cost-map-pv" resource and the corresponding response.
次の例は、「フィルターコスト-MAP-PV」リソースへのリクエストと対応する応答を示しています。
The request uses the "path-vector" cost type in the "cost-type" field. The "ane-property-names" field is missing, indicating that the client only requests the Path Vector and not the ANE properties.
リクエストでは、「コストタイプ」フィールドで「パスベクトル」コストタイプを使用します。「ANE-Property-names」フィールドが欠落しており、クライアントがANEプロパティではなくパスベクトルのみを要求することを示しています。
The response consists of two parts:
応答は2つの部分で構成されています。
* The first part returns the array of data type ANEName for each source and destination pair. There are two ANEs, where "L1" represents interconnection link L1 and "L2" represents interconnection link L2.
* 最初の部分は、各ソースと宛先ペアのデータ型ANENAMEの配列を返します。2つのANEがあり、「L1」は相互接続リンクL1を表し、「L2」は相互接続リンクL2を表します。
* The second part returns the property map. Note that the properties of the ANE entries are equal to the literal string "{}" (see Section 8.3 of [RFC9240]).
* 2番目の部分はプロパティマップを返します。ANEエントリのプロパティは、リテラル文字列「{}」に等しいことに注意してください（[RFC9240]のセクション8.3を参照）。
POST /costmap/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;type=application/alto-costmap+json,
application/alto-error+json
Content-Length: 163
Content-Type: application/alto-costmapfilter+json
{
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"pids": {
"srcs": [ "PID1" ],
"dsts": [ "PID3", "PID4" ]
}
}
HTTP/1.1 200 OK
Content-Length: 952
Content-Type: multipart/related; boundary=example-1;
type=application/alto-costmap+json
--example-1
Content-ID: <costmap@alto.example.com>
Content-Type: application/alto-costmap+json
{
"meta": {
"vtag": {
"resource-id": "filtered-cost-map-pv.costmap",
"tag": "d827f484cb66ce6df6b5077cb8562b0a"
},
"dependent-vtags": [
{
"resource-id": "my-default-networkmap",
"tag": "c04bc5da49534274a6daeee8ea1dec62"
}
],
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
}
},
"cost-map": {
"PID1": {
"PID3": [ "L1" ],
"PID4": [ "L1", "L2" ]
}
}
}
--example-1
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "filtered-cost-map-pv.costmap",
"tag": "d827f484cb66ce6df6b5077cb8562b0a"
}
]
},
"property-map": {
".ane:L1": {},
".ane:L2": {}
}
}
--example-1
The following examples demonstrate the request to the "endpoint-cost-pv" resource and the corresponding response.
次の例は、「エンドポイントコスト-PV」リソースへのリクエストと対応する応答を示しています。
The request uses the "path-vector" cost type in the "cost-type" field and queries the maximum reservable bandwidth ANE property and the persistent entity ID property for two IPv4 source and destination pairs (192.0.2.34 -> 192.0.2.2 and 192.0.2.34 -> 192.0.2.50) and one IPv6 source and destination pair (2001:db8::3:1 -> 2001:db8::4:1).
リクエストは、「コストタイプ」フィールドの「パスベクトル」コストタイプを使用し、2つのIPv4ソースと宛先ペア（192.0.2.34-> 192.0.2.2および192.0.2.2および192.0.2.34-> 192.0.2.50）および1つのIPv6ソースと宛先ペア（2001：DB8 :: 3：1-> 2001：DB8 :: 4：1）。
The response consists of two parts:
応答は2つの部分で構成されています。
* The first part returns the array of data type ANEName for each valid source and destination pair. As one can see in Figure 10, flow 192.0.2.34 -> 192.0.2.2 traverses NET3, L1, and NET1; and flows 192.0.2.34 -> 192.0.2.50 and 2001:db8::3:1 -> 2001:db8::4:1 traverse NET2, L2, and NET3.
* 最初の部分は、有効なソースと宛先ペアごとにデータ型ANENAMEの配列を返します。図10でわかるように、Flow 192.0.2.34-> 192.0.2.2 Traverses Net3、L1、およびNet1。フロー192.0.2.34-> 192.0.2.50および2001：db8 :: 3：1-> 2001：db8 :: 4：1トラバースNet2、L2、およびNet3。
* The second part returns the requested properties of ANEs. Assume that NET1, NET2, and NET3 have sufficient bandwidth and their "max-reservable-bandwidth" values are set to a sufficiently large number (50 Gbps in this case). On the other hand, assume that there are no prior reservations on L1 and L2 and their "max-reservable-bandwidth" values are the corresponding link capacity (10 Gbps for L1 and 15 Gbps for L2).
* 2番目の部分は、ANESの要求されたプロパティを返します。Net1、Net2、およびNet3に十分な帯域幅があり、それらの「最大販売可能帯域幅」値が十分に多数（この場合は50 gbps）に設定されていると仮定します。一方、L1とL2に事前の予約がなく、それらの「最大販売可能な帯域幅」値が対応するリンク容量（L1で10 Gbps、L2で15 Gbps）であると仮定します。
Both NET1 and NET2 have a mobile edge deployed, i.e., MEC1 in NET1 and MEC2 in NET2. Assume that the ANEName values for MEC1 and MEC2 are "MEC1" and "MEC2" and their properties can be retrieved from the property map "ane-props". Thus, the "persistent-entity-id" property values for NET1 and NET2 are "ane-props.ane:MEC1" and "ane-props.ane:MEC2", respectively.
net1とnet2の両方に、モバイルエッジが展開されています。つまり、net1のmec1とnet2のmec2が展開されています。MEC1とMEC2のANENAME値が「MEC1」と「MEC2」であり、プロパティマップ「ANE-Props」からそれらのプロパティを取得できると仮定します。したがって、net1とnet2の「永続的エンティティID」プロパティ値は、それぞれ「ane：mec1」と「ane-props.ane：mec2」です。
POST /endpointcost/pv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
type=application/alto-endpointcost+json,
application/alto-error+json
Content-Length: 383
Content-Type: application/alto-endpointcostparams+json
{
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
},
"endpoints": {
"srcs": [
"ipv4:192.0.2.34",
"ipv6:2001:db8::3:1"
],
"dsts": [
"ipv4:192.0.2.2",
"ipv4:192.0.2.50",
"ipv6:2001:db8::4:1"
]
},
"ane-property-names": [
"max-reservable-bandwidth",
"persistent-entity-id"
]
}
HTTP/1.1 200 OK
Content-Length: 1508
Content-Type: multipart/related; boundary=example-2;
type=application/alto-endpointcost+json
--example-2
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json
{
"meta": {
"vtags": {
"resource-id": "endpoint-cost-pv.ecs",
"tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
},
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.34": {
"ipv4:192.0.2.2": [ "NET3", "L1", "NET1" ],
"ipv4:192.0.2.50": [ "NET3", "L2", "NET2" ]
},
"ipv6:2001:db8::3:1": {
"ipv6:2001:db8::4:1": [ "NET3", "L2", "NET2" ]
}
}
}
--example-2
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "endpoint-cost-pv.ecs",
"tag": "bb6bb72eafe8f9bdc4f335c7ed3b10822a391cef"
},
{
"resource-id": "ane-props",
"tag": "bf3c8c1819d2421c9a95a9d02af557a3"
}
]
},
"property-map": {
".ane:NET1": {
"max-reservable-bandwidth": 50000000000,
"persistent-entity-id": "ane-props.ane:MEC1"
},
".ane:NET2": {
"max-reservable-bandwidth": 50000000000,
"persistent-entity-id": "ane-props.ane:MEC2"
},
".ane:NET3": {
"max-reservable-bandwidth": 50000000000
},
".ane:L1": {
"max-reservable-bandwidth": 10000000000
},
".ane:L2": {
"max-reservable-bandwidth": 15000000000
}
}
}
--example-2
In certain scenarios where the traversal order is not crucial, an ALTO server implementation may choose not to strictly follow the physical traversal order and may even obfuscate the order intentionally to preserve its own privacy or conform to its own policies. For example, an ALTO server may choose to aggregate NET1 and L1 as a new ANE with ANE name "AGGR1" and aggregate NET2 and L2 as a new ANE with ANE name "AGGR2". The "max-reservable-bandwidth" property of "AGGR1" takes the value of L1, which is smaller than that of NET1, and the "persistent-entity-id" property of "AGGR1" takes the value of NET1. The properties of "AGGR2" are computed in a similar way; the obfuscated response is as shown below. Note that the obfuscation of Path Vector responses is implementation specific and is out of scope for this document. Developers may refer to Section 11 for further references.
トラバーサル順序が重要ではない特定のシナリオでは、ALTOサーバーの実装は、物理的なトラバーサル順序に厳密に従わないことを選択し、独自のプライバシーを維持したり、独自のポリシーに準拠したりするために順序を意図的に難読化することさえあります。たとえば、ALTOサーバーは、ANE名「Aggr1」を備えた新しいANEとしてNet1とL1を集約し、ANE名「Aggr2」を持つ新しいANEとしてNet2とL2を集約することを選択できます。「aggr1」の「最大復元可能な帯域幅」プロパティは、net1の値よりも小さく、「aggr1」の「永続的なエンティティid」プロパティをnet1の値を取得します。「Aggr2」の特性は同様の方法で計算されます。難読化された応答は、以下に示すとおりです。パスベクトル応答の難読化は実装固有であり、このドキュメントの範囲外であることに注意してください。開発者は、さらなる参照についてはセクション11を参照できます。
HTTP/1.1 200 OK
Content-Length: 1333
Content-Type: multipart/related; boundary=example-2;
type=application/alto-endpointcost+json
--example-2
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json
{
"meta": {
"vtags": {
"resource-id": "endpoint-cost-pv.ecs",
"tag": "bb975862fbe3422abf4dae386b132c1d"
},
"cost-type": {
"cost-mode": "array",
"cost-metric": "ane-path"
}
},
"endpoint-cost-map": {
"ipv4:192.0.2.34": {
"ipv4:192.0.2.2": [ "NET3", "AGGR1" ],
"ipv4:192.0.2.50": [ "NET3", "AGGR2" ]
},
"ipv6:2001:db8::3:1": {
"ipv6:2001:db8::4:1": [ "NET3", "AGGR2" ]
}
}
}
--example-2
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "endpoint-cost-pv.ecs",
"tag": "bb975862fbe3422abf4dae386b132c1d"
},
{
"resource-id": "ane-props",
"tag": "bf3c8c1819d2421c9a95a9d02af557a3"
}
]
},
"property-map": {
".ane:AGGR1": {
"max-reservable-bandwidth": 10000000000,
"persistent-entity-id": "ane-props.ane:MEC1"
},
".ane:AGGR2": {
"max-reservable-bandwidth": 15000000000,
"persistent-entity-id": "ane-props.ane:MEC2"
},
".ane:NET3": {
"max-reservable-bandwidth": 50000000000
}
}
}
--example-2
In this example, an ALTO client subscribes to the incremental update for the multipart Endpoint Cost Service resource "endpoint-cost-pv".
この例では、ALTOクライアントは、マルチパートエンドポイントコストサービスリソース「Endpoint-COST-PV」の増分更新プログラムを購読しています。
POST /updates/pv HTTP/1.1
Host: alto.example.com
Accept: text/event-stream
Content-Type: application/alto-updatestreamparams+json
Content-Length: 120
{
"add": {
"ecspvsub1": {
"resource-id": "endpoint-cost-pv",
"input": <ecs-input>
}
}
}
Based on the server-side process defined in [RFC8895], the ALTO server will send the "control-uri" first, using a Server-Sent Event (SSE) followed by the full response of the multipart message.
[RFC8895]で定義されているサーバー側のプロセスに基づいて、ALTOサーバーは最初に「Control-URI」を送信し、サーバーセントイベント（SSE）を使用してマルチパートメッセージの完全な応答を使用します。
HTTP/1.1 200 OK Connection: keep-alive Content-Type: text/event-stream
http/1.1 200 ok接続：キープアライブコンテンツタイプ：テキスト/イベントストリーム
event: application/alto-updatestreamcontrol+json
data: {"control-uri": "https://alto.example.com/updates/streams/123"}
event: multipart/related;boundary=example-3;
type=application/alto-endpointcost+json,ecspvsub1
data: --example-3
data: Content-ID: <ecsmap@alto.example.com>
data: Content-Type: application/alto-endpointcost+json
data:
data: <endpoint-cost-map-entry>
data: --example-3
data: Content-ID: <propmap@alto.example.com>
data: Content-Type: application/alto-propmap+json
data:
data: <property-map-entry>
data: --example-3--
When the contents change, the ALTO server will publish the updates for each node in this tree separately, based on Section 6.7.3 of [RFC8895].
コンテンツが変更されると、ALTOサーバーは[RFC8895]のセクション6.7.3に基づいて、このツリーの各ノードの更新を個別に公開します。
event: application/merge-patch+json,
ecspvsub1.ecsmap@alto.example.com
data: <Merge patch for endpoint-cost-map-update>
event: application/merge-patch+json,
ecspvsub1.propmap@alto.example.com
data: <Merge patch for property-map-update>
The following examples demonstrate the request to the "multicost-pv" resource and the corresponding response.
次の例は、「マルチコスト-PV」リソースへのリクエストと対応する応答を示しています。
The request asks for two cost types: the first is the Path Vector cost type, and the second is a numerical routing cost. It also queries the maximum reservable bandwidth ANE property and the persistent entity ID property for two IPv4 source and destination pairs (192.0.2.34 -> 192.0.2.2 and 192.0.2.34 -> 192.0.2.50) and one IPv6 source and destination pair (2001:db8::3:1 -> 2001:db8::4:1).
リクエストは2つのコストタイプを要求します。1つ目はパスベクトルコストタイプ、2つ目は数値ルーティングコストです。また、2つのIPv4ソースと宛先ペア（192.0.2.34-> 192.0.2.2および192.0.2.34-> 192.0.2.50）と1つのIPV6ソースと宛先ペアの最大予約可能な帯域幅ANEプロパティと永続的なエンティティIDプロパティをクエリします。：db8 :: 3：1-> 2001：db8 :: 4：1）。
The response consists of two parts:
応答は2つの部分で構成されています。
* The first part returns a JSONArray that contains two JSONValue entries for each requested source and destination pair: the first JSONValue is a JSONArray of ANENames, which is the value of the Path Vector cost type; and the second JSONValue is a JSONNumber, which is the value of the routing cost.
* 最初の部分は、要求された各ソースと宛先ペアの2つのjSonValueエントリを含むJSonArrayを返します。最初のJSonValueは、パスベクトルコストタイプの値であるAnenamesのJSonarrayです。2番目のjsonvalueはjsonnumberであり、これがルーティングコストの価値です。
* The second part contains a property map that maps the ANEs to their requested properties.
* 2番目の部分には、ANEを要求されたプロパティにマッピングするプロパティマップが含まれています。
POST /endpointcost/mcpv HTTP/1.1
Host: alto.example.com
Accept: multipart/related;
type=application/alto-endpointcost+json,
application/alto-error+json
Content-Length: 454
Content-Type: application/alto-endpointcostparams+json
{
"multi-cost-types": [
{ "cost-mode": "array", "cost-metric": "ane-path" },
{ "cost-mode": "numerical", "cost-metric": "routingcost" }
],
"endpoints": {
"srcs": [
"ipv4:192.0.2.34",
"ipv6:2001:db8::3:1"
],
"dsts": [
"ipv4:192.0.2.2",
"ipv4:192.0.2.50",
"ipv6:2001:db8::4:1"
]
},
"ane-property-names": [
"max-reservable-bandwidth",
"persistent-entity-id"
]
}
HTTP/1.1 200 OK
Content-Length: 1419
Content-Type: multipart/related; boundary=example-4;
type=application/alto-endpointcost+json
--example-4
Content-ID: <ecs@alto.example.com>
Content-Type: application/alto-endpointcost+json
{
"meta": {
"vtags": {
"resource-id": "endpoint-cost-pv.ecs",
"tag": "84a4f9c14f9341f0983e3e5f43a371c8"
},
"multi-cost-types": [
{ "cost-mode": "array", "cost-metric": "ane-path" },
{ "cost-mode": "numerical", "cost-metric": "routingcost" }
]
},
"endpoint-cost-map": {
"ipv4:192.0.2.34": {
"ipv4:192.0.2.2": [[ "NET3", "AGGR1" ], 3],
"ipv4:192.0.2.50": [[ "NET3", "AGGR2" ], 2]
},
"ipv6:2001:db8::3:1": {
"ipv6:2001:db8::4:1": [[ "NET3", "AGGR2" ], 2]
}
}
}
--example-4
Content-ID: <propmap@alto.example.com>
Content-Type: application/alto-propmap+json
{
"meta": {
"dependent-vtags": [
{
"resource-id": "endpoint-cost-pv.ecs",
"tag": "84a4f9c14f9341f0983e3e5f43a371c8"
},
{
"resource-id": "ane-props",
"tag": "be157afa031443a187b60bb80a86b233"
}
]
},
"property-map": {
".ane:AGGR1": {
"max-reservable-bandwidth": 10000000000,
"persistent-entity-id": "ane-props.ane:MEC1"
},
".ane:AGGR2": {
"max-reservable-bandwidth": 15000000000,
"persistent-entity-id": "ane-props.ane:MEC2"
},
".ane:NET3": {
"max-reservable-bandwidth": 50000000000
}
}
}
--example-4
The multipart filtered cost map resource and the multipart Endpoint Cost Service resource have no backward-compatibility issues with legacy ALTO clients and servers. Although these two types of resources reuse the media types defined in the base ALTO Protocol for the "Accept" input parameters, they have different media types for responses. If the ALTO server provides these two types of resources but the ALTO client does not support them, the ALTO client will ignore the resources without incurring any incompatibility problems.
マルチパートフィルタリングコストマップリソースとマルチパートエンドポイントコストサービスリソースには、レガシーALTOのクライアントとサーバーに関する後方互換性の問題はありません。これらの2種類のリソースは、「受け入れる」入力パラメーターのベースALTOプロトコルで定義されているメディアタイプを再利用しますが、応答用のさまざまなメディアタイプがあります。ALTOサーバーがこれらの2種類のリソースを提供しているが、ALTOクライアントがそれらをサポートしていない場合、ALTOクライアントは非互換性の問題を伴うことなくリソースを無視します。
The extension defined in this document is compatible with the multi-cost extension [RFC8189]. Such a resource has a media type of either "multipart/related; type=application/alto-costmap+json" or "multipart/related; type=application/alto-endpointcost+json". Its "cost-constraints" field must be either "false" or not present, and the Path Vector cost type must be present in the "cost-type-names" capability field but must not be present in the "testable-cost-type-names" field, as specified in Sections 7.2.4 and 7.3.4.
このドキュメントで定義されている拡張機能は、マルチコスト拡張[RFC8189]と互換性があります。このようなリソースには、メディアタイプの「MultiPart/関連; Type = Application/ALTO-COSTMAP JSON」または「MultiPart/関連; Type = Application/Alto-EndpointCost JSON」のいずれかがあります。その「コスト制約」フィールドは「false」または存在しないかのいずれかでなければならず、パスベクトルコストタイプは「コストタイプの名前」機能フィールドに存在する必要がありますが、「テスト可能なコストタイプ」に存在してはなりません。-names "フィールド、セクション7.2.4および7.3.4で指定されています。
This extension is compatible with the incremental update extension [RFC8895]. ALTO clients and servers MUST follow the specifications given in Sections 5.2 and 6.7.3 of [RFC8895] to support incremental updates for a Path Vector resource.
この拡張機能は、増分アップデート拡張[RFC8895]と互換性があります。ALTOクライアントとサーバーは、[RFC8895]のセクション5.2および6.7.3の仕様に従って、パスベクトルリソースの増分更新をサポートする必要があります。
The extension specified in this document is compatible with the Cost Calendar extension [RFC8896]. When used together with the Cost Calendar extension, the cost value between a source and a destination is an array of Path Vectors, where the k-th Path Vector refers to the abstract network paths traversed in the k-th time interval by traffic from the source to the destination.
このドキュメントで指定された拡張機能は、コストカレンダー拡張[RFC8896]と互換性があります。コストカレンダー拡張機能と一緒に使用する場合、ソースと宛先間のコスト値はパスベクトルの配列です。ここでは、k番目のパスベクトルは、k番目のネットワークパスを指します。目的地へのソース。
When used with time-varying properties, e.g., maximum reservable bandwidth, a property of a single ANE may also have different values in different time intervals. In this case, if such an ANE has different property values in two time intervals, it MUST be treated as two different ANEs, i.e., with different entity identifiers. However, if it has the same property values in two time intervals, it MAY use the same identifier.
時変プロパティ、たとえば最大予約可能な帯域幅で使用する場合、単一のANEのプロパティは、異なる時間間隔で異なる値を持つ場合があります。この場合、そのようなANEが2つの時間間隔で異なるプロパティ値を持っている場合、2つの異なるANE、つまり異なるエンティティ識別子を扱う必要があります。ただし、2つの時間間隔で同じプロパティ値がある場合、同じ識別子を使用する場合があります。
This rule allows the Path Vector extension to represent both changes of ANEs and changes of the ANEs' properties in a uniform way. The Path Vector part is calendared in a compatible way, and the property map part is not affected by the Cost Calendar extension.
このルールにより、パスベクトル拡張は、ANESの変化とANESのプロパティの変化の両方を均一な方法で表すことができます。パスベクトル部分は互換性のある方法でカレンダーされ、プロパティマップパーツはコストカレンダー拡張の影響を受けません。
The two extensions combined together can provide the historical network correlation information for a set of source and destination pairs. A network broker or client may use this information to derive other resource requirements such as Time-Block-Maximum Bandwidth, Bandwidth-Sliding-Window, and Time-Bandwidth-Product (TBP) (see [SENSE] for details).
2つの拡張機能を組み合わせることで、ソースと宛先のペアのセットに履歴ネットワーク相関情報を提供できます。ネットワークブローカーまたはクライアントは、この情報を使用して、Time-Block-Maximum帯域幅、帯域幅スライディングウィンドウ、Time Bandwidth-Product（TBP）などの他のリソース要件を導き出すことができます（詳細については[Sense]を参照）。
The constraint test is a simple approach for querying the data. It allows users to filter query results by specifying some boolean tests. This approach is already used in the ALTO Protocol. ALTO clients are permitted to specify either the "constraints" test [RFC7285] [RFC8189] or the "or-constraints" test [RFC8189] to better filter the results.
制約テストは、データを照会するための簡単なアプローチです。これにより、ユーザーはいくつかのブールテストを指定することにより、クエリ結果をフィルタリングできます。このアプローチは、すでにALTOプロトコルで使用されています。ALTOクライアントは、結果をより適切にフィルタリングするために、「制約」テスト[RFC7285] [RFC8189]または「Orconstraints」テスト[RFC8189]を指定することが許可されています。
However, the current syntax can only be used to test scalar cost types and cannot easily express constraints on complex cost types, e.g., the Path Vector cost type defined in this document.
ただし、現在の構文は、スカラーコストタイプをテストするためにのみ使用でき、複雑なコストタイプ、たとえばこのドキュメントで定義されているパスベクトルコストタイプの制約を簡単に表現することはできません。
In practice, developing a bespoke language for general-purpose boolean tests can be a complex undertaking, and it is conceivable that such implementations already exist (the authors have not done an exhaustive search to determine whether such implementations exist). One avenue for developing such a language may be to explore extending current query languages like XQuery [XQuery] or JSONiq [JSONiq] and integrating these with ALTO.
実際には、汎用ブールテストのための特注言語の開発は複雑な取り組みであり、そのような実装がすでに存在すると考えられます（著者は、そのような実装が存在するかどうかを判断するための徹底的な検索を行っていません）。このような言語を開発するための1つの手段は、Xquery [Xquery]やJsoniq [Jsoniq]などの現在のクエリ言語を拡張し、これらをALTOと統合することです。
Filtering the Path Vector results or developing a more sophisticated filtering mechanism is beyond the scope of this document.
パスベクトルの結果のフィルタリングまたはより洗練されたフィルタリングメカニズムの開発は、このドキュメントの範囲を超えています。
Querying multiple ALTO information resources continuously is a general requirement. Enabling such a capability, however, must address general issues like efficiency and consistency. The incremental update extension [RFC8895] supports submitting multiple queries in a single request and allows flexible control over the queries. However, it does not cover the case introduced in this document where multiple resources are needed for a single request.
複数のALTO情報リソースを継続的にクエリすることは、一般的な要件です。ただし、そのような機能を有効にすると、効率や一貫性などの一般的な問題に対処する必要があります。増分更新拡張子[RFC8895]は、単一の要求で複数のクエリの送信をサポートし、クエリを柔軟に制御できるようにします。ただし、単一のリクエストに複数のリソースが必要なこのドキュメントで導入されたケースをカバーしていません。
The extension specified in this document gives an example of using a multipart message to encode the responses from two specific ALTO information resources: a filtered cost map or an Endpoint Cost Service, and a property map. By packing multiple resources in a single response, the implication is that servers may proactively push related information resources to clients.
このドキュメントで指定された拡張機能は、マルチパートメッセージを使用して、2つの特定のALTO情報リソースの応答をエンコードする例を示しています。フィルタリングされたコストマップまたはエンドポイントコストサービスとプロパティマップです。単一の応答で複数のリソースを梱包することにより、サーバーが関連情報リソースをクライアントに積極的にプッシュする可能性があるという意味があります。
Thus, it is worth looking into extending the SSE mechanism as used in the incremental update extension [RFC8895]; or upgrading to HTTP/2 [RFC9113] and HTTP/3 [RFC9114], which provides the ability to multiplex queries and to allow servers to proactively send related information resources.
したがって、インクリメンタル更新拡張[RFC8895]で使用されるSSEメカニズムの拡張を検討する価値があります。または、HTTP/2 [RFC9113]およびHTTP/3 [RFC9114]にアップグレードします。これにより、クエリをマルチプレックスする機能が提供され、サーバーが関連情報リソースを積極的に送信できるようになります。
Defining a general multi-resource query mechanism is out of scope for this document.
一般的なマルチリソースクエリメカニズムの定義は、このドキュメントの範囲外です。
This document is an extension of the base ALTO Protocol, so the security considerations provided for the base ALTO Protocol [RFC7285] fully apply when this extension is provided by an ALTO server.
このドキュメントは、ベースALTOプロトコルの拡張であるため、この拡張機能がALTOサーバーによって提供されている場合、ベースALTOプロトコル[RFC7285]に提供されるセキュリティに関する考慮事項が完全に適用されます。
The Path Vector extension requires additional scrutiny of three security considerations discussed in the base protocol: confidentiality of ALTO information (Section 15.3 of [RFC7285]), potential undesirable guidance from authenticated ALTO information (Section 15.2 of [RFC7285]), and availability of ALTO services (Section 15.5 of [RFC7285]).
パスベクトル拡張では、基本プロトコルで議論された3つのセキュリティに関する考慮事項についての追加の精査が必要です。ALTO情報の機密性（[RFC7285]のセクション15.3）、認証されたALTO情報からの潜在的な望ましくないガイダンス（[RFC7285]のセクション15.2）、およびALTOの入手可能性サービス（[RFC7285]のセクション15.5）。
For confidentiality of ALTO information, a network operator should be aware that this extension may introduce a new risk: the Path Vector information, when used together with sensitive ANE properties such as capacities of bottleneck links, may make network attacks easier. For example, as the Path Vector information may reveal more fine-grained internal network structures than the base protocol, an attacker may identify the bottleneck link or links and start a distributed denial-of-service (DDoS) attack involving minimal flows, triggering in-network congestion. Given the potential risk of leaking sensitive information, the Path Vector extension is mainly applicable in scenarios where 1) the ANE structures and ANE properties do not impose security risks on the ALTO service provider (e.g., they do not carry sensitive information) or 2) the ALTO server and client have established a reliable trust relationship (e.g., they operate in the same administrative domain or are managed by business partners with legal contracts).
ALTO情報の機密性については、ネットワークオペレーターは、この拡張機能が新しいリスクを導入する可能性があることに注意する必要があります。パスベクトル情報は、ボトルネックリンクの容量などの機密性のあるANEプロパティとともに使用する場合、ネットワーク攻撃を容易にする可能性があります。たとえば、パスベクトル情報はベースプロトコルよりも細粒の内部ネットワーク構造を明らかにする可能性があるため、攻撃者はボトルネックリンクまたはリンクを識別し、最小限のフローを含む分散拒否（DDOS）攻撃を開始し、 - ネットワークの混雑。機密情報を漏らす潜在的なリスクを考えると、パスベクトル拡張は主に1）ANE構造とANEプロパティがALTOサービスプロバイダーにセキュリティリスクを課さないシナリオに適用されます（たとえば、それらは機密情報を運びません）または2） ALTOサーバーとクライアントは、信頼できる信頼関係を確立しています（たとえば、同じ管理ドメインで動作するか、法的契約でビジネスパートナーによって管理されています）。
Three risk types are identified in Section 15.3.1 of [RFC7285]:
[RFC7285]のセクション15.3.1で3つのリスクタイプが特定されています。
(1) excess disclosure of the ALTO service provider's data to an unauthorized ALTO client,
(1) ALTOサービスプロバイダーのデータを無許可のALTOクライアントに過剰に開示し、
(2) disclosure of the ALTO service provider's data (e.g., network topology information or endpoint addresses) to an unauthorized third party, and
(2) ALTOサービスプロバイダーのデータ（例：ネットワークトポロジ情報またはエンドポイントアドレス）を不正な第三者に開示すること、および
(3) excess retrieval of the ALTO service provider's data by collaborating ALTO clients.
(3) ALTOクライアントと協力することにより、ALTOサービスプロバイダーのデータの過剰検索。
To mitigate these risks, an ALTO server MUST follow the guidelines in Section 15.3.2 of [RFC7285]. Furthermore, an ALTO server MUST follow the following additional protections strategies for risk types (1) and (3).
これらのリスクを軽減するには、ALTOサーバーは[RFC7285]のセクション15.3.2のガイドラインに従う必要があります。さらに、ALTOサーバーは、リスクタイプ（1）および（3）の以下の追加の保護戦略に従う必要があります。
For risk type (1), an ALTO server MUST use the authentication methods specified in Section 15.3.2 of [RFC7285] to authenticate the identity of an ALTO client and apply access control techniques to restrict the retrieval of sensitive Path Vector information by unprivileged ALTO clients. For settings where the ALTO server and client are not in the same trust domain, the ALTO server should reach agreements with the ALTO client regarding protection of confidentiality before granting access to Path Vector services with sensitive information. Such agreements may include legal contracts or Digital Rights Management (DRM) techniques. Otherwise, the ALTO server MUST NOT offer Path Vector services that carry sensitive information to the clients, unless the potential risks are fully assessed and mitigated.
リスクタイプ（1）の場合、ALTOサーバーは、[RFC7285]のセクション15.3.2で指定された認証方法を使用してALTOクライアントのIDを認証し、アクセス制御手法を適用して、特用されていないALTOによる機密パスベクター情報の検索を制限する必要があります。クライアント。ALTOサーバーとクライアントが同じトラストドメインにない設定の場合、ALTOサーバーは、機密情報を持つPath Vectorサービスへのアクセスを許可する前に、機密性の保護に関してALTOクライアントと合意する必要があります。このような契約には、法的契約またはデジタル権利管理（DRM）技術が含まれる場合があります。それ以外の場合、ALTOサーバーは、潜在的なリスクが完全に評価され、軽減されない限り、クライアントに機密情報を伝達するPATHベクターサービスを提供してはなりません。
For risk type (3), an ALTO service provider must be aware that persistent ANEs may be used as "landmarks" in collaborative inferences. Thus, they should only be used when exposing public service access points (e.g., API gateways, CDN Interconnections) and/ or when the granularity is coarse grained (e.g., when an ANE represents an AS, a data center, or a WAN). Otherwise, an ALTO server MUST use dynamic mappings from ephemeral ANE names to underlying physical entities. Specifically, for the same physical entity, an ALTO server SHOULD assign a different ephemeral ANE name when the entity appears in the responses to different clients or even for different requests from the same client. A RECOMMENDED assignment strategy is to generate ANE names from random numbers.
リスクタイプ（3）の場合、ALTOサービスプロバイダーは、持続的なANEが共同推論の「ランドマーク」として使用される可能性があることに注意する必要があります。したがって、公共サービスのアクセスポイント（APIゲートウェイ、CDN相互接続など）を公開する場合、および/または粒度が粗い粒子の場合（たとえば、ANEがAS、データセンター、またはWANを表す場合）の場合にのみ使用する必要があります。それ以外の場合、ALTOサーバーは、一時的なANE名から基礎となる物理エンティティに動的マッピングを使用する必要があります。具体的には、同じ物理エンティティの場合、ALTOサーバーは、エンティティが異なるクライアントへの応答に表示される場合、または同じクライアントからの異なる要求に対してさえ、異なる一時的なANE名を割り当てる必要があります。推奨される割り当て戦略は、乱数からANE名を生成することです。
Further, to protect the network topology from graph reconstruction (e.g., through isomorphic graph identification [BONDY]), the ALTO server SHOULD consider protection mechanisms to reduce information exposure or obfuscate the real information. When doing so, the ALTO server must be aware that information reduction/obfuscation may lead to a potential risk of undesirable guidance from authenticated ALTO information (Section 15.2 of [RFC7285]).
さらに、ネットワークトポロジーをグラフの再構成から保護するため（例えば、同型グラフ識別[Bondy]）、ALTOサーバーは、情報への露出を減らすか、実際の情報を難読化するための保護メカニズムを考慮する必要があります。その場合、ALTOサーバーは、情報削減/難読化が、認証されたALTO情報からの望ましくないガイダンスの潜在的なリスクにつながる可能性があることに注意する必要があります（[RFC7285]のセクション15.2）。
Thus, implementations of ALTO servers involving reduction or obfuscation of the Path Vector information SHOULD consider reduction/ obfuscation mechanisms that can preserve the integrity of ALTO information -- for example, by using minimal feasible region compression algorithms [NOVA] or obfuscation protocols [RESA] [MERCATOR]. However, these obfuscation methods are experimental, and their practical applicability to the generic capability provided by this extension has not been fully assessed. The ALTO server MUST carefully verify that the deployment scenario satisfies the security assumptions of these methods before applying them to protect Path Vector services with sensitive network information.
したがって、パスベクトル情報の削減または難読化を含むALTOサーバーの実装は、たとえば最小限の領域圧縮アルゴリズム[nova]または難読化プロトコル[Resa]を使用することにより、ALTO情報の整合性を維持できる削減/難読化メカニズムを考慮する必要があります。[メルカトル]。ただし、これらの難読化方法は実験的であり、この拡張機能によって提供される一般的な能力への実際的な適用性は完全には評価されていません。ALTOサーバーは、展開シナリオがこれらのメソッドのセキュリティの仮定を満たしていることを慎重に確認する必要があります。その後、機密のネットワーク情報でパスベクトルサービスを保護するために適用します。
For availability of ALTO services, an ALTO server should be cognizant that using a Path Vector extension might introduce a new risk: frequent requests for Path Vectors might consume intolerable amounts of server-side computation and storage. This behavior can break the ALTO server. For example, if an ALTO server implementation dynamically computes the Path Vectors for each request, the service that provides the Path Vectors may become an entry point for denial-of-service attacks on the availability of an ALTO server.
ALTOサービスの可用性のために、ALTOサーバーは、パスベクトル拡張機能を使用すると新しいリスクが導入される可能性があることを認識する必要があります。パスベクトルの頻繁な要求は、耐え難い量のサーバー側の計算とストレージを消費する可能性があります。この動作は、ALTOサーバーを破ることができます。たとえば、ALTOサーバーの実装が各要求のパスベクトルを動的に計算する場合、パスベクトルを提供するサービスは、ALTOサーバーの可用性に対するサービス拒否攻撃のエントリポイントになる場合があります。
To mitigate this risk, an ALTO server may consider using such optimizations as precomputation-and-projection mechanisms [MERCATOR] to reduce the overhead for processing each query. An ALTO server may also protect itself from malicious clients by monitoring client behavior and stopping service to clients that exhibit suspicious behavior (e.g., sending requests at a high frequency).
このリスクを緩和するために、ALTOサーバーは、各クエリを処理するためのオーバーヘッドを減らすために、事前計算とプロジェクションメカニズム[メルカトル]などの最適化を使用することを検討する場合があります。ALTOサーバーは、クライアントの動作を監視し、疑わしい動作を示すクライアントにサービスを停止することにより、悪意のあるクライアントから身を守ることもできます（たとえば、高頻度でリクエストを送信します）。
The ALTO service providers must be aware that providing incremental updates of "max-reservable-bandwidth" may provide information about other consumers of the network. For example, a change in value may indicate that one or more reservations have been made or changed. To mitigate this risk, an ALTO server can batch the updates and/or add a random delay before publishing the updates.
ALTOサービスプロバイダーは、「Max-Reservable-BandWidth」の増分更新を提供すると、ネットワークの他の消費者に関する情報を提供できることに注意する必要があります。たとえば、価値の変化は、1つ以上の予約が行われたか、変更されたことを示している可能性があります。このリスクを軽減するために、ALTOサーバーは更新をバッチバッチしたり、更新を公開する前にランダムな遅延を追加したりできます。
This document registers a new entry in the "ALTO Cost Metrics" registry, per Section 14.2 of [RFC7285]. The new entry is as shown below in Table 1.
このドキュメントは、[RFC7285]のセクション14.2に従って、「ALTOコストメトリック」レジストリの新しいエントリを登録します。新しいエントリは、以下に表1に示されています。
+============+====================+===========+
| Identifier | Intended Semantics | Reference |
+============+====================+===========+
| ane-path | See Section 6.5.1 | RFC 9275 |
+------------+--------------------+-----------+
Table 1: "ALTO Cost Metrics" Registry
表1：「ALTOコストメトリック」レジストリ
This document registers a new entry in the "ALTO Cost Modes" registry, per Section 5 of [RFC9274]. The new entry is as shown below in Table 2.
このドキュメントは、[RFC9274]のセクション5に従って、「ALTOコストモード」レジストリの新しいエントリを登録します。新しいエントリは、以下に表2に示されています。
+============+=========================+=============+===========+
| Identifier | Description | Intended | Reference |
| | | Semantics | |
+============+=========================+=============+===========+
| array | Indicates that the cost | See Section | RFC 9275 |
| | value is a JSON array | 6.5.2 | |
+------------+-------------------------+-------------+-----------+
Table 2: "ALTO Cost Modes" Registry
表2：「ALTOコストモード」レジストリ
This document registers a new entry in the "ALTO Entity Domain Types" registry, per Section 12.3 of [RFC9240]. The new entry is as shown below in Table 3.
このドキュメントは、[RFC9240]のセクション12.3に従って、「ALTOエンティティドメインタイプ」レジストリの新しいエントリを登録します。新しいエントリは、以下に表3に示されています。
+============+============+=============+===================+=======+
| Identifier |Entity |Hierarchy and| Media Type of |Mapping|
| |Identifier |Inheritance | Defining Resource |to ALTO|
| |Encoding | | |Address|
| | | | |Type |
+============+============+=============+===================+=======+
| ane |See Section |None | application/alto- |false |
| |6.2.2 | | propmap+json | |
+------------+------------+-------------+-------------------+-------+
Table 3: "ALTO Entity Domain Types" Registry
表3：「Alto Entityドメインタイプ」レジストリ
Identifier: See Section 6.2.1.
識別子：セクション6.2.1を参照してください。
Entity Identifier Encoding: See Section 6.2.2.
エンティティ識別子エンコーディング：セクション6.2.2を参照してください。
Hierarchy: None
階層：なし
Inheritance: None
継承：なし
Media Type of Defining Resource: See Section 6.2.4.
メディアタイプの定義リソース：セクション6.2.4を参照してください。
Mapping to ALTO Address Type: This entity type does not map to an ALTO address type.
ALTOアドレスへのマッピングタイプ：このエンティティタイプは、ALTOアドレスタイプにマッピングされません。
Security Considerations: In some usage scenarios, ANE addresses carried in ALTO Protocol messages may reveal information about an ALTO client or an ALTO service provider. If a naming schema is used to generate ANE names, either used privately or standardized by a future extension, how (or if) the naming schema relates to private information and network proximity must be explained to ALTO implementers and service providers.
セキュリティ上の考慮事項：いくつかの使用シナリオでは、ALTOプロトコルメッセージに掲載されたANEアドレスがALTOクライアントまたはALTOサービスプロバイダーに関する情報を明らかにする場合があります。命名スキーマを使用してANE名を生成する場合、個人的に使用されるか、将来の拡張機能によって標準化されている場合、ネーミングスキーマが個人情報とネットワークの近接性にどのように関連するか（または）をALTOの実装者とサービスプロバイダーに説明する必要があります。
Two initial entries -- "max-reservable-bandwidth" and "persistent-entity-id" -- are registered for the ALTO domain "ane" in the "ALTO Entity Property Types" registry, per Section 12.4 of [RFC9240]. The two new entries are shown below in Table 4, and their details can be found in Sections 12.4.1 and 12.4.2 of this document.
[RFC9240]のセクション12.4に従って、「Max-Reservable-BandWidth」と「Persistent-Entity-ID」の2つの初期エントリが、「ALTOエンティティプロパティタイプ」レジストリのALTOドメイン「ANE」に登録されています。2つの新しいエントリを表4に示します。詳細は、このドキュメントのセクション12.4.1および12.4.2に記載されています。
+==========================+====================+===================+
| Identifier | Intended | Media Type of |
| | Semantics | Defining Resource |
+==========================+====================+===================+
| max-reservable-bandwidth | See Section | application/alto- |
| | 6.4.1 | propmap+json |
+--------------------------+--------------------+-------------------+
| persistent-entity-id | See Section | application/alto- |
| | 6.4.2 | propmap+json |
+--------------------------+--------------------+-------------------+
Table 4: Initial Entries for the "ane" Domain in the "ALTO Entity Property Types" Registry
表4：「ALTOエンティティプロパティタイプ」レジストリの「ANE」ドメインの初期エントリ
Identifier: "max-reservable-bandwidth"
識別子：「Max-Reservable-BandWidth」
Intended Semantics: See Section 6.4.1.
意図されたセマンティクス：セクション6.4.1を参照してください。
Media Type of Defining Resource: application/alto-propmap+json
Security Considerations: To make better choices regarding bandwidth reservation, this property is essential for applications such as large-scale data transfers or an overlay network interconnection. It may reveal the bandwidth usage of the underlying network and can potentially be leveraged to reduce the cost of conducting denial-of-service attacks. Thus, the ALTO server MUST consider such protection mechanisms as providing the information to authorized clients only and applying information reduction and obfuscation as discussed in Section 11.
セキュリティ上の考慮事項：帯域幅の予約に関してより良い選択をするために、このプロパティは、大規模なデータ転送やオーバーレイネットワークの相互接続などのアプリケーションに不可欠です。基礎となるネットワークの帯域幅の使用が明らかになる可能性があり、サービス拒否攻撃を実施するコストを削減するために活用される可能性があります。したがって、ALTOサーバーは、そのような保護メカニズムを、認定クライアントのみに情報を提供し、セクション11で説明したように情報削減と難読化を適用するなどしなければなりません。
Identifier: "persistent-entity-id"
識別子：「永続的エンティティID」
Intended Semantics: See Section 6.4.2.
意図されたセマンティクス：セクション6.4.2を参照してください。
Media Type of Defining Resource: application/alto-propmap+json
Security Considerations: This property is useful when an ALTO server wants to selectively expose certain service points whose detailed properties can be further queried by applications. As mentioned in Section 12.3.2 of [RFC9240], the entity IDs may reveal sensitive information about the underlying network. An ALTO server should follow the security considerations provided in Section 11 of [RFC9240].
セキュリティ上の考慮事項：このプロパティは、ALTOサーバーが、詳細なプロパティをアプリケーションによってさらに照会できる特定のサービスポイントを選択的に公開したい場合に役立ちます。[RFC9240]のセクション12.3.2で述べたように、エンティティIDは、基礎となるネットワークに関する機密情報を明らかにする場合があります。ALTOサーバーは、[RFC9240]のセクション11で提供されるセキュリティに関する考慮事項に従う必要があります。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。and N. Borenstein、「多目的インターネットメールエクステンション（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487/RFC2046、1996年11月、<https://www.rfc-editor.orgg/info/rfc2046>。
[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。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, DOI 10.17487/RFC2387, August 1998, <https://www.rfc-editor.org/info/rfc2387>.
[RFC2387] Levinson、E。、「The Mime MultiPart/関連コンテンツタイプ」、RFC 2387、DOI 10.17487/RFC2387、1998年8月、<https://www.rfc-editor.org/info/rfc2387>
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487/RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5321。
[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.、Roome、W。、およびN. Schwan、「マルチコストアプリケーション層トラフィック最適化（ALTO）」、RFC 8189、DOI 10.17487/RFC8189、2017年10月、<https：// www。rfc-editor.org/info/rfc8189>。
[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。and Y. Yang、「アプリケーションレイヤートラフィック最適化（ALTO）サーバーセントイベント（SSE）を使用した増分更新」、RFC 8895、DOI 10.17487/RFC8895、2020年11月、<https：// wwwwwwwwwwwwww.rfc-editor.org/info/rfc8895>。
[RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N. Schwan, "Application-Layer Traffic Optimization (ALTO) Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November 2020, <https://www.rfc-editor.org/info/rfc8896>.
[RFC8896] Randriamasy、S.、Yang、R.、Wu、Q.、Deng、L。、およびN. Schwan、「アプリケーションレイヤートラフィック最適化（ALTO）コストカレンダー」、RFC 8896、DOI 10.17487/RFC8896、11月2020、<https://www.rfc-editor.org/info/rfc8896>。
[RFC9240] Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K. Gao, "An Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps", RFC 9240, DOI 10.17487/RFC9240, July 2022, <https://www.rfc-editor.org/info/rfc9240>.
[RFC9240] Roome、W.、Randriamasy、S.、Yang、Y.、Zhang、J。、およびK. Gao、「アプリケーションレイヤートラフィック最適化の拡張（ALTO）：エンティティプロパティマップ」、RFC 9240、doi10.17487/rfc9240、2022年7月、<https://www.rfc-editor.org/info/rfc9240>。
[RFC9274] Boucadair, M. and Q. Wu, "A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol", RFC 9274, DOI 10.17487/RFC9274, July 2022, <https://www.rfc-editor.org/info/rfc9274>.
[RFC9274] Boucadair、M。およびQ. Wu、「アプリケーション層トラフィック最適化（ALTO）プロトコルのコストモードレジストリ」、RFC 9274、DOI 10.17487/RFC9274、2022年7月、<https：//www.rfc-editor.org/info/rfc9274>。
[ALTO-PERF-METRICS] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and L. Contreras, "ALTO Performance Cost Metrics", Work in Progress, Internet-Draft, draft-ietf-alto-performance-metrics-28, 21 March 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-28>.
[Alto-Perf-Metrics] Wu、Q.、Yang、Y.、Lee、Y.、Dhody、D.、Randriamasy、S。、およびL. Contreras、「Alto Performance Cost Metrics」、進行中の作業、インターネット - ドラフト、ドラフト-ITET-ALTO-ALTO-PERFORMANCE-METRICS-28、2022年3月21日、<https://datatracker.ietf.org/doc/html/draft-ietf-alto-performance-metrics-28>。
[BONDY] Bondy, J.A. and R.L. Hemminger, "Graph reconstruction--a survey", Journal of Graph Theory, Volume 1, Issue 3, pp. 227-268, DOI 10.1002/jgt.3190010306, 1977, <https://onlinelibrary.wiley.com/doi/10.1002/ jgt.3190010306>.
[ボンディ]ボンディ、J.A。およびR.L. Hemminger、「Graph Reconstruction-a Survey」、Graph TheoryのJournal of Graph Theory、Volume 1、Issue 3、pp。227-268、doi 10.1002/jgt.3190010306、1977、<https://onlinelibrary.wiley.com/.com/.doi/ 10.1002/ jgt.3190010306>。
[BOXOPT] Xiang, Q., Yu, H., Aspnes, J., Le, F., Kong, L., and Y.R. Yang, "Optimizing in the Dark: Learning an Optimal Solution through a Simple Request Interface", Proceedings of the AAAI Conference on Artificial Intelligence 33, 1674-1681, DOI 10.1609/aaai.v33i01.33011674, July 2019, <https://ojs.aaai.org//index.php/AAAI/article/view/3984>.
[Boxopt] Xiang、Q.、Yu、H.、Aspnes、J.、Le、F.、Kong、L。、およびY.R.Yang、「暗闇の中で最適化：単純な要求インターフェイスを介して最適なソリューションを学ぶ」、人工知能に関するAAAI会議33、1674-1681、DOI 10.1609/aaai.v33i01.33011674、2019年7月、<https：//ojs.aaai.org//index.php/aaai/article/view/3984>。
[CLARINET] Viswanathan, R., Ananthanarayanan, G., and A. Akella, "CLARINET: WAN-aware optimization for analytics queries", Proceedings of the 12th USENIX conference on Operating Systems Design and Implementation (OSDI'16), Savannah, GA, pp. 435-450, November 2016, <https://dl.acm.org/doi/abs/10.5555/3026877.3026911>.
[Clarinet] Viswanathan、R.、Ananthanarayanan、G。、およびA. Akella、「クラリネット：分析クエリのためのWan-Aware最適化」、第12回オペレーティングシステムの設計と実装（OSDI'16）、Savannah、GA、pp。435-450、2016年11月、<https://dl.acm.org/doi/abs/10.5555/3026877.3026911>。
[G2] Ros-Giralt, J., Bohara, A., Yellamraju, S., Langston, M.H., Lethin, R., Jiang, Y., Tassiulas, L., Li, J., Tan, Y., and M. Veeraraghavan, "On the Bottleneck Structure of Congestion-Controlled Networks", Proceedings of the ACM on Measurement and Analysis of Computing Systems, Volume 3, Issue 3, pp. 1-31, DOI 10.1145/3366707, December 2019, <https://dl.acm.org/doi/10.1145/3366707>.
[G2] Ros-Giralt、J.、Bohara、A.、Yellamraju、S.、Langston、M.H.、Lethin、R.、Jiang、Y.、Tassiulas、L.、Li、J.、Tan、Y。M. Veeraraghavan、「混雑制御ネットワークのボトルネック構造について」、コンピューティングシステムの測定と分析に関するACMの議事録、第3巻、第3号、1-31ページ、DOI 10.1145/3366707、2019年12月、<https：//dl.acm.org/doi/10.1145/3366707>。
[HUG] Chowdhury, M., Liu, Z., Ghodsi, A., and I. Stoica, "HUG: multi-resource fairness for correlated and elastic demands", Proceedings of the 13th USENIX Conference on Networked Systems Design and Implementation (NSDI'16), Santa Clara, CA, pp. 407-424, March 2016, <https://dl.acm.org/doi/10.5555/2930611.2930638>.
[hug] Chowdhury、M.、Liu、Z.、Ghodsi、A。、およびI. Stoica、「Hug：Multi-Resource Fiarness for Corlerated and Elastic Remands」、Networked Systemsの設計と実装に関する第13回USENIX会議の議事録（NSDI'16）、カリフォルニア州サンタクララ、pp。407-424、2016年3月、<https://dl.acm.org/doi/10.5555/2930611.2930638>。
[INTENT-BASED-NETWORKING] Clemm, A., Ciavaglia, L., Granville, L. Z., and J. Tantsura, "Intent-Based Networking - Concepts and Definitions", Work in Progress, Internet-Draft, draft-irtf-nmrg-ibn-concepts-definitions-09, 24 March 2022, <https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibn-concepts-definitions-09>.
[Intent Based-Networking] Clemm、A.、Ciavaglia、L.、Granville、L。Z.、およびJ. Tantsura、「Intent Based Networking-概念と定義」、Work in Progress、Internet-Draft、Draft-Artf-Nmrg-IBNCONCEPTS-DEFINITIONS-09、2022年3月24日、<https://datatracker.ietf.org/doc/html/draft-irtf-nmrg-ibnconcepts-definitions-09>。
[JSONiq] JSONiq, "The JSON Query Language", 2022, <https://www.jsoniq.org/>.
[jsoniq] jsoniq、「json Query Language」、2022、<https://www.jsoniq.org/>。
[MERCATOR] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F., MacAuley, J., Newman, H., and Y.R. Yang, "Toward Fine-Grained, Privacy-Preserving, Efficient Multi-Domain Network Resource Discovery", IEEE/ACM, IEEE Journal on Selected Areas in Communications, Volume 37, Issue 8, pp. 1924-1940, DOI 10.1109/JSAC.2019.2927073, August 2019, <https://ieeexplore.ieee.org/document/8756056>.
[メルカトル] Xiang、Q.、Zhang、J.、Wang、X.、Liu、Y.、Guok、C.、Le、F.、Macauley、J.、Newman、H。、およびY.R.Yang、「微調整された、プライバシーを提供する、効率的なマルチドメインネットワークリソース発見に向けて」、IEEE/ACM、Communicationsの選択された領域に関するIEEEジャーナル、第37巻、第8号、1924-1940ページ、DOI 10.1109/JSAC。2019.2927073、2019年8月、<https://ieeexplore.ieee.org/document/8756056>。
[MOWIE] Zhang, Y., Li, G., Xiong, C., Lei, Y., Huang, W., Han, Y., Walid, A., Yang, Y.R., and Z. Zhang, "MoWIE: Toward Systematic, Adaptive Network Information Exposure as an Enabling Technique for Cloud-Based Applications over 5G and Beyond", Proceedings of the Workshop on Network Application Integration/CoDesign (NAI '20), ACM, Virtual Event USA, pp. 20-27, DOI 10.1145/3405672.3409489, August 2020, <https://dl.acm.org/doi/10.1145/3405672.3409489>.
[Mowie] Zhang、Y.、Li、G.、Xiong、C.、Lei、Y.、Huang、W.、Han、Y.、Walid、A.、Yang、Y.R。、およびZ. Zhang、Mowie：5G以上のクラウドベースのアプリケーションの有効化手法としての体系的で適応的なネットワーク情報露出に向けて」、ネットワークアプリケーション統合/コード設計に関するワークショップの議事録（NAI '20）、ACM、仮想イベントUSA、pp。20-27、pp。20-27、doi 10.1145/3405672.3409489、2020年8月、<https://dl.acm.org/doi/10.1145/3405672.3409489>。
[NOVA] Gao, K., Xiang, Q., Wang, X., Yang, Y.R., and J. Bi, "An Objective-Driven On-Demand Network Abstraction for Adaptive Applications", IEEE/ACM Transactions on Networking (TON) Vol. 27, Issue 2, pp. 805-818, DOI 10.1109/TNET.2019.2899905, April 2019, <https://doi.org/10.1109/TNET.2019.2899905>.
[Nova] Gao、K.、Xiang、Q.、Wang、X.、Yang、Y.R。、およびJ. Bi、「適応アプリケーション向けの客観的なオンデマンドネットワーク抽象化」、ネットワーキング上のIEEE/ACMトランザクション（Ton））Vol。27、第2号、805-818、DOI 10.1109/TNET.2019.289905、2019年4月、<https://doi.org/10.1109/TNET.2019.2899905>。
[RESA] Xiang, Q., Zhang, J., Wang, X., Liu, Y., Guok, C., Le, F., MacAuley, J., Newman, H., and Y.R. Yang, "Fine-Grained, Multi-Domain Network Resource Abstraction as a Fundamental Primitive to Enable High-Performance, Collaborative Data Sciences", SC18: International Conference for High Performance Computing, Networking, Storage and Analysis, pp. 58-70, DOI 10.1109/SC.2018.00008, November 2018, <https://ieeexplore.ieee.org/document/8665783>.
[Resa] Xiang、Q.、Zhang、J.、Wang、X.、Liu、Y.、Guok、C.、Le、F.、Macauley、J.、Newman、H。、およびY.R.Yang、「高性能、共同データ科学を可能にするための基本的な原始としての微細なマルチドメインネットワークリソースの抽象化」、SC18：高性能コンピューティング、ネットワーキング、ストレージ、分析のための国際会議、58-70ページ、doi10.1109/sc.2018.00008、2018年11月、<https://ieeexplore.ieee.org/document/8665783>。
[RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service Specification Template", RFC 2216, DOI 10.17487/RFC2216, September 1997, <https://www.rfc-editor.org/info/rfc2216>.
[RFC2216] Shenker、S。およびJ. Wroclawski、「ネットワーク要素サービス仕様テンプレート」、RFC 2216、DOI 10.17487/RFC2216、1997年9月、<https://www.rfc-editor.org/info/rfc2216>
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y.、ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487/RFC4271、2006年1月、<https://www.rfc-editor.org/info/rfc4271>。
[RFC9113] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113, DOI 10.17487/RFC9113, June 2022, <https://www.rfc-editor.org/info/rfc9113>.
[RFC9113] Thomson、M.、ed。and C. Benfield、ed。、「HTTP/2」、RFC 9113、DOI 10.17487/RFC9113、2022年6月、<https://www.rfc-editor.org/info/rfc9113>。
[RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/info/rfc9114>.
[RFC9114] Bishop、M.、ed。、 "HTTP/3"、RFC 9114、DOI 10.17487/RFC9114、2022年6月、<https://www.rfc-editor.org/info/rfc9114>。
[SENSE] ESnet, "Software Defined Networking (SDN) for End-to-End Networked Science at the Exascale", 2019, <https://www.es.net/network-r-and-d/sense/>.
[SENSE] ESNET、「Exascaleでのエンドツーエンドネットワーク科学のソフトウェア定義ネットワーキング（SDN）」、2019、<https://www.es.net/network-r-and-d/sense/>。
[SEREDGE] Contreras, L., Baliosian, J., Martínez-Julia, P., and J. Serrat, "Computing at the Edge: But, what Edge?", Proceedings of NOMS 2020 - 2020 IEEE/IFIP Network Operations and Management Symposium, pp. 1-9, DOI 10.1109/NOMS47738.2020.9110342, April 2020, <https://ieeexplore.ieee.org/document/9110342>.
[Seredge] Contreras、L.、Baliosian、J.、Martínez -Julia、P。、およびJ. Serrat、「エッジでのコンピューティング：しかし、どのエッジ？」管理シンポジウム、1-9ページ、DOI 10.1109/noms47738.2020.9110342、2020年4月、<https://ieeexplore.ieee.org/document/9110342>。
[SWAN] Hong, C., Kandula, S., Mahajan, R., Zhang, M., Gill, V., Nanduri, M., and R. Wattenhofer, "Achieving high utilization with software-driven WAN", Proceedings of the ACM SIGCOMM 2013 conference on SIGCOMM (SIGCOMM '13), New York, NY, pp. 15-26, DOI 10.1145/2486001.2486012, August 2013, <https://dl.acm.org/doi/10.1145/2486001.2486012>.
[スワン] Hong、C.、Kandula、S.、Mahajan、R.、Zhang、M.、Gill、V.、Nanduri、M.、およびR. Wattenhofer、「ソフトウェア駆動型WANで高い活用を達成する」、議事録ACM Sigcomm 2013 Conference on Sigcomm（Sigcomm '13）、ニューヨーク、ニューヨーク、pp。15-26、DOI 10.1145/2486001.2486012、2013年8月、<https://dl.acm.org/doi/10.1145/2486001.2486012>。
[UNICORN] Xiang, Q., Wang, T., Zhang, J., Newman, H., Yang, Y.R., and Y. Liu, "Unicorn: Unified resource orchestration for multi-domain, geo-distributed data analytics", Future Generation Computer Systems, Volume 93, pp. 188-197, DOI 10.1016/j.future.2018.09.048, April 2019, <https://www.sciencedirect.com/science/article/abs/pii/ S0167739X18302413?via%3Dihub>.
[Unicorn] Xiang、Q.、Wang、T.、Zhang、J.、Newman、H.、Yang、Y.R。、およびY. Liu、「Unicorn：Multi-domainの統一された資源オーケストレーション、地理分布データ分析」、Future Generation Computer Systems、Volume 93、pp。188-197、doi 10.1016/j.future.2018.09.048、2019年4月、<https://www.sciendirect.com/science/abs/pii/ s0167739x18302413？％3dihub>。
[XQuery] Robie, J., Ed., Dyck, M., Ed., and J. Spiegel, Ed., "XQuery 3.1: An XML Query Language", W3C Recommendation, March 2017, <https://www.w3.org/TR/xquery-31/>.
[XQuery] Robie、J.、Ed。、Dyck、M.、ed。、およびJ. Spiegel、ed。、「Xquery 3.1：an XML Query Language」、W3C推奨、2017年3月、<https：// www。w3.org/tr/xquery-31/>。
Acknowledgments
謝辞
The authors would like to thank Andreas Voellmy, Erran Li, Haibin Song, Haizhou Du, Jiayuan Hu, Tianyuan Liu, Xiao Shi, Xin Wang, and Yan Luo for fruitful discussions. The authors thank Greg Bernstein, Dawn Chen, Wendy Roome, and Michael Scharf for their contributions to earlier draft versions of this document.
著者は、Andreas Voellmy、Erran Li、Haibin Song、Haizhou Du、Jiayuan Hu、Tianyuan Liu、Xiao Shi、Xin Wang、およびYan Luoに実り多い議論に感謝したいと思います。著者は、グレッグ・バーンスタイン、ドーン・チェン、ウェンディ・ルーム、マイケル・シャーフに、この文書の以前のドラフトバージョンへの貢献について感謝します。
The authors would also like to thank Tim Chown, Luis Contreras, Roman Danyliw, Benjamin Kaduk, Erik Kline, Suresh Krishnan, Murray Kucherawy, Warren Kumari, Danny Lachos, Francesca Palombini, Éric Vyncke, Samuel Weiler, and Qiao Xiang, whose feedback and suggestions were invaluable for improving the practicability and conciseness of this document; and Mohamed Boucadair, Martin Duke, Vijay Gurbani, Jan Seedorf, and Qin Wu, who provided great support and guidance.
著者はまた、ティム・チャウン、ルイス・コントレラス、ローマン・ダニリウ、ベンジャミン・カドゥク、エリック・クライン、スレシュ・クリシュナン、マレー・クチェラウィー、ウォーレン・クマリ、ダニー・ラチョス、フランチェスカ・パロンビニ、エリック・ヴィンチケ、サミュエル・ウェイラー、キアオ・キオ・キオ・キオ・キオ・キオ・キアンは提案は、この文書の実用性と簡潔さを改善するために非常に貴重でした。そして、Mohamed Boucadair、Martin Duke、Vijay Gurbani、Jan Seedorf、およびQin Wuは、素晴らしいサポートとガイダンスを提供しました。
Authors' Addresses
著者のアドレス
Kai Gao Sichuan University No.24 South Section 1, Yihuan Road Chengdu 610000 China Email: kaigao@scu.edu.cn
Kai Gao Sichuan University No.24 South Section 1、Yihuan Road Chengdu 610000 China Email：kaigao@scu.edu.cn
Young Lee Samsung Republic of Korea Email: younglee.tx@gmail.com
Young Lee Samsung共和国メールメール：Younglee.tx@gmail.com
Sabine Randriamasy Nokia Bell Labs Route de Villejust 91460 Nozay France Email: sabine.randriamasy@nokia-bell-labs.com
sabine randriamasy nokia bell labs route de villejust 91460 nozay franceメール：sabine.randriamasy@nokia-bell-labs.com
Yang Richard Yang Yale University 51 Prospect Street New Haven, CT 06511 United States of America Email: yry@cs.yale.edu
ヤン・リチャード・ヤン・イェール大学51プロスペクト・ストリートニューヘブン、CT 06511アメリカ合衆国電子メール：yry@cs.yale.edu
Jingxuan Jensen Zhang Tongji University 4800 Caoan Road Shanghai 201804 China Email: jingxuan.n.zhang@gmail.com
Jingxuan Jensen Zhang Tongji University 4800 Caoan Road Shanghai 201804 China Email：jingxuan.n.zhang@gmail.com