The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-May> msg00158



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

New encaps not really needed for Multicast Servers

  • From: carlberg@tieo.saic.com ( Kenneth Carlberg)
  • Date: Thu, 18 May 95 08:52:33 EDT
  • CC: ip-atm@matmos.hpl.hp.com, dino@cisco.com

Hello,

> - End System sourcing mcasts directly onto ATM.  When the echo comes back
>   it's clearly trivial to look at the source IP address and discard the
>   echos.

Out of curiosity, do all end systems currently have this filtering
mechanism ?  If not, which ones am I going to have to restrict from
participating in ATMmc using MCS (until those vendors decide if and 
when to support this filtering mechanism) ?

Also, there is an implied view (at least on my part) that if I attach
my host (or your router :-) directly to the ATM network, then I need to
pump _out_ a lot of data, which of course will be echoed back to me
using MCS. Hence, if my node has to also filter out echos at the IP layer, 
then I'm wasting CPU cycles (and worse, suffering from memory access 
latency) in dropping IP packets.

I thought routing vendors developed rashes whenever memory has to be 
accessed :-)

Now if the natural response is "well don't use MCS", then no solution
has been found and we are back to square 1 in needing to change encaps.
Other than that, if I'm wrong (and I hope I am) and no encapsulation 
changes are needed to support MCS, then *amen* and pass the butter so we 
can move on to other stuff.

-ken