The IP over ATM Mailing List Archive by date

[jkrawczy@pobox.wellfleet.com (John Krawczyk)]

   On Fri, 21 April, Timothy J. Smith (tjsmith@vnet.ibm.com) wrote:

   A creative colleague of mine just stopped by with a
   possible alternative to a new packet format solution.
   
   The proposal is to simply use the Record Route option of
   an IP packet.  Before an mcast/bcast packet gets xmitted, we add the
   interface address to the list of routes.  If we receive an
   mcast/bcast packet and our address is on the RR list,
   then we discard.
   
   The above is for a router.  A host may be required to send out
   the mcast/bcast packet with the option set and space in the packet
   allocated.  As mentioned in earlier postings,
   the host would discard a received packet if
   the source IP address was his own.
   
   This is just a thought.  Any pros or cons?
   TJS

Some cons:

1) This spreads the problem out to non-ATM hosts and routers.  How
does a host know if the mcast packet it is sending will have to
transit an ATM cloud?  Why burden the routers not connected to the ATM
cloud with the record-route processing?  If there was some way the
option was added/stripped at the cloud edges, this would not be so
bad, but....

2) With the current technology, packet forwarding performance will be
severely impacted.  Most, if not all, router vendors do not optimize
for options processing.

3) The options space in the IP header is limited.  An IP header can be
a maximum of 60 bytes, 20 of which is used for non-options
information.  If record route is the only option, you can only fit 9
IP hops.  (someone correct my quick math if I goofed...)


I would advise avoiding the IP options route (pun intended) in solving
this problem.

-jj