Re: IP -> PES -> MPEG TS?

["Kearney" <clausen@cosy.sbg.ac.at>]

----- Original Message -----
From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
To: <ip-dvb@erg.abdn.ac.uk>
Sent: Monday, March 25, 2002 3:21 AM
Subject: Re: IP -> PES -> MPEG TS?

> This is a useful debate.... You seem to have two contrasting viewpoints,
> and both have merits ;-)
>
>
Maybe I am boring most of you with the following explanations and everything
that I am going to say is very
obvious to you - but let me pontificate a bit about addresses and
identifiers. After all Gorr, has suggested we keep this discussion going.

on 25/3/02 9:34 am, Patrick Cipiere at Patrick.Cipiere@udcast.com wrote:
> For me PID stands at the physical layer

correct. But before getting into an argument let´s look at some basic
concepts: first of all, what is (the purpose of) a physical-level address ?
It is an identification of a channel interface (usually called an adaptor),
intended to help the adaptor to decide whether a block/frame/packet arriving
over the channel is intended for it i.e. whether to take it off the channel
or let pass. You see this clearly when you look at e.g. HDLC or BSC where a
master-slave or a peer-peer operation (balanced mode) is possible. The
master station can thus "poll" individual stations by setting the proper
address bits in the header of the frame and/or in the balanced mode the
stations identify the intended partner on the channel this way.
This way the "medium access" can be handled in a controlled way. The scope
of these identification fields is strictly limited to one link (channel -
Ethernet calls this a "segment"). In the not so good old days you had to set
dip switches to configure terminals or other stations connected to a
particular wire; of course the number of switches was kept low - e.g. 6 or 8
switches = bits was considered sufficient.

The minute you leave one link environment (segment), cross through a
"forwarding device" to another link environment you need to introduce
another level of identification - network level (logical) addresses which
identify the device (host, node) attached to the adaptor. Of course the
"forwarding device" will have to be informed about the mapping of these
network-level addresses of the device to the physical addresses of the
adaptor.

Along came Ethernet which didn´t use dip switches any more but ICs and,
hence could afford to use much longer physical level addresses. This allowed
to make these addresses unique by e.g. including the manufacturer id, the
date of its production etc etc. At the same time it made a separate
network-level identification unneccessary - the 48-bit MAC level addresses
of the old Ethernet (and its later derivatives) are a combination of these
two
identifications and are supposed to be unique. Ethernet was based on a
common "bus" with broadcast properties and "forwarding devices"  called
repeaters. The addresses are "flat" in the sense that they do not contain
any topological information which could be used to assist in routing and
forwarding. And the whole architecture was based on the broadcast nature of
the system - no "routing" was necessary.

This changed when link-level bridges ("learning" and "transparent") were
invented and all of a sudden the "forwarding devices" had to make forwarding
decisions - which are based on the complete 48-bit MAC-level addresses and a
learning algorithm. The IEEE 802 standard defines a fairly complex solution
to this type of extended LAN.

What do we learn from this recollection: network-level addresses and
physical level address are two totally separate concepts which should be
kept separate and not combined since the functions of routing/forwarding
(switching) and interface identification are totally different.
But LANs and particularly Ethernet/CSMA-CD (EN), being the most popular
network, have made the IEEE 48-bit MAC addresses the most popular examples
and almost all people are not aware of the subtle difference of the two
addresses involved.

Now let´s move on to multicasting and start again with EN:
an EN interface operates either in a controlled mode or in promiscuous mode.
In the latter it pulls of the channel any frame that comes along and
delivers it tho the next level of protocol (the link level); in the
controlled mode it filters the blocks and delivers only those where the
destination address matches its own address - or the global broadcast
address.
When multicast was introduced, the MAC-level IEEE addresses were extended to
include this functionality by interpreting the most significant bit as the
individual/group bit - and the EN network adaptors all of a sudden had to
implement a more complex filtering mechanism including a list of
multicast addresses. Now the destination address field of every passing
frame has to be checked not only against the devices MAC-level address and
the broadcast bits but also against a whole list of multicast group
addresses - and the number of entries in this list is quite limited.
Depending on the processing speed and the data rate, most interfaces can not
handle more then just a few simultaneously. Check the manufacturers specs!

And finally, back to the MPEG-2 PID: it corresponds to the multicast EN
addresses - i.e. the interface uses a (rather limited) list of PIDs it can
filter at a time and only TS packets with these PID values are delivered to
the next level of protocol. This is all a PID is - it is a physical level
multicast asddress and does NOT identify an individual interface - and it
also does NOT contain any network-level address information.
BTW - the reason why MPE inverts the byte sequence of the MAC level address
is that this allows the hardware to filter on the PID and a few bytes of the
MAC-level address.

> and 13 bits is not enough to map a multicast IP address.
the PID is a link-level/MAC-level multicast id - the multicast IP address is
a network-level address. You will need some sort of "address resolution"
mechanism to bind the two.

> I would prefer the ethernet scheme, mapping the IP V4 (or V6)
> multicast address on the IEEE 48 bits MAC address (link layer).
>
IP multicast addresses are 24 bits - PIDs are 13 bits - no  way you could
use the EN scheme.
But don´t forget - your interface might not be capable of discriminating
more then -say- 16 or 20 PIDs simultaneously, so a pool of more than 8000
PIDs  seems totally adequate.

> Gorry wrote: 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.
>
correct - 13818 introduces the concept of a "remultiplexor" where PIDs are
rewritten and also used for forwarding decisions

>     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.
>
this is exactly what 13818-1 defines - you have a number of  tables (PAT and
a PMTs) per channel (transponder) specifying which PIDs are being used for
which bouquets (services) and there are certainly possibilites to set up an
"Internet bouquet" which has its own PMT and each entry in the PMT
identifies a multicast group. In this casse you could "listen" to several IP
multicast groups.
>
>     (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.
>
yes - and this "selected range" is rather limited - as mentioned above to
approx. 10..20, maybe a few more if hardware speeds go up.
But there is at least one level of protocol in between the TS-packet level
and the IP
level - some sort of "adaptation layer" doing encaspsulation fo the IP
datgrams - for example PPP or AAL5 or some hybrid form such as PPPoM (PPP
over Mpeg-2 - not yet5 invented!). And we could certainly filter also on
this level - and also
deliver link-level packets to different next-level protocols such as ARP or
IP or
some other network-level protocol.
Actually, if you look at the PES and TableSection headers you will find
fiels saying "stream_id" or "table_id"
and these are typically fields used for discriminating and filtering on the
next level of processing.
>

Let me stop at this point.
Gorry, lets take up your item (iii) when we figured out if we agree so far.

To summarize:
(1) MAC-level addresses are identifiers for network interfaces and are used
by adaptors to decide whether to deliver an incoming frrame to the
link-level protocol.

(2) PIDs are physical - level multicast group addresses which, of course,
can be used for a multicast group of only 2 participants i.e. in a
point-to-point mode.

(3) IP addresses are network-level entities and ident6ify devices attached
to adaptors; thea rea used by nodes for making routing decisions and by
hosts for filtering on the nedtwork level. They can be either unicast or
multicas addresses and they must be mapped to MAC-level addresses in some
way.

(4) IP datagrams (and other network layer protocol units) need to be
encaspsulated by an adaptation layer before being segmented/reassembled into
TS-packets (fixed length "cells"). This level of protocol can introduce yet
another level of identification - for example "labels" or "tags" for
switching purposes (a la MPLS) or multicast subgroups.

(5) Every frame/packet/cell crossing a "segment" will carry a MAC-level
address (individual or group) which is interpreted by the adaptors - but not
every packet will carry a network-level address since this might have been
replaced by a connection identifier (VC/VP_id) in a connection-oriented
network. [you might consider using the PID as a VC and the link-level id as
the VP]

But let's always keep in mind: satellite bandwidth is expensive, and hence
all address fields should only be as long as necessary and sufficient.

> 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 ( ;-) ).
>
>
> What do you think?
>
> Gorry Fairhurst
>
>
>