Internet Draft                                                R. Bonica
Expiration Date: January 2002                                  WorldCom
                                                               E. Rosen
                                                          Cisco Systems
                                                            K. Kompella
                                                       Juniper Networks
                                                               D. Meyer
                                                                 Sprint
                                                                 R.Dube
                                                   Xebeo Communications
                                                              July 2001

          Generic Tunnel Tracing Protocol (GTTP) Specification
                      draft-bonica-tunproto-01.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 through an IP
   network's forwarding plane (including the MPLS forwarding plane).
   Enhanced route-tracing applications also reveal details regarding IP
   and MPLS tunnels that contribute to the traced path.


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 through an IP
   network's forwarding plane (including the MPLS forwarding plane).
   Enhanced route-tracing applications also reveal details regarding IP
   and MPLS tunnels that contribute to traced path. A companion document
   [TUNREQ] specifies requirements for enhanced route-tracing
   applications.

   Each section of this document presents a significant aspect of GTTP.
   This section describes the generic tunnel-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). A
   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 (TLH) .
   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.



4.2. Informal Protocol Description

   GTTP supports two PDU types. These PDUs represent a TraceProbe and a
   TraceResponse. Route-tracing applications emit a series of
   TraceProbes in order to obtain information regarding the path that
   connects two network interfaces. Specifically, route-tracing
   applications emit one TraceProbe to discover each hop that
   contributes to the traced path.

   Each TraceProbe elicits exactly one TraceResponse. Each TraceResponse
   reveals details concerning one hop that contributes to the traced
   path. That hop may represent a TLH or part of a subordinate tunnel.

   The User Datagram Protocol (UDP) carries all GTTP traffic. IANA will
   assign a UDP port to GTTP. Route-tracing applications will direct all
   TraceProbes to this well-known port and network elements will listen
   for GTTP traffic on this well-know port only. Route-tracing
   applications will listen for TraceResponses on a non-well-known port
   that they will specify in the corresponding TraceProbe's UDP source
   address.

   UDP obtains network layer services from IP. IP datagrams that carry
   GTTP MUST NOT specify IP options.


4.3. Discovering the Top-Level Path

   In the example above, the route-tracing application sends one
   TraceProbe to discover H1, another TraceProbe to discover H2, and a
   third TraceProbe to discover H3. Each TraceProbe elicits a single
   TraceResponse and each TraceResponse provides details regarding a
   single TLH.

   The application sends its first TraceProbe to D1, in order to
   discover H1. The TraceProbe contains the following information:

      1) The IP address of the route-tracing application

      2) A Sequence Number, used to match TraceProbes with
      TraceResponses

      3) An IP address that identifies the head-end of the traced path
      (i.e., D1's loopback address)

      4) A Path Identifier Object (PIO). In its simplest form, the Path
      Identifier Object identifies the traced path by its destination
      address (i.e., D4's loopback address). In  a more complex form,
      the PIO identifies the traced path based upon an incoming
      interface (or sub-interface), a tunnel header (e.g. MPLS header),
      and an IP header.

      5) A TLH Identifier. The TLH identifier identifies the TLH about
      which the application is requesting information. In this case, the
      value "1" represents the first TLH (i.e., H1).

      6) A Tunnel Hop Identifier. As this probe solicits TLH details,
      this value is equal to zero.

      7) An optional Access Control Object (ACO)



   D1 receives the TraceProbe, removes its IP and UDP headers, and
   delivers it to a local GTTP module. The GTTP module examines the
   TraceProbe ACO in order to determine whether local security policy
   permits it to process the probe. If security policy does not permit
   the GTTP module to service the probe, D1 can either silently discard
   the TraceProbe or send D0 a TraceResponse, indicating insufficient
   privilege, as per local security policy.

   If security policy permits the GTTP module to process the probe, the
   GTTP module examines the TraceProbe and determines that it is
   soliciting details regarding a downstream TLH. Therefore, the GTTP
   module relays the TraceProbe downstream. First, if required by PIO
   size specifications, the GTTP module pads the TraceProbe. Next, the
   GTTP module encapsulates the TraceProbe in a UDP header.

   The GTTP module then encapsulates the UDP packet in an IP header. The
   IP header contains information specified by the original TraceProbe's
   PIO. The GTTP module then copies the original TraceProbe's TLH
   Identifier to the IP header TTL field and recalculates the IP header
   checksum. D1 then forwards the TraceProbe downstream as per all PIO
   specifications. (Note that the Layer 2 interface and tunnel upon
   which a datagram might arrive can contribute to PIO specifications.)

   In our example, D1 forwards the TraceProbe through H1 to D2. D2
   decrements the TTL value to 0 and forwards the datagram to an error-
   processing module. The error-processing module sends an ICMP Time
   Expired Message to D1. D1 discards this ICMP message.

   The error-processing module then forwards the TraceProbe to a local
   GTTP module. The GTTP module examines the TraceProbe ACO in order to
   determine whether local security policy permits it to process the
   probe. If security policy does not permit the GTTP module to service
   the probe, the GTTP module silently discards the TraceProbe.

   If security policy permits the GTTP module to process the probe, the
   GTTP module examines the TraceProbe and determines that it is
   soliciting details regarding a directly connected, upstream TLH.
   Therefore, D2 sends D0 a TraceResponse. The TraceResponse contains
   the following information:

      1) The IP address of the route-tracing application

      2) A Sequence Number, used to match TraceProbes with TraceRespones

      3) An IP address identifying the interface upon which the
      TraceProbe arrived. If the TraceProbe arrived on an unnumbered
      interface, this IP address will not uniquely identify the
      interface upon which the TraceProbe arrived

      4) The MIB-II ifDescr value associated with the interface upon
      which the TraceProbe arrived. This value, in conjunction with the
      IP address mentioned above, SHOULD uniquely identify the interface
      upon which the datagram arrived.

      5) A Tunnel Security Status (TSS). This value indicates whether
      local security policy permits GTTP to reveal tunnel details.

      6) A Tunnel Identifier Object (TIO). The TraceResponse contains a
      TIO if security policy permits GTTP to reveal tunnel details and
      if the TraceProbe was encapsulated in a tunnel header when it
      arrived at the probed node.

      The TIO contains several data items. One data item represents the
      type of the outermost tunnel (e.g., IP-in-IP, MPLS). Another data
      item represents the entire tunnel header stack, as it encapsulated
      the TraceProbe when it arrived at the probed network element.
      Another data item represents a tunnel identifier that is shared
      between the tunnel ingress and tunnel egress nodes. (This data
      item is empty when the tunneling mechanism does not support such a
      shared identifier).

      7) Egress Indicator. This field indicates whether the
      TraceResponse was sent by the tail-end of the traced path. The
      GTTP module sets this Egress Indicator if the tail-end of the
      traced path, as specified by the PIO, is a local interface.

      8) An Optional Access Control Object (ACO). This object is copied
      from the TraceProbe.


   D0 receives the TraceResponse and processes it if the ACO matches
   that which was sent in the corresponding TraceProbe. D0 repeats the
   procedure described above, incrementing the TLH identifier in order
   to discover each subsequent TLH. Specifically, D0 sends each
   TraceProbe to D1 and D1 probes the traced path. D0 repeats this
   process until it receives a TraceResponse from the tail-end of the
   traced path.

   Local policy determines how many times D0 should probe each hop. It
   also determines how long D0 should wait for a response to each probe
   and the maximum number of probes that D0 should send in order to
   trace a given path.

   In order to trace the top-level path accurately, D2 must be
   configured so that it sets TTL value specified by the outer header of
   its IP-in-IP tunnel to an appropriately high value.


4.4. Discovering First Order Tunnel Details

   At this point, the network has revealed details regarding H1, H2 and
   H3. D3 also has provided cursory information regarding the IP-in-IP
   tunnel that supports H2. D2 and D4, however, have provided no
   information regarding tunnels that might support H1 and H3.

   Even though D2 and D4 returned a TraceProbe that did not include a
   TIO, tunnels may support H1 and H3. For example, an MPLS LSP that
   engages in penultimate hop popping may support H1. In this case, a
   TraceProbe would arrive at D2 without an MPLS header and D2 would
   return a TraceResponse that does not include a TIO.

   Therefore, the route-tracing application must probe D1, D2 and D3 for
   details regarding tunnels that might support H1, H2 and H3,
   respectively. The route-tracing application begins by sending a
   TraceProbe to D1. The TraceProbe contains the following information:

      1) The IP address of the route-tracing application

      2) A Sequence Number, used to match TraceProbes with
      TraceResponses

      3) An IP address that identifies the head-end of the traced tunnel
      (i.e., D1's loopback address)

      4) A Path Identifier Object (PIO). This PIO contains values
      identical to those that were sent to D1 while tracing the top-
      level path.

      5) A TLH Identifier. As this TraceProbe solicits tunnel details,
      the TLH identifier is equal to zero.

      6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a
      tunnel hop about which the current TraceProbe is soliciting
      details. In this case, a value of 1 represents the first hop in a
      tunnel that might support H1.

      7) An optional Access Control Object (ACO)


   D1 receives the TraceProbe, removes its IP and UDP headers, and
   delivers it to a local GTTP module. The GTTP module examines the
   TraceProbe ACO in order to determine whether local security policy
   permits it to process the probe. If security policy does not permit
   the GTTP module to service the probe, the D1 can either silently
   discard the TraceProbe or send D0 a TraceResponse, indicating
   insufficient privilege, as per local security policy.

   If security policy permits the GTTP module to process the probe, the
   GTTP module examines the TraceProbe and determines that it is
   soliciting details regarding the first hop of a particular downstream
   tunnel. (The GTTP module makes this determination based upon the
   Tunnel Hop Identifier value). Therefore, D1 queries its routing
   information and determines that no tunnel supports H1. Having made
   this determination, D1 sends D0 a TraceResponse message that does not
   include a TIO.

   D0 receives the TraceResponse and processes it if the ACO matches
   that which was sent in the corresponding TraceProbe. Having processed
   this TraceResponse, D0 is informed that no tunnel supports H1.

   D0 now probes D2, soliciting details concerning the tunnel that
   supports H2. Specifically, D0 sends D2 a TraceProbe. The TraceProbe
   contains the following information:

      1) The IP address of the route-tracing application

      2) A Sequence Number, used to match TraceProbes with
      TraceResponses

      3) An IP address that identifies the head-end of the traced tunnel
      (i.e., D2's loopback address)

      4) A Path Identifier Object (PIO). The PIO contains the same IP
      header that all previously mentioned PIOs contained. The route-
      tracing application augments this information information that was
      obtained from D2 while discovering the top-level path. For
      example, while discovering the top-level path, the the route-
      tracing application learned that D2 received its TraceProbe from a
      particular sub-interface. The route-tracing application specifies
      this sub-interface in the PIO when probing D2 for H2 tunnel
      details.

      5) A TLH Identifier. As this TraceProbe solicits tunnel details,
      the TLH identifier is equal to zero.

      6) A Tunnel Hop Identifier. The Tunnel Hop Identifier represents a
      tunnel hop about which the current TraceProbe is soliciting
      details. In this case, a value of 1 represents the first hop in a
      tunnel that might support H2.

      7) An optional Access Control Object (ACO)


   D2 receives the TraceProbe, removes its IP and UDP headers, and
   delivers it to a local GTTP module. The GTTP module examines the
   TraceProbe ACO in order to determine whether local security policy
   permits it to process the probe. If security policy does not permit
   the GTTP module to service the probe, the D2 can either silently
   discard the TraceProbe or send D0 a TraceResponse, indicating
   insufficient privilege, as per local security policy.

   If security policy permits the GTTP module to process the probe, the
   GTTP module examines the TraceProbe and determines that it is
   soliciting details regarding the first hop of a particular downstream
   tunnel. (The GTTP module makes this determination based upon the
   Tunnel Hop Identifier value). Therefore, D2 queries its routing
   information and determines that an IP-in-IP tunnel supports H2.

   D2 then executes a tunnel specific tracing procedure. In this
   particular case, D2 encapsulates the TraceProbe in a UDP header. It
   then encapsulates the UDP packet in the IP header that is specified
   by the PIO. It sets the IP TTL value to 1 and recalculates the
   checksum. Finally, D2 encapsulates the IP header in another IP
   header. The outer IP header represents the IP-in-IP tunnel. Its
   source address represents the tunnel ingress and its destination
   address represents the tunnel egress. D2 copies the Tunnel Hop
   Identifier to the outer header TTL field and recalculates the outer
   checksum. Finally, D2 forwards the encapsulated TraceProbe.

   In our example, D2 forwards the TraceProbe through H2:1 to D5. D5
   decrements the outer TTL value to 0 and forwards the datagram to an
   error-processing module. The error-processing module sends an ICMP
   Time Expired Message to D2. D2 discards this ICMP message.

   The error-processing module then forwards the TraceProbe to a local
   GTTP module. The GTTP module examines the TraceProbe ACO in order to
   determine whether local security policy permits it to process the
   probe. If security policy does not permit the GTTP module to service
   the probe, the GTTP module silently discards the TraceProbe.

   If security policy permits the GTTP module to process the probe, the
   GTTP module examines the TraceProbe and determines that it is
   soliciting details regarding a directly connected, upstream tunnel
   hop. Therefore, D5 sends D2 a TraceResponse. The TraceResponse
   contains the following information:

      1) The IP address of the route-tracing application

      2) A Sequence Number, used to match TraceProbes with TraceRespones

      3) An IP address identifying the interface upon which the
      TraceProbe arrived. If the TraceProbe arrived on an unnumbered
      interface, this IP address will not uniquely identify the
      interface upon which the TraceProbe arrived

      4) The MIB-II ifDescr value associated with the interface upon
      which the TraceProbe arrived. This value, in conjunction with the
      IP address mentioned above, SHOULD uniquely identify the interface
      upon which the datagram arrived.

      5) A Tunnel Security Status (TSS). This value indicates whether
      local security policy permits GTTP to reveal tunnel details.

      6) A Tunnel Identifier Object (TIO).  The TIO contains several
      data items. One data item represents the type of the outermost
      tunnel (i.e., IP-in-IP). Another data item represents the entire
      tunnel header stack, as it encapsulated the TraceProbe when it
      arrived at the probed network element. Another data item
      represents a tunnel identifier that is shared between the tunnel
      ingress and tunnel egress nodes. (In this case, the identifier is
      a 64 bit value, with the first 32 bits representing the IP address
      of the tunnel ingress and the remaining 32 bits representing the
      IP address of the tunnel egress).

      7) Egress Indicator. This field indicates whether the
      TraceResponse was sent by the tail-end of the traced tunnel. The
      GTTP module sets this Egress Indicator if the tail-end of the
      traced tunnel is a local interface.

      8) An Optional Access Control Object (ACO). This object is copied
      from the TraceProbe.


   D2 receives the TraceResponse and relays it to the route-tracing
   application on D0. Having processed this TraceResponse, the route-
   tracing application has acquired H2:1 details.

   The route-tracing application sends another TraceProbe to D2 in order
   to solicit details regarding the second hop of the tunnel that
   supports H2. In return, it receives a TraceResponse that describes
   H2:2. Next, the route-tracing application sends another TraceProbe to
   D2 in order to solicit details regarding the third hop of the tunnel
   that supports H2. In response, it receives a TraceResponse that
   describes H2:3. This TraceResponse indicates that H2:3 is the final
   hop of the tunnel that supports H2.

   Finally, the route-tracing application sends a TraceProbe to D3 in
   order to determine whether any tunnel supports H3. In return, the
   application receives a TraceResponse that does not contain a TIO.
   This TraceResponse indicates that no tunnel supports H3.

   Local policy determines how many times D0 should probe each tunnel
   hop. It also determines how long D0 should wait for a response to
   each probe and the maximum number of probes that D0 should send in
   order to trace a given tunnel.

   In order to trace the the IP-in-IP tunnel accurately, D5 must be
   configured so that it sets TTL value specified the MPLS header that
   supports H2:2 to an appropriately high value.







