home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-ogawa-receiver-shortcut-path-00.txt < prev    next >
Text File  |  1997-03-26  |  34KB  |  852 lines
  1. Internet Draft                                         Jun Ogawa
  2. Expires September 1997                (Fujitsu Laboratories LTD.)
  3.                                                     Yao-Min Chen
  4.                            (Fujitsu Laboratories of America INC.)
  5.  
  6.                                                       March 1997
  7.  
  8.  
  9.        The Receiver-Initiated Shortcut Path Protocol (RISP) 
  10.            <draft-ogawa-receiver-shortcut-path-00.txt>
  11.  
  12.  
  13. Status of This Memo.
  14.  
  15.      This document is an Internet-Draft.  Internet-Drafts are working
  16.      documents of the Internet Engineering Task Force (IETF), its
  17.      areas, and its working groups.  Note that other groups may also
  18.      distribute working documents as Internet-Drafts.
  19.  
  20.      Internet-Drafts are draft documents valid for a maximum of six
  21.      months and may be updated, replaced, or obsoleted by other
  22.      documents at any time.  It is inappropriate to use Internet-
  23.      Drafts as reference material or to cite them other than as
  24.      ``work in progress.''
  25.  
  26.      To learn the current status of any Internet-Draft, please check
  27.      the ``1id-abstracts.txt'' listing contained in the Internet-
  28.      Drafts Shadow Directories on ftp.is.co.za (Africa),
  29.      nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  30.      ds.internic.net (US East Coast), or ftp.isi.edu (WE West Coast).
  31.  
  32.  
  33. Abstract
  34.  
  35.      This memo defines the Receiver Initiated Shortcut Path (RISP)
  36.      protocol for NBMA networks.  The protocol extends the NHRP message
  37.      set by adding Callback Request and Reply messages to allow the
  38.      destination host (or its corresponding egress router) to establish
  39.      a shortcut path for a data flow, using the existing NBMA signaling
  40.      protocols.  Because of this receiver-initiated mechanism, a
  41.      shortcut-capable network can use just the NBMA ARP servers, such as
  42.      the ATMARP servers, instead of the more complex Next Hop
  43.      Servers. This draft also describes how to extend NHRP with the new,
  44.      receiver-initiated mechanism.
  45.  
  46.  
  47. 1. Introduction
  48.  
  49.      A main goal of the IP over NBMA Networks (ion) working group is to
  50.      define efficient address resolution mechanisms for establishing
  51.      NBMA paths suitable for IP flows. Towards this goal, Classical IP
  52.      over ATM [1] and Next-Hop Address Resolution Protocol (NHRP) [2]
  53.  
  54.  
  55. Jun Ogawa, Yao-Min Chen                                       [Page 1]
  56.  
  57. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  58.  
  59.  
  60.      are outputs from the working group that have received significant
  61.      attention.  The strength of Classical IP over ATM is its simplicity
  62.      but it cannot establish shortcut paths across multiple logical IP
  63.      subnetworks.  NHRP establishes the shortcuts but the complexity of
  64.      Next Hop Servers may prevent its rapid adoption.  In this memo, we
  65.      describe a way to establish shortcut paths without the complexity
  66.      of Next Hop Servers.
  67.  
  68.      RFC 1577 [1] defined the concept of Logical IP Subnetwork (LIS)
  69.      which is a separate administrative entity where hosts and routers
  70.      are configured within a closed IP subnetwork.  In this memo, we
  71.      describe a protocol to establish shortcut paths without the
  72.      complexity of Next Hop Servers.
  73.  
  74.      The protocol is called Receiver-Initiated Shortcut Path (RISP). It
  75.      works on an environment where an NBMA subnet is divided into
  76.      multiple Logical IP Subnetworks (LISs, see reference [1]).  This is
  77.      the same environment considered by both Classical IP over ATM and
  78.      NHRP. 
  79.  
  80.      Below, we briefly review Classical IP over ATM and NHRP and then
  81.      introduce RISP as a simple method to establish inter-LIS shortcut
  82.      paths.
  83.  
  84.  
  85. 1.1 Classical IP over ATM
  86.  
  87.     First of all, a client must register its IP address and ATM address
  88.     with an ATMARP Server using Inverse ATM Address Resolution Protocol
  89.     (InATMARP). A client connects to the ATMARP server using a
  90.     point-to-point VC.
  91.  
  92.     In the case of Intra-LIS path establishment, a sender client
  93.     resolves the receiver's ATM address using the ATMARP server. Then
  94.     the sender client establishes a path and sends IP packets along it.
  95.  
  96.     In the case of Inter-LIS, a sender client sends IP packets to a
  97.     router. The router transmits these packets to the receiver using the
  98.     ordinary routing table constructed by a routing protocol such as RIP
  99.     or OSPF.
  100.  
  101.     Therefore, intermediate routers become bottleneck for the speedy
  102.     transmission of data packets.
  103.  
  104.  
  105. 1.2 Next Hop Resolution Protocol 
  106.  
  107.     First of all, a client host must register its Protocol and NBMA
  108.     addresses with an Next Hop Server (NHS) using an NHRP Registration
  109.     Request message.  For example, if the internetwork-layer protocol is
  110.     IP and the underlying subnet-layer NBMA network is ATM, the client
  111.     registers its IP and ATM addresses with the NHS.
  112.  
  113.  
  114. Jun Ogawa, Yao-Min Chen                                       [Page 2]
  115.  
  116. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  117.  
  118.  
  119.  
  120.     In both intra- and inter-LIS communications, a sender client sends
  121.     an NHRP Resolution Request to the nearest NHS to resolve the
  122.     destination NBMA address.  If the NHS cannot resolve it, it forwards
  123.     the request to the destination using the ordinary routing table
  124.     because the NHS is also equipped with router function.  Eventually,
  125.     the NHS (router) nearest to the destination resolves the NBMA
  126.     address.
  127.  
  128.     Once the destination NBMA address is resolved, the sender
  129.     establishes a shortcut path to the receiver.  Therefore, inter-LIS
  130.     communication under NHRP does not suffer the router bottleneck
  131.     problem in Classical IP over ATM.
  132.  
  133.     NHRP also allows an intermediate NHS to cache the NBMA address of a
  134.     destination so that later the NHS can directly resolve a request
  135.     instead of forwarding it.
  136.  
  137.     In addition, note that NHRP offers not only shortcut path
  138.     establishment but also a rich set of functions beyond what is
  139.     provided by Classical IP over ATM.  Here we briefly mention a few.
  140.  
  141.     1) An NHS can resolve the NBMA address for an equivalent class of
  142.        internetwork layer addresses using the prefix length field in an
  143.        NHRP message (See Section 5.2.0.1 of [2] for more details).  This
  144.        is useful when several Protocol addresses share an NBMA address.
  145.  
  146.     2) An NHS can resolve an NBMA address from a Protocol address using
  147.        the U bit (which indicates that the NBMA address is unique to the 
  148.        Protocol address).
  149.  
  150.     3) To invalidate the cached information at a station(e.g. NHC or
  151.        NHS), NHRP Purge Request is defined. This message facilitates the 
  152.        coherency of the information cached at multiple stations.
  153.  
  154.     However, the rich set of functions comes at the price of complexity
  155.     at NHSs, which we summarize below and discuss in more depth in
  156.     Appendix-A.
  157.  
  158.     a) Along with the conventional router function, an NHS must maintain
  159.        a database for address resolution.  In addition, all routers in
  160.        the NBMA network must be equipped with this function when using
  161.        NHRP in the network.
  162.  
  163.     b) When a LIS has multiple routers (NHSs), they need a mechanism to
  164.        synchronize the cached information.  SCSP [4] is such a mechanism 
  165.        being drafted by the ion working group.
  166.  
  167.     c) NHRP allows a transit NHS to cache the entries contained in the
  168.        received NHRP Resolution Replys (i.e., the resolved Protocol/NBMA
  169.        address mappings in the messages). Subsequently the NHS can
  170.        resolve an NHRP Resolution Request using the cached entries.
  171.  
  172.  
  173. Jun Ogawa, Yao-Min Chen                                       [Page 3]
  174.  
  175. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  176.  
  177.  
  178.        However, the NHS also needs to keep track of the source address
  179.        of the request (see Appendix-A.2 for a more thorough discussion
  180.        on this aspect).
  181.  
  182.     In summary, the main reason for the complexity of NHS is that NHRP
  183.     requires that the routers also perform address resolution for both
  184.     intra- and inter-LIS communications. Consider a network that is
  185.     based on Classical IP over ATM.  When it migrates to NHRP,
  186.     complexity incurred on all routers due to additional requirements in
  187.     a)- c).  In some cases a network operator may not want the
  188.     complexity in spite of the benefits provided by NHRP.  For example,
  189.     the operator may be satisfied with just the provision of "inter-LIS
  190.     shortcut paths" but rather uses Classical IP over ATM for intra-LIS
  191.     paths.  For this kind of networks, this document describes a simple
  192.     way to establish shortcut paths without the need of inter-LIS
  193.     address resolution.
  194.  
  195.  
  196. 1.3 Receiver-Initiated Shortcut Path Protocol 
  197.  
  198.     The protocol adopts Classical IP over ATM for intra-LIS
  199.     communication and defines a receiver-initiated setup mechanism for
  200.     inter-LIS shortcut paths.  Such a shortcut path is set up by the
  201.     following four phases.  In the Request phase, a sender sends a
  202.     request along a routed (i.e., hop-by-hop) path.  In the Respond
  203.     phase, a responder, which can be either a destination host or an
  204.     egress router, sets up a shortcut path back to the sender, and then
  205.     sends a responding packet along the path.  In the Transmit phase,
  206.     data are transmitted between the sender and receiver through the
  207.     shortcut path.  In the Close phase, either the sender or the
  208.     responder sends a release packet to its peer, which then tears down
  209.     the path.  A complete specification of the protocol will be given in
  210.     Section 3, after we introduce terminology in Section 2.
  211.         
  212.     The protocol can stand alone (without NHRP) as an inter-LIS shortcut
  213.     protocol, or its functionality can be integrated into NHRP.  It can
  214.     also be used as a transit step for the migration of ATMARP-based
  215.     networks to NHRP networks, because it offers inter-LIS shortcut
  216.     paths with just ATMARP servers.  If later a network requires the
  217.     richer set of functions provided by NHRP, it can migrate to NHRP.
  218.     For this reason, we choose a packet format closely tied to the NHRP
  219.     packet format. The packet format is described in Section 4, and the
  220.     migration is discussed in Section 5.
  221.  
  222.  
  223. 2. Terminology
  224.  
  225.    A "RISP host" refers to a host machine that can process RISP
  226.    messages.  Where there is no ambiguity, we will refer to a RISP host
  227.    simply as a "host".
  228.  
  229.    A "RISP router" is a router performing conventional
  230.  
  231.  
  232. Jun Ogawa, Yao-Min Chen                                       [Page 4]
  233.  
  234. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  235.  
  236.  
  237.    forwarding/routing functions as well as being capable of handling
  238.    RISP messages including Callback Request, Callback Reply and Error
  239.    Indication.  The routers described in this memo, unless otherwise
  240.    mentioned, refer to RISP routers.
  241.  
  242.  
  243. 3. Protocol Overview
  244.  
  245.    Currently, we only consider an IP-over-ATM environment.  However, it
  246.    is possible to generalize the draft for other NBMA networks.  This is
  247.    currently under study.
  248.  
  249.    The protocol does NOT use any servers for establishing a path across
  250.    multiple LISs, but only uses ATMARP servers for intra-LIS address
  251.    resolution. So,
  252.  
  253.    1) for inter-LIS communication, a host does not need to know the NBMA
  254.       address of its destination before initialing communication,
  255.    2) a router does not need to maintain a database for the purpose of
  256.       address resolution, and
  257.    3) a destination host can refuse a shortcut path request.
  258.  
  259.    Below, we specify the protocol by specifying how inter- and intra-LIS
  260.    communications are conducted.  As we mentioned earlier, the messages
  261.    used by the protocol will follow the NHRP basic packet format.
  262.    Therefore, we add "NHRP" in front of these messages to indicate this
  263.    fact.
  264.  
  265.  
  266. 3.1 Inter-LIS Communication
  267.  
  268.     By default, a source host sends IP packets to the destination
  269.     through routers (hop by hop).  We call a path taken this way a
  270.     "routed" path.
  271.  
  272.     If the host decides that a shortcut path is more suitable for a flow
  273.     than the routed path, it sends an NHRP Callback Request message to
  274.     the destination along the routed path. We refer to this host as the
  275.     requester for the NHRP Callback Request.
  276.         
  277.     An NHRP Callback Request message has the IP and ATM addresses of its
  278.     requester.  It also has a Request ID to uniquely identify the
  279.     message.
  280.  
  281.     When the destination or its egress router (if the destination is not
  282.     on the NBMA subnet) receives the NHRP Callback Request, it starts
  283.     establishing a shortcut path back to the requester, using the NBMA
  284.     signaling such as UNI*.  This signaling is possible because the ATM
  285.     address of the requester is contained in the NHRP Callback
  286.     Request. We call the destination host or egress router the responder
  287.     for the Callback Request.
  288.  
  289.  
  290.  
  291. Jun Ogawa, Yao-Min Chen                                       [Page 5]
  292.  
  293. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  294.  
  295.  
  296.     If the NHRP Callback Request packet contains an error then the
  297.     responder sends the NHRP Error Indication with appropriate Error
  298.     Code as described in [2].
  299.  
  300.     As soon as the shortcut path is established, the responder sends an
  301.     NHRP Callback Reply along the path to the requester.
  302.  
  303.     The NHRP Callback Reply message contains the IP and ATM addresses of
  304.     the responder.  It also has a Request ID which is identical to the
  305.     Request ID of the NHRP Callback Request.
  306.  
  307.     Upon receiving an NHRP Callback Reply, the requester verifies if the
  308.     Request ID in the message is the same as in the NHRP Callback
  309.     Request it issued. If they are the same, the shortcut path
  310.     establishment has completed. Otherwise, the shortcut path must be
  311.     terminated by the requester.
  312.  
  313.     After the establishment, the requester re-directs its data packets
  314.     from the routed path to the shortcut path.
  315.  
  316.     On the other hand, if the path establishment fails, the responder
  317.     sends an NHRP Callback Reply along the routed path.  Such a failure
  318.     may occur because of lack of resources at the responder or some
  319.     layer-2 problem.  In Section 4.2, we have a more thorough
  320.     discussion.
  321.  
  322.     To terminate a shortcut path, either the requester or the responder
  323.     sends an NHRP Release Request message to its peer. When the peer
  324.     receives the message, it disconnects the shortcut path.
  325.  
  326.     If the requester sends an NHRP Callback Request but does not receive
  327.     any NHRP Callback Reply or Error Indication messages with the
  328.     Request ID, it sends an NHRP Callback Request again with the same
  329.     Request ID. The interval between the NHRP Callback Requests and the
  330.     number of times for the re-transmission are for further study.
  331.  
  332.     If the path establishment fails, the requester continues to send IP
  333.     packets through the routed path.
  334.  
  335.  
  336.   +-------+       +-------+      +-------+      +-------+
  337.   | src   |-------|Router |------|Router |------| dst   |
  338.   |       |       +-------+      +-------+      |       |
  339.   +-------+                                     +-------+
  340.     (1)    ------->------------->--------------> NHRP Callback Request
  341.                                                     (hop by hop)
  342.  
  343.     (2)   <==================================== establish a shortcut
  344.                                                 path
  345.  
  346.     (3)   <------------------------------------  NHRP Callback Reply
  347.                            :
  348.  
  349.  
  350. Jun Ogawa, Yao-Min Chen                                       [Page 6]
  351.  
  352. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  353.  
  354.  
  355.     (4)   <------------------------------------  NHRP Release Request
  356.  
  357.     (5)         The shortcut path terminates
  358.  
  359.               Fig.1 Typical usage of RISP.
  360.  
  361.  
  362. 3.2 Intra-LIS
  363.  
  364.     In the case of Intra-LIS address resolution, the protocol uses
  365.     Classical IP over ATM. Therefore, when a host wants to join a LIS,
  366.     it registers its IP and ATM addresses with an ATMARP server.
  367.  
  368.  
  369. 3.3 Authentication
  370.  
  371.     The protocol also provides an authentication mechanism, which is
  372.     described in Appendix-B. The protocol has the option to work without
  373.     the mechanism.
  374.  
  375.  
  376. 3.4 Summary
  377.  
  378.     The simplicity of the protocol lies in the fact that it does not
  379.     require address resolution function to establish an inter-LIS
  380.     shortcut path, because such a path is established by the receiver
  381.     using NBMA signaling.
  382.  
  383.  
  384. 4. Messages
  385.  
  386.     The protocol requires that the NHRP to extend its message set and
  387.     assign packet type values(ar$op.type) to the new messages NHRP
  388.     Callback Request, NHRP Callback Reply, and NHRP Callback Release.
  389.     If a network merely uses the RISP functions, it only needs to
  390.     support these messages along with NHRP Error Indication.
  391.  
  392.  
  393. 4.1 NHRP Callback Request
  394.  
  395.     This message is used by a sender host to request a shortcut path.
  396.     Unlike the NHRP Resolution Request, the nearest router or NHS of the
  397.     destination simply forwards this message to the destination host. If
  398.     the destination is outside of the NBMA subnet, then the egress
  399.     router MUST become the responder to answer this request and it MUST
  400.     not forward this request to the next NBMA subnet.
  401.  
  402.     NHRP Callback Request's mandatory part is coded as described in
  403.     Section 5.2.0.1 of [2].
  404.  
  405.     The message specific meanings of the fields are as follows,
  406.  
  407.  
  408.  
  409. Jun Ogawa, Yao-Min Chen                                       [Page 7]
  410.  
  411. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  412.  
  413.  
  414.     Flags - The flags field is coded as follows,
  415.  
  416.        0                   1
  417.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  418.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  419.       |Q|           unused            |
  420.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  421.  
  422.       Q
  423.         Set if the station sending the NHRP Resolution Request is a
  424.         router;  clear if it is a host.
  425.  
  426.     Zero or one CIE may be specified in an NHRP Callback Request. If a
  427.     CIE is specified then that entry carries the pertinent information
  428.     for the client sourcing the NHRP Callback Request. The usage of the
  429.     CIE is described below:
  430.  
  431.       Maximum Transmission Unit
  432.         This field gives the maximum transmission unit for the source
  433.         station.  A possible use of this field in the NHRP Callback
  434.         Request packet is for the requester to ask for a target MTU. In
  435.         lieu of that usage, the CIE must be omitted.
  436.  
  437.     All other fields in the CIE MUST be ignored and SHOULD be set to 0.
  438.  
  439.     All the Extension Parts of the NHRP can be used, but some of it may
  440.     be meaningless to the NHRP Callback Request (e.g., the NHRP Reverse
  441.     Transit NHS Record Extension).
  442.  
  443.  
  444. 4.2 NHRP Callback Reply
  445.  
  446.     This message is used by a responder to reply to an NHRP Callback
  447.     Request. The message is sent along the shortcut path established for
  448.     the NHRP Callback Request if the path establishment is successful,
  449.     otherwise it is sent along the routed path.
  450.  
  451.     NHRP Callback Reply's mandatory part is coded as described in
  452.     Section 5.2.0.1 of [2].
  453.  
  454.     The message specific meanings of the fields are as follows,
  455.  
  456.     Flags - The flags field is coded as follows,
  457.  
  458.        0                   1
  459.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  460.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  461.       |Q|           unused            |
  462.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  463.  
  464.       Q
  465.         Copied from the NHRP Callback Request.  Set if the requester is
  466.  
  467.  
  468. Jun Ogawa, Yao-Min Chen                                       [Page 8]
  469.  
  470. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  471.  
  472.  
  473.         a router; clear if it is a host.
  474.  
  475.  
  476.  
  477.     One CIE is specified in the NHRP Callback Reply. The CIE contains
  478.     the responder's information. If CIE Code is 0 then it MUST send this
  479.     message along the shortcut path, otherwise this message MUST be sent
  480.     along the routed path.
  481.  
  482.  
  483.       Code
  484.         If this field is set to 0 then this packet contains a positively
  485.         acknowledged NHRP Callback Reply.  If this field contains any
  486.         other value then this means NAK for the shortcut
  487.         establishment. CIE Codes are defined temporary as follows:
  488.  
  489.         0 - The shortcut path is established successfully.
  490.  
  491.         The NHRP Callback Request is accepted by its responder, and the
  492.         shortcut path is established successfully.
  493.  
  494.  
  495.         32 - Not enough resource is available to establish the cut
  496.         through path.
  497.  
  498.         The responder receives the NHRP Callback Request correctly, but
  499.         it does not have enough resources to establish the shortcut path
  500.         requested.
  501.  
  502.  
  503.         33 - The shortcut path establishment fails because of the
  504.         sublayer.
  505.  
  506.         The responder receives the NHRP Callback Request correctly, but
  507.         it fails to establish the shortcut path after using the NBMA
  508.         signaling such as UNI*.
  509.  
  510.  
  511.         34 - Establishment the shortcut path is prohibited by the
  512.         administrator.
  513.   
  514.         An administrator of the responder prohibits the shortcut path to
  515.         the responder.
  516.  
  517.  
  518.     Prefix Length and Maximum Transmission Unit fields are used as
  519.     described in Section 5.2.0.1 of [2].
  520.  
  521.  
  522.     All other fields in the CIE, such as Holding Time, Cli Addr T/L, Cli
  523.     SAddr T/L, Cli Proto Len, Preference, Client NBMA Address, Client
  524.     NBMA Subaddress, Client Protocol Address SHOULD be set to 0, because
  525.  
  526.  
  527. Jun Ogawa, Yao-Min Chen                                       [Page 9]
  528.  
  529. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  530.  
  531.  
  532.     the NHRP Callback Reply is not used for the address resolution.
  533.  
  534.  
  535. 4.3 NHRP Release Request
  536.  
  537.     The message is used by a host to ask its peer to disconnect the
  538.     shortcut path between them, if the two hosts are located at
  539.     different LISs.
  540.  
  541.     When a requester or responder wants to release a shortcut path, it
  542.     sends this message to its peer along the shortcut path.  When the
  543.     peer receives the message and is ready to release the path, it uses
  544.     NBMA signaling to disconnect the path.
  545.  
  546.     This message facilitates a host to detect whether a path termination
  547.     is legal.  Note that NHRP does not define any message for a host to
  548.     notify its peer about path termination.  This makes it difficult to
  549.     distinguish whether the path is terminated by a peer or due to some
  550.     intermediate switching entity failure.  Hence, the NHRP Release
  551.     Request message can be a useful addition to NHRP.
  552.  
  553.     Note that it is possible to release a shortcut path without using
  554.     NHRP Release Request.
  555.  
  556.     If this message is not received through a shortcut path across
  557.     multiple LISs, it must be discarded. Also a host can only send an
  558.     NHRP Release Request message along a path where it has received or
  559.     sent an NHRP Callback Reply, so that the NHRP Release Request
  560.     Message is not sent along a path established by Classical IP over
  561.     ATM.
  562.  
  563.     Flags - The flags field is coded as follows,
  564.  
  565.        0                   1
  566.        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  567.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  568.       |           unused              |
  569.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  570.  
  571.     No CIE is specified in the NHRP Release Request.
  572.  
  573.  
  574. 5. Migration to the "full-set" NHRP
  575.  
  576.    We consider the "full-set" NHRP as the current NHRP proposal [2] plus
  577.    the functions defined in RISP.  Adding the functions to NHRP has
  578.    following advantages.
  579.  
  580.    First, a receiver can refuse a shortcut path request.  For example,
  581.    an NHC may have a filter to determine which sender addresses are
  582.    allowed shortcut paths, or it may decide to accept or deny a shortcut
  583.    path request according to its load and resource level.  This kind of
  584.  
  585.  
  586. Jun Ogawa, Yao-Min Chen                                       [Page 10]
  587.  
  588. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  589.  
  590.  
  591.    dynamic decision is difficult if done by an NHS.
  592.  
  593.    Second, some networks may allow services charged on receivers.  In
  594.    this case, it is desirable to let the receivers control the shortcut
  595.    path establishment.
  596.  
  597.    When migrating to the full-set NHRP, an NHS must route/forward the
  598.    NHRP Callback Request/Reply messages to its destination unless the
  599.    NHS happens to be the egress router for the destination.
  600.  
  601.    If an NHS receives an NHRP Callback Request destined for a host in
  602.    its LIS and does not have a cache for the host address, it MUST send
  603.    NHRP Error Indication packet with the Error Code 6(Protocol Address
  604.    Unreachable) to stop the requester from re-sending the NHRP Callback
  605.    Request.
  606.  
  607.  
  608. 6. Security Considerations
  609.  
  610.    Security Considerations are not discussed in this memo.
  611.  
  612.  
  613. 7. Intellectual Property Considerations.
  614.  
  615.    Fujitsu Laboratories Limited may seek patent or other intellectual
  616.    property protection for some or all of the technologies described in
  617.    this document.
  618.  
  619.  
  620. Appendix-A Complexity of the NHRP Servers.
  621.  
  622.  A-1: Necessity of the SCSP.
  623.  
  624.     When a LIS has more than one router(e.g.NHS), all the routers
  625.     belonging to the LIS use SCSP to synchronize their cached
  626.     information.
  627.  
  628.   
  629.             <------- LIS ------->
  630.  
  631.    +-------+                     +-------+
  632.    |  NHS1 |------+-------+------|  NHS2 |
  633.    +-------+      |       |      +-------+
  634.                    \     /
  635.                     \   /
  636.                   +-------+
  637.                   | NHC1  |
  638.                   |       |
  639.                   +-------+
  640.  
  641.      (1)   <------ NHRP Registration Request
  642.  
  643.  
  644.  
  645. Jun Ogawa, Yao-Min Chen                                       [Page 11]
  646.  
  647. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  648.  
  649.  
  650.      (2)    ------> NHRP Registration Reply
  651.  
  652.      (3)   <=====================>
  653.         Registration synchronization by SCSP
  654.  
  655.            Fig.A-1: NHRP requires SCSP for cache synchronization
  656.  
  657.     In the case of Fig.A-1, both NHS1 and NHS2 must be able to resolve
  658.     the ATM address of NHC1, but NHC1 only registers with NHS1. So NHS1
  659.     tells NHS2 about NHC1's IP/ATM address using SCSP.
  660.  
  661.  
  662.  A-2: Necessity of Memorizing NHRP Resolution Requests
  663.  
  664.     NHRP allows that a transit NHS receiving an NHRP Resolution Reply
  665.     (e.g., NHS1 of Fig. A-2) caches its entries (the resolved IP/ATM
  666.     address in NHRP Resolution Reply). The destination of an NHRP
  667.     Resolution Reply (e.g., NHC1 of Fig. A-2) is allowed to cache too.
  668.  
  669.     Consider the example in Fig. A-2.  In order to purge the cached
  670.     Resolution Reply at NHS1 and NHC1 in Step (6), NHS2 has to remember
  671.     having forwarded NHRP Resolution Request in Step (1).
  672.  
  673.  
  674.    +-------+       +-------+      +-------+      +-------+
  675.    | NHC1  |-------| NHS1  |------| NHS2  |------| NHC2  |
  676.    | (src) |       +-------+      +-------+      | (dst) |
  677.    +-------+                                     +-------+
  678.  
  679.      (1)    ------->-------------> NHRP Resolution Request
  680.                       NHRP Resolution Request has cached at NHS2.
  681.  
  682.      (2)   <----------------<----- NHRP Resolution Reply
  683.      The content of NHRP Resolution Reply is cached at NHS1 and NHC1.
  684.                             :
  685.      (3)    -------> NHRP Resolution Request
  686.  
  687.      (4)   <-------  NHRP Resolution Reply
  688.                             :
  689.      (5)                                   <----- NHRP Purge Request
  690.  
  691.      (6)   <-------<------------- NHRP Purge Request
  692.  
  693.            Fig.A-2: NHRP Purge requires stations to memorize 
  694.                     earlier NHRP Resolution Requests
  695.  
  696.  
  697. Appendix B  The Authentication Mechanism for RISP
  698.  
  699.     In the case of the NHRP, an NHC resolves the ATM address of a
  700.     destination using an NHRP Resolution Request message.  Later, this
  701.     requester can establish the shortcut path to the same destination
  702.  
  703.  
  704. Jun Ogawa, Yao-Min Chen                                       [Page 12]
  705.  
  706. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  707.  
  708.  
  709.     without another NHRP Resolution Request because it already knows the
  710.     ATM address of the destination. Therefore, the intermediate routers
  711.     cannot authenticate each shortcut path.
  712.  
  713.     If RISP stands alone as the inter-LIS shortcut protocol,
  714.     authentication of each short-cut path is straightforward.
  715.  
  716.     A source may know the ATM address of a destination through a
  717.     previous shortcut path establishment.  However, later if the source
  718.     sets up a shortcut path to the same destination (e.g., Step (6) in
  719.     Fig. B-1), it does not have a Request ID from the destination and so
  720.     it cannot send a proper NHRP Callback Reply along the path to the
  721.     destination and so the destination will disconnect the path (e.g.,
  722.     Steps (7) and (8) in Fig. B-1).
  723.  
  724.  
  725.    +-------+       +-------+      +-------+      +-------+
  726.    | src   |-------|Router |------|Router |------| dst   |
  727.    |       |       +-------+      +-------+      |       |
  728.    +-------+                                     +-------+
  729.      (1)    ------->------------->--------------> NHRP Callback Request
  730.                                                      (hop by hop)
  731.  
  732.      (2)   <==================================== establish a shortcut
  733.                                                  path
  734.  
  735.      (3)   <------------------------------------  NHRP Callback Reply
  736.                             :
  737.      (4)   <------------------------------------  NHRP Release Request
  738.  
  739.      (5)         The shortcut path terminates
  740.                             :
  741.                             :
  742.      (6)    ====================================> establish a shortcut
  743.                                                   path
  744.  
  745.      (7)     Can not send an NHRP Callback Reply
  746.  
  747.      (8)     The shortcut path terminates by dst
  748.  
  749.  
  750.    Fig.B-1 A shortcut path without an NHRP Callback Request cannot be 
  751.            authenticated.
  752.  
  753.  
  754.     The following authentication rules are only optional and its
  755.     adoption is a local decision matter; RISP can work without
  756.     implementing these rules. However, if RISP is integrated with NHRP,
  757.     these rules MUST NOT be adopted (see Chapter 5 for discussion about
  758.     the migration to the full set NHRP).
  759.  
  760.     (1) A host that has a path without a corresponding NHRP Callback
  761.  
  762.  
  763. Jun Ogawa, Yao-Min Chen                                       [Page 13]
  764.  
  765. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  766.  
  767.  
  768.         Reply needs to check first whether the path is established by
  769.         Classical IP over ATM (i.e., whether the other end of the path
  770.         is within the same LIS). If it is, the host MUST accept IP
  771.         packets from the path, for backward compatibility with Classical
  772.         IP over ATM (because if the path is established by the Classical
  773.         IP over ATM for intra-LIS communication, no NHRP Callback Reply
  774.         is sent along the path).
  775.  
  776.     To verify whether the path is established via Classical IP over ATM,
  777.     the host sends an InATMARP Request to the ATMARP server to acquire
  778.     the IP address of the remote host.  For this to work, ATMARP server
  779.     MUST accept the InATMARP Request and reply it using information
  780.     cached (although current RFC1577 does not require this on ATMARP
  781.     servers).
  782.  
  783.     If the address resolved is in the same LIS as the host, it knows
  784.     that the path is established by Classical IP over ATM and so accepts
  785.     IP packets sent along the path.  Otherwise, we recommend that the
  786.     host terminate the path quietly.
  787.         
  788.     (2) For hosts belonging to different LISs, the normal Request ID
  789.         authentication process MUST be followed. In other words, if a
  790.         requester has a shortcut path along which it never receives an
  791.         NHRP Callback Reply with the proper Request ID but receives some
  792.         other IP packets, the requester MUST terminate the path.
  793.  
  794.  
  795.     The details of this authentication mechanism is for further
  796.     study. For example, in the case of (1), the handling of the packets
  797.     that are received while the host communicates with its ATMARP server
  798.     is yet to be determined.  Also, RISP requires an NHRP Callback
  799.     Request for each path establishment, while under NHRP, a host does
  800.     not need to send an NHRP Resolution Request if it already has the
  801.     destination NBMA address in its cache.  Therefore, considering the
  802.     number of request packets that are passed through the routers, the
  803.     number of NHRP Callback Requests, under RISP, may be significantly
  804.     larger than the number of NHRP Resolution Requests under NHRP. We
  805.     are investigating whether this increase in packet count will be a
  806.     disadvantage of the RISP authentication mechanism.
  807.  
  808.  
  809.  References
  810.  
  811.     [1] Classical IP and ARP over ATM, Mark Laubach, RFC 1577.
  812.  
  813.     [2] NBMA Next Hops Resolution Protocol (NHRP), James V. Luciani,
  814.         draft-ietf-rolc-nhrp-11.txt
  815.  
  816.     [3] Classical IP to NHRP Transition, James V. Luciani,
  817.         raft-ietf-ion-transition-00.txt
  818.  
  819.     [4] Server Cache Synchronization Protocol (SCSP), James V. Luciani,
  820.  
  821.  
  822. Jun Ogawa, Yao-Min Chen                                       [Page 14]
  823.  
  824. INTERNET-DRAFT                  RISP               Expires Sept. 1997
  825.  
  826.  
  827.         Grenville Armitage, and Joel Halpern, draft-ietf-ion-scsp-00.txt.
  828.  
  829.  
  830.  Acknowledgments
  831.  
  832.     We would like to thank David Richard and Steven A. Wright of 
  833.     Fujitsu Network Communications Inc. and Walter Sotelo of Hal Computer
  834.     for insightful suggestions and comments.
  835.  
  836.  
  837.  Authors' Addresses
  838.  
  839.     Jun Ogawa
  840.     Fujitsu Laboratories LTD.
  841.     4-1-1 Kamikodanaka Nakahara-ku Kawasaki 211-88
  842.     Japan
  843.     Phone: +81-44-754-2629
  844.     E-mail: ogawa@flab.fujitsu.co.jp
  845.  
  846.     Yao-Min Chen
  847.     Fujitsu Laboratories of America, INC.
  848.     3350 Scott Blvd.,Bldg.#34, Santa Clara, CA 95054-3104
  849.     USA
  850.     Phone: +1-408-567-4513
  851.     E-mail: ychen@fla.fujitsu.com
  852.