rfc2103.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   that establishes a signalling channel for communication with the MH.

   If the MH is itself a node then N and the MH execute an arc formation
   procedure between themselves as described in [RS96].  This results in
   a locator being assigned to the MH and to the arcs between N and MH.

   If the MH is not a node but only an endpoint, then MH initiates
   locator acquisition procedure as described in [RS96].  This results
   in a locator being assigned to the MH.

   The MH then sends a Foreign Agent Request message to N. This message
   contains, amongst other information, the EID and locator of the MH.
   If N is not itself the foreign agent, then we assume that it knows of
   and has the ability to reach a foreign agent.

   The foreign agent (FA) notes the EID of the MH in its Visitor List
   and sends a Foreign Agent Reply to the MH. This contains the EID and
   the locator of the FA and will be used as the "Care-of-Address" (COA)
   of the MH for a prespecified period.

   Registration: In the registration phase, infomation is exchanged
   between the MH and the Home Agent (HA). The HA could, for instance,
   be the endpoint representative of the endpoint in its home location.
   The registration procedure is used to create a mobility binding which
   the HA uses to forward data packets intended for the MH. Another
   purpose of registration is to verify the authenticity of the MH.

   There are four parts to the registration.  We describe the values
   assigned to the relevant fields.  Recall that there are two headers
   we must create - the Nimrod Protocol (NP) header and the Mobile-IP
   Protocol (MIPP) header.  The NP fields are as described above and the
   MIPP fields are as in [Sim94].  The fields mh-eid(mh-loc), fa-



Ramanathan                   Informational                     [Page 12]

RFC 2103                Nimrod Mobility Support            February 1997


   eid(fa-loc), ha-eid(ha-loc) are used to refer to the EID (locator) of
   the mobile host, foreign agent and home agent respectively.

   1. The MH sends a Registration Request to the prospective Foreign
      Agent to begin the registration process.

   o NP fields :  S-EID = mh-eid; D-EID = fa-eid; S-LOC = mh-loc ; D-LOC
     = fa-loc.

   o MIPP fields :  Home Agent = ha-eid; Home Address = mh-eid;
     Care-of-Address = fa-eid.

   Note that the mh-loc is known to the MH by virtue of the locator
   acquisition (see paragraph on "Agent Discovery") and that the fa-eid
   is known to the MH from the Foreign Agent Reply.  The FA caches the
   mh-eid for future reference.

   2. The Foreign Agent relays the request by sending a Registration
      Request to the Home Agent, to ask the Home Agent to provide the
      requested service.

   o NP fields :  S-EID = fa-eid; D-EID = ha-eid; S-LOC = fa-loc; D-LOC
     = ha-loc.

   o MIPP fields :  Same as in (copied from) (1) above.

   The HA caches the (Home Address, Care-of-Address) as a mobility
   binding.  Optionally, for efficiency, it may also cache fa-loc.

   3. The Home Agent sends a Registration Reply to the Foreign Agent to
      grant or deny service.

   o NP fields :  S-EID = ha-eid; D-EID = fa-eid; S-LOC = ha-loc; D-LOC
     = fa-loc.

   o MIPP fields :  Home Address = mh-eid; code = as in [Sim94].

   The S-EID and D-EID fields are taken from the Request and swapped, as
   are the S-LOC and D-LOC fields.  The Home Address in the MIPP is the
   same as the Home Address in the Request.  The code indicates whether
   or not permission was granted by the Home Agent.

   4. The Foreign Agent sends a copy of the Registration Reply to the MH
      to inform it of the disposition of its request.

   o NP fields :  S-EID = fa-eid; D-EID = mh-eid; S-LOC = fa-loc; D-LOC
     = mh-loc.




Ramanathan                   Informational                     [Page 13]

RFC 2103                Nimrod Mobility Support            February 1997


   o MIPP fields :  Same as (copied from) (3) above.

   At this point the MH is registered with the HA (provided the
   registration request is approved by the HA) and packets can be
   forwarded to the MH.

  +--------+
  |  CH    |
  +--------+
      V
      V
  #--------------#
  |mh-eid | data | = P(orig)
  #--------------#
      V
  +--------+  *----------------*   +--------+ *--------------* +------+
  |        |  |fa-eid | mh-eid |   |        | | ha-eid|mh-eid| |      |
  |        |  *----------------*   |        | *--------------* |      |
  |  HA    |------<-REG REQ-<------|  FA    |----<-REG REQ-<---| MH   |
  |        |   2                   |        |  1               |      |
  | mh-eid |                    3  | mh-eid |                4 |      |
  |   |    |------>-REG REPL->-----|   |    |---->-REG REPL->--|      |
  |   v    |  *----------------*   |   v    | *--------------* |      |
  | fa-eid |  |mh-eid | yes/no |   | mh-loc | |mh-eid|yes/no | |      |
  |        |  *----------------*   |        | *--------------* |      |
  |        |  #------------------# |        | #---------#      |      |
  |        |>>|       #--------# |>|        |>| P (orig)|>>>>> |      |
  +--------+5 |fa-eid | P(orig)| | +--------+ #---------#  6   +------+
              |       #--------# |
              #------------------#

Figure 1 : The control and data packets for mobility handling using
           the Mobile-IP protocol. The packets bordered as # denote
           data packets and those bordered * denote control packets.
           Only the crucial information conveyed in each message is
           shown (i.e., locators and EIDs in packet headers are not
           shown. The associations maintained at HA and FA are shown.

   Forwarding Data: We describe the manner in which a packet from the
   correspondent host (CH) intended for the MH is encapsulated and
   forwarded by the HA.

o At HA : Suppose that a packet P intended for MH arrives at HA. For
  instance, P first comes to the router for the local network and the
  router finds that MH is unreachable.  The router then forwards P to the
  HA for possible redirection.





Ramanathan                   Informational                     [Page 14]

RFC 2103                Nimrod Mobility Support            February 1997


   The HA extracts the destination EID from the NP header for P. If no
   match is found in its mobility binding, then the MH is deemed as
   unreachable.  If a match is found, the corresponding fa-eid is
   extracted.  A new header is prepended to P. For this header, S-EID =
   ha-eid, D-EID = fa-eid, S-LOC = ha-loc and D-LOC = fa-loc.  The fa-
   loc may be obtained from the Association Database [CCS96].
   Alternatively, if it was cached in (2) above, it could be obtained
   from the cache.

o At FA: By looking at the next header field in the Nimrod Protocol
  packet header, the FA knows that the packet is an encapsulated one.
  It removes the wrapping and looks at the EID in P. If that EID is
  found in the Visitor List then the FA knows the locator of the MH
  and can deliver the packet to the MH. Otherwise, the packet is
  discarded and an error message is returned to HA.

   Other Issues: We have not addressed a number of issues such as
   deregistration, authentication, etc.  The mobility specific portion
   of authentication can be adapted from the specification in [Sim94];
   deregistration can be done in a manner similar to registration.

   The protocol in [Sim94] describes a registration scheme without the
   involvement of the Foreign Agent.  This is done when the MH obtains a
   transient IP address using some link-level protocol (e.g.  PPP). A
   similar scheme can be given in the context of Nimrod.  In this case,
   the MH obtains its locator (typically inherited from the node to
   which it attaches) and sends this locator as its Care-of-Address in
   the Registration Request.  The HA, while forwarding, uses this as the
   locator in the outer NP header and thus the encapsulated packet is
   delivered directly to the MH which then decapsulates it.  No Foreign
   Agent Discovery is needed.  Apart from this, the fields used are as
   described for the scheme with the FA.

   We note however that many networks may require that the registration
   be through a Foreign Agent, for purposes of security, billing etc.

6  Security Considerations

   The registration protocol between a mobile host and the network (for
   instance, in the mobile-ip protocol, the MH and the HA) contains
   security mechanisms to validate access, prevent impersonation etc.

   This document is not a protocol specification and therefore does not
   contain a description of security mechanisms for Nimrod.







Ramanathan                   Informational                     [Page 15]

RFC 2103                Nimrod Mobility Support            February 1997


7  Summary

o Nimrod permits physical devices to be mobile, but does not specify a
  particular solution for routing in the face of mobility.

o The fact that the endpoint naming (EID) space and the locator space are
  separated in Nimrod helps in accommodating mobility in a graceful and
  natural manner.  Mobility may be percieved, essentially, as dynamism in
  the endpoint - locator association.

o Nimrod allows two kinds of mobility:

   -  Endpoint mobility.  For example, when a host in a network moves.
      This might cause a change in the locator associated with the host,
      but does not cause a change in the topology map for Nimrod.

   -  Network mobility.  For example, when a router or an entire network
      moves.  This might cause a change in the topology in addition to
      the locator.

o Endpoint mobility may be handled by maintaining a dynamic association
  between endpoints and locators.  However, network mobility requires
  addressing the topology change problem as well.

o Apart from the ability to handle network mobility, it is desirable that
  the mobility solution be scalable to large networks and large numbers
  of mobile devices and provide security mechanisms.

o There are a number of existing and emerging solutions to mobility.  In
  particular, adaptation of solutions developed by the IETF is a first
  cut possibility for Nimrod.  As the description given in section 5
  shows, it is relatively easy to implement the scheme being designed by
  the Mobile-IP working group in the context of Nimrod.

8  Acknowledgements

   We thank Isidro Castineyra (BBN), Charles Lynn (BBN), Martha
   Steenstrup (BBN) and other members of the Nimrod Working Group for
   their comments and suggestions on this memo.












Ramanathan                   Informational                     [Page 16]

RFC 2103                Nimrod Mobility Support            February 1997


9  Author's Address

   Ram Ramanathan
   BBN Systems and Technologies
   10 Moulton Street
   Cambridge, MA 02138

   Phone :  [phone]
   Email :  [e-mail]

References

[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The Nimrod
        Routing Architecture", RFC 1992, August 1996.

[RS96]  Ramanathan, S., and M. Steenstrup.  Nimrod functional and
        protocol specifications, Work in Progress.

[Sim94] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.

[TYT91] F. Teraoka, Y. Yokote, and M. Tokoro.  A network architecture
        providing host migration transparency.  In Proceedings of ACM
        SIGCOMM, 1991.

[WJ92]  K. A. Wimmer and J. B. Jones.  Global development of pcs. IEEE
        Communications Magazine, pages 22--27, Jun 1992.

























Ramanathan                   Informational                     [Page 17]