SUBJECT D12)

Questions about Emulation and Interoperability

SUBJECT D12-1) Question:What is the ATM Forum's LAN Emulation all about?

Answer: The ATM Forum has published their LAN Emulation (LANE) V1.0 specification. Reference that spec for complete details. Here's the basics on the requirements and general approach.

The organizations who worked on it thought LANE would be needed for two key reasons

  1. Allow an ATM network to be used as a LAN backbone for hubs, bridges, switching hubs (also sometimes called Ethernet switches or Token Ring switches) and the bridging feature in routers.

  2. Allow endstations connected to "legacy" LANs to communicate though a LAN-to-ATM hub/bridge/switch with an ATM-attached device (a file server, for example) without requiring the traffic to pass through a more complex device such as a router. Note that the LAN-attached device has a conventional, unchanged protocol stack, complete with MAC address, etc.
LANE does not replace routers or routing, but provides a complementary MAC-level service which matches the trend to MAC-layer switching in the hubs and wire closets of large LANs.

LANE defines the three main areas required to emulate 802 LANs (connectionless, broadcast/multicast, 802 hardwired MAC addresses) over ATM networks (connection-oriented, point-to-point, network-defined telephone-like addresses).

LANE specifies:

  1. The address resolution procedures and protocols used to first discover the ATM address that corresponds to a given MAC station address (whether the station is directly ATM-attached, or sitting behind an Ethernet/ATM device) and then to set up a virtual circuit between the end points (or to the Ethernet/ATM device in front of the Ethernet end station).
  2. The protocols and procedures to send broadcast and multicast 802 packets over the network, using a LANE server with point-to-point circuits inbound and point-to-multipoint circuits back out to the clients.
  3. Same for how to "flood" (bridging term) packets across ATM, through Ethernet/ATM devices to reach Ethernet end stations, even those which have not sent a packet yet (thus making the Ethernet switch aware of them).
  4. The packet formats/encapsulations.
LANE also works for Token Ring so substitute Token Ring for Ethernet in the above.

LANE also defines how an ATM adapter in a host can present an Ethernet or Token Ring logical interface to the protocol stack above. This enables applications and LAN protocols which were implemented to run above the aforesaid Ethernet or TR LANs to operate without change over an ATM network.

Surf the ATM Forum's WEB site http://www.atmforum.com for the January 1995 back issue of their "53 Bytes" publication. That issue contains a helpful LANE tutorial.


SUBJECT D12-2) Question:How does LANE work?

Answer: Here is a brief spew on how LANE works with ATM:

On boot the ATM adapter registers with the local switch and exchanges management information. Switch provides a prefix to the ATM adapter which in combination with the MAC address of the adapter becomes the ATM address of the adapter. Switch also provides its ATM address.

At this point the 2 ATM adresses are known so the LEC establishes a virtual circuit connection (VCC) with the LES.

The LEC Registers its ATM/IP/MAC Address with the LES and joins the Emulated Lan. The LES adds the new LEC to the ARP distribution tree.

The LEC now queries the LES for the Broadcast/Unknown Server (BUS) for multi- cast. LES provides BUS address. LEC establishes VCC with BUS and registers its ATM/IP/MAC Address to mcast distribution tree.

Now we can talk to other end systems by arping for the ATM address to the LES. LES does a lookup and upon hit returns the address. On a miss the LES broadcasts the ARP in hopes that some LEC will answer. The response is returned by the LES to the orignating LEC.

A VCC can now be established between the two LEC's and Data is moved.


SUBJECT D12-3) Question:What is DXI?

Answer: The ATM DXI (Data Exchange Interface)is basically the functional equivalent of the SMDS DXI. Routers will handle frames and packets but not typically fragment them into cells; DSUs will fragment frames into cells as the information is mapped to the digital transmission facility.

The DXI, then, provides the standard interface between routers and DSUs without requiring a bunch of proprietary agreements. The SMDS DXI is simple because the router does the frame (SMDS level 3) and the DSU does the cells (SMDS level 2). The ATM DXI is a little more complicated since it has to accomomodate AAL3/4 and/or AAL5 (possibly concurrently).


SUBJECT D12-4) Question:Specs on how Frame Relay frames gets mapped to ATM cells.

Answer: There are at least four. One is the mapping defined for Frame Relay/ATM network interworking as defined in Version 1.1 of the ATM Forum's B-ICI spec (network interworking allows Frame Relay end users to communicate with each other over an ATM network). In this case frames are mapped using AAL 5 and the FR-SSCS (Frame Relay specific service-specific convergence sublayer). Despite the long-winded name, the essentials of the mapping are quite simple to describe: remove the flags and FCS from a Frame Relay frame, add the AAL-5 CPCS trailer, and segment the result into ATM cells using AAL 5 SAR rules. The spec defines additional details such as the mapping between FECN/BECN/DE in the Frame Relay header and EFCI/CLP bits in the ATM cell headers.

A second mapping is ATM DXI (data exchange interface) mode 1a. This is not strictly a Frame Relay to ATM mapping but rather uses an HDLC frame structure identical to that of Frame Relay frames with a two-byte address field (i.e. a 10-bit DLCI). The HDLC DXI frame address (called DFA in the spec) gets stripped off and the 10 bits of the "DLCI" get mapped in a funny way to the VPI and VCI of the ATM cells. The remainder of the DXI frame gets an AAL 5 CPCS trailer and is chopped up into cells by standard AAL 5 rules.

A third mapping is used for ATM/Frame Relay service interworking. This version allows for conversion between the RFC 1490 multiprotocol encapsulation and the RFC 1483 multiprotocol encapsulation. It uses AAL5 with the RFC 1483 encapsulation within the network. It allows a Frame Relay user to communicate with a user of a different service (e.g. SMDS/CBDS) across the ATM network.

A fourth mapping is the FUNI which is completely separate standard ratified by the ATM Forum. It is an extension of the ATM-DXI standard. However instead of being a local serial interface, it is extended across the wide area. For more information reference "From Frames to Cells: Low Speed Access to ATM" in the May 1995 issue of Data Communications.


SUBJECT D12-5) Question:What is MPOA?

Answer: The ATM Forum's Multiprotocol Over ATM (MPOA) subworking group is developing an approach to support seamless transport of layer 3 protocols across ATM networks. Layer 3 protocols meaning things like IP and IPX. MPOA, operating at layer 2 and 3, will use the ATM Forum LAN Emulation for its layer 2 forwarding. As such, MPOA can be seen as an evolution beyond LANE.

LANE basically connects together a single legacy LAN subnet across ATM. MPOA will take this further by allowing direct ATM connectivity between hosts in different subnets.

The proposed architecture consists of edge devices and route servers. An edge device (not necessarily user equipment) would forward packets between the LAN and ATM networks, establishing ATM connections when needed, but would not be involved directly in routing. Edge devices would query a Route Server when an unknown host address is encountered. Route Servers would be able to map a host address into the information needed by the edge device to establish a connection across the ATM network. That would be the layer 3 address of the optimal exit point from the ATM network as well as the ATM address of that exit point. Route servers would also be able to forward packets on to the exit point on behalf of the edge device while they are establishing their own ATM virtual circuits. (This last part is LANE.)

Some folks will notice that the Route Server address mapping function is basically the same problem that the Next Hop Resolution Protocol (NHRP) is addressing.


SUBJECT D12-6) Question:Info about classical IP over ATM

Answer: RFC1483 defines the encapsulation of IP datagrams (or other protocols) directly in AAL5.

Classical IP and ARP over ATM, defined in RFC1577, is targetted towards making IP run over ATM in the most efficient manner utilizing as many of the facilities of ATM as possible. It considers the application of ATM as a direct replacement for the "wires" and local LAN segments connection IP end-stations and routers operating in the "classical" LAN-based paradigm. A comprehensive document, RFC1577 defines the ATMARP protocol for logical IP subnets (LISs). Within an LIS, IP addresses map directly into ATM Forum UNI 3.0 addresses. For communicating out a LIS, an IP router must be used - following the classical IP routing mode. Reference RFC1577 for a full description of this approach.


SUBJECT D12-7) Question: What is a Logical IP Subnet (LIS) and how does it differ from any other subnet?

Answer: RFC1577 is the document which defines LIS, but it doesn't make the concept as obvious as one might wish, although the info is in there in section 3.

The short answer is that Logical IP subnets are identical, in all "protocol" aspects, to conventional LAN etc media subnets. The key aspects that matter in this context are that ATM-attached systems in the same LIS have the same network numbers and subnet masks, just as on an Ethernet or other conventional media. Also, two ATM-attached systems not in the same LIS cannot communicate via RFC1577 except through a router, even though they are both attached to the same ATM physical network, with ATM-level connectivity available (PVC or SVC) between them.

This second limitation was a significant factor in the creation of RFC1577. The issues of "cut-through routing", or communications between two systems in different IP subnets on a common ATM network (as well as other connection-oriented networks) were found to be complex, and there was a desire to define at least the standard or "Classical" means of running IP over ATM before all those issues were resolved.

RFC 1932, the IP over ATM: A Framework Document, has more overview info on these basic issues.


[ Back to Index | FAQ Index | Cell Relay Retreat ]

Maintained by Cell Relay Retreat
Last Changed 24 November 2002