Re: New Descriptor.]

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

From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
>
>
> Gorry Fairhurst wrote:
> >
> > Ghassane Aniba wrote:
> > >
> > > Hi,
> > > thanks to gorry for his explanation..
> > > For me, i'm thinking to give for each connection (source,groupe or
> > > destination) an unique identifier, which is (PID, @link_sat_adress):
> > >
> > > |-----------------|-------------------|----------------------|
> > > | mpeg2-tp header |  @link_sat_adress |  SNDU Fragment       |
> > > |-----------------|-------------------|----------------------|
> > >
> > > The  @link_ID, will be 3 bytes. we will use 20 of PID combination with
3
> > > bytes @link_sat_adress, which give us a 2^28 possible connections in
the
> > > same time.
> >
I think this is absolute overkill - to address 2^28 multicast groups or
individual stations in ONE PID stream is unrealistic. And remember: every
bit counts.

> Could the " @link_sat_adress" be an adaptation header of EACH TS
> Packet?
>
> If so, then  I think the combined (PID<label) looks very much as an
> ATM (VP,VCI) in a pure ATM networks and the DVB  satellite - or MPEG-2
> remux looks like an ATM VP_switch.
>
> In that case the thing you mark "SNDU" be a SNDU including header,
> and encapsulation  fields including length, type, CRC, etc. ?
>
> If so , we may be fairly near in terms of format? - and each TS Packet
> carries a part of a SNDU payload + encapsulation.
>
agree!
> >
> > >
> > > In the satellite we will have, a switching table
(PID,@link_sat_adress)
> > > --> List of spots.
> > >
that would make your switching table (theoretically) 2^13 * 2^28 = 2^41
=approx 4*10^13 entries - how do you intend to implement this for an
on-board switch?

> > > For informing about the mapping between (PID,@link_sat_adress) and the
> > > (source,destination), i will use a new Descriptor, called "
> > > channel_Descriptor", which will be as below:
> > >
> > > --------------------------------------
> > > Channel_Descriptor {
> > > descriptor_tag       8 bits
> > > descriptor_length    8 bits
> > > link_sat_adress      24 bits
> > > label_switching      32 bits
> > > adress_type           1 bit
> > > source_adress        32/48 bits
> > > group_adress         32/48 bits
> > > }
> > >
> > > -----------------------------
> > > this descriptor will be, if necessary, in the PMT table, with each PID
> > > reserved for IP traffic.
> > >
>
> - This seems like the signalling part.
>
> > > I presented here a general idea, and i hope sincerly that we could
> > > improve this idea.
> > > I hope that the new RFC of IP over DVB, will be more switable with the
> > > IP over DVB-S, and specialy with the IP Multicasting traffic over
> > > satellite with the OnBoard Processor.
>
> Multicast will be interesting... and probably non-trivial.
>
yes - but absolutely important.
And we must base it on realistic assumptions and keep the overhead low. Any
additional functionality required for specific services should go into a
"next level" or adaptation header - pretty much what RTP is doing which also
limits itself to the basic real time transport function.

> > > Thanks, and i'm waiting for all your remark or ask.
> > >
> > > --
> > > Ghassane ANIBA
> > > INRIA (Projet PLANETE)             | Email :
> > > ghassane.aniba@sophia.inria.fr
> > > 2004, Route des Lucioles BP 93     | Phone : +33 4 92 38 75 63
> > > 06902 Sophia Antipolis CEDEX France| Fax   : +33 4 92 38 79 78
>