RFC relevance of solution

As per Relevance of the word solution, we have this rfc below:

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

Mobility Support for Nimrod : Challenges and Solution

Status of this

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

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

Table of

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

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

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

Ramanathan Informational [Page 1]

RFC 2103 Nimrod Mobility Support February 1997

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

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

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

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

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

2 Mobility : A Modular

Nimrod has a basic feature that helps accommodate mobility in
graceful and natural manner, namely, the separation of the
naming space from the locator space. The Nimrod architecture [CCS96]
associates an endpoint with a globally unique endpoint
(EID) and an endpoint label (EL). The location of the endpoint
the Internetwork topology is given by its locator. When an
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
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
be perceived as one of maintaining a dynamic association between
endpoints and the locators. Extending this viewpoint further,
can think of mobility-capable Nimrod as essentially consisting of
"modules": the Nimrod routing module and the dynamic
module (DAM). The DAM is an abstraction, embodying the
pertinent to maintaining the dynamic association. This is a
paradigm because it facilitates the comparison of various
schemes from a common viewpoint. Our discussion will be
based on the DAM abstraction and will be in two parts, the themes
which are :

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

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

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

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

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

Ramanathan Informational [Page 3]

RFC 2103 Nimrod Mobility Support February 1997

3 Effects of

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

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

