GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2103

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.

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

  1. 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.
  1. 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 :  (617) 873-2736
 Email :  ramanath@bbn.com

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2103.txt · Last modified: 1997/02/06 00:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki