Subject: PPP over AAL5 LCP negotiation

From: [email-masked] (luna3!gmg)
Date: Wed, 4 Mar 1998 13:52:07 -0500

Hi,
	I'm posting the following E-mail exchange to the list with
Dirk Van Aten's permission. It contains comments that might be useful
to PPP over AAL5 implementors...

	George
-------------------- begin forwarded message --------------------
> From [email-masked] Tue Mar  3 08:33 EST 1998
> Return-Path: <[email-masked]>
> Received: from alig1.firewall.lucent.com by luna3.lc.lucent.com (SMI-8.6/EMS-1.3.1 sol2)
> 	id IAA03043; Tue, 3 Mar 1998 08:33:50 -0500
> Received: by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
> 	id IAA02224; Tue, 3 Mar 1998 08:48:43 -0500
> Received: by alig1.firewall.lucent.com (SMI-8.6/EMS-L sol2)
> 	id IAA02207; Tue, 3 Mar 1998 08:48:41 -0500
> Received: by algw1.lucent.com; Tue Mar  3 08:43 EST 1998
> Received: from localhost (uucp@localhost) by btmplq.god.bel.alcatel.be (8.6.5/8.6.5) id OAA18372 for <[email-masked]>; Tue, 3 Mar 1998 14:34:47 +0100
> Received: from we2ws260.sebb.bel.alcatel.be(138.203.169.5) by btmplq via smap (V1.3)
> 	id sma018349; Tue Mar  3 14:34:40 1998
> From: [email-masked]
> Date: Tue, 3 Mar 1998 14:34:47 +0100
> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: Questions about draft-ietf-pppext-aal5-04.txt.
> Cc: [email-masked]
> X-Sun-Charset: US-ASCII
> Content-Type: text
> Content-Length: 3421
> Status: R
> 
> Hello George,
> 
> 
> I have a few questions about draft-ietf-pppext-aal5-04.txt. Maybe you can give me
> some clarifications ?
> 
> 
> We are creating a PPP over AAL5 IWU hence according to the draft PPP/AAL5 RFC:
> 
> "the LCP framing options MUST be actively negotiated by the bridging converters
> independently of the LCP framing options in use by other physical layer sections."
> 
> I understand the above paragraph as follows:
> 
> 1) there are LCP options which are negotiated end-to-end e.g., authentication protocol,
> protocol field compression etc.. and LCP options which are negotiated segment per segment
> e.g. FCS alternatives, ACFC etc..
> 
> This sounds logical to me in the sense that if one uses multiple segments based on 
> various technologies (ATM, STM etc ..) to transport PPP packets, it is just normal
> that the frame or "physical"-layer related LCP options are negotiated locally as these
> apply to that segment only.
> 
> Is my view correct ?
> 

Yes, your summary is accurate. There was a series of threads on this topic
discussed on the PPP extensions working group list last September/October.
The result was a BCP authored by Bill Simpson on "bridging convertors".
Unfortunately, the recent attempt to revise the L2TP specification to
embrace this "segment by segment" approach to LCP negotiation didn't succeed.

> 
> 2) ACFC applied to LLC based encapsulation (theoretical case).
> 
> I had a discussion over ACFC for LLC encapsulation with one of our guys implementing PPP/AAL5.
> My view is that if you apply ACFC to LLC encapsulation the sequences might look like below:
> 
>   a) ACFC not negotiated:
>   FE FE 03 CF 00 21 ... IP packet
>   FE FE 03 CF C0 21 ... LCP packet
>   FE FE 03 CF 00 2B ... IPX packet
>   
> 
>   b) ACFC negotiated:
>   CF 00 21 ... IP packet
>   FE FE 03 CF C0 21 ... LCP packet
>   CF 00 2B ... IPX packet
> 
> (I am fully aware that a LCP ACFC request must be rejected but I want to verify my view on Address
> and Control field for AAL5.)
>   
> I assume that address and control field for AAL5 are the LLC header which yields DSAP=FE SSAP=FE CONTROL=03.
> 
> Am I correct ?
> 
Well, no and yes... as you are aware, the ACFC option is intended for HDLC
framing. Applying it to AAL5 is not really "right".  ACFC, ACCM, and FCS
alternatives are all examples of physical media specific LCP options that are
not applicable to AAL5.  That is why the ID requires that they be rejected.

But what you are indirectly suggesting is using a new AAL5-specific LCP
option could negotiate the use of VC-multiplexing versus LLC-encapsulation.
But before we jump to the conclusion that this should be proposed, I think
we'd need to take a harder look.  The Q.2931 signaling protocol already does
this negotiation for SVCs; for PVCs it is part of the provisioning process.
I could see that for the situation where an ADSL subscriber is talking to
a RFC1973 compliant end point through an ATM/FR IWF, that this could be
a way to simplify their PVC configuration process. But there is a gotcha...

I guess my main problem with this is that LLC-encapsulation usually implies
that multiple protocols are being transported across the PVC. This avoids the
tariffs that would otherwise occur if there were multiple parallel VCs, each
carrying only a single protocol. But what happens when this new LCP option
turns off LLC-encapsulation while other protocol stacks are still sharing
the use of the PVC with PPP? Remember, by definition, LCP options are allowed
to be re-negotiated at any time as per RFC1661. If you fail to negotiate
mutally acceptable option values, then the link goes down.

> 
> What about NLPID 0xCF then ? Is it part of the address and Control Field and should it
> be compressed too (again theoretical case) ?
> 
> In this case there is practically no difference anymore between LLC encapsulation
> and VC Based Multiplexing .. ?
> 
A person's preference for LLC encapsulation versus VC-mux seems to be
largely religous. Each method has its merits within its respective usage
context.
> 
> 3) VC Based Multiplexing
> 
> Some weeks ago I wrote an email to Philip Rakity of Flowpoint (actually I first
> addressed these questions to him but I still got no reply. Maybe he's on business trip ..).
> 
> So Philip wrote:
> > In VC Multiplexing the PPP frame starts with the PPP Protocol ID.  There
> > is no need for flags, an address, or a control field, since the PPP frame
> > is protected by the AAL5 encoding. So, a few bytes are saved.  It is
> > equivalent to LCP negotiating Address Field Compression except it also
> > applies to LCP.
> 
> May I interprete this that for VC_Mux it appears that ACFC has been "negotiated" but
> that in this case you do not comply with RFC 1661 stating that LCP packets
> may never be send ACFC compressed but you cannot fully comply as VC_Mux has no
> address or control field ?
> 

As stated above, ACFC is an HDLC physical media specific LCP option.
The presence of an LLC header is not negotiated by the ACFC option.

If the use of LLC-encapsulation was a mandatory part of the AAL5 framing for
PPP over AAL5 payloads, then having an LCP option to remove it would make
sense. But LLC encapsulation is _optional_ and it is selected through non-PPP
mechanisms, so IMHO having an LCP option for it as another selection mechanism
is redundant. It also has the problem noted above when sharing the PVC...
> 
> These were my questions so maybe you can shed some light on this matter ...
> 
> 
> Anyway, thank you in advance for taking some time to read this.
> 
> Best regards, 
> 
> 
> Dirk Van Aken
> ______________________________________________________________________________
>             _
>             V              Dirk Van Aken  email: [email-masked]
> +-----------------------+                         
> |  A  L  C  A  T  E  L  |  Alcatel Bell Telephone, Dept. WE3
> +-----------------------+  F. Wellesplein 1              Phone: 32 3 240 7901
>       BELL TELEPHONE       B-2018 Antwerpen, BELGIUM       Fax: 32 3 240 9919
> ______________________________________________________________________________
> 
> 
> 
-------------------- end of forwarded message --------------------