The IP Over NBMA (ION) Archive

Cell Relay Retreat>ION Archive>month:1996-Jul> msg00045



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

shortcut routing

  • From: Grenville Armitage <gja@bellcore.com>
  • Date: Tue, 09 Jul 1996 10:48:22 -0400
  • cc: ion@nexen.com, gja@faline.bellcore.com

David,
	[..]
>>The argument/debate seems to be:
>>
>>1) There exist some problems (e.g. IP multicast over a large ATM cloud
>>where the size of the multicast groups is very large), where
>>straightforward use of NHRP causes an excessive amount of signaling
>>messages to be processed/generated by senders to that group. Some people
>>have concluded from this that NHRP is not useful.

Please - to encourage clarity of people's understanding of the issues
here I'd like to see an end to this bogus association of NHRP with
multicast (cut-through or otherwise). It lacks the facilities to manage
pt-mpt SVC forwarding pathes after their establishment. Tracking unicast
link layer destinations and multicast link layer groups are almost
orthogonal problem spaces. (i.e. there is no 'straightforward use of
NHRP' that has been analyzed in this thread.)

>>2) Another view is that there exist a number of problems (e.g., unicast
>>cut-through, IP multicast over small multicast groups per above draft)
>>where NHRP provides useful solutions. Other people have concluded from this
>>that NHRP is useful.

Yakov's draft (such as I remember of it) was not to do with small mc
groups per se, but the interconnection of mrouters attached to the edges
of a transit ATM/NBMA cloud. It demonstrates an interesting application
of NHRP (but is a solution to a problem that can be solved in other
ways).

NHRP addresses a palpable need people have to dynamically bypass
topological mismatches between IP unicast paths and underlying
ATM paths. That is all. (It is only of secondary importance that
you reduce the number of reassembly/segmentation hops.) In so far
as it achieves this need, it is a good thing. However, it is
also worth remembering that if you minimise your topological
mismatch, you reduce the need for unicast cut-throughs (regardless
of the name of the protocol you use to discover them).

The issue for multicast cut-throughs is not whether you can conjecture
a use for them, but whether it is worth the effort to construct and
manage them.

cheers,
gja
_________________________________________________________________________
Grenville Armitage           http://gump.bellcore.com:8000/~gja/home.html
...loony at large.