I think the key thing for the group to keep in mind as you review your architecture and scope is that there are systems in use today on ATSC and DVB MPEG-2 transports that, while simplistic, are not wrong for some applications. And, they are not likely to change, and are in fact growing. These systems followed ISO's recommendation (13818-6 amendment) on how to carry network packets. And, devices today that work with MPEG-2 are used to encoding and decoding all non-video, non-audio information (including network packets and other things) in MPEG-2 sections, not raw transport packets. Devices that handle the multiplexing stages of the transport encode and decode processes (which may be different devices) are used to operating with these headers without necessarily knowing what's in the payload.
For multicast and other inherently large payload packet applications, the overhead of the section header is obviously not an issue, and service discovery is done by "other means" more compatible with overall service discovery on the transport. Many times, the IP stream is related to only one set of components in the multiplex, and service discovery is done at a layer higher than the IP stream itself to be sure one decodes the "right" IP stream.
That is not to say that an efficient means is not also needed for the carriage of small packets (telnet sessions and general IP traffic), and design work needed to make an MPEG-2 transport a "real" link route, where that is its primary purpose.
Also, be careful how you define the subnet. An MPEG-2 transport is a multiplex, and all components of the multiplex are never decoded concurrently, when used for television anyway. Thus, the subnet is something less than the full transport. A/92 treated this topic. Also note that A/96 is about the return channel operation using more traditional transports to connect from the decoder back into the Internet.
Regards,
Mike
At 11/9/2004 05:12 PM, Gorry Fairhurst wrote:
On 8/11/04 3:07 pm, "Allison, Art" <AAllison@nab.org> wrote: > Gorry <snip> > > The committee members may find ATSC A/96 - 'Interaction Channel Protocols'> of some interest with respect to the two-way standardization work; though it> may not be directly usable. See http://www.atsc.org/standards/A_96.pdf > > A small correction, the document is at: http://www.atsc.org/standards/a_96.pdf I'd recommend reading sections 6 & 7 which discuss networking - although the description is rather end-host centric, its clear this also anticipates routing/bridging to a LAN. Gorry