INTERNET DRAFT Yutaka Ezaki November, 2000 Yuji Imai Expires May 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: Actual Mobile IPv6 handoff involves two types of the network: 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 for the Small Group Multicast (SGM). On the wired section, control/user packets are multicasted by xcast to the Base Stations where MN can access, then packets are passed to the air-link activated between a BS and the MN. 1. Introduction In this draft, we propose another fast 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 through to the MN. Recently, fast handoff or smooth handoff method 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 hierarchical MIPv6 (HMIPv6) [2] comes from the restriction that a packet from the CN must NOT duplicate over the network (e.g. CN-HA-MN). Actual MIPv6/HMIPv6 handoff involves two type of the network: re-routing on the wired region of the network and the activation of the air-link on the wireless region. In the mobile world, the resource for the air-link is still important, whereas resource on wired network is becoming sufficient since the development of the transport equipment (e.g. WDM) is distinctive. A cellular phone service achieves fast hand off procedure 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 the BS which receives 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. The datagram of 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. Basic mechanism and many protocols have been proposed and experimented. However, present multicast technique has some problems that it requires a state management for each group address or scaling of the network. Actually, a BoF has been established to study the multicast technique for small group on IPv4/IPv6 environment without a complex routing protocol [7]. Small Group Multicast (SGM) is based on the 'xcast' (explicit multicast) technique which means that the multicast datagrams includes all the addresses to deliver on each packet header. 2.1 MDO6 overview There are several experimental variant protocols proposed in SGM/xcast BoF. Conceptually, smooth handoff for Mobile IP can be applied onto any xcast variants. In this draft, we explain the principle of handoff by xcast describing handoff by MDO6 (Multiple Destination Option on IPv6) that is our variant of xcast. MDO6, as well as other 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. The list is stored in an IPv6 routing option header with a bitmap that represents the destinations to send. The router looks up the next hop of each unicast address, using their unicast routing table, if their bitmap is on. Comparing the result of routing lookup, the router can analyze that destinations has common path for the following routers or not. Then routers duplicate the datagram and diverge it for the other path if needed. Since routers can branch and forward the MDO6 datagram only by unicast routing table, it has a good scalability concerning with the number of multicast group that is necessary for our handoff. Header formats extended in MDO6 and detail behaviors of a router are explained in [5]. 3. Fast handoff extension for Mobile IPv6 by MDO6 In this section, we describe the fast handoff extension for Mobile IPv6 (MIPv6) [1] using Small Group Multicast (SGM) especially about Multiple Destination Option for IPv6 (MDO6) 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 MDO6 option 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) | +---------------------------------------+ === | Hop-by-hop Option Header | | | (Tail of address list for MDO6) | | +---------------------------------------+ | | Routing Option Header | for MDO6 operation | (Explicit multicast addresses) | | +---------------------------------------+ | | Destination Option Header | | | (Dummy) | | +---------------------------------------+ === | 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 MDO6 extension, smooth handoff 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 should 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 MDO6 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. 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 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 MDO6-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 MDO6 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) | +---------------------------------------+ === | Hop-by-hop Option Header | | | (Tail of address list for MDO6) | | +---------------------------------------+ | | Routing Option Header | for MDO6 operation | (Explicit multicast addresses) | | +---------------------------------------+ | | Destination Option Header | | | (Dummy) | | +---------------------------------------+ === | 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 MDO6, MN may send some COAs to the CN. If the CN is MDO6-aware, multicast packet will be sent with a MDO6 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 MDO6 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) | +---------------------------------------+ === | Hop-by-hop Option Header | | | (Tail of address list for MDO6) | | +---------------------------------------+ | | Routing Option Header | for MDO6 operation | (Explicit multicast addresses) | | +---------------------------------------+ | | Destination Option Header | | | (Dummy) | | +---------------------------------------+ === | 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 MOD6 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 MDO6. 5.4 Action of the MDO6-unaware HA If a HA is not MDO6-aware, HA acts as the original MIPv6 HA. On initialization sequence, MN should make a negotiation with his HA to check the capability of MDO6-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) In the triangle routing, 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 MDO6-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 MDO6 option header. 6.3 Action of the MDO6-unaware CN If a CN is not MDO6-aware, CN acts as the original MIPv6 CN. MN may also realize the fast handoff by sending a packet to the MDO6-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 MDO6-awareness. This procedure is for further study. 6.4 Consideration about MN-MN operation If the MDO6-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 for MIPv6 control may be piggy-backed on the MDO6 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 MDO6-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 MDO6-aware. These protocols are for further study. 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", , February 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. 10. 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 /end