The IP over ATM Mailing List Archive by date

[Keith McCloghrie <kzm@cisco.com>]

> > I agree, but this isn't what UNI 3.x says.  With UNI 3.x, it would seem
> > that the called party either has to wait for incoming data, or be
> > prepared for its transmissions to be lost.
> >
> > If I recall correctly, UNI 4.0 will have 3rd-party call setup where
> > there are two called parties, and so, having each called party wait for
> > incoming data would cuase a deadlock.  Perhaps, UNI 4.0 needs to have
> > the CONNECT-ACK become end-to-end (even though I think that would
> > require a "flag-day" to upgrade all the switches in a network).
> 
> I think the 3rd-party call setup argument is a red-herring.  You are confusing
> the control and user planes again.  Each called party should be prepared to
> receive data upon sending the CONNECT.  It should not send until it receives
> the CONNECT-ACK.  Both sides will eventually receive this, so there is no
> deadlock, just a small delay.

No, the confusion is between the "right solution" and today's spec.  
In UNI 3.x, the CONNECT-ACK is not end-to-end, and so the behaviour you
describe (the called party sending data immediately after receiving the
CONNECT-ACK) is liable to result in data being lost.  My comment about
3rd-party call setup was to say that the called party(ies) cannot further
delay their sending until they receive data because that can lead to a
deadlock.

> Also note that P-NNI phase 1 signalling is not yet complete, and
> might possibly be able to fix this right off, particularly because it
> is being done in a somewhat coordinated fashion with UNI 4.0.

P-NNI Phase 1 signalling is not an end-to-end protocol.  It can't fix
it without changing the semantics of CONNECT-ACK at the UNI.

Keith.