Scenario 1. Neither the locator nor the topology changes.
is the trivial case and affects neither the DAM nor Nimrod.
example of this scenario is when a workstation is moved to a
interface on the same local area network(This is not true for
LANs, only those in which all interfaces are part of the
Nimrod node) or when mobility is handled
(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
indicate this to Nimrod if necessary. The effect on Nimrod
related to obtaining this change from the DAM. For instance
Nimrod may be informed of this change or ask for the
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
its neighbors (topology change) but remains within the
enclosing node. The DAM is not affected because
endpoint-locator association has not changed. Nimrod is
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
node moves out of its enclosing node, we have a change both
the map and in the locators of the devices in the network.
this case, both Nimrod and the DAM are affected

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

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

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

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

o Support of both off-line and on-line mobility. Off-line
(or portability) refers to the situation in which a session
torn down during the move, while on-line mobility refers to
situation in which the session stays up during the move.
currently much of the mobility is off-line, trends indicate
a large part of mobility in the future is likely to be on-line.
solution that only supports off-line mobility would probably
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
solution does not scale. The Internet is rapidly growing and
the advent of Personal Communication Systems (PCS) [WJ92],
number and rapidity of mobile components in the Internet is
likely to increase. Thus, there are three directions in
scalability is important : size of the network, number of
entities and the frequency of movement of the mobile entities

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

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

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

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

4

As discussed in section 2, the problem of mobility in the context
Nimrod may be viewed as one of maintaining a dynamic
(DAM) and communicating this association and changes therein
Nimrod. Approaches to mobility may be classified based on
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
endpoints and locators? This may be perceived as a problem
database maintenance. The database may be maintained in
centralized fashion, wherein a single entity maintains
association and updates are sent to it by the mobile host or
a distributed fashion, wherein there are a number of
that store the associations

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

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

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

(Re-mapping location
|

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

Table 1 : Classification of approaches based on how the
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
three combinations (marked A1 - A3 in the table) and examine
advantages and disadvantages in the context of our requirements.
other combinations (marked X in the table) are possible, but do
represent a substantially different class of solutions from the
discussed and hence are not considered here

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

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

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

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

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

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

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

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

An alternate mechanism is to maintain the mapping in all of
border routers (e.g., forwarding agents) in the node within
the movement took place. A packet from outside the node
for a destination within the node would typically enter the
through one of the border routers. Using the mapping, the
router could figure out the most recent locator of the
destination and send the packet directly to that locator. If
of the movements are within low level nodes, this would scale
large numbers of movements. Furthermore, the packet takes
optimal path (or as optimal as one can get with a
network) to the new location within the time it takes for the
representative to get the new information, which is
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
involved. However, future requirements in regard to scalability
response time might necessitate such an approach. Furthermore,
solution has closer ties with Nimrod routing and is better suited
handling scenarios 3 and 4 where the topology changes as a result
mobility

All of these approaches seem potentially capable of
scenarios 1 and 2 of the previous section. Scenarios 3 and 4
best handled by an approach similar to A3. However, approaches
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
Nimrod. In the final analysis, the tradeoffs between the
options will have to be examined vis-a-vis our
requirements (for instance, the need to support network mobility)
adopting a solution. It is likely that general requirements such
scalability and security will also influence the direction of
approach to mobility in Nimrod

5 A Solution using IETF Mobile-

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

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

5.1

The general scheme employed by the IETF Mobile-IP protocol is
follows. A Mobile Host (MH) has a predefined Home Agent (HA) that
responsible for the MH's whereabouts. Typically, the MH spends
of its time in the network containing the HA. Let us assume that
MH wanders to a new network. The MH then contacts a Foreign
(FA) at the new network that will act on its behalf and sends
registration request to the HA via the FA. This serves the purpose
informing the HA of the MH's new whereabouts and also is a means
verification of the MH's authenticity. It also contains the
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

Ramanathan Informational [Page 10]

RFC 2103 Nimrod Mobility Support February 1997

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

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

A fundamental difference between IP and Nimrod is that in the
an endpoint has both a (topologically sensitive) locator and
(topologically insensitive) endpoint-id (EID). In IP, the IP
serves as both the EID and the locator. Thus, it should be
to use the Mobile-IP protocol for providing mobility support
Nimrod by simply using the EID of the MH wherever its Home IP
was being used and by appropriately using the EID and locator of
FA and HA in place of their IP addresses (An issue is the format
length compatibility between EIDs and IP addresses. For
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
protocol fields and the actions taken by the MH, FA and HA to
that this is possible and that it is quite simple

5.2 Protocol

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

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

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

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

o Source locator (S-LOC) : Locator of the entity originating
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
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
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
ICMP Router Discovery messages

When an MH attaches to a Nimrod network (node), foreign
discovery is done as follows. We assume that a link-level
is established between the MH and a node N belonging to the network
For instance, this node could be a wireless equipped base
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
procedure between themselves as described in [RS96]. This results
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
locator acquisition procedure as described in [RS96]. This
in a locator being assigned to the MH

The MH then sends a Foreign Agent Request message to N. This
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
and has the ability to reach a foreign agent

The foreign agent (FA) notes the EID of the MH in its Visitor
and sends a Foreign Agent Reply to the MH. This contains the EID
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
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
the HA uses to forward data packets intended for the MH.
purpose of registration is to verify the authenticity of the MH

There are four parts to the registration. We describe the
assigned to the relevant fields. Recall that there are two
we must create - the Nimrod Protocol (NP) header and the Mobile-
Protocol (MIPP) header. The NP fields are as described above and
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)
the mobile host, foreign agent and home agent respectively

1. The MH sends a Registration Request to the prospective
Agent to begin the registration process

o NP fields : S-EID = mh-eid; D-EID = fa-eid; S-LOC = mh-loc ; D-
= 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
acquisition (see paragraph on "Agent Discovery") and that the fa-
is known to the MH from the Foreign Agent Reply. The FA caches
mh-eid for future reference

2. The Foreign Agent relays the request by sending a
Request to the Home Agent, to ask the Home Agent to provide
requested service

o NP fields : S-EID = fa-eid; D-EID = ha-eid; S-LOC = fa-loc; D-
= ha-loc

o MIPP fields : Same as in (copied from) (1) above

The HA caches the (Home Address, Care-of-Address) as a
binding. Optionally, for efficiency, it may also cache fa-loc

3. The Home Agent sends a Registration Reply to the Foreign Agent
grant or deny service

o NP fields : S-EID = ha-eid; D-EID = fa-eid; S-LOC = ha-loc; D-
= 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,
are the S-LOC and D-LOC fields. The Home Address in the MIPP is
same as the Home Address in the Request. The code indicates
or not permission was granted by the Home Agent

4. The Foreign Agent sends a copy of the Registration Reply to the
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-
= 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
registration request is approved by the HA) and packets can
forwarded to the MH

+--------+
| CH |
+--------+

#--------------#
|mh-eid | data | = P(orig
#--------------#

+--------+ *----------------* +--------+ *--------------* +------+
| | |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
the Mobile-IP protocol. The packets bordered as #
data packets and those bordered * denote control packets
Only the crucial information conveyed in each message
shown (i.e., locators and EIDs in packet headers are
shown. The associations maintained at HA and FA are shown

Forwarding Data: We describe the manner in which a packet from
correspondent host (CH) intended for the MH is encapsulated
forwarded by the HA

o At HA : Suppose that a packet P intended for MH arrives at HA.
instance, P first comes to the router for the local network and
router finds that MH is unreachable. The router then forwards P to
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
match is found in its mobility binding, then the MH is deemed
unreachable. If a match is found, the corresponding fa-eid
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
from the cache

o At FA: By looking at the next header field in the Nimrod
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
found in the Visitor List then the FA knows the locator of the
and can deliver the packet to the MH. Otherwise, the packet
discarded and an error message is returned to HA

Other Issues: We have not addressed a number of issues such
deregistration, authentication, etc. The mobility specific
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
involvement of the Foreign Agent. This is done when the MH obtains
transient IP address using some link-level protocol (e.g. PPP).
similar scheme can be given in the context of Nimrod. In this case
the MH obtains its locator (typically inherited from the node
which it attaches) and sends this locator as its Care-of-Address
the Registration Request. The HA, while forwarding, uses this as
locator in the outer NP header and thus the encapsulated packet
delivered directly to the MH which then decapsulates it. No
Agent Discovery is needed. Apart from this, the fields used are
described for the scheme with the FA

We note however that many networks may require that the
be through a Foreign Agent, for purposes of security, billing etc

6 Security

The registration protocol between a mobile host and the network (
instance, in the mobile-ip protocol, the MH and the HA)
security mechanisms to validate access, prevent impersonation etc

This document is not a protocol specification and therefore does
contain a description of security mechanisms for Nimrod

Ramanathan Informational [Page 15]

RFC 2103 Nimrod Mobility Support February 1997

7

o Nimrod permits physical devices to be mobile, but does not specify
particular solution for routing in the face of mobility

o The fact that the endpoint naming (EID) space and the locator space
separated in Nimrod helps in accommodating mobility in a graceful
natural manner. Mobility may be percieved, essentially, as dynamism
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
moves. This might cause a change in the topology in addition
the locator

o Endpoint mobility may be handled by maintaining a dynamic
between endpoints and locators. However, network mobility
addressing the topology change problem as well

o Apart from the ability to handle network mobility, it is desirable
the mobility solution be scalable to large networks and large
of mobile devices and provide security mechanisms

o There are a number of existing and emerging solutions to mobility.
particular, adaptation of solutions developed by the IETF is a
cut possibility for Nimrod. As the description given in section 5
shows, it is relatively easy to implement the scheme being designed
the Mobile-IP working group in the context of Nimrod

8

We thank Isidro Castineyra (BBN), Charles Lynn (BBN),
Steenstrup (BBN) and other members of the Nimrod Working Group
their comments and suggestions on this memo

Ramanathan Informational [Page 16]

RFC 2103 Nimrod Mobility Support February 1997

9 Author's

Ram
BBN Systems and
10 Moulton
Cambridge, MA 02138

Phone : (617) 873-2736
Email : ramanath@bbn.

[CCS96] Castineyra, I., Chiappa, N., and M. Steenstrup, "The
Routing Architecture", RFC 1992, August 1996.

[RS96] Ramanathan, S., and M. Steenstrup. Nimrod functional
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
providing host migration transparency. In Proceedings of
SIGCOMM, 1991.

[WJ92] K. A. Wimmer and J. B. Jones. Global development of pcs.
Communications Magazine, pages 22--27, Jun 1992.

Ramanathan Informational [Page 17]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX