Re: IP -> PES -> MPEG TS?

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

Let me try and help -

You seem to be asking, *WHY* do this?

First, let me say MPE can be used exactly as you say. I agree.

Second, let's now look beyond what we have today. IP was originally seen as
a supplementary service by DVB to video transport - BUT, DVB is now proving
a good platform for building true IP networks (both terrestrial wireless and
satellite). So, is it optimal, does MPE constrain the design?

I'd argue it is inefficient (especially in terms of header processing) AND
that current systems are far from plug-and-play. There's also potential for
doing much more, when we look at DVB-T, two way DVB-S (DVB-RCS) and DVB
switched networks.

If you look at the requirements documents, the new encapsulation aims at the
latter, while recognising that MPE would likely continue in use for some
applications.


on 23/3/02 9:07 pm, TAKEI jun at takei@csm.jcsat.co.jp wrote:

> From: Ghassane Aniba <Ghassane.Aniba@sophia.inria.fr>
> Subject: Re: IP -> PES -> MPEG TS?
> Date: Fri, 22 Mar 2002 18:50:42 +0100
> Message-ID: <>
> 
> Ghassane.Aniba> HI,
> Ghassane.Aniba> 
> Ghassane.Aniba> Patrick Cipiere wrote:
> Ghassane.Aniba> >
> Ghassane.Aniba> > IP packet in MPE datagram section in MPEG2 Transport packets
> Ghassane.Aniba> >
> Ghassane.Aniba> > Patrick.
> 
> 
> Ghassane.Aniba>  i ask if we can put directly ip in MPEG2 TP.  As i
> Ghassane.Aniba>  know, we use MPE to have the destination adress, and
> Ghassane.Aniba>  so we could
> Ghassane.Aniba> filter IP paquets in Layer 2. But, if we have a
> Ghassane.Aniba> mapping between MAC Adress and PID in the receiver, so
> Ghassane.Aniba> we don't need to transmet the MAC, because we already
> Ghassane.Aniba> transmit PID.  Could someone give me his opinion,
> Ghassane.Aniba> thanks.
> 
> I can't understand why you want to map IP address or MAC address into
> PID.
> 
> PID = 13 bit
> MAC = 48 bit(ethernet)
> IP  = 32 bit or 128 bit
> 
> PID has been designed as a PROGRAM IDENTIFIER in broadcasting
> world. MAC and IP address represent identification of the
> communication node. If you map MAC address and PID, PID will be a MAC
> address. 

PID is not really a MAC address.

It's a subnetwork flow-id. There COULD be a one-to-one mapping between IP
address and PID, or more-likely, several IP destination addresses map to the
same PID.  It could even be that the same IP address maps to several PIDs.
(Such things are common in networks which support QoS, and need to assign
e.g., priorities, to flows within a subnetwork.)

Nothing that has been said so far on this list has assumed that you allocate
one PID per receiver.  That means it acts only as a pre-filter, some
unwanted packets would still be received and sent to the IP layer. If it's
IP packets, then this filtering can be done in the network layer by the IPv4
or IPv6 forwarding code. You can do this in hardware or software (providing
you can find and filter the addresses easily).

N.B. If you want to process non-IP datagrams (including arp), then you need
to use a MAC frame.

> That means PID is not Program ID but Receiver ID and the
> number of receiver would be less than 8191. Do you think it is
> scalable?

Not scalable (but also note need for multicast and subnetwork broadcast).

BUT, that was not what was being suggested.

> --
> JSAT
> Jun Takei
>