| Hi Gullik,
I don't know the customer. I got a call from our ex-colleague Krister Larsson,
who told me this and asked if I had seen this mentioned anywhere. I do not
believe LAN Emulation is causing this, even if there are a number of
operations involved in SAR, LES, BUS and so on.
Krister is going to get some more facts, but until then, if anyone has some
ideas about how LAT would be coped with in ATM and LANE, it's always good to
listen to the ideas.
Bj�rn Olav
|
| From: SMTP%"[email protected]" 9-MAY-1997 11:52:06.86
To: "'\"NPSS::ROUNDS\"@amuck.lkg.dec.com'" <"NPSS::ROUNDS"@amuck.lkg.dec.com>
CC:
Subj: RE: LAT/ATM
The GS/ATM BUS supports up to 700 Kbps of traffic in the current
release. If the LAN the ELAN is supporting is above that level in
multicast and unknown destination, packets will be lost.
The lost packets could include LAT service multicasts which prevent the
LAT client from discovering where the LAT service is. This would
indefinitely cause a connection problem. There is some statistical
probability that a multicast will get through and the MAC address of the
service will be learned. This depends on the multicast/broadcast level.
If there is a lot of traffic, the probability is low.
LAT has relatively short retry timeouts. It is conceivable that setting
up a Data Direct VC in LANE takes longer than the LAT retry timeouts.
This is due to the LEC having to resolve the MAC address to ATM address
mapping, and then set up the Data Direct SVC. Initially the LAT
connection may time out waiting for the above to complete, but the
connection should complete on a later try. This try will probably need
to be manually initiated, since the built-in retries will probably be
exhausted.
The combination of the above two factors could create problems for LAT.
In the next release of GS/ATM, the BUS performance increases to 2 Mbps.
Even with this rate, network administrators should be careful of dropped
packets. Dropping a Bridge PDU spells trouble for spanning tree and
users of the LAN/ELAN.
>----------
|