[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ROHC and ULE
Preliminary to my embedded responses... I think there are two parts. The first is a mechanism to indicate when the payload contains a packet which has a compressed header. This is the problem we ran into with MPE which made us take a look at ULE. The second is whether or not we need to specify a means for the compressor and decompressor to communicate or we just assume an out of band mechanism (which is likely to be using other IP messaging)... 

Cedric.Baudoin@alcatelaleniaspace.com wrote:


Dear Gorry and ipdvb members,

We, at Alcatel Alenia Space, are indeed interested in this topic.
The I-D appears as a good starting point we would like to comment.

Support of mulitcast / broadcast traffic
In section 3.3 it is mentioned that the proposed scheme will not support
multicast or broadcast traffics.
From our point of view, we would like to reconsider this, provided that
group services may be of importance in DVB systems such as satellite
networks.
Now, how having a multicast addressing to work  with ROHC remains an open
issue, but at least a basic solution would be the use of unidirectional
mode (no need to acknowdege)
The draft is currently only referencing a mechanism to signal that something has a compressed header. In that context, there is really no reason not to support multicast. (I had already made a note to myself to fix this.)
I think synchronizing multiple decompressors with a compressor may be challenging. 


(The same question of multicast has already been raised in the ip-dvb
archive (05/05), apparently without any answer ...)

Negociation of parameters between compressor and decompressor
This point does not appear to be address in the document yet, but how to
make the negociation is a real issue for the implementation of ROHC over
ULE. Probably some propositions should be discussed here ? (e.g. use of
default parameters according to the type of DVB network ? PPP replacement ?
use of SI tables ? etc...)
To get things started, the draft just currently assumes out of band. But, this is what I really wanted to see discussed. My own opinion is not well formed yet... 


ROHC recommendation
We strongly believe that one of the output of the task shall be ROHC usage
recommendations. This can be either parameters values proposition or
analysis of the best suited mode  depending on different scenarios (namely
unidr system, satcom systems with a return link, in both mesh and star
topologies)

ROHC adaptation
A interesting point to investigate can be ROHC adaptation to fit the
satellite systems and the ULE stack. Two approaches can be foreseen. The
first one is dedicated to simplification of the compression scheme, and the
second one to the optimisation of ROHC in this context.
We were trying to make the mechanism independent from the specific algorithm(s). On the other hand, some ROHC usage recommendations re ULE would be very useful. 

ULE over ROHC ?
This has never been proposed, but maybe the compression gain could be
pushed a little more, if new ROHC profiles integrating ULE (i.e.. x/IP/ULE)
were supported ? What would be the main barriers for such an approach ?

ROHC and GSE
Another important point is to take into account GSE in order to prepare
future work on the GSE/ROHC topic (How to support ROHC in DVB-S2 / GSE
could be investigated in another I-D taken into account the work done in
this task, as the GSE standardisation process is on-going).

Best regards

Cédric Baudoin and Fabrice Arnal


Research Department/Advanced Telecom Satellite Systems
Tel : +33 (0)53435 6817  /  Fax : +33 (0)53435 5560
Porte : W218  /  E-Mail : cedric.baudoin@alcatelaleniaspace.com

This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. ALCATEL ALENIA SPACE (and its subsidiaries)
shall (will) not therefore be liable for the message if modified.

Ce message et toutes les pieces jointes (ci-apres le "message") sont
etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur, merci de le detruire et d'en avertir
immediatement l'expediteur. Toute utilisation de ce message non conforme a
sa destination, toute diffusion ou toute publication, totale ou partielle,
est interdite, sauf autorisation expresse. L'internet ne permettant pas
d'assurer l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
decline(nt) toute responsabilite au titre de ce message, dans l'hypothese
ou il aurait ete modifie.



John Border
Hughes