[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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