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

[ayed samiha <[e-mail]>]

Note: forwarded message attached.

		
---------------------------------
 Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails !
Créez votre Yahoo! Mail

--- Begin Message ---

Hello,

Although a SAP may identify the protocol, is true that the SNAP header
has a ethertype field. I guess the it might be easier for bridges to
support the SNAP proposal, or maybe is because it might be difficult
or expensive to allocate a OUI for RoHC. But it seems to me that a LLC
solution is better than a LLC+SNAP solution.

I imagine that you wanted to send this email to RoHC mailling list and
hitted the "Reply" button instead of "Reply All" :)

Anyway, if you want to know my opinion, neither a LLC or LLC+SNAP
solution will work with legacy equipment (i.e. common bridges) due to
the fact that they use DIX frames by default. It's not realistic to
assume they _all_ can be reconfigured to send 802.2 frames instead of
DIX frames. If my assumption is true, this means that the software
running on bridges must be modified to correctly support RoHC, if we
want to make sure that padding is _never_ proppagated to wireless
links.
If we go any further on this line of thought, if we must change
software running in bridges, we might as well go for RoHC
transportation on standard DIX frames. That would require an ethertype
and an extra Lenght header on RoHC packets or some sort of RoHC
padding schemes.

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

On Tue, 29 Mar 2005 10:32:59 +0200 (CEST), ayed samiha
<[e-mail]> wrote:
> Hi, 
>   
> Why we need to use the layer SNAP although we can do it only with the LLC
> layer ? 
> 
> Thank you.
> Pedro Fortuna <[e-mail]> wrote: 
> 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 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
> > 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
> > > 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
> > > >
> > >
> > >
> >
> 
> 
>  ________________________________
>  Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos
> mails !
> Créez votre Yahoo! Mail 
> 
>

--- End Message ---

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