INTERNET DRAFT Yutaka Ezaki May 2001 Yuji Imai Expires December 2001 Fujitsu Labs. Mobile IPv6 handoff by Explicit Multicast 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", , November 2000. [2] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier, "Hierarchical MIPv6 mobility management", , 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)", , 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", , March, 2001. [14] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", rfc2461, December 1998. 10. Changes 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