ATSC

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

Art, 

Sorry for the terse answer, earlier. The authors (and I do expect the WG
too) value the inputs and experience of both the ATSC & DVB communities.

The chief goal of the WG is to develop protocols and documents to define how
the IP protocol suite (both IPv4 and IPv6) is to use these services as a
link within the Internet.  It includes specification of appropriate ways to
bind the end-to-end IP addresses to the L2 network. This also explicitly
includes how arp, neighbor discovery would be used, how to handle multicast
routing, support for Uni-directional links, etc.

There are many scenarios in which MPEG-2 is used, and one of the objectives
of the (arch) document that just went through WGLC was to define specific
scenarios as useful basis for future work. 6 of these were defined. Scenario
A relates to the broadcast TV case (as in figure 4.1 of A/90), which you
referred to. In this case, the text of the Internet Draft seems to follow
the requirements, that you mentioned, i.e.:

Section 3.3 says:
   "In a more complex example, the same TS may be fed to multiple MPEG-2
    multiplexors and these may, in turn, feed other MPEG-2 multiplexors
    (remultiplexing). Remultiplexing may occur in several places (and is
    common in Scenarios A and B of section 3.1)."

And 5.1 says:
   "Elements (ii) and (iii) need to be de-referenced via indexes to the
    Service Information (i.e. the Program Map Table, PMT) when the
    MPEG-2 Transmission Network includes remultiplexors that renumber
    the PID values of the TS Logical Channels that they process. (Note
    that PIDs are not intended to be end-to-end identifiers). However,
    although such use is common in broadcast TV networks, many private
    networks do not need to employ multiplexors that renumber PIDs
   (see section 3.2)."

As far as I can see, the set of ATSC references in the arch document refer
only to push (uni-directional) transmission of IP multicast content.

While IP multicast is in important service for MPEG-2 bearers, the WG scope
is to provide IP in general (unicast, multicast, routing, etc), linking IP
networks using the MPEG-2 link. It would also be useful to point the WG to
any other documents from the ATSC community that relate to two-way IP
services.

Best wishes,

Gorry Fairhurst. 


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