Cell Relay Archive

[albert.e.manfredi@boeing.com]

In article <86vhld95a3.fsf@ironbridgenetworks.com>,
  James Carlson <carlson@ironbridgenetworks.com> wrote:
> albert.e.manfredi@boeing.com writes:
> > Please see RFC 1171:
>
> 1171 is quite obsolete.  Try RFC 1661.

Okay, you got that.

> > PPP in essence provides the overhead functions, over a serial link, that
> > Ethernet or FDDI overhead provide over their media. One of which is to
> > identify the protocol used by the data packet. You will note that AAL5 does
> > not do this.
>
> That's almost correct.  AAL5 is like Frame Relay -- it provides an
> addressing structure (the VPI+VCI pair) that can be used to segregate
> multiple streams.  This can be done entirely by prior arrangement --
> no PPP needed at all -- and the VCs are just used as packet-oriented
> pipes between routers, as Frame Relay PVCs are today.

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.

An ISP might want to limit the number of VCs it must maintain at any given
time, so this feature of PPP is a useful addition to AAL5 alone. And, for that
matter, if an ISP is using PPP, perhaps that ISP might choose to use AAL1 for
everything, instead of using AAL1 for voice only and AAL5 for data.

(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.)

> > So the encapsulation
> > feature of PPP would not be of added value, but the link layer of PPP would
> > be needed. If you're using other AALs, e.g. AAL1 for any reason, you would
> > need to have something encapsulate the data packets.
>
> Huh?  That doesn't really make sense.  The "encapsulation" that PPP
> provides gives negotiated multiprotocol support over that single VC.
> PPP *IS* the link layer, so I don't know what you mean by having the
> PPP link layer but not the encapsulation.

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.

> > PPP also provides a link quality check, set up and tear down the link, and
> > protocol configuration options (but assigning of addresses is not specified
in
> > PPP).
>
> Wrong.  Network layer addresses are assigned by the various NCPs.
> IPCP (RFC 1332), for instance, negotiates IP addresses between the
> peers.

Okay, I'll give you that.

> > So if you have PPP over the ATM VC, in principle you could terminate the
> > IP session and start something else, without having to tear down the
> > VC.
>
> You can do much, much more.  You can run multiple simultaneous
> protocols over the same VC if you're running PPP.

Gee, that's sounds like an echo, don't it? That's what the link layer services
I was mentioning provide you. AAL5 does not have a built-in link layer, so
either you dedicate the particular VC to _one_ protocol, or you put something
between AAL5 and the network layer packet. PPP or the options in RFC 1483 will
do the trick.

Bert
manfredi@arl.bna.boeing.com

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own