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

[Pedro Fortuna <[e-mail]>]

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
=======================
Faculty of Engineering (FEUP)
University of Porto
Portugal


On Fri, 25 Mar 2005 14:37:52 +0100, Ana Minaburo <[e-mail]> wrote:
> 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
> 
> 
> On Wed, 23 Mar 2005 23:24:05 +0000, Pedro Fortuna
> <[e-mail]> wrote:
> > 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
> >
> > On Wed, 23 Mar 2005 14:04:16 +0100, Ana Minaburo
> > <[e-mail]> wrote:
> > > 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/rohc
> > >
> >
> >
>

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