Technical Committee

LAN Emulation Over ATM
Version 1.0 Addendum

af-lane-0050.000
December, 1995

(C)  1995 The ATM Forum. All Rights Reserved. No part of this publication may be reproduced in any form or by any means. 
The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and The ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. 
The receipt or any use of this document or its contents does not in any way create by implication or otherwise:
•	Any express or implied license or right to or under any ATM Forum member company’s patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor
•	Any warranty or representation that any ATM Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor
•	Any form of relationship between any ATM Forum member companies and the recipient or user of this document.
Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the ATM Forum.
The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.
NOTE: The user’s attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others.  By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity to obtain the license to use such rights.  ATM Forum Member companies agree to grant nondiscriminatory terms and conditions to applicants desiring to obtain such a license.  For additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Suite 304
Mountain View, CA  94040  USA
Tel: +1-415-949-6700
Fax: +1-415-949-6705

Introduction  This document is an Addendum to the LAN Emulation Over ATM: Version 1.0 Specification.  Section and paragraph numbers reference the released Version 1.0 specification (af-lane-0021.000).  This is a “delta” document to af-lane-0021.000, and does not replace it. This Addendum only introduces clarifications for implementors and additional explanatory text. Where text has been changed or added to the original document, such text is marked with strikeout or an underscore.
5.1.1  Initial State - LE Client View 

C7	Control Time-out. Time out period used for timing out most request/response control frame interactions, as specified elsewhere. The value of C7 MUST be less than S4.
Value: Minimum=10 seconds, Default=120 seconds, Maximum=300 seconds.
5.1.2  Initial State - LE Service View

S4	Control Time-out. Time out period used for timing out most request/response control frame interactions, as specified elsewhere.  Once an LE Client establishes a Control Direct VCC to the LE Server, the Join phase must complete within the Join Time-out time. If not, the LE Service SHOULD release any Control VCCs to that LE Client, terminating the Join phase. The value of S4 MUST be greater than C7.
Value: Minimum=10 seconds, Default=120 seconds, Maximum=300 seconds.

5.2.1 LECS Connect - LE Client View
The mechanisms used to locate the configuration service are as follows, in the order in which an LE Client MUST attempt them:

1.	Get the LECS Address via ILMI
2.	Use the well-known LECS Address
3.	Use the LECS PVC

In addition, the LE Client MAY attempt to establish the Configuration Direct VCC to a locally configured LECS ATM address at any step in the above ordering.

These mechanisms are described in the following paragraphs.

5.2.2.1 Finding At Least One LECS
The provider of the LAN Emulation service MUST ensure that an LE Client following the rules of section 5.2.1 will be able to connect to an LE Configuration Server.

Note: Some UNI implementations might not allow the LECS to register the well-known LECS address as one of its valid addresses. Furthermore, the Interim Interswitch Signaling protocol (IISP), will route calls addressed to the well-known LECS address only toward a static set of switches. In these cases, the LE Clients might not be able to connect to an LE Configuration Server using this address.

5.4.1.2  Transmitting LE_JOIN_REQUEST
The LE Client MUST send an LE_JOIN_REQUEST over the Control Direct VCC. The LE_JOIN_REQUEST MUST include the LE Client variables C2, C3, C4, and C5, plus the primary ATM address from LE Client variable C1.  It MAY also include one MAC address from C6 to be registered as a pair with the SOURCE_ATM_ADDRESS. The LEC MUST send an LE_JOIN_REQUEST within timeout period C7.

5.4.2.8  Sending LE_JOIN_RESPONSE
The LE Server MAY return the LE_JOIN_RESPONSE to the LE Client on either the Control Direct VCC or the Control Distribute VCC (if created). If the LE Server returns an LE_JOIN_RESPONSE indicating a successful Join, the response MUST include C5.
7.1.31  Learning New LE_ARP Cache Entries
An LE Client MAY learn new entries for its LE_ARP cache by observing the source MAC address of a frame received on a Data Direct VCC, and associate that MAC address with the VCC and/or the ATM address of the LE Client at the other end of the VCC. Any such learned MAC address MUST be learned as a Remote MAC Address (C27).
9.2  Flush Frames
Flush messages are used for ensuring the in-order delivery of data frames. They are described in Table 27.

Table 27. Flush Frame Format
Offset	Size	Name	Function	
0	2	MARKER	Control Frame = X"FF00"	
2	1	PROTOCOL	ATM LAN Emulation protocol = X"01"	
3	1	VERSION	ATM LAN Emulation protocol version = X"01"	
4	2	OP-CODE	Type of request:
    X”0007”  LE_FLUSH_REQUEST
    X”0107”  LE_FLUSH_RESPONSE	
6	2	STATUS	Always X”0000” in requests.  In Responses: See Table 13 for a list of values.
	
