datatracker.ietf.org
Sign in
Version 5.6.3, 2014-09-19
Report a bug

Tracing Requirements for Generic Tunnels
RFC 3609

Document type: RFC - Informational (October 2003; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3609 (Informational)
Responsible AD: Bert Wijnen
IESG Note: Published as RFC3609
Send notices to: <ronald.p.bonica@mci.com>, <kireeti@juniper.net>

Network Working Group                                          R. Bonica
Request for Comments: 3609                                           MCI
Category: Informational                                      K. Kompella
                                                        Juniper Networks
                                                                D. Meyer
                                                                  Sprint
                                                          September 2003

                Tracing Requirements for Generic Tunnels

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   This document specifies requirements for a generic route-tracing
   application.  It also specifies requirements for a protocol that will
   support that application.  Network operators will use the generic
   route-tracing application to verify proper operation of the IP
   forwarding plane.  They will also use the application to discover
   details regarding tunnels that support IP forwarding.

   The generic route-tracing application, specified herein, supports a
   superset of the functionality that "traceroute" currently offers.
   Like traceroute, the generic route-tracing application can discover
   the forwarding path between two interfaces that are contained by an
   IP network.  Unlike traceroute, this application can reveal details
   regarding tunnels that support the IP forwarding path.

1.  Introduction

   IP networks utilize several tunneling technologies.  Although these
   tunneling technologies provide operators with many useful features,
   they also present management challenges.  Network operators require a
   generic route-tracing application that they can use to verify the
   correct operation of the IP forwarding plane.  The generic
   route-tracing application must be capable of detecting tunnels and
   revealing tunnel details.  The application also must be useful in
   diagnosing tunnel faults.

Bonica, et al.               Informational                      [Page 1]
RFC 3609        Tracing Requirements for Generic Tunnels  September 2003

   Implementors also require a new protocol that will support the
   generic-route tracing application.  This document specifies
   requirements for that protocol.  It specifies requirements,
   primarily, by detailing the desired capabilities of the generic
   route-tracing application.  A particular version of generic
   route-tracing application may implement some subset of the desired
   capabilities.  It may also implement a superset of those
   capabilities.  However, protocol designers are not required to
   consider the additional capabilities when designing the new protocol.

   This document also specifies a few protocol requirements, stated as
   such.  These requirements are driven by desired characteristics of
   the generic route-tracing application.  Whenever a protocol
   requirement is stated, it is mapped to the desired characteristic of
   the route-tracing application.

2.  Review of Existing Functionality

   Currently, network operators use "traceroute" to trace through the
   forwarding path of an IP network.  Section 3.4 of [RFC-2151] provides
   a thorough description of traceroute.  Although traceroute is very
   reliable and very widely deployed, it is deficient with regard to
   tunnel tracing.

   Depending upon tunnel type, traceroute may display an entire tunnel
   as a single IP hop, or it may display the tunnel as a collection of
   IP hops, without indicating that they are part of a tunnel.

   For example, assume that engineers deploy an IP tunnel in an IP
   network.  Assume also that they configure the tunnel so that the
   ingress router does not copy the TTL value from the inner IP header
   to outer IP header.  Instead, the ingress router always sets the
   outer TTL value to its maximum permitted value.  When engineers trace
   through the network, traceroute will always display the tunnel as a
   single IP hop, hiding all components except the egress interface.

   Now assume that engineers deploy an MPLS LSP in an IP network.
   Assume also that engineers configure the MPLS LSP so that the ingress
   router propagates the TTL value from the IP header to the MPLS
   header.  When engineers trace through the network, traceroute will
   display the LSP as a series of IP hops, without indicating that they
   are part of a tunnel.

Bonica, et al.               Informational                      [Page 2]
RFC 3609        Tracing Requirements for Generic Tunnels  September 2003

[include full document text]