Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!ATHENA.MIT.EDU!martillo
From: martillo@ATHENA.MIT.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Station wagon full of bits (Frame-Relay)
Message-ID: <8703301458.AA18974@HECTOR.MIT.EDU>
Date: Mon, 30-Mar-87 09:58:07 EST
Article-I.D.: HECTOR.8703301458.AA18974
Posted: Mon Mar 30 09:58:07 1987
Date-Received: Tue, 31-Mar-87 05:48:16 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 23
Approved: tcp-ip@sri-nic.arpa



I confess to not having thought about it too much, but my impression
is frame relay simply permits the passage of level 2 packets on the
basis of level 2 address through the switch to some place in the phone
network where full level 2 processing can be handled.  This means that
the switch can basically concentrate on tdm switching problems while
the level 2 termination point can concentrate statistical muxing
switching problems.  Such a division makes sense as a way to optimise
CSC switch or packet switch performance.

In the asynchronous world LAPD could per passed on a 64 KBPS
unrestricted data circuit to a terminal concentrator and each LAPD
virtual level 2 could correspond to an asynchronous terminal.  While I
consider asynchronous terminal concentrators a backward-looking
technology, in the business world lots of firm want such devices.
Obviously this is not an OSI application, but the separation of the
problem into a physical channel, multiple virtual level 2s, and a flow
control layer on top of this has clearly been influenced by concepts
of layering, and LAPD terminal multiplexing seems more sensible than
the PAD protocols.

Yaqim Martillo