view Side-By-Side changes

IPPM





Network Working Group                                       S. Niccolini
Internet-Draft
Request for Comments: 5388                                 S. Tartarelli
Intended status:
Category: Standards Track                                     J. Quittek
Expires: April 26, 2009
                                                                T. Dietz
                                                                     NEC
                                                                M. Swany
                                                                    UDel
                                                        October 23,
                                                           December 2008


    Information Model and XML Data Model for Traceroute Measurements
                  draft-ietf-ippm-storetraceroutes-12

Status of this This Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of

   This document specifies an Internet standards track protocol for the
   Internet Engineering
   Task Force (IETF), its areas, community, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid requests discussion and suggestions for a maximum
   improvements.  Please refer to the current edition of six months the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It status of this protocol.  Distribution of this memo is inappropriate to use Internet-Drafts unlimited.

Copyright Notice

   Copyright (c) 2008 IETF Trust and the persons identified as reference
   material or the
   document authors.  All rights reserved.

   This document is subject to cite them other than as "work BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (http://trustee.ietf.org/
   license-info) in progress."

   The list effect on the date of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list publication of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 26, 2009. this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This document describes a standard way to store the configuration and
   the results of traceroute measurements.  This document first of all
   describes the terminology used in this document and the traceroute
   tool itself; afterwards, the common information model is defined defined,
   dividing the information elements in into two semantically separated
   groups (configuration elements and results elements).  Moreover  Moreover, an
   additional element is defined to relate configuration elements and
   results elements by means of a common unique identifier.  On the



Niccolini, et al.        Expires April 26, 2009                 [Page 1]

Internet-Draft          Traceroute Storage Format           October 2008
   basis of the information model model, a data model based on XML is defined
   to store the results of traceroute measurements.








Niccolini, et al.           Standards Track                     [Page 1]

RFC 5388               Traceroute Storage Format           December 2008


Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3 ....................................................3
   2. Terminology used Used in this document  . . . . . . . . . . . . . .  3 This Document ...............................3
   3. The Traceroute tool Tool and its operations . . . . . . . . . . . .  4 Its Operations ..........................4
   4. Results of traceroute measurements . . . . . . . . . . . . . .  4 Traceroute Measurements ..............................5
   5. Information Model for Traceroute Measurements  . . . . . . . .  5 ...................5
      5.1. Data Types . . . . . . . . . . . . . . . . . . . . . . . .  6 .................................................6
      5.2. Information Elements . . . . . . . . . . . . . . . . . . .  7 .......................................7
           5.2.1.  Relationship Relationships between the Information Elements  . . . .  7 ......7
           5.2.2. Configuration Information Elements . . . . . . . . . . 10 .................12
           5.2.3. Results Information Elements . . . . . . . . . . . . . 15 .......................17
           5.2.4. Information Element Correlating
                  Configuration and Results Elements . . . . . . . . . . . . . . . . . . . 18 ..........................21
           5.2.5. Information Elements to compare traceroute
               measurements results one with each other . . . . . . . 18 Compare Traceroute
                  Measurement Results ................................22
   6. Data Model for Storing Traceroute Measurements . . . . . . . . 19 .................23
   7. XML Schema for traceroute Traceroute Measurements . . . . . . . . . . . . 20 .........................24
   8. Security Considerations  . . . . . . . . . . . . . . . . . . . 35 ........................................38
      8.1. Conducting Traceroute Measurements . . . . . . . . . . . . 35 ........................39
      8.2. Securing Traceroute Measurements Measurement Information . . . . . . . 36 ...............39
   9. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 36 ............................................40
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 ....................................................40
      10.1. Normative References . . . . . . . . . . . . . . . . . . . 36 .....................................40
      10.2. Informative References . . . . . . . . . . . . . . . . . . 37 ...................................41
   Appendix A. Traceroute Default Configuration Parameters . . . . . 38 ...........43
      A.1. Alternative Traceroute Implementations . . . . . . . . . . 42 ....................46
   Appendix B. Known Problems with Traceroute  . . . . . . . . . . . 42 ........................47
      B.1. Compatibility between traceroute measurements results Traceroute Measurement Results
           and IPPM metrics . . . . . . . . . . . . . . . . . . . . . 42 Metrics ..........................................47
   Appendix C. Differences to DISMAN-TRACEROUTE-MIB  . . . . . . . . 43 ..................47
      C.1. Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . 44 .....................................................48
      C.2. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 44 ....................................................49
      C.3. Semantics  . . . . . . . . . . . . . . . . . . . . . . . . 45 .................................................49
      C.4. Additional Information Elements  . . . . . . . . . . . . . 45 ...........................50
   Appendix D. Traceroute Examples with XML representation . . . . . 46
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
   Intellectual Property and Copyright Statements . . . . . . . . . . 72 Representation ...........50















Niccolini, et al.        Expires April 26, 2009           Standards Track                     [Page 2]

Internet-Draft

RFC 5388               Traceroute Storage Format           October           December 2008


1.  Introduction

   Traceroutes are being used by lots of measurement efforts, either as
   an
   independent measurement measurements or to get 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
   working
   group in matter matters of delay, connectivity connectivity, and losses do not apply to
   the metrics returned by the traceroute tool; therefore, 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 a
   an XML schema.

   The document is organized as follows: Section 2 defines the
   terminology used in this document, document; Section 3 describes the traceroute tool,
   tool; Section 4 describes the results of a traceroute measurement as
   displayed to the screen from which the traceroute tool was launched. launched;
   Section 5 and Section 6 respectively 6, respectively, describe the information model
   and data model for storing configuration and results of the
   traceroute measurements. measurements; Section 7 contains the XML schema to be used
   as a template for storing and/or exchanging traceroute measurements information.  The measurement
   information; the document ends with security considerations and IANA
   considerations in Section 8 and Section 9 respectively.

   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].

2.  Terminology used Used in this document This Document

   The terminology used in this document is defined as follow: follows:

   o  traceroute tool: a software tool for network diagnostic behaving that
      behaves as described in Section 3;

   o  traceroute measurement: an instance of the traceroute tool
      launched, with specific configuration parameters (traceroute
      measurement configuration parameters), from a specific host
      (initiator of the traceroute measurement) giving as output
      specific traceroute measurement results;

   o  traceroute probe: one of many IP packets send sent out by the
      traceroute tool during a traceroute measurement;





Niccolini, et al.           Standards Track                     [Page 3]

RFC 5388               Traceroute Storage Format           December 2008


   o  traceroute measurement configuration parameters: the configuration
      parameters of a traceroute measurement;

   o  traceroute measurement results: the results of a traceroute
      measurement;




Niccolini, et al.        Expires April 26, 2009                 [Page 3]

Internet-Draft          Traceroute Storage Format           October 2008

   o  traceroute measurement information: both the results and the
      configuration parameters of a traceroute measurement;

   o  traceroute measurement path: a sequence of hosts transited in
      order by traceroute probes during a traceroute measurement; measurement.

3.  The Traceroute tool Tool and its operations Its Operations

   Traceroute is a network diagnostic tool used to determine the hop by 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.

   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.

   More in

   In more detail, a first set of probes with TTL equal to 1 are 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 of increasing 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.

   Some implementations, implementations use ICMP Echoes, instead of UDP datagrams.
   However, many routers do not return ICMP messages about ICMP
   messages, i.e. i.e., no ICMP TIME_EXCEEDED is returned for an ICMP Echo.





Niccolini, et al.           Standards Track                     [Page 4]

RFC 5388               Traceroute Storage Format           December 2008


   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.

4.  Results of traceroute measurements Traceroute Measurements

   The following list reports the information fields provided as results



Niccolini, et al.        Expires April 26, 2009                 [Page 4]

