The IP over ATM Mailing List Archive by date

[Werner Almesberger <almesber@lrc.epfl.ch>]

Curtis Villamizar <curtis@ans.net> wrote:
> This mechanism fails completely if the host is one ethernet or FDDI
> hop away from the ATM network or for any other non-ATM service that
> offers QoS.

We tried to be very careful to phrase how we position Arequipa, but
maybe we weren't careful enough, so let me re-iterate:

 - Arequipa neither tries to be yet another next hop resolution/routing
   protocol nor do we intend it to replace NHRP
 - Arequipa neither tries to be yet another RSVP, nor do we intend it to
   replace RSVP
 - Arequipa is strictly confined to an end-to-end ATM scenario

The idea behind Arequipa is to provide a one stop shopping solution
that can be easily implemented on existing systems without requiring
extensive protocol modifications. We think that NHRP and particularly
RSVP on ATM won't be stable very soon (simply because they're solving
difficult problems and this always takes some time) and that it's
better to use an independent protocol (if easy to implement) to provide
some of the functionality needed as soon as possible than to rush out
some immature early version of NHRP and RSVP. You might want to view
Arequipa as a transition protocol in this sense.

Now why can't we just wait until NHRP and RSVP on ATM are done and
widely deployed ? First of all, Arequipa allows to develop applications
and protocols that already make use of all the QoS guarantees that will
later be provided by RSVP on ATM, so new requirements on applications
and protocols can be identified and they can be developed in parallel
(e.g. I'd expect that some significant work will be needed to define
mechanisms to indicate QoS requirements/capabilities before the
actual transfer is initiated).

Applications should even be easily portable from Arequipa to an RSVP+
NHRP-based world, because they use almost the same API (and we'd
appreciate advise for how we could improve that compatibility where
necessary). Compare this with the "native ATM" applications people
might be forced to implement if there's no IP solution. Also,
requirements on ATM networks can be tested in more realistic ways,
particularly in WANs.

> I recommend that the WG not adopt this draft.

We think that there is a need for a protocol to fill the gap between
the past (routed ATMARP or IP-flatnets) and the future (NHRP+RSVP) and
that's why we designed a protocol that is easy to implement and that
won't stand in the way of NHRP and RSVP, and we also think that IP-ATM
is the right forum to present such a protocol to, because it fits
service-wise in the evolutionary direction IP-ATM is taking, although
it uses different mechanisms to do so.

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, DI-LRC,EPFL,CH   werner.almesberger@lrc.di.epfl.ch /
/_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/