Internet DRAFT - draft-inzerilli-mobileip-simple
draft-inzerilli-mobileip-simple
INTERNET-DRAFT T. Inzerilli
Expires June 2001 University of Rome "La Sapienza"
January 2001
Intra-domain Mobility Support with SIMPLE
<draft-inzerilli-mobileip-simple-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." The list
of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this document is proposed a protocol for intra-domain mobility
management. This is intended to offer a transparent point-to-point
transport service for IP datagrams that need to be delivered to
mobile nodes. SIMPLE (Scalable Intra-domain Mobility Protocol using
Local Encapsulation) makes it possible for a mobile node to change
its point of attachment to a LAN, a group of LANs or even a MAN
without changing its IP address, this link being the home or a
foreign one.
Protocols for intra-domain mobility management find their rationale
in improving performances of communications when fast-moving mobile
nodes are involved. Recent studies on modern cellular systems have
Inzerilli [Page 1]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
shown that a conspicuous part of mobility is local. Consequently,
handovers could be managed using local ad-hoc measures in large part.
Not only does local handover management reduce latencies for location
updates and packet loss, but it limits mobility signaling to local
areas as well, preventing the Internet backbone from being congested
by location-update messages.
The goal of this protocol in particular is to achieve efficient
forwarding of IP datagrams inside a link, good scalability
properties, compatibility with Mobile IPv6 and, with some
adaptations, to Mobile IPv4 and to provide multiple-gateway access to
a domain.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and acronyms . . . . . . . . . . . . . . . . . . . . 5
2.1. General Terms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Mobile IP terms . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. Mobile IPv6 terms . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Mobile IP and Mobile IP6 terms . . . . . . . . . . . . . . . . 8
2.5. SIMPLE terms . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Overview of SIMPLE . . . . . . . . . . . . . . . . . . . . . . . 15
4. SIMPLE nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Switching node model . . . . . . . . . . . . . . . . . . . . . 22
4.2. Access Point model . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1. Routing Registers (RRs) . . . . . . . . . . . . . . . . . . . 26
4.2.2. Access Point operation . . . . . . . . . . . . . . . . . . . 31
4.2.2.1. Access Point signaling . . . . . . . . . . . . . . . . . . 31
4.2.2.2. AP switching algorithm . . . . . . . . . . . . . . . . . . 32
4.3. Mobile node model . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.1. Mobile node operation . . . . . . . . . . . . . . . . . . . . 35
4.3.1.1. Mobile node signaling . . . . . . . . . . . . . . . . . . . 35
4.3.1.2. Reception and transmission of data . . . . . . . . . . . . 36
4.4. Gateway model . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1. Reception and transmission of data . . . . . . . . . . . . . 37
5. SIMPLE signaling procedures . . . . . . . . . . . . . . . . . . . 38
5.1. Location discovery . . . . . . . . . . . . . . . . . . . . . . 40
5.2. Link-layer registration . . . . . . . . . . . . . . . . . . . . 42
5.3. DLA research procedures . . . . . . . . . . . . . . . . . . . . 45
5.4. State Refreshing . . . . . . . . . . . . . . . . . . . . . . . 48
5.5. Location update procedure . . . . . . . . . . . . . . . . . . . 49
5.6. Handovers and Error Recovery . . . . . . . . . . . . . . . . . 51
5.6.1. Forwarding strategy for handovers . . . . . . . . . . . . . . 53
Inzerilli [Page 2]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
5.6.2. Buffering and forwarding strategy for handovers and error
recovery . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Mobile IPv6 and Mobile IP non-standard routers' operation . . . . 58
6.1. Operation of home agents in IPv4 and IPv6 links . . . . . . . . 58
6.2. Operation of foreign agents in IPv4 links . . . . . . . . . . . 59
7. Considerations on SIMPLE . . . . . . . . . . . . . . . . . . . . 60
8. ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . 62
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 63
APPENDIX A: SIMPLE packet format . . . . . . . . . . . . . . . . . . 63
APPENDIX B: Routing Registers (RRs) format . . . . . . . . . . . . . 65
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction
A single standard protocol to provide the Internet with mobility
support could hardly represent an optimal solution. It would mean
imposing a single approach to a number of domains without considering
link peculiarities as for the technologies adopted and their
geographical extension. The need of standardization to render
interworking between heterogeneous links possible, together with the
necessity of leaving a window open for research, suggest separating
mobility at least into two levels. Mobility between domains (inter-
domain mobility) can be handled with Mobile IP either version 6 or
version 4, so as to allow a gradual transition from the current
version of IP towards its successor together with a gradual
deployment of mobile nodes. As regards to mobility inside domains
(intra-domain mobility), many alternative protocols could coexist in
the Internet to be better adapted to particular situations.
A separate intra-domain mobility protocol finds its rationale in
enhancing performances of communications when fast-moving mobile
nodes are involved. In fact, mobility management needs ad-hoc
signaling for location updates and handovers. Signaling propagated
over long distances could result in poor performances as it would be
subject to long latencies and could be affected by possible
congestion on the route. Moreover, the additional load of mobility
signaling itself could contribute to congesting the Internet backbone
in a future scenario with a large number of mobile nodes.
Recent studies on modern cellular systems have shown that a
conspicuous part of mobility is local. Consequently, handovers could
be managed using local ad-hoc measures in large part. Not only does
local handover management reduce latencies for location updates but
it limits mobility signaling to local areas as well, preventing the
Internet backbone from being congested by location update messages.
Inzerilli [Page 3]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
This document arises from the assumption that fundamental properties
of an intra-domain mobility protocol for the Internet are the
following:
- Full compatibility with both Mobile IP and Mobile IPv6 and
correlated Internet protocols should be guaranteed. Intra-domain
mobility has to appear as a completely transparent service to IP
entities. As a consequence, the scope of an intra-domain mobility
protocol is a link.
- Good scalability properties should be offered, in the sense that
performances have not to degrade significantly when the number of
mobile nodes registered to the link increases, or, more in general,
when the traffic that is globally offered to the link increases.
In addition, in large links where the number of switching levels is
considerable, performances should remain satisfactory. This because
solutions envisioning more than two mobility levels could be
inefficient and not easily deployable.
- The presence of an additional intra-domain mobility protocol should
not restrict access to a link through a single gateway. This would
become a single point of failure for a number of mobile nodes and a
possible bottleneck in case of heavy load.
- An intra-domain mobility protocol should fulfill its general task
of enhancing performances, in other words, it should considerably
reduce signaling latency and, hence, intervals of intermittent
connectivity and packet loss.
In this document an intra-domain mobility protocol is proposed .
SIMPLE (Scalable Intra-domain Mobility Protocol using Local
Encapsulation) could be used to bridge many different wireless and
wired segments. The resulting network would then appear as a single
link to Mobile IP ([2]) or Mobile IPv6 ([3]).
The main goals of the protocol are the points listed above. Another
feature of SIMPLE is a scalable auto-routing algorithm with limited
utilization of memory resources. In addition, SIMPLE can be used to
mask the non-multicast-capable nature of the networks it is built on
when signaling for address resolution needs propagating. In fact,
SIMPLE can enable to use ARP ([9]) and Neighbor Discovery ([7])
unchanged even on Non-Broadcast Multi-Access link (NBMA)([12])
without multicasting. Moreover, when Mobile IPv6 is used SIMPLE
makes it possible to assign care-of addresses through IPv6 Stateless
Address Autoconfiguration ([10]) independently of the nature of the
underlying networks, which could be non-multicast-capable. This
allows avoiding deployment of servers ([6]) for dynamic IP Address
assignment.
A preliminary version of this protocol can be found in [1].
Inzerilli [Page 4]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
2. Terminology and acronyms
2.1. General Terms
Access Point (AP)
A link node (generally with a wireless interface) which
grants or denies mobile nodes access to the link.
Domain
A division of the Internet.
Gratuitous ARP message
ARP packets sent to spontaneously cause other nodes to update
an entry in their ARP cache.
Handover or handoff
A movement of an active (receiving or transmitting) host to
another cell.
Host
Any Internet node that is not a gateway.
Interface
A node's attachment to a link.
Interface identifier
A number used to identify a node's interface on a link. The
interface identifier is the remaining low-order bits in the
node's IP address after the subnet prefix.
Internet node
A device provided with the IP layer. In a SIMPLE link it can
be a gateway (stationary device), a stationary host or a
mobile node.
Link
A communication facility or medium over which nodes can
communicate at the link layer level, such as an Ethernet
(simple or bridged). A link is the layer immediately below
IP. When SIMPLE is used, the link is the whole set of
networks SIMPLE bridges and it is built on. SIMPLE is used to
connect a number of links with a local routing rule to offer
an alternative to IP routing.
Link-layer address
The address used to identify an endpoint of some
Inzerilli [Page 5]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
communication over a physical link. Typically, the Link-Layer
address is an interface's Media Access Control (MAC) address,
such as IEEE 802 addresses on Ethernet links. (see also
definition of link-layer addresses in SIMPLE below).
Location update
The process of updating the location information relevant to
an idle mobile node after a change of cell.
Neighbor Discovery unsolicited advertisement
Neighbor Advertisement message to inform of a changed of
link- layer address.
Router
An Internet node that forwards IP packets not explicitly
addressed to itself. In a SIMPLE link routers can be either
gateways, stationary devices providing the SIMPLE link with
connectivity with the Internet, or mobile routers providing
external LANs with temporary connectivity with the SIMPLE
link.
Subnet prefix
A bit string that consists of some number of initial bits of
an IP address.
2.2. Mobile IP terms
Care-of Address
The termination point of a tunnel toward a mobile node for
datagrams forwarded to the mobile node while it is away from
home. The protocol can use two different types of care-of
addresses: a "foreign agent care-of address" is an address of
a foreign agent the mobile node is registered to, and a
"co-located care-of address" is an externally obtained local
address which the mobile node has associated with one of its
own network interfaces. In this document we will consider
only access to a foreign link by means of a foreign agent and
hence only foreign agent care-of addresses.
Foreign Agent
A router on mobile node's visited network which provides
routing services to the mobile node while registered. The
foreign agent detunnels and delivers datagrams to the mobile
node that were tunneled by the mobile node's home agent. For
datagrams sent by a mobile node, the foreign agent may serve
as a default router for registered mobile nodes.
Inzerilli [Page 6]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Foreign Network
Any network other than the mobile node's Home Network.
Home Address
An IP address that is assigned for an extended period of time
to a mobile node. It remains unchanged regardless of where
the node is attached to the Internet.
Home Agent
A router on a mobile node's visited network which tunnels
datagrams to be delivered to the mobile node when it is away
from home, and maintains current location information for the
mobile node.
Home Network
A network, having a network prefix matching that of a mobile
node's home address. Note that standard IP routing mechanisms
will deliver datagrams destined to a mobile node's Home
Address to the mobile node's Home Network.
Visited Network
A network other than a mobile node's Home Network, to which
the mobile node is currently connected. .fi
2.3. Mobile IPv6 terms
Care-of address
An IP address associated with a mobile node while visiting a
foreign link; the subnet prefix of this IP address is a
foreign subnet prefix. Among the multiple care-of addresses
that a mobile node may have at a time (e.g., with different
subnet prefixes), the one registered with the mobile node's
home agent is called its "primary" care-of address. Multiple
care-of address aspects are out of the scope of this
document.
Foreign link
Any link other than the mobile node's home link.
Foreign subnet prefix
Any IP subnet prefix other than the mobile node's home subnet
prefix.
Home address
An IP address assigned to a mobile node within its home link.
Home agent
Inzerilli [Page 7]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
A router on a mobile node's home link with which the mobile
node has registered its current care-of address. While the
mobile node is away from home, the home agent intercepts
packets on the home link destined to the mobile node's home
address, encapsulates them, and tunnels them to the mobile
node's registered care-of address.
Home link
The link on which a mobile node's home subnet prefix is
defined. Standard IP routing mechanisms will deliver packets
destined for a mobile node's home address to its home link.
Home subnet prefix
The IP subnet prefix corresponding to a mobile node's home
address.
2.4. Mobile IP and Mobile IP6 terms
Mobile node (MN)
A node that can change its point of attachment from one link
to another, while still being reachable via its home address.
Correspondent node
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Binding (or Mobility Binding)
The association of the home address of a mobile node with a
care-of address for that mobile node, along with the
remaining lifetime of that association.
2.5. SIMPLE terms
Access part
A SIMPLE link consists of a distribution system and an access
part. Internet nodes attach to the SIMPLE link in the access
part through APs. APs and mobile nodes are typically provided
with wireless interfaces.
Access point number (APN)
It identifies an AP in a SIMPLE link and corresponds to its
switching number (see below). All current link-layer
addresses (CLAs) assigned to mobile nodes served in the cell
must begin with the same prefix, which is the APN.
Inzerilli [Page 8]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Advertisement message
A signaling message broadcast by each AP regularly and
carrying information about the link and the cell. In this
document it is a SIMPLE specific message and not a Mobile IP
message.
Buffering Request message
A signaling message generated by a mobile node during a
period of degradation of the communication quality and sent
to the AP, requesting the Access Point (AP) to buffer a copy
of each packet which is transmitted into the channel and
destined to the mobile node for a specified interval of time
(buffering soft state).
Buffering state (see also SIMPLE soft states)
It is created in a Routing Register (AP routing table) on
reception of a Buffering request message from a registered
mobile node. When a registration state for a mobile node is
turned into a buffering state, a copy of all packets
transmitted to the mobile node is stored in the serving AP
till a timer expires or a request of forwarding buffered
packets for accomplishing a handover is received. In the
former case, the buffering state is turned into a
registration state again. In the latter case, is turned into
a forwarding state.
Current AP
It is the AP where a mobile node is being served or tries to
register to. A mobile node which is served in a cell will use
a two-byte binary string beginning with its AP's access point
number (APN) as its current link-layer address (CLA).
Current LA (CLA)
This is a two-byte address identifying the current location
of the mobile node in the link and it is assigned by the
serving AP. The current LA is changed each time a mobile node
moves to a new AP. Internet nodes' caches contain the
bindings (IP address, CLA). All packets destined to a mobile
node will have to be sent using its CLA as the packet's
destination link-layer address.
Default AP
Each mobile node registered to a SIMPLE link has a default AP
where its current address (CLA) is contained. The mobile
node's default AP is selected during a link-layer
registration and kept by the mobile node all the time it
remains attached to the link. If the mobile node is in its
home link, it will correspond to the mobile node's reserved
Inzerilli [Page 9]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
cell.
Default LA (DLA)
It is a two-byte pointer to a location where the mobile
node's CLA is contained. It is used to deliver address
resolution queries by means of a two-step routing when the
destination CLA is not known. In the mobile node's home link
the returned DLA is simply the last two bytes of the mobile
node's home address. In a foreign link and when Mobile IPv6
([3]) is used, this is the IPv6 interface identifier (without
a 6-byte of initial zeros to respect the EUI-64 ([15])
format) that is passed to the mobile node's IP entity to
obtain a dynamic care-of address through IPv6 Stateless
Address Autoconfiguration ([10]). In a foreign IPv4 network,
a DLA is the link-layer address of the foreign agent the
mobile node is registered to.
Distribution system
A SIMPLE link consists of a distribution system and an access
part. Nodes in the distribution system perform switching of
packets not addressed to themselves and are called switching
nodes. Switching in the distribution system exploits the
auto- routing content of SIMPLE link-layer address in a
suitably numbered link to forward packets.
DLA Request message
A message originated by an access point to request an
available DLA to assign to a registering mobile node.
DLA Reply message
A message sent to an access point that assigns a unique DLA
for a new registering mobile node.
Forwarding Request message
A signaling message generated during a mobile node's handover
and sent from the new AP to the old AP to have packets
destined to the mobile node and carrying the mobile node's
old CLA as destination link-layer address forwarded to its
new AP. This message creates a forwarding state in the old
AP's Routing Register (RR).
Forwarding State (see also SIMPLE soft states)
When a registration state or a buffering state is turned into
a forwarding state in the old AP on a forwarding request
arrival, packets for a mobile node arriving at the old AP are
diverted to the new mobile node's AP together with all the
buffered packets, if any. When a forwarding state expires the
mobile node's old CLA is released and can be assigned to
Inzerilli [Page 10]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
another mobile node (AH bits set to 00).
Handover Request message
A signaling message sent by an active mobile node to the
current AP while moving from a cell to another to request
access to a new cell.
Handover Reply message
A signaling message sent by an AP to an active mobile node in
response to a Handover Request message to grant or deny
access to the cell.
Home link identifier
It is the link identifier of the mobile node's home link (see
link identifier below).
Link identifier
It is a number broadcast in a SIMPLE Advertisement message.
Each mobile node has its own home link identifier. It can
then compare the advertised link identifier with its home
link identifier to understand if it is in its home link. An
access point receiving a registration message from a new
mobile node can compare the advertised link identifier (the
mobile node's home link identifier) with its configured link
identifier (that broadcast regularly by all APs) to
understand if the registering mobile node is in its home
link.
Link-layer address (LA)
It is a SIMPLE specific two-byte address assigned to all
Internet nodes on the link. Gateways' LAs are permanent and
also called Static Link-Layer Addresses (SLAs). The set of
SLAs in a link is always constituted by consecutive numbers
starting from 0 to NUM_GT-1. Mobile node's LA are composed
of a prefix, Access Point Number (APN), and a suffix, Local
Mobile node Identifier (LMI). Each mobile node in the link
has its own Current Link-layer Address (CLA), Default
Link-layer address and Reserved Link-layer address (see
below). Two of them or the all three can sometimes correspond
for a same mobile node.
Link-layer Registration
It is the SIMPLE specific registration. This ends with the
acceptance or the rejection of the registering mobile node in
the cell. In the former case, a CLA and a DLA are returned to
the registering mobile node.
Link node (or SIMPLE node)
Inzerilli [Page 11]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
A device which is provided with a SIMPLE entity but not
necessarily with an IP entity. It can be a switching node
(access point, switch, gateway) or a mobile node. Switching
nodes are stationary devices, constitute the distribution
system of a link and provide local transport of SIMPLE
packets to be sent in the Internet or destined to mobile
nodes in the link.
Local mobile node Identifier (LMI)
It is the suffix of an LA, identifying a mobile node that is
being served in a cell.
Location Refresh message
A message generated by a mobile node's current AP following a
Registration Refresh message by the mobile node. It is sent
to the mobile node's default cell (or the mobile node's
foreign agent in a foreign IPv4 network) to refresh a
location state.
Location State (or default state, see also SIMPLE soft states)
It contains a pointer to a mobile node's current location
(mobile node's CLA) and it is stored in the mobile node's
default cell, which is selected during registration time. A
location state is soft and lasts till the relevant
registration state in the mobile node's current AP expires.
It then needs to be continuously refreshed by Location
Refresh messages by the mobile node's current AP.
Location Update message
A signaling message sent by a mobile node's current AP to
update the mobile node's default state with its new CLA after
a successful handover or location update.
Location Update Request message
A signaling message sent by an idle mobile node to the
current AP while moving from a cell to another to request
access to a new cell.
Location Update Reply message
A signaling message sent by an AP to an idle mobile node in
response to a Location Update Request message to grant or
deny access to the cell.
Peer (link) node
A switching node with a switching number as long as another
switching node's.
Registration Refresh message
Inzerilli [Page 12]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
A message sent by a mobile node to its serving access point
to refresh its registration state. A mobile node registered
to a link has to regularly refresh its registration state to
assure the current AP that it is still present in the cell.
Registration Request message
A signaling message sent by a mobile node to the current AP
at the beginning of a link-layer registration to request
access to a SIMPLE link.
Registration Reply message
A signaling message sent by an access point to a registering
mobile node in response to a Registration Request message to
deny or grant access to the link.
Registration state (see also SIMPLE soft states)
It is created after a successful link-layer registration to
an AP. A registration state is soft, in other words, it
needs to be regularly refreshed by data or ad-hoc
Registration Refresh messages to be kept alive.
Reserved AP
Each mobile node has a reserved cell in its home link, where
it holds a reserved LA, which cannot be assigned to any other
mobile node as CLA. It consequently has guaranteed access to
the link if it enters that cell. For the consistency of the
protocol the mobile node's reserved LA must be always the
two-byte suffix of the mobile node's home IP address and the
reserved AP's APN must be a prefix of the mobile node's
reserved LA. As a consequence, assigning an IP home address
to a mobile node in a SIMPLE link, means providing it with a
granted access in a reserved cell in the link
Reserved LA (RLA)
This is a two-byte link-layer address configured in the
mobile node. It corresponds to the two-byte suffix of the
mobile node's IP home address. The prefix of a RLA identifies
the mobile node's reserved cell in its home link. A mobile
node can never be rejected by its reserved cell in its home
link.
Routing Register (RR)
It is a table where intra-domain mobility management
information is contained (section 4.2.1 ).
SIMPLE packet
An IP datagram plus a SIMPLE header or a SIMPLE specific
signaling message.
Inzerilli [Page 13]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
SIMPLE soft states
SIMPLE keeps track of all the mobile nodes registered to the
link by means of a distributed set of tables referred to as
Routing Registers, each of them containing a set of entries
associated to an LA of the link. An entry can contain one or
two soft states associated to the relevant LA. When an LA is
used as a CLA for a mobile node there can be either a
registration state or a buffering state or a forwarding state
in the relevant entry. When an LA is used as a DLA for a
mobile a default state is present. An LA can be used either
as a CLA for a mobile node or a DLA for a mobile node or both
a CLA and a DLA for the same or for two distinct mobile
nodes.
Static LA (SLA)
It is a link-layer address of a gateway on a SIMPLE link. The
set of SLAs in a SIMPLE link consists of binary strings
corresponding to consecutive numbers starting from 0.
Switching mask
Binary mask assigned to each switching node in a SIMPLE link
for routing purposes (see switching node definition).
Switching node
Switch, AP or gateway in a SIMPLE link. Each switching node
performs an auto-routing algorithm of SIMPLE packets, basing
on node-local information and the routing rule expressed by
the content of packets' destination LAs (see appendix A and
section 4.1). Node-local information consists of the node's
switching number and its neighbor switching nodes'.
Switching number (SWN)
An identifier of a switching node used for switching
purposes. It must be a prefix of all its downlink nodes'
SWN. APs' switching numbers are also referred to as Access
Point Numbers (APNs) and must be the prefix of all CLAs
assigned in the relevant cell.
Visitor Address Resolution Table
It is a separate cache used by a foreign agent in IPv4 links
to store (Home IP address, CLA) bindings of visiting mobile
nodes. These correspond to default states associated to the
visiting mobile nodes, which are not present in the
dynamic-CLA entries of RRs in IPv4 links.
Inzerilli [Page 14]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
3. Overview of SIMPLE
SIMPLE (Scalable Intra-domain mobility Protocol using Local
Encapsulation) provides mobile nodes with a local mobility service
inside a link, which is completely transparent to the IP layer. In
other words, it allows mobile nodes (MNs) to change their interface
to a link and keep their IP address. SIMPLE provides intra-domain
mobility support in both home and foreign links, these being IPv4 or
IPv6 links.
The SIMPLE network we consider is made of a distribution system and
an access part (fig. 1). Internet nodes are all located at the edges
of the link. They can be gateway on the distribution system or mobile
nodes on the access part and use SIMPLE as a facility to exchange IP
datagrams with neighboring IP nodes on the link.
+----+ +----+
| GT |<=============>| GT |
+----+ +----+
// \
+----+___________________+----+
| SW |-------------------| SW |
+----+ +----+
// || \______+----+_______// \
// || ------ | AP |-------- \
// || +----+ \
+----+ || +----+
| SW | || | SW |
+----+ || +----+
// || || // \
// || || // \
// || +----+ +----+ \
+----+ || | AP | | AP | \
| AP | || +----+ +----+ \
+----+ || +----+
|| | AP |
+----+ +----+
| AP | ||
+----+ ||
|| +----+
+----+ | MN |
| MN | +----+
+----+
Fig. 1-An example of SIMPLE link
Inzerilli [Page 15]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
When a mobile node shows up in a SIMPLE link it will trigger suitable
signaling procedures to attach to it. This will consist of two or
three separate procedures in general:
a With a first exchange of messages, which are peculiar of the
access technology (i.e. Hiperlan II, IEEE802.11...) and often
involves the physical and MAC layer, the mobile node will associate
with an AP, establishing connectivity at the level of the access
channel. In those technologies, where a wireless segment is
integrated with a wired segment by means of bridges, this procedure
will allow to use the wired segment as a distribution system for
intercell communications as well.
b In a SIMPLE link, either the previous association procedure has
involved a wired segment or not, a second registration level
(link-layer registration) will take place to establish full link
connectivity to enable the mobile node to exchange IP datagrams
with all Internet nodes on the link. A link could contain many
wired segments and many wireless segments. Link-layer registrations
will successfully end providing mobile nodes with two two-byte
identifiers, a Current Link-layer Address (CLA) and a Default Link-
layer Address (DLA). The former (CLA) identifies the mobile node's
serving AP (or current AP) with its prefix and the particular
mobile node in the cell with its suffix. The CLA will be changed
each time the mobile node attaches to a new AP of the same link.
The latter (DLA) is a pointer to a default location where the
mobile node's CLA is constantly stored. Unlike the CLA, a DLA is
kept unchanged till the mobile node leaves the link. A DLA always
corresponds to the last two bytes of the IP address the mobile node
will use in the link.
c A Mobile IP or Mobile IPv6 registration with a remote home agent
will take place only if the mobile node is visiting a foreign link.
However, it can happen that a mobile node entering its home link
needs to deregister explicitly with a home agent in its home link.
Level-b connectivity is the intra-domain mobility level when SIMPLE
is used. It is clear that this has some utility only if level b has a
scope which is wider than level a. Its purpose is to make the
distribution system plus the access part appear as a homogeneous
link, where changes of link interface are completely transparent to
the IP layer. Whereas, level c is the inter-domain mobility level
([2,3]) and is out of the scope of this document, if not only for
those aspects which define the interfacing of SIMPLE with Mobile IP
and Mobile IPv6.
Transparency of SIMPLE to the inter-domain mobility level is achieved
thanks to the fact that a mobile node while roaming inside the same
Inzerilli [Page 16]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
link will keep its IP address and its DLA, which is easily derivable
from the mobile node's IP address used in the link by extracting the
last two bytes of the IP address (with the exception of IPv4 mobile
nodes registered to a foreign agent), while it will change its CLA
after a move to a new cell. A CLA of a registered mobile node can be
discovered using the DLA. In fact, the mobile node's DLA is fix and
points to a location where the mobile node's CLA is stored.
Once a mobile node has acquired a CLA, it can send and receive IP
datagrams. These are first encapsulated in SIMPLE packets, then
routed using the destination LA field in their SIMPLE header and
finally, on reception, decapsulated and delivered to the destination
node's IP entity. The routing algorithm takes advantage of the format
of LAs. In fact, SIMPLE LAs have auto-routing content, in the sense
that an LA itself represents a rule to perform routing inside the
link.
All Internet nodes on the link are given a link-layer address (LA).
An LA is two bytes long. As a consequence, a SIMPLE link can contain
up to 65536 Internet nodes and SIMPLE packets have only a 4-byte
header(see Appendix A). SIMPLE is then suited for managing local
mobility in a rather large area adding a minimal overhead to IP
datagrams (an IP datagram is typically 1500 bytes). A link can then
correspond to a LAN, simple or bridged, a group of LANs, or a MAN.
Gateways in a SIMPLE domain are stationary devices located at the
highest switching level of the link and used both for switching
within the SIMPLE link and as edge devices with the Internet. They
need to be assigned what it is referred to as a Static Link-layer
Address (SLA) to recognize packets destined to them when these
contain their SLA in the destination LA field. The set of SLAs
assigned in the link consists of two-byte binary strings
corresponding to consecutive numbers starting from 0. So, when a
SIMPLE link is provided with three gateways these have to be given
the following SLAs: 0000000000000000, 0000000000000001,
0000000000000010.
Instead, an LA assigned to a mobile node consists of two parts (see
Appendix A), a prefix and a suffix. The prefix, Access Point Number
(APN), identifies the Access Point (AP) the node is attached to. The
suffix, Local mobile node Identifier (LMI), identifies a particular
node in the cell.
Link nodes other than mobile nodes constitute the distribution system
of the SIMPLE link and are used for switching purposes. They are then
referred to as switching nodes and are all provided with a unique
parameter referred to as switching number (a string of bits shorter
than two octets). Access point switching numbers are also called
Inzerilli [Page 17]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Access Point Numbers (APNs). An auto-routing algorithm is performed
in the distribution system to enable packets relaying with routing
tables containing only local information. This is obtained fixing a
suitable numeration of the SIMPLE link by means of local
configuration of the switching nodes. More precisely, a SIMPLE node
has to be aware only of its switching number and of its neighboring
switching node's.
Figure 2 shows a possible logical link topology with a consistent
numeration of the nodes, which allows automatic routing in the
distribution system. All switching nodes have links to one uplink
node (except for gateways), to some downlink nodes and to peer nodes
(nodes with the switching number of the same length). All the
downlink nodes from a same uplink node have their switching number of
the same length and beginning with a same prefix, which is
correspondent to the uplink node's switching number. Switching nodes
of a same hierarchical level can be connected and will have their
switching number of the same length (peer nodes).
The routing algorithm exploits local information in each node plus
the number-of-gateways-in-the-link information NUM_GT. It proceeds
applying the following rules:
1 A SIMPLE packet with a destination LA which is grater than or equal
to NUM_GT, originated in a gateway, is relayed downlink hop-by-hop,
each node having its switching number equal to the prefix of the
destination LA field in the packet header.
2 A SIMPLE packet with a destination LA which is smaller than NUM_GT,
originated in a gateway, is sent towards the gateway having its
SLA equal to the packet's destination LAs.
3 A SIMPLE packet with a destination LA which is grater than or equal
to NUM_GT, originated in a mobile node, is relayed uplink till one
of the following events occurs.
3.1 a node with a direct link to another peer node having its
switching number equal to the prefix of the destination LA field
in the packet header is reached; the packet is then relayed to
the peer node and, afterwards, the packet will be relayed
downlink till the destination node as specified in rule 1.
3.2 a node having its switching number equal to the prefix of
the destination LA field in the packet header is reached and,
afterwards, the packet will be relayed downlink till the
destination node as specified in rule 1.
4 A SIMPLE packet with a destination LA which is smaller than NUM_GT,
originated in a mobile node, is sent uplink till a gateway is
reached. The packet will be then sent to the destination gateway
having its SLA coinciding with the packet's destination LA.
Inzerilli [Page 18]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
+----+ +----+
SWN:00 | GT |<============>| GT | SWN:01
+----+ +----+
// \
+----+__________________+----+
SWN:000 | SW |------------------| SW | SWN:010
+----+ APN:010 +----+
// || \_______+----+_____// \
// || --------| AP |------ \
// || +----+ \
+----+ || +----+
SWN:0000 | SW | || | SW | SWN:0101
+----+ || +----+
// || || // \
// || || // \
// || +----+ +----+ \
+----+ || | AP | APN:0001 | AP | \
| AP | || +----+ +----+ \
+----+ || APN:010101000 \
APN: || +----+
00000001011 || APN: | AP |
+----+ 010100110 +----+
| AP | APN:00000010000 ||
+----+ ||
// +----+
+----+ | MN |
| MN | CLA:00000010000.01111 +----+
+----+ CLA:010100110.0001001
Fig. 2 - An example of SIMPLE routing
In the following we provide an example of SIMPLE routing. Mobile node
00000010000.01111 needs to send a packet to mobile node
010100110.0001001 (fig. 2).
- The packet is sent to the mobile node's current AP 00000010000.
- Here, as the packet's destination LA is grater than 1 and the
APN and the prefix of the packet's destination LA differ and no
direct link with an AP 01010011000 is provided, the packet is
relayed to the uplink node 0000.
- Here, as the packet's destination LA is grater than 1 and the
switching number of the node and the prefix of the packet's
destination LA differ and no direct link with a node 0101 is
provided, the packet is relayed to the uplink node 000.
- Here, as the packet's destination LA is grater than 1 and the
switching number of the node and the prefix of the packet's
destination LA differ but a direct link for the node 010 is
Inzerilli [Page 19]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
provided, the packet is relayed directly to it.
- Here, as the packet's destination LA is grater than 1 and the
switching number of the node and the prefix of the packet's
destination LA coincide, the packet is relayed to the downlink
node 0101, having its switching number that is a prefix of the
packet's destination LA.
- Here, as the packet's destination LA is grater than 1 and the
switching number of the node and the prefix of the packet's
destination LA coincide the packet is relayed to the downlink AP
010100110, having its switching number that is a prefix of the
packet's destination LA.
- Here, as the packet's destination LA is grater than 1 and the
APN and prefix of the packet's destination LA coincide, the
packet is relayed to the mobile node 010100110.0001001, having
its CLA coinciding to the packet's destination LA.
A SIMPLE can also enable stationary nodes to coexist with mobile
nodes in a same IPv4 or IPv6 link. Stationary hosts can attach to an
AP as mobile nodes do. They can be considered as particular cases of
mobile nodes keeping a fix CLA, which corresponds to their DLA, which
in turn is given by the last two-byte of the mobile node's IP
address. In the following there will be no explicit reference to
stationary host operation in a SIMPLE link. Suffice to say that what
is applicable to mobile node is valid for stationary hosts as well,
in particular switching of SIMPLE packets toward stationary hosts is
performed in the same way as toward mobile nodes. Instead, all
mobility related issues are excluded.
4. SIMPLE nodes
A SIMPLE node can be either a mobile node or a switching node. The
former is a device univocally identified in the link by its Current
Link-layer Address (CLA), which it is changed each time it moves from
a cell to another, and has a single uplink interface with the serving
AP. The latter is a stationary device, which makes part of the SIMPLE
link distribution system, allows intercell as well as intracell
communication and provides connectivity with the Internet. Switching
nodes can be Access Points (APs), Switches (SWs) or gateways (GTs).
It is necessary that a packet destined to a mobile node contains its
CLA in the destination LA field to reach the destination mobile node.
However, it can happen that a gateway or a mobile node on the link,
on sending a packet, be not provided with the destination mobile
node's CLA, as mobile nodes can continuously change their point of
attachment to the link.
Inzerilli [Page 20]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
As a solution, each mobile node registered to the link is also
provided with a Default Link-Layer Address (DLA), which is a fix
pointer to a default location where the mobile node's CLA can be
found (default state or location state). A DLA always corresponds to
the last two bytes of the mobile node's IP address (either home
address or IPv6 care-of address) used in the link (the link-layer
registration will guarantee this condition), except when mobile nodes
roam in a IPv4 foreign network. In this case it will correspond to
the mobile node's foreign agent's SLA (see section 6.2). Unlike a
mobile node's CLA, a DLA is kept all the time the mobile node remains
registered to the link while moving from a cell to another. When a
packet has to be sent to a mobile node whose CLA is not known, it is
then possible to use first the mobile node's DLA as the packet's
destination LA, which will lead the packet to the mobile node's
default cell. Once arrived here, the CLA can be read and the packet
sent again using the mobile node's CLA.
Gateways in a SIMPLE domain are stationary devices located at the
highest switching level of the link and used both for switching
within the SIMPLE link and as edge devices with other networks. As a
consequence, they need to be assigned a Static Link-layer Address
(SLA) to recognize packets destined to them when these contain their
SLA in the destination LA field. The set of SLAs assigned in the link
consists of two-byte binary strings corresponding to consecutive
numbers from 0. So, when a SIMPLE link is provided with three
gateways these have to be given the following SLAs: 0000000000000000,
0000000000000001, 0000000000000010.
Access points, switches and gateways perform switching of packets
inside the link and constitute the distribution part of the SIMPLE
link. Packets are forwarded inside the distribution system by means
of an auto-routing algorithm which exploits a suitable numeration of
switching nodes (see section 4.1).The algorithm is scalable as it
exploits in each switching node only local information. The global
information to perform routing end-to-end in the link is the packet's
destination LA itself.
An access point uses this algorithm in combination with a routing
table, referred to as Routing Register (RR). This is used when the AP
receives a packet with a destination LA beginning with its APN. The
AP will be Then decide if to relay the packet in the channel or
discard it, or buffer a copy or forward it to another destination on
the basis of the Information contained in the RR for the packet's
destination LA (see section 4.2.1).
Inzerilli [Page 21]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
4.1. Switching node model
In this section we provide a specification of the routing algorithm
performed on the distribution system together with some
implementation guidelines using right-shifts and two-byte binary
masks. A different implementation approach could be adopted if proved
to be more efficient and guaranteeing a correct operation.
Access points, switches and gateways are referred to as switching
nodes. They perform switching of packets inside the link and
constitute the distribution part of the SIMPLE link. Packets are
forwarded inside the distribution system by means of an auto-routing
algorithm which exploits a suitable numeration of switching nodes.
Each switching node is provided with a switching number, one
interface toward an uplink node (apart from gateways, which have no
uplink node in the link), a number of interfaces toward peer nodes
and a number of interfaces toward downlink nodes. Each interface in a
node is identified by the switching number of the neighboring node
seen from that interface. The uplink node's switching number is
always a prefix of the node's switching number. In other words, a set
of nodes sharing a same uplink node has a switching number beginning
with the same prefix, which is the uplink node's switching number.
Figure 3 shows a model of node with consistent numeration of the
switching number and the interfaces:
|| interface
---- 010
_______||______
| |
interface | | interface
01011__ | __| switching |__ | __ 01100
-- | --| number |-- | --
| | | |
| 01001 |
| |
|_______________|
interface || || || interface
0100110 ---- ---- ---- 0100100
|| || ||
interface
0100101
Fig. 3 - Switching node model
Inzerilli [Page 22]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Some switching nodes could not have all possible interfaces. For
example, in a tree topology no nodes have interfaces to peer nodes.
In addition, gateways are particular nodes without the uplink
interface, as we said before.
The routing algorithm in a SIMPLE link requires that each switching
node has its switching number and interfaces consistently configured.
Routing inside the distribution system is performed using local
information on switching number and interfaces independently of the
size of the link, the number of hierarchical levels, the number of
mobile nodes actually registered to the link and their exact
location. However, the global information on the number of gateways
(NUM_GT) in the link must be present in each node for the correct
operation of the switching algorithm.
All switching nodes implement a scalable auto-routing algorithm,
using local information on their switching number and interfaces.
However, APs are the only nodes having knowledge of the mobile nodes
registered to the link, which is contained in special distributed
routing tables, which are used in combination with the auto-routing
algorithm. These are called Routing Registers (RRs). RRs form a set
of fixed-size single-lookup distributed databases, where routing
information is stored with no duplications. As they are fixed-size
and single-lookup, the time needed for a lookup is constant and
independent of the table size. RRs are looked up on a packet arrival
only when the packet's destination LA have a prefix equal to the AP's
APN. This is done either to intercept signaling message destined to
the AP or to check that the destination mobile node is being served
in the cell before transmitting the packet or to buffer copies of
packets or to divert packets to another AP (see section 4.2.1).
All nodes in the distribution system, apart from APs, treat signaling
messages in the same way as data packets. While APs use signaling
messages to update their RR and perform data buffering and
forwarding, the other switching nodes just relay packets from an AP
or a gateway to another AP or gateway on the basis of their
destination LA field only, without processing of control information
in the packet header. Routing in the distribution system is
performed exploiting the auto-routing content of LAs in a SIMPLE link
consistently numbered (figure 2,3). A SIMPLE link is such if
- all the downlink nodes from a node have their switching number of the
same length and begins with a same prefix, which is correspondent to
the uplink node's switching number;
- peer nodes (those other than downlink nodes or the uplink node) have
switching numbers distinct and of the same length as each node's
switching number.
Inzerilli [Page 23]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
In such a link, each node in the distribution system is locally
configured with its own switching number and with its neighboring
link nodes' and with the global information on the number of gateways
on the link (NUM_GT). In addition, switching nodes are provided with a
two-byte binary mask of k initial consecutive ones followed by 16-k
zeros, the node's mask (N_MASK), where k is the length of the node's
switching number. In addition, the downlink switching numbers' length
n is provided. This parameter is equal to 16 in case the switching
number is an access point.
Neighboring nodes' switching numbers are needed for each switching
node to configure each switching node's interfaces. The data
structures were interfaces are specified are:
- the downlink node interface list
- the peer node interface list
with the following format:
[ index, interface, MAC address]
Each entry of these lists associates an index to a peer or downlink
neighboring node. When a packet with a destination LA not smaller
than the number of gateways on the link (NUM_GT) arrives at a
switching node, the packet's destination LA is right-shifted of 16-k
bits to obtain an index to compare with the node's switching number.
a If the index matches the node's switching number, a the packet's
destination LA is put in AND with the complement of the N_MASK and
right-shifted of 16-n bits to obtain another index. This new index
is then used to look up the downlink list for an output interface
to send the packet.
b If, on the contrary, the index does not match the switching number of
the node, the peer node interface list (if not empty) is looked up
using the index as a key. If a match is found the packet is sent to
the correspondent output interface. If the entry is not found, the
packet is relayed to the uplink interface.
When, instead, a packet with a destination LA smaller than the number
of gateways on the link (NUM_GT) arrives at a switching node
c the packet is relayed to the uplink node if the switching node
is not a gateway
d if the switching node is a gateway and the packet carries its SLA as
destination LA, it is intercepted, otherwise, it is relayed
Inzerilli [Page 24]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
to the gateway having its SLA corresponding to the packet's
If the actions described above are applied locally in each switching
node, the complete end-to-end SIMPLE routing algorithm then proceeds
following the following rules:
1 A SIMPLE packet with a destination LA which is grater than or equal
to NUM_GT, originated in a gateway, is relayed downlink hop-by-hop,
each node having its switching number equal to the prefix of the
destination LA field in the packet header.
2 A SIMPLE packet with a destination LA which is smaller than NUM_GT,
originated in a gateway, is sent towards the gateway having its SLA
equal to the packet's destination LAs.
3 A SIMPLE packet with a destination LA which is grater than or equal
to NUM_GT, originated in a mobile node, is relayed uplink till one
of the following events occurs.
3.1 a node with a direct link to another peer node having its
switching number equal to the prefix of the destination LA
field in the packet header is reached; the packet is then
relayed to the peer node and, afterwards, the packet will be
relayed downlink till the destination node as specified in
rule 1.
3.2 a node having its switching number equal to the prefix of
the destination LA field in the packet header is reached and,
afterwards, the packet will be relayed downlink till the
destination node as specified in rule 1.
4 A SIMPLE packet with a destination LA which is smaller than NUM_GT,
originated in a mobile node, is sent uplink till a gateway is
reached. The packet will be then sent to the destination gateway
having its SLA coinciding with the packet's destination LA.
.fi
4.2. Access Point model
Access points represent the core of the SIMPLE protocol. Unlike the
other switching nodes, which need to be aware only of their switching
number and of their neighboring link nodes' together with the global
information of the number of gateways on the link (NUM_GT), access
points provide a set of distributed databases where routing
information is contained. These are called Routing Registers (RRs)
and are used to keep track of all the mobile nodes registered to the
link and of their exact location.
A peculiarity of SIMPLE is that however large a link is, APs are the
only nodes that process and generate signaling, whose load on a
Inzerilli [Page 25]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
single AP is independent of the size of the link. All the other nodes
are passive forwarder of packets and do not distinguish signaling
packets from data packet (IP datagrams or ARP packets encapsulated in
SIMPLE packets).
The main functions of APs are: broadcasting information about the
link and the serving AP itself, routing packets and handling link-
Layer registrations, state refreshing, location updates and
handovers. Some parameters have to be configured in each access point
to make these procedures possible (apart from what is present in each
switching node for implementing the auto-routing algorithm), which
are:
- the link identifier, which must be the same for all APs of the link
and can correspond to an IP subnet prefix of the link; this is used
by mobile nodes to discover if they are in their home link or in a
foreign link when they switch on and to detect link changes after a
movement to a new cell while switched on;
- the APN, which is used by mobile nodes in their home link to
discover if they are in their reserved cell when they switch on and
to detect changes of cell while switched on;
- the Advertisement message interarrival time (ADV_TIME), which
has to be the same for all APs in a same link, to enable mobile
nodes to detect loss of connectivity to the link after a long time
without receiving Advertisement messages from an AP;
- a MAX_REG_TIME parameter, which corresponds to the maximum time a
mobile node's registration state can last without being refreshed;
- a MAX_DEF_TIME parameter, which corresponds to the maximum time a
mobile node's default state can last without being refreshed;
- a REFR_REG_TIME parameter, which is the time that has to elapse
between two consecutive Registration Refresh messages;
- at least one SLA of a foreign agent (only in IPv4 links) to which
foreign IPv4 mobile nodes will have to register;
4.2.1. Routing Registers (RRs)
Each AP has a routing table, which contains as much entries as the
number of CLAs that can be assigned in the cell. This table is
referred to as Routing Register (RR). If an AP has its APN k bits
long, it can grant access to the cell to up to 2**(16-k) mobile
nodes. In fact, each CLA that is assigned in that cell is a 16-bit
string with a prefix of k bits correspondent to the APN and a suffix
of 16-k bit which can be associated to a particular mobile node in
the cell, the Local Mobile node Identifier (LMI).
Inzerilli [Page 26]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
A RR is a fixed-size table with 16-k entries, each of which relevant
to a CLA, either assigned to a mobile node registered in the cell or
available for requesting mobile nodes. Each entry is also indexed by
an LMI as all CLAs of the cell share the same prefix (APN) but have
different suffix, the LMI.
APs use RRs to modify the routing algorithm explained in section 4.1,
as regards to point a in particular. When a SIMPLE packet arrives at
an AP, if this has a destination LA beginning with the AP's APN, the
LMI is extracted and used as an index for a RR lookup before trying
to send the packet downlink. This is needed either for applying a
two-step routing algorithm to an address resolution message, or for
intercepting signaling, or for intercepting data to buffer or to
forward during handovers, or finally to assure that a data packet to
relay into the cell is destined to a mobile node effectively
registered to the AP, which otherwise has to be dropped.
An entry of a RR has the following format:
[Available-CLA bit, Handover-in-progress bit, remote mobile node's
CLA, mobile node's new CLA, registration state timer, default state
timer].
The Available-CLA bit is set when the correspondent LMI (and,
consequently, the associated CLA) has been assigned to a mobile node
in the cell. This bit when set corresponds to a soft state that is
created after a successful link-layer registration of a mobile node.
A creation of a registration state triggers the correspondent
registration state timer in the same entry. A mobile node attached to
an AP must regularly refresh its registration state with suitable
signaling before its expiration, otherwise, it is canceled by the
link and the correspondent CLA becomes available for a new mobile
node.
The Handover-in-progress bit is set at conclusion of a handover or
after a buffering request by the mobile node and it is used together
with the Available-CLA bit and the registration state timer to
implement a handover strategy or a simple error recovery technique
(see section 5.9). The two bits together with the registration state
timer can be used to store up to four types of states, to handle
registrations, error recovery and handovers.
Forwarding of packets from the old to the new AP at conclusion of a
handoff can be performed by storing the mobile node's new CLA in the
correspondent field of the entry pointed by the mobile node's old CLA
in its old cell. A forwarding state is then created. This information
allows implementing a handover strategy to improve performances of
handovers. We make a distinction between a handover and a simple
Inzerilli [Page 27]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
location update. The latter involves idle mobile nodes' movements to
a new cell that need just to update their location in order to keep
themselves reachable. The former applies to active (sending or
receiving packets) mobile nodes, which needs the link to take some
measures to minimize packet loss and latencies. Forwarding states are
made soft to render the handover procedure more robust. They are
left in place till the expiration of their relevant timer and cannot
be refreshed. We will deal with handovers in section 5.9.
The remote mobile node's CLA field contains values of default states.
A default state (or location state) is used to forward SIMPLE packets
to a mobile node current location when its CLA is not known at the
sender node. Default states are looked up to implement two-step
routing for transporting address resolution messages (ARP ([9]) or ND
([7])). Instead of broadcasting these messages to the whole link as
it would be expected in a classical LAN, a single packet is first
sent to the destination mobile node's default AP, where the
correspondent default state, containing the destination mobile node's
CLA, is stored. The packet is then diverted from the default AP to
the destination mobile node's CLA.
The steps of the algorithm for address resolution are the following:
1 An Internet node on sending an IP datagram would check its cache to
resolve an IP address into a SIMPLE CLA.
1.1 If the needed entry is found, the IP datagram is encapsulated
in a SIMPLE packet and sent directly to the destination mobile
node.
1.1 Otherwise, one message for address resolution (ARP or ND) is
created and encapsulated in a SIMPLE packet setting a special
flag D in the packet header (see appendix A)and sent to the
default cell using the last two bytes of the mobile node's IP
address as the packet's destination LA and. This always
corresponds to the mobile node's Default Link-layer Address
(DLA), which is a pointer to the mobile node's default state.
1.2 The packet will reach the mobile node's default cell and
recognized as carrying a destination LA of a CLA that can be
assigned in the cell by its prefix (see section 4.1 point a).
The D flag set will tell the AP, the destination LA field
contain a DLA. The LMI extracted by the packet's destination LA
will be used to retrieve the remote mobile node's CLA value in
the relevant entry. The retrieve LA is the mobile node's CLA.
This will overwrite the packet destination LA, the D flag set
to 0 and the packet sent again, carrying the address resolution
request to destination.
1.3 The address resolution request will trigger a response message
(ARP or ND) on its arrival at the mobile node.
1.4 On the arrival of the response, the pending IP datagram will be
Inzerilli [Page 28]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
sent to the mobile node
A DLA is a pointer to a default state. The prefix of this pointer is
an APN identifying a mobile node's default cell, where the default
state is stored, the remaining suffix is an LMI pointing to the entry
of the RR in the mobile node's default cell where the default state
is stored. A mobile node, while moving in a SIMPLE link, will change
its CLA but will keep its DLA (always correspondent to the last two
bytes of its IP address) and will regularly update its current
location (CLA) in its default state. The double use of a DLA and a
CLA allows a mobile node to roam in a link and change interface (CLA)
and keeping its IP address all the time it remains registered to it.
A default state is soft. When a default state is created after a
successful link-layer registration of a mobile node, the
correspondent timer is triggered and the default state has to be
regularly refreshed. If the timer expires the correspondent default
state is canceled. It is the current AP where the mobile node is
attached to which will generate suitable signaling to regularly
refresh the remote mobile node's default state until the mobile node
leaves the cell. Location Refresh messages are regularly issued by
the AP a mobile node is currently attached to all the time its
registration state is kept alive.
The CLA and the DLA of a mobile node can sometimes coincide. This is
a preferable situation because it avoids propagating refreshing
messages for default states and two-step routing to deliver address
resolution messages. This condition, however, cannot be always
guaranteed, especially for fast-moving mobile nodes. This is because
a DLA is assigned once for all when a mobile nodes registers to a
link and is kept all the time it remains in the link, while the CLA
is changed each time it moves to a new cell.
There is a parameter that needs configuring in each AP to enable
utilization of RRs, which is the Reserved Local mobile node
Identifier (RESV_LMI). The RESV_LMI gives the number of reserved LAs
in the AP. In fact, in order to reduce admission failures to a link
during a link- layer registration or a change of cell, because all
the available CLA have already been assigned, some LAs are kept
reserved for particular mobile nodes in each AP. More precisely, all
the reserved LAs (RLAs) are assigned the bit strings from 0 to
(RESV_LMI-1). As a consequence, each RR of an AP is logically
organized in two parts. The first RESV_LMI entries are reserved for
particular mobile nodes, the other 2**(16-k)-RESV_LMI entries can be
assigned to any mobile node who requested one of them dynamically.
A cell where a mobile node holds a Reserved LA is said reserved cell
with respect to that mobile node. A mobile node must have at least a
Inzerilli [Page 29]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Reserved cell in its home link and as much Reserved LAs as the number
of its IP home addresses in its reserved cells. A Reserved LA is
always given by the last two bytes of a home address. When a mobile
node registers to its home link it must be always given a DLA
correspondent to its Reserved LA. In addition, when a mobile node
enters its Reserved cell (both in case of link-layer registration or
after a movement to a new cell) in its home link it cannot be
rejected and has to be assigned a CLA equal to its Reserved LA as
well. When the mobile node registers in its home link it must be
given a DLA equal to its RLA, wherever it enters it. The presence of
Reserved LAs is necessary not only to reduce admission failures.
Reserved LAs are also needed to allow correct operation of SIMPLE in
home links. In fact, here mobility at the IP level is not provided
and IP datagrams have to reach a mobile node only through its IP home
address. If the provisions above are respected, the address
resolution algorithm described above operates correctly in all home
links.
In a IPv4 link RRs have a different format. We will consider only the
case in which a foreign agent is used and no co-located care-of
addresses are assigned, as it is the typical case. All the entries
relevant to reserved CLAs remain the same:
[Available-CLA bit, Handover-in-progress bit, remote mobile node's
CLA, mobile node's new CLA, registration state timer, default state
timer].
On the contrary, the entries relevant to dynamic CLAs have the
following format:
[Available-CLA bit, Handover-in-progress bit, mobile node's new CLA
registration state timer].
In fact, default states for foreign mobile nodes would not be of any
use if placed in APs. This is because the IP address used by a mobile
node in a foreign link (for link-layer routing) is the IP home
address. So an easy mechanism for deriving a DLA from the mobile
node's IP address cannot be exploited.
However, as all traffic toward a foreign mobile node flows through
the foreign agent it is registered to, default states can be stored
here. So, a table for address resolution will be used by the foreign
agent and will store default states. This, however, is called
Visitors Address Resolution Table have a slightly different format:
[ mobile node's IP home address, mobile node's CLA, CLA timer]
Inzerilli [Page 30]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
4.2.2. Access Point operation
Each AP point uses its RR to route data packets and to process and
generate SIMPLE specific signaling.
4.2.2.1. Access Point signaling
An AP processes and generates the following SIMPLE specific
signaling:
1 It broadcasts Advertisement messages, which convey information on
the link and the specific cell they are serving. This includes:
- the link identifier to help the mobile node understand whether
it is in its home link or not and, consequently, to trigger a
suitable Mobile IP or Mobile IPv6 registration or deregistration
when a change of link identifier is detected by the mobile node
after a movement to a new cell;
- its APN, which the mobile node needs to understand if it is in
its reserved cell of its home link and to detect changes of cell;
- an interarrival-time parameter for Advertisement messages
(ADV_TIME), which can be used by the mobile node to initialize a
timer at each Advertisement arrival in order to detect loss of
connectivity with the link (Advertisement messages could be
solicited by mobile nodes on switching on or after the timer for
Advertisement messages expires);
- a REFR_REG_TIME parameter, which the mobile node will use to set
the frequency of Registration Refresh message generation.
2 It processes registration requests from new mobile nodes and grants
or denies them access to the link. A successful link-layer
registration has to assign a unique CLA (among all those already
assigned in the cell) and a unique DLA (among all those already
assigned in the link). In order to assign a CLA does an AP first
need to look up its local RR for an available CLA (scanning the RR
and find an Available-CLA bit not set yet) and activate the
relevant registration state (setting this Available-CLA bit). In
order to assign a DLA can it use an LA of the cell which is not
being used as a DLA by any mobile node in the link (this is
signaled by a default state timer null). It can also query a
centralized database, a set of distributed databases or a recursive
algorithm for DLA research. We will discuss all these alternatives
section 5.3.
3 It generates and processes refreshing messages for default states
all the time the correspondent mobile node remains registered to
the cell.
Inzerilli [Page 31]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
4 It processes and generates location update messages to update
default states when and idle mobile node changes cell and
participates to the exchange of signaling and data buffering and
forwarding during handovers.
5 APs have also to process proxy ARP messages and ND messages, which
are not broadcast in a SIMPLE link to enable the operation of home
agents (see section 6.1).
4.2.2.2. AP switching algorithm
An AP routes all packets in the same way as any other switching node
in the distribution system except for those carrying a destination LA
prefix which matches the AP's APN. When this event occurs (section
4.1 point a) the RR is looked up using the LMI extracted from the
packet's destination LA as a key. There are then two possibilities:
- the special flag D in the packet header is set (see appendix A and
section 4.2.1): this means that the two-step routing algorithm has
to be applied, as the sender of the packet didn't know the
destination mobile node's CLA and used its DLA to discover it,
- the special flag D is not set: the packet's destination LA is the
mobile node's CLA the sender had in its cache; there are then four
cases depending on the state associated to the entry pointed by the
packet's destination LA. Each of such states is identified by a
code assigned to the AH bits.
The following pseudo code illustrates the complete forwarding
algorithm of an access point receiving a data packet which matches
the APN with the prefix of its destination LA. It also considers a
possible handover or error recovery technique taking place (see
section 5.6.1). Handovers and error recovery exploits buffering and
forwarding of data.
When a data packet (the SIMPLE header will begin with the 000 prefix
(see appendix A)arrives at an AP and has the prefix of its
destination LA coinciding with the AP's APN, the D flag is checked:
1 if the D flag is set, the LMI of the packet's destination LA is
used as an index to look up the RR and retrieve the remote mobile
node's CLA value; the packet's destination LA is then overwritten
with this value and the D flag set to 0; if the prefix of the
packet's new destination LA matches the APN, rule 2 is applied,
otherwise, the auto-routing algorithm is used to send the packet
uplink or to a peer neighboring node;
Inzerilli [Page 32]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
2 if the D flag is not set, the LMI of the packet's destination LA
is used as a key to look up the RR and check the AH bits,
2.1 if these are set to 10, the packet is sent to the downlink
interface after looking up the downlink node interface
list.
2.1 if these are set to 00, the packet is dropped.
2.1 if these are set to 11, the packet is sent to the downlink
interface after looking up the downlink node interface
list and a copy of it is buffered.
2.1 if these are set to 01, the mobile node's new CLA value is
read and used to overwrite the packet destination LA and the
auto- routing algorithm is used to send the packet uplink or to
a peer neighboring node.
Note that sometimes a mobile node's default state is contained in its
current cell. In this case rule 1 is followed by rule 2 and it will
not be necessary to send the packet to another AP to complete the
two-step algorithm.
Steps 2.1 when the AH bits are set to 11 or 01 are associated to
error recovery and handovers (see section 5.6).
4.3. Mobile node model
A mobile node is an Internet node, in other words is provided with an
IP entity. It then creates SIMPLE packets adding a header to IP
datagrams when they need to be sent to a neighboring Internet node,
decapsulates SIMPLE packets and pass them to the destination IP
entity on their arrival.
IP processing is out of the scope of this section if not relatively
to the interfacing aspects with SIMPLE only. As regards to the SIMPLE
level capabilities, a mobile node has to be provided with signaling
and data transporting services, first of all, to request access to
the link and then to send and receive SIMPLE packets. In addition, it
should be able to change AP both in idle state and in active state
without loosing connectivity and reducing packet loss and delay at
the most during a movement to another cell.
To render the above feature possible to realize, a mobile node should
be configured with two parameters:
- a Reserved LA (RLA)
- a home link identifier
Inzerilli [Page 33]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Alternatively the two parameters can be calculated, as the RLA could
be derived from the mobile node's home IP address and the link
identifier could be made correspondent to the subnet prefix of the
mobile node's IP home address.
In addition, a couple of timers are needed:
- an Advertisement message timer
- a registration refresh timer
As a first Advertisement message from an AP is received, the mobile
node should store the current APN and the current link identifier. It
should also store the Advertisement message interarrival time
ADV_TIME, the REFR_REG_TIME parameter and initialize the
correspondent timers.
The mobile node will then try to register to the link. If the link-
layer registration is successful a CLA and a DLA have to be stored in
the mobile node. In the meanwhile the mobile node should constantly
listen to Advertisement messages in order to detect changes of cell
or of link, in which cases new values for CLA or CLA plus DLA have to
be requested respectively and stored together with the new values for
the current link identifier, APN, ADV_TIME, REFR_REG_TIME and the
timers reinitialized to the new values.
A mobile node can derive the APN of its Reserved cell from its
Reserved LA. More precisely, as the length of APNs is not fixed a
priori, but can be different from AP to AP, a mobile node entering a
cell has to listen to Advertisement messages broadcast by the AP.
- If the advertised link identifier is the same of its home link
identifier, it means the mobile node has entered its home link.
- It can then compare the advertised APN with the first bits of
its Reserved LA and understand if it is in its dedicated cell.
- If so, it can then send a registration request to the serving
access point (see section 5.2) and immediately set both its DLA
and CLA to its Reserved LA without waiting for a response message
from the AP.
A mobile node has to be provided with another couple of constants
that Are used to set buffering and forwarding state timers during
handovers and error recovery:
a) FWD_TIME, if implementing a forwarding strategy only
b) BUFF_TIME and FWD_TIME, if implementing a buffering and forwarding
strategy
Inzerilli [Page 34]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
We will examine the two techniques in section 5.6.1.
4.3.1. Mobile node operation
4.3.1.1. Mobile node signaling
Each mobile node uses the pre-configured constants and the CLA and
DLA dynamically acquired to register to a link to send and receive
data packets and to move from cell to cell inside a SIMPLE link. To
make this possible it is necessary a mobile node processes and
generates the following SIMPLE specific signaling:
- It listens to Advertisement messages conveying information on the
link and the specific cell. These include the number of gateways on
the link to derive the set of SLAs, the link identifier to help the
mobile node understand whether or not it is in its home link and to
trigger a suitable Mobile IP or Mobile IPv6 registration or
deregistration when a change of link identifier is detected. While
it listens it also has to store the Advertisement interarrival
time, ADV_TIME, which is needed to detect loss of connectivity with
the link, and the REFR_REG_TIME, which regulates the mobile node's
Registration Refresh message generation frequency.
- It has to send registration request messages, once understood where
it is and optionally set immediately its DLA and/or CLA to its
Reserved LA, when it understands that it has entered its Reserved
cell or its home link.
- It processes registration responses from the serving AP and sets
its CLA and DLA if the link-layer registration accomplishes
successfully.
- It generates refreshing messages for registration states to assure
the serving AP that it is still present in the cell.
- It generates location update messages to update registration states
when it is idle and changes cell and exchanges signaling massages
with the old and new AP to request data buffering and forwarding
during handovers or simply to request data buffering during period
of low-quality communication.
Inzerilli [Page 35]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
4.3.1.2. Reception and transmission of data
A mobile node uses its single uplink interface with the AP to send
and receive data. So, no particular switching capability is needed in
the mobile node.
Its only task to accomplish on a data packet reception is to assure
that it is really destined to it, checking the packet's destination
LA, which must correspond to its CLA, decapsulate the packet and send
it to the IP layer. If the check is not passed, the packet is
discarded.
On transmission, an IP datagram has to be encapsulated in a SIMPLE
packet using a CLA as the packet's destination LA if the next IP hop
is another mobile node. If the destination node is a gateway, its SLA
has to be retrieved. CLA and SLA bindings with IP addresses are
contained in the mobile node's address resolution cache.
When the destination IP node is not located in the link the packet
can be sent to the default gateway. The default gateway can be
assigned the SLA equal to 0. This guarantees that if a gateway exist
on the link, the Packet will be certainly sent to a gateway. Instead,
when the destination node is a host on the link, its CLA will be
looked for in the cache. If this is found the packet will be sent,
otherwise, the address resolution algorithm with the two-step routing
will take place. The SLAs of a specific gateway or a mobile router
can be discovered with the same mechanism (see also section 4.2.1).
When the destination mobile node's CLA is not available , an address
resolution request message is generated (ARP for IPv4 or ND for IPv6)
and encapsulated in a SIMPLE packet and the data packet is put in a
pending state, waiting for the node's CLA to be communicated. The
node's DLA (last two bytes of the mobile node's IP address used in
the link) has to be used as the encapsulated address resolution
message's destination LA, and the D flag must be set to signal that a
two-step algorithm has to be applied. The destination LA set to the
mobile node's DLA will make sure the packet reaches the mobile node's
default cell, which has the mobile node's CLA stored in its RR. Once
here, the D flag set will guarantee that the packet is relayed again
using the mobile node's CLA. The signaling message will arrive at
destination triggering a response, which will be sent using directly
the sending mobile node's CLA. As the response reaches the sending
node, the pending data packet will be sent.
When it is a gateway's SLA not available, the same action as before
will be taken. So an address resolution request will be encapsulated
Inzerilli [Page 36]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
in a SIMPLE packet, the destination LA will be set to the last-two
byte address of the gateway's IP address, the D flag will be set and
the packet will be sent. The packet will reach the gateway directly.
Here, the D flag will be ignored and the packet recognized as
destined to the gateway, which will send a reply to the sending
mobile node. So, it not necessary that a mobile node be aware of
transmitting to a gateway or to a mobile node.
This routing mechanism is completely transparent to ARP or Neighbor
Discovery. Even if these messages are not repeatedly broadcast and
only A single packet is created, this will be correctly routed to the
destination mobile node's no matter how large the link is. It then
provides ARP and ND with a transparent and efficient service
independently of the link topology.
4.4. Gateway model
A gateway is a switching node provided with the IP layer and serves
as a point of ingress and exit to and from the Internet. It has
SIMPLE interfaces on the link to other gateways (peer nodes) in
multiple-access-gateway links and to other downlink nodes.
4.4.1. Reception and transmission of data
As an Internet node it has to send a receive IP datagrams. It is then
provided with a link-layer address, referred to as Static Link-layer
Address (SLA). When sending a datagram, it has to encapsulate it in a
SIMPLE packet retrieving the destination node's LA (neighboring
Internet node). If this is not available, it must be capable of
resolving the destination node's IP address into its link-layer
address with the same mechanism specified in section 4.3.1.2, before
sending the data. In addition, when receiving a packet it will check
if it carries its SLA as destination LA. If so, it will decapsulate
it and send it to the IP layer, otherwise, it will relay it to
another gateway or to a downlink node.
As a switching SIMPLE node, it has to perform the same actions as any
other switching node. It is then provided with a switching number,
and the other parameters necessary for performing the switching
algorithm explained in section 4.1. In addition, it must be capable
Inzerilli [Page 37]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
of sending packets to other gateways on the basis of their SLAs. This
is a facility that the auto-routing algorithm explained in section
4.1 does not specify. In fact, packet's carrying an SLA are relayed
uplink till a gateway is reached if originated by mobile nodes. Once
here, an output interface associated with the destination gateway's
SLA is needed. In addition if a packet is originated in a gateway
and it has to be sent to another gateway, the same issues arise. So,
besides the peer node interface list and the downlink interface list,
gateways has an additional static table, which is referred to as
gateway interface list, whose entries have the following format.
[destination SLA, interface, MAC address]
Unlike the other two, this table could contain non-local information.
This can happen if the gateways of a link are not connected with a
full mash topology. It is in fact, necessary that all gateway knows
to which output interface sending a packet for any other gateway. So,
if NUM_GT is number of gateways on a link each gateway interface list
of a gateway will have exactly one NUM_GT-1 entries. This will make
sure that a chain of forwarding entries from any gateway to any other
gateway of a same link will be present if a physical path is
available.
5. SIMPLE signaling procedures
In this section, the signaling procedures performed by SIMPLE are
described. They consist of the following: location discovery, link-
layer registration, DLA research, state refreshing, location update,
error recovery, handover.
1 The location discovery procedure allows a mobile node to discover
the link and the cell it has entered on switching on and on moving
to a new cell while powered on and gather useful information about
the link and the current cell.
2 The link-layer registration procedure is used by the mobile node to
request and obtain admission to a link through an AP. An AP will
reject a registration request if the registering mobile node has
not a Reserved LA in the cell and all the dynamic CLAs have already
been assigned. If, on the contrary, the procedure is successful the
mobile node can attach to the link and use the network for
intercell communications with other mobile nodes in the link. A
link-layer registration attempt terminates successfully if the
mobile nodes is returned a CLA to send and receive packets in the
Inzerilli [Page 38]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
cell and a DLA to render its current interface to the link (CLA)
obtainable through a two-step routing.
3 The DLA research procedure is used to find a unique DLA to assign
to foreign mobile nodes (mobile nodes which are not in their home
link) during a link-layer registration. This could be done either
having the serving AP querying a centralized database, a set of
distributed databases or using a recursive algorithm for DLA
research in which a DLA Request message is relayed from AP to AP
recursively till a lookup of a RR returns an available DLA.
4 The state refreshing procedure is needed to keep registration and
default states alive during the staying of a mobile node in a link.
While a mobile node is attached to an AP, it has to send
Registration Refreshing messages to the serving AP regularly. On a
Registration Refreshing message arrival, the AP will generate a
Location Refreshing message to keep the mobile node's remote
default state alive (unless mobile node's default state is
contained in the same RR as the mobile node's registration state).
As this procedure is likely to account for the majority of the
signaling that a mobile node has to generate (for fast-moving
mobile nodes location update procedure generate a large part of the
overall signaling from a mobile node as well), data sent by a
mobile node can be used to refresh the correspondent registration
state in the serving AP to save battery in the mobile node. In this
case Location Refreshing message will be triggered after a period
of continuous transmission of data.
5 The Location update procedure allows a mobile node moving to
another cell while idle to update its remote default state with its
new location (CLA). The procedure consists of a couple of messages
in general. With a first message a mobile node registers to the new
AP. The new serving AP will then send another message to the mobile
node's default cell to update the mobile node's default state. If
the mobile node's new cell corresponds to the mobile node's default
cell the second signaling message is obviously not needed. If the
mobile node's is being served in a foreign IPv4 network, location
update message will be addressed to a foreign agent rather than a
default cell.
6 The error recovery procedure allows a mobile node to request a
buffering of a copy of each data packets transmitted during a
period of poor communication quality and it is requested by the
mobile node with a Buffering Request message. If a handover follows
a buffering request buffered packets can be forwarded to the new AP
on request to reduce packet loss. Otherwise after thee expiration
of a timer buffered packets are released in a single burst into the
channel. The applicability of a buffering strategy depends on the
type of wireless interface a mobile node is provided, which should
trigger a Buffer Request message when the communication quality
drops below a certain threshold.
7 The Handover procedure allows a mobile node moving to another cell
Inzerilli [Page 39]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
while communicating with other Internet nodes on the link to update
its remote default state with its new location (CLA) and avoid
losing packets or minimizing packet loss during the move. There are
alternative strategies which exploit a previous buffering for error
recovery and forwarding from the old to the new AP or directly
forwarding from the old AP.
All the procedures synthetically introduced above take place only
after the standard underlying technology cell selection, association
and re-association procedures. Mobile IP ([2]) or Mobile IPv6 ([3])
signaling follow SIMPLE signaling procedures when necessary.
Therefore, we distinguish three levels of connectivity corresponding
to three architectural levels (we the term connectivity we intend the
capability of exchanging packets between peer entities at a certain
architectural level):
- a wireless channel connectivity, which is provided by the
underlying wireless access technology by means of its standard
association and re-association processes; this could optionally
include connectivity to a core network through bridges;
- a link connectivity, which is provided by the intra-domain mobility
protocol interfacing with both the access part and the distribution
system; many different segments could be present in the
distribution system as well as in the access part of the same link;
the APs and the switching nodes of the intra-domain mobility
protocol will bridge all these segments so that they all appeared
as a single homogeneous link to the IP layer;
- an Internet connectivity, which is provided by Mobile IP or Mobile
Ipv6 in a foreign link and by IP or IPv6 in a home link;
5.1. Location discovery
When a mobile node switches on the first procedure it activates is
location discovery. This procedure will continue running in
background while the mobile node is switched on to enable the mobile
node to detect changes of location (interfaces or links). Location
discovery consists in listening to Advertisement messages that are
broadcast by APs and trigger either link-layer registration or
location update procedure or handovers (in SIMPLE handovers are
mobile-node-initiated). Below is a description of this procedure:
UPON SWITCHING ON
1 The mobile node initializes its Advertisement message timer to a
default value and listens to the channel for an Advertisement
message from an AP. If this timer expires without the mobile
Inzerilli [Page 40]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
node's receiving an Advertisement message, the mobile node issues a
solicitation Message carrying no parameters. Solicitations can be
repeated an undetermined number of times till an Advertisement
message is received, or a finite number of attempts can be made
before the mobile node switches off automatically.
2 An AP, receiving a solicitation message will reply broadcasting an
Advertisement message which carries a current link identifier, the
APN, the Advertisement message interarrival time and the default
gateway's SLA. Even if not solicited each AP will have to
broadcast Advertisement regularly.
3 The mobile node, on receiving an Advertisement message, will set
its Advertisement interarrival timer and the registration refresh
timer to the advertised values and store the default gateway's SLA.
It will then compare the advertised link identifier and APN with
its home link identifier and its reserved APN. One of the following
possibilities can occur:
CASE A) The advertised link identifier and APN coincide with the
mobile node's home link identifier and the mobile node's
reserved APN. The mobile node is then in its reserved cell
in its home link. A link-layer registration will be
triggered.
CASE B) The advertised link identifier coincides with the mobile
node's home link identifier but the advertised APN and the
mobile node's reserved APN do not match. The mobile node is
then in its home link but not in its reserved cell. A link-
layer registration will be triggered.
CASE C) The advertised link identifier does not coincide with the
mobile node's home link identifier. The mobile node is then
in a foreign link. A link-layer registration will be
triggered and a Mobile IP or Mobile IPv6 registration will
follow.
WHILE SWITCHED ON
Points 1 and 2 are the same as when the mobile node switches on.
Below are the following points when location discovery is performed
while the mobile node is on.
3 The mobile node, on receiving an Advertisement message, will set
its Advertisement interarrival timer and the registration refresh
timer to the advertised values and update its default gateway's
SLA, if necessary. It will then compare the advertised link
identifier and APN with its previously stored link identifier and
APN. One of the following possibilities can occur:
CASE A) The advertised link identifier and APN coincide with the
mobile node's previously stored link identifier and APN.
The mobile node is still in the same cell as before. Then,
nothing has to be done.
Inzerilli [Page 41]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
CASE B) The advertised link identifier coincides with the
previously stored link identifier but the advertised APN
and the previously stored APN do not match. The mobile node
has then moved to another cell of the same link. This
information can be optionally provided by the underlying
network to reduce times for handovers or location updates.
There are then two possibilities:
1) The mobile node is active (receiving or transmitting
data packets). A Handover procedure will be then
triggered
2) The mobile node is idle (neither receiving nor
transmitting data packets). A location update procedure
will be then triggered
CASE C) The advertised link identifier does not coincide with the
previously stored link identifier. The mobile node has then
moved to another link. One of the following possibilities
can occur:
1) The advertised link identifier and APN coincide with the
mobile node's home link identifier and the mobile node's
reserved APN. The mobile node is then in its reserved
cell in its home link. A link-layer registration will be
triggered. A Mobile IP or Mobile IPv6 deregistration
will follow.
2) The advertised link identifier coincides with the mobile
node's home link identifier but the advertised APN and
the mobile node's reserved APN do not match. The mobile
node is then in its home link but not in its reserved
cell. A link- layer registration will be triggered. A
Mobile IP or Mobile IPv6 deregistration will follow.
3) The advertised link identifier does not coincide with the
mobile node's home link identifier. The mobile node is
then in a foreign link. A link-layer registration will
be triggered and a Mobile IP or Mobile IPv6 registration
will follow.
5.2. Link-layer registration
Mobile node in its reserved cell in its home link: upon mobile node's
switching on CASE A), while the mobile node is switched on CASE C)1.
1 The mobile node has simply to inform the serving AP of its presence
through a Registration Request message containing its home link
identifier and its reserved LA. It can also immediately set its CLA
and DLA to its reserved LA (RLA).
2 The AP will recognize the mobile node as having a reserved access
Inzerilli [Page 42]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
to the cell on the request arrival, will create a registration
state for it in the entry pointed by the mobile node's reserved LA
(the Available-CLA bit in the RR will be set), will create a
default state for it in the same entry (the remote mobile node's
CLA field in the AP's RR will be filled with the assigned CLA and
the relevant timer triggered) and finally will send a Registration
Reply to the mobile node to inform it of the successful
registration.
3 The mobile node on the Registration Reply message arrival will
check the provided DLA and CLA. These must both coincide with the
mobile node's reserved LA. This consistency check could be used to
detect malfunctioning of the serving AP.
Mobile node in its home link but not in its reserved cell: upon
mobile node's switching on CASE B), while the mobile node is switched
on CASE C)2.
1 The mobile node tries to register with the serving AP and send a
Registration Request message containing its home link identifier
and its reserved LA. It can also immediately set its DLA to its
reserved LA (RLA).
2 The AP will recognize the mobile node as belonging to the link but
not having a reserved access to the cell and will look for a
dynamic CLA to assign to the mobile node. If no dynamic CLA is
available, the mobile node will be rejected through a Registration
Reply message. If, on the contrary, a dynamic CLA is still
available, this will be assigned to the mobile node, a registration
state for it will be created in the entry pointed by the selected
CLA(the Available-CLA bit in the RR will be set) and a Registration
Reply will be sent to the mobile node to inform it of the
successful registration. In addition, a Location update message
will be created and sent from the current AP to the mobile node's
reserved AP.
3 If the registration is successful the mobile node on the
Registration Reply message arrival will store the provided CLA and
check the provided DLA. This must coincide with the mobile node's
reserved LA. This consistency check could be used to detect
malfunctioning of the serving AP. If the registration is not
successful the mobile node can wait for a while to try again.
Either an undetermined number or a finite number of attempts before
the mobile node automatic switching-off can be made.
4 If the registration is successful and a Location update message
arrives at the mobile node's reserved cell, a default state will be
created for it in the entry pointed by the mobile node's reserved
LA (the remote mobile node's CLA field in the AP's RR will be
filled with the mobile node's reserved LA and the relevant timer
triggered).
Inzerilli [Page 43]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Mobile node in a foreign link: upon mobile node's switching on CASE
C), while the mobile node is switched on CASE C3.
1 The mobile node tries to register with the serving AP and send a
Registration Request message containing its home link identifier
and its reserved LA.
2 The AP will recognize the mobile node as not belonging to the link
and will look for a dynamic CLA to assign to the mobile node. If
no dynamic CLA is available, the mobile node will be rejected
through a Registration Reply message. If, on the contrary, a
dynamic CLA is still available, this will be assigned to the mobile
node, a registration state for it will be created in the entry
pointed by the selected CLA (the Available-CLA bit in the will be
set) and a DLA to assign to the mobile node will be looked for. In
a IPv4 link the DLA to assign must coincide with the static LA of a
foreign agent, pre-configured in the AP. In addition, the serving
AP will generate a Location update message and will send it to the
foreign agent. In a IPv6 link, there are a number of possibilities
for assigning a DLA.
As a first choice, the AP will try to assign a DLA equal to the CLA
just selected. This, however, cannot be done if this DLA has
already been assigned to another mobile node (a DLA must always
correspond to the last two bytes of the mobile node's IP address).
This can be verified by simply looking at the correspondent DLA
timer. If the timer is not null, it means that another mobile node
is using that DLA. If a DLA correspondent to the selected CLA can
be assigned, a default state is created in the entry pointed by the
just selected CLA (the remote mobile node's CLA field in the AP's
RR will be filled with the mobile node's CLA and the relevant timer
triggered).
On the contrary, if a DLA correspondent to the just selected CLA
cannot be assigned, as a second choice, the AP can scan its RR for
an entry with a null value of the default state timer among the
dynamic CLA only. If such an entry is found the correspondent DLA
is assigned and a default state is created in the entry pointed by
the just selected DLA(the remote mobile node's CLA field in the
AP's RR will be filled with the mobile node's CLA and the relevant
timer triggered).
If even this second choice attempt fails an algorithm for DLA
research (we will examine a set of possible algorithms in the next
section) will be triggered. This will always return a DLA not
already assigned in the link to a mobile node and will create a
default state for the mobile node in a remote AP. A Registration
Reply will be sent to the mobile node to inform it of the
successful registration.
3 if the registration is successful the mobile node on the
Registration Reply message arrival will store the provided CLA and
DLA. In a IPv6 link the DLA will be used to create a dynamic IP
Inzerilli [Page 44]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
address through IPv6 Stateless Address Autoconfiguration ([10]).
The DLA plus a six-octet prefix of zeros will become the interface
identifier the mobile node will use in that link. A subnet prefix
advertised in a ND ([7]) message plus the interface identifier will
become the IPv6 dynamic care-of address the mobile node will use in
the link. If the registration is not successful the mobile node
can wait for a while to try again. Either an undetermined number or
a finite number of attempts before the mobile node automatic
switching-off can be made.
4 In a IPv4 link after a successful registration a Location update
message will reach a foreign agent. This message will create a
default state in the foreign agent's Visitor Address Resolution
Table. This corresponds to a binding (mobile node's IP home
address, mobile node's CLA).
5.3. DLA research procedures
During a link-layer registration of a foreign mobile node (a mobile
node not in its home link) in a IPv6 link an available DLA which no
mobile nodes in the link is using has to be found and assigned to the
registering mobile node.
Unlike the cases of a mobile node in its home link or a mobile node
in a IPv4 foreign link provided with a foreign agent, where the
assignment of a DLA is straightforward (in the former case the DLA
coincide with the mobile node's pre-configured reserved LA, in the
latter with a static LA which is pre-configured in each access point
and belonging to a foreign agent), a separate procedure is needed to
discover an available DLA when all DLAs of the serving AP have
already been assigned.
An important consideration to make at this point is that when one of
such procedure is called it will always return an available DLA. This
is because a DLA procedure is activated by an AP only when a CLA has
been assigned but not a DLA. As CLAs and DLAs in a link are of the
same number, when such a procedure begins there will always be an
available DLA in the link to assign.
There are three possible options:
A)A centralized database recording all the DLAs already assigned in
the link can be used. This can be any Internet node on the link.
So, when an AP needing an available DLA could query this database
directly to conclude a link-layer registration. The following
exchange of messages will take place:
Inzerilli [Page 45]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
1 The access point will send a DLA Request message to the
centralized database carried the assigned CLA as parameter.
2 On the arrival of this message the node where the database is
stored will scan a table to find an available DLA. An available
DLA will be returned, the table updated consequently and a DLA
Reply carrying the selected DLA will be sent using the mobile
node's CLA as the message's destination LA.
3 On the arrival of this message the AP will be able to continue
the registration procedure and send a Registration Reply message
carrying the assigned CLA and DLA.
B)Another choice could be providing the link with a set of
distributed databases, one for each gateway. If n=2**k is the
number of DLAs that can be administered by a single gateway. All
APs looking for an available DLA and sharing the first k bits of
prefix in their APNs will query a same database as first choice,
identified by that prefix, which corresponds to its switching
number. If all DLAs in the first choice database have already been
assigned, the first choice database can forward the DLA request to
another gateway. DLA Requests can be forwarded recursively from a
gateway to another till an available DLA is found in a database.
DLA Reply can be then sent directly to the querying AP using the
registering mobile node's CLA as destination LA of the message.
C)Another option needs no additional database as it uses directly the
existing RRs in APs. The algorithm originates from these
considerations:
Consider the case of an IPv6 mobile node that successfully
registers to a foreign link, acquiring a DLA equal to the assigned
CLA and moving out of the cell after a while. If, later, another
foreign mobile node (we will call it the new-comer) registers in
the cell which was left by the old one and acquires the CLA that
the old mobile node used there as both its CLA and DLA, it will not
be able to use this LA as its DLA. This is because the old mobile
node is still using it as its DLA. A DLA must be unique for each
mobile node, otherwise, two mobile nodes in the link will share the
same IPv6 care-of address, obtained using the assigned DLA and IPv6
Stateless Address Autoconfiguration ([10]).
As a solution, one could think that the newcomer may use the value
of the old mobile node's CLA to assign to the new comer's DLA. The
result of this technique would be the same as if the new comer had
first registered in the old mobile node's current cell acquiring a
DLA and a CLA both equal to the old mobile node's CLA. Afterwards
both the new comer and the old mobile node would have swapped cell
and CLA simultaneously.
Inzerilli [Page 46]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Actually, the algorithm above has a bug. It does not take into
account the possibility that someone else could be using the old
mobile node's CLA as its DLA. We can call this mobile node old-old
mobile node. Assigning the old-old mobile node's CLA to the new
comer as its DLA could not be a solution as an old-old-old mobile
node could be using the old-old mobile node's CLA as its DLA. There
seem to be no strategy that solves the problem. Actually, this
technique could return a correct result if applied recursively,
each time checking if a mobile node's CLA is already used by
another mobile node as its DLA, till this is no longer true.
The DLA research algorithm then follows these steps:
1 A mobile node is assigned an available CLA, the correspondent
Available-CLA bit in the RR is set and, from now on, this is the
mobile node's CLA until it remains in the cell.
2 The default state timer field is then read. As this is not null,
the remote mobile node's CLA value of the same entry is
retrieved. A DLA Request packet is sent using the retrieved value
as destination LA. The message reaches the destination AP and the
entry of the RR pointed by the message's destination LA is looked
up.
2.1 The default state timer field is then read. As this is not
null, the remote mobile node's CLA value of the same entry is
retrieved. A DLA Request packet is sent using the retrieved
value as destination LA. The message reaches the destination AP
and the entry of the RR pointed by the message's destination LA
is looked up.
2.1.1 The default state timer field is then read. As this is not
null, the remote mobile node's CLA value of the same entry is
retrieved. A DLA Request packet is sent using the retrieved
value as destination LA. The message reaches the destination
AP and the entry of the RR pointed by the message's
destination LA is looked up.
...............................................................
2.1..............1 The default state timer field is then read. As
this is null, the remote mobile node's CLA field
is written with the registering mobile node's
CLA, the correspondent default state timer is
activated and a DLA Reply message carrying the
assigned DLA is returned to the registering
mobile node's current cell, using the
registering mobile node's CLA as destination LA.
It can be proven that this algorithm terminates in a finite number of
steps.
Inzerilli [Page 47]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
An improvement of this algorithm, which minimizes the number of
signaling messages, could use the chain of CLAs to point to RRs,
which are completely scanned for an available DLA before e new DLA
Request message is generated instead of limiting to checking the
pointed entries only. So, before sending the first DLA Request
message from the registering mobile node's current AP and each time a
subsequent RR is looked up, before sending a new DLA Request message
to a new AP, all the table is completely scanned beginning from the
pointed entry and if necessary the rest of the RR is read afterwards.
Only if no available DLA is found in the RR a new DLA Request message
is generated and sent along the chain of CLA. The RRs to scan are
selected using the chain of CLA because this measure gives the
guarantee that the algorithm terminates. RRs are scanned completely
to limit the number of access to new RRs and accelerate the
termination of the algorithm.
5.4. State Refreshing
While a mobile node moves within a link, its default and registration
states have to be regularly refreshed. If these soft states expire
(this happens after a MAX_REG_TIME and MAX_DEF_TIME interval without
refreshing messages) the mobile node is canceled from the link and
its CLA can be assigned to a new mobile node. If the mobile node was
visiting an IPv6 foreign link, its DLA and IPv6 dynamic care-of
address become available for a new mobile node. Soft states render
the protocol robust and are mandatory with wireless access. However,
They could be not necessary to grant access to stationary hosts, as a
consequence timers and state refreshing procedures could be removed
for such nodes. What follows in this section is then to consider
applicable to mobile nodes with a wireless interface in particular.
The procedure for refreshing registration and default states is the
following:
1 Every REFR_REG_TIME seconds a mobile node which is being served in
a cell sends a Registration Refresh message to the serving AP to
refresh its registration state. This message contains the mobile
node's DLA.
2 When the Registration Refresh message is received by the AP, the
mobile node's registration state is refreshed by reinitializing the
relevant registration state timer to MAX_REG_TIME. If the
MAX_REG_TIME is three times bigger than REFR_REG_TIME up to a
couple of Registration Refresh messages can be lost in the wireless
channel without disconnecting the mobile node from the link.
Inzerilli [Page 48]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
3 A Location Refresh message is then created by the AP using the
advertised DLA as the message's destination LA. This carries the
mobile node's CLA.
4 In the mobile node's home link or in a IPv6 foreign link the
message will arrive at the mobile node's default cell. The mobile
node's default state will be then refreshed by setting the relevant
default state timer to MAX_DEF_TIME. If the MAX_DEF_TIME is three
times bigger than REFR_REG_TIME up to a couple of Registration
Refresh messages can be lost in the wireless channel without
freeing the mobile node's DLA.
In an IPv4 foreign link the message will arrive at the foreign
Agent the mobile node is registered to. Here the Visitor Address
Resolution Table will be scanned using the mobile node's CLA as a
key. The mobile node's default state will be then refreshed by
setting the default state timer to MAX_DEF_TIME seconds.
5.5. Location update procedure
A location update can be much faster than a link-layer registration
as only a CLA but not a DLA has to be assigned. It can be either
activated by the location discovery procedure running in background
when a move to a new cell is detected or through an explicit feedback
from the underlying access technology. In the latter case a location
update can be faster.
The actions taken during this procedure are different in the three
cases of a mobile node entering its reserved cell, not entering its
reserved cell but moving in its home link, and moving in a foreign
link:
MOBILE NODE ENTERING ITS RESERVED CELL
1 The mobile node moving to the new cell sends a Location update
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA and the mobile node's DLA, to the new AP.
As the mobile node cannot be rejected from the link, its CLA can be
immediately set to its reserved LA, which must be the same as its
DLA. It can then wait for a confirmation in the following Location
Update Reply.
2 When the Location update message arrives at the new AP the mobile
node is recognized as having a reserved access in the cell. The
advertised reserved LA and the advertised DLA must be equal. This
consistency check can be used to detect mobile node's
malfunctioning. The new AP creates a registration state for the
Inzerilli [Page 49]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
mobile node in the entry pointed by the mobile node's reserved LA
and refreshes the mobile node's default state in the same entry. It
then sends a Location update Reply, carrying the mobile node's new
CLA.
3 When the mobile node receives the Location update Reply it check
the advertised new CLA, which must correspond to the mobile node's
reserved LA. This consistency check can be used to detect AP's
malfunctioning.
MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS HOME
LINK
1 The mobile node moving to the new cell sends a Location update
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA and the mobile node's DLA, to the new AP.
2 When the Location update message arrives at the new AP the mobile
node is recognized as belonging to the link but not having a
reserved access in the cell.
If no dynamic CLA is available for the mobile node, this is
rejected through a Location update Reply.
On the contrary, if an available CLA is found the relevant
registration state is created and a Location update reply, carrying
the mobile node's new CLA, is sent to inform the mobile node of the
successful location update. In addition, a Location update message
for the mobile node's default cell is sent to update its default
state. This will carry the new mobile node's CLA and its
destination LA will be the mobile node's DLA.
3 If the mobile node receives a successful Location Update Reply it
will store the advertised new CLA. If the registration is not
successful the mobile node can wait for a while to try again.
Either an undetermined number or a finite number of attempts before
the mobile node's automatic switching-off can be made.
4 If the location update is successful a location update message
carrying the mobile node's new CLA will arrive at the mobile node's
default cell and update the mobile node's default state.
MOBILE NODE MOVING IN A FOREIGN LINK
1 The mobile node moving to the new cell sends a Location update
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA and the mobile node's DLA, to the new AP.
2 When the Location update message arrives at the new AP the mobile
node is recognized as not belonging to the link. If no dynamic CLA
is available for the mobile node, this is rejected through a
Location update Reply. On the contrary, if an available CLA is
found the relevant registration state is created and a Location
update reply, carrying the mobile node's new CLA, is sent to inform
the mobile node of the successful location update. In a IPv6 link
Inzerilli [Page 50]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
the mobile node's default state could be stored in the new cell. In
this case the new AP updates it directly. Otherwise, a Location
update message is sent to the mobile node's default cell to update
its default state. This will carry the new mobile node's CLA and
its destination LA will be the mobile node's DLA. If the mobile
node is moving in a IPv4 link, a Location update message is sent to
the mobile node's foreign agent to update its default state in the
foreign agent's Visitor Address Resolution Table.
3 If the mobile node receives a successful Location Update Reply it
stores the advertised new CLA.
If the registration is not successful the mobile node can wait for
a while to try again. Either an undetermined number or a finite
number of attempts before the mobile node's automatic switching-off
can be made.
4 In a IPv6 link, if the location update is successful a Location
update message carrying the mobile node's new CLA will arrive at
the mobile node's default cell and update the mobile node's default
state.
In a IPv4 link, if the location update is successful a location
update message carrying the mobile node's new CLA will arrive at
the mobile node's foreign agent and update the mobile node's
default state in the foreign agent's Visitor Address Resolution
table.
5.6. Handovers and Error Recovery
SIMPLE makes a distinction between a simple location update, which
involves idle mobile nodes only, from a handover procedure, where
particular measures have to be taken to reduce packet loss and delay
during a move of an active mobile node to a new cell.
Different handover strategies can be used advantageously depending on
the characteristics of the wireless interface the mobile node is
provided with. In particular those technologies allowing a mobile
node to keep multiple associations with many APs simultaneously can
reach better performances. In the following section two alternative
approaches for handovers are described to consider both multiple-
association-capable mobile nodes and non-multiple-association-capable
mobile nodes.
In order to improve the performances of a handover with respect to a
simple location update some extra signaling is needed. In fact, when
a mobile node moves to a new cell while communicating with other
Internet nodes on the link, the mobile node should inform them of its
new CLA as soon as possible. Otherwise, packets will continue to be
Inzerilli [Page 51]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
sent to the old CLA and will be lost till the IP layer detects the
mobile node's unreachability.
In a IPv6 link a mobile node after a move can send an Unsolicited
Neighbor Discovery Advertisement message to each Internet node it is
communicating with. The same thing can be done with Gratuitous ARP
messages in a IPv4 link. We can substantially reduce packet loss
with this measure. However, some packets on the flight during the
mobile node's movement will not be routed correctly altogether. To
further reduce packet loss can a mobile node, after a movement,
create a forwarding state in the old AP which is used to divert all
packets for the mobile node which arrive at the old cell to the new
one.
This could be done by the new AP immediately after the assignment of
the new CLA by sending a Forwarding Request message to the old AP,
carrying the mobile node's new CLA, the mobile node's old CLA, a
forwarding time value (FWD_TIME) to initialize a timer to create a
forwarding state in the AP's RR.
The strategy presented above is the forwarding strategy.
Optionally, if the physical layer of the mobile node's wireless
interface, which monitors the quality of the signal in the channel,
can tell the upper layers that a re-association attempt will be made
soon, the mobile node can send a Buffering Request message to the old
AP before making the move in order to have a copy of each packet
relayed in the wireless channel for it buffered in the old AP and
waiting to be forwarded to the new mobile node's CLA on a Forward
Request arrival. This message carries a BUFF_TIME value to initialize
a buffering soft state in the old AP.
With this additional measure the handover uses a buffering and
forwarding strategy rather than a simple forwarding.
It can happen that a Buffering Request is not followed by a handover
because the degradation of the communication quality is only
transient. If this is the case at the expiration of the buffering
state, all buffered copies will be released in a single burst into
the wireless channel and the buffering state will be turned into a
registration state again. The buffering followed by the flushing of
packets will have served as an error recovery technique.
It is possible to express a buffering or a forwarding state for a
CLA, assigning a code to the Available-CLA and Handover-in-progress
bits in the entry pointed by the CLA. As a consequence we have the
following meaning for the two-bit codes:
Inzerilli [Page 52]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
AH | MEANING | ACTION
----|----------------------|---------------------------------------
00 | CLA not assigned | on a packet arrival throw away packet
| |
10 | registration state | on a packet arrival relay packet in
| | the wireless channel
11 | buffering state | on a packet arrival relay packet in
| | the wireless channel and store a copy
01 | forwarding state | on a packet arrival send packet to
| | the new CLA only
Tab. 1 - Routing Register state coding
5.6.1. Forwarding strategy for handovers
A handover with a forwarding strategy can be used in those mobile
nodes provided with a wireless interface which enables keeping
multiple associations with many APs at a time. It would proceed as
follows, considering the three cases of a mobile node entering its
reserved cell, not entering its reserved cell but moving in its home
link, and moving in a foreign link:
MOBILE NODE ENTERING ITS RESERVED CELL
1 The mobile node moving to the new cell sends a Handover Request
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA, the mobile node's DLA and the mobile
node's old CLA (that held in the old cell) to the new AP. This is
done while receiving from the old AP. As the mobile node cannot be
rejected from the cell, its CLA can be immediately set to its
reserved LA, which must be the same as its DLA. The mobile node can
then wait for a confirmation in a Handover Reply.
2 When the Handover Request message arrives at the new AP the mobile
node is recognized as having a reserved access in the cell. The
advertised reserved LA and the advertised DLA must be equal. This
consistency check can be used to detect mobile node's
malfunctioning. The new AP creates a registration state for the
mobile node in the entry pointed by the mobile node's reserved LA
and refreshes the mobile node's default state in the same entry. It
then sends a Handover Reply, carrying the mobile node's new CLA, to
the mobile node and a Forwarding Request to the mobile node's old
AP, which carries a FWD_TIME parameter and the mobile node's new
CLA and uses the mobile node's old CLA as destination LA.
3 When the mobile node receives the Handover Reply it checks the
Inzerilli [Page 53]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
advertised new CLA, which must correspond to the mobile node's
reserved LA. This consistency check can be used to detect AP's
malfunctioning. It then sends an unsolicited neighbor discovery
message (if it is in a IPv6 link) or a gratuitous ARP (if it is in
a IPv4 link) to all the Internet nodes on the link it is
communicating with.
4 When the Forwarding Request arrives at the old AP, a forwarding
state for the mobile node's old CLA is created. The entry of the RR
pointed by the mobile node's old CLA is set to the mobile node's
new CLA. The CLA timer and the Handover-in-progress bit and the
Available-CLA bit of the entry in the RR pointed by the mobile
node's old CLA are set to FWD_TIME, 1 and 0 respectively.
5 Each Internet node communicating with the mobile node will update
its cache on the unsolicited ND advertisement message or gratuitous
ARP arrival.
MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS HOME
LINK
1 The mobile node moving to the new cell sends a Handover Request
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA, the mobile node's DLA and the mobile
node's old CLA to the new AP. This is done while receiving from the
old AP.
2 When the Handover Request message arrives at the new AP the mobile
node is recognized as belonging to the link but not having a
reserved access in the cell. If no dynamic CLA is available for
the mobile node, this is rejected through a Handover Reply. On the
contrary, if an available CLA is found the relevant registration
state is created and a Handover Reply, carrying the mobile node's
new CLA, is sent to inform the mobile node of the successful
handover. In addition, a Location update message for the mobile
node default cell is sent to update its default state. This will
carry the new mobile node's CLA and its destination LA will be the
mobile node's DLA. In addition, a Forwarding Request is sent to the
mobile node's old AP, which carries a FWD_TIME parameter and the
mobile node's new CLA and uses the mobile node's old CLA as
destination LA.
3 If the mobile node receives a successful Handover Reply it will
store the advertised new CLA. It will then send an unsolicited
neighbor discovery message (if it is in a IPv6 link) or a
gratuitous ARP (if it is in a IPv4 link) to all the Internet nodes
on the link it is communicating with.
If the registration is not successful the mobile node can wait for
a while to try again. Either an undetermined number or a finite
number of attempts before the mobile node's automatic switching-off
can be made.
4 If the handover is successful a Handover Reply message, carrying
Inzerilli [Page 54]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
the mobile node's new CLA will arrive at the mobile node's default
cell and update the mobile node's default state.
5 If the handover is successful, when the Forwarding Request arrives at
the old AP, a forwarding state for the mobile node's old CLA is
created. The entry of the RR pointed by the mobile node's old CLA
is set to the mobile node's new CLA. The CLA timer, the
Handover-in- progress bit and the Available-CLA bit of the entry in
the RR pointed by the mobile node's old CLA are set to FWD_TIME, 1
and 0 respectively.
6 If the handover is successful, each Internet node communicating with
the mobile node will update its cache on the unsolicited ND
advertisement message or gratuitous ARP arrival.
MOBILE NODE MOVING IN A FOREIGN LINK
1 The mobile node moving to the new cell sends a Handover Request
message, carrying the mobile node's home link identifier, the
mobile node's reserved LA, the mobile node's DLA and the mobile
node's old CLA to the new AP. This is done while receiving from the
old AP.
2 When the Handover request message arrives at the new AP the mobile
node is recognized as not belonging to the link. If no dynamic CLA
is available for the mobile node, this is rejected through a
Handover Reply.
On the contrary, if an available CLA is found the relevant
registration state is created and a Handover reply, carrying the
mobile node's new CLA, is sent to inform the mobile node of the
successful handover.
In a IPv6 link the mobile node's default state could be stored in
the new cell. In this case, the new AP updates it directly.
Otherwise, a Location update message is sent to the mobile node's
default cell to update its default state. This will carry the new
mobile node's CLA and its destination LA will be the mobile node's
DLA.
If the mobile node is moving in a IPv4 foreign link, a Location
update message is sent to the mobile node's foreign agent to update
its default state in the foreign agent's Visitor Address Resolution
Table.
In addition, a Forwarding Request is sent to the mobile node's old
AP, which carries a FWD_TIME parameter and the mobile node's new
CLA and uses the mobile node's old CLA as destination LA.
3 If the mobile node receives a successful Handover Reply it stores
the advertised new CLA.
Inzerilli [Page 55]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
MN New AP Old AP Default AP Peer node
| | | | |
|(Home Link Identifier)| | | |
| (Reserved LA) | | | |
| (Default LA) | | | |
| (old Current LA) | | | |
|--------------------->| | | |
| | | | |
| | | | |
| (Current LA) | | | |
|<---------------------| (Current LA) | |
| |------------------------------>| |
| | | | |
| | (FWD_TIME) | | |
| | (Current LA) | | |
| |-------------->| | |
| | | | |
| (Unsolicited Neighbor Discovery) | |
|---------------------------------------------------------------->|
| | | | |
Fig. 4 - Handoff in a foreign link with successful registration
If the mobile node is in a IPv6 link, it will then send an
unsolicited neighbor discovery message to all the Internet nodes on
the link it is communicating with.
If the registration is not successful the mobile node can wait for
a while to try again. Either an undetermined number or a finite
number of attempts before the mobile node's automatic switching-off
can be made.
4 In a IPv6 link, if the location update is successful, a location
update message carrying the mobile node's new CLA will arrive at
the mobile node's default cell and update the mobile node's default
state. In a IPv4 link, if the location update is successful, a
location update message carrying the mobile node's new CLA will
arrive at the mobile node's foreign agent and update the mobile
node's default state in the foreign agent's Visitor Address
Resolution table.
5 If the handover is successful, when the Forwarding Request arrives at
the old AP, a forwarding state for the mobile node's old CLA is
created. The entry of the RR pointed by the mobile node's old CLA
is set to the mobile node's new CLA. The CLA timer, the
Handover-in- progress bit and the Available-CLA bit of the entry in
the RR pointed by the mobile node's old CLA are set to FWD_TIME, 1
and 0 respectively.
6 If the handover is successful, each Internet node communicating with
the mobile node will update its cache on the unsolicited ND
advertisement message (this is not done in IPv4 foreign links).
Inzerilli [Page 56]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
5.6.2. Buffering and forwarding strategy for handovers and error
recovery
A handover strategy with buffering and forwarding could be used in
those mobile nodes provided with a wireless interface which enables
keeping only a single association with an AP at a time. It exploits a
separate error recovery technique, which takes place immediately
before.
The signaling associated with the error recovery consists of a single
message which should be sent by the mobile node when communication
quality drops below a certain threshold and could not be followed by
a handover. The events associated with this procedure are the
following:
1 The mobile node is informed by the underlying access technology of
a drop in the communication quality. This could be ascribed to a
movement to a new cell or could be just a transient degradation of
the communication. In any case the mobile node sends a Buffering
Request to the serving AP, carrying a BUFF_TIME parameter.
2 On this message arrival the AP will turn the registration state
associated to the mobile node's CLA into a buffering state by
setting the Handover-in-progress bit and the CLA timer to 1 and
BUFF_TIME respectively. This will cause the AP to store a copy of
all subsequent packets which are relayed into the channel for the
mobile node till the buffering state is in place. Two cases are
then possible:
2.1 if a Forwarding Request messages arrives at the AP before the
expiration of the buffering state, all buffered packets will be
forwarded to the mobile node's new CLA together with all
subsequent packets arriving at the AP and for the mobile node
till the forwarding state is place.
2.1 If the buffering state expires before a Forwarding Request
reaches the AP, the buffered packets will be released into the
channel in a single burst and the buffering state will be
turned in a registration state.
A handover using a buffering and forwarding strategy will proceed
similarly as before with the only difference the a Forwarding request
arriving at the old AP will cause some buffered packets to be
forwarded to the new mobile node's CLA. Below are reported only the
differences with respect to the previous handover scheme, considering
again the three cases of a mobile node entering its reserved cell,
not entering its reserved cell but moving in its home link, and
moving in a foreign link:
Inzerilli [Page 57]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
MOBILE NODE ENTERING ITS RESERVED CELL
4 When the Forwarding Request arrives at the old AP, a forwarding
state for the mobile node's old CLA is created. The entry of the RR
pointed by the mobile node's old CLA is set to the mobile node's
new CLA. The CLA timer and the Available-CLA bit of the entry in
the RR pointed by the mobile node's old CLA are set to FWD_TIME
and 0 respectively. Any buffered packets destined to the mobile
node's old CLA will have its destination LA overwritten with the
mobile node's new CLA and sent. The old AP will have buffered
packets only if the Forwarding Request arrives before the
expiration of the buffering state.
EITHER MOBILE NODE NOT ENTERING ITS RESERVED CELL BUT MOVING IN ITS
HOME LINK OR MOBILE NODE MOVING IN A FOREIGN LINK
5 If the handover is successful, when the Forwarding Request arrives
at the old AP, a forwarding state for the mobile node's old CLA is
created. The entry of the RR pointed by the mobile node's old CLA
is set to the mobile node's new CLA. The CLA timer and the
Available-CLA bit of the entry in the RR pointed by the mobile
node's old CLA are set to FWD_TIME and 0 respectively. Any buffered
packets destined to the mobile node's old CLA will have its
destination LA overwritten with the mobile node's new CLA and sent.
. The old AP will have buffered packets only if the Forwarding
Request arrives before the expiration of the buffering state.
6. Mobile IPv6 and Mobile IP non-standard routers' operation
6.1. Operation of home agents in IPv4 and IPv6 links
Home agents are non-standard IP routers. They are used to forward IP
datagrams destined to a mobile node and arriving at its home link to
the mobile node current link when this is "away from home" through IP
tunneling. In other words, home agents enables mobile node roaming
out of their home link. They are fundamental devices for the
operation of both Mobile IP and Mobile IPv6. Home agents must be able
to intercept all datagrams destined to mobile nodes when these are
away from home. This is done by allowing home agents to work as
proxies ([7,12]) for them.
Inzerilli [Page 58]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
When a mobile node away from home registers to a home agent in its
home link through Mobile IP or Mobile IPv6, the home agent must be
able to store an address resolution entry (mobile node's IP home
address, home agent's link-layer address) in the caches of the nodes
on the mobile node's home link. This is done by broadcasting suitable
signaling messages to the whole link, repeatedly for reliability
reasons. In addition, each time a node on the link broadcasts a
request for the mobile node's link-layer address, the home agent will
reply for it providing the home agent's link-layer address. These
measures guarantee the home agent's intercepting all datagrams
destined to mobile node's and are implemented through gratuitous ARP
([13]) and proxy ARP ([12]) in IPv4 links, whereas, through Neighbor
Discovery ([7]) in IPv6 links.
SIMPLE links use default states to allow interception of datagrams by
home agents without broadcasting signaling messages and using
existing ARP or Neighbor Discovery signaling.
The following actions are taken in a SIMPLE link to allow a home
agent to intercept datagrams destined to a mobile node's registered
to it while this is away from home:
- On a remote mobile node's registration, a home agent will not
broadcast a gratuitous ARP message to the whole link but will send
a single SIMPLE Location Update message, carrying its static LA as
the mobile node's CLA, to the mobile node's default cell, using the
mobile node's DLA (last two bytes of its IP home address) as the
message's destination LA.
- The home agent will have to send Location Refresh messages to the
mobile node's default cell regularly all the time the mobile node's
mobility binding survives in the home agent binding cache. Each
refreshment message will be sent every REG_TIME seconds.
All nodes on the mobile node's home link when sending a datagram
destined to the mobile node whose CLA is not known will send a single
ARP or Neighbor Discovery request (no broadcast is needed) to the
mobile node's DLA, this will be intercepted in the mobile node's
default cell and diverted to the Mobile node's home agent, using the
home agent's static LA, stored in the default state as the packet's
new destination LA. The home agent will reply with a proxy ARP or
proxy Neighbor Discovery message.
6.2. Operation of foreign agents in IPv4 links
Foreign agents are non-standard IP routers used in Mobile IP. They
Inzerilli [Page 59]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
intercept packets for visiting mobile node's and delivers them to the
destination mobile nodes through link-layer mechanisms. In a SIMPLE
link all foreign agents have a Visitor Address Resolution Table where
SIMPLE default states are centralized. The entries of this table have
the following format:
[visiting mobile node's IP home address, mobile node's CLA]
They are created on foreign mobile node's registrations to the link
and need to be regularly refreshed through Location Refresh messages
by mobile nodes' current cells.
A SIMPLE link can have more than a foreign agent. When multiple
foreign agents are present in a SIMPLE link, APs have to be divided
into groups, and each group assigned to a foreign agent. A set of APs
sharing the same k-bit prefix in their APN could be assigned a same
foreign agent.
7. Considerations on SIMPLE
SIMPLE is a protocol that provides mobile nodes with intra-domain
mobility both in the home link and in foreign links, either IPv6 or
IPv4. It is then intended to enhance performances of fast-moving
mobile nodes during handovers, implementing local link-layer location
updates, and to reduce the impact of mobility signaling on the
internet by limiting it to the SIMPLE link. A couple of strategies
for facing intermittent connectivity during handovers, one of them
coupled with an error recovery technique, were discussed.
The forwarding strategy exploits multiple-association capability
which some wireless interfaces provides for mobile nodes. When such a
feature is not available, the forwarding strategy can be strengthen
with preventive buffering requests. Buffering request messages,
however, can be triggered only if a feedback from the underlying
access technology to SIMPLE is provided. The physical layer should
trigger a buffering request, each time the quality of the
transmission drops under a certain threshold before a re-association
with a new AP is made by the wireless interface. However,
communication degradation could be just momentary at some times and
could not correspond to a move to a new cell. In this case buffered
packets will be released into the wireless channel when their
buffering state expire. This preventive buffering even when a
handover does not follow can improve channel reliability as it
correspond to a retransmission of a group of packets during times of
Inzerilli [Page 60]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
"bad channel".
In addition to intra-domain mobility support and performance
enhancing during handovers, SIMPLE provides a facility to use IPv6
Stateless Address autoconfiguration ([10]) in any link, no matter
what topology has the whole link. This could be in fact very large,
containing up to 65536 Internet nodes and with many switching levels.
IPv6 Stateless Address Autoconfiguration can be applied on any SIMPLE
link thanks to a facility offered by one of the possible SIMPLE
algorithms. These calculate a unique link identifier from which the
mobile node can obtain a dynamic IPv6 care-of address.
In SIMPLE links broadcast of address resolution messages is not
needed, as a mobile node's link-layer address is always stored in a
well known location, which is independent of the link topology. This
is the mobile node's default state and the pointer to this state is
simply derivable from the IP address (either home address or care-of
address) the mobile node is using in the link, as it correspond just
to the last two bytes of it. Home agents exploit default states to
avoid broadcasting ND or ARP messages as well for intercepting
packets destined to mobile nodes away from home. Repeated
broadcasting of signaling a very large link could be very
inefficient, SIMPLE allows avoiding it.
SIMPLE is a scalable protocol as its performances do not degrade
significantly in very big links, with many Internet nodes and many
switching levels. The following arguments support this statement:
- SIMPLE guarantees efficient packet forwarding by means of an
auto-routing algorithm on the distribution system. The fact that an
implicit end-to-end forwarding rule inside the link is adopted
makes it possible to keep routing information only in APs. In fact,
these are the only points where routing information is needed. The
other nodes need simply to know their switching number and their
neighboring link nodes'. Local configuration of nodes makes the
routing algorithm and its performances independent of the size of
the link.
- SIMPLE guarantees compressed and small routing databases in
the APs. RRs are fixed-size and very small and they account only
for the mobile nodes having a default or a registration state in
the AP and not in general for all the mobile nodes in the SIMPLE
link. Their number can grow indeterminately, without changing the
size of any RR in the link.
- As RRs are fixed-size and single-lookup tables, lookups are
fixed-cost operations that are independent of the RR size. This
could be particularly efficient with respect to other lookup
techniques which need routing table scanning. If N is the number of
the entries of a table, these latter have a complexity of O(N) or
Inzerilli [Page 61]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
O(log(N)) when a exhaustive research or a binary research is
applied.
- Signaling load on the distribution system is low as mainly
signaling between access points and their served mobile nodes is
needed. Signaling that is propagated over the distribution system
consists of some location updates and location refresh messages
which are sent from current cells to default cells and what is
needed to implement a DLA research, which is performed during some
link-layer registrations.
- In addition, SIMPLE signaling is processed only by APs and
mobile nodes, intermediate nodes on the distribution system are
passive forwarders, which do no make distinction between signaling
messages an data packets.
- Signaling load on an AP cannot exceed a well defined limit
as it is proportional to the number of mobile nodes registered at
the AP and of those using the cell as default cell, which is
limited by the choice of the APN length.
Other favorable features of SIMPLE are that it has a vast range of
applicability, as a SIMPLE logical link can be built on a number of
physical topologies, tree-like and meshed too, as it exploits
possible direct links between peer nodes. These are used in the
routing algorithm as shortcuts, to minimize delay and network
resources utilization.
Moreover, SIMPLE signaling packets are very small (4 bytes of header
plus a few parameters vs. 20 bytes for an IPv4 header or 40 bytes for
an IPv6 header). This reduces the probability of being corrupted
while crossing a wireless channel and the bandwidth utilization of
signaling.
Finally, SIMPLE provides multiple-gateway access to a link Preventing
a single gateway from being a single point of failure for many
Internet nodes and from becoming a bottleneck in case of heavy load.
8. ACKNOWLEDGMENTS
Special thanks to Prof. Francesco Delli Priscoli for making it
possible to develop this work from initial ideas started with a
thesis and for his constant support.
Thanks also to Paolo Di Lorenzo and Guido Paolucci for their past and
present help in defining important aspects of the protocol operation
and for their assistance in writing this document.
Inzerilli [Page 62]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Finally, thanks to the WINE Consortium, within which the protocol was
studied and developed benefiting from an intense and stimulating
debate on mobility.
9. Security Considerations
This document deals with no security issues. This memo is focused on
interworking of various Internet protocols in particular without
examining security aspects. In a future version some security aspects
could be dealt with as generally needed with wireless access.
APPENDIX A: SIMPLE packet format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| APN | LMI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16 - k bits k bits
Figure A - SIMPLE Current Link-Layer Address (CLA)
APN Prefix of a SIMPLE Link-Layer address (LA)
identifying the access point where the mobile node is
being served.
LMI Suffix of an LA, identifying a mobile node that is
being served at the AP identified by the APN.
Control info
Field specifying options regarding data or signaling
packet. Option bit formats are detailed below.
Destination LA
SIMPLE specific two-bytes address, composed by a
prefix (APN) and a suffix (LMI), identifying the
destination node.
Inzerilli [Page 63]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Control info | Destination LA | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| Payload |
| ............................ |
Figure B - SIMPLE packet
Hop Limit
Time to Live. It is incremented at each hop from a
link node to another. When it arrives at 255, the
packet is discarded. In order to limit the number of
hops of a packet to N, when the packet is sent this
field is initialized to 255-N.
Payload
Variable-length field, used to contain an IP datagram
or an ARP message as for SIMPLE data packets or
parameters as for SIMPLE signaling messages.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|0 0 0|R|R|R|R|D| |0 0 1| CODE |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Data Header Signaling Header
Figure C - Control info field
R Reserved for future use.
D Default delivery flag.
CODE Bits identifying the type of signaling message.
Inzerilli [Page 64]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
APPENDIX B: Routing Registers (RRs) format
A H CLA New CLA CLA timer DLA timer
+-+-+--------+--------+--------------+--------------+ ^
000000 | | | | | | | |
+-+-+--------+--------+--------------+--------------+ |
000001 | | | | | | | | Reserved
+-+-+--------+--------+--------------+--------------+ | LMIs
000010 | | | | | | | |(RESV_LMI)
+-+-+--------+--------+--------------+--------------+ |
000011 | | | | | | | |
+-+-+--------+--------+--------------+--------------+ v
. . . . . ^
. . . . . |
. . . . . |
+-+-+--------+--------+--------------+--------------+ |
111110 | | | | | | | | Dynamic
+-+-+--------+--------+--------------+--------------+ | LMIs
111111 | | | | | | | |
+-+-+--------+--------+--------------+--------------+ v
bits 1 1 16 16 64 64
APN 10 bits, LMIs 6 bits (up to 64 mobile nodes)
Figure D - Routing Register
A Available CLA bit. When set, it means that the
relevant CLA is being used by a mobile node in the cell.
H Handover in progress bit. It is used in combination
with the A bit to signal a buffering of a forwarding
state for the relevant CLA
CLA Two-byte address identifying the current location of
the mobile node in the link.
New CLA
Two-Byte address identifying the new address assigned
to a mobile host after a handoff and used to forward
packets.
Inzerilli [Page 65]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
CLA timer
Current Link-layer Address timer. A registration
state cell MUST be periodically refreshed every
REFR_REG_TIME. The CLA timer is set to MAX_REF_TIME >
REFR_REG_TIME after each refreshment.
DLA timer
Default Link-Layer Address timer. A default or
location state needs to be regularly refreshed by the
relevant mobile node's current AP every
REFR_REG_TIME. The CLA timer is set to MAX_DEF_TIME >
REFR_REG_TIME after each refreshment.
Reserved LMIs
Identifier of a mobile node having a reserved
link-layer Address (RLA) in a cell. It corresponds to
the RLA without the APN prefix. The first RESV_NUM
LMIs in a cell are reserved LMIs.
Dynamic LMIs
Identifier that can be assigned to any mobile node
without a reserved link-layer Address (RLA) in a
cell. The APN prefix followed by the assigned LMI
corresponds to the CLA assigned to the mobile node.
The last (16-RESV_NUM) LMIs in a cell can be assigned
to any mobile node without an RLA in the cell.
References
[1] Tiziano Inzerilli, "SIMPLE, a Scalable Intra-domain Mobility
Protocol using Local Encapsulation for Mobile IPv6 and Mobile
IP", IST Mobile Summit 2000, Galway (Ireland).
[2] "IP Mobility Support" - C. Perkins, October 1996 - RFC 2002.
[3] "Mobility Support in IPv6" - D. B. Johnson, C. Perkins - 10
February 2000, Internet Draft.
[4] "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" - Jim
Bound and Charles Perkins - February 1999. Work in progress.
[5] "Internet Protocol version 6 (IPv6) specification" - Stephen E.
Deering and Robert M. Hinden - RFC 2460, December 1998
[6] "Dynamic Host Configuration Protocol" - R. Droms - RFC (Draft
Standard) 2131, IETF, March 1997.
[7] "Neighbor Discovery for IP version 6 (IPv6)" - Thomas Narten,
Erik Nordmark, and William Allen Simpson - RFC 2461,
December1998.
[8] "Reserved IPv6 subnet anycastaddresses" - David B. Johnson and
Inzerilli [Page 66]
INTERNET-DRAFT Intra-domain Mobility Support with SIMPLE January 2001
Stephen E. Deering -RFC 2526, March 1999
[9] "An Ethernet address resolution protocol: Or converting network
protocol addresses to 48.bit Ethernet addresses for transmission
on Ethernet hardware" - David C. Plummer - RFC 826,
November 1982.
[10] "IPv6 stateless address Autoconfiguration" - Susan Thomson and
Thomas Narten - RFC 2462, December 1998.
[11] "Network Time Protocols (Version 3): Specification,
Implementation and Analysis" - D.Mills - March 1992, RFC 1305
[12] "Ipv6 over Non-Broadcast Multiple Access (NBMA) Networks", G.
Armitage, P. Schulter, M. Jork, G. Harter, January 1999,
RFC 2491.
[13] Postel, J., "Multi-LAN Address Resolution", RFC 925, October
1984.
[14] W. Richard Stevens. TCP/IP Illustrated, Volume 1: The Protocols.
Addison-Wesley, Reading, Massachusetts, 1994.
[15] "IPv6 version 6 Addressing Architecture",R. Hinden, S. Deering,
July 1998, RFC 2373.
Authors' Addresses
Tiziano Inzerilli
Dipartimento di Informatica e Sistemistica, Universita' di Roma
"La Sapienza"
Via Eudossiana 18, 00184 Rome, Italy
Phone: +39-3333070111
fax : +39-0686203163
email: inzerilli@tiscalinet.it
Inzerilli Expires June 2001 [Page 67]
