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