Broadcast IP Network Model Problem Statement

IETF UDLR WG-

The purpose of this email to establish (or not) the scope of this problem
relative to UDLR WG, and if within scope, stimulate discussion on the
issues for the purpose of eventually publishing one or more RFC's to solve
the problem.

So, this is a problem statement for the issue of defining an IP network
model to facilitate the carriage of IP packets over a broadcast transport
(single unidirectional link).

Note that this issue spans several types of network topologies and
transport technologies.  But in particular, I am most interested in solving
this for the MPEG digital television transport.  However, the solution
space should apply equally well to any broadcast transport carrying IP
packets.

The basic substance of this same message is being concurrently posted to
the Implementation Systems Sub-Committee of ATSC in the United States,
where I am currently personally active, and this issue has come up.  I have
also cc'd the W3C's WWW-TV group as FYI in case they wish to join this
discussion here.

Since the problem is more general than ATSC, I am hopeful that the UDLR WG
will embrace it for solution on a general level, including of course,
solution for DVB and other similar broadcast transports.  If this happens,
then I will recommend to ATSC that it defer to the work of this group.

Note that the usage of the term "network" in this discussion refers to the
Internet definition, and not the TV definition (for any of you that are
more TV-oriented).  I'm sure some other TV terms have slipped in, but hope
they are not confusing.

Note also that the assumption is that the device in question has an MPEG
transport input, and may or may not have a full-duplex transport
"backchannel".  Although any solution model and protocols need to work in
both topologies.

Note further that at this stage, I am simply trying to convey the problem
and its applicability to IETF UDLR.  Any proposed solutions are simply
examples to help illustrate the problem.


THE PROBLEM
-----------
In the carriage of IP over a broadcast link, there are several problems
that need to be addressed in order for multiple broadcasters and receiver
manufacturers to make use of the transport in any sane manner, and without
colliding on network address usage.

First and foremost:

1. What, exactly, constitutes a "network" in an MPEG transport?  Every
broadcaster must have the same definition so that address usage is well
known, and a usable address scheme can in fact be defined.  For example, is
every MPEG Program a network?  In contrast, if a network is the entire
transport, then how does one manage IP address usage from multiple feeds by
one broadcaster?  A single transport may contain content that was authored
by different entities unknown to each other.  Or worse, in a larger content
aggregator like a cable system or DBS, how does one keep the address usage
straight on a single transport?

Then, depending on the answer to the above, there are some specific
technical problems to solve:

2. What modifications, if any, are required to the IP and Multicast-IP
address assignment and usage customary on a full-duplex transport?  [If the
"right" network model is chosen in (1) above, then the answer to this is
ideally "none".]

3. How does one convey the IP address-to-transport-specific (tuning)
bindings?  On a full-duplex transport, this is done with well-known 2-way
protocols such as ARP and IGMP.  So, perhaps broadcast-specific protocols
analogous to ARP and IGMP should probably be developed.  While this *could*
be done with transport-proprietary tables and descriptors, it would not be
"normal" to do so, and relying on proven protocols and mechanisms would
minimally improve the operation of such a device when it is also connected
to a full-duplex transport.

4. How does an API author create a programming environment on a receiver
that provides a consistent network model to the application author?  For
example, it should be the case that an application written on a network
workstation behaves identically to one written in a broadcast-receiver (TV)
without modification.  It should also be the case that an application
receiving IP packets from the broadcast stream do so in a consistent manner
with packets sent and received when the device is also connected to a
full-duplex transport.  This means that the concept of "interfaces" (local
IP addresses) needs to be well-defined and unambiguous.

I look forward to everyone's thoughts, and hope that UDLR is willing to
embrace this problem as in its scope.

Best regards,

	Mike

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122

Received on Sunday, 25 April 1999 19:13:16 UTC