Path: bloom-beacon.mit.edu!hookup!news.kei.com!eff!news.umbc.edu!haven.umd.edu!umd5.umd.edu!not-for-mail From: carl@umd5.umd.edu (Carl Symborski) Newsgroups: comp.dcom.cell-relay,comp.answers,news.answers Subject: comp.dcom.cell-relay FAQ: ATM, SMDS, and related technologies Followup-To: comp.dcom.cell-relay Date: 26 Apr 1994 23:49:58 -0400 Organization: University of Maryland, College Park Lines: 1539 Sender: carl@macbeth.umd.edu Approved: news-answers-request@MIT.Edu Message-ID: <2pknd6$756@macbeth.umd.edu> NNTP-Posting-Host: macbeth.umd.edu Summary: General information and answers to questions related to or seen in the comp.dcom.cell-relay group. Keywords: cell-relay, ATM, SMDS, communications Xref: bloom-beacon.mit.edu comp.dcom.cell-relay:3257 comp.answers:5088 news.answers:18674 Archive-name: cell-relay-faq Last-modified: 1994/04/25 FAQ-Maintainer: Carl Symborski (carl@umd5.umd.edu) NOTE: This FAQ reflects cell-relay traffic through the early part of March. This article mostly contains general information but also answers to some Frequently Asked Questions (FAQ) which are related to or have been seen in comp.dcom.cell-relay. It is posted to provide information of general interest to both new and experienced readers. This list includes answers to questions, which are loosely grouped into categories. Questions marked with a "+" are new in this issue; those with significant changes of content since the last issue are marked by "*": A) TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION A1) What is the CELL-RELAY group? A2) * What is the archive site for this group? A3) Is there a parallel mailing list for this group? A4) What other mailing lists are related to ATM? B) TOPIC: INDUSTRY FORUMS AND VENDOR INFORMATION B1) How can I contact the ATM Forum? B2) What vendors are working on ATM technology? B3) * What vendors are working on ATM hardware/chips? B4) What vendors are selling ATM test equipment? B5) Are there any ATM interface boards for PCs? B6) Where are the ATM Forum's FTP sites and mailing lists? B7) + What vendors are selling ATM software? C) TOPIC: ATM REFERENCES C1) What are some good getting started ATM references? C2) Where/What is the "Network Compatible ATM for LANs" document? C3) Where are hosts with ATM related information? C4) How can I get the ATM Forum's Interface Specifications? C5) * List of ITU-T Recommendations concerning ATM. C6) * Internet drafts from IETF working groups. C7) * ATM Tutorials. C8) Contact information for ANSI T1S1 specifications. C9) * Internet RFCs. C10) ATM and Related Acronyms. C11)+ Where can I find the "Self Similar" Ethernet Traffic Study? C12)+ How can I get copies of ITU-T documents? D) TOPIC: ATM TECHNOLOGY QUESTIONS D1) What are the various ATM Access layers? D2) Are ATM cells delivered in order? D3) What do people mean by the term "traffic shaping"? D4) * What is happening with signalling standards for ATM? D5) What is VPI and VCI? D6) Why both VPI *and* VCI? D7) How come an ATM cell is 53 bytes anyway? D8) How does AAL5 work? D9) What are the diffferences between Q.93B and Q.931? D10)+ What is a DXI? D11)+ What is Goodput? D12)+ What is LAN Emulation all about? D13)+ Information about the Classsical IP over ATM approach. D14)+ Classical IP and LAN/MAC Emulation approaches compaired. E) TOPIC: ATM VS. XYZ TECHNOLOGY E1) * How does ATM differ from SMDS? F) TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS F1) What and where is VINCE? G) TOPIC: FLAMES AND RECURRING HOLY WARS G1) + Are big buffers in ATM switches needed to support TCP/IP? G2) + Can AAL5 be used for connection-less protocols? If you have suggestions or corrections for any of these answers or any additional information, please send them directly to carl@umd5.umd.edu; the information will be included in the next revision (or possibly the one after that). This posting is intended to be distributed every few months. New versions are archived along with other comp.dcom.cell-relay traffic on cell-relay.indiana.edu. See subject A2 for instructions to access the archive. The information contained herein has been gathered from a variety of sources. Most derived from a consensus of postings on the group. A listing of contributors so far can be found at the end of the FAQ text. If you would like to claim responsibility for a particular item, please let me know. Enjoy! Carl Symborski | Put my faith in the people, but the people let me down carl@umd5.umd.edu | So I turn the other way and I carry on, anyhow... Rare Earth ----------------------------------------------------------------------------- TOPIC: A) TOPIC: COMP.DCOM.CELL-RELAY BASIC INFORMATION ----------------------------------------------------------------------------- SUBJECT: A1) What is the CELL-RELAY group? The purpose of this group is to provide a forum for the submission of articles and inquiries dealing with networks using Cell Relay as a transport; including local, metropolitan, and wide area networks. The name cell-relay was chosen as a compromise over objections to the name "ATM" during the creation of this group. The acronym ATM in the context of this group stands for Asynchronous Transfer Mode, not Automatic Teller Machines or Adobe Type Manager. The term "cell" in cell-relay is taken to mean a small, fixed sized, information bearing unit that provides the foundation for transport and multiplexing of user traffic. This topic area is not related to cellular phones or intra-cellular organisms. SUBJECT: A2) * What is the archive site for this group? The archives for comp.dcom.cell-relay are available via anonymous ftp to cell-relay.indiana.edu as: /pub/cell-relay/archives/cell-relay/..... with subdirectories for each year, and group messages split out by month. I must point out that there is a wealth of other cell-relay related information in the /pub/cell-relay directory tree. If you have access to a Gopher client you should use it instead of ftp as we have set this server up to be *much* more friendly when using Gopher. For instance, when you use Gopher: /pub/cell-relay/docs/current/tenet.berkeley.edu/Mah93.txt becomes: A Mechanism for the Administration of Real-Time Channels. Users are encourged to use Gopher to access this information if possible. SUBJECT: A3) Is there a parallel mailing list for this group? A direct mailing list has been setup which is a mirror of the USEnet newsgroup comp.dcom.cell-relay. To send mail TO the list, send it to: comp.dcom.cell-relay@indiana.edu To un/subscribe, or send other notes to the list management, please use: cell-relay-request@indiana.edu SUBJECT: A4) What other mailing lists are related to ATM? There are several lists described below. One is for an IETF group working on the issue of IP over ATM. This work is on going and primarily focused on that task. General ATM questions and blue-skying are inappropriate and discouraged by the members on the list. To send mail TO the list, send it to: atm@hpl.hp.com To un/subscribe, or send other notes to the list management, use the address: atm-request@hpl.hp.com Related to cell-relay technology is the Distributed Queueing mailing list. The distributed queueing list is intended for discussion about protocol design, variants, extensions, associated with the use of DQ for arbitrating access to cells in shared-medium cell-relay networks. To send mail TO the list, sent it to: dqlist@atri.curtin.edu.au To un/subscribe, or send other notes to the list management, use the address: dqlist-request@atri.curtin.edu.au Another IETF working group is working on the issue of general routing over networks (large clouds). As with the IP over ATM list it is best to subscribe with the intention to just "listen in". To un/subscribe to this list use the address: rolc-request@network.com Also of possible interest is the mailing list for the SMDS special interest group (SIG) Technical Committee. To send mail TO the list, send it to: smdstc@nsco.network.com To un/subscribe, or send other notes to the list management, use the address: smdstc-request@nsco.network.com ----------------------------------------------------------------------------- TOPIC: B) INDUSTRY FORUMS AND VENDOR INFORMATION ----------------------------------------------------------------------------- SUBJECT: B1) How can I contact the ATM Forum? Similar to the Frame Relay Forum, the ATM Forum is an open public forum with over 300 contributing and auditing companies. Membership includes many international companies. Some companies also participate in ANSI T1S1 and other standards bodies. Audit membership of the Forum is $1500/year. Those interested in joining the forum or needing additional information should contact: The ATM Forum 480 San Antonio Road, Suite 100 Mountain View, CA 94040-1219 U.S.A Tel +1 415-962-2585 Fax +1 415-941-0849 Email atmforum_info@atmforum.com The ATM Forum also has a FAX-On-Demand service. Using this it is possible to get instructions, order forms, membership applications, etc. Just dial +1 415-688-4318 from a FAX phone and follow the instructions. SUBJECT: B2) What vendors are working on ATM technology? It is tough to get a number on this. Increasingly there are companies with hardware they can demonstrate. More who have made product announcements. Many more who have stated product intentions. Some are building big central office switches, others smaller ones for the LAN market. Workstation vendors are working on ATM interface boards. Chip companies are working on ATM chip sets, etc. There are now software vendors advertizing protocol software stacks (Q.93B, etc.) suitable for inclusion in ATM products. Previously (in 1992) there was an attempt here to list most of the major players in the ATM arena. This was possible in 1992. At this time *everyone* is doing something or paying lip service to ATM. It is simply not practical to keep a fair and accurate list here in this FAQ. Some postings on the cell-relay list (Fall 1993) attempted to again list the current vendors developing and/or selling equipment in this technology area. As predicted, these partial lists exceeded 40 vendors! SUBJECT: B3) * What vendors are working on ATM hardware/chips? As with ATM technology vendors, the number of companies developing board level components is growing and soon will be hard to track. For starters, there is a group in North America working on low-cost SONET-based ATM physical layer chips for local nets using optics and twisted pair interfaces. This group is called the Saturn Development Group, and consists of PMC-Sierra, Sun Microsystems, Ungermann-Bass, Bell-Northern Research, Interphase, Optical Data Systems, SynOptics Communications, Themis Computer, BBN, MPR Tetltech, the University of British Columbia, and maby others. PMC-Sierra, Inc. 8999 Nelson Way Burnaby, BC Canada V5A 4B5 604-293-5755 604-293-6012 FAX Adaptive has designed an ATM/AAL chipset for use in equipment (computer, workstation, router, etc.) which connects to an ATM network. That chipset is now licenced to two chip manufacturers, TranSwitch and National Semiconductor. The TranSwitch product is called SARA and consists of a segmentation chip and reassembly chip. Together they can form the basis of an ATM/AAL controller which can process up to 8000 packets simultaneously at speeds of up to 155.52 Mbit/s. The chip set implements BISDN adaptation layers AAL3/4 and AAL5 in addition to supporting constant bit rate (CBR) traffic. Presumably the National Semiconductor product is similar. TranSwitch Corporation 8 Progress Drive Shelton, CT 06484 Tel: 203-929-8810 Fax: 203-926-9453 Fujitsu makes a 4 x 4 switch element chip set (MB86680). Note that there ARE other ATM/AAL chipsets out there, besides the Adaptive design, now that the industry is rolling. Other vendors include Brooktree (Boulder, CO (303) 494-4484) and Integrated Telecom Technology (IgT) which both have ATM UNI chips and other cool ATM chips. Integrated Telecom Technology, Inc. 18310 Montgomery Village Avenue Suite 300 Gaithersburg, Maryland 20879 Tel: 301-990-9890 Fax: 301-990-9893 SUBJECT: B4) What vendors are selling ATM test equipment? There exist already a number of vendors that have ATM test equipment available. To name a few: 1. ATM-100, Wandel & Goltermann Tel.: +49 7121-862143 Fax.: +49 7121-862054 2. ATM Test Tool, Siemens AG Tel.: +49 30-386-4173 7077 Fax.: +49 30-386-7934 The Siemens tool is the same as the Wandel & Goltermann tool 3. HP 75000 Series 90 ATM Analyzer, contact your local Hewlett Packard sales office 4. HP Broadband Series protocol test system, IDACOM Telecom Division, Hewlett Packard (Canada) Ltd. Edmonton, Alberta Canada T6E 5R6 Tel.: +1-800-661-3868 +1-403-462-4545 Fax.: +1-403-462-4869 5. Alcatel 8643 ATM Traffic Generator Analyzer, and Alcatel 8640, Alcatel STR, Tel.: +41 1 4652860 Fax.: +41 1 4652319 or Alcatel Network Systems Inc., Richardson, TX Tel.: +1 214-996-5000 Fax.: +1 214-996-5409 6. Adtech AX/3000 ATM Cell Data Generator, AX/3010 DS3 ATM Cell Data Generator 1814 Algaroba St, Honolulu HI 96826 Tel.: (808) 941-0708 Fax.: (808) 946-1300 This list is provided for information purposes only. There is no implied claim that this list is correct or complete. SUBJECT: B5) Are there any ATM interface boards for PCs? National Semiconductor has an ESIA ATM card (Vicksburg DP8300VK) which will be available in November 1993. NET will resell the board. Also, at the August 1993 Interop IBM was demonstrating their PS/2 based ATM cards. SUBJECT: B6) Where are the ATM Forum's FTP sites and mailing lists? The ATM Forum is a members only organization. Although an open public forum (which means that anyone can join) only members have direct access to Forum activities and documentation. There are *NO* FTP sites and *NO* open e-mail lists. Note that the minimal entry to the Forum is as an Auditing Member. Auditing Members are allowed access to the e-mail distribution lists to "audit" all documentation but are NOT ALLOWED to make comments. Please note that auditing members are not allowed to attend Technical and Market Commitee meetings, not allowed to vote on issues and not allowed to submit technical contributions. See subject B1 for ATM Forum membership information. SUBJECT: B7) + What vendors are selling ATM software? Several software vendors have been mentioned on this list over the past few months. Two that come to mind are: 1) Bellcore's signalling software product called Q.PORT (800-521-2673 x4649) 2) Trillium signalling software product ----------------------------------------------------------------------------- TOPIC: C) ATM REFERENCES ----------------------------------------------------------------------------- SUBJECT: C1) What are some good getting started ATM references? Generally it is impossible to pick up any communications related technical journal, conference, or trade publications and not find something about ATM. Most of what has been written in the 1985 through 1990 time frame primarily deals with the application of ATM to Broadband ISDN. These provide the foundation on which other applications of ATM have been based and therefore should not be over looked. Without a doubt, if you are at all serious about learning ATM, the best references are the series of specifications developed by the ATM Forum. These are the: o ATM User-Network Interface Specification, Ver 3.0, September 10, 1993 o The ATM Forum BISDN Inter Carrier Interface (B-ICI) Specification, Ver 1.0 August, 1993 The ATM Forum's DXI specification is also useful. See subject C4 for ways to obtain these documents. Note that because of the pace of ATM standardization, reference books rapidly become out-of-date. Specifically, there have been major changes to the specification of the AALs subsequent to the publication of these books and articles. However, the following references do offer a good base of background information. Note, see also subject C7 for ATM Tutorials. --General: "Data Communications Special Guide", IEEE Spectrum, 8/91, p.22. o Hi-level overview of high-speed lans, wans, bisdn, atm, with glossary and bibliography. IEEE Communications Magazine, April 1992, VOL. 30, NO. 4 o This is a special issue with six articles on gigabit networks technology. "Cell Relay Switching", Data Communications, 9/91, p.58. o Looks at cell relay and switching in general, not just ATM. Rainer Handel and Manfred Huber. "Integrated Broadband Networks: An Introduction to ATM-Based Networks". Addison-Wesley, 1991. ISBN 0-201-54444-X. --ATM: "Overview of ATM Networks: functions and procedures", Computer Communications, 12/91, p.615. o Cell headers, bit definitions and the like. 33 References, including good list of CCITT recommendations. "Broadband ISDN and Asynchronous Transfer Mode (ATM)", IEEE Communications, 9/89. o Describes most of the jargon as well as the paradigm and unresolved issues. One point to note is that the article is fairly old (1989) and some things have changed. For example, the ATM cell headers described are no longer valid. "Asynchronous Transfer Mode: Solution for Broadband ISDN", Martin de Prycker, Ellis Horwood, New York, 1991. ISBN 0-13-053513-3 o See Martin's more recent book below. "Asynchronous Transfer Mode", Martin De Prycker, Ellis Horwood, New York 1993, ISBN 0-13-178542-7. o Very readable general description of the technology and optimization. Even though its recent some of the details have changed AND the book is NOT long on details. Also, this is primarily an ITU-oriented (telecomm services) view of ATM, not an ATM Forum-oriented view (CPE), I believe. "Gigabit Networking", Craig Partridge, Addison-Wesley, Reading MA, 1993, ISBN 0-201-56333-9. o Very well written book. Craig is the Editor of "IEEE Network" magazine. Topics: fiber optics, cell networking, ATM, Gbps packet schemes, applications, host interface, higher protocols, bandwidth management and performance, distributed systems, etc. --SWITCH FABRICS: These papers offer a fast jump start on ATM switch architectures, design issues and tradeoffs. H. Ahmadi and W. Denzel, "A Survey of Modern High-Performance Switching Techniques", IEEE J on Selected Areas in Comm, Vol. 7, No. 7, Sept 1989, p. 1091-1103 F. Tobagi, "Fast Packet Switch Architectures for Broad-band Integrated Services Digital Networks", Proceedings of IEEE, Vol. 78, No. 1, Jan. 1990 p. 133-167 Joseph Y. Hui, "Switching and Traffic Theory for Integrated Broadband Networks", Kluwer Academic Publishers, 1991, ISBN 0-7923-9061-X o A back to basics text book explaining core switching concepts like batcher/banyon, clos, min, buffering, etc. Technical journals ================== IEEE Network IEEE Communications IEEE Journal on Selected Areas in Communications IEEE Transactions on Communications IEEE/ACM Transactions on Networking Computer Communication Review (by ACM SIGCOMM) Computer Communications Computer Networks and ISDN Systems IEICE Transactions on Communications Journal of High Speed Networks Magazines ========= Communications Week Data Communications Open Systems Today Lightwave (the leading-edge magazine for the fiber-optics industry) SUBJECT: C2) Where/What is the "Network Compatible ATM for Local Network Applications" document? "Network Compatible ATM for Local Network Applications", V1.01, October 19, 1992. A proposal for a 150 Mb ATM LAN from Apple, Bellcore, Sun and Xerox. Available in standard postscript and compressed standard postscript from: thumper.bellcore.com: /pub/nclatm/nclatm.ps /pub/nclatm/nclatm.ps.Z ftp.apple.com: /pub/latm/nclatm.ps /pub/latm/nclatm.ps.Z parcftp.xerox.com: /pub/latm/nclatm.ps /pub/latm/nclatm.ps.Z SUBJECT: C3) Where are hosts with ATM related information? Here's a list of sites that that seem to cater to the ATM/broadband/real-time continuous-media crowd: cc-hw.bbn.com Rec_I_cls.ps, Rec_I_cls.hqx icsi-ftp.Berkeley.EDU Research, Continuous media wuarchive.wustl.edu Research, ATM Hardware datanet.tele.fi Standards drafts (see below) nsco.network.com HIPPI gregorio.stanford.edu IP Multicast cell-relay.indiana.edu cell-relay archives, etc. (see below) If you have ftp access, ftp to cell-relay.indiana.edu as user anonymous and look in /pub/cell-relay for: 1) In /pub/cell-relay/bib A bibliography of ATM research. This includes several to reference books and LOTS of citations. 2) In /pub/cell-relay/docs Some papers on ATM-related topics, standards, etc. 3) In /pub/cell-relay This FAQ list! 4) In /pub/cell-relay/conferences A bunch of files describing upcoming conferences (Special thanks to Allen Robel for hosting this list and archive.) Additionally, there are some draft standards, RFCs, technical papers, etc. on ATM available at datanet.tele.fi in the directory called /atm The collection includes draft AAL5 CCITT standards. This is a general good place to look. SUBJECT: C4) How can I get the ATM Forum's Interface Specifications? The ATM Forum has produced a document called the User-Network Interface specification. This document applies to both the "Private UNI" between an ATM user and a private ATM switch, and also a "Public UNI" between a private ATM switch or a user and the public network. The specification contains information on the ATM bearer services, physical level interface options, local network management, traffic, and signalling for both the private and public UNIs. For those which are not ATM Forum members, hard copies will be available for purchase at book stores and direct from Prentice Hall. This specification is due to be published by Prentice Hall on 12/15/93 and will cost $34. It can be backordered now. To do this call 1-800-374-1200 and ask for the following book: Title: ATM User-Network Interface Specification (V3.0 is not in the title; it's the First Edition) Author: ATM Forum ISBN: 0-132-25863-3 The ATM Forum's DXI and B-ICI specification can be ordered directly from the ATM Forum. Call the ATM Forum information line for ordering information (415) 962-2585. See also subject B1. SUBJECT: C5) * List of ITU-T recommendations concerning ATM This list is provided for informational purposes only. No guarantee as to its completeness or correctness. Also, although they are not formally published, many of the following recommendations have been substantially updated since first published. =ITU-T Recommendations Concerning ATM = E.164 Numbering plan for the ISDN era 11/91 G.707 Synchronous digital hierarchy bit rates 04/91 G.708 Network node interface for the synchronous 06/92 digital hierarchy G.709 Synchronous multiplexing structure 06/92 I.113 B-ISDN Vocabulary of Terms 04/91 I.121R Broadband Aspects Of ISDN 04/91 I.150 B-ISDN asynchronous transfer mode functional 06/92 characteristics I.211 B-ISDN service aspects 04/91 I.311 B-ISDN General Network aspects 06/92 I.321 B-ISDN protocol reference model and its 04/91 application I.327 B-ISDN functional architecture 04/91 I.361 B-ISDN ATM layer specification 06/92 I.362 B-ISDN ATM adaptation layer (AAL) functional 04/91 description I.363 B-ISDN ATM adaptation layer (AAL) specification 06/92 I.413 B-ISDN user-network interface 04/91 I.432 B-ISDN user-network interface - Physical layer 06/92 specification I.610 OAM principles of the B-ISDN access 06/92 Also, there are draft recommendations yet to be published (or I am just not sure of their status): I.35B BISDN ATM Layer Cell Transfer Performance, 1992 I.363 Temp Doc 10 (XVIII) 'AAL Type 5 , Draft Recommendation text for ssection 6 of I.363" 06/93 I.364 Temp Doc 58 (XVIII) 'Support of Broadband Connectionless Data Service on B-ISDN' 06/92 I.365.1 Frame Relaying Service Specific Convergence Sublayer (FR-SSCS) 06/93 I.371 Temp Doc 64 (XVIII) 'Traffic Control and Congestion Control in B-ISDN' 05/92 I.555 Frame Relaying Bearer Service Interworking 06/93 Q.93B B-ISDN User-Network Interface Layer 3 Specification for Basic Call/Bearer Control, 04/93 Q.931 ISDN user-network interface layer 3 specification for basic call control 05/92 Q.933 Digital Subscriber Signalling Systems No. 1 (DSS 1) Signalling Specification for Frame Mode Basic Call Control 05/92 G.804 Which describes the mapping of ATM cells into PDH links at 1.544, 2.048, 6.312, 34.368, 44.736, 97.728, 139.264 Mb/s (Jan 1993) SUBJECT: C6) * Internet drafts from IETF working groups. Various work items of the IP over Asynchronous Transfer Mode Working group and other working groups of the IETF currently available include: draft-brazdziunas-ipng-atm-00.txt draft-ietf-atm-address-resolve-00.txt draft-ietf-atm-address-translation-00.txt draft-ietf-atm-classic-ip-06.txt draft-ietf-atm-framework-doc-00.ps draft-ietf-atm-framework-doc-00.txt draft-ietf-atm-mtu-07.txt draft-ietf-atm-multipro-06.txt draft-ietf-atm-nbma-01.txt draft-ietf-atm-sig-00.txt draft-ietf-atommib-atm-06.txt draft-ohta-ip-over-atm-00.txt draft-ietf-rolc-nhrp-00.txt draft-ietf-atommib-atm-06.txt draft-ietf-atommib-sonet-04.txt Internet-Drafts are available by anonymous FTP. Internet-Drafts directories are located (as officially designated by the IETF folks) at: o East Coast (US) ds.internic.net (198.49.45.10) o Pacific Rim munnari.oz.au (128.250.1.21) o Europe nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body specify the filename requested. For example type: "SEND draft-ietf-atm-multipro-06.txt". SUBJECT: C7) * ATM Tutorials. The following ATM tutorials are available via anonymous FTP. Machine: ftp.magic.net Path: pub/magic File: ip-atm.ps (PostScript) ip-atm.ps.Z (Compressed PostScript) The focus of this paper is running IP over ATM, but there is an extensive tutorial on ATM, followed by discussion IP over ATM networks. Machine: datanet.tele.fi Path: atm/articles File: atm-intro.txt This paper is also a good starting point. And a the following publically available paper is a good start: "The Asynchronous Trnasfer Mode: A Tutorial" by Jean-Yves Le Boudec in Computer Networks and ISDN, Vol 24, No 4, May 1992, pp 279-309 Additionally there are reasonable tutorials available from three commercial communications companies. Specifically: 1. "ATM In Private Networking", Anthony Alles, Hughes LAN Systems, Spring 1993 This was handed out at the Spring 1993 Interop for free. Contact Hughes LAN Systems, Inc., 1225 Charleston Road, Mountain View, CA 94043. Phone: (415) 966-7330 Fax: (415) 960-3738 (Note no guarentee that they will send out a copy.) 2. "Asynchronous Transfer Mode: Bandwidth for the Future", Jim Lane, Telco Systems, 1992. To order a free copy simply call 1-800-447-2537 3. "Broadband Testing Technologies", (a HP Seminar Handbook), Hewlett- Packard Company, February 1993, Document number 5091-6902E Call your local HP sales office and or contact the HP IDACOM Test division. The inside cover claims this document costs $10. Additionally, Ameritech and the other Bell companies publish a pamphlet called "ATM Today" anad another called "SMDS Today". You can call (800) TEAM-DATA for copies. SUBJECT: C8) Contact information for ANSI T1S1 specifications. These documents can be obtained directly from the Secretariat for the ANSI T1 Telecommunications committee. Exchange Carriers Standard Association 1200 G. Street N.W. Suite 500 Washington, D.C. 20005 All orders and requests for quotations on prices must be in writing. Their FAX number is: (202) 393-5453 SUBJECT: C9) * Internet RFCs The following RFCs are available related to cell-relay technology. RFC 1483: Multiprotocol Encapsulation over ATM Adaptation Layer 5 RFC 1577: Classical IP and ARP over ATM SUBJECT: C10) ATM and Related Acronyms These are a few acronyms which tend to appear in postings, RFCs, standards and other text related to the cell-relay topic area. AAL ATM Adaptation Layer ATM Asynchronous Transfer Mode BISDN Broadband Integrated Services Digital Network CBR Constant Bit Rate CLP Cell Loss Priority (as in CLP bit) CPCS Common Part Convergence Sublayer CS Convergence Sublayer (as in CS_PDU) DXI Data Exchange Interface (as in ATM DXI) GFC Generic Flow Control HEC Header Error Control ILMI Interim Local Management Interface NLPID Network Layer Protocol ID NNI Network Node Interface NSAP Network Layer Service Access Point PDU Protocol Data Unit PLCP Physical Layer Convergence Procedure PTI Payload Type Identifer PVC Permanent Virtual Circuit QOS Quality of Service SAR Segmentation and Reassembly (as in SAR_PDU) SDH Synchronous Digital Hierarchy SDU Service Data Unit (as in AAL_SDU) SIR Sustained Information Rate SMDS Switched Multi-Megabit Data Service SNAP SubNetwork Attachment Point (see IEEE 802.1a) SNI Subscriber Network Interface SSCS Service Specific Convergence Sublayer SSCOP Service Specific Connection Oriented Protocol SVC Switched Virtual Circuit UNI User to Network Interface VBR Variable Bit Rate VC Virtual Channel (not circuit) VCC Virtual Channel Connection VCI Virtual Channel Identifier VP Virtual Path VPC Virtual Path Connection Here are a few five dollar words which sometime come arise in this topic area. Plesiochronous: Signals which are arbitrarily close in frequency to some defined precision. They are not sourced from the same clock and so, over the long term, will be skewed from each other. Their relative closeness of allows a switch to cross connect, switch, or in some way processs them. That same inaccuracy of timing will force a switch, over time, to repeat or delete frames (called frame slips) in order to handle buffer underflow or overflow. Synchronous: Signals that are sourced from the same timing reference. These have the same frequency. (Contrast with Plesiochronous signals) Asynchronous: Signals that are sourced from independent clocks. These signals generally have no relation to each other and so have different frequencies and phase relationships. (Contrast with Plesiochronous signals) Isochronous: Signals which are dependant on some uniform timing or carry their own timing information embedded as part of the signal. SUBJECT: C11) + Where can I find the "Self Similar" Ethernet Traffic Study? FTP site for article 'Self Similar Nature of Ethernet' is: thumper.bellcore.com:/pub/wel SUBJECT: C12) + How can I get copies of ITU-T documents? You can buy these on paper from the ITU: ITU Place des Nations CH-1211 Geneva 20 Switzerland. The fax number of the sales office is +41 22 730 5194. They are also available commercially from at least 2 sources in the U.S.: Information Gatekeepers in Boston, MA (1-800-323-1088) Phillips Publishing (1-800-OMNICOM) Phillips usually has documents in stock & has fast delivery. Online access is limited. Some postings suggested telnet to: ties.itu.ch / 156.106.4.75 or chi.itu.ch / 156.106.4.16 Others suggest using gopher because that is what they are using. For gopher you'll need to use info.itu.ch if you want to use a local gopher client. ties and chi will refuse connections to port 70. You can also get copies of ITU documents using their auto-answering mailbox. Send mail to itudoc@itu.ch with GET ITU-4313 in the message body to get information how to get the documents, including I.363, that you want. Alternatively, send e-mail to itudoc@itu.ch with the single line HELP in the body of the message. That will get you information on the ITU's automatic mail server. Essentially you send a message to the above address with GET ITU-nnnn in the body, where nnnn is the document identifier number that you get by asking for ITU-1100, which is the index to the ITU I. series, including I.363. ITU-4313 also has directions how to use gopher: Name=International Telecommunications Union (ITU) Host=info.itu.ch Port=70 ----------------------------------------------------------------------------- TOPIC: D) ATM TECHNOLOGY QUESTIONS ----------------------------------------------------------------------------- SUBJECT: D1) What are the various ATM Adaptation layers? In order for ATM to support many kinds of services with different traffic characteristics and system requirements, it is necessary to adapt the different classes of applications to the ATM layer. This function is performed by the AAL, which is service-dependent. Four types of AAL were originally recommended by CCITT. Two of these have now been merged into one. Also, within the past year a fifth type of AAL has been proposed. Briefly the four ATM adaptation layers (AAL) have/are being defined: AAL1 - Supports connection-oriented services that require constant bit rates and have specific timing and delay requirements. Example are constant bit rate services like DS1 or DS3 transport. AAL2 - Supports connection-oriented services that do not require constant bit rates. In other words, variable bit rate applications like some video schemes. AAL3/4 - This AAL is intended for both connectionless and connection oriented variable bit rate services. Originally two distinct adaptation layers AAL3 and 4, they have been merged into a single AAL which name is AAL3/4 for historical reasons. AAL5 - Supports connection-oriented variable bit rate data services. It is a substantially lean AAL compaired with AAL3/4 at the expense of error recovery and built in retransmission. This tradeoff provides a smaller bandwidth overhead, simpler processing requirements, and reduced implementation complexity. Some organizations have proposed AAL5 for use with both connection-oriented and connectionless services. A recent document which describes these (except AAL2) with frame formats is: "Asynchronous Transfer Mode (ATM) and ATM Adaptation Layer (AAL) Protocols Generic Requirements", Bellcore Technical Advisory, TA-NWT-001113, Issue 1, August 1992. This can be obtained by writing to: Bellcore Document Registrar 445 South Street - Rm. 2J125 P.O. Box 1910 Morristown, NJ 07962-1910 SUBJECT: D2) Are ATM cells delivered in order? Yes. The ATM standards specify that all ATM cells will be delivered in order. Any switch and adaptation equipment design must take this into consideration. SUBJECT: D3) What do people mean by the term "traffic shaping"? Here is an explicit definition of traffic shaping followed by brief tutorial. Note that a variety of techniques have been investigated to implement traffic shaping. Reference the literature for keywords such as "leaky bucket", "congestion", "rate control", and "policing". Definition: Traffic shaping is forcing your traffic to conform to a certain specified behavior. Usually the specified behavior is a worst case or a worst case plus average case (i.e., at worst, this application will generate 100 Mbits/s of data for a maximum burst of 2 seconds and its average over any 10 second interval will be no more than 50 Mbit/s). Of course, understand that the specified behavior may closely match the way the traffic was going to behave anyway. But by knowing precisely how the traffic is going to behave, it is possible to allocate resources inside the network such that guarantees about availability of bandwidth and maximum delays can be given. Brief Tutorial: Assume some switches connected together which are carrying traffic. The problem to actually deliver the grade of service that has been promised, and that people are paying good money for. This requires some kind of resource management strategy, since congestion will be by far the greatest factor in data loss. You also need to charge enough to cover you costs and make a profit, but in such a way that you attract customers. There are a number of parameters and functions that need to be considered: PARAMETERS ---------- There are lots of traffic parameters that have been proposed for resource management. The more important ones are: mean bitrate peak bitrate variance of bitrate burst length burst frequency cell-loss rate cell-loss priority etc. etc. These parameters exist in three forms: (a) actual (b) measured, or estimated (c) declared (by the customer) FUNCTIONS --------- (a) Acceptance Function ----------------------- Each switch has the option of accepting a virtual circuit request based on the declared traffic parameters as given by the customer. Acceptance is given if the resulting traffic mix will not cause the switch to not achieve its quality of service goals. The acceptance process is gone through by every switch in a virtual circuit. If a downstream switch refuses to accept a connection, an alternate route might be tried. (b) Policing Function --------------------- Given that a switch at the edge of the network has accepted a virtual circuit request, it has to make sure the customer equipment keeps its promises. The policing function in some way estimates the the parameters of the incoming traffic and takes some action if they measure traffic exceeding agreed parameters. This action could be to drop the cells, mark them as being low cell-loss priority, etc. (c) Charging Function --------------------- The function most ignored by traffic researchers, but perhaps the most important for the success of any service! Basically, this function computes a charge from the estimated and agreed traffic parameters. (d) Traffic Shaping Function ---------------------------- Traffic shaping is something that happens in the customer premise equipment. If the Policing function is the policeman, and the charging function is the judge, then the traffic shaper is the lawyer. The traffic shaper uses information about the policing and charging functions in order to change the traffic characteristics of the customer's stream to get the lowest charge or the smallest cell-loss, etc. For example, an IP router attached to an ATM network might delay some cells slightly in order to reduce the peak rate and rate variance without affecting throughput. An MPEG codec that was operating in a situation where delay wasn't a problem might operate in a CBR mode. SUBJECT: D4) * What is happening with signalling standards for ATM? The Signaling Sub-Working Group (SWG) of the ATM Forum's Technical Committee has completed its implementation agreement on signaling at the ATM UNI (summer 1993). The protocol is based on Q93B with extensions to support point-to-multipoint connections. Agreements on addressing specify the use of GOSIP-style NSAPs for the (SNPA) address of an ATM end-point at the Private UNI, and the use of either or both GOSIP-style NSAPs and/or E.164 addresses at the Public UNI. The agreements have been documented as part of an updated (3.0) UNI specification. Additionally, the ANSI T1S1 as well as the ITU-T sudygroup XI are concerned with ATM signalling. In the latter half of 1993 a couple of things happened: 1) The ITU finally agreed to modify its version of Q93B to more closely to align it with that specified in the ATM Forum's UNI 3.0 specification. The remaining variations included some typos which the ITU Study Group found in the Forum's specification. Also, some problems were solved differently. Aligned yes, but the changes could still cause incompatibilities with UNI 3.0. 2) Given the above, the ATM Forum's signalling SWG decided to modify the Forum's specification to close the remaining gap and align it with the ITU. The end result may be declared as errata to UNI 3.0 or defined as a UNI 3.1 specification The ATM Forum also has a Private-NNI SWG. Their objective is to define an interface between one Switching System (SS) and another, where each SS is a group of one or more switches, such that the specification can be applied to both the switch-to-switch case and the network-to-network cases. SUBJECT: D5) What is VPI and VCI? ATM is a connection orientated protocol and as such there is a connection identifier in every cell header which explicitly associates a cell with a given virtual channel on a physical link. The connection identifier consists of two sub-fields, the Virtual Channel Identifier (VCI) and the Virtual Path Identifier (VPI). Together they are used in multiplexing, demultiplexing and switching a cell through the network. VCIs and VPIs are not addresses. They are explicitly assigned at each segment (link between ATM nodes) of a connection when a connection is established, and remain for the duration of the connection. Using the VCI/VPI the ATM layer can asynchronously interleave (multiplex) cells from multiple connections. SUBJECT: D6) Why both VPI *and* VCI? The Virtual Path concept originated with concerns over the cost of controlling BISDN networks. The idea was to group connections sharing common paths through the network into identifiable units (the Paths). Network management actions would then be applied to the smaller number of groups of connections (paths) instead of a larger number of individual connections (VCI). Management here including call setup, routing, failure management, bandwidth allocation etc. For example, use of Virtual Paths in an ATM network reduces the load on the control mechanisms because the function needed to set up a path through the network are performed only once for all subsequent Virtual Channels using that path. Changing the trunk mapping of a single Virtual Path can effect a route change for every Virtual Channel using that path. Now the basic operation of an ATM switch will be the same, no matter if it is handling a virtual path or virtual circuit. The switch must identify on the basis of the incomming cell's VPI, VCI, or both, which output port to forward a cell received on a given input port. It must also determine what the new values the VPI/VCI are on this output link, substituting these new values in the cell. SUBJECT: D7) How come an ATM cell is 53 bytes anyway? ATM cells are standardized at 53 bytes because it seemed like a good idea at the time! As it turns out, during the standardization process a conflict arose within the CCITT as to the payload size within an ATM cell. The US wanted 64 byte payloads because it was felt optimal for US networks. The Europeans and Japanese wanted 32 payloads because it was optimal for them. In the end 48 bytes was chosen as a compromise. So 48 bytes payload plus 5 bytes header is 53 bytes total. The two positions were not chosen for similar applications however. US proposed 64 bytes taking into consideration bandwidth utilization for data networks and efficient memory transfer (length of payload should be a power of 2 or at least a multiple of 4). 64 bytes fit both requirements. Europe proposed 32 bytes taking voice applications into consideration. At cell sizes >= 152, there is a talker echo problem. Cell sizes between 32-152 result in listener echo. Cell sizes <= 32 overcome both problems, under ideal conditions. CCITT chose 48 bytes as a compromise. As far as the header goes, 10% of payload was perceived as an upper bound on the acceptable overhead, so 5 bytes was chosen. SUBJECT: D8) How does AAL5 work? Here is is a very simplified view of AAL5 and AALs in general. AAL5 is a mechanism for segmentation and reassembly of packets. That is, it is a rulebook which sender and receiver agree upon for taking a long packet and dividing it up into cells. The sender's job is to segment the packet and build the set of cells to be sent. The receiver's job is to verify that the packet has been received intact without errors and to put it back together again. In AAL5, a packet is segmented as follows: - The packet is divided up into 48 byte chunks -- each chunk is placed into a separate cell (carried on the same VCI) - If the last chunk is from 1 to 40 bytes, then the last eight bytes in that cell are filled with the AAL5 trailer (2 bytes reserved, 2 bytes of packet length, and 4 bytes of CRC). (If the last chunk is less than 40 bytes, then padding is added to place the trailer at the end of the cell.) - If the last chunk is from 41 to 48 bytes, then that chunk is placed into a cell and an additional cell is added. In that additional cell, the last eight bytes are used for the AAL5 trailer and the rest is padding. - The payload type in the last cell (i.e., wherever the AAL5 trailer is) is marked to indicate that this is the last cell in a packet. (The receiver may assume that the next cell received on that VCI is the beginning of a new packet.) There are two problems that can happen during transit. First, a cell could be lost. In that case, the receiver can detect the problem either because the length does not correspond with the number of cells received, or because the CRC does not match what is calculated. Second, a bit error can occur within the payload. Since cells do not have any explicit error correction/detection mechanism, this cannot be detected except through the CRC mismatch. Note that it is up to higher layer protocols to deal with lost and corrupted packets. Most people assume that a corrupted packet will be handled by discarding it and treating it as if it were lost. SUBJECT: D9) What are the diffferences between Q.93B and Q.931? Essentially, Q.93B is an enhanced signalling protocol for call control at the Broadband-ISDN user-network interface, using the ATM transfer mode. The most important difference is that unlike Q.931 which manages fixed bandwidth circuit switched channels, Q.93B has to manage variable bandwidth virtual channels. So, it has to deal with new parameters such as ATM cell rate, AAL parameters (for layer 2), broadband bearer capability, etc. In addition, the ATM Forum has defined new functionality such as point-to-multipoint calls. The ITU-T Recommendation will specify interworking procedures for narrowband ISDN. SUBJECT: D10) + What is a DXI? 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 'cause 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: D11) + What is Goodput? When ATM is used to tranasport cells originating from higher-level protocols (HLP), an important consideration is the impact of ATM cell loss on that protocol or at least the segmentation processs. ATM cell loss can cause the effective throughput of some HLPs to be arbitrarily poor depending on ATM switch buffer size, HLP congestion control mechanisms, and packet size. This occurs because during congestion for example, and ATM switch buffer can overflow which will cause cells to be dropped from multiple packets, runining each such packet. The preceding and the remaining cells from such packets, which are ultimately discarded by the frame reassembly process in the receiver, are nevertheless transmitted on an already congested link, thus wasting valuable link bandwidth. The traffic represented by these "bad" cells may be termed as BADPUT. Correspondingly, the effective throughput, as determined by those cells which are successfully recombined at the receiver, can be termed as GOODPUT. SUBJECT: D12) + What is LAN Emulation all about? "LAN Emulation" is a work in progress in the ATM Forum. There is not a complete agreement on all aspects of LAN Emulation, but there is good agreement on the requirements and general approach. Here's the basics: The organizations working on it say LAN Emulation is 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. LAN Emulation 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. The technical approach being discussed in the Forum among companies with interest and expertise in this area include three elements: 1) Multicast/broadcast support Since almost all LAN protocols depend on broadcast or multicast packet delivery, an ATM LAN must provide the same service. Ideally, this would use some sort of multipoint virtual circuit facility. 2) Mac address to ATM address resolution. There are two basic variations being discussed: a) do an ARP-like protocol to ask for a mapping from Mac address to ATM address b) send packets to some sort of directory or cache server that sends the destination ATM address back to the source as a sort of side effect of delivering the packet. 3) Switched Virtual Circuit Management It is generally desireable (for scalabilitiy, quality of service, etc) to set up point-to-point virtual circuits between endpoints that want to communicate with each other (client to file server, for example) once the two atm addresses are known. To make this work in the existing legacy LAN environment, we don't have the freedom to push knowledge or management of these virtual circuits up above the MAC level (no protocol changes, remember?) so the logic to resovle for an ATM address and set up a virtual circuit on demand must be in the LAN Emulation layer. This would include recognising when an SVC to another ATM endpoint already existed, so that the same circuit could be used for other traffic. 4) Mac definition The actual packet format would be some variant of the packets used on existing networks. For example, a packet leaving an Ethernet to go over a virtual circuit to an ATM-attached file server would probably be carried directly over AAL5, with some additional control information. SUBJECT: D13) + Information about the Classical IP over ATM approach. RFC1483 defines the encapsulation of IP datagrams 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 the RFCs for a full description of this approach. SUBJECT: D14) + Classical IP and LAN/MAC Emulation approaches compaired. The IETF scheme defines an encapsulation and an address resolution mechanism. The encapsulation could be applied to a lot of LAN protocols but the address resolution mechanism is specifically defined (only) for IP. Further, the IETF has not (yet) defined a multicast capability. So, those protocols which require multicast definitely cannot adapt the IETF scheme for their own use. The purpose behind the ATM Forum's LAN-Emulation effort is to allow existing applications (i.e., layer-3 and above protocol stacks) to run *with no changes* over ATM. Thus, the mapping for all protocols is already defined. In a PC environment, such applications tend to run over an NDIS/ODI/etc. interface. The LAN-Emulation effort aims to be able to be implementable underneath the NDIS/ODI-type interface. In contrast to LAN-Emulation, the IETF's scheme will allow IP to make better use of ATM capabilities (e.g., the larger MTU sizes), and for unicast traffic will be more efficient than having the additional LAN-Emulation layer. However, the Classical draft suggests that IP multicast (e.g., the MBONE) will have to be tunnelled over ATM; I suspect this will be less efficient than LAN-Emulation. For better or worse, I think both are going to be used. So, vendors may have to do both. The worse part is extra drivers (or extra code in one driver that does both). The better part is that all existing LAN applications can use one (LAN Emulation), and over time (as their mapping to ATM is fully defined) can transition to use the other (IETF Scheme). I would summarize LAN-Emulation as follows: The advantage of LAN-Emulation is that the applications don't know they're running over ATM. The disadvantage of LAN-Emulation is also that the applications don't know they're running over ATM. ----------------------------------------------------------------------------- TOPIC: E) TOPIC: ATM VS. XYZ TECHNOLOGY ----------------------------------------------------------------------------- SUBJECT: E1) * How does ATM differ from SMDS? SMDS is the Switched Multi-megabit Data Service, a service offering interface from Bellcore. SMDS provides a datagram service, where a packet has about a 40-octet header plus up to 9188 octets of data. The packets themselves may or may not be transported within the network on top of a connection- oriented ATM service. SMDS uses E.164 (ISDN) addresses. Therefore SMDS is a connectionless packet switched *service*, not a cell-relay service. HOWEVER, the SMDS Subscriber Network Interface is currently defined to use IEEE 802.6 Distributed Queue Dual Bus (DQDB) access across the SMDS user-network interface. DQDB itself *is* a form of cell relay. The lower layers of SMDS fragment the packets into cells with a 5-octet header and 48-octet payload. The payload itself has a 2-octet header, 44-octets of data, plus a 2-octet trailer. An SMDS cell therefore is nearly identical in form to an AAL3/4 cell. Note that while DQDB is used as the access protocol, either DQDB or AAL3/4 may be used for the switch-to-switch interface. The best source of (readable) information on SMDS is probably the SMDS Interest Group (SIG), 480 San Antonio Road, Suite 100, Mountain View, California 94040, USA; Tel +1 415 962 2590; Fax +1 415 941 0849. The SIG is in many ways similar to the ATM Forum, and cooperates with it. Also, there is a European branch known as ESIG which is concerned with adapting the American SIG documents to fit European network architectures and regulations. SIG work is mostly based on Bellcore SMDS TAs and such like, while ESIG aligns with ITU and ETSI standards. ----------------------------------------------------------------------------- TOPIC: F) TOPIC: FREELY AVAILABLE REFERENCE IMPLEMENTATIONS ----------------------------------------------------------------------------- SUBJECT: F1) What and where is VINCE? Vince has now on record as the first "publicaly available" software source code in the ATM technology area. This work was carried out by the Research Networks section of the Center for Computational Science at the Naval Research Laboratory, with support from the Advanced Research Projects Agency and NAVSEA. In the Grand Internet Tradition, these fine folks have contributed their efforts to the community in support of further research. VINCE RELEASE 0.6 ALPHA Vince, the Vendor Independent Network Control Entity, is publicly available (in source code form) as an alpha release. Its primary function is to perform ATM signalling and VC management tasks. It currently includes a hardware module that allows it to run on Fore ASX-100(tm) switches. Other hardware modules are under development. Vince consists of a core which provides basic ATM network semantics, and modules to perform specific functions. Modules included in this release are: spans - module which intereroperates signalling and routing with Fore Systems ASX switch and various host interfaces. SPANS is (tm) Fore Systems, Inc. q93b - an implementation of signalling as specified in the ATM Forum UNI 3.0 document. The vince core includes sscop and aal5 in its protocol library. sim - a software ATM switch or host that can be used to test signalling and routing implementations without ATM hardware. sroute - an address independent VC routing module. The Vince distribution also contains a driver that uses spans for signalling and supports the Fore Systems SBA-100 under SunOS(tm). Work has already begun on a kernel version of Vince, which will allow ATM Forum UNI signalling for hosts. Also in development are SNMP/ILMI support, interdomain routing, and support for other switches. The intent is to provide a redistributable framework which allows for code sharing among ATM protocol developers. Vince and its architecture document are available for anonymous ftp at hsdndev.harvard.edu:pub/mankin A mailing list for Vince developers and users can be joined by sending mail to vince-request@cmf.nrl.navy.mil. ----------------------------------------------------------------------------- TOPIC: G) + TOPIC: FLAMES AND RECURRING HOLY WARS ----------------------------------------------------------------------------- As with any News and/or email list, topics will be raised which elicit a broad range of viewpoints. Often these are quite polarized and yield a chain of replies and counter topics which can span weeks and even months. Typically without resolution or group consensus. This section lists some memorable (lengthy?) topic threads. PLEASE NOTE that the idea here is not to re-kindle old flames, and not to somehow pronounce some conclusion. Rather, recorded here are are a few pieces of the dialogue containing information which might be of some use. SUBJECT: G1) + Are big buffers in ATM switches needed to support TCP/IP? A recurring theme in 1993 concerned the suitability of ATM to transport TCP/IP based traffic. The arguments generally centered around the possible need for ATM WAN switches to support very large buffers such that TCP's reactive congestion control mechanism will work. Points of contention include: are big buffers needed, if so then where, and what exactly is the TCP congestion control mechanism. Undoubtedly, many of these discussions have been fueled by some 1993 studies which reported that TCP works poorly over ATM because of the cell-discard phenomenon coupled with TCP's congestion control scheme. The longest thread on this subject started in the October 1993 timeframe and ended in December under the subject of "Fairness on ATM Networks". Generally folks expressed opinions in one of the following postures: 1) Big buffers are not needed at all.... A few argued that if ATM VC's are provisioned and treated as fixed leased lines then ATM will be able to support TCP/IP just fine. This means that you would need to subscribe to the maximum possible burst rate which would be very inefficient use of bandwidth since TCP is usually very bursty. 2) Put big buffers in routers and not ATM switches.... If you are using wide-area links over ATM, then use a router smart enough not to violate the Call-Acceptance contract. The call acceptance function should be such that it doesn't let you negotiate a contract that causes congestion. Congestion should only occur when there is a fault in the network. A router is quite capable of smoothing out bursts. That is what they do right now when they operate over leased lines. The advantage of an ATM connection replacing a leased line is that the connection parameters can be able to be renegotiated on the fly, so if your IP network (as opposed to the ATM network) is experiencing congestion, then it can request more bandwidth. Supporting this thinking is the notion that for most data networks using ATM as their wide-area medium, a router would likely be the access point with many TCP connections being concentrated on a given ATM connection. 3) Still others suggest that ATM switches should implement priorities and that there should be different buffer sizes allocated per priority. The different priorities and associated buffer sizes would support traffic separation, trading off cell loss for delay. So for example, "voice" traffic could have small buffer sizes and "data" traffic could have big buffer sizes. The switches would then provide the buffering necessary to support TCP's reactive congestion control algorithms. Some folks argued that this would be "expensive" to implement. Regardless, many new switches being anounced in 1993/4 claim to have such priorities and buffer size capabilities. Finally many folks were not clear on the differing TCP reactive congestion control mechanisms. A quick summary follows: In the original algorithm, the TCP goes into slow-start when a packet loss is detected. In slow-start, the window is set to one packet and increased by one for every acknowledgement received until the window size is half what it was before the packet is dropped. You get a series of larger and larger bursts but the largest causes half the number of packets to be buffered as there were before the packet drop occurred. Hence there is no burst until the window size is half what it was before the packet is dropped and is then increased at a much lower rate, 1/(window size) for each acknowledgement. This window control algorithm ensures that the only bursts generated are probably small enough to be no problem. In the Reno algorithm, the window is halved so that packets start being sent in response to acknowledgements again after half the old window's of acknowledgements have been received. Hence there is no "burst" of packets generated. The only packess generated are in response to acknowledgements, and only after half an old window of acknowledgements are received. For more information check out Van Jacoboson's algorithms published in ACM SIGCOMM 1988. SUBJECT: G2) + Can AAL5 be used for connection-less protocols? This thread started with questions about wether AAL5 supports connection oriented or connection-less protocols. Check the November and December 1993 archives for the subject: "AAL Type 5 question". First some background --------------------- Officially, AAL 5 provides support for adaption of higher layer connection- oriented protocols to the connection-oriented ATM protocol. There was, however, a debate going on, claiming, that AAL 5 could also be used to adapt higher layer connectionless protocols to the connection-oriented ATM protocol. The whole debate is grounded in a systematical approach of the ITU-T, which states, that all AALs should be classified into four different classes, to minimise the number of AALs required for supporting any imaginable service. The classification of the ITU-T is as follows: +------------------------+-----------+-----------+-----------+-----------+ | | Class A | Class B | Class C | Class D | +------------------------+-----------+-----------+-----------------------+ |Timing relation between | Required | Not Required | |source and destination | | | +------------------------+-----------+-----------+-----------------------+ | Bit Rate | Constant | Variable | +------------------------+-----------+-----------------------+-----------+ | Connection Mode | Connection-Oriented |Connection-| | | | less | +------------------------+-----------------------------------+-----------+ AAL 5 is currently agreed to be in Class C. Some parties at the standardisation bodies claim that it could be as well in Class D. At the moment the following mapping between AALs and classes applies: Class A: AAL 1 Class B: AAL 2 Class C: AAL 3/4, AAL 5 Class D: AAL 3/4 The reason for AAL3/4 in classes C and D is the follwing: The ITU-T started to define AAL3 for Class C and AAL 4 for Class D. They turned out to be identical after long debates. Reality Check ------------- The real issue is how to run a connection-less service over ATM which is inherently connection-oriented. AALs themselfs merely transport higher layer packets across an ATM virtual circuit. Connection-less services are actually provided by higher layer protocols such as CLNAP. Given that, there is nothing to prevent folks from using AAL5 to implement a connection-less communication mode. This is exactly what the IETF is doing with IP over ATM, and what the ATM Forum is also doing with LAN Emulation. The reality is that these folks expect that AAL5 will be largely used for connection-less upper layer protocols such as CLNP and IP. So some find it strange to have AAL5 classified as an AAL for connection- oriented services only. However, from an ITU-T service Class perspective, you must stick strictly to the view that to call an AAL "Class D" it must support each and every posssible connection-less protocol. The current agreement in the ITU-T is that AAL5 can not claim this and so is officially considered a "Class C" AAL. ----------------------------------------------------------------------------- CONTRIBUTORS This FAQ is a collective work which has been compiled by and is maintained by Carl Symborski. The information contained herein has been gathered from a variety of sources. Most derived from a consensus of postings on the cell-relay group. The following individuals have provided direct contributions to this FAQ, either by posting to the cell-relay list or by private EMail coorespondance. If you would like to claim responsibility for a particular item, please let me know. Reto Beeler, beeler@tech.ascom.ch Kingston Duffie, kduffie@netcom.com A. Gavras, ag@fokus.gmd.de Rajeev Gupta, r_gupta@trillium.com Mark Jeffrey, mtj@ncp.gpt.co.uk Gary C. Kessler, kumquat@smcvax.smcvt.edu Mark Laubach, laubach@hpl.hp.com Matthew Maa, maa@edsdrd.eds.com George Marshall, george@helios.adaptive.com Keith McCloghrie, kzm@cisco.com Chris O'Neill, c.oneill@trl.oz.au Craig Partridge, craig@bbn.com Vijay Rangarajan vijay@ncsa.uiuc.edu Allen Robel, robelr@indiana.edu Lee D. Rothstein, ldr@veritech.com Jukka Saukkonen, jukka.saukkonen@sandiegoca.ncr.com Carl Symborski, carl@umd5.umd.edu Mark Williams, miw@cc.uq.edu.au Mark, mark@viper.cwru.edu ------ END OF FAQ -------