Re: Alcatel Space interest about IP/DVB

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

Hello Stéphane ,

in your presentation you are using the term "Ethernet-like stack". Could
yopu, please, explain what you mean exactly under this term.
The MPEG system as defined by 13818-1 has only two layers:
* the lowest being the Transport Stream Multiplex
* the upper one being the Elementary Packet Stream, PES packets and PSI
Sections
there is no physical layer - this is provided e.g. by DVB-S

Comparing this to data networks is not very obvious. The closest might be to
look at ATM - the MPEG Transport Stream packets are somewhow similar to ATM
cells - however with the big difference that the ATM cell header specifies a
point-to-point connection with the VC/CP field whereas the PID in the TS
packet specifies a broadcast channel.

The next layer in MPEG can be interpreted as either a link- or
network-level - similar to AAL5 for example although there is no  concept of
an "address" in either Sections or PES packets. If we define a new
encapsulation we could certainly include a "label" or similar discriminator
field in the encapsulation - but unless this is bound to a PID either in
one-to-one way or by including the label field in every TS packet - for
example in an adaptation field - then filtering can only be done after the
reassembly if the encapsulated packet (IPv4, IPv6, any other network or link
layer packet).

As I tried to point out in my recent pontification about addresses -
Ethernet MAC addresses are a combination of a physical-level address and a
network-level address and are not very good examples for other types of
networks.

> Alcatel Space Industries would like to support the work currently
undertaken by
> this group.
...

> 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.
This is definitely intended - ther is no reason why we could not follow the
PPP strategy and carry any type of content.

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

yes - agree; but it will be difficult to replace an existing solution (MPE)
unless we look at future systems.

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

I have some difficulties here: MPLS and other label-based systems use this
for "switching". Of course, one could build some sort of switches into a
MPEG-TS system - in a very crude way an MPEG re-mux does this.
If we consider this, then this "label" must be included in the TS-packet,
preferably in an adaptation field and "as far to the left" as possible since
hardware filtering scans from the left (this is the reason why MPE puts
the rightmost byte of the MAC address first into the encapsulation header).

If you need to swithc AND the PID space is not sufficient you need to
introduce a "label" - but then you need to decide whether you want to put
it into each TS packet or you reassemble a complete SNDU (?). It all
depends on your system architecture and applications.


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

yes - but see my comment above

> Therefore a limited link layer header might still
> be useful.

yes - I agree. But whatever we propose - we MUST stay within the
confimenents of the MPEG standards. Luckily they are quite liberal when it
comes to "private" data.

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

> Feel free to share comments on this list,

Looking forward to some interesting discussion,

--Horst Clausen

> Best Regards,

> Stéphane COMBES