Internet-Draft          Traceroute Storage Format           October 2008
   by all traceroute tool implementations considered.  The order in
   which they are reported here is not relevant and it changes in different
   implementations.  For each hop hop, the following information reported is: is
   reported:

   o  the hop index;

   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 host, and that the option to display only
      numerical addresses was not set;

   o  the host IP address, provided that at least one of the probes
      received a response;

   o  the RTT for each response to a probe.

   Depending on the traceroute tool implementation, additional
   information might be displayed in the output (for instance instance, MPLS-
   related information).

   It might happen that some probes do not receive a response within the
   configured time-out timeout (for instance 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"
   "RoundTripTimeNotAvailable", meaning either the probe was lost
   because of a time-out 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 one, thus
   looking like multiple hops, the hops.  The information model is not impacted by
   this since each line is handled separately and separately; it is left to the
   applications handling the XML file how to deal with it.  Moreover,
   for delays below 1 ms, some implementations reports report 0 ms (e.g. (e.g., UNIX
   and LINUX) LINUX), while WINDOWS tracert reports "< 1 ms".

5.  Information Model for Traceroute Measurements

   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


   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 lower-case letter, e.g.,
      "sourceIpAddress".

   o  description - The semantics of this information element.

   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  units - If the element is a measure of some kind, the units
      identify what the measure is.





Niccolini, et al.        Expires April 26, 2009                 [Page 5]

Internet-Draft          Traceroute Storage Format           October 2008

5.1.  Data Types

   This section describes the set of basic valid data types of the
   information model.

   o  String  string - The type "String" "string" represents a finite length 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 USASCII characters, US-ASCII characters but
      which also accommodates other Unicode multi-byte characters.

   o  String255  string255 - Same type as "String" "string" but with the restriction to of 255
      characters.

   o  InetAddressType  inetAddressType - The type "InetAddressType" "inetAddressType" represents a type of
      Internet address.  The allowed values are to be intended as imported from [RFC4001]
      (where the intent was to import only some of the values);
      additional allowed value values are "asnumber" and "noSpecification".

   o  InetAddress  inetAddress - The type "InetAddress" "inetAddress" denotes a generic Internet
      address.  The allowed values are imported from [RFC4001] (the
      values imported are unknown, ipv4, ipv6 ipv6, and dns), while non-global non-
      global IPv4/IPv6 addresses (e.g. (e.g., ipv4z and ipv6z) were are excluded;
      an additional allowed value is the AS number to be number, indicated as the
      actual number plus the indication of how the mapping from IP
      address to AS number was performed. "unknown"  "Unknown" is used to indicate
      an IP address that is not in one of the formats defined.

   o  ipASNumberMappingType - The type "ipASNumberMappingType"
      represents a type of mapping from IP to AS number, it indicated indicates
      the method that was used to do get the mapping (allowed values are
      "bgptables", "routingregistries", "nslookup", "others" or
      "unknown").



Niccolini, et al.           Standards Track                     [Page 6]

RFC 5388               Traceroute Storage Format           December 2008


   o  Boolean  boolean - The type "boolean" represents a Boolean boolean value according
      to XML standards [W3C.REC-xmlschema-2-20041028].

   o  UnsignedInt  unsignedInt - The type "UnsignedInt" "unsignedInt" represents a value in the
      range (0..4294967295).

   o  UnsignedShort  unsignedShort - The type "UnsignedShort" "unsignedShort" represents a value in the
      range (0..65535).

   o  UnsignedByte  unsignedByte - The type "UnsignedByte" "unsignedByte" represents a value in the
      range (0..255).

   o  u8nonzero - The type "u8nonzero" represents a value in the range
      (1..255).

   o  ProbesType  probesType - The type "ProbesType" "probesType" represents a way of indicating
      the protocol used for the traceroute probes.  Values defined in
      this document are UDP, TCP TCP, and ICMP.

   o  OperationResponseStatus  operationResponseStatus - The type "OperationResponseStatus" "operationResponseStatus" is
      used to report the result of an operation.  The allowed values are
      to be intended as
      imported from [RFC4560].




Niccolini, et al.        Expires April 26, 2009                 [Page 6]

Internet-Draft          Traceroute Storage Format           October 2008

   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].

5.2.  Information Elements

   This section describes the elements related to the storing of a
   traceroute measurement.  The elements are grouped in two groups
   (Configuration
   (configuration and Results) 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
   the two
   groups.

5.2.1.  Relationship  Relationships between the Information Elements

   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  0..4294967295  0..2147483647 "Measurement" elements; elements.



Niccolini, et al.           Standards Track                     [Page 7]

RFC 5388               Traceroute Storage Format           December 2008


   Each "Measurement" element contains:

   o  1 optional "MeasurementMetadata" element;

   o  0..4294967295  0..2147483647 "MeasurementResult" elements; elements.

   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 by for a specific traceroute measurement is specified in a
   "MeasurementMetadata" element.

   The "RequestMetadata" element is a sequence that contains:

   o  1 "TestName" element;

   o  1 optional "ToolVersion" element;

   o  1 optional "ToolName" element;

   o  1 "CtlTargetAddress" element;

   o  1 optional "CtlBypassRouteTable" element;

   o  1 optional "CtlProbeDataSize" element;





Niccolini, et al.        Expires April 26, 2009                 [Page 7]

Internet-Draft          Traceroute Storage Format           October 2008

   o  1 optional "CtlTimeOut" element;

   o  1 optional "CtlProbesPerHop" element;

   o  1 optional "CtlPort" element;

   o  1 optional "CtlMaxTtl" element;

   o  1 optional "CtlDSField" element;

   o  1 optional "CtlSourceAddress" element;

   o  1 optional "CtlIfIndex" element;

   o  1 optional "CtlMiscOptions" element;

   o  1 optional "CtlMaxFailures" element;

   o  1 optional "CtlDontFragment" element;




Niccolini, et al.           Standards Track                     [Page 8]

RFC 5388               Traceroute Storage Format           December 2008


   o  1 optional "CtlInitialTtl" element;

   o  1 optional "CtlDescr" element;

   o  1 "CtlType" element; element.

   If the "RequestMetadata" element is omitted from an XML file then file, it
   means that the traceroute measurement configuration parameters
   requested were all used and the "MeasurementMetadata" element list lists
   them in detail.

   The "MeasurementMetadata" element is a sequence that contains:

   o  1 "TestName" element;

   o  1 "OSName" element;

   o  1 "OSVersion" element;

   o  1 "ToolVersion" element;

   o  1 "ToolName" element;

   o  1 "CtlTargetAddressType" element;

   o  1 "CtlTargetAddress" element;

   o  1 "CtlBypassRouteTable" element;

   o  1 "CtlProbeDataSize" element;

   o  1 "CtlTimeOut" element;

   o  1 "CtlProbesPerHop" element;

   o  1 "CtlPort" element;

   o  1 "CtlMaxTtl" element;

   o  1 "CtlDSField" element;

   o  1 "CtlSourceAddressType" element;

   o  1 "CtlSourceAddress" element;

   o  1 "CtlIfIndex" element;

   o  1 optional "CtlMiscOptions" element;



Niccolini, et al.           Standards Track                     [Page 9]

RFC 5388               Traceroute Storage Format           December 2008


   o  1 "CtlMaxFailures" element;

   o  1 "CtlDontFragment" element;

   o  1 "CtlInitialTtl" element;

   o  1 optional "CtlDescr" element;

   o  1 "CtlType" element; element.

   Configuration Information Elements information elements can describe not just traceroute
   measurements that have already happened ("MeasurementMetadata"
   elements), but also the configuration to be used when requesting a



Niccolini, et al.        Expires April 26, 2009                 [Page 8]

Internet-Draft          Traceroute Storage Format           October 2008
   measurement to be made ("RequestMetadata" element).  This is quite
   different semantically, even if the individual information elements
   are similar.  Due to this similarity similarity, both "RequestMetadata" as well
   as 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" "RequestMetadata",
   but since default values cannot be specified for complex types in an
   XML schema schema, the element is mandatory also in the "RequestMetadata".

   The "MeasurementResult" element is a sequence that contains:

   o  1 "TestName" element;

   o  1 "ResultsStartDateAndTime" element;

   o  1 "ResultsIpTgtAddrType" element;

   o  1 "ResultsIpTgtAddr" element;

   o  1 "ProbeResults" elements;

   o  1 "ResultsEndDateAndTime" element;

   Additionally element.

   Additionally, it is important to say that each "ProbeResults" element
   is a sequence that contains:

   o  1..255 "hop" elements; elements.

   Each "hop" element is a sequence that contains contains:

   o  1..10 "probe" elements;




Niccolini, et al.           Standards Track                    [Page 10]

RFC 5388               Traceroute Storage Format           December 2008


   o  1 optional "HopRawOutputData" element; element.

   Each "probe" element contains:

   o  1 "HopAddrType" element;

   o  1 "HopAddr" element;

   o  1 optional "HopName" element;

   o  0..255 optional "MPLSLabelStackEntry" elements;

   o  1 "ProbedRoundTripTime" element;

   o  1 "ResponseStatus" element;

   o  1 "Time" element; element.

   Different numbers of appearances of the three basic elements in the
   XML file are meant for different scopes:

   o  a file with only 1 "RequestMetadata" element represents a file
      containing the traceroute measurement configuration parameters of
      a traceroute measurement, measurement; it can be used to distribute the
      traceroute measurement configuration parameters over multiple



Niccolini, et al.        Expires April 26, 2009                 [Page 9]

Internet-Draft          Traceroute Storage Format           October 2008
      nodes asked to run the same traceroute measurement;

   o  a file with 1 "Measurement "Measurement" element containing 1
      "MeasurementMetadata" and 1 "MeasurementResult" element represents
      a file containing the traceroute measurement information of a
      traceroute measurement;

   o  a file with 1 "Measurement "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  a file with 1 "RequestMetadata" and 1 "Measurement "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  other combinations are possible to store multiple traceroute
      measurements all in one XML file.



Niccolini, et al.           Standards Track                    [Page 11]

RFC 5388               Traceroute Storage Format           December 2008


5.2.2.  Configuration Information Elements

   This section describes the elements specific to the configuration of
   the traceroute measurement (belonging to both the "RequestMetadata"
   and "MeasurementMetadata" elements).

5.2.2.1.  CtlTargetAddressType

   o  name - CtlTargetAddressType

   o  description - Specifies the type of address in the corresponding
      CtlTargetAddress
      "CtlTargetAddress" element.  This element is not directly
      reflected in the XML Schema schema of Section 7.  The host address type
      can be determined by examining the inetAddress type name and the
      corresponding element value.

   o  dataType - InetAddressType inetAddressType

   o  units - N/A

5.2.2.2.  CtlTargetAddress

   o  name - CtlTargetAddress

   o  description - In the "RequestMetadata" element element, it specifies the
      host address requested to be used in the traceroute measurement.
      In the "MeasurementMetadata" element element, it specifies the host
      address used in the traceroute measurement.

   o  dataType - InetAddress inetAddress

   o  units - N/A





Niccolini, et al.        Expires April 26, 2009                [Page 10]

Internet-Draft          Traceroute Storage Format           October 2008

5.2.2.3.  CtlBypassRouteTable

   o  name - CtlBypassRouteTable

   o  description - In the "RequestMetadata" element element, specifies if it is
      requested to enable 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 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]).



Niccolini, et al.           Standards Track                    [Page 12]

RFC 5388               Traceroute Storage Format           December 2008


   o  dataType - Boolean boolean

   o  units - N/A

5.2.2.4.  CtlProbeDataSize

   o  name - 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. (i.e., TCP or ICMP) 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 was 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). jumbograms).

   o  dataType - UnsignedShort unsignedShort

   o  units - octets

5.2.2.5.  CtlTimeOut

   o  name - CtlTimeOut

   o  description - Specifies the time-out 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  dataType - UnsignedByte unsignedByte

   o  units - seconds






Niccolini, et al.        Expires April 26, 2009                [Page 11]

Internet-Draft          Traceroute Storage Format           October 2008

5.2.2.6.  CtlProbesPerHop

   o  name - 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).




Niccolini, et al.           Standards Track                    [Page 13]

RFC 5388               Traceroute Storage Format           December 2008


   o  dataType - UnsignedByte unsignedByte

   o  units - probes

5.2.2.7.  CtlPort

   o  name - 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  dataType - UnsignedShort unsignedShort

   o  units - port number

5.2.2.8.  CtlMaxTtl

   o  name - 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  dataType - u8nonzero

   o  units - time-to-live value

5.2.2.9.  CtlDSField

   o  name - 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 field is defined as the Type of Service (TOS) octet in a an IPv4
      header or as the Traffic Class octet in a an IPv6 header (see section
      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' 16 (low
      delay) and '8' 8 (high throughput).  Further references can be found
      in [RFC2474] for the definition of the Differentiated Services
      (DS) field and to in [RFC1812] Section 5.3.2 for Type of Service
      (TOS).



Niccolini, et al.        Expires April 26, 2009           Standards Track                    [Page 12]

Internet-Draft 14]

RFC 5388               Traceroute Storage Format           October           December 2008


   o  dataType - UnsignedByte unsignedByte

   o  units - N/A

5.2.2.10.  CtlSourceAddressType

   o  name - CtlSourceAddressType

   o  description - Specifies the type of address in the corresponding
      CtlSourceAddress
      "CtlSourceAddress" element.  This element is not directly
      reflected in the XML Schema schema of Section 7.  The host address type
      can be determined by examining the inetAddress "inetAddress" type name and the
      corresponding element value.  DNS names are not allowed for the
      CtlSourceAddress.
      "CtlSourceAddress".

   o  dataType - InetAddressType inetAddressType

   o  units - N/A

5.2.2.11.  CtlSourceAddress

   o  name - 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  dataType - InetAddress inetAddress

   o  units - N/A

5.2.2.12.  CtlIfIndex

   o  name - 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 in the "RequestMetadata" indicates that no
      specific interface is requested.  Specifies the
      one interface index
      actually used if (if in the "MeasurementMetadata" element. element).




Niccolini, et al.           Standards Track                    [Page 15]

RFC 5388               Traceroute Storage Format           December 2008


   o  dataType - UnsignedInt unsignedInt

   o  units - N/A

5.2.2.13.  CtlMiscOptions

   o  name - CtlMiscOptions

   o  description - Specifies implementation dependent implementation-dependent options
      (requested if in the "RequestMetadata" element, actually used if
      in the "MeasurementMetadata" element).




Niccolini, et al.        Expires April 26, 2009                [Page 13]

Internet-Draft          Traceroute Storage Format           October 2008

   o  dataType - String255 string255

   o  units - N/A

5.2.2.14.  CtlMaxFailures

   o  name - 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 a 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  dataType - Unsigned8

   o  units - timeouts

5.2.2.15.  CtlDontFragment

   o  name - CtlDontFragment

   o  description - Specifies if the don't fragment flag (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 enable enabled or not.  Setting
      the DF flag can be used for performing a manual PATH MTU test.

   o  dataType - Boolean boolean

   o  units - N/A




Niccolini, et al.           Standards Track                    [Page 16]

RFC 5388               Traceroute Storage Format           December 2008


5.2.2.16.  CtlInitialTtl

   o  name - 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) well-known)
      portion of a path.

   o  dataType - u8nonzero

   o  units - N/A

5.2.2.17.  CtlDescr

   o  name - CtlDescr

   o  description - The purpose of this element is to provide Provides a description of the traceroute
      measurement.

   o  dataType - String255





Niccolini, et al.        Expires April 26, 2009                [Page 14]

Internet-Draft          Traceroute Storage Format           October 2008 string255

   o  units - N/A

5.2.2.18.  CtlType

   o  name - 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 ICMP, or other
      type
      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  dataType - ProbesType probesType

   o  units - N/A

5.2.3.  Results 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


5.2.3.1.  ResultsStartDateAndTime

   o  name - 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  dataType - DateTime

   o  units - N/A

5.2.3.2.  ResultsIpTgtAddrType

   o  name - ResultsIpTgtAddrType

   o  description - Specifies the type of address in the corresponding
      ResultsIpTgtAddr
      "ResultsIpTgtAddr" element.  This element is not directly
      reflected in the XML Schema schema of Section 7.  The host address type
      can be determined by examining the inetAddress "inetAddress" type name and the
      corresponding element value.

   o  dataType - InetAddressType inetAddressType

   o  units - N/A

5.2.3.3.  ResultsIpTgtAddr

   o  name - ResultsIpTgtAddr

   o  description - Specifies the IP address associated with a
      CtlTargetAddress
      "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 when if a specified DNS name fails to
      resolve.



Niccolini, et al.        Expires April 26, 2009                [Page 15]

Internet-Draft          Traceroute Storage Format           October 2008

   o  dataType - InetAddress inetAddress

   o  units - N/A

5.2.3.4.  HopAddrType

   o  name - HopAddrType

   o  description - Specifies the type of address in the corresponding
      HopAddr
      "HopAddr" element.  This element is not directly reflected in the
      XML Schema schema of Section 7.  The host address type can be determined




Niccolini, et al.           Standards Track                    [Page 18]

RFC 5388               Traceroute Storage Format           December 2008


      by examining the inetAddress "inetAddress" type name and the corresponding
      element value.  DNS names are not allowed for HopAddr. "HopAddr".

   o  dataType - InetAddressType inetAddressType

   o  units - N/A

5.2.3.5.  HopAddr

   o  name - 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  dataType - InetAddress inetAddress

   o  units - N/A

5.2.3.6.  HopName

   o  name - HopName

   o  description - Specifies the DNS name of the HopAddr "HopAddr" if it is
      available.  If it is not available available, the element is omitted.

   o  dataType - InetAddress inetAddress

   o  units - N/A

5.2.3.7.  MPLSLabelStackEntry

   o  name - 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 32 bit 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 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  dataType - UnsignedInt unsignedInt

   o  units - N/A




Niccolini, et al.        Expires April 26, 2009           Standards Track                    [Page 16]

Internet-Draft 19]

RFC 5388               Traceroute Storage Format           October           December 2008


5.2.3.8.  ProbeRoundTripTime

   o  name - ProbeRoundTripTime

   o  description - If this element contains the element roundTripTime
      "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 "roundTripTimeNotAvaiable" "roundTripTimeNotAvailable", it
      means either the probe was lost because of a timeout or it was not
      possible to transmit a probe.

   o  dataType - UnsignedShort unsignedShort or String string

   o  units - milliseconds or N/A

5.2.3.9.  ResponseStatus

   o  name - ResponseStatus

   o  description - Specifies the result of a traceroute measurement
      made by the host for a particular probe.

   o  dataType - OperationResponseStatus operationResponseStatus

   o  units - N/A

5.2.3.10.  Time

   o  name - Time

   o  description - Specifies the timestamp for the time the response to
      the probe was received at the interface.

   o  dataType - DateTime

   o  units - N/A

5.2.3.11.  ResultsEndDateAndTime

   o  name - 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




Niccolini, et al.           Standards Track                    [Page 20]

RFC 5388               Traceroute Storage Format           December 2008


      the last probe of the traceroute measurement was sent plus the
      relative timeout (in case of a missing response).

   o  dataType - DateTime

   o  units - N/A

5.2.3.12.  HopRawOutputData

   o  name - 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-dependant implementation-dependent, printable



Niccolini, et al.        Expires April 26, 2009                [Page 17]

Internet-Draft          Traceroute Storage Format           October 2008
      string, expected to be useful for a human interpreting the
      traceroute results.

   o  dataType - String string

   o  units - N/A

5.2.4.  Information Element Correlating Configuration and Results
        Elements

   This section defines an additional element belonging to both the two previous
   groups (configuration elements and result results elements) named
   TestName.
   "TestName".  This element is defined in order to relate configuration
   elements
   and results ones elements by means of a common unique identifier (to be
   chosen in accordance to the specification of [RFC4560]).

5.2.4.1.  TestName

   o  name - TestName

   o  description - Specifies the name of a traceroute measurement.
      This is not necessarily unique, unique within any well-defined scope
      (e.g.
      (e.g., a specific host, initiator of the traceroute measurement).

   o  dataType - String255 string255

   o  units - N/A










Niccolini, et al.           Standards Track                    [Page 21]

RFC 5388               Traceroute Storage Format           December 2008


5.2.5.  Information Elements to compare traceroute measurements results
        one Compare Traceroute Measurement Results
        with each other Each Other

   This section defines additional elements belonging to both the two previous
   groups (configuration elements and result results elements); these elements
   were defined in order to allow traceroute measurements measurement results
   comparison among different traceroute measurements.

5.2.5.1.  OSName

   o  name - 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  dataType - String255 string255

   o  units - N/A

5.2.5.2.  OSVersion

   o  name - OSVersion

   o  description - Specifies the OS version on which the traceroute
      measurement was launched.  This element is ignored if used in the
      "RequestMetadata".





Niccolini, et al.        Expires April 26, 2009                [Page 18]

Internet-Draft          Traceroute Storage Format           October 2008

   o  dataType - String255 string255

   o  units - N/A

5.2.5.3.  ToolVersion

   o  name - 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  dataType - String255 string255

   o  units - N/A








Niccolini, et al.           Standards Track                    [Page 22]

RFC 5388               Traceroute Storage Format           December 2008


5.2.5.4.  ToolName

   o  name - 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  dataType - String255 string255

   o  units - N/A

6.  Data Model for Storing Traceroute Measurements

   For storing and transmitting information according to the information
   model defined in the previous section, a data model is required that
   specifies how to encode the elements of the information model.

   There are several design choices for a data model.  It can use a
   binary or textual representation and it can be defined from scratch
   or use already existing frameworks and data models.  In general, the
   use of already existing frameworks and models should be preferred.

   Binary and textual representation representations both have advantages and
   disadvantages.  Textual representations are (with some limitations)
   human readable
   human-readable, while a binary representation consumes less resources
   for storing, transmitting transmitting, and parsing data.

   An already existing and closely related data model is the DISMAN-
   TRACEROUTE-MIB module [RFC4560], that which specifies a SMIv2 encoding Structure of
   Management Information version 2 (SMIv2) encoding [RFC2578], [RFC2579]
   [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 results, it is
   not easily applicable.

   Another binary representation would be an extension of traffic flow traffic-flow
   information encodings as specified for the IPFIX IP Flow Information Export
   (IPFIX) protocol [RFC5101],



Niccolini, et al.        Expires April 26, 2009                [Page 19]

Internet-Draft          Traceroute Storage Format           October 2008 [RFC5102].  The IPFIX protocol is
   extensible.  However, the architecture behind this protocol [I-D.ietf-ipfix-architecture] [IPFIX]
   is targeted at exporting passively measured flow information.
   Therefore, some obstacles are expected when trying to use it for
   transmitting traceroute measurements measurement information.

   For textual representations, using the eXtensible Markup Language
   (XML) [W3C.REC-xml-20060816] is an obvious choice.  XML supports
   clean structuring of data and syntax checking of records.  With some
   limitations



Niccolini, et al.           Standards Track                    [Page 23]

RFC 5388               Traceroute Storage Format           December 2008


   limitations, it is human readable. human-readable.  It is supported well by a huge
   pool of tools and standards for generating, transmitting, parsing parsing,
   and converting it to other data formats.  Its disadvantages is are the
   resource consumption for processing, storing, and transmitting
   information.  Since the expected data volumes related to traceroute
   measurements
   measurement in network operation and maintenance is 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 measurements measurement information model that is specified in
   this
   section. memo.

   Section 7 contains the XML schema to be used as a template for
   storing and/or exchanging traceroute measurements 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,
   Request, "RequestMetadata", and the actual parameters used, MeasurementMetadata)
   "MeasurementMetadata") are
   meta data metadata to be referenced by results
   information elements (data) by means of the TestName "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 analysis, the XML schema contained in Section 7 is compatible
   with the OGF schema since it was both were designed in a way that both limits the
   unnecessary redundancy and a simple one-to-
   one one-to-one transformation between
   the two exist. exists.

7.  XML Schema for traceroute Traceroute Measurements

   This section presents the XML schema to be used as a template for
   storing and/or exchanging traceroute measurements measurement information.  The
   schema uses UTF-8 encoding as defined in [RFC3629].  In documents
   conforming to the format presented here 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 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



Niccolini, et al.        Expires April 26, 2009                [Page 20]

Internet-Draft          Traceroute Storage Format           October 2008
   according to the XML schema shown in this section.  This includes all
   elements.  Since elements of
   type _CtlType "_CtlType" may contain elements from unknown namespaces namespaces, those
   elements MUST be ignored if their namespace is unknown to the
   processor.  Values for elements using the XML schema type dateTime "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 parts some of the data types and elements defined in this
   version or by establishing a complete new schema.




Niccolini, et al.           Standards Track                    [Page 24]

RFC 5388               Traceroute Storage Format           December 2008


   Due to the limited line length some lines appear wrapped.

 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema elementFormDefault="qualified"
            targetNamespace="urn:ietf:params:xml:ns:traceroute-1.0"
            xmlns:xs="http://www.w3.org/2001/XMLSchema"
            xmlns:tr="urn:ietf:params:xml:ns:traceroute-1.0">
   <xs:simpleType name="string255">
     <xs:annotation>
       <xs:documentation>String restricted to 255
       characters.</xs:documentation>
     </xs:annotation>

     <xs:restriction base="xs:string">
       <xs:maxLength value="255"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="u8nonzero">
     <xs:annotation>
         <xs:documentation>usginedByte
       <xs:documentation>unsignedByte with non zero
       value.</xs:documentation>
     </xs:annotation>

     <xs:restriction base="xs:unsignedByte">
       <xs:minInclusive value="1"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="_roundTripTime">
     <xs:choice>
       <xs:element name="roundTripTime">
         <xs:simpleType>
           <xs:restriction base="xs:unsignedInt"/>
         </xs:simpleType>
       </xs:element>

       <xs:element name="roundTripTimeNotAvailable">



Niccolini, et al.        Expires April 26, 2009                [Page 21]

Internet-Draft          Traceroute Storage Format           October 2008
         <xs:complexType/>
       </xs:element>
     </xs:choice>
   </xs:complexType>

   <xs:complexType name="_inetAddressUnknown"/>

   <xs:simpleType name="_inetAddressIpv4">
     <xs:restriction base="xs:string">
       <xs:pattern value="(([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5



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>

   <xs:simpleType name="_inetAddressIpv6">
     <xs:restriction base="xs:string">
       <xs:pattern value="(([\dA-Fa-f]{1,4}:){7}[\dA-Fa-f]{1,4})(:([\d
 ]{1,3}.){3}[\d]{1,3})?"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:simpleType name="_inetAddressDns">
     <xs:restriction base="xs:string">
       <xs:maxLength value="256"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="_inetAddressASNumber">
     <xs:annotation>
       <xs:documentation>Specifies the AS number of a hop in the
       traceroute path as a 32 bit 32-bit number and the indication indicates how the
       mapping from IP address to AS number was
       performed.</xs:documentation>
     </xs:annotation>

     <xs:sequence>
       <xs:element name="asNumber" type="xs:unsignedInt"/>

       <xs:element name="ipASNumberMappingType">
         <xs:simpleType>
           <xs:restriction base="xs:string">
             <xs:enumeration value="bgptables"/>

             <xs:enumeration value="routingregistries"/>

             <xs:enumeration value="nslookup"/>

             <xs:enumeration value="others"/>



Niccolini, et al.        Expires April 26, 2009                [Page 22]

Internet-Draft          Traceroute Storage Format           October 2008

             <xs:enumeration value="unknown"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="inetAddress">
     <xs:choice>



Niccolini, et al.           Standards Track                    [Page 26]

