[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New Descriptor.]



 From: "Thomas 'Dent' Mirlacher" <dent@cosy.sbg.ac.at>
Sent: Tuesday, April 23, 2002 1:58 AM
Subject: Re: New Descriptor.]


> On Tue, 23 Apr 2002, Patrick Cipiere wrote:
>
> >
> > "Kearney" <clausen@cosy.sbg.ac.at> wrote:
> >
> > > 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.
> >
> > How many addresses do you think is realistic?
> > I don't understand why we should not allow the full IP adresses scope
> > on one PID.
>
> another related question would be:
>
> how does the correct scheme for segmenting the IP-address space
> into PIDs look like.
>
Question: how does the scheme for segmenting NSAP or E.164 addresses into
ATM VP/VC connection IDs look?
What we really need is a solution for mapping IP addresses to either local
subnetwork addresses (connectionless) or to connecti0on_IDs (labels -
connection-oriented) and, of course, multicast groups.

> and there are a couple of possible solutions (also remember there
> are receivers out there which are not capable of filtering
> 2^13 PIDs)
>
> 1) put all the traffic in one PID
> + simple implementation on the receiver side (just filter a
> single PID)
> - load on the receiver
>
> 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)
>
> 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
>
> all the above points share the need for an IP->PID table.
>
not quite: IP->local subnetwork address ("LSA" - classical Internet datagram
philosophy), and then LSA->PID
or  IP -> local subnetwork connection_ID ("label" - see MPLS), and then
Label -> PID
> tm
> --
> in some way i do, and in some way i don't.
>
--