Internet DRAFT - draft-inayat-mat
draft-inayat-mat
Internet Engineering Task Force Riaz Inayat
Internet Draft Pakistan Telecommunication Company Limited
Expires: January 31, 2006 Reiji Aibara
Hiroshima University
Kouji Nishimura
Hiroshima University
Kaori Maeda
Hiroshima City University
Yasunori Sugimoto
Net One Systems Co., Ltd.
August 1, 2005
MAT: A Network Architecture for Supporting Node Mobility
in Wireless IP Networks
<draft-inayat-mat-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.
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.
This Internet-Draft will expire on January 31, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79.
Inayat, et al Expires January 31, 2006 [Page 1]
draft-inayat-mat-00.txt August 2005
Abstract
This document describes MAT, a mobile network architecture that allows
smooth node mobility in wireless IP networks without using any packet
intercepter/forwarder. The mobility solution is specifically designed
for time-sensitive real-time applications, particularly the applications
where payload tends to be short and packet header overhead is very
significant. Connections are established as per permanent addresses of
the nodes but are carried on by the IP layer according to the temporary
addresses by address translation at the end nodes. The mapping
information is maintained by database servers, which can be placed in
the Internet in a distributed manner. TCP connections and security
associations can be preserved even if the node moves to another subnet
or the node changes its active interface in a multi-homed environment
without modifying TCP or IPsec. In comparison with Mobile IPv4 and
IPv6, MAT has several advantages in terms of header overhead and fault
tolerance.
1. Introduction
This document describes the protocol specification of
MAT [IEICE04,SAINT04,IJWOC03]. We propose MAT (Mobile Network
Architecture with Address Translation) to solve several problems such as
mobility, handoff management and multihoming particularly for
time-sensitive real-time applications. MAT supports mobility in IPv4 as
well as in IPv6[RFC2460] environments.
From mobility support viewpoint, MAT has several advantages in
comparison with Mobile IPv6[MIPv6] and IPv4[MIP] as follows:
o MAT has no header overhead because it generally does not use any
extension headers of IPv6 while Mobile IPv6 uses the Destination
Options Header for the Home Address Option and the Routing Header for
optimal routing.
o MAT is more fault tolerant than Mobile IPv6. In Mobile IPv6, the
Home Agent cannot be replicated to the subnet other than the home link
of the mobile node. MAT introduces MIS (Mapping Information Server)
which can be replicated anywhere in the Internet.
o MAT keeps end-to-end communication model, that is, MAT does not use
any packet intercepter/forwarder such as the Home Agent of Mobile
IPv6. There is no tunneling in MAT.
MAT has several advantages from viewpoint of IP diversity support.
For multi-interfaced mobile devices, IP addresses of the interfaces are
stored in MIS with priorities against the home address. This helps to
achieve smooth handoff without requiring direct update of IP addresses
between the end nodes. Assume that Node-A starts communication with
Node-B, a multihoming node with two network interfaces.
Inayat, et al Expires January 31, 2006 [Page 2]
draft-inayat-mat-00.txt August 2005
o Node-A will always communicate with the home address of Node-B no
matter which network interface of Node-B is used.
o Packets from node-A to node-B are routed to the highest priority
interface of node-B by translating home address to the IP address of
that interface.
o Node-B keeps the priority of the interfaces updated at the MIS. At the
overlapping area between subnets packets can be received through both
interfaces.
o There is no need to send the change of address update to the node-A
directly. This update is made effective with the help of MIS.
Similarly in MAT Security Association (SA) does not have to be changed
if the node changes its point of attachment during a session. Assume
that Node-A starts TCP communication with Node-B, a multihoming node
with two network interfaces, by using Ipsec [RFC2401].
o Node-A can recognize the identity of Node-B by the home address of
Node-B no matter which network interface of Node-B is used.
o The same security association (SA) can be used between Node-A and
Node-B no matter which network interface of Node-B is used.
o The TCP connection and the SA are still available even after the used
network interface of Node-B is switched to another during
communication.
2. Terminology
This document uses the following terms.
MAT:
Mobile network Architecture with address Translation, the network
architecture described in this document.
node:
The node is the general term to specify the equipment that
understands IP in the Internet. The node includes hosts, mobile
terminals, routers, and so on.
mobile node (MN):
A node that can change its point of attachment from one link to
another. A mobile node is assumed to have implemented MAT
features unless explicitly stated otherwise.
correspondent node (CN):
A peer node with which a mobile node is communicating. The
correspondent node may be either mobile or stationary.
Inayat, et al Expires January 31, 2006 [Page 3]
draft-inayat-mat-00.txt August 2005
MAT node:
A node that has implemented MAT features.
non-MAT node:
A traditional node that does not have MAT capabilities.
home address (HAdr):
An IP address assigned to a node within its home link. It also
represents node's identity.
mobile address (MAdr):
An IP address associated with an interface of a node while
visiting a foreign link. For a non-mobile node, mobile address is
same as HAdr.
home network:
The network on which a node's home subnet prefix is defined.
foreign network:
Any network other than the node's home network.
mapping informtion:
The association of the home address of a mobile node with mobile
addresses (mobile node can have more than one address depending
upon number of interfaces) of that mobile node, along with the
remaining lifetime of that association.
mapping information server (MIS):
A location directory, which maintains the location database of the
MN corresponding to the home address. A secure communication must
be supported among mobile node and corresponding MISs.
mapping information table (MIT):
A table maintained by every MAT-node caching the mapping
informations and the addresses of the corresponding MISs of the
mobile nodes with which the MAT-node is communicating.
3. Architecture Overview
3.1. Addressing
For MAT, we remain consistent with the current mobile internet,
MIP[RFC3344] and MIPv6[RFC3375] addressing schemes i.e., to use two
addresses for a mobile node; the permanent address specifies the node's
identity and the temporary address represents the current location.
As a matter of fact any Internet addressing scheme which employs
separation of node identifier and node locator, either using a single
address or two separate addresses, can be used to describe end points.
However, in this document, for simplicity of exposition, HAdr represents
the node identity and MAdr represents the current location of the node.
Inayat, et al Expires January 31, 2006 [Page 4]
draft-inayat-mat-00.txt August 2005
transport layer |
---------------------------------------|--------------------------------
V
+----------------------+
| source address: HAdr |
| target address: HAdr |
+----------------------+
source address translation | target address translation
+------------------+-------------------+
(a)| | (c) | (b)
V | V
+---------+-----------+ | +---------------------+
|source address: MAdr | | |target address: MAdr |
+-------------------- + | +---------------------+
| | |
+------------------+-------------------+
V
+----------------------+
| source address: MAdr |
| target address: MAdr |
network +----------------------+ MAT sublayer
layer ------------------------------|----------------------------
V delivery sublayer
+----------------------+
| source address: MAdr |
| target address: MAdr |
+----------------------+
---------------------------------------|--------------------------------
V
Figure 1: Basic Communication Model
3.2. Basic Communication Model
Figure 1 depicts the basic communication model of MAT. The network
layer is divided into two sub-layers: the MAT sub-layer and delivery
sub-layer. The MAT sub-layer performs the following functions.
o it identifies whether the target node is MAT node or non-MAT node.
o it determines the IP address of the MIS corresponding to the target
MAT node.
o it finds out the mobile address corresponding to the target home
address.
o it performs the address translations.
The delivery sub-layer delivers the packet as per target address. As
Inayat, et al Expires January 31, 2006 [Page 5]
draft-inayat-mat-00.txt August 2005
shown in the Figure 1, while sending a packet, application specifies the
destination with the home address for the target node. MAT sub-layer
receives the packet from transport layer. It identifies that whether the
target node is a MAT node or non MAT node. Now depending upon the type
of the target node as well as mobility status of the source and
destination nodes, the MAT layer performs address translations:
o If end-hosts are MAT nodes then both address translations, source
address translation and destination address translation are performed.
As shown is Figure 1, both (a) and (b) operations are performed.
o if the target node is a non-MAT node and the source node itself is at
home network, it simply hand over the packet to the delivery sub-layer
for further transmission without any translation (see Figure 1
operation (c)).
o If the target node is a non-MAT node and the source node itself is at
foreign network, it only performs the source address translation. As
shown is Figure 1, only (a) operation is performed.
o If both end nodes are MAT nodes but only target node is mobile then
only operation (b), as shown in the Figure 1, is performed.
After address translation, the packet is passed to the delivery
sub-layer, which transmits the packet as usual. While receiving, the
same operations are performed depending upon the type and mobility
status of the source and destination nodes.
3.3. Basic Mobility Support in MAT
subnet 1
+----+ +----+
| | <=======> | MN | -----+
| | A +----+ V
| | | +----+ subnet 2
| CN | <===========|======>| MN |-------+
| | | B +----+ V
| | | | +----+
| | <===========|==========|======>| MN | subnet 3
+----+ | | C +----+
^ | | |
| | | |
V | | |
+------+ | | |
| | <----------+ | |
| MIS | <---------------------+ |
| | <--------------------------------+
+------+
Figure 2: Mobility Support in MAT
Inayat, et al Expires January 31, 2006 [Page 6]
draft-inayat-mat-00.txt August 2005
The mobility support in MAT is depicted in the Figure 2. The single
lines show the control information messaging and double lines show the
actual user data transmission. Suppose that the correspondent node is
communicating with the mobile node, which is at its home network and has
been assigned IP address A. As it is a MAT node, so from the start of
communication the correspondent node has a mapping information entry of
MN in its Mapping Information Table (MIT). MIT is maintained by every
MAT node. When CN starts communicating with a mobile node, it fetches
the mapping information of the mobile node from MIS by querying it with
the home address A as the key. Mobile node keeps the MIS updated with
its location by sending mapping information updates. So when the mobile
node moves to the foreign networks, the mapping information entry
(mobile addresses B and C) in the MIS corresponding to the mobile node
home address A is updated. CN updates the MIT by periodically querying
the MIS depending upon the lifetime of the mapping information entry or
whenever MN alerts CN about change of address or address priorities.
The user data always flows directly between CN and MN.
3.4. Mapping Information Server (MIS)
When a node performs address translation, the node needs to associate
the HAdr with MAdr. Thus a database system having the mapping
information about the nodes is required. In the Internet, the Domain
Name System (DNS) maintains a similar sort of database. DNS is a
distributed database that maps Fully Qualified Domain Name (FQDN) to IP
address and vice versa, and provides other type of information related
to an IP address and a FQDN. For example, consider the case in which
one wants to know a FQDN associated with a particular IP address. In
this case, one sends a query with the IP address as a key to DNS, and
obtains the FQDN associated with the requested IP address. This feature
of DNS, called reverse lookup, works fine in the Internet.
DNS can be used to store the mapping information of a mobile node.
However, as DNS is meant for "static" data, it is not feasible to use
DNS for maintaining the mapping information regarding the location of a
mobile node, which changes its location very frequently. DNS is a very
large scale distributed database and so for load balancing it caches the
data for a reasonable long time. And thus it takes a very long time for
a change to be affective.
We use a dedicated location database server, MIS, for maintaining the
mapping information. A node registers its mapping information
periodically to its corresponding MIS. It also registers a new mapping
information when the node changes its location on the network. If a
mobile node has more than one network interfaces, the mapping
information record will have more than one MAdrs corresponding to the
HAdr and these MAdrs will be with priorities. CN will communicate with
the MAdr having highest priority. MIS only maintains the mapping
information of mobiles nodes. It does not perform any kind of
interception or forwarding of packets.
Inayat, et al Expires January 31, 2006 [Page 7]
draft-inayat-mat-00.txt August 2005
In MAT, to make the network architecture more fault-tolerant i.e.,
immune to a single point of failure and to reduce mapping information
registration latencies, MIS can be replicated and placed at multiple
locations in the Internet. The main purpose of having multiple MISs
is to make the system more fault tolerant however this feature of MAT
can also help to improve the quality of the handoff by reducing the
mapping information update and mapping information acquisition times.
It is obvious that if the location of MIS is near to the MN and CN then
the mapping information update and acquisition time will be less.
However having multiple MISs can give rise to two issues. One is how to
synchronize MN's mapping information between multiple MISs so that the
database of corresponding MISs about the MN should be same and the
second is how to find the nearest MIS corresponding to the mobile nodes.
We deal with these issues in the following ways.
3.4.1. Synchronizing Multiple MIS's Database
For synchronizing the mapping information between multiple MISs, as we
assume very few MISs corresponding to a certain MN, the MN updates its
mapping information by itself to all its corresponding MIS. By this,
mapping information remains updated and synchronized automatically
between multiple MISs. However in case of a large number of MISs, more
refine procedures are required. These procedures are beyond the scope of
this document.
3.4.2. Finding the Nearest MIS
To address the second problem we could use a mechanism like global load
balancing, which is used in web-access to select the nearest web server
from the clients. However, the appropriate MIS is that which is near
to both MN and CN, so the MIS selected by the global load balancing
method may not be the optimal one because it does not take into
consideration proximity from both CN and MN. MAT assumes a simple
method to select the appropriate MIS. The MIS record in DNS contains
the IP addresses of all the MISs corresponding to a certain MN. At
first the CN selects any MIS from the MISs specified by the MIS record
and after obtaining MN's mapping information starts communication with
the MN. It then sends special packet forcing it to take the route to
the MN through the MIS by using source routing option in IPv4 and
routing header in IPv6. CN repeats this for all the corresponding MISs
and select the one that offers minimum path delay. The addresses of all
the MISs are cached in the order of increasing path delays. From then
onward CN always fetches the MN's mapping information from the MIS that
offer minimum delay. However in case of a large number of MISs, more
refine procedures are required. These procedures are beyond the scope of
this document.
3.5. Identifying the Type of Target Node and Finding the Corresponding MIS
In MAT, in order to provide the backward compatibility with the existing
Inayat, et al Expires January 31, 2006 [Page 8]
draft-inayat-mat-00.txt August 2005
Internet infrastructure, we need to identify the type of the target node
from the address specified by the transport layers protocols. By type we
mean that whether it is a MAT enabled node or otherwise? If the target
node is a MAT node then we also need mapping information to perform
address translation. As mentioned in section 3.4, mapping information is
stored in MIS. Therefore, we need to know the IP address of the MIS
(MIS record) to fetch the mapping information corresponding to the HAdr.
As the MIS record is almost static and does not change as frequently as
mapping information of a mobile node, DNS can be used for maintaining MIS
record.
The MIS record is a reverse record stored like a pointer (PTR) record in
DNS but it points to the IP address of the MIS instead of the fully
qualified domain name (FQDN). It associates IP address (HAdr) with the
IP address (MIS). To implement this, MIS record is added in DNS
database at the home network, which is managing the PTR record of the
HAdr. No modification is required at the root and intermediate DNSs,
since intermediate servers are only interested in query name and query
name is the reverse domain name (like PTR) corresponding to the target
IP address which is compatible with the existing query names allowed in
the DNS. In MAT the authoritative server for the MIS record is the
server that is managing other resource records corresponding to the
HAdr.
In order to identify the target node type, a MAT node sends a query to
DNS to obtain the MIS record. If the answer section of the response
does not contain the MIS record, it means the target node is not a MAT
enabled node otherwise if the response has the MIS record it then
obtains the mapping information from the MIS pointed by the MIS record
and caches it to the MIT for the life time specified in the mapping
information. The address of the MIS is also cached.
3.6. Communication Mechanism of MAT
Communication mechanism of MAT is summarized in Figure 3. For
Simplicity of exposition, it is assumed that Node-1 and Node-2 are
associated with only a single Mapping Information Server. MIS11
maintains the mapping information of Node-1 and MIS22 of Node-2. Both
nodes are updating their mapping information to their respective MIS.
The following functions are performed when a packet transverses from
node-1 to node-2.
1. Node-1 and node-2 are updating their current locations to MIS11 and
MIS22 respectively.
2. From the upper layer the packet is handed over to the network layer
with permanent home addresses in the packet header.
3. As there is no cache entry in the MIT corresponding to the home
address, the node-1 through DNS1 finds that the target node is a MAT
node and its corresponding location directory is MIS22.
Inayat, et al Expires January 31, 2006 [Page 9]
draft-inayat-mat-00.txt August 2005
+-------+ 1
| MIS22 | <--------------+
+-------+ |
^ |
4| |
2,5 V V 9,10
+------+ 3 +------+ 6 +------+ 7 +------+
| DNS1 | <---------> |Node-1| <=========> |Node-2| <---------> | DNS2 |
+------+ +------+ +------+ +------+
^ 8 ^
DNS: Domain Name Server | 8|
MIS: Mapping Information | V
Server | 1 +-------+
+--------------->| MIS11 |
+-------+
Figure 3: Communication Mechanism
4. Mapping information for node-2 is fetched from MIS22 and cached in
MIT.
5. As both nodes are mobile so both address translations (source and
destination) are performed.
6. The packet is routed according to the destination mobile addresses.
7. The packet reached the node-2. As there is no cache entry in MIT
corresponding to the source home address, the node-2 through DNS2
finds that the source node is a MAT node and its corresponding
location directory is MIS11.
8. Mapping information for node-1 is fetched from MIS11 and cached.
9. Destination as well as source translations are performed at the
network layer.
10. The packet is handed over to the upper layers with home addresses.
3.6.1. Start of Communication as a Sender
There is slight difference in messaging sequence when communication is
started at sending and receiving node. A CN, when starts communication
as a sender, follows the following sequence of messages (see Figure 4).
1. With target node's home address as a key, the CN sends the request to
the DNS server for the MIS record. If it gets the MIS record in the
answer section of the response, it means that the target node is a
MAT node.
Inayat, et al Expires January 31, 2006 [Page 10]
draft-inayat-mat-00.txt August 2005
+-----+
+----------------> | MIS |
| +-----+
2 | ^
| |
V V
+-----+ 1 +-----+ 3 +-----+
| DNS | <----------> | CN | ===========> | MN |
+-----+ +-----+ +-----+
Figure 4: Messaging Sequence When CN starts Communication as a Sender
2. From the MIS record, it gets the IP address of the MIS of the target
mobile node. It then queries that MIS for the mapping information of
the mobile node. The response contains the mapping information of the
mobile node.
3. It then starts sending the data packets to the mobile node after
translating the target home address to the respective mobile address.
If the CN node itself is a mobile node it must sends the first data
packet with its home address in IP header option, we called it Home
Address Option, HAO (IP header option in IPv4, destination option
header in IPv6). Its use is explained in section 3.6.2.
3.6.2. Start of Communication as a Receiver
+-----+
+----------------> | MIS |
| +-----+
3 | ^
| |
V V
+-----+ 2 +-----+ 1 +-----+
| DNS | <----------> | CN | <=========== | MN |
+-----+ +-----+ +-----+
Figure 5: Messaging Sequence When CN starts Communication as a Receiver
When a CN starts communication as a receiver, the messaging sequence is
as follows, Figure 5.
1. In MAT, the first packet received from the mobile node must have home
address information. Home address information is required to find out
the IP address of the MIS and consequently the mapping information of
the mobile node.
2. The CN then finds the MIS record from the DNS server.
Inayat, et al Expires January 31, 2006 [Page 11]
draft-inayat-mat-00.txt August 2005
3. From the MIS record, the CN gets the IP address of the MIS of the
mobile node and consequently finds the mapping information
corresponding to the mobile node.
IP addresses of MIS as well as mobile nodes are then cached in the
mapping information table for further communication until the CN
receives the next alert message from a mobile node
3.7. DNS Entries
As described in section 3.4 and section 3.5 the relation between the MAT
node and its MIS is almost static in contrast to the mapping
informations of the MAT node. MAT makes use of the Domain Name System
(DNS) to maintain the relation between the mobile node and its MISs.
The MAT node has an MIS record entry in DNS. An MIS record is a PTR
like record which maps a (reversed) node identity (home address) to the
IP addresses (addresses of MIS corresponding to the node) instead of
FQDN. When a MAT node (receiver node) received a packet from another
MAT node then the first few packets must have the home address of the
MN. This home address is used to fetch the MIS record of MN through the
DNS. The subsequent mapping information fetched from the MIS also
confirms the current location of the MN which avoid impersonation.
Thus, no modifications to DNS are required.
3.8. IPsec Operation
In the sending node, IPsec is processed as follows.
When the packet is passed from the transport layer, the source and the
destination address fields in the IP header contain home addresses
representing the node identities. The security association is decided
by using the destination home address, and then IPsec calculation is
executed. After that, the source and the destination addresses are
converted to mobile addresses.
In the receiving node, IPsec is processed as follows.
Upon packet reception, the source and the destination address fields of
IP header contain mobile addresses. First, these mobile addresses are
converted to home addresses. The security association is decided by
using the destination home address, and then IPsec calculation is
executed.
3.9. Handoff Support for multi-interfaced Devices
In MAT, a source node is capable of changing the destination address to
the current MAdr without affecting the communication. And also the
feature of MAT of having more than one MAdrs at MIS corresponding to a
HAdr when MN has dual interface, can help to reduce handoff latency if
these addresses are stored with priorities. In MAT, for seamless
Inayat, et al Expires January 31, 2006 [Page 12]
draft-inayat-mat-00.txt August 2005
handoff with dual interface, overlapping area between subnets is
required. Within this overlapping area if we control the timings of
link layer handoffs, either at link layer by having different handoff
threshold values for two interfaces or at upper layer by forcing the
interfaces to connect to new subnet at different times, we can create a
overlapping time that may be exploited with the above feature of MAT to
reduce handoff latency. In that case interface-2 will connect to the
new subnet as soon as it receives signal from new subnet, whereas
interface-1 will remain connected to the previous subnet as long as the
signal is receivable from previous subnet.
With the assumption that a MN can force wireless network adapter to keep
association with a specific Access Point (AP), it is possible that in
the overlapping coverage area, one wireless adapter keeps its
association with the existing AP and the other makes its association
with the new AP by providing IP diversity. If the MN is within the
coverage area of a single AP then only one network interface will be
active. When it reaches within the coverage area of the new AP, its
second interface gets the mobile IP address MAdr2 from the subnet-2 and
mobile node sends the mapping information updates to the MIS having both
mobile addresses with respective priorities and also alerts the CN by
sending a packet with home address option (HAO). In the overlapping
area the mobile node has two mobile addresses with first priority to the
mobile address with subnet-1. But in the middle of the overlapping area,
the priority of the mobiles addresses may be interchanged. The CN is
informed by sending a packet with HAO. So CN will fetch the new mapping
information from the MIS and keep communication continued. Before
fetching the mapping information from MIS, CN knows the authenticated
priority-2 address. So if the source address of the packets from MN is
the priority-2 address, the CN does not have to authenticate the
packet's source, as it already knows the tentative address. This also
reduces the handoff latency
When the primary direction of packets transmission is from CN to MN,
handoff in MAT involves the following sequence of events:
o MN having interface-1 connected to subnet-1 enters the overlapping
area between subnet-1 and subnet-2.
o After some time the interface-2 obtains a mobile address MAdr2 from
subnet-2.
o MN registers this mobile address with the MIS as standby (priority-2)
address.
o MN alerts the CN about this change.
o CN fetches the mobile addresses from the MIS and keep the
communication through priority-1 MAdr1.
o When the signal strength from the subnet-2 becomes more than that of
Inayat, et al Expires January 31, 2006 [Page 13]
draft-inayat-mat-00.txt August 2005
subnet-1, MN gets the priorities of mobile addresses interchanged at
MIS.
o MN alerts the CN about this change.
o CN gets the mobile addresses with new priorities from the MIS and
starts sending the packets to the new MAdr2.
o MN loses the connection with the subnet-A1 and updates the MIS
accordingly.
So during the overlapping time the MN is capable of receiving packets
from both interfaces. With dual-interface handoff packets will only be
lost when the overlapping time is insufficient to acquire the MAdr and
to alert the CN. Whereas when the direction of transmission is from MN
to CN, we can even avoid this loss by buffering the packets until the
interface-2 is ready for transmission. For transmission from MN to CN,
as soon as the MN changes the priority of addresses it starts sending
the packets through MAdr2. So if CN receives the packet having source
address MAdr2, it accepts the packet as it already has this as
priority-2 address in its MIT. If it does not have MAdr2 in MIT it
buffers the packet until confirming the source address from MIS because
this packet must be with HAO. So CN fetches the new priorities from the
MIS. With this scheme it is easy to provide constant QoS by
maintaining the old reservation until the successful completion of the
new one.
3.11. Communication with non-MAT nodes
MAT nodes are compatible with the traditional IP nodes. When a MAT node
starts communication with the traditional node, then after identifying
that the target node is not a MAT node it does not perform any further
MAT specific operation. When MAT node communicates with traditional
nodes, it uses its current location address in the IP header (i.e., HAdr
when at home network and MAdr when at foreign network). However in this
case mobility is not supported.
When the MAT node receives communication from a traditional node, it
identifies the type of the sender node from the option with the header
of first packet (IP header option in IPv4, destination option header in
IPv6). If there is no home address in the IP option, it means the node
is a traditional one and so MAT node behaves as a traditional node. In
this case, it communicates with source address equals to its current
location address and thus mobility is not supported.
While communicating among MAT nodes, mobility is supported irrespective
of the location of the nodes when the communication started i.e.,
whether they are at their home network or at a foreign network.
Inayat, et al Expires January 31, 2006 [Page 14]
draft-inayat-mat-00.txt August 2005
4. Packet Formats
MAT can be implemented in IPv4 and IPv6 environments. For this document
we describe the IPv6 packets formats only. The subsequent subsections
describe the following messages of MAT and their packet formats.
Mapping Information Update Request Message UDP MN -> MIS
Mapping Information Update Reply Message UDP MIS -> MN
Mapping Information Request Message UDP CN/MN -> MIS
Mapping Information Reply Message UDP MIS -> CN/MN
Mapping Information Change Alert Message IP MN -> CN
Any Message between MISs (if needed) UDP MIS -> MIS
4.1. Data Packet
MAT uses the normal IP header in which the home addresses are used, as
node identity for the layers above the network layer, in the source and
destination address fields. However for the lower layers i.e., for the
routing purposes, home addresses are translated to mobile addresses
depending on the node type as describe in section 3.2. Figure 6 shows
the format of the normal IPv6 header.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| Traffic Class | Flow Label |
+-------+---------------+-------+---------------+---------------+
| Payload Length | Next Header | Hop Limit |
+-------------------------------+---------------+---------------+
| |
+ +
| Source Address |
+ (Home Address for upper layers) +
| (Mobile Address for lower layers) |
+ +
| |
+---------------------------------------------------------------+
| |
+ +
| Destination Address |
+ (Home Address for upper layers) +
| (Mobile Address for lower layers) |
+ +
| |
+---------------------------------------------------------------+
Figure 6: IPv6 header format
4.2. Mapping Information Update Request and Reply Messages
When a mobile node moves to another subnet, i.e., when the current
Inayat, et al Expires January 31, 2006 [Page 15]
draft-inayat-mat-00.txt August 2005
0 0 1 2 3
0 8 6 4 1
+-->+--------+--------+--------+--------+
| | Type | code | Flags | Length |
| +--------+--------+--------+--------+
| | Sequence Number |
| +-----------------------------------+
| | |
| + Home Address +
| | |
| +-----------------------------------+
| | |
| + Priority-1 Mobile Address +
| | |
| +-----------------------------------+
| | |
| + Priority-2 Mobile Address +
| | |
+----------------------+ | +-----------------------------------+
| IPv6 Base Header | | | |
+----------------------+ | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
|Authentication Header | | | |
+----------------------+ | +-----------------------------------+
| UDP Header | | | Timestamp |
+----------------------+--+ +-----------------------------------+
|Mapping Update Request| | Lifetime |
+----------------------+----->+-----------------------------------+
(a) Mapping Information Update
Request Message
+----------------------+
| IPv6 Base Header |
+----------------------+ 0 0 1 2 3
|Authentication Header | 0 8 6 4 1
+----------------------+ +-->+--------+--------+--------+--------+
| UDP Header | | | Type | Code | Flags | Length |
+----------------------+--+ +--------+--------+--------+--------+
| Mapping Update Reply | | Sequence Number |
+----------------------+----->+-----------------------------------+
(b) Mapping Information Update
Reply Message
Figure 7. Mapping Information Update Request/Reply formats
location of the mobile node changes, the mobile node sends the Mapping
Information Update Request Message to the MIS. Upon receiving the
Mapping Information Update Request Message, the MIS returns the Mapping
Information Update Reply Message to the mobile node. The Mapping
Information Update Request and Reply Messages are UDP packets. The
Inayat, et al Expires January 31, 2006 [Page 16]
draft-inayat-mat-00.txt August 2005
Authentication Header of IPv6 must be included in the Mapping
Information Update Request Message to avoid illegal mapping information
update. Figure 7 shows the formats of the Mapping Information Update
Request and Reply Messages.
Source Address: the mobile address of the source node.
Destination Address: the mobile address of the destination node.
Source Port: TBD.
Destination Port: TBD.
Type:
0x01: mapping information update request
0x02: mapping information update reply
Code:
0x00: succeeded
0x01: authentication failed
0x02: ...
Flags: TBD
Length:
specifies the length of the mapping information update
request/reply message in 32 bits word
Sequence Number:
the source node of the Mapping Information Update Request Message
assigns this field a sequence number. The same value is copied to
the sequence number field of the Mapping Information Update Reply
Message.
Home Address: the node ID of the source node.
Mobile Address: the current mobile addresses of the source node.
Timestamp: the current time.
Lifetime: the period of time for which this mapping information is
valid.
4.3. Mapping Information Request and Reply Messages
When a node tries to send a packet to a mobile node, the node sends the
Mapping information Request Message to the MIS to obtain the current
address of the mobile node. When the MIS receives the Mapping
Information Request Message, it returns the Reply Message to the node to
notify the Current addresses of the mobile node. Figure 8 shows the
Inayat, et al Expires January 31, 2006 [Page 17]
draft-inayat-mat-00.txt August 2005
0 0 1 2 3
0 8 6 4 1
+-->+--------+--------+--------+--------+
| | Type | code | Flags | Length |
| +--------+--------+--------+--------+
| | Sequence Number |
+----------------------+ | +-----------------------------------+
| IPv6 Base Header | | | |
+----------------------+ | + Home Address +
| UDP Header | | | |
+----------------------+--+ +-----------------------------------+
| Mapping Request | | Timestamp |
+----------------------+----->+-----------------------------------+
(a) Mapping Information
Request Message
0 0 1 2 3
0 8 6 4 1
+-->+--------+--------+--------+--------+
| | Type | code | Flags | Length |
| +--------+--------+--------+--------+
| | Sequence Number |
| +-----------------------------------+
| | |
| + Home Address +
| | |
| +-----------------------------------+
| | |
| + Priority-1 Mobile Address +
| | |
| +-----------------------------------+
| | |
| + Priority-2 Mobile Address +
| | |
| +-----------------------------------+
| | |
+----------------------+ | /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
| IPv6 Base Header | | | |
+----------------------+ | +-----------------------------------+
| UDP Header | | | Timestamp |
+----------------------+--+ +-----------------------------------+
| Mapping Reply | | Lifetime |
+----------------------+----->+-----------------------------------+
(b) Mapping Information
Reply Message
Figure 8. Mapping Information request/Reply Message format
Inayat, et al Expires January 31, 2006 [Page 18]
draft-inayat-mat-00.txt August 2005
format of the Mapping Information Request and Reply Messages.
Source Address: the mobile address of the source node.
Destination Address: the mobile address of the destination node.
Source Port: TBD.
Destination Port: TBD.
Type:
0x03: Mapping Information request
0x04: Mapping Information reply
Code:
0x00: succeeded
0x01: authentication failed
0x02: ...
Flags: TBD
Length:
specifies the length of the mapping Information request/reply
message in 32 bits word
Sequence Number:
the source node of the Mapping Information Request Message assigns
this field a sequence number. The same value is copied to the
sequence number field of the Mapping Information Reply Message.
Home Address: the node ID of the mobile node.
Mobile Address: the current mobile addresses of the mobile node.
Timestamp: the timestamp of this mapping information.
Lifetime: the period of time for which this mapping information is
valid.
4.4. Mapping Information Change Alert Message
We call this message as Home Address Option (HAO). This message is sent
at the start of communication or whenever the mobile node changes its
point of attachment. For IPv6 we use the destination option header
containing the Home Address of the mobile node. This destination option
header is added with the normal data packet. Upon receiving this alert,
the receiving node sends the Mapping Information Request Message to
obtain the new mobile addresses of the node sending the Mapping
Information Change Alert message.
Inayat, et al Expires January 31, 2006 [Page 19]
draft-inayat-mat-00.txt August 2005
5. Processing on a Mobile Node
5.1. Bootstrap
When the mobile node is powered on, it obtains the mobile addresses
against its interfaces from the subnet to which it is connected after
sending the Router Solicitation Message[RFC2461] and receiving the
Router Advertisement Message. Next, the mobile node sends a DNS query
packet to obtain the addresses of the MISs that maintain the mapping
information of the mobile node. Next, the mobile node establishes a
security association of IPsec[RFC2401] with the MIS. Next, the mobile
node sends the Mapping Information Update Request Message to the MISs to
register the current mobile addresses and receives the Mapping
Information Update Reply Message.
5.2. Processing on Movement
The mobile node detects the change of the point of attachment to the
Internet at one of its interfaces by some mechanisms, for example, 1)
interrupt by hardware, 2) upcall from the link layer, and 3) router
advertisement message. When the mobile node detects a location change,
first, it sends the Router Solicitation Message and receives the Router
Advertisement Message. Then it obtains the mobile address from the
subnet against the interface to which the mobile node is connected.
Next, the mobile node sends the Mapping Information Update Request
Message to the MIS to notify the current change in mobile addresses.
The Mapping Information Update Request Message must follow some security
procedure like including the Authentication Header. The mobile node sends
the Mapping Information Change Alert Message to the correspondent
nodes with which it is communicating.
6. Processing on a MIS
Upon receiving the Mapping Information Update Request Message from the
mobile node, first, the MIS makes it sure that the Authentication
Header is correct. If authentication fails, the MIS returns the
Mapping Information Update Reply Message with the error code
Authentication Failed. If authentication succeeds, the MIS updates the
mapping Information of the mobile node and returns the Mapping
Information Update Reply Message to the mobile node.
If the mobile node is associated with two or more MISs, consistency
among the databases on the MISs must be kept by some procedures. One
of the procedures is described in section 3.4.1. However, if a MN is
associated with a large number of MISs, more refined mechanisms are
required to synchronize the databases. These mechanisms are beyond the
scope of this document.
Inayat, et al Expires January 31, 2006 [Page 20]
draft-inayat-mat-00.txt August 2005
7. Packet Transmission and Reception
7.1. Packet Transmission
When the network layer receives a packet transmission request from the
transport layer, the addresses passed from the TCP/UDP are always home
addresses. Network layer then searches the Mapping Information Table
for the mobile addresses by using the home address of the destination
node as the key. If the mobile addresses are found then the network
layer changes the home address to the highest priority mobile address.
After that the network layer executes the normal IP transmission
procedure.
If the mobile addresses of the destination node is not found in the
Mapping Information Table, the node keeps the packet waiting for
transmission, and then sends the Mapping Information Request Message to
the MIS to obtain the mobile addresses. If the source node does not
know the addresses of the MISs, it obtains the MIS's address from the
name server by indicating the home address of the destination node. Upon
receiving the Mapping Information Reply Message, the node translate the
home address to the mobile address of the destination node, and then
executes the normal IP transmission procedure. This mapping information
is also cached in the MIT. For the non-MAT node a dummy entry is
created in MIT with home address is all the address fields.
7.2. Packet Reception
When the network layer receives a packet from the link layer, first the
network layer searches the MIT for the home address by using the mobile
address of the source node as key. If an entry is found, the network
layer translates the source address to the home address and handovers
the packet to the TCP/UDP layer.
If no entry is found, then the network layer checks whether the packet
has home address in the destination option header. With that home
address as key, first the node finds out the addresses of the MISs
through DNS and then fetches the mapping information from the MIS. It
then translates the source address to the home address and handovers the
packet to the TCP/UDP layer. For the non-MAT node a dummy entry is
created in MIT with home address is all the address fields.
7.3. Mapping Information Change Alert Message Reception
When a node receives the Mapping Information Change Alert Message, it
sends the Mapping Information Request Message to the MIS of the node
sending the Message. If the node does not know the address of the MIS,
it obtains the MIS's address from the name server by indicating the
home address of the node sending the Mapping Information Change Alert
message.
Inayat, et al Expires January 31, 2006 [Page 21]
draft-inayat-mat-00.txt August 2005
8. Scalability and Security Considerations
In MAT, as there is no restriction about the numbers as well as
locations of the MIS, the mapping information database system is quite
flexible without any major scalability problem. Moreover MAT does not
require any modification in the DNS and addressing systems. After
acquiring new MAdr, MN needs to update its mapping information to the
respective MISs. This potentially leaves the door open for a malicious
node to hijack the network connection or to spoof the MIS database. This
scenario is very similar to the security problem with the DNS. Actually
in the context of security, the implementation of MIS is similar to
that of DNS in the Internet. To address the problems of hijacking and
spoofing, MAT suggests to use some mechanism to protect the
communication as well as MIS database with shared secret key
authentication between a MN and its respective MISs, when the Ipsec
procedure become time costly due to high movement of the mobile node.
We could use symmetric or asymmetric key algorithms, but being
substantially fast, symmetric key algorithms are more suitable to MAT
architecture. As MN only has to update its mapping information with a
very few already known MISs, so there is no problem for key
distribution.
The scenario of secure relationship between CN and MIS is similar to
that of CN and DNS. MAT does not provide any enhancement of security
between CN and MIS more than what is provided traditionally between CN
and DNS in the Internet. Thus, the vulnerability of MIS database to the
malicious attacks and hijacking of communication is alleviated by making
secured communication between mobile nodes and their respective MISs a
must and by not allowing direct transfer of mapping information between
MN and CN. The direct transfer of mapping information from MN to the CN
makes the system insecure.
9. MAT and Real-time Applications
MAT is specifically designed for real-time applications, particularly
the applications where payload tend to be very short and thus packet
header overhead becomes very significant. The mobility architectures
requiring encapsulation or additional headers are not so efficient for
real-time applications. Particularly in stable state i.e., a mobility
scenario involving very few handoffs, these extension headers and
encapsulation overheads are not required. MAT network architecture does
not induce significant packet header overhead. Only at the start of
communication or at the change of mapping information, the node sends
the home address in the extension header. In the normal operation there
is absolutely no encapsulation or additional header requirement.
Inayat, et al Expires January 31, 2006 [Page 22]
draft-inayat-mat-00.txt August 2005
10. Acknowledgements
The authors would like to thank Mr. Takahiro Fujita of Graduate School
of Engineering of Hiroshima University Japan for his invaluable input to
this draft.
References
[IEICE04] R. Inayat, R, Aibara, K. Nishimura, T. Fujita, and K. Maeda. An
End-to-End Network Architecture for Supporting Mobility in Wide
Area Wireless Networks. IEICE Transactions on Communications,
Vol. E87-B, No.6, pp. 1584-1593, June 2004.
[IJWOC03] R. Inayat, R. Aibara, K. Nishimura, T. Fujita, Y. Nomura, and
K. Maeda. Realizing fast Mobility and Multi-homing Support in
Wireless access Networks. International Journal on Wireless and
Optical Communication, Vol. 1, No.2, pp. 123-146, December 2003.
[SAINT04] Riaz Inayat, Reiji Aibara, Kouji Nishimura, Takahiro Fujita, and
Kaori Maeda. Realizing High Mobility through an End-to-End
Network Architecture with IP Diversity Support for Real Time
Internet Applications. Proceeding of 2004 Symposium on
Applications and the Internet (SAINT 2004): Tokyo, Japan,
pp. 243-249, January 26-30, 2004.
[RFC2401] S. Kent and R. Atkinson. Security Architecture for the Internet
Protocol. RFC 2401, November 1998.
[RFC2460] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6)
Specification. RFC 2460, IETF, December 1998.
[RFC3344] Charles E. Perkins. IP mobility support for IPv4. RFC 3344,
IETF, August 2002.
[RFC3775] D. Johnson, C. Perkins, and J. Arkko. Mobility Support in IPv6.
RFC 3775, IETF, June 2004.
Inayat, et al Expires January 31, 2006 [Page 23]
draft-inayat-mat-00.txt August 2005
Author's Address
o Riaz Inayat
Pakistan Telecommunication Company Limited (PTCL),
Technologies and Standards Wing,
CDDT Building, PTCL H/Qs,
H-9/1, Islamabad, Pakistan.
Phone: +92-51-443-1191
Email: riaz.inayat@ptcl.net.pk
o Reiji Aibara
Information Media center, Hiroshima University,
1-4-2 Kagamiyama, Higashi-Hiroshima, Hiroshima,
739-8511, Japan.
Phone: +81-82-424-6258
Email: ray@hiroshima-u.ac.jp
o Kouji Nishimura
Information Media center, Hiroshima University,
1-4-2 Kagamiyama, Higashi-Hiroshima, Hiroshima,
739-8511, Japan.
Phone: +81-82-424-6252
Email: kouji@hiroshima-u.ac.jp
o Kaori Maeda
Information Processing Center, Hiroshima City University,
3-4-1 Ozuka-Higashi, Asa-Minami-Ku, Hiroshima,
731-3194, Japan.
Phone: +81-82-830-1655
Email: kaori@ipc.hiroshima-cu.ac.jp
o Yasunori Sugimoto
Network Technology & Product Operations,
Net One Systems Co., Ltd.,
IS BLDG., 3-32-42 Higashi-Sinagawa, Shinagawa-Ku, Tokyo,
140-002, Japan.
Phone: +81-3-5462-0821
Email: y-sugimoto@netone.co.jp
Inayat, et al Expires January 31, 2006 [Page 24]
draft-inayat-mat-00.txt August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Inayat, et al Expires January 31, 2006 [Page 25]
