The IP Over NBMA (ION) Archive

[Albert Manfredi <manfredi@arl.bna.boeing.com>]

I think AREQUIPA is also a peer-to-peer shortcut protocol? RISP struck
me as similar in that regard, although RISP is not attempting to make
the IP end stations make special use of ATM-specific features as
AREQUIPA does. RISP seems to to address the same shortcut goal NHRP
does, but without a server.

I like the concept. I have a couple of comments on the writeup
draft-ogawa-responder-shortcut-path-01.txt

1. You state that RISP requests (for a shortcut path) can be forwarded
by any conventional router. Is this true? I would agree only that any
router connected to the same ATM infrastructure as the RISP requestor
can forward a RISP request. Otherwise, you will soon encounter a
situation in which the request transits across non-ATM nets, arrives at
a RISP-capable end station, but this end station cannot set up the
shortcut path. Or maybe it can, if the ATM network has a weird shape
which makes the routed path shorter than the "shortcut" path. In which
case the RISP path will not really be a shortcut. (Think of a
banana-shaped ATM net, for instance.)

So perhaps even the non-RISP routers must at least be smart enough to
only forward RISP requests along to those ports which are _also_ ATM
ports. As to solving the banana-shaped problem, I'm not sure how RISP
could do this. Maybe it doesn't need to.

2. How about multicast? In principle, RISP requests could also be
transmitted either by the ATM source of a multicast, when using the VC
mesh approach, by the MCS (multicast server) in an MCS scenario, or even
by an mrouter when the mrouter has ports into ATM nets. The MARS
(multicast address resolution server) would not be affected, I wouldn't
think.

3. How about aging of the shortcut? Should long-lived RISP-generated
SVCs be re-established at certain intervals? I guess this is a pretty
general question about shortcuts.

Bert
manfredi@arl.bna.boeing.com