Subject: Re: PPP Payload in L2TP

From: christian hublet we21 7848 <[email-masked]>
Date: Wed, 11 Feb 1998 13:45:35 +0100

Hi,

I completely agree with Walter. I also see this as an issue and it is related to the framing used for PPP.

We are also implementing PPP over AAL5 in combination with L2TP. If we play the
role of the LAC, what can we expect from the LNS in the case of outgoing calls ?
Will the LNS assume to send PPP in an ISDN or ATM or ...  framing ?

In short what is the use of the control and address byte in the L2TP packet ?

Why not transport the PDU's compliant to RFC 1661 (PPP) over an L2TP tunnel ?
Currently it looks like transporting PDU's compliant to RFC 1662 
(PPP in HDLC-like framing) over an L2TP tunnel. In other words, why send medium
dependent PPP if we can send medium independent PPP.

Thanks, Chris

----- Begin Included Message -----

>From [email-masked] Wed Feb 11 09:44:13 1998
From: "Walter Klausberger" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: PPP Payload in L2TP
Date: Wed, 11 Feb 1998 09:46:09 +0100
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-Msmail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [email-masked]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by merit.edu id DAA19172
Content-Length: 2516

Well that is the main problem. How should the LNS know, what header is us=
ed
for PPP at the LAC?

During establishment of the tunnel-session (Incoming-Call-Request) the LN=
S
is only informed if the PPP is transported over analog or digital channel
(Bearer Type). With the message Incoming-Call-Connected the AVP "Framing
Type" must be sent. But the LNS is only informed if asynch. or synch.
framing is used, not which type of synch. framing (e.g. HDLC, PPP in Fram=
e
Relay, PPP over AAL5/ATM).

I think this is a problem.

Thanks, Walter
-----Urspr=FCngliche Nachricht-----
Von: [email-masked] <[email-masked]>
An: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Datum: Dienstag, 10. Februar 1998 20:05
Betreff: Re: PPP Payload in L2TP

>Rich,
>
>Perhaps I am misunderstanding your remark, but PPP in Frame Relay says t=
he
>frame format is:
>
>   +-+-+-+-+-+-+-+-+
>   |  Flag (0x7e)  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         Q.922 Address         |    Control    |  NLPID(0xcf)  |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |         PPP Protocol          |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>If link framing is only the flag sequence, and the LAC only strips this
>portion, the LNS would see the Q.922 header in full.  Is this the intent=
 of
>the L2TP text?
>
>Thanks
>--
>Rene Tio <[email-masked]>
>
>
>> From [email-masked]  Tue Feb 10 09:25:40 1998
>>
>> Walter Klausberger wrote:
>> >
>> > Hi
>> > I have a question about PPP over L2TP.
>> >
>> > In L2TP Draft, Page 8 (end of page) is written:
>> > Frames from the remote user are received at the POP, stripped of CRC=
,
>> > link
>> > framing, and transparency bytes,...
>> >
>> > Question: If the PPP connection works over ISDN (synch. HDLC Framing=
)
>> > does the address and control field belong to the link framing, or ar=
e
>> > they
>> > also encapsulated into L2TP.
>> >
>>
>> Address and control field are encapsulated into L2TP as necessary (i.e.
>> when present).  In the case of HDLC I believe "link framing" would
>> consist of the "flag sequence" which would of course not be encapsulat=
ed
>> in L2TP.
>>
>> Richard.
>>
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> Richard Shea                                  [email-masked]
>> Bay Networks, Extranet Access                     978-266-1011 x210
>>
>

----- End Included Message -----

---

From: Richard Shea <[email-masked]>
Date: Wed, 11 Feb 1998 08:35:23 -0500

> dependent PPP if we can send medium independent PPP.

I think the two sticky issues with RFC 1662 is that there are LCP
options related to the framing (ACFC) and also ACFC can be used on any
packet except LCP packets.

So, when tunneling HDLC ppp traffic, the LNS could tell the LAC that
ACFC was negotiated, but the LAC would have to know if the traffic was
LCP or not in order to do the right things with the AC fields.

So there are three ways I can think of for dealing with this:

(1) The way it is today.
(2) Have the LACs "snoop" to recognize LCP traffic.
(3) Having a bit in the L2TP encapsulation payload indicating to the LAC
when the encapsulated payload is LCP.

Of these, I think (3) might be the best option.  I'm not confident that
I understand the architecture of all of the LACs out there enough to
know if this is really viable.  It is a question which should definitely
be taken-up on the L2TP mailing list ([email-masked],
[email-masked]).

The problem with (1) is that it sets a precedent for the LNS to have to
know the framing information (and incur the byte overhead of having to
send the framing information between the LNS and LAC).

The problems with (2) are actually being discussed right now on the L2TP
mailing list, and I don't think it sounds like a viable option.

Richard.