Submitted to the Mobile IP working group V. Magret Internet Engineering Task Force V. Kumar Choyi INTERNET DRAFT Alcatel July 1, 2000 Multicast Micro-Mobility Protocol (MMM) draft-magret-mobileip-mmm-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). The list Magret Expires January 1, 2001 [Page 1] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 Abstract The document proposes an extension to Mobile IP [RFC2002] to offer a support of micro-mobility. Micro-mobility refers to the part of a mobile protocol allowing a mobile node to move without having to notify its home agent. The mobile node's home agent's notification is a concept defined by Mobile IP [RFC2002]. This protocol defines a service known as macro-mobility. The protocol defined in this Internet Draft specifies the messages and the operations required to extend Mobile IP. Magret Expires January 1, 2001 [Page 2] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 Table of Contents 1. Introduction ................................................ 3 2. Conventions ................................................. 3 3. New Mobile IP extensions .................................... 5 3.1. Mobile node advertisement ................................. 5 3.2. BSR extension ............................................. 6 3.3. Neighbor update extension ................................. 7 3.4. Multicast address extension ............................... 8 4. Protocol overview ........................................... 9 4.1. Entering into a foreign domain ............................ 12 4.2. Care-of address ........................................... 14 4.3. Traffic flow .............................................. 14 4.3.1. Foreign agent care-of address ........................... 14 4.3.2. Co-located care-of address .............................. 14 4.3.3. Correspondent within the same wireless domain ........... 15 4.4. Moving within the foreign domain .......................... 15 4.5. Make before break option .................................. 15 4.6. Refreshing the registration ............................... 16 4.7. Wireless Home domain ...................................... 16 4.7.1. Virtual home domain ..................................... 16 4.7.2. Traffic flow ............................................ 16 5. Change in the protocol behavior ............................. 17 5.1. Mobile node considerations ................................ 17 5.2. Base station considerations ............................... 17 5.3. Base station router considerations ........................ 18 5.4. Main access router considerations ......................... 20 6. Security considerations ..................................... 21 7. References .................................................. 21 Authors' addresses ............................................. 22 Magret Expires January 1, 2001 [Page 3] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 1. Introduction The Internet has revolutionized the way we do our day-to-day chores. Whether it is reading our daily morning papers, trading stocks, keep- ing track of weather, buying clothes or anything else that one can think of. Slowly the technology of wireless communications has improved of the last decade. It started back in the sixties with the first analog radio system to become digital and now in transition to offer broadband access. The reason that this slow revolution of wire- less networking is now going to be explosive in the next few years is because now we have a medium (Internet) to communicate and a tremen- dous set of applications. Mobile IP [RFC2002] provides a framework wherein mobile nodes can move from one point of attachment (e.g. a sub network in an enterprise) to another sub-network (e.g. another sub-network in another enterprise) and will still be able to communi- cate with nodes. Mobile IP provides the means to keep track of the current location (called a binding in Mobile IP specification) and have all the traffic sent to the mobile node transparently forwarded to the current location. Mobile IP implies that whenever the mobile node moves from one sub-network to another to update the tracking (i.e. the binding) which is maintain in his home network (e.g. the network in which the user is officially registered). The problem with Mobile IP is the overhead that is incurred while performing handoff. When the Mobile Host is in a Foreign Network and every time it performs a handoff, Mobile IP Registration Request messages are sent to the Home Agent. The Base Stations in Cellular networks are usually clustered together forming domains along with routers in the upstream that determine where the packets have to be forwarded. 2. Convention The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" amd "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. Main access router (MAR): The router connected to a wireless domain and to the Inter- net. This router needs to support mobile IP. Base station router (BSR): The router connected to a set of bridges of base stations. Magret Expires January 1, 2001 [Page 4] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 BSR coverage area: The BSR coverage area is composed of every coverage area of each base station attached to the BSR. Serving BSR: This BSR that is currently processing the multicast packet sent to a mobile node. The BSR de-tunnels the outer header and forwards the inner packet to the mobile node. 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. BS coverage area: The area covered by a single base station. BSR active cache: This cache contains information related to every mobile node located under the coverage area of the say BSR. BSR probable cache: This cache contains information sent by surrounding BSRs indicating that a mobile node has been authorized to use the wireless infrastructure. Cell: It is the area covered by a base station. 3. New Mobile IP extensions 3.1. Mobile node advertisement Usage: a base station sends this message to its BSR whenever the base station discovers that a new mobile has entered its coverage area. The message is also sent periodically to refresh binding cache entries in the BSR. In this case the message includes the list on link layer information of all the mobile node currently attached to the base station. Magret Expires January 1, 2001 [Page 5] 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 | Sub-type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of one item | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or more link-layer | | specific information | | .../... Type: TBD Sub-type: A new mobile node (n) or link-layer table update (u). The new mobile node type message is sent whenever the base sta- tion discovers that a new mobile node has entered the cov- erage area. The link-layer table update is sent periodi- cally by the base station to refresh binding entries at the BSR. Length: N, where N is the number of link-layer information sent. The information sent can be the MAC layer address for instance if the wireless link is 802.11 compliant. Length of one item: M, where M is equal to the length of a single link-layer specific information. 3.2. BSR extension Usage: the extension is appended after the mobile node's registration request and contains the IP address of the BSR forwarding the mobile node's registration request. Magret Expires January 1, 2001 [Page 6] 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 | BSR IP ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... address | +-+-+-+-+-+-+-+- Type: TBD BSR IP address: The IP address of the BSR. The IP address indicates which BSR is serving the mobile node. This address is used to forward the mobile IP registration reply to the BSR serving the mobile node. The BSR extension MUST be appended at the end of the mobile IP registration request. 3.3. Neighbor update extension Usage: the message is sent by one BSR to its surrounding BSRs to inform them with the list of mobile node currently located under its BSR coverage area. The message is sent periodically. Magret Expires January 1, 2001 [Page 7] 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of one link-layer item | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile node home address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile node's link-layer information 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile node home address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile node's link-layer information n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: N, where N is the value of triplets (mobile node home address, multicast address and link- layer specific infor- mation) present in the message. Can potentially be zero, to delete of the entries in the surrounding caches. Mobile node home address The IP address of the mobile node. Mobile node link-layer information: this field contains the link-layer specific information for the mobile node (e.g. the MAC address if the network physi- cal layer is 802.11). 3.4. Multicast address extension Usage: the extension is appended after the home agent's registration reply and contains the multicast address allocated by the MAR for the Magret Expires January 1, 2001 [Page 8] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 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 | Multicast ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |... address | +-+-+-+-+-+-+-+- Type: TBD Multicast address: the multicast address assigned for the mobile node. The information 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. 4. Protocol overview In this section we described the behavior of the different nodes in two situations. The first part describes the protocol when the mobile node enters the foreign domain and moves within its coverage area. The second part describes the evolution of the mobile node while it moves within the coverage area of the home network. For both cases we base our discussion on the following topology. Magret Expires January 1, 2001 [Page 9] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 INTERNET | +-----+ | MAR | +-----+ ||| ||| +------------+|+-----------+ | | | +-+ +-+ +-+ |R| |R| |R| +-+ +-+ +-+ | | | | | | | | | | | | +---+ +---+ +---+ +---+ +---+ +---+ |BSR| |BSR| |BSR| |BSR| |BSR| |BSR| +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | | | | | | | BS BS BS BS BS BS BS BS BS BS BS BS BS: Base Station BSR: Base Station Router R: Router MAR: Main Access Router Figure 1 Home or foreign domain topology The Main Access Router (MAR) MUST support mobile IP [RFC2002] by implementing both foreign and home agent functionality. The MAR MUST also implement part of the protocol extensions described in this document. The MAR MUST process the BSR extension that follows every registration request. The MAR MUST allocate and insert the multicast address extension before forwarding the registration reply. The routers within the wireless domain MUST support IP multicast routing. The Base station Routers (BSR) MUST implement the extensions described in this document. The BSR MUST insert the BSR extension after each mobile IP registration request. The BSR MUST process the multicast address extension following the mobile registration reply. The BSR MUST periodically send a neighbor binding update to every BSR surrounding it. This message is used by the neighboring BSRs to manage their own probable cache. This cache contains the information of the mobile nodes that are located within the vicinity of the BSR. As mentioned earlier, the topology is well know, and each BSR knows the IP address of other BSRs that are located in its neighborhood. Magret Expires January 1, 2001 [Page 10] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 For instance BSR 4 knows that the IP addresses of BSR 3 and BSR 5 as these BSRs are its neighbors. Each base station router knows the IP address of its Main Access Router. The protocol extends the current Mobile IP protocol with a set of messages designed to: Allow a BSR to communicate to the next probable BSRs the list of mobile nodes information that is currently located under the BSR coverage area. This message is called the neighbor binding update extension (i.e. the mobile moves from one BSR to another). This message is sent from BSR to BSR. Allow a BSR to inform its MAR giving the IP address of the BSR that has forwarded the mobile IP registration request. This mes- sage is called the BSR extension. This message is appended to the mobile IP registration request. Allow a MAR to inform the BSR of the multicast address assigned to this particular mobile node when the access to the network is granted. This message is called the multicast address extension. This message is appended to the mobile IP registration reply. Allow a BST to inform the BSR with the layer characteristics of a mobile node entering one of the cells. This message is called the mobile node advertisement extension. The message MAY contain more than one mobile node information. We now describe the different phases, detailing how these extensions contribute in extending mobile IP to offer micro-mobility support. The first case illustrated is when the mobile node is moving under the coverage area of a foreign domain. The second case is when the mobile node moves within its home domain. In this case we describe how the mobile manages to return to its home agent. This protocol takes the assumption that there is a single operator managing the foreign network. The BSR will take an action based on the presence of the link layer information of the mobile node in its caches. If the binding cache is hit, the BSR MUST refresh the entry. If the probable cache is hit, the BSR MUST joint the diffusion tree and transfer the entry from the probable cache to the binding cache. The BSR MUST periodically send a neighbor binding update to its surrounding BSRs with the list of link layer information of all the mobile nodes located in its cover- age area. Magret Expires January 1, 2001 [Page 11] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 4.1. Entering into a foreign domain When a mobile node enters the coverage area of the base station router 1 (or any other router in this domain), the link layer proto- col at the base station (BS) serving the mobile node triggers the emission of the mobile node advertisement message. The BS informs its BSR of the entrance of a mobile node in the cell. The base station MUST periodically send the mobile node advertisement message to the BSR with the list of mobile nodes located in the base station cell. The BSR will take an action based on the presence of the link layer information of the mobile node in its caches. If the binding cache is hit, the BSR MUST refresh the entry. If the probable cache is hit, the BSR MUST joint the diffusion tree and transfer the entry from the probable cache to the binding cache. The BSR MUST periodically send a neighbor binding update to its surrounding BSRs with the list of link layer information of all the mobile nodes located in its cover- age area. If none of the caches are hit, the BSR MUST send a mobile IP agent advertisement message to the mobile node. The mobile node sends the registration request to the base station router. The BSR (which can be for instance BSR 1) MUST add its IP address (i.e. using the BSR extension) ot the mobile node's registra- tion request. The BSR MUST forward the registration request to the MAR. The MAR after having performed all the required security checks necessary for granting the registration request (AAA, challenge/response and key exchange protocols) MUST remove the BSR extension and MUST forward the registration request to the home agent. The MAR creates an entry in the pending cache for the mobile node registration request, including the IP address of the BSR serving the mobile node. For the home agent the MAR is apparently hosting the mobile node. The home agent, based on its policy, grants or denies the registration request. Considering that the home agent grants the request, it sends its reply to the foreign agent (i.e. the MAR). If the mobile node initiates the first registration request and moves towards a new cell connected to a new BSR, the mechanism previously described will trigger a second registration request. The new BSR processes the registration request as described in the previous para- graph (i.e. the BSR appends the BSR extension to the registration request). The MAR receiving the mobile node registration MUST check in its pending cache. If the cache is hit, the MAR will conclude that the mobile node has moved to under another BSR's coverage area while the mobile node's home agent processes the previous registration Magret Expires January 1, 2001 [Page 12] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 request. The MAR MUST update the pending cache to reflect the new BSR address. When the MAR receives the registration reply it updates its cache to reflect the result of the request (e.g. remove the entry in the pending cache and creates one entry in the binding cache) and assigns a multicast address to the mobile node. The registration reply is forwarded to the BSR preceding the multicast address exten- sion. BSR 1 removes the multicast address extension and forwards the registration reply to the mobile node. It also creates a binding entry associating the multicast address to the mobile node. BSR 1 periodically informs BSR 2 of the newly created bindings with a neighbor binding update message. The message includes for each mobile node found in the binding cache the mobile node address, the care-of address, the home agent address, the multicast address, the link layer information and the lifetime of the registration. The neighbor binding update message refreshes partially the probable cache entries. It is a partial refresh, as the cache will be entirely refreshed after the BSR has received every neighbor binding update message from each of its neighboring BSRs. If the mobile node remains under the coverage area connected to the same base station, this base station MUST send periodically refresh message (mobile node advertisement) to BSR 1 (periodicity needs to be defined). The mobile node advertisement message refreshes partially BSR 1's binding cache entries. It is a partial refresh, as the cache will be entirely refreshed after BSR1 has received every mobile node advertisement message from each of the base stations. If the mobile node moves to another base station connected to the same BSR, the base station MUST immediately send a mobile node advertisement mes- sage with the link layer information of the mobile node that has gen- erated the event. If the mobile node moves to the cell that is connected to BSR 2, one of the BSs informs BSR 2 of the presence of the mobile node by send- ing a mobile node advertisement message to BSR 2. If BSR 2 has an entry in its probable cache containing the information sent by BSR 1. BSR 2 associates the link layer information given by the BS to the one found in the probable cache and sends a message in direction of its MAR to join the diffusion group to receive the packets of the mobile node. Meanwhile, BSR 1 , which does not receive a mobile node advertisement message from at least one of its BSs refreshing the binding cache entry of a mobile node, then the entry is moved in the probable cache. If the mobile node can receive and transmit via several base stations the mobile node will receive the same message from these base sta- tions. Magret Expires January 1, 2001 [Page 13] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 4.2. Care-of address The proposed protocol does not make any special requirement on the type care-of address used by the mobile node. This address can either be a foreign agent care-of address or a co-located care-of address. The MAR has initially required all the BSR to set the 'R' bit in the agent advertisement message they send after receiving a mobile node advertisement message. How the mobile node acquires the co-located care of address is out of the scope of the document. Beside this point, the principle remains identical. If the mobile node register with a co-located care-of address, the BSR appends the BSR extension after the registration request. The MAR processes the registration and removes the BSR extension. The MAR allocates a multicast address for the mobile node and appends it in the multicast address extension after the registra- tion reply. The only difference resides in the traffic management, i.e. which node removes the tunnel and forwards the packet to its mobile destination. Section 4.3 describes how the traffic is managed when the mobile node uses a co-located care-of address. 4.3. Traffic flow 4.3.1. Foreign agent care-of address If the correspondent node is located outside the foreign wireless domain, packets send to a mobile node will be addressed to the home network. The home agent captures and tunnels those packets to the care-of address of the mobile node found in its binding cache. This address corresponds to MAR IP address. The MAR receives the tunneled packets. If the MAR has a valid binding cache for the mobile node, it de-tunnels the packet and creates a new tunnel. The source IP address is set with the IP address of the MAR and the destination IP address is set with the multicast address allocated for the mobile node. The packets are then sent to the diffusion group. Each BSR that has sub- scribed to the diffusion group receives a copy and de-tunnels the packet and forwards the packets to the mobile node. 4.3.2. Co-located care-of address If the mobile node uses a co-located care-of address, the MAR cap- tures the datagram and tunnels them with the destination address set to the multicast address allocated for the mobile node. Each BSR that has subscribed to the diffusion group receives the packets and de-tunnels it and sends the packet to the mobile node. The mobile Magret Expires January 1, 2001 [Page 14] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 node de-tunnels the packet as specified in mobile IP [RFC 2002]. 4.3.3. Correspondent within the same wireless domain If the correspondent node is located in the foreign domain, the traffic is sent to the mobile node home address. The MAR searches its binding cache for a valid entry containing the mobile node home address. If the cache is hit, MAR tunnels directly the packet to the multicast group. This mechanism enhances the performance of the overall network when route optimization is not used. 4.4. Moving within the foreign domain The main advantage of the protocol is the low latency required before receiving packets on outgoing connections. The protocol, as it relies on link layer protocol, allows such performance to be achieved. If the mobile node enters a new cell, the base station MUST inform the BSR of the presence of the mobile node. It MUST send a mobile node advertisement message including the link layer information of the mobile node. Two scenarios can be foreseen. The mobile node has moved to another base station but remains under the coverage of the same BSR (i.e. the mobile node is served by a BS linked to the same BSR), then no action is needed. If the mobile node is not among the ones served by the BSR (i.e. the BSR does not have a binding cache), but the BSR has an entry in the probable cache, the BSR MUST immediately subscribe to the multicast group. At the next expiration of the timer for the emission on the neighbor binding update message, the BSR sends all BSRs in its neighborhood the list of mobile node information of each mobile node within its coverage area. 4.5. Make before break option The "make before break" option requires that the surrounding BSRs of a serving BSR subscribe to the diffusion group as soon as they receive the neighbor update message. The option also requires that all the BSRs not currently serving the mobile node (i.e. the mobile node's entry is in the probable cache) to filter and discard all the incoming multicast packets. The filtering is removed when the BSR received from one of its base station a mobile node advertisement message including the mobile node link layer information. This option is intended to reduce the latency of the diffusion group join message's processing, since the BSR already receive the packets sent to the mobile. The processing is then limited to the removal of Magret Expires January 1, 2001 [Page 15] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 the filtering feature associated with this particular multicast address. 4.6. Refreshing the registration When the mobile node determines that the previous registration is close to expire, it MUST send a new mobile IP registration request to the its home agent. The BSR currently serving the mobile node MUST append the BSR extension. The MAR MUST update the binding cache to reflect the new lifetime of the binding. The multicast address remains unchanged. 4.7. Wireless Home domain 4.7.1. Virtual home domain When the mobile node is moving within the home wireless domain, prin- ciples described for the foreign domain remain. The mobile node home domain is administratively linked to the MAR. Thus the MAR acts as a home agent for the mobile node. The protocol requires an initialization phase, during which the BSRs received information on the mobile agent capability of the MAR. The BSRs use this information to generate agent advertisement. The mobile node entering a point within the home wireless domain will send a mobile IP registration which will cancel any previous binding manage by the home agent while the mobile node was visiting a foreign wire- less domain. It might as well be a new registration request as the mobile devices has just been turned on. The BSR serving the mobile node MUST append the BSR extension, which will be used by the MAR to forward the registration reply. The MAR home agent allocates a multi- cast address and creates a binding cache entry for the mobile node. The multicast address is sent to the BSR with the multicast address extension. The BSR removes the multicast address extension and for- wards the registration reply to the mobile node. The BSR sends a neighbor binding update message to the surrounding BSRs. While the mobile node moves in the home domain the principles, described for the foreign domain, are strictly identical to the behavior of a mobile node while visiting a foreign domain. 4.7.2. Traffic flow If the correspondent node is located within the home domain, its packets are sent to the mobile node home address, which are inter- cepted by the MAR of the said domain. The MAR creates tunnel to Magret Expires January 1, 2001 [Page 16] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 forward the packets. The destination address is set to the multicast IP address and the source address is set to the address of the MAR. All the BSRs that have subscribe to the diffusion group will receive the tunneled packet. The BSRs MUST remove the outer IP header and forward the inner packet to the mobile node. If the correspondent node is outside the home domain, its packets are obliged to transit via the MAR of the home domain, which applies the same principle as described in the previous paragraph. The MAR creates a tunnel with the destination address set to the multicast address and with the source address set to the MAR IP address. This packet is de-tunneled by every BSR that has subscribed to the group. The packet sent by the correspondent is forwarded to the mobile node. 5. Change in the protocol behavior This proposal modified slightly the Mobile IP protocol. This protocol implies that the mobile node MUST register every time he enters a wireless domain, regardless that the wireless domain is the mobile node's home domain. This is mandatory to allow the establishment of the multicast distribution tree. The protocol does not require the BSR that is acting as the foreign agent to send periodically the agent advertisement message. The message is sent only when the BSR determines that the mobile node is new in the BSR's coverage area. 5.1. Mobile node considerations The proposed protocol does not imply any specific requirement for the mobile node beside the fact that the mobile node MUST implement mobile IP as defined in RFC 2002. The unique requirement made is that the mobile node SHOULD send a registration request when entering a new wireless domain. This is required to set up the multicast tunnel within the wireless domain. This registration also removes the pending binding when the mobile node returns in its home domain. The mobile node MUST then set the lifetime to zero as specified in mobile IP [RFC 2002]. The mobile node MUST keep track of the pending registration request as these messages may get lost. In such case, the mobile node MUST set a timer which expiration will trigger a new mobile IP registration message. The number of mobile IP registration messages sent should be limited. 5.2. Base station considerations The base station MUST maintain a cache including link-layer specific information of every mobile node located within its coverage area. The base station MUST sent periodically mobile node advertisement Magret Expires January 1, 2001 [Page 17] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 update (see section 5.2.1) containing all the link-layer specific information of all the mobile nodes located under its coverage area. The periodicity of this message remains to be defined. It is more likely that the periodicity will be linked to the number of base sta- tion attached to the BSR and to the number of users that the BSR can manage. The number of messages sent should tuned so that the signal- ing part of the protocol does not create too much overhead. The base station MUST immediately sent a mobile node advertisement message with the sub-type set to "new" (see section XX) giving the link-layer specific information of the mobile node, when it detects that a mobile node has enter its coverage area. 5.3. Base station router considerations The BSR MUST process agent advertisement message sent by the MAR. The BSR MUST store the given information as it will be used to send local agent advertisement message to a mobile node. The BSR detects a MAR failure when it receives an agent advertisement message with a sequence number equal to zero. If the BSR receives an agent adver- tisement message with a sequence number different than zero just after its own power-up phase, this indicates that the BSR has rebooted. This case requires all mobile nodes to re-register with their home agent. The BSR MUST manage two caches. The binding cache holds the informa- tion of all mobile nodes that are currently or were within the cover- age area of one of the base stations served by the BSR. Indeed a mobile node may have been included in the last mobile node advertise- ment message which will have refreshed the binding cache entry and may have moved under another coverage area managed by another BSR. The probable cache holds the information of the mobile nodes that are in the neighborhood. These mobile nodes may appear within the BSR's coverage area in the near future and the information of these mobile nodes is intended to help the handoff process. The base station MUST process the mobile node advertisement message. There are two different scenarios depending on the value of the sub- type field. 1. The sub-type field indicates that the mobile node has just entered the coverage area of a base station. For the base station router, this message either means that the mobile is new in the BSR coverage area or the mobile node has moved under an area covered by another BS. The BSR deter- mines the first case by the fact that both its binding cache and probable cache do not contain an entry matching the link-layer information included in the mobile node Magret Expires January 1, 2001 [Page 18] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 advertisement message. In such case, the BSR MUST send a Mobile IP agent advertisement message to the mobile node. If the BSR has an entry in the binding cache, it means that the mobile node has moved in a new cell and no action is needed. If the BSR determines that the mobile node have just move into its BSR coverage area because it has an entry matching the mobile node's link layer information in its probable cache. The BSR MUST send an IGMP (if this is the protocol used) join message in direction of its MAR. The BSR must also move the entry from its probable cache to its binding cache. 2. If the sub-type field indicates an update message, the BSR MUST process the message, which consists of refreshing the entry in the binding cache of each mobile node included in the list. A single message (i.e. mobile node advertisement update) reflects only a part of the mobile node currently located in the BSR coverage area. The BSR must wait until it has received every base station's mobile node advertise- ment message before removing entries in the binding cache. If some entries of the binding cache expired, these entries should be moved from the binding cache to the probable cache. The BSR MUST send an IGMP leave message in direction of its MAR if the BSR does not implement the "make before break" option. The lifetime of a binding entry is set to be equal to twice the time needed for the BSR to receive all BSRs mobile node advertisement update message. The BSR MUST send periodically a neighbor update message with the list of mobile node located under its BSR coverage area. This list is sent to all the BSRs in the entire neighborhood. How the BSR knows the list of BSRs in the neighborhood is out of the scope of the docu- ment (e.g. the information could be given to the BSR via network management protocol, SNMP). The BSR must process every neighbor update message received. Each of these messages includes the list of mobile node currently served by a neighboring BSR. For each mobile node included in the list the BSR MUST either creates an entry or refreshes an existing one. If the implementation wants to support the "make before break" option, the BSR MUST send an IGMP [RFC2236] direction of the MAR. If the entry in the probable cache expires, the entry MUST be deleted and the BSR MUST send a leave message in direction of the MAR. The lifetime of the probable cache entry is set to twice the sending rate of the neighbor update messages. Magret Expires January 1, 2001 [Page 19] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 For each multicast diffusion group that matches an entry in the bind- ing cache and for which the BSR has subscribed the BSR MUST de-tunnel all packets received and forward them to the base stations. If the BSR implements the make before break feature, the BSR MUST be able to filter the multicast diffusion group that do not require packet pro- cessing (i.e. because the mobile node have not yet entered the BSR coverage area). The BSR knows the list of mobile nodes that require such processing by consulting the probable cache. When an entry of the probable cache is not refreshed, if the BSR does not implement the make before break option, the BSR MUST send an IGMP leave message in direction of the MAR. The entry MUST then be removed from the cache. 5.4. Main access router considerations The MAR is the only foreign agent available in the foreign wireless domain. The MAR MUST after initially boot (or a reboot) send an agent advertisement message to all the BSRs of the wireless domain. This message MUST be sent periodically to cover a BSR failure. The first message send after the initial power-up phase by the MAR MUST have the sequence number equals to zero. The MAR, as it is the foreign agent, MUST process all registration request as defined in Mobile IP [RFC 2002] and SHOULD process all the extensions of the registration request (e.g. NAI extension [RFC2794], AAA extension [AAA], reverse tunneling extension [RFC2344]...) The MAR MUST check the presence of the BSR extension. The registration request MUST be rejected by the MAR if the BSR extension is not included. The MAR must be able to determine the two following two cases: 1. The mobile node is registering for the first time (i.e. the binding cache does not have an entry for this mobile node). 2. The mobile node is sending a registration request to refresh a current binding (i.e. the binding cache has an entry for this mobile node). In the first case, the MAR should create an entry in its pending cache containing the information included in the registration request. If the MAR receives a second registration request from the same mobile node while the first registration request is currently pro- cessed (i.e. the pending cache has an entry for this mobile node). The MAR MUST check the content of the BSR extension presents at the Magret Expires January 1, 2001 [Page 20] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 end of the registration request, as the mobile node may have moved to another BSR coverage area. The MAR should update the entry in the pending to reflect the change since the registration reply MUST be sent to this new BSR. If the registration request is identical to the first one, the MAR should process the registration and forward it the home agent. The MAR MUST process all the extensions included in the registration, which implies that, the MAR SHOULD have interface with a local AAA server to grant the mobile node's access. If the home agent grants the registration request, the MAR MUST assign a multicast address and associate to the mobile node. The mechanism by which the MAR finds the multicast address is out of the scope of this document. The MAR MUST append the multicast address extension at the end of the registration reply and forward the mes- sage to the BSR that has forward the registration request. The MAR MUST create a binding entry holding the information of the associa- tion (binding and multicast address). If the MAR finds that the registration request of the mobile node is sent to refresh its current binding, the MAR MUST forward the regis- tration to the mobile node's home agent. The MAR MUST append the mul- ticast address extension at the end of the registration reply received from the home agent. This extension MUST include the same multicast address that has been allocated during the processing of the initial registration request. _6. Security considerations The protocol described in this Internet Draft defines extension to a base protocol that has security features (i.e. MN-HA authentication). There are currently a set of protocols submitted to the mobile IP working group that provides extended security capabilities [CHAPREP][AAA]. The protocol detailled does not modify the behavior of these protocols. 7. References [RFC2002]: IP mobility support, Charles Perkins (Editor), RFC 2002, October 1996 [RFC2119]: S. Bradner, "Key words for use in RFCs to indicate Magret Expires January 1, 2001 [Page 21] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 requirement 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 Corpora- tion, M. Beadles, WorldCom Advanced Networks, RFC 2486, January 1999. [RFC2344]: Reverse Tunneling for Mobile IP, G. Montenegro (Editor), RFC 2344, May 1998 [RFC2794]: Mobile IP Network Access Identifier Extension for IPv4, C. Perkins, P. Calhoun, RFC 2794, March 2000 [CHALREP]: Mobile IP Challenge/Response Extensions, C. Perkins, P Calhoun, draft-ietf-mobileip-challenge, work in progress [AAA]: Mobile IP Authentication, Authorization, and Accounting Requirements, S. Glass, T. Hiller, S. Jacobs, C. perkins, draft-ietf-mobileip-aaa-reqs, work in progress. Authors' addresses Questions or comments about this document may be directed at the author addresses. Magret Expires January 1, 2001 [Page 22] INTERNET DRAFT Multicast Micro-mobility protocol July 1, 2000 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 Vinod Kumar Choyi Alcatel USA, Inc. 1201 E. Campbell Road Richardson Texas 75081 USA M/S 446-310 Voice: +1-972-996-2788 Fax: +1-972-996-5902 E-mail: vinod.choyi@usa.alcatel.com Magret Expires January 1, 2001 [Page 23]