[要約] RFC 9217 - Current Open Questions in Path-Aware Networkingは、2021年時点で未解決のパス認識ネットワーキングに関する質問を提示し、パス認識インターネットワークの設計、開発、展開に必要な情報を提供することを目的としています。
Internet Research Task Force (IRTF) B. Trammell
Request for Comments: 9217 Google Switzerland GmbH
Category: Informational March 2022
ISSN: 2070-1721
Current Open Questions in Path-Aware Networking
パスアウェアネットワーキングで現在の問題を開く
Abstract
概要
In contrast to the present Internet architecture, a path-aware internetworking architecture has two important properties: it exposes the properties of available Internet paths to endpoints, and it provides for endpoints and applications to use these properties to select paths through the Internet for their traffic. While this property of "path awareness" already exists in many Internet-connected networks within single domains and via administrative interfaces to the network layer, a fully path-aware internetwork expands these concepts across layers and across the Internet.
現在のインターネットアーキテクチャとは対照的に、パス対応のインターネットワーキングアーキテクチャには2つの重要なプロパティがあります。エンドポイントに利用可能なインターネットパスのプロパティを公開し、エンドポイントとアプリケーションを使用してこれらのプロパティを使用してトラフィックのインターネットを介したパスを選択することができます。。この「パス認識」のこのプロパティは、単一のドメイン内の多くのインターネット接続ネットワークに既に存在し、ネットワーク層への管理インターネットのインターネットワークを介して、インターネットワークがこれらの概念を展開し、インターネット全体で拡大します。
This document poses questions in path-aware networking, open as of 2021, that must be answered in the design, development, and deployment of path-aware internetworks. It was originally written to frame discussions in the Path Aware Networking Research Group (PANRG), and has been published to snapshot current thinking in this space.
この文書は、PATH対応のインターネットワークの設計、開発、および展開で回答する必要があります。それはもともとPath Aware Networking Research Group（Panrg）のフレームディスカッションに書かれ、このスペースでスナップショットの現在の考え方に公開されました。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。それは情報提供のために公開されています。
This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Path Aware Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
この文書は、インターネットリサーチタスクフォース（IRTF）の製品です。IRTFはインターネット関連の研究開発活動の結果を発行しています。これらの結果は展開には適していない可能性があります。このRFCは、インターネットリサーチタスクフォース（IRTF）のPath Aware Networking Researchグループのコンセンサスを表しています。IRSGによる出版承認された文書は、インターネット規格のレベルレベルの候補者ではありません。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/rfc9217.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9217で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF信頼と文書の著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。
Table of Contents
目次
1. Introduction to Path-Aware Networking
1.1. Definitions
2. Questions
2.1. A Vocabulary of Path Properties
2.2. Discovery, Distribution, and Trustworthiness of Path
Properties
2.3. Supporting Path Selection
2.4. Interfaces for Path Awareness
2.5. Implications of Path Awareness for the Transport and
Application Layers
2.6. What is an Endpoint?
2.7. Operating a Path-Aware Network
2.8. Deploying a Path-Aware Network
3. IANA Considerations
4. Security and Privacy Considerations
5. Informative References
Acknowledgments
Author's Address
In the current Internet architecture, the network layer provides a best-effort service to the endpoints using it, without verifiability of the properties of the path between the endpoints. While there are network-layer technologies that attempt better-than-best-effort delivery, the interfaces to these are generally administrative as opposed to endpoint exposed (e.g., Path Computation Element (PCE) [RFC4655] and Software-Defined Wide Area Network (SD-WAN) [MEF70] approaches), and they are often restricted to single administrative domains. In this architecture, an application can assume that a packet with a given destination address will eventually be forwarded toward that destination, but little else.
現在のインターネットアーキテクチャでは、ネットワーク層は、エンドポイント間のパスのプロパティを検証することなく、それを使用してエンドポイントに最適なサービスを提供します。最善よりも優れた配達を試みるネットワーク層技術があるが、これらへのインターフェースは一般にエンドポイントにさらされているとは対照的に管理者（例えば、PATH計算要素（PCE）[RFC4655]およびソフトウェア定義されたワイドエリアネットワーク（SD-WAN）[MEF70]アプローチ）、そしてそれらはしばしば単一の管理ドメインに制限されます。このアーキテクチャでは、アプリケーションは、与えられた宛先アドレスを持つパケットが最終的にその目的地に向かって転送されると仮定することができますが、他にはほとんどありません。
A transport-layer protocol such as TCP can provide reliability over this best-effort service, and a protocol above the network layer, such as Transport Layer Security (TLS) [RFC8446], can authenticate the remote endpoint. However, little, if any, explicit information about the path is available to the endpoints, and any assumptions made about that path often do not hold. These sometimes have serious impacts on the application, as in the case with BGP hijacking attacks.
TCPなどのトランスポート層プロトコルは、このベストエフォートサービスに対する信頼性を提供することができ、トランスポート層のセキュリティ（TLS）[RFC8446]などのネットワーク層の上のプロトコルで、リモートエンドポイントを認証できます。ただし、パスに関する明示的な情報がエンドポイントで利用可能である場合はほとんど、あれば、そのパスについて行われた仮定はしばしば保持されません。BGPハイジャック攻撃と同様に、これらは時々アプリケーションに深刻な影響を与えることがあります。
By contrast, in a path-aware internetworking architecture, endpoints can select or influence the path(s) through the network used by any given packet or flow. The network and transport layers explicitly expose information about the path or paths available to the endpoints and to the applications running on them, so that they can make this selection. The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] can be seen as an example of a path-awareness approach implemented in transport-layer terms on the present Internet protocol stack.
対照的に、経路認識インターネットワーキングアーキテクチャでは、エンドポイントは、特定のパケットまたはフローによって使用されるネットワークを介して経路を選択または影響することができる。ネットワーク層とトランスポート層は、エンドポイントとそれらの上で実行されているアプリケーションとのパスまたはパスに関する情報を明示的に公開して、この選択を行うことができます。アプリケーションレイヤトラフィック最適化（ALTO）プロトコル[RFC7285]は、現在のインターネットプロトコルスタック上のトランスポート層用語で実装された経路認識アプローチの一例として見ることができる。
Path selection provides explicit visibility and control of network treatment to applications and users of the network. This selection is available to the application-, transport-, and/or network-layer entities at each endpoint. Path control at the flow and subflow level enables the design of new transport protocols that can leverage multipath connectivity across disjoint paths through the Internet, even over a single physical interface. When exposed to applications, or to end users through a system configuration interface, path control allows the specification of constraints on the paths that traffic should traverse, for instance to confound passive surveillance in the network core [RFC7624].
パス選択は、ネットワークのアプリケーションとユーザーへのネットワーク扱いの明示的な可視性と制御を提供します。この選択は、各エンドポイントのアプリケーション、トランスポート、および/またはネットワーク層エンティティに使用できます。フローとサブフローレベルでのパス制御は、単一の物理インターフェイスを介しても、インターネットを介して、インターネットを介してマルチパス接続を活用できる新しいトランスポートプロトコルの設計を可能にします。アプリケーションにさらされると、システム構成インターフェイスを介してユーザーをエンドユーザーにエンドユーザーに表示すると、トラフィックがトラバースするパスに対する制約の仕様を、ネットワークコア[RFC7624]でパッシブサーベイランスを交絡させることができます。
We note that this property of "path awareness" already exists in many Internet-connected networks within single domains. Indeed, much of the practice of network engineering using encapsulation at layer 3 can be said to be "path aware" in that it explicitly assigns traffic at tunnel endpoints to a given path within the network. Path-aware internetworking seeks to extend this awareness across domain boundaries without resorting to overlays, except as a transition technology.
私たちは、「パス認識」のこの財産は、単一のドメイン内の多くのインターネット接続ネットワークにすでに存在していることに注意してください。実際、レイヤ3でカプセル化を使用したネットワークエンジニアリングの実践の多くは、トンネルエンドポイントでトラフィックをネットワーク内の特定のパスに明示的に割り当てるという点で、「PATH AWARE」と言える。経路認識インターネットワーキングは、移行技術としてのオーバーレイに頼ることなくドメイン境界を越えてこの認識を拡張しようとしています。
This document presents a snapshot of open questions in this space that will need to be answered in order to realize a path-aware internetworking architecture; it is published to further frame discussions within and outside the Path Aware Networking Research Group, and is published with the rough consensus of that group.
この文書では、パス対応のインターネットワーキングアーキテクチャを実現するために回答する必要があるこのスペースで開かれた質問のスナップショットを表示します。Path Aware Networking Research Groupの内外での議論のさらなるフレームディスカッションに公開され、そのグループの大まかなコンセンサスが公開されています。
For purposes of this document, "path-aware networking" describes endpoint discovery of the properties of paths they use for communication across an internetwork, and endpoint reaction to these properties that affects routing and/or data transfer. Note that this can and already does happen to some extent in the current Internet architecture; this definition expands current techniques of path discovery and manipulation to cross administrative domain boundaries and up to the transport and application layers at the endpoints.
このドキュメントの目的のために、「パスアウェアネットワーク」は、インターネットワーク全体で通信に使用するパスのプロパティのエンドポイント検出、およびルーティングやデータ転送に影響を与えるこれらのプロパティへのエンドポイント反応について説明しています。これは現在のインターネットアーキテクチャのある程度ある程度起こることができることに注意してください。この定義は、管理ドメインの境界とエンドポイントのトランスポート層とアプリケーションレイヤを渡すためのパス検出と操作の現在のテクニックを拡張します。
Expanding on this definition, a "path-aware internetwork" is one in which endpoint discovery of path properties and endpoint selection of paths used by traffic exchanged by the endpoint are explicitly supported regardless of the specific design of the protocol features that enable this discovery and selection.
この定義では、「パスアウェアインターネットワーク」の拡大は、この発見を可能にするプロトコル機能の特定の設計に関係なく、エンドポイントによって交換されるトラフィックによって使用されるパスのエンドポイントの検出とエンドポイントの選択のエンドポイント検出が明示的にサポートされています。選択。
A "path", for the purposes of these definitions, is abstractly defined as a sequence of adjacent path elements over which a packet can be transmitted, where the definition of "path element" is technology dependent. As this document is intended to pose questions rather than answer them, it assumes that this definition will be refined as part of the answer to the first two questions it poses about the vocabulary of path properties and how they are disseminated.
これらの定義の目的のための「経路」は、「path要素」の定義が技術に依存するパケットを送信することができる隣接する経路要素のシーケンスとして抽象的に定義される。この文書は彼らに答えるのではなく質問をすることを目的としているので、この定義は、パスプロパティの語彙とそれらがどのように普及しているかについて、最初の2つの質問に対する答えの一部として洗練されることを前提としています。
Research into path-aware internetworking covers any and all aspects of designing, building, and operating path-aware internetworks or the networks and endpoints attached to them. This document presents a collection of research questions to address in order to make a path-aware Internet a reality.
経路と認識されたインターネットワーキングへの研究は、設計、構築、および操作経路認識のあるインターネットワークまたはそれらに添付されたネットワークおよびエンドポイントのあらゆる面をカバーする。この文書は、経路を意識したインターネットを現実にするために対処するための調査質問の集まりを提示します。
Realizing path-aware networking requires answers to a set of open research questions. This document poses these questions as a starting point for discussions about how to realize path awareness in the Internet and to direct future research efforts within the Path Aware Networking Research Group.
経路対応ネットワーキングを実現するには、一連のオープンリサーチ質問に対する回答が必要です。この文書は、インターネットにおける経路の認識を実現し、経路を意識したネットワーキング研究グループ内での将来の研究努力を指示する方法についての議論の出発点としてこれらの質問を投入します。
The first question: how are paths and path properties defined and represented?
最初の質問：パスとパスのプロパティはどのように定義され、表現されますか？
In order for information about paths to be exposed to an endpoint, and for the endpoint to make use of that information, it is necessary to define a common vocabulary for paths through an internetwork and properties of those paths. The elements of this vocabulary could include terminology for components of a path and properties defined for these components, for the entire path or for subpaths of a path. These properties may be relatively static, such as the presence of a given node or service function on the path, as well as relatively dynamic, such as the current values of metrics such as loss and latency.
パスについての情報をエンドポイントに公開し、エンドポイントがその情報を利用するためには、インターネットワークとそれらのパスのプロパティを介してパスの一般的な語彙を定義する必要があります。この語彙の要素には、パス全体またはパスのサブパスに対して、これらのコンポーネントに定義されたパスとプロパティのコンポーネントのための用語が含まれます。これらのプロパティは、経路上の所与のノードまたはサービス関数の存在、ならびに損失および待ち時間などのメトリックの現在の値のような比較的動的などの比較的静的であり得る。
This vocabulary and its representation must be defined carefully, as its design will have impacts on the properties (e.g., expressiveness, scalability, and security) of a given path-aware internetworking architecture. For example, a system that exposes node-level information for the topology through each network would maximize information about the individual components of the path at the endpoints, at the expense of making internal network topology universally public, which may be in conflict with the business goals of each network's operator. Furthermore, properties related to individual components of the path may change frequently and may quickly become outdated. However, aggregating the properties of individual components to distill end-to-end properties for the entire path is not trivial.
この語彙とその表現は、その設計が、特定のパス対応のインターネットワーキングアーキテクチャのプロパティ（例えば、表現力、スケーラビリティ、およびセキュリティ）に影響を与えるため、慎重に定義する必要があります。たとえば、各ネットワークを通じてトポロジのノードレベルの情報を公開するシステムは、内部的に公開されている内部的に公開されている、エンドポイントのパスの個々のコンポーネントに関する情報を最大化します。各ネットワークのオペレータの目標。さらに、経路の個々の構成要素に関連する特性が頻繁に変化し、そして迅速に古くなる可能性がある。しかしながら、経路全体のためのエンドツーエンド特性を蒸留するために個々の構成要素の特性を集約することは簡単ではない。
The second question: how do endpoints and applications get access to accurate, useful, and trustworthy path properties?
2番目の質問：エンドポイントとアプリケーションは、正確、便利な、および信頼できるパスプロパティへのアクセスをどのように受け取るのですか？
Once endpoints and networks have a shared vocabulary for expressing path properties, the network must have some method for distributing those path properties to the endpoints. Regardless of how path property information is distributed, the endpoints require a method to authenticate the properties in order to determine that they originated from and pertain to the path that they purport to.
エンドポイントとネットワークにパスプロパティを表現するための共有語彙があると、ネットワークにはそれらのパスプロパティをエンドポイントに配布する方法がいくつかあります。パスプロパティ情報がどのように配布されているかにかかわらず、エンドポイントには、それらがそれらから発信されていることを判断し、それらが目的としたパスに関連するようにプロパティを認証する方法が必要です。
Choices in distribution and authentication methods will have impacts on the scalability of a path-aware architecture. Possible dimensions in the space of distribution methods include in band versus out of band, push versus pull versus publish subscribe, and so on. There are temporal issues with path property dissemination as well, especially with dynamic properties, since the measurement or elicitation of dynamic properties may be outdated by the time that information is available at the endpoints, and interactions between the measurement and dissemination delay may exhibit pathological behavior for unlucky points in the parameter space.
配布および認証方法の選択は、パス対応アーキテクチャのスケーラビリティに影響を与えます。配布方法の空間内の可能な寸法には、バンドの帯域対帯域換算、プッシュ対プル対Purfus Subscribeなどがあります。動的特性の測定または誘発はエンドポイントで情報が入手可能な時までに古くなっている可能性があるので、PATEプロパティの普及に関する時間的な問題も、動的性質の測定または誘発が終点で終わり、測定と普及遅延の間の相互作用が病理学的行動を示す可能性があるパラメータ空間内の不運なポイントの場合。
The third question: how can endpoints select paths to use for traffic in a way that can be trusted by the network, the endpoints, and the applications using them?
3番目の質問：エンドポイントには、ネットワーク、エンドポイント、およびそれらを使用しているアプリケーションによって信頼できる方法でトラフィックに使用するパスを選択することができますか。
Access to trustworthy path properties is only half of the challenge in establishing a path-aware architecture. Endpoints must be able to use this information in order to select paths for specific traffic they send. As with the dissemination of path properties, choices made in path-selection methods will also have an impact on the trade-off between scalability and expressiveness of a path-aware architecture. One key choice here is between in-band and out-of-band control of path selection. Another is granularity of path selection (whether per packet, per flow, or per larger aggregate), which also has a large impact on the scalability/expressiveness trade-off. Path selection must, like path property information, be trustworthy, such that the result of a path selection at an endpoint is predictable. Moreover, any path-selection mechanism should aim to provide an outcome that is not worse than using a single path or selecting paths at random.
TrustWorthy Pathプロパティへのアクセスは、パス対応アーキテクチャを確立する際の課題の半分だけです。エンドポイントは、送信する特定のトラフィックのパスを選択するためにこの情報を使用できる必要があります。パスプロパティの普及と同様に、パス選択方法で行われた選択は、パス対応アーキテクチャのスケーラビリティと表現力との間のトレードオフにも影響を与えます。ここで1つのキー選択は、パス選択の帯域内および帯域外制御の間である。もう1つは、パス選択の粒度（パケットごと、1フローごと、より大きな集計あたり）でもあり、スケーラビリティ/表現力のトレードオフに大きな影響を与えます。パスプロパティ情報は、パスプロパティ情報と同様に、エンドポイントでのパス選択の結果が予測可能であるように、信頼できるものです。さらに、どのパス選択メカニズムは、単一のパスを使用すること以外ではない、またはランダムにパスを選択する結果を提供することを目的としています。
Path selection may be exposed in terms of the properties of the path or the identity of elements of the path. In the latter case, a path may be identified at any of multiple layers (e.g., routing domain identifier, network-layer address, higher-layer identifier or name, and so on). In this case, care must be taken to present semantically useful information to those making decisions about which path(s) to trust.
経路選択は、経路の特性または経路の要素の身元に関して露出され得る。後者の場合、経路は複数の層（例えば、ルーティングドメイン識別子、ネットワーク層アドレス、上位層識別子または名前など）で識別され得る。この場合、どの経路を信頼するかについて決定を下すものに意味的に有用な情報を提示するように注意しなければならない。
The fourth question: how can interfaces among the network, transport, and application layers support the use of path awareness?
4番目の質問：ネットワーク、トランスポート、およびアプリケーションレイヤ間のインタフェースはどのようにパス認識の使用をサポートできますか？
In order for applications to make effective use of a path-aware networking architecture, the control interfaces presented by the network and transport layers must also expose path properties to the application in a useful way, and provide a useful set of paths among which the application can select. Path selection must be possible based not only on the preferences and policies of the application developer, but of end users as well. Also, the path-selection interfaces presented to applications and end users will need to support multiple levels of granularity. Most applications' requirements can be satisfied with the expression of path-selection policies in terms of properties of the paths, while some applications may need finer-grained, per-path control. These interfaces will need to support incremental development and deployment of applications, and provide sensible defaults, to avoid hindering their adoption.
アプリケーションが経路認識ネットワークアーキテクチャを有効に活用するために、ネットワーク層とトランスポート層によって提示された制御インタフェースは、便利な方法でパスプロパティをアプリケーションに公開し、アプリケーションの中で有用なパスのセットを提供する必要があります。選択できます。パス選択は、アプリケーション開発者の環境設定とポリシーだけでなく、エンドユーザーも同様に可能である必要があります。また、アプリケーションおよびエンドユーザーに提示されたパス選択インターフェイスは、複数のレベルの粒度をサポートする必要があります。ほとんどのアプリケーションの要件は、パスのプロパティに関してパス選択ポリシーの表現を満たすことができますが、一部のアプリケーションは粒状化された、パスごとのコントロールが微細になります。これらのインタフェースは、アプリケーションの増分開発と展開をサポートし、それらの採用を妨げるのを避けるために賢明なデフォルトを提供する必要があります。
2.5. Implications of Path Awareness for the Transport and Application Layers
2.5. 輸送層とアプリケーション層に対する経路認識の影響
The fifth question: how should transport-layer and higher-layer protocols be redesigned to work most effectively over a path-aware networking layer?
第5の質問：経路対応ネットワーク層を介して最も効果的に機能するように、トランスポート層と上位層のプロトコルをどのように再設計するべきか？
In the current Internet, the basic assumption that at a given time all traffic for a given flow will receive the same network treatment and traverse the same path or equivalent paths often holds. In a path-aware network, this assumption is more easily violated. The weakening of this assumption has implications for the design of protocols above any path-aware network layer.
現在のインターネットでは、所与の時間が与えられた流れに対するすべてのトラフィックが同じネットワーク処理を受信し、同じ経路または同等の経路を通過することができるという基本的な仮定を基本的な仮定である。経路対応ネットワークでは、この仮定はより容易に違反されます。この仮定の弱化は、任意の経路認識ネットワーク層の上のプロトコルの設計に影響を与える。
For example, one advantage of multipath communication is that a given end-to-end flow can be "sprayed" along multiple paths in order to confound attempts to collect data or metadata from those flows for pervasive surveillance purposes [RFC7624]. However, the benefits of this approach are reduced if the upper-layer protocols use linkable identifiers on packets belonging to the same flow across different paths. Clients may mitigate linkability by opting to not reuse cleartext connection identifiers, such as TLS session IDs or tickets, on separate paths. The privacy-conscious strategies required for effective privacy in a path-aware Internet are only possible if higher-layer protocols such as TLS permit clients to obtain unlinkable identifiers.
例えば、マルチパス通信の1つの利点は、周囲監視目的のための流れからデータまたはメタデータを収集する試みを混乱させるために、所与のエンドツーエンドフローを複数の経路に沿って「スプレー」することができることである。しかしながら、上位レイヤプロトコルが異なる経路にわたって同じフローに属するパケット上でリンク可能な識別子を使用する場合、このアプローチの利点は減少する。クライアントは、TLSセッションIDやチケットなどのClearText接続識別子を別々のパスで再利用しないようにリンク可能性を軽減することができます。パス対応インターネットにおける効果的なプライバシーに必要なプライバシーを意識した戦略は、TLSのような上位層のプロトコルが、クライアントがリンク不能識別子を取得することを許可する場合にのみ可能です。
The sixth question: how is path awareness (in terms of vocabulary and interfaces) different when applied to tunnel and overlay endpoints?
第6回の質問：トンネルとオーバーレイエンドポイントに適用されたときに、パス認識（語彙とインターフェースの観点から）が異ならないのですか？
The vision of path-aware networking articulated so far makes an assumption that path properties will be disseminated to endpoints on which applications are running (terminals with user agents, servers, and so on). However, incremental deployment may require that a path-aware network "core" be used to interconnect islands of legacy protocol networks. In these cases, it is the gateways, not the application endpoints, that receive path properties and make path selections for that traffic. The interfaces provided by this gateway are necessarily different than those a path-aware networking layer provides to its transport and application layers, and the path property information the gateway needs and makes available over those interfaces may also be different.
PATH対応ネットワーキングのビジョンは、これまでのところで明確にされた経路特性は、パスのプロパティがアプリケーションが実行されているエンドポイント（ユーザーエージェント、サーバーなどの端末）に普及します。しかしながら、増分展開は、経路認識ネットワーク「コア」をレガシプロトコルネットワークの島を相互接続するために使用されることを必要とし得る。このような場合は、パスのプロパティを受信し、そのトラフィックのパス選択を行うアプリケーションエンドポイントではなく、ゲートウェイです。このゲートウェイによって提供されるインターフェースは、パスアウェアネットワークレイヤがそのトランスポートおよびアプリケーション層に提供され、そのインターフェースを介して利用可能になる経路プロパティ情報もまた異なる可能性がある。
The seventh question: how can a path-aware network in a path-aware internetwork be effectively operated, given control inputs from network administrators, application designers, and end users?
7番目の質問：ネットワーク管理者、アプリケーション設計者、およびエンドユーザからの制御入力が、パス対応のインターネットワーク内のパス対応ネットワークを効果的に操作する方法をどのように効果的に操作することができますか。
The network operations model in the current Internet architecture assumes that traffic flows are controlled by the decisions and policies made by network operators as expressed in interdomain and intradomain routing protocols. In a network providing path selection to the endpoints, however, this assumption no longer holds, as endpoints may react to path properties by selecting alternate paths. Competing control inputs from path-aware endpoints and the routing control plane may lead to more difficult traffic engineering or non-convergent forwarding, especially if the endpoints' and operators' notion of the "best" path for given traffic diverges significantly. The degree of difficulty may depend on the fidelity of information made available to path-selection algorithms at the endpoints. Explicit path selection can also specify outbound paths, while BGP policies are expressed in terms of inbound traffic.
現在のインターネットアーキテクチャのネットワーク運用モデルは、トラフィックフローが、DomainとDomain Routing Protocolsで表現されているように、ネットワーク事業者によって行われた決定とポリシーによって制御されていると仮定しています。しかしながら、エンドポイントへのパス選択を提供するネットワークでは、エンドポイントが代替パスを選択することによってパスプロパティに反応する可能性があるため、この仮定はもはや保持されません。パス対応のエンドポイントとルーティング制御プレーンからの競合する制御入力は、特に、与えられたトラフィックに対する「最善の」パスのエンドポイントとオペレータの概念が大きく分岐している場合、より困難なトラフィックエンジニアリングまたは非収束転送につながる可能性があります。困難度は、エンドポイントでパス選択アルゴリズムに利用可能にされた情報の忠実度に依存する可能性があります。明示的なパス選択はアウトバウンドパスを指定することもできますが、BGPポリシーはインバウンドトラフィックに関して表現されます。
A concept for path-aware network operations will need to have clear methods for the resolution of apparent (if not actual) conflicts of intent between the network's operator and the path selection at an endpoint. It will also need a set of safety principles to ensure that increasing path control does not lead to decreasing connectivity; one such safety principle could be "the existence of at least one path between two endpoints guarantees the selection of at least one path between those endpoints."
パス対応ネットワーク操作の概念は、ネットワークのオペレータとエンドポイントでのパス選択の意図との間の明らかな（実際ではない場合）の解像度のための明確な方法を持つ必要があります。また、経路制御を増大させることで接続性が低下しないようにするために一連の安全原理が必要になる。そのような安全原理の1つは、「2つのエンドポイント間の少なくとも1つの経路の存在はそれらのエンドポイント間の少なくとも1つの経路の選択を保証する」となる可能性がある。
The eighth question: how can the incentives of network operators and end users be aligned to realize the vision of path-aware networking, and how can the transition from current ("path-oblivious") to path-aware networking be managed?
第8の質問：ネットワーク事業者やエンドユーザのインセンティブが経路対応ネットワーキングのビジョンを実現するためにどのように整列させることができ、経路認識ネットワーキングへの現在の遷移（「パス忘却」）を管理することができるのでしょうか。
The vision presented in the introduction discusses path-aware networking from the point of view of the benefits accruing at the endpoints, to designers of transport protocols and applications as well as to the end users of those applications. However, this vision requires action not only at the endpoints but also within the interconnected networks offering path-aware connectivity. While the specific actions required are a matter of the design and implementation of a specific realization of a path-aware protocol stack, it is clear that any path-aware architecture will require network operators to give up some control of their networks over to endpoint-driven control inputs.
序論に提示されたビジョンは、エンドポイントでの利点の観点から、トランスポートプロトコルやアプリケーションの設計者、ならびにそれらのアプリケーションのエンドユーザーにとって、パスアウェアネットワーキングを議論しています。ただし、このビジョンでは、エンドポイントだけでなく、パス対応の接続性を提供する相互接続されたネットワーク内でもアクションが必要です。必要な特定のアクションは、パス対応プロトコルスタックの特定の実現の設計と実装の問題であるが、パス対応のアーキテクチャではネットワーク事業者がネットワークをエンドポイントに何らかの制御を排出する必要があることが明らかである。駆動制御入力
Here, the question of apparent versus actual conflicts of intent arises again: certain network operation requirements may appear essential but are merely accidents of the interfaces provided by current routing and management protocols. For example, related (but adjacent) to path-aware networking, the widespread use of the TCP wire image [RFC8546] in network monitoring for DDoS prevention appears in conflict with the deployment of encrypted transports, only because path signaling [RFC8558] has been implicit in the deployment of past transport protocols.
ここでは、明らかな意図と実際の衝突の矛盾の問題が発生します。特定のネットワーク運用要件は不可欠ですが、現在のルーティングと管理プロトコルによって提供されるインターフェイスの事故だけです。たとえば、PATH対応ネットワーキングへの関連（しかし隣接）DDOS防止のためのネットワーク監視におけるTCPワイヤイメージ[RFC8546]の広範な使用は、パスシグナリング[RFC8558]が行われているために、暗号化トランスポートの展開と競合して表示されます。過去のトランスポートプロトコルの展開に暗黙的に。
Similarly, incentives for deployment must show how existing network operation requirements are met through new path selection and property dissemination mechanisms.
同様に、展開のためのインセンティブは、新しいパス選択および不動産普及メカニズムを通じて既存のネットワーク操作要件がどのように満たされるかを示す必要があります。
The incentives for network operators and equipment vendors need to be made clear, in terms of a plan to transition [RFC8170] an internetwork to path-aware operation, one network and facility at a time. This plan to transition must also take into account that the dynamics of path-aware networking early in this transition (when few endpoints and flows in the Internet use path selection) may be different than those later in the transition.
ネットワーク事業者および機器のベンダーのインセンティブは、遷移する計画「RFC8170」を経路対応操作、一度に1つのネットワークおよび施設に遷移させるための計画に関して明確にする必要があります。この移行計画は、この遷移の早期に経路認識ネットワーキングのダイナミクス（インターネット使用パス選択内のエンドポイントおよびフローが遷移の中でほとんどない場合）が遷移の後半と異なる場合があります。
Aspects of data security and information management in a network that explicitly radiates more information about the network's deployment and configuration, and implicitly radiates information about endpoint configuration and preference through path selection, must also be addressed.
データセキュリティと情報管理の側面ネットワークの展開と設定に関するより多くの情報を明示的に放射し、パス選択によるエンドポイント構成と優先に関する情報を暗黙的に放射するネットワークにおける情報管理にも対処する必要があります。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document poses questions about path-aware internetworking; the answers are a matter for future research, and security considerations for those answers would be included in the corresponding RFCs that describe them. While each of these questions is to a lesser or greater degree relevant to the security and privacy of users of a path-aware network, questions of discovery and trustworthiness (Section 2.2) are most security-relevant.
この文書はパス対応のインターネットワーキングに関する質問を投げます。答えは将来の研究の問題であり、それらの答えに関するセキュリティ上の考慮事項はそれらを説明する対応するRFCに含まれるでしょう。これらの質問のそれぞれは、経路対応ネットワークのセキュリティとプライバシーに関連するより少ないまたはそれ以上の程度であるが、発見と信頼性の質問（第2.2節）は最もセキュリティ関連性がある。
[MEF70] MEF, "SD-WAN Service Attributes and Services", MEF Standard, MEF 70, July 2019, <https://www.mef.net/wp-content/uploads/2019/07/MEF-70.pdf>.
[MEF70] MEF、「SD-WANサービス属性とサービス」、MEFスタンダード、MEF 70、2019年7月、<https：//www.mef.net/wp-content/uploads/2019/07/mef-70.pdf>。
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
[RFC4655] Farrel、A.、Vasseur、J.-P.およびJ.ASH、「Aパス計算要素（PCE）ベースのアーキテクチャ」、RFC 4655、DOI 10.17487 / RFC4655、2006年8月、<https：//www.rfc-editor.org/info/rfc4655>。
[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。、珪藻、S、Presidi、S.、Roome、W.、Shalunov、S.、およびR。不安、「アプリケーション層交通最適化（ALTO）プロトコル」、RFC 7285、DOI 10.17487 / RFC7285、2014年9月、<https：//www.rfc-editor.org/info/rfc7285>。
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>.
[RFC7624] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C.、D. Borkmann、「浸透性監視に直面した機密性：脅威モデルそして、2015年8月、<https：//www.rfc-editor.org/info/rfc7624>。
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, May 2017, <https://www.rfc-editor.org/info/rfc8170>.
[RFC8170] Thaler、D.、ED。、「プロトコル採用およびその後の遷移の計画」、RFC 8170、DOI 10.17487 / RFC8170、<https：//www.rfc-editor.org/info/rfc8170>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8546] Trammell, B. and M. Kuehlewind, "The Wire Image of a Network Protocol", RFC 8546, DOI 10.17487/RFC8546, April 2019, <https://www.rfc-editor.org/info/rfc8546>.
[RFC8546] Trammell、B.およびM.Kuehlewind、「ネットワークプロトコルのワイヤ画像」、RFC 8546、DOI 10.17487 / RFC8546、2019年4月、<https：//www.rfc-editor.org/info/rfc8546>。
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, <https://www.rfc-editor.org/info/rfc8558>.
[RFC8558] Hardie、T.、ED。、「トランスポートプロトコルパス信号」、RFC 8558、DOI 10.17487 / RFC8558、2019年4月、<https：//www.rfc-editor.org/info/rfc8558>。
Acknowledgments
謝辞
Many thanks to Adrian Perrig, Jean-Pierre Smith, Mirja Kühlewind, Olivier Bonaventure, Martin Thomson, Shwetha Bhandari, Chris Wood, Lee Howard, Mohamed Boucadair, Thorben Krüger, Gorry Fairhurst, Spencer Dawkins, Reese Enghardt, Laurent Ciavaglia, Stephen Farrell, and Richard Yang for discussions leading to questions in this document and for feedback on the document itself.
Adrian Perrig、Jean-Pierre Smith、MirjaKühlewind、MirjaKühlewind、Marjiier Bonaventure、Martin Thomson、Shwetha Bhandari、Chris Wood、Lee Howard、Mohamed Boucadair、Thevener Dawkins、Reese Ciavaglia、Stephen Farrell、Laurent Farrell、Stephen Farrell、Stephen Farrell、Stephen Farrell、Stephen Farrelliaそして、この文書の質問や文書自体に関するフィードバックにつながる議論のためのリチャード・ヤン。
This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture for a Middleboxed Internet (MAMI) and by the Swiss State Secretariat for Education, Research, and Innovation under contract no. 15.0268. This support does not imply endorsement.
この作品は、Horizo n 2020補助金契約番号の下で欧州委員会によって部分的に支えられています。688421ミドルボックスインターネット（MAMI）の測定とアーキテクチャと、契約番号の下での教育、研究、およびイノベーションのためのスイス国家事務局による。15.0268。このサポートは承認を意味するものではありません。
Author's Address
作者の住所
Brian Trammell Google Switzerland GmbH Gustav-Gull-Platz 1 CH-8004 Zurich Switzerland Email: ietf@trammell.ch
Brian Trammell Google Switzerland GmbH Gustav-Gull-Platz 1 CH-8004チューリッヒスイスEメール：IETF@TRAMMELL.CH