[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fair-ipdvb-req : Some questions
Gorry Fairhurst wrote:
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.
I don't understand the question.
I just meant that if a logical IP-interface is associated to
each TSQ multiplex (in case of the sebder has diretc acces to
various Ts multiplex), then the standard Ip routing will select
the outgoing interface, and then what will still need resolution
is only the PID.
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 ?
What do you propose?
About the flows definition it was to stick to IPv6 flow definition,
hence imposing to alwaus use the same PID for a single (SRC+DST+FLOW)
3-uple. But indeed I don't understand why a flow must be associted to a
single PID.
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 ?
"Use cases" should be developed, Jun, sent something about this, and it is
good to collect as many different use cases as we can. (This has been
repeated in many places over the last few days).
I'm halas, not experienced with staellite techniques and/or usage, and
can not provide such pieces of information.
5) Framework position
...
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 ?
I'm keen to focus on subnetwork issues first so we can get the basic
encapsulation protocol out of the way, or at least into a stable draft. We
will need to look at this when we do the address resolution.
OK I see. This place will also be the good place for the MTU definition
of such interface.
Did I miss something or is this pointer removable ?
No, this is required in MPEG-2.
I still have to read 13818-1. It's a little bit BIGGER tahn I expected
but I'll read it :-( Just need to find a couple of hours; -)
I think i'm still confused about PUSI_pointer, Payload_Pointer, and the
pointer in ten Adaptation Field ....
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.
We need text from people deploying links to give some clear "use cases" so
we can identify what is needed. If you have use-cases send them to the list,
and we can add them to the AR or architectural requirements Ids.
Same answer as before ...
but if there's no REAL use-case (and maybe even if there is some ..)
I think this req should be removed, because I think VPN-stuff should be
managed above IP level and not below.
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