doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc2103.txt b/doc/rfc/rfc2103.txt
new file mode 100644
index 0000000..f704d91
--- /dev/null
+++ b/doc/rfc/rfc2103.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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:
+
+   -  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 :  (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]
+