Subject: Re: PPP Payload in L2TP

From: "Walter Klausberger" <[email-masked]>
Date: Wed, 11 Feb 1998 09:46:09 +0100

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

During establishment of the tunnel-session (Incoming-Call-Request) the LNS
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 Frame
Relay, PPP over AAL5/ATM).

I think this is a problem.

Thanks, Walter
-----Ursprüngliche 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 the
>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 are
>> > 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 encapsulated
>> in L2TP.
>>
>> Richard.
>>
>> -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
>> Richard Shea                                  [email-masked]
>> Bay Networks, Extranet Access                     978-266-1011 x210
>>
>

---

From: "Walter Klausberger" <[email-masked]>
Date: Wed, 11 Feb 1998 15:13:45 +0100

Hi,
Why send PPP in HDLC-like framing? That's what I was asking myself the first
time when I read the L2TP Draft. I think that most PPP implementations have
an synch. HDLC or asynch. Interface (eg. V.24). So you have to provide an
HDLC (or serial) compatible interface for these implementations. The
existing hardware drivers normally strip the flags and the CRC from the
framed PPP packet. So the inventors of L2TP proposed this remaining PDU as
"payload" for L2TP.

This explains the sentence "The virtual interface behaves very much like a
hardware interface with the exception that the hardware in this case is
physically located at the ISP POP" (L2TP Draft Page 9, beginning of page).
If this was intended then there should have been more variations for the AVP
Framing Type (like AAL5 or PPP over Frame Relay) or otherwise the ISP will
always assume HDLC framing in case of digital framing type.

We plan to build a LAC based on a 2-part embedded platform. The Interface
part provides several interfaces (ISDN, ATM, High Speed Bitrate Line
Cards,...) towards the users. On the other hand there is an ATM connection
to the second part (LAC functionality). So PPP connections over ISDN will be
forwarded by the first part over an ATM VCI/VPI connection (framed with
AAL5) to the second part.

So you see there is a need for other interfaces than PPP/HDLC to be handled
in conjunction with L2TP.

Any comments are appriciated!

with best regards
Walter

-----Ursprüngliche Nachricht-----
Von: [email-masked] <[email-masked]>
An: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>
Datum: Mittwoch, 11. Februar 1998 13:45
Betreff: Re: PPP Payload in L2TP

