fair-ipdvb-req : Some questions

[alain.ritoux@6wind.com]

Hi all,

I have some question about the draft '"Requirements for IP
transport over MPEG-2 networks" (draft-fair-ipdvb-req-03.txt)
As a newbie in satellite stuff, some of these questions/precisions
may be irrelevant, thanks for indulgence ;-)


1) some reference don't exist  [DVB-RC] [LINK-ID] [DVB-SIDAT],
and maybe some other. As a newbie in that stuff, finding its way
among multiple ISO/ETSI/whatever norms isn't really obvious :-(


2) About the TS-multiplex selection
  2-a related to figure 2
Maybe I didn't get the point but hiw does it work : is it for
the sender, a selection between multiple DVB-Sending cards ?
If so, but managing  one  (or many ?) logical IP interface per
sending card, I don't see why the 'normal' IP routing souldn't
be enough.
  2-b related to figure 3
The IP encapsulator has no mean to interact with the second TS
multiplexor, so what is the point ?

3) Packet flows
  3-a the flow itself
They are associated with IP source and destination addresses.
Well is it enough ? I mean, the recent flow-label discussion in
the IPv6-WG ended up with a flow definition with SRC+DST+Flow_Label
(http://www.ietf.org/internet-drafts/draft-ietf-ipv6-flow-label-07.txt)
  3-b the usage ?
Indeed, why impase taht a single flow MUST use a single PID,
I would consider it safer, but what is the rational behind it ?

4) Motivation
In the needed fcts (§3 p10), there is the IPv4 broadcast packet support
: is there a real need for this ? what is the use-case foreseen ?

5) Framework position
The framework operates below the IP level. Couldn't it be a good
place to define a logical-interface level (just for exemple, one
pseudo-interface associated to a group of PID), and to see how to
defien this group PID properties, in such a way that classical IP
mechanisms will work 'perfectly' over this interface. By IP mechanisms
I include not, only the stacks tmeselves, but also routing, ...
To make myself more clear, ythe level of abstraction could be
equivalment as the one we find in UDLR.
Or is it over-specifying, and considered as implementation-dependant ?

6) About lenght indicator.
It is said (§6.3 note ii p17) that when more than 2 payload are present
in a single TS-cell, the PUSI pointer is only used for the first start.
This is because the mandatory lenght indicator is enough to find the
start of the next payload.
In this case, why even use the PUSI pointer for the first tart in the
TS-cell ? for I think lenght indicator + cell_numbering should be
enough ?). Did I miss something or is this pointer removable ?

7) About address scoping
I don't really see the point in managing sort of scope indicator
at DVB-level, to manage muliple IPv4 private addressing that overlap.
Indded, it may be out of context, and if we asume the DVB link a
sort of publi link, overlapping addresses space should be managed
at IP-level (with virtual routers or whatever).
Or is it foreseen to addres a sub-PID managemùent, i.e. to do view a
PID as a LAn, and to perform sort of VLAN management.

8) p23end of the page :
excuse my ignorance, but what is the bandwitdth commonly associated to a
single PID ? because can really  a few Mbps recpetion (destined to be
filtered at IP level) be considered as a DoS ?

Even in case of a router, and strange protocol behaviuour, report, to 7)


Thanks for having read so far ....
Regards.

Alain.
--
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com