One document matched: draft-bonica-tunproto-04.txt
Differences from draft-bonica-tunproto-03.txt
Internet Draft R. Bonica
Expiration Date: August 2003 WorldCom
E. Rosen
Cisco Systems
K. Kompella
Juniper Networks
D. Meyer
Sprint
R.Dube
Xebeo Communications
February 2003
Generic Tunnel Tracing Protocol (GTTP) Specification
draft-bonica-tunproto-04.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC-2026].
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.
2. Abstract
This document describes the Generic Tunnel Tracing Protocol (GTTP).
GTTP supports enhanced route-tracing applications. Network operators
use enhanced route-tracing applications to trace the path between any
two points on an IP network. Enhanced route-tracing applications can
trace through a network's forwarding plane, its control plane or
both. Furthermore, enhanced route-tracing applications can reveal
details concerning tunnels that support the traced path. Tunnel
details can be revealed regardless of tunneling technology. For
example, enhanced route-tracing applications can trace through an
MPLS LSP as well as they can trace through an IP-in-IP tunnel.
3. Conventions used in this document
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 [RFC-2119].
4. Introduction
This document describes the Generic Tunnel Tracing Protocol (GTTP).
GTTP supports enhanced route-tracing applications. Network operators
use enhanced route-tracing applications to trace the path between any
two points on an IP network. Enhanced route-tracing applications can
trace through a network's forwarding plane, its control plane or
both. Furthermore, enhanced route-tracing applications can reveal
details concerning tunnels that support the traced path. Tunnel
details can be revealed regardless of tunneling technology. For
example, enhanced route-tracing applications can trace through an
MPLS LSP as well as they can trace through an IP-in-IP tunnel.
A companion document [TUNREQ] specifies requirements for enhanced
route-tracing applications. It also describes protocol requirements
for GTTP.
Each section of this document presents a significant aspect of GTTP.
This section describes the generic route-tracing problem and provides
an informal description of GTTP. Section 5 describes protocol
mechanisms and Section 6 describes IANA considerations. Section 7
details security considerations.
4.1. The Tunnel Tracing Problem
-----
| D0 |
|Route|
|Trace|
-----
|
| - H1 - H2 - H3 -
(IP) -|D|----|D|-------------------------------------|D|----|D|
|1| |2| H2:1 - H2:2 - H2:3 |3| |4|
(IP) | | | |------|D|-------------------|D|------| | | |
- - |5| H2:2:1 - H2:2:2 |6| - -
(MPLS) | |--------|D|--------| |
- |7| -
| |
-
Figure 1: Tunnel Tracing Problem
Figure 1 depicts eight IP accessible devices (D0 through D7). An
enhanced route-tracing application executes upon device D0. The
route-tracing application must trace the route between the D1 and D4.
In this example, assume that the traced route originates on D1's
loopback interface and terminates on D4's loopback interface.
The route between D1 and D4 contains three top level hops. These are
H1, H2 and H3. An IP-in-IP tunnel supports H2. The IP-in-IP tunnel
itself contains three hops. These hops, H2:1, H2:2 and H2:3, are
subordinate to H2.
Finally, an MPLS LSP supports H2:2. The LSP contains two hops, H2:2:1
and H2:2:2. The MPLS LSP is configured for penultimate hop popping.
Therefore, MPLS headers do not encapsulate datagrams arriving at D6.
4.2. Informal Protocol Description
GTTP supports two PDU types. These PDU types represent a traceProbe
and a traceResponse.
Enhanced route-tracing applications emit a series of traceProbe
messages. Each traceProbe elicits exactly one traceResponse and each
traceResponse describes a portion of the traced path.
Each traceProbe contains the following objects:
Source Object
Head-end Object
Access Control Object
Route Object
Propagation Object
Context Object (optional)
The Source Object identifies an IP interface and UDP port upon which
the route-tracing application is listening for a traceResponse. It
also contains a timestamp and sequence number. The route-tracing
application provides these values and uses them to match traceProbes
with traceResponses.
The Head-end Object identifies head-end of the traced path by IP
address. It also contains two timestamps. The device that supports
the head-end of the traced path provides one timestamp while
processing a traceProbe message and the other timestamp while
processing the corresponding traceResponse message. The difference
between these two timestamps represents the round trip time between
the head-end device and the device that provided the traceResponse.
The Access Control Object contains an access control token. Network
elements use this token in order to determine whether the route-
tracing application can access the information that it is requesting.
The Route Object identifies the route being traced, from the
perspective of the head-end device. The route object can represent
the top level path between two points in an IP network. It can also
represent a tunnel that supports the top level path. When the Route
Object represents a top level path, it contains an IP Header Object.
The IP Header Object contains an IP header that identifies the traced
path. (In most cases, the traced path is identifiable by IP
destination address only. In special cases, the router bases its
forwarding decision upon multiple IP header fields, so the entire IP
header is provided for completeness.) When the Route Object
represents a tunnel, it contains a Tunnel Object and the Tunnel
Object contains a tunnel identifier.
The Propagation Object determines which member of the traced path
will respond to the traceProbe. If the traced path supports TTL
decrement for (as is the case for IP or MPLS) the propagation object
contains a Hop Count. This Hop Count determines how far the
traceProbe will travel along the traced path before it expires and
elicits a traceResponse message. If the traced path does not support
TTL decrement (as is the case for some tunneling technologies), the
Propagation Object identifies the device that will provide a
traceResponse by IP address.
The optional Context Object identifies a VPN context. It is required
if the address specified by the Source Object is to be interpreted
within the context of a VPN. This is the case when the device at the
head-end of the traced is a VPN Provider Edge router.
Each traceResponse message contains an error code and the following
objects:
Source Object
Head-end Object
Access Control Object
Arrival Object (optional)
Next-hop Object (optional)
Context Object (optional)
The Source, Head-end, Access Control and Context Objects are
described above.
The Arrival Object describes how the traceProbe arrived at the
responding device. Specifically, the Arrival Object contains the
following:
- an Interface Object that identifies the interface upon
which the traceProbe arrived
- an optional Tunnel Object that identifies the tunnel
upon which the traceProbe arrived
- an Expiration field that indicates whether the traceProbe
was contained by an datagram whose TTL expired
at the responding device
The traceResponse message must include an Arrival Object if it
describes any interface other than the origination point traced path
or tunnel.
The Next-hop Object identifies the next hop along the traced path.
Specifically, the Next-hop Object contains the following:
- the next hop, identified by IP address.
- an Interface Object that identifies the interface through
which the responding device would forward the traceProbe
if it were to forward it to its ultimate destination.
- an optional Tunnel Object that identifies the tunnel through
which the responding device would forward the traceProbe
if it were to forward it to its ultimate destination.
The traceResponse message must include an Next-hop Object if it
describes any interface other than the termination point of a traced
path or tunnel.
The traceResponse message must contain a Context Object if it is
responding to a traceProbe that also contained a Context Object. The
Context Object contained by the traceResponse must be identical to
the Context Object that was contained in the corresponding
traceProbe.
4.2.1. Theory of Operation
The enhanced route-tracing application operates in phases. During its
initial phase, the application acquires information regarding the top
level path that connects two IP interfaces. Specifically, the
application receives a traceResponse from each device that
participates in the top level path. Each traceResponse can contain an
Arrival Object and a Next-hop Object. The Arrival Object describes
the hop directly upstream of the responding device, while the Next-
hop Object describes the hop directly downstream of the responding
device. The Next-hop Object contains a Tunnel Object if a tunnel
supports the downstream hop. The Tunnel Object contains a tunnel
identifier that the application will use in subsequent phases to
probe for tunnel details.
During the next phase, the application acquires information regarding
tunnels that support top level hops. Specifically, the application
uses the Tunnel Object mentioned above to query tunnel details. If
the application discovers nested tunnels, it executes subsequent
phases as required.
During each phase, the route-tracing applications sends probes to the
device that serves as head-end of the traced object. For example,
during the initial phase, the route-tracing application sends
traceProbes to the head-end of the top level path. If the route-
tracing application discovers that a tunnel supports one top level
hop, it initiates a second phase. During the second phase, the
route-tracing application sends traceProbes directly to the device
that supports the tunnel head-end.
The following sections describe how an enhanced route-tracing
application would trace the route described in Section 4.1.
4.2.2. Top Level Path Discovery
D0 formats a traceProbe, encapsulates it within UDP and IP headers,
and sends it to D1. The traceProbe contains the following objects:
- a Source Object that identifies D0 as the traceProbe's source
- a Head-end Object that identifies D1 as the head-end of the
traced path
- an Access Control Object that contains an access control token
- a Route Object that identifies D4 as the tail-end of the traced
path
- a Propagation Object that contains a Hop Count of 0, indicating
that the traceProbe is requesting information about the hop
directly downstream from D1.
D1 receives the traceProbe and interrogates its Access Control
Object. If D1 does not grant access, it sends D0 a traceResponse
indicating that access has been denied. If D1 grants access, it
interrogates the Head-end object and determines that it is the head-
end of the traced path. D1 then interrogates the Route Object and
determines that it is tracing the route towards D4. Finally, D1
interrogates the propagation object and determines that it should
report on H1.
D1 sends D0 a traceResponse that contains the following objects:
- the Source Object, as it arrived in the traceProbe
- the Head-end Object, as it arrived in the traceProbe. D1
overwrites both timestamps, indicating the time at which
it received the traceProbe and the time at which it sent
the traceResponse.
- the Access Control Object, as it arrived in the traceProbe
- a Next-hop Object that identifies the next hop by IP address.
The Next-hop Object also contains an Interface Object that
describes the interface to the next hop. The Next-hop Object
does not contain a Tunnel Object because no tunnel supports H1.
D1 directs the traceResponse to the UDP port specified by the Source
Object.
Having received the traceResponse, D0 has acquired control plane
information regarding H1. Next, D0 sends D1 another traceProbe. This
traceProbe is identical to the previous traceProbe except that its
Propagation Object contains a Hop Count of 1.
D1 receives the traceProbe and interrogates its Access Control
Object. If D1 does not grant access, it sends D0 a traceResponse
indicating that access has been denied. If D1 grants access, it
interrogates the Head-end Object and determines that it is the head-
end of the traced path. D1 then interrogates the Route Object and
determines that it is tracing the route towards D4. Next, D1
interrogates the Propagation Object and determines that it should
probe the path towards D4. Therefore, D1 timestamps the traceProbe's
Head-end Object and encapsulates the traceProbe within UDP and IP
headers. D1 sets all IP header values to those specified by the
traceProbe's Route Object. It also sets the IP TTL value equal to the
Propagation Object's Hop Count (i.e., 1). Finally, D1 recalculates
the IP header checksum and forwards the traceProbe towards D4.
Because D1 set the IP TTL to 1, the traceProbe expires at D2. D2
emits an ICMP Time Expired message, which GTTP ignores. D2 then
processes the traceProbe.
Specifically, D2 interrogates the traceProbe's Access Control Object.
If D2 does not grant access, it sends D1 a traceResponse indicating
that access has been denied. (D1 would relay this message to D0.) If
D2 grants access, it interrogates the Head-end object and determines
that it is not the head-end of the traced-path. D2 then interrogates
the Route Object and determines that it is tracing the IP route
towards D4. Therefore, D2 determines that it should report forwarding
plane information regarding H1 and control plane information
regarding H2. Having made this determination, D2 sends D1 a
traceResponse that contains the following objects:
- the Source Object, as it arrived in the traceProbe
- the Head-end Object, as it arrived in the traceProbe.
- the Access Control Object, as it arrived in the traceProbe.
- an Arrival Object indicating that the traceProbe arrived
in an expired datagram (i.e., TTL = 0). The Arrival Object
also describes the interface upon which the datagram arrived.
It does not contain a tunnel object because no tunnel supports
H1.
- a Next-hop Object that identifies the next hop by IP address.
The Next-hop Object also contains an Interface Object that
describes the interface to the next hop. Furthermore, the Next-hop
Object contains a Tunnel Object that will be used when probing
for details regarding the tunnel that supports H2.
D1 receives the traceResponse and verifies its Access Control Object.
If the traceResponse does not specify any errors, D1 updates the
Head-end object's traceResponse timestamp. Whether or not any errors
were detected, D1 relays the traceResponse to D0.
Having received the traceResponse, D0 has acquired forwarding plane
information regarding H1 and control plane information regarding H2.
D0 repeats the process described above in order to discover the
balance of the top level path.
4.2.3. Tunnel Discovery
Having discovered details regarding the top level path, the route-
tracing application must obtain details regarding the IP-in-IP tunnel
that supports H2. In order to obtain these details, D0 sends D2 a
traceProbe. The traceProbe contains the following objects:
- a Source Object that identifies D0 as the traceProbe's source
- a Head-end Object that identifies D2 as the head-end of the
traced tunnel
- an Access Control Object that contains an access control token
- a Route Object that contains the Tunnel Object obtained from
D2, above
- a Propagation Object that contains a Hop Count of 0, indicating
that the traceProbe is requesting information about the hop
directly downstream from D2.
D2 receives the traceProbe and interrogates its Access Control
Object. If D2 does not grant access, it sends D0 a traceResponse
indicating that access has been denied. If D2 grants access, it
interrogates the Head-end object and determines that it is the head-
end of the traced tunnel. D2 then interrogates the Route Object and
determines that it is tracing Tunnel H2. Finally, D2 interrogates the
propagation object and determines that it should report on H2:1.
D2 sends D0 a traceResponse that contains the following objects:
- the Source Object, as it arrived in the traceProbe
- the Head-end Object, as it arrived in the traceProbe. D2
overwrites both timestamps, indicating the time at which
it received the traceProbe and the time at which it sent
the traceResponse.
- Access Control Object, as it arrived in the traceProbe.
- a Next-hop Object that identifies the next hop by IP address.
The Next-hop Object also contains an Interface Object that
describes the interface to the next hop. It does not contain a
Tunnel Object because no tunnel supports H2:1.
Having received the traceResponse, D0 has acquired control plane
information regarding H2:1. Next, D0 sends D2 another traceProbe.
This traceProbe is identical to the previous traceProbe except that
its Propagation Object contains a Hop Count of 1.
D2 receives the traceProbe and interrogates its Access Control
Object. If D2 does not grant access, it sends D0 a traceResponse
indicating that access has been denied. If D2 grants access, it
interrogates the Head-end Object and determines that it is the head-
end of the traced-path. D2 then interrogates the Route Object and
determines that it is tracing Tunnel H2. Next, D2 interrogates the
Propagation Object and determines that it should probe Tunnel H2.
Therefore, D2 timestamps the traceProbe's Head-end Object and
encapsulates the traceProbe within UDP and IP headers. (IP header
values are determined by the configuration of tunnel H2.) D2 sets the
IP TTL value equal to the Propagation Object's Hop Count (i.e., 1),
recalculates the checksum and forwards the traceProbe the tunnel
endpoint.
Because D2 set the IP TTL to 1, the traceProbe expires at D5. D5
emits an ICMP Time Expired message, which GTTP ignores. D5 then
processes the traceProbe.
Specifically, D5 interrogates the traceProbe's Access Control Object.
If D5 does not grant access, it sends D2 a traceResponse indicating
that access has been denied. (D2 would relay this message to D0.) If
D5 grants access, it interrogates the Head-end object and determines
that it is not the head-end of the traced-path. D5 then interrogates
the Route Object and determines that it is tracing Tunnel H2.
Therefore, D5 determines that it should report forwarding plane
information regarding H2:1 and control plane information regarding
H2:2. Having made this determination, D5 sends D2 a traceResponse
that contains the following objects:
- the Source Object, as it arrived in the traceProbe
- the Head-end Object, as it arrived in the traceProbe.
- Access Control Object, as it arrived in the traceProbe.
- an Arrival Object indicating that the traceProbe arrived
in an expired datagram (i.e., TTL = 0). The Arrival Object
also describes the interface upon which the datagram arrived.
It does not contain a tunnel object because no tunnel supports
H2:1.
- a Next-hop Object that identifies the next hop by IP address.
The Next-hop Object also contains an Interface Object that
describes the interface to the next hop. Furthermore, the
Next-hop Object contains a Tunnel Object that will be used
when probing for details regarding the tunnel that supports H2:2.
D2 receives the traceResponse and verifies the Access Control Object.
If the traceResponse does not specify any errors, D2 updates the
Head-end object's traceResponse timestamp. Whether or not any errors
were detected, D2 relays the traceResponse to D0.
Having received the traceResponse, D0 has acquired forwarding plane
information regarding H2:1 and control plane information regarding
H2:2.
D0 repeats the process described above in order to discover remaining
tunnel details.
4.3. Interaction with LSP PING
When tracing through an MPLS LSP, GTTP invokes [LSP-PING]. In order
to support the mapping between GTTP and LSP-PING, the Tunnel ID
contained by the GTTP Tunnel object is identical to the the Target
FEC Stack described by LSP-PING.
The MPLS ingress router also copies the entire GTTP traceProbe
message into the LSP PING PAD TLV. The LSR responding LSR includes
the PAD TLV in its reply to the ingres LSR and the ingress LSR uses
this information to format a traceResponse message.
5. Protocol Mechanisms
5.1. Transport
GTTP obtains transport services from UDP. All GTTP messages are
directed to UDP port 3693, except for traceResponse messages that are
bound directly for the route-tracing application. Those messages are
directed to the UDP port specified by the route-tracing application
in the traceProbe Source Object.
5.2. Message Formats
The following subsections detail GTTP Message Formats.
5.2.1. The TraceProbe Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Unused | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head-end Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Control Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Propagation Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Object (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: The TraceProbe Message
Figure 2 depicts the TraceProbe Message. Applications send a
TraceProbe in order to solicit details regarding a hop that is
contained by a traced path. The following paragraphs describe each
field that contributes to the TraceProbe Message.
Version: 4 bits
The Version field specifies the GTTP Message format. Value is
equal to 1.
Type: 4 bits
The Type field specifies the GTTP message type. A value of 0
identifies a TraceProbe Message.
Length: 16 bits
The Length field specifies the message length in words, with one
word equal to four octets.
The Source, Head-end, Access Control, Route, Propagation and Context
Objects are described in dedicated sections of this document.
5.2.2. The TraceResponse Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Type | Error Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head-end Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access Control Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Arrival Object (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next-Hop Object (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Context Object (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The TraceResponse Message
Figure 3 depicts the TraceResponse Message. Network devices send
traceResponse messages in order to provide details regarding a hop
that contributes to a traced path. The following paragraphs describe
each field that contributes to the TraceResponse Message.
Version: 4 bits
The Version field specifies the GTTP Message format. Value is
equal to 1.
Type: 4 bits
The Type field specifies the GTTP message type. A value of 1
identifies a TraceResponse Message.
Error Code: 8 bits
The Error Code field defines protocol errors. The following error
codes are currently defined:
0 - gttp_no_error
1 - gttp_access_denied
2 - gttp_unknown_object
3 - gttp_malformed_object
4 - gttp_required_object_missing
5 - gttp_no_such_tunnel
6 - gttp_no_route_to_destination
Length: 16 bits
The Length field specifies the message length in words, with one
word equal to four octets.
The Source, Head-end, Access Control, Arrival, Next-hop and Context
Objects are described in dedicated sections of this document.
5.2.3. The Source Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Application Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origination Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Origination Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Application Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: The Source Object
Figure 4 depicts the Source Object. The Source Object identifies the
GTTP message and its source. The following paragraphs describe each
field that contributes to the Source Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Source Object, the Type field is always equal to 1.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words. For the Source Object, this value is always
equal to 5.
Application Port: 16 bits
The Application Port field identifies a UDP port upon which the
route-tracing application is awaiting a traceResponse.
Origination TimeStamp (seconds): 32 bits
The Origination Timestamp (seconds) represents the time of day at
which the route-tracing application originated the traceProbe.
Measured in seconds.
Origination TimeStamp (microseconds): 32 bits
The Origination Timestamp (microseconds) represents the number of
microseconds that have elapsed since the last second.
Sequence Number: 32 bits
The Sequence Number identifies the traceProbe. Applications use
this field to match traceProbes with TraceResponses.
Application Address: 32 bits
The Application Address identifies an IP interface upon which the
route-tracing application is awaiting a traceResponse.
5.2.4. The Head-end Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TraceProbe Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TraceProbe Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TraceResponse Timestamp (seconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TraceResponse Timestamp (microseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head-end Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: The Head-end Object
Figure 5 depicts the Head-end Object. The Head-end Object identifies
the head-end of a top level path or supporting tunnel. The following
paragraphs describe each field that contributes to the Head-end
Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Head-end Object, the Type field is always equal to 2.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words. For the Head-end Object, this value is always
equal to 6.
TraceProbe TimeStamp: 32 bits
The TraceProbe Timestamp represents the time at which the Head-end
device received the traceProbe. It represents the number of
seconds and microseconds since some arbitrarily chosen point in
time.
TraceResponse TimeStamp: 32 bits
The TraceResponse Timestamp represents the time at which the
Head-end device sent the traceResponse. It represents the number
of seconds and microseconds since some arbitrarily chosen point in
time.
Head-end Address: 32 bits
The Head-end Address identifies the head-end of the top level path
or tunnel that is being traced.
All Unused bits must be set to 0.
5.2.5. The Access Control Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | AuType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: The Access Control Object
Figure 6 depicts the Access Control Object. GTTP entities use the
access control object to enforce access control policy. The following
paragraphs describe each field that contributes to the Access Control
Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Access Control Object, the Type field is always equal to 3.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words. For the Access Control Object, this value is
always equal to 3.
AuType: 8 bits
The AuType specifies the type of authentication used for this
message. Encoding rules follow:
1 = Plaintext password
2 = Cryptographic Authentication
Authentication: 64 bits
The Authentication field contains authentication data. See
Appendix D of [RFC 2328] for a description of this field.
5.2.6. The Route Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header Object |
| (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Object |
| (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: The Route Object
Figure 7 depicts the Route Object. The traceProbe message must
contain a Route Object.
The Route Object identifies the route being traced. The route object
can represent the top level path between two points in an IP network.
It can also represent a tunnel that supports the top level path. When
the Route Object represents a top level path, it contains an IP
Header Object. The IP Header Object contains an IP header that
identifies the traced path. (In most cases, the traced path is
identifiable by IP destination address only. In special cases, the
router bases its forwarding decision upon multiple IP header fields,
so the entire IP header is provided for completeness.) When the Route
Object represents a tunnel, it contains a Tunnel Object and the
Tunnel Object contains a tunnel identifier.
The following paragraphs describe each field that contributes to the
Route Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Route Object, the Type field is always equal to 4.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
The IP Header and Tunnel Objects are described in dedicated sections
of this document.
All Unused bits must be set to 0.
5.2.7. The Propagation Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Hop Count | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Responder Address (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: The Propagation Object
Figure 8 depicts the Propagation Object. The Propagation Object
determines which member of the traced path will respond to the
traceProbe. If the traced route supports TTL decrement for (as is the
case for IP or MPLS) the propagation object specifies a Hop Count.
This Hop Count determines how far the traceProbe will travel along
the traced route before it expires and elicits a traceResponse
message. If the traced route does not support TTL decrement (as is
the case for some tunneling technologies), the Propagation Object
identifies the device that will provide a traceResponse by IP
address.
The following paragraphs describe each field that contributes to the
Propagation Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Propagation Object, the Type field is always equal to 5.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
Flags : 8 bits
The flag in the right-most position is set if the Hop Count is to
be used. All remaining flags are unused.
Responder Address : 32 bits
The Responder Address identifies the device that is to provide the
traceResponse by IP address. This field is specified only when the
Hop Count is not used.
All Unused bits must be set to 0.
5.2.8. The Arrival Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Object |
| (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: The Arrival Object
Figure 9 depicts the Arrival Object. The Arrival Object describes how
a traceProbe arrived at the probed device.
The following paragraphs describe each field that contributes to the
Arrival Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Arrival Object, the Type field is always equal to 6.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
Flags : 8 bits
The flag in the right-most position is set if the traceProbe
arrived in a datagram whose TTL expired. All remaining flags are
unused.
The Interface Object and Tunnel Object are described in dedicated
sections of this document.
All Unused bits must be set to 0.
5.2.9. The Next-hop Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Hop Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Object |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Object |
| (optional) |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: The Next-hop Object
Figure 10 depicts the Next-hop Object. The Next-Hop Object describes
how a device would forward a traceProbe toward its destination.
The following paragraphs describe each field that contributes to the
Next-hop Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Next-Hop Object, the Type field is always equal to 7.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
Next Hop Address : 32 bits
The Next Hop Address identifies the device that supports the next
hop by IP address.
The Interface and Tunnel Objects are described in dedicated sections
of this document.
All Unused bits must be set to 0.
5.2.10. The IP Header Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: The IP Header Object
Figure 11 depicts the IP Header Object. The IP Header Object contains
an IP Header that can identify the top level path being traced.
The following paragraphs describe each field that contributes to the
IP Header Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the IP Header Object, the Type field is always equal to 8.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
IP Header : Variable Length
This field contains an IP header. It can be 0 padded for word
alignment.
All Unused bits must be set to 0.
5.2.11. The Interface Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | ifDescr Len | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ifDescr |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: The Interface Object
Figure 12 depicts the Interface Object. The Interface Object
identifies an interface and specifies its attributes. The Arrival
Object and Next-hop Object can contain the Interface Object.
The following paragraphs describe each field that contributes to the
Interface Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Interface Object, the Type field is always equal to 9.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
ifDescr Length : 8 bits
The ifDescr Length Field specifies the length of the ifDescr
field, in 4 octet words.
MTU : 16 bits
The MTU field specifies interface MTU in octets.
IP Address: 32 bits
The IP Address field identifies the interface by IP Address.
ifDescr : Variable Length
The ifDescr field identifies the interface by a unique name. It
can be 0 padded for word alignment.
All Unused bits must be set to 0.
5.2.12. The Tunnel Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | TunnelID Len | TunDetail Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTU | TunnelName Len| Tunnel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head-end IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TunnelID |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Details |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Name |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: The Tunnel Object
Figure 13 depicts the Tunnel Object. The Tunnel Object identifies a
tunnel and specifies its attributes. The Route Object, Arrival Object
and Next-hop Object can contain the Tunnel Object.
The following paragraphs describe each field that contributes to the
Tunnel Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Tunnel Object, the Type field is always equal to 10.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
TunnelID Length : 8 bits
The TunnelID Length Field specifies the length of the TunnelID
field, in 4 octet words.
TunDetail Length : 8 bits
The TunDetail Length Field specifies the length of the TunDetail
field, in 4 octet words.
MTU : 16 bits
The MTU field specifies tunnel MTU in octets.
Flags : 8 bits
bit 0 set: tunnel can decrement TTL
bit 1 set: tunnel ingress device copies upper layer TTL value to tunnel header
TunnelName Length : 8 bits
The TunnelName Length Field specifies the length of the TunnelName
field, in 4 octet words.
Tunnel Type : 8 bits
The Tunnel Type field identifies a tunnel type. Currently, the
following tunnel types are defined:
0 - IP-in-IP
1 - MPLS
2 - L2TPv2
3 - IPSEC
4 - L2TPv3
5 - GMPLS
Head-end IP Address : 32 bits
The Head-end IP Address field identifies the tunnel head-end by IP
address.
Tail-end IP Address : 32 bits
The Tail-end IP Address field identifies the tunnel tail-end by IP
address.
TunnelID : Variable Length
The TunnelID field identifies the tunnel by a unique identifier.
It can be 0 padded for word alignment.
Tunnel Details : Variable Length
The Tunnel Details field provides tunnel specific details (e.g.,
MPLS label values). It can be 0 padded for word alignment.
TunnelName : Variable Length
The TunnelName field identifies the tunnel by name. It can be 0
padded for word alignment.
All Unused bits must be set to 0.
5.2.13. The Context Object
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| // |
| // |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: The Context Object
Figure 14 depicts the Context Object. The Context Object provides a
context for the Source Object. It is required when the address
provided in the Source Object is to be interpreted within the context
of a VPN. Because the same device that provides the context object
interprets its meaning, the syntax of the context object need not be
standardized.
The following paragraphs describe each field that contributes to the
Context Object.
Type: 8 bits
The Type field specifies the type of the object that follows. For
the Context Object, the Type field is always equal to 11.
Length : 8 bits
The Length Field specifies the length of the object that follows,
in 4 octet words.
6. IANA Guidelines
IANA has assigned UDP port 3693 to GTTP.
7. Security Considerations
The following are security considerations:
1) GTTP MUST enforce access control policy before disclosing any
information.
2) GTTP entities should rate limit messages that they send and
receive.
8. Normative References
[RFC-2026], Bradner, S., "Internet Standards Process Revision 3", RFC
2026, Harvard University, October 1996.
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997
[RFC-2151], Kessler, G., Shepard, S., A Primer On Internet and TCP/IP
Tools and Utilities, RFC 2151, Hill Associates, Inc., June 1997
[RFC-2328], Moy, J., OSPF Version 2, April, 1998.
[RFC-2434] T. Narten and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October, 1998.
[RFC-2637] Hamzeh, K. et. al., "Point-to-Point Tunneling Protocol
(PPTP)", RFC 2637, July, 1999.
[TUNREQ] Bonica, R., Kompella, K., Meyer, D., Tracing Requirements
for Generic Tunnels, draft-ietf-ccamp-tracereq-00, August 2002.
[LSP-PING] Kompella, K. et al, "Detecting MPLS Data Plane Liveness",
draft-ietf-mpls-lsp-ping-01, October 2002.
9. Acknowledgements
Thanks to Randy Bush, Philip Matthews, Tricci So and Beth Alwin for
their comments.
10. Author's Addresses
Ronald P. Bonica
WorldCom
22001 Loudoun County Pkwy
Ashburn, Virginia, 20147
Phone: 703 886 1681
Email: ronald.p.bonica@wcom.com
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, Massachusetts, 01824
E-mail: erosen@cisco.com
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, California 94089
Email: kireeti@juniper.net
Dave Myers
Sprint E|Solutions
12502 Sunrise Valley Drive
Reston, Virginia 20191
Email: dmm@sprint.net
Rohit Dube
Xebeo Communications Inc.
1 Cragwood Road, Suite 100
South Plainfield, NJ 07080
Email: rohit@xebeo.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
| PAFTECH AB 2003-2026 | 2026-04-23 12:57:41 |