Re: Timing of the upstream data path establishment

["Adrian Farrel" <afarrel@movaz.com>]

Adam,
I should refer you to the archive on this point which has been discussed before.

The drafts state that the reverse direction (tail to head) reservation and
programming must be completed before the Path/Label Request can be forwarded,
but this, I believe, ignored by many people.

The bottom line was that it is solely an issue for the tail end (aka egress) to
decide when to start sending data.  There are many approaches that it can take
to determine this and, as you point out, requesting ResvConf is a good one.
Another is to 'know' that the network has behaved as specified in the draft
(either by increasing the latency or by having speedy hardware).

A further choice is for the tail end to wait a period of time before sending
data.  If all nodes in the network come from the same supplier, they will take
roughly the same time to program so once the tail end is programmed, all the
others should be ready.

The tail could even wait until it sees light on the forward path before turning
on the reverse path.

Your third option (add RESV_CONFIRM to Path if you believe your node's hardware
programming may be too slow) is an interesting flag that might interest SPs when
they're buying equipment. "Look," it says, "this hardware takes a long time to
program, and everyone else needs to adapt to it."

Finally, perhaps you could suggest how this would be applied to CR-LDP.

Have fun,
Adrian
--
Adrian Farrel
Movaz Networks Inc.
afarrel@movaz.com
----- Original Message -----
From: "Adam Shepherd" <AS@dataconnection.com>
To: <ccamp@ops.ietf.org>; <mpls@uu.net>
Sent: Wednesday, May 23, 2001 10:05 AM
Subject: Timing of the upstream data path establishment


> Hi all
>
> We have been considering some issues regarding the timing of the
> establishment of the reverse direction data path for bidirectional LSPs in
> RSVP GMPLS.  We would be interested in input from the mailing list on
> whether these problems are significant, and if so, whether there is a strong
> enough case for modifying the drafts at this stage.
>
> The key factor is whether bidirectional LSP establishment is a 2-way
> handshake (Path, Resv), as currently, or a 3-way one (Path, Resv and
> mandatory ResvConf).  We believe that the 3-way handshake, as used in the
> OIF OUNI, potentially offers significant reductions in latency of
> establishing bidirectional LSPs for LSRs where hardware programming is slow.
> The motivation here is the same as for Suggested Label (described in
> draft-ietf-mpls-generalized-signaling section 3.4).
>
> 2-way handshake
> ---------------
>
> With 2-way handshaking, the egress LSR can send reverse direction data as
> soon as it receives the Path (as in GMPLS
> draft-ietf-mpls-generalized-rsvp-te, section 3.1, paragraph 4).  Transit
> LSRs must program the reverse direction data path before forwarding the Path
> across the network or there is a risk that reverse direction data will be
> lost.  ResvConf is optional, and if sent it does not affect the timing of
> the setup of the data path.
>
> The benefits of this are as follows.
>
> * If the significant factor in latency is message propagation, then
> the latency for establishment of the reverse direction data path is one
> third as long as 3-way handshaking (the time taken for the Path message to
> cross the network, rather than Path, Resv, ResvConf).  Arguably, reverse
> direction latency is less important than downstream - the initiating LSR is
> the one that triggered the LSP establishment, so is more likely to have the
> immediate requirement to send data.
>
> * Less signaling traffic and less processing required.  However
> ResvConf processing is probably not a very large proportion of overall load.
>
> 3-way handshake
> ---------------
>
> In this approach, ResvConf becomes mandatory for bidirectional LSPs, and the
> egress LSR cannot send reverse direction data until it has received this
> message (those familiar with the OIF OUNI will note this matches
> oif2000-125.4 Section 12.4.8, figure 12.1).  Transit LSRs may forward the
> Path message before completing reverse direction data path programming.
>
> The advantage of 3-way handshaking is as follows.  If hardware programming
> is the significant factor in latency, then latency is significantly reduced
> as we can parallelize hardware programming at each LSR.  Each LSR can start
> programming on receipt of the Path message (based on the Upstream Label and
> Suggested Label), but forward the message immediately.  The total latency is
> dominated by the maximum of each LSR's programming latency, rather than the
> sum.
>
> Dynamic selection
> -----------------
>
> As a third option, we propose a possible solution to support either 2-way or
> 3-way handshaking in RSVP GMPLS, at the choice of the LSRs involved.  By
> default, 2-way handshaking is used.  However, any LSR can delay programming,
> in which case, the egress LSR must be informed that a 3-way handshake is
> required.  The requirement for 3-way handshaking must be indicated in the
> Path message, and we propose using a RESV_CONFIRM object on the Path message
> to do so.
>
> In more detail, this works as follows.
>
> * Any ingress or transit LSR MAY elect to enable 3-way handshaking and
> forward the Path message before completing programming of the reverse
> direction data path.  Typically it would do so because hardware programming
> is slow.  If it elects to do so, it MUST add a RESV_CONFIRM object to the
> Path message.
>
> * A transit LSR receiving a Path message with a RESV_CONFIRM object
> SHOULD forward the Path message before completing programming of the reverse
> direction data path.  However it MAY choose not to do so.
>
> * An egress LSR receiving a Path message with a RESV_CONFIRM object
> SHOULD include its own RESV_CONFIRM object in the Resv and it SHOULD NOT
> start to send reverse direction data until it receives the ResvConf message.
> (If it does send sooner, then data may be lost).
>
> * Each LSR MUST complete programming of both directions before
> forwarding the Resv message.
>
> Moving Forward
> --------------
>
> We would be interested to get feedback from readers of this list on which
> option is preferred.  If it is felt that dynamic selection is best, then is
> the solution we have proposed suitable?
>
> Regards,
> Adam
>
>
> Adam Shepherd
> Network Convergence Group
> Data Connection Ltd
> -------------------
>
> Tel: +44 (0) 20 8366 1177                Fax: +44 (0) 20 8363 1468
> Email: adam.shepherd@dataconnection.com  Web: http://www.dataconnection.com
>