New I-D has been submitted for draft-wan-ipdvb-rohc

"Ang Way Chuang <洪伟壮>" <> Fri, 17 October 2008 07:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CB2D23A680C for <>; Fri, 17 Oct 2008 00:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.137
X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3WKlMjCMNCpg for <>; Fri, 17 Oct 2008 00:23:43 -0700 (PDT)
Received: from ( [IPv6:2001:630:241:204:203:baff:fe9a:8c9b]) by (Postfix) with ESMTP id 71E293A63CB for <>; Fri, 17 Oct 2008 00:23:41 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (8.13.4/8.13.4) with ESMTP id m9H75E79013502 for <>; Fri, 17 Oct 2008 08:05:14 +0100 (BST)
Received: (from majordomo.lists@localhost) by (8.13.4/8.12.2/Submit) id m9H75Eba013501 for ipdvb-subscribed-users; Fri, 17 Oct 2008 08:05:14 +0100 (BST)
X-Authentication-Warning: majordomo.lists set sender to using -f
Received: from ([]) by (8.13.4/8.13.4) with ESMTP id m9H74nNT013469 for <>; Fri, 17 Oct 2008 08:04:51 +0100 (BST)
Received: from localhost (unknown []) by (Postfix) with ESMTP id EEB6D1D6017C; Fri, 17 Oct 2008 07:39:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at
Received: from [] (unknown []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id 5DB331D60170; Fri, 17 Oct 2008 15:39:30 +0800 (MYT)
Message-ID: <>
Date: Fri, 17 Oct 2008 16:02:57 +0900
From: "\"Ang Way Chuang <洪伟壮>\"" <>
User-Agent: Thunderbird (X11/20080925)
MIME-Version: 1.0
To: "" <>
CC: TC Wan <>
Subject: New I-D has been submitted for draft-wan-ipdvb-rohc
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ERG-MailScanner: Found to be clean, Found to be clean
Precedence: bulk

Hi all,
	I've just submitted the latest draft to IETF. The URL:

     The following is a summary of changes that went into this draft:
- Introduce a field called RefID (reference ID) in RCPNP message that 
used to ack/nack another message with the same ID.
- Reorganize the content so all causes of negative acknowledgement are 
now put under Negative acknowlegement section.
- Introduce heartbeat message in RCPNP that will be sent periodically 
when ROHC channel is idle. This is used to detect cases where 
compressor/decompressor terminates abnormally.
- In the section where interaction of RCPNP is shown, how RefID and ID 
are used was added. In addition, a case where abnormal termination is 
also shown.

Any comment on the latest draft?

In addition, we would like to discuss and possibly include the following 
ideas for the next revision:

1. Network with only 2 nodes may avoid the steps involve in the learning 
of network topology. Broadcast/multicast traffic can be compressed in 
this case. My guess is that this can achieved by gateway machine by 
detecting how many receiver frontend. If there is only one receiver 
frontend, then it is safe to assume the network only consists of 2 
nodes. Our definition of node is limited to receive capable feed. Of 
course, I am likely to be wrong.

2. How to enable compression of broadcast/multicast traffic if the 
network has more than 2 nodes? One idea is to have compressor gateway 
send a beacon signal about parameters of ROHC channel for 
broadcast/multicast traffic through uncompressed channel periodically 
There are several challenges that must be handled for this case.
- Firstly, if one of the receiver gateway can't accept the ROHC channel 
parameter (e.g doesn't support certain profile or doesn't ROHC 
decompression), then compression of broadcast/multicast can't proceed.
- There may be cases where receiver gateway joins the network after 
compressor gateway has started transmission of compressed packet. In 
this situation, the receiver gateway won't be able to decompress the 
packet until it receives the beacon and until the compressor's context 
falls back to IR state. Thus, context of compressor must periodically 
fall back to IR state after certain time (this may consumes more 
bandwidth than having uncompressed packet for certain cases depending on 
how frequent it falls back to IR state).

3. Only decompressor gateway can initiate the negotiation of ROHC 
channel in current draft. I think it is sufficient, so is there a need 
to specify a way to let compressor gateway to initiate the negotiation 
of ROHC channel?

Anyway, I had a quick glance at the drafts related to security extension 
  mentioned in the last IETF meeting, but I have no idea how it can be 
used to overcome the problem of address spoofing vulnerability mentioned 
in our draft.

Thanks for reading this lengthy email.

Ang Way Chuang