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

[<harri.hakulinen@nokia.com>]

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.

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.

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..)

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).

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.) 

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.  

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.. 

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). 

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.

Br,

// Harri Hakulinen
// Sr. Technology 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