[要約] RFC 5388は、トレースルート測定の情報モデルとXMLデータモデルに関するものであり、トレースルート測定のためのデータの構造化と交換を目的としています。
Network Working Group S. Niccolini
Request for Comments: 5388 S. Tartarelli
Category: Standards Track J. Quittek
T. Dietz
NEC
M. Swany
UDel
December 2008
Information Model and XML Data Model for Traceroute Measurements
Traceroute測定のための情報モデルとXMLデータモデル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document describes a standard way to store the configuration and the results of traceroute measurements. This document first describes the terminology used in this document and the traceroute tool itself; afterwards, the common information model is defined, dividing the information elements into two semantically separated groups (configuration elements and results elements). Moreover, an additional element is defined to relate configuration elements and results elements by means of a common unique identifier. On the basis of the information model, a data model based on XML is defined to store the results of traceroute measurements.
このドキュメントでは、構成とTraceroute測定の結果を保存する標準的な方法について説明します。このドキュメントでは、最初にこのドキュメントで使用されている用語とTracerouteツール自体について説明します。その後、一般的な情報モデルが定義され、情報要素を意味的に分離した2つのグループ（構成要素と結果要素）に分割します。さらに、共通の一意の識別子を使用して、構成要素と結果要素を関連付けるために追加の要素が定義されています。情報モデルに基づいて、XMLに基づくデータモデルは、Traceroute測定の結果を保存するために定義されています。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology Used in This Document ...............................3
3. The Traceroute Tool and Its Operations ..........................4
4. Results of Traceroute Measurements ..............................5
5. Information Model for Traceroute Measurements ...................5
5.1. Data Types .................................................6
5.2. Information Elements .......................................7
5.2.1. Relationships between the Information Elements ......7
5.2.2. Configuration Information Elements .................12
5.2.3. Results Information Elements .......................17
5.2.4. Information Element Correlating
Configuration and Results ..........................21
5.2.5. Information Elements to Compare Traceroute
Measurement Results ................................22
6. Data Model for Storing Traceroute Measurements .................23
7. XML Schema for Traceroute Measurements .........................24
8. Security Considerations ........................................38
8.1. Conducting Traceroute Measurements ........................39
8.2. Securing Traceroute Measurement Information ...............39
9. IANA Considerations ............................................40
10. References ....................................................40
10.1. Normative References .....................................40
10.2. Informative References ...................................41
Appendix A. Traceroute Default Configuration Parameters ...........43
A.1. Alternative Traceroute Implementations ....................46
Appendix B. Known Problems with Traceroute ........................47
B.1. Compatibility between Traceroute Measurement Results
and IPPM Metrics ..........................................47
Appendix C. Differences to DISMAN-TRACEROUTE-MIB ..................47
C.1. Scope .....................................................48
C.2. Naming ....................................................49
C.3. Semantics .................................................49
C.4. Additional Information Elements ...........................50
Appendix D. Traceroute Examples with XML Representation ...........50
Traceroutes are used by lots of measurement efforts, either as independent measurements or as a means of getting path information to support other measurement efforts. That is why there is the need to standardize the way the configuration and the results of traceroute measurements are stored. The standard metrics defined by the IPPM group in matters of delay, connectivity, and losses do not apply to the metrics returned by the traceroute tool. Therefore, in order to compare results of traceroute measurements, the only possibility is to add to the stored results a specification of the operating system as well as the name and version for the traceroute tool used. This document, in order to store results of traceroute measurements and allow comparison of them, defines a standard way to store them using an XML schema.
トレーサーは、独立した測定として、または他の測定努力をサポートするパス情報を取得する手段として、多くの測定努力によって使用されます。そのため、構成とTraceroute測定の結果が保存される方法を標準化する必要性があります。遅延、接続、および損失の問題でIPPMグループによって定義された標準メトリックは、Tracerouteツールによって返されたメトリックには適用されません。したがって、Traceroute測定の結果を比較するために、唯一の可能性は、保存された結果にオペレーティングシステムの仕様と、使用されるTracerouteツールの名前とバージョンを追加することです。このドキュメントは、Traceroute測定の結果を保存し、それらの比較を可能にするために、XMLスキーマを使用してそれらを保存する標準的な方法を定義します。
The document is organized as follows: Section 2 defines the terminology used in this document; Section 3 describes the traceroute tool; Section 4 describes the results of a traceroute measurement as displayed to the screen from which the traceroute tool was launched; Section 5 and Section 6, respectively, describe the information model and data model for storing configuration and results of the traceroute measurements; Section 7 contains the XML schema to be used as a template for storing and/or exchanging traceroute measurement information; the document ends with security considerations and IANA considerations in Section 8 and Section 9 respectively.
ドキュメントは次のように編成されています。セクション2では、このドキュメントで使用されている用語を定義しています。セクション3では、Tracerouteツールについて説明します。セクション4では、Tracerouteツールが起動された画面に表示されるTraceroute測定の結果について説明します。セクション5とセクション6は、それぞれ、トレーサーアウト測定の構成と結果を保存するための情報モデルとデータモデルについて説明します。セクション7には、Traceroute測定情報を保存および/または交換するためのテンプレートとして使用されるXMLスキーマが含まれています。このドキュメントは、セクション8とセクション9のセキュリティに関する考慮事項とIANAの考慮事項で終了します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
The terminology used in this document is defined as follows:
このドキュメントで使用される用語は、次のように定義されています。
o traceroute tool: a software tool for network diagnostic that behaves as described in Section 3;
o Tracerouteツール：セクション3で説明されているように動作するネットワーク診断用のソフトウェアツール。
o traceroute measurement: an instance of the traceroute tool launched, with specific configuration parameters (traceroute measurement configuration parameters), from a specific host (initiator of the traceroute measurement) giving as output specific traceroute measurement results;
o Traceroute測定：特定のホスト（Traceroute測定のイニシエーター）から、特定のホスト（Traceroute測定構成パラメーター）を使用して、Tracerouteツールのインスタンスが発動し、出力特定のTraceroute測定結果を提供します。
o traceroute probe: one of many IP packets sent out by the traceroute tool during a traceroute measurement;
o Tracerouteプローブ：Traceroute測定中にTracerouteツールによって送信される多くのIPパケットの1つ。
o traceroute measurement configuration parameters: the configuration parameters of a traceroute measurement;
o Traceroute測定構成パラメーター：Traceroute測定の構成パラメーター。
o traceroute measurement results: the results of a traceroute measurement;
o Traceroute測定結果：Traceroute測定の結果。
o traceroute measurement information: both the results and the configuration parameters of a traceroute measurement;
o Traceroute測定情報：Traceroute測定の結果と構成パラメーターの両方。
o traceroute measurement path: a sequence of hosts transited in order by traceroute probes during a traceroute measurement.
o Traceroute測定パス：Traceroute測定中にTracerouteプローブによって順番にトランジングされたホストのシーケンス。
Traceroute is a network diagnostic tool used to determine the hop-by-hop path from a source to a destination and the Round Trip Time (RTT) from the source to each hop. Traceroute can be therefore used to discover some information (hop counts, delays, etc.) about the path between the initiator of the traceroute measurement and other hosts.
Tracerouteは、ソースから宛先までのホップバイホップパスと、ソースから各ホップまでの往復時間（RTT）を決定するために使用されるネットワーク診断ツールです。したがって、Tracerouteを使用して、Traceroute測定のイニシエーターと他のホストの間のパスに関する情報（ホップ数、遅延など）を発見できます。
Typically, the traceroute tool attempts to discover the path to a destination by sending UDP probes with specific time-to-live (TTL) values in the IP packet header and trying to elicit an ICMP TIME_EXCEEDED response from each gateway along the path to some host.
通常、Tracerouteツールは、IPパケットヘッダーに特定の時間（TTL）値を持つUDPプローブを送信し、各ゲートウェイから一部のホストへの各ゲートウェイからICMP Time_Exceedの応答を引き出しようとすることにより、宛先へのパスを発見しようとします。。
In more detail, a first set of probes with TTL equal to 1 is sent by the traceroute tool from the host initiating the traceroute measurement (some tool implementations allow setting the initial TTL to a value equal to "n" different from 1, so that the first "n-1" hops are skipped and the first hop that will be traced is the "n-th" in the path). Upon receiving a probe, the first hop host decreases the TTL value (by one or more). By observing a TTL value equal to zero, the host rejects the probe and typically returns an ICMP message with a TIME_EXCEEDED value. The traceroute tool can therefore derive the IP address of the first hop from the header of the ICMP message and evaluate the RTT between the host initiating the traceroute measurement and the first hop. The next hops are discovered following the same procedure, taking care to increase at each step the TTL value of the probes by one. The TTL value is increased until either an ICMP PORT_UNREACHABLE message is received, meaning that the destination host has been reached, or the maximum configured number of hops has been hit.
さらに詳しくは、TTLが1に等しいプローブの最初のプローブがTraceroute測定を開始するホストからTracerouteツールによって送信されます（一部のツール実装により、初期のTTLを1とは異なる「n」に設定することで、最初の「n-1」ホップはスキップされ、トレースされる最初のホップはパスの「n-th」です）。プローブを受信すると、最初のホップホストはTTL値を（1つ以上）減少させます。ゼロに等しいTTL値を観察することにより、ホストはプローブを拒否し、通常、time_exの成功した値でICMPメッセージを返します。したがって、Tracerouteツールは、ICMPメッセージのヘッダーから最初のホップのIPアドレスを導出し、Traceroute測定と最初のホップを開始するホスト間のRTTを評価できます。次のホップは同じ手順に従って発見され、各ステップでプローブのTTL値を1つずつ増やすように注意します。TTL値は、ICMP PORT_UNREACHABLEメッセージが受信されるまで増加します。つまり、宛先ホストに到達したか、最大設定されたホップ数がヒットします。
Some implementations use ICMP Echoes, instead of UDP datagrams. However, many routers do not return ICMP messages about ICMP messages, i.e., no ICMP TIME_EXCEEDED is returned for an ICMP Echo.
一部の実装では、UDPデータグラムの代わりにICMPエコーを使用しています。ただし、多くのルーターはICMPメッセージに関するICMPメッセージを返しません。つまり、ICMPエコーのICMP Time_Exededは返されません。
Therefore, this document recommends to base implementations on UDP datagrams. Considerations on TCP-based implementations of the traceroute tool are reported in Appendix A.1.
したがって、このドキュメントでは、UDPデータグラムの実装の基礎を推奨しています。TracerouteツールのTCPベースの実装に関する考慮事項は、付録A.1に報告されています。
The following list reports the information fields provided as results by all traceroute tool implementations considered. The order in which they are reported here is not relevant and changes in different implementations. For each hop, the following information is reported:
次のリストは、考慮されるすべてのTracerouteツールの実装によって結果として提供される情報フィールドを報告しています。ここで報告される順序は関連性がなく、さまざまな実装の変更があります。各ホップについて、次の情報が報告されています。
o the hop index;
o ホップインデックス。
o the host symbolic address, provided that at least one of the probes received a response, the symbolic address could be resolved at the corresponding host, and the option to display only numerical addresses was not set;
o ホストのシンボリックアドレスは、プローブの少なくとも1つが応答を受信し、対応するホストでシンボリックアドレスを解決でき、数値アドレスのみを表示するオプションが設定されていないことを条件としています。
o the host IP address, provided that at least one of the probes received a response;
o ホストIPアドレスは、プローブの少なくとも1つが応答を受け取ったことを提供します。
o the RTT for each response to a probe.
o プローブに対する各応答のRTT。
Depending on the traceroute tool implementation, additional information might be displayed in the output (for instance, MPLS-related information).
Tracerouteツールの実装に応じて、出力（たとえば、MPLS関連情報）に追加情報が表示される場合があります。
It might happen that some probes do not receive a response within the configured timeout (for instance, if the probe is filtered out by a firewall). In this case, an "*" is displayed in place of the RTT. The information model reflects this using a string with the value of "RoundTripTimeNotAvailable", meaning either the probe was lost because of a timeout or it was not possible to transmit a probe. It may also happen that some implementations print the same line multiple times when a router decreases the TTL by more than one, thus looking like multiple hops. The information model is not impacted by this since each line is handled separately; it is left to the applications handling the XML file how to deal with it. Moreover, for delays below 1 ms, some implementations report 0 ms (e.g., UNIX and LINUX), while WINDOWS reports "< 1 ms".
一部のプローブは、構成されたタイムアウト内で応答を受信しないことがあります（たとえば、プローブがファイアウォールによってフィルタリングされている場合）。この場合、RTTの代わりに「*」が表示されます。情報モデルは、「roundtriptimenotavailable」の値を持つ文字列を使用してこれを反映しています。つまり、タイムアウトのためにプローブが失われたか、プローブを送信することができませんでした。また、いくつかの実装は、ルーターがTTLを複数減らしたときに同じラインを複数回印刷し、複数のホップのように見えることもあります。各ラインは個別に処理されるため、情報モデルはこれに影響されません。XMLファイルに処理する方法を処理するアプリケーションに任されています。さらに、1ミリ秒未満の遅延の場合、一部の実装は0ミリ秒（UNIXやLinuxなど）を報告し、Windowsは「<1 ms」と報告しています。
The information model is composed of information elements; for defining these information elements, a template is used. Such template is specified in the list below: o name - A unique and meaningful name for the information element. The preferred spelling for the name is to use mixed case if the name is compound, with an initial lower-case letter, e.g., "sourceIpAddress".
情報モデルは情報要素で構成されています。これらの情報要素を定義するために、テンプレートが使用されます。このようなテンプレートは、以下のリストで指定されています。o名 - 情報要素のユニークで意味のある名前。名前の好ましいスペルは、名前が化合物の場合、初期の低ケース文字、たとえば「sourceipAddress」を使用する場合、混合ケースを使用することです。
o description - The semantics of this information element.
o 説明 - この情報要素のセマンティクス。
o dataType - One of the types listed in Section 5.1 of this document or in an extension of the information model. The type space for attributes is constrained to facilitate implementation.
o データタイプ - このドキュメントのセクション5.1にリストされているタイプの1つまたは情報モデルの拡張。属性のタイプスペースは、実装を容易にするために制約されています。
o units - If the element is a measure of some kind, the units identify what the measure is.
o ユニット - 要素が何らかの尺度である場合、ユニットは尺度が何であるかを識別します。
This section describes the set of basic valid data types of the information model.
このセクションでは、情報モデルの基本的な有効なデータ型のセットについて説明します。
o string - The type "string" represents a finite-length string of valid characters from the Unicode character encoding set. Unicode allows for ASCII and many other international character sets to be used. It is expected that strings will be encoded in UTF-8 format, which is identical in encoding for US-ASCII characters but which also accommodates other Unicode multi-byte characters.
o 文字列 - タイプ「文字列」は、Unicode文字エンコードセットの有効な文字の有限長文字列を表します。Unicodeを使用すると、ASCIIや他の多くの国際的なキャラクターセットを使用できます。文字列はUTF-8形式でエンコードされると予想されます。これは、US-ASCII文字のエンコードで同一であり、他のUnicodeマルチバイト文字にも対応します。
o string255 - Same type as "string" but with the restriction of 255 characters.
o string255-「string」と同じタイプですが、255文字の制限があります。
o inetAddressType - The type "inetAddressType" represents a type of Internet address. The allowed values are imported from [RFC4001] (where the intent was to import only some of the values); additional allowed values are "asnumber" and "noSpecification".
o InetAddressType -"InetAddressType"のタイプは、インターネットアドレスの種類を表します。許可された値は[RFC4001]からインポートされます（ここでは、一部の値のみをインポートすることが意図されていました）。追加の許可値は「ASNUMBER」および「NOSPECIFICITION」です。
o inetAddress - The type "inetAddress" denotes a generic Internet address. The allowed values are imported from [RFC4001] (the values imported are unknown, ipv4, ipv6, and dns), while non-global IPv4/IPv6 addresses (e.g., ipv4z and ipv6z) are excluded; an additional allowed value is the AS number, indicated as the actual number plus the indication of how the mapping from IP address to AS number was performed. "Unknown" is used to indicate an IP address that is not in one of the formats defined.
o inetAddress -"inetAddress"のタイプは、一般的なインターネットアドレスを示します。許可された値は[RFC4001]からインポートされます（インポートされた値は不明です、IPv4、IPv6、およびDNS）。追加の許可された値は、AS番号であり、実際の数値として示されていることに加えて、IPアドレスからAS数のマッピングがどのように実行されたかを示しています。「不明」は、定義された形式の1つでないIPアドレスを示すために使用されます。
o ipASNumberMappingType - The type "ipASNumberMappingType" represents a type of mapping from IP to AS number, it indicates the method that was used to do get the mapping (allowed values are "bgptables", "routingregistries", "nslookup", "others" or "unknown").
o IPASNumberMappingType-タイプ「IPASNumberMappingType」は、IPから数としてのマッピングのタイプを表します。マッピングを取得するために使用された方法を示します（許可値は「BGPTABLES」、「NSLOOKUP」、「NSLOOKUP」、「その他」または"知らない"）。
o boolean - The type "boolean" represents a boolean value according to XML standards [W3C.REC-xmlschema-2-20041028].
o ブール - 型「ブール」は、XML標準[W3C.REC-XMLSCHEMA-2-20041028]に従ってブール値を表します。
o unsignedInt - The type "unsignedInt" represents a value in the range (0..4294967295).
o unsignedint -"unsignedint"のタイプは、範囲（0..4294967295）の値を表します。
o unsignedShort - The type "unsignedShort" represents a value in the range (0..65535).
o unsignedshort-「unsignedshort」というタイプは、範囲（0..65535）の値を表します。
o unsignedByte - The type "unsignedByte" represents a value in the range (0..255).
o unsignedbyte-型「unsignedbyte」は、範囲（0..255）の値を表します。
o u8nonzero - The type "u8nonzero" represents a value in the range (1..255).
o u8nonzero-型「u8nonzero」は、範囲（1..255）の値を表します。
o probesType - The type "probesType" represents a way of indicating the protocol used for the traceroute probes. Values defined in this document are UDP, TCP, and ICMP.
o probestype-タイプ「probestype」は、tracerouteプローブに使用されるプロトコルを示す方法を表します。このドキュメントで定義されている値は、UDP、TCP、およびICMPです。
o operationResponseStatus - The type "operationResponseStatus" is used to report the result of an operation. The allowed values are imported from [RFC4560].
o OperationResponsestatus-操作の結果を報告するために「OperationResponsestatus」というタイプが使用されます。許可された値は[RFC4560]からインポートされます。
o dateTime - The type "dateTime" represents a date-time specification according to XML standards [W3C.REC-xmlschema-2-20041028] but is restricted to the values defined in [RFC3339].
o DateTime-タイプ「DateTime」は、XML標準[W3C.REC-XMLSCHEMA-20041028]に従って日付時間の仕様を表しますが、[RFC3339]で定義されている値に制限されています。
This section describes the elements related to the storing of a traceroute measurement. The elements are grouped in two groups (configuration and results) according to their semantics. In order to relate configuration and results elements by means of a common unique identifier, an additional element is defined belonging to both groups.
このセクションでは、Traceroute測定の保存に関連する要素について説明します。要素は、セマンティクスに従って2つのグループ（構成と結果）にグループ化されます。共通の一意の識別子を使用して構成要素と結果要素を関連付けるために、両方のグループに属する追加要素が定義されます。
Every traceroute measurement is represented by an instance of the "traceRoute" element. This class provides a standardized representation for traceroute measurement data. The "traceroute" element is an element that can be composed of (depending on the nature of the traceroute measurement):
すべてのTraceroute測定は、「Traceroute」要素のインスタンスで表されます。このクラスは、Traceroute測定データの標準化された表現を提供します。「Traceroute」要素は、（Traceroute測定の性質に応じて）で構成できる要素です。
o 1 optional "RequestMetadata" element;
o 1オプションの「requestmetadata」要素。
o 0..2147483647 "Measurement" elements.
o 0..2147483647「測定」要素。
Each "Measurement" element contains:
各「測定」要素には次のものが含まれます。
o 1 optional "MeasurementMetadata" element;
o 1オプションの「測定メタデータ」要素。
o 0..2147483647 "MeasurementResult" elements.
o 0..2147483647「測定値」要素。
The "RequestMetadata" element can be used for specifying parameters of a traceroute measurement to be performed at one or more nodes by one or more traceroute implementations. Depending on the capabilities of a traceroute implementation, not all requested parameters can be applied. Which parameters have actually been applied for a specific traceroute measurement is specified in a "MeasurementMetadata" element.
「RequestMetadata」要素は、1つ以上のTraceroute実装によって1つ以上のノードで実行されるトレーサーアウト測定のパラメーターを指定するために使用できます。Traceroute実装の機能に応じて、すべての要求されたパラメーターを適用できるわけではありません。特定のトレーサー測定に実際に適用されているパラメーターは、「測定メタダタ」要素で指定されています。
The "RequestMetadata" element is a sequence that contains:
「requestmetadata」要素は、次のようなシーケンスです。
o 1 "TestName" element;
o 1 "testname"要素。
o 1 optional "ToolVersion" element;
o 1オプションの「ツールバージョン」要素。
o 1 optional "ToolName" element;
o 1オプションの「ツール名」要素。
o 1 "CtlTargetAddress" element;
o 1 "ctltargetAddress"要素。
o 1 optional "CtlBypassRouteTable" element;
o 1オプションの「ctlbypassrouteTable」要素。
o 1 optional "CtlProbeDataSize" element;
o 1オプションの「ctlprobedatasize」要素。
o 1 optional "CtlTimeOut" element;
o 1オプションの「ctltimeout」要素。
o 1 optional "CtlProbesPerHop" element;
o 1オプションの「CTLPROBESPERHOP」要素。
o 1 optional "CtlPort" element;
o 1オプションの「ctlport」要素。
o 1 optional "CtlMaxTtl" element;
o 1オプションの「ctlmaxttl」要素。
o 1 optional "CtlDSField" element;
o 1オプションの「CTLDSField」要素。
o 1 optional "CtlSourceAddress" element;
o 1オプションの「ctlsourceaddress」要素。
o 1 optional "CtlIfIndex" element;
o 1オプションの「ctlifindex」要素。
o 1 optional "CtlMiscOptions" element;
o 1オプションの「ctlmiscoptions」要素。
o 1 optional "CtlMaxFailures" element;
o 1オプションの「ctlmaxfailures」要素。
o 1 optional "CtlDontFragment" element;
o 1オプションの「ctldontfragment」要素。
o 1 optional "CtlInitialTtl" element;
o 1オプションの「ctlinitialttl」要素。
o 1 optional "CtlDescr" element;
o 1オプションの「ctldescr」要素。
o 1 "CtlType" element.
o 1 "CTLTYPE"要素。
If the "RequestMetadata" element is omitted from an XML file, it means that the traceroute measurement configuration parameters requested were all used and the "MeasurementMetadata" element lists them in detail.
XMLファイルから「RequestMetadata」要素が省略されている場合、要求されたTraceroute測定構成パラメーターがすべて使用され、「測定メタダタ」要素がそれらを詳細にリストしたことを意味します。
The "MeasurementMetadata" element is a sequence that contains:
「測定メタダタ」要素は、次のようなシーケンスです。
o 1 "TestName" element;
o 1 "testname"要素。
o 1 "OSName" element;
o 1 "osname"要素。
o 1 "OSVersion" element;
o 1 "Osversion"要素。
o 1 "ToolVersion" element;
o 1「ツールバージョン」要素。
o 1 "ToolName" element;
o 1 "ToolName"要素。
o 1 "CtlTargetAddressType" element;
o 1 "ctltargetaddresstype"要素。
o 1 "CtlTargetAddress" element;
o 1 "ctltargetAddress"要素。
o 1 "CtlBypassRouteTable" element;
o 1 "CTLBYPASSROUTETABLE"要素。
o 1 "CtlProbeDataSize" element;
o 1「Ctlprobedatasize」要素。
o 1 "CtlTimeOut" element;
o 1 "ctltimeout"要素。
o 1 "CtlProbesPerHop" element;
o 1 "CTLPROBESPERHOP"要素。
o 1 "CtlPort" element;
o 1 "ctlport"要素。
o 1 "CtlMaxTtl" element;
o 1 "ctlmaxttl"要素。
o 1 "CtlDSField" element;
o 1 "CTLDSFIELD"要素。
o 1 "CtlSourceAddressType" element;
o 1 "ctlsourceaddresstype"要素。
o 1 "CtlSourceAddress" element;
o 1 "ctlsourceaddress"要素。
o 1 "CtlIfIndex" element;
o 1 "ctlifindex"要素。
o 1 optional "CtlMiscOptions" element;
o 1オプションの「ctlmiscoptions」要素。
o 1 "CtlMaxFailures" element;
o 1 "ctlmaxfailures"要素。
o 1 "CtlDontFragment" element;
o 1 "ctldontfragment"要素。
o 1 "CtlInitialTtl" element;
o 1 "ctlinitialttl"要素。
o 1 optional "CtlDescr" element;
o 1オプションの「ctldescr」要素。
o 1 "CtlType" element.
o 1 "CTLTYPE"要素。
Configuration information elements can describe not just traceroute measurements that have already happened ("MeasurementMetadata" elements), but also the configuration to be used when requesting a measurement to be made ("RequestMetadata" element). This is quite different semantically, even if the individual information elements are similar. Due to this similarity, both "RequestMetadata" and "MeasurementMetadata" are represented by the same type in the XML schema. All elements that are missing from the "RequestMetadata" or marked as optional in the "RequestMetadata" but mandatory in the "MeasurementMetadata" must be specified as empty elements. Specifying them as empty elements means use the default value. The "CtlType" element could have been optional in the "RequestMetadata", but since default values cannot be specified for complex types in an XML schema, the element is mandatory in the "RequestMetadata".
構成情報要素は、既に発生している測定値（「測定メタダタ」要素）だけでなく、測定を要求するときに使用する構成（ "requestmetadata"要素）を記述することもできます。個々の情報要素が類似していても、これは意味的にはまったく異なります。この類似性のため、「RequestMetadata」と「MeasurementMetadata」の両方が、XMLスキーマの同じタイプで表されます。「requestmetadata」から欠落しているか、「requestmetadata」でオプションとしてマークされているが、「測定メタダタ」で必須であるすべての要素は、空の要素として指定する必要があります。空の要素としてそれらを指定すると、デフォルト値が使用されることを意味します。「ctltype」要素は「requestmetadata」ではオプションであった可能性がありますが、XMLスキーマの複雑なタイプではデフォルト値を指定できないため、要素は「requestmetadata」で必須です。
The "MeasurementResult" element is a sequence that contains:
「測定値」要素は、以下を含むシーケンスです。
o 1 "TestName" element;
o 1 "testname"要素。
o 1 "ResultsStartDateAndTime" element;
o 1 "resultsstartdateandtime"要素。
o 1 "ResultsIpTgtAddrType" element;
o 1 "resultiptgtaddrtype"要素。
o 1 "ResultsIpTgtAddr" element;
o 1 "resultipiptgtaddr"要素。
o 1 "ProbeResults" elements;
o 1 "proberesults"要素。
o 1 "ResultsEndDateAndTime" element.
o 1 "resultsenddateandtime"要素。
Additionally, it is important to say that each "ProbeResults" element is a sequence that contains:
さらに、それぞれの「proberesults」要素は次のシーケンスであると言うことが重要です。
o 1..255 "hop" elements.
o 1..255「ホップ」要素。
Each "hop" element is a sequence that contains:
各「ホップ」要素は、次のようなシーケンスです。
o 1..10 "probe" elements;
o 1..10「プローブ」要素。
o 1 optional "HopRawOutputData" element.
o 1オプションの「hoprawoutputdata」要素。
Each "probe" element contains:
各「プローブ」要素には次のものが含まれます。
o 1 "HopAddrType" element;
o 1 "hopaddrtype"要素。
o 1 "HopAddr" element;
o 1 "Hopaddr"要素。
o 1 optional "HopName" element;
o 1オプションの「hopname」要素。
o 0..255 optional "MPLSLabelStackEntry" elements;
o 0..255オプションの「mplslabelstackentry」要素。
o 1 "ProbedRoundTripTime" element;
o 1 "ProbedroundTriptime"要素。
o 1 "ResponseStatus" element;
o 1 "Restupdestatus"要素。
o 1 "Time" element.
o 1「時間」要素。
Different numbers of appearances of the three basic elements in the XML file are meant for different scopes:
XMLファイルの3つの基本要素の異なる数の外観は、さまざまなスコープを対象としています。
o a file with only 1 "RequestMetadata" element represents a file containing the traceroute measurement configuration parameters of a traceroute measurement; it can be used to distribute the traceroute measurement configuration parameters over multiple nodes asked to run the same traceroute measurement;
o 1 "requestmetadata"要素のみを持つファイルは、traceroute測定のtraceroute測定構成パラメーターを含むファイルを表します。同じTraceroute測定を実行するように求められた複数のノード上で、Traceroute測定構成パラメーターを配布するために使用できます。
o a file with 1 "Measurement" element containing 1 "MeasurementMetadata" and 1 "MeasurementResult" element represents a file containing the traceroute measurement information of a traceroute measurement;
o 1「測定」要素を含む1「測定」要素を含むファイルと1「測定値」要素は、traceroute測定のtraceroute測定情報を含むファイルを表します。
o a file with 1 "Measurement" element containing 1 "MeasurementMetadata" and n "MeasurementResult" elements represents a file containing the traceroute measurement information of a set of traceroute measurements run over different times with always the same traceroute measurement configuration parameters;
o 1「測定」要素を含む1「測定」要素を含むファイルとn「測定値」要素は、常に同じトレーサー測定構成パラメーターで異なる時間にわたって実行される一連のtraceroute測定のtraceroute測定情報を含むファイルを表します。
o a file with 1 "RequestMetadata" and 1 "Measurement" element containing 1 "MeasurementMetadata" and 1 "Measurement" element represents a file containing the traceroute measurement information of a traceroute measurement (containing both the requested traceroute measurement configuration parameters and the ones actually used);
o 1 "requestmetadata"と1 "測定値の要素を含む1"測定値の要素を含むファイルは、1 "測定メタダタ"と1 "測定値"要素を含むtraceroute測定情報を含むファイルを表します（要求されたtraceroute測定構成パラメーターの両方と実際に使用されるものの両方を含む）;
o other combinations are possible to store multiple traceroute measurements all in one XML file.
o その他の組み合わせは、1つのXMLファイルにすべて複数のTraceroute測定値を保存することができます。
This section describes the elements specific to the configuration of the traceroute measurement (belonging to both the "RequestMetadata" and "MeasurementMetadata" elements).
このセクションでは、Traceroute測定の構成に固有の要素について説明します（「RequestMetadata」と「MeasurementMetadata」要素の両方に属する）。
o name - CtlTargetAddressType
o 名前-CTLTARGETADDRESSTYPE
o description - Specifies the type of address in the corresponding "CtlTargetAddress" element. This element is not directly reflected in the XML schema of Section 7. The host address type can be determined by examining the inetAddress type name and the corresponding element value.
o 説明 - 対応する「ctltargetAddress」要素のアドレスのタイプを指定します。この要素は、セクション7のXMLスキーマに直接反映されていません。ホストアドレスタイプは、InetAddressタイプ名と対応する要素値を調べることで決定できます。
o dataType - inetAddressType
o DataType -InetAddressType
o units - N/A
o 単位-N/A
o name - CtlTargetAddress
o 名前-CTLTargetAddress
o description - In the "RequestMetadata" element, it specifies the host address requested to be used in the traceroute measurement. In the "MeasurementMetadata" element, it specifies the host address used in the traceroute measurement.
o 説明 - 「RequestMetadata」要素では、Traceroute測定で使用するように要求されたホストアドレスを指定します。「測定メタダタ」要素では、Traceroute測定で使用されるホストアドレスを指定します。
o dataType - inetAddress
o Datatype -InetAddress
o units - N/A
o 単位-N/A
o name - CtlBypassRouteTable
o 名前-CTLBYPASSROUTETABLE
o description - In the "RequestMetadata" element, specifies if the optional bypassing of the route table was enabled or not. In the "MeasurementMetadata" element, specifies if the optional bypassing of the route table was enabled or not. If enabled, the normal routing tables will be bypassed and the probes will be sent directly to a host on an attached network. If the host is not on a directly attached network, an error is returned. This option can be used to perform the traceroute measurement to a local host through an interface that has no route defined. This object can be used when the setsockopt SOL_SOCKET SO_DONTROUTE option is supported and set (see [IEEE.1003-1G.1997]).
o 説明 - 「requestmetadata」要素で、ルートテーブルのオプションのバイパスが有効かどうかを指定します。「測定メタダタ」要素では、ルートテーブルのオプションのバイパスが有効かどうかを指定します。有効にすると、通常のルーティングテーブルがバイパスされ、プローブが添付ネットワーク上のホストに直接送信されます。ホストが直接接続されていない場合、エラーが返されます。このオプションは、定義されたルートのないインターフェイスを介してローカルホストにTraceroute測定を実行するために使用できます。このオブジェクトは、SetSockopt Sol_Socket So_Dontrouteオプションがサポートされ、設定されている場合に使用できます（[IEEE.1003-1G.1997]を参照）。
o dataType - boolean
o DataType -Boolean
o units - N/A
o 単位-N/A
o name - CtlProbeDataSize
o 名前-CTLProBedatasize
o description - Specifies the size of the probes of a traceroute measurement in octets (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). If UDP datagrams are used as probes, then the value contained in this object is exact. If another protocol is used to transmit probes (i.e., TCP or ICMP), for which the specified size is not appropriate, then the implementation can use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object is computed by subtracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 jumbograms).
o 説明 - オクテットのトレーサーアウト測定のプローブのサイズを指定します（「requestmetadata」要素の場合、「測定メタダタ」要素の場合に実際に使用される場合は要素）を指定します。UDPデータグラムがプローブとして使用される場合、このオブジェクトに含まれる値は正確です。指定されたサイズが適切でないプローブ（つまり、TCPまたはICMPなど）を送信するために別のプロトコルを使用している場合、実装は、指定されたサイズに最も近いサイズ（メソッドに適した）を使用できます。このオブジェクトの最大値は、可能な限り小さなIPヘッダーサイズ20オクテット（オプションなしのIPv4ヘッダー）と最大IPパケットサイズから8オクテットのUDPヘッダーサイズを減算することにより計算されます。IPパケットの最大サイズは65535オクテット（IPv6ジャンボグラムを除く）です。
o dataType - unsignedShort
o DataType -UnsignedShort
o units - octets
o ユニット - オクテット
o name - CtlTimeOut
o 名前-CTLTIMEOUT
o description - Specifies the timeout value, in seconds, for each probe of a traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - Traceroute測定の各プローブに対して、数秒単位でタイムアウト値を指定します（「RequestMetaData」要素で、「測定メタダタ」要素で実際に使用される場合は要素）。
o dataType - unsignedByte
o datatype- unsignedbyte
o units - seconds
o ユニット - 秒
o name - CtlProbesPerHop
o 名前-CTLPROBESPERHOP
o description - Specifies the number of probes with the same time-to-live (TTL) value that are sent for each host (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - 各ホストに対して送信される同じ時間（TTL）値を持つプローブの数を指定します（ "requestmetadata"要素の場合、「測定メタダタ」要素で実際に使用される場合は要素）。
o dataType - unsignedByte
o datatype- unsignedbyte
o units - probes
o ユニット - プローブ
o name - CtlPort
o 名前-Ctlport
o description - Specifies the base port used by the traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - Traceroute測定で使用されるベースポートを指定します（「requestmetadata」要素で実際に「測定メタダタ」要素で使用されている場合は要求されます）。
o dataType - unsignedShort
o DataType -UnsignedShort
o units - port number
o ユニット - ポート番号
o name - CtlMaxTtl
o 名前-CTLMAXTTL
o description - Specifies the maximum TTL value for the traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - Traceroute測定の最大TTL値を指定します（「RequestMetadata」要素の場合は、「測定メタダタ」要素で実際に使用される場合に使用されます）。
o dataType - u8nonzero
o データタイプ-U8NONZERO
o units - time-to-live value
o ユニット - 時間からの時間まで
o name - CtlDSField
o 名前-CTLDSField
o description - Specifies the value that was requested to be stored in the Differentiated Services (DS) field in the traceroute probe (if in the "RequestMetadata" element). Specifies the value that was stored in the Differentiated Services (DS) field in the traceroute probe (if in the "MeasurementMetadata" element). The DS field is defined as the Type of Service (TOS) octet in an IPv4 header or as the Traffic Class octet in an IPv6 header (see Section 7 of [RFC2460]). The value of this object must be a decimal integer in the range from 0 to 255. This option can be used to determine what effect an explicit DS field setting has on a traceroute measurement and its probes. Not all values are legal or meaningful. Useful TOS octet values are probably 16 (low delay) and 8 (high throughput). Further references can be found in [RFC2474] for the definition of the Differentiated Services (DS) field and in [RFC1812] Section 5.3.2 for Type of Service (TOS).
o 説明 - Tracerouteプローブの差別化されたサービス（DS）フィールドに保存されるように要求された値を指定します（「requestmetadata」要素の場合）。Tracerouteプローブの差別化されたサービス（DS）フィールドに保存された値を指定します（「測定メタダタ」要素の場合）。DSフィールドは、IPv4ヘッダーのサービスのタイプ（TOS）Octet、またはIPv6ヘッダーのトラフィッククラスOctetとして定義されます（[RFC2460]のセクション7を参照）。このオブジェクトの値は、0〜255の範囲の小数整数でなければなりません。このオプションは、明示的なDSフィールド設定がTraceroute測定とそのプローブにどのような影響を与えるかを決定するために使用できます。すべての価値が合法的または意味があるわけではありません。有用なTOSオクテット値は、おそらく16（低遅延）および8（高スループット）です。詳細な参照は、[RFC2474]では、差別化されたサービス（DS）フィールドの定義と[RFC1812]セクション5.3.2（TOS）のセクション5.3.2にあります。
o dataType - unsignedByte
o datatype- unsignedbyte
o units - N/A
o 単位-N/A
o name - CtlSourceAddressType
o 名前-CTLSOURCEADDRESSTYPE
o description - Specifies the type of address in the corresponding "CtlSourceAddress" element. This element is not directly reflected in the XML schema of Section 7. The host address type can be determined by examining the "inetAddress" type name and the corresponding element value. DNS names are not allowed for the "CtlSourceAddress".
o 説明 - 対応する「ctlsourceaddress」要素のアドレスのタイプを指定します。この要素は、セクション7のXMLスキーマに直接反映されていません。ホストアドレスタイプは、「inetAddress」タイプ名と対応する要素値を調べることで決定できます。DNS名は「CTLSourCeaddress」では許可されていません。
o dataType - inetAddressType
o DataType -InetAddressType
o units - N/A
o 単位-N/A
o name - CtlSourceAddress
o 名前-CTLSOURCEADDRESS
o description - Specifies the IP address (which has to be given as an IP number, not a hostname) as the source address in traceroute probes (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). On hosts with more than one IP address, this option can be used in the "RequestMetadata" element to force the source address to be something other than the primary IP address of the interface the probe is sent on; the value "unknown" means the default address will be used.
o 説明 - Tracerouteプローブのソースアドレス（「requestmetadata」要素の場合は要求されている場合、「測定メタダタ」要素で実際に使用される場合は要求）として、IPアドレス（ホスト名ではなくIP番号として指定する必要があります）を指定します。複数のIPアドレスを持つホストでは、このオプションを「RequestMetaData」要素で使用して、プローブが送信されるインターフェイスの主要なIPアドレス以外のものにします。値「不明」は、デフォルトのアドレスが使用されることを意味します。
o dataType - inetAddress
o Datatype -InetAddress
o units - N/A
o 単位-N/A
o name - CtlIfIndex
o 名前-Ctlifindex
o description - Specifies the interface index as defined in [RFC2863] that is requested to be used in the traceroute measurement for sending the traceroute probes (if in the "RequestMetadata" element). A value of 0 indicates that no specific interface is requested. Specifies the interface index actually used (if in the "MeasurementMetadata" element).
o 説明 - [RFC2863]で定義されているインターフェイスインデックスを指定します。これは、Tracerouteプローブを送信するためにTraceroute測定で使用するように要求されます（「RequestMetadata」要素の場合）。0の値は、特定のインターフェイスが要求されていないことを示します。実際に使用されるインターフェイスインデックスを指定します（「測定メタダタ」要素の場合）。
o dataType - unsignedInt
o DataType -UnsignedInt
o units - N/A
o 単位-N/A
o name - CtlMiscOptions
o 名前-CTLMISCOPTIONS
o description - Specifies implementation-dependent options (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - 実装依存オプションを指定します（「requestmetadata」要素の場合は要求されます。実際には「測定メタダタ」要素で使用されます）。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
o name - CtlMaxFailures
o 名前-CTLMAXFAILURES
o description - Specifies the maximum number of consecutive timeouts allowed before terminating a traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). A value of either 255 (maximum hop count/possible TTL value) or 0 indicates that the function of terminating a remote traceroute measurement when a specific number of consecutive timeouts are detected was disabled. This element is included to give full compatibility with [RFC4560]. No known implementation of traceroute currently supports it.
o 説明 - Traceroute測定を終了する前に許可される連続タイムアウトの最大数を指定します（「RequestMetadata」要素で、「測定メタダタ」要素で実際に使用される「requestmetadata」要素で要求されます）。255（最大ホップカウント/可能なTTL値）または0の値は、特定の数の連続したタイムアウトが検出されたときのリモートトレーサーアウト測定を終了する機能が無効になったことを示しています。この要素は、[RFC4560]との完全な互換性を与えるために含まれています。Tracerouteの既知の実装は現在それをサポートしていません。
o dataType - Unsigned8
o datatype -unsigned8
o units - timeouts
o ユニット - タイムアウト
o name - CtlDontFragment
o 名前-CTLDONTFRAGMENT
o description - Specifies if the don't fragment (DF) flag in the IP header for a probe was enabled or not (if in the "MeasurementMetadata" element). If in the "RequestMetadata", it specifies if the flag was requested to be enabled or not. Setting the DF flag can be used for performing a manual PATH MTU test.
o 説明-ProbeのIPヘッダーのDont Fragment（DF）フラグが有効かどうかを指定します（「測定Metadata」要素の場合）。「requestmetadata」で、フラグが有効になるように要求されたかどうかを指定します。DFフラグの設定は、マニュアルパスMTUテストの実行に使用できます。
o dataType - boolean
o DataType -Boolean
o units - N/A
o 単位-N/A
o name - CtlInitialTtl
o 名前-Ctlinitialttl
o description - Specifies the initial TTL value for a traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). Such TTL setting is intended to bypass the initial (often well-known) portion of a path.
o 説明 - Traceroute測定の初期TTL値を指定します（「RequestMetadata」要素の場合は、「測定メタダタ」要素で実際に使用される場合は要素）。このようなTTL設定は、パスの初期（しばしばよく知られている）部分をバイパスすることを目的としています。
o dataType - u8nonzero
o データタイプ-U8NONZERO
o units - N/A
o 単位-N/A
o name - CtlDescr
o 名前-CTLDESCR
o description - Provides a description of the traceroute measurement.
o 説明 - Traceroute測定の説明を提供します。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
o name - CtlType
o 名前-CTLTYPE
o description - Specifies the implementation method used for the traceroute measurement (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). It specifies if the traceroute is using TCP, UDP, ICMP, or other types of probes. It is possible to specify other types of probes by using an element specified in another schema with a different namespace.
o 説明 - Traceroute測定に使用される実装メソッドを指定します（「requestmetadata」要素の場合、「測定メタダタ」要素で実際に使用される場合は要求）。TracerouteがTCP、UDP、ICMP、または他のタイプのプローブを使用しているかどうかを指定します。別の名前空間を持つ別のスキーマで指定された要素を使用して、他のタイプのプローブを指定することができます。
o dataType - probesType
o Datatype -probestype
o units - N/A
o 単位-N/A
This section describes the elements specific to the results of the traceroute measurement.
このセクションでは、Traceroute測定の結果に固有の要素について説明します。
o name - ResultsStartDateAndTime
o 名前 - 結果StartDateandTime
o description - Specifies the date and start time of the traceroute measurement. This is the time when the first probe was seen at the sending interface.
o 説明 - Traceroute測定の日付と開始時間を指定します。これは、送信インターフェイスで最初のプローブが見られた時期です。
o dataType - DateTime
o DataType -DateTime
o units - N/A
o 単位-N/A
o name - ResultsIpTgtAddrType
o 名前-LesultSiptgtadDrtype
o description - Specifies the type of address in the corresponding "ResultsIpTgtAddr" element. This element is not directly reflected in the XML schema of Section 7. The host address type can be determined by examining the "inetAddress" type name and the corresponding element value.
o 説明 - 対応する「resultiptgtaddr」要素のアドレスのタイプを指定します。この要素は、セクション7のXMLスキーマに直接反映されていません。ホストアドレスタイプは、「inetAddress」タイプ名と対応する要素値を調べることで決定できます。
o dataType - inetAddressType
o DataType -InetAddressType
o units - N/A
o 単位-N/A
o name - ResultsIpTgtAddr
o 名前-Lesultsiptgtaddr
o description - Specifies the IP address associated with a "CtlTargetAddress" value when the destination address is specified as a DNS name. The value of this object should be "unknown" if a DNS name is not specified or if a specified DNS name fails to resolve.
o 説明 - 宛先アドレスがDNS名として指定されている場合、「ctltargetAddress」値に関連付けられたIPアドレスを指定します。このオブジェクトの値は、DNS名が指定されていない場合、または指定されたDNS名が解決できない場合に「不明」する必要があります。
o dataType - inetAddress
o Datatype -InetAddress
o units - N/A
o 単位-N/A
o name - HopAddrType
o 名前-HOPADDRTYPE
o description - Specifies the type of address in the corresponding "HopAddr" element. This element is not directly reflected in the XML schema of Section 7. The host address type can be determined by examining the "inetAddress" type name and the corresponding element value. DNS names are not allowed for "HopAddr".
o 説明 - 対応する「Hopaddr」要素のアドレスのタイプを指定します。この要素は、セクション7のXMLスキーマに直接反映されていません。ホストアドレスタイプは、「inetAddress」タイプ名と対応する要素値を調べることで決定できます。DNS名は「Hopaddr」では許可されていません。
o dataType - inetAddressType
o DataType -InetAddressType
o units - N/A
o 単位-N/A
o name - HopAddr
o 名前-Hopaddr
o description - Specifies the address of a hop in the traceroute measurement path. This object is not allowed to be a DNS name.
o 説明 - Traceroute測定パスのホップのアドレスを指定します。このオブジェクトはDNS名になることは許可されていません。
o dataType - inetAddress
o Datatype -InetAddress
o units - N/A
o 単位-N/A
o name - HopName
o 名前 - hopname
o description - Specifies the DNS name of the "HopAddr" if it is available. If it is not available, the element is omitted.
o 説明 - 使用可能な場合は、「hopaddr」のDNS名を指定します。利用できない場合、要素は省略されます。
o dataType - inetAddress
o Datatype -InetAddress
o units - N/A
o 単位-N/A
o name - MPLSLabelStackEntry
o 名前-MPLSLABELSTACKENTRY
o description - Specifies entries of the MPLS label stack of a probe observed when the probe arrived at the hop that replied to the probe. This object contains one MPLS label stack entry as a 32-bit value as it is observed on the MPLS label stack. Contained in this single number are the MPLS label, the Exp field, the S flag, and the MPLS TTL value as specified in [RFC3032]. If more than one MPLS label stack entry is reported, then multiple instances of elements of this type are used. They must be ordered in the same order as on the label stack with the top label stack entry being reported first.
o 説明 - プローブがプローブに応答したホップに到着したときに観察されたプローブのMPLSラベルスタックのエントリを指定します。このオブジェクトには、MPLSラベルスタックで観察されるように、1つのMPLSラベルスタックエントリが32ビット値として含まれています。この単一の数値に含まれるのは、[RFC3032]で指定されているように、MPLSラベル、EXPフィールド、Sフラグ、およびMPLS TTL値です。複数のMPLSラベルスタックエントリが報告されている場合、このタイプの要素の複数のインスタンスが使用されます。それらは、最初に報告されたトップレーベルスタックエントリを持つラベルスタックと同じ順序で注文する必要があります。
o dataType - unsignedInt
o DataType -UnsignedInt
o units - N/A
o 単位-N/A
o name - ProbeRoundTripTime
o 名前-ProberoundTriptime
o description - If this element contains the element "roundTripTime", this specifies the amount of time measured in milliseconds from when a probe was sent to when its response was received or when it timed out. The value of this element is reported as the truncation of the number reported by the traceroute tool (the output "< 1 ms" is therefore encoded as 0 ms). If it contains the element "roundTripTimeNotAvailable", it means either the probe was lost because of a timeout or it was not possible to transmit a probe.
o 説明 - この要素に「roundtriptime」要素が含まれている場合、これは、プローブが送信されたときから応答が受信されたとき、またはタイミングが上がったときにミリ秒単位で測定された時間を指定します。この要素の値は、Tracerouteツールによって報告された数の切り捨てとして報告されます（したがって、出力「<1 ms」は0ミリ秒としてエンコードされます）。「roundtriptimenotavaible」という要素が含まれている場合、タイムアウトのためにプローブが失われたか、プローブを送信することができなかったことを意味します。
o dataType - unsignedShort or string
o Datatype -unsignedshortまたは文字列
o units - milliseconds or N/A
o ユニット - ミリ秒またはn/a
o name - ResponseStatus
o 名前 - Restupdestatus
o description - Specifies the result of a traceroute measurement made by the host for a particular probe.
o 説明 - 特定のプローブのためにホストが作成したトレーサーアウト測定の結果を指定します。
o dataType - operationResponseStatus
o データ型 - 操作ResponseStatus
o units - N/A
o 単位-N/A
o name - Time
o 名前 - 時間
o description - Specifies the timestamp for the time the response to the probe was received at the interface.
o 説明 - プローブへの応答がインターフェイスで受信された時間のタイムスタンプを指定します。
o dataType - DateTime
o DataType -DateTime
o units - N/A
o 単位-N/A
o name - ResultsEndDateAndTime
o 名前 - resultsenddateandtime
o description - Specifies the date and end time of the traceroute measurement. It is either the time when the response to the last probe of the traceroute measurement was received or the time when the last probe of the traceroute measurement was sent plus the relative timeout (in case of a missing response).
o 説明 - Traceroute測定の日付と終了時間を指定します。トレーサーアウト測定の最後のプローブへの応答が受信された時期か、トレーサーアウト測定の最後のプローブが送信された時間と相対的なタイムアウト（反応が欠落している場合）の時間です。
o dataType - DateTime
o DataType -DateTime
o units - N/A
o 単位-N/A
o name - HopRawOutputData
o 名前-HopRawOutputData
o description - Specifies the raw output data returned by the traceroute measurement for a certain hop in a traceroute measurement path. It is an implementation-dependent, printable string, expected to be useful for a human interpreting the traceroute results.
o 説明 - Traceroute測定パスでの特定のホップのTraceroute測定によって返される生の出力データを指定します。これは、実装依存の印刷可能な文字列であり、人間がTracerouteの結果を解釈するのに役立つと予想されます。
o dataType - string
o データタイプ - 文字列
o units - N/A
o 単位-N/A
This section defines an additional element belonging to both previous groups (configuration elements and results elements) named "TestName". This element is defined in order to relate configuration and results elements by means of a common unique identifier (to be chosen in accordance to the specification of [RFC4560]).
このセクションでは、「TestName」という名前の以前のグループ（構成要素と結果要素）の両方に属する追加要素を定義します。この要素は、[RFC4560]の仕様に従って選択される共通の一意の識別子によって構成要素と結果要素を関連付けるために定義されます。
o name - TestName
o 名前-TestName
o description - Specifies the name of a traceroute measurement. This is not necessarily unique within any well-defined scope (e.g., a specific host, initiator of the traceroute measurement).
o 説明 - Traceroute測定の名前を指定します。これは、明確に定義された範囲内で必ずしも一意ではありません（たとえば、特定のホスト、Traceroute測定のイニシエーター）。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
This section defines additional elements belonging to both previous groups (configuration elements and results elements); these elements were defined in order to allow traceroute measurement results comparison among different traceroute measurements.
このセクションでは、以前のグループ（構成要素と結果要素）の両方に属する追加要素を定義します。これらの要素は、さまざまなトレーサーアウト測定間の測定結果の比較を可能にするために定義されました。
o name - OSName
o 名前 - osname
o description - Specifies the name of the operating system on which the traceroute measurement was launched. This element is ignored if used in the "RequestMetadata".
o 説明 - Traceroute測定が起動されたオペレーティングシステムの名前を指定します。この要素は、「requestmetadata」で使用される場合は無視されます。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
o name - OSVersion
o 名前 - Osversion
o description - Specifies the OS version on which the traceroute measurement was launched. This element is ignored if used in the "RequestMetadata".
o 説明 - Traceroute測定が起動されたOSバージョンを指定します。この要素は、「requestmetadata」で使用される場合は無視されます。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
o name - ToolVersion
o 名前 - ツールバージョン
o description - Specifies the version of the traceroute tool (requested to be used if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - Tracerouteツールのバージョンを指定します（「requestmetadata」要素で使用される場合は、「測定メタダタ」要素の場合に実際に使用される場合に使用するように使用されます）。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
o name - ToolName
o 名前 - ツール名
o description - Specifies the name of the traceroute tool (requested to be used if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element).
o 説明 - Tracerouteツールの名前を指定します（「requestmetadata」要素にある場合は、「測定メタダタ」要素の場合に実際に使用される場合に使用するように使用されます）。
o dataType - string255
o データタイプ-String255
o units - N/A
o 単位-N/A
For storing and transmitting information according to the information model defined in the previous section, a data model is required that specifies how to encode the elements of the information model.
前のセクションで定義されている情報モデルに従って情報を保存および送信するには、情報モデルの要素をエンコードする方法を指定するデータモデルが必要です。
There are several design choices for a data model. It can use a binary or textual representation and it can be defined from scratch or use already existing frameworks and data models. In general, the use of already existing frameworks and models should be preferred.
データモデルにはいくつかの設計選択があります。バイナリ表現またはテキスト表現を使用でき、ゼロから定義したり、既存のフレームワークとデータモデルを使用したりできます。一般に、すでに既存のフレームワークとモデルの使用を推奨する必要があります。
Binary and textual representations both have advantages and disadvantages. Textual representations are (with some limitations) human-readable, while a binary representation consumes less resources for storing, transmitting, and parsing data.
バイナリ表現とテキスト表現には、利点と短所があります。テキスト表現は（いくつかの制限があります）人間が読み取ることができますが、バイナリ表現はデータの保存、送信、および解析のためのリソースが少なくなります。
An already existing and closely related data model is the DISMAN-TRACEROUTE-MIB module [RFC4560], which specifies a Structure of Management Information version 2 (SMIv2) encoding [RFC2578], [RFC2579], and [RFC2580] for transmitting traceroute measurement information (configuration and results). This data model is well suited and supported within network management systems, but as a general format for storing and transmitting traceroute results, it is not easily applicable.
すでに存在し、密接に関連するデータモデルは、Disman-Traceroute-MIBモジュール[RFC4560]です。これは、トレーカルアウト測定情報を送信するための[RFC2578]、[RFC2579]、[RFC2579]、[RFC2580]をコードする管理情報バージョン2（SMIV2）の構造を指定します。（構成と結果）。このデータモデルは、ネットワーク管理システム内でよく適しており、サポートされていますが、Tracerouteの結果を保存および送信するための一般的な形式として、簡単に適用できません。
Another binary representation would be an extension of traffic-flow information encodings as specified for the IP Flow Information Export (IPFIX) protocol [RFC5101], [RFC5102]. The IPFIX protocol is extensible. However, the architecture behind this protocol [IPFIX] is targeted at exporting passively measured flow information. Therefore, some obstacles are expected when trying to use it for transmitting traceroute measurement information.
別のバイナリ表現は、IPフロー情報エクスポート（IPFIX）プロトコル[RFC5101]、[RFC5102]に指定されたトラフィックフロー情報エンコーディングの拡張です。IPFIXプロトコルは拡張可能です。ただし、このプロトコル[IPFIX]の背後にあるアーキテクチャは、受動的に測定されたフロー情報をエクスポートすることを目的としています。したがって、Traceroute測定情報を送信するためにそれを使用しようとする場合、いくつかの障害が予想されます。
For textual representations, using the eXtensible Markup Language (XML) [W3C.REC-xml-20060816] is an obvious choice. XML supports clean structuring of data and syntax checking of records. With some limitations, it is human-readable. It is supported well by a huge pool of tools and standards for generating, transmitting, parsing, and converting it to other data formats. Its disadvantages are the resource consumption for processing, storing, and transmitting information. Since the expected data volumes related to traceroute measurement in network operation and maintenance are not expected to be extremely high, the inefficient usage of resources is not a significant disadvantage. Therefore, XML was chosen as a basis for the traceroute measurement information model that is specified in this memo.
テキスト表現の場合、拡張可能なマークアップ言語（XML）[W3C.REC-XML-20060816]を使用することは明らかな選択です。XMLは、データのクリーン構造とレコードの構文チェックをサポートしています。いくつかの制限があるため、人間が読みやすいです。それは、それを他のデータ形式に生成、送信、解析、および変換するためのツールと標準の巨大なプールによってよくサポートされています。その短所は、情報の処理、保存、および送信のためのリソース消費です。ネットワークの操作とメンテナンスにおけるトレーサーアウト測定に関連する予想データ量は非常に高いと予想されるため、リソースの非効率的な使用は大きな不利益ではありません。したがって、XMLは、このメモで指定されているTraceroute測定情報モデルの基礎として選択されました。
Section 7 contains the XML schema to be used as a template for storing and/or exchanging traceroute measurement information. The schema was designed in order to use an extensible approach based on templates (pretty similar to how the IPFIX protocol is designed) where the traceroute configuration elements (both the requested parameters, "RequestMetadata", and the actual parameters used, "MeasurementMetadata") are metadata to be referenced by results information elements (data) by means of the "TestName" element (used as a unique identifier, chosen in accordance to the specification of [RFC4560]). Currently Open Grid Forum (OGF) is also using this approach and cross-requirements have been analyzed. As a result of this analysis, the XML schema contained in Section 7 is compatible with the OGF schema since both were designed in a way that limits the unnecessary redundancy and a simple one-to-one transformation between the two exists.
セクション7には、Traceroute測定情報を保存および/または交換するためのテンプレートとして使用されるXMLスキーマが含まれています。スキーマは、Traceroute構成要素（要求されたパラメーター「RequestMetadata」、および使用された実際のパラメーターの両方のテンプレート（IPFixプロトコルの設計方法とかなり似ています）に基づいた拡張可能なアプローチを使用するために設計されました。メタデータは、「testName」要素（[RFC4560]の仕様に従って選択された一意の識別子として使用される」要素によって結果情報要素（データ）によって参照されるものです。現在、Open Grid Forum（OGF）もこのアプローチを使用しており、交差要請が分析されています。この分析の結果、セクション7に含まれるXMLスキーマは、不必要な冗長性と2つの間の単純な1対1の変換を制限する方法で設計されているため、OGFスキーマと互換性があります。
This section presents the XML schema to be used as a template for storing and/or exchanging traceroute measurement information. The schema uses UTF-8 encoding as defined in [RFC3629]. In documents conforming to the format presented here, an XML declaration SHOULD be present specifying the version and the character encoding of the XML document. The document should be encoded using UTF-8. Since some of the strings can span multiple lines, [RFC5198] applies. XML processing instructions and comments MUST be ignored. Mind that whitespace is significant in XML when writing documents conforming to this schema. Documents using the presented format must be valid according to the XML schema shown in this section. Since elements of type "_CtlType" may contain elements from unknown namespaces, those elements MUST be ignored if their namespace is unknown to the processor. Values for elements using the XML schema type "dateTime" MUST be restricted to values defined in [RFC3339]. Future versions of this format MAY extend this schema by creating a new schema that redefines all or some of the data types and elements defined in this version or by establishing a complete new schema.
このセクションでは、Traceroute測定情報を保存および/または交換するためのテンプレートとして使用するXMLスキーマを示します。スキーマは、[RFC3629]で定義されているようにUTF-8エンコードを使用します。ここに示す形式に準拠したドキュメントでは、XMLドキュメントのバージョンと文字エンコードを指定するXML宣言が存在する必要があります。ドキュメントは、UTF-8を使用してエンコードする必要があります。一部の文字列は複数の線に及ぶ可能性があるため、[RFC5198]が適用されます。XML処理手順とコメントは無視する必要があります。このスキーマに準拠したドキュメントを作成する際に、XMLでWhitespaceが重要であることに注意してください。提示された形式を使用したドキュメントは、このセクションに示すXMLスキーマに従って有効でなければなりません。タイプ「_CTLTYPE」の要素には不明な名前空間の要素が含まれている可能性があるため、名前空間がプロセッサに不明な場合は、これらの要素を無視する必要があります。XMLスキーマタイプ「DateTime」を使用した要素の値は、[RFC3339]で定義された値に制限する必要があります。この形式の将来のバージョンは、このバージョンで定義されているすべてまたは一部を再定義する新しいスキーマを作成するか、完全な新しいスキーマを確立することにより、このスキーマを拡張する場合があります。
Due to the limited line length some lines appear wrapped.
線の長さが限られているため、いくつかの線が包まれているように見えます。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:traceroute-1.0"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tr="urn:ietf:params:xml:ns:traceroute-1.0">
<xs:simpleType name="string255">
<xs:annotation>
<xs:documentation>String restricted to 255
characters.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="u8nonzero">
<xs:annotation>
<xs:documentation>unsignedByte with non zero
value.</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_roundTripTime">
<xs:choice>
<xs:element name="roundTripTime">
<xs:simpleType>
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
</xs:element>
<xs:element name="roundTripTimeNotAvailable">
<xs:complexType/>
</xs:element>
</xs:choice>
</xs:complexType>
<xs:complexType name="_inetAddressUnknown"/>
<xs:simpleType name="_inetAddressIpv4">
<xs:restriction base="xs:string">
<xs:pattern value="(([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5
]).){3}([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressIpv6">
<xs:restriction base="xs:string">
<xs:pattern value="(([\dA-Fa-f]{1,4}:){7}[\dA-Fa-f]{1,4})(:([\d
]{1,3}.){3}[\d]{1,3})?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressDns">
<xs:restriction base="xs:string">
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_inetAddressASNumber">
<xs:annotation>
<xs:documentation>Specifies the AS number of a hop in the
traceroute path as a 32-bit number and indicates how the
mapping from IP address to AS number was
performed.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="asNumber" type="xs:unsignedInt"/>
<xs:element name="ipASNumberMappingType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="bgptables"/>
<xs:enumeration value="routingregistries"/>
<xs:enumeration value="nslookup"/>
<xs:enumeration value="others"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="inetAddress">
<xs:choice>
<xs:element name="inetAddressUnknown"
type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
<xs:element minOccurs="0" name="inetAddressDns"
type="tr:_inetAddressDns"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="inetAddressWithoutDns">
<xs:sequence>
<xs:choice>
<xs:element name="inetAddressUnknown"
type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4"
type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6"
type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="operationResponseStatus">
<xs:restriction base="xs:string">
<xs:enumeration value="responseReceived"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="internalError"/>
<xs:enumeration value="requestTimedOut"/>
<xs:enumeration value="unknownDestinationAddress"/>
<xs:enumeration value="noRouteToTarget"/>
<xs:enumeration value="interfaceInactiveToTarget"/>
<xs:enumeration value="arpFailure"/>
<xs:enumeration value="maxConcurrentLimitReached"/>
<xs:enumeration value="unableToResolveDnsName"/>
<xs:enumeration value="invalidHostAddress"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="_CtlType">
<xs:choice>
<xs:element name="TCP">
<xs:complexType/>
</xs:element>
<xs:element name="UDP">
<xs:complexType/>
</xs:element>
<xs:element name="ICMP">
<xs:complexType/>
</xs:element>
<xs:any namespace="##other"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="_ProbeResults">
<xs:sequence>
<xs:element maxOccurs="255" name="hop">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="10" name="probe">
<xs:complexType>
<xs:sequence>
<xs:element name="HopAddr"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the address of a
hop in the traceroute measurement path. This
object is not allowed to be a DNS name. The
address type can be determined by examining the
"inetAddress" type name and the corresponding
element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="HopName"
type="tr:_inetAddressDns">
<xs:annotation>
<xs:documentation>Specifies the DNS name of
the "HopAddr" if it is available. If it is
not available, the element is
omitted.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="255" minOccurs="0" name="MPLSLabelStackEntry"> <xs:annotation> <xs:documentation>Specifies entries of the MPLS label stack of a probe observed when the probe arrived at the hop that replied to the probe. This object contains one MPLS label stack entry as a 32-bit value as it is observed on the MPLS label stack. Contained in this single number are the MPLS label, the Exp field, the S flag, and the MPLS TTL value as specified in [RFC3032]. If more than one MPLS label stack entry is reported, then multiple instances of elements of this type are used. They must be ordered in the same order as on the label stack with the top label stack entry being reported first.</xs:documentation> </xs:annotation>
<xs：element maxoccurs = "255" minoccurs = "0" name = "mplslabelstackentry"> <xs：annotation> <xs：documentation> Probeが到着したときに観察されたプローブのMPLSラベルスタックのエントリを指定します。プローブに。このオブジェクトには、MPLSラベルスタックで観察されるように、1つのMPLSラベルスタックエントリが32ビット値として含まれています。この単一の数値に含まれるのは、[RFC3032]で指定されているように、MPLSラベル、EXPフィールド、Sフラグ、およびMPLS TTL値です。複数のMPLSラベルスタックエントリが報告されている場合、このタイプの要素の複数のインスタンスが使用されます。それらは、最初に報告されたトップレーベルスタックエントリが記載されたラベルスタックと同じ順序で注文する必要があります。
<xs:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:maxInclusive value="4294967295"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ProbeRoundTripTime" type="tr:_roundTripTime"> <xs:annotation> <xs:documentation>If this element contains the element "roundTripTime", this specifies the amount of time measured in milliseconds from when a probe was sent to when its response was received or when it timed out. The value of this element is reported as the truncation of the number reported by the traceroute tool (the output "< 1 ms" is therefore encoded as 0 ms). If it contains the element
<xs：要素名= "proberoundtriptime" type = "tr：_roundtriptime"> <xs：annotation> <xs：documentation>この要素に「roundtriptime "が含まれている場合、これはプローブがいつから測定された時間を指定します。その応答が受信されたときまたはタイミングを出したときに送信されました。この要素の値は、Tracerouteツールによって報告された数の切り捨てとして報告されます（したがって、出力 "＆lt; 1 ms"は0 msとしてエンコードされます）。要素が含まれている場合
"roundTripTimeNotAvailable", it means either
the probe was lost because of a timeout or it
was not possible to transmit a probe.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResponseStatus"
type="tr:operationResponseStatus">
<xs:annotation>
<xs:documentation>Specifies the result of a
traceroute measurement made by the host for a
particular probe.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="Time" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the timestamp for
the time the response to the probe was
received at the interface.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="HopRawOutputData"
type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the raw output data
returned by the traceroute measurement for a
certain hop in a traceroute measurement path. It is
an implementation-dependent, printable string,
expected to be useful for a human interpreting the
traceroute results.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_Metadata">
<xs:annotation>
<xs:documentation>Specifies the metadata for a traceroute
operation -- the parameters requested if used in
"RequestMetadata" or the actual parameters used if used in
"MeasurementMetadata".</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="TestName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of a traceroute
measurement. This is not necessarily unique within any
well-defined scope (e.g., a specific host, initiator of
the traceroute measurement).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="OSName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of the operating
system on which the traceroute measurement was launched.
This element is ignored if used in the
"RequestMetadata".</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="OSVersion" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the OS version on which the
traceroute measurement was launched. This element is
ignored if used in the
"RequestMetadata".</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="ToolVersion" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the version of the traceroute
tool (requested to be used if in the "RequestMetadata"
element, actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="" name="ToolName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of the traceroute
tool (requested to be used if in the "RequestMetadata"
element, actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="CtlTargetAddress" type="tr:inetAddress">
<xs:annotation>
<xs:documentation>In the "RequestMetadata" element, it
specifies the host address requested to be used in the
traceroute measurement. In the "MeasurementMetadata"
element, it specifies the host address used in the
traceroute measurement. The host address type can be
determined by examining the "inetAddress" type name and
the corresponding element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="false" name="CtlBypassRouteTable"
type="xs:boolean">
<xs:annotation>
<xs:documentation>In the "RequestMetadata" element
specifies if the optional bypassing of the route
table was enabled or not. In the "MeasurementMetadata"
element, specifies if the optional bypassing of the route
table was enabled or not. If enabled, the normal routing
tables will be bypassed and the probes will be sent
directly to a host on an attached network. If the host is
not on a directly attached network, an error is returned.
This option can be used to perform the traceroute
measurement to a local host through an interface that has
no route defined. This object can be used when the
setsockopt SOL_SOCKET SO_DONTROUTE option is supported and
set (see the POSIX standard IEEE.1003-1G.1997).
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlProbeDataSize"> <xs:annotation> <xs:documentation>Specifies the size of the probes of a traceroute measurement in octets (requested if in the "RequestMetadata" element, actually used if in the "MeasurementMetadata" element). If UDP datagrams are used as probes, then the value contained in this object is exact. If another protocol is used to transmit probes (i.e., TCP or ICMP) for which the specified size is not appropriate, then the implementation can use whatever size (appropriate to the method) is closest to the specified size. The maximum value for this object is computed by subtracting the smallest possible IP header size of 20 octets (IPv4 header with no options) and the UDP header size of 8 octets from the maximum IP packet size. An IP packet has a maximum size of 65535 octets (excluding IPv6 jumbograms).</xs:documentation> </xs:annotation>
<xs：要素default = "0" name = "ctlprobedatasize"> <xs：annotation> <xs：documentation>オクテットのトレーサーアウト測定のプローブのサイズのサイズを指定します（「requestmetadata」要素で実際に使用される「requestmetadata」要素の場合は要求されます。「測定メタダタ」要素で）。UDPデータグラムがプローブとして使用される場合、このオブジェクトに含まれる値は正確です。指定されたサイズが適切でないプローブ（つまり、TCPまたはICMP）を送信するために別のプロトコルを使用している場合、実装は指定されたサイズに最も近いサイズ（メソッドに適した）を使用できます。このオブジェクトの最大値は、可能な限り小さなIPヘッダーサイズ20オクテット（オプションなしのIPv4ヘッダー）と最大IPパケットサイズから8オクテットのUDPヘッダーサイズを減算することにより計算されます。IPパケットの最大サイズは65535オクテット（IPv6ジャンボグラムを除く）です。</xs：ドキュメント> </xs：annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:maxInclusive value="65507"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="3" name="CtlTimeOut">
<xs:annotation>
<xs:documentation>Specifies the timeout value, in
seconds, for each probe of a traceroute measurement
(requested if in the "RequestMetadata" element, actually
used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="60"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="3" name="CtlProbesPerHop">
<xs:annotation>
<xs:documentation>Specifies the number of probes with the
same time-to-live (TTL) value that are sent for each host
(requested if in the "RequestMetadata" element, actually
used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedByte">
<xs:minInclusive value="1"/>
<xs:maxInclusive value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="33434" name="CtlPort">
<xs:annotation>
<xs:documentation>Specifies the base port used by the
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element default="30" name="CtlMaxTtl" type="tr:u8nonzero">
<xs:annotation>
<xs:documentation>Specifies the maximum TTL value for the
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlDSField" type="xs:unsignedByte"> <xs:annotation> <xs:documentation>Specifies the value that was requested to be stored in the Differentiated Services (DS) field in the traceroute probe (if in the "RequestMetadata" element). Specifies the value that was stored in the Differentiated Services (DS) field in the traceroute probe (if in the "MeasurementMetadata" element). The DS field is defined as the Type of Service (TOS) octet in an IPv4 header or as the Traffic Class octet in an IPv6 header (see Section 7 of [RFC2460]). The value of this object must be a decimal integer in the range from 0 to 255. This option can be used to determine what effect an explicit DS field setting has on a traceroute measurement and its probes. Not all values are legal or meaningful. Useful TOS octet values are probably 16 (low delay) and 8 (high throughput). Further references can be found in [RFC2474] for the definition of the Differentiated Services (DS) field and in [RFC1812] Section 5.3.2 for Type of Service (TOS).</xs:documentation> </xs:annotation> </xs:element>
<xs：要素default = "0" name = "ctldsfield" type = "xs：unsignedbyte"> <xs：annotation> <xs：documentation>差別化されたサービス（DS）フィールドに保存されるように要求された値を指定します。Tracerouteプローブ（「requestmetadata」要素の場合）。Tracerouteプローブの差別化されたサービス（DS）フィールドに保存された値を指定します（「測定メタダタ」要素の場合）。DSフィールドは、IPv4ヘッダーのサービスのタイプ（TOS）Octet、またはIPv6ヘッダーのトラフィッククラスOctetとして定義されます（[RFC2460]のセクション7を参照）。このオブジェクトの値は、0〜255の範囲の小数整数でなければなりません。このオプションは、明示的なDSフィールド設定がTraceroute測定とそのプローブにどのような影響を与えるかを決定するために使用できます。すべての価値が合法的または意味があるわけではありません。有用なTOSオクテット値は、おそらく16（低遅延）および8（高スループット）です。詳細な参照は、[RFC2474]に、差別化されたサービス（DS）フィールドの定義について、および[RFC1812]セクション5.3.2のサービス（TOS）のセクション5.3.2に記載されています。/XS：要素>
<xs:element name="CtlSourceAddress"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the IP address (which has to
be given as an IP number, not a hostname) as the source
address in traceroute probes (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). On hosts with more than
one IP address, this option can be used in the
"RequestMetadata" element to force the source address to
be something other than the primary IP address of the
interface the probe is sent on; the value "unknown" means
the default address will be used. The address type can be
determined by examining the "inetAddress" type name and the
corresponding element value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="0" name="CtlIfIndex"
type="xs:unsignedInt">
<xs:annotation>
<xs:documentation>Specifies the interface index as
defined in [RFC2863] that is requested to be used in the
traceroute measurement for sending the traceroute probes
(if in the "RequestMetadata" element). A value of 0
indicates that no specific interface is requested.
Specifies the interface index actually used (if in the
"MeasurementMetadata" element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element minOccurs="0" name="CtlMiscOptions"
type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies implementation-dependent
options (requested if in the "RequestMetadata" element,
actually used if in the "MeasurementMetadata"
element).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="5" name="CtlMaxFailures"
type="xs:unsignedByte">
<xs:annotation>
<xs:documentation>Specifies the maximum number of
consecutive timeouts allowed before terminating a
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). A value of either 255 (maximum hop count/possible TTL value) or 0 indicates that the function of terminating a remote traceroute measurement when a specific number of consecutive timeouts are detected was disabled. This element is included to give full compatibility with [RFC4560]. No known implementation of traceroute currently supports it.</xs:documentation> </xs:annotation> </xs:element>
「MeasurementMetadata」要素）。255（最大ホップカウント/可能なTTL値）または0の値は、特定の数の連続したタイムアウトが検出されたときのリモートトレーサーアウト測定を終了する機能が無効になったことを示しています。この要素は、[RFC4560]との完全な互換性を与えるために含まれています。Tracerouteの既知の実装は現在それをサポートしていません。
<xs:element default="false" name="CtlDontFragment"
type="xs:boolean">
<xs:annotation>
<xs:documentation>Specifies if the don't fragment (DF)
flag in the IP header for a probe was enabled or not (if
in the "MeasurementMetadata" element). If in the
"RequestMetadata", it specifies if the flag was requested
to be enabled or not. Setting the DF flag can be used for
performing a manual PATH MTU test.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element default="1" name="CtlInitialTtl"
type="tr:u8nonzero">
<xs:annotation>
<xs:documentation>Specifies the initial TTL value for a
traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). Such TTL setting is
intended to bypass the initial (often well-known) portion
of a path.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element maxOccurs="1" minOccurs="0" name="CtlDescr"
type="tr:string255">
<xs:annotation>
<xs:documentation>Provides a description of the traceroute
measurement.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="CtlType" type="tr:_CtlType">
<xs:annotation>
<xs:documentation>Specifies the implementation method
used for the traceroute measurement (requested if in the
"RequestMetadata" element, actually used if in the
"MeasurementMetadata" element). It specifies if the
traceroute is using TCP, UDP, ICMP, or other types of
probes. It is possible to specify other types of probes
by using an element specified in another schema with a
different namespace.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_Measurement">
<xs:annotation>
<xs:documentation>Contains the actual traceroute measurement
results.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="TestName" type="tr:string255">
<xs:annotation>
<xs:documentation>Specifies the name of a traceroute
measurement. This is not necessarily unique within any
well-defined scope (e.g., a specific host, initiator of
the traceroute measurement).</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResultsStartDateAndTime" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the date and start time of
the traceroute measurement. This is the time when the
first probe was seen at the sending
interface.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ResultsIpTgtAddr"
type="tr:inetAddressWithoutDns">
<xs:annotation>
<xs:documentation>Specifies the IP address associated
with a "CtlTargetAddress" value when the destination
address is specified as a DNS name. The value of this
object should be "unknown" if a DNS name is not specified
or if a specified DNS name fails to resolve. The
address type can be determined by examining the "inetAddress"
type name and the corresponding element
value.</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ProbeResults" type="tr:_ProbeResults"/>
<xs:element name="ResultsEndDateAndTime" type="xs:dateTime">
<xs:annotation>
<xs:documentation>Specifies the date and end time of the
traceroute measurement. It is either the time when the
response to the last probe of the traceroute measurement
was received or the time when the last probe of the
traceroute measurement was sent plus the relative timeout
(in case of a missing response).</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="traceRoute">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="RequestMetadata"
type="tr:_Metadata"/>
<xs:element maxOccurs="2147483647" minOccurs="0"
name="Measurement">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="MeasurementMetadata"
type="tr:_Metadata"/>
<xs:element maxOccurs="2147483647" minOccurs="0"
name="MeasurementResult"
type="tr:_Measurement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Security considerations discussed in this section are grouped into considerations related to conducting traceroute measurements and considerations related to storing and transmitting traceroute measurement information.
このセクションで説明するセキュリティ上の考慮事項は、トレーサー測定の実施に関連する考慮事項と、トレーサーアウト測定情報の保存と送信に関連する考慮事項にグループ化されています。
This memo does not specify an implementation of a traceroute tool. Neither does it specify a certain procedure for storing traceroute measurement information. Still, it is considered desirable to discuss related security issues below.
このメモは、Tracerouteツールの実装を指定していません。また、Traceroute測定情報を保存するための特定の手順を指定しません。それでも、以下の関連するセキュリティの問題を議論することが望ましいと考えられています。
Conducting Internet measurements can raise both security and privacy concerns. Traceroute measurements, in which traffic is injected into the network, can be abused for denial-of-service attacks disguised as legitimate measurement activity.
インターネット測定を実施すると、セキュリティとプライバシーの両方の懸念を引き起こす可能性があります。トラフィックがネットワークに注入されるTraceroute測定は、正当な測定活動に変装したサービス拒否攻撃のために乱用することができます。
Measurement parameters MUST be carefully selected so that the measurements inject trivial amounts of additional traffic into the networks they measure. If they inject "too much" traffic, they can skew the results of the measurement, and in extreme cases cause congestion and denial of service.
測定パラメーターは、測定されるネットワークに測定量の追加トラフィックを注入するように、慎重に選択する必要があります。「多すぎる」トラフィックを注入すると、測定の結果をゆがめる可能性があり、極端な場合には混雑とサービスの拒否を引き起こす可能性があります。
The measurements themselves could be harmed by routers giving measurement traffic a different priority than "normal" traffic, or by an attacker injecting artificial measurement traffic. If routers can recognize measurement traffic and treat it separately, the measurements will not reflect actual user traffic. If an attacker injects artificial traffic that is accepted as legitimate, the loss rate will be artificially lowered. Therefore, the measurement methodologies SHOULD include appropriate techniques to reduce the probability that measurement traffic can be distinguished from "normal" traffic.
測定自体は、「通常の」トラフィックとは異なる優先度を測定するルーターによって、または人工測定トラフィックを注入する攻撃者によって害を与える可能性があります。ルーターが測定トラフィックを認識し、個別に処理できる場合、測定値は実際のユーザートラフィックを反映しません。攻撃者が合法として受け入れられている人工トラフィックを注入すると、損失率は人為的に低下します。したがって、測定方法には、測定トラフィックが「通常の」トラフィックと区別できる確率を減らすための適切な手法を含める必要があります。
Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks.
デジタル署名などの認証技術は、必要に応じて、注入された交通攻撃を防ぐために使用できます。
Traceroute measurement information is not considered highly sensitive. Still, it may contain sensitive information on network paths, routing states, used IP addresses, and roundtrip times that operators of networks may want to protect for business or security reasons.
Traceroute測定情報は、あまり感度が高いとは見なされません。それでも、ネットワークパス、ルーティング状態、使用済みのIPアドレス、およびネットワークのオペレーターがビジネスまたはセキュリティの理由で保護したいと思う往復時間に関する機密情報が含まれている場合があります。
It is thus important to control access to information acquired by conducting traceroute measurements, particularly when transmitting it over a networks but also when storing it. It is RECOMMENDED that a transmission of traceroute measurement information over a network uses appropriate protection mechanisms for preserving privacy, integrity, and authenticity. It is further RECOMMENDED that secure authentication and authorization are used for protecting stored traceroute measurement information.
したがって、Traceroute測定を実施することで獲得した情報へのアクセスを制御することが重要です。特に、ネットワークを介して送信する場合だけでなく、保存する際にも測定することが重要です。ネットワーク上のTraceroute測定情報の送信は、プライバシー、整合性、および信頼性を維持するために適切な保護メカニズムを使用することをお勧めします。さらに、保存されたTraceroute測定情報を保護するために、安全な認証と承認を使用することをお勧めします。
This document uses URNs to describe an XML namespace and an XML schema for traceroute measurement information storing and transmission, conforming to a registry mechanism described in [RFC3688]. Two URI assignments have been made.
このドキュメントでは、URNSを使用して、[RFC3688]に記載されているレジストリメカニズムに準拠して、Traceroute測定情報の保存と送信用のXMLネームスペースとXMLスキーマを記述します。2つのURI割り当てが行われました。
1. Registration for the IPPM traceroute measurements namespace
1. IPPM Traceroute測定の名前空間の登録
* URI: urn:ietf:params:xml:ns:traceroute-1.0
* uri：urn：ietf：params：xml：ns：traceroute-1.0
* Registrant Contact: IESG
* 登録者の連絡先：IESG
* XML: None. Namespace URIs do not represent an XML.
* XML：なし。名前空間urisはXMLを表しません。
2. Registration for the IPPM traceroute measurements schema
2. IPPM Traceroute測定スキーマの登録
* URI: urn:ietf:params:xml:schema:traceroute-1.0
* uri：urn：ietf：params：xml：schema：traceroute-1.0
* Registrant Contact: IESG
* 登録者の連絡先：IESG
* XML: See Section 7 of this document.
* XML：このドキュメントのセクション7を参照してください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339] Klyne、G.、ed。C.ニューマン、「インターネット上の日時：タイムスタンプ」、RFC 3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.
[RFC4001] Daniele、M.、Haberman、B.、Routhier、S。、およびJ. Schoenwaelder、「インターネットネットワークアドレスのテキストコンベンション」、RFC 4001、2005年2月。
[RFC4560] Quittek, J. and K. White, "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, June 2006.
[RFC4560] Quittek、J。およびK. White、「リモートPing、Traceroute、およびLookup操作の管理されたオブジェクトの定義」、RFC 4560、2006年6月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「ネットワークインターチェンジのユニコード形式」、RFC 5198、2008年3月。
[IEEE.1003-1G.1997] Institute of Electrical and Electronics Engineers, "Protocol Independent Interfaces", IEEE Standard 1003.1G, March 1997.
[IEEE.1003-1G.1997]電気およびエレクトロニクスエンジニアの研究所、「プロトコル独立インターフェース」、IEEE Standard 1003.1G、1997年3月。
[IPFIX] Sadasivan, G., "Architecture for IP Flow Information Export", Work in Progress, September 2006.
[IPFIX] Sadasivan、G。、「IP Flow Information Exportのアーキテクチャ」、2006年9月、進行中の作業。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Ed。、Perkins、D.、ed。、およびJ. Schoenwaelder、ed。、「Smiv2のテキストコンベンション」、STD 58、RFC 2579、1999年4月。
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101] Claise、B。、「IPトラフィックフロー情報の交換のためのIPフロー情報エクスポート（IPFIX）プロトコルの仕様」、RFC 5101、2008年1月。
[RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", RFC 5102, January 2008.
[RFC5102] Quittek、J.、Bryant、S.、Claise、B.、Aitken、P。、およびJ. Meyer、「IPフロー情報エクスポートの情報モデル」、RFC 5102、2008年1月。
[W3C.REC-xml-20060816] Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-XML-20060816] Bray、T.、Paoli、J.、Maler、E.、Sperberg-Mcqueen、C。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、World Wide Web Consortium Firstedition REC-XML-20060816、2006年8月、<http://www.w3.org/tr/2006/REC-XML-20060816>。
[W3C.REC-xmlschema-2-20041028] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-XMLSCHEMA-2-20041028] Biron、P。およびA. Malhotra、「XML Schema Part 2：DataTypes Second Edition」、World Wide Webコンソーシアムの推奨REC-XMLSCHEMA-20041028、2004年10月、<http：//www.w3.org/tr/2004/rec-xmlschema-2-20041028>。
This section lists traceroute measurement configuration parameters as well as their defaults on various platforms and illustrates how widely they may vary. This document considers four major traceroute tool implementations and compares them based on configurable parameters and default values. The LINUX (SUSE 9.1), BSD (FreeBSD 7.0), and UNIX (SunOS 5.9) implementations are based on UDP datagrams, while the WINDOWS (XP SP2) one uses ICMP Echoes. The comparison is summarized in the following table, where an N/A in the option column means that such parameter is not configurable for the specific implementation. A comprehensive comparison of available implementations is outside the scope of this document; however, by sampling a few different implementations, it can be observed that they can differ quite significantly in terms of configurable parameters and also default values. Note that in the following table only those options that are available in at least two of the considered implementations are reported.
このセクションでは、Traceroute測定構成パラメーターと、さまざまなプラットフォームでのデフォルトを示し、それらがどれだけ変化するかを示しています。このドキュメントでは、4つの主要なTracerouteツールの実装を考慮し、構成可能なパラメーターとデフォルト値に基づいてそれらを比較します。Linux（Suse 9.1）、BSD（FreeBSD 7.0）、およびUNIX（SUNOS 5.9）の実装はUDPデータグラムに基づいており、Windows（XP SP2）はICMPエコーを使用します。比較は次の表に要約されています。ここでは、オプション列のN/Aは、そのようなパラメーターが特定の実装のために構成できないことを意味します。利用可能な実装の包括的な比較は、このドキュメントの範囲外です。ただし、いくつかの異なる実装をサンプリングすることにより、構成可能なパラメーターとデフォルト値の点で非常に大きく異なる可能性があることが観察できます。次の表では、考慮された実装の少なくとも2つで利用可能なオプションのみが報告されていることに注意してください。
+---------------------------------------------------------+
| OS |Option| Description | Default |
+--------+------+-------------------------------+---------+
| LINUX | -m |Specify the maximum TTL used | 30 |
|--------+------|in traceroute probes. |---------|
| FreeBSD| -m | | OS var |
|--------+------| |---------|
| UNIX | -m | | 30 |
|--------+------| |---------|
| WINDOWS| -h | | 30 |
+--------+------+-------------------------------+---------+
| LINUX | -n |Display hop addresses | - |
|--------+------|numerically rather than |---------|
| FreeBSD| -n |symbolically. | - |
|--------+------| |---------|
| UNIX | -n | | - |
|--------+------| |---------|
| WINDOWS| -d | | - |
+--------+------+-------------------------------+---------+
| LINUX | -w |Set the time to wait for a | 3 sec |
|--------+------|response to a probe. |---------|
| FreeBSD| -w | | 5 sec |
|--------+------| |---------|
| UNIX | -w | | 5 sec |
|--------+------| |---------|
| WINDOWS| -w | | 4 sec |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Specify a loose source route | - |
|--------+------|gateway (to direct the |---------|
| FreeBSD| -g |traceroute probes through | - |
|--------+------|routers not necessarily in |---------|
| UNIX | -g | the path). | - |
|--------+------| |---------|
| WINDOWS| -g | | - |
+--------+------+-------------------------------+---------+
| LINUX | -p |Set the base UDP port number | 33434 |
|------- +------|used in traceroute probes |---------|
| FreeBSD| -p |(UDP port = base + nhops - 1). | 33434 |
|--------+------| |---------|
| UNIX | -p | | 33434 |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -q |Set the number of probes per | 3 |
|--------+------|TTL. |---------|
| FreeBSD| -q | | 3 |
|--------+------| |---------|
| UNIX | -q | | 3 |
|--------+------| |---------|
| WINDOWS| N/A | | 3 |
+--------+------+-------------------------------+---------+
| LINUX | -S |Set the IP source address in |IP |
|--------+------|outgoing probes to the |address |
| FreeBSD| -s |specified value. |of the |
|--------+------| |out |
| UNIX | -s | |interface|
|--------+------| | |
| WINDOWS| N/A | | |
+--------+------+-------------------------------+---------+
| LINUX | -t |Set the Type of Service (TOS) | 0 |
|--------+------|in the probes to the specified |---------|
| FreeBSD| -t |value. | 0 |
|--------+------| |---------|
| UNIX | -t | | 0 |
|--------+------| |---------|
| WINDOWS| N/A | | 0 |
+--------+------+-------------------------------+---------+
| LINUX | -v |Verbose output: received ICMP | - |
|--------+------|packets other than |---------|
| FreeBSD| -v |TIME_EXCEEDED and | - |
|--------+------|UNREACHABLE are listed. |---------|
| UNIX | -v | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Set the time (in msec) to | - |
|--------+------|pause between probes. |---------|
| FreeBSD| -z | | 0 |
|--------+------| |---------|
| UNIX | -P | | 0 |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -r |Bypass the normal routing | - |
|--------+------|tables and send directly to a |---------|
| FreeBSD| -r |host on attached network. | - |
|--------+------| |---------|
| UNIX | -r | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -f |Set the initial TTL for the | 1 |
|--------+------|first probe. |---------|
| FreeBSD| -f | | 1 |
|--------+------| |---------|
| UNIX | -f | | 1 |
|--------+------| |---------|
| WINDOWS| N/A | | 1 |
+--------+------+-------------------------------+---------+
| LINUX | -F |Set the "don't fragment" bit. | - |
|--------+------| |---------|
| FreeBSD| -F | | - |
|--------+------| |---------|
| UNIX | -F | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Enable socket level debugging. | - |
|--------+------| |---------|
| FreeBSD| -d | | - |
|--------+------| |---------|
| UNIX | -d | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Use ICMP Echoes instead of UDP | - |
|--------+------|datagrams. |---------|
| FreeBSD| -I | | - |
|--------+------| |---------|
| UNIX | -I | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | -I |Specify a network interface to | - |
|--------+------|obtain the IP address for |---------|
| FreeBSD| -i |outgoing IP packets | - |
|--------+------|(alternative to option -s). |---------|
| UNIX | -i | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | N/A |Toggle checksum. | - |
|--------+------| |---------|
| FreeBSD| -x | | - |
|--------+------| |---------|
| UNIX | -x | | - |
|--------+------| |---------|
| WINDOWS| N/A | | - |
+--------+------+-------------------------------+---------+
| LINUX | - |As optional last parameter, |Depends |
|--------+------|LINUX, FreeBSD, and UNIX |on |
| FreeBSD| - |implementations allow |implement|
|--------+------|specifying the probe datagram |ation. |
| UNIX | - |length for outgoing probes. | |
|--------+------| | |
| WINDOWS| N/A | | |
+--------+------+-------------------------------+---------+
As stated above, the widespread use of firewalls might prevent UDP-or ICMP-based traceroutes to completely trace the path to a destination since traceroute probes might end up being filtered. In some cases, such limitation might be overcome by sending instead TCP packets to specific ports that hosts located behind the firewall are listening for connections on. TCP-based implementations use TCP, SYN, or FIN probes and listen for TIME_EXCEEDED messages, TCP RESET, and other messages from firewalls and gateways on the path. On the other hand, some firewalls filter out TCP SYN packets to prevent denial-of-service attacks; therefore, the actual advantage of using TCP instead of UDP traceroute depends mainly on firewall configurations, which are not known in advance. A detailed analysis of TCP-based traceroute tools and measurements is outside the scope of this document; regardless, for completeness reasons, the information model also supports the storing of TCP-based traceroute measurements.
上記のように、ファイアウォールの広範な使用は、UDPまたはICMPベースのトレーサーアウトを防ぎ、Tracerouteプローブがフィルタリングされる可能性があるため、目的地へのパスを完全に追跡することができます。場合によっては、そのような制限は、ファイアウォールの後ろにあるホストが接続を聞いている特定のポートにTCPパケットを送信することにより克服される場合があります。TCPベースの実装は、TCP、SYN、またはFINプローブを使用し、Time_Exceedメッセージ、TCPリセット、およびパス上のファイアウォールやゲートウェイからのその他のメッセージをリッスンします。一方、一部のファイアウォールは、サービス拒否攻撃を防ぐためにTCP Synパケットを除外します。したがって、UDP Tracerouteの代わりにTCPを使用するという実際の利点は、主にファイアウォールの構成に依存しますが、これは事前に知られていません。TCPベースのTracerouteツールと測定の詳細な分析は、このドキュメントの範囲外です。とにかく、完全な理由で、情報モデルはTCPベースのTraceroute測定の保存もサポートしています。
Because of implementation choices, a known inconsistency exists between the round-trip delay metric defined by the IPPM working group in RFC 2681 and the results returned by the current traceroute tool implementations. Unfortunately, it is unlikely that the traceroute tool implementations will implement the standard definition in the near future. The only possibility is therefore to compare results of different traceroute measurements with each other; in order to do this, specifications both of the operating system (name and version) and of the traceroute tool version used were added to the metadata elements in order to help in comparing metrics between two different traceroute measurement results (if run using the same operating system and the same version of the tool). Moreover, the traceroute tool has built-in configurable mechanisms like timeouts and can experience problems related to the crossing of firewalls; therefore, some of the packets that traceroute sends out end up being timeout or filtered. As a consequence, it might not be possible to trace the path to a node or there might not be a complete enough set of probes describing the RTT to reach it.
実装の選択により、RFC 2681のIPPMワーキンググループによって定義された往復遅延メトリックと、現在のTracerouteツールの実装によって返された結果の間には、既知の矛盾が存在します。残念ながら、Tracerouteツールの実装が近い将来に標準の定義を実装する可能性は低いです。したがって、唯一の可能性は、異なるトレーサー測定の結果を互いに比較することです。これを行うために、2つの異なるTraceroute測定結果の間のメトリックを比較するのに役立つオペレーティングシステム（名前とバージョン）とTracerouteツールバージョンの両方の仕様がメタデータ要素に追加されました（同じオペレーティングを使用して実行される場合システムと同じバージョンのツール）。さらに、Tracerouteツールには、タイムアウトなどの構成可能なメカニズムが組み込まれており、ファイアウォールの交差に関連する問題が発生する可能性があります。したがって、Tracerouteが送信するパケットの一部は、最終的にタイムアウトまたはフィルタリングされています。結果として、ノードへのパスをトレースすることは不可能であるか、RTTを記述するプローブの完全なセットが到達していない場合があります。
For performing remote traceroute operations at managed node, the IETF has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This module allows:
Managed NodeでリモートTraceroute操作を実行するために、IETFは[RFC4560]のDisman-Traceroute-Mibモジュールを標準化しました。このモジュールは次のことを許可します。
o retrieving capability information of the traceroute tool implementation at the managed node;
o 管理されたノードでのTracerouteツール実装の機能情報を取得します。
o configuring traceroute measurements to be performed;
o 実行するTraceroute測定の構成。
o retrieving information about ongoing and completed traceroute measurements;
o 進行中および完了したトレーサーアウト測定に関する情報の取得。
o retrieving traceroute measurement statistics.
o Traceroute測定統計の取得。
The traceroute storage format described in this document has significant overlaps with this MIB module. Particularly, the models for the traceroute measurement configuration and for the results from completed measurements are almost identical. But for other parts of the DISMAN-TRACEROUTE MIB module there is no need to model them in a traceroute measurement storage format. Particularly, the capability information, information about ongoing measurements, and measurement statistics are not covered by the DISMAN traceroute storage model.
このドキュメントで説明されているTracerouteストレージ形式には、このMIBモジュールとの重大な重複があります。特に、Traceroute測定構成と完了した測定の結果のモデルはほぼ同じです。しかし、Disman-Traceroute MIBモジュールの他の部分では、Traceroute測定ストレージ形式でそれらをモデル化する必要はありません。特に、機能情報、進行中の測定に関する情報、および測定統計は、ディスマントレーサーアウトストレージモデルではカバーされていません。
Concerning traceroute measurements and their results, there are structural differences between the two models caused by the different choices for the encoding of the specification. For DISMAN-TRACEROUTE-MIB, the Structure of Management Information (SMIv2, STD 58, RFC 2578 [RFC2578]) was used, while the IPPM traceroute measurement data model is encoded using XML.
Traceroute測定とその結果に関して、仕様のエンコードのための異なる選択によって引き起こされる2つのモデルには構造的な違いがあります。Disman-Traceroute-Mibの場合、管理情報の構造（SMIV2、STD 58、RFC 2578 [RFC2578]）が使用され、IPPM Traceroute測定データモデルはXMLを使用してエンコードされます。
This difference in structure implies that the DISMAN-TRACEROUTE-MIB module contains SMI-specific information elements (managed objects) that concern tables of managed objects (specification, entry creation and deletion, status retrieval) that are not required for the XML-encoded traceroute measurement data model.
この構造の違いは、Disman-Traceroute-MIBモジュールに、XMLエンコードされたトレーサーでは不要な管理オブジェクト（仕様、エントリの作成、削除、ステータス取得）の表に関係するSMI固有の情報要素（管理されたオブジェクト）が含まれていることを意味します。測定データモデル。
But for most of the remaining information elements that concern configuration of traceroute measurements and results of completed measurements, the semantics are identical between the DISMAN-TRACEROUTE-MIB module and the traceroute measurement data model. There are very few exceptions to this; these are listed below. Also, naming of information elements is identical between both models with a few exceptions. For the traceroute measurement data model, a few information elements have been added, some because of the different structure and some to provide additional information on completed measurements.
しかし、Traceroute測定の構成と完了した測定の結果に関係する残りの情報要素のほとんどでは、セマンティクスはDisman-Traceroute-MibモジュールとTraceroute測定データモデルとの間で同じです。これには例外はほとんどありません。これらを以下に示します。また、情報要素の命名は、いくつかの例外を除き、両方のモデル間で同じです。Traceroute測定データモデルの場合、いくつかの情報要素が追加されています。一部は構造が異なり、いくつかは完了した測定に関する追加情報を提供するためです。
There are some basic differences in nature and application between MIB modules and XML documents. This results in two major differences of scope between the DISMAN-TRACEROUTE-MIB module and the traceroute measurement data model.
MIBモジュールとXMLドキュメントの間には、性質とアプリケーションにいくつかの基本的な違いがあります。これにより、Disman-Traceroute-MibモジュールとTraceroute測定データモデルの間の範囲の2つの大きな違いが生じます。
The first difference is the "traceRouteResultsTable" contained in the DISMAN-TRACEROUTE-MIB module. This table allows online observation of status and progress of an ongoing traceroute measurement. This highly dynamic information is not included in the traceroute measurement data model because it has not been envisioned to use the model for dynamically reporting progress of individual traceroute measurements. The traceroute measurement data model is rather intended to be used for reporting completed traceroute measurements.
最初の違いは、Disman-Traceroute-Mibモジュールに含まれる「tracerouteresultstable」です。この表は、進行中のトレーサー測定のステータスと進捗状況をオンラインで観察できるようにします。この非常に動的な情報は、個々のTraceroute測定の進行状況を動的に報告するためにモデルを使用することは想定されていないため、Traceroute測定データモデルには含まれていません。Traceroute測定データモデルは、完了したTraceroute測定の報告に使用することを目的としています。
The second difference is due to the fact that information in a MIB is typically tied to a local node hosting the MIB instance. The "RequestMetadata" element specified in the traceroute measurement data model can be used for specifying a measurement request that may be applied to several probes in a network. This concept does not exist in the DISMAN-TRACEROUTE-MIB module.
2番目の違いは、MIBの情報が通常、MIBインスタンスをホストするローカルノードに結び付けられているという事実によるものです。Traceroute測定データモデルで指定されている「RequestMetadata」要素は、ネットワーク内のいくつかのプローブに適用できる測定要求を指定するために使用できます。この概念は、Disman-Traceroute-Mibモジュールには存在しません。
For the remaining elements in the DISMAN-TRACEROUTE-MIB module and in the traceroute measurement data model, there is a very good match between the two worlds. The "traceRouteCtlTable" corresponds to the "MeasurementMetadata" element, and the combination of the "traceRouteProbeHistoryTable" and the "traceRouteHopsTable" corresponds to a collection of "MeasurementResult" elements.
Disman-Traceroute-MibモジュールとTraceroute測定データモデルの残りの要素については、2つの世界の間に非常に良い一致があります。「traceroutectltable」は、「測定メタダタ」要素に対応し、「tracerouteprobehistorable」と「traceroutehopstable」の組み合わせは、「測定値」要素のコレクションに対応します。
Basically, names in both models are chosen using the same naming conventions.
基本的に、両方のモデルの名前は、同じ命名規則を使用して選択されます。
For the traceroute measurement configuration information, all names, such as "CtlProbesPerHop", are identical in both models except for the traceRoute prefix that was removed to avoid unnecessary redundancy in the XML file and for "CtlDataSize", which was renamed to "CtlProbeDataSize" for clarification in the traceroute measurement data model.
Traceroute測定構成情報の場合、「CTLPROBESPERHOP」などのすべての名前は、XMLファイルの不必要な冗長性を避け、「Ctlprobedatasize」に変更された「ctldatasize」を避けるために削除されたtracerouteプレフィックスを除き、両方のモデルで同一です。Traceroute測定データモデルの明確化。
Results of measurements in the DISMAN-TRACEROUTE-MIB modules are distributed over two tables, the "traceRouteResultsTable" contains mainly information about ongoing measurements and the "traceRouteProbeHistoryTable" contains only information about completed measurements. According to the SMIv2 naming conventions, names of information elements in these tables have different prefixes ("traceRouteResults" and "traceRouteProbeHistory"). Since the traceroute measurement data model only reports on completed measurements, this separation is not needed anymore and the prefix "Results" is used for all related information elements.
Disman-Traceroute-Mibモジュールの測定結果は、2つのテーブルに分布しています。「TracerouteresultStable」には、継続的な測定に関する主に情報が含まれており、「tracerouteprobehistorytable」には完成した測定に関する情報のみが含まれています。SMIV2の命名規則によれば、これらのテーブルの情報要素の名前には異なるプレフィックス（「tracerouteresults」と「tracerouteprobehistory」）があります。Traceroute測定データモデルは完成した測定値についてのみ報告するため、この分離はもう必要なく、プレフィックス「結果」は関連するすべての情報要素に使用されます。
Beyond that, there are only a few changes in element names. The renaming actions include:
それを超えて、要素名にわずかな変更しかありません。変更アクションには次のものが含まれます。
o "traceRouteProbeHistoryResponse" to "ProbeRoundTripTime";
o 「proberoundtriptime」から「tracerouteprobehistoryresponse」;
o "traceRouteProbeHistoryHAddr" to "HopAddr";
o 「Tracerouteprobehistoryhaddr」から「Hopaddr」から。
o "traceRouteProbeHistoryTime" to "ResultsEndDateAndTime";
o 「tracerouteprobehistorytime」から「resultenddateandtime」。
o "traceRouteProbeHistoryLastRC" to "ResultsHopRawOutputData".
o 「resultshoprawoutputdata」から「tracerouteprobehistorylastrc」。
The semantics were changed for two information elements only.
セマンティクスは、2つの情報要素のみで変更されました。
For "traceRouteProbeHistoryResponse" in the DISMAN-TRACEROUTE-MIB, a value of 0 indicates that it is not possible to transmit a probe. For the traceroute measurement data model, a value of 0 for element
Disman-Traceroute-Mibの「tracerouteprobehistoryresponse」の場合、0の値は、プローブを送信できないことを示します。Traceroute測定データモデルの場合、要素の値は0の値です
"RoundTripTime" indicates that the measured time was less than one millisecond. For the case that it was not possible to transmit a probe, a string is used that indicates the problem.
「RoundTriptime」は、測定時間が1ミリ秒未満であることを示しています。プローブを送信することが不可能な場合、問題を示す文字列が使用されます。
For "traceRouteCtlIfIndex" in the DISMAN-TRACEROUTE-MIB, a value of 0 indicates that the option to set the index is not available. This was translated to the traceroute measurement data model, such that a value of 0 for this element indicates that the used interface is unknown.
Disman-Traceroute-Mibの「traceroutectlifindex」の場合、0の値は、インデックスを設定するオプションが使用できないことを示します。これは、Traceroute測定データモデルに翻訳されたため、この要素の値は使用されているインターフェイスが不明であることを示します。
The element "traceRouteProbeHistoryLastRC" in the DISMAN-TRACEROUTE-MIB was replaced by element "ResultsHopRawOutputData". While "traceRouteProbeHistoryLastRC" just reports a reply code, "ResultsHopRawOutputData" reports the full raw output data (per hop) produced by the traceroute measurement that was used.
Disman-Traceroute-Mibの要素「tracerouteprobehistorylastrc」は、要素「resultshoprawoutputdata」に置き換えられました。「tracerouteprobehistorylastrc」は返信コードを報告するだけですが、「resultshoprawoutputdata」は、使用されたtraceroute測定によって生成された完全な生の出力データ（ホップごと）を報告します。
Only a few information elements have been added to the model of the DISMAN-TRACEROUTE-MIB module.
Disman-Traceroute-Mibモジュールのモデルに追加された情報要素はごくわずかです。
o For providing information on the MPLS label stack entries of a probe in the traceroute measurement path, "MPLSLabelStackEntry" was added.
o Traceroute測定パスのプローブのMPLSラベルスタックエントリに関する情報を提供するために、「MPLSLABELSTACKENTRY」が追加されました。
o For providing additional timestamp beyond "ResultsEndDateAndTime", "ResultsStartDateAndTime" and "Time" were added.
o 「resultenddateandtime」を超えて追加のタイムスタンプを提供するために、「resultsstartdateandtime」と「時間」が追加されました。
o For providing DNS names at the time of the execution of the traceroute for each "HopAddr" (which may change over time), "HopName" was added.
o 各「hopaddr」（時間の経過とともに変化する可能性がある）のtracerouteの実行時にDNS名を提供するために、「Hopname」が追加されました。
This section shows some examples of traceroute applications. In addition, the encoding of requests and results is shown for some of those examples. Also, note that in these XML examples some lines appear wrapped due to the limited length of line.
このセクションでは、Tracerouteアプリケーションの例をいくつか示しています。さらに、これらの例のいくつかについて、リクエストと結果のエンコードが示されています。また、これらのXMLの例では、ラインの長さが限られているため、いくつかの線が包まれているように見えることに注意してください。
A typical traceroute on a LINUX system looks like the following:
# traceroute -f 4 www.example 1500
traceroute to ww.example (192.0.2.42), 30 hops max, 1500-byte packets
5 out.host1.example (192.0.2.254) 6.066 ms 5.625 ms 6.095 ms
6 rtr4.host6.example (192.0.2.142) 6.979 ms 6.221 ms 7.368 ms
7 hop7.rtr9.example (192.0.2.11) 16.165 ms 15.347 ms 15.514 ms
8 192.0.2.222 (192.0.2.222) 32.796 ms 28.723 ms 26.988 ms
9 in.example (192.0.2.123) 15.861 ms 16.262 ms 17.610 ms
10 in.example (192.0.2.123)(N!) 17.391 ms * *
This traceroute ignores the first 4 hops and uses 1500-byte packets
including the header. It does not reach its goal since the last
listed hop says that the network is not reachable (N!). The XML
representation for this trace follows:
<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
<RequestMetadata>
<TestName>Example 1</TestName>
<OSName/>
<OSVersion/>
<ToolVersion/>
<ToolName/>
<CtlTargetAddress>
<inetAddressDns>www.example</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize>1472</CtlProbeDataSize>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl/>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressUnknown/>
</CtlSourceAddress>
<CtlIfIndex/>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl>4</CtlInitialTtl>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><UDP/></CtlType>
</RequestMetadata>
<Measurement>
<MeasurementMetadata>
<TestName>Example 1</TestName>
<OSName>Linux</OSName>
<OSVersion>2.6.16.54-0.2.5-smp i386</OSVersion>
<ToolVersion>1.0</ToolVersion>
<ToolName>traceroute</ToolName>
<CtlTargetAddress>
<inetAddressDns>www.example</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize>1472</CtlProbeDataSize>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl/>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressIpv4>192.0.2.1</inetAddressIpv4>
</CtlSourceAddress>
<CtlIfIndex>2</CtlIfIndex>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl>4</CtlInitialTtl>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><UDP/></CtlType>
</MeasurementMetadata>
<MeasurementResult>
<TestName>Example 1</TestName>
<ResultsStartDateAndTime>2008-05-16T14:22:34+02:00</ResultsStar
tDateAndTime>
<ResultsIpTgtAddr>
<inetAddressIpv4>192.0.2.42</inetAddressIpv4>
</ResultsIpTgtAddr>
<ProbeResults>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>out.host1.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>6</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:35+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>out.host1.example</HopName>
<ProbeRoundTripTime><roundTripTime>5</roundTripTime></Pro
beRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:35+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>out.host1.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>6</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:35+02:00</Time>
</probe>
<HopRawOutputData> 5 out.host1.example (192.0.2.254) 6.06
6 ms 5.625 ms 6.095 ms</HopRawOutputData>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.142</inetAddressIpv4>
</HopAddr>
<HopName>rtr4.host6.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>6</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:36+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.142</inetAddressIpv4>
</HopAddr>
<HopName>rtr4.host6.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>6</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:36+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.142</inetAddressIpv4>
</HopAddr>
<HopName>rtr4.host6.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>7</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:37+02:00</Time>
</probe>
<HopRawOutputData> 6 rtr4.host6.example (192.0.2.142) 6.9
79 ms 6.221 ms 7.368 ms</HopRawOutputData>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.11</inetAddressIpv4>
</HopAddr>
<HopName>hop7.rtr9.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>16</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:37+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.11</inetAddressIpv4>
</HopAddr>
<HopName>hop7.rtr9.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>15</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:38+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.11</inetAddressIpv4>
</HopAddr>
<HopName>hop7.rtr9.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>15</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:38+02:00</Time>
</probe>
<HopRawOutputData> 7 hop7.rtr9.example (192.0.2.11) 16.16
5 ms 15.347 ms 15.514 ms</HopRawOutputData>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>32</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:39+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>38</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:39+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>26</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:39+02:00</Time>
</probe>
<HopRawOutputData> 8 192.0.2.222 (192.0.2.222) 32.796 ms
28.723 ms 26.988 ms</HopRawOutputData>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>15</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:40+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>16</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:40+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>17</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-16T14:22:40+02:00</Time>
</probe>
<HopRawOutputData> 9 in.example (192.0.2.123) 15.861 ms
16.262 ms 17.610 ms</HopRawOutputData>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>17</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>noRouteToTarget</ResponseStatus>
<Time>2008-05-16T14:22:41+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTimeNotAvailable/>
</ProbeRoundTripTime>
<ResponseStatus>requestTimedOut</ResponseStatus>
<Time>2008-05-16T14:22:44+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<HopName>in.example</HopName>
<ProbeRoundTripTime>
<roundTripTimeNotAvailable/>
</ProbeRoundTripTime>
<ResponseStatus>requestTimedOut</ResponseStatus>
<Time>2008-05-16T14:22:44+02:00</Time>
</probe>
<HopRawOutputData>10 in.example (192.0.2.123)(N!) 17.391
ms * *</HopRawOutputData>
</hop>
</ProbeResults>
<ResultsEndDateAndTime>2008-05-16T14:22:44+02:00</ResultsEndDat
eAndTime>
</MeasurementResult>
</Measurement>
</traceRoute>
The second example was generated on an OpenBSD system. On that system, the traceroute looks like the following: # traceroute -P tcp w2.example 128
2番目の例は、OpenBSDシステムで生成されました。そのシステムでは、Tracerouteは次のようになります。
traceroute to w2.example (192.0.2.254), 64 hops max, 160-byte packets 1 router1.example.org (192.0.2.22) 0.486 ms 0.486 ms 0.482 ms 2 router7.example.org (192.0.2.1) 3.27 ms 1.420 ms 1.873 ms 3 hop0.c.example (192.0.2.105) 3.177 ms 3.258 ms 3.859 ms 4 hop6.c.example (192.0.2.107) 5.994 ms 4.607 ms 5.678 ms 5 hop3.c.example (192.0.2.111) 20.341 ms 20.732 ms 19.505 ms 6 in.example.net (192.0.2.222) 20.333 ms 19.174 ms 19.856 ms 7 egress.example.net (192.0.2.227) 20.268 ms 21.79 ms 19.992 ms 8 routerin.example (192.0.2.253) 19.983 ms 19.931 ms 19.894 ms 9 routerdmz.example (192.0.2.249) 20.943 ms !X * 19.829 ms !X
w2.example（192.0.2.254）、64 Hops max、160-byte packets 1 router1.example.org（192.0.2.22）0.486 MS 0.486 MS 0.482 MS 2 Router7.example.org（192.0.2.1）3.27 MS 1.420MS 1.873 MS 3 Hop0.C.Example（192.0.2.105）3.177 MS 3.258 MS 3.859 MS 4 Hop6.C.Example（192.0.2.107）5.994 MS 4.607 MS 5.678 MS 5 Hop3.C.example（192.0.2.2.111）20.341 MS MS MS MS20.732 MS 19.505 MS 6 in.example.net（192.0.2.2222222）20.333 MS 19.174 MS 19.856 MS 7 egress.example.net（192.0.2.227）20.268 MS 21.79 MS 19.992 MS 8 Routerin.example（192.0.0.0.0.0.0.0.2.253）MS 19.894 MS 9 routerdmz.example（192.0.2.249）20.943 ms！x * 19.829 ms！x
It was executed with the TCP protocol and 128-byte packets (plus
header). The traceroute ended at hop 9 because the packets are
administratively filtered (!X). A corresponding XML representation
follows:
<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
<RequestMetadata>
<TestName>Example 2</TestName>
<OSName/>
<OSVersion/>
<ToolVersion/>
<ToolName/>
<CtlTargetAddress>
<inetAddressDns>w2.example</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize>128</CtlProbeDataSize>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl/>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressUnknown/>
</CtlSourceAddress>
<CtlIfIndex/>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl/>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><TCP/></CtlType>
</RequestMetadata>
<Measurement>
<MeasurementMetadata>
<TestName>Example 2</TestName>
<OSName>OpenBSD</OSName>
<OSVersion>4.1 i386</OSVersion>
<ToolVersion></ToolVersion>
<ToolName>traceroute</ToolName>
<CtlTargetAddress>
<inetAddressDns>w2.example</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize>128</CtlProbeDataSize>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl/>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressIpv4>192.0.2.42</inetAddressIpv4>
</CtlSourceAddress>
<CtlIfIndex>1</CtlIfIndex>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl/>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><TCP/></CtlType>
</MeasurementMetadata>
<MeasurementResult>
<TestName>Example 2</TestName>
<ResultsStartDateAndTime>2008-05-14T09:57:11+02:00</ResultsStar
tDateAndTime>
<ResultsIpTgtAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</ResultsIpTgtAddr>
<ProbeResults>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.22</inetAddressIpv4>
</HopAddr>
<HopName>router1.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:13+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.22</inetAddressIpv4>
</HopAddr>
<HopName>router1.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:13+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.22</inetAddressIpv4>
</HopAddr>
<HopName>router1.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:13+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.1</inetAddressIpv4>
</HopAddr>
<HopName>router7.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:13+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.1</inetAddressIpv4>
</HopAddr>
<HopName>router7.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:13+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.1</inetAddressIpv4>
</HopAddr>
<HopName>router7.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:14+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.105</inetAddressIpv4>
</HopAddr>
<HopName>hop0.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:14+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.105</inetAddressIpv4>
</HopAddr>
<HopName>hop0.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:14+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.105</inetAddressIpv4>
</HopAddr>
<HopName>hop0.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:14+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.107</inetAddressIpv4>
</HopAddr>
<HopName>hop6.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:15+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.107</inetAddressIpv4>
</HopAddr>
<HopName>hop6.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>4</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:16+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.107</inetAddressIpv4>
</HopAddr>
<HopName>hop6.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:16+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>hop3.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>20</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:17+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>hop3.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>20</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:18+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>hop3.c.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:19+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<HopName>in.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>20</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:20+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<HopName>in.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:20+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.222</inetAddressIpv4>
</HopAddr>
<HopName>in.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:21+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.227</inetAddressIpv4>
</HopAddr>
<HopName>egress.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>20</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:22+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.227</inetAddressIpv4>
</HopAddr>
<HopName>egress.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>21</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:22+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.227</inetAddressIpv4>
</HopAddr>
<HopName>egress.example.net</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:23+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.253</inetAddressIpv4>
</HopAddr>
<HopName>routerin.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:24+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.253</inetAddressIpv4>
</HopAddr>
<HopName>routerin.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:24+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.253</inetAddressIpv4>
</HopAddr>
<HopName>routerin.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T09:57:25+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.249</inetAddressIpv4>
</HopAddr>
<HopName>routerdmz.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>20</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>unknown</ResponseStatus>
<Time>2008-05-14T09:57:26+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.249</inetAddressIpv4>
</HopAddr>
<HopName>routerdmz.example</HopName>
<ProbeRoundTripTime>
<roundTripTimeNotAvailable/>
</ProbeRoundTripTime>
<ResponseStatus>requestTimedOut</ResponseStatus>
<Time>2008-05-14T09:57:26+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.249</inetAddressIpv4>
</HopAddr>
<HopName>routerdmz.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>19</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>unknown</ResponseStatus>
<Time>2008-05-14T09:57:30+02:00</Time>
</probe>
</hop>
</ProbeResults>
<ResultsEndDateAndTime>2008-05-14T09:57:30+02:00</ResultsEndDat
eAndTime>
</MeasurementResult>
</Measurement>
</traceRoute>
The third and last example is based on the Microsoft Windows pendant of traceroute. On an MS Windows system, the command is called "tracert" and typically looks as follows:
3番目と最後の例は、TracerouteのMicrosoft Windowsペンダントに基づいています。MS Windowsシステムでは、コマンドは「Tracert」と呼ばれ、通常は次のように見えます。
# tracert -h 10 www.example.org
＃tracert -h 10 www.example.org
Tracing route to www.example.org [192.0.2.11] over a maximum of 10 hops:
www.example.orgへのトレースルート[192.0.2.11]最大10ホップを超えて：
1 1 ms 1 ms 8 ms 192.0.2.99
2 <1 ms <1 ms <1 ms r1.provider4.example [192.0.2.102]
3 <1 ms <1 ms <1 ms rtr8.provider8.example [192.0.2.254]
4 1 ms 1 ms 1 ms hop11.hoster7.example [192.0.2.4]
5 2 ms 3 ms 1 ms sw6.provider2.example [192.0.2.201]
6 3 ms 3 ms 3 ms out.provider2.example [192.0.2.111]
7 * 6 ms 5 ms 192.0.2.123
8 5 ms 5 ms 5 ms 192.0.2.42
9 94 ms 95 ms 95 ms ingress.example.org [192.0.2.199]
10 168 ms 169 ms 169 ms 192.0.2.44
Trace complete.
トレースが完了します。
In this example, the trace was limited to 10 hops, so the tenth and
last hop of this example was not the final destination. Applying the
XML schema defined in this document, the trace could look as follows:
<?xml version="1.0" encoding="UTF-8"?>
<traceRoute xmlns="urn:ietf:params:xml:ns:traceroute-1.0">
<RequestMetadata>
<TestName>Example 3</TestName>
<OSName/>
<OSVersion/>
<ToolVersion/>
<ToolName/>
<CtlTargetAddress>
<inetAddressDns>www.example.org</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize/>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl>10</CtlMaxTtl>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressUnknown/>
</CtlSourceAddress>
<CtlIfIndex/>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl/>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><TCP/></CtlType>
</RequestMetadata>
<Measurement>
<MeasurementMetadata>
<TestName>Example 3</TestName>
<OSName>Windows</OSName>
<OSVersion>XP SP2 32-bit</OSVersion>
<ToolVersion></ToolVersion>
<ToolName>tracert</ToolName>
<CtlTargetAddress>
<inetAddressDns>www.example.org</inetAddressDns>
</CtlTargetAddress>
<CtlBypassRouteTable/>
<CtlProbeDataSize/>
<CtlTimeOut/>
<CtlProbesPerHop/>
<CtlPort/>
<CtlMaxTtl>10</CtlMaxTtl>
<CtlDSField/>
<CtlSourceAddress>
<inetAddressIpv4>192.0.2.142</inetAddressIpv4>
</CtlSourceAddress>
<CtlIfIndex>3</CtlIfIndex>
<CtlMiscOptions/>
<CtlMaxFailures/>
<CtlDontFragment/>
<CtlInitialTtl/>
<CtlDescr>Show how it encodes in XML</CtlDescr>
<CtlType><TCP/></CtlType>
</MeasurementMetadata>
<MeasurementResult>
<TestName>Example 3</TestName>
<ResultsStartDateAndTime>2008-05-14T11:03:09+02:00</ResultsStar
tDateAndTime>
<ResultsIpTgtAddr>
<inetAddressIpv4>192.0.2.11</inetAddressIpv4>
</ResultsIpTgtAddr>
<ProbeResults>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.99</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.99</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.99</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>8</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.102</inetAddressIpv4>
</HopAddr>
<HopName>r1.provider4.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.102</inetAddressIpv4>
</HopAddr>
<HopName>r1.provider4.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.102</inetAddressIpv4>
</HopAddr>
<HopName>r1.provider4.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>rtr8.provider8.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>rtr8.provider8.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.254</inetAddressIpv4>
</HopAddr>
<HopName>rtr8.provider8.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>0</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.4</inetAddressIpv4>
</HopAddr>
<HopName>hop11.hoster7.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:09+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.4</inetAddressIpv4>
</HopAddr>
<HopName>hop11.hoster7.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:10+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.4</inetAddressIpv4>
</HopAddr>
<HopName>hop11.hoster7.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:10+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.201</inetAddressIpv4>
</HopAddr>
<HopName>sw6.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>2</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:10+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.201</inetAddressIpv4>
</HopAddr>
<HopName>sw6.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:11+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.201</inetAddressIpv4>
</HopAddr>
<HopName>sw6.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>1</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:11+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>out.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:11+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>out.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:11+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.111</inetAddressIpv4>
</HopAddr>
<HopName>out.provider2.example</HopName>
<ProbeRoundTripTime>
<roundTripTime>3</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:12+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTimeNotAvailable/>
</ProbeRoundTripTime>
<ResponseStatus>requestTimedOut</ResponseStatus>
<Time>2008-05-14T11:03:14+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>6</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:15+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.123</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:16+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.42</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:17+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.42</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:17+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.42</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>5</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:17+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.199</inetAddressIpv4>
</HopAddr>
<HopName>ingress.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>94</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:19+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.199</inetAddressIpv4>
</HopAddr>
<HopName>ingress.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>95</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:19+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.199</inetAddressIpv4>
</HopAddr>
<HopName>ingress.example.org</HopName>
<ProbeRoundTripTime>
<roundTripTime>95</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:19+02:00</Time>
</probe>
</hop>
<hop>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.44</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>168</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:20+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.44</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>169</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:21+02:00</Time>
</probe>
<probe>
<HopAddr>
<inetAddressIpv4>192.0.2.44</inetAddressIpv4>
</HopAddr>
<ProbeRoundTripTime>
<roundTripTime>169</roundTripTime>
</ProbeRoundTripTime>
<ResponseStatus>responseReceived</ResponseStatus>
<Time>2008-05-14T11:03:23+02:00</Time>
</probe>
</hop>
</ProbeResults>
<ResultsEndDateAndTime>2008-05-14T11:03:23+02:00</ResultsEndDat
eAndTime>
</MeasurementResult>
</Measurement>
</traceRoute>
The three examples given in this section are intended to give an impression of how a trace could be represented in XML. The representation generated by an implementation may differ from the examples here depending on the system and the capabilities of the traceroute implementation.
このセクションで示されている3つの例は、XMLでトレースをどのように表現できるかについて印象を与えることを目的としています。実装によって生成される表現は、システムとTraceroute実装の機能に応じて、ここの例とは異なる場合があります。
Authors' Addresses
著者のアドレス
Saverio Niccolini NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 118 EMail: saverio.niccolini@nw.neclab.eu URI: http://www.nw.neclab.eu
SAVERIO NICCOLINI NEC LABORATORIESヨーロッパ、NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ電話：49（0）6221 4342 118電子メール：saverio.niccolini@nw.neclab.eu Uri：
Sandra Tartarelli NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 132 EMail: sandra.tartarelli@nw.neclab.eu URI: http://www.nw.neclab.eu
Sandra Tartarelli NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: 49 (0) 6221 4342 132 EMail: sandra.tartarelli@nw.neclab.eu URI: http://www.nw.neclab.eu
Juergen Quittek NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 115 EMail: quittek@nw.neclab.eu URI: http://www.nw.neclab.eu
Juergen Quittek Nec Laboratories Europe、Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ電話：49（0）6221 4342 115電子メール：quittek@nw.neclab.eu uri：http：//www.nw.neclab.euu
Thomas Dietz NEC Laboratories Europe, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 4342 128 EMail: thomas.dietz@nw.neclab.eu URI: http://www.nw.neclab.eu
Thomas Dietz Nec Laboratories Europe、Nec Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115ドイツ電話：49（0）6221 4342 128メール：thomas.dietz@nw.neclab.eu Uri：http://www.nw.neclab.eu
Martin Swany Dept. of Computer and Information Sciences University of Delaware Newark DE 19716 U.S.A. EMail: swany@UDel.Edu
コンピューターおよび情報科学のマーティン・スワニー部デラウェア大学ニューアーク・デ・19716 U.S.A.電子メール：swany@udel.edu