Subject: Re: PPP Frames on tunnel

From: "Andy Bickford" <[email-masked]>
Date: Tue, 1 Aug 2000 10:16:13 +0100

Hi folks,

Can anybody clarify the replies to Sridhar's question, as they appear to
contradict each other.

Hence what should be added to the PPP frames being sent from the LAC to
the LNS and the LNS to the LAC ?

How does the LAC/LNS distinguish between the FF 03 bytes that have been
added as extra bytes on entry to the tunnel and the real address and control
fields ?

Apologies if the questions have already been answered.

Best Regards

Andy Bickford
Technical Associate
IPWireless Inc

>Sridhar Malarothu wrote:
>
> Hi All,
>
>     LAC before sending ppp frames on tunnel to LAC should strip of
> the CRC, Link Framing and transperancy bytes, encapsulate them in L2TP
> header. But what should be status of the PPP frames on tunnel, if send
> by LNS.
>
> Best Regards
> Sridhar

>Mark Townsley's reply was:
>
>PPP framing of FF03, unless ACFC is negotiated, should exist on packets
>sent from the LNS and from the LAC.

>James Carlson's reply was:
>
>Data frames from the LNS should not have an appended CRC, framing, or
>transparency bytes, and they should have L2TP headers.
>
>Note that the leading FF 03 (the default values used for the HDLC Address
>and Control fields on regular PPP links) must be included on the tunneled
>frames, contrary to prior convention (such as described in RFCs 1598, 1973,
>and 2364). So, if you're coming from a regular PPP over Frame Relay network
>into an L2TP tunnel, you'll have to add those extra bytes on entry to the
>tunnel and remove them before going into Frame Relay.

---

From: Andy Valencia <[email-masked]>
Date: Wed, 02 Aug 2000 10:30:07 -0700

>  Let's be honest about why the Address and Control fields are there in
>  PPP.   

Since I'm as responsible as anybody for this, I may as well respond to this
point.

The reason A/C was left in was that, at the time this was all being
assembled, PPP-over-HDLC was pretty much the only game in town.  At the
time, my perception of the FR and ATM people was that they were going to go
their own way, and reinvent everything they needed.

PPP over Ethernet was, to put it mildly, right off the radar screen.

So, in this environment, I looked at PPP, and saw that if I didn't monkey
with A/C, then A/C compression would still be available (so the overhead
isn't mandatory), and I wouldn't have to spend time explaining why disabling
RFC1663 (which at least some of *my* customers, at the time, used) was a
Good Idea.  So that was the encap used in L2F, and by the time Gurdeep and I
were assembling L2TP, this was working out fine in practice, so we left the
encap the way you find it today.

With the possibility of L2TP extensions to carry other circuit services, I
certainly agree that we're at a very nice point to parameterize the
encapsulation, and thus permit "raw" PPP as well as HDLC PPP.  If L2TP ends
up not being used as a circuit tunnel, then it probably still makes sense
for L2TPbis to add an appropriate AVP.

$0.02,
Andy Valencia