Subject: Re: [rohc] question about draft-bormann-rohc-over-802-00.txt

From: Ana Minaburo <[email-masked]>
Date: Wed, 23 Mar 2005 14:04:16 +0100

Hi!

After reading your draft of ROHC over 802, and looking at the LLC 
encapsulation,  I was wondering why do not use ROHC directly with the 
Ethernet header using a self describing padding?

Ana

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

---

From: Pedro Fortuna <[email-masked]>
Date: Wed, 23 Mar 2005 23:24:05 +0000

That solution has got my vote too.
There are some issues regarding legacy switches/bridges, which when
transporting IP packets, are not able to distinguish padding in an
ethernet frame, and thus, not able to strip padding.
It is my understanding that one of the major motivations of a LLC/Snap
solution, is to be able to support this legacy equipment (i.e. without
any modification).

IMHO, I think is better not to follow this approach and develop a
solution that carries RoHC packets directly over DIX frames, using a
RoHC padding scheme. This approach would not assume the existance of a
L2 length field (like in RFC 3409).

Of course this means that future equipment will have to support this.
But there are other indications that these equipments will have to be
modified, e.g. like with most solutions developed in the context of 4G
networks.

Best Regards,
Pedro Fortuna
=======================
Faculty of Engineering (FEUP)
University of Porto
Portugal

---

From: Ana Minaburo <[email-masked]>
Date: Fri, 25 Mar 2005 14:37:52 +0100

Hi,

If I understand well, this will be used when we are bridging between
"ethernet/802.3" and "point to point" link and we donot want the
padding to be sent on the p-t-p link.
If we are using PPP-tinygrams since ROHC supress IP length field we
cannot distinguish the data from the padding. If we are using ROHC
padding then it will be sent on the p-t-p link. Is it correct?

My other concern is the use of SNAP, it seems to introduce 5 bytes for
nothing, it will not be better to use only LLC? and ask for a SAP ?

Ana

---

From: Pedro Fortuna <[email-masked]>
Date: Fri, 25 Mar 2005 22:22:53 +0000

Hello,

Yes, this will be used when bridging between ethernet/802.3 and 802.11
or 802.15 or 802.16, (...) . Care must be taken for padding not to be
propagated to non-802.3 links.

The internet draft clearly states that using DIX frames is not the way
to go because the lenght field is needed. But the identification of
the carried payload is also necessary so it points out some possible
solutions, all of them involving the use of 802.2 frames.

In my opinion it will be difficult for a 802.2 based solution to work
with legacy equipment, because bridges/APs are programmed to send DIX
frames by default (they support receiving 802.2 frames, but normally
do no send them when bridging from other 802 technologies). If my
assumption is true, it is not difficult to picture scenarios where the
802.2 based solutions will not work. Of course, a DIX frames based
solution will not work either.

My point is that there is no solution that I can think of, that will
support the transmission of RoHC traffic, bridging between 802.3,
802.11, (...) and that _guarantees_ that padding will not be
propagated to wireless links. I think that bridges/AP will have to be
modified to support RoHC packets (just like they support IP traffic by
snooping the Total Lenght field).

Regards,
Pedro Fortuna
=======================

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Mar 2005 14:51:29 +0200

On Mar 25 2005, at 23:22 Uhr, Pedro Fortuna wrote:

> do no send them when bridging from other 802 technologies).

We did some quick experiments before I wrote the draft.
We found three classes of APs:

1) APs that just discard length-field (LLC)) frames.  If we use LLC for 
the negotiation protocol, too, then when these are in the path, 
ROHC-over-802 implementations would never negotiate ROHC in the first 
place.  Not a problem.
2) APs that mangle LLC frames.  For instance, one AP received an LLC 
frame and "corrected" the length field to include the Ethernet padding 
before sending it forward.  Again, the negotiation protocol could 
include some sanity checks here.
3) Correct APs.

The first two classes are generally known in the community as "don't 
support Appletalk".
They do exist, but have become rarer.

In my opinion a solution that only supports class 3, but is robust in 
the presence of classes 1 and 2, would be fine.

Gruesse, Carsten

---

From: Pedro Fortuna <[email-masked]>
Date: Tue, 29 Mar 2005 17:26:50 +0100

Carsten, did you find any AP that allow the reception of LLC frames,
but always send DIX frames when bridging to a different 802 link type?
(e.g. receive a 802.11 frame with LLC and forward a 802.3 DIX frame)

In my previous messages, I made the assumption (maybe an incorrect
one) that most bridges would behave like this. But maybe there aren't
any APs with this kind of behaviour. I didn't made any tests yet.

Best Regards,
Pedro Fortuna
=======================

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 29 Mar 2005 22:08:55 +0200

> (e.g. receive a 802.11 frame with LLC and forward a 802.3 DIX frame)

No, we didn't see that behavior.
(Note that we did not use SNAP, in which case this behaviour would have 
been likely.)

> any APs with this kind of behaviour. I didn't made any tests yet.

We certainly need to expand our tests.  Right now, we only have half a 
dozen or so types of access points available for testing.

However, it is clear that any AP *should* forward LLC frames just fine.
The point of the testing can only be to find out about the failure 
modes of deployed APs and to make sure ROHC-over-802 is robust to these 
failure modes.

Gruesse, Carsten