4.5. Discovering Order N Tunnel Details

   Now D0 probes D2, D5 and D6 in order to determine whether any tunnel
   supports H2:1, H2:2 or H2:3. D0 repeats the procedure described
   above, this time augmenting the PIO with information obtained while
   discovering first layer tunnels.


5. Protocol Mechanisms


5.1. Transport

   GTTP rides directly over UDP.


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     |            Checksum           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Application  Address                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Sequence Number          |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Head-end Address                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |    TLH ID     | Tunnel Hop ID |            Unused             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +      Optional Objects
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-

                          Figure 2: The TraceProbe Message


   Figure 2 depicts the TraceProbe Message. Applications send a
   TraceProbe in order to solicit details about 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.

   Checksum: 16 bits

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the GTTP message starting with the TraceProbe
      Version. For computing the checksum, the checksum field should be
      zero.

   Application Address: 32 bits

      The Application Address identifies the route-tracing application
      that originated the TraceProbe by IP address.

   Sequence Number: 16 bits

      Route-tracing applications use the Sequence Number to match
      TraceProbes with TraceResponses.

   Length: 16 bits

      The Length field specifies the length of the TraceProbe Message,
      beginning with the TraceProbe Version, in octets.

   Head-end Address: 32 bits

      The Head-end Address identifies the head-end of the traced path or
      tunnel.

   Top Level Hop (TLH) ID: 8 bits

      The Top Level Hop (TLD) ID identifies the TLH about which the
      TraceProbe is soliciting details. For example, when soliciting
      details regarding the first TLH that contributes to a path, the
      TLH ID should be equal to 1.

   Tunnel Hop ID: 8 bits

      The Tunnel Hop ID identifies the tunnel hop about which the
      TraceProbe is soliciting details. For example, when soliciting
      details regarding the first tunnel hop that contributes to a
      tunnel, the Tunnel Hop ID should be equal to 1.

   Optional Objects: Variable Length

      The ACO, PIO, and Padding Objects may be specified in the
      TraceProbe Message. The PIO is mandatory.

      Each optional object must begin on a 32 bit boundary. See the
      following subsections for optional object details.

   All Unused bits must be set to 0.


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 |    Flags      |            Checksum           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Application  Address                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |       Sequence Number         |            Length             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                   Arrival Interface Address                   |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |      Code     | ifDesc Length |            Unused             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                            ifDescr                            |
        |                              //                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        +    Optional Objects
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 3: The TraceResponse Message


   Figure 3 depicts the TraceResponse Message. Network elements send the
   TraceResponse Message in order to reveal details concerning a TLH or
   tunnel hop. 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.

   Flags: 8 bits

      The leftmost bit of the Flags field represents the Egress
      Indicator. The Egress Indicator bit is set if the path or tunnel
      egress device originated the TraceResponse.

      The second bit represents the Tunnel Security Status (TSS). The
      TSS bit is set if local security policy permits GTTP to reveal
      whether a tunnel supports the hop upon which the current
      TraceResponse reports.

      All unused bits MUST be cleared (i.e., set to zero).

   Checksum: 16 bits

      The checksum is the 16-bit ones's complement of the one's
      complement sum of the GTTP message starting with the TraceProbe
      Version. For computing the checksum, the checksum field should be
      zero.

   Application Address: 32 bits

      The Application Address identifies the route-tracing application
      that originated the corresponding TraceProbe by IP address.

   Sequence Number: 16 bits

      Route-traccing applications use the Sequence Number to match
      TraceProbes with TraceResponses.

   Length: 16 bits

      The Length field specifies the length of the TraceResponse
      Message, beginning with the TraceResponse Version, in octets.

   Arrival Interface Address: 32 bits

      The Arrival Interface Address identifies the interface upon which
      the corresponding TraceProbe arrived. If the corresponding
      TraceProbe arrived on an unnumbered interface, the Arrival
      Interface Address may not uniquely indentify the interface upon
      which the corresponding TraceProbe arrived.

   Code: 8 bits

      The Code represents an error code. The following values are
      defined:

         0 No Error

         1 Insufficient Privilege

         2 Malformed TraceProbe

         3 No such tunnel

         4 No route to destination

         5 Communication administratively prohibited

         6 Ambiguous PIO


   ifDescr Length: 8 bits

      The ifDescr Length specifies the number of significant bytes in
      the field.

   ifDescr: variable Length

      The ifDescr field identifies the interface upon which the
      corresponding TraceProbe arrived, by name. This value is taken
      from the MIB-II ifDesc object. This value, in conjunction with the
      Arrival Interface Address, uniquely identifies the interface upon
      which the corresponding TraceProbe arrived.

      The ifDescr field is zero padded for word alignment.

      Optional Objects: Variable Length

      The ACO and TIO objects may be specified in the TraceResponse
      Message.

      Each optional object must begin on a 32 bit boundary. See the
      following subsections for optional object details.





