[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Commants on the comments of Alcatel. space.
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