The MPLS WG Archive

[Eric Rosen <erosen@cisco.com>]

Having now been convinced of the  need to have the echo response travel back
along the path  of label distribution, piggybacking it  on the control plane
messages  does  seem  to  make  sense.   The alternative  is  to  devise  an
independent transport  method which follows the control  plane reverse path.
This  is probably  more complicated,  given that  we have  only  two control
planes.

So here's my  off-the-cuff suggestion for doing the same  kind of thing with
LDP.  

The LSP-ping message  should be able to carry an  echo object which contains
(a) an  identifier of  the ingress,  and (b) an  LDP FEC  TLV.  (And  also a
sequence number,  I think, to aid  in matching responses  to requests.)  The
LDP FEC  TLV is the one  corresponding to the  LSP on which the  LSP-ping is
being sent.

When the LSP-ping message reaches  the egress, the echo object is extracted,
and given to LDP to be treated as an attribute (TLV) of the FEC it contains.
The egress then  sends a label mapping message for  that FEC, containing the
echo object.  This should  be sent to each LDP peer to  which the egress has
previously distributed  a label  (most likely the  implicit NULL  label) for
that FEC.  The egress then forgets about the response TLV.

When a  label mapping  message for  a particular FEC  is received,  and that
message contains an echo response TLV, then:

- if the  mapping message is not  from the next  hop for that FEC,  the echo
  response TLV is ignored;

- if the mapping message IS from the next hop for that FEC, 

  * if the  LSR is not the ingress  node identified in the  echo object, the
    LSR  sends a label  mapping message  for that  FEC, containing  the echo
    object, to each LDP peer to  which it has previously distributed a label
    for that FEC  (except the one from which it  received this message); the
    LSR then forgets about the TLV. 

  * if the LSR is the ingress node identified in the echo object, it matches
    the echo object  up to a particular LSP-ping and  treats the LSP-ping as
    having been properly responded to.

This procedure  is little different than  the procedure used to  pass up the
MTU or path vector TLVs upstream.   As in the RSVP-TE scheme, if the control
plane is operating properly, the TLV will make it upstream properly. 

This works  fine in the  multipoint-to-point case, at  least as long  as one
isn't pinging an egress from several  ingresses at once.  To handle the case
where there  are multiple outstanding  pings (from different  ingresses), we
either need to allow multiple echo  TLVs in a mapping message, or perhaps we
only need to define which of several  echo TLVs is the one which gets passed
upstream.