INTERNET DRAFT Yutaka Ezaki June 2002 Yuji Imai Expires January 2003 Fujitsu Labs. Mobile IPv6 handoff by Explicit Multicast <draft-ezaki-smoothhandoff-xcast6-00.txt> Status of This Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract: A handover process on Mobile IPv6 requires a time period referred as handoff latency. This latency is not acceptable to support real-time application. We propose a new smooth 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 Mobile Node (MN) can receive, and then packets are passed to the air-link activated between a BS and the MN. This procedure provides mobility in heterogeneous media environment because this handoff mechanism is basically able to implemented without additional control or intelligence of neither intermediate routers. 1. Introduction In this draft, we propose another 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-handover method is proposed [2]. Fast-handover process is executed by the Access Routers (ARs) on the old subnet and the new subnet with a complex handover sequences and a tunnel between two ARs. The complexity of current MIPv6 or fast-handover 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 because of the remarkable development of the transport equipment (e.g. WDM). Actual MIPv6 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. The MN to select some BSs, which receive the packet with the best condition, can realize low delay and no packet loss. 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. In this draft, we propose a smooth handoff method for MIPv6 by SGM/Xcast6 with few modifications to the MIPv6 architecture. This handoff mechanism provides mobility in heterogeneous media environment because this handoff mechanism is basically able to implement without additional control or intelligence of neither intermediate routers. SGM/Xcast6 technique supplements a classical multicast. Since Xcast6 has some characteristics that intermediate routers forward multicast datagrams only by unicast routing information, Xcast6 supports huge number of restless multicast groups that is necessary for handoff. 2. Overview of Small Group Multicast Multicast technique is important for the broadcast application, many-to-many videoconference, 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]. In the next section, we introduce a summary of the spec. 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: node 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]. Recently, some implementations and applications are published for NetBSD and Linux [15]. 3. Fast handoff extension for Mobile IPv6 by Xcast6 In this section, we describe the fast handoff extension for Mobile IPv6 (MIPv6) [1] using Xcast6 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 MN detects his movement by receiving a Router Advertisement from a router, and 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 MN on the Home Link are blocked by the HA and are tunneled to the MN for the destination in his Binding Cache. At this situation, smooth handoff operation will be available with the extension that MN can treat multiple Care-of-Addresses (COAs) 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 keeping only one entry of the 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 MN on its Home Link 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 +---------------------------------------+ | Outer IPv6 Header | | (SRC=HA, DST=one of CoAs) | +=======================================+ === | Inner IPv6 Header | | | (SRC=HA, DST='all_xcast address') | | +---------------------------------------+ for Xcast6 operation | Routing Extension Header | | | (Explicit address list of Xcast6) | | +=======================================+ === | Destination Option Headers | | | (Binding-Acknowledgement if needed) | for Mobile IPv6 operation +=======================================+ === | Original IPv6 Header | | | (SRC=CN, DST=MN's Home Address) | | +---------------------------------------+ original IPv6 packet | | | | (datagram from a CN) | | | | | | | | +---------------------------------------+ === Fig.3.3 Packet format from the HA to MN 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, and 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. The BS deletes packets silently in the air-links that are not activated. 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 link exchange is available by the procedure in the 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. A packet format is like Fig.3.7. +---------------------------------------+ | Outer IPv6 Header | | (SRC=CN, DST=one of CoAs) | +=======================================+ === | Inner IPv6 Header | | | (SRC=CN, DST='all_xcast address') | | +---------------------------------------+ for Xcast6 operation | Routing Extension Header | | | (Explicit address list of Xcast6) | | +=======================================+ === | Destination Option Headers | | | (Binding-Acknowledgement if needed) | for Mobile IPv6 operation +=======================================+ === | Original IPv6 Header | | | (SRC=CN, DST=MN's Home Address) | | +---------------------------------------+ original IPv6 packet | | | | (datagram from a CN) | | | | | | | | +---------------------------------------+ === Fig.3.7 Packet format from the CN to MN 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 | (Binding-Update & Home Address option)| | +---------------------------------------+ === | | | (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. Note: The BAck message may be either piggy-backed on a multicast packet or a unicast (i.e. non piggy-backed) packet. CN HA BS1 BS2 BS3 MN | | | | | | | Packet | | | | | +-------->|multicast| | | | | +=====+===+---------------------------->| | | \ | | | | | | +===========+------------------>| | | | | | | | | | | | | Fig.4.3 Multicast a packet from HA +---------------------------------------+ | Outer IPv6 Header | | (SRC=HA, DST=one of CoAs) | +=======================================+ === | Inner IPv6 Header | | | (SRC=HA, DST='all_xcast address') | | +---------------------------------------+ for Xcast6 operation | Routing Extension Header | | | (Explicit address list of Xcast6) | | +=======================================+ === | Destination Option Headers | | | (Binding-Acknowledgement if needed) | for Mobile IPv6 operation +=======================================+ === | Original IPv6 Header | | | (SRC=CN, DST=MN's Home Address) | | +---------------------------------------+ original IPv6 packet | | | | (datagram from a CN) | | | | | | | | +---------------------------------------+ === Fig.4.4 Packet format from the HA to MN 4.4 Selection of links for BSs To save the bandwidth of the air-link, MN may 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 Xcast6 extension of this draft, when MN moves the other subnet that are already registered, fast link change 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 link change sequence 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 an 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 +---------------------------------------+ | Outer IPv6 Header | | (SRC=CN, DST=one of CoAs) | +=======================================+ === | Inner IPv6 Header | | | (SRC=CN, DST='all_xcast address') | | +---------------------------------------+ for Xcast6 operation | Routing Extension Header | | | (Explicit address list of Xcast6) | | +=======================================+ === | Destination Option Headers | | | (Binding-Acknowledgement if needed) | for Mobile IPv6 operation +=======================================+ === | Original IPv6 Header | | | (SRC=CN, DST=MN's Home Address) | | +---------------------------------------+ original IPv6 packet | | | | (datagram from a CN) | | | | | | | | +---------------------------------------+ === Fig.4.8 Packet format from the CN to MN 5. HA 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, a smooth handoff operation will be available without re-routing in the wired network. 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 Binding Update (BU) message that 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. When the MN sends an extra COA with a BU message, MN sets the 'X'-bit to inform to use the multiple COA procedure. If the HA is Xcast6-aware, HA adds this COA, and returns a Binding Acknowledge (BAck) message with the 'X'-bit still set. Otherwise HA replace the old COA with the new COA. Then HA returns a BAck message with the 'X'-bit not set. The formats of the BU and BAck message are described in chapter 7. 5.3 Forwarding the packets from CN A packet from a Correspondent Node (CN) or the other nodes to the shadow of MN on the Home Link 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 binding sequence, MN should make a negotiation with his HA to check the capability of Xcast6-awareness. This procedure has described in section 5.2. 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), and 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 by the Binding Update (BU) message with the 'X'-bit set. 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 still 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 binding sequence, MN should make a negotiation with his CN to check the capability of Xcast6-awareness. This procedure has already described in section 5.2. 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 control message of the MIPv6 may be piggy-backed on the Xcast6 multicast packet. A detail operation is for further study. 7. Message format To inform the Xcast6 awareness, we need to add the 'X'-bit to the Binding Update and Binding Acknowledge messages. 7.1 Modified Binding Update (BU) Message The Binding Update (BU) message is used by a Mobile Node (MN) to notify other nodes of a new care-of address for itself. The BU message uses the Mobility Header (MH) Type value 5. When MN sends the additional COA, MN sets 'X'-bit as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D| Reserved |X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extra COA (X) The Extra COA (X) bit is set by the sending mobile node to request a new entry of the COA for Xcast6 operation. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Another flags and parameter fields have the same meaning of original MIPv6 [1]. 7.2 Binding Acknowledgement (BAck) Message The Binding Acknowledgement message is used to acknowledge receipt of a BU message. When an Xcast6-aware node receives a packet containing a Binding Update message, with this node being the destination of the packet, this node MUST return a Back message to the mobile node, with the 'X'-bit still set. Otherwise, a node resets the 'X'-bit. The BAck message has the MH Type value 6. Format is as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved |X| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extra COA (X) The Extra COA (X) bit is set by the sender to inform the request of creating a new entry of the COA is accepted. Reserved These fields are unused. They MUST be initialized to zero by the sender and MUST be ignored by the receiver. Status 8-bit unsigned integer indicating the disposition of the Binding Update. Values of the Status field are the same as defined in [1]. Another flags and parameter fields have the same meaning of original MIPv6 [1]. 8. Compatibility of existing Mobile IPv6 specification In the extension of this draft, there are few modifications from the Mobile IPv6 [1] specification. Home Agent (HA) 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 is not Xcast6-aware, HA is still act as an ordinary MIPv6 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 described in the previous chapter. 8.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. - Number of the COAs effective in this home address. - 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 six fields are created and maintained individually corresponding to the COAs to be multicasted. - A flag that indicate that this COA is available. - 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. - 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. 9. 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. 10. References: [1] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", <draft-ietf-mobileip-ipv6-17.txt>, May 2002. [2] G. Dommety, A. Yegin, C. Perkins, G. Tsirtsis, K. El-Malki, M. Khalil, " Fast Handovers for Mobile IPv6", <draft-ietf-mobileip-fast-mipv6-04.txt>, March 2002. [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. [15] Xcast6 implementation page. http://sourceforge.net/projects/xcast6 11. 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 8.1) <Xcast v01 -> Xcast6 v00> - Modified a file name. - Added a note that the BAck message may be either piggy-backed on a multicast packet or a unicast packet. (Section 4.3) - Added the Binding Update & Binding Acknowledge format to negotiate a capability of Xcast6 handoff. (Chapter 5 and Chapter 7) - Added the Xcast6 Implementation page [15]. - Updated the referenced document's revision [1], [2]. 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-777-1111 Fax: +81-44-754-2741 /end Internet Draft draft-ezaki-handoff-xcast6-00.txt June 2002