5.2.3. 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 4: The Access Control Object


   Figure 4 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 1.

   Length : 8 bits

      The Length Field specifies the length of the object that follows,
      in octets. For the Access Control Object, the value of the Length
      field is always equal to 12.

   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.4. The Path Identifier Object (PIO)

           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    | ifDesc Length |  Tun Hdr Len  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | IP Hdr Len    | Tunnel Type   |             Unused            |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Tunnel Ingress Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Tunnel Egress Address                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                          ifDescr                              |
        |                           //                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                    Tunnel Stack Header                        |
        |                           //                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                        IP Header                              |
        |                           //                                  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          Figure 5: Path Identifier Object


   Figure 5 depicts the Path Identifier Object (PIO). TraceProbe
   Messages use the PIO in order to identify a traced path.

   The following paragraphs describe each field that contributes to the
   PIO.

   Type: 8 bits

      The Type field specifies the type of the object that follows. For
      the PIO, the Type field is always equal to 2.

   Length : 8 bits

      The Length field specifies the object length, in octets.

   ifDescr Length: 8 bits

      The ifDescr Length field specifies the number of significant
      octets contained by the ifDescr field.


   Tunnel Header Length: 8 bits

      The Tunnel Header Length field specifies the number of significant
      octets contained by the Tunnel Header field.


   IP Header Length: 8 bits

      The IP Header Length field represents an IP header that might
      encapsulate a datagram.



   Tunnel Type: 8 bits

      The Tunnel Type field identifies the type of the outermost tunnel
      specified in the Tunnel Header. The following values are defined:

         0 Undefined

         1 GRE

         2 MPLS

         3 IPSEC

         4 IP Optical (IPO)

         5 Layer 2 Tunneling Protocol (L2TP)

         6 IP-in-IP

         7 UTI

   Tunnel Ingress Address: 32 bits

      When soliciting tunnel details, the Tunnel Ingress address
      identifies any interface that is local the the tunnel ingress
      node. When soliciting  TLH details, the Tunnel Ingress Address is
      meaningless.

   Tunnel Egress Address: 32 bits

      When soliciting tunnel details, the Tunnel Egress address
      identifies any interface that is local the the tunnel egress node.
      When soliciting  TLH details, the Tunnel Egress Address is
      meaningless.


   ifDescr : variable length

      The ifDescr Field identifies the interface or sub-interface upon
      which a datagram might arrive, by MIB-II ifDescr. The ifDescr
      field can be zero padded for word alignment. This field can be
      empty if the incoming interface does not contribute to the routing
      decision.

   Tunnel Header : variable length

      The Tunnel Header Field identifies a tunnel header that might
      encapsulate an incoming datagram. The Tunnel Header field can be
      zero padded for word alignment. This field can be empty if the
      incoming tunnel header does not contribute to the routing
      decision.


   IP Header : variable length

      The IP Header Field identifies a traced path. The Tunnel Type
      field can be zero padded for word alignment. The IP Header field
      can be zero padded for word alignment. This field must be
      specified.



