Submitted to the Mobile IP working group L. Rose Internet Engineering Task Force V. Magret INTERNET DRAFT Alcatel July 12, 2000 Simple Multicast Mobility Protocol (SMM) draft-rose-mobileip-smm-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. This document is an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the authors. Distribution of this memo is unlimited. This document is an Internet-Draft. 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. To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rose Expires January 12, 2001 [Page 1] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 Abstract The Simple Multicast Mobility Protocol (SMM) defines extensions and changes to Mobile IP [RFC2002] to extend the service offered by this protocol. The new features allows a new support of smooth handoffs. The service allows the support of both macro and micro mobility. The goal of the protocol is extend the services of mobile IP to cope with requirement coming from "real-time" applications such a voice over IP. Rose Expires January 12, 2001 [Page 2] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 Table of Contents 1. Introduction ................................................ 3 2. Conventions ................................................. 5 3. New Mobile IP extensions .................................... 5 3.1. Mobility Agent Advertisement Extension .................... 5 3.2. Foreign Agent Network Access Identifier extension ......... 6 3.3. Registration Request ...................................... 7 3.4. Registration Reply ........................................ 8 3.5. Source Specific Multicast address extension ............... 9 3.6. Multicast Subscription Request ............................ 9 3.7. Binding Update ............................................ 11 3.8. Source Update ............................................. 11 4. Protocol overview ........................................... 12 4.1. Registration process ...................................... 16 4.2. Traffic flow .............................................. 17 4.3. Moving in the wireless domain ............................. 17 4.4. Route optimization ........................................ 17 5. Change in the protocol behavior ............................. 18 5.1. Mobile node considerations ................................ 18 5.1.1. Receiving Agent advertisement Message ................... 18 5.1.2. Sending Registration Request ............................ 18 5.1.3. Receiving Registration Reply ............................ 19 5.1.4. Sending Multicast Subscription Request .................. 20 5.1.5. Receiving Source Update ................................. 20 5.2. Security considerations ................................... 21 5.2.1. Configuration and registration table .................... 21 5.2.2. Sending Agent Advertisement ............................. 21 5.2.3. Receiving Registration Request .......................... 21 5.2.4. Receiving Registration Reply ............................ 21 5.2.5. Receiving Multicast Subscription Request ................ 22 5.3. Home agent considerations ................................. 22 5.3.1. Configuration and registration tables ................... 22 5.3.2. Receiving registration request .......................... 22 5.3.3. Sending Registration Reply .............................. 23 5.3.4. Sending Binding Update .................................. 23 5.3.5. Sending Source Update ................................... 24 5.4. Correspondent node considerations ......................... 24 5.4.1. Sending Binding Request ................................. 24 5.4.2. Receiving Binding Update ................................ 24 5.4.3. Sending Binding Acknowledgement ......................... 25 6. Security considerations ..................................... 25 7. References .................................................. 25 Authors' addresses ............................................. 26 Rose Expires January 12, 2001 [Page 2] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 1. Introduction For many years, we are living explosive growth of the Internet and the increasing popularity of notebook type computers. Users are free to use their notebooks anywhere and because of the Internet popular- ity coming along with the huge information data-base and powerful tools it gives like email, more and more notebook user would like to maintain the Internet access while moving. With the current IP without mobility protocols, if a Mobile Host moves without changing its address, it will lose routing, but if the Mobile Host changes its address, it will lose connections. Host Mobility is not a new concept and there are already years of research in this area, with several proposals. The Internet Engineer- ing Task Force (IETF) has proposed Mobile IP [RFC2002] which allows computers to roam freely to other networks while still maintaining the same IP address. Mobile IP is a mean for providing location independent routing sup- port to a mobile node, which keeps the same IP address while changing location. This operation is transparent for the mobile's user. It is intended to enable nodes to move from one IP sub-net to another. Its principle is simple: Mobile IP does not use any physical layers nor make any assumption on it. Several special entities have been defined in the Mobile IP architecture proposed by the IETF. The Home Agent (HA) and the Foreign Agent (FA) work together to allow a user's Mobile Node (MN) to move freely around the Internet without changing its IP address. A user who wants to send packets to the Mobile Host is called a Correspondent Node (CN). Each network that wants to allow its users to roam to other network must have a Home Agent. Every site that wants to allow visitors must have a Foreign Agent. Any router on a network can serve as a Home Agent, Foreign Agent or both. When a MN gets connected to a foreign network, it uses the agent advertisement messages to locate a Foreign Agent that is willing to provide mobil- ity support the MN while attached to this foreign network. The agent advertisement message includes one or more care-of addresses. The MN must choose one care-of address. The MN registers using the registra- tion request messages and sends it to the FA. Then, the FA forwards the registration message to the user's Home Agent. The HA captures all datagram destined to the MN and encapsulates each CN's information using the care-of address, meaning the information is now routed toward the new FA using a tunnel. The FA decapsulates the incoming datagram and the original information is forwarded toward the MN. When Mobile IP was created in 1996, the mobility notion was not the same as now and users were not supposed to move often in large area Rose Expires January 12, 2001 [Page 3] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 with their mobile device. We could consider that mobile IP was offer- ing a "portability" service. The new mobility scheme we are nowadays facing requests a more stringent service. We are now facing an increasing number of mobile users requesting to be able to roam in a big geographical area. Such area encompasses different sub-networks, as it is not conceivable to have a single LAN covering the entire Los Angeles' area. People, for example, worked with their connected PDA on bus and train where change sub-network quiet often. With those new directions taken, Mobile IP protocol is facing the following problem: - The mobile may or may not keep on receiving the previous packets coming from the previous sub-network while moving toward a new sub-network - i.e. performing a handoff at the mobile IP level -, because this depends on the physical layer implementation of radio technologies, and Mobile IP does not use it. Thus, while activating the Mobile IP pro- tocol to register the new location with the HA so that information can be re-routed to the new sub-network, the mobile during this process will loose information still coming to the previous sub-network. This situation is not acceptable for applications requiring "real-time" behavior (e.g. voice over IP applications). - Mobile IP may not be a scalable solution, since the size of a routing table increases linearly with the number of mobile hosts and the frequency of updates to it is propor- tional to the frequency of handoffs in the system. One solution to the problem is to enlarge the sub-network notion to minimize the use of the number of Registration Request messages being sent to the HA. The Virtual Private Network notion (VPN) creating virtual sub-network could be used. We intend to propose here a much simpler and much more scalable solution. Our solution takes advantage of the domain concept and the topology of the domain (usually Tree-like). The SMM protocol defines an integrate macro/micro mobility scheme. The SMM protocol uses multicast to route to the mobile node. The new protocol is fully compliant with Mobile IP protocol, as it only defines extensions and changes to the base protocol. As one of the drawback of Mobile IP was that it was using triangle routing, the proposed extension also defines a way to avoid this tri- angle routing by suggesting an extension to the route optimization protocol [draft-ietf-mobileip-optim]. Rose Expires January 12, 2001 [Page 4] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 2. Convention The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Wireless domain (WD): The domain via which the user gains access to the Internet. The domain needs to be managed by a single entity for secu- rity and authorization reasons. Home Wireless Domain (HWD): The wireless domain in which the Home Agent of a Mobile Node is located. Foreign Wireless Domain (FWD): A Wireless Domain in which a Mobile Node does not have a Home Agent. Base station (BS): This is the end point of the wired network. It has an air interface. Several base stations may be linked to the same BSR. Cell: It is the area covered by a base station. Source Specific Multicast (SMM): Source Specific Multicast introduces the concept of chan- nel, which links the group address to a set of specific sources. The range from 232.0.0.0 to 232.255.255.255 is reserved for source specific multicast [draft-holbrook- ssm-00.txt]. 3. New Mobile IP extensions In this section, we identify the modifications to Mobile IP [RFC2002] necessary to implement the proposed protocol. 3.1. Mobility Agent Advertisement Extension Usage: In Simple Multicast extension for Mobile IP, Mobile IP "Mobil- ity Agent Advertisement Extension" is used by a Mobility Agent to Rose Expires January 12, 2001 [Page 5] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 advertise its capacity to support SSM as defined in [draft-holbrook- ssm-00.txt] 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Registration Lifetime |R|B|H|F|M|G|V|L| reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero or more Care-of Addresses | | - L: Source Specific Multicast bit. Simple Multicast extension for Mobile IP defines this bit to indicate that this Mobil- ity Agent supports SSM service. - All other fields keep their meaning as defined in mobile IP [RFC2002]. 3.2. Foreign Agent Network Access Identifier extension Usage: the Network Access Identifier extension MUST be sent along with the Agent Advertisement message if the FA set the Source Specific Multicast bit. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | FA-NAI ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: the length in bytes of the FA-NAI field. FA-NAI : A string in the NAI format as defined in the NAI Rose Expires January 12, 2001 [Page 6] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 specification [RFC2486]. 3.3. Registration Request Usage: The Mobile IP "Registration Request" MUST be set as defined in Mobile IP [RFC2002]. If the Mobility Agent has advertised its capacity to support Source Specific Multicast, the Mobile Node MAY use Source Specific Multicast bit in Mobile IP "Registration Request" to requests the SSM service to the Home Agent. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|L|P| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- - L: Source Specific Multicast bit. In Simple Multicast exten- sion for MobileIP, this bit indicates the mobile node's request to have its home agent assigning and using a SSM address. .IP "- P: " The private ('P') bit is set by the node sending the Binding Update message to indicate that the home agent MUST keep its mobility binding private. In any Binding Update message sent by the mobile node's home agent, the care-of address SHOULD be set equal to the mobile node's home address, and the lifetime SHOULD be set equal to 0. This bit is defined in [draft-ietf-mobileip- optim-09.txt]. - All other fields keep their meaning as defined in mobile IP [RFC2002]. Rose Expires January 12, 2001 [Page 7] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 3.4. Registration Reply The Mobile IP "Registration Reply" MUST be set as defined in Mobile IP [RFC2002]. 1. If the SSM service is supported by the Home Agent, and if the Home Agent does succeed the SSM address allocation as indicated in the Mobile IP "Registration Request", the Registration Reply Code value MUST be set to 0. The Simple Multicast extension for Mobile IP "Source Specific Multi- cast address extension" MUST be added at the end of the Registration Reply. 2. If the Home Agent supports SSM service, and if the Home Agent does not succeed the Mobile IP "Registration Request" SSM address allocation, the CODE option MUST be set accord- ingly to the reason. From now on, Mobile IP [RFC2002]MUST be used. 3. If the Home Agent does not support the SSM service, the CODE option MUST be set accordingly to the reason. From now on, Mobile IP [RFC2002] MUST be used. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+-+- Simple Multicast Mobility Protocol extension for Mobile IP introduces new codes: 2: registration successful but SSM not supported by the home agent. This code means that the mobile node is registered using Mobile IP as defined in [RFC2002]. Rose Expires January 12, 2001 [Page 8] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 3: registration successful but SSM not available (i.e. the home agent may support a limited number of SSM addresses). This code means that the mobile node is registered using Mobile IP as defined in [RFC2002]. 89: SSM is not supported by the Foreign Agent. 90: Source Specific Multicast Address not presents in the Home Agent's registration reply. _3._5. Source Specific Multicast address extension Usage: the Simple Multicast extension for Mobile IP "Source Specific Multicast address extension" is appended at the end of the home agent's Mobile IP "Registration Reply" and contains the source specific multicast address allocated for the mobile node. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Source Specific Multicast ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... address | +-+-+-+-+-+-+-+- Type: TBD Source Specific Multicast address: the SSM address assigned for the mobile node. The informa- tion related to the mobile is included in the mobile IP registration reply. The multicast address extension MUST be appended at the end of the mobile IP registration reply. 3.6. Multicast Subscription Request Usage: The MN sends the Multicast Subscription Request after detect- ing that it has moved from one FA to another, but both FAs belong to the same wireless domain. The message request the FA, which acts as a router for the MN, to deliver the datagram sent to the specified channel (i.e. combination of a source address(es) and a source specific multicast address. The subscription contains a lifetime, Rose Expires January 12, 2001 [Page 9] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 which indicates the maximum duration of the service. If the FA does not receive a refreshing Multicast Subscription Request, the FA will stop delivering the datagram. The Multicast Subscription Request MUST accompanied with a MN-FA authentication as defined in section 3.5.3 of Mobile IP [RFC2002]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | counter | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Specific Multicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- Type: TBD Counter: The number of source addresses present in the message. Source Specific Multicast Address: It indicates the source specific multicast address assigned by the mobile node's home agent. Source Address 1 to n: The list of source address associated with the channel. Identification: A 64-bit number, constructed by the mobile node, used for matching Multicast Subscription Requests with Multicast Subscription Replies, and for protecting against replay attacks of registration messages. Rose Expires January 12, 2001 [Page 10] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 3.7. Binding Update Usage: Home Agent to a correspondent of a Mobile Node to inform it with the current care-of address of the Mobile Node. The care-of address can either be a regular care-of address as defined in Mobile IP [RFC2002] or can be a Source Specific Multicast Address. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |A|I|M|G|L| Rsvd| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile Node Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- - L: The `L' bit specifies that the care-of address is a Source Specific Multicast Address. - All other fields keep their meaning as defined in Route Optimization for Mobile IP [draft-ietf-mobileip-optim]. 3.8. Source Update Usage: the Home Agent sends the source update message to the Mobile Node when the Home Agent has received a Binding Request Message from a correspondent and has returned a Binding Update Message to the correspondent node. Rose Expires January 12, 2001 [Page 11] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Correspondent IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD. Correspondent IP address The IP address of a correspondent node to which the Home Agent has sent a Binding Update message in response to a Binding Request message. Lifetime: The number of seconds remaining before the binding cache entry must be considered expired. The lifetime is typically equal to the remaining lifetime of the mobile node's regis- tration. A value of all ones is not acceptable. Identification: If present, a 64-bit number, assigned by the node sending the Source Update message, used to assist in matching this message with the previous message sent to the originator of the message, and in protecting against replay attacks. 4. Protocol overview The new solution does not imply any modification in the Mobile IP protocol principle, since it uses some extensions made possible inside Mobile IP. The micro-mobility scheme is almost completely transparent for the mobile node that has only to remember his multi- cast address and join multicast group while performing handoff in the case it uses our protocol. The solution works with off the shelf com- ponents, which can be deployed in the network. These network elements must enable multicast routing. The solution can support "make before Rose Expires January 12, 2001 [Page 12] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 break" scheme if the SMM protocol is associated with a "movement detection" mechanism. We do not intend to propose here any "movement detection" mechanism but just to suggest some possibilities found in the public domain like the beacon detection. The "make before break" principle is used in the Global System for Mobile communication (GSM) networks. Basically, this principle allows the creation of a new cir- cuit (or path) going to the mobile before breaking the old one. This principle is vital for voice communication. Having such feature give a great advantage to the proposed solution. This has to be used along with an adequate MN or a FA algorithm to avoid the reception of duplicate packets as a multiple inscriptions to the same SSM channel are possible for the same MN for a while. We do not intend to study such algorithm here. We base our discussion on the topology illustrated in Figure 1. In this figure, we have connected several Wireless Domains to the Inter- net. The protocol proposed in this document can also be applied to the case where a single Wireless Domain exists (i.e. a corporate net- work), where users can move from one point of attachment to another. Rose Expires January 12, 2001 [Page 13] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 BS BS BS BS BS BS BS BS | | | | +-----+ +-----+ | | | | +--+--+--+---|FA/HA| |FA/HA|---+--+--+--+ +-----+ +-----+ | | | +------+ | +--+Router+----+ +------+ | Wireless domain 1 | Internet | | Wireless domain 2 | | Wireless domain 3 +------+ | | +------+ |Router+-----------+ +------------|Router| +-+--+-+ +-+--+-+ | | | | | | | | +-----+ +-----+ +-----+ +-----+ | | | | +-----+ +-----+ +-----+ +-----+ |FA/HA| |FA/HA| |FA/HA| |FA/HA| +-----+ +-----+ +-----+ +-----+ | | | | | | | | +--+--+--+ +--+--+--+ +--+--+--+ +--+--+--+ | | | | | | | | | | | | | | | | BS BS BS BS BS BS BS BS BS BS BS BS BS BS BS BS BS: Base Station FA/HA: Foreign Agent/Home Agent Figure 1 wireless domain topology The terms FA, HA and MN are defined in Mobile IP [RFC2002]. A given Mobile Node has a static Home Agent within its Home Wireless Domain. The introduction of the Simple Multicast extension for Mobile IP modifies some aspects of the behavior of each entity. The mobile node arrives at a foreign Wireless Domain and listens for Agent Advertisement. The FA advertises its capabilities to support the Sim- ple Multicast Extension for Mobile IP and inserts a network access identifier [RFC2486] extension. The MN uses the NAI extension defined for mobile IP [RFC2794] to decide which action must be taken. If the MN discovers that it has entered a new foreign domain, it sends a registration request to the foreign agent. The MN chooses then to Rose Expires January 12, 2001 [Page 14] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 request the service from its home agent by setting the Simple Multi- cast flag in its registration request. If the mobile node identifies that it is still in the same domain but has moved from a previous FA to a new one, it sends a Multicast Subscription Request to the new FA. If the home agent supports the Simple Multicast Extension for Mobile IP, it allocates a source specific multicast address and inserts the address in the Source Specific Multicast Address Extension after the Registration Reply. The MN receives the two messages (i.e. registration reply and Source Multicast Address Extension) and then subscribes to the following SSM channel: Source address = home agent Source Specific Multicast address = the one given in the source specific multicast address. The home agent as in Mobile IP intercepts packets sent to the mobile node while it is visiting a foreign wireless domain and tunnels them. The destination address of the tunnel is set to the source specific multicast previously allocated. The mobile node must be able to de- tunnel the packets sent by the home agent. Simple Multicast extension for Mobile IP defined extensions, which extend the current Mobile IP protocol designed to: - Allow the Foreign Agent to advertise its capacity to use Source Specific Multicast Address as defined in [draft- holbrook-ssm-00.txt]. - Allow the mobile node to request the HA to allocate a Source Specific Multicast address and to encapsulate all his destined packets using this SSM address. - Allow the HA to grant the request and allocate a SSM address and sending it back to the MN or to deny the allo- cation. - Allow the HA to send the source specific multicast address to the correspondent so that the triangle route problem can be avoided. The correspondent encapsulates the packets using the source specific multicast address and sends them to the mobile node. Rose Expires January 12, 2001 [Page 15] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 - Allow the HA to send the source address of the correspon- dent so that the mobile node can modify its channel sub- scription by adding the new source address (i.e. the correspondent address). We now describe the different phases, detailing how Simple Multicast extension for Mobile IP contribute in extending mobile IP to offer micro-mobility support. This protocol takes the assumption that there is a single operator managing the foreign network and that the networks between the HA and the MN are multicast enabled. Thus our protocol is envision to be used in enterprises where those assumptions are credible. 4.1. Registration process When the MN arrives in a wireless domain it will receives an agent advertisement message from the FA located on the sub-network. This agent advertisement messages includes an FA-NAI extension (see sec- tion 3.2.). The MN uses the extension's content to identify the wire- less domain to which it is now going to be connected. As the MN has just entered the wireless domain, it must register with its HA. The MN determines that the FA supports the SMM protocol extension by checking the value of the 'L' bit in the agent advertisement message. If the FA supports the service, the MN can register with its HA along with requesting the allocation of a SSM address. The MN sets the 'L' bit in the registration request. The MN fills the registration mes- sages as defined in Mobile IP [RFC2002], so that in the case where the SMM service can not be obtained the MN can rely on classical Mobile IP. The registration message is forwarded by the FA to the HA. The HA after having performed the usual verification on the registration request grants the request and checks the value of the 'L' bit. It assigns a SSM address to the mobile node. The HA returns a registra- tion reply to the mobile node including a Source Specific Multicast Address extension. This extension includes the SSM address allocated. The Registration reply is sent to the FA which forwards it to the MN. The mobile node retrieves the SSM address from the Source Specific Multicast Address extension. The MN subscribes to the channel [draft-ietf-idmr-igmp-v3] request including the HA's address and the SSM address assigned. The subscription to the channel SHOULD NOT have a lifetime greater than the remaining the lifetime given by the HA in the registration reply. Rose Expires January 12, 2001 [Page 16] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 The MN MUST includes a MN-AAA extension in its registration request, in order to obtain a MN-FA key [draft-ietf-mobileip-aaa-key] to pro- tect the messages exchange between the MN and the FAs of the wireless domain. The MN-FA key MUST be accessible from any FA of the wireless domain. The means required for an FA to obtain the MN-FA key are out of the scope of this document. 4.2. Traffic flow The handling of the traffic sent to a MN is pretty much similar to the one defined by Mobile IP [RFC2002], excepts that the HA uses the SSM address to built the outer tunnel. The mobile node MUST be able to de-tunnel the incoming packets to retrieve the correspondent's packets. 4.3. Moving in the wireless domain The MN when receives an agent advertisement message from a new FA, it determines first that it is still roaming within the same wireless domain. The MN uses the FA-NAI extension. Once MN knows that it is still roaming in the same wireless domain, but connected to a new FA. The MN in such case simply needs to send a Multicast Extension request. The request MUST be sent along with a MN-FA authentication extension as defined in Mobile IP [RFC2002]. The FA MUST be able to obtain the MN-FA key to verify that the Multi- cast Subscription Request. The FA after having retrieve the MN-FA key MUST verify the validity of the request and if granted, the FA must set up the forwarding of the multicast packet. The Multicast Sub- scription Request is similar to an IGMP unsolicitate message [IGMPv3]. The need of this message can from the fact that the IGMP message are not secured. The subscription to the channel SHOULD NOT have a lifetime greater than the remaining of the current binding's lifetime. 4.4. Route optimization The SMM protocol defines a modification to the binding update message defined in route optimization [draft-ietf-mobileip-optim]. The bind- ing update has now a 'L' bit indicating that the address given in the binding update message is a source specific multicast address. In the case the HA is responding to a binding request message sent from a correspondent node, the HA MUST set the 'A' bit in the binding update to request a binding acknowledgement. The HA, when it receives the binding acknowledgement, MUST send a source update to Rose Expires January 12, 2001 [Page 17] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 the mobile node. This is necessary because of the essence of the source specific multicast protocol, which link a specific source address to a multicast address. The mobile node is now able to request the FA to forward the packet sent by the correspondent node to the new channel. If the HA is sending the binding update message after having received a binding warning from the mobile node. The MN is this case as the correspondent's IP address and can immediately subscribe to the new channel. A subscription to a channel is limited in time. The time SHOULD NOT exceed the time remaining for the current binding. The correspondent node simply needs to encapsulate packets using the source specific multicast address. 5. Change in the protocol behavior 5.1. Mobile node considerations 5.1.1. Receiving Agent advertisement Message When a Mobile Node entering a foreign network, receives a Mobility Agent Advertisement Extension in an ICMP Router Advertisement message from a foreign agent as described in Mobile IP. If the Source Specific Multicast "L" bit is set, the Agent Advertisement message MUST include the following extension in this specific order: - Agent Advertisement Challenge Extension as defined in [draft-ietf- mobileip-challenge-09.txt]. - Network Access Identifier extension [RFC2486] following the Agent Advertisement Challenge Extension. The mobile node uses the combination of the two messages (i.e. the Agent Advertisement and the Network Access Identifier Extension) to determine the action to take. If the mobile node has a current bind- ing (i.e. its has already register with its home agent), the mobile node uses the Network Access Identifier to determine if it is evolv- ing in the same domain. The FA-NAI should be in the form of FA_xx@wireless_domain.com. The mobile node uses "wireless_domain.com" to identify if it is roaming in the same wireless domain, as this suffix is identical to all FAs in the wireless domain. 5.1.2. Sending Registration Request If the mobile node identifies the situation where it needs to Rose Expires January 12, 2001 [Page 18] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 register with its home agent, the mobile node sends the registration request to foreign agent. The mobile node MUST follow the procedures defined in [draft-ietf-mobileip-challenge]. We assume to have the possibility to configure the MN to support or not SSM. Thus, two scenarios are possible: 1. The Mobile Node does support SSM: The Mobile Node sends the Registration Request with the Source Specific Multicast `L' bit set. This request is sent to the foreign Agent. The Mobile Node MAY request its Home Agent to not inform its correspondents of its current care-of address, in such case the Mobile Node sets the `P' as defined in [draft-ietf- mobileip-optim]. 2. The Mobile Node does not support SSM: In this case the MN MUS use the Mobile IP registration request procedure as defined in [RFC2002]. 5.1.3. Receiving Registration Reply We assume all the protocols among different network entities are suc- cessful, thus, the Registration Reply is forwarded back to the MN. If the registration reply contains a positive code, the MN MUST verify that the message includes the following extension in this specific order: - Unsolicited MN-FA Key From AAA Subtype as defined in sec- tion 4 of [draft-ietf-mobileip-aaa-key]. - Source Specific Multicast Address extension. The mobile node performs then an IGMP join to the SSM channel formed by associating the home agent address and the Source Specific Multi- cast address contained in the Source Specific Multicast Address Extension. If the code is 89 it indicates that the Foreign Agent does not sup- port the SSM option. The mobile SHOULD reattempt to register without setting the L bit in the registration request. If the code is 2 or 3, the mobile node MUST uses regular Mobile IP protocol as defined in [RFC2002]. We assume that we are now in the successful state in which the Mobile Node can receive packets from any correspondent. Each packet is Rose Expires January 12, 2001 [Page 19] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 intercepted by the home agent and tunneled using the SSM address assigned for this mobile node. Upon reception of the packets for- warded by the FA, which in this specific case acts simply as a source specific multicast router, the MN de-tunnels the packets to obtain the original correspondent's datagram. 5.1.4. Sending Multicast Subscription Request To be efficient and as quick as possible, the MN should avoid going through the entire registration process. Thus the mobile node MUST uses the Network Access Identifier (NAI) extension appended to the Agent Advertisement message to determine that it is roaming within the same wireless domain. The MN MUST memorize the NAI of the previ- ous FA (e.g. previous_FA@wireless_domain.com) and compare it to the new NAI received (e.g. new_FA@wireless_domain.com). If both NAI are identical, them the MN determines that it is receiving an Agent Advertisement message from the same FA, thus no action is required. If the MN determines that the new FA is different then the previous, but belong to the same wireless domain (i.e. the suffix is identical; e.g. wireless_domain.com), then the MN MUST send the Multicast Sub- scription Request to the Foreign Agent. The Mobile Node MUST insert at least the Home Agent's Address and SHOULD give the address of each correspondent that has received a Binding Update Message from the Home Agent. The Multicast Subscription Request MUST be immediately followed by a MN-FA authentication as defined in 3.5.3 of Mobile IP [RFC2002]. The value of the lifetime MUST NOT exceed the time remaining for the current registration. _5._1._5. Receiving Source Update The Mobile Node MAY choose to have its Home Agent informing the correspondent of the current care-of address. Then the Mobile Node MAY receive a Source Update from it Home Agent, informing the Mobile Node that the correspondent which unicast address is given in the message has received a Binding Update Message with the Source Specific Multicast Address. The Mobile Node MUST verify that the lifetime field does not have a value of all ones. If it is the case the Mobile Node MUST NOT perform any further action and MUST discard the message. The Mobile Node MUST verify that the Source Update message is pro- tected with a MN-HA authentication message as defined in section Rose Expires January 12, 2001 [Page 20] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 3.5.2 of mobile IP [RFC2002]. 5.2. Foreign agent considerations 5.2.1. Configuration and registration table The Foreign Agent MUST maintain a visitor list entry as described in section 3.7.1 of the mobile IP specification [RFC2002]. The entry MUST include the options present in the Registration Request. 5.2.2. Sending Agent Advertisement The foreign agent supporting the simple multicast extension form Mobile IP (IP SMM) MUST set the `L' bit in all Agent Advertisement Messages. The Agent Advertisement MUST be followed by an Agent Adver- tisement Challenge Extension as defined in [draft-ietf-mobileip- challenge] and MUST be finished by the FA-NAI extension defined by this protocol. The rate at which the Foreign Agent sends Agent Adver- tisement is defined in Mobile IP [RFC2002]. Since the Mobile IP pro- tocol is evolving, this section SHOULD be updated to reflect the changes made in Mobile IP. 5.2.3. Receiving Registration Request The FA when receiving a registration request from a mobile node MUST perform the validity checks as described in section 3.7.2.1 of Mobile IP [RFC2002]. If the `L' bit is set in the registration request, a FA not supporting the Simple Multicast extension MUST return a registra- tion reply to the mobile node with the code field set to 89. Other- wise the FA MUST relay the registration request to the HA. 5.2.4. Receiving Registration Reply The FA MUST hold the information included in the registration request to help the registration reply process. If the `L' bit was set in the registration request, the FA MUST perform the following checks: 1. The registration reply's code is 0, the registration reply MUST contains a Source Specific Multicast Address Exten- sion. Otherwise the FA MUST send a registration reply with the code field set to 90. 2. If the registration code is either 2 or 3, the FA MUST ver- ify the registration as described in section 3.7.3.1 of the Mobile IP specification [RFC2002]. Rose Expires January 12, 2001 [Page 21] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 3. For all other codes, the FA SHOULD simply relay the regis- tration request. 5.2.5. Receiving Multicast Subscription Request If the FA receives a Multicast Subscription Request, the FA MUST ver- ify that exactly one NM-FA authentication is present just after the Multicast Subscription Request. The FA MUST check the authenticator value present in the MN-FA authentication. If the result of the verification is positive the Foreign Agent MUST be able to relay the traffic on all given channels. A channel is form by associating the Source Specific Multicast Address to each Source Address found in the Multicast Subscription Message. 5.3. Home agent considerations 5.3.1. Configuration and registration tables The Home Agent MAY implement the SMM protocol. When the Home Agent implements the SMM protocol, the Home Agent MUST have a policy for allocation Source Specific Multicast Address. The HOME agent MAY be configured to serve a limited number of mobile nodes with this ser- vice. When the home agent accepts a valid Registration Request from a mobile node that it serves as a home agent, the home agent MUST create or modify the entry for this mobile node in its mobility bind- ing list containing: - the mobile node's Source Specific Multicast Address - the Identification field from the Registration Reply - the remaining Lifetime of the registration 5.3.2. Receiving registration request When the mobile node receives a registration request from a mobile node it MUST proceed the validity checks as described in section 3.8.2.1 of the mobile IP specification [RFC2002]. The Home Agent MUST process all extensions present in the message before allocating the Source Specific Multicast Address to the mobile node. If the bit `L' is set in the registration the Home Agent, if it implements the SMM protocol, MUST allocate a Source Specific Multicast Address. The pro- cedure used to allocate and manage the Source Specific Multicast Address Poll is out of the scope of this document. If the `P' bit is set in the binding cache, the Home Agent is not authorized to Rose Expires January 12, 2001 [Page 22] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 transmit Binding Update Message to the correspondents of a Mobile Node. The Home Agent MUST comply with the protocol described in [draft-ietf-mobileip-optim]. The Mobile Node's Home Agent MUST send a Binding Update Message with the care-of address set to 0 as well as the lifetime. 5.3.3. Sending Registration Reply The Home Agent MUST apply the policy described in section 3.8.2.2. of mobile IP specification [RFC2002].The Home Agent possible responses are listed below: 1. If the Home Agent supports SSM service, and if the Home Agent does succeed the SSM address allocation as indicated in the Mobile IP Registration Request, the Registration Reply Code value MUST be set to 0. The Simple Multicast extension for Mobile IP "Source Specific Multicast address extension" MUST be added at the end of the Registration Reply. The HA is in charge of allocating a SSM address. We do not need a special mechanism to insure the multicast address to be unique among different HA since this multicast address is associated with the unique HA IP address in the concept of channel, this pair is unique. 2. If the Home Agent supports SSM service, and if the Home Agent does not succeed the Mobile IP "Registration Request" SSM address allocation, the CODE (value 3, see section 5.3.4) field MUST be set accordingly to the reason. And the Home Agent MUST apply Mobile IP [RFC2002].3. If the Home Agent does not support the SSM service, the CODE (value 2, see section 5.3.4) field MUST be set accordingly to the reason. From now on, Mobile IP [RFC2002] MUST be used. When the registration is successful, the Home Agent MUST be able to intercept the datagram sent to the Mobile Node and MUST tunnel them using either the Source Specific Multicast Address or the care-of Address, depending on the outcome of the registration request. 5.3.4. Sending Binding Update The Home Agent either sends Binding Update Message to Mobile Node's correspondent in the following cases: - In response to a Binding Warning Message sent by the Mobile Node. Rose Expires January 12, 2001 [Page 23] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 - In response to a Binding Request Message sent by a correspondent. - In response to a Binding Request Message sent along with a Registration Request Message. Before sending a Binding Update the Home Agent MUST verify that it has received authorization from the Mobile Node to do so. The Home Agent MUST set the Acknowledgement in the Binding Update Message sent to the correspondent node and MUST include the identification field to have a mechanism to match the Binding Update and the Binding Ack- nowledgement Messages. 5.3.5. Sending Source Update The Home Agent MUST send a Source Update Message to the Mobile Node after receiving a Binding Acknowledgement from the Correspondent. The Home Agent MUST set the lifetime field to the remaining time of the Mobile Node's registration. The Home Agent MUST append a MN-HA Authentication Extension as defined in 3.5.2 of the Mobile IP specif- ication [RFC2002]. 5.4. Correspondent node considerations 5.4.1. Sending Binding Request A correspondent MAY send a Binding Request is the current binding's lifetime is close to expiration. The rules applied to this message are not related to the type of care-of address use by the mobile (i.e. regular care-of address or Source Specific Multicast Address). The Correspond MUST be compliant with the procedure described in [draft-ietf-mobileip-optim]. 5.4.2. Receiving Binding Update The correspondent MUST verify that the `A' and the 'L' bits are both set in the Binding Update Message set by the Mobile Node's Home Agent. The Correspondent Node MUST also verify that the `I' bit is set in the message. The Correspondent Node MUST first check that there is not another binding entry in its cache using the same Source Specific Multicast Address. If there is an entry with the same Source Specific Multicast Address but for a different Mobile Node, the Correspondent Node MUST NOT create an entry for the Binding Update Message. If the Correspondent Node creates an entry it MUST process the message as indicated in [draft-ietf-mobileip-optim]. Rose Expires January 12, 2001 [Page 24] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 5.4.3. Sending Binding Acknowledgement The Correspondent Node MUST send a Binding Acknowledgement to the Mobile Node's Home Agent. 6. Security considerations The protocol IP SMM creates extensions to the base protocol of mobile IP and requires usage of security mechanisms as defined in: 1. Mobile IP Challenge/Response Extensions [draft-ietf- mobileip-challenge] 2. AAA keys distribution [draft-ietf-mobileip-aaa-key] These protocols extend the base protocol of mobile IP with enhance security features. The protocols define how a mobile node can request usage of AAA (authorization, authentication and Accounting) server services to authenticate the mobile node, to receive authorization from the network access provider to use its services. 7. References [RFC2002]: IP mobility support, Charles Perkins (Editor), RFC 2002, October 1996 [draft-holbrook-ssm]: Source-Specific Multicast for IP, H. Holbrook, B. Cain, IETF March 2000, work in progress. [RFC2119]: S. Bradner, "Key words for use in RFCs to indicate require- ment levels", BSP 14, RFC 2119, March 1997. [RFC2236]: Internet Group Management Protocol, Version 2, W. Fenner, Xerox Parc, RFC 2236, November 1997. [RFC2486]: "The Network Access Identifier, B. Aboba, Microsoft Cor- poration, M. Beadles, WorldCom Advanced Networks, RFC 2486, Rose Expires January 12, 2001 [Page 25] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 January 1999. [RFC2794]: "Mobile IP Network Access Identifier Extension for IPv4," C. Perkins and P. Calhoun, RFC 2794, March 2000 [draft-ietf-mobileip-challenge]: "Mobile IP Challenge/Response Extensions," C. Perkins and P Calhoun, IETF Internet Draft, work in progress. [draft-ietf-mobileip-aaa-key]: "AAA Registration Keys for Mobile IP," C. perkins and P. Calhoun, IETF Internet draft, work in progress. [draft-ietf-mobileip-optim]: "Route optimization in Mobile IP," C. Perkins and D. John- son, IETF Internet Draft, work in progress. [IGMPv3]: "Internet Group Management Protocol, Version 3," Cain, B., Deering, S., and A. Thyagarajan, IETF Internet Draft, Work in Progress. Authors' addresses Questions or comments about this document may be directed at the author addresses. Rose Expires January 12, 2001 [Page 26] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 Laurence Rose Alcatel USA, Inc 1201 Campbell Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-3567 Fax: +1-972-996-5902 E-mail: laurence.rose@usa.alcatel.com Vincent Magret Alcatel USA, Inc 1201 Campbell Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-2625 Fax: +1-972-996-5902 E-mail: vincent.magret@usa.alcatel.com Rose Expires January 12, 2001 [Page 27]