Subject: [L2tpext] Offset size

From: Cédric Fau <[email-masked]>
Date: Fri, 01 Mar 2002 17:03:33 +0100

Hello,

I have some issues with the offset size field. I don't understand its aim.
If it is still present in the L2TP header in the 
draft-ietf-l2tpext-l2tp-ppp-01.txt, that's
because there is a use of this field. But what kind of use ?

Cédric Fau
mailto: [email-masked]

Student in Telecommunication and Network Engineering
http://www.enseeiht.fr/

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sat, 02 Mar 2002 11:45:50 +0100

If you have an odd-sized layer two frame being carried between your tunnel
header and the framed network packets (e.g. an IP packet being framed by a PPP
packet with PFC negotiated, resulting in a 3 byte PPP frame) then it could help
the performance of some implementations to insert padding bytes to ensure
alignment of the framed network packet (e.g. the IP packet). 

At one time, it's affect on at least some implementations was measurable,
particularly on an LNS which routed the tunneled, framed, IP packet locally
rather than sending it out another physical connection. The implications today
may not be as marked, and is in fact becoming more and more contraversial as to
whether it is even necessary, but still could theoretically be an issue. It is
always, of course, optional.

- Mark

---

From: Cédric Fau <[email-masked]>
Date: Tue, 05 Mar 2002 15:57:33 +0100

> alignment of the framed network packet (e.g. the IP packet). 

OK in that case the offset can not exceed 3 bytes to align the end of 
the header on the end of a 32-bits word?
So why the RFC propose a 2 bytes long field.

> always, of course, optional.

In L2TP data packet, it seems that optional fields are not used. Is that 
the current implementation?

---

From: "W. Mark Townsley" <[email-masked]>
Date: Tue, 05 Mar 2002 17:18:06 +0100

> So why the RFC propose a 2 bytes long field.

The offset is a 2 byte field stating the number of bytes of padding that follow.
So, if you need to bad two bytes, the offset is 0. If you need to pad 3, the
offset is 1. If you need to pad 1, sorry, you need to use an offset value of 3
so that you will effectively pad 5.

> the current implementation?

Not sure what you are asking. The optional fields of a data packet include
length, offset, and a sequence number. I have seen different combinations of
these fields used by different implementations. All MUST be able to receive a
packet with any of these fields present.