An FYI on
       Current Directions of the LANE 2.0 LNNI Protocol
   Keith McCloghrie, Cisco Systems

                        Background
   LANE 1.0 specifies the LEC to LANE-Service protocol
   ATM Forum is working on LANE 2.0 to specify
   Server-to-Server protocols (LNNI)
   Multiple LES's (LAN Emulation Servers) and BUS (Broadcast
   and Unknown Servers).  Assumes each LES is paired with a BUS.
   An LES handles control frames for an ELAN including:
 
      - assignment of unique LEC-ids,
      - registration of addresses,
      - address resolution requests.
   Requirement is to support 20+ LES's.

               Topology Considerations
    A fully-connected mesh is good when can afford rich
    connectivity between a small number of LES's
        (e.g., campus LAN) 
    A tree of point-to-point links is good for scaling and
    when fully-connected links are expensive
    LNNI has chosen to use a combination: a "peer-tree"

                       Peer Tree
    Each node is either:
      - 'complex node' of multiple LES's with fully-meshed
        interconnections, or
      - a single LES.
    A pure tree contains no complex nodes & no redundant links
    A pure mesh consists of a single complex node
    Spanning Tree algorithm to produce a loop-free tree:
      - a mesh is modelled as on a multi-access broadcast
        network interconnecting multiple bridges 
      - each link between nodes is modelled as a pt-to-pt
        link between bridges

             Distribution of Database
    Each node in the tree:
       - retains all the information for itself and for
         all the nodes beneath it in the tree,
    Thus, the root and only the root has all the information.

                  New Registrations
    Sent up the tree from leaf towards root
    Each node checks for conflicts, and responds down if so
    If root finds no conflict, responds down with success.
    With "optimistic" enhancement, assume will succeed - if not,
    retract later  (latency v. retraction tradeoff)

                 Resolution Request
    Sent up the tree towards root,
    Each node checks for resolution, and responds down if found.
    If answer is not necessarily registered:
      - root floods if not found.
      - "pessimistic" enhancement: assume will fail
        and flood at each node  (latency v. flood tradeoff)

                   Some Issues
    Caching
    - Efficient mechanisms to purge caches
    - Don't want ot purge caches for momentary loss of
      connectivity
    Partitions and repairs
    - Resolving conflicts in registrations made during
      partition after healing