[要約] RFC 9473は、ネットワーク上のパスとそのパスを通じて提供されるサービスに関する情報を表現するためのパスプロパティを定義し、カテゴリ化する。この文書は、エンドポイントなどのエンティティにとって有用なパスプロパティを識別し、パス選択や提供されるサービスの利用に役立つ。
Internet Research Task Force (IRTF) R. Enghardt
Request for Comments: 9473 Netflix
Category: Informational C. Krähenbühl
ISSN: 2070-1721 ETH Zürich
September 2023
Path properties express information about paths across a network and the services provided via such paths. In a path-aware network, path properties may be fully or partially available to entities such as endpoints. This document defines and categorizes path properties. Furthermore, the document identifies several path properties that might be useful to endpoints or other entities, e.g., for selecting between paths or for invoking some of the provided services. This document is a product of the Path Aware Networking Research Group (PANRG).
PATHプロパティは、ネットワーク間のパスと、そのようなパスを介して提供されるサービスに関する情報を表します。パス認識ネットワークでは、パスプロパティがエンドポイントなどのエンティティが完全または部分的に使用できる場合があります。このドキュメントは、パスプロパティを定義および分類します。さらに、このドキュメントは、エンドポイントや他のエンティティに役立つ可能性のあるいくつかのパスプロパティを識別します。たとえば、パス間を選択したり、提供されたサービスの一部を呼び出すために。このドキュメントは、パス認識ネットワーキング研究グループ（PANRG）の製品です。
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）のパス認識ネットワーキング研究グループのコンセンサスを表しています。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/rfc9473.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9473で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Terminology
2.1. Terminology Usage for Specific Technologies
3. Use Cases for Path Properties
3.1. Path Selection
3.2. Protocol Selection
3.3. Service Invocation
4. Examples of Path Properties
5. Security Considerations
6. IANA Considerations
7. Informative References
Acknowledgments
Authors' Addresses
The current Internet architecture does not explicitly support endpoint discovery of forwarding paths through the network nor the discovery of properties and services associated with these paths. Path-aware networking, as defined in Section 1.1 of [RFC9217], 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". This document provides a generic definition of path properties, addressing the first of the questions in path-aware networking [RFC9217].
現在のインターネットアーキテクチャは、ネットワークを通るパスを転送するエンドポイントの発見や、これらのパスに関連するプロパティとサービスの発見を明示的にサポートしていません。[RFC9217]のセクション1.1で定義されているパスアウェアネットワークは、「インターネットワーク全体で通信に使用するパスのプロパティのエンドポイント発見、およびルーティングおよび/またはデータ転送に影響するこれらのプロパティに対するエンドポイントの反応」について説明しています。このドキュメントは、パスアウェアネットワーキングの最初の質問に対処するパスプロパティの一般的な定義を提供します[RFC9217]。
As terms related to paths have been used with different meanings in different areas of networking, first, this document provides a common terminology to define paths, path elements, and flows. Based on these terms, the document defines path properties. Then, this document provides some examples of use cases for path properties. Finally, the document lists several path properties that may be useful for the mentioned use cases. This list is intended to be neither exhaustive nor definitive.
パスに関連する用語は、ネットワーキングのさまざまな分野で異なる意味で使用されているため、最初に、このドキュメントは、パス、パス要素、およびフローを定義するための共通の用語を提供します。これらの用語に基づいて、ドキュメントはパスプロパティを定義します。次に、このドキュメントは、パスプロパティのユースケースの例をいくつか提供します。最後に、ドキュメントには、上記のユースケースに役立つ可能性のあるいくつかのパスプロパティがリストされています。このリストは、網羅的でも決定的でもないことを目的としています。
Note that this document does not assume that any of the listed path properties are actually available to any entity. The question of how entities can discover and distribute path properties in a trustworthy way is out of scope for this document.
このドキュメントでは、リストされているパスプロパティのいずれかが実際にどのエンティティが利用できると想定していないことに注意してください。エンティティが信頼できる方法でパスプロパティを発見および配布する方法の問題は、このドキュメントの範囲外です。
This document represents the consensus of the Path Aware Networking Research Group (PANRG).
このドキュメントは、パス認識ネットワーキング研究グループ（PANRG）のコンセンサスを表しています。
Entity:
実在物：
A physical or virtual device or function, or a collection of devices or functions, that plays a role related to path-aware networking for particular paths and flows. An entity can be on-path or off-path. On the path, an entity may participate in forwarding the flow, i.e., what may be called "data plane functionality". On or off the path, an entity may influence aspects of how the flow is forwarded, i.e., what may be called "control plane functionality", such as path selection or service invocation. An entity influencing forwarding aspects is usually aware of path properties, e.g., by observing or measuring them or by learning them from another entity.
特定のパスとフローのパスアウェアネットワークに関連する役割を演じる物理的または仮想デバイスまたは機能、またはデバイスまたは機能のコレクション。エンティティは、パス上またはパスのオフにすることができます。パスでは、エンティティはフローの転送、つまり「データプレーン機能」と呼ばれるものに参加する場合があります。経路の上または外側では、エンティティは、流れの転送方法、つまりパス選択やサービスの呼び出しなどの「制御プレーン機能」と呼ばれるものの側面に影響を与える可能性があります。転送の側面に影響を与えるエンティティは、通常、パスプロパティを認識しています。たとえば、それらを観察または測定したり、別のエンティティから学習したりすることにより、パスプロパティを認識します。
Node:
ノード：
An on-path entity that processes packets, e.g., sends, receives, forwards, or modifies them. A node may be physical or virtual, e.g., a physical device, a service function provided as a virtual element, or even a single queue within a switch. A node may also be an entity that consists of a collection of devices or functions, e.g., an entire Autonomous System (AS).
パケットを処理する、たとえば送信、受信、転送、または修正を行うパスオンパスエンティティ。ノードは物理的または仮想的なものである場合があります。たとえば、物理デバイス、仮想要素として提供されるサービス関数、またはスイッチ内の単一のキューなどです。ノードは、デバイスまたは機能のコレクション、たとえば自律システム全体（AS）で構成されるエンティティでもあります。
Link:
リンク：
A medium or communication facility that connects two or more nodes with each other. A link enables a node to send packets to other nodes. Links can be physical, e.g., a Wi-Fi network that connects an Access Point to stations, or virtual, e.g., a virtual switch that connects two virtual machines hosted on the same physical machine. A link is unidirectional. As such, bidirectional communication can be modeled as two links between the same nodes in opposite directions.
2つ以上のノードを互いに接続するメディアまたは通信施設。リンクを使用すると、ノードがパケットを他のノードに送信できます。リンクは、たとえば、アクセスポイントをステーションまたは仮想に接続するWi-Fiネットワーク、例えば、同じ物理マシンでホストされている2つの仮想マシンを接続する仮想スイッチなどの物理的なものにすることができます。リンクは一方向です。そのため、双方向通信は、同じノード間の反対方向の2つのリンクとしてモデル化できます。
Path element:
パス要素：
Either a node or a link. For example, a path element can be an Abstract Network Element (ANE) as defined in [RFC9275].
ノードまたはリンクのいずれか。たとえば、パス要素は、[RFC9275]で定義されている抽象ネットワーク要素（ANE）にすることができます。
Path:
パス：
A sequence of adjacent path elements over which a packet can be transmitted, starting and ending with a node. Paths are unidirectional and time dependent, i.e., there can be a variety of paths from one node to another, and the path over which packets are transmitted may change. A path definition can be strict (i.e., the exact sequence of path elements remains the same) or loose (i.e., the start and end node remain the same, but the path elements between them may vary over time). The representation of a path and its properties may depend on the entity considering the path. On the one hand, the representation may differ due to entities having partial visibility of path elements comprising a path or their visibility changing over time. On the other hand, the representation may differ due to treating path elements at different levels of abstraction. For example, a path may be given as a sequence of physical nodes and the links connecting these nodes, be given as a sequence of logical nodes such as a sequence of ASes or an Explicit Route Object (ERO), or only consist of a specific source and destination that is known to be reachable from that source. A multicast or broadcast setting where a packet is sent by one node and received by multiple nodes is described by multiple paths over which the packet is sent, one path for each combination of sending and receiving node; these paths do not have to be disjoint as defined by the disjointness path property, see Section 4.
パケットを送信できる隣接するパス要素のシーケンス、ノードで開始し、終了します。パスは一方向であり、時間に依存します。つまり、あるノードから別のノードへのさまざまなパスがあり、パケットが送信されるパスが変更される場合があります。パス定義は厳密である可能性があります（つまり、パス要素の正確なシーケンスは同じままです）または緩み（つまり、開始ノードとエンドノードは同じままですが、それらの間のパス要素は時間とともに異なる場合があります）。パスとそのプロパティの表現は、パスを考慮したエンティティによって依存する場合があります。一方では、パスを構成するパス要素の部分的な可視性や、時間の経過とともに変化するパス要素の部分的な可視性があるため、表現は異なる場合があります。一方、異なるレベルの抽象化でパス要素を処理するため、表現は異なる場合があります。たとえば、パスは一連の物理ノードとこれらのノードを接続するリンクとして与えられ、ASESまたは明示的なルートオブジェクト（ERO）のシーケンスなどの論理ノードのシーケンスとして与えられるか、特定のもののみで構成されている場合があります。そのソースから到達可能であることが知られているソースと目的地。パケットが1つのノードで送信され、複数のノードによって受信されるマルチキャストまたはブロードキャスト設定は、パケットが送信される複数のパス、ノードの送信と受信の各組み合わせの1つのパスによって記述されます。これらのパスは、分離パスプロパティによって定義されているように、ばらばらである必要はありません。セクション4を参照してください。
Endpoint:
終点：
The endpoints of a path are the start and end node of the path. For example, an endpoint can be a host as defined in [RFC1122], which can be a client (e.g., a node running a web browser) or a server (e.g., a node running a web server).
パスのエンドポイントは、パスの開始ノードとエンドノードです。たとえば、エンドポイントは[RFC1122]で定義されているホストであり、クライアント（たとえば、Webブラウザーを実行しているノード）またはサーバー（Webサーバーを実行しているノードなど）にすることができます。
Reverse Path:
リバースパス：
The path that is used by a remote node in the context of bidirectional communication.
双方向通信のコンテキストでリモートノードによって使用されるパス。
Subpath:
サブパス：
Given a path, a subpath is a sequence of adjacent path elements of this path.
パスを考えると、サブパスはこのパスの隣接するパス要素のシーケンスです。
Flow:
流れ：
One or multiple packets to which the traits of a path or set of subpaths may be applied in a functional sense. For example, a flow can consist of all packets sent within a TCP session with the same five-tuple between two hosts, or it can consist of all packets sent on the same physical link.
パスまたは一連のサブパスの特性を機能的な意味で適用できる1つまたは複数のパケット。たとえば、フローは、2つのホストの間に同じ5タプルを持つTCPセッション内で送信されるすべてのパケットで構成できます。または、同じ物理リンクで送信されたすべてのパケットで構成されます。
Property:
財産：
A trait of one or a sequence of path elements, or a trait of a flow with respect to one or a sequence of path elements. An example of a link property is the maximum data rate that can be sent over the link. An example of a node property is the administrative domain that the node belongs to. An example of a property of a flow with respect to a subpath is the aggregated one-way delay of the flow being sent from one node to another node over this subpath. A property is thus described by a tuple containing the path element(s), the flow or an empty set if no packets are relevant for the property, the name of the property (e.g., maximum data rate), and the value of the property (e.g., 1 Gbps).
パス要素の1つまたはシーケンスの特性、またはパス要素の1つまたはシーケンスに対するフローの特性。リンクプロパティの例は、リンク上に送信できる最大データレートです。ノードプロパティの例は、ノードが属する管理ドメインです。サブパスに関するフローの特性の例は、このサブパスを介して1つのノードから別のノードに送信されるフローの集約された一方向遅延です。したがって、プロパティは、パス要素、フローまたは空のセットを含むタプル、プロパティの名前、プロパティの名前（最大データレートなど）、およびプロパティの値を含むタプルによって説明されます。（例、1 Gbps）。
Aggregated property:
集約されたプロパティ：
A collection of multiple values of a property into a single value, according to a function. A property can be aggregated over: * multiple path elements (i.e., a subpath), for example, the MTU of a path as the minimum MTU of all links on the path, * multiple packets (i.e., a flow), for example, the median one-way latency of all packets between two nodes, * or both path elements and packets, for example, the mean of the queueing delays of a flow on all nodes along a path. The aggregation function can be numerical (e.g., median, sum, minimum) or logical (e.g., "true if all are true", "true if at least 50% of values are true"), or it can be an arbitrary function that maps multiple input values to an output value.
関数に従って、プロパティの複数の値のプロパティのコレクション。プロパティは次のように集約できます。たとえば、パスのすべてのノードの平均、またはパスに沿ったすべてのノードのフローのキューイングレイの平均、またはパスの両方のノード間のすべてのパケットの一元配置レイテンシの中央値。集約関数は、数値（例：中央値、合計、最小）または論理（たとえば、「すべてが真である場合」、「値の少なくとも50％が真である場合は真」）、または任意の関数になる可能性がある場合があります。複数の入力値を出力値にマッピングします。
Observed property:
観察された特性：
A property that is observed for a specific path element, subpath, or path. A property may be observed using measurements, for example, the one-way delay of a specific packet transmitted from node to node.
特定のパス要素、サブパス、またはパスに対して観察されるプロパティ。測定を使用してプロパティが観察される場合があります。たとえば、ノードからノードに送信される特定のパケットの一元配置遅延。
Assessed property:
評価された財産：
An approximate calculation or assessment of the value of a property. An assessed property includes the reliability of the calculation or assessment. The notion of reliability depends on the property. For example, a path property based on an approximate calculation may describe the expected median one-way latency of packets sent on a path within the next second, including the confidence level and interval. A non-numerical assessment may instead include the likelihood that the property holds.
プロパティの価値の近似計算または評価。評価された特性には、計算または評価の信頼性が含まれます。信頼性の概念は、プロパティに依存します。たとえば、おおよその計算に基づくパスプロパティは、信頼レベルと間隔を含む、次の秒以内に送信されたパスで送信されるパケットの予想される一元配置レイテンシの中央値を記述する場合があります。代わりに、数値以外の評価には、プロパティが保持する可能性が含まれる場合があります。
Target property:
ターゲットプロパティ：
An objective that is set for a property over a path element, subpath, or path. Note that a target property can be set for observed properties, such as one-way delay, and also for properties that cannot be observed by the entity setting the target, such as inclusion of certain nodes on a path.
パス要素、サブパス、またはパス上のプロパティに設定された目的。ターゲットプロパティは、一元配置遅延などの観測されたプロパティ、およびパスに特定のノードを含めるなど、ターゲットを設定するエンティティでは観察できないプロパティに設定できることに注意してください。
The terminology defined in this document is intended to be general and applicable to existing and future path-aware technologies. Using this terminology, a path-aware technology can define and consider specific path elements and path properties on a specific level of abstraction. For instance, a technology may define path elements as IP routers, e.g., in source routing [RFC1940]. Alternatively, it may consider path elements on a different layer of the Internet architecture [RFC1122] or as a collection of entities not tied to a specific layer, such as an AS or ERO. Even within a single path-aware technology, specific definitions might differ depending on the context in which they are used. For example, the endpoints might be the communicating hosts in the context of the transport layer, ASes that contain the hosts in the context of routing, or specific applications in the context of the application layer.
このドキュメントで定義されている用語は、一般的であり、既存および将来のパスアウェアテクノロジーに適用できることを目的としています。この用語を使用して、パスアウェアテクノロジーは、特定のレベルの抽象化で特定のパス要素とパスプロパティを定義および検討できます。たとえば、テクノロジーは、ソースルーティング[RFC1940]で、パス要素をIPルーターとして定義する場合があります。あるいは、インターネットアーキテクチャの異なるレイヤー[RFC1122]のパス要素、またはASやEROなどの特定のレイヤーに結び付けられていないエンティティのコレクションを考慮することもできます。単一のパスアウェアテクノロジー内であっても、特定の定義が使用されているコンテキストによって異なる場合があります。たとえば、エンドポイントは、輸送層のコンテキストでの通信ホスト、ルーティングのコンテキストでホストを含むASE、またはアプリケーション層のコンテキストで特定のアプリケーションです。
When a path-aware network exposes path properties to endpoints or other entities, these entities may use this information to achieve different goals. This section lists several use cases for path properties.
Path-Awareネットワークがパスプロパティをエンドポイントまたは他のエンティティに公開する場合、これらのエンティティはこの情報を使用して異なる目標を達成することができます。このセクションには、パスプロパティのいくつかのユースケースがリストされています。
Note that this is not an exhaustive list; as with every new technology and protocol, novel use cases may emerge, and new path properties may become relevant. Moreover, for any particular technology, entities may have visibility of and control over different path elements and path properties and consider them on different levels of abstraction. Therefore, a new technology may implement an existing use case related to different path elements or on a different level of abstraction.
これは網羅的なリストではないことに注意してください。すべての新しいテクノロジーやプロトコルと同様に、新しいユースケースが出現し、新しいパスプロパティが関連する可能性があります。さらに、特定のテクノロジーでは、エンティティは異なるパス要素とパスプロパティの可視性と制御を持ち、異なるレベルの抽象化でそれらを検討する場合があります。したがって、新しいテクノロジーは、異なるパス要素に関連する既存のユースケースまたは異なるレベルの抽象化を実装する場合があります。
Nodes may be able to send flows via one (or a subset) out of multiple possible paths, and an entity may be able to influence the decision about which path(s) to use. Path selection may be feasible if there are several paths to the same destination (e.g., in case of a mobile device with two wireless interfaces, both providing a path) or if there are several destinations, and thus several paths, providing the same service (e.g., Application-Layer Traffic Optimization (ALTO) [RFC5693], an application layer peer-to-peer protocol allowing endpoints a better-than-random peer selection). Entities can express their intent to achieve a specific goal by specifying target properties for their paths, e.g., related to performance or security. Then, paths can be selected that best meet the target properties, e.g., the entity can select these paths from all available paths or express the target properties to the network and rely on the network to select appropriate paths.
ノードは、複数の可能なパスから1つ（またはサブセット）を介してフローを送信できる場合があり、エンティティはどのパスを使用するかについての決定に影響を与えることができます。同じ宛先へのいくつかのパスがある場合（たとえば、2つのワイヤレスインターフェイスを備えたモバイルデバイスの場合、両方ともパスを提供する場合）、いくつかの目的地があり、したがっていくつかのパスがある場合、同じサービスを提供する場合、パスの選択が実行可能になる場合があります。たとえば、アプリケーションレイヤートラフィック最適化（ALTO）[RFC5693]、エンドポイントがランダムよりも優れたピア選択を可能にするアプリケーション層のピアツーピアプロトコル）。エンティティは、パフォーマンスやセキュリティに関連するパスのターゲットプロパティを指定することにより、特定の目標を達成する意向を表明できます。次に、ターゲットプロパティを最適に満たすパスを選択できます。たとえば、エンティティは利用可能なすべてのパスからこれらのパスを選択したり、ネットワークにターゲットプロパティを表現したり、ネットワークに依存して適切なパスを選択したりできます。
Target properties relating to network performance typically refer to observed properties, such as one-way delay, one-way packet loss, and link capacity. Entities then select paths based on their target property and the assessed property of the available paths that best match the application requirements. For such performance-related target properties, the observed property is similar to a Service Level Indicator (SLI), and the assessed property is similar to a Service Level Objective (SLO) for IETF Network Slices [NETWORK-SLICES]. As an example path-selection strategy, an entity may select a path with a short one-way delay for sending a small delay-sensitive query, while it may select a path with high link capacities on all links for retrieving a large file.
ネットワークパフォーマンスに関連するターゲットプロパティは、通常、一元配置遅延、一元配置パケット損失、リンク容量など、観測されたプロパティを指します。エンティティは、ターゲットプロパティに基づいてパスを選択し、アプリケーション要件に最適な利用可能なパスの評価されたプロパティを選択します。このようなパフォーマンス関連のターゲットプロパティの場合、観測されたプロパティはサービスレベルインジケーター（SLI）に似ており、評価されたプロパティは、IETFネットワークスライス[ネットワークスライス]のサービスレベル目標（SLO）に似ています。パス選択戦略の例として、エンティティは、小さな遅延に敏感なクエリを送信するための短い一方向遅延のあるパスを選択できますが、大きなファイルを取得するためにすべてのリンクに高いリンク容量を持つパスを選択できます。
It is also possible for an entity to set target properties that it cannot (directly) observe, similar to Service Level Expectations (SLEs) for IETF Network Slices [NETWORK-SLICES]. This may apply to security-related target properties (e.g., to mandate that all enterprise traffic goes through a specific firewall) and path selection (e.g., to enforce traffic policies by allowing or disallowing sending flows over paths that involve specific networks or nodes).
また、IETFネットワークスライス[ネットワークスライス]のサービスレベルの期待（SLE）と同様に、エンティティが（直接）観察できないターゲットプロパティを設定することも可能です。これは、セキュリティ関連のターゲットプロパティ（たとえば、すべてのエンタープライズトラフィックが特定のファイアウォールを通過することを義務付けていることを義務付ける）およびパス選択（たとえば、特定のネットワークまたはノードを含むパス上のフローの送信を許可または許可することによりトラフィックポリシーを実施するため）に適用される場合があります。
Care needs to be taken when selecting paths based on observed path properties, as path properties that were previously measured may not be helpful in predicting current or future path properties, and such path selection may lead to unintended feedback loops. Also, there may be trade-offs between path properties (e.g., one-way delay and link capacity), and entities may influence these trade-offs with their choices. Finally, path selection may impact fairness. For example, if multiple entities concurrently attempt to meet their target properties using the same network resources, one entity's choices may influence the conditions on the path as experienced by flows of another entity.
観測されたパスプロパティに基づいてパスを選択する場合は注意が必要です。以前に測定されたパスプロパティは、現在または将来のパスプロパティの予測に役立ちない場合があり、そのようなパス選択は意図しないフィードバックループにつながる可能性があります。また、パスプロパティの間にトレードオフが存在する場合があります（例：一方向の遅延とリンク容量）、エンティティはこれらのトレードオフに選択肢に影響を与える可能性があります。最後に、パスの選択は公平性に影響を与える可能性があります。たとえば、複数のエンティティが同じネットワークリソースを使用してターゲットプロパティを同時に満たそうとする場合、1つのエンティティの選択は、別のエンティティのフローが経験するように、パス上の条件に影響を与える可能性があります。
As a baseline, a path-selection algorithm should aim to do a better job of meeting the target properties, and consequently accommodating the user's requirements, than the default case of not selecting a path most of the time.
ベースラインとして、パス選択アルゴリズムは、ほとんどの場合パスを選択しないデフォルトのケースよりも、ターゲットプロパティを満たし、その結果、ユーザーの要件に対応するためのより良い仕事をすることを目指すべきです。
Path selection can be done either by the communicating node(s) or by other entities within the network. A network (e.g., an AS) can adjust its path selection for internal or external routing based on path properties. In BGP, the Multi-Exit Discriminator (MED) attribute is used in the decision-making process to select which path to choose among those having the same AS path length and origin [RFC4271]; in a path-aware network, instead of using this single MED value, other properties such as link capacity or link usage could additionally be used to improve load balancing or performance [PERFORMANCE-ROUTING].
パスの選択は、通信ノードまたはネットワーク内の他のエンティティによって実行できます。ネットワーク（ASなど）は、パスプロパティに基づいて内部または外部ルーティングのパス選択を調整できます。BGPでは、意思決定プロセスでマルチエキシット識別子（MED）属性を使用して、パスの長さと起源と同じパス[RFC4271]を選択するパスを選択します。パス認識ネットワークでは、この単一のMED値を使用する代わりに、リンク容量やリンクの使用量などの他のプロパティを使用して、負荷分散またはパフォーマンス[パフォーマンスルーティング]を改善することができます。
Before sending data over a specific path, an entity may select an appropriate protocol or configure protocol parameters depending on path properties. For example, an endpoint may cache state if a path allows the use of QUIC [RFC9000]; if so, it may first attempt to connect using QUIC before falling back to another protocol when connecting over this path again. A video-streaming application may choose an (initial) video quality based on the achievable data rate or the monetary cost of sending data (e.g., volume-based or flat-rate cost model).
特定のパスでデータを送信する前に、エンティティはパスプロパティに応じて適切なプロトコルを選択するか、プロトコルパラメーターを構成することができます。たとえば、パスがquic [rfc9000]の使用を許可する場合、エンドポイントは状態をキャッシュする場合があります。もしそうなら、このパスを再び接続するときに別のプロトコルに戻る前に、最初にQUICを使用して接続しようとするかもしれません。ビデオストリーミングアプリケーションは、達成可能なデータレートまたは送信データ（ボリュームベースまたは定額コストモデルなど）に基づいて（初期）ビデオ品質を選択できます。
In addition to path or protocol selection, an entity may choose to invoke additional functions in the context of Service Function Chaining [RFC7665], which may influence which nodes are on the path. For example, a 0-RTT Transport Converter [RFC8803] will be involved in a path only when invoked by an endpoint; such invocation will lead to the use of Multipath TCP (MPTCP) [RFC8684] or tcpcrypt [RFC8548] capabilities, while such use is not supported via the default forwarding path. Another example is a connection that is composed of multiple streams where each stream has specific service requirements. An endpoint may decide to invoke a given service function (e.g., transcoding) only for some streams while others are not processed by that service function.
パスまたはプロトコルの選択に加えて、エンティティは、パス上にあるノードに影響を与える可能性のあるサービス関数[RFC7665]のコンテキストで追加の関数を呼び出すことを選択できます。たとえば、0-RTTトランスポートコンバーター[RFC8803]は、エンドポイントによって呼び出された場合にのみパスに関与します。このような呼び出しは、マルチパスTCP（MPTCP）[RFC8684]またはTCPCRYPT [RFC8548]機能の使用につながりますが、そのような使用はデフォルトの転送パスを介してサポートされていません。別の例は、各ストリームに特定のサービス要件がある複数のストリームで構成される接続です。エンドポイントは、特定のサービス機能（たとえば、トランスコーディング）をいくつかのストリームでのみ呼び出すことを決定する場合がありますが、他のストリームはそのサービス機能によって処理されません。
This section gives some examples of path properties that may be useful, e.g., for the use cases described in Section 3.
このセクションでは、セクション3で説明されているユースケースなど、有用なパスプロパティの例をいくつか示します。
Within the context of any particular technology, available path properties may differ as entities have insight into and are able to influence different path elements and path properties. For example, an endpoint may have some visibility into path elements that are close and on a low level of abstraction (e.g., individual nodes within the first few hops), or it may have visibility into path elements that are far away and/or on a higher level of abstraction (e.g., the list of ASes traversed). This visibility may depend on factors such as the physical or network distance or the existence of trust or contractual relationships between the endpoint and the path element(s). A path property can be defined relative to individual path elements, a sequence of path elements, or "end-to-end", i.e., relative to a path that comprises of two endpoints and a single virtual link connecting them.
特定のテクノロジーのコンテキスト内では、エンティティが洞察を持ち、異なるパス要素とパスプロパティに影響を与えることができるため、利用可能なパスプロパティが異なる場合があります。たとえば、エンドポイントは、近くにあり、低レベルの抽象化（例：最初の数ホップ内の個々のノード）にあるパス要素にある程度の可視性を持つ場合があります。より高いレベルの抽象化（たとえば、ASESのリストを通過）。この可視性は、物理的またはネットワーク距離、またはエンドポイントとパス要素の間の信頼の存在、または契約上の関係などの要因に依存する場合があります。パスプロパティは、個々のパス要素、パス要素のシーケンス、または「エンドツーエンド」、つまり、2つのエンドポイントとそれらを接続する単一の仮想リンクで構成されるパスに対して、「エンドツーエンド」に対して定義できます。
Path properties may be relatively dynamic, e.g., the one-way delay of a packet sent over a specific path, or non-dynamic, e.g., the MTU of an Ethernet link that only changes infrequently. Usefulness over time differs depending on how dynamic a property is: the merit of a momentarily observed dynamic path property may diminish greatly as time goes on, e.g., it is possible for the observed values of one-way delay to change on timescales that are shorter than the one-way delay between the measurement point and an entity making a decision such as path selection, which may cause the measurement to be outdated when it reaches the decision-making entity. Therefore, consumers of dynamic path properties need to apply caution when using them, e.g., by aggregating them appropriately or applying a dampening function to their changes to avoid oscillation. In contrast, the observed value of a less dynamic path property might stay relevant for a longer period of time, e.g., a NAT typically stays on a particular path during the lifetime of a connection involving packets sent over this path.
パスプロパティは比較的動的である可能性があります。たとえば、特定のパスまたは非ダイナミックに送信されるパケットの一元配置遅延、例えば、まれに変化するイーサネットリンクのMTUなどです。時間の経過に伴う有用性は、プロパティがどの程度動的であるかによって異なります。時間が経つにつれて一時的に観察される動的パスプロパティのメリットは、一時的に観察される動的パスプロパティのメリットが大きく減少する可能性があります。測定ポイントとパス選択などの決定を下すエンティティとの間の一元配置遅延よりも、意思決定エンティティに到達すると測定が時代遅れになる可能性があります。したがって、動的なパスプロパティの消費者は、それらを使用する際には注意を払う必要があります。たとえば、それらを適切に集約するか、振動を避けるために湿潤関数を変更に適用することにより。対照的に、動的でないパスプロパティの観測値は、長期間にわたって関連性を維持する可能性があります。たとえば、NATは通常、このパスに送信されるパケットが含まれる接続の生涯の間に特定のパスにとどまります。
Access Technology:
アクセステクノロジー：
The physical- or link-layer technology used for transmitting or receiving a flow on one or multiple path elements. If known, the access technology may be given as an abstract link type, e.g., as Wi-Fi, wired Ethernet, or cellular. It may also be given as a specific technology used on a link, e.g., 3GPP cellular or 802.11 Wireless Local Area Network (WLAN). Other path elements relevant to the access technology may include nodes related to processing packets on the physical or link layer, such as elements of a cellular core network. Note that there is no common registry of possible values for this property.
1つまたは複数の経路要素の流れの送信または受信に使用される物理的またはリンク層技術。既知の場合、アクセステクノロジーには、Wi-Fi、有線イーサネット、またはセルラーなど、抽象リンクタイプとして提供される場合があります。また、リンクで使用される特定のテクノロジーとして、たとえば3GPP Cellularまたは802.11ワイヤレスローカルエリアネットワーク（WLAN）として提供される場合があります。アクセステクノロジーに関連する他のパス要素には、セルラーコアネットワークの要素など、物理レイヤーまたはリンクレイヤーの処理パケットに関連するノードが含まれる場合があります。このプロパティに可能な値の一般的なレジストリはないことに注意してください。
Monetary Cost:
金銭的費用：
The price to be paid to transmit or receive a specific flow across a network to which one or multiple path elements belong.
1つまたは複数のパス要素が属するネットワークを介して特定のフローを送信または受信するために支払われる価格。
Service Function:
サービス機能：
A service function that a path element applies to a flow, see [RFC7665]. Examples of abstract service functions include firewalls, Network Address Translation (NAT), and TCP Performance Enhancing Proxies. Some stateful service functions, such as NAT, need to observe the same flow in both directions, e.g., by being an element of both the path and the reverse path.
パス要素がフローに適用されるサービス関数は、[RFC7665]を参照してください。抽象サービス機能の例には、ファイアウォール、ネットワークアドレス変換（NAT）、およびTCPパフォーマンスのプロキシが含まれます。NATなどの一部のステートフルサービス関数は、たとえば、パスと逆パスの両方の要素であることにより、両方向に同じフローを観察する必要があります。
Transparency:
透明性：
When a node performs an action A on a flow F, the node is transparent to F with respect to some (meta-)information M if the node performs A independently of M. M can, for example, be the existence of a protocol (header) in a packet or the content of a protocol header, payload, or both. For example, A can be blocking packets or reading and modifying (other protocol) headers or payloads. Transparency can be modeled using a function f, which takes as input F and M and outputs the action taken by the node. If a taint analysis shows that the output of f is not tainted (impacted) by M, or if the output of f is constant for arbitrary values of M, then the node is considered to be transparent. An IP router could be transparent to transport protocol headers such as TCP/UDP but not transparent to IP headers since its forwarding behavior depends on the IP headers. A firewall that only allows outgoing TCP connections by blocking all incoming TCP SYN packets regardless of their IP address is transparent to IP but not to TCP headers. Finally, a NAT that actively modifies IP and TCP/UDP headers based on their content is not transparent to either IP or TCP/UDP headers. Note that according to this definition, a node that modifies packets in accordance with the endpoints, such as a transparent HTTP proxy, as defined in [RFC9110], and a node listening and reacting to implicit or explicit signals, see [RFC8558], are not considered transparent. Transparency only applies to nodes and not to links, as a link cannot modify or perform any other actions on the packets by itself. For example, if the content of a packet is altered when forwarded over a Generic Routing Encapsulation (GRE) tunnel [RFC2784] [RFC7676], per this document the software instances that terminate the tunnel are considered nodes over which the actions are performed; thus, the transparency definition applies to these nodes.
ノードがフローfでアクションaを実行すると、ノードがM. Mとは独立して実行できる場合、一部の（メタ）情報に対してノードはfに対して透過的です。たとえば、プロトコルの存在になることができます（ヘッダー）プロトコルヘッダー、ペイロード、またはその両方のパケットまたはコンテンツ。たとえば、Aはパケットをブロックしたり、ヘッダーまたはペイロードを読み取りしたり変更したりすることができます。透明性は、入力FおよびMを取得し、ノードで取得したアクションを出力する関数Fを使用してモデル化できます。汚染分析では、fの出力がmによって汚染（衝撃）されていないことを示している場合、またはfの出力がmの任意の値に対して一定の場合、ノードは透明であると見なされます。IPルーターは、TCP/UDPなどのプロトコルヘッダーを透過する可能性がありますが、フォワーディング動作はIPヘッダーに依存するため、IPヘッダーに透過的ではありません。IPアドレスに関係なく、すべての着信TCP synパケットをブロックすることにより、発信TCP接続のみを許可するファイアウォールは、IPに対して透過的ではなく、TCPヘッダーではありません。最後に、コンテンツに基づいてIPおよびTCP/UDPヘッダーを積極的に変更するNATは、IPまたはTCP/UDPヘッダーのいずれにも透過的ではありません。この定義によれば、[RFC9110]で定義されている透明なHTTPプロキシなどのエンドポイントに従ってパケットを変更するノード、および暗黙的または明示的な信号にリスニングおよび反応するノードは、[RFC8558]を参照してください。透明とは見なされません。リンクはパケット上の他のアクションを単独で変更または実行できないため、透明度はノードにのみ適用されず、リンクには適用されません。たとえば、汎用ルーティングカプセル化（GRE）トンネル[RFC2784] [RFC7676]に転送されると、パケットの内容が変更された場合、このドキュメントに従って、アクションが実行されるトンネルを終了するソフトウェアインスタンスは、ノードと見なされます。したがって、透明性定義はこれらのノードに適用されます。
Administrative Domain:
管理ドメイン：
The identity of an individual or an organization that controls access to a path element (or several path elements). Examples of administrative domains are an IGP area, an AS, or a service provider network.
パス要素（または複数のパス要素）へのアクセスを制御する個人または組織の身元。管理ドメインの例は、IGP領域、AS、またはサービスプロバイダーネットワークです。
Routing Domain Identifier:
ルーティングドメイン識別子：
An identifier indicating the routing domain of a path element. Path elements in the same routing domain are in the same administrative domain and use a common routing protocol to communicate with each other. An example of a routing domain identifier is the globally unique Autonomous System Number (ASN) as defined in [RFC1930].
パス要素のルーティングドメインを示す識別子。同じルーティングドメインのパス要素は同じ管理ドメインにあり、共通のルーティングプロトコルを使用して相互に通信します。ルーティングドメイン識別子の例は、[RFC1930]で定義されているように、グローバルに一意の自律システム数（ASN）です。
Disjointness:
嫌悪感：
For a set of two paths or subpaths, the number of shared path elements can be a measure of intersection (e.g., Jaccard coefficient, which is the number of shared elements divided by the total number of elements). Conversely, the number of non-shared path elements can be a measure of disjointness (e.g., 1 - Jaccard coefficient). A multipath protocol might use disjointness as a metric to reduce the number of single points of failure. As paths can be defined at different levels of abstraction, two paths may be disjoint at one level of abstraction but not on another.
2つのパスまたはサブパスのセットの場合、共有されたパス要素の数は、交差点の尺度（たとえば、Jaccard係数、これは要素の総数で割った共有要素の数）です。逆に、非共有パス要素の数は、ばらばらの尺度になります（例：1 -Jaccard係数）。マルチパスプロトコルは、障害の単一ポイントの数を減らすためにメトリックとしての分離を使用する場合があります。パスはさまざまなレベルの抽象化で定義できるため、あるレベルの抽象化では2つのパスが矛盾している可能性がありますが、別のレベルでは見られません。
Symmetric Path:
対称パス：
Two paths are symmetric if the path and its reverse path consist of the same path elements on the same level of abstraction, but in reverse order. For example, a path that consists of layer 3 switches and links between them and a reverse path with the same path elements but in reverse order are considered "routing" symmetric, as the same path elements on the same level of abstraction (IP forwarding) are traversed in the opposite direction. Symmetry can depend on the level of abstraction on which the path is defined or modeled. If there are two parallel physical links between two nodes, modeling them as separate links may result in a flow using asymmetric paths, and modeling them as a single virtual link may result in symmetric paths, e.g., if the difference between the two physical links is irrelevant in a particular context.
パスとその逆パスが同じレベルの抽象化の同じパス要素で構成されている場合、逆の順序で2つのパスが対称です。たとえば、レイヤー3のスイッチとリンクと同じパス要素を持つ逆パスで構成されるパスは、同じレベルの抽象化（IP転送）の同じパス要素として、「ルーティング」対称と見なされます。反対方向に横断されます。対称性は、パスが定義またはモデル化されている抽象化のレベルに依存します。2つのノード間に2つの並列物理リンクがある場合、それらを個別のリンクとしてモデル化すると、非対称パスを使用してフローが得られる場合があり、それらを単一の仮想リンクとしてモデル化すると、2つの物理リンクの違いがある場合、対称パスになる場合があります。特定の文脈では無関係です。
Path MTU:
PathMTU：
The maximum size, in octets, of a packet or frame that can be transmitted without fragmentation.
断片化せずに送信できるパケットまたはフレームの最大サイズ、オクテット、またはフレームの最大サイズ。
Transport Protocols available:
利用可能な輸送プロトコル：
Whether a specific transport protocol can be used to establish a connection over a path or subpath, e.g., whether the path is QUIC-capable or MPTCP-capable, based on input such as policy, cached knowledge, or probing results.
特定のトランスポートプロトコルを使用して、パスまたはサブパスを介した接続を確立できるかどうか、たとえば、ポリシー、キャッシュされた知識、調査結果などの入力に基づいて、パスがQUIC対応またはMPTCP対応であるかどうか。
Protocol Features available:
利用可能なプロトコル機能：
Whether a specific protocol feature is available over a path or subpath, e.g., Explicit Congestion Notification (ECN) or TCP Fast Open.
特定のプロトコル機能がパスまたはサブパスで利用できるかどうか、たとえば明示的な輻輳通知（ECN）またはTCP高速開く。
Some path properties express the performance of the transmission of a packet or flow over a link or subpath. Such transmission performance properties can be observed or assessed, e.g., by endpoints or by path elements on the path, or they may be available as cost metrics, see [RFC9439]. Transmission performance properties may be made available in an aggregated form, such as averages or minimums. Properties related to a path element that constitutes a single layer 2 domain are abstracted from the used physical- and link-layer technology, similar to [RFC8175].
一部のパスプロパティは、リンクまたはサブパスを介したパケットまたはフローの送信のパフォーマンスを表しています。このような伝送パフォーマンスプロパティは、例えば、エンドポイントまたはパス上のパス要素によって観察または評価できます。または、コストメトリックとして使用できる場合があります。[RFC9439]を参照してください。トランスミッションパフォーマンスのプロパティは、平均や最小値などの集約された形式で利用可能になる場合があります。単一層2ドメインを構成するパス要素に関連する特性は、[RFC8175]と同様に、使用されている物理的およびリンク層技術から抽出されます。
Link Capacity:
リンク容量：
The link capacity is the maximum data rate at which data that was sent over a link can correctly be received at the node adjacent to the link. This property is analogous to the link capacity defined in [RFC5136] and [RFC9097] but is not restricted to IP-layer traffic.
リンク容量は、リンクを介して送信されたデータをリンクに隣接するノードで正しく受信できる最大データレートです。このプロパティは、[RFC5136]および[RFC9097]で定義されているリンク容量に類似していますが、IP層トラフィックに限定されていません。
Link Usage:
リンクの使用法：
The link usage is the actual data rate at which data that was sent over a link is correctly received at the node adjacent to the link. This property is analogous to the link usage defined in [RFC5136] and [RFC9097] but is not restricted to IP-layer traffic.
リンクの使用法は、リンクを介して送信されたデータがリンクに隣接するノードで正しく受信される実際のデータレートです。このプロパティは、[RFC5136]および[RFC9097]で定義されているリンク使用量に類似していますが、IP層トラフィックに限定されていません。
One-Way Delay:
一元配置遅延：
The one-way delay is the delay between a node sending a packet and another node on the same path receiving the packet. This property is analogous to the one-way delay defined in [RFC7679] but is not restricted to IP-layer traffic.
一元配置遅延は、パケットを送信するノードとパケットを受信する同じパス上の別のノードの間の遅延です。このプロパティは、[RFC7679]で定義されている一元配置遅延に類似していますが、IP層トラフィックに限定されていません。
One-Way Delay Variation:
一元配置遅延バリエーション：
The variation of the one-way delays within a flow. This property is similar to the one-way delay variation defined in [RFC3393], but it is not restricted to IP-layer traffic and it is defined for packets on the same flow instead of packets sent between a source and destination IP address.
フロー内の一方向遅延の変動。このプロパティは[RFC3393]で定義されている一方向遅延変動に似ていますが、IP層トラフィックに限定されておらず、ソースと宛先IPアドレス間で送信されるパケットの代わりに同じフローのパケットに対して定義されています。
One-Way Packet Loss:
一元配置パケット損失：
Packets sent by a node but not received by another node on the same path after a certain time interval are considered lost. This property is analogous to the one-way loss defined in [RFC7680] but is not restricted to IP-layer traffic. Metrics such as loss patterns [RFC3357] and loss episodes [RFC6534] can be expressed as aggregated properties.
特定の時間間隔が失われたと見なされた後、同じパスで別のノードで受信されていないノードによって送信されたパケット。このプロパティは、[RFC7680]で定義されている一方向損失に類似していますが、IP層トラフィックに限定されていません。損失パターン[RFC3357]や損失エピソード[RFC6534]などのメトリックは、集計特性として表現できます。
If entities are basing policy or path-selection decisions on path properties, they need to rely on the accuracy of path properties that other devices communicate to them. In order to be able to trust such path properties, entities may need to establish a trust relationship or be able to independently verify the authenticity, integrity, and correctness of path properties received from another entity.
エンティティがパスプロパティに関するポリシーまたはパス選択の決定に基づいている場合、他のデバイスが通信するパスプロパティの精度に依存する必要があります。そのようなパスプロパティを信頼できるようにするには、エンティティは信頼関係を確立するか、別のエンティティから受け取ったパスプロパティの信頼性、整合性、および正確性を独立して検証する必要がある場合があります。
Entities that reveal their target path properties to the network can negatively impact their own privacy, e.g., if the target property leaks personal information about a user, such as their identity or which (type of) application is used. Such information could then allow network operators to block or reprioritize traffic for certain users and/or applications. Conversely, if privacy-enhancing technologies, e.g., MASQUE proxies [RFC9298], are used on a path, the path may only be partially visible to any single entity. This may diminish the usefulness of path-aware technologies over this path.
ネットワークへのターゲットパスプロパティを明らかにするエンティティは、たとえば、ターゲットプロパティがユーザーに関する個人情報（アイデンティティなど）が使用される場合、（タイプの）アプリケーションが使用されている場合、独自のプライバシーに悪影響を与える可能性があります。そのような情報により、ネットワークオペレーターは、特定のユーザーやアプリケーションのトラフィックをブロックまたは再現できるようになります。逆に、プライバシーを向上させるテクノロジー（例えば、マスクプロキシ[RFC9298]がパスで使用される場合、パスは任意のエンティティに部分的にしか見えない場合があります。これにより、このパスでのパスアウェアテクノロジーの有用性が低下する可能性があります。
The need for, and potential definition of, security- and privacy-related path properties, such as confidentiality and integrity protection of payloads, are the subject of ongoing discussion and research, for example, see [RFC9049] and [RFC9217]. As the discussion of such properties is not mature enough, they are out of scope for this document. One aspect discussed in this context is that security-related properties are difficult to characterize since they are only meaningful with respect to a threat model that depends on the use case, application, environment, and other factors. Likewise, properties for trust relations between entities cannot be meaningfully defined without a concrete threat model, and defining a threat model is out of scope for this document. Properties related to confidentiality, integrity, and trust seem to be orthogonal to the path terminology and path properties defined in this document, since they are tied to the communicating nodes and the protocols they use (e.g., client and server using HTTPS, or client and remote network node using a VPN service) as well as additional context, such as keying material and who has access to such a context. In contrast, the path as defined in this document is typically oblivious to these aspects. Intuitively, the path describes what function the network applies to packets, while confidentiality, integrity, and trust describe what function the communicating parties apply to packets.
ペイロードの機密性や整合性の保護など、セキュリティおよびプライバシー関連のパスプロパティの必要性と潜在的な定義は、たとえば[RFC9049]および[RFC9217]を参照して進行中の議論と研究の対象です。そのような特性の議論は十分に成熟していないため、このドキュメントの範囲外です。このコンテキストで説明されている1つの側面は、セキュリティ関連のプロパティは、ユースケース、アプリケーション、環境、およびその他の要因に依存する脅威モデルに関してのみ意味があるため、特徴付けが困難であることです。同様に、エンティティ間の信頼関係のプロパティは、具体的な脅威モデルなしでは有意義に定義することはできません。脅威モデルの定義は、このドキュメントの範囲外です。機密性、整合性、および信頼に関連するプロパティは、このドキュメントで定義されているパス用語とパスプロパティに直交するようです。これは、使用する通信ノードとプロトコル（HTTP、またはクライアントとクライアントとクライアントを使用してクライアントとサーバーを使用するプロトコルに関連付けられているためVPNサービスを使用したリモートネットワークノードと、キーイング素材やそのようなコンテキストにアクセスできる追加のコンテキスト。対照的に、このドキュメントで定義されているパスは、通常、これらの側面を忘れています。直感的に、パスはネットワークがパケットに適用する機能を記述し、機密性、整合性、および信頼は、通信者がパケットに適用する機能を説明します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[NETWORK-SLICES]
Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani,
K., Contreras, L. M., and J. Tantsura, "A Framework for
Network Slices in Networks Built from IETF Technologies",
Work in Progress, Internet-Draft, draft-ietf-teas-ietf-
network-slices-24, 25 August 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-
ietf-network-slices-24>.
[PERFORMANCE-ROUTING]
Xu, X., Hegde, S., Talaulikar, K., Boucadair, M., and C.
Jacquenet, "Performance-based BGP Routing Mechanism", Work
in Progress, Internet-Draft, draft-ietf-idr-performance-
routing-03, 21 December 2020,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-
performance-routing-03>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>.
[RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, DOI 10.17487/RFC1930, March 1996,
<https://www.rfc-editor.org/info/rfc1930>.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940,
DOI 10.17487/RFC1940, May 1996,
<https://www.rfc-editor.org/info/rfc1940>.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>.
[RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample
Metrics", RFC 3357, DOI 10.17487/RFC3357, August 2002,
<https://www.rfc-editor.org/info/rfc3357>.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation
Metric for IP Performance Metrics (IPPM)", RFC 3393,
DOI 10.17487/RFC3393, November 2002,
<https://www.rfc-editor.org/info/rfc3393>.
[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>.
[RFC5136] Chimento, P. and J. Ishac, "Defining Network Capacity",
RFC 5136, DOI 10.17487/RFC5136, February 2008,
<https://www.rfc-editor.org/info/rfc5136>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
DOI 10.17487/RFC5693, October 2009,
<https://www.rfc-editor.org/info/rfc5693>.
[RFC6534] Duffield, N., Morton, A., and J. Sommers, "Loss Episode
Metrics for IP Performance Metrics (IPPM)", RFC 6534,
DOI 10.17487/RFC6534, May 2012,
<https://www.rfc-editor.org/info/rfc6534>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<https://www.rfc-editor.org/info/rfc7665>.
[RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
for Generic Routing Encapsulation (GRE)", RFC 7676,
DOI 10.17487/RFC7676, October 2015,
<https://www.rfc-editor.org/info/rfc7676>.
[RFC7679] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Delay Metric for IP Performance Metrics
(IPPM)", STD 81, RFC 7679, DOI 10.17487/RFC7679, January
2016, <https://www.rfc-editor.org/info/rfc7679>.
[RFC7680] Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton,
Ed., "A One-Way Loss Metric for IP Performance Metrics
(IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January
2016, <https://www.rfc-editor.org/info/rfc7680>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>.
[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.
[RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
2020, <https://www.rfc-editor.org/info/rfc8684>.
[RFC8803] Bonaventure, O., Ed., Boucadair, M., Ed., Gundavelli, S.,
Seo, S., and B. Hesmans, "0-RTT TCP Convert Protocol",
RFC 8803, DOI 10.17487/RFC8803, July 2020,
<https://www.rfc-editor.org/info/rfc8803>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.
[RFC9097] Morton, A., Geib, R., and L. Ciavattone, "Metrics and
Methods for One-Way IP Capacity", RFC 9097,
DOI 10.17487/RFC9097, November 2021,
<https://www.rfc-editor.org/info/rfc9097>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/info/rfc9217>.
[RFC9275] Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang,
"An Extension for Application-Layer Traffic Optimization
(ALTO): Path Vector", RFC 9275, DOI 10.17487/RFC9275,
September 2022, <https://www.rfc-editor.org/info/rfc9275>.
[RFC9298] Schinazi, D., "Proxying UDP in HTTP", RFC 9298,
DOI 10.17487/RFC9298, August 2022,
<https://www.rfc-editor.org/info/rfc9298>.
[RFC9439] Wu, Q., Yang, Y., Lee, Y., Dhody, D., Randriamasy, S., and
L. Contreras, "Application-Layer Traffic Optimization
(ALTO) Performance Cost Metrics", RFC 9439,
DOI 10.17487/RFC9439, August 2023,
<https://www.rfc-editor.org/info/rfc9439>.
Thanks to the Path Aware Networking Research Group for the discussion and feedback. Specifically, thanks to Mohamed Boucadair for the detailed review, various text suggestions, and shepherding; thanks to Brian Trammell for suggesting the flow definition; and thanks to Luis M. Contreras, Spencer Dawkins, Paul Hoffman, Jake Holland, Colin Perkins, Adrian Perrig, and Matthias Rost for the reviews, comments, and suggestions. Many thanks to Dave Oran for his careful IRSG review.
ディスカッションとフィードバックについて、Path Aware Networking Research Groupに感謝します。具体的には、詳細なレビュー、さまざまなテキストの提案、羊飼いのMohamed Boucadairに感謝します。フローの定義を提案してくれたブライアン・トラメルに感謝します。そして、ルイス・M・コントレラス、スペンサー・ドーキンス、ポール・ホフマン、ジェイク・ホランド、コリン・パーキンス、エイドリアン・ペリグ、マティアス・ロストのレビュー、コメント、提案のおかげです。彼の慎重なIRSGレビューをしてくれたDave Oranに感謝します。
Reese Enghardt
Netflix
Email: ietf@tenghardt.net
Cyrill Krähenbühl
ETH Zürich
Email: cyrill.kraehenbuehl@inf.ethz.ch