Internet Draft Jun Ogawa
Expires September 1997 (Fujitsu Laboratories LTD.)
Yao-Min Chen
(Fujitsu Laboratories of America INC.)
March 1997
The Receiver-Initiated Shortcut Path Protocol (RISP)
<draft-ogawa-receiver-shortcut-path-00.txt>
Status of This Memo.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
``work in progress.''
To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (WE West Coast).
Abstract
This memo defines the Receiver Initiated Shortcut Path (RISP)
protocol for NBMA networks. The protocol extends the NHRP message
set by adding Callback Request and Reply messages to allow the
destination host (or its corresponding egress router) to establish
a shortcut path for a data flow, using the existing NBMA signaling
protocols. Because of this receiver-initiated mechanism, a
shortcut-capable network can use just the NBMA ARP servers, such as
the ATMARP servers, instead of the more complex Next Hop
Servers. This draft also describes how to extend NHRP with the new,
receiver-initiated mechanism.
1. Introduction
A main goal of the IP over NBMA Networks (ion) working group is to
define efficient address resolution mechanisms for establishing
NBMA paths suitable for IP flows. Towards this goal, Classical IP
over ATM [1] and Next-Hop Address Resolution Protocol (NHRP) [2]
Jun Ogawa, Yao-Min Chen [Page 1]
INTERNET-DRAFT RISP Expires Sept. 1997
are outputs from the working group that have received significant
attention. The strength of Classical IP over ATM is its simplicity
but it cannot establish shortcut paths across multiple logical IP
subnetworks. NHRP establishes the shortcuts but the complexity of
Next Hop Servers may prevent its rapid adoption. In this memo, we
describe a way to establish shortcut paths without the complexity
of Next Hop Servers.
RFC 1577 [1] defined the concept of Logical IP Subnetwork (LIS)
which is a separate administrative entity where hosts and routers
are configured within a closed IP subnetwork. In this memo, we
describe a protocol to establish shortcut paths without the
complexity of Next Hop Servers.
The protocol is called Receiver-Initiated Shortcut Path (RISP). It
works on an environment where an NBMA subnet is divided into
multiple Logical IP Subnetworks (LISs, see reference [1]). This is
the same environment considered by both Classical IP over ATM and
NHRP.
Below, we briefly review Classical IP over ATM and NHRP and then
introduce RISP as a simple method to establish inter-LIS shortcut
paths.
1.1 Classical IP over ATM
First of all, a client must register its IP address and ATM address
with an ATMARP Server using Inverse ATM Address Resolution Protocol
(InATMARP). A client connects to the ATMARP server using a
point-to-point VC.
In the case of Intra-LIS path establishment, a sender client
resolves the receiver's ATM address using the ATMARP server. Then
the sender client establishes a path and sends IP packets along it.
In the case of Inter-LIS, a sender client sends IP packets to a
router. The router transmits these packets to the receiver using the
ordinary routing table constructed by a routing protocol such as RIP
or OSPF.
Therefore, intermediate routers become bottleneck for the speedy
transmission of data packets.
1.2 Next Hop Resolution Protocol
First of all, a client host must register its Protocol and NBMA
addresses with an Next Hop Server (NHS) using an NHRP Registration
Request message. For example, if the internetwork-layer protocol is
IP and the underlying subnet-layer NBMA network is ATM, the client
registers its IP and ATM addresses with the NHS.
Jun Ogawa, Yao-Min Chen [Page 2]
INTERNET-DRAFT RISP Expires Sept. 1997
In both intra- and inter-LIS communications, a sender client sends
an NHRP Resolution Request to the nearest NHS to resolve the
destination NBMA address. If the NHS cannot resolve it, it forwards
the request to the destination using the ordinary routing table
because the NHS is also equipped with router function. Eventually,
the NHS (router) nearest to the destination resolves the NBMA
address.
Once the destination NBMA address is resolved, the sender
establishes a shortcut path to the receiver. Therefore, inter-LIS
communication under NHRP does not suffer the router bottleneck
problem in Classical IP over ATM.
NHRP also allows an intermediate NHS to cache the NBMA address of a
destination so that later the NHS can directly resolve a request
instead of forwarding it.
In addition, note that NHRP offers not only shortcut path
establishment but also a rich set of functions beyond what is
provided by Classical IP over ATM. Here we briefly mention a few.
1) An NHS can resolve the NBMA address for an equivalent class of
internetwork layer addresses using the prefix length field in an
NHRP message (See Section 5.2.0.1 of [2] for more details). This
is useful when several Protocol addresses share an NBMA address.
2) An NHS can resolve an NBMA address from a Protocol address using
the U bit (which indicates that the NBMA address is unique to the
Protocol address).
3) To invalidate the cached information at a station(e.g. NHC or
NHS), NHRP Purge Request is defined. This message facilitates the
coherency of the information cached at multiple stations.
However, the rich set of functions comes at the price of complexity
at NHSs, which we summarize below and discuss in more depth in
Appendix-A.
a) Along with the conventional router function, an NHS must maintain
a database for address resolution. In addition, all routers in
the NBMA network must be equipped with this function when using
NHRP in the network.
b) When a LIS has multiple routers (NHSs), they need a mechanism to
synchronize the cached information. SCSP [4] is such a mechanism
being drafted by the ion working group.
c) NHRP allows a transit NHS to cache the entries contained in the
received NHRP Resolution Replys (i.e., the resolved Protocol/NBMA
address mappings in the messages). Subsequently the NHS can
resolve an NHRP Resolution Request using the cached entries.
Jun Ogawa, Yao-Min Chen [Page 3]
INTERNET-DRAFT RISP Expires Sept. 1997
However, the NHS also needs to keep track of the source address
of the request (see Appendix-A.2 for a more thorough discussion
on this aspect).
In summary, the main reason for the complexity of NHS is that NHRP
requires that the routers also perform address resolution for both
intra- and inter-LIS communications. Consider a network that is
based on Classical IP over ATM. When it migrates to NHRP,
complexity incurred on all routers due to additional requirements in
a)- c). In some cases a network operator may not want the
complexity in spite of the benefits provided by NHRP. For example,
the operator may be satisfied with just the provision of "inter-LIS
shortcut paths" but rather uses Classical IP over ATM for intra-LIS
paths. For this kind of networks, this document describes a simple
way to establish shortcut paths without the need of inter-LIS
address resolution.
1.3 Receiver-Initiated Shortcut Path Protocol
The protocol adopts Classical IP over ATM for intra-LIS
communication and defines a receiver-initiated setup mechanism for
inter-LIS shortcut paths. Such a shortcut path is set up by the
following four phases. In the Request phase, a sender sends a
request along a routed (i.e., hop-by-hop) path. In the Respond
phase, a responder, which can be either a destination host or an
egress router, sets up a shortcut path back to the sender, and then
sends a responding packet along the path. In the Transmit phase,
data are transmitted between the sender and receiver through the
shortcut path. In the Close phase, either the sender or the
responder sends a release packet to its peer, which then tears down
the path. A complete specification of the protocol will be given in
Section 3, after we introduce terminology in Section 2.
The protocol can stand alone (without NHRP) as an inter-LIS shortcut
protocol, or its functionality can be integrated into NHRP. It can
also be used as a transit step for the migration of ATMARP-based
networks to NHRP networks, because it offers inter-LIS shortcut
paths with just ATMARP servers. If later a network requires the
richer set of functions provided by NHRP, it can migrate to NHRP.
For this reason, we choose a packet format closely tied to the NHRP
packet format. The packet format is described in Section 4, and the
migration is discussed in Section 5.
2. Terminology
A "RISP host" refers to a host machine that can process RISP
messages. Where there is no ambiguity, we will refer to a RISP host
simply as a "host".
A "RISP router" is a router performing conventional
Jun Ogawa, Yao-Min Chen [Page 4]
INTERNET-DRAFT RISP Expires Sept. 1997
forwarding/routing functions as well as being capable of handling
RISP messages including Callback Request, Callback Reply and Error
Indication. The routers described in this memo, unless otherwise
mentioned, refer to RISP routers.
3. Protocol Overview
Currently, we only consider an IP-over-ATM environment. However, it
is possible to generalize the draft for other NBMA networks. This is
currently under study.
The protocol does NOT use any servers for establishing a path across
multiple LISs, but only uses ATMARP servers for intra-LIS address
resolution. So,
1) for inter-LIS communication, a host does not need to know the NBMA
address of its destination before initialing communication,
2) a router does not need to maintain a database for the purpose of
address resolution, and
3) a destination host can refuse a shortcut path request.
Below, we specify the protocol by specifying how inter- and intra-LIS
communications are conducted. As we mentioned earlier, the messages
used by the protocol will follow the NHRP basic packet format.
Therefore, we add "NHRP" in front of these messages to indicate this
fact.
3.1 Inter-LIS Communication
By default, a source host sends IP packets to the destination
through routers (hop by hop). We call a path taken this way a
"routed" path.
If the host decides that a shortcut path is more suitable for a flow
than the routed path, it sends an NHRP Callback Request message to
the destination along the routed path. We refer to this host as the
requester for the NHRP Callback Request.
An NHRP Callback Request message has the IP and ATM addresses of its
requester. It also has a Request ID to uniquely identify the
message.
When the destination or its egress router (if the destination is not
on the NBMA subnet) receives the NHRP Callback Request, it starts
establishing a shortcut path back to the requester, using the NBMA
signaling such as UNI*. This signaling is possible because the ATM
address of the requester is contained in the NHRP Callback
Request. We call the destination host or egress router the responder
for the Callback Request.
Jun Ogawa, Yao-Min Chen [Page 5]
INTERNET-DRAFT RISP Expires Sept. 1997
If the NHRP Callback Request packet contains an error then the
responder sends the NHRP Error Indication with appropriate Error
Code as described in [2].
As soon as the shortcut path is established, the responder sends an
NHRP Callback Reply along the path to the requester.
The NHRP Callback Reply message contains the IP and ATM addresses of
the responder. It also has a Request ID which is identical to the
Request ID of the NHRP Callback Request.
Upon receiving an NHRP Callback Reply, the requester verifies if the
Request ID in the message is the same as in the NHRP Callback
Request it issued. If they are the same, the shortcut path
establishment has completed. Otherwise, the shortcut path must be
terminated by the requester.
After the establishment, the requester re-directs its data packets
from the routed path to the shortcut path.
On the other hand, if the path establishment fails, the responder
sends an NHRP Callback Reply along the routed path. Such a failure
may occur because of lack of resources at the responder or some
layer-2 problem. In Section 4.2, we have a more thorough
discussion.
To terminate a shortcut path, either the requester or the responder
sends an NHRP Release Request message to its peer. When the peer
receives the message, it disconnects the shortcut path.
If the requester sends an NHRP Callback Request but does not receive
any NHRP Callback Reply or Error Indication messages with the
Request ID, it sends an NHRP Callback Request again with the same
Request ID. The interval between the NHRP Callback Requests and the
number of times for the re-transmission are for further study.
If the path establishment fails, the requester continues to send IP
packets through the routed path.
+-------+ +-------+ +-------+ +-------+
| src |-------|Router |------|Router |------| dst |
| | +-------+ +-------+ | |
+-------+ +-------+
(1) ------->------------->--------------> NHRP Callback Request
(hop by hop)
(2) <==================================== establish a shortcut
path
(3) <------------------------------------ NHRP Callback Reply
:
Jun Ogawa, Yao-Min Chen [Page 6]
INTERNET-DRAFT RISP Expires Sept. 1997
(4) <------------------------------------ NHRP Release Request
(5) The shortcut path terminates
Fig.1 Typical usage of RISP.
3.2 Intra-LIS
In the case of Intra-LIS address resolution, the protocol uses
Classical IP over ATM. Therefore, when a host wants to join a LIS,
it registers its IP and ATM addresses with an ATMARP server.
3.3 Authentication
The protocol also provides an authentication mechanism, which is
described in Appendix-B. The protocol has the option to work without
the mechanism.
3.4 Summary
The simplicity of the protocol lies in the fact that it does not
require address resolution function to establish an inter-LIS
shortcut path, because such a path is established by the receiver
using NBMA signaling.
4. Messages
The protocol requires that the NHRP to extend its message set and
assign packet type values(ar$op.type) to the new messages NHRP
Callback Request, NHRP Callback Reply, and NHRP Callback Release.
If a network merely uses the RISP functions, it only needs to
support these messages along with NHRP Error Indication.
4.1 NHRP Callback Request
This message is used by a sender host to request a shortcut path.
Unlike the NHRP Resolution Request, the nearest router or NHS of the
destination simply forwards this message to the destination host. If
the destination is outside of the NBMA subnet, then the egress
router MUST become the responder to answer this request and it MUST
not forward this request to the next NBMA subnet.
NHRP Callback Request's mandatory part is coded as described in
Section 5.2.0.1 of [2].
The message specific meanings of the fields are as follows,
Jun Ogawa, Yao-Min Chen [Page 7]
INTERNET-DRAFT RISP Expires Sept. 1997
Flags - The flags field is coded as follows,
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Set if the station sending the NHRP Resolution Request is a
router; clear if it is a host.
Zero or one CIE may be specified in an NHRP Callback Request. If a
CIE is specified then that entry carries the pertinent information
for the client sourcing the NHRP Callback Request. The usage of the
CIE is described below:
Maximum Transmission Unit
This field gives the maximum transmission unit for the source
station. A possible use of this field in the NHRP Callback
Request packet is for the requester to ask for a target MTU. In
lieu of that usage, the CIE must be omitted.
All other fields in the CIE MUST be ignored and SHOULD be set to 0.
All the Extension Parts of the NHRP can be used, but some of it may
be meaningless to the NHRP Callback Request (e.g., the NHRP Reverse
Transit NHS Record Extension).
4.2 NHRP Callback Reply
This message is used by a responder to reply to an NHRP Callback
Request. The message is sent along the shortcut path established for
the NHRP Callback Request if the path establishment is successful,
otherwise it is sent along the routed path.
NHRP Callback Reply's mandatory part is coded as described in
Section 5.2.0.1 of [2].
The message specific meanings of the fields are as follows,
Flags - The flags field is coded as follows,
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Q| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q
Copied from the NHRP Callback Request. Set if the requester is
Jun Ogawa, Yao-Min Chen [Page 8]
INTERNET-DRAFT RISP Expires Sept. 1997
a router; clear if it is a host.
One CIE is specified in the NHRP Callback Reply. The CIE contains
the responder's information. If CIE Code is 0 then it MUST send this
message along the shortcut path, otherwise this message MUST be sent
along the routed path.
Code
If this field is set to 0 then this packet contains a positively
acknowledged NHRP Callback Reply. If this field contains any
other value then this means NAK for the shortcut
establishment. CIE Codes are defined temporary as follows:
0 - The shortcut path is established successfully.
The NHRP Callback Request is accepted by its responder, and the
shortcut path is established successfully.
32 - Not enough resource is available to establish the cut
through path.
The responder receives the NHRP Callback Request correctly, but
it does not have enough resources to establish the shortcut path
requested.
33 - The shortcut path establishment fails because of the
sublayer.
The responder receives the NHRP Callback Request correctly, but
it fails to establish the shortcut path after using the NBMA
signaling such as UNI*.
34 - Establishment the shortcut path is prohibited by the
administrator.
An administrator of the responder prohibits the shortcut path to
the responder.
Prefix Length and Maximum Transmission Unit fields are used as
described in Section 5.2.0.1 of [2].
All other fields in the CIE, such as Holding Time, Cli Addr T/L, Cli
SAddr T/L, Cli Proto Len, Preference, Client NBMA Address, Client
NBMA Subaddress, Client Protocol Address SHOULD be set to 0, because
Jun Ogawa, Yao-Min Chen [Page 9]
INTERNET-DRAFT RISP Expires Sept. 1997
the NHRP Callback Reply is not used for the address resolution.
4.3 NHRP Release Request
The message is used by a host to ask its peer to disconnect the
shortcut path between them, if the two hosts are located at
different LISs.
When a requester or responder wants to release a shortcut path, it
sends this message to its peer along the shortcut path. When the
peer receives the message and is ready to release the path, it uses
NBMA signaling to disconnect the path.
This message facilitates a host to detect whether a path termination
is legal. Note that NHRP does not define any message for a host to
notify its peer about path termination. This makes it difficult to
distinguish whether the path is terminated by a peer or due to some
intermediate switching entity failure. Hence, the NHRP Release
Request message can be a useful addition to NHRP.
Note that it is possible to release a shortcut path without using
NHRP Release Request.
If this message is not received through a shortcut path across
multiple LISs, it must be discarded. Also a host can only send an
NHRP Release Request message along a path where it has received or
sent an NHRP Callback Reply, so that the NHRP Release Request
Message is not sent along a path established by Classical IP over
ATM.
Flags - The flags field is coded as follows,
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
No CIE is specified in the NHRP Release Request.
5. Migration to the "full-set" NHRP
We consider the "full-set" NHRP as the current NHRP proposal [2] plus
the functions defined in RISP. Adding the functions to NHRP has
following advantages.
First, a receiver can refuse a shortcut path request. For example,
an NHC may have a filter to determine which sender addresses are
allowed shortcut paths, or it may decide to accept or deny a shortcut
path request according to its load and resource level. This kind of
Jun Ogawa, Yao-Min Chen [Page 10]
INTERNET-DRAFT RISP Expires Sept. 1997
dynamic decision is difficult if done by an NHS.
Second, some networks may allow services charged on receivers. In
this case, it is desirable to let the receivers control the shortcut
path establishment.
When migrating to the full-set NHRP, an NHS must route/forward the
NHRP Callback Request/Reply messages to its destination unless the
NHS happens to be the egress router for the destination.
If an NHS receives an NHRP Callback Request destined for a host in
its LIS and does not have a cache for the host address, it MUST send
NHRP Error Indication packet with the Error Code 6(Protocol Address
Unreachable) to stop the requester from re-sending the NHRP Callback
Request.
6. Security Considerations
Security Considerations are not discussed in this memo.
7. Intellectual Property Considerations.
Fujitsu Laboratories Limited may seek patent or other intellectual
property protection for some or all of the technologies described in
this document.
Appendix-A Complexity of the NHRP Servers.
A-1: Necessity of the SCSP.
When a LIS has more than one router(e.g.NHS), all the routers
belonging to the LIS use SCSP to synchronize their cached
information.
<------- LIS ------->
+-------+ +-------+
| NHS1 |------+-------+------| NHS2 |
+-------+ | | +-------+
\ /
\ /
+-------+
| NHC1 |
| |
+-------+
(1) <------ NHRP Registration Request
Jun Ogawa, Yao-Min Chen [Page 11]
INTERNET-DRAFT RISP Expires Sept. 1997
(2) ------> NHRP Registration Reply
(3) <=====================>
Registration synchronization by SCSP
Fig.A-1: NHRP requires SCSP for cache synchronization
In the case of Fig.A-1, both NHS1 and NHS2 must be able to resolve
the ATM address of NHC1, but NHC1 only registers with NHS1. So NHS1
tells NHS2 about NHC1's IP/ATM address using SCSP.
A-2: Necessity of Memorizing NHRP Resolution Requests
NHRP allows that a transit NHS receiving an NHRP Resolution Reply
(e.g., NHS1 of Fig. A-2) caches its entries (the resolved IP/ATM
address in NHRP Resolution Reply). The destination of an NHRP
Resolution Reply (e.g., NHC1 of Fig. A-2) is allowed to cache too.
Consider the example in Fig. A-2. In order to purge the cached
Resolution Reply at NHS1 and NHC1 in Step (6), NHS2 has to remember
having forwarded NHRP Resolution Request in Step (1).
+-------+ +-------+ +-------+ +-------+
| NHC1 |-------| NHS1 |------| NHS2 |------| NHC2 |
| (src) | +-------+ +-------+ | (dst) |
+-------+ +-------+
(1) ------->-------------> NHRP Resolution Request
NHRP Resolution Request has cached at NHS2.
(2) <----------------<----- NHRP Resolution Reply
The content of NHRP Resolution Reply is cached at NHS1 and NHC1.
:
(3) -------> NHRP Resolution Request
(4) <------- NHRP Resolution Reply
:
(5) <----- NHRP Purge Request
(6) <-------<------------- NHRP Purge Request
Fig.A-2: NHRP Purge requires stations to memorize
earlier NHRP Resolution Requests
Appendix B The Authentication Mechanism for RISP
In the case of the NHRP, an NHC resolves the ATM address of a
destination using an NHRP Resolution Request message. Later, this
requester can establish the shortcut path to the same destination
Jun Ogawa, Yao-Min Chen [Page 12]
INTERNET-DRAFT RISP Expires Sept. 1997
without another NHRP Resolution Request because it already knows the
ATM address of the destination. Therefore, the intermediate routers
cannot authenticate each shortcut path.
If RISP stands alone as the inter-LIS shortcut protocol,
authentication of each short-cut path is straightforward.
A source may know the ATM address of a destination through a
previous shortcut path establishment. However, later if the source
sets up a shortcut path to the same destination (e.g., Step (6) in
Fig. B-1), it does not have a Request ID from the destination and so
it cannot send a proper NHRP Callback Reply along the path to the
destination and so the destination will disconnect the path (e.g.,
Steps (7) and (8) in Fig. B-1).
+-------+ +-------+ +-------+ +-------+
| src |-------|Router |------|Router |------| dst |
| | +-------+ +-------+ | |
+-------+ +-------+
(1) ------->------------->--------------> NHRP Callback Request
(hop by hop)
(2) <==================================== establish a shortcut
path
(3) <------------------------------------ NHRP Callback Reply
:
(4) <------------------------------------ NHRP Release Request
(5) The shortcut path terminates
:
:
(6) ====================================> establish a shortcut
path
(7) Can not send an NHRP Callback Reply
(8) The shortcut path terminates by dst
Fig.B-1 A shortcut path without an NHRP Callback Request cannot be
authenticated.
The following authentication rules are only optional and its
adoption is a local decision matter; RISP can work without
implementing these rules. However, if RISP is integrated with NHRP,
these rules MUST NOT be adopted (see Chapter 5 for discussion about
the migration to the full set NHRP).
(1) A host that has a path without a corresponding NHRP Callback
Jun Ogawa, Yao-Min Chen [Page 13]
INTERNET-DRAFT RISP Expires Sept. 1997
Reply needs to check first whether the path is established by
Classical IP over ATM (i.e., whether the other end of the path
is within the same LIS). If it is, the host MUST accept IP
packets from the path, for backward compatibility with Classical
IP over ATM (because if the path is established by the Classical
IP over ATM for intra-LIS communication, no NHRP Callback Reply
is sent along the path).
To verify whether the path is established via Classical IP over ATM,
the host sends an InATMARP Request to the ATMARP server to acquire
the IP address of the remote host. For this to work, ATMARP server
MUST accept the InATMARP Request and reply it using information
cached (although current RFC1577 does not require this on ATMARP
servers).
If the address resolved is in the same LIS as the host, it knows
that the path is established by Classical IP over ATM and so accepts
IP packets sent along the path. Otherwise, we recommend that the
host terminate the path quietly.
(2) For hosts belonging to different LISs, the normal Request ID
authentication process MUST be followed. In other words, if a
requester has a shortcut path along which it never receives an
NHRP Callback Reply with the proper Request ID but receives some
other IP packets, the requester MUST terminate the path.
The details of this authentication mechanism is for further
study. For example, in the case of (1), the handling of the packets
that are received while the host communicates with its ATMARP server
is yet to be determined. Also, RISP requires an NHRP Callback
Request for each path establishment, while under NHRP, a host does
not need to send an NHRP Resolution Request if it already has the
destination NBMA address in its cache. Therefore, considering the
number of request packets that are passed through the routers, the
number of NHRP Callback Requests, under RISP, may be significantly
larger than the number of NHRP Resolution Requests under NHRP. We
are investigating whether this increase in packet count will be a
disadvantage of the RISP authentication mechanism.
References
[1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
[2] NBMA Next Hops Resolution Protocol (NHRP), James V. Luciani,
draft-ietf-rolc-nhrp-11.txt
[3] Classical IP to NHRP Transition, James V. Luciani,
raft-ietf-ion-transition-00.txt
[4] Server Cache Synchronization Protocol (SCSP), James V. Luciani,
Jun Ogawa, Yao-Min Chen [Page 14]
INTERNET-DRAFT RISP Expires Sept. 1997
Grenville Armitage, and Joel Halpern, draft-ietf-ion-scsp-00.txt.
Acknowledgments
We would like to thank David Richard and Steven A. Wright of
Fujitsu Network Communications Inc. and Walter Sotelo of Hal Computer
for insightful suggestions and comments.
Authors' Addresses
Jun Ogawa
Fujitsu Laboratories LTD.
4-1-1 Kamikodanaka Nakahara-ku Kawasaki 211-88
Japan
Phone: +81-44-754-2629
E-mail: ogawa@flab.fujitsu.co.jp
Yao-Min Chen
Fujitsu Laboratories of America, INC.
3350 Scott Blvd.,Bldg.#34, Santa Clara, CA 95054-3104
USA
Phone: +1-408-567-4513
E-mail: ychen@fla.fujitsu.com