5.2.5. The Tunnel Identification Object (TIO)

           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    |  Tunnel Type  | Tunnel ID Len |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Tun Hdr Len   |                  Unused                       |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Tunnel Ingress Address                    |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Tunnel Egress Address                     |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                           Tunnel ID                           |
        |                               //                              |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                     Tunnel Header Stack                       |
        |                              //                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                          Figure 6: The Tunnel Identification Object


   Figure 6 depicts the Tunnel Identification Object (TIO). The TIO
   object describes a tunnel upon which the probed network element
   received a TraceProbe.

   The following paragraphs describe each field that contributes to the
   TIO.


   Type: 8 bits

      The Type field specifies the type of the object that follows. For
      TIO, the Type field is always equal to 3.

   Length : 8 bits

      The Length Field specifies the length of the object that follows,
      in octets.

   Tunnel Type: 8 bits

      The Tunnel Type field identifies a tunnel type. The following
      values are defined:

         0 Undefined

         1 GRE

         2 MPLS

         3 IPSEC

         4 IP Optical (IPO)

         5 Layer 2 Tunneling Protocol (L2TP)

         6 IP-in-IP

         7 UTI

   Tunnel ID Length: 8 bits

      The Tunnel ID Length field specifies the number of significant
      bits in the Tunnel ID field.

   Tun Hdr Len: 8 bits

      This field represents the number of significant octets in the
      Tunnel Header Stack.

   Tunnel Ingress Address: 32 bits

      The Tunnel Ingress Address identifies the tunnel ingress, by IP
      address. The route-tracing application can send a TraceProbe
      Message to this address in order to obtain tunnel details. If the
      tail-end device cannot provide this information, it specifies the
      address 0.0.0.0.

   Tunnel Egress Address: 32 bits

   The Tunnel Egress address identifies the tunnel egress, by IP
   address. If the tail-end device cannot provide this information, it
   specifies the address 0.0.0.0.

   Tunnel ID: variable length

      The Tunnel ID field identifies the tunnel to its ingress device.
      The format of this field is determined by tunnel specific tracing
      procedures (defined below). This field is empty when the tunneling
      mechanism does not support such an identifier.

   Tunnel Header Stack: variable length

      This field represents the entire tunnel header stack, as it
      encapsulated the TraceProbe when it arrived at the probed node.


