Re: ASPI comments about draft-clausen-ipdvb-enc-00.txt

[Dr G Fairhurst <gorry@erg.abdn.ac.uk>]

Thanks,

That's a very useful list - these will help to improve the enxt
draft. WE'll start compiling a list of issues in a few weeks.

See a few in-line comments.

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).
> - 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).

Well, we use the PUSI at the moment - but if we remove the section header,
we need at least some way to identify that a packet doesn't contain another
whole/partial SNDU following the end of the first.  I believe the AFC could
be used to introduce the appropriate padding - and is probably best. The scheme
in the draft may need a little more work?

> - 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...

There are many more types possible, one mentioned in our charter is "ROHC"
compressed IP packets.

I agree though, it seems unlikely there would initially be more than 255.
One reason, I favoured 2B was to allow reuse of existing type codes, 
is this important?
Do we care about the byte-alignment?

> - 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.

Is that yet another type?

> - 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 ?
> 
No - As I see it, this an overhead per MPEG-2 TS Packet.

> 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
> !
> - 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.

This doesn't seem incompatible with the proposed encapsulation, more an
issue to
do with the way the encapsulator chooses to process IP packets. So, this seems
good.

> - concerning G. Anissa's mail about "Channel-descriptor" signalling the mapping
> Source/Destination @ -> PID, Label : DVB-RCS group is currently working on such
> protocol.

It would be good to know more of this.

> 
> 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