RFC 5388               Traceroute Storage Format           December 2008


       <xs:element name="inetAddressUnknown"
                   type="tr:_inetAddressUnknown"/>

       <xs:element name="inetAddressIpv4" type="tr:_inetAddressIpv4"/>

       <xs:element name="inetAddressIpv6" type="tr:_inetAddressIpv6"/>

       <xs:element name="inetAddressASNumber"
                   type="tr:_inetAddressASNumber"/>

       <xs:element minOccurs="0" name="inetAddressDns"
                   type="tr:_inetAddressDns"/>
     </xs:choice>
   </xs:complexType>

   <xs:complexType name="inetAddressWithoutDns">
     <xs:sequence>
       <xs:choice>
         <xs:element name="inetAddressUnknown"
                     type="tr:_inetAddressUnknown"/>

         <xs:element name="inetAddressIpv4"
                     type="tr:_inetAddressIpv4"/>

         <xs:element name="inetAddressIpv6"
                     type="tr:_inetAddressIpv6"/>

         <xs:element name="inetAddressASNumber"
                     type="tr:_inetAddressASNumber"/>
       </xs:choice>
     </xs:sequence>
   </xs:complexType>

   <xs:simpleType name="operationResponseStatus">
     <xs:restriction base="xs:string">
       <xs:enumeration value="responseReceived"/>

       <xs:enumeration value="unknown"/>




Niccolini, et al.        Expires April 26, 2009                [Page 23]

Internet-Draft          Traceroute Storage Format           October 2008

       <xs:enumeration value="internalError"/>

       <xs:enumeration value="requestTimedOut"/>

       <xs:enumeration value="unknownDestinationAddress"/>

       <xs:enumeration value="noRouteToTarget"/>

       <xs:enumeration value="interfaceInactiveToTarget"/>



Niccolini, et al.           Standards Track                    [Page 27]

RFC 5388               Traceroute Storage Format           December 2008


       <xs:enumeration value="arpFailure"/>

       <xs:enumeration value="maxConcurrentLimitReached"/>

       <xs:enumeration value="unableToResolveDnsName"/>

       <xs:enumeration value="invalidHostAddress"/>
     </xs:restriction>
   </xs:simpleType>

   <xs:complexType name="_CtlType">
     <xs:choice>
       <xs:element name="TCP">
         <xs:complexType/>
       </xs:element>

       <xs:element name="UDP">
         <xs:complexType/>
       </xs:element>

       <xs:element name="ICMP">
         <xs:complexType/>
       </xs:element>

       <xs:any namespace="##other"/>
     </xs:choice>
   </xs:complexType>

   <xs:complexType name="_ProbeResults">
     <xs:sequence>
       <xs:element maxOccurs="255" name="hop">
         <xs:complexType>
           <xs:sequence>
             <xs:element maxOccurs="10" name="probe">
               <xs:complexType>
                 <xs:sequence>
                   <xs:element name="HopAddr"
                               type="tr:inetAddressWithoutDns">



Niccolini, et al.        Expires April 26, 2009                [Page 24]

Internet-Draft          Traceroute Storage Format           October 2008
                     <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
                       "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


                   <xs:element minOccurs="0" name="HopName"
                               type="tr:_inetAddressDns">
                     <xs:annotation>
                       <xs:documentation>Specifies the DNS name of
                       the HopAddress "HopAddr" if it is available.  If it is
                       not available 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 32 bit 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 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:element name="ProbeRoundTripTime"



Niccolini, et al.        Expires April 26, 2009                [Page 25]

Internet-Draft          Traceroute Storage Format           October 2008
                               type="tr:_roundTripTime">
                     <xs:annotation>
                       <xs:documentation>If this element contains the
                       element roundTripTime "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 "&lt; 1 ms" is therefore encoded as 0 ms).
                       If it contains the element
                         "roundTripTimeNotAvaiable"



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> probe.
                       </xs:documentation>
                     </xs:annotation>
                   </xs:element>

                   <xs:element name="ResponseStatus"
                               type="tr:operationResponseStatus">
                     <xs:annotation>
                       <xs:documentation>Specifies the result of a
                       traceroute measurement made by the host for a
                       particular probe.</xs:documentation>
                     </xs:annotation>
                   </xs:element>

                   <xs:element name="Time" type="xs:dateTime">
                     <xs:annotation>
                       <xs:documentation>Specifies the timestamp for
                       the time the response to the probe was
                       received at the interface.</xs:documentation>
                     </xs:annotation>
                   </xs:element>
                 </xs:sequence>
               </xs:complexType>
             </xs:element>

             <xs:element minOccurs="0" name="HopRawOutputData"
                         type="tr:string255">
               <xs:annotation>
                 <xs:documentation>Specifies the raw output data
                 returned by the traceroute measurement for a
                 certain hop in a traceroute measurement path.  It is
                 an implementation-dependant implementation-dependent, printable string,
                 expected to be useful for a human interpreting the
                 traceroute results.</xs:documentation>
               </xs:annotation>



Niccolini, et al.        Expires April 26, 2009                [Page 26]

