[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
Art, which document are you referring to?
The version of A/92 which I have relates only to multicast packet
delivery. Is there an update that covers more? I can't find how the
bindings apply to usage of arp for IPv4 (or how these multicast mappings
relate to ND for IPv6).
Gorry
Allison, Art wrote:
It should be clear to anyone informed about MPEG2 TS multiplexers that using
a fixed PID introduces significant complexity for management of a TS
intended for broadcast to consumers. Re-multiplexers drop such PIDs from the
stream unless specifically programed for special treatment of the fixed PID
(the value of which has to be communicated via 'other' means). IMHO, this
makes the entire solution/approach developed by this group generally useless
for the transmission path from a broadcaster to the consumer (which also
goes through cable system remultiplexers).
Is this not scenario A in the above document?
The address resolution and scoping of 'network' issues have been resolved by
the ATSC. The method of delivery of IP traffic that is documented is proven.
It is offered in products from multiple vendors and is being used every day
(and has been for a few years) in the real world for delivery of IP traffic
via over the air broadcast to consumers.
Inventing another solution for the broadcast OTA link seems to be wasted
effort - especially a solution that is fundimentially as flawed as to
require a fixed PID.
Perhaps now is the time to recognize that this IETF work is really optimized
for other MPEG-TS-using networks and its claimed scope should be reduced to
the other transmission links, where folks determine that the 2.2% overhead
the 'fixed PID' approach requires is actually less than one obtains with
DSMCC for the traffic they expect to flow.
Which 2.2% do you mean?
Art Allison
NAB S&T
p.s. If someone would like more information see A/92 and applicable parts of
A/90 at www.atsc.org. Also note, as it may not be obvious, that the
DSMCC-based technology in these standards is seperable from the ATSC
announcement technology and then is applicable to any TS.
-----Original Message-----
From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk]
Sent: Tuesday, November 02, 2004 6:17 AM
To: ipdvb@erg.abdn.ac.uk
Subject: Re: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt
On clarification of the AR work scope:
Rod.Walsh@nokia.com wrote:
<snip>
* I get the impression that it is an intentional limitation of the AR that
it
> applies only to the current TS (as you would expect cf ARP). This is
a sensible
> limitation but it's worth stating explicitly.
> (i.e. that address resolution for other TSes, e.g. for moving TS and
mobility
> optimisation, is not in scope).
<snip>
Cheers, Rod.
My understanding was that the scope of any new work will be to resolve
*within* a transport multiplex (i.e. a single physical bearer). The
proposals to date do not allow the possibility of a TS logical channel
(i.e. PID value) to be changed during (re)multiplexing - there are
scenarios in which this can happen - and there are specific solutions
already in this space (guidance on how to use these is within scope).
Providing AR services that span multiple physical bearers is
significantly more complex and typically requires processing of SI table
information - solutions also already exist in this space e.g. proposed
by ATSC and DVB (guidance on how to use these is within scope).
I'd encourage an approach which is simple.
Rod is that any help? Do other people have thoughts?
Gorry