5.2.6. The Padding 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 7: The Padding Object

   Figure 7 depicts the Padding Object.  Route-tracing applications use
   the Padding object to extend a TraceProbe to the desired size. The
   following paragraphs describe each field that contributes to the
   Padding Object.

   Type: 8 bits

      The Type field specifies the type of the object that follows. For
      the Padding Object, the Type field is always equal to 4.

   Length : 8 bits

      The Length Field specifies the length of the object that follows,
      in octets. The length of the Padding Object must be a multiple of
      four.

   Unused: variable length

      Unused bits must be set to zero.





5.3. Message Processing


5.3.1. The TraceProbe Message

   Having received a TraceProbe Message, the GTTP module must examine
   TraceProbe's ACO in order to determine whether local security policy
   permits it to process the probe. If security policy does not permit
   the GTTP module to service the probe, the GTTP module can either
   silently discard the TraceProbe or send route-tracing application a
   TraceResponse, indicating insufficient privilege, as per local
   security policy.

   If local security policy permits the GTTP module to process the
   probe, the GTTP module must determine which of the following is true:

      1) The TraceProbe is soliciting details concerning a downstream
      TLH. This condition is true if the TLH Identifier is greater than
      zero and the head-end of the traced path is a local interface and
      the tail-end of the traced path is not a local interface.

      2) The TraceProbe is soliciting details concerning a directly
      connected upstream TLH. This condition is true if the TLH
      Identifier is greater than zero and the head-end of the traced
      path is a not local interface.

      3) The TraceProbe is soliciting details concerning a tunnel for
      which the local node serves as igress. This condition is true if
      the Tunnel Hop Identifier is greater than zero and the head-end of
      the traced tunnel is a local interface.

      4) The TraceProbe is soliciting details concerning a directly
      connected upstream tunnel hop. This condition is true if the
      Tunnel Hop Identifier is greater than zero and the head-end of the
      traced tunnel is not a local interface.

   If the first condition is true, the GTTP module relays the TraceProbe
   downstream. First, if required by PIO specifications, the GTTP module
   pads the TraceProbe Message. Next, the GTTP module encapsulates the
   TraceProbe Message in a UDP header.

   The GTTP module then encapsulates the UDP packet in an IP header. The
   IP header contains all of the information specified by the original
   TraceProbe's PIO. The GTTP module then copies the original
   TraceProbe's TLH Identifier to the IP header TTL field and
   recalculates the IP header checksum. The GTTP module then forwards
   the TraceProbe downstream as per all PIO specifications.

   If the second condition is true, the GTTP module formats a
   TraceResponse and sends it to the route-tracing application.

   If the third condition is true, GTTP executes a tunnel specific
   tracing procedure. The tunnel specific tracing procedure elicits a
   TraceResponse message that describes a hop of the traced tunnel.
   Tunnel specific tracing procedures are described in a later
   paragraph.

   If the fourth condition is true, the GTTP module formats a
   TraceResponse and sends it to the head-end of the traced tunnel.


