LANE NNI: ATM LAN Emulation NNI

ATM LAN Emulation enables the implementation of emulated LANs over an ATM network. An emulated LAN provides communication of user data frames among all its users, similar to a physical LAN. One or more emulated LANs could run on the same ATM network. However, each of the emulated LANs is logically independent of the others. Communication between emulated LANs requires some type of interconnection device (bridge, router, etc.), even though direct ATM connections between emulated LANs are explicitly allowed in some circumstances. The LAN Emulation LUNI defines the protocols and interactions between LAN Emulation Clients (LE Clients) and the LAN Emulation Service. Each LE Client connects across the LUNI to a single LES and BUS, may connect to a single LECS, and may have connections to multiple SMSs.

The LAN Emulation NNI (LNNI) defines the behavior of these LANE service components as seen by each other, the procedures necessary to provide a distributed and reliable LAN Emulation Service. A single ELAN may be served by multiple LECSs, LESs, BUSs and SMSs. Each LES, BUS, and SMS serves a single ELAN, while an LECS may serve multiple ELANs. LANE service components interconnect with multiple VCCs for Configuration, Status, Database Synchronization, Control and Data forwarding. LNNI specification provides multivendor interoperability among the components serving an ELAN so that consumers may mix and match the LANE Service implementations of different vendors.

LANE service consists of four major components:
• LAN emulation client (LEC) - located in ATM end systems and implements the LUNI interface, and serve as a proxy for LAN systems to perform data forwarding and address resolution, provides a MAC level emulated Ethernet/IEEE 802.3 or IEEE 802.5 service interface to higher level software.
• LAN emulation server (LES) - to support of the address resolution protocol (LE-ARP), used to determine the ATM address of the target LEC responsible for a certain destination MAC address. An LE Client is connected to only one LE Server. An LE Client may register LAN Destinations it represents and/or multicast MAC addresses it wishes to receive with its LE Server. An LE Client will also query its LE Server to resolve a MAC address or route descriptor of an ATM address. 
• Broadcast/Unknown Server (BUS) - to handle all multicast traffic forwarding to all attached LECs. An LE Client sees a single Broadcast and Unknown Server.
• Selective Multicast Server (SMS) - to efficiently forwarding multicast frames, it may be used to offload much of the multicast processing from the BUSs, which also have to forward broadcast frames and frames for unresolved LAN destinations.

The multiple LANE Service entities serving an ELAN need to co-operate and communicate in order to provide a distributed and reliable LAN Emulation Service. The communications required for LNNI may be partitioned as follows:

a) Control Plane
• Configuration and Status Communications - LESs and SMSs obtain configuration information from an LECS over Configuration Direct VCCs. LECSs obtain the status of LESs and SMSs over the same connection.
• LANE Control Communications - Each LES is responsible for distributing LE_ARP requests for unregistered destinations from local LE Clients to local LE Clients and to other LESs. LESs must also forward LE_ARP responses back to the originator. Additionally, LESs must be able to forward LE_FLUSH responses and LE_TOPOLOGY requests to the correct destination(s).

b) Synchronization Plane
• LECS Synchronization - A particular LECS may not directly receive status from all service components. Thus, LECSs must exchange LES and SMS status information among themselves. In order to distribute this status information, all LECSs participating in an ELAN must maintains an LECS Synchronization VCC to all other LECSs in the network.
• LES-SMS Database Synchronization – LESs and SMSs use SCSP to synchronize their databases.

c) Data Plane
• BUS Data Communications - Each BUS is assumed to be logically paired with an LES, and the BUS is assumed to have access to the registration database maintained by the LES, which includes the ATM address of all BUSs. No protocol is defined between a paired LES and BUS.
• SMS Data Communications – Every SMS (and LES) obtains a complete copy of the registration database for the entire ELAN via SCSP, so every SMS knows of every other SMS and BUS. When a LE Client LE_ARPs for a multicast address, the LES should assign the client to an SMS as a sender if an SMS is available for that destination, otherwise a BUS’s ATM address is returned in the LE_ARP response. An ELAN, and hence all the ELAN's SMSs, may operate in either distributed or stand-alone mode, as determined by the network administrator.

 Protocol Structure - LANE NNI: ATM LAN Emulation NNI

LANE Data Frames:

 The LNNI Control frame format is shown below:

• LLC - Logical Link Control: The Control Coordinate VCCs are all LLC encapsulated.
• OUI - Organizationally Unique Identifier = X”00A03E” which indicates ATM Forum.
• FRAME-TYPE = X”000F”
• ELAN-ID - Emulated LAN ID
• OP-CODE (2 Bytes) - Control frame Operation type. Some defined OP-Code are:

• Status - (2 Bytes) Control frame Operation status.
• TLV - Type/ Length / Value Encoded Parameter, examples of LNNI TLVs are:

The ATM protocols are based on standards developed by the ITU.
ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0112.000.pdf : LAN Emulation Over ATM LNNI Specification Version 2.0 (AF-LANE-0112.000), February 1999

ftp://ftp.atmforum.com/pub/approved-specs/af-lane-0084.000.pdf : LAN Emulation Over ATM LUNI Specification Version 2 (AF-LANE-0084.000), July 1997
The ATM Forum, ATM User-Network Interface (UNI) Signalling Specification Version 4.0, af-sig-0061.000, July 1996.
http://www.atmforum.com/standards/approved.html : ATM Forum approved specifications
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/atm.htm: ATM Overview