Internet-Draft          Traceroute Storage Format           October 2008
             </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
       operation -- the parameters requested if used in



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>

     <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, unique within any
           well-defined scope (e.g. (e.g., a specific host, initiator of
           the traceroute measurement).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="OSName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of the operating
           system on which the traceroute measurement was launched.
           This element is ignored if used in the
           "RequestMetadata".</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="OSVersion" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the OS version on which the
           traceroute measurement was launched.  This element is
           ignored if used in the
           "RequestMetadata".</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="" name="ToolVersion" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the version of the traceroute
           tool (requested to be used if in the "RequestMetadata"
           element, actually used if in the "MeasurementMetadata"



Niccolini, et al.        Expires April 26, 2009                [Page 27]

Internet-Draft          Traceroute Storage Format           October 2008
           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>



Niccolini, et al.           Standards Track                    [Page 31]

RFC 5388               Traceroute Storage Format           December 2008


       </xs:element>

       <xs:element name="CtlTargetAddress" type="tr:inetAddress">
         <xs:annotation>
           <xs:documentation>In the "RequestMetadata" element element, it
           specifies the host address requested to be used in the
           traceroute measurement.  In the "MeasurementMetadata"
             element
           element, it specifies the host address used in the
           traceroute measurement.  The host address type can be
           determined by the examining the inetAddress "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 it is requested to enable 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 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 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> 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



Niccolini, et al.        Expires April 26, 2009                [Page 28]

Internet-Draft          Traceroute Storage Format           October 2008
           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.
           (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 was 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


           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> jumbograms).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedShort">
             <xs:maxInclusive value="65507"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="3" name="CtlTimeOut">
         <xs:annotation>
           <xs:documentation>Specifies the time-out timeout value, in
           seconds, for each probe of a traceroute measurement
           (requested if in the "RequestMetadata" element, actually
           used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedByte">
             <xs:minInclusive value="1"/>

             <xs:maxInclusive value="60"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="3" name="CtlProbesPerHop">
         <xs:annotation>
           <xs:documentation>Specifies the number of probes with the
           same time-to-live (TTL) value that are sent for each host
           (requested if in the "RequestMetadata" element, actually
           used if in the "MeasurementMetadata"
           element).</xs:documentation>



Niccolini, et al.        Expires April 26, 2009                [Page 29]

Internet-Draft          Traceroute Storage Format           October 2008
         </xs:annotation>

         <xs:simpleType>
           <xs:restriction base="xs:unsignedByte">
             <xs:minInclusive value="1"/>

             <xs:maxInclusive value="10"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>




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:simpleType>
           <xs:restriction base="xs:unsignedShort">
             <xs:minInclusive value="1"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:element>

       <xs:element default="30" name="CtlMaxTtl" type="tr:u8nonzero">
         <xs:annotation>
           <xs:documentation>Specifies the maximum TTL value for the
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="0" name="CtlDSField"
                   type="xs:unsignedByte">
         <xs:annotation>
           <xs:documentation>Specifies the value that was requested
           to be stored in the Differentiated Services (DS) field in
           the traceroute probe (if in the "RequestMetadata"
           element).  Specifies the value that was stored in the
           Differentiated Services (DS) field in the traceroute
           probe (if in the "MeasurementMetadata" element).  The DS
             Field
           field is defined as the Type of Service (TOS) octet in a an
           IPv4 header or as the Traffic Class octet in a an IPv6
           header (see section Section 7 of [RFC2460]).  The value of this
           object must be a decimal integer in the range from 0 to



Niccolini, et al.        Expires April 26, 2009                [Page 30]

Internet-Draft          Traceroute Storage Format           October 2008
           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' 16 (low delay) and
             '8'
           8 (high throughput).  Further references can be found in
           [RFC2474] for the definition of the Differentiated
           Services (DS) field and to 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


       <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 "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 in
             the "RequestMetadata"
           indicates that no specific interface is requested.
           Specifies the one interface index actually used
             if (if in the
           "MeasurementMetadata"
             element.</xs:documentation> element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element minOccurs="0" name="CtlMiscOptions"
                   type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies implementation dependent implementation-dependent
           options (requested if in the "RequestMetadata" element,



Niccolini, et al.        Expires April 26, 2009                [Page 31]

Internet-Draft          Traceroute Storage Format           October 2008
           actually used if in the "MeasurementMetadata"
           element).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="5" name="CtlMaxFailures"
                   type="xs:unsignedByte">
         <xs:annotation>
           <xs:documentation>Specifies the maximum number of
           consecutive timeouts allowed before terminating a
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the



Niccolini, et al.           Standards Track                    [Page 35]

RFC 5388               Traceroute Storage Format           December 2008


           "MeasurementMetadata" element).  A value of either 255
           (maximum hop count/possible TTL value) or a 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>

       <xs:element default="false" name="CtlDontFragment"
                   type="xs:boolean">
         <xs:annotation>
           <xs:documentation>Specifies if the don't fragment flag (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 enable enabled or not.  Setting the DF flag can be used for
           performing a manual PATH MTU test.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element default="1" name="CtlInitialTtl"
                   type="tr:u8nonzero">
         <xs:annotation>
           <xs:documentation>Specifies the initial TTL value for a
           traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the
           "MeasurementMetadata" element).  Such TTL setting is
           intended to bypass the initial (often well known) well-known) portion
           of a path.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element maxOccurs="1" minOccurs="0" name="CtlDescr"



Niccolini, et al.        Expires April 26, 2009                [Page 32]

Internet-Draft          Traceroute Storage Format           October 2008
                   type="tr:string255">
         <xs:annotation>
             <xs:documentation>The purpose of this element is to
             provide
           <xs:documentation>Provides a description of the traceroute
           measurement.</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="CtlType" type="tr:_CtlType">
         <xs:annotation>
           <xs:documentation>Specifies the implementation method
           used for the traceroute measurement (requested if in the
           "RequestMetadata" element, actually used if in the



Niccolini, et al.           Standards Track                    [Page 36]

RFC 5388               Traceroute Storage Format           December 2008


           "MeasurementMetadata" element).  It specifies if the
           traceroute is using TCP, UDP, ICMP ICMP, or other type types of
           probes.  It is possible to specify other types of probes
           by using an element specified in another schema with a
           different namespace.</xs:documentation>
         </xs:annotation>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:complexType name="_Measurement">
     <xs:annotation>
       <xs:documentation>Contains the actual traceroute measurement
       results.</xs:documentation>
     </xs:annotation>

     <xs:sequence>
       <xs:element name="TestName" type="tr:string255">
         <xs:annotation>
           <xs:documentation>Specifies the name of a traceroute
           measurement.  This is not necessarily unique, unique within any
           well-defined scope (e.g. (e.g., a specific host, initiator of
           the traceroute measurement).</xs:documentation>
         </xs:annotation>
       </xs:element>

       <xs:element name="ResultsStartDateAndTime" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>Specifies the date and start time of
           the traceroute measurement.  This is the time when the
           first probe was seen at the sending
           interface.</xs:documentation>
         </xs:annotation>
       </xs:element>




Niccolini, et al.        Expires April 26, 2009                [Page 33]

Internet-Draft          Traceroute Storage Format           October 2008

       <xs:element name="ResultsIpTgtAddr"
                   type="tr:inetAddressWithoutDns">
         <xs:annotation>
           <xs:documentation>Specifies the IP address associated
           with a CtlTargetAddress "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 when if a specified DNS name fails to resolve.  The
           address type can be determined by examining the inetAddress "inetAddress"
           type name and the corresponding element
           value.</xs:documentation>
         </xs:annotation>
       </xs:element>



Niccolini, et al.           Standards Track                    [Page 37]

RFC 5388               Traceroute Storage Format           December 2008


       <xs:element name="ProbeResults" type="tr:_ProbeResults"/>

       <xs:element name="ResultsEndDateAndTime" type="xs:dateTime">
         <xs:annotation>
           <xs:documentation>Specifies the date and end time of the
           traceroute measurement.  It is either the time when the
           response to the last probe of the traceroute measurement
           was received or the time when the last probe of the
           traceroute measurement was sent plus the relative timeout
           (in case of a missing response).</xs:documentation>
         </xs:annotation>
       </xs:element>
     </xs:sequence>
   </xs:complexType>

   <xs:element name="traceRoute">
     <xs:complexType>
       <xs:sequence>
         <xs:element minOccurs="0" name="RequestMetadata"
                     type="tr:_Metadata"/>

         <xs:element maxOccurs="4294967295" maxOccurs="2147483647" minOccurs="0"
                     name="Measurement">
           <xs:complexType>
             <xs:sequence>
               <xs:element minOccurs="0" name="MeasurementMetadata"
                           type="tr:_Metadata"/>

               <xs:element maxOccurs="4294967295" maxOccurs="2147483647" minOccurs="0"
                           name="MeasurementResult"
                           type="tr:_Measurement"/>
             </xs:sequence>
           </xs:complexType>
         </xs:element>



Niccolini, et al.        Expires April 26, 2009                [Page 34]

Internet-Draft          Traceroute Storage Format           October 2008
       </xs:sequence>
     </xs:complexType>
   </xs:element>
 </xs:schema>

8.  Security Considerations

   Security considerations discussed in this section are grouped into
   considerations related to conducting traceroute measurements and
   considerations related to storing and transmitting traceroute
   measurements
   measurement information.






Niccolini, et al.           Standards Track                    [Page 38]

RFC 5388               Traceroute Storage Format           December 2008


   This memo does not specify an implementation of a traceroute tool.
   Neither does it specify a certain procedure for storing traceroute
   measurements
   measurement information.  Still  Still, it is considered desirable to
   discuss related security issues below.

8.1.  Conducting Traceroute Measurements

   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.

   Authentication techniques, such as digital signatures, may be used
   where appropriate to guard against injected traffic attacks.







Niccolini, et al.        Expires April 26, 2009                [Page 35]

Internet-Draft          Traceroute Storage Format           October 2008

8.2.  Securing Traceroute Measurements Measurement Information

   Traceroute measurement information are is not considered highly
   sensitive.  Still, they it may contain sensitive information on network
   paths, routing states, used IP addresses, and roundtrip times, times that
   operators of networks may want to protect for business or security
   reasons.

   It is thus important to control access to Information 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
   integrity, and authenticity.  It is further RECOMMENDED that secure
   authentication and authorization are used for protecting stored
   traceroute measurement information.



Niccolini, et al.           Standards Track                    [Page 39]

RFC 5388               Traceroute Storage Format           December 2008


9.  IANA Considerations

   This document uses URNs to describe an XML namespace and an XML
   schema for traceroute measurements measurement information storing and
   transmission
   transmission, conforming to a registry mechanism described in
   [RFC3688].  Two URI assignments are requested. have been made.

   1.  Registration request for the IPPM traceroute measurements namespace

       *  URI: urn:ietf:params:xml:ns:traceroute-1.0

       *  Registrant Contact: IESG

       *  XML: None.  Namespace URIs do not represent an XML XML.

   2.  Registration request for the IPPM traceroute measurements schema

       *  URI: urn:ietf:params:xml:schema:traceroute-1.0

       *  Registrant Contact: IESG

       *  XML: See the section Section 7 of this document.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.




Niccolini, et al.        Expires April 26, 2009                [Page 36]

Internet-Draft          Traceroute Storage Format           October 2008

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC3339]  Klyne, G., Ed. and C. Newman, "Date and Time on the
              Internet: Timestamps", RFC 3339, July 2002.

   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, November 2003.

   [RFC4001]  Daniele, M., Haberman, B.,






Niccolini, et al.           Standards Track                    [Page 40]

RFC 5388               Traceroute Storage Format           December 2008


   [RFC4001]  Daniele, M., Haberman, B., Routhier, S., and J.
              Schoenwaelder, "Textual Conventions for Internet Network
              Addresses", RFC 4001, February 2005.

   [RFC4560]  Quittek, J. and K. White, "Definitions of Managed Objects
              for Remote Ping, Traceroute, and Lookup Operations",
              RFC 4560, June 2006.

   [RFC5198]  Klensin, J. and M. Padlipsky, "Unicode Format for Network
              Interchange", RFC 5198, March 2008.

10.2.  Informative References

   [I-D.ietf-ipfix-architecture]
              Sadasivan, G., "Architecture for IP Flow Information
              Export", draft-ietf-ipfix-architecture-12 (work in
              progress), September 2006.

   [IEEE.1003-1G.1997]
              Institute of Electrical and Electronics Engineers,
              "Protocol Independent Interfaces", IEEE Standard 1003.1G,
              March 1997.

   [IPFIX]    Sadasivan, G., "Architecture for IP Flow Information
              Export", Work in Progress, September 2006.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [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.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.



Niccolini, et al.        Expires April 26, 2009                [Page 37]

Internet-Draft          Traceroute Storage Format           October 2008

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
              January 2004.

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.




Niccolini, et al.           Standards Track                    [Page 41]

RFC 5388               Traceroute Storage Format           December 2008


   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

   [W3C.REC-xml-20060816]
              Bray, T., Paoli, J., Yergeau, F., Maler, E., Sperberg-McQueen, C., Bray, T., and E. Maler,
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
              Edition)", World Wide Web Consortium
              Recommendation REC-xml-20060816, FirstEdition REC-xml-
              20060816, August 2006,
              <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>.



































Niccolini, et al.           Standards Track                    [Page 42]

RFC 5388               Traceroute Storage Format           December 2008


Appendix A.  Traceroute Default Configuration Parameters

   This section lists traceroute measurement configuration parameters as
   well as their defaults on various platforms and illustrates how
   widely they may vary.  This document considered considers four major traceroute
   tool implementations and compared compares them based on configurable
   parameters and default values.  The LINUX (SUSE 9.1), BSD (FreeBSD
   7.0)
   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, 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,
   already 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 which that are available in at least two of the
   considered implementations are reported.




