Re: Number of PID

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

From: "Ghassane Aniba" <Ghassane.Aniba@sophia.inria.fr>
Sent: Tuesday, April 23, 2002 2:24 AM
Subject: Number of PID


> Thomas 'Dent' Mirlacher wrote:
...
SNIP
...
> > and there are a couple of possible solutions (also remember there
> >         are receivers out there which are not capable of filtering
> >         2^13 PIDs)
>
> We will not use 2^13 PID. In the first time we'll use just 4 bits from
> 13 bits (20 PID), as you say, the receivers, until now, could only
> filter 20 PID.
> That's why i've said, we will have 2^28 connection (4 bits from PID and
> 24 from @link_sat)
>
> >
> > 1) put all the traffic in one PID
> >         + simple implementation on the receiver side (just filter a
> >                 single PID)
> >         - load on the receiver
>
> We won't profit from the PID if we do like this.
> In fthe future if the receivers, will be able to filter more PID, it
> will be profitable for us, and we won't need any change in our schema.
>
in the future faster chips might allow you to scan more than 20 PIDs
simultaneously but certainly not one or two orders of magnitude more
and in the future you might encounter higher data rates from the channel
which would compensate the increase in processing speed


> >
> > 2) put unicast inside one PID
> >    group multicast in several other PIDs
> >         + (see above - at least for P2P connections)
> >         - for the unicast case, there's no easy way to
> >                 do fast filtering (ar HW/FW level, without
> >                 looking at the IP address - so the work
> >                 needs to be done in the IP stack)
>
> Another problem, there isn't enough PID to do it.2^13.
>
the way in which Ethernet treats IP multicast address binding is not the
only way in which this could be done - how are ATM networks doing this?

> >
> > 3) put every connection into a single PID (like PVCs)
> >         - PID space exhaustion: possible problems with OBPs (like
skyplex)
> >         - most existing receivers cannot HW-filter more than n-PIDs
>
> This is why we will just use i20 PID n the first time.
>
> >
> > all the above points share the need for an IP->PID table.
> >
> It's clear.
>
> >         tm
> > --
> > in some way i do, and in some way i don't.
>
> Aniba.
>
SNIP

--cls