> 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
>framing is used, not which type of synch. framing (e.g. HDLC, PPP in Fram=
>e
>-----Urspr=FCngliche Nachricht-----
>>Perhaps I am misunderstanding your remark, but PPP in Frame Relay says t=
>he
>>frame format is:
>>
>>   +-+-+-+-+-+-+-+-+
>>   |  Flag (0x7e)  |
>>portion, the LNS would see the Q.922 header in full.  Is this the intent=
> of
>>the L2TP text?
>>
>>Thanks
>>--
>>> > Frames from the remote user are received at the POP, stripped of CRC=
>,
>>> > link
>>> > 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
>>> consist of the "flag sequence" which would of course not be encapsulat=
>ed
>>> in L2TP.
>>>
>>> Richard.
>>>
>----- End Included Message -----
>
>
>

---

From: "Walter Klausberger" <[email-masked]>
Date: Wed, 11 Feb 1998 15:34:56 +0100

Hi,

Well, I think the only secure way to handle this is, to say that interface
specific options (like ACFC) are forbidden to be negotiated by a LAC or LNS.
If the LAC strips the AAL5 framing and puts 0xff 0x03 in front, the LNS
could try to negotiate ACFC with the client, which will work in our case.

The LAC can not listen to options that are re-negotiated between LNS and
client. The LAC will only change headers based on his connection table. So
how will this work?

Another question:
How can I take part in the discussions of this mailing list?

with best regards

Walter Klausberger
Siemens AG Austria

-----Ursprüngliche Nachricht-----
Von: [email-masked] <[email-masked]>
An: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Datum: Mittwoch, 11. Februar 1998 14:35
Betreff: Re: PPP Payload in L2TP

>christian hublet we21 7848 wrote:
>>
>>  Hi,
>>
>> 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 ?
>> 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 ?
>> (PPP in HDLC-like framing) over an L2TP tunnel. In other words, why
>> send medium
>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.
>

---

From: [email-masked] (luna3!gmg)
Date: Wed, 11 Feb 1998 09:57:19 -0500

Hi,
	This mail thread on PPP over L2TP has a striking resemblance to
the thread on bridging convertors that occurred back in October/September
on the PPP list. This new thread simply is talking about an L2TP/IP/UDP tunnel
media instead of "foo". The upshot of those bridging convertor discussions
was a BCP produced by Bill Simpson. In it, "passive" bridging conversion
like is being done by L2TP is deprecated in favor of "active" bridging.
In active bridging, the PPP framing is negotiated pair-wise between
adjacent bridging convertor boxs using LCP.

	If you apply the BCP's philosophy to L2TP tunnels, it suggests to me
that the LCP framing options should be negotiated between the LAC and
LNS independent of the LAC's access link. In that case, you would not have
any framing overhead on the tunnel, just the PPP payload. The LAC's access
link could be async, ISDN, AAL5, Frame Relay, or "foo" and the LNS should
not care...

	George

---

From: christian hublet we21 7848 <[email-masked]>
Date: Wed, 11 Feb 1998 18:05:04 +0100

Thanks for the feedback on my question. Taken into account the reactions on
this question, and assuming that the ACFC option is the only reason to include
the address and the control field, I believe the discussion can be combined 
with the discussion called "MRU and Set_Link_Info". Here are discussed the fact that due to end to end negotiations (LNS/user), a MRU can be negotiated which 
the LAc is not able to handle.

My impression is that the only thing we have to know are the capabilities of the LAC related to handling ACFC, MRU, Protocol field compression in other words 
LCP configuration options. 

Reading the Draft 4 on PPP over ATM it is clearly indicated that some options
must not be requested and must be rejected e.g. ACFC, FCS, ACCM... 
So it seems to me that capabilities should be reported on call level and 
not on tunnel level (e.g. mixed ATM/ ISDN LAC).

So in short, I believe the capabilities of the LAC should be negotiated
on tunnel level and on call level between LAC and LNS another strategy
could be to forbid some options on LCP level if tunnels are involved.
For MRU, an AVP solution is desirable.

Regards and thanks,

	Chris Hublet

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

>From [email-masked] Wed Feb 11 15:41:07 1998
From: "Walter Klausberger" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: PPP Payload in L2TP
Date: Wed, 11 Feb 1998 15:34:56 +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 JAA22320
Content-Length: 7326

Hi,

Well, I think the only secure way to handle this is, to say that interfac=
e
specific options (like ACFC) are forbidden to be negotiated by a LAC or L=
NS.
If the LAC strips the AAL5 framing and puts 0xff 0x03 in front, the LNS
could try to negotiate ACFC with the client, which will work in our case.

We plan to build a LAC based on a 2-part embedded platform. The Interface
part provides several interfaces (ISDN, ATM, High Speed Bitrate Line
Cards,...) towards the users. On the other hand there is an ATM connectio=
n
to the second part (LAC functionality). So PPP connections over ISDN will=
 be
forwarded by the first part over an ATM VCI/VPI connection (framed with
AAL5) to the second part.

The LAC can not listen to options that are re-negotiated between LNS and
client. The LAC will only change headers based on his connection table. S=
o
how will this work?

Another question:

with best regards

Walter Klausberger
Siemens AG Austria

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] <[email-masked]>
An: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked]

>> Content-Type: text/plain; charset=3D"iso-8859-1"
>> X-Priority: 3
>> Well that is the main problem. How should the LNS know, what header is
>> us=3D
>> ed
>> for PPP at the LAC?
>>
>> During establishment of the tunnel-session (Incoming-Call-Request) the
>> LN=3D
>> S
>> framing is used, not which type of synch. framing (e.g. HDLC, PPP in
>> Fram=3D
>> e
>> -----Urspr=3DFCngliche Nachricht-----
>> >Perhaps I am misunderstanding your remark, but PPP in Frame Relay
>> says t=3D
>> he
>> >frame format is:
>> >
>> >   +-+-+-+-+-+-+-+-+
>> >   |  Flag (0x7e)  |
>> >portion, the LNS would see the Q.922 header in full.  Is this the
>> intent=3D
>>  of
>> >the L2TP text?
>> >
>> >Thanks
>> >--
>> >> > Frames from the remote user are received at the POP, stripped of
>> CRC=3D
>> ,
>> >> > link
>> >> > Question: If the PPP connection works over ISDN (synch. HDLC
>> Framing=3D
>> )
>> >> > does the address and control field belong to the link framing, or
>> ar=3D
>> e
>> >> > they
>> >> consist of the "flag sequence" which would of course not be
>> encapsulat=3D
>> ed
>> >> in L2TP.
>> >>
>> >> Richard.
>> >>

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