8	4	TRANSACTION-ID	Arbitrary value supplied by the requester and returned by the responder.	
12	2	REQUESTER-LECID	LECID of LE Client issuing the flush request.	
14	2	FLAGS	Always 0 sending, ignored on receipt.	
16	8	SOURCE-LAN-DESTINATION	Always X”00” when sent, ignored on receipt.	
24	8	TARGET-LAN-DESTINATION	Always X”00” when sent, ignored on receipt.	
32	20	SOURCE-ATM-ADDRESS	ATM address of originator of flush request.	
52	4	RESERVED	Always X”00” when sent, ignored on receipt.	
56	20	TARGET-ATM-ADDRESS	ATM address of LE Client to which flush request is directed.	
76	32	RESERVED	Always X”00” when sent, ignored on receipt.	

11.5.1 ATM Address Required
An operational LE Configuration Server MUST have at least one ATM address, and MAY have more.

Note: In these cases, the LE Clients might not be able to connect to an LE Configuration Server using one of these addresses. Even if registration fails, the network might nonetheless correctly route calls using the well-known address to the LECS; better interoperability might occur if the LECS were to accept such calls even though the well-known address was not registered.
12.  Special Topics
12.4.4  Interworking with FDDI LANs

When interworking with FDDI LANs, it is necessary for an internetworking device to map to a LE Client which is a member of either a Ethernet/802.3 or Token-Ring/802.5 emulated LAN. This requires that a device operating as a bridge convert FDDI LAN data frames into frames for one of the defined ATM emulated LAN types as a translating bridge. Procedures for converting to Ethernet frame formats are defined in [802.1h] and to IEEE 802 [802.1I]. There also exist published specifications for mapping to 802.5/Token-Ring [IBM] [802.1x] and for running network layer protocols over such IEEE 802 networks e.g. [RFC 1042] [RFC 1188].

Note that, because LAN Emulation supports IEEE 802.3-like data frame formats with length greater than 4500 bytes, an emulation of a FDDI LAN may be achieved without fragmentation of packets according to established standards without requiring a separate "emulated FDDI" LAN type.

Example configurations

1. Connecting existing FDDI backbones together using ATM

Bridges and routers can use ATM LAN Emulation to connect efficiently between FDDI LANs without the cost of packet fragmentation. The ATM emulated LAN (ELAN) may be defined to use either of the LAN Emulation frame formats defined in this specification.

Connecting existing FDDI backbones 

2. Replacement of FDDI by ATM as a high-performance host/server interconnect:

ATM LAN Emulation allows similar efficiency for communication across ATM when compared to FDDI: stations may still use 4500 octet MTU or even higher MTUs up to 18k octets, if desired, for more efficiency. The ELAN may be defined to use either of the LAN Emulation frame formats defined in this specification. ATM-to-FDDI concentrators may be used if it is desired to keep devices on same LAN as FDDI stations;  bridges or routers may be used if it is desired to separate the ATM ELAN from a FDDI LAN.

Replacing FDDI by ATM in Hosts

3. Replacement of FDDI by ATM in a mixed Ethernet/FDDI host environment:

As with legacy LANs, translation bridges may be used to connect segments using different packet encapsulations or MTUs. The technologies and standards used to do this still apply in the ATM LAN Emulation world:

Ethernet/FDDI mixed -> ATM hosts (1)

This specification supports use of  ‘mixed MTU’ devices on the same emulated LAN where the upper layer protocols permit this. One possible example would be if an ATM NIC card joins a  4500-octet ELAN: if upper layer protocol uses a smaller MTU, the NIC can discard received frames which are too long for the upper-layer protocol. In other cases, higher layer protocols will automatically lower or negotiate the MTU size between pairs of destinations. This scenario offers several advantages including minimizing the amount of configuration and management by users and reducing the number of hops through intermediate bridges: 

Ethernet/FDDI mixed -> ATM hosts (2)

References

The following references pertain to mixed-media bridging over LANs:

[802.1h] 	“MAC Bridging of Ethernet V2.0 in IEEE 802 Local Area 
                            Networks”  IEEE P802.1h/D4  1/12/93

[802.1i] 	“Local Area Networks MAC Bridges FDDI Supplement”
		    IEEE P802.1i/D3    6/30/91

[802.1x] 	“MAC Bridges - Source-Routing Supplement”
		    IEEE P802.5m/P802.1x/D5   8/15/91

[RFC 1042]	“A Standard for the Transmission of IP Datagrams over 
                           IEEE 802 Networks"   Reynolds & Postel, IETF, May 1987

[RFC 1188]	“A Proposed Standard for the Transmission of IP Datagrams over 
                          FDDI Networks"   Katz, IETF, October 1990

[IBM]		"The IBM 8209 LAN Bridge"
                            Latif et al., IEEE Network Magazine, May 1992

End of Addendum