INTERNET DRAFT Yutaka Ezaki
May 2001 Yuji Imai
Expires December 2001 Fujitsu Labs.
Mobile IPv6 handoff by Explicit Multicast
<draft-ezaki-handoff-xcast-01.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:
For a handoff action using the mobile IPv6, we need two functions:
re-routing on the wired region of the network and the activation of the
air-link on the wireless region. In this architecture, a possibility of
small break for a session is still large by the signaling overhead between
Home Agent and Mobile Node (MN). We propose a new handoff method using the
Explicit Multicast (xcast) technique. On the wired section, control/user
packets are multicasted by xcast scheme to the Base Stations where MN can
receive, then packets are passed to the air-link activated between a BS
and the MN.
1. Introduction
In this draft, we propose another fast or smooth handoff method using the
Small Group Multicast (SGM) / explicit multicast (xcast) technique.
In Mobile IPv6 (MIPv6)[1], a Mobile Node (MN) sends a Binding Update (BU)
packet to his Home Agent (HA) to modify the Binding Cache in the HA. Packets
from Correspondent Node (CN) are encapsulated at the HA and tunneled to
the MN. Recently, fast handoff or smooth handoff method called hierarchical
MIPv6 (HMIPv6) using multiple layer and sub-HA called Mobility Anchor Point
(MAP) are proposed [2]. It has an advantage of decreasing the load of HA,
because the MAP hides the micro-movement of the MN in his layer. However,
decapsulation and re-encapsulation on the MAP or a complex handover
sequences are still needed.
The complexity of current MIPv6 or HMIPv6 comes from the basic restriction
that a packet from the CN must NOT duplicate over the network (e.g. CN-HA-MN).
In the mobile communication, the resource for the air-link is still
important, whereas resource on wired network becomes sufficient since the
development of the transport equipment (e.g. WDM) is distinctive. Actual
MIPv6/HMIPv6 handoff procedure involves two type of the function:
re-routing on the wired region of the network and the activation of the
air-link on the wireless region. A cellular phone service achieves fast
hand off scheme and saving of mobility administration table on Home Location
Register (HLR) using the zone calling up technique for multiple cells [9].
Introducing the same idea, simple and fast handoff can be achieved on Mobile
IP by multicasting the packet from HA. Low delay and no packet loss can
be realized by the MN to select some BSs which receive the packet with the
best condition.
Several handoff methods using multicast are proposed [9, 10, 11]. They
describe that smooth handoff by multicast is effective in reducing datagram
transmission latency, simplifying the intermediate routers logic and
saving bandwidth of the wired network. However, in the past, it could not
be achieved because using a classical multicast technique (e.g. DVMRP, PIM),
it is difficult to maintain the large number of multicast group and routing
spanning tree. These handoff methods transmit the datagrams for each MN
by multicast. That means the base multicast system is required to support
same number of multicast groups as that of MNs. And delivery trees of each
multicast address must be frequently changed in order to trace a movement
of each MN. It also costs expensive to set each of the group that has an
only few destinations.
In this draft, first we introduce the SGM/Xcast technique which supplements
a classical multicast, including standardization status. Since Xcast has
some characteristics that intermediate routers forward multicast datagrams
only by unicast routing information, xcast supports huge number of restless
multicast groups that is necessary for handoff.
We propose the fast handoff method for MIPv6 by SGM/Xcast with few
modifications to the MIPv6 architecture. This handoff mechanism provides
mobility in heterogeneous media environment because this handoff mechanism
is basically able to implemented without additional control or intelligence
of neither intermediate routers nor Mobility Access Point (MAP).
2. Overview of Small Group Multicast
Multicast technique is important for the broadcast application,
many-to-many video conference, or the advertisement of the router
information. Using a group (class D) address, many protocols have been
proposed and experimented. However, present multicast technique has some
problems that it requires a state management for each group address.
Recently, a BoF has been established to study the multicast technique for
small group on IPv4/IPv6 environment without a complex routing protocol
[7]. For a large number of small group communications, Small Group Multicast
(SGM) scheme will be suitable. SGM is based on the 'Xcast' (explicit
multicast) technique meaning that the every datagram includes all the
addresses to deliver on the header of the packet.
There are several experimental variant protocols [5] proposed in SGM/xcast
BoF. Recently, unified specification for Xcast has been published [13].
We introduce a summary of the spec. in the next section.
2.1 Xcast overview
Xcast is multicast delivery mechanism that depends only on the existing
unicast routing environment. The destination of a multicast datagram is
specified by a list of unicast addresses instead of a group multicast
address. Xcast is available for IPv4 or IPv6 environment with slightly
modifying the header format. For IPv6 datagram, a destination list is stored
in an IPv6 routing extension header with a bitmap that represents the
destinations to send. For example, suppose that node A is trying to get
packets distributed to B, C and D in Figure 2.1 below:
R4 ---- B
/
/
A----- R1 ---- R2 ---- R3 R8 ---- C
\ /
\ /
R5 ---- R6 ---- R7
\
\
R9 ---- D
Figure 2.1 Sample network
This is accomplished as follows: A sends an Xcast packet with the list of
destinations in its Xcast header to the first router, R1. Ignoring the
details, the packet that A sends to R1 looks like this:
[ src = A | dest = B C D | payload ] .
When R1 receives this packet, it needs to process the Xcast header as
follows:
- Perform a route table lookup to determine the next hop for each of
the destinations listed in the packet.
- Partition the set of destinations based on their next hops.
- Replicate the packet so that there's one copy of the packet for
each of the next hops found in the previous steps.
- Modify the list of destinations in each of the copies so that the
list in the copy for a given next hop includes just the destinations
that ought to be routed through that next hop.
- Send the modified copies of the packet on to the next hops.
- Optimization: If there is only one destination for a particular
next hop, send the packet as a standard unicast packet to the
destination (X2U).
So, in the example above, R1 will send a single packet on to R2 with a
destination list of < B C D > and R2 will send a single packet to R3 with
the same destination list. The following routers forward the Xcast packet
with performing the same process.
Since routers can branch and forward the Xcast datagram only by unicast
routing table, it has a good scalability concerning with the number of
multicast group that is necessary for our handoff.
The format of the Xcast6 (Xcast for IPv6) datagram is
[IPv6 header | Xcast6 header | transport header | payload ].
Detail formats of these headers are explained in [13].
3. Fast handoff extension for Mobile IPv6 by Xcast
In this section, we describe the fast handoff extension for Mobile IPv6
(MIPv6) [1] using Xcast technique. Now, we assume that a Mobile Node (MN)
moves from area 1 to area 4 for a network model shown in Fig.3.1.
CN HA (MN): shadow
| | |
---+--- --+--+--+-- (Home link)
| |
+---+---------------+---+
| Core Network |
+---+---------------+---+
| |
--+---+-----+-- --+---------+-- (Access network)
| | | |
BS1 BS2 BS3 BS4
/ \ / \ / \ / \ <- Wireless link
~~~~~~~~ ~~~~~~~~ ~~~~~~~~ ~~~~~~~~
SubnetüFarea 1 area 2 area 3 area 4
|
+--+
|MN| ==Movement==>>
+--+
COA: COA#1 COA#2 COA#3 COA#4
Figure 3.1: Example of a mobile network
Mobile Node (MN) detects his movement by receiving a Routing advertisement
from a router, then he generates his Care-of-Address (COA) with a stateless
or a stateful address allocating procedure. MN sends this information to
his Home Agent (HA) by a Binding Update (BU) message. HA modifies the
information on the address entry in his Binding Cache and returns a Binding
Acknowledgement (BAck) message to MN. Packets from a Correspondent Node
(CN) or the other node to the shadow of the Home Address of MN are blocked
by the HA and are tunneled to the MN for the destination in the Binding
Cache.
At this situation, smooth handoff operation will be available with the
extension that MN can treat multiple Care-of-Address (COA) and that HA sends
a multicast packet to the appropriate subnets.
Normally, Mobile Station (terminal) in current cellular system has a
function of selecting the Base Station (BS) which can receive the data with
the best condition [9]. Applying this method, MN is able to get multiple
information about BSs. If the MN receives some IPv6 prefix announcements
from the subnets, MN can generate multiple COAs. When MN sends them to HA
by the Binding Update (BU) message, HA can create the addresses in his
Binding Cache to multicast. Differing from the MIPv6, it is important that
the HA should be able to treat multiple addresses for a single MN.
Modification to the BS nor to the router is not needed.
Now, assume that MN generates the two COAs (COA#1 and COA#2), MN will send
these addresses to his HA by BU message. Original Mobile IPv6 requires MN
to select primary COA from candidate and send BU message to HA. It requires
also HA to keep only one binding cache. By our extension, MN treats each
address equally and makes BU for each of them. HA generates the appropriate
entry for each of them without overwriting previous entry in their Binding
Cache.
Packets from a CN or the other node to the shadow of the Home Address are
blocked by the HA and are compared with the Binding Cache. Because the entry
for the MN has two COAs, HA multicasts the packet to the MN with the Xcast6
extension header (Fig.3.2 and Fig.3.3).
CN HA BS1 BS2 BS3 MN
| | | | | |
| | | | (Subnet Info.) |
| | +---------------------------->|Genarate COA#1
| | | | (Subnet Info.) |
| | | +------------------>|Generate COA#2
| | | (BUs for COA#1 & COA#2) |
| |<--------------------------------------+
| |<--------------------------------------+
| | | | | |
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+---------------------------->|
| | \ | | | |
| | +===========+------------------>|
| | | | | |
| | | | | |
Fig.3.2 Multiple COA registration and packet multicast
+---------------------------------------+
| IPv6 Header |
| (Source & Destination addresses) |
+=======================================+ ===
| Routing Extension Header | |
| (Explicit address list of Xcast6) | |
+---------------------------------------+ for Xcast6 operation
| Destination Extension Header | |
| (List of ports: Option) | |
+=======================================+ ===
| Destination Option Headers | |
| (Binding-Acknowledgement if needed) | |
+---------------------------------------+ |
| Authentication Header | for Mobile IPv6 operation
| (to Authenticate MN-HA) | |
+---------------------------------------+ |
| Encapsulating Security Payload | |
| (for tunneling a user datagram) | |
+---------------------------------------+ |
| | |
| (datagram from a CN) | |
| | |
| | |
+---------------------------------------+ ===
Fig.3.3 Packet format from the HA
Using Xcast6 extension, smooth handoff for MIPv6 is realized. We show the
example in Fig.3.4. Even if the receiving condition from BS1 becomes wrong,
multicast packet can still receive via BS2, then a session will not break.
If the air-link to the BS3 will be activate, sending COA#3 to the HA, MN
can receive the multicast packet from BS3. In this way, seamless
communication can be realized.
CN HA BS1 BS2 BS3 MN
| | | | | |
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+--..........(hard to receive)|
| | \ | | | |
| | +===========+------------------>|
| | | (BU for COA #3) |
| |<--------------------------------------+
| | | (BU: Delete COA #1) |
| |<--------------------------------------+
| Packet | | | | |
+-------->|multicast| | | |
| +===+ | | | |
| | \ | | | |
| | +=============+------------------>|
| | \ | | | |
| | +=====================+-------->|
| | | | | |
| | | | | |
Fig.3.4 Smooth handoff sequence example
To save the resource of the air-link, MN may select one of the packets sent
via multicast distribution. It will be accomplished by making a negotiation
between BS and MN (Fig.3.5). The negotiation will be available with Layer
2 or Layer 3 function. The detail should be for further study. Packets in
the air-links which are not activated are deleted silently by the BS.
ICMP-Destination Unreachable error must not be returned [6]. Actually,
delete process are defined by the option header on the multicast packet
[3].
CN HA BS1 BS2 BS3 MN
| | | | | |
| | | | |(inactivation)
| | | | |<--------+
| Packet | | | | |
+-------->|multicast| | | |
| +===+ | | | |
| | \ | | | |
| | +=============+------------------>|
| | \ | | | |
| | +=====================+-X |
| | | | | |
| | | | | |
Fig.3.5 Air-link operation
If MN cannot receive the packet from BS2 by the movement of MN, fast handoff
is available only activating the air-link to the BS3 (Fig.3.6).
CN HA BS1 BS2 BS3 MN
| | | | | |
| | | | |(activation)
| | | | |<--------+
| | | | |(inactivation)
| | | |<------------------+
| Packet | | | | |
+-------->|multicast| | | |
| +===+ | | | |
| | \ | | | |
| | +=============+-X | |
| | \ | | | |
| | +=====================+-------->|
| | | | | |
| | | | | |
Fig.3.6 Fast handoff by air-link operation
In addition, it is applicable to use the route optimization procedure of
MIPv6. In this environment, CN must have a function of receiving the BU
message and sending the Xcast6 packets like HA.
The method for the authentication and the integrity of the data is based
on the MIPv6. In other words, security association should be created between
MN and HA or MN and CN, then Authentication Header (AH) and Encapsulating
Security Payload (ESP) are used.
4. MN operation
In this section, we describe the detail operation of the Mobile Node (MN)
and the modification from the original Mobile IPv6 (MIPv6) specification
[1].
Basically, MN operation is compatible with MIPv6. Route optimization is
also available. With our extension, MN may require the multicast
distribution to his Home Agent (HA) or the Correspondent Node (CN). This
function has an advantage when the MN rapidly moves through multiple
subnets.
4.1 Address registration
MN generates his Care-of-Address (COA) by the Router advertisement from
the routers. At the same time, MN gets the HA lists by ICMP-Address Discovery
procedure [1]. MN sends his COA to his HA by the Binding Update (BU) message.
If the registration on the HA is succeeded, MN is ready to receive the
packets after receiving the Binding Acknowledgement (BAck) message.
A packet from a CN or the other node to the shadow of the MN on the home
link is blocked by the HA and tunneled to the MN according to HA's Binding
Cache.
4.2 Multiple subnet registration
If the MN is available to receive the multiple information of the subnets,
MN may register the multiple COAs to a HA repeating the procedure on the
section 4.1.
Now assume that a MN receives the two Care-of-Address (COA) of COA#1 and
COA#2 on the network in Fig.3.1. If the HA is Xcast6-aware, MN may send
these COAs to a HA with the BU message individually. We show a registration
sequence in Fig.4.1. The packet format for BU message is the same as that
of the MIPv6 (Fig.4.2).
CN HA BS1 BS2 BS3 MN
| | | | | |
| | | | (Subnet Info.) |
| | +---------------------------->|Genarate COA#1
| | | (BU for COA #1)| |
| |<--------------------------------------+
| | | | (Subnet Info.) |
| | | +------------------>|Generate COA#2
| | | (BU for COA #2)| |
| |<--------------------------------------+
| | | | | |
| | | | | |
Fig.4.1 Binding Update for individual registration
+---------------------------------------+
| IPv6 Header |
| (Source & Destination addresses) |
+---------------------------------------+ ===
| Destination Option Headers | for Mobile IPv6 operation
| (for Binding-Update) | |
+---------------------------------------+ ===
| |
| (datagram for a HA) |
| |
| |
+---------------------------------------+
Fig.4.2 Packet Format for Binding Update message
4.3 Multicast the packet for tunneling
HA will block a packet to the Home Address of MN and multicast it with adding
the Xcast6 header including all the registered addresses. Procedure is
shown in Fig.4.3. Packet format from HA is shown in Fig.4.4.
CN HA BS1 BS2 BS3 MN
| | | | | |
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+---------------------------->|
| | \ | | | |
| | +===========+------------------>|
| | | | | |
| | | | | |
Fig.4.4 Packet multicast from HA
+---------------------------------------+
| IPv6 Header |
| (Source & Destination addresses) |
+=======================================+ ===
| Routing Extension Header | |
| (Explicit address list of Xcast6) | |
+---------------------------------------+ for Xcast6 operation
| Destination Extension Header | |
| (List of ports: Option) | |
+=======================================+ ===
| Destination Option Headers | |
| (for Binding-Acknowledgement) | |
+---------------------------------------+ |
| Authentication Header | for Mobile IPv6 operation
| (to Authenticate MN-HA) | |
+---------------------------------------+ |
| Encapsulating Security Payload | |
| (for tunneling a user datagram) | |
+---------------------------------------+ |
| | |
| (datagram from a CN) | |
| | |
| | |
+---------------------------------------+ ===
Fig.4.4 Packet format from the HA
4.4 Selection of links for BSs
To save the bandwidth of the air-link, MN should decide the Base Station
(BS) to receive the packet, and negotiate with it before receiving the
packet. For example, MN can receive a packet only from the BS1 inactivating
the link to BS2 (Fig.4.5). The procedure of the negotiation is considered
in Layer 2 or Layer 3. A detail is for further study.
CN HA BS1 BS2 BS3 MN
| | | | | |
| | | | (inactivation)|
| | | |<------------------+
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+---------------------------->|
| | \ | | | |
| | +===========+-X | |
| | | | | |
| | | | | |
Fig.4.5 Link selection for BS
If the MN uses a xcast extension of this draft, when MN moves the other
subnet that are already registered, fast handoff is available only
activating the appropriate air-link between the BS and the MN (Fig.4.6).
CN HA BS1 BS2 BS3 MN
| | | | | |
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+---------------------------->|
| | \ | | | |
| | +===========+-X | |
| | | | (activation)|
| | | |<------------------+
| | | | (inactivation)|
| | |<----------------------------+
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+-X | | |
| | \ | | | |
| | +===========+------------------>|
| | | | | |
| | | | | |
Fig.4.6 Fast handoff by the control of Link selection for BS
4.5 Route optimization
On receiving a packet via the HA, MN may send a BU message to the CN based
on the MIPv6 route optimization procedure. After confirming the capability
of Xcast6, MN may send some COAs to the CN. If the CN is Xcast6-aware,
multicast packet will be sent with a Xcast6 header. Otherwise, CN will send
a unicast packet to the destination of MN.
If a MN sends the BU messages to the CN with two COAs (COA#1 and COA#2),
CN will multicast the Xcast6 packet including these COAs (Fig.4.7). Packet
format from CN is also shown in Fig.4.8.
CN HA BS1 BS2 BS3 MN
| | | | | |
| Packet | | | | |
+-------->|multicast| | | |
| +=====+===+---------------------------->|
| | \ | | | |
| | +===========+-X | |
| | | | | |
| | | (BUs for COA#1 & COA#2) |
|<------------------------------------------------+
|<------------------------------------------------+
| | | | | |
| Packet | | | | |
+=====+=============+---------------------------->|
| \ | | | | |
| +=====================+-X | |
| | | | | |
| | | | | |
Fig.4.7 Route optimization
+---------------------------------------+
| IPv6 Header |
| (Source & Destination addresses) |
+=======================================+ ===
| Routing Extension Header | |
| (Explicit address list of Xcast6) | |
+---------------------------------------+ for Xcast6 operation
| Destination Extension Header | |
| (List of ports: Option) | |
+=======================================+ ===
| Destination Option Headers | |
| (for Binding-Acknowledgement) | |
+---------------------------------------+ |
| Authentication Header | for Mobile IPv6 operation
| (to Authenticate MN-CN) | |
+---------------------------------------+ |
| Encapsulating Security Payload | |
| (for tunneling a user datagram) | |
+---------------------------------------+ |
| | |
| (datagram from a CN) | |
| | |
| | |
+---------------------------------------+ ===
Fig.4.8 Packet format from the CN
5. HA/MAP operation
In this section, we describe the detail function of the Home Agent (HA)
and modification from the Mobile IPv6 (MIPv6) specification [1].
Basically, the HA actions are the same as that of the MIPv6 specification.
Adding our extension, the fast handoff operation will be available without
re-routing in the wired network. Mobility Access Point (MAP) defined in
hierarchical MIPv6 [2] can be used for the backward compatibility or for
policy reasons.
5.1 Sending a Router Advertisement message
HA sends a Router Advertisement message to his network. After relayed
through the routers, a Mobile Node (MN) receives the message. This operation
is the same as the MIPv6 [1].
5.2 Receiving a Binding Update message
In original MIPv6, Binding Cache is modified by the information of the BU
message which HA received recently. In the Xcast6 extension, adding the
previous BU information, MN may send the new subnet information with BU
message. Therefore, we introduce a new procedure for HA to add the new
multicast entry in the Binding Cache. The deadline of the information is
administrated by the 'Lifetime' in the BU message. To delete an entry in
the Binding Cache, MN should send a BU message with Lifetime equal zero.
5.3 Forwarding the packets from CN
A packet from a Correspondent Node (CN) or the other nodes to the shadow
on the Home Address is blocked by HA. HA sends it to the MN's addresses
written in the Binding Cache. The packet are encapsulated by HA based on
the MIPv6 specification and are added the explicit multicast addresses on
the option header of the Xcast6.
5.4 Action of the Xcast6-unaware HA
If a HA is not Xcast6-aware, HA acts as the original MIPv6 HA. On
initialization sequence, MN should make a negotiation with his HA to check
the capability of Xcast6-awareness. This procedure is for further
study.
6. CN operations
In this section, we describe the detail action of the Correspondent Node
(CN) and the modification from the Mobile IPv6 (MIPv6) specification [1].
Basically, the action of the CN is the same as that of MIPv6. Route
optimization is also available.
6.1 Triangle routing (CN -> HA => MN)
Before a route optimization, CN sends a normal packet to a shadow of the
Mobile Node (MN) on the Home Link. The packet is tunneled by the Home Agent
(HA), then sent to the actual MN. A packet from the MN to the CN is sent
directly.
6.2 Route optimization (CN => MN)
If a CN is Xcast6-aware, when the MN sends the route optimization
requirement, MN may send some COAs to the CN. CN will register these
addresses on his Binding Cache and send the success information over a
Binding Acknowledgement (BAck) message.
CN will multicast a packet including the explicit destination addresses
of COAs on the Xcast6 extension header.
6.3 Action of the Xcast6-unaware CN
If a CN is not Xcast6-aware, CN acts as the original MIPv6 CN. MN may also
realize the fast handoff by sending a packet to the Xcast6-aware HA. The
selection of sending a CN's packet directly to MN or via HA is decided by
the MN. Notice that MN should send the COA to CN concerning the air-link
activated by MN.
On initialization sequence, MN should make a negotiation with his CN to
check the capability of Xcast6-awareness. This procedure is for further
study.
6.4 Consideration about MN-MN operation
If the Xcast6-aware CN is also a MN, a communication may be done between
each MN. Basically, this operation will be available with our extension.
A packet to control a MIPv6 may be piggy-backed on the Xcast6 multicast
packet. A detail operation is for further study.
7. Compatibility of existing Mobile IPv6 specification
In the extension of this draft, there are few modifications from the Mobile
IPv6 [1] or the hierarchical Mobile IPv6 [2] specification. Home Agent (HA)
or Mobility Access Point (MAP) may be added the Small Group Multicast (SGM)
function by adding the routing header of the addresses registered by the
BU messages. If the HA or the MAP is not Xcast6-aware, HA/MAP is still act
as an ordinary MIPv6/HMIPv6 node.
MN is needed to add the functions of sending the multiple subnet information
and selecting the one of subnets. A protocol to select a subnet will be
considered in Layer 2 or Layer 3. MN also needs to have a negotiation
function to recognize that the HA and CN are Xcast6-aware. These protocols
are for further study.
7.1 Data structures
The Mobile IPv6 (MIPv6) specification defines some conceptual data
structures [1]. In this section, we will review them briefly then make clear
the part to modify for the Xcast6 extension.
Binding Cache:
A cache, maintained by each IPv6 node, of bindings for other nodes. When
sending a packet, the Binding Cache is searched before the Neighbor
Discovery conceptual Destination Cache [14]. Each Binding Cache entry
conceptually contains the following fields:
- The home address of the mobile node.
- The care-of address (COA) for the mobile node indicated by the home
address field in this Binding Cache entry. In the Xcast6 extension,
plural entries are needed to record the addresses corresponding to
the Xcast6 routes.
- A lifetime value, indicating the remaining lifetime for this Binding
Cache entry. In the Xcast6 extension, the lifetime value for each
COA is maintained individually. They are initialized from the
Lifetime field in the Binding Update (BU) that created or last
modified this Binding Cache entry.
- A flag indicating whether or not this Binding Cache entry is a "home
registration" entry.
- A flag indicating whether or not this Binding Cache entry represents
a mobile node that should be advertised as a router in proxy Neighbor
Advertisements sent by this node on its behalf. This flag is only
valid if the Binding Cache entry indicates that this is a "home
registration" entry.
- The value of the Prefix Length field received in the Binding Update
that created or last modified this Binding Cache entry. This field
is only valid if the "home registration" flag is set on this Binding
Cache entry.
Below three fields are created and maintained individually corresponding
to the COAs to be multicasted.
- The maximum value of the Sequence Number field (16 bits) received
in previous Binding Updates for this mobile node home address.
- Recent usage information for this Binding Cache entry.
- The time at which a Binding Request was last sent for this entry.
Binding Update List:
A list, maintained by each mobile node, recording information for each
Binding Update sent by this mobile node, for which the Lifetime sent in
that Binding Update has not yet expired. The Binding Update List includes
all bindings sent by the mobile node: those to correspondent nodes, those
to the mobile node's home agent, and those to a home agent on the link on
which the mobile node's previous care-of address is located. In the Xcast6
extension, entries are created and maintained individually corresponding
to each COA to be multicast. Each Binding Update List entry conceptually
contains the following fields:
- The IP address of the node to which a Binding Update was sent.
- The home address for which that Binding Update was sent.
- The care-of address sent in that Binding Update.
- The initial value of the Lifetime field sent in that Binding Update.
- The remaining lifetime of that binding. This lifetime is initialized
from the Lifetime value sent in the Binding Update and is decremented
until it reaches zero, at which time this entry MUST be deleted from
the Binding Update List.
- The maximum value of the Sequence Number field sent in previous
Binding Updates to this destination.
- The time at which a Binding Update was last sent to this destination,
as needed to implement the rate limiting restriction for sending
Binding Updates.
- The state of any retransmissions needed for this Binding Update,
if the Acknowledge (A) bit was set in this Binding Update. This state
includes the time remaining until the next retransmission attempt
for the Binding Update, and the current state of the exponential
back-off mechanism for retransmissions.
- A flag that indicates that future Binding Updates should not be sent
to this destination.
Home Agents List:
A list, maintained by each home agent and each mobile node, recording
information about each home agent from which this node has received a Router
Advertisement in which the Home Agent (H) bit is set, for which the remaining
lifetime for this list entry (defined below) has not yet expired. The home
agents list is thus similar to the Default Router List conceptual data
structure maintained by each host for Neighbor Discovery [14], although
the Home Agents List MAY be implemented in any manner consistent with the
external behavior described in this document.
In the Xcast6 extension, there is no modification for this list. Each Home
Agents List entry conceptually contains the following fields:
- The link-local IP address of a router on the link that this node
currently believes is operating as a home agent for that link. A new
entry is created or an existing entry is updated in the Home Agents
List in response to receipt of a valid Router Advertisement in which
the Home Agent (H) bit is set. The link-local address of the home
agent is learned through the Source Address of the Router
Advertisements received from it [14].
- One or more global IP addresses for this home agent, learned through
Prefix Information options with the Router Address (R) bit set,
received in Router Advertisements from this link-local address.
- The remaining lifetime of this Home Agents List entry.
- The preference for this home agent taken from the Home Agent
Preference field; higher values indicate a more preferable home
agent.
8. Security consideration
The extension of this draft has a compatibility with the AAA (Authentication,
Authorization and Accounting) function studied in the Mobile IPv6 (MIPv6)
[1]. The procedure of the authentication and the integrity of a packet will
be based on the MIPv6 specification. In other words, security associations
are engaged between a Mobile Node (MN) and a Home Agent (HA) or MN and
Correspondent Node (CN). Authentication Header (AH) and Encapsulating
Security Payload (ESP) are also used.
In addition, a further AAA function based on the MIPv6 should be adapted
as it is.
9. References:
[1] D. Johnson and C. Perkins, "Mobility Support in IPv6",
<draft-ietf-mobileip-ipv6-13.txt>, November 2000.
[2] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier,
"Hierarchical MIPv6 mobility management",
<draft-ietf-mobileip-hmipv6-00.txt>, October 2000.
[3] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", rfc2460, December 1998.
[4] C. Perkins, Editor. "IP Mobility Support", rfc2002, October 1996.
[5] IMAI Yuji, "Multiple Destination option on IPv6(MDO6)",
<draft-imai-mdo6-01.txt>, March, 2000.
[6] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6) Specification", rfc2463,
December 1998.
[7] "Small Group Multicast (sgm) BOF" agenda,
http://www.ietf.org/ietf/00jul/sgm-agenda.txt
[8] IANA, "IP Address Services",
http://www.iana.org/ipaddress/ip-addresses.htm
[9] S. Seshan, "Low-Latency Handoff for Cellular Data Networks", Ph.D.
Thesis, University of California at Berkeley, December 1995.
http://www.seshan.org/papers.html
[10] J. Mysore and V. Bharghavan, "A New Multicasting-Based Architecture
for Internet Host Mobility", ACM Mobicom'97, Budapest, Hungary, October
1997.
[11] Ahmed Helmy, "Multicast-based Architecture for IP Mobility:
Simulation Analysis and Comparison with Basic Mobile IP", Technical
Report USC Computer Science Department, 2000
[12] James D. Solomon, "Mobile IP", Prentice-Hall, 1998.
[13] R. Boivie, N. Feldman, Y. Imai, W. Livens, D. Ooms, O. Paridaens,
"Explicit Multicast (Xcast) Basic Specification",
<draft-ooms-xcast-basic-spec-01.txt>, March, 2001.
[14] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version
6 (IPv6)", rfc2461, December 1998.
10. Changes
<V00 -> V01>
- Modified the descriptions in the chapter of the 'Overview of Small Group
Multicast'. (Section 2)
- Added the Xcast Basic Specification to the references[13].
- Added the data structures (e.g. Binding Cache, Binding Update List) in
the HA/MN/CN according to the MIPv6 specification. (Section 7.1)
11. Authors addresses
Contact:
Yutaka Ezaki
ezaki@flab.fujitsu.co.jp
Yuji Imai
kimai@flab.fujitsu.co.jp
Mail:
Fujitsu Laboratories Ltd.
4-1-1 Kami-kodanaka, Nakahara-ku,
Kawasaki, 211-8588, Japan
Phone: +81-44-754-2623
Fax: +81-44-754-2741
Internet Draft draft-ezaki-handoff-xcast-01.txt May 2001