rfc2103.txt

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

Network Working Group                                      R. Ramanathan
Request for Comments: 2103                  BBN Systems and Technologies
Category: Informational                                    February 1997


   Mobility Support for Nimrod :  Challenges and Solution Approaches

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   We discuss the issue of mobility in Nimrod.  While a mobility
   solution is not part of the Nimrod architecture, Nimrod does require
   that the solution have certain characteristics.  We identify the
   requirements that Nimrod has of any solution for mobility support.
   We also classify and compare existing approaches for supporting
   mobility within an internetwork and discuss their advantages and
   disadvantages.  Finally, as an example, we outline the mechanisms to
   support mobility in Nimrod using the scheme currently being developed
   within the IETF - namely, the Mobile-IP protocol.

Table of Contents

   1  Introduction...................................................  1
   2  Mobility :  A Modular Perspective..............................  2
   3  Effects of Mobility............................................  4
   4  Approaches.....................................................  6
   5  Solution using IETF Mobile-IP.................................. 10
      5.1 Overview .................................................. 10
      5.2 Protocol Details........................................... 11
   6  Security Considerations........................................ 15
   7  Summary........................................................ 16
   8  Acknowledgements............................................... 16
   9  Author's Address............................................... 17

1  Introduction

   The nature of emerging applications makes the support for mobility
   essential for any future routing architecture.  It is the intent of
   Nimrod to allow physical devices as well as networks to be mobile.

   Nimrod, as a routing and addressing architecture, does not directly
   concern itself with mobility.  That is, Nimrod does not propose a
   solution for the mobility problem.  There are two chief reasons for



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


   this.  First, mobility is a non-trivial problem whose implications
   and requirements are still not well understood and will perhaps be
   understood only when a mobile internetwork is deployed on a large
   scale.  Second, a number of groups (for instance the Mobile-IP
   working group of the IETF) are studying the problem by itself and it
   is not our intention to duplicate those efforts.

   This attitude towards mobility is consistent with Nimrod's general
   philosophy of flexibility, adaptability and incremental change.

   While a mobility solution is not part of the "core" Nimrod
   architecture, Nimrod does require that the solution have certain
   characteristics.  It is the purpose of this document to discuss some
   of these requirements and evaluate approaches towards meeting them.

   We begin by identifying the precise nature of the functionality
   needed to accommodate mobile entities (section 2).  Following that,
   we discuss the effects of mobility on Nimrod (section 3).  Next, we
   classify current and possible approaches to a solution for mobility
   (section 4) and finally (in section 5) we describe how mobility can
   be implemented using the IETF's Mobile-IP protocol.

   This document uses many terms and concepts from the Nimrod
   Architecture document [CCS96] and some terms and concepts (in section
   5) from the Nimrod Functionality document [RS96].  Much of the
   discussion assumes that you have read at least the Nimrod
   Architecture document [CCS96].

2  Mobility :  A Modular Perspective

   Nimrod has a basic feature that helps accommodate mobility in a
   graceful and natural manner, namely, the separation of the endpoint
   naming space from the locator space.  The Nimrod architecture [CCS96]
   associates an endpoint with a globally unique endpoint identifier
   (EID) and an endpoint label (EL). The location of the endpoint within
   the Internetwork topology is given by its locator.  When an endpoint
   moves, its EID and EL remain the same, but its locator might change.
   Nimrod can route a packet to the endpoint after the move, provided it
   is able to obtain its new locator.












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


   Thus, providing a solution to mobility in the context of Nimrod may
   be perceived as one of maintaining a dynamic association between the
   endpoints and the locators.  Extending this viewpoint further, one
   can think of mobility-capable Nimrod as essentially consisting of two
   "modules":  the Nimrod routing module and the dynamic association
   module (DAM). The DAM is an abstraction, embodying the functionality
   pertinent to maintaining the dynamic association.  This is a valuable
   paradigm because it facilitates the comparison of various mobility
   schemes from a common viewpoint.  Our discussion will be structured
   based on the DAM abstraction and will be in two parts, the themes of
   which are :

   o What constitutes mobility for the DAM and Nimrod?  Is the
     realization of mobility as a mobility "module" that interacts
     with Nimrod viable? What then are the interactions between
     Nimrod and such a module?  These points will be discussed in
     section 3.

   o What are some of the approaches one can take in engineering the DAM
     functionality?  We classify some approaches and compare them in
     section 4.

   A word of caution:  the DAM should not be thought of as something
   equivalent to the current day Domain Name Service (DNS) - the DAM is
   a more general concept than that.  For instance, consider a mobility
   solution for Nimrod similar to the scheme described in [Sim94].  Very
   roughly, this approach is as follows:  Every endpoint is associated
   with a "home" locator.  If the endpoint moves, it tells a "home
   representative" about its new locator.  Packets destined for the
   endpoint sent to the old locator are picked up by the home
   representative and sent to the new locator.  In this scheme, the DAM
   embodies the functionalities implemented by all of the home
   representatives in regard to tracking the mobile hosts.  The point is
   that the association maintenance, while required in some form or
   other, may not be an explicitly distinct part, but implicit in the
   way mobility is handled.

   Thus, the DAM is merely an abstraction useful to our discussion and
   should not be construed as dictating a design.

   In summary, we view the Nimrod architecture as carrying a functional
   "stub" for mobility, the details of the stub being deferred for
   later.  The stub will be elaborated when a solution that meets the
   requirements of Nimrod becomes available (for instance from the IETF
   Mobile-IP research).  We do not, however, preclude the modification
   of any such solutions to meet the Nimrod requirements or preclude the
   development of an independent solution within Nimrod.




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


