Subject: [rohc] Multpoint ROHC for MANET

From: "Green, David B RDECOM CERDEC STCD SRI" <[email-masked]>
Date: Thu, 18 Mar 2004 15:50:56 -0500

Has anyone in the group worked on a schema for point to multipoint robust
header compression 
suitable for broadcast and multicast links in MANETs? The base spec for ROHC
only seems to consider point to point links for cellular systems. I'm
normally in the MANET 
and IPv6 Ops groups but recently became very interested in ROHC as we see
ROHC as an enabling 
technolgy to get IPv6 working on a MANET radio system we are helping to
develop.
The protocol would need to be able to discover multiple neighbors, check to
see if they
are the recipients of multast or broadcast group messages, establish
compression contexts 
with them, have a mechanism to prevent collisions on any bi-directional
replies, and probably
several more problems I haven't thought of.

I'm working on a problem statement for the work now, so anyone interested
please let me know.

David B. Green
SRI International
desk (732) 532-6715
cell (732) 693-6500

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Mon, 22 Mar 2004 09:23:56 +0100

David,

Would it be appropriate to use ROHC in unidirectional mode? The
compression scheme would then not depend on any feeback, and the
number of recipients would thus not affect the compression 
operation. A mapping (ROHC over xxxxx) would of course still
have to be defined.

/L-E

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Green, David B RDECOM CERDEC STCD SRI
> Sent: den 18 mars 2004 21:51
> To: [email-masked]'
> Subject: [rohc] Multpoint ROHC for MANET
> 
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "West, Mark" <[email-masked]>
Date: Wed, 24 Mar 2004 13:02:55 -0000

ROHC in unidirectional mode is the most obvious starting point.  Of course, one of the curiosities of ROHC is that U-mode does allow the use of positive ACKs; however for this application I suspect that negative ACKs would be more useful...

The point-to-multipoint (broadcast) case is considered within ROHC.  The more fluid manet environment (+ multiple senders / receivers) would probably raise some additional things to consider.

One interesting issue might be the management of CID spaces: each sender (point-to-point; point-to-multipoint) assumes that it has complete control of the CID space on the remote decompressor(s).  This still works if you move to a 'mesh' environment, but means that a node needs an instance of ROHC for each sender that it is listening to.

Hmmmm... it's certainly a more interesting 'ROHC over foo' case than where foo==PPP..!

Cheers,

Mark.

> From: Lars-Erik Jonsson (LU/EAB) 
> [mailto:[email-masked]]
> Sent: 22 March 2004 08:24
> To: 'Green, David B RDECOM CERDEC STCD SRI'; [email-masked]'
> Subject: RE: [rohc] Multpoint ROHC for MANET
> 
> 
> David,
> 
> This communication is confidential and intended solely for 
> the addressee(s). Any unauthorized review, use, disclosure or 
> distribution is prohibited. If you believe this message has 
> been sent to you in error, please notify the sender by 
> replying to this transmission and delete the message without 
> disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to data 
> corruption, interruption, unauthorized amendment, tampering 
> and viruses, and we only send and receive e-mails on the 
> basis that we are not liable for any such corruption, 
> interception, amendment, tampering or viruses or any 
> consequences thereof.
> 
>