The MPLS WG Archive

[Ping Pan <pingpan@juniper.net>]

Ravi,

This is one of the many solutions we had talked about before. See below.

Ravi Shekhar wrote:
> 
>   That seems to be the right way to me. One possible way to achieve this is
>   as a 4 step process - first 2 to gather the hop-by-hop path from ingress to
>   egress node and the next 2 to do the ping on LSP:
> 
>    1) Initiate a UDP packet at ingress and send it to the next hop for the LSP to
>       be traced (i.e. destination IP address is the address of the next hop for
>       LSP and not the egress address itself).
>       Have enough information (like ingress router/egress router address/label)
>       in the UDP packet to uniquely identify the LSP.
>       Every hop(including ingress/egress) on the way appends its hop information
>       and sends this packet to the next hop of the LSP.
>    2) When this UDP packet reaches egress, egress sends it back to the ingress
>       hop-by-hop in the reverse order of the way path was traced(and recorded in
>       the packet) in step 1. Sending it this way ensures that it reaches the
>       ingress.

In RSVP-TE, this is the RRO object. For RSVP, you can even skip this two
steps.

>    3) At this point ingress has the elaborated hop-by-hop path for the LSP from
>       ingress to egress. It now generates a UDP packet at ingress with the
>       destination address of the egress. Since the UDP packet's destination is
>       egress node, it should traverse the LSP now. Inside the UDP packet fill in
>       the path that was traced in step 1 (and received by ingress in step 2).
>    4) If egress receives the UDP packet sent in step 3 via LSP, it can use the
>       hop-by-hop information contained in the packet and send a response back
>       hop-by-hop to the ingress (the same way it sent it back in step 2).
> 
>    This should work independent of the protocol that sets up the LSP (and across
>    multiple protocols). Since a unique return path for response is already
>    recorded while traversing in the forward direction of LSP (i.e. from ingress
>    to egress) in step 1, it would work for LDP too where same label might have
>    been handed over to multiple upstreams.
>

Yep! This is all nice, but it is *not* backward compatible. In a network
that has many routers, if one of them does not support this, the test
will fail.

Also this is a self supply-demand condition: with one implementation bug
on one of the LSR's, a whole bunch of LSP's may get torn down. So your
approach is best to debug own bugs. :-)

See, the LSP-ping proposal works, because it is based on the assumption:
the only working path from egress to ingress is the control path itself.
It is simple (no extra signaling other than adding one object) and
backward compatible (no change to the network LSR's).

- Ping