Cell Relay Archive

Cell Relay Retreat>List Archive>month:1998-Oct> msg00125



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Re: ppp over atm...why?

  • From: James Carlson <carlson@ironbridgenetworks.com>
  • Date: 22 Oct 1998 08:56:51 -0400

albert.e.manfredi@boeing.com writes:
> In principle, there is no reason to restrict the VCs from a future ATM-capable
> ISP to a residence to carrying just one protocol. PPP provides the link layer
> that allows you to carry many different packet types over the VC. AAL5 by
> itself, as I said before, doesn't do this. See RFC 1483 for more discussion on
> this, using options other than PPP.

This is text from RFC 1483:

   The presence of a SNAP header is indicated by the LLC header value
   0xAA-AA-03. A SNAP header is of the form

               +------+------+------+------+------+
               |         OUI        |     PID     |
               +------+------+------+------+------+

   The three-octet Organizationally Unique Identifier (OUI) identifies
   an organization which administers the meaning of the following two
   octet Protocol Identifier (PID).  Together they identify a distinct
   routed or bridged protocol.  The OUI value 0x00-00-00 specifies that
   the following PID is an EtherType.

You *can* carry multiple protocol types over a single AAL-5 VC without
using PPP if you're willing to use LLC/SNAP and forgo negotiation.
That's what I said.  You can even do it without LLC/SNAP if you're
willing to dedicate separate VCs.

I think we're both arguing from the same side here.

> (If you really want to get twisted, you can also use AAL5 exclusively, for
> voice CBR channels and data channels, as far as that goes.)

Not at all twisted.  Frankly, I think that using AAL-1 for voice is
pretty twisted.  Each VC represents persistent state through the core
of the network.  Doing that for a high bandwidth multiplexed
connection (say, a trunk between Class 5 switches) makes sense.  Doing
it for each person gabbing to another does not.

Furthermore, voice really isn't all that sensitive to delay, which is
the real criterion on which you'd choose CBR over other schemes.  As
long as you stay within 20-50ms or so of buffering -- easily
achievable on packet switched networks -- then the echo cancellation
is stable, and that humans won't notice.  (This, combined with the
fact that packet switching is cheaper to implement and maintain than
circuit switching, is likely going to allow folks working on voice
over IP to become very, very wealthy in the near future.)

(Of course, if you can find a way to work without hybrids, then the
cancellation problem also goes away ...)

(Video distribution is even easier, since there's no echo to consider,
and buffering is essentially invisible.)

I can't say I'm a huge fan of cell switching.

> Let me try rewording, then. If you use AAL1 instead of AAL5 even for the data
> VCs, the ATM VC will _not_ give you any inherent packet delimiting feature.
> AAL1 gives you what amounts to a serial link, which can be either CBR, VBR,
> ABR, or UBR. So if the ISP decides to use AAL1, PPP's packet delimiting
> feature would also be a required feature.

There is no definition of PPP over AAL-1.  I'm sure it would be easy
to define some reasonable set of options for the HDLC framing
necessary (which is what you're referring to as PPP's packet
delimiting feature), but nobody has done this, and the solution would
be proprietary.

-- 
James Carlson, Consulting S/W Engineer  <carlson@ironbridgenetworks.com>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA          42.423N    Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp