(4 bits from PID * 24 bits from @link_sat_adress) == 28 bits.

[Ghassane Aniba <Ghassane.Aniba@sophia.inria.fr>]

Kearney wrote:
> 
> 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.

No, when i say that we'll map 2^28, i mean that we will use 4 bits from
PID and 24 bits which represent @link_sat_adress.
So we'll have for each PID 2^24, so what's the problem with that?

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

Absolutly not, we will have at the maximum 2^28 entries (4 bits for PID
* 24 bits from @link_sat_adress).

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

If we take in consideration, that most of IP packet are 1500 or 576, and
40 or 48, and with a simple calcul, we see that the overhead don't
affect.
One thing more, i'll present another schema of encapsulation, into
reduce the treatment on board the satellite.

> 
> > > > Thanks, and i'm waiting for all your remark or ask.
> > > >

Aniba.

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