Re: IP -> PES -> MPEG TS?

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

on 25/3/02 9:34 am, Patrick Cipiere at Patrick.Cipiere@udcast.com wrote:

> 
> "Kearney" <clausen@cosy.sbg.ac.at> wrote:
> 
>> Yes - it identifies a broadcast channel; if you "tune" your receiver to this
>> PID you will receive all TS packets from the incoming TS multiplex of an
>> MCPC channel which have exactly this PID value. This corresponds largely to
>> a multicast group address on an Ethernet interface.
> 
> I do not agree. For me PID stands at the physical layer, and 13 bits
> is not enough to map a multicast IP address.
> I would prefer the ethernet scheme, mapping the IP V4 (or V6)
> multicast address on the IEEE 48 bits MAC address (link layer).

This is a useful debate.... You seem to have two contrasting viewpoints, and
both have merits ;-)

So, let me add some observations myself...

The PID lets you specify a flow at the subnetwork level. What can/should we
use this for?

    (i) We could use this to tell a multiplexor where to "forward" the data
    - if we have a hierarchy of multiplexors connected to several feeds, we
    can send some MPEG-2 TS to some feeds, others to only only one feed,
    etc.

    This is the basis of various schemes suggested/implemented for example
    to perform on-board MPEG-2 TS packet switching. (There is some
    resemblance to Ethernet switching here).


    (ii) We can use the PID as the basis for differentiating type of flows,
    some PIDs denote video streams, tables, use of encryption, presentation
    time stamps, etc. This is a demultiplexing function.


    (iii) We can use the PID as the first level of filtering at receivers.
    Receivers can filter and forward only a selected range of PID values to
    the host/router to which they are connected. This CAN reduce receiver
    processing. NOTE that the IP layer must still filter as well, but does
    not need to see every packet sent over the feed.


So (iii) is the point in question...

Consider a MPEG multiplex feeding a large group of receivers.
I think the MAC address ***is*** useful.  It provides per-receiver filters
for unicast (reducing unwanted traffic at the receiver). If you wish to do
multicast support, then you also need to expect IP-level filtering, because
there is not a one-to-one mapping of IP group destination address to MAC
address. I think if we go along this line, we should use a full MAC header -
source, destination & type - with CRC-32. That way, we really do have a
"LAN" in the sky, and can do proper LAN emulation, and support IPv6 as well
as IPv4.

On the other hand, why not also allow the next generation systems to use
native IP support, without a MAC header?  This would require the receiver to
do per-packet IP level filtering, (as an IP router does).  If we think
carefully about the structure of the encapsulation, we should be able to
allow (hardware?) processing of the IP address by the interface card - much
the same as MAC addresses are currently processed. This can have several
merits:
(a) If we think about efficiency, we can now have a *VERY* small header per
packet. I'm keen we get this right, if we can.
(b) Some uses of DVB, are simply point-to-point links, or unidirectional
point-to-multipoint links. I'm thinking here of uses by network service
providers providing BGP-style connectivity between networks. Such topologies
do not NEED inidividual terminal subnetwork addresses (MAC) (they can be
"unumbered" IP interfaces at the network level too).


Do this two cases capture to the two points of view?

Are there other topologies / needs out there?

> 
>> Finally - satellite networks behave differently from LANs (two-way, very
>> short delay, cheap bandwidth) and, hence, transferring solutions from the
>> LAN world to MPEG2-S networks is not a reasonable approach.
> 
> I do not agree. When you use UDLR (RFC3077) the satellite link behaves
> as a broadcast LAN and you can re-use almost everything from the LAN
> work.

Yes - in UDLR, you have a good case using MAC addresses with this, but
that's may be not surprising, since it's an Ethernet LAN emulation scheme,
rather than a native IP scheme.

But there ***are*** other scenarios...

    What happens when we have several feeds in use simultaneously?

    There's also two-way satellite links.

    Satellite links with on-board processing (soonish).

And, we shouldn't confine this debate to satellite:

DVB-T has interesting possibilities for IP transport, and may also have an
urgent need to address the issues of multiple feeds carrying the same
multicast groups ( ;-) ).

> 
> Patrick.

What do you think?

Gorry Fairhurst