The IP over ATM Mailing List Archive by date

[rajeev@trillium.com]

> From: Andrew Smith <asmith@synoptics.com>
> Subject: Re: Question on RFC1577.
> 
> I would call it a "bug", not a feature.

I guess I meant to say "unique aspect", not necessarily a desirable
"feature" of the signalling protocol. It is not a "bug" in the sense
that the problem of synchronizing the data path with the signalling
path cannot be solved in the control plane alone.

> This should be addressed by the IP-over-ATM group in the next rev of 
> the document: I think it is an interoperability/protocol issue that
> should be covered in the spec. It looks like an extra state variable
> is needed per-VCC to cover the "I've accepted the call but have not
> heard any packets from the VCC yet" state.

The signalling protocol does not specify an intermediate state after
reception of CONNECT ACK, since in the control plane, the connection
is active. To ensure that the data path is also active, the higher level
protocols (that use signalling to establish data VCCs) need to employ
some kind of synchronizing protocol. This could be implicit (e.g. a
packet is sent and when no response is received, it is resent) or
explicit (e.g.where the data path activation is synchronized using a 
protocol such as the FLUSH protocol of LAN Emulation). RFC 1577, as it stands,
should not break due to this aspect of signalling.

> This race condition seems to be exacerbated by 2 identical implementations
> both doing the same collision avoidance algorithm at each end of the 
> VCC in question.

I don't understand where is the race condition and how it is affected
by any collision avoidance mechanism. Presumably, the calling party is
the one that wants to send data, and if so, the data will get across
without loss. If both parties decide to set up VCCs to each other at
the same time, and a collision avoidance mechanism forces both of them
to use only one of the established VCCs (no thrashing), then it is possible
that one party's data might get lost for a short period of time. This
condition is transient and should disappear without causing any race
conditions.

-------------------------------------------------------------------
Rajeev Gupta                       Email     : rajeev@trillium.com
Trillium Digital Systems, Inc.     Voice (w) : (310) 479-0500
Los Angeles, CA 90025.             Fax   (w) : (310) 575-0172
* I speak only for myself, but make no claim to original thought *
-------------------------------------------------------------------