1. Introduction

   This document describes a simple and efficient mechanism that can be
   used to detect data plane failures in MPLS Label Switched Paths
   (LSPs).  There are two parts to this document: information carried in
   an MPLS "echo request" and "echo reply", and mechanisms for
   transporting the echo reply.  The first part aims at providing enough
   information to check correct operation of the data plane, as well as
   a mechanism to verify the data plane against the control plane, and
   thereby localize faults.  The second part suggests two methods of
   reliable reply channels for the echo request message for more robust
   fault isolation.

   An important consideration in this design is that MPLS echo requests
   follow the same data path that normal MPLS packets would traverse.
   MPLS echo requests are meant primarily to validate the data plane,
   and secondarily to verify the data plane against the control plane.
   Mechanisms to check the control plane are valuable, but are not
   covered in this document.

   This document makes special use of the address range 127/8.  This is
   an exception to the behavior defined in RFC 1122std3 [RFC1122] and
   updates that RFC.  The motivation for this change and the details of
   this exceptional use are discussed in section 2.1 below.

1.1. Conventions

   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 [KEYWORDS].

   The term "Must Be Zero" (MBZ) is used in object descriptions for
   reserved fields.  These fields MUST be set to zero when sent and
   ignored on receipt.

   Terminology pertaining to L2 and L3 Virtual Private Networks (VPNs)
   is defined in [RFC4026].

   Since this document refers to the MPLS Time to Live (TTL) far more
   frequently than the IP TTL, the authors have chosen the convention of
   using the unqualified "TTL" to mean "MPLS TTL" and using "IP TTL" for
   the TTL value in the IP header.

1.2. Structure of This Document

   The body of this memo contains four main parts: motivation, MPLS echo
   request/reply packet format, LSP ping operation, and a reliable
   return path.  It is suggested that first-time readers skip the actual
   packet formats and read the Theory of Operation first; the document
   is structured the way it is to avoid forward references.

1.3. Contributors

   The following made vital contributions to all aspects of this
   document, and much of the material came out of debate and discussion
   among this group.

      Ronald P. Bonica, Juniper Networks, Inc.
      Dave Cooper, Global Crossing
      Ping Pan, Hammerhead Systems

      Nischal Sheth, Juniper Networks, Inc.
      Sanjay Wadhwa, Juniper Networks, Inc.