informis
/
textfiles
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
textfiles/internet/FAQ/cellrela.faq

1557 lines
69 KiB
Plaintext
Raw Permalink Blame History

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 -------
Reference in New Issue View Git Blame Copy Permalink