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

Carsten Bormann <cabo@tzi.org> Tue, 29 March 2005 12:53 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22682 for <rohc-web-archive@ietf.org>; Tue, 29 Mar 2005 07:53:45 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGGKo-0003Dz-Ib for rohc-web-archive@ietf.org; Tue, 29 Mar 2005 08:00:42 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGGCJ-0000ob-QX; Tue, 29 Mar 2005 07:51:55 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGGCI-0000oR-Lj for rohc@megatron.ietf.org; Tue, 29 Mar 2005 07:51:54 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22369 for <rohc@ietf.org>; Tue, 29 Mar 2005 07:51:53 -0500 (EST)
Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGGIz-00039A-Hm for rohc@ietf.org; Tue, 29 Mar 2005 07:58:50 -0500
Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j2TCpVjF001856; Tue, 29 Mar 2005 14:51:32 +0200 (MEST)
In-Reply-To: <db95d40c0503251422528f89dc@mail.gmail.com>
References: <3F2E01E1D7B04F4EBEC92D3FA324D8803857FC@rsys004a.roke.co.uk> <550877E8-420B-11D9-82C1-000A95DC4DB6@tzi.org> <db95d40c0412071707b0c2e1b@mail.gmail.com> <C7666E10-48EE-11D9-B3CF-000A95DC4DB6@tzi.org> <db95d40c04122008155a0416fe@mail.gmail.com> <d1ba43fa626fb030b44ff955e33c3364@tzi.org> <42416950.4090701@enst-bretagne.fr> <db95d40c05032315243d47c7d7@mail.gmail.com> <29ed16a405032505371a35ee56@mail.gmail.com> <db95d40c0503251422528f89dc@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v619.2)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <a0a74cff0b622b0082d543bd111c9b65@tzi.org>
Content-Transfer-Encoding: 7bit
From: Carsten Bormann <cabo@tzi.org>
Subject: Re: [rohc] question about draft-bormann-rohc-over-802-00.txt
Date: Tue, 29 Mar 2005 14:51:29 +0200
To: Pedro Fortuna <pedro.fortuna@gmail.com>
X-Mailer: Apple Mail (2.619.2)
X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Content-Transfer-Encoding: 7bit
Cc: rohc@ietf.org, francis.dupont@enst-bretagne.fr, anacarolina.minaburo@enst-bretagne.fr, Carsten Bormann <cabo@tzi.org>, Laurent Toutain <Laurent.Toutain@enst-bretagne.fr>, ayed_samiha@yahoo.fr
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
Sender: rohc-bounces@ietf.org
Errors-To: rohc-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Content-Transfer-Encoding: 7bit

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

> 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).

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


_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc