Re: About some issues (RE: Alcatel Space interest about IP/DVB)

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

From: <harri.hakulinen@nokia.com>
To: <ip-dvb@erg.abdn.ac.uk>
Cc: <Stephane.Combes@space.alcatel.fr>
Sent: Wednesday, April 17, 2002 3:23 AM
Subject: About some issues (RE: Alcatel Space interest about IP/DVB)


>
> Hello everyone,
>
> after following the list in silent mode, I decided to make some
> comments to issues that I have seen frequently under discussion
> since I got involved with the "IP over DVB" concept back in -96.
>  good - we need to get all the "silent" listeners to start participating.
Thanks for getting involved.

> My current interest to this work relates to the DVB-T domain,
> but as we know, most of the issues are common for different
> DVB mediums.
>
> I am not "the great MPE lover", but the point of the standards
> usually is to stick with it (until the new one comes in..).
> MPE also is a typical creation of commitee, but I think that it
> was honestly trying to reuse the capabilities of the reveiver
> hardware that existed or were in sight when it was defined.
>
I think we are really looking more into the future of and not at an
immediatel alternaive or raplacement of MPE. This will stick around for a
while since there is equipment available that supports it. But ther might be
nwo applications and systems showing up....

> Comparison to ATM
>
> It is a matter of taste, if this makes any sence, but if you
> do it, I think that it is fair to say that PID is roughly the
> same concept as VPI(/VCI) in ATM. And, what is even more
> interesting, mpeg section format is very close to AAL5, or
> at least it offers the same functionality (and of course,
> MPE builds on mpeg section format..)
>
this is a point where I disagree. A  VP/VC   is basically a point to point
connection whereas a PID is a broadcast channel. I guess this is one of the
reasons why MPE looks the way it is - people saw it just as another sort of
LAN - based on broadcast properties of the channel.

AAL5 is a lot "leaner" than the Section structure which is really tailored
to the transmission of tables which represent signaling and control
information for the PES streams which are part of the respective "program".
AAL5 is a good example for a minimal encapsulation - it baiscally contains a
length field so you do not have to search for a terminating bit pattern and
a type field - which in the case of AAL5 consists of two parts - both until
now pretty much open to interpretation and not (yet) standardized. And it
makes uses the last cell carry this information, together with the CRC.

> If I remember it correctly, there is or was a version of DSM-CC
> specification in MPEG (or some spec in DAVIC), that is/was in
> fact using the same idea to encapsulate "IP over sections" than
> the famous RFC 1483 ( by Juha Heinänen) specified for ATM/AAL5.
>
> Multifeed/ "satellite onboard processing" case
>
> If we recocnise, that PID actually forms "a connection" or "a pipe"
> in a same sense than VPI/VCI does in ATM, it means that every
> "feed" should use it's own PID to transmit, and every receiver
> should receive from those PID's separately (and thus listening
> to those feeds that it is interested in).
>
of course you can consider the TS packet stream conveyed by one PID as a
"pipe" i.e. point to point, but in general it is a broadcast channel. You
can multiplex several services on one PID if you introduce a discriminator
("label", "address") on the next level and use this for filtering - actually
both, PES and Section packets have such a field called stream_id resp
table_id in the MPEG standard.

> This also means, that "onboard swicth" in satellite systems should
> in fact be a remux, forming an "multiprogram transport stream"
> from incoming "singleprogram transport streams", if it is working
> in MPEG TS level. (In other words, satellite onboard processor
> should not be able "to mix" ts packets coming in with different
> inputs by using the same PID.)
>
what is the difference between a remux and a switch ???

> Now, if the number of feeds is so large, that PID "space" is not
> large enough, or if receivers are not able to listen/filter big
> enough number of PID's, we are in trouble if we are trying
> to limit ourselves to MPEG TS processing.
>
As far as I know (but I may be mistaken) a state of the art IRD can not scan
simultaneously more than a few (say 20 .. 30) PIDs at one time - for
Ethernet interfaces the number of multicast MAC addresses it can scan at any
one time is also limited to "several" - it is definitely not a very large
number.

> What we need to do in that case is to broke the "connection/pipe"
> onboard, and do whatever layer 3/4 switching that we want
> (including MPLS, Ethernet, IP etc.). After that we can create
> a new connection(s)/pipe(s), that are carrying the desired
> layer 3/4 packets down to receivers..
>
I believe if you want to put something up in space you wsant to make it as
simple an reliable as possible and keep complex functions at the terrestrial
gateway. If you need to switch onboard you should chose a simple an robust
structure. I believe that one of the most interesting appoaches for some
types of applications, e.g. for distribution, is the SkyPlex system which
was developed by ESA and Eutelsat - this is basically an onboard
multiplexer. Of course it can not support spot beam configurations but it
can broadcast from many uplink stations to a very large footprint.

> This was little bit satellite specifig, but it may also apply
> to backbones that are used for terrestrial networks. Or at least
> it should be kept in mind when thinking how and when to use
> (or better not to use) MPEG TS as the backbone transport medium.
>
> Maybe one of the areas that this group wants to concentrate on
> is to clarify the roles of MPEG TS transport layer, IP layer and
> the possibble switching layer in bethween (e.g. MPLS or Ethernet).
>
yes - I think that is the point.

> Flexibility of MPE
>
> I belive that originally MPE was designed so, that you could in
> fact use whatever you want in the place of "MAC address", at least
> in proprietary systems. I think that the "undocumented" feature in
> question may have something to do with the "payload and address
> scambling" bits (defined by service), but someone else may know
> that better.
>
> If that is true, I quess you could use that space to something
> like MPLS labels, or whatever else comes to your mind. Maybe
> this is also something that this group wants to consider together
> with DVB groups.
>
there is one point to keep on mind: for wireless systems, in particular for
satellites, bandwidth is an EXPENSIVE resource, so you want to keep the
overhead as small as possible - and this goes in partucular for the header
which is transmitted with each cell - pardon, TS packet. People always look
at Ethernet as an example - but many of the design decision for Ethernet
were made under the assumptions (a) bandwidth is cheap, and (b) propagation
delay is low (and you can do CD - collision detection). Ther are working
groups looking very actuvely at header compressionm so you can reduce the IP
overhead down to a few bytes - and we should follow this example and look
very carefully at each byte we want to include in the encapsulation header.

And yes - we should cooperate with the DVB and ATSC groups.

--Horst Clausen ("kearney")



logy Manager
> // Nokia Ventures Organization
>
> > -----Original Message-----
> > From: ext Stephane.Combes@space.alcatel.fr
> > [mailto:Stephane.Combes@space.alcatel.fr]
> > Sent: Thursday, April 11, 2002 2:55 PM
> > To: ip-dvb@erg.abdn.ac.uk
> > Cc: Sebastien.Josset@space.alcatel.fr
> > Subject: Alcatel Space interest about IP/DVB
> >
> >
> >
> > Dear colleagues,
> >
> > Alcatel Space Industries would like to support the work
> > currently undertaken by
> > this group.
> >
> > As requested by Gorry Fairhurst, here follows a draft of the
> > presentation we
> > could make at the next BOF :
> > (See attached file: Alcatel_space_IP_DVB_view01.pdf)
> > Note that this document is informational only but can be
> > distributed freely to
> > anybody interested.
> >
> > The general issues raised here seem to align with those expressed in
> > http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/charter.html and
> > http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ip
> dvb-req-00.doc
>
> It includes our vision for MPE enhancement. We would actually be very
interested
> if the to-be-defined encapsulation could support protocols other than IPv4
and
> v6. Ethernet and MPLS are of equal importance according to the network
segment
> the DVB (or other MPEG-2 based) links are deployed. It would be nice if a
future
> RFC could have the same role than ITU-T I.363.5 (AAL5) and RFC-2684
> (Multiprotocol encapsulation) have in the ATM world.
>
> It also details some Layer 2 labelling management procedures that we have
> developed in the frame of the BRAHMS IST project. This is perhaps more
targetted
> to a MPE "replacement". It actually includes a label distribution protocol
> (working in a similar way as Ethernet ARP) and associated encapsulation
> optimised for the broadcast nature of satellites (and thefore DVB) links.
Such
> kind of protocol could well play for broadcast links the same role than
MPLS in
> backbone networks.
>
> The main ideas behind this proposed scheme are in line with the questions
about
> a possible "native IP" support that Gorry raised in his 03/25 e-mail. PID
would
> indeed only be a first level of filtering at receivers. IP filtering would
then
> be based on IP destination address. An additional label at layer 2,
identifying
> the source of the IP flow, could help avoiding to re-assemble all the IP
traffic
> received on a given PID (and allow proper re-assembly if packets are mixed
by a
> satellite on-board processor). Therefore a limited link layer header might
still
> be useful. The other characteristics of our scheme is that it naturally
supports
> multiple feeds configurations, two-way satellite links and on-board
processing
> (no more multisource multicast headaches !)
>
> You'll find more details about BRAHMS project at
> http://brahms.telecomitalialab.com/. There was also a paper published at
last
> year's AIAA conference ("IP Dedicated : a new Internet oriented satellite
> transfer scheme", I. Buret et al., 19th AIAA ICSSC conference, april
2001).
> Note that some outputs of the BRAHMS project have already been presented
at the
> ETSI BSM. Actually, the same presentation which is included here is being
sent
> to the ETSI BSM mailing-list.
>
> Feel free to share comments on this list,
> Best Regards,
>
> Stéphane COMBES
>
>
> ALCATEL SPACE INDUSTRIES
> Research Department/Advanced Telecom Satellite Systems
> Tel : +33 (0)53435 6938  /  Fax : +33 (0)53435 5560
> Porte : F1027  /  E-Mail : stephane.combes@space.alcatel.fr
>