RE: Timing of the upstream data path establishment

[John Drake <jdrake@calient.net>]

Adam,

I don't think that this is an issue.  Suggested label allows a node to begin
to establish the forward direction as it progresses the Path message.  Since
it controls the labels in the reverse direction, it can also begin to
establish the reverse direction concurrently.

Thanks,

John
-----Original Message-----
From: Adam Shepherd [mailto:AS@dataconnection.com]
Sent: Wednesday, May 23, 2001 7:06 AM
To: ccamp@ops.ietf.org; mpls@uu.net
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