Cell Relay Archive

[newton@nactoc.nacto.lkg.dec.com (Tom Newton)]

In article <3ns01g$8gg@cronkite.cisco.com> lmercili@cisco.com (Leena Merciline) writes:
>
>The ATM Forum's LE spec addresses this situation. Now say both A & B
>are moving IP traffic over ATM. Both A & B would have device driver
>software containing a lan emulation client (LEC)

So far, so good.

>which takes all
>broadcasts (arp requests) and directs them to the lan emulation
>server (LES). The LES maintains a table of IP address to ATM address
>mappings of all hosts in the LE domain. The LES basically replies
>to the ATM-ARP request if it can find a match in its table. If not,
>the LES consults the broadcast unknown server (BUS). Now how do

I believe you have LAN Emulation confused with Classical IP over ATM.  The
LES doesn't know anything about IP addresses.  It helps LECs translate MAC
addresses and Route Descriptors to ATM addresses.  In this example,

  1. LEC 'A' would find out the ATM address of the BUS by sending a LE_ARP
     request containing the broadcast MAC address 'ff-ff-ff-ff-ff-ff' to
     the LES.  The LES is required to know this particular ATM address and
     would reply.  The LEC would then set up a connection to the BUS.  All
     this happens automatically as part of client startup.

  2. Since IP ARP requests are sent using broadcast packets, the LEC knows
     to send them to the BUS over the Multicast Send VCC that it set up in
     Step 1.  Any broadcast packets get this treatment, not just IP ARPs.

  3. Assuming that an ATM workstation replies to the IP ARP, but does not
     know the ATM address of the sender, something like this will happen:

     a.  The unicast IP ARP reply will be handed to the LEC driver.

     b.  LEC 'B' will look in its LE_ARP cache for the unicast destination
	 address MAC(A), but won't find it.

     c.  LEC 'B' will send a LE_ARP request for the original sender's MAC
	 address to the LES.  While it is waiting to get the reply and to
	 set up a circuit, it may flood unicast packets intended for that
	 address to the BUS (Broadcast and UNKNOWN Server) at a limited
	 rate.  Reasonable implementations will do at least some flooding
	 to handle the case of silent stations behind transparent bridges.

     d.  The LE_ARP request may be answered either by the LES (if the MAC
	 address is registered), or by LEC 'A' (which MUST answer a LE_ARP
	 request for one of its own LAN Destinations).  Either way,
	 the response comes back to the second LEC via the LES.

     e.  When the IP ARP Server LEC gets the LE_ARP reply, it will set up
	 a Data Direct VCC to the first LEC.  It will then send new frames
         for MAC(A) over that VCC.  Once LEC 'A' uses LE_ARP requests (or
	 other permitted means) to learn ATM(B), it too will use the VCC.

A LES does have a database of registered (LAN Destination --> ATM Address)
pairs that it can use to directly answer LE_ARP requests.  However, if the
LES can't or won't answer a request, it forwards it to clients to let them
have a try.  No consultation with the BUS is involved - a BUS doesn't know
anything that could help the LES resolve LE_ARP requests for a unicast MAC
address or a route descriptor.  (On the other hand, an "intelligent" BUS
that selectively routes flooded unicast frames may want to consult the LES
database.)

>A & B determine the addresses of LES and BUS to communicate with 
>them? This is done by querying the configuration server (CS). The
>CS is probably statically defined at the time of device driver
>installation. LAN Emulation Services (LANES) is a trademark. It
>comprises of LES, BUS, and CS (also called LECS).

The LES address can be auto-configured (via the LECS) or manually configured
(via SNMP).  The BUS address is obtained from the LES using a LE_ARP_REQUEST.
I am not sure what you mean about a "statically defined" LECS -- the process
for connecting to a LECS requires no management on the client side of an ATM
User-Network Interface, and lecConfigServerAtmAddress is read-only.


Tom   (newton@school.enet.dec.com)