3  Effects of Mobility

   One consequence of mobility is the change in the locator of an
   endpoint.  However, not all instances of mobility result in a locator
   change (for instance, there is no locator change if a host moves
   within a LAN) and a change in the locator is not the only possible
   effect of mobility.  Mobility might also cause a change in the
   topology map.  This typically happens when entire networks move
   (e.g., an organization relocates, a wireless network in a train or
   plane moves between cells, etc.).  If the network is a Nimrod
   network, we might have a change in the connectivity of the node
   representing the network and hence a change in the map.

   In this section, we consider the effects of mobility on the two
   "modules" identified above:  Nimrod, which provides routing to a
   locator, and a hypothetical instantiation of the DAM, which provides
   a dynamic endpoint-locator association, for use by Nimrod.  We
   consider four scenarios based on whether or not the topology and an
   endpoint's locator changes and comment on the effect of the scenarios
   on Nimrod and the DAM.

   Scenario 1.  Neither the locator nor the topology changes.  This
       is the trivial case and affects neither the DAM nor Nimrod.  An
       example of this scenario is when a workstation is moved to a new
       interface on the same local area network(This is not true for all
       LANs, only those in which all interfaces are part of the same
       Nimrod node) or when mobility is handled transparently
       (by lower layers).

   Scenario 2.  The locator changes but the topology remains the same.
       This is the case when an endpoint moves from one node to another,
       thereby changing its locator.  The DAM is affected in this case,
       since it has to note the new endpoint-locator association and
       indicate this to Nimrod if necessary.  The effect on Nimrod is
       related to obtaining this change from the DAM. For instance,
       Nimrod may be informed of this change or ask for the association
       if and when it finds out that the mobile host cannot be reached.

   Scenario 3.  The locator does not change but the topology changes.
       One way this could happen is if a network node moves and changes
       its neighbors (topology change) but remains within the same
       enclosing node.  The DAM is not affected because the
       endpoint-locator association has not changed.  Nimrod is affected
       in the sense that the topology map would now have to be updated.







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


   Scenario 4.  Both the locator and the topology change.  If a network
       node moves out of its enclosing node, we have a change both in
       the map and in the locators of the devices in the network.  In
       this case, both Nimrod and the DAM are affected.

   In scenarios 3 and 4, it may not be sufficient to simply let Nimrod
   handle the topological change using the update mechanisms described
   in [RS96].  These mechanisms are likely to be optimized for
   relatively slow changes.

   Mobile wireless networks (in trains and cars for instance) are likely
   to produce more frequent changes in topology.  Therefore, it might be
   necessary that topological updates caused by mobility be handled
   using additional mechanisms.  For instance, one might send specific
   updates to appropriate node representatives, so that packets entering
   that node can be routed using the new topology.  We observe that
   accommodating mobility of networks, especially the fast moving ones,
   might require a closer interaction between Nimrod and the DAM than
   required for endpoint mobility.  It is beyond the scope of this
   document to specify the nature of this interaction; however, we note
   that a solution to mobility should handle the case when a network as
   a whole moves.  Current trends [WJ92] indicate that such situations
   are likely to be common in future when wireless networks will be
   present in trains, airplanes, cars, ships, etc.

   In summary, if we discount the movement of networks, i.e., assume no
   topology changes, it appears that the mobility solution can be kept
   fairly independent of Nimrod and in fact can be accommodated by an
   implementation of the DAM. However, to accommodate network mobility
   (scenarios 3 and 4), it might be necessary for Nimrod routing/routers
   to get involved with mobility.

   Beyond the constraints imposed by the interaction with Nimrod, it is
   desirable that the mobility solution have some general features.  By
   general, we mean that these are not Nimrod specific.  However, their
   paramount importance in future applications makes them worth
   mentioning in this document.  The desirable features are :

   o Support of both off-line and on-line mobility.  Off-line mobility
     (or portability) refers to the situation in which a session is
     torn down during the move, while on-line mobility refers to the
     situation in which the session stays up during the move.  While
     currently much of the mobility is off-line, trends indicate that
     a large part of mobility in the future is likely to be on-line.  A
     solution that only supports off-line mobility would probably have
     limited applications in future.





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


   o Scalability.  One of the primary goals of Nimrod is scalability,
     and it would be contrary to our design goals if the mobility
     solution does not scale.  The Internet is rapidly growing and with
     the advent of Personal Communication Systems (PCS) [WJ92], the
     number and rapidity of mobile components in the Internet is also
     likely to increase.  Thus, there are three directions in which
     scalability is important :  size of the network, number of mobile
     entities and the frequency of movement of the mobile entities.

     Note that for any given system with minimum response time (to a
     move) of o seconds, if the mobile entity changes attachment points
     faster than 1=o changes per second, the system will fail to track
     the entity.  Augmenting traditional location tracking mechanisms
     with special techniques such as predictive routing might be
     necessary in this case.  Hooks in the mobility solution for such
     augmentation is a desirable feature.

   o Security.  It is likely that in the future, there will be increased
     demand for secure communications.  Apart from the non-mobility
     specific security mechanisms, the solution should address the
     following :

-  Authentication.  The information sent by a mobile host about its
   location should be authenticated to prevent impersonation.
   Additionally, there should be mechanisms to decide if a mobile user
   who wishes to join a network has the privileges to do so or not.

-  Denial of service.  The schemes employed for handling mobility in
   general could be a drain on the resources if not controlled
   carefully.  Specifically, the resource intensive portions of the
   protocol should be guarded so that inappropriate use of them does
   not cause excessive load on the network.