5.3.2. The TraceResponse Message

   Having received a TraceResponse Message, the GTTP module examines the
   TraceResponse ACO in order to determine whether local security policy
   permits it to process the probe. If security policy does not permit
   the GTTP module to service the probe, the the GTTP module silently
   discards the TraceResponse.

   If security policy permits the GTTP module to process the response,
   the GTTP module relays the TraceResponse to the route-tracing
   application.


5.4. Tunnel Specific Tracing Proceedures

   The following subsections detail tunnel specific tracing procedures.


5.4.1. TTL Aware Tunnels

   The GTTP module encapsulates the TraceProbe in a UDP header. It then
   encapsulates the UDP packet in the IP header that is specified by the
   PIO. It sets the IP TTL value to 1 and recalculates the checksum.
   Finally, the GTTP module encapsulates the IP header in tunnel header
   (e.g., MPLS shim header). Finally, the GTTP module copies the Tunnel
   Hop Identifier to the tunnel header TTL field and recalculates the
   tunnel checksum (if required). Finally, the GTTP module forwards the
   encapsulated TraceProbe.


5.4.2. Other Tunnel Types

   TBD


6. IANA Guidelines

   IANA will assign a UDP port to GTTP [RFC-2434].


7. Security Considerations

   The following are security considerations:

      1) GTTP MUST enforce access control policy before disclosing any
      information.

      2) GTTP MUST NOT yield multiple TraceResponses in response to a
      single TraceProbe.

      3) When tracing through encrypted tunnels, GTTP must never deliver
      the cipher-text equivalent of user provided data.

      4) GTTP entities should rate limit messages that they send and
      receive.

      5) When the device at the head-end of a traced path generates a
      TraceProbe, it MUST identify a local address in that messages IP
      Source Address field.



8. 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-bonica-tunneltrace-02.txt, July 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.