The MPLS WG Archive

[Sanjay Wadhwa <swadhwa01@yahoo.com>]

It is hard to disagress that a signalling independent solution in the
long run is a good thing. draft-pan-lsp-ping-00.txt is a simple,
backward compatible solution that will work currently for an RSVP-TE
core. I think as a solution for RSVP-TE it has merits by virtue of it's
simplicity and ease of deployment.

Thinking about the following "generic" solution (which looks to be
built upon various suggestions by various folks on the list) in context
of an LSP setup using LDP :

This four step process has a substantial window between the time the
forward path is discovered by the ingress and egress and it is actually

used for the echo-response in the reverse direction. During this time
routing could have changed and the forward LSP could be taking a
different path. So, the step 4 is not as simple as sending the response
hop-by-hop exactly according to the path information contained in the
echo-response. A next-hop indicated there could now no longer directly
attached to the intermediate node due to a routing change. What do you
do in this case ? Do a routing lookup towards that hop. But then you
are back to relying on unicast routing in the reverse direction as
opposed to exactly using the forward path used by the forward LSP, and
I think this is something we want to avoid in the first place. 
Also, with un-converged routing step 4 could result in a loop which
would cause the echo-response to be dropped. And the ingress could
mistakenly then take down a valid LSP.

With rsvp loose hops or non-rsvp cloud or nested tunnels a similar
situation can arise. But there tying it's fate to the RESV is the key.

Cheers..
-Sanjay


--- Ravi Shekhar <ravi_shekhar007@yahoo.com> wrote:
> > So then  I think then the base  requirement for the routing  of the
> response
> > from the  egress is that it  be reverse-path-forwarded back  to the
> ingress,
> > i.e., that it follow the path of label distribution from egress to
> ingress. 
> 
> 
>   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.
>    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.
> 
>    Some other useful information can also be gathered. Like protocol
> that set up
>    the LSP on each hop interface / timestamp and
> number-of-packets-forwarded-on
>    -the-LSP in steps 2 and 4 to calculate the rate of forwarding on
> LSP etc. 
>    
>    Maximum number of hops to be traced can be specified by the
> ingress (and
>    decremented at each hop) to prevent looping of message in step 1
> forever.
>    Indication of failure of LSP or reaching maximum number of hops at
> any hop 
>    can be put in the UDP packet and sent back to ingress in step 2.
>  
>    - Ravi Shekhar.
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/