RFC5388 日本語訳
5388 Information Model and XML Data Model for Traceroute Measurements.S. Niccolini, S. Tartarelli, J. Quittek, T. Dietz, M. Swany. December 2008. (Format: TXT=156801 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Niccolini
Request for Comments: 5388 S. Tartarelli
Category: Standards Track J. Quittek
T. Dietz
NEC
M. Swany
UDel
December 2008
コメントを求めるワーキンググループS.ニッコリーニの要求をネットワークでつないでください: 5388秒間Tartarelliカテゴリ: 標準化過程J.Quittek T.ディーツNEC M.Swany UDel2008年12月
Information Model and XML Data Model for Traceroute Measurements
情報モデルと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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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.
このドキュメントは構成を保存する標準の方法とトレースルート測定値の結果を述べます。 このドキュメントは最初に、本書では使用される用語とトレースルートツール自体について説明します。 その後、一般的な情報モデルは定義されます、情報要素を2つの意味的に切り離されたグループ(構成要素と結果要素)に分割して。 そのうえ、追加要素は、一般的なユニークな識別子によって構成要素と結果要素を関係づけるために定義されます。 情報モデルに基づいて、XMLに基づくデータモデルは、トレースルート測定値の結果を保存するために定義されます。
Niccolini, et al. Standards Track [Page 1] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[1ページ]。
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
1. 序論…3 2. このドキュメントで中古の用語…3 3. トレースルートツールとその操作…4 4. トレースルート測定値の結果…5 5. トレースルート測定値のための情報モデル…5 5.1. データ型…6 5.2. 情報要素…7 5.2.1. 情報要素の間の関係…7 5.2.2. 設定情報Elements…12 5.2.3. 結果Information Elements…17 5.2.4. 構成と結果を関連させる情報要素…21 5.2.5. トレースルート測定結果を比較する情報要素…22 6. データはトレースルート測定を保存するためにモデル化されます…23 7. トレースルート測定値のためのXML図式…24 8. セキュリティ問題…38 8.1. トレースルート測定値を行います…39 8.2. トレースルート測定が情報であると機密保護します…39 9. IANA問題…40 10. 参照…40 10.1. 標準の参照…40 10.2. 有益な参照…41 付録A.トレースルートデフォルト設定パラメータ…43 A.1。 代替のトレースルート実装…46 トレースルートの付録B.既知の問題…47 B.1。 トレースルート測定結果とIPPM測定基準との互換性…47 DISMANトレースルートMIBへの付録C.差…47 C.1。 範囲…48 C.2。 命名します。49 C.3。 意味論…49 C.4。 追加情報Elements…50 XML表現がある付録D.トレースルートの例…50
Niccolini, et al. Standards Track [Page 2] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[2ページ]。
1. Introduction
1. 序論
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.
トレースルートは独立している測定値として、または、多くの測定取り組みか、他の測定が取り組みであるとサポートする経路情報を得る手段として使用されます。 それは構成とトレースルート測定値の結果が保存される方法を標準化する必要がある理由です。 遅れ、接続性、および損失の物質でIPPMグループによって定義された標準の測定基準はトレースルートツールによって返された測定基準に適用されません。 したがって、唯一の可能性はトレースルート測定値の結果を比較するためにトレースルートツールのための名前とバージョンと同様にオペレーティングシステムの仕様が使用した保存された結果に加えることです。 このドキュメントは、トレースルート測定値の結果を保存して、それらの比較を許すために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はトレースルートツールについて説明します。 セクション4はトレースルートツールが始められたスクリーンに表示するようにトレースルート測定の結果について説明します。 セクション5とセクション6は構成とトレースルート測定値の結果を保存するためにそれぞれ情報モデルとデータモデルについて説明します。 セクション7はトレースルート測定情報を保存する、そして/または、交換するのにテンプレートとして使用されるべきXML図式を含みます。 セキュリティ問題とIANA問題がセクション8とセクション9にある状態で、ドキュメントはそれぞれ終わります。
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Terminology Used in This Document
2. 本書では使用される用語
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 トレースルートツール: ネットワーク病気の特徴のためのセクション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 トレースルート測定: 特定の設定パラメータ(トレースルート測定設定パラメータ)で進水するトレースルートツールのインスタンス、出力されるように与える特定のホスト(トレースルート測定の創始者)から、特定のトレースルート測定は結果として生じます。
o traceroute probe: one of many IP packets sent out by the
traceroute tool during a traceroute measurement;
o トレースルート徹底的調査: 多くのIPパケットの1つはトレースルート測定の間、トレースルートツールによる外に発信しました。
Niccolini, et al. Standards Track [Page 3] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[3ページ]。
o traceroute measurement configuration parameters: the configuration
parameters of a traceroute measurement;
o トレースルート測定設定パラメータ: トレースルート測定に関する設定パラメータ。
o traceroute measurement results: the results of a traceroute
measurement;
o トレースルート測定は結果として生じます: トレースルート測定の結果。
o traceroute measurement information: both the results and the
configuration parameters of a traceroute measurement;
o トレースルート測定情報: トレースルート測定に関する両方の結果と設定パラメータ。
o traceroute measurement path: a sequence of hosts transited in
order by traceroute probes during a traceroute measurement.
o トレースルート測定経路: トレースルートによって整然とした状態で通過されたホストの系列はトレースルート測定の間、調べられます。
3. The Traceroute Tool and Its Operations
3. トレースルートツールとその操作
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.
トレースルートは診断用道具がホップによるソースから目的地までの経路とソースからそれぞれまでのRound Trip Time(RTT)を飛び越しているホップを決定するのに使用したネットワークです。 したがって、トレースルート測定の創始者と他のホストの間の経路の何らかの情報(ホップカウント、遅れなど)を発見するのにトレースルートを使用できます。
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.
通常、トレースルートツールは、生きる特定の時間(TTL)値がIPパケットのヘッダーにある状態で探測装置をUDPに送って、経路に沿った各ゲートウェイからICMP TIME_EXCEEDED応答をホストに引き出そうとすることによって経路を目的地に発見するのを試みます。
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.
さらに詳細に、トレースルートツールは、トレースルート測定を開始しながら、ホストから1と等しいTTLとの徹底的調査の第一セットを送ります。(いくつかのツール実装が、1と異なった「n」と等しい値に初期のTTLを設定するのを許容する、1番目、「n-1インチのホップがスキップされて、たどられる最初のホップが経路の「n番目」である、)、」 探測装置を受け止めると、第1代ホップホストはTTL値(1以上の)を減少させます。 ゼロに合わせるために等しいTTL値を観測することによって、ホストは、徹底的調査を拒絶して、タイム誌_EXCEEDED値があるICMPメッセージを通常返します。 トレースルートツールは、したがって、ICMPメッセージのヘッダーから最初のホップのIPアドレスを引き出して、トレースルート測定を開始するホストと最初のホップの間でRTTを評価できます。 次のホップは同じ手順に従っていると発見されます、各ステップで徹底的調査のTTL値を1つ増強するために注意して。 ICMP PORT_UNREACHABLEメッセージが受信されるまで、TTL値は増強されます、あて先ホストが連絡されたか、またはホップの最大の構成された数を打ってあることを意味して。
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.
いくつかの実装がICMPエコーズを使用します、UDPデータグラムの代わりに。しかしながら、多くのルータはICMPメッセージに関するメッセージをICMPに返しません、すなわち、ICMP EchoのためにICMP TIME_EXCEEDEDを全く返しません。
Niccolini, et al. Standards Track [Page 4] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[4ページ]。
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データグラムの上に実装をベースに推薦します。トレースルートツールのTCPベースの実装に関する問題はAppendix A.1で報告されます。
4. Results of Traceroute Measurements
4. トレースルート測定値の結果
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:
以下のリストは、結果としてすべてのトレースルートツール実装によって提供された情報フィールドが考えられると報告します。 それらがここで報告されるオーダーは、関連していなくて、異なった実装で変化します。 各ホップに関しては、以下の情報は報告されます:
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).
トレースルートツール実装によって、出力で追加情報を表示するかもしれません(例えば、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を1つ以上以上減少させるといくつかの実装が複数の回同じ系列を印刷するのは起こるかもしれません、その結果、複数のホップに似ています。 各系列が別々に扱われるので、情報モデルはこれによって影響を与えられません。 左では、アプリケーション取り扱いに、XMLがどうそれに対処するかをファイルするということです。 そのうえ、1msの下の遅れのために、いくつかの実装が0ms(例えば、UNIXとリヌクス)を報告します、Windowsは「<1ms」を報告しますが。
5. Information Model for Traceroute Measurements
5. トレースルート測定値のための情報モデル
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:
情報モデルは情報要素で構成されます。 これらの情報要素を定義するのにおいて、テンプレートは使用されています。 そのようなテンプレートは以下のリストで指定されます:
Niccolini, et al. Standards Track [Page 5] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[5ページ]。
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 dataType--タイプのひとりはこのドキュメントのセクション5.1か情報モデルの拡大で記載しました。 属性のためのタイプスペースが実装を容易にするのが抑制されます。
o units - If the element is a measure of some kind, the units
identify what the measure is.
o ユニット--要素がある種の基準であるなら、ユニットは、測定が何であるかを特定します。
5.1. Data Types
5.1. データ型
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 ストリング--タイプ「ストリング」はユニコード文字符号化セットから有効なキャラクタの有限長さのストリングを代表します。 ユニコードは、ASCIIと他の多くの国際的な人物セットが使用されるのを許容します。 ストリングがUTF-8形式でコード化されると予想されます。(米国-ASCII文字のためのコード化が同じですが、また、形式は他のユニコード多バイト文字に対応します)。
o string255 - Same type as "string" but with the restriction of 255
characters.
o string255--「ストリング」にもかかわらず、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"と"noSpecification"です。
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です)、非グローバルなIPv4/IPv6アドレス(例えば、ipv4zとipv6z)は除かれますが。 追加許容値は、実数として示された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からAS番号まで一種のマッピングを表して、それはマッピングを得るのに使用されたメソッドを示します(値が許容されているのは、「bgptables」、「routingregistries」、"nslookup"、「他のもの」または「未知」です)。
Niccolini, et al. Standards Track [Page 6] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[6ページ]。
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"はトレースルートに使用されるプロトコルが調べられるのを示す方法を表します。 本書では定義された値は、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-2-20041028]に従って日付-時間仕様を表しますが、[RFC3339]で定義された値に制限されます。
5.2. Information Elements
5.2. 情報要素
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.
このセクションはトレースルート測定の保存に関連する要素について説明します。 それらの意味論によると、要素は2つのグループ(構成と結果)で分類されます。 一般的なユニークな識別子によって構成と結果要素を関係づけるために、追加要素は両方のグループに属しながら、定義されます。
5.2.1. Relationships between the Information Elements
5.2.1. 情報要素の間の関係
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):
あらゆるトレースルート測定が「トレースルート」要素のインスタンスによって表されます。 このクラスはトレースルート測定データの標準化された表現を提供します。 「トレースルート」要素はそれを構成できる要素(トレースルート測定の本質によって)です:
o 1 optional "RequestMetadata" element;
o 1つの任意の"RequestMetadata"要素。
o 0..2147483647 "Measurement" elements.
o 0..2147483647 「測定」要素。
Niccolini, et al. Standards Track [Page 7] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[7ページ]。
Each "Measurement" element contains:
それぞれの「測定」要素は以下を含んでいます。
o 1 optional "MeasurementMetadata" element;
o 1つの任意の"MeasurementMetadata"要素。
o 0..2147483647 "MeasurementResult" elements.
o 0..2147483647 "MeasurementResult"要素。
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.
1つ以上のノードで1つ以上のトレースルート実装によって実行されるためにトレースルート測定のパラメタを指定するのに"RequestMetadata"要素を使用できます。 トレースルート実装の能力によって、すべて要求されなかったパラメタは適用できます。 どのパラメタが特定のトレースルート測定のために実際に適用されたかは"MeasurementMetadata"要素で指定されます。
The "RequestMetadata" element is a sequence that contains:
"RequestMetadata"要素は以下を含む系列です。
o 1 "TestName" element;
o 1つの"TestName"要素。
o 1 optional "ToolVersion" element;
o 1つの任意の"ToolVersion"要素。
o 1 optional "ToolName" element;
o 1つの任意の"ToolName"要素。
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"要素。
Niccolini, et al. Standards Track [Page 8] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[8ページ]。
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.
"RequestMetadata"要素がXMLファイルから省略されるなら、それは、設定パラメータが要求したトレースルート測定がすべて使用されて、"MeasurementMetadata"要素が詳細にそれらを記載することを意味します。
The "MeasurementMetadata" element is a sequence that contains:
"MeasurementMetadata"要素は以下を含む系列です。
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つの"ToolVersion"要素。
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」要素。
Niccolini, et al. Standards Track [Page 9] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[9ページ]。
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"要素)測定に要求するとき、使用されるために既に起こったトレースルート測定値("MeasurementMetadata"要素)だけではなく、構成も説明できます。 個人情報要素が同様であっても、これは意味的に全く異なっています。 この類似性のため、"RequestMetadata"と"MeasurementMetadata"の両方がXML図式で同じタイプによって表されます。 空の要素として"RequestMetadata"から消えるか、または"RequestMetadata"で任意ですが、"MeasurementMetadata"で義務的であるとしてマークされるすべての要素を指定しなければなりません。 空の要素としてそれらを指定するのは、デフォルト値を使用することを意味します。 要素は"RequestMetadata"で"CtlType"要素がXML図式の複素数型にデフォルト値を指定できないので"RequestMetadata"で任意であったかもしれないのが義務的です。
The "MeasurementResult" element is a sequence that contains:
"MeasurementResult"要素は以下を含む系列です。
o 1 "TestName" element;
o 1つの"TestName"要素。
o 1 "ResultsStartDateAndTime" element;
o 1つの"ResultsStartDateAndTime"要素。
o 1 "ResultsIpTgtAddrType" element;
o 1つの"ResultsIpTgtAddrType"要素。
o 1 "ResultsIpTgtAddr" element;
o 1つの"ResultsIpTgtAddr"要素。
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は要素を「調べます」。
Niccolini, et al. Standards Track [Page 10] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[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つの「ResponseStatus」要素。
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"要素だけがあるファイルはトレースルート測定に関するトレースルート測定設定パラメータを含むファイルを表します。 同じトレースルート測定を実行するように頼まれた複数のノードの上にトレースルート測定設定パラメータを分配するのにそれを使用できます。
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つの"MeasurementMetadata"と1"MeasurementResult"の要素を含んでいるファイルはトレースルート測定のトレースルート測定情報を含むファイルを表します。
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"MeasurementMetadata"とn"MeasurementResult"要素を含んでいるファイルはいつも同じトレースルート測定設定パラメータでいろいろな時間の上に実行された1セットのトレースルート測定値のトレースルート測定情報を含むファイルを表します。
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"MeasurementMetadata"と1つの「測定」要素を含んでいるファイルはトレースルート測定のトレースルート測定情報を含むファイルを表します(要求されたトレースルート測定設定パラメータと実際に使用されるものの両方を含んでいて)。
o other combinations are possible to store multiple traceroute
measurements all in one XML file.
o 他の組み合わせは複数のトレースルート測定値オールインワンXMLファイルを保存するのにおいて可能です。
Niccolini, et al. Standards Track [Page 11] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[11ページ]。
5.2.2. Configuration Information Elements
5.2.2. 設定情報Elements
This section describes the elements specific to the configuration of the traceroute measurement (belonging to both the "RequestMetadata" and "MeasurementMetadata" elements).
このセクションはトレースルート測定の構成に特定の要素について説明します(両方の"RequestMetadata"と"MeasurementMetadata"要素に属して)。
5.2.2.1. CtlTargetAddressType
5.2.2.1. CtlTargetAddressType
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 データ型式--inetAddressType
o units - N/A
o ユニット--N/A
5.2.2.2. CtlTargetAddress
5.2.2.2. CtlTargetAddress
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"要素では、それはアドレスがトレースルート測定に使用されるよう要求したホストを指定します。 "MeasurementMetadata"要素では、それはトレースルート測定に使用されるホスト・アドレスを指定します。
o dataType - inetAddress
o データ型式--inetAddress
o units - N/A
o ユニット--N/A
5.2.2.3. CtlBypassRouteTable
5.2.2.3. CtlBypassRouteTable
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"要素における記述は、ルートテーブルの任意の迂回が可能にされたかどうか指定します。 "MeasurementMetadata"要素で指定する、ルートテーブルの任意の迂回が可能にされたかどうか指定します。 可能にすると、正常な経路指定テーブルを迂回させるでしょう、そして、付属ネットワークで直接ホストに探測装置を送るでしょう。 ホストが直接付属しているネットワークの一員でないなら、誤りは返されます。 定義されなかったルートを全く持っているインタフェースを通してトレースルート測定をローカル・ホストに実行するのにこのオプションを使用できます。 setsockopt SOL_SOCKET SO_DONTROUTEオプションがサポートされて、設定されるとき([IEEE.1003-1G.1997]を見てください)、このオブジェクトを使用できます。
Niccolini, et al. Standards Track [Page 12] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[12ページ]。
o dataType - boolean
o dataType--論理演算子
o units - N/A
o ユニット--N/A
5.2.2.4. CtlProbeDataSize
5.2.2.4. CtlProbeDataSize
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 記述--八重奏("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)における、トレースルート測定の徹底的調査のサイズを指定します。 UDPデータグラムが徹底的調査として使用されるなら、このオブジェクトに含まれた値は正確です。 別のプロトコルが指定されたサイズが適切でない探測装置(すなわち、TCPかICMP)を送るのに使用されるなら、実装は指定されたサイズの最も近くにあるどんなサイズ(メソッドに適切な)も使用できます。 このオブジェクトのための最大値は、最大のIPパケットサイズから20の八重奏(オプションのないIPv4ヘッダー)の可能な限り小さいIPヘッダーサイズと8つの八重奏のUDPヘッダーサイズを引き算することによって、計算されます。 IPパケットには、65535の八重奏(IPv6 jumbogramsを除いた)の最大サイズがあります。
o dataType - unsignedShort
o データ型式--unsignedShort
o units - octets
o ユニット--八重奏
5.2.2.5. CtlTimeOut
5.2.2.5. CtlTimeOut
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 記述--秒にトレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)の各徹底的調査にタイムアウト値を指定します。
o dataType - unsignedByte
o データ型式--unsignedByte
o units - seconds
o ユニット--秒
5.2.2.6. CtlProbesPerHop
5.2.2.6. CtlProbesPerHop
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)値は各ホスト("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)を呼びにやりました。
Niccolini, et al. Standards Track [Page 13] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[13ページ]。
o dataType - unsignedByte
o データ型式--unsignedByte
o units - probes
o ユニット--徹底的調査
5.2.2.7. CtlPort
5.2.2.7. CtlPort
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 記述--トレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)で使用されるベース港を指定します。
o dataType - unsignedShort
o データ型式--unsignedShort
o units - port number
o ユニット--ポートナンバー
5.2.2.8. CtlMaxTtl
5.2.2.8. CtlMaxTtl
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 記述--トレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)に最大のTTL値を指定します。
o dataType - u8nonzero
o dataType--u8nonzero
o units - time-to-live value
o ユニット--生きる時間値
5.2.2.9. CtlDSField
5.2.2.9. CtlDSField
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 記述--トレースルート徹底的調査("RequestMetadata"要素で)におけるDifferentiated Services(DS)分野に保存されるよう要求された値を指定します。 トレースルート徹底的調査("MeasurementMetadata"要素で)におけるDifferentiated Services(DS)分野に保存された値を指定します。 DS分野はIPv4ヘッダーのService(TOS)八重奏のTypeかIPv6ヘッダーのTraffic Class八重奏と定義されます([RFC2460]のセクション7を見てください)。 このオブジェクトの値は0〜255までの範囲の10進整数でなければなりません。 トレースルート測定とその徹底的調査のときに、明白なDS分野設定にはどんな効果があるかを決定するのにこのオプションを使用できます。 すべての値が、どんな法的であるか、または重要であるというわけではありません。 役に立つTOS八重奏値は、たぶん16(低い遅れ)と8(高生産性)です。 Differentiated Services(DS)分野の定義のための[RFC2474]とService(TOS)のTypeのための[RFC1812]セクション5.3.2でさらなる参照を見つけることができます。
Niccolini, et al. Standards Track [Page 14] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[14ページ]。
o dataType - unsignedByte
o データ型式--unsignedByte
o units - N/A
o ユニット--N/A
5.2.2.10. CtlSourceAddressType
5.2.2.10. CtlSourceAddressType
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 データ型式--inetAddressType
o units - N/A
o ユニット--N/A
5.2.2.11. CtlSourceAddress
5.2.2.11. CtlSourceAddress
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 記述--トレースルートにおけるソースアドレスが調べられるとき("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求されます)、IPアドレス(ホスト名ではなく、IP番号として与えられなければならない)を指定します。 1つ以上のIPアドレスをもっているホストの上では、探測装置が送られるインタフェースのプライマリIPアドレス以外の何かであるソースアドレスをオンに強制するのに"RequestMetadata"要素でこのオプションを使用できます。 値の「未知」は、デフォルトアドレスが使用されることを意味します。
o dataType - inetAddress
o データ型式--inetAddress
o units - N/A
o ユニット--N/A
5.2.2.12. CtlIfIndex
5.2.2.12. CtlIfIndex
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]で定義されるように("RequestMetadata"要素で)インタフェースインデックスを指定します。 0の値は、どんな特定のインタフェースも要求されていないのを示します。 実際に使用される("MeasurementMetadata"要素で)インタフェースインデックスを指定します。
Niccolini, et al. Standards Track [Page 15] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[15ページ]。
o dataType - unsignedInt
o データ型式--unsignedInt
o units - N/A
o ユニット--N/A
5.2.2.13. CtlMiscOptions
5.2.2.13. CtlMiscOptions
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 記述--実装依存するオプション("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)を指定します。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
5.2.2.14. CtlMaxFailures
5.2.2.14. CtlMaxFailures
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 記述--トレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)を終える前に許容された連続したタイムアウトの最大数を指定します。 どちらかの255(最大のホップカウント/可能なTTL値)か0の値は、特定の数の連続したタイムアウトが検出されるときリモートトレースルート測定を終える機能が無効にされたのを示します。 この要素は、[RFC4560]との完全な互換性を与えるために含まれています。 トレースルートのどんな知られている実装も現在、それをサポートしません。
o dataType - Unsigned8
o データ型式--Unsigned8
o units - timeouts
o ユニット--タイムアウト
5.2.2.15. CtlDontFragment
5.2.2.15. CtlDontFragment
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 記述--、指定、徹底的調査が可能にされたので("MeasurementMetadata"要素で)、IPヘッダーで(DF)旗を断片化しないでください。 "RequestMetadata"で旗が可能にされるよう要求されたかどうか指定するなら。 手動のPATH MTUテストを実行するのにDF旗を設定するのを使用できます。
o dataType - boolean
o dataType--論理演算子
o units - N/A
o ユニット--N/A
Niccolini, et al. Standards Track [Page 16] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[16ページ]。
5.2.2.16. CtlInitialTtl
5.2.2.16. CtlInitialTtl
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 記述--トレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)に初期のTTL値を指定します。 そのようなTTL設定が経路の初期(しばしばよく知られる)の部分を迂回させることを意図します。
o dataType - u8nonzero
o dataType--u8nonzero
o units - N/A
o ユニット--N/A
5.2.2.17. CtlDescr
5.2.2.17. CtlDescr
o name - CtlDescr
o 名前--CtlDescr
o description - Provides a description of the traceroute
measurement.
o 記述--トレースルート測定の記述を提供します。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
5.2.2.18. CtlType
5.2.2.18. CtlType
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 記述--トレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)に使用される実装メソッドを指定します。 それは、トレースルートがTCP、UDP、ICMP、または他のタイプの探測装置を使用しているかどうか指定します。 異なった名前空間で別の図式で指定された要素を使用することによって他のタイプの徹底的調査を指定するのは可能です。
o dataType - probesType
o データ型式--probesType
o units - N/A
o ユニット--N/A
5.2.3. Results Information Elements
5.2.3. 結果Information Elements
This section describes the elements specific to the results of the traceroute measurement.
このセクションはトレースルート測定の結果に特定の要素について説明します。
Niccolini, et al. Standards Track [Page 17] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[17ページ]。
5.2.3.1. ResultsStartDateAndTime
5.2.3.1. ResultsStartDateAndTime
o name - ResultsStartDateAndTime
o 名前--ResultsStartDateAndTime
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 記述--トレースルート測定の日付と開始時刻を指定します。 ここで、最初の徹底的調査は送付インタフェースで見られました。
o dataType - DateTime
o データ型式--DateTime
o units - N/A
o ユニット--N/A
5.2.3.2. ResultsIpTgtAddrType
5.2.3.2. ResultsIpTgtAddrType
o name - ResultsIpTgtAddrType
o 名前--ResultsIpTgtAddrType
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 記述--対応する"ResultsIpTgtAddr"要素のアドレスのタイプを指定します。 この要素は直接セクション7のXML図式に反映されません。 ホスト・アドレスタイプは、「inetAddress」型名と対応する要素値を調べることによって、決定できます。
o dataType - inetAddressType
o データ型式--inetAddressType
o units - N/A
o ユニット--N/A
5.2.3.3. ResultsIpTgtAddr
5.2.3.3. ResultsIpTgtAddr
o name - ResultsIpTgtAddr
o 名前--ResultsIpTgtAddr
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 データ型式--inetAddress
o units - N/A
o ユニット--N/A
5.2.3.4. HopAddrType
5.2.3.4. HopAddrType
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
o 記述--対応する"HopAddr"要素のアドレスのタイプを指定します。 この要素は直接セクション7のXML図式に反映されません。 ホスト・アドレスタイプは決定できます。
Niccolini, et al. Standards Track [Page 18] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[18ページ]。
by examining the "inetAddress" type name and the corresponding
element value. DNS names are not allowed for "HopAddr".
「inetAddress」を調べることによって、名前と対応する要素値をタイプしてください。 DNS名は"HopAddr"のために許容されていません。
o dataType - inetAddressType
o データ型式--inetAddressType
o units - N/A
o ユニット--N/A
5.2.3.5. HopAddr
5.2.3.5. HopAddr
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 記述--トレースルート測定経路でホップのアドレスを指定します。 このオブジェクトはDNS名であることが許容されていません。
o dataType - inetAddress
o データ型式--inetAddress
o units - N/A
o ユニット--N/A
5.2.3.6. HopName
5.2.3.6. HopName
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 記述--それが利用可能であるなら、DNS名"HopAddr"を指定します。 それが利用可能でないなら、要素は省略されます。
o dataType - inetAddress
o データ型式--inetAddress
o units - N/A
o ユニット--N/A
5.2.3.7. MPLSLabelStackEntry
5.2.3.7. MPLSLabelStackEntry
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ラベルスタックの上で観測されるような32ビットの値として1つのMPLSラベルスタックエントリーを含んでいます。 このただ一つの数に含まれているのは、[RFC3032]のMPLSラベルと、Exp分野と、S旗と、指定されるとしてMPLS TTL値です。 1つ以上のMPLSラベルスタックエントリーが報告されるなら、このタイプの要素の複数のインスタンスが使用されています。 先頭のラベルスタックエントリーが最初に報告されているラベルスタックのように同次でそれらを注文しなければなりません。
o dataType - unsignedInt
o データ型式--unsignedInt
o units - N/A
o ユニット--N/A
Niccolini, et al. Standards Track [Page 19] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[19ページ]。
5.2.3.8. ProbeRoundTripTime
5.2.3.8. ProbeRoundTripTime
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"を含んでいるなら、これはいつ応答が受けられた時に探測装置を送ったか、そして、またはいつ外で調節したかからミリセカンドで測定された時間を指定します。 数のトランケーションがトレースルートツールで報告したようにこの要素の価値は報告されます(したがって、出力「<1ms」は0msとしてコード化されます)。 要素"roundTripTimeNotAvailable"を含んでいるなら、それは、徹底的調査がタイムアウトのために失われたか、または探測装置を送るのが可能でなかったことを意味します。
o dataType - unsignedShort or string
o dataType--unsignedShortかストリング
o units - milliseconds or N/A
o ユニット--ミリセカンドかN/A
5.2.3.9. ResponseStatus
5.2.3.9. ResponseStatus
o name - ResponseStatus
o 名前--ResponseStatus
o description - Specifies the result of a traceroute measurement
made by the host for a particular probe.
o 記述--特定の徹底的調査のためにホストによってされたトレースルート測定の結果を指定します。
o dataType - operationResponseStatus
o データ型式--operationResponseStatus
o units - N/A
o ユニット--N/A
5.2.3.10. Time
5.2.3.10. 時間
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 データ型式--DateTime
o units - N/A
o ユニット--N/A
5.2.3.11. ResultsEndDateAndTime
5.2.3.11. ResultsEndDateAndTime
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
o 記述--トレースルート測定の日付と終わりの時間を指定します。 トレースルート測定の最後の徹底的調査への応答が受けられた時であるか時間はいつです。
Niccolini, et al. Standards Track [Page 20] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[20ページ]。
the last probe of the traceroute measurement was sent plus the
relative timeout (in case of a missing response).
測定が送られたトレースルートの最後の徹底的調査と相対的なタイムアウト(なくなった応答の場合の)。
o dataType - DateTime
o データ型式--DateTime
o units - N/A
o ユニット--N/A
5.2.3.12. HopRawOutputData
5.2.3.12. HopRawOutputData
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 記述--トレースルート測定経路のあるホップのためのトレースルート測定で返された生の出力データを指定します。 それはトレースルート結果を解釈する人間の役に立つと予想された実装依存して、印刷可能なストリングです。
o dataType - string
o dataType--ストリング
o units - N/A
o ユニット--N/A
5.2.4. Information Element Correlating Configuration and Results
Elements
5.2.4. 情報要素関連構成と結果要素
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]の仕様に選ばれる)によって構成と結果要素を関係づけるために定義されます。
5.2.4.1. TestName
5.2.4.1. TestName
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 記述--トレースルート測定の名前を指定します。 これは必ずどんな明確な範囲(例えば、特定のホスト、トレースルート測定の創始者)の中でもユニークであるというわけではありません。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
Niccolini, et al. Standards Track [Page 21] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[21ページ]。
5.2.5. Information Elements to Compare Traceroute Measurement Results
with Each Other
5.2.5. トレースルート測定結果を互いに比べる情報要素
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.
このセクションはともに前のグループ(構成要素と結果要素)のもの追加要素を定義します。 これらの要素は、異なったトレースルート測定値でトレースルート測定結果に比較を許すために定義されました。
5.2.5.1. OSName
5.2.5.1. OSName
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 記述--トレースルート測定が着手されたオペレーティングシステムの名前を指定します。 "RequestMetadata"で使用されるなら、この要素は無視されます。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
5.2.5.2. OSVersion
5.2.5.2. OSVersion
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 記述--トレースルート測定が着手されたOSバージョンを指定します。 "RequestMetadata"で使用されるなら、この要素は無視されます。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
5.2.5.3. ToolVersion
5.2.5.3. ToolVersion
o name - ToolVersion
o 名前--ToolVersion
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 記述--トレースルートツール("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で使用されるよう要求される)のバージョンを指定します。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
Niccolini, et al. Standards Track [Page 22] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[22ページ]。
5.2.5.4. ToolName
5.2.5.4. ToolName
o name - ToolName
o 名前--ToolName
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 記述--トレースルートツール("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で使用されるよう要求される)の名前を指定します。
o dataType - string255
o dataType--string255
o units - N/A
o ユニット--N/A
6. Data Model for Storing Traceroute Measurements
6. データは、トレースルート測定を保存するためにモデル化されます。
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.
データモデルのためのいくつかのデザイン選択があります。 2進の、または、原文の表現を使用できて、それは、最初から、定義されるか、または既に既存のフレームワークとデータモデルを使用できます。 一般に、既に既存のフレームワークとモデルの使用は好まれるべきです。
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.
2進の、そして、原文の表現には、利点と損失がともにあります。 原文の表現はこと(いくつかの制限で)です。人間読み込み可能であることで、データを保存のための、より少ないリソースを消費して、伝えて、分析しながら、2進法表示をゆったり過ごしてください。
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]、および[RFC2580]をコード化しながら、Management情報バージョン2(SMIv2)のStructureを指定します)。 このデータモデルは、よく合っていて、ネットワーク管理システムの中でサポートされますが、トレースルートを保存して、伝えるための一般形式が結果として生じる間それは容易に適切ではありません。
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.
別の2進法表示はIP Flow情報Export(IPFIX)プロトコル[RFC5101][RFC5102]のための指定されるとしての交通の流れ情報encodingsの拡大でしょう。 IPFIXプロトコルは広げることができます。 しかしながら、受け身に測定された流れが情報であるとエクスポートするのにこのプロトコル[IPFIX]の後ろのアーキテクチャは狙います。 したがって、トレースルート測定情報を伝えるのにそれを使用しようとするとき、いくつかの障害が予想されます。
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
原文の表現のために、eXtensible Markup Language(XML)[W3C. REC-xml-20060816]を使用するのは、当然の選択です。 XMLはデータの清潔な構造と記録の構文の照合をサポートします。 いくつかで
Niccolini, et al. Standards Track [Page 23] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[23ページ]。
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はこのメモで指定されるトレースルート測定情報モデルの基礎として選ばれました。
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はトレースルート測定情報を保存する、そして/または、交換するのにテンプレートとして使用されるべきXML図式を含みます。 図式は、結果情報要素(データ)によって"TestName"要素(一致で[RFC4560]の仕様に選ばれたユニークな識別子として、使用される)によって参照をつけられるのにトレースルート構成要素(要求されたパラメタ、"RequestMetadata"と使用される実引数、"MeasurementMetadata"の両方)がメタデータであるところでテンプレートに基づく(IPFIXプロトコルがどう設計されているかとかなり同様の)広げることができるアプローチを使用するように設計されました。 また、現在の、オープンGrid Forum(OGF)はこのアプローチを使用しています、そして、交差している要件は分析されました。 この分析の結果、セクション7に含まれたXML図式はOGF図式と互換性があるのが、以来ともに方法で設計されていて、それが不要な冗長を制限して、2つの間の簡単な1〜1つの変換が存在しているということであったということです。
7. XML Schema for Traceroute Measurements
7. トレースルート測定値のためのXML図式
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.
このセクションは、トレースルート測定情報を保存する、そして/または、交換するのにテンプレートとして使用されるためにXML図式を提示します。 図式は[RFC3629]で定義されるようにUTF-8コード化を使用します。 ここに提示された形式、XML宣言SHOULDに一致しているドキュメントでは、XMLドキュメントのバージョンと文字符号化を指定しながら、存在してください。 ドキュメントは、UTF-8を使用することでコード化されるべきです。 いくつかのストリングが複数の系列にかかることができるので、[RFC5198]は適用します。 XML処理命令とコメントを無視しなければなりません。 ドキュメントを書くとき、空白がこの図式に従いながらXMLで重要であることを気にしてください。 このセクションで示されたXML図式によると、提示された形式を使用するドキュメントは有効であるに違いありません。 「」 _タイプCtlTypeの要素」は未知の名前空間からの要素を含むかもしれなくて、プロセッサにおいて、それらの名前空間が未知であるなら、それらの要素を無視しなければなりません。 XML図式タイプ"dateTime"を使用する要素のための値を[RFC3339]で定義された値に制限しなければなりません。 この形式の将来のバージョンは、すべてを再定義する新しい図式かこのバージョンで定義されたデータ型と要素のいくつかを作成するか、または完全な新しい図式を確立することによって、この図式を広げるかもしれません。
Niccolini, et al. Standards Track [Page 24] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[24ページ]。
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>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><xs: 図式elementFormDefault=がtargetNamespace=に「資格を与えた」、「つぼ:ietf:params:xml:ナノ秒: トレースルート1インチのxmlns: xsが" http://www.w3.org/2001/XMLSchema "xmlns: tr=と等しい、「つぼ:ietf:params: xml:ナノ秒:トレースルート1インチの><xs: simpleTypeが=を命名する、「「><xs: 注釈><xs: ドキュメンテーション>Stringは255のキャラクタ</xs: ドキュメンテーション></xs: 注釈>に制限した」string255
<xs:restriction base="xs:string">
<xs:maxLength value="255"/>
</xs:restriction>
</xs:simpleType>
<xs: ></xs: 制限ベース=「xs: 「><xs: maxLengthは=を評価する」という255を結んでください」という/></xs: 制限simpleType>。
<xs:simpleType name="u8nonzero">
<xs:annotation>
<xs:documentation>unsignedByte with non zero
value.</xs:documentation>
</xs:annotation>
<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: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: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:element name="roundTripTimeNotAvailable"> <xs:complexType/> </xs:element> </xs:choice> </xs:complexType>
<xs:complexType name="_inetAddressUnknown"/>
<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
<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
Niccolini, et al. Standards Track [Page 25] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 25] RFC 5388 Traceroute Storage Format December 2008
]).){3}([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"/>
</xs:restriction>
</xs:simpleType>
]).){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="_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: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: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:sequence> <xs:element name="asNumber" type="xs:unsignedInt"/>
<xs:element name="ipASNumberMappingType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="bgptables"/>
<xs:element name="ipASNumberMappingType"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="bgptables"/>
<xs:enumeration value="routingregistries"/>
<xs:enumeration value="routingregistries"/>
<xs:enumeration value="nslookup"/>
<xs:enumeration value="nslookup"/>
<xs:enumeration value="others"/>
<xs:enumeration value="others"/>
<xs:enumeration value="unknown"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:enumeration value="unknown"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType>
<xs:complexType name="inetAddress">
<xs:choice>
<xs:complexType name="inetAddress"> <xs:choice>
Niccolini, et al. Standards Track [Page 26] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 26] RFC 5388 Traceroute Storage Format December 2008
<xs:element name="inetAddressUnknown"
type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressUnknown" type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
<xs:element name="inetAddressASNumber" type="tr:_inetAddressASNumber"/>
<xs:element minOccurs="0" name="inetAddressDns"
type="tr:_inetAddressDns"/>
</xs:choice>
</xs:complexType>
<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:complexType name="inetAddressWithoutDns"> <xs:sequence> <xs:choice> <xs:element name="inetAddressUnknown" type="tr:_inetAddressUnknown"/>
<xs:element name="inetAddressIpv4"
type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>
<xs:element name="inetAddressIpv6"
type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>
<xs:element name="inetAddressASNumber"
type="tr:_inetAddressASNumber"/>
</xs:choice>
</xs:sequence>
</xs:complexType>
<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:simpleType name="operationResponseStatus"> <xs:restriction base="xs:string"> <xs:enumeration value="responseReceived"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="internalError"/>
<xs:enumeration value="internalError"/>
<xs:enumeration value="requestTimedOut"/>
<xs:enumeration value="requestTimedOut"/>
<xs:enumeration value="unknownDestinationAddress"/>
<xs:enumeration value="unknownDestinationAddress"/>
<xs:enumeration value="noRouteToTarget"/>
<xs:enumeration value="noRouteToTarget"/>
<xs:enumeration value="interfaceInactiveToTarget"/>
<xs:enumeration value="interfaceInactiveToTarget"/>
Niccolini, et al. Standards Track [Page 27] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 27] RFC 5388 Traceroute Storage Format December 2008
<xs:enumeration value="arpFailure"/>
<xs:enumeration value="arpFailure"/>
<xs:enumeration value="maxConcurrentLimitReached"/>
<xs:enumeration value="maxConcurrentLimitReached"/>
<xs:enumeration value="unableToResolveDnsName"/>
<xs:enumeration value="unableToResolveDnsName"/>
<xs:enumeration value="invalidHostAddress"/>
</xs:restriction>
</xs:simpleType>
<xs:enumeration value="invalidHostAddress"/> </xs:restriction> </xs:simpleType>
<xs:complexType name="_CtlType">
<xs:choice>
<xs:element name="TCP">
<xs:complexType/>
</xs:element>
<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="UDP"> <xs:complexType/> </xs:element>
<xs:element name="ICMP">
<xs:complexType/>
</xs:element>
<xs:element name="ICMP"> <xs:complexType/> </xs:element>
<xs:any namespace="##other"/>
</xs:choice>
</xs:complexType>
<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: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>
Niccolini, et al. Standards Track [Page 28] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 28] RFC 5388 Traceroute Storage Format December 2008
<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 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>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:simpleType>
<xs:restriction base="xs:unsignedInt">
<xs:maxInclusive value="4294967295"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<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: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
Niccolini, et al. Standards Track [Page 29] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 29] RFC 5388 Traceroute Storage Format December 2008
"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>
"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="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 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: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
<xs:complexType name="_Metadata"> <xs:annotation> <xs:documentation>Specifies the metadata for a traceroute operation -- the parameters requested if used in
Niccolini, et al. Standards Track [Page 30] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 30] RFC 5388 Traceroute Storage Format December 2008
"RequestMetadata" or the actual parameters used if used in
"MeasurementMetadata".</xs:documentation>
</xs:annotation>
"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: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="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="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="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 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>
Niccolini, et al. Standards Track [Page 31] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 31] RFC 5388 Traceroute Storage Format December 2008
</xs:element>
</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 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="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
<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
Niccolini, et al. Standards Track [Page 32] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 32] RFC 5388 Traceroute Storage Format December 2008
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>
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:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:maxInclusive value="65507"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<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: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:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:minInclusive value="1"/>
<xs:maxInclusive value="60"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<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: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:simpleType> <xs:restriction base="xs:unsignedByte"> <xs:minInclusive value="1"/>
<xs:maxInclusive value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:maxInclusive value="10"/> </xs:restriction> </xs:simpleType> </xs:element>
Niccolini, et al. Standards Track [Page 33] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 33] RFC 5388 Traceroute Storage Format December 2008
<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: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: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="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: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>
Niccolini, et al. Standards Track [Page 34] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 34] RFC 5388 Traceroute Storage Format December 2008
<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 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: 要素デフォルトが等しい、「0インチ名前="CtlIfIndex"が=をタイプする、「xs: unsignedInt、「><xs: 注釈><はxsされます: トレースルート探測装置を送るのにトレースルート測定にインタフェースが[RFC2863]それで定義されるように索引をつけるドキュメンテーション>Specifiesが使用されるよう要求("RequestMetadata"要素で)にされています」。 0の値は、どんな特定のインタフェースも要求されていないのを示します。 指定、インタフェースインデックスは実際に. </xs: ドキュメンテーション></xs: 注釈></xs: 要素>を使用しました("MeasurementMetadata"要素で)。
<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: 要素minOccurs=、「0インチ名前=「CtlMiscOptions」が=をタイプする、「tr: 「><xs: 注釈><xs: ドキュメンテーション>Specifies実装扶養家族は. </xs: ドキュメンテーション></xs: 注釈></xs: 要素>にゆだね("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求されます)」string255
<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
<xs: 要素デフォルトが等しい、「5インチ名前=「CtlMaxFailures」が=をタイプする、「xs: unsignedByte、「トレースルート測定を終える前に連続したタイムアウトの最大数が許容した><xs: 注釈><xs: ドキュメンテーション>Specifies、(中なら実際に使用される"RequestMetadata"要素で要求される、」
Niccolini, et al. Standards Track [Page 35] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[35ページ]。
"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]との完全な互換性を与えるために含まれています。 トレースルートのどんな知られている実装も、現在、それが. </xs: ドキュメンテーション></xs: 注釈></xs: 要素>であるとサポートしません。
<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: 要素デフォルト="CtlDontFragment"が=をタイプする、「xs: 論理演算子、「><xs: 注釈><xs: ドキュメンテーション>Specifies、徹底的調査が可能にされたので("MeasurementMetadata"要素で)IPヘッダーで(DF)旗を断片化しないでください、」 "RequestMetadata"で旗が可能にされるよう要求されたかどうか指定するなら。 手動のPATH MTUテスト</xsを実行します: ドキュメンテーション></xs: 注釈></xs: 要素>にDF旗を設定するのを使用できます。
<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: 要素デフォルトが等しい、「1インチ名前="CtlInitialTtl"が=をタイプする、「tr: u8nonzero、「><xs: 注釈><はトレースルート測定("MeasurementMetadata"要素で実際に使用される"RequestMetadata"要素で要求される)のために初期のTTLが評価する: ドキュメンテーション>Specifiesをxsします」。 そのようなTTL設定が経路</xsの初期(しばしばよく知られる)の部分: ドキュメンテーション></xs: 注釈></xs: 要素>を迂回させることを意図します。
<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: 要素のmaxOccurs=「1インチのminOccurs=」の0インチの名=の"CtlDescr"が=をタイプする、「tr: string255、「><xs: 注釈><xs: . トレースルート測定</xsのドキュメンテーション>Provides a記述: ドキュメンテーション></xs: 注釈></xs: 要素>」
<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
<xs: 要素名=の"CtlType"が=をタイプする、「tr: _CtlType、「実装メソッドがトレースルート測定に使用した><xs: 注釈><xs: ドキュメンテーション>Specifies、(中なら実際に使用される"RequestMetadata"要素で要求される、」
Niccolini, et al. Standards Track [Page 36] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[36ページ]。
"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>
"MeasurementMetadata"要素) それは、トレースルートがTCP、UDP、ICMP、または他のタイプの探測装置を使用しているかどうか指定します。 要素を使用することによって他のタイプの徹底的調査を指定するのが異なった名前空間で別の図式で></xs: . </xs: ドキュメンテーション></xs: 注釈></xs: 要素></xs: 系列complexType>を指定したのは、可能です。
<xs:complexType name="_Measurement">
<xs:annotation>
<xs:documentation>Contains the actual traceroute measurement
results.</xs:documentation>
</xs:annotation>
「<はxsされます: complexTypeは「><xs: 注釈><xs: ドキュメンテーション測定結果実際のトレースルート</がxsする>Contains: ドキュメンテーション></xs: 注釈>」と」 _=Measurementを命名します。
<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されます: 注釈><は: ドキュメンテーション>Specifiesをxsします。<xs: 系列><xs: 要素名=の"TestName"が=をタイプする、「tr: string255、「トレースルート測定の名前、」 これは必ず明確な範囲(例えば、特定のホスト、トレースルート測定の創始者)</xs: ドキュメンテーションの></xs: 注釈の></xs: 要素のいずれも>の中でユニークであるというわけではありません。
<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: 要素名=の"ResultsStartDateAndTime"が=をタイプする、「xs: dateTime、「トレースルート測定の日付と開始時刻の間の><xs: 注釈><xs: ドキュメンテーション>Specifies。」 これは送付インタフェース. </xs: ドキュメンテーション></xs: 注釈></xs: 要素>の最初の徹底的調査が見られた時です。
<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: 要素名=の"ResultsIpTgtAddr"が=をタイプする、「tr: inetAddressWithoutDns、「送付先アドレスがDNS名として指定されるときIPアドレスが「CtlTargetAddress」値に関連づけた><xs: 注釈><xs: ドキュメンテーション>Specifies。」 指定されないか、または指定されたDNS名が失敗するならDNS名が未知であるなら、決心において、このオブジェクトの値は「未知であるべきです」。 . 「inetAddress」型名と対応する要素価値の</xsを調べます: ドキュメンテーション></xs: 注釈></xs: 要素>はアドレスタイプを決定できます。
Niccolini, et al. Standards Track [Page 37] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[37ページ]。
<xs:element name="ProbeResults" type="tr:_ProbeResults"/>
<xs: 要素名=の「ProbeResults」は=「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: 要素名=の"ResultsEndDateAndTime"が=をタイプする、「xs: dateTime、「トレースルート測定の日付と終わりの時間の><xs: 注釈><xs: ドキュメンテーション>Specifies。」 ></xs: トレースルート測定の最後の徹底的調査への応答が受けられた時かトレースルート測定の最後の徹底的調査が送られた時のどちらかであり、親類はタイムアウト(なくなった応答の場合の)</xs: ドキュメンテーション></xs: 注釈></xs: 要素></xs: 系列complexType>です。
<xs:element name="traceRoute">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="RequestMetadata"
type="tr:_Metadata"/>
<xs: 要素名=「トレースルート「><xs: complexType><xs: 系列><xs: 要素minOccurs=」0インチ名前="RequestMetadata"は=「tr: _メタデータ」/>をタイプします」。
<xs:element maxOccurs="2147483647" minOccurs="0"
name="Measurement">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="MeasurementMetadata"
type="tr:_Metadata"/>
<xs: 要素maxOccurs=「2147483647」minOccurs=「0インチの名前=」測定「><xs: complexType><xs: 系列><xs: 要素minOccurs=」0インチ名前="MeasurementMetadata"は=「tr: _メタデータ」/>をタイプします。
<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>
<xs: 要素maxOccurs=「2147483647」minOccursは「0インチ名前="MeasurementResult"は=></xs: 「tr: _測定」/></xs: 系列complexType></xs: 要素></xs: 系列></xs: complexType></xs: 要素></xs: 図式>をタイプすること」と等しいです。
8. Security Considerations
8. セキュリティ問題
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.
このセクションで議論したセキュリティ問題はトレースルート測定情報を保存して、伝えながらトレースルート測定値と関連する問題を行うと関連する問題に分類されます。
Niccolini, et al. Standards Track [Page 38] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[38ページ]。
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.
このメモはトレースルートツールの実装を指定しません。 どちらも、それはトレースルート測定情報を保存するためのある手順を指定しません。 それでも、それは以下の関連する安全保障問題について議論するのにおいて望ましいと考えられます。
8.1. Conducting Traceroute Measurements
8.1. トレースルート測定値を行います。
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.
伝導するインターネット測定値はセキュリティとプライバシーの問題の両方を提起できます。 正統の測定活動に変装するサービス不能攻撃のために、トレースルート測定(トラフィックはネットワークに注がれる)を乱用できます。
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.
測定トラフィックを異なった優先させるルータはトラフィックの、または、攻撃者のそばで注入している「標準」人工の測定トラフィックより測定自体に害を及ぼすことができました。 ルータが別々に測定トラフィックを認識して、それを扱うことができると、測定値は実施している者トラフィックを反映しないでしょう。 攻撃者が正統であるとして認められる人工のトラフィックを注入すると、損失率は人工的に下げられるでしょう。 したがって、測定方法論SHOULDは、「正常な」トラフィックと測定トラフィックを区別できるという確率を減少させるために適切なテクニックを含んでいます。
Authentication techniques, such as digital signatures, may be used where appropriate to guard against injected traffic attacks.
デジタル署名などの認証のテクニックは注入されたトラフィック攻撃に用心するのが適切であるところで使用されるかもしれません。
8.2. Securing Traceroute Measurement Information
8.2. トレースルート測定が情報であると機密保護します。
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.
トレースルート測定情報は非常に敏感であると考えられません。 それでも、それはネットワークのオペレータがビジネスかセキュリティ理由で保護したがっているかもしれないというネットワーク経路、ルーティング州、中古の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.
その結果、それはしかしまたそれを保存するとき情報入手が特にネットワークの上にそれを伝えるときトレースルート測定値を行うことによって取得したコントロールに重要です。 ネットワークの上のトレースルート測定情報の伝達がプライバシー、保全、および信憑性を保持するのに適切な保護メカニズムを使用するのは、RECOMMENDEDです。 安全な認証と承認が保存されたトレースルート測定情報を保護するのに使用されるのは、一層のRECOMMENDEDです。
Niccolini, et al. Standards Track [Page 39] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[39ページ]。
9. IANA Considerations
9. IANA問題
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.
このドキュメントはトレースルート測定情報保存とトランスミッションのためにXML名前空間とXML図式について説明するのにURNsを使用します、[RFC3688]で説明された登録メカニズムに従って。 2つのURI課題をしました。
1. Registration for the IPPM traceroute measurements namespace
1. IPPMトレースルート測定値名前空間のための登録
* URI: urn:ietf:params:xml:ns:traceroute-1.0
* URI: つぼ:ietf:params:xml:ナノ秒: トレースルート-1.0
* Registrant Contact: IESG
* 記入者接触: IESG
* XML: None. Namespace URIs do not represent an XML.
* XML: なし。 名前空間URIはXMLを表しません。
2. Registration for the IPPM traceroute measurements schema
2. IPPMトレースルート測定値図式のための登録
* URI: urn:ietf:params:xml:schema:traceroute-1.0
* URI: つぼ:ietf:params:xml:図式: トレースルート-1.0
* Registrant Contact: IESG
* 記入者接触: IESG
* XML: See Section 7 of this document.
* XML: このドキュメントのセクション7を見てください。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、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] ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、「MPLSラベルスタックコード化」、RFC3032(2001年1月)。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyneエド(G.、C.ニューマン)は「インターネットで以下の日付を入れて、調節します」。 「タイムスタンプ」、RFC3339、2002年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
Niccolini, et al. Standards Track [Page 40] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[40ページ]。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
[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.白、「リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトの定義」RFC4560(2006年6月)。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, March 2008.
[RFC5198] KlensinとJ.とM.Padlipsky、「ネットワーク置き換えのためのユニコード形式」、RFC5198、2008年3月。
10.2. Informative References
10.2. 有益な参照
[IEEE.1003-1G.1997]
Institute of Electrical and Electronics Engineers,
"Protocol Independent Interfaces", IEEE Standard 1003.1G,
March 1997.
[IEEE.1003-1G.1997]米国電気電子技術者学会、「プロトコルインディペンデント・インタフェース」、IEEEの標準の1003.1G、1997年3月。
[IPFIX] Sadasivan, G., "Architecture for IP Flow Information
Export", Work in Progress, September 2006.
G.、「IP流れ情報輸出のためのアーキテクチャ」という[IPFIX]Sadasivanは進歩、2006年9月に働いています。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、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] ニコルズ、K.、ブレーク、S.、ベイカー、F.、およびD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」、RFC2474(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.(エド)、パーキンス、D.(エド)、およびJ.Schoenwaelder(エド)、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(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.(エド)、パーキンス、D.(エド)、およびJ.Schoenwaelder(エド)、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2580] McCloghrieとK.とパーキンス、D.とJ.Schoenwaelder、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[RFC3688] 食事、M.、「IETF XML登録」、BCP81、RFC3688、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)プロトコルの仕様」、RFC5101(2008年1月)。
Niccolini, et al. Standards Track [Page 41] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[41ページ]。
[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.、ブライアント、S.、Claise、B.、エイトケン、P.、およびJ.マイヤー、「IP流れ情報輸出のための情報モデル」、RFC5102(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>.
T.、パオリ、J.、Maler、E.、Sperberg-マックィーン、C.、およびF.Yergeau、「拡張マークアップ言語(XML)1.0(第4版)」を[W3C. REC-xml-20060816]は、いななかせます、ワールドワイドウェブコンソーシアムFirstEdition REC-xml20060816、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] ビロン、P.、およびA.Malhotra、「XML図式第2部:」 「データ型式第2版」、ワールドワイドウェブコンソーシアム推薦REC-xmlschema-2-20041028、<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028 2004年10月の>。
Niccolini, et al. Standards Track [Page 42] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[42ページ]。
Appendix A. Traceroute Default Configuration Parameters
付録A.トレースルートデフォルト設定パラメータ
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.
このセクションは、様々なプラットホームにまた、トレースルート測定設定パラメータについてそれらのデフォルトに記載して、それらがどれくらい広く異なるかもしれないかを例証します。 このドキュメントは、4の主要なトレースルートツールが実装であると考えて、構成可能なパラメタとデフォルト値に基づいてそれらを比較します。 リヌクス(SUSE9.1)、BSD(無料OSの一つ7.0)、およびUNIX(SunOS5.9)実装はUDPデータグラムに基づいています、Windows(XP SP2)1は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 |
+---------------------------------------------------------+ | OS|オプション| 記述| デフォルト| +--------+------+-------------------------------+---------+ | リヌクス| -m|TTLが使用した最大を指定してください。| 30 | |--------+------|トレースルート徹底的調査で。 |---------| | 無料OSの一つ| -m| | OS var| |--------+------| |---------| | UNIX| -m| | 30 | |--------+------| |---------| | Windows| -h| | 30 | +--------+------+-------------------------------+---------+ | リヌクス| -n|ディスプレイホップアドレス| - | |--------+------|数の上で、むしろ。|---------| | 無料OSの一つ| -n|象徴的に。 | - | |--------+------| |---------| | UNIX| -n| | - | |--------+------| |---------| | Windows| -d| | - | +--------+------+-------------------------------+---------+ | リヌクス| -w|aを待つ時間を決めてください。| 3秒| |--------+------|徹底的調査への応答。 |---------| | 無料OSの一つ| -w| | 5秒| |--------+------| |---------| | UNIX| -w| | 5秒| |--------+------| |---------| | Windows| -w| | 4秒|
Niccolini, et al. Standards Track [Page 43] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[43ページ]。
+--------+------+-------------------------------+---------+
| 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 | | - |
+--------+------+-------------------------------+---------+ | リヌクス| なし|ゆるい送信元経路を指定してください。| - | |--------+------|gateway (to direct the |---------| | FreeBSD| -g |traceroute probes through | - | |--------+------|routers not necessarily in |---------| | UNIX | -g | the path). | - | |--------+------| |---------| | Windows| -g| | - | +--------+------+-------------------------------+---------+ | リヌクス| -p|ベースUDPポートナンバーを設定してください。| 33434 | |------- +------|トレースルート徹底的調査では、使用されます。|---------| | 無料OSの一つ| -p|(UDPポートはベース+nhopsと等しいです--1。) | 33434 | |--------+------| |---------| | UNIX| -p| | 33434 | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| -q|徹底的調査の数を設定します。| 3 | |--------+------|TTL。 |---------| | 無料OSの一つ| -q| | 3 | |--------+------| |---------| | UNIX| -q| | 3 | |--------+------| |---------| | Windows| なし| | 3 | +--------+------+-------------------------------+---------+ | リヌクス| -S|中にIPソースアドレスを設定してください。|IP| |--------+------|外向的である、調べます。|アドレス| | 無料OSの一つ| -s|規定値。 |the| |--------+------| |アウト| | UNIX| -s| |インタフェース| |--------+------| | | | Windows| なし| | | +--------+------+-------------------------------+---------+ | リヌクス| -t|サービス(TOS)のタイプを設定してください。| 0 | |--------+------|指定への徹底的調査で|---------| | 無料OSの一つ| -t|値。 | 0 | |--------+------| |---------| | UNIX| -t| | 0 | |--------+------| |---------| | Windows| なし| | 0 | +--------+------+-------------------------------+---------+ | リヌクス| -v|冗長な出力: 容認されたICMP| - | |--------+------|パケット|---------| | 無料OSの一つ| -v|そして時間_が超えていた。| - | |--------+------|UNREACHABLEは記載されています。 |---------| | UNIX| -v| | - | |--------+------| |---------| | Windows| なし| | - |
Niccolini, et al. Standards Track [Page 44] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[44ページ]。
+--------+------+-------------------------------+---------+
| 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 | | - |
+--------+------+-------------------------------+---------+ | リヌクス| なし|時間(msecにおける)を決めます。| - | |--------+------|徹底的調査の間に止まってください。 |---------| | 無料OSの一つ| -z| | 0 | |--------+------| |---------| | UNIX| -P| | 0 | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| -r|正常なルーティングを迂回させてください。| - | |--------+------|直接aにテーブルの上に置いて、送ります。|---------| | 無料OSの一つ| -r|付属ネットワークでは、接待します。 | - | |--------+------| |---------| | UNIX| -r| | - | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| -f|初期のTTLを設定します。| 1 | |--------+------|まず最初に、調べてください。 |---------| | 無料OSの一つ| -f| | 1 | |--------+------| |---------| | UNIX| -f| | 1 | |--------+------| |---------| | Windows| なし| | 1 | +--------+------+-------------------------------+---------+ | リヌクス| -F|「断片化しないでください」というビットを設定してください。 | - | |--------+------| |---------| | 無料OSの一つ| -F| | - | |--------+------| |---------| | UNIX| -F| | - | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| なし|ソケットレベルデバッグを可能にしてください。 | - | |--------+------| |---------| | 無料OSの一つ| -d| | - | |--------+------| |---------| | UNIX| -d| | - | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| なし|UDPの代わりにICMPエコーズを使用してください。| - | |--------+------|データグラム。|---------| | 無料OSの一つ| -I| | - | |--------+------| |---------| | UNIX| -I| | - | |--------+------| |---------| | Windows| なし| | - |
Niccolini, et al. Standards Track [Page 45] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[45ページ]。
+--------+------+-------------------------------+---------+
| 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 | | |
+--------+------+-------------------------------+---------+
+--------+------+-------------------------------+---------+ | リヌクス| -I|ネットワーク・インターフェースを指定します。| - | |--------+------|IPアドレスを得ます。|---------| | 無料OSの一つ| -i|出発しているIPパケット| - | |--------+------|(オプション-sへの代替の。) |---------| | UNIX| -i| | - | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| なし|チェックサムを切り換えてください。 | - | |--------+------| |---------| | 無料OSの一つ| -x| | - | |--------+------| |---------| | UNIX| -x| | - | |--------+------| |---------| | Windows| なし| | - | +--------+------+-------------------------------+---------+ | リヌクス| - |最後の任意のパラメタとして|よります。| |--------+------|リヌクス、無料OSの一つ、およびUNIX|オン| | 無料OSの一つ| - |実装は許容します。|道具| |--------+------|徹底的調査データグラムを指定します。|ation。 | | UNIX| - |外向的な徹底的調査のための長さ。 | | |--------+------| | | | Windows| なし| | | +--------+------+-------------------------------+---------+
A.1. Alternative Traceroute Implementations
A.1。 代替のトレースルート実装
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ベースのトレースルートを防ぐかもしれません。 いくつかの場合、そのような限界は、ファイアウォールの後ろに位置するホストが接続における、進行中の聴取であることが特定のポートに代わりにパケットをTCPに送ることによって、克服されるかもしれません。 TCPベースの実装は、経路のファイアウォールとゲートウェイからTCP、SYN、またはFIN探測装置を使用して、タイム誌_EXCEEDEDメッセージ、TCP RESET、および他のメッセージを聞こうとします。 他方では、いくつかのファイアウォールがサービス不能攻撃を防ぐためにTCP SYNパケットを無視します。 したがって、UDPトレースルートの代わりにTCPを使用する実際の利点は主にファイアウォール構成に依存します。構成はあらかじめ、知られていません。 このドキュメントの範囲の外にTCPベースのトレースルートツールと測定値の詳細に渡る分析があります。 不注意に、また、完全性理由で、情報モデルはTCPベースのトレースルート測定値の保存をサポートします。
Niccolini, et al. Standards Track [Page 46] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[46ページ]。
Appendix B. Known Problems with Traceroute
トレースルートの付録B.既知の問題
B.1. Compatibility between Traceroute Measurement Results and IPPM
Metrics
B.1。 トレースルート測定結果とIPPM測定基準との互換性
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.
実装選択のために、現在のトレースルートツール実装によって返されたRFC2681と結果でIPPMワーキンググループによって定義されて、知られている矛盾は往復の遅れの間にメートル法であることで存在しています。 残念ながら、トレースルートツール実装が近い将来標準定義を実装するのは、ありそうもないです。 唯一の可能性はしたがって、異なったトレースルート測定値の結果を互いに比べることです。 これをして、オペレーティングシステム(名前とバージョン)とトレースルートツールバージョンの両方が使用した仕様は、2つの異なったトレースルート測定結果の間の測定基準を比較するのを手伝う(同じオペレーティングシステムとツールの同じバージョンを使用する走行であるなら)ためにメタデータ要素に追加されました。 そのうえ、トレースルートツールは、タイムアウトのような内蔵の構成可能なメカニズムを持って、ファイアウォールの交差点に関連する問題になることができます。 したがって、タイムアウトであるかフィルターにかけられて、トレースルートが出すパケットのいくつかが終わります。 結果として、経路をノードにたどるのが可能でないかもしれないか、またはそれに達するようにRTTについて説明する十分完全なセットの徹底的調査がないかもしれません。
Appendix C. Differences to DISMAN-TRACEROUTE-MIB
DISMANトレースルートMIBへの付録C.差
For performing remote traceroute operations at managed node, the IETF has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560]. This module allows:
管理されたノードでリモートトレースルート操作を実行するために、IETFは[RFC4560]のDISMAN-TRACEROUTE-MIBモジュールを標準化しました。 このモジュールは以下を許容します。
o retrieving capability information of the traceroute tool
implementation at the managed node;
o 管理されたノードでトレースルートツール実装の能力情報を検索します。
o configuring traceroute measurements to be performed;
o 実行されるためにトレースルート測定を構成します。
o retrieving information about ongoing and completed traceroute
measurements;
o 進行中の、そして、完成したトレースルート測定値の情報を検索します。
o retrieving traceroute measurement statistics.
o トレースルート測定統計を検索します。
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.
本書では説明されたトレースルートストレージ形式はこのMIBモジュールに重要なオーバラップを持っています。 特に、トレースルート測定構成と完成した測定値からの結果のためのモデルはほとんど同じです。 しかし、DISMAN-TRACEROUTE MIBモジュールの他の部分には、トレースルート測定ストレージ形式でそれらをモデル化する必要は全くありません。 特に、能力情報、進行中の測定値の情報、および測定統計はDISMANトレースルートストレージモデルで含まれていません。
Niccolini, et al. Standards Track [Page 47] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[47ページ]。
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.
トレースルート測定値とそれらの結果に関して、仕様のコード化のための異なった選択で引き起こされた2つのモデルの間には、構造的な違いがあります。 DISMAN- TRACEROUTE-MIBのために、Management情報(SMIv2、STD58、RFC2578[RFC2578])のStructureは使用されました、IPPMトレースルート測定データモデルが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.
しかし、残っている情報要素の大部分において、トレースルート測定値のその関心構成と完成した測定値の結果、意味論はDISMAN- TRACEROUTE-MIBモジュールとトレースルート測定データモデルの間で同じです。 これへのほんのわずかな例外があります。 これらは以下に記載されています。 また、情報要素の命名も両方のモデルの間で若干の例外はあるものの同じです。 トレースルート測定データモデルにおいて、いくつかの情報要素が加えられて、異なった構造によるいくつかと追加情報を提供する或るものは測定値を完成しました。
C.1. Scope
C.1。 範囲
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モジュールとトレースルート測定データモデルの間の範囲の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"です。 このテーブルは状態のオンライン観測と進行中のトレースルート測定の進歩を許容します。 それがダイナミックに個々のトレースルート測定値の進歩を報告するのにモデルを使用するために思い描かれていないので、この非常にダイナミックな情報はトレースルート測定データモデルに含まれていません。 むしろ、完成したトレースルート測定値を報告するのにトレースルート測定データモデルが使用されることを意図します。
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インスタンスを接待するローカルのノードに通常結ばれるという事実のためです。 ネットワークにおけるいくつかの徹底的調査に適用されるかもしれない測定要求を指定するのにトレースルート測定データモデルで指定された"RequestMetadata"要素は使用できます。 この概念はDISMAN-TRACEROUTE-MIBモジュールで存在していません。
Niccolini, et al. Standards Track [Page 48] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[48ページ]。
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モジュールとトレースルート測定データモデルの残っている要素のために、2つの世界の間には、申し分のない相手があります。 "traceRouteCtlTable"は"MeasurementMetadata"要素に対応しています、そして、"traceRouteProbeHistoryTable"と"traceRouteHopsTable"の組み合わせは"MeasurementResult"要素の収集に対応しています。
C.2. Naming
C.2。 命名
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.
トレースルート測定設定情報に関しては、XMLファイルの不要な冗長を避けるために取り除かれたtraceRoute接頭語以外の両方のモデルと"CtlDataSize"に、"CtlProbesPerHop"などのすべての名前が同じです。(それは、トレースルート測定データモデルにおける明確化のために"CtlProbeDataSize"に改名されました)。
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")があります。 データがレポートだけを似せるトレースルート測定が測定値を完成したので、この分離はそれ以上必要ではありません、そして、接頭語「結果」はすべての関連情報要素に使用されます。
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 "HopAddr"への"traceRouteProbeHistoryHAddr"。
o "traceRouteProbeHistoryTime" to "ResultsEndDateAndTime";
o "ResultsEndDateAndTime"への"traceRouteProbeHistoryTime"。
o "traceRouteProbeHistoryLastRC" to "ResultsHopRawOutputData".
o "ResultsHopRawOutputData"への"traceRouteProbeHistoryLastRC"。
C.3. Semantics
C.3。 意味論
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の値は、探測装置を送るのが可能でないことを示します。 トレースルート測定データモデル、要素のための0の値のために
Niccolini, et al. Standards Track [Page 49] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[49ページ]。
"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の値は、インデックスを設定するオプションが利用可能でないことを示します。 これはトレースルート測定データモデルに翻訳されました、この要素のための0の値が、中古のインタフェースが未知であることを示すように。
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"は、完全な生の出力データ(1ホップあたりの)が使用されたトレースルート測定で作り出されたと報告します。
C.4. Additional Information Elements
C.4。 追加情報Elements
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 トレースルート測定経路の徹底的調査のMPLSラベルスタックエントリーの情報を提供するのにおいて、"MPLSLabelStackEntry"は加えられました。
o For providing additional timestamp beyond "ResultsEndDateAndTime",
"ResultsStartDateAndTime" and "Time" were added.
o "ResultsEndDateAndTime"を超えて追加タイムスタンプを提供するのにおいて、"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"(時間がたつにつれて、変化するかもしれない)のために名前をDNSに供給するのにおいて、"HopName"は加えられました。
Appendix D. Traceroute Examples with XML Representation
XML表現がある付録D.トレースルートの例
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.
このセクションはトレースルートアプリケーションに関するいくつかの例を示しています。 さらに、要求と結果のコード化はそれらの例のいくつかのために示されます。 また、これらの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 * *
リヌクスシステムの上の典型的なトレースルートは以下に似ています: # 1500年のww.exampleへのトレースルート-f4www.exampleトレースルート、(192.0に、.42、)30が飛び越す.2は最大限にします、1500年のバイトのパケット5out.host1.example、(192.0.2.254)6.066ms5.625ms6.095ms6rtr4.host6.example、(192.0.2.142)6.979ms6.221ms7.368ms7hop7.rtr9.example、(192.0.2.11)16.165ms15.347が15.514ms8 192.0に.2をmsする、.222、(192.0.2.222)32.796ms28.723のmsの26.988のmsの9インチの例、(192.0.2.123)15.861ms16.262のmsの17.610のmsの10インチの例(192.0 .2 .123) (N!) 17.391 ms**
Niccolini, et al. Standards Track [Page 50] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[50ページ]。
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/>
このトレースルートは、最初の4つのホップを無視して、ヘッダーを含む1500年のバイトのパケットを使用します。 最後の記載されたホップが、ネットワークが届いていないと言うので(N!)、それは目的を達成しません。 この跡のXML表現は続きます: <?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチそれがXML</CtlDescrで><CtlType><UDP/></CtlType></RequestMetadata><Measurement><MeasurementMetadata><TestName>Example1</TestName><OSName>リナックス</OSName @?OSVersion h2をコード化する?CtlMaxFailures/??CtlDontFragment/??CtlInitialTtl?4?/CtlInitialTtl??CtlDescr?ショー｛rt/>。
Niccolini, et al. Standards Track [Page 51] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[51ページ]。
<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>
<CtlMaxTtl/><CtlDSField/><CtlSourceAddress><inetAddressIpv4>192.0.2; 1 </inetAddressIpv4></CtlSourceAddress><CtlIfIndex>2</CtlIfIndex><CtlMiscOptions/><CtlMaxFailures/><CtlDontFragment/><CtlInitialTtl>4</CtlInitialTtl><CtlDescr>ショー; それはXML</CtlDescrでどう><CtlType><UDP/></CtlType></MeasurementMetadata><MeasurementResult><TestName>Example1</TestName><ResultsStartDateAndTime>2008-05-16T14をコード化するか:; 22:34+02:00</ResultsStar tDateAndTime><ResultsIpTgtAddr><inetAddressIpv4>192; 0.2; 42 </inetAddressIpv4></ResultsIpTgtAddr><ProbeResults><ホップ><徹底的調査><HopAddr><inetAddressIpv4>192.0.2.254</inetAddressIpv4></HopAddr><HopName>out.host1; 例の</HopName><ProbeRoundTripTime><roundTripTime>6</roundTripTime></ProbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-16T14: 22:35 </時間></徹底的調査><+02:00は><HopAddr><inetAddressIpv4>192を調べます; 0.2.254 </inetAddressIpv4></HopAddr><HopName>out.host1.example</HopName><ProbeRoundTripTime><roundTripTime>5</roundTripTime></プロbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-16T14: 22:35</時間></徹底的調査><+02:00は><HopAddr><inetAddressIpv4>192.0.2.254</inetAddressIpv4></HopAddr><HopName>out.host1.example</HopName>を調べます。
Niccolini, et al. Standards Track [Page 52] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[52ページ]。
<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>
0.2.142 </inetAddressIpv4></HopAddr><HopName>rtr4.host6.example</HopName><ProbeRoundTripTime><roundTripTime>6</roundTripTime></ProbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-16T14: 22:36+02:00</時間></徹底的調査><徹底的調査><HopAddr><inetAddressIpv4 @192‥TripTime></ProbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><Time>2008-05-16T14: 22:37+02:00</時間></徹底的調査><HopRawOutputData>6rtr4.host6.example、(192.0.2.142)6.9 79ms6.221ms7.368ms</HopRawOutputData></ホップ><ホップ><徹底的調査>。
Niccolini, et al. Standards Track [Page 53] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルートストレージ形式2008年12月にRFC5388を追跡します[53ページ]。
<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>
<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>
Niccolini, et al. Standards Track [Page 54] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 54] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 55] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 55] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 56] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 56] RFC 5388 Traceroute Storage Format December 2008
<ResultsEndDateAndTime>2008-05-16T14:22:44+02:00</ResultsEndDat
eAndTime>
</MeasurementResult>
</Measurement>
</traceRoute>
<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
The second example was generated on an OpenBSD system. On that system, the traceroute looks like the following: # traceroute -P tcp w2.example 128
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
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
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/>
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/>
Niccolini, et al. Standards Track [Page 57] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 57] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 58] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 58] RFC 5388 Traceroute Storage Format December 2008
<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> <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>
Niccolini, et al. Standards Track [Page 59] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 59] RFC 5388 Traceroute Storage Format December 2008
</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>
</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>
Niccolini, et al. Standards Track [Page 60] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 60] RFC 5388 Traceroute Storage Format December 2008
<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: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>
Niccolini, et al. Standards Track [Page 61] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 61] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 62] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 62] RFC 5388 Traceroute Storage Format December 2008
<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.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>
Niccolini, et al. Standards Track [Page 63] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 63] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 64] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 64] RFC 5388 Traceroute Storage Format December 2008
<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>
<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:
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:
# 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:
Tracing route to www.example.org [192.0.2.11] over a maximum of 10 hops:
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
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
Niccolini, et al. Standards Track [Page 65] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 65] RFC 5388 Traceroute Storage Format December 2008
Trace complete.
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/>
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/>
Niccolini, et al. Standards Track [Page 66] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 66] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 67] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 67] RFC 5388 Traceroute Storage Format December 2008
<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>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>
Niccolini, et al. Standards Track [Page 68] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 68] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 69] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 69] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 70] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 70] RFC 5388 Traceroute Storage Format December 2008
</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> </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>
Niccolini, et al. Standards Track [Page 71] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 71] RFC 5388 Traceroute Storage Format December 2008
<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>
<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>
Niccolini, et al. Standards Track [Page 72] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 72] RFC 5388 Traceroute Storage Format December 2008
</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>
</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>
Niccolini, et al. Standards Track [Page 73] RFC 5388 Traceroute Storage Format December 2008
Niccolini, et al. Standards Track [Page 73] RFC 5388 Traceroute Storage Format December 2008
<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>
<ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-14T11: 03:20+02:00</時間></徹底的調査><徹底的調査><HopAddr><inetAddressIpv4>、192.0、.2; 44 </inetAddressIpv4></HopAddr><ProbeRoundTripTime><roundTripTime>169</roundTripTime></ProbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-14T11: 03:21 </時間></徹底的調査><+02:00は><HopAddr><inetAddressIpv4>192を調べます; 0.2; 44 </inetAddressIpv4></HopAddr><ProbeRoundTripTime><roundTripTime>169</roundTripTime></ProbeRoundTripTime><ResponseStatus>responseReceived</ResponseStatus><時間>2008-05-14T11:; 03:23+02:00</時間></徹底的調査></ホップ></ProbeResults><ResultsEndDateAndTime>2008-05-14T11: 03:23+02:00</ResultsEndDat eAndTime></MeasurementResult></測定></トレースルート>。
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にどう跡を表すことができたかに関する印象を与えることを意図します。 トレースルート実現のシステムと能力によって、実現で発生する表現はここで例と異なるかもしれません。
Niccolini, et al. Standards Track [Page 74] RFC 5388 Traceroute Storage Format December 2008
ニッコリーニ、他 規格はトレースルート格納形式2008年12月にRFC5388を追跡します[74ページ]。
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ニッコリーニ・NEC研究所ヨーロッパ、NECヨーロッパ株式会社Kurfuersten-原基36ハイデルベルグ69115ドイツ電話: +49 (0)6221 4342 118はメールされます: saverio.niccolini@nw.neclab.eu ユリ: 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
サンドラ・Tartarelli NEC研究所ヨーロッパ、NECヨーロッパ株式会社Kurfuersten-原基36ハイデルベルグ69115ドイツ電話: +49 (0)6221 4342 132はメールされます: sandra.tartarelli@nw.neclab.eu ユリ: 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
ユルゲン・Quittek NEC研究所ヨーロッパ、NECヨーロッパ株式会社Kurfuersten-原基36ハイデルベルグ69115ドイツ電話: +49 (0)6221 4342 115はメールされます: quittek@nw.neclab.eu ユリ: http://www.nw.neclab.eu
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
トーマス・ディーツ・NEC研究所ヨーロッパ、NECヨーロッパ株式会社Kurfuersten-原基36ハイデルベルグ69115ドイツ電話: +49 (0)6221 4342 128はメールされます: thomas.dietz@nw.neclab.eu ユリ: 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
コンピュータと情報科学デラウエア大学ニューアークDE19716米国メールのマーチンSwany部: swany@UDel.Edu
Niccolini, et al. Standards Track [Page 75]
ニッコリーニ、他 標準化過程[75ページ]
一覧
スポンサーリンク
