RFC 2098 (rfc2098) - Page 3 of 18


Toshiba's Router Architecture Extensions for ATM : Overview



Alternative Format: Original Text Document



RFC 2098          Toshiba's Router Extension for ATM       February 1997


   Another internetworking architecture is "NHRP (Next Hop Resolution
   Protocol) Model" [NHRP09].  This model aims at resolving throughput
   and latency problems in the Classical IP Model and making the best
   use of ATM.  ATM connections can be directly established from an
   ingress point to an egress point of an ATM cloud even when they do
   not share the same IP address prefix.  In order to enable it, the
   Next Hop Server [KAT95] is introduced which can find an egress point
   of the ATM cloud nearest to the given destination and resolves its
   ATM address.  A sort of query/response protocols between the
   server(s) and clients and possibly server and server are specified.
   After the ATM address of a desired egress point is resolved, the
   client establishes a direct ATM connection to that point through ATM
   signaling procedures [ATM3.1].  Once a direct ATM connection has been
   set up through this procedure, IP datagrams do not have to experience
   hop-by-hop IP processing but can be transmitted over the direct ATM
   connection.  Therefore, high throughput and low latency
   communications become possible even if they go beyond IP subnet
   boundaries.  It should be noted that the provision of such direct ATM
   connections does not mean disappearance of legacy routers which
   interconnect distinct ATM-based IP subnets.  For example, hop-by-hop
   IP datagram forwarding function would still be required in the
   following cases:

   - When you want to transmit IP datagrams before direct ATM connection
     from an ingress point to an egress point of the ATM cloud is
     established

   - When you neither require a certain QoS nor transmit large amount of
     IP datagrams for some communication

   - When the direct ATM connection is not allowed by security or policy
     reasons

2) IP level resource reservation and flow support

   Apart from investigation on specific datalink technology such as ATM,
   resource reservation technologies for desired IP level flows have
   been studied and are still under discussion.  Their typical examples
   are RSVP [RSVP13] and STII [RFC 1819].

   RSVP itself is not a connection oriented technology since datagrams
   can be transmitted regardless of the result of the resource
   reservation process.  After a resource reservation process from a
   receiver (or receivers) to a sender (or senders) is successfully
   completed, RSVP-capable routers along the path of the flow reserve
   their resources for datagram forwarding according to the requested
   flow spec.




Katsube, et. al.             Informational