The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In the interest of making progress on this document, below are some
suggested addtions to draft-ietf-mpls-lsp-ping-01 to provide
clarification and reflect some of the conversations on the list.

I had some private conversations with Alia about the points she
brought up about TTL processing.  These are reflected below.

I intend this to be one of three parts.  I'm writing and sending them
in order of expected most baked and least controversial first.

The second is an addition at the end of the document to clarify how
traceroute mode works (only ping more is defined) and to very briefly
suggest how ping and traceroute can be used for path identification
(including MP), continuity testing, and in problem isolation.

The third is the revised protocol bits for MP.

In the interest of being as constructive as I could be, rather than
just complaining, I provided this as diffs to the existing draft.  I
did not incorporate Eric Gray's comments.  (Someone needs to
incorporate changes reflecting those comments or respond to Eric).

Curtis

ps - If no controversy errupts, the second part will follow shortly.


@@ -108,41 +108,59 @@
 
 
 
 
 
 Kompella et al               Standards Track                    [Page 2]
 
 Internet Draft     Detecting MPLS Data Plane Liveness       October 2002
 
 
 1. Introduction
 
-   This document describes a simple and efficient mechanism that can be
-   used to detect data plane failures in MPLS LSPs.  There are two parts
+   This document describes a mechanism that can be used to detect data
+   plane failures in MPLS LSPs.  The mechanisms described here are
+   intended to detect forwarding faults in an MPLS LSP which prevent
+   traffic from being delivered to its intended destination and
+   isolate the fault to the LSR at which traffic stops flowing.  No
+   attempt is made to determine that cause of the fault or diagnose
+   problems any further.  Enumeration of all possible fault types is
+   outside the scope of this document.
+
+   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.
 
+   Most persistent faults in transiting an LSP from ingress to egress
+   can be detected and isolated to one or two LSR.  Since MPLS-ping
+   "echo request" packets are injected no further upstream than the
+   ingress LSR, faults at the ingress related to classifying and
+   directing packets and encapsulating them for placement in the LSP
+   are not detected.  Since the MPLS-ping "echo request" packets are
+   extracted no further downstream than the egress LSR, faults at the
+   egress in decapsulating and directing traffic further are not
+   detected.
+
    To avoid potential Denial of Service attacks, it is recommended to
    regulate the MPLS ping traffic going to the control plane.  A rate
    limiter should be applied to the well-known UDP port defined 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].
 
 1.2. Changes since last revision
 
@@ -205,30 +223,111 @@
    determined as the path.
 
    One way these tools can be used is to periodically ping a FEC to
    ensure connectivity.  If the ping fails, one can then initiate a
    traceroute to determine where the fault lies.  One can also
    periodically traceroute FECs to verify that forwarding matches the
    control plane; however, this places a greater burden on transit LSRs
    and thus should be used with caution.
 
 
 
 
+2.1. Multipath Considerations
 
-
-
-
-
-
+   Multipath has been implemented in both IP based forwarding and in
+   MPLS.  The foundation for multipath in IP can be found in the
+   definition of ECMP for OSPF [OSPF].  Important consideration for
+   implementation of multipath and insights into behaviour of existing
+   implementations can be found in [MP-NH aka RFC2991].
+
+   For MPLS LSPs multipath may be encountered in one of the following
+   forms:
+
+      1.  IP traffic at an ingress LSR is put on multiple LSPs.  The
+          decision regarding a traffic split is made on the basis of
+          information in the IP header exactly as it is done for OSPF
+          ECMP.
+
+      2.  An LSP splits traffic at one or more midpoints based on
+          labels beneath the top label.  Existing implementations may
+          use all labels in the stack in this decision, or impose a
+          fixed limit on the number of labels considered.
+
+      3.  An LSP may be known to contain IP traffic (either through
+          signaling or other means outside the scope of this
+          document).  For such an LSP traffic may split at one or more
+          midpoints based on IP header information exactly as it is
+          done for OSPF ECMP.
+
+      4.  Traffic may be spread over more than one resource (for
+          example: forwarding ASIC, switch fabric channel, external
+          link) where the component path needs to be exposed for a
+          thorough test.
+
+   Instances of each of the above applications of multipath are known
+   to be deployed.  Considerations are made which address the
+   requirements to identify all paths and test each path
+   independently.  
+
+   The analogous multipath diagnostic capability is not currently
+   provided by IP traceroute and ping.  The analogous control plane
+   trace is available for IP through the technique known as MIB
+   traceroute.  The ability to verify forwarding on all paths is
+   provided for IP by using test traffic random destinations and using
+   the record route option to determine that all paths have been
+   exercised.  Service providers are aware of these techniques and
+   make use of them.
+
+
+2.2. TTL Processing during Forwarding
+
+   Three forms of TTL processing for MPLS LSR is specified in
+   [draft-ietf-mpls-ttl-04], Uniform, Pipe, and Short Pipe.  The
+   Uniform Model corresponds to TTL processing specified in RFC3032.
+
+   Like IP traceroute, for MPLS traceroute the ingress sends test
+   traffic with an initial TTL of one and increases TTL to acquire
+   path information.  Unlike IP traceroute, MPLS traceroute may have
+   to work with a label stack.
+
+   The method of TTL processing will not affect tracing the path of
+   the top label, if the LSP does not traverse a hierarchical hop as
+   defined in [draft-ietf-mpls-lsp-hierarchy-08] or otherwise enter an
+   outer LSP as would occur when LDP takes a directed hop through an
+   MPLS RSVP-TE LSP.  For a given hierarchical hop, if the ingress LSR
+   for the inner LSP under test is not the ingress of the outer LSP,
+   then testability will be limited if the Pipe Model is used.  
+
+   For hierarchical LSPs where the outer LSP uses Pipe Mode, if the
+   outer (upper) TTL is copied from the inner TTL, then the outer LSP
+   will be traced but a number of inner LSP hops (the LSP actually
+   under test) will not be traceable.  If the outer TTL is
+   independently set to a high initial number, then the outer LSP will
+   not be traced but instead will appear as a single hop.  The latter
+   case is known to be the more common.  If the Uniform Model is used,
+   then all hops of the outer and inner LSP will appear in the trace.
+
+   When the LSP being tested represents an inner label in the label
+   stack and this LSP and an upper LSP both terminate at the same LSR,
+   processing of the S bit on the inner LSP at the egress LSR may
+   require change.  For pseudo-wire [ccc, martinni, PW?] and virtual
+   private network services [BGPVPN] this label is normally popped and
+   the packet underneath is forwarded uniterpreted to an outgoing
+   interface.  The presence of another label (absense of the "S" or
+   "bottom of stack" bit) should suppress this delivery and instead
+   cause inspection of the next label in the stack.  If the egress is
+   configured to implement Pipe Mode TTL processing, the TTL of the
+   lower label will not expire premempting this forwarding.
+ 
 
 
 Kompella et al               Standards Track                    [Page 4]
 
 Internet Draft     Detecting MPLS Data Plane Liveness       October 2002
 
 
 3. Packet Format
 
    An MPLS echo request is a (possibly labelled) UDP packet; the
    contents of the UDP packet have the following format: