rfc2103.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

4  Approaches

   As discussed in section 2, the problem of mobility in the context of
   Nimrod may be viewed as one of maintaining a dynamic association
   (DAM) and communicating this association and changes therein to
   Nimrod.  Approaches to mobility may be classified based on how
   different aspects of the DAM are addressed.











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


   Our classification identifies two aspects to the mobility solution :

   1. How and where to maintain the dynamic association between
      endpoints and locators?  This may be perceived as a problem of
      database maintenance. The database may be maintained in a
      centralized fashion, wherein a single entity maintains the
      association and updates are sent to it by the mobile host or in
      a distributed fashion, wherein there are a number of entities
      that store the associations.

      A (distributed) database that stores the endpoint-locator
      mapping is required by Nimrod even in the absence of mobility.  If
      this service can accommodate dynamic update and retrieval requests
      at the rate produced by mobility, this service is a candidate for a
      solution. However, we note that the availability of such a system
      should not be a requirement for the mobility solution.

   2. Where to do the remapping between the endpoint and locator, in
      case of a change in association?  By remapping, we mean associate
      a new locator with the endpoint.  Some candidates are :  the
      source, the "home" location of the host that has moved and any
      router (say, between the source and the destination) in the network.

   Many of the existing approaches and perhaps some new approaches to
   the problem of mobile internetworking may be seen to be
   instantiations of a combination of a dynamic association method and a
   remapping method.  We

                         (Re-mapping location)
                                   |
                                   v
          -----------------------------------------
          |            |Source |  Home  | Routers |
          -----------------------------------------
 (Assoc.  |Centralized |  A1   |   X    |    X    |
  maint)-> ----------------------------------------
          |Distributed |  X    |   A2   |   A3    |
          ----------------------------------------

Table 1 : Classification of approaches based on how the association
          is maintained and where the remapping is done.










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


   consider some combinations as illustrated in Table 1.  We discuss
   three combinations (marked A1 - A3 in the table) and examine their
   advantages and disadvantages in the context of our requirements.  The
   other combinations (marked X in the table) are possible, but do not
   represent a substantially different class of solutions from the ones
   discussed and hence are not considered here.

   Note that this is but one classsification of mobility schemes and
   that the remapping and endpoint-locator maintenance strategies
   mentioned in the table are not exhaustive.  The main intention is to
   help understand better the kinds of approaches that would be most
   suitable for Nimrod.

   In the following, we use the term source to refer to the endpoint
   that is attempting to communicate with or sending packets to a mobile
   endpoint.  The source could be static or mobile.  We use the term
   mobile destination to refer to the endpoint that is the intended
   destination of the source's packets.

A1.  In this approach, all endpoint-locator mappings are maintained
    at a centralized location.  The source queries the database to
    get the locator of the mobile destination.  Alternatively, the
    database can send updates to the source when the mobile
    destination moves. The main advantage of this scheme is its
    simplicity.  Also, no modification to routers is required, and the
    route from the source to a mobile destination is direct.

    The main disadvantage of this scheme is vulnerability - if the
    centralized location goes down, all information is lost.  While
    this scheme may be sufficient for small networks with low
    mobility, it does not scale adequately to be a long term solution
    for Nimrod.

A2.  This approach uses distributed association maintenance with
    remapping done at the home.  This is the approach that is being
    used by the Mobile-IP working group of the IETF for the draft
    proposal and by the Cellular Digital Packet Data (CDPD)
    consortium.  In this approach, every mobile endpoint is associated
    with a "home" and a "home representative" keeps track of the
    location of every mobile endpoint associated with it.  A protocol
    between a mobile endpoint and the home representative is used to
    keep the information up-to-date.  The source sends the packet
    using the home locator of the mobile destination, and the home
    representative forwards the packet to the mobile destination. The
    advantage of this scheme is that it is fairly simple and does not
    involve either the source or the routers in the network.
    Furthermore, the mobile destination can keep its location secret
    (known only to the home representative) - this is likely to be a



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


    desirable feature for mobile hosts in some applications.  Finally,
    most of the control information is confined to the node containing
    the home representative and the mobile host and this is a plus for
    scalability. The main disadvantage is a problem often referred to
    as triangular routing.  That is, the packets have to go from the
    source to the home representative first before going to the mobile
    destination.  This is especially inefficient if, for instance,
    both the source and mobile destination are in, say, England and
    the home representative is in, say, Australia.  Also, there is
    still some vulnerability, since if the home representative becomes
    unreachable, the location of all of the mobile hosts it tracks is
    lost and communication from most sources to the mobile host is
    cut-off.  It is also not clear how well this scheme will scale to
    mobile internetworks of the future.

    Nevertheless, we feel that this approach or a modification thereof
    might be a viable first-cut mobility solution for Nimrod.

A3.  In each of the previous cases, the routers in the network were
    not involved in tracking the location of the mobile host.  In
    this approach, state is maintained in the routers.  An example
    is the approach proposed in [TYT91] wherein the packets sent by
    a mobile host are snooped and state is created.  The packets
    contain the mobile host's home location and its new location.
    This mapping is maintained at some routers in the network.  When
    a packet intended for the mobile host addressed to its home
    location enters such a router, a translation is made and the
    packet is redirected to the new location.

    An alternate mechanism is to maintain the mapping in all of the
    border routers (e.g., forwarding agents) in the node within which
    the movement took place.  A packet from outside the node intended
    for a destination within the node would typically enter the node
    through one of the border routers.  Using the mapping, the border
    router could figure out the most recent locator of the mobile
    destination and send the packet directly to that locator.  If most
    of the movements are within low level nodes, this would scale to
    large numbers of movements. Furthermore, the packet takes an
    optimal path (or as optimal as one can get with a hierarchical
    network) to the new location within the time it takes for the node
    representative to get the new information, which is typically
    quite small for low-level nodes.









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


    The main disadvantage of this scheme is that routers have to be
    involved.  However, future requirements in regard to scalability and
    response time might necessitate such an approach.  Furthermore, this
    solution has closer ties with Nimrod routing and is better suited to
    handling scenarios 3 and 4 where the topology changes as a result of
    mobility.

   All of these approaches seem potentially capable of handling
   scenarios 1 and 2 of the previous section.  Scenarios 3 and 4 are
   best handled by an approach similar to A3.  However, approaches like
   A3 are more complex and involve more Nimrod entities (e.g., routers)
   than may be desirable.

   We have tried to bring out the various issues governing mobility in
   Nimrod.  In the final analysis, the tradeoffs between the various
   options will have to be examined vis-a-vis our particular
   requirements (for instance, the need to support network mobility) in
   adopting a solution.  It is likely that general requirements such as
   scalability and security will also influence the direction of the
   approach to mobility in Nimrod.

5  A Solution using IETF Mobile-IP

   The Mobile-IP Working Group of the IETF is in the process of
   standardizing a protocol that allows an IPv4 capable network to
   support mobile hosts.  In this section, we outline how mobility can
   be implemented within Nimrod using the same mechanism and indeed, the
   same protocol headers defined in [Sim94].  Not all functionality
   described in [Sim94] are covered - only those that form the "core" of
   mobility support.

   In order to follow this section, the reader is required to have some
   familiarity with the IETF Mobile-IP protocol (see [Sim94]).

5.1  Overview

   The general scheme employed by the IETF Mobile-IP protocol is as
   follows.  A Mobile Host (MH) has a predefined Home Agent (HA) that is
   responsible for the MH's whereabouts.  Typically, the MH spends most
   of its time in the network containing the HA. Let us assume that the
   MH wanders to a new network.  The MH then contacts a Foreign Agent
   (FA) at the new network that will act on its behalf and sends a
   registration request to the HA via the FA. This serves the purpose of
   informing the HA of the MH's new whereabouts and also is a means of
   verification of the MH's authenticity.  It also contains the address
   of the FA as the new Care-of-Address.  A correspondent host (CH)
   wishing to send a message to the MH uses the MH's Home IP address.
   This message is captured by the HA and tunnelled using encapsulation



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


   to the FA whereupon the FA decapsulates and sends the original
   message to the MH.

   If the MH can get itself a new transient address then there is no
   need for a Foreign Agent.  The transient address will be sent as the
   Care-of-Address.  The packets will be tunnelled directly to this
   address by the Home Agent.  Note, however, that some networks may
   require that a mobile host go through a Foreign Agent.

   A fundamental difference between IP and Nimrod is that in the latter
   an endpoint has both a (topologically sensitive) locator and a
   (topologically insensitive) endpoint-id (EID). In IP, the IP address
   serves as both the EID and the locator.  Thus, it should be possible
   to use the Mobile-IP protocol for providing mobility support in
   Nimrod by simply using the EID of the MH wherever its Home IP Address
   was being used and by appropriately using the EID and locator of the
   FA and HA in place of their IP addresses (An issue is the format and
   length compatibility between EIDs and IP addresses.  For the
   discussion here, we assume that an EID can fit into an IP (v4 or v6)
   address given in Figure 1).  We give below the details of the
   protocol fields and the actions taken by the MH, FA and HA to show
   that this is possible and that it is quite simple.

5.2  Protocol Details

   There are two kinds of protocol headers relevant to our discussion -
   the Mobile-IP Protocol (MIPP headers) and the headers for data
   packets transported by Nimrod (NP headers).  It is our intent that
   Nimrod use, as much as possible, the next generation IP (IPv6)
   header.  The NP header contains as a subset fields that would
   eventually be present in the IPv6 header.

   In the scheme given below, the MIPP header is enclosed within the NP
   packet (i.e., MIPP operates over NP). The details of the fields
   constituting the NP header are beyond the scope of this document.
   However, without venturing into bit lengths, etc., we identify below
   a few fields that are relevant to our discussion:

   o Source EID (S-EID) : The endpoint ID of the source entity
     originating the packet.

   o Destination EID (D-EID) : The endpoint ID of the destination.

   o Source locator (S-LOC) : Locator of the entity originating the
     packet.

   o Destination locator (D-LOC) : Locator of the destination.




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


   The MIPP header fields are described in [Sim94].

   In what follows, we describe the values that must be assigned to the
   relevant NP and MIPP fields in order for Nimrod to work with Mobile-
   IP.  There are three phases we must consider : agent discovery,
   registration and forwarding [Sim94].  A pictorial summary of the
   control and data packets is given in Figure 1.

   Agent Discovery: In this phase, the MH discovers the foreign agent,
   if any, that will act on its behalf.  In MIPP, this is done using the
   ICMP Router Discovery messages.

   When an MH attaches to a Nimrod network (node), foreign agent
   discovery is done as follows.  We assume that a link-level connection
   is established between the MH and a node N belonging to the network.
   For instance, this node could be a wireless equipped base station