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.