Niccolini, et al.        Expires April 26, 2009                [Page 38]

Internet-Draft          Traceroute Storage Format           October 2008

             +---------------------------------------------------------+
             |  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  |






Niccolini, et al.           Standards Track                    [Page 43]

RFC 5388               Traceroute Storage Format           December 2008


             +--------+------+-------------------------------+---------+
             | 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    |



Niccolini, et al.        Expires April 26, 2009                [Page 39]

Internet-Draft          Traceroute Storage Format           October 2008
             |--------+------|                               |---------|
             | 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 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  |                               |    -    |



Niccolini, et al.           Standards Track                    [Page 44]

RFC 5388               Traceroute Storage Format           December 2008


             +--------+------+-------------------------------+---------+
             | 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    |



Niccolini, et al.        Expires April 26, 2009                [Page 40]

Internet-Draft          Traceroute Storage Format           October 2008
             |--------+------|                               |---------|
             | WINDOWS| N/A  |                               |    1    |
             +--------+------+-------------------------------+---------+
             | LINUX  | -F   |Set the "don't fragment" bit.  |    -    |
             |--------+------|                               |---------|
             | FreeBSD| -F   |                               |    -    |
             |--------+------|                               |---------|
             | UNIX   | -F   |                               |    -    |
             |--------+------|                               |---------|
             | WINDOWS| N/A  |                               |    -    |
             +--------+------+-------------------------------+---------+
             | LINUX  | N/A  |Enables  |Enable socket level debugging.| debugging. |    -    |
             |--------+------|                               |---------|
             | FreeBSD| -d   |                               |    -    |
             |--------+------|                               |---------|
             | UNIX   | -d   |                               |    -    |
             |--------+------|                               |---------|
             | WINDOWS| N/A  |                               |    -    |
             +--------+------+-------------------------------+---------+
             | LINUX  | N/A  |Use ICMP ECHO Echoes instead of UDP |    -    |
             |--------+------|datagrams.                     |---------|
             | FreeBSD| -I   |                               |    -    |
             |--------+------|                               |---------|
             | UNIX   | -I   |                               |    -    |
             |--------+------|                               |---------|
             | WINDOWS| N/A  |                               |    -    |



Niccolini, et al.           Standards Track                    [Page 45]

RFC 5388               Traceroute Storage Format           December 2008


             +--------+------+-------------------------------+---------+
             | 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 FreeBSD, and UNIX       |on       |
             | FreeBSD|  -   |implementations allow          |implement|
             |--------+------|specifying the probe datagram  |ation.   |
             | UNIX   |  -   |length for outgoing probes.    |         |



Niccolini, et al.        Expires April 26, 2009                [Page 41]

Internet-Draft          Traceroute Storage Format           October 2008
             |--------+------|                               |         |
             | WINDOWS| N/A  |                               |         |
             +--------+------+-------------------------------+---------+

A.1.  Alternative Traceroute Implementations

   As stated above, the widespread use of firewalls might prevent UDP UDP-
   or
   ICMP based ICMP-based traceroutes to completely trace the path to a destination,
   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  TCP-based implementations use TCP SYN TCP,
   SYN, or FIN probes and listen for TIME_EXCEEDED messages, TCP RESET 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
   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 was is outside the scope
   of this
   document, anyway document; regardless, for completeness reasons reasons, the
   information model also supports the storing of TCP-based traceroute measurements, too.
   measurements.







Niccolini, et al.           Standards Track                    [Page 46]

RFC 5388               Traceroute Storage Format           December 2008


Appendix B.  Known Problems with Traceroute

B.1.  Compatibility between traceroute measurements results Traceroute Measurement Results and IPPM
      metrics
      Metrics

   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 one 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 measurements 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 time-outs timeouts and can
   experience problems related to the crossing of firewalls; therefore therefore,
   some of the packets that traceroute sends out end up being time-out 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.





Niccolini, et al.        Expires April 26, 2009                [Page 42]

Internet-Draft          Traceroute Storage Format           October 2008

Appendix C.  Differences to DISMAN-TRACEROUTE-MIB

   For performing remote traceroute operations at managed node, the IETF
   has standardized the DISMAN-TRACEROUTE-MIB module in [RFC4560].  This
   module allows:

   o  retrieving capability information of the traceroute tool
      implementation at the managed node, node;

   o  configuring traceroute measurements to be performed, performed;

   o  retrieving information about ongoing and completed traceroute
      measurements,
      measurements;

   o  retrieving traceroute measurement statistics.

   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 result results from
   completed measurements are almost identical.  But for other pats parts of
   the DISMAN-TRACEROUTE MIB module there is no need to model them in a
   traceroute measurements measurement storage format.  Particularly, the capability
   information, information about ongoing measurements measurements, and measurement
   statistics are not covered by the DISMAN traceroute storage model.

   Concerning traceroute measurements and their results, there



Niccolini, et al.           Standards Track                    [Page 47]

RFC 5388               Traceroute Storage Format           December 2008


   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
   measurements
   measurement data model is encoded using XML.

   This difference in structure implies that the DISMAN-TRACEROUTE-MIB
   module contains SMI-specific information element 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 measurements measurement data model.

   But for most of the remaining information elements that concern
   configuration of traceroute measurements and results of completed
   measurements, the semantics is are identical between the DISMAN-
   TRACEROUTE-MIB module and the traceroute measurements measurement data model.
   There are very few exceptions to this which this; these are listed below.  Also  Also,
   naming of information elements is identical between both models with
   a few exceptions.  For the traceroute measurements 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.






Niccolini, et al.        Expires April 26, 2009                [Page 43]

Internet-Draft          Traceroute Storage Format           October 2008

C.1.  Scope

   There are some basic differences in nature and application between
   MIB modules and XML documents.  This results in two major differences
   of Scope scope between the DISMAN-TRACEROUTE-MIB module and the traceroute
   measurements
   measurement data model.

   The first difference is the traceRouteResultsTable "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
   measurements
   measurement data model, model because it has not been envisioned to use the
   model for dynamically reporting progress of individual traceroute
   measurements.  The traceroute measurements measurement data model is rather
   intended to be used for reporting completed traceroute measurements.

   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 measurements 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.





Niccolini, et al.           Standards Track                    [Page 48]

RFC 5388               Traceroute Storage Format           December 2008


   For the remaining elements in the DISMAN-TRACEROUTE-MIB module and in
   the traceroute measurements measurement data model model, there is a very good match
   between the two worlds.  The traceRouteCtlTable "traceRouteCtlTable" corresponds to the
   "MeasurementMetadata" element element, and the combination of the
   traceRouteProbeHistoryTable
   "traceRouteProbeHistoryTable" and the traceRouteHopsTable "traceRouteHopsTable"
   corresponds to a collection of "MeasurementResult" elements.

C.2.  Naming

   Basically, names in both models are chosen using the same naming
   conventions.

   For the traceroute measurement configuration information information, all names,
   such as CtlProbesPerHop, "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 "CtlDataSize", which was renamed
   to
   CtlProbeDataSize "CtlProbeDataSize" for clarification in the traceroute measurements measurement
   data model.

   Results of measurements in the DISMAN-TRACEROUTE-MIB modules are
   distributed over two tables, the traceRouteResultsTable containing "traceRouteResultsTable" contains
   mainly information about ongoing measurements and the
   traceRouteProbeHistoryTable containing
   "traceRouteProbeHistoryTable" contains only information about
   completed measurements.  According to the SMIv2 naming conventions conventions,
   names of information elements in these tables have different prefixes



Niccolini, et al.        Expires April 26, 2009                [Page 44]

Internet-Draft          Traceroute Storage Format           October 2008


   (traceRouteResults
   ("traceRouteResults" and traceRouteProbeHistory). "traceRouteProbeHistory").  Since the
   traceroute
   measurements 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.

   Beyond that, there are only a few changes in element names.  The
   renaming actions include:

   o  traceRouteProbeHistoryResponse  "traceRouteProbeHistoryResponse" to ProbeRoundTripTime, "ProbeRoundTripTime";

   o  traceRouteProbeHistoryHAddr  "traceRouteProbeHistoryHAddr" to HopAddr, "HopAddr";

   o  traceRouteProbeHistoryTime  "traceRouteProbeHistoryTime" to ResultsEndDateAndTime, "ResultsEndDateAndTime";

   o  traceRouteProbeHistoryLastRC  "traceRouteProbeHistoryLastRC" to ResultsHopRawOutputData. "ResultsHopRawOutputData".

C.3.  Semantics

   The semantics was were changed for two information elements only.

   For traceRouteProbeHistoryResponse "traceRouteProbeHistoryResponse" in the DISMAN-TRACEROUTE-MIB, a
   value of 0 indicated, indicates that it was is not possible to transmit a probe.
   For the traceroute measurements measurement data model, a value of 0 for element
   RoundTripTime



Niccolini, et al.           Standards Track                    [Page 49]

RFC 5388               Traceroute Storage Format           December 2008


   "RoundTripTime" indicates that the measured time was less than one
   millisecond, while for
   millisecond.  For the case that it was not possible to transmit a probe
   probe, a string is used that indicates the problem.

   For traceRouteCtlIfIndex "traceRouteCtlIfIndex" in the DISMAN-TRACEROUTE-MIB, a value of 0
   indicated,
   indicates that it the option to set the index is not available.  This
   was translated to the traceroute measurements measurement data model, such that a
   value of 0 for this element indicates that the used interface is
   unknown.

   The element traceRouteProbeHistoryLastRC "traceRouteProbeHistoryLastRC" in the DISMAN-TRACEROUTE-MIB DISMAN-TRACEROUTE-
   MIB was replaced by element ResultsHopRawOutputData. "ResultsHopRawOutputData".  While
   traceRouteProbeHistoryLastRC
   "traceRouteProbeHistoryLastRC" just reports a reply code,
   ResultsHopRawOutputData
   "ResultsHopRawOutputData" reports the full raw output data (per hop)
   produced by the traceroute measurements measurement that was used.

C.4.  Additional Information Elements

   Only a few information elements have been added to the model of the
   DISMAN-TRACEROUTE-MIB module.

   o  For providing information on the MPLS label stack entries of a
      probe in the traceroute measurement path MPLSLabelStackEntry path, "MPLSLabelStackEntry"
      was added.

   o  For providing additional timestamp beyond ResultsEndDateAndTime,
      ResultsStartDateAndTime "ResultsEndDateAndTime",
      "ResultsStartDateAndTime" and Time "Time" were added.





Niccolini, et al.        Expires April 26, 2009                [Page 45]

Internet-Draft          Traceroute Storage Format           October 2008

   o  For providing DNS names at the time of the execution of the
      traceroute for each HopAddr "HopAddr" (which may change over time) HopName time),
      "HopName" was added.

Appendix D.  Traceroute Examples with XML representation Representation

   This Section section shows some examples of traceroute applications.  In
   addition
   addition, the encoding of requests and results is shown for some of
   those examples.  Note  Also, note that also in these XML examples some lines
   appear wrapped due to the limited length of line.

   A typical traceroute on a linux 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 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 * *



Niccolini, et al.           Standards Track                    [Page 50]

RFC 5388               Traceroute Storage Format           December 2008


   This traceroute ignores the first 4 hops and uses 1500 byte packets. 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>1500</CtlProbeDataSize>
       <CtlProbeDataSize>1472</CtlProbeDataSize>
       <CtlTimeOut/>
       <CtlProbesPerHop/>
       <CtlPort/>
       <CtlMaxTtl/>
       <CtlDSField/>
       <CtlSourceAddress>
         <inetAddressUnknown/>
       </CtlSourceAddress>
       <CtlIfIndex/>



Niccolini, et al.        Expires April 26, 2009                [Page 46]

Internet-Draft          Traceroute Storage Format           October 2008
       <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>1500</CtlProbeDataSize>
         <CtlProbeDataSize>1472</CtlProbeDataSize>
         <CtlTimeOut/>
         <CtlProbesPerHop/>
         <CtlPort/>



Niccolini, et al.           Standards Track                    [Page 51]

RFC 5388               Traceroute Storage Format           December 2008


         <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>



Niccolini, et al.        Expires April 26, 2009                [Page 47]

Internet-Draft          Traceroute Storage Format           October 2008
               <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>



Niccolini, et al.           Standards Track                    [Page 52]

RFC 5388               Traceroute Storage Format           December 2008


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 48]

Internet-Draft          Traceroute Storage Format           October 2008
               <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>



Niccolini, et al.           Standards Track                    [Page 53]

RFC 5388               Traceroute Storage Format           December 2008


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 49]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


                 <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>



Niccolini, et al.        Expires April 26, 2009                [Page 50]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 51]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


         <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
   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 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 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"?>



Niccolini, et al.        Expires April 26, 2009                [Page 52]

Internet-Draft          Traceroute Storage Format           October 2008
   <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


       <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>



Niccolini, et al.        Expires April 26, 2009                [Page 53]

Internet-Draft          Traceroute Storage Format           October 2008
         <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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 54]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


               </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>



Niccolini, et al.        Expires April 26, 2009                [Page 55]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 56]

Internet-Draft          Traceroute Storage Format           October 2008
             <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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 57]

Internet-Draft          Traceroute Storage Format           October 2008
             <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


             <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>



Niccolini, et al.        Expires April 26, 2009                [Page 58]

Internet-Draft          Traceroute Storage Format           October 2008
                 <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


             <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>



Niccolini, et al.        Expires April 26, 2009                [Page 59]

Internet-Draft          Traceroute Storage Format           October 2008
               <HopName>routerin.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>19</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>responseReceived</ResponseStatus>
               <Time>2008-05-14T09:57:25+02:00</Time>
             </probe>
           </hop>
           <hop>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.249</inetAddressIpv4>
               </HopAddr>
               <HopName>routerdmz.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTime>20</roundTripTime>
               </ProbeRoundTripTime>
               <ResponseStatus>unknown</ResponseStatus>
               <Time>2008-05-14T09:57:26+02:00</Time>
             </probe>
             <probe>
               <HopAddr>
                 <inetAddressIpv4>192.0.2.249</inetAddressIpv4>
               </HopAddr>
               <HopName>routerdmz.example</HopName>
               <ProbeRoundTripTime>
                 <roundTripTimeNotAvailable/>
               </ProbeRoundTripTime>
               <ResponseStatus>requestTimedOut</ResponseStatus>
               <Time>2008-05-14T09:57:26+02:00</Time>



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>



Niccolini, et al.        Expires April 26, 2009                [Page 60]

Internet-Draft          Traceroute Storage Format           October 2008
   </traceRoute>

   The third and last example is based on the Microsoft Windows pendant
   of traceroute.  On a an MS Windows system system, the command is called
   "tracert" and typically looks as follows:

   # tracert -h 10 www.example.org

   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




Niccolini, et al.           Standards Track                    [Page 65]

RFC 5388               Traceroute Storage Format           December 2008


   Trace complete.

   In this example example, the trace was limited to 10 hops.  So, hops, so the tenth and
   last hop of this example was not the final destination.  Applying the
   XML schema defined in this document 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/>



Niccolini, et al.        Expires April 26, 2009                [Page 61]

Internet-Draft          Traceroute Storage Format           October 2008
       <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


         <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>



Niccolini, et al.        Expires April 26, 2009                [Page 62]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


                 <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>



Niccolini, et al.        Expires April 26, 2009                [Page 63]

Internet-Draft          Traceroute Storage Format           October 2008
               <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


                 <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>



Niccolini, et al.        Expires April 26, 2009                [Page 64]

Internet-Draft          Traceroute Storage Format           October 2008
           </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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 65]

Internet-Draft          Traceroute Storage Format           October 2008
             <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


             </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>



Niccolini, et al.        Expires April 26, 2009                [Page 66]

Internet-Draft          Traceroute Storage Format           October 2008
                 <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


             <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>



Niccolini, et al.        Expires April 26, 2009                [Page 67]

Internet-Draft          Traceroute Storage Format           October 2008
                 <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


               </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>



Niccolini, et al.        Expires April 26, 2009                [Page 68]

Internet-Draft          Traceroute Storage Format           October 2008
             </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


               <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>



Niccolini, et al.        Expires April 26, 2009                [Page 69]

Internet-Draft          Traceroute Storage Format           October 2008
       </MeasurementResult>
     </Measurement>
   </traceRoute>

   The three examples given in this section are intended to give an
   impression on of how a trace could be represented in XML.  The
   representation generated by an implementation may differ from the
   examples here dependent depending on the system and the capabilities of the
   traceroute implementation.















Niccolini, et al.           Standards Track                    [Page 74]

RFC 5388               Traceroute Storage Format           December 2008


Authors' Addresses

   Saverio Niccolini
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany
   Phone: +49 (0) 6221 4342 118
   Email:
   EMail: saverio.niccolini@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   Sandra Tartarelli
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany
   Phone: +49 (0) 6221 4342 132
   Email:
   EMail: sandra.tartarelli@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   Juergen Quittek
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany
   Phone: +49 (0) 6221 4342 115
   Email:
   EMail: quittek@nw.neclab.eu
   URI:   http://www.nw.neclab.eu







Niccolini, et al.        Expires April 26, 2009                [Page 70]

Internet-Draft          Traceroute Storage Format           October 2008


   Thomas Dietz
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany
   Phone: +49 (0) 6221 4342 128
   Email:
   EMail: thomas.dietz@nw.neclab.eu
   URI:   http://www.nw.neclab.eu


   Martin Swany
   Dept. of Computer and Information Sciences, Sciences
   University of Delaware
   Newark  DE 19716
   U.S.A.

   Email:
   EMail: swany@UDel.Edu



Niccolini, et al.        Expires April 26, 2009                [Page 71]

Internet-Draft          Traceroute Storage Format           October 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.











Niccolini, et al.        Expires April 26, 2009           Standards Track                    [Page 72] 75]

----