[要約] RFC 9198は、ネットワークパスの性能を評価するためのAdvanced Unidirectional Route Assessment (AURA)プロトコルに関するものです。このプロトコルの目的は、一方向のデータ転送パスの品質を測定し、ネットワークの問題を特定することにあります。利用場面としては、ISPや大規模ネットワークの運用者がネットワークのパフォーマンスを監視し、最適化する際に活用されます。
Internet Engineering Task Force (IETF) J. Alvarez-Hamelin
Request for Comments: 9198 Universidad de Buenos Aires
Updates: 2330 A. Morton
Category: Standards Track AT&T Labs
ISSN: 2070-1721 J. Fabini
TU Wien
C. Pignataro
Cisco Systems, Inc.
R. Geib
Deutsche Telekom
May 2022
Advanced Unidirectional Route Assessment (AURA)
高度な一方向ルート評価（オーラ）
Abstract
概要
This memo introduces an advanced unidirectional route assessment (AURA) metric and associated measurement methodology based on the IP Performance Metrics (IPPM) framework (RFC 2330). This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multipath technologies.
このメモは、IPパフォーマンスメトリック（IPPM）フレームワーク（RFC 2330）に基づいて、高度な単方向ルート評価（AURA）メトリックおよび関連する測定方法論を紹介します。このメモは、マルチパステクノロジーの存在により、特定のソースペアと宛先ペアの間に並列サブパスの可能性を含めるために、パス関連の用語とパスの説明の領域でRFC 2330を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9198.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9198で取得できます。
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
1.1. Issues with Earlier Work to Define a Route Metric
1.2. Requirements Language
2. Scope
3. Route Metric Specifications
3.1. Terms and Definitions
3.2. Formal Name
3.3. Parameters
3.4. Metric Definitions
3.5. Related Round-Trip Delay and Loss Definitions
3.6. Discussion
3.7. Reporting the Metric
4. Route Assessment Methodologies
4.1. Active Methodologies
4.1.1. Temporal Composition for Route Metrics
4.1.2. Routing Class Identification
4.1.3. Intermediate Observation Point Route Measurement
4.2. Hybrid Methodologies
4.3. Combining Different Methods
5. Background on Round-Trip Delay Measurement Goals
6. RTD Measurements Statistics
7. Security Considerations
8. IANA Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. MPLS Methods for Route Assessment
Acknowledgements
Authors' Addresses
The IETF IP Performance Metrics (IPPM) Working Group first created a framework for metric development in [RFC2330]. This framework has stood the test of time and enabled development of many fundamental metrics. It has been updated in the area of metric composition [RFC5835] and in several areas related to active stream measurement of modern networks with reactive properties [RFC7312].
IETF IPパフォーマンスメトリック（IPPM）ワーキンググループは、最初に[RFC2330]のメトリック開発のフレームワークを作成しました。このフレームワークは、時間のテストに耐え、多くの基本的なメトリックの開発を可能にしました。メトリック組成の領域[RFC5835]およびリアクティブ特性を使用した最新のネットワークのアクティブストリーム測定に関連するいくつかの領域[RFC7312]で更新されています。
The framework in [RFC2330] motivated the development of "performance and reliability metrics for paths through the Internet"; Section 5 of [RFC2330] defines terms that support description of a path under test. However, metrics for assessment of paths and related performance aspects had not been attempted in IPPM when the framework in [RFC2330] was written.
[RFC2330]のフレームワークは、「インターネットを介したパスのパフォーマンスと信頼性メトリック」の開発を動機付けました。[RFC2330]のセクション5では、テスト中のパスの説明をサポートする用語を定義します。ただし、[RFC2330]のフレームワークが書かれたとき、IPPMでパスと関連するパフォーマンスの側面を評価するためのメトリックは試みられていませんでした。
This memo takes up the Route measurement challenge and specifies a new Route metric, two practical frameworks for methods of measurement (using either active or hybrid active-passive methods [RFC7799]), and Round-Trip Delay and link information discovery using the results of measurements. All Route measurements are limited by the willingness of Hosts along the path to be discovered, to cooperate with the methods used, or to recognize that the measurement operation is taking place (such as when tunnels are present).
このメモは、ルート測定チャレンジを取り上げ、新しいルートメトリック、測定方法のための2つの実用的なフレームワーク（アクティブまたはハイブリッドアクティブパッシブメソッド[RFC7799]を使用）、およびラウンドトリップの遅延とリンク情報の発見を指定します。測定。すべてのルート測定は、発見されるパスに沿ったホストの意欲、使用される方法と協力すること、または測定操作が行われていることを認識することによって制限されます（トンネルが存在するなど）。
Section 7 of [RFC2330] presents a simple example of a "Route" metric along with several other examples. The example is reproduced below (where the reference is to Section 5 of [RFC2330]):
[RFC2330]のセクション7は、他のいくつかの例とともに「ルート」メトリックの簡単な例を示しています。この例を以下に再現します（参照は[RFC2330]のセクション5への参照です）：
| route: The path, as defined in Section 5, from A to B at a given | time.
|ルート：セクション5で定義されているパスは、与えられた|時間。
This example provides a starting point to develop a more complete definition of Route. Areas needing clarification include:
この例は、ルートのより完全な定義を開発するための出発点を提供します。明確化が必要な領域には次のものがあります。
Time: In practice, the Route will be assessed over a time interval because active path detection methods like Paris-traceroute [PT] rely on Hop Limits for their operation and cannot accomplish discovery of all Hosts using a single packet.
時間：実際には、ルートは時間間隔で評価されます。これは、パリトレーサーアウト[PT]のようなアクティブパス検出方法がホップ制限に依存しており、単一のパケットを使用してすべてのホストの発見を達成できないためです。
Type-P: The legacy Route definition lacks the option to cater for packet-dependent routing. In this memo, we assess the Route for a specific packet of Type-P and reflect this in the metric definition. The methods of measurement determine the specific Type-P used.
タイプ-P：レガシールートの定義には、パケット依存ルーティングに対応するオプションがありません。このメモでは、タイプPの特定のパケットのルートを評価し、メトリック定義にこれを反映します。測定方法により、使用される特定のタイプ-Pが決定されます。
Parallel Paths: Parallel paths are a reality of the Internet and a strength of advanced Route assessment methods, so the metric must acknowledge this possibility. Use of Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP) technologies are common sources of parallel subpaths.
並列パス：平行パスは、インターネットの現実であり、高度なルート評価方法の強度であるため、メトリックはこの可能性を認識する必要があります。等しいコストマルチパス（ECMP）および不平等なコストマルチパス（UCMP）テクノロジーの使用は、並列サブパスの一般的なソースです。
Cloud Subpath: Cloud subpaths may contain Hosts that do not decrement the Hop Limit but may have two or more exchange links connecting "discoverable" Hosts or routers. Parallel subpaths contained within clouds cannot be discovered. The assessment methods only discover Hosts or routers on the path that decrement Hop Limit or cooperate with interrogation protocols. The presence of tunnels and nested tunnels further complicate assessment by hiding Hops.
クラウドサブパス：クラウドサブパスには、ホップ制限を減少させないが、「発見可能な」ホストまたはルーターを接続する2つ以上の交換リンクがある場合があるホストが含まれている場合があります。雲内に含まれる平行サブパスを発見することはできません。評価方法は、ホップ制限を減らすか、尋問プロトコルに協力するパス上のホストまたはルーターのみを発見します。トンネルとネストされたトンネルの存在は、ホップを隠すことにより、さらに複雑に評価されます。
Hop: The definition of Hop in [RFC2330] was a link-Host pair. However, only Hosts that were discoverable and cooperated with interrogation protocols (where link information may be exposed) provided both link and Host information.
ホップ：[RFC2330]のホップの定義は、リンクホストペアでした。ただし、リンク情報とホスト情報の両方が提供された尋問プロトコル（リンク情報が公開される可能性がある）と協力したホストのみが尋問プロトコル（リンク情報が公開される可能性があります）。
Note that the actual definitions appear in Section 3.1.
実際の定義はセクション3.1に表示されることに注意してください。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The purpose of this memo is to add new Route metrics and methods of measurement to the existing set of IPPM metrics.
このメモの目的は、既存のIPPMメトリックセットに新しいルートメトリックと測定方法を追加することです。
The scope is to define Route metrics that can identify the path taken by a packet or a flow traversing the Internet between two Hosts. Although primarily intended for Hosts communicating on the Internet, the definitions and metrics are constructed to be applicable to other network domains, if desired. The methods of measurement to assess the path may not be able to discover all Hosts comprising the path, but such omissions are often deterministic and explainable sources of error.
範囲は、2つのホスト間でインターネットを通過するパケットまたはフローによって実行されるパスを識別できるルートメトリックを定義することです。主にインターネット上で通信するホストを対象としていますが、必要に応じて他のネットワークドメインに適用できるように定義とメトリックが構築されています。パスを評価するための測定方法は、パスを構成するすべてのホストを発見できない場合がありますが、そのような省略はしばしば決定論的で説明可能なエラーの原因です。
This memo also specifies a framework for active methods of measurement that uses the techniques described in [PT] as well as a framework for hybrid active-passive methods of measurement, such as the Hybrid Type I method [RFC7799] described in [RFC9197]. Methods using [RFC9197] are intended only for single administrative domains that provide a protocol for explicit interrogation of Nodes on a path. Combinations of active methods and hybrid active-passive methods are also in scope.
このメモは、[PT]で説明されている手法を使用するアクティブな測定方法のフレームワークと、[RFC9197]で説明されているハイブリッドI型メソッド[RFC7799]などのハイブリッドアクティブパッシブ測定方法のフレームワークも指定します。[RFC9197]を使用した方法は、パス上のノードの明示的な尋問のためのプロトコルを提供する単一の管理ドメインのみを対象としています。アクティブな方法とハイブリッドアクティブパッシブメソッドの組み合わせも範囲にあります。
Further, this memo provides additional analysis of the Round-Trip Delay measurements made possible by the methods in an effort to discover more details about the path, such as the link technology in use.
さらに、このメモは、使用中のリンクテクノロジーなど、パスに関する詳細を発見するために、方法によって可能になった往復遅延測定の追加分析を提供します。
This memo updates Section 5 of [RFC2330] in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination address pair (possibly resulting from ECMP and UCMP technologies).
このメモは、[RFC2330]のセクション5をパス関連の用語とパス記述の領域で更新します。これは、主に特定のソースアドレスペアと宛先アドレスペアの間に並列サブパスの可能性を含めるためです（ECMPとUCMPテクノロジーに起因する可能性があります）。
There are several simple non-goals of this memo. There is no attempt to assess the reverse path from any Host on the path to the Host attempting the path measurement. The reverse path contribution to delay will be that experienced by ICMP packets (in active methods) and may be different from delays experienced by UDP or TCP packets. Also, the Round-Trip Delay will include an unknown contribution of processing time at the Host that generates the ICMP response. Therefore, the ICMP-based active methods are not supposed to yield accurate, reproducible estimations of the Round-Trip Delay that UDP or TCP packets will experience.
このメモにはいくつかの簡単な非ゴールがあります。パス測定を試みるホストへのパス上のホストからの逆パスを評価する試みはありません。遅延への逆パスの寄与は、ICMPパケット（アクティブな方法で）が経験したものであり、UDPまたはTCPパケットが経験する遅延とは異なる場合があります。また、往復遅延には、ICMP応答を生成するホストでの処理時間の不明な寄与が含まれます。したがって、ICMPベースのアクティブな方法は、UDPまたはTCPパケットが経験する往復遅延の正確で再現可能な推定をもたらすことは想定されていません。
This section sets requirements for the components of the route metric.
このセクションでは、ルートメトリックのコンポーネントの要件を設定します。
Host A Host (as defined in [RFC2330]) is a computer capable of IP communication, including routers (aka an RFC 2330 Host).
ホスト（[RFC2330]で定義されている）は、ルーター（別名RFC 2330ホスト）を含むIP通信が可能なコンピューターです。
Node A Node is any network function on the path capable of IP-layer Communication, including RFC 2330 Hosts.
ノードAノードは、RFC 2330ホストを含むIP層通信が可能なパス上のネットワーク機能です。
Node Identity The Node identity is the unique address for Nodes communicating within the network domain. For Nodes communicating on the Internet with IP, it is the globally routable IP address that the Node uses when communicating with other Nodes under normal or error conditions. The Node identity revealed (and its connection to a Node name through reverse DNS) determines whether interfaces to parallel links can be associated with a single Node or appear to identify unique Nodes.
ノードIDノードIDは、ネットワークドメイン内で通信するノードの一意のアドレスです。IPでインターネット上で通信するノードの場合、それはノードが通常のノードまたはエラー条件下で他のノードと通信するときに使用するグローバルにルーティング可能なIPアドレスです。明らかにされたノードのID（および逆DNSを介したノード名への接続）は、並列リンクへのインターフェイスを単一のノードに関連付けることができるか、一意のノードを識別できるかどうかを決定します。
Discoverable Node Discoverable Nodes are Nodes that convey their Node identity according to the requirements of their network domain, such as when error conditions are detected by that Node. For Nodes communicating with IP packets, compliance with Section 3.2.2.4 of [RFC1122], when discarding a packet due to TTL or Hop Limit Exceeded condition, MUST result in sending the corresponding Time Exceeded message (containing a form of Node identity) to the source. This requirement is also consistent with Section 5.3.1 of [RFC1812] for routers.
発見可能なノード検出可能なノードは、そのノードによってエラー条件が検出された場合など、ネットワークドメインの要件に従ってノードIDを伝えるノードです。IPパケットと通信するノードの場合、[RFC1122]のセクション3.2.2.4のコンプライアンス、TTLまたはホップ制限が条件を超えたためにパケットを破棄する場合、対応する時間を超えたメッセージ（ノードアイデンティティの形式を含む）を送信する必要があります。ソース。この要件は、ルーターの[RFC1812]のセクション5.3.1とも一致しています。
Cooperating Node Cooperating Nodes are Nodes that respond to direct queries for their Node identity as part of a previously established and agreed upon interrogation protocol. Nodes SHOULD also provide information such as arrival/departure interface identification, arrival timestamp, and any relevant information about the Node or specific link that delivered the query to the Node.
協力ノード協力ノードは、以前に確立され、合意された尋問プロトコルの一部として、ノードIDの直接クエリに応答するノードです。また、ノードは、到着/出発インターフェイスの識別、到着タイムスタンプ、およびノードにクエリを提供するノードまたは特定のリンクに関する関連情報を提供する必要があります。
Hop specification A Hop specification MUST contain a Node identity and MAY contain arrival and/or departure interface identification, Round-Trip Delay, and an arrival timestamp.
ホップ仕様ホップ仕様には、ノードのIDが含まれている必要があり、到着および/または出発インターフェイス識別、往復遅延、到着タイムスタンプを含めることができます。
Routing Class Routing Class is a Route that treats a class of different types of packets, designated "C" (unrelated to address classes of the past) equally ([RFC2330] [RFC8468]). Knowledge of such a class allows any one of the types of packets within that class to be used for subsequent measurement of the Route. The designator "class C" is used for historical reasons; see [RFC2330].
ルーティングクラスルーティングクラスは、さまざまな種類のパケットのクラスを扱うルートです。これは、「C」（過去のクラスに対処することは関係ありません）と均等に指定されています（[RFC2330] [RFC8468]）。このようなクラスの知識により、そのクラス内のタイプのパケットのいずれかが、ルートのその後の測定に使用されることができます。指定子「クラスC」は、歴史的な理由で使用されます。[RFC2330]を参照してください。
The formal name of the metric is:
メトリックの正式な名前は次のとおりです。
Type-P-Route-Ensemble-Method-Variant
Type-P-Route-Ensemble-Method-Variant
abbreviated as Route Ensemble.
ルートアンサンブルとして略されました。
Note that Type-P depends heavily on the chosen method and variant.
Type-Pは、選択した方法とバリアントに大きく依存していることに注意してください。
This section lists the REQUIRED input factors to define and measure a Route metric, as specified in this memo.
このセクションには、このメモで指定されているように、ルートメトリックを定義および測定するために必要な入力係数をリストします。
Src: the address of a Node (such as the globally routable IP address).
SRC：ノードのアドレス（グローバルにルーティング可能なIPアドレスなど）。
Dst: the address of a Node (such as the globally routable IP address).
DST：ノードのアドレス（グローバルにルーティング可能なIPアドレスなど）。
i: the limit on the number of Hops a specific packet may visit as it traverses from the Node at Src to the Node at Dst (such as the TTL or Hop Limit).
I：特定のパケットがSRCのノードからDSTのノードまで通過するときに、特定のパケットが訪れる可能性があるホップ数の制限（TTLやホップ制限など）。
MaxHops: the maximum value of i used (i=1,2,3,...MaxHops).
maxhops：私の最大値（i = 1,2,3、... maxhops）。
T0: a time (start of measurement interval).
T0：時間（測定間隔の開始）。
Tf: a time (end of measurement interval).
TF：時間（測定間隔の終わり）。
MP(address): the Measurement Point at address, such as Src or Dst, usually at the same Node stack layer as "address".
MP（アドレス）：通常、「アドレス」と同じノードスタックレイヤーで、SRCやDSTなどのアドレスの測定ポイント。
T: the Node time of a packet as measured at MP(Src), meaning Measurement Point at the Source.
T：MP（SRC）で測定されたパケットのノード時間、ソースの測定点を意味します。
Ta: the Node time of a reply packet's *arrival* as measured at MP(Src), assigned to packets that arrive within a "reasonable" time (see parameter below).
TA：MP（SRC）で測定された返信パケットの *到着 *のノード時間は、「合理的な」時間内に到着するパケットに割り当てられています（以下のパラメーターを参照）。
Tmax: a maximum waiting time for reply packets to return to the source, set sufficiently long to disambiguate packets with long delays from packets that are discarded (lost), such that the distribution of Round-Trip Delay is not truncated.
TMAX：返信パケットがソースに戻るのに最大待つ時間は、往復遅延の分布が切り捨てられないように、破棄された（失われた）パケットからの長い遅延でパケットを明確にするのに十分な長さを設定します。
F: the number of different flows simulated by the method and variant.
F：メソッドとバリアントによってシミュレートされた異なるフローの数。
flow: the stream of packets with the same n-tuple of designated header fields that (when held constant) result in identical treatment in a multipath decision (such as the decision taken in load balancing). Note: The IPv6 flow label MAY be included in the flow definition if the MP(Src) is a Tunnel Endpoint (TEP) complying with the guidelines in [RFC6438].
フロー：指定されたヘッダーフィールドの同じn-tupleを備えたパケットのストリーム（一定になった場合）は、マルチパス決定（負荷分散で行われる決定など）で同一の処理をもたらします。注：MP（SRC）が[RFC6438]のガイドラインに準拠したトンネルエンドポイント（TEP）である場合、IPv6フローラベルはフロー定義に含まれる場合があります。
Type-P: the complete description of the packets for which this assessment applies (including the flow-defining fields).
タイプ-P：この評価が適用されるパケットの完全な説明（フロー定義フィールドを含む）。
This section defines the REQUIRED measurement components of the Route metrics (unless otherwise indicated):
このセクションでは、ルートメトリックの必要な測定コンポーネントを定義します（特に明記しない限り）。
M: the total number of packets sent between T0 and Tf.
M：T0とTFの間に送信されるパケットの総数。
N: the smallest value of i needed for a packet to be received at Dst (sent between T0 and Tf).
N：パケットをDSTで受信するのに必要な最小値（T0とTFの間で送信）。
Nmax: the largest value of i needed for a packet to be received at Dst (sent between T0 and Tf). Nmax may be equal to N.
NMAX：パケットをDSTで受信するために必要な最大の値（T0とTFの間で送信）。nmaxはnに等しい場合があります。
Next, define a *singleton* for a Node on the path with sufficient indexes to identify all Nodes identified in a measurement interval (where *singleton* is part of the IPPM Framework [RFC2330]).
次に、測定間隔で識別されたすべてのノードを識別するのに十分なインデックスを持つパス上のノードのA * Singleton *を定義します（ * Singleton *はIPPMフレームワークの一部[RFC2330]）。
singleton: A Hop specification, designated h(i,j), the IP address and/or identity of Discoverable Nodes (or Cooperating Nodes) that are i Hops away from the Node with address = Src and part of Route j during the measurement interval T0 to Tf. As defined here, a Hop singleton measurement MUST contain a Node identity, hid(i,j), and MAY contain one or more of the following attributes:
Singleton：HOP仕様、指定H（I、J）、IPアドレス、および/または発見可能なノード（または協力ノード）のIDは、測定間隔中のアドレス= SRCとルートJの一部を備えたノードから離れてホップします。T0からTF。ここで定義されているように、ホップシングルトン測定にはノードID、HID（i、j）が含まれている必要があり、次の属性の1つ以上が含まれている場合があります。
* a(i,j) Arrival Interface ID (e.g., when [RFC5837] is supported)
* a（i、j）到着インターフェイスID（たとえば、[rfc5837]がサポートされている場合）
* d(i,j) Departure Interface ID (e.g., when [RFC5837] is supported)
* d（i、j）出発インターフェイスID（たとえば、[rfc5837]がサポートされている場合）
* t(i,j) arrival timestamp, where t(i,j) is ideally supplied by the Hop (note that t(i,j) might be approximated from the sending time of the packet that revealed the Hop, e.g., when the round-trip response time is available and divided by 2)
* t（i、j）到着タイムスタンプ。ここで、t（i、j）はホップによって理想的に提供されます（t（i、j）は、ホップを明らかにしたパケットの送信時間から近似する可能性があることに注意してください。たとえば、たとえば、往復応答時間が利用可能で、2）
* Measurements of Round-Trip Delay (for each packet that reveals the same Node identity and flow attributes, then this attribute is computed; see next section)
* 往復遅延の測定（同じノードのIDとフロー属性を明らかにするパケットごとに、この属性は計算されます。次のセクションを参照）
Node identities and related information can be ordered by their distance from the Node with address Src in Hops h(i,j). Based on this, two forms of Routes are distinguished:
ノードのアイデンティティと関連情報は、ホップH（i、j）のアドレスSRCを使用して、ノードからの距離によって注文できます。これに基づいて、2つの形式のルートが区別されます。
A Route Ensemble is defined as the combination of all Routes traversed by different flows from the Node at Src address to the Node at Dst address. A single Route traversed by a single flow (determined by an unambiguous tuple of addresses Src and Dst and other identical flow criteria) is a member of the Route Ensemble and called a Member Route.
ルートアンサンブルは、SRCアドレスのノードからDSTアドレスのノードまでの異なるフローによって横断されるすべてのルートの組み合わせとして定義されます。単一のフローによって横断される単一のルート（アドレスSRCおよびDSTおよびその他の同一のフロー基準の明確なタプルによって決定）は、ルートアンサンブルのメンバーであり、メンバールートと呼ばれます。
Using h(i,j) and components and parameters further define:
h（i、j）とコンポーネントとパラメーターを使用すると、さらに定義します。
When considering the set of Hops in the context of a single flow, a Member Route j is an ordered list {h(1,j), ... h(Nj, j)} where h(i-1, j) and h(i, j) are one Hop away from each other and Nj satisfying h(Nj,j)=Dst is the minimum count of Hops needed by the packet on member Route j to reach Dst. Member Routes must be unique. The uniqueness property requires that any two Member Routes, j and k, that are part of the same Route Ensemble differ either in terms of minimum Hop count Nj and Nk to reach the destination Dst or, in the case of identical Hop count Nj=Nk, they have at least one distinct Hop: h(i,j) != h(i,k) for at least one i (i=1..Nj).
単一のフローのコンテキストでホップのセットを考慮するとき、メンバールートjは順序付きリスト{h（1、j）、... h（nj、j）}ここで、h（i-1、j）とh（i、j）は互いに1つのホップ離れており、NJを満たすNJ（nj、j）= dstは、DSTに到達するためにメンバールートJのパケットが必要とするホップの最小カウントです。メンバールートは一意でなければなりません。一意性プロパティでは、同じルートアンサンブルの一部である2つのメンバールートJとKが、宛先DSTに到達するために最小ホップカウントNJとNKのいずれかで、または同一のホップカウントNJ = NKの場合に異なることが必要です。、彼らは少なくとも1つの異なるホップを持っています：h（i、j）！= h（i、k）少なくとも1つのi（i = 1..nj）。
All the optional information collected to describe a Member Route, such as the arrival interface, departure interface, and Round-Trip Delay at each Hop, turns each list item into a rich structure. There may be information on the links between Hops, possible information on the routing (arrival interface and departure interface), an estimate of distance between Hops based on Round-Trip Delay measurements and calculations, and a timestamp indicating when all these additional details were measured.
各ホップでの到着インターフェイス、出発インターフェイス、各ホップでの往復遅延など、メンバールートを記述するために収集されたすべてのオプション情報は、各リスト項目を豊富な構造に変えます。ホップ間のリンク、ルーティングに関する可能な情報（到着インターフェイスと出発インターフェイス）、ラウンドトリップ遅延測定と計算に基づくホップ間の距離の推定値、およびこれらすべての追加の詳細が測定された時期を示すタイムスタンプに関する情報がある場合があります。。
The Route Ensemble from Src to Dst, during the measurement interval T0 to Tf, is the aggregate of all m distinct Member Routes discovered between the two Nodes with Src and Dst addresses. More formally, with the Node having address Src omitted:
SRCからDSTへのルートアンサンブルは、測定間隔T0からTFへのアンサンブルであり、SRCとDSTアドレスを持つ2つのノード間で発見されたすべてのM異なるメンバールートの集合体です。より正式には、ノードにアドレスSRCが省略されているため：
Route Ensemble = {
{h(1,1), h(2,1), h(3,1), ... h(N1,1)=Dst},
{h(1,2), h(2,2), h(3,2),..., h(N2,2)=Dst},
...
{h(1,m), h(2,m), h(3,m), ....h(Nm,m)=Dst}
}
where the following conditions apply: i <= Nj <= Nmax (j=1..m)
Note that some h(i,j) may be empty (null) in the case that systems do not reply (not discoverable or not cooperating).
システムが応答しない場合（発見できないか協力していない）場合、一部のH（I、J）は空（null）である可能性があることに注意してください。
h(i-1,j) and h(i,j) are the Hops on the same Member Route one Hop away from each other.
h（i-1、j）とh（i、j）は、同じメンバールートのホップであり、互いに1つ離れたホップです。
Hop h(i,j) may be identical with h(k,l) for i!=k and j!=l, which means there may be portions shared among different Member Routes (parts of Member Routes may overlap).
ホップh（i、j）は、i！= kおよびj！= lのh（k、l）と同一である可能性があります。つまり、異なるメンバールート間で共有される部分がある場合があります（メンバールートの一部が重複する場合があります）。
RTD(i,j,T) is defined as a singleton of the [RFC2681] Round-Trip Delay between the Node with address = Src and the Node at Hop h(i,j) at time T.
RTD（i、j、t）は、[RFC2681]の[RFC2681]のラウンドトリップ遅延のシングルトンとして定義されます。
RTL(i,j,T) is defined as a singleton of the [RFC6673] Round-Trip Loss between the Node with address = Src and the Node at Hop h(i,j) at time T.
RTL（i、j、t）は、[RFC6673]のシングルトンとして定義されています。Address= SRCとHOP H（I、J）のノードとのノード間の往復損失時間T。
Depending on the way that the Node identity is revealed, it may be difficult to determine parallel subpaths between the same pair of Nodes (i.e., multiple parallel links). It is easier to detect parallel subpaths involving different Nodes.
ノードのアイデンティティが明らかになる方法に応じて、同じノードのペア間の並列サブパス（つまり、複数の並列リンク）を決定することは困難な場合があります。異なるノードを含む並列サブパスを検出する方が簡単です。
* If a pair of discovered Nodes identify two different addresses (IP or not), then they will appear to be different Nodes. See item below.
* 発見されたノードのペアが2つの異なるアドレス（IPかどうか）を識別した場合、それらは異なるノードのように見えます。以下のアイテムを参照してください。
* If a pair of discovered Nodes identify two different IP addresses and the IP addresses resolve to the same Node name (in the DNS), then they will appear to be the same Node.
* 発見されたノードのペアが2つの異なるIPアドレスを識別し、IPアドレスが同じノード名（DNS）に解決すると、それらは同じノードのように見えます。
* If a discovered Node always replies using the same network address, regardless of the interface a packet arrives on, then multiple parallel links cannot be detected in that network domain. This condition may apply to traceroute-style methods but may not apply to other hybrid methods based on In situ Operations, Administration, and Maintenance (IOAM). For example, if the ICMP extension mechanism described in [RFC5837] is implemented, then parallel links can be detected with the discovery traceroute-style methods.
* 発見されたノードが常に同じネットワークアドレスを使用して回答した場合、パケットが到着するインターフェイスに関係なく、そのネットワークドメインで複数の並列リンクを検出できません。この条件は、Tracerouteスタイルの方法に適用される場合がありますが、In situ操作、管理、およびメンテナンス（IOAM）に基づいた他のハイブリッド方法には適用されない場合があります。たとえば、[RFC5837]で説明されているICMP拡張メカニズムが実装されている場合、ディスカバリートレーサースタイルの方法で並列リンクを検出できます。
* If parallel links between routers are aggregated below the IP layer, then, from the Node's point of view, all these links share the same pair of IP addresses. The existence of these parallel links can't be detected at the IP layer. This applies to other network domains with layers below them as well. This condition may apply to traceroute-style methods but may not apply to other hybrid methods based on IOAM.
* ルーター間の平行リンクがIPレイヤーの下に集約されている場合、ノードの観点から、これらのリンクはすべて同じペアのIPアドレスを共有します。これらの平行リンクの存在は、IPレイヤーでは検出できません。これは、レイヤーの下にある他のネットワークドメインにも適用されます。この条件は、Tracerouteスタイルの方法に適用される場合がありますが、IOAMに基づいた他のハイブリッドメソッドには適用されない場合があります。
When a Route assessment employs IP packets (for example), the reality of flow assignment to parallel subpaths involves layers above IP. Thus, the measured Route Ensemble is applicable to IP and higher layers (as described in the methodology's packet of Type-P and flow parameters).
ルート評価がIPパケットを使用する場合（たとえば）、並列サブパスへのフロー割り当ての現実には、IPの上のレイヤーが含まれます。したがって、測定されたルートアンサンブルは、IPおよび高層に適用できます（方法論のタイプPおよびフローパラメーターのパケットで説明されています）。
An Information Model and an XML Data Model for Storing Traceroute Measurements is available in [RFC5388]. The measured information at each Hop includes four pieces of information: a one-dimensional Hop index, Node symbolic address, Node IP address, and RTD for each response.
Traceroute測定を保存するための情報モデルとXMLデータモデルは、[RFC5388]で利用できます。各ホップで測定された情報には、1次元ホップインデックス、ノードシンボリックアドレス、ノードIPアドレス、および各応答のRTDの4つの情報が含まれています。
The description of Hop information that may be collected according to this memo covers more dimensions, as defined in Section 3.4. For example, the Hop index is two-dimensional to capture the complexity of a Route Ensemble, and it contains corresponding Node identities at a minimum. The models need to be expanded to include these features as well as Arrival Interface ID, Departure Interface ID, and arrival timestamp, when available. The original sending Timestamp from the Src Node anchors a particular measurement in time.
このメモに従って収集される可能性のあるホップ情報の説明は、セクション3.4で定義されているように、より多くの寸法をカバーしています。たとえば、ホップインデックスはルートアンサンブルの複雑さをキャプチャするために2次元であり、最低限の対応するノードのアイデンティティが含まれています。モデルを拡張して、これらの機能、到着インターフェイスID、出発インターフェイスID、および到着タイムスタンプを含む必要があります。SRCノードからの元の送信タイムスタンプは、時間内に特定の測定値を固定します。
There are two classes of methods described in this section, active methods relying on the reaction to TTL or Hop Limit Exceeded condition to discover Nodes on a path and hybrid active-passive methods that involve direct interrogation of Cooperating Nodes (usually within a single domain). Description of these methods follow.
このセクションで説明されている2つのクラスのメソッドがあります。TTLまたはホップ制限を超えた条件を超えた条件を超えたアクティブな方法は、パス上のノードを発見し、協力ノードの直接尋問（通常は単一のドメイン内）を伴うハイブリッドアクティブパッシブメソッドを発見します。。これらの方法の説明は次のとおりです。
This section describes the method employed by current open-source tools, thereby providing a practical framework for further advanced techniques to be included as method variants. This method is applicable for use across multiple administrative domains.
このセクションでは、現在のオープンソースツールで採用されている方法について説明し、それにより、メソッドバリアントとしてさらに高度な技術を含めるための実用的なフレームワークを提供します。この方法は、複数の管理ドメインでの使用に適用できます。
Internet routing is complex because it depends on the policies of thousands of Autonomous Systems (ASes). Most routers perform load balancing on flows using a form of ECMP. [RFC2991] describes a number of flow-based or hashed approaches (e.g., Modulo-N Hash, Hash-Threshold, and Highest Random Weight (HRW)) and makes some good suggestions. Flow-based ECMP avoids increased packet Delay Variation and possibly overwhelming levels of packet reordering in flows.
インターネットルーティングは、数千の自律システム（ASE）のポリシーに依存するため、複雑です。ほとんどのルーターは、ECMPの形式を使用してフローで負荷分散を実行します。[RFC2991]は、多くのフローベースまたはハッシュされたアプローチ（例：modulo-n hash、hash-whold、および最高のランダム重量（HRW））を説明し、いくつかの良い提案をします。フローベースのECMPは、パケット遅延の変動の増加を回避し、フローでのパケットの並べ替えの圧倒的なレベルを回避します。
A few routers still divide the workload through packet-based techniques, such as a round-robin scheme to distribute every new outgoing packet to multiple links, as explained in [RFC2991]. The methods described in this section assume flow-based ECMP.
いくつかのルーターは、[RFC2991]で説明されているように、すべての新しい発信パケットを複数のリンクに分配するラウンドロビンスキームなど、パケットベースの手法を通してワークロードを分割します。このセクションで説明する方法は、フローベースのECMPを想定しています。
Taking into account that Internet protocol was designed under the "end-to-end" principle, the IP payload and its header do not provide any information about the Routes or path necessary to reach some destination. For this reason, the popular tool, traceroute, was developed to gather the IP addresses of each Hop along a path using ICMP [RFC0792]. Traceroute also measures RTD from each Hop. However, the growing complexity of the Internet makes it more challenging to develop an accurate traceroute implementation. For instance, the early traceroute tools would be inaccurate in the current network, mainly because they were not designed to retain a flow state. However, evolved traceroute tools, such as Paris-traceroute ([PT] [MLB]) and Scamper ([SCAMPER]), expect to encounter ECMP and achieve more accurate results when they do, where Scamper ensures traceroute packets will follow the same path in 98% of cases ([SCAMPER]).
インターネットプロトコルが「エンドツーエンド」の原則の下で設計されていることを考慮して、IPペイロードとそのヘッダーは、宛先に到達するために必要なルートまたはパスに関する情報を提供しません。このため、人気のあるツールであるTracerouteは、ICMP [RFC0792]を使用してパスに沿って各ホップのIPアドレスを収集するために開発されました。Tracerouteは、各ホップからRTDも測定します。ただし、インターネットの複雑さの高まりにより、正確なTracerouteの実装を開発することがより困難になります。たとえば、初期のトレーサーツールは、主にフロー状態を保持するように設計されていないため、現在のネットワークでは不正確です。ただし、パリトレーサーアウト（[PT] [MLB]）やScamper（[scamper]）などの進化したトレーサーツールは、ECMPに遭遇し、より正確な結果を達成することを期待しています。症例の98％（[scamper]）。
Today's traceroute tools send Type-P of packets, which are either ICMP, UDP, or TCP. UDP and TCP are used when a particular characteristic needs to be verified, such as filtering or traffic shaping on specific ports (i.e., services). UDP and TCP traceroute are also used when ICMP responses are not received. [SCAMPER] supports IPv6 traceroute measurements, keeping the Flow Label constant in all packets.
今日のTracerouteツールは、ICMP、UDP、またはTCPのいずれかであるタイプPのパケットを送信します。UDPとTCPは、特定のポート（すなわち、サービス）でのフィルタリングやトラフィックの形成など、特定の特性を検証する必要がある場合に使用されます。ICMP応答が受信されない場合、UDPおよびTCP Tracerouteも使用されます。[Scamper]は、IPv6 Traceroute測定をサポートし、すべてのパケットでフローラベルを一定に保ちます。
Paris-traceroute allows its users to measure the RTD to every Node of the path for a particular flow. Furthermore, either Paris-traceroute or Scamper is capable of unveiling the many available paths between a source and destination (which are visible to active methods). This task is accomplished by repeating complete traceroute measurements with different flow parameters for each measurement; Paris-traceroute provides an "exhaustive" mode, while Scamper provides "tracelb" (which stands for "traceroute load balance"). "Framework for IP Performance Metrics" [RFC2330], updated by [RFC7312], has the flexibility to require that the Round-Trip Delay measurement [RFC2681] uses packets with the constraints to assure that all packets in a single measurement appear as the same flow. This flexibility covers ICMP, UDP, and TCP. The accompanying methodology of [RFC2681] needs to be expanded to report the sequential Hop identifiers along with RTD measurements, but no new metric definition is needed.
Paris-Tracerouteを使用すると、ユーザーは特定のフローのパスのすべてのノードにRTDを測定できます。さらに、Paris-TracerouteまたはScamperのいずれかは、ソースと宛先の間に多くの利用可能なパスを発表することができます（アクティブな方法に表示されます）。このタスクは、測定ごとに異なるフローパラメーターを使用して、完全なトレーサーアウト測定を繰り返すことによって達成されます。Paris-Tracerouteは「網羅的な」モードを提供し、Scamperは「Tracelb」（「Traceroute Load Balance」を表す）を提供します。[RFC7312]によって更新された「IPパフォーマンスメトリックのフレームワーク」[RFC2330]は、往復遅延測定[RFC2681]が制約を持つパケットを使用して、単一の測定のすべてのパケットが同じように表示されることを保証することを要求する柔軟性があります。フロー。この柔軟性は、ICMP、UDP、およびTCPをカバーしています。[RFC2681]の付随する方法論は、RTD測定とともにシーケンシャルホップ識別子を報告するために拡張する必要がありますが、新しいメトリック定義は必要ありません。
The advanced Route assessment methods used in Paris-traceroute [PT] keep the critical fields constant for every packet to maintain the appearance of the same flow. When considering IPv6 headers, it is necessary to ensure that the IP Source and Destination addresses and Flow Label are constant (but note that many routers ignore the Flow Label field at this time); see [RFC6437]. Use of IPv6 Extension Headers may add critical fields and SHOULD be avoided. In IPv4, certain fields of the IP header and the first 4 bytes of the IP payload should remain constant in a flow. In the IPv4 header, the IP Source and Destination addresses, protocol number, and Diffserv fields identify flows. The first 4 payload bytes include the UDP and TCP ports and the ICMP type, code, and checksum fields.
Paris-Traceroute [PT]で使用される高度なルート評価方法は、すべてのパケットの臨界フィールドを一定に保ち、同じフローの外観を維持します。IPv6ヘッダーを検討する場合、IPソースと宛先アドレスとフローラベルが一定であることを確認する必要があります（ただし、多くのルーターは現時点ではフローラベルフィールドを無視していることに注意してください）。[RFC6437]を参照してください。IPv6拡張ヘッダーの使用は、重要なフィールドを追加する場合があり、避ける必要があります。IPv4では、IPヘッダーの特定のフィールドとIPペイロードの最初の4バイトは、フローで一定のままである必要があります。IPv4ヘッダーでは、IPソースと宛先アドレス、プロトコル番号、およびDiffServフィールドがフローを識別します。最初の4つのペイロードバイトには、UDPポートとTCPポートとICMPタイプ、コード、およびチェックサムフィールドが含まれます。
Maintaining a constant ICMP checksum in IPv4 is most challenging, as the ICMP sequence number or identifier fields will usually change for different probes of the same path. Probes should use arbitrary bytes in the ICMP data field to offset changes to the sequence number and identifier, thus keeping the checksum constant.
IPv4で一定のICMPチェックサムを維持することは最も困難です。ICMPシーケンス番号または識別子フィールドは通常、同じパスの異なるプローブに対して変更されるためです。プローブは、ICMPデータフィールドの任意のバイトを使用して、シーケンス番号と識別子の変更を相殺して、チェックサムを一定に保つ必要があります。
Finally, it is also essential to Route the resulting ICMP Time Exceeded messages along a consistent path. In IPv6, the fields above are sufficient. In IPv4, the ICMP Time Exceeded message will contain the IP header and the first 8 bytes of the IP payload, both of which affect its ICMP checksum calculation. The TCP sequence number, UDP length, and UDP checksum will affect this value and should remain constant.
最後に、結果のICMP時間を超えたメッセージを一貫したパスに沿ってルーティングすることも不可欠です。IPv6では、上記のフィールドで十分です。IPv4では、ICMP時間を超えたメッセージにはIPヘッダーとIPペイロードの最初の8バイトが含まれ、どちらもICMPチェックサムの計算に影響します。TCPシーケンス番号、UDP長、およびUDPチェックサムは、この値に影響を及ぼし、一定のままである必要があります。
Formally, to maintain the same flow in the measurements to a particular Hop, the Type-P-Route-Ensemble-Method-Variant packets should have the following attributes (see [PT]):
正式には、特定のホップへの測定値の同じフローを維持するために、タイプPルート - ensemble-method-variantパケットには次の属性が必要です（[PT]を参照）：
TCP case: For IPv4, the fields Src, Dst, port-Src, port_Dst, sequence number, and Diffserv SHOULD be the same. For IPv6, the fields Flow Label, Src, and Dst SHOULD be the same.
TCPケース：IPv4の場合、Fields SRC、DST、PORT-SRC、PORT_DST、シーケンス番号、およびDiffServは同じでなければなりません。IPv6の場合、フィールドフローラベル、SRC、およびDSTは同じでなければなりません。
UDP case: For IPv4, the fields Src, Dst, port-Src, port-Dst, and Diffserv should be the same, and the UDP checksum SHOULD change to keep the IP checksum of the ICMP Time Exceeded reply constant. Then, the data length should be fixed, and the data field is used to make it so (consider that ICMP checksum uses its data field, which contains the original IP header plus 8 bytes of UDP, where TTL, IP identification, IP checksum, and UDP checksum changes). For IPv6, the field Flow Label and Source and Destination addresses SHOULD be the same.
UDPケース：IPv4の場合、Fields SRC、DST、Port-SRC、Port-DST、およびDiffServは同じである必要があり、UDPチェックサムはICMP時間のIPチェックサムを維持するために変更する必要があります。次に、データの長さを固定する必要があり、データフィールドを使用してそのようにします（ICMPチェックサムは、元のIPヘッダーと8バイトのUDPを含むデータフィールドを使用していると考えてください。およびUDPチェックサムの変更）。IPv6の場合、フィールドフローラベルとソースおよび宛先アドレスは同じでなければなりません。
ICMP case: For IPv4, the data field SHOULD compensate variations on TTL or Hop Limit, IP identification, and IP checksum for every packet. There is no need to consider ICMPv6 because only Flow Label of IPv6 and Source and Destination addresses are used, and all of them SHOULD be constant.
ICMPケース：IPv4の場合、データフィールドは、すべてのパケットのTTLまたはホップ制限、IP識別、およびIPチェックサムのバリエーションを補正する必要があります。IPv6とソースアドレスと宛先アドレスのフローラベルのみが使用され、それらはすべて一定であるため、ICMPV6を考慮する必要はありません。
Then, the way to identify different Hops and attempts of the same IPv4 flow is:
次に、同じIPv4フローの異なるホップと試行を識別する方法は次のとおりです。
TCP case: The IP identification field.
TCPケース：IP識別フィールド。
UDP case: The IP identification field.
UDPケース：IP識別フィールド。
ICMP case: The IP identification field and ICMP sequence number.
ICMPケース：IP識別フィールドとICMPシーケンス番号。
The active Route assessment methods described above have the ability to discover portions of a path where ECMP load balancing is present, observed as two or more unique Member Routes having one or more distinct Hops that are part of the Route Ensemble. Likewise, attempts to deliberately vary the flow characteristics to discover all Member Routes will reveal portions of the path that are flow invariant.
上記のアクティブルート評価方法には、ECMP負荷分散が存在するパスの部分を発見する機能があり、ルートアンサンブルの一部である1つ以上の異なるホップを持つ2つ以上のユニークなメンバールートとして観察されます。同様に、フロー特性を意図的に変化させようとすると、すべてのメンバールートを発見すると、流れの不変のパスの一部が明らかになります。
Section 9.2 of [RFC2330] describes the Temporal Composition of metrics and introduces the possibility of a relationship between earlier measurement results and the results for measurement at the current time (for a given metric). There is value in establishing a Temporal Composition relationship for Route metrics; however, this relationship does not represent a forecast of future Route conditions in any way.
[RFC2330]のセクション9.2は、メトリックの時間的組成について説明し、以前の測定結果と現在の測定の結果との関係の可能性を導入します（特定のメトリックについて）。ルートメトリックの時間的構成関係を確立することには価値があります。ただし、この関係は、将来のルート条件の予測を決して表していません。
For Route-metric measurements, the value of Temporal Composition is to reduce the measurement iterations required with repeated measurements. Reduced iterations are possible by inferring that current measurements using fixed and previously measured flow characteristics:
ルートメトリック測定の場合、時間組成の値は、繰り返し測定で必要な測定反復を減らすことです。固定および以前に測定されたフロー特性を使用して現在の測定値を推測することにより、還元された反復が可能です。
* will have many common Hops with previous measurements.
* 以前の測定で多くの共通ホップがあります。
* will have relatively time-stable results at the ingress and egress portions of the path when measured from user locations, as opposed to measurements of backbone networks and across inter-domain gateways.
* バックボーンネットワークの測定とドメイン間ゲートウェイ全体で、ユーザーの場所から測定された場合、パスの侵入と出口の部分で比較的時間安定の結果が得られます。
* may have greater potential for time variation in path portions where ECMP load balancing is observed (because increasing or decreasing the pool of links changes the hash calculations).
* ECMP負荷分散が観察されるパス部分の時間変動の可能性が高い場合があります（リンクのプールを増やすか減少させるため、ハッシュ計算が変化します）。
Optionally, measurement systems may take advantage of the inferences above when seeking to reduce measurement iterations after exhaustive measurements indicate that the time-stable properties are present. Repetitive active Route measurement systems:
オプションで、測定システムは、徹底的な測定が時間安定の特性が存在することを示した後、測定の反復を減らすことを求める際に上記の推論を利用する場合があります。繰り返しアクティブルート測定システム：
1. SHOULD occasionally check path portions that have exhibited stable results over time, particularly ingress and egress portions of the path (e.g., daily checks if measuring many times during a day).
1. 時間の経過とともに安定した結果を示したパス部分、特にパスの侵入と出口の部分を時々チェックする必要があります（たとえば、日中に何度も測定するかどうかを毎日チェックします）。
2. SHOULD continue testing portions of the path that have previously exhibited ECMP load balancing.
2. 以前にECMP負荷分散を示したパスの一部のテストを続ける必要があります。
3. SHALL trigger reassessment of the complete path and Route Ensemble if any change in Hops is observed for a specific (and previously tested) flow.
3. 特定の（および以前にテストされた）フローでホップの変更が観察される場合、完全なパスとルーチのアンサンブルの再評価をトリガーします。
There is an opportunity to apply the notion from [RFC2330] of equal treatment for a class of packets, "...very useful to know if a given Internet component treats equally a class C of different types of packets", as it applies to Route measurements. The notion of class C was examined further in [RFC8468] as it applied to load-balancing flows over parallel paths, which is the case we develop here. Knowledge of class C parameters (unrelated to address classes of the past) on a path potentially reduces the number of flows required for a given method to assess a Route Ensemble over time.
[RFC2330]の概念をパケットのクラスの平等な処理の概念を適用する機会があります。ルート測定。クラスCの概念は、[RFC8468]でさらに調査されました。これは、並列パス上の負荷分散フローに適用されました。これは、ここで開発された場合です。パス上のクラスCパラメーターの知識（過去のクラスに対処することは関係ありません）は、特定の方法に必要なフローの数を潜在的に減らし、時間の経過とともにルートアンサンブルを評価します。
First, recognize that each Member Route of a Route Ensemble will have a corresponding class C. Class C can be discovered by testing with multiple flows, all of which traverse the unique set of Hops that comprise a specific Member Route.
まず、ルートアンサンブルの各メンバールートには対応するクラスCがあることを認識します。クラスCは、複数のフローでテストすることで発見できます。これらはすべて、特定のメンバールートを構成する一意のホップセットを横断します。
Second, recognize that the different classes depend primarily on the hash functions used at each instance of ECMP load balancing on the path.
第二に、異なるクラスは、パス上のECMPロードバランスの各インスタンスで使用されるハッシュ関数に主に依存していることを認識してください。
Third, recognize the synergy with Temporal Composition methods (described above), where evaluation intends to discover time-stable portions of each Member Route so that more emphasis can be placed on ECMP portions that also determine class C.
第三に、評価が各メンバールートの時間安定の部分を発見し、クラスCも決定するECMP部分をより重視できるようにすることを目的とした時間的構成方法（上記）との相乗効果を認識します。
The methods to assess the various class C characteristics benefit from the following measurement capabilities:
さまざまなクラスCの特性を評価する方法は、次の測定機能の恩恵を受けます。
* flows designed to determine which n-tuple header fields are considered by a given hash function and ECMP Hop on the path and which are not. This operation immediately narrows the search space, where possible, and partially defines a class C.
* どのN-Tupleヘッダーフィールドが特定のハッシュ関数によって考慮され、ECMPホップがパスでホップしていないかを決定するために設計されたフロー。この操作は、可能であれば検索スペースをすぐに狭め、クラスCを部分的に定義します。
* a priori knowledge of the possible types of hash functions in use also helps to design the flows for testing (major router vendors publish information about these hash functions; examples are in [LOAD_BALANCE]).
* 使用中の可能なタイプのハッシュ関数に関するアプリオリの知識は、テストのためのフローを設計するのにも役立ちます（主要なルーターベンダーは、これらのハッシュ関数に関する情報を公開します。例は[load_balance]にあります）。
* ability to direct the emphasis of current measurements on ECMP portions of the path, based on recent past measurement results (the Routing Class of some portions of the path is essentially "all packets").
* 最近の過去の測定結果に基づいて、パスのECMP部分に現在の測定値の重点を向ける能力（パスの一部のルーティングクラスは、本質的に「すべてのパケット」です）。
There are many examples where passive monitoring of a flow at an Observation Point within the network can detect unexpected Round-Trip Delay or Delay Variation. But how can the cause of the anomalous delay be investigated further *from the Observation Point* possibly located at an intermediate point on the path?
ネットワーク内の観測点での流れのパッシブモニタリングが、予期しない往復遅延または遅延の変動を検出できる多くの例があります。しかし、異常な遅延の原因を、おそらくパスの中間点にある観測点 *からさらに調査することができますか？
In this case, knowledge that the flow of interest belongs to a specific Routing Class C will enable measurement of the Route where anomalous delay has been observed. Specifically, Round-Trip Delay assessment to each Hop on the path between the Observation Point and the Destination for the flow of interest may discover high or variable delay on a specific link and Hop combination.
この場合、対象の流れが特定のルーティングクラスCに属するという知識は、異常な遅延が観察されているルートの測定を可能にします。具体的には、観測点と目的地の間のパス上の各ホップへの往復遅延評価は、特定のリンクとホップの組み合わせで高いまたは可変遅延を発見する場合があります。
The determination of a Routing Class C that includes the flow of interest is as described in the section above, aided by computation of the relevant hash function output as the target.
対象の流れを含むルーティングクラスCの決定は、ターゲットとして関連するハッシュ関数出力の計算によって支援された上記のセクションで説明されています。
The Hybrid Type I methods provide an alternative for Route assessment. The "Scope, Applicability, and Assumptions" section of [RFC9197] provides one possible set of data fields that would support Route identification.
ハイブリッドタイプIメソッドは、ルート評価の代替品を提供します。[RFC9197]の「スコープ、適用可能性、および仮定」セクションは、ルート識別をサポートするデータフィールドの可能なセットを1つ提供します。
In general, Nodes in the measured domain would be equipped with specific abilities:
一般に、測定されたドメインのノードには、特定の能力が装備されます。
* Store the identity of Nodes that a packet has visited in header data fields in the order the packet visited the Nodes.
* パケットがノードにアクセスした順に、パケットがヘッダーデータフィールドにアクセスしたノードのIDを保存します。
* Support of a "Loopback" capability where a copy of the packet is returned to the encapsulating Node and the packet is processed like any other IOAM packet on the return transfer.
* パケットのコピーがカプセル化ノードに返され、パケットが返品転送時に他のIOAMパケットと同様に処理される「ループバック」機能のサポート。
In addition to Node identity, Nodes may also identify the ingress and egress interfaces utilized by the tracing packet, the absolute time when the packet was processed, and other generic data (as described in Section 3 of [RFC9197]). Interface identification isn't necessarily limited to IP, i.e., different links in a bundle (Link Aggregation Control Protocol (LACP)) could be identified. Equally well, links without explicit IP addresses can be identified (like with unnumbered interfaces in an IGP deployment).
ノードのアイデンティティに加えて、ノードは、トレースパケット、パケットが処理された絶対時間、および他の汎用データ（[RFC9197]のセクション3で説明されているように）によって使用されるイングレスおよび出力インターフェイスを識別することもできます。インターフェイス識別は必ずしもIPに限定されていません。つまり、バンドル内の異なるリンク（リンク集約制御プロトコル（LACP））を識別できます。同様に、明示的なIPアドレスのないリンクを識別できます（IGP展開内の非仮定されたインターフェイスなど）。
Note that the Type-P packet specification for this method will likely be a partial specification because most of the packet fields are determined by the user traffic. The packet encapsulation header or headers added by the hybrid method can certainly be specified in Type-P, in unpopulated form.
ほとんどのパケットフィールドはユーザートラフィックによって決定されるため、このメソッドのType-Pパケット仕様は部分的な仕様になる可能性が高いことに注意してください。ハイブリッドメソッドによって追加されたパケットカプセル化ヘッダーまたはヘッダーは、確実にタイプ-Pで、操縦されていない形式で指定できます。
In principle, there are advantages if the entity conducting Route measurements can utilize both forms of advanced methods (active and hybrid) and combine the results. For example, if there are Nodes involved in the path that qualify as Cooperating Nodes but not as Discoverable Nodes, then a more complete view of Hops on the path is possible when a hybrid method (or interrogation protocol) is applied and the results are combined with the active method results collected across all other domains.
原則として、ルート測定を実行するエンティティが両方の形式の高度な方法（アクティブとハイブリッド）を利用して結果を組み合わせることができる場合、利点があります。たとえば、協力ノードとして適格であるが発見可能なノードとしてではないパスにノードがある場合、ハイブリッドメソッド（または尋問プロトコル）が適用され、結果が組み合わされている場合、パス上のより完全なビューがパス上のより完全なビューを可能にします。アクティブなメソッド結果が他のすべてのドメインで収集されます。
In order to combine the results of active and hybrid/interrogation methods, the network Nodes that are part of a domain supporting an interrogation protocol have the following attributes:
アクティブ/ハイブリッド/尋問法の結果を組み合わせるために、尋問プロトコルをサポートするドメインの一部であるネットワークノードには、次の属性があります。
1. Nodes at the ingress to the domain SHOULD be both Discoverable and Cooperating.
1. ドメインへのイングレスのノードは、発見可能で協力する必要があります。
2. Any Nodes within the domain that are both Discoverable and Cooperating SHOULD reveal the same Node identity in response to both active and hybrid methods.
2. ドメイン内のノードは、発見可能で協力していることは、アクティブメソッドとハイブリッドメソッドの両方に応じて、同じノードIDを明らかにする必要があります。
3. Nodes at the egress to the domain SHOULD be both Discoverable and Cooperating and SHOULD reveal the same Node identity in response to both active and hybrid methods.
3. ドメインへの出口でのノードは、発見可能で協力することの両方であり、アクティブメソッドとハイブリッドメソッドの両方に応じて同じノードIDを明らかにする必要があります。
When Nodes follow these requirements, it becomes a simple matter to match single-domain measurements with the overlapping results from a multidomain measurement.
ノードがこれらの要件に従うと、単一ドメイン測定値をマルチドメイン測定からの重複結果と一致させることが単純な問題になります。
In practice, Internet users do not typically have the ability to utilize the Operations, Administrations, and Maintenance (OAM) capabilities of networks that their packets traverse, so the results from a remote domain supporting an interrogation protocol would not normally be accessible. However, a network operator could combine interrogation results from their access domain with other measurements revealing the path outside their domain.
実際には、インターネットユーザーは通常、パケットが横断するネットワークの運用、管理、およびメンテナンス（OAM）機能を利用する能力を持っていないため、尋問プロトコルをサポートするリモートドメインの結果は通常アクセスできません。ただし、ネットワークオペレーターは、アクセスドメインからの尋問の結果を、ドメインの外側のパスを明らかにする他の測定値と組み合わせることができます。
The aim of this method is to use packet probes to unveil the paths between any two End-Nodes of the network. Moreover, information derived from RTD measurements might be meaningful to identify:
この方法の目的は、パケットプローブを使用して、ネットワークの任意の2つのエンドノード間のパスを発表することです。さらに、RTD測定から派生した情報は、識別することに意味があるかもしれません。
1. Intercontinental submarine links
1. 大陸間潜水艦リンク
2. Satellite communications
2. 衛星通信
3. Congestion
3. 混雑
4. Inter-domain paths
4. ドメイン間パス
This categorization is widely accepted in the literature and among operators alike, and it can be trusted with empirical data and several sources as ground of truth (e.g., [RTTSub]), but it is an inference measurement nonetheless [bdrmap] [IDCong].
この分類は、文献やオペレーターの両方で広く受け入れられており、実証データといくつかの情報源で真実の根拠として信頼できます（例：[rttsub]）が、それでも[bdrmap] [idcong]。
The first two categories correspond to the physical distance dependency on RTD, the next one binds RTD with queuing delay on routers, and the last one helps to identify different ASes using traceroutes. Due to the significant contribution of propagation delay in long-distance Hops, RTD will be on the order of 100 ms on transatlantic Hops, depending on the geolocation of the vantage points. Moreover, RTD is typically higher than 480 ms when two Hops are connected using geostationary satellite technology (i.e., their orbit is at 36000 km). Detecting congestion with latency implies deeper mathematical understanding, since network traffic load is not stationary. Nonetheless, as the first approach, a link seems to be congested if observing different/varying statistical results after sending several traceroute probes (e.g., see [IDCong]). Finally, to recognize distinctive ASes in the same traceroute path is challenging because more data is needed, like AS relationships and Regional Internet Registry (RIR) delegations among others (for more details, please consult [bdrmap]).
最初の2つのカテゴリは、RTDの物理的距離依存性に対応し、次のカテゴリはRTDにルーターのキューイング遅延でバインドされ、最後のカテゴリはトレーサーを使用して異なるASEを識別するのに役立ちます。長距離ホップでの伝播遅延が大きく貢献しているため、RTDは、視点の地理配置に応じて、大西洋横断ホップで100ミリ秒程度になります。さらに、Geostationary Satelliteテクノロジーを使用して2ホップが接続されている場合、RTDは通常480ミリ秒より高くなります（つまり、軌道は36000 kmです）。ネットワークトラフィックの負荷は静止していないため、レイテンシで混雑を検出することは、より深い数学的理解を意味します。それにもかかわらず、最初のアプローチとして、いくつかのTracerouteプローブを送信した後に異なる/変化する統計結果を観察すると、リンクが混雑しているようです（例：[idcong]を参照）。最後に、関係や地域のインターネットレジストリ（RIR）の代表団など、より多くのデータが必要であるため、同じTracerouteパスの特徴的なASEを認識することは困難です（詳細については、[BDRMAP]を参照してください）。
Several articles have shown that network traffic presents a self-similar nature [SSNT] [MLRM] that is accountable for filling the queues of the routers. Moreover, router queues are designed to handle traffic bursts, which is one of the most remarkable features of self-similarity. Naturally, while queue length increases, the delay to traverse the queue increases as well and leads to an increase on RTD. Due to traffic bursts generating short-term overflow on buffers (spiky patterns), every RTD only depicts the queueing status on the instant when that packet probe was in transit. For this reason, several RTD measurements during a time window could begin to describe the random behavior of latency. Loss must also be accounted for in the methodology.
いくつかの記事では、ネットワークトラフィックがルーターのキューを埋めることに責任を負う自己類似の性質[SSNT] [MLRM]を提示することを示しています。さらに、ルーターのキューは、交通バーストを処理するように設計されています。これは、自己類似性の最も注目すべき特徴の1つです。当然のことながら、キューの長さが増加している間、キューを横断する遅延も増加し、RTDで増加します。トラフィックバーストがバッファーで短期オーバーフローを生成するため（スパイクパターン）、すべてのRTDは、そのパケットプローブが輸送中のときの瞬間にキューイングステータスを描写します。このため、タイムウィンドウ中のいくつかのRTD測定は、レイテンシのランダムな動作を説明し始める可能性があります。また、方法論では損失を考慮する必要があります。
To understand the ongoing process, examining the quartiles provides a nonparametric way of analysis. Quartiles are defined by five values: minimum RTD (m), RTD value of the 25% of the Empirical Cumulative Distribution Function (ECDF) (Q1), the median value (Q2), the RTD value of the 75% of the ECDF (Q3), and the maximum RTD (M). Congestion can be inferred when RTD measurements are spread apart; consequently, the Interquartile Range (IQR), i.e., the distance between Q3 and Q1, increases its value.
進行中のプロセスを理解するために、四分位数を調べることは、分析のノンパラメトリックな方法を提供します。四分位数は5つの値で定義されます。最小RTD（M）、経験的累積分布関数（ECDF）（Q1）の25％のRTD値、中央値（Q2）、ECDFの75％のRTD値（Q3）、および最大RTD（M）。RTDの測定が広がっている場合、混雑は推測できます。その結果、四分位範囲（IQR）、つまりQ3とQ1の間の距離はその値を増加させます。
This procedure requires the algorithm presented in [P2] to compute quartile values "on the fly".
この手順では、[P2]で提示されたアルゴリズムが「オンザフライ」で四分位数を計算する必要があります。
This procedure allows us to update the quartile values whenever a new measurement arrives, which is radically different from classic methods of computing quartiles, because they need to use the whole dataset to compute the values. This way of calculus provides savings in memory and computing time.
この手順により、新しい測定が到着するたびに四分位数を更新できます。これは、データセット全体を使用して値を計算する必要があるため、四分位数の典型的な方法とは根本的に異なります。この計算方法は、メモリとコンピューティング時間の節約を提供します。
To sum up, the proposed measurement procedure consists of performing traceroutes several times to obtain samples of the RTD in every Hop from a path during a time window (W) and compute the quartiles for every Hop. This procedure could be done for a single Member Route flow, for a non-exhaustive search with parameter E (defined below) set to False, or for every detected Route Ensemble flow (E=True).
要約すると、提案された測定手順は、時間ウィンドウ（W）中にパスからすべてのホップでRTDのサンプルを取得し、すべてのホップの四分位数を計算するために、トレーサーアウトを数回実行することで構成されています。この手順は、単一のメンバールートフロー、falsに設定されたパラメーターE（以下に定義）を使用した非網羅的な検索、または検出されたすべてのルートアンサンブルフロー（E = True）に対して実行できます。
The identification of a specific Hop in a traceroute is based on the IP origin address of the returned ICMP Time Exceeded packet and on the distance identified by the value set in the TTL (or Hop Limit) field inserted by traceroute. As this specific Hop can be reached by different paths, the IP Source and Destination addresses of the traceroute packet also need to be recorded. Finally, different return paths are distinguished by evaluating the ICMP Time Exceeded TTL (or Hop Limit) of the reply message; if this TTL (or Hop Limit) is constant for different paths containing the same Hop, the return paths have the same distance. Moreover, this distance can be estimated considering that the TTL (or Hop Limit) value is normally initialized with values 64, 128, or 255. The 5-tuple (origin IP, destination IP, reply IP, distance, and response TTL or Hop Limit) unequivocally identifies every measurement.
Tracerouteでの特定のホップの識別は、返されたICMP時間のIPオリジンアドレスを超えて、TTL（またはホップ制限）フィールドに設定された値で識別された距離を超えた距離に基づいています。この特定のホップに異なるパスによって到達できるため、TracerouteパケットのIPソースと宛先アドレスも記録する必要があります。最後に、ReplyメッセージのTTL（またはホップ制限）を超えるICMP時間を評価することにより、異なるリターンパスが区別されます。このTTL（またはホップ制限）が同じホップを含む異なるパスに対して一定である場合、リターンパスの距離は同じです。さらに、この距離は、TTL（またはホップ制限）値が通常、値64、128、または255で初期化されることを考慮して推定できます。制限）すべての測定を明確に識別します。
This algorithm below runs in the origin of the traceroute. It returns the Qs quartiles for every Hop and Alt (alternative paths because of balancing). Notice that the "Alt" parameter condenses the parameters of the 5-tuple (origin IP, destination IP, reply IP, distance, and response TTL), i.e., one for each possible combination.
以下のこのアルゴリズムは、Tracerouteの起源で実行されます。すべてのホップとALT（バランスのために代替パス）に対してQSクワリタイルを返します。「Alt」パラメーターは、5タプル（Origin IP、宛先IP、返信IP、距離、および応答TTL）のパラメーター、つまり、可能な組み合わせごとに1つを凝縮することに注意してください。
================================================================
0 input: W (window time of the measurement)
1 i_t (time between two measurements, set the i_t time
2 long enough to avoid incomplete results)
3 E (True: exhaustive, False: a single path)
4 Dst (destination IP address)
5 output: Qs (quartiles for every Hop and Alt)
----------------------------------------------------------------
6 T := start_timer(W)
7 while T is not finished do:
8 | start_timer(i_t)
9 | RTD(Hop,Alt) = advanced-traceroute(Dst,E)
10 | for each Hop and Alt in RTD do:
11 | | Qs[Dst,Hop,Alt] := ComputeQs(RTD(Hop,Alt))
12 | done
13 | wait until i_t timer is expired
14 done
15 return (Qs)
================================================================
During the time W, lines 6 and 7 assure that the measurement loop is made. Lines 8 and 13 set a timer for each cycle of measurements. A cycle comprises the traceroutes packets, considering every possible Hop and the alternatives paths in the Alt variable (ensured in lines 9-12). In line 9, the advanced-traceroute could be either Paris-traceroute or Scamper, which will use the "exhaustive" mode or "tracelb" option if E is set to True, respectively. The procedure returns a list of tuples (m, Q1, Q2, Q3, and M) for each intermediate Hop, or "Alt" in as a function of the 5-tuple, in the path towards the Dst. Finally, lines 10 through 12 store each measurement into the real-time quartiles computation.
w、6行目と7行目の間に、測定ループが作成されることを保証します。8行目と13行目は、測定のサイクルごとにタイマーを設定します。サイクルは、すべての可能なホップとALT変数の代替パスを考慮して、Traceroutesパケットを含みます（9〜12行目で確保されます）。9行目では、Advanced-TracerouteはParis-TracerouteまたはScamperのいずれかである可能性があります。これは、EがそれぞれTrueに設定されている場合、「網羅的な」モードまたは「Tracelb」オプションを使用します。この手順では、各中間ホップのタプル（M、Q1、Q2、Q3、およびM）のリスト、またはDSTに向かうパスで5タプルの関数として「Alt」のリストを返します。最後に、各測定値をリアルタイム四分位数の計算に保存します。
Notice there are cases where even having a unique Hop at distance h from the Src to Dst, the returning path could have several possibilities, yielding different total paths. In this situation, the algorithm will return another "Alt" for this particular Hop.
SRCからDSTまでの距離hで一意のホップを持っているだけでも、戻るパスにはいくつかの可能性があり、異なる合計パスが得られる可能性がある場合に注意してください。この状況では、アルゴリズムはこの特定のホップの別の「alt」を返します。
The security considerations that apply to any active measurement of live paths are relevant here as well. See [RFC4656] and [RFC5357].
ライブパスの積極的な測定に適用されるセキュリティ上の考慮事項は、ここでも関連しています。[RFC4656]および[RFC5357]を参照してください。
The active measurement process of changing several fields to keep the checksum of different packets identical does not require special security considerations because it is part of synthetic traffic generation and is designed to have minimal to zero impact on network processing (to process the packets for ECMP).
異なるパケットのチェックサムを同一に保つためにいくつかのフィールドを変更するアクティブな測定プロセスは、合成交通生成の一部であり、ネットワーク処理に最小限からゼロの影響を与えるように設計されているため、特別なセキュリティに関する考慮事項を必要としません（ECMPのパケットを処理するため）。
Some of the protocols used (e.g., ICMP) do not provide cryptographic protection for the requested/returned data, and there are risks of processing untrusted data in general, but these are limitations of the existing protocols where we are applying new methods.
使用されるプロトコルの一部（例：ICMP）は、要求/返されたデータの暗号化保護を提供しておらず、一般に信頼されていないデータを処理するリスクがありますが、これらは新しい方法を適用している既存のプロトコルの制限です。
For applicable hybrid methods, the security considerations in [RFC9197] apply.
該当するハイブリッド方法には、[RFC9197]のセキュリティに関する考慮事項が適用されます。
When considering the privacy of those involved in measurement or those whose traffic is measured, the sensitive information available to potential observers is greatly reduced when using active techniques that are within this scope of work. Passive observations of user traffic for measurement purposes raise many privacy issues. We refer the reader to the privacy considerations described in the Large-scale Measurement of Broadband Performance (LMAP) Framework [RFC7594], which covers active and passive techniques.
測定に関与する人々またはトラフィックが測定された人のプライバシーを考慮すると、この作業範囲内にあるアクティブな手法を使用すると、潜在的なオブザーバーが利用できる機密情報が大幅に減少します。測定目的でユーザートラフィックの受動的な観察は、多くのプライバシーの問題を引き起こします。読者は、アクティブおよびパッシブテクニックをカバーするブロードバンドパフォーマンス（LMAP）フレームワーク[RFC7594]の大規模測定で説明されているプライバシーに関する考慮事項を紹介します。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>.
[RFC0792] POSTEL、J。、「インターネットコントロールメッセージプロトコル」、STD 5、RFC 792、DOI 10.17487/RFC0792、1981年9月、<https://www.rfc-editor.org/info/rfc792>。
[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>.
[RFC1122] Braden、R.、ed。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、DOI 10.17487/RFC1122、1989年10月、<https://www.rfc-editor.org/info/RFC1122>。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <https://www.rfc-editor.org/info/rfc1812>.
[RFC1812] Baker、F.、ed。、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487/RFC1812、1995年6月、<https://www.rfc-editor.org/info/rfc12>。
[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>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、Mahdavi、J。、およびM. Mathis、「IPパフォーマンスメトリックのフレームワーク」、RFC 2330、DOI 10.17487/RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.
[RFC2681] Almes、G.、Kalidindi、S。、およびM. Zekauskas、「IPPMの往復遅延メトリック」、RFC 2681、DOI 10.17487/RFC2681、1999年9月、<https：//www.rfc-editor.org/info/rfc2681>。
[RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.
[RFC4656] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J。、およびM. Zekauskas、「一元配置活動測定プロトコル（OWAMP）」、RFC 4656、DOI 10.17487/RFC4656、9月2006、<https://www.rfc-editor.org/info/rfc4656>。
[RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., and M. Swany, "Information Model and XML Data Model for Traceroute Measurements", RFC 5388, DOI 10.17487/RFC5388, December 2008, <https://www.rfc-editor.org/info/rfc5388>.
[RFC5388] Niccolini、S.、Tartarelli、S.、Quittek、J.、Dietz、T。、およびM. Swany、「Traceroute測定の情報モデルとXMLデータモデル」、RFC 5388、DOI 10.17487/RFC5388、2008年12月、<https://www.rfc-editor.org/info/rfc5388>。
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.
[RFC6438] Carpenter、B。およびS. Amante、「トンネルの等しいコストマルチパスルーティングとリンク集約にIPv6フローラベルを使用」、RFC 6438、DOI 10.17487/RFC6438、2011年11月、<https：//ww.rfc-editor.org/info/rfc6438>。
[RFC6673] Morton, A., "Round-Trip Packet Loss Metrics", RFC 6673, DOI 10.17487/RFC6673, August 2012, <https://www.rfc-editor.org/info/rfc6673>.
[RFC6673]モートン、A。、「往復パケット損失メトリック」、RFC 6673、DOI 10.17487/RFC6673、2012年8月、<https://www.rfc-editor.org/info/rfc673>。
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7799]モートン、A。、「アクティブおよびパッシブメトリックとメソッド（中間ハイブリッドタイプを含む）」、RFC 7799、DOI 10.17487/RFC7799、2016年5月、<https://www.rfc-editor.org/info/RFC7799>。
[RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>.
[RFC8029] Kompella、K.、Swallow、G.、Pignataro、C.、Ed。、Kumar、N.、Aldrin、S。、およびM. Chen、「マルチプロトコルラベルスイッチの検出（MPLS）データプレーン障害」、RFC 8029、DOI 10.17487/RFC8029、2017年3月、<https://www.rfc-editor.org/info/rfc8029>。
[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>。
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, <https://www.rfc-editor.org/info/rfc8468>.
[RFC8468] Morton、A.、A.、Fabini、J.、Elkins、N.、Ackermann、M.、およびV. Hegde、「IPv4、IPv6、およびIPv4-IPV6共存：IPパフォーマンスメトリック（IPPM）フレームワークの更新」、RFC 8468、DOI 10.17487/RFC8468、2018年11月、<https://www.rfc-editor.org/info/rfc8468>。
[RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, <https://www.rfc-editor.org/info/rfc9197>.
[RFC9197] Brockners、F.、ed。、Bhandari、S.、ed。、およびT. Mizrahi、ed。、「現場操作、管理、メンテナンスのデータフィールド（IOAM）」、RFC 9197、DOI 10.17487/RFC9197、2022年5月、<https://www.rfc-editor.org/info/rfc9197>。
[bdrmap] Luckie, M., Dhamdhere, A., Huffaker, B., Clark, D., and KC. Claffy, "bdrmap: Inference of Borders Between IP Networks", Proceedings of the 2016 ACM on Internet Measurement Conference, pp. 381-396, DOI 10.1145/2987443.2987467, November 2016, <https://doi.org/10.1145/2987443.2987467>.
[Bdrmap] Luckie、M.、Dhamdhere、A.、Huffaker、B.、Clark、D。、およびKC。Claffy、「BDRMAP：IPネットワーク間の境界の推論」、2016 ACM ON INTERNTER MESUEMENT CONFERENCE、pp。381-396、DOI 10.1145/2987443.2987467、2016年11月、<https://doi.org/10.1145/298743.23.298747>。
[IDCong] Luckie, M., Dhamdhere, A., Clark, D., and B. Huffaker, "Challenges in Inferring Internet Interdomain Congestion", Proceedings of the 2014 Conference on Internet Measurement Conference, pp. 15-22, DOI 10.1145/2663716.2663741, November 2014, <https://doi.org/10.1145/2663716.2663741>.
[Idcong] Luckie、M.、Dhamdhere、A.、Clark、D。、およびB. Huffaker、「インターネット間渋滞の推測における課題」、2014年のインターネット測定会議会議の議事録、pp。15-22、DOI 10.1145/2663716.2663741、2014年11月、<https://doi.org/10.1145/2663716.2663741>。
[LOAD_BALANCE] Sanguanpong, S., Pittayapitak, W., and K. Kasom Koht-Arsa, "COMPARISON OF HASH STRATEGIES FOR FLOW-BASED LOAD BALANCING", International Journal of Electronic Commerce Studies, Vol.6, No.2, pp.259-268, DOI 10.7903/ijecs.1346, December 2015, <https://doi.org/10.7903/ijecs.1346>.
[Load_balance] Sanguanpong、S.、Pittayapitak、W。、およびK. Kasom Koht-Arsa、「フローベースの負荷分散のためのハッシュ戦略の比較」、International Journal of Electronic Commerce Studies、Vol.6、No.2、pp.259-268、doi 10.7903/ijecs.1346、2015年12月、<https://doi.org/10.7903/ijecs.1346>。
[MLB] Augustin, B., Friedman, T., and R. Teixeira, "Measuring load-balanced paths in the internet", Proceedings of the 7th ACM SIGCOMM conference on Internet measurement, pp. 149-160, DOI 10.1145/1298306.1298329, October 2007, <https://doi.org/10.1145/1298306.1298329>.
[MLB] Augustin、B.、Friedman、T。、およびR. Teixeira、「インターネットの負荷分散パスの測定」、第7回ACM Sigcomm Conference on Internet Measurement、pp。149-160、DOI 10.1145/1298306.1298329、2007年10月、<https://doi.org/10.1145/1298306.1298329>。
[MLRM] Fontugne, R., Mazel, J., and K. Fukuda, "An empirical mixture model for large-scale RTT measurements", 2015 IEEE Conference on Computer Communications (INFOCOM), pp. 2470-2478, DOI 10.1109/INFOCOM.2015.7218636, April 2015, <https://doi.org/10.1109/INFOCOM.2015.7218636>.
[MLRM] Fontugne、R.、Mazel、J。、およびK. Fukuda、「大規模なRTT測定の経験的混合モデル」、2015 IEEE Conference on Computer Communications（Infocom）、pp。2470-2478、doi 10.1109/Infocom.2015.7218636、2015年4月、<https://doi.org/10.1109/infocom.2015.7218636>。
[P2] Jain, R. and I. Chlamtac, "The P 2 algorithm for dynamic calculation of quartiles and histograms without storing observations", Communications of the ACM 28.10 (1985): 1076-1085, DOI 10.1145/4372.4378, October 1985, <https://doi.org/10.1145/4372.4378>.
[P2] Jain、R。and I. Chlamtac、「観測を保存せずに四分位数とヒストグラムの動的計算のためのP 2アルゴリズム」、ACM 28.10（1985）：1076-1085、DOI 10.1145/4372.4378、1985年10月、DOI 10.1145/4372.4378、<https://doi.org/10.1145/4372.4378>。
[PT] Augustin, B., Cuvellier, X., Orgogozo, B., Viger, F., Friedman, T., Latapy, M., Magnien, C., and R. Teixeira, "Avoiding traceroute anomalies with Paris traceroute", Proceedings of the 6th ACM SIGCOMM conference on Internet measurement, pp. 153-158, DOI 10.1145/1177080.1177100, October 2006, <https://doi.org/10.1145/1177080.1177100>.
[Pt] Augustin、B.、Cuvellier、X.、Orgogozo、B.、Viger、F.、Friedman、Latapy、M.、Magnien、C。、およびR. Teixeira、「Paris Tracerouteとのトレーサーの異常を回避する」"、インターネット測定に関する第6回ACM Sigcomm Conferenceの議事録、pp。153-158、DOI 10.1145/1177080.1177100、2006年10月、<https://doi.org/10.1145/1177080.1177100>。
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and Multicast Next-Hop Selection", RFC 2991, DOI 10.17487/RFC2991, November 2000, <https://www.rfc-editor.org/info/rfc2991>.
[RFC2991] Thaler、D。およびC. Hopps、「UnicastおよびMulticast Next-Hop Selectionのマルチパス問題」、RFC 2991、DOI 10.17487/RFC2991、2000年11月、<https://www.rfc-editor.org/info/RFC2991>。
[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.
[RFC5357] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「双方向活性測定プロトコル（Twamp）」、RFC 5357、DOI 10.17487/RFC5357、10月2008、<https://www.rfc-editor.org/info/rfc5357>。
[RFC5835] Morton, A., Ed. and S. Van den Berghe, Ed., "Framework for Metric Composition", RFC 5835, DOI 10.17487/RFC5835, April 2010, <https://www.rfc-editor.org/info/rfc5835>.
[RFC5835]モートン、A。、編およびS. van den Berghe編、「メトリック組成のフレームワーク」、RFC 5835、DOI 10.17487/RFC5835、2010年4月、<https://www.rfc-editor.org/info/rfc5835>。
[RFC5837] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, DOI 10.17487/RFC5837, April 2010, <https://www.rfc-editor.org/info/rfc5837>.
[RFC5837] Atlas、A.、ed。、Bonica、R.、ed。、Pignataro、C.、Ed。、Shen、N.、Jr。Rivers、「インターフェイスとネクストホップ識別のICMPの拡張」、RFC 5837、DOI 10.17487/RFC5837、2010年4月、<https://www.rfc-editor.org/info/rfc5837>
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S.、およびJ. Rajahalme、「IPv6フローラベル仕様」、RFC 6437、DOI 10.17487/RFC6437、2011年11月、<https：//www.rfc-editor.org/info/rfc6437>。
[RFC7312] Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <https://www.rfc-editor.org/info/rfc7312>.
[RFC7312] Fabini、J。およびA. Morton、「IPパフォーマンスメトリックの高度なストリームとサンプリングフレームワーク（IPPM）」、RFC 7312、DOI 10.17487/RFC7312、2014年8月、<https：//www.rfc-editor.org/info/rfc7312>。
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., and C. Pignataro, "MPLS Forwarding Compliance and Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, August 2014, <https://www.rfc-editor.org/info/rfc7325>.
[RFC7325] Villamizar、C.、Ed。、Kompella、K.、Amante、S.、Malis、A.、およびC. Pignataro、「MPLS Forwarding Compliance and Performance Recomations」、RFC 7325、DOI 10.17487/RFC7325、2014年8月、<https://www.rfc-editor.org/info/rfc7325>。
[RFC7594] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.
[RFC7594] Eardley、P.、Morton、A.、Bagnulo、M.、Burbridge、T.、Aitken、P。、およびA. Akhter、「ブロードバンドパフォーマンスの大規模測定（LMAP）のフレームワーク」、RFC7594、doi 10.17487/rfc7594、2015年9月、<https://www.rfc-editor.org/info/rfc7594>。
[RFC8403] Geib, R., Ed., Filsfils, C., Pignataro, C., Ed., and N. Kumar, "A Scalable and Topology-Aware MPLS Data-Plane Monitoring System", RFC 8403, DOI 10.17487/RFC8403, July 2018, <https://www.rfc-editor.org/info/rfc8403>.
[RFC8403] Geib、R.、Ed。、Filsfils、C.、Pignataro、ed。、およびN. Kumar、「スケーラブルでトポロジを認識しているMPLSデータプレーン監視システム」、RFC 8403、DOI 10.17487/RFC8403、2018年7月、<https://www.rfc-editor.org/info/rfc8403>。
[RTTSub] Bischof, Z., Rula, J., and F. Bustamante, "In and out of Cuba: Characterizing Cuba's Connectivity", Proceedings of the 2015 ACM Conference on Internet Measurement Conference, pp. 487-493, DOI 10.1145/2815675.2815718, October 2015, <https://doi.org/10.1145/2815675.2815718>.
[Rttsub] Bischof、Z.、Rula、J。、およびF. Bustamante、「内外キューバ：キューバの接続の特徴」、2015 ACM会議に関するインターネット測定会議の議事録、pp。487-493、doi 10.1145/2815675.2815718、2015年10月、<https://doi.org/10.1145/2815675.2815718>。
[SCAMPER] Matthew Luckie, M., "Scamper: a scalable and extensible packet prober for active measurement of the internet", Proceedings of the 10th ACM SIGCOMM conference on Internet measurement, pp. 239-245, DOI 10.1145/1879141.1879171, November 2010, <https://doi.org/10.1145/1879141.1879171>.
[Scamper] Matthew Luckie、M。、「Scamper：インターネットのアクティブ測定のためのスケーラブルで拡張可能なパケットプローバー」、第10回ACM Sigcomm Conference on Internet Measurement、pp。239-245、DOI 10.1145/1879141.1879171、2010年11月、<https://doi.org/10.1145/1879141.1879171>。
[SSNT] Park, K. and W. Willinger, "Self-Similar Network Traffic and Performance Evaluation (1st ed.)", DOI 10.1002/047120644X, John Wiley & Sons, Inc., New York, NY, USA, August 2000, <https://doi.org/10.1002/047120644X>.
[SSNT] Park、K。およびW. Willinger、「自己相似ネットワークトラフィックとパフォーマンス評価（第1版）」、DOI 10.1002/047120644X、John Wiley＆Sons、Inc。、ニューヨーク、ニューヨーク、米国、2000年8月、<https://doi.org/10.1002/047120644x>。
A Node assessing an MPLS path must be part of the MPLS domain where the path is implemented. When this condition is met, [RFC8029] provides a powerful set of mechanisms to detect "correct operation of the data plane, as well as a mechanism to verify the data plane against the control plane".
MPLSパスを評価するノードは、パスが実装されているMPLSドメインの一部でなければなりません。この条件が満たされると、[RFC8029]は、「データプレーンの正しい動作と、制御プレーンに対するデータプレーンを検証するメカニズム」を検出する強力なメカニズムセットを提供します。
MPLS routing is based on the presence of a Forwarding Equivalence Class (FEC) Stack in all visited Nodes. Selecting one of several Equal-Cost Multipaths (ECMPs) is, however, based on information hidden deeper in the stack. Late deployments may support a so-called "Entropy label" for this purpose. State-of-the-art deployments base their choice of an ECMP member interface on the complete MPLS label stack and on IP addresses up to the complete 5-tuple IP header information (see Section 2.4 of [RFC7325]). Load sharing based on IP information decouples this function from the actual MPLS routing information. Thus, an MPLS traceroute is able to check how packets with a contiguous number of ECMP-relevant IP addresses (and an identical MPLS label stack) are forwarded by a particular router. The minimum number of equivalent MPLS paths traceable at a router should be 32. Implementations supporting more paths are available.
MPLSルーティングは、訪問されたすべてのノードに転送等価クラス（FEC）スタックの存在に基づいています。ただし、いくつかの等しいマルチパス（ECMP）の1つを選択することは、スタックの深い情報に基づいています。展開後の展開は、この目的のためにいわゆる「エントロピーラベル」をサポートする場合があります。最先端の展開は、完全なMPLSラベルスタックのECMPメンバーインターフェイスの選択と、完全な5タプルIPヘッダー情報までのIPアドレスに基づいています（[RFC7325]のセクション2.4を参照）。IP情報に基づく負荷共有は、実際のMPLSルーティング情報からこの関数を切り離します。したがって、MPLS Tracerouteは、隣接する数のECMP関連のIPアドレス（および同一のMPLSラベルスタック）を持つパケットが特定のルーターによって転送される方法を確認できます。ルーターでトレース可能な同等のMPLSパスの最小数は32でなければなりません。より多くのパスをサポートする実装が利用可能です。
The MPLS echo request and reply messages offering this feature must support the Downstream Detailed Mapping TLV (was Downstream Mapping initially, but the latter has been deprecated). The MPLS echo response includes the incoming interface where a router received the MPLS echo request. The MPLS echo reply further informs which of the n addresses relevant for the load-sharing decision results in a particular next-hop interface and contains the next Hop's interface address (if available). This ensures that the next Hop will receive a properly coded MPLS echo request in the next step Route of assessment.
この機能を提供するMPLSエコーリクエストと返信メッセージは、下流の詳細なマッピングTLVをサポートする必要があります（最初は下流マッピングでしたが、後者は廃止されました）。MPLSエコー応答には、ルーターがMPLSエコー要求を受信した着信インターフェイスが含まれます。MPLSエコーの応答は、特定のNext-Hopインターフェイスでロードシェアリングの決定に関連するNアドレスをさらに通知し、次のホップのインターフェイスアドレス（利用可能な場合）を含みます。これにより、次のホップが次のステップの評価ルートで適切にコーディングされたMPLSエコー要求を受信することが保証されます。
[RFC8403] explains how a central Path Monitoring System could be used to detect arbitrary MPLS paths between any routers within a single MPLS domain. The combination of MPLS forwarding, Segment Routing, and MPLS traceroute offers a simple architecture and a powerful mechanism to detect and validate (segment-routed) MPLS paths.
[RFC8403]は、中央パス監視システムを使用して、単一のMPLSドメイン内の任意のルーター間の任意のMPLSパスを検出する方法を説明します。MPLS転送、セグメントルーティング、およびMPLS Tracerouteの組み合わせは、単純なアーキテクチャと、MPLSパスを検出および検証するための強力なメカニズムを提供します。
Acknowledgements
謝辞
The original three authors (Ignacio, Al, Joachim) acknowledge Ruediger Geib for his penetrating comments on the initial document and his initial text for the appendix on MPLS. Carlos Pignataro challenged the authors to consider a wider scope and applied his substantial expertise with many technologies and their measurement features in his extensive comments. Frank Brockners also shared useful comments and so did Footer Foote. We thank them all!
元の3人の著者（Ignacio、Al、Joachim）は、Ruediger Geibが最初の文書とMPLSに関する付録に関する彼の最初のテキストについての彼の浸透したコメントについて認めています。Carlos Pignataroは著者に幅広い範囲を検討するように挑戦し、多くのテクノロジーとその測定機能で彼の実質的な専門知識を彼の広範なコメントで適用しました。フランクブロックナーも有用なコメントを共有し、フッターフットも共有しました。私たちは彼らに感謝します！
Authors' Addresses
著者のアドレス
J. Ignacio Alvarez-Hamelin
Universidad de Buenos Aires
Av. Paseo Colón 850
C1063ACV Buenos Aires
Argentina
Phone: +54 11 5285-0716
Email: ihameli@cnet.fi.uba.ar
URI: http://cnet.fi.uba.ar/ignacio.alvarez-hamelin/
Al Morton AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America Phone: +1 732 420 1571 Email: acm@research.att.com
Al Morton AT＆T Labs 200 Laurel Avenue South Middletown、NJ 07748アメリカ合衆国電話：1 732 420 1571メール：acm@research.att.com
Joachim Fabini
TU Wien
Gusshausstrasse 25/E389
1040 Vienna
Austria
Phone: +43 1 58801 38813
Email: Joachim.Fabini@tuwien.ac.at
URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
Carlos Pignataro Cisco Systems, Inc. 7200-11 Kit Creek Road Research Triangle Park, NC 27709 United States of America Email: cpignata@cisco.com
Carlos Pignataro Cisco Systems、Inc。7200-11 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国電子メール：cpignata@cisco.com
Ruediger Geib Deutsche Telekom Heinrich Hertz Str. 3-7 64295 Darmstadt Germany Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de
Ruediger Geib Deutsche Telekom Heinrich Hertz str。3-7 64295ダルムシュタットドイツ電話：49 6151 5812747メール：ruediger.geib@telekom.de