Network Working Group R. Ramanathan Request for Comments: 2103 BBN Systems and Technologies Category: Informational February 1997
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.
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.
2 Mobility : A Modular Perspective
3 Effects of Mobility
5 Solution using IETF Mobile-IP
5.2 Protocol Details
6 Security Considerations
9 Author's Address
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
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].
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.
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 :
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.
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.
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 :
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.
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.
Our classification identifies two aspects to the mobility solution :
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.
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
| v ----------------------------------------- | |Source | Home | Routers | ----------------------------------------- (Assoc. |Centralized | A1 | X | X | maint)-> ---------------------------------------- |Distributed | X | A2 | A3 | ----------------------------------------
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.
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.
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.
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.
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.
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]).
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
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.
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:
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-
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.
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.
The HA caches the (Home Address, Care-of-Address) as a mobility binding. Optionally, for efficiency, it may also cache fa-loc.
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.
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 +------+ | #--------# | #------------------#
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.
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.
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.
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.
- 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.
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.
BBN Systems and Technologies
10 Moulton Street
Cambridge, MA 02138
Phone : (617) 873-2736
Email : firstname.lastname@example.org