The IP over ATM Mailing List Archive by date

[Jim Forster <forster@cisco.com>]

Hi Folks,

I'll bet you've all been glad for the respite from my persistent postings
arguing against changing the encapsulations.  Well, I'm back....:-)

We seem to have gotten into this morass by the observation that MCSs echo
packets back to the sender, and the need to distinguish these
echos from originals, and the belief that this should be done below the IP
layer.  After a bit of analysis, it seems that it need not be done below
the IP layer.  The cases break down as follows:

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

- Router forwarding mcasts.  It depends a bit on the multicast routing
  protocol, but it turns out they all have mechanisms that can be used
  straighforwardly to this:

  - MOSPF & DVMRP. Both will look at the source address and if it is not
    received on the correct interface, they will silently drop it.

  - PIM.  PIM also looks at the source address, and will discard the packet
    if it is not received on the correct interface (the interface the
    router would choose to send a packet to the source -- this is the reverse
    path algorithm).  Additionally, when this happens, a Dense Mode PIM
    router will think that there is another router with a parallel path
    back to the source, and will generate a PIM Assert message to elect
    which of the two apparent routers on this net will be the forwarders.
    In the case of MCS, there is no second router, but PIM will still
    generate the Assert.  When it receives the Assert it just sent, it need
    only note the Assert's source address to realize what's happening.

So I no longer see the need for a new encapsulation, even if we do end up
wanting an MCS in some cases.  Have I missed anything?

  -- Jim


> > System architects who have reason to require MCSs can go and buy
> > a MARS off the shelf from their favourite supplier, and additionally
> > specify that all hosts must have IP/ATM drivers capable of
> > using the new encaps. Obviously this becomes one of the costs
> > they must factor in when architecting a solution for the customer
> > (given whatever range of parameters they choose to factor 'cost').
>
> This is not a matter of a tool with options. This is, so to speak, two
> different tools, as the alternatives are not compatible. As you stated
> above: "... and additionally specify that ALL hosts MUST have ...".
> 
> The fact is, most vendors would interpret your "options" as requirements
> (the "MUST" above).  This would delay product offerings, which for many
> of us, vendors and customers, is not a good thing. IMO, There should be a
> compelling justification for this (a new encap), which I have yet to hear.
> 
> -Greg
>