Re: Réf. : Re: Alcatel Space interest about IP/DVB

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

Hello Stéphane>
> Thanks a lot for your reviewing and comments !
>
let's keep the discussion cooking!
> By "Ethernet-like" we only mean "connectionless layer 2 based on broadcast
> medium".
Question - why does it have to be connectionless?
Most of the applications are anyhow sessio-oriented - TCP, HTTP, and in
particulatr multicast applications are based on the concept of a session. If
you "tune" your receiver to a PID you are basically opening a session - so
why wouild you like to have the next higher layer (link/encapsulation)
connection-less?

> Nevertheless we do not propose to re-use the addressing scheme of
> Ethernet.
I found it pretty interesting that the ATSC people renamed this thing a
device-ID - that is a pretty correct name for the thing. If in the future we
go to 64-bit exteded IEEE MAC-deviceIDs then we can use this thing for
authentication and authorization, for example on the Return Channel System
when a station becomes active. But once we assigned a "label" to this
connection or multicast stream whihc the station joined, ther is absolutely
no need to include the deviceID in every packet.

> As I said in my previous e-mail, using a label uniquely identifying a
> "source" in a "subnet" may be enough and much more flexible for the
systems we
> target.
agree
>
> MPEG-2 layer would indeed be seen like ATM layer where PID would bear a
> significance analogous to the VPI (aggregation of flows - but here from
> different sources and towards several destinations - , first level of
> filtering).
>  It would indeed be very nice if a new link layer protocol could be
transported
> seamlessly over MPEG and ATM (very interesting for DVB-RCS systems which
use
> MPEG as forward link and ATM as return or mesh link).
> The filtering performed at the level of this new link layer on top of MPEG
would
> be similar to MPE filtering (we do not need to have the MPE address in
each TS
> packet), at least for Gateway Terminals transmission (if we consider
Gateways do
> not share the same PID for emission).
I am sure we can come up with a more efficient link-layer encapsulation. The
proposal we have submitted is still very close to the audio/video (PES) and
table section (PSI) of MPEG-2. I read the standard many times - well, at
least those parts that refer to "private" data and I come to the conclusion
that the people who wrote this standard have been very nice to future "data"
applications. They did not address the Internet at that time but they left a
lot of freedom in the standard and one could come up with a much more
radical approach.
Just as an example: the semantics of the PUSI bit is left totally
unspecified for private data; hence we could do the same thing as the AAL5
people did and flag the end instead of the start of a packet. However, I am
not so sure how some of the "standard" IRDs would react to TS packets of
this type?
It also seems to me that the AFC bits could be re-interpreted for private
data streams in a different way.
I hope we will get some expert opinions on this in this group.
And I wouild be jut soo glad to get inputs from the DVB and ATSC folks!

> For user Satellite Terminals (sharing a
> DVB-RCS access for instance), the additional label would indeed be
included in
> each TS (if we consider several such terminals share the same PID for
emision).
>
yes - agree. One question that arises is - do we have a separate
encapsulation for teh forward and the return links or should only one be
proposed which can handle the differences in a hidden "convergence" layer?

> As far as switching is concerned, only the PID would be used for such a
purpose
> (not the additional link layer label). For example, we could have a MPEG
switch
> on-board the satellite. And in such a case, we are very very limited by
the PID
> numbering space. Therefore this additional label would be needed.
>
the PID number space is not this small if you use each PID as a broadcast
network and not as a point-to-point  link. If you have spot beams you wouild
have to assign (at least o ne) PID to each spot and switch onboard on the
PID only - and leave the filtering to the "gateway" and the link layer.

> So I guess we basically agree with you that Ethernet addressing is not the
ideal
> solution for networks other than Ethernet. But such proposal for a
complete "MPE
> replacement" (although trying to keep a similar filtering and re-assembly
> process) would indeed only be justified for new systems. We propose to
explore
> this for multiple-feeds and "mesh" capable systems (allowing direct
> terminal-to-terminal communication).
>
I think what we are looking for in this group is a long-term "New and
Efficient Encapsulation Scheme" for doing IP or possibly any other network
over MPEG-2.

> Does this clarify our requirements ?
>
sure

> Cheers,
>
same
--Horst

> Stéphane
>
> 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
>
>
>