IPPM Working Group S. Niccolini
Internet-Draft S. Tartarelli
Expires: January 21, 2006 J. Quittek
NEC
July 20, 2005
How to store traceroute measurements and related metrics
draft-niccolini-ippm-storetraceroutes-01
Status of 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 the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo describes a standard way to store traceroute measurements
and possibly their related metrics. To better address the traceroute
measurements storing issue, the authors first of all give a
definition of the traceroute tool, describe the tool itself as well
as its parameters and the default values on the most common operating
systems and the output results that can be stored. Afterwards, the
common information model with the base elements of the traceroute
Niccolini, et al. Expires January 21, 2006 [Page 1]
Internet-Draft IPPM Way to store traceroutes July 2005
measurement storing is defined dividing the information elements in
two semantically separated groups (configuration elements and results
ones). On the basis of the information model a data model is then
proposed in order to actually store the traceroute measurements.
Finally the relevant metrics related to traceroute measurements are
defined using the metrics already standardized in the IPPM working
group, where they are found to be applicables.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of traceroute . . . . . . . . . . . . . . . . . . . 4
2.1 Traceroute configuration parameters . . . . . . . . . . . 4
3. Known problems with traceroute . . . . . . . . . . . . . . . . 8
4. Reports/results . . . . . . . . . . . . . . . . . . . . . . . 9
5. Information model for storing traceroutes measurements . . . . 10
5.1 Data types . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2 Information Elements . . . . . . . . . . . . . . . . . . . 11
5.2.1 Configuration Information Elements . . . . . . . . . . 11
5.2.2 Results Information Elements . . . . . . . . . . . . . 18
6. Data model for storing traceroutes measurements . . . . . . . 24
6.1 XML schema for traceroute measurements . . . . . . . . . . 25
7. Relevant metrics for traceroute measurements . . . . . . . . . 40
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Security considerations . . . . . . . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 44
12. Normative References . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 46
Niccolini, et al. Expires January 21, 2006 [Page 2]
Internet-Draft IPPM Way to store traceroutes July 2005
1. Introduction
Traceroutes are being used by lots of measurement efforts, either as
an independent measurement or to get path information to support
other measurement efforts. That is why there is the need to
standardize the way traceroute measurements are stored and the
related metrics associated with such measurements. Since traceroute
is a tool that has built-in configurable mechanisms like time-outs
and can experience problems related to the crossing of firewalls thus
experiencing fake losses or incomplete delay information, the
standard metrics defined by IPPM working group in matter of delay,
connectivity and losses may not be complete enough to define
univocally the metrics retrieved by the traceroute tool. In such a
context, already standardized metrics have to be closely examined in
order to check for their applicability. Moreover there is a need to
better define the traceroute tool as well as its parameters and the
results it outputs since, to the authors' knowledge, there is so far
no standard describing these. These are the motivations that moved
the authors to write this draft in the context of the IPPM working
group even if other working groups (like DISMAN) have already
addressed similar issues related to the definition of the MIB for
configuring and retrieving traceroute measurements results. The rest
of the draft is organised as follows: Section 2 gives the definition
of traceroute used as reference in the rest of the draft as well as
the traceroute configurable parameters and their default values for
the most common operating systems. Section 3 reports on both known
problems of traceroute and existing alternatives. Section 4
describes the results available from the traceroute output screen.
Section 5 and Section 6 respectively describe our proposed
Information model and Data model for storing traceroute measurements.
Section 7 reports on the proposed relevant metrics while Section 8
gives our conclusions. The draft ends with security considerations,
IANA considerations and open issues in Section 9, Section 10 and
Section 11 respectively.
Niccolini, et al. Expires January 21, 2006 [Page 3]
Internet-Draft IPPM Way to store traceroutes July 2005
2. Definition of traceroute
Traceroute is a network diagnostic tool used to determine the hop by
hop path from a source to a destination and the Round Trip Time (RTT)
from the source to each hop. Traceroute can therefore be used to
discover where and how a host is connected to the Internet and can be
usefully employed to troubleshoot network connections.
Typically, traceroute attemps 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 detail, the host running the traceroute sends the first set
of probes with TTL equal to one (some implementations allow setting
the initial TTL to a value equal to "n" different from one, 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. By observing a TTL value
equal to zero, the host rejects the probe and typically returns an
ICMP message with a TIME_EXCEEDED value. Traceroute can therefore
derive the IP address of the first hop from the header of the ICMP
message and evaluate the RTT between the source and the first hop.
The next hops are discovered following the same procedure, taking
care of increasing at each step the TTL value of the outgoing probes
by one. The TTL value is increased until either an ICMP
PORT_UNREACHABLE message is received, meaning that the destination
has been reached, or the maximum configured number of hops has been
hit.
Some implementations, use ICMP Echos, instead of UDP datagrams.
However, many routers do not return ICMP messages about ICMP
messages, i.e. no ICMP TIME_EXCEEDED is returned for an ICMP Echo.
Therefore, in this draft we RECOMMEND to base implementations on UDP
datagrams.
2.1 Traceroute configuration parameters
In order to define an information model for storing traceroutes, we
first investigated which configuration parameters are relevant when
running traceroute. We considered three major traceroute
implementations and compared them based on configurable parameters
and default values. The LINUX (SUSE 9.1) and UNIX (multiple
platform) implemetations are based on UDP datagrams, while the
WINDOWS (XP SP2) one uses ICMP Echos. The following table summarizes
such comparison. A N/A in the option column, means that such option
is not configurable for the specific implementation.
Niccolini, et al. Expires January 21, 2006 [Page 4]
Internet-Draft IPPM Way to store traceroutes July 2005
+---------------------------------------------------------+
| OS |Option| Description | Default |
+-------+------+--------------------------------+---------+
| LINUX | -m |Specify the maximum TTL used | 30 |
|-------+------|in outgoing probes. |---------|
| UNIX | -m | | 30 |
|-------+------| |---------|
|WINDOWS| -h | | 30 |
+-------+------+--------------------------------+---------+
| LINUX | -n |Display hop addresses | - |
|-------+------|numerically rather than |---------|
| UNIX | -n |simbolically. | - |
|-------+------| |---------|
|WINDOWS| -d | | - |
+-------+------+--------------------------------+---------+
| LINUX | -w |Set the time to wait for a | 3 sec |
|-------+------|response to a probe. |---------|
| UNIX | -w | | 5 sec |
|-------+------| |---------|
|WINDOWS| -w | | 4 sec |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Specify a loose source route | - |
|-------+------|gateway (to direct the |---------|
| UNIX | -g |traceroute through routers not | - |
|-------+------|necessarily in the path). |---------|
|WINDOWS| -g | | - |
+-------+------+--------------------------------+---------+
| LINUX | -p |Set the base UDP port number | 33434 |
|-------+------|used in probes |---------|
| UNIX | -p |(UDP port = base + nhops - 1). | 33434 |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | -q |Set the number of probes per | 3 |
|-------+------|TTL. |---------|
| UNIX | -q | | 3 |
|-------+------| |---------|
|WINDOWS| N/A | | 3 |
+-------+------+--------------------------------+---------+
| LINUX | -s |Set the IP source address in |IP |
|-------+------|outgoing probes to the specified|address |
| UNIX | -s |value. |of the |
|-------+------| |out |
|WINDOWS| N/A | |interface|
+-------+------+--------------------------------+---------+
| LINUX | -t |Set the type-of-service (TOS) | 0 |
|-------+------|in the probes to the specified |---------|
| UNIX | -t |value. | 0 |
Niccolini, et al. Expires January 21, 2006 [Page 5]
Internet-Draft IPPM Way to store traceroutes July 2005
|-------+------| |---------|
|WINDOWS| N/A | | 0 |
+-------+------+--------------------------------+---------+
| LINUX | -v |Verbose output: received ICMP | - |
|-------+------|packets other than TIME_EXCEEDED|---------|
| UNIX | -v |and UNREACHABLE are listed. | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | -l |Display the TTL value of | - |
|-------+------|returned packets. This is useful|---------|
| UNIX | N/A |for checking for asymmetric | - |
|-------+------|routing. |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | -r |Bypass the normal routing tables| - |
|-------+------|and send directly to a host on |---------|
| UNIX | -r |attached network. | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Set the initial TTL for the | 1 |
|-------+------|first probe. |---------|
| UNIX | -f | | 1 |
|-------+------| |---------|
|WINDOWS| N/A | | 1 |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Set the "don't fragment" bit. | - |
|-------+------| |---------|
| UNIX | -F | | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Enables socket level debugging. | - |
|-------+------| |---------|
| UNIX | -d | | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Use ICMP ECHO instead of UDP | - |
|-------+------|datagrams. |---------|
| UNIX | -I | | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Specify a network interface to | - |
|-------+------|obtain the IP address for |---------|
| UNIX | -i |outgoing IP packets (alternative| - |
Niccolini, et al. Expires January 21, 2006 [Page 6]
Internet-Draft IPPM Way to store traceroutes July 2005
|-------+------|to option -s). |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | N/A |Toggle checksum. | - |
|-------+------| |---------|
| UNIX | -x | | - |
|-------+------| |---------|
|WINDOWS| N/A | | - |
+-------+------+--------------------------------+---------+
| LINUX | - |As optional last paramater, |Depends |
|-------+------|LINUX and UNIX implementations |on |
| UNIX | - |allow specifying the probe |implement|
|-------+------|datagram length for outgoing |ation. |
|WINDOWS| N/A |probes. | |
+-------+------+--------------------------------+---------+
Niccolini, et al. Expires January 21, 2006 [Page 7]
Internet-Draft IPPM Way to store traceroutes July 2005
3. Known problems with traceroute
The widespred use of firewalls might prevent UDP or ICMP based
traceroutes to completely trace the path to a destination, since
traceroute probes might end up being filtered. In some cases, such
limitation might be overcome by sending instead TCP packets to
specific ports that hosts located behind the firewall are listening
for connections on. TCP based implementations use TCP SYN or FYN
probes and listen for TIME_EXCEEDED messages, TCP RESET and other
messages from firewalls and gateways on the path. On the other hand,
some firewalls filter out TCP SYN packets to prevent denial of
service attacks, therefore the actual advantage of using TCP instead
of UDP traceroute depends mainly on firewall configurations, which
are not known in adavance. A detailed analysis of TCP based
traceroutes is outside the scope of this draft, therefore in the
sequel, we will restrict our focus to the most commonly implemented
UDP based traceroute.
Niccolini, et al. Expires January 21, 2006 [Page 8]
Internet-Draft IPPM Way to store traceroutes July 2005
4. Reports/results
The following list reports the information fields provided by all
traceroute implementations considered. The order in which they are
reported here is not relevant and it changes in different
implementations. For each hop the information reported is:
o the hop index;
o the host symbolical address, provided that at least one of the
probes received a response, the symbolic address could be resolved
at the correponding 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 implementation, additional information
might be displayed in the output (for instance MPLS-related
information).
It might happen that some probes do not receive a response within the
configured time-out (for instance if the probe is filtered out by a
firewall). In this case, an "*" is displayed in place of the RTT.
Besides, for delays below 1 ms, some implementations reports 0 ms
(f.i. UNIX and LINUX) while WINDOWS tracert reports "< 1 ms".
Niccolini, et al. Expires January 21, 2006 [Page 9]
Internet-Draft IPPM Way to store traceroutes July 2005
5. Information model for storing traceroutes measurements
This section describes the information model for the traceroute
measurements data storing. The information model is composed of
information elements; for defining these information elements, a
template is used. Such template is specified in the list below:
o name - A unique and meaningful name for the information element.
The preferred spelling for the name is to use mixed case if the
name is compound, with an initial lower case letter, e.g.,
"sourceIpAddress".
o 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.
o default value - The default value for the element (where
applicable).
5.1 Data types
This section describes the set of valid data types of the information
model.
o String - The type "String" represents a finite length string of
valid characters from the Unicode character encoding set. Unicode
allows for ASCII and many other international character sets to be
used. It is expected that strings will be encoded in UTF-8
format, which is identical in encoding for USASCII characters, but
also accomodates other Unicode multibyte characters.
o InetAddressType - The type "InetAddressType" represents a type of
Internet address. The allowed values are to be intended as
imported from [1].
o InetAddress - The type "InetAddress" denotes a generic Internet
address. The allowed values are to be intended as imported from
[1].
o TruthValue - The type "TruthValue" represents a boolean value.
The allowed values are to be intended as imported from [2].
Niccolini, et al. Expires January 21, 2006 [Page 10]
Internet-Draft IPPM Way to store traceroutes July 2005
o Unsigned32 - The type "Unsigned32" represents a value in the range
(0..4294967295).
o InterfaceIndexOrZero - The type "InterfaceIndexOrZero" is an
extension of the InterfaceIndex convention. The latter defines a
greater than zero value used to identify an interface or interface
sub-layer in the system. This extension permits the additional
value of zero. Examples of the usage of zero might include
situations where interface was unknown, or when none or all
interfaces need to be referenced. The allowed values are to be
intended as imported from [5].
o ProbesType - The type "ProbesType" represents a way of indicating
the protocol used for the traceroute probes. Allowed values are
UDP, TCP, ICMP.
o DateAndTime - The type "DateAndTime" represents a date-time
specification. The allowed values are to be intended as imported
from [2] apart from the fact that in this document there is the
need to use a milli-second resolution instead a deci-second one.
o OperationResponseStatus - The type "OperationResponseStatus" is
used to report the result of an operation. The allowed values are
to be intended as imported from [6] or from its recent update
([8]).
5.2 Information Elements
This section describes the elements of the traceroute measurement.
The elements are grouped in two groups (Configuration and Results)
according to their semantics.
5.2.1 Configuration Information Elements
This section describes the elements of the traceroute measurement
that are specific to traceroute configuration.
5.2.1.1 traceRouteCtlTestName
o name - traceRouteCtlTestName
o description - Specifies the name of a traceroute test. This is
locally unique.
o dataType - String
Niccolini, et al. Expires January 21, 2006 [Page 11]
Internet-Draft IPPM Way to store traceroutes July 2005
o units - N/A
o default value - N/A
5.2.1.2 traceRouteCtlTargetAddressType
o name - traceRouteCtlTargetAddressType
o description - Specifies the type of host address used in the
traceroute command.
o dataType - InetAddressType
o units - N/A
o default value - N/A
5.2.1.3 traceRouteCtlTargetAddress
o name - traceRouteCtlTargetAddress
o description - Specifies the host address used in the traceroute
command. The host address type can be determined by the examining
the value of the corresponding traceRouteCtlTargetAddressType.
o dataType - InetAddress
o units - N/A
o default value - N/A
5.2.1.4 traceRouteCtlByPassRouteTable
o name - traceRouteCtlByPassRouteTable
o description - Specifies if the optional bypassing of the route
table was enabled or not. If enabled, the traceroute will bypass
the normal routing tables and send directly to a host on an
attached network. If the host is not on a directly-attached
network, an error is returned. This option can be used to perform
the traceroute operation to a local host through an interface that
has no route defined.
o dataType - TruthValue
Niccolini, et al. Expires January 21, 2006 [Page 12]
Internet-Draft IPPM Way to store traceroutes July 2005
o units - N/A
o default value - false
5.2.1.5 traceRouteCtlProbeDataSize
o name - traceRouteCtlProbeDataSize
o description - Specifies the size of the data portion of a
traceroute operation in octets. If the RECOMMENDED traceroute
method (UDP datagrams as probes) is used, then the value contained
in this object is exact. If another traceroute method is used for
which the specified size is not appropriate, then the
implementation should have used whatever size (appropriate to the
method) is closest to the specified size. The maximum value for
this object was computed by substracting the smallest possible IP
header size of 20 octets (IPv4 header with no options) and the UDP
header size of 8 octets from the maximum IP packet size. An IP
packet has a maximum size of 65535 octets (excluding IPv6
Jumbograms).
o dataType - Unsigned32
o units - octects
o default value - 0
5.2.1.6 traceRouteCtlTimeOut
o name - traceRouteCtlTimeOut
o description - Specifies the time-out value, in seconds, for the
traceroute operation.
o dataType - Unsigned32
o units - seconds
o default value - 3
5.2.1.7 traceRouteCtlProbesPerHop
o name - traceRouteCtlProbesPerHop
Niccolini, et al. Expires January 21, 2006 [Page 13]
Internet-Draft IPPM Way to store traceroutes July 2005
o description - Specifies the number of times to reissue a
traceroute request with the same time-to-live (TTL) value.
o dataType - Unsigned32
o units - probes
o default value - 3
5.2.1.8 traceRouteCtlPort
o name - traceRouteCtlPort
o description - Specifies the base UDP port used by the traceroute
operation. Need to specify a port that is not in use at the
destination (target) host. The default value for this object is
the IANA assigned port, 33434, for the traceroute function.
o dataType - Unsigned32
o units - UDP Port
o default value - 33434
5.2.1.9 traceRouteCtlMaxTtl
o name - traceRouteCtlMaxTtl
o description - Specifies the maximum TTL value for the traceroute
operation.
o dataType - Unsigned32
o units - time-to-live value
o default value - 30
5.2.1.10 traceRouteCtlDSField
o name - traceRouteCtlDSField
o description - Specifies the value that was stored in the
Differentiated Services (DS) field in the IP packet used to
encapsulate the traceroute probe. The DS Field is defined as the
Type of Service (TOS) octet in a IPv4 header or as the Traffic
Niccolini, et al. Expires January 21, 2006 [Page 14]
Internet-Draft IPPM Way to store traceroutes July 2005
Class octet in a IPv6 header. 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 response. Not all values are legal or meaningful.
DS field usage is often not supported by IP implementations. A
value of 0 means that the function represented by this option is
not supported. Useful TOS octet values are probably '16' (low
delay) and '8' (high throughput). Further references can be found
in [3] for the definition of the Differentiated Services (DS)
field and to [4] Section 5.3.2 for Type of Service (TOS).
o dataType - Unsigned32
o units - N/A
o default value - 0
5.2.1.11 traceRouteCtlSourceAddressType
o name - traceRouteCtlSourceAddressType
o description - Specifies the type of the source address,
traceRouteCtlSourceAddress, used when performing the traceroute
operation.
o dataType - InetAddressType
o units - N/A
o default value - N/A
5.2.1.12 traceRouteCtlSourceAddress
o name - traceRouteCtlSourceAddress
o description - Specifies the IP address (which has to be given as
an IP number, not a hostname) as the source address used in
outgoing probe packets. On hosts with more than one IP address,
this option can be used to force the source address to be
something other than the primary IP address of the interface the
probe packet is sent on. A zero length octet string value for
this object means that source address specification was disabled.
The address type (InetAddressType) that relates to this object is
specified by the corresponding value of
traceRouteCtlSourceAddressType.
Niccolini, et al. Expires January 21, 2006 [Page 15]
Internet-Draft IPPM Way to store traceroutes July 2005
o dataType - InetAddress
o units - N/A
o default value - N/A
5.2.1.13 traceRouteCtlIfIndex
o name - traceRouteCtlIfIndex
o description - Specifies the inferface index used in the traceroute
operation for sending the traceroute probes. A value of zero for
this object implies that the interface was unknown.
o dataType - InterfaceIndexOrZero
o units - N/A
o default value - 0
5.2.1.14 traceRouteCtlMiscOptions
o name - traceRouteCtlMiscOptions
o description - Specifies implementation dependent options.
o dataType - String
o units - N/A
o default value - N/A
5.2.1.15 traceRouteCtlMaxFailures
o name - traceRouteCtlMaxFailures
o description - Specifies the maximum number of consecutive timeouts
allowed before terminating a traceroute operation. A value of
either 255 (maximum hop count/possible TTL value) or a 0 indicates
that the function of terminating a remote traceroute operation
when a specific number of consecutive timeouts are detected was
disabled. This element is included to give full compatibility
with [6] and with its recent update ([8]). No known
implementation of traceroute currently supports it.
Niccolini, et al. Expires January 21, 2006 [Page 16]
Internet-Draft IPPM Way to store traceroutes July 2005
o dataType - Unsigned32
o units - timeouts
o default value - 5
5.2.1.16 traceRouteCtlDontFragment
o name - traceRouteCtlDontFragment
o description - Specifies if the don't fragment flag (DF) in the IP
header for a probe was enabled or not. The use of the DF flag is
intended to be relative to a manual PATH MTU test.
o dataType - TruthValue
o units - N/A
o default value - false
5.2.1.17 traceRouteCtlInitialTtl
o name - traceRouteCtlInitialTtl
o description - Specifies the initial TTL value uses in a traceroute
operation. The use of initial TTL setting is intended to be used
when bypassing the initial (often well known) portion of a path is
to be achieved.
o dataType - Unsigned32
o units - N/A
o default value - 1
5.2.1.18 traceRouteCtlDescr
o name - traceRouteCtlDescr
o description - The purpose of this element is to provide a
description of the traceroute test.
o dataType - String
Niccolini, et al. Expires January 21, 2006 [Page 17]
Internet-Draft IPPM Way to store traceroutes July 2005
o units - N/A
o default value - N/A
5.2.1.19 traceRouteCtlType
o name - traceRouteCtlType
o description - Specifies the implementation method used for the
traceroute operation.
o dataType - ProbesType
o units - N/A
o default value - UDP
5.2.2 Results Information Elements
This section describes the elements of the traceroute measurement
that are specific to the results of a traceroute operation.
5.2.2.1 traceRouteResultsStartDateAndTime
o name - traceRouteResultsStartDateAndTime
o description - Specifies the date and start time of the traceroute
operation. This is the time when the first probe was seen at the
sending interface.
o dataType - DateAndTime
o units - N/A
o default value - N/A
5.2.2.2 traceRouteResultsIpTgtAddrType
o name - traceRouteResultsIpTgtAddrType
o description - Specifies the type of address stored in the
corresponding traceRouteResultsIpTgtAddr element.
o dataType - InetAddressType
Niccolini, et al. Expires January 21, 2006 [Page 18]
Internet-Draft IPPM Way to store traceroutes July 2005
o units - N/A
o default value - N/A
5.2.2.3 traceRouteResultsIpTgtAddr
o name - traceRouteResultsIpTgtAddr
o description - Specifies the IP address associated with a
traceRouteCtlTargetAddress value when the destination address is
specified as a DNS name. The value of this object should be a
zero length octet string when a DNS name is not specified or when
a specified DNS name fails to resolve.
o dataType - InetAddress
o units - N/A
o default value - N/A
5.2.2.4 traceRouteResultsProbeIndex
o name - traceRouteResultsProbeIndex
o description - Specifies the progressive index of a probe within
the traceroute operation. The maximum value here is the number
resulting from the operation
traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop.
o dataType - Unsigned32
o units - N/A
o default value - N/A
5.2.2.5 traceRouteResultsProbeHopIndex
o name - traceRouteResultsProbeHopIndex
o description - Specifies which hop in a traceroute path that the
probe's results are for. The value of this element is initially
determined by the value of traceRouteCtlInitialTtl.
o dataType - Unsigned32
Niccolini, et al. Expires January 21, 2006 [Page 19]
Internet-Draft IPPM Way to store traceroutes July 2005
o units - N/A
o default value - N/A
5.2.2.6 traceRouteResultsProbeIndexPerHop
o name - traceRouteResultsProbeIndexPerHop
o description - Specifies the index of a probe for a particular hop
in a traceroute path. The number of probes per hop is determined
by the value of the corresponding traceRouteCtlProbesPerHop
element.
o dataType - Unsigned32
o units - N/A
o default value - N/A
5.2.2.7 traceRouteResultsProbeHopAddrType
o name - traceRouteResultsProbeHopAddrType
o description - Specifies the type of address stored in the
corresponding traceRouteResultsProbeHopAddr element.
o dataType - InetAddressType
o units - N/A
o default value - N/A
5.2.2.8 traceRouteResultsProbeHopAddr
o name - traceRouteResultsProbeHopAddr
o description - Specifies the address of a hop in the traceroute
path. This object is not allowed to be a DNS name. The value of
the corresponding object, traceRouteResultsProbeHopAddrType,
indicates this object's IP address type.
o dataType - InetAddress
o units - N/A
Niccolini, et al. Expires January 21, 2006 [Page 20]
Internet-Draft IPPM Way to store traceroutes July 2005
o default value - N/A
5.2.2.9 traceRouteResultsProbeHopASNumber
o name - traceRouteResultsProbeHopASNumber
o description - Specifies the AS number of a hop in the traceroute
path, when the value of this element is unknown or not relevant it
should be set to zero.
o dataType - Unsigned32
o units - N/A
o default value - 0
5.2.2.10 traceRouteResultsProbeHopGeoLocation
o name - traceRouteResultsProbeHopGeoLocation
o description - Specifies the geo location of a hop in the
traceroute path.
o dataType - String
o units - N/A
o default value - N/A
5.2.2.11 traceRouteResultsProbeRoundTripTime
o name - traceRouteResultsProbeRoundTripTime
o description - 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 0 when it was not possible to transmit a probe.
o dataType - Unsigned32
o units - milliseconds
o default value - N/A
Niccolini, et al. Expires January 21, 2006 [Page 21]
Internet-Draft IPPM Way to store traceroutes July 2005
5.2.2.12 traceRouteResultsProbeResponseStatus
o name - traceRouteResultsProbeResponseStatus
o description - Specifies the result of a traceroute operation made
by the host for a particular probe.
o dataType - OperationResponseStatus
o units - N/A
o default value - N/A
5.2.2.13 traceRouteResultsProbeTime
o name - traceRouteResultsProbeTime
o description - Specifies the timestamp for when the response to the
probe was received interface.
o dataType - DateAndTime
o units - N/A
o default value - N/A
5.2.2.14 traceRouteResultsHopRawOutputData
o name - traceRouteResultsHopRawOutputData
o description - Specifies the raw output data returned by the
traceroute operation for a certain hop in a traceroute path.
o dataType - String
o units - N/A
o default value - N/A
5.2.2.15 traceRouteResultsEndDateAndTime
o name - traceRouteResultsEndDateAndTime
o description - Specifies the date and end time of the traceroute
operation. It is either the time when the response to the last
Niccolini, et al. Expires January 21, 2006 [Page 22]
Internet-Draft IPPM Way to store traceroutes July 2005
probe of the traceroute operation was received or the time when
the last probe of the traceroute operation was sent plus the
relative timeout (in case of missing response).
o dataType - DateAndTime
o units - N/A
o default value - N/A
Niccolini, et al. Expires January 21, 2006 [Page 23]
Internet-Draft IPPM Way to store traceroutes July 2005
6. Data model for storing traceroutes 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 both have advantages and
disadvantages. Textual representions are (with some limitations)
human readable while a binary representation consumes less resources
for storing, transmitting and parsing data.
An already existing and closely related data model is the DISMAN-
TRACEROUTE-MIB module [6], that specifies a BER encoding [9] used by
the Simple Network Management Protocol (SNMP) [10] for transmitting
traceroute information. This data model is well suited and supported
within network management systems, but as a general format for
storing and transmitting traceroute results it is not easily
applicable.
Another binary representation would be an extension of traffic flow
information encodings specified for the NetFlow version 9 [11]
protocol and the IPFIX protocol [12], [13]. For these protocols
standard templates could be defined as it has been done for another
purpose in [14]. The architectures behind these protocols have been
designed for the export of passively measured flow information. For
following this approach, it needs to be investigated whether or not
the respective architectures can be extended to active route
measurement.
For textual representations, using the eXtensible Markup Language
(XML) [15] is an obvious choice. XML supports clean structuring of
data and syntax checking of records. With some limitations it is
human readable. It is supported well by a huge pool of tools and
standards for generating, transmitting, parsing and converting it to
other data formats. Its disadvantages is the resource comsumption
for processing, storing, and transmitting information. Since the
expected data volumes of traceroute data in network operation and
maintenance is not expected to be extremly high, the inefficient
usage of resources is not a significant disadvantage. Therefore, XML
was chosen as basis for the traceroute information model that is
specified in this section.
Niccolini, et al. Expires January 21, 2006 [Page 24]
Internet-Draft IPPM Way to store traceroutes July 2005
6.1 XML schema for traceroute measurements
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<!-- definition of simple types -->
<xs:simpleType name="inetAddressType">
<xs:restriction base="xs:string">
<xs:enumeration value="unknown"/>
<xs:enumeration value="ipv4"/>
<xs:enumeration value="ipv6"/>
<xs:enumeration value="dns"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="inetAddressTypeWithoutDns">
<xs:restriction base="xs:string">
<xs:enumeration value="unknown"/>
<xs:enumeration value="ipv4"/>
<xs:enumeration value="ipv6"/>
<xs:enumeration value="noSpecification"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_zeroLenghtString">
<xs:restriction base="xs:string">
<xs:maxLength value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressIpv4">
<xs:restriction base="xs:string">
<xs:pattern value=
"(([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]).)
{3}([1-9]?[0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])"
/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_inetAddressIpv6">
<xs:restriction base="xs:string">
<xs:pattern value=
"(([\dA-Fa-f]{1,4}:){7}[\dA-Fa-f]{1,4})
(:([\d]{1,3}.){3}[\d]{1,3})?"
/>
</xs:restriction>
</xs:simpleType>
Niccolini, et al. Expires January 21, 2006 [Page 25]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:simpleType name="_inetAddressDns">
<xs:restriction base="xs:string">
<xs:maxLength value="256"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="operationResponseStatus">
<xs:restriction base="xs:string">
<xs:enumeration value="responseReceived"/>
<xs:enumeration value="unknown"/>
<xs:enumeration value="internalError"/>
<xs:enumeration value="requestTimedOut"/>
<xs:enumeration value="unknownDestinationAddress"/>
<xs:enumeration value="noRouteToTarget"/>
<xs:enumeration value="interfaceInactiveToTarget"/>
<xs:enumeration value="arpFailure"/>
<xs:enumeration value="maxConcurrentLimitReached"/>
<xs:enumeration value="unableToResolveDnsName"/>
<xs:enumeration value="invalidHostAddress"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_dateAndTimeUpToSeconds">
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="_timeMilliseconds">
<xs:restriction base="xs:unsignedShort">
<xs:maxExclusive value="1000"/>
</xs:restriction>
</xs:simpleType>
<!-- Configuration Information elements -->
<xs:simpleType name="_traceRouteCtlTestName">
<xs:annotation>
<xs:documentation>Specifies the name of a traceroute
test. This is locally unique.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="32"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlByPassRouteTable">
<xs:annotation>
<xs:documentation>Specifies if the optional bypassing of
the route table was enabled or not. If enabled, the
Niccolini, et al. Expires January 21, 2006 [Page 26]
Internet-Draft IPPM Way to store traceroutes July 2005
traceroute will bypass the normal routing tables and
send directly to a host on an attached network. If
the host is not on a directly-attached network, an
error is returned. This option can be used to perform
the traceroute operation to a local host through an
interface that has no route defined.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlProbeDataSize">
<xs:annotation>
<xs:documentation>Specifies the size of the data
portion of a traceroute operation in octets.
If the RECOMMENDED traceroute method (UDP datagrams
as probes) is used, then the value contained in this
object is exact. If another
traceroute method is used for which the specified size
is not appropriate, then the implementation should have
used whatever size (appropriate to the method) is
closest to the specified size. The maximum value for
this object was computed by substracting 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).
Units are: octects.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedShort">
<xs:maxExclusive value="65508"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlTimeOut">
<xs:annotation>
<xs:documentation>Specifies the time-out value, in
seconds, for the traceroute operation.
Units are: seconds.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
<xs:maxExclusive value="61"/>
</xs:restriction>
</xs:simpleType>
Niccolini, et al. Expires January 21, 2006 [Page 27]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:simpleType name="_traceRouteCtlProbesPerHop">
<xs:annotation>
<xs:documentation>Specifies the number of times to
reissue a traceroute request with the same
time-to-live (TTL) value.
Units are: probes.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
<xs:maxExclusive value="11"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlPort">
<xs:annotation>
<xs:documentation>Specifies the base UDP port used by
the traceroute operation. Need to specify a port that
is not in use at the destination (target) host. The
default value for this object is the IANA assigned
port, 33434, for the traceroute function.
Units are: UDP port.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedShort">
<xs:minExclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlMaxTtl">
<xs:annotation>
<xs:documentation>Specifies the maximum TTL value for
the traceroute operation.
Units are: time-to-live value.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlDSField">
<xs:annotation>
<xs:documentation>Specifies the value that was stored
in the Differentiated Services (DS) field in the IP
packet used to encapsulate the traceroute probe. The DS
Field is defined as the Type of Service (TOS) octet in
a IPv4 header or as the Traffic Class octet in a IPv6
Niccolini, et al. Expires January 21, 2006 [Page 28]
Internet-Draft IPPM Way to store traceroutes July 2005
header. 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 response. Not all values
are legal or meaningful. DS field usage is often not
supported by IP implementations. A value of 0 means
that the function represented by this option is not
supported. Useful TOS octet values are probably '16'
(low delay) and '8' (high throughput). Further
references can be found in the RFC 2474 for the
definition of the Differentiated Services (DS) field
and to the RFC 1812 Section 5.3.2 for Type of Service
(TOS).
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlIfIndex">
<xs:annotation>
<xs:documentation>Specifies the inferface index used
in the traceroute operation for sending the
traceroute probes. A value of zero for this object
implies that the interface was unknown.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlMiscOptions">
<xs:annotation>
<xs:documentation>Specifies implementation dependent
options.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlMaxFailures">
<xs:annotation>
<xs:documentation>Specifies the maximum number of
consecutive timeouts allowed before terminating a
traceroute operation. A value of either 255
(maximum hop count/possible TTL value) or a 0
indicates that the function of terminating a
remote traceroute operation when a specific number
Niccolini, et al. Expires January 21, 2006 [Page 29]
Internet-Draft IPPM Way to store traceroutes July 2005
of consecutive timeouts are detected was disabled.
This element is included to give full compatibility
with DISMAN working group documents. No known
implementation of traceroute currently supports it.
Units are: timeouts.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlDontFragment">
<xs:annotation>
<xs:documentation>Specifies if the don't fragment
flag (DF) in the IP header for a probe was enabled
or not. The use of the DF flag is intended to be
relative to a manual PATH MTU test.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:boolean"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlInitialTtl">
<xs:annotation>
<xs:documentation>Specifies the initial TTL value
uses in a traceroute operation. The use of initial
TTL setting is intended to be used when bypassing
the initial (often well known) portion of a path
is to be achieved.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlDescr">
<xs:annotation>
<xs:documentation>The purpose of this element is to
provide a description of the traceroute test.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteCtlType">
<xs:annotation>
Niccolini, et al. Expires January 21, 2006 [Page 30]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:documentation>Specifies the implementation method
used for the traceroute operation.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="TCP"/>
<xs:enumeration value="UDP"/>
<xs:enumeration value="ICMP"/>
</xs:restriction>
</xs:simpleType>
<!-- End of Configuration Information elements -->
<!-- Results Information elements -->
<xs:simpleType name="_traceRouteResultsProbeIndex">
<xs:annotation>
<xs:documentation>Specifies the progressive index of
a probe within the traceroute operation. The maximum
value here is the number resulting from the operation
traceRouteCtlMaxTtl*traceRouteCtlProbesPerHop.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedShort">
<xs:minExclusive value="0"/>
<xs:maxExclusive value="2551"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsProbeHopIndex">
<xs:annotation>
<xs:documentation>Specifies which hop in a traceroute
path that the probe's results are for. The value of
this element is initially determined by the value of
traceRouteCtlInitialTtl.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsProbeIndexPerHop">
<xs:annotation>
<xs:documentation>Specifies the index of a probe for a
particular hop in a traceroute path. The number of
probes per hop is determined by the value of the
corresponding traceRouteCtlProbesPerHop element.
</xs:documentation>
</xs:annotation>
Niccolini, et al. Expires January 21, 2006 [Page 31]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:restriction base="xs:unsignedByte">
<xs:minExclusive value="0"/>
<xs:maxExclusive value="11"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsProbeHopASNumber">
<xs:annotation>
<xs:documentation>Specifies the AS number of a hop
in the traceroute path, when the value of this element
is unknown or not relevant it should be set to zero.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedInt"/>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsProbeHopGeoLocation">
<xs:annotation>
<xs:documentation>Specifies the geo location of a hop
in the traceroute path.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="100"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsProbeRoundTripTime">
<xs:annotation>
<xs:documentation>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 0 when it was not
possible to transmit a probe.
Units are: milliseconds.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:unsignedShort">
<xs:maxExclusive value="60001"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="_traceRouteResultsHopRawOutputData">
<xs:annotation>
<xs:documentation>Specifies the raw output data returned
by the traceroute operation for a certain hop in a
traceroute path.
</xs:documentation>
Niccolini, et al. Expires January 21, 2006 [Page 32]
Internet-Draft IPPM Way to store traceroutes July 2005
</xs:annotation>
<xs:restriction base="xs:string">
<xs:maxLength value="200"/>
</xs:restriction>
</xs:simpleType>
<!-- End of Results Information Elements -->
<!-- End of definition of simple types -->
<!-- definition of complex types -->
<xs:complexType name="_inetAddress">
<xs:choice>
<xs:element name="inetAddressUnknown" type="_zeroLenght
String"/>
<xs:element name="inetAddressIpv4" type="_inetAddress
Ipv4"/>
<xs:element name="inetAddressIpv6" type="_inetAddress
Ipv6"/>
<xs:element name="inetAddressDns" type="_inetAddress
Dns"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="_inetAddressWithoutDns">
<xs:choice>
<xs:element name="inetAddressUnknown" type="_zeroLenght
String"/>
<xs:element name="inetAddressIpv4" type="_inetAddress
Ipv4"/>
<xs:element name="inetAddressIpv6" type="_inetAddress
Ipv6"/>
<xs:element name="zeroLenghtString" type="_zeroLenght
String"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="_dateAndTime">
<xs:sequence>
<xs:element name="dateAndTimeUpToSeconds" type="_date
AndTimeUpToSeconds"/>
<xs:element name="timeMilliseconds" type="_timeMilli
seconds"/>
</xs:sequence>
</xs:complexType>
<!-- Configuration Information elements -->
<xs:complexType name="_traceRouteCtlTargetAddressType">
<xs:annotation>
Niccolini, et al. Expires January 21, 2006 [Page 33]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:documentation>Specifies the type of host address
used in the traceroute command.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="targetAddressType" type="inetAddress
Type"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteCtlTargetAddress">
<xs:annotation>
<xs:documentation>Specifies the host address used in
the traceroute command. The host address type can be
determined by the examining the value of the
corresponding traceRouteCtlTargetAddressType.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="targetAddress" type="_inetAddress"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteCtlSourceAddressType">
<xs:annotation>
<xs:documentation>Specifies the type of the source
address, traceRouteCtlSourceAddress, used when
performing the traceroute operation.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="sourceAddressType" type="inetAddress
TypeWithoutDns"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteCtlSourceAddress">
<xs:annotation>
<xs:documentation>Specifies the IP address (which has
to be given as an IP number, not a hostname) as the
source address used in outgoing probe packets. On
hosts with more than one IP address, this option
can be used to force the source address to be
something other than the primary IP address of the
interface the probe packet is sent on. A zero length
octet string value for this object means that source
address specification was disabled. The address type
(InetAddressType) that relates to this object is
Niccolini, et al. Expires January 21, 2006 [Page 34]
Internet-Draft IPPM Way to store traceroutes July 2005
specified by the corresponding value of
traceRouteCtlSourceAddressType.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="sourceAddress" type="_inetAddress
WithoutDns"/>
</xs:sequence>
</xs:complexType>
<!-- End of Configuration Information elements -->
<!-- Results Information elements -->
<xs:complexType name="_traceRouteResultsStartDateAndTime">
<xs:annotation>
<xs:documentation>Specifies the date and start time of
the traceroute operation. This is the time when the
first probe was sent.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="dateAndTime" type="_dateAndTime"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsIpTgtAddrType">
<xs:annotation>
<xs:documentation>Specifies the type of address stored
in the corresponding traceRouteResultsIpTgtAddr
element.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="ipTgtAddrType" type="inetAddressType
WithoutDns"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsIpTgtAddr">
<xs:annotation>
<xs:documentation>Specifies the IP address associated
with a traceRouteCtlTargetAddress value when the
destination address is specified as a DNS name.
The value of this object should be a zero length
octet string when a DNS name is not specified or
when a specified DNS name fails to resolve.
</xs:documentation>
</xs:annotation>
<xs:sequence>
Niccolini, et al. Expires January 21, 2006 [Page 35]
Internet-Draft IPPM Way to store traceroutes July 2005
<xs:element name="ipTgtAddr" type="_inetAddress
WithoutDns"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsProbeHopAddrType">
<xs:annotation>
<xs:documentation>Specifies the type of address stored
in the corresponding traceRouteResultsProbeHopAddr
element.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="probeHopAddrType" type="inetAddressType
WithoutDns"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsProbeHopAddr">
<xs:annotation>
<xs:documentation>Specifies the address of a hop in the
traceroute path. This object is not allowed to be a
DNS name. The value of the corresponding object,
traceRouteResultsProbeHopAddrType, indicates this
object's IP address type.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="probeHopAddr" type="_inetAddress
WithoutDns"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsProbeResponseStatus">
<xs:annotation>
<xs:documentation>Specifies the result of a traceroute
operation made by the host for a particular probe.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="probeResponseStatus" type="operation
ResponseStatus"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsProbeTime">
<xs:annotation>
<xs:documentation>Specifies the timestamp when the
Niccolini, et al. Expires January 21, 2006 [Page 36]
Internet-Draft IPPM Way to store traceroutes July 2005
response to the probe was received.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="dateAndTime" type="_dateAndTime"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsProbe">
<xs:sequence>
<xs:element name="traceRouteResultsProbeIndex"
type="_traceRouteResultsProbeIndex"/>
<xs:element name="traceRouteResultsProbeHopIndex"
type="_traceRouteResultsProbeHopIndex"/>
<xs:element name="traceRouteResultsProbeIndexPerHop"
type="_traceRouteResultsProbeIndexPerHop"/>
<xs:element name="traceRouteResultsProbeHopAddrType"
type="_traceRouteResultsProbeHopAddrType"/>
<xs:element name="traceRouteResultsProbeHopAddr"
type="_traceRouteResultsProbeHopAddr"/>
<xs:element name="traceRouteResultsProbeHopASNumber"
type="_traceRouteResultsProbeHopASNumber"
minOccurs="0" maxOccurs="1"/>
<xs:element name="traceRouteResultsProbeHopGeo
Location"
type="_traceRouteResultsProbeHopGeoLocation"
minOccurs="0" maxOccurs="1"/>
<xs:element name="traceRouteResultsProbeRoundTrip
Time"
type="_traceRouteResultsProbeRoundTripTime"/>
<xs:element name="traceRouteResultsProbeResponse
Status"
type="_traceRouteResultsProbeResponseStatus"/>
<xs:element name="traceRouteResultsProbeTime"
type="_traceRouteResultsProbeTime"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="_traceRouteResultsEndDateAndTime">
<xs:annotation>
<xs:documentation>Specifies the date and end time of
the traceroute operation. It is either the time
when the response to the last probe of the
traceroute operation was received or the time when
the last probe of the traceroute operation was sent
plus the relative timeout (in case of missing
response).
</xs:documentation>
Niccolini, et al. Expires January 21, 2006 [Page 37]
Internet-Draft IPPM Way to store traceroutes July 2005
</xs:annotation>
<xs:sequence>
<xs:element name="dateAndTime" type="_dateAndTime"/>
</xs:sequence>
</xs:complexType>
<!-- End of Results Information Elements -->
<xs:complexType name="_traceRouteMeasurement">
<xs:sequence>
<xs:element name="traceRouteCtlTestName"
type="_traceRouteCtlTestName"/>
<xs:element name="traceRouteCtlTargetAddressType"
type="_traceRouteCtlTargetAddressType"/>
<xs:element name="traceRouteCtlTargetAddress"
type="_traceRouteCtlTargetAddress"/>
<xs:element name="traceRouteCtlByPassRouteTable"
type="_traceRouteCtlByPassRouteTable"
minOccurs="0" maxOccurs="1" default="false"/>
<xs:element name="traceRouteCtlProbeDataSize"
type="_traceRouteCtlProbeDataSize"
minOccurs="0" maxOccurs="1" default="0"/>
<xs:element name="traceRouteCtlTimeOut"
type="_traceRouteCtlTimeOut"
minOccurs="0" maxOccurs="1" default="3"/>
<xs:element name="traceRouteCtlProbesPerHop"
type="_traceRouteCtlProbesPerHop"
minOccurs="0" maxOccurs="1" default="3"/>
<xs:element name="traceRouteCtlPort"
type="_traceRouteCtlPort"
minOccurs="0" maxOccurs="1" default="33434"/>
<xs:element name="traceRouteCtlMaxTtl"
type="_traceRouteCtlMaxTtl"
minOccurs="0" maxOccurs="1" default="30"/>
<xs:element name="traceRouteCtlDSField"
type="_traceRouteCtlDSField"
minOccurs="0" maxOccurs="1" default="0"/>
<xs:element name="traceRouteCtlSourceAddressType"
type="_traceRouteCtlSourceAddressType"/>
<xs:element name="traceRouteCtlSourceAddress"
type="_traceRouteCtlSourceAddress"/>
<xs:element name="traceRouteCtlIfIndex"
type="_traceRouteCtlIfIndex"
minOccurs="0" maxOccurs="1" default="0"/>
<xs:element name="traceRouteCtlMiscOptions"
type="_traceRouteCtlMiscOptions"
minOccurs="0" maxOccurs="1"/>
<xs:element name="traceRouteCtlMaxFailures"
type="_traceRouteCtlMaxFailures"
Niccolini, et al. Expires January 21, 2006 [Page 38]
Internet-Draft IPPM Way to store traceroutes July 2005
minOccurs="0" maxOccurs="1" default="5"/>
<xs:element name="traceRouteCtlDontFragment"
type="_traceRouteCtlDontFragment"
minOccurs="0" maxOccurs="1" default="false"/>
<xs:element name="traceRouteCtlInitialTtl"
type="_traceRouteCtlInitialTtl"
minOccurs="0" maxOccurs="1" default="1"/>
<xs:element name="traceRouteCtlDescr"
type="_traceRouteCtlDescr"
minOccurs="0" maxOccurs="1"/>
<xs:element name="traceRouteCtlType"
type="_traceRouteCtlType"
minOccurs="0" maxOccurs="1" default="UDP"/>
<xs:element name="traceRouteResultsStartDateAndTime"
type="_traceRouteResultsStartDateAndTime"/>
<xs:element name="traceRouteResultsIpTgtAddrType"
type="_traceRouteResultsIpTgtAddrType"/>
<xs:element name="traceRouteResultsIpTgtAddr"
type="_traceRouteResultsIpTgtAddr"/>
<xs:element name="traceRouteResultsProbe"
type="_traceRouteResultsProbe"
minOccurs="1" maxOccurs="2550"/>
<xs:element name="traceRouteResultsHopRawOutputData"
type="_traceRouteResultsHopRawOutputData"
minOccurs="0" maxOccurs="255"/>
<xs:element name="traceRouteResultsEndDateAndTime"
type="_traceRouteResultsEndDateAndTime"/>
</xs:sequence>
</xs:complexType>
<!-- End of definition of complex types -->
<!-- Reference to "Configuration" to define the
"Configuration" element -->
<!-- It is the "father" of all the other elements -->
<xs:element name="traceRouteMeasurement"
type="_traceRouteMeasurement"/>
</xs:schema>
Niccolini, et al. Expires January 21, 2006 [Page 39]
Internet-Draft IPPM Way to store traceroutes July 2005
7. Relevant metrics for traceroute measurements
The previous sections of this draft have been dealing with the
traceroute tool description, its parameters and the output that is
going to be stored; in this section we want to highlight the relevant
metrics that are of interest when storing traceroute measurements.
Since the traceroute has built-in configurable mechanisms like time-
outs and can experience problems related to the crossing of
firewalls, some of the packets that traceroute sends out end up being
time-out or filtered. Sometimes it is impossible to trace the path
to a node or there is not a complete set of probes describing the RTT
to reach it. Classical metrics already standardized by the IPPM
working group have to be closely examined in order to check for their
applicability in the traceroute context. If some metrics are found
not to be adequate, the authors will propose new metrics to remove
the inconsistencies. The metrics that are currently under
investigation by the authors of this draft are:
o Round-trip delay metric
o Connectivity metrics
o Loss metrics
A known inconsistency exists between the round-trip delay metric
defined by the PPM working group and the results returned by the
current traceroute implementations. Unfortunately, it is unlikely
that the traceroute implementations will change accordingly in the
near future.
Niccolini, et al. Expires January 21, 2006 [Page 40]
Internet-Draft IPPM Way to store traceroutes July 2005
8. Conclusions
This draft attempts to define a standard way to store traceroute
measurements. The document starts by examining a set of traceroute
tools from the most common operatying systems and provides a summary
of configurable and default input parameters. This investigation
served as base for the definition of an information model and related
data model. Furthermore, this draft tackles the issue of metrics
resulting from traceroute measurements. Metrics already standardized
by the IPPM might indeed not be directly applicable to traceroute
results, where it is necessary to take into account, for instance,
for missing responses. The detailed analysis of the different
metrics and potential proposals to overcome possible inconsistencies
will be topic for future work. A number of open issues that still
need to be discussed in the IPPM mailing list was also drafted.
Niccolini, et al. Expires January 21, 2006 [Page 41]
Internet-Draft IPPM Way to store traceroutes July 2005
9. Security considerations
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. This memo does not specify an
implementation of the metrics, so it does not directly affect the
security of the Internet nor of applications which run on the
Internet. However, implementations of these metrics must be mindful
of security and privacy concerns. Since traceroute measurements
involve metrics of different types, each of the metric defined for
storing traceroute measurments needs separate security considerations
that are basically already covedered in the related RFCs published by
the IPPM working group. The 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
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 January 21, 2006 [Page 42]
Internet-Draft IPPM Way to store traceroutes July 2005
10. IANA Considerations
This document will need to register a new XML schema according to the
guidelines in [7].
The URN Sub-Namespace Registration will be for
urn:ietf:params:xml:schema:<id>. Where id has to be provided by
IANA. NOTE: in order for a URN of this type to be assigned, the item
being registered MUST have been through the IETF consensus process.
Basically, this means that it must be documented in a RFC.
URI: The URI for this schema will be urn:ietf:params:xml:schema:<id>.
Registrant Contact: TBD.
XML: TBD.
Niccolini, et al. Expires January 21, 2006 [Page 43]
Internet-Draft IPPM Way to store traceroutes July 2005
11. Open Issues
This section is intended to keep track of the open issues that are to
be discussed in the IPPM working group.
o Relevant metrics and their applicability to the traceroute case.
o Security considerations may be improved.
o IANA considerations are to be completed.
12. Normative References
[1] Daniele et al., M., "Textual Conventions for Internet Network
Addresses", RFC 3291, May 2002.
[2] McCloghrie et al., K., "Textual Conventions for SMIv2",
RFC 2579, April 1999.
[3] Nichols et al., K., "Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[4] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[5] McCloghrie et al., K., "The Interfaces Group MIB", RFC 2863,
June 2000.
[6] White, K., "Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations", RFC 2925, September 2000.
[7] Mealling, M., "The IETF XML registry", RFC 3688, January 2004.
[8] Quittek, J., "Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations",
DRAFT draft-ietf-disman-remops-mib-v2-06.txt, December 2004.
[9] Presuhn et al., R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", RFC 3417, December 2002.
[10] Case et al., J., "Introduction and Applicability Statements for
Internet Standard Management Framework", RFC 3410,
December 2002.
[11] Claise, B., "Cisco Systems NetFlow Services Export Version 9",
RFC 3954, October 2004.
Niccolini, et al. Expires January 21, 2006 [Page 44]
Internet-Draft IPPM Way to store traceroutes July 2005
[12] Claise, B., "Definitions of Managed Objects for Remote Ping,
Traceroute, and Lookup Operations",
DRAFT draft-ietf-ipfix-protocol-17.txt, July 2005.
[13] Quittek et al., J., "Information Model for IP Flow Information
Export", DRAFT draft-ietf-ipfix-info-09.txt, July 2005.
[14] Stephan et al., E., "IPFIX templates for common ISP usages",
DRAFT draft-stephan-isp-templates-00.txt, July 2005.
[15] Yergeau et al., F., "Extensible Markup Language (XML) 1.0
(Third Edition)", W3C Recommendation, February 2004.
Authors' Addresses
Saverio Niccolini
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 18
Email: saverio.niccolini@netlab.nec.de
URI: http://www.netlab.nec.de
Sandra Tartarelli
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 32
Email: sandra.tartarelli@netlab.nec.de
URI: http://www.netlab.nec.de
Juergen Quittek
Network Laboratories, NEC Europe Ltd.
Kurfuersten-Anlage 36
Heidelberg 69115
Germany
Phone: +49 (0) 6221 905 11 15
Email: quittek@netlab.nec.de
URI: http://www.netlab.nec.de
Niccolini, et al. Expires January 21, 2006 [Page 45]
Internet-Draft IPPM Way to store traceroutes July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Niccolini, et al. Expires January 21, 2006 [Page 46]