Subject: RE: Timing of the upstream data path establishment

From: John Drake <[email-masked]>
Date: Wed, 23 May 2001 08:50:33 -0700

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:[email-masked]]
Sent: Wednesday, May 23, 2001 7:06 AM
To: [email-masked]; [email-masked]
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: [email-masked]  Web: http://www.dataconnection.com

---

From: Guangzhi Li <[email-masked]>
Date: Wed, 23 May 2001 14:56:19 -0400

Adam:

I think it is a concern. When the egress node receives the Path message, the
reverse direction may not be functional. Two situations may happen:
(1) An implementation may not wait for the completion of reverse path
programming (cross-connect in transport network) before forwarding the Path
message.
(2) Bi-directional contention happened.

It is important for the egress node to know when the reverse direction path is
functional. Two-way handshaking may not provide enough information. But for
unidirectional LSPs and PSC LSPs, there may not be an issue. Since GMPLS is
assumed to support unidirectional LSPs and PSC LSPs, it may not be approrate to
require three-way handshaking mandatory.

Your suggestion of ResvConfim indication flag is interesting. It should work.

Thanks,

-- Guangzhi

> establish the reverse direction concurrently.

I think Adam's question is about the time when the egress node is able to send
data.
(1) After receiving Path message ? or
(2) After receiving ResvConf if there is one ? or
(3) simply waiting for some random time ? or
(4) After receiving data from ingress node ?

(1) may loss data
(2) ok but ResvConf is optional
(3) is not determinated
(4) carriers may not feel confortable about this. Since ingress node may not
have data at this time.

---

From: Harry Mantakos <[email-masked]>
Date: Wed, 23 May 2001 15:12:02 -0400

>establish the reverse direction concurrently.

As I understand it, suggested label allows a single node to do
whatever hardware preparation is required for the upstream and
downstream data flows in parallel, but this preparation is
still necessarily done at each node in the path sequentially.
If it takes 'T' time to prep hardware for a single direction at a
single node, and there are 'N' nodes, you're looking at something
on the order of TN to establish the LSP. In the absence of suggested
label, you'd be looking at something like 2TN.

The suggested "3-way handshake" allows "preparation" to be done
at all nodes in the path in parallel. The circuit establishment
time can be reduced to something on the order of T (assuming suggested
label was chosen).
-harry