ROHC-over-802 (was: Re: IPDVB Provisional Agenda (IETF-75))

Carsten Bormann <cabo@tzi.org> Sat, 18 July 2009 08:57 UTC

Return-Path: <owner-ipdvb@erg.abdn.ac.uk>
X-Original-To: ietfarch-ipdvb-archive@core3.amsl.com
Delivered-To: ietfarch-ipdvb-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53E53A6AB7 for <ietfarch-ipdvb-archive@core3.amsl.com>; Sat, 18 Jul 2009 01:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JjTQ75kiz6j for <ietfarch-ipdvb-archive@core3.amsl.com>; Sat, 18 Jul 2009 01:57:49 -0700 (PDT)
Received: from erg.abdn.ac.uk (dee.erg.abdn.ac.uk [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by core3.amsl.com (Postfix) with ESMTP id EACAA3A69EC for <ipdvb-archive@ietf.org>; Sat, 18 Jul 2009 01:57:48 -0700 (PDT)
Received: from dee.erg.abdn.ac.uk (localhost [IPv6:::1]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6I8WTqH014844 for <ipdvb-subscribed-users@dee.erg.abdn.ac.uk>; Sat, 18 Jul 2009 09:32:29 +0100 (BST)
Received: (from majordomo.lists@localhost) by dee.erg.abdn.ac.uk (8.13.4/8.12.2/Submit) id n6I8WT3P014843 for ipdvb-subscribed-users; Sat, 18 Jul 2009 09:32:29 +0100 (BST)
X-Authentication-Warning: dee.erg.abdn.ac.uk: majordomo.lists set sender to owner-ipdvb@erg.abdn.ac.uk using -f
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9:209:3dff:fe00:7136]) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id n6I8W82C014832 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for <ipdvb@erg.abdn.ac.uk>; Sat, 18 Jul 2009 09:32:09 +0100 (BST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id n6I8Vxkg022931 for <ipdvb@erg.abdn.ac.uk>; Sat, 18 Jul 2009 10:31:59 +0200 (CEST)
Received: from [192.168.217.107] (p5489B5F8.dip.t-dialin.net [84.137.181.248]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTP id B7B70B539; Sat, 18 Jul 2009 10:31:58 +0200 (CEST)
Message-Id: <A04B1CF2-2A7C-4658-9BF2-6137B2015480@tzi.org>
From: Carsten Bormann <cabo@tzi.org>
To: ipdvb@erg.abdn.ac.uk
In-Reply-To: <4A617AA6.8080506@nav6.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Subject: ROHC-over-802 (was: Re: IPDVB Provisional Agenda (IETF-75))
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Sat, 18 Jul 2009 10:31:55 +0200
References: <4A5261C6.6050408@erg.abdn.ac.uk> <93E26FA7-E4FF-4161-8D3E-C8A288A5FEBC@tzi.org> <86EA1C81-D636-47DA-8E33-593F2E7D2328@tzi.org> <4A5D886F.6010009@erg.abdn.ac.uk> <4A617AA6.8080506@nav6.org>
X-Mailer: Apple Mail (2.935.3)
X-ERG-MailScanner: Found to be clean, Found to be clean
Sender: owner-ipdvb@erg.abdn.ac.uk
Precedence: bulk
Reply-To: ipdvb@erg.abdn.ac.uk
X-ERG-MailScanner-From: owner-ipdvb@erg.abdn.ac.uk

> 	   R=1 (what I can decompress)	
> sender <------------------------------ receiver
> 	   R=2 (I will send using these params)
> sender -------------------------------------> receiver
> 	   R=4 (I too will send ROHC using these params)	
> sender <------------------------------------- receiver

Correct, that is what I'm proposing for the bidirectional case (e.g.,  
two devices connected by some form of bridged Ethernet/WLAN  
combination).  (The sender might then occasionally transmit R=4  
packets based on a NUD-like algorithm.)

> I'm not sure how ROHC will work properly with multicast.

That is the other case with R=6 at the end of section 6 (penultimate  
paragraph).
If the sender does not have direct information about the ROHC  
capabilities from its peer (which it would get based on negotiation  
packets with R=1 and R=4), the R=6 case allows setting up the  
compression based on some out-of-band information (such as  
configuration or some other negotiation protocol).  See the caveats in  
that paragraph.

Gruesse, Carsten