Commants on the comments of Alcatel. space.

[Ghassane Aniba <Ghassane.Aniba@sophia.inria.fr>]

Hi every body,

Stephane.Combes@space.alcatel.fr wrote:
> 
> Hi,
> 
> a few comments on the draft  :
> 
> - page header to be corrected : it is not the ID "Requirements..." anymore
> - in the introduction, something should be said about bidirectionnal systems
> (UDLR, DVB-RCS) and the ones including MPEG switches (satellite OBP for
> instance). DVB-RCS (either for transparent or regenerative satellites) is very
> interesting since it specifies MPEG-2 transport both for the forward and
> (optionally) for the return link.
> - when we think about DVB-RCS's MPEG mode for the return link (shared access
> between terminals), we may want to have a slightly different encapsulation
> scheme. For instance it could include an additional sublayer performing IP
> packet segmentation into several SNDU (AAL2 like scheme).

Why you want to segment IP in many SNDU. If we use the lenght == 16
bits?
We will nwwd segmentation of SNDU in many MPEG2-TP.

> - on the other hand, we could allow IP packets "packing" into a same SNDU
> - I tend to agree with P. Cipière comment : why making such a complex use of
> PUSI and AFC ? Sticking to the simpler solution that some drivers currently
> implement might be better (less complex, less overhead).

I agree with you, it will be more complex to manage.

> - I am not convinced we need to envisage that many SNDU types : aren't IPv4, v6,
> Ethernet, MPLS enough ? 2 bytes for this like Ethertype is long...

We can use just 1 byte.

> - the famous "label" needs to be specified. A 16-bit field should be enough for
> all kinds of usage, provided it is complemented by an ARP protocol.

Do you propose a label for each SNDU or for each fragment of SNDU?

> - why should the format of bridged payload be specified in this document ?
> - is it so important to keep the 16/32 bit alignment ?
> - I am not sure to understand well the paragraph about the MPLS header. Why
> putting it into the adaptation field ? it is not the case for other higher layer
> headers like IP and Ethernet.
> - Do you have an adaptation field inserted before each SNDU ? why ?
> 
> As far as regenerative satellites are concerned, here are our views :
> 
> - currently we only envisage ATM VP or MPEG PID switching at the OBP. Switching
> on an extra label would cost a lot... and currently we do not see any concrete
> need to do that. Currently forget about Ethernet or IP layer processing on-board
> !

How will you use switching just on the PID? Don't forget that in the
receiver we can just distinguish between 20 PID, i think.

> - large capacity multi spot-beam "mesh" systems based on regenerative payload
> and MPEG switch handle a lot of terminals (hence a lot of "feeds"). Being able
> to use the same PID for several feeds may prove to be interesting (PID used as a
> "broadcast network" as Horst put it). It is possible to do this, even with a
> "simple" MPEG TS level switch a the OBP. The only need is to have an extra label
> (e.g. the SNDU label) being used to discriminate the SOURCE of the SNDU and have
> only one such SNDU per MPEG cell.

That what i've already propose, to have a label in each mpeg-ts packet.
So what's your opinion about the overhead of this idea?

> - concerning G. Anissa's mail about "Channel-descriptor" signalling the mapping

G.Aniba and not Anissa :).

> Source/Destination @ -> PID, Label : DVB-RCS group is currently working on such
> protocol.

I've more detail about this proposed Descriptor.

> 
> Best regards,
> 
> Stéphane
> 
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes@space.alcatel.fr

Best regards,

Aniba.

-- 
Ghassane ANIBA
INRIA (Projet PLANETE)             | Email :
ghassane.aniba@sophia.inria.fr  
2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78