INTERNET-DRAFT Jiang Wu KTH/IT Expires: October, 2000 April 2000 Seamless IP Multicast Receiver Mobility Support Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents, valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies protocol enhancements that allow seamless IP multicast datagram delivery to mobile nodes in the Internet. In order to receive IP multicast datagrams, mobile nodes are not required to be identified by their unicast IP addresses. For unicast communication using Mobile IP, each mobile node needs to have a unicast home address and a care-of address. Following a handover to another IP subnet, such a mobile node is able to receive IP multicast traffic after exchanging IGMP messages with the multicast routers on the currently visiting network. However, in the worst case, it takes an unreasonably long time (especially with respect to streaming media) to resume receiving multicast IP traffic in the visiting network. This draft specifies a Mobility Support Agent (MSA) protocol which provides a mechanism to help ensure seamless reception of IP multicast traffic despite a mobile node handover. This is possible because in advance of its handover, a mobile node pre-registers with the MSA on the next network to be visited. The MSA acts as a proxy for this mobile node and is thus able to set up all the necessary states for the seamless delivery of multicast traffic to this mobile node. Jiang [Page 1] INTERNET-DRAFT Expires October, 2000 April 2000 Table of Contents 1. Introduction ................................................... 2 1.1. New Architectural Entities ........................... 5 1.2. Terminology .......................................... 5 1.3. Protocol Overview .................................... 6 1.4. Message Format ....................................... 7 2. Agent Discovery ................................................ 8 2.1. Inter-Agent Advertisement ............................ 8 2.2. Agent-MN Advertisement ............................... 9 2.2.1. Neighboring Network Extension ................. 10 2.3. Agent Solicitation ................................... 10 2.3.1. MSA History Extension ......................... 10 2.4. MSA Considerations ................................... 11 2.5. Mobile Node Considerations ........................... 12 3. Pre-registration ............................................... 12 3.1. Pre-registration ..................................... 12 3.2. Registration Confirm ................................. 13 3.3. MSA Considerations ................................... 14 3.3.1. Visitor Counter ............................... 14 3.3.2. Mapping Table ................................. 14 3.3.3. IGMPv2 Process ................................ 15 3.3.4. Multicast Routing Process ..................... 15 3.3.5. Other Services ................................ 16 3.4. Mobile Node Considerations ........................... 16 4. De-registration ................................................ 16 5. Security Considerations ........................................ 17 6. Performance Measurements ....................................... 17 7. Acknowledgments ................................................ 18 8. References ..................................................... 18 9. Author's Addresses ............................................. 19 1. Introduction Current IP multicast routing protocols [3, 4, 8] and membership management protocols [2, 6] do not require explicit identification of a node in the IP layer. A mobile node, is therefore capable of receiving IP multicast traffic in a visited network, provided that IP multicast routing is available on that network, and that the node is provided service. The later aspect is being addressed by the AAA work regarding Mobile IP [1, 9]. Because in IP multicast traffic the destination addresses are not network specific, the mobile node can easily resume receiving IP multicast IP after a handover without changing its IP address or even acquiring a care-of IP address. Jiang [Page 2] INTERNET-DRAFT Expires October, 2000 April 2000 In this draft we propose a Mobility Support Agent (MSA) architecture to support IP mobility related issues on a IP subnet, especially for micro-mobility support. A MSA is a network entity that resides on a IP subnet. It provides a set of services to all the mobile nodes currently visiting that IP subnet. This approach supposes to provide seamless IP handover with little change to the current Internet architecture and protocols. The MSA architecture is a general purpose architecture. In this draft, however, only IP multicast is considered. The MSA protocol described in this draft only intends to be used in an environment where multicast is widely deployed and the nodes are mobile. Its main goal is to help the mobile nodes to make handovers without causing noticeable increases in multicast handover latency. Internet ---------------------------- | | | | +------+ +------+ +---+ |Router| +---+ |Router| |MSA| +------+ |MSA| +------+ +---+ | +---+ | | | | | ---------------------- --------------------- visiting network next network +--+ |MN| ---> +--+ The figure above shows a typical scenario for a handover procedure. A mobile node can take part in multiple multicast sessions identified by their multicast IP addresses. When doing a handover to the next network, two scenarios are possible for each multicast session: 1.That multicast session is active on the next network, i.e., the corresponding multicast traffic is available on that network. 2.That multicast session is passive on the next network, i.e., the multicast tree is not established yet - hence there is no corresponding multicast traffic on that network. In the case of active multicast sessions, the mobile node suffers little latency receiving the IP multicast traffic after a handover - since it is already being delivered to this subnet. However, for those passive multicast sessions, IGMP and multicast routing protocols must be used to establish the new multicast tree on that network. This draft deals with the second scenario, the next network is highly possible to be passive in the multicast sessions a mobile node is participating in because: Jiang [Page 3] INTERNET-DRAFT Expires October, 2000 April 2000 1.Pico cells with high capacity and low error rate will be popular in the near future as the basic wireless infrastructure. The pico cell size is too small to accommodate many mobile nodes, hence the probability of their already being a member of the multicast group in the cell is small. 2.Many multicast sessions will be sparse mode sessions, in which members are scattered over the Internet. This also reduces the probability of having active multicast sessions in the next network. In this scenario, after a handover to the next network, the mobile node waits for an new IGMP Membership Query. It is this message that triggers the mobile node to send an IGMP Membership Report to the multicast routers. However, this will probably result in a big traffic gap in receiving, since the average waiting time for an IGMP Membership Query by a mobile node after a handover is around half of the IGMP Query Membership Interval. In typical implementations, the IGMP Query Membership Interval usually is 60 or 120 seconds, resulting in 30 or 60 seconds of average handover latency. In the following text, we use "handover latency" to indicate the traffic gap (in time domain) a mobile node suffers during a handover. Once the mobile node receives an IGMP Membership Query, it sets a delay timer for each group. Each timer is set to a different random value between 0 and Max Response Time. It is after this timer's expiration that the mobile node sends an IGMP Membership Report to the multicast routers, which in turn start to establish the multicast tree. The handover latency introduced by the back off sending IGMP Membership Report is on average half of the Max Response Time. In typical implementations, the Max Response Time is 10 seconds, resulting in 5 seconds of average handover latency. Besides the latency introduced by IGMP process, the mobile node also needs to establish the multicast tree to the up-streaming routers. The tree establishing procedure is started right after the multicast routers receiving the IGMP Membership Report, which introduces additional latency in the handover. The tree establishing latency depends on the distance between the leaf multicast router and the closest up-streaming router, and the current situation of the networks. This latency is short in many cases (in the magnitude order of several tens of milliseconds), so that it is insignificant when compared with the potential latency introduced by IGMP. However, the tree establishing latency is not negligible when the distance to the up-streaming router is very long or the networks are instable. Looking a little closer, the situation after the handover is similar to when a multicast application first starts running in the mobile node - in this case the application triggers the IGMP to emit an unsolicited IGMP Membership Report, which eliminates the Jiang [Page 4] INTERNET-DRAFT Expires October, 2000 April 2000 start up latency by allowing the mobile node to report its presence without waiting for the IGMP Membership Query. The remaining latency only results from the tree establishing procedure. However, in the current Internet, neither the multicast applications nor IGMP has the mechanism to detect the handover and trigger the unsolicited IGMP Membership Report. The potential handover latency for a mobile node thus is very long in receiving IP multicast traffic [see section 6]. 1.1. New Architecture Entities The MSA protocol introduces the following new architectural entities: Mobile Node A host that changes its point of attachment from one network or subnetwork to another. Mobility Support Agent An agent on a network which acts as a proxy for mobile nodes (that potential might come to this network) to establish the multicast tree in advance of the mobile nodes' arrival. In addition, this agent can also be used to advertise the services available on its subnet to the mobile nodes. 1.2. Terminology The terminology used in this draft mostly is the same as used in Mobile IP. The different/additional definitions used in this draft are: Visiting network The IP subnet that the mobile node is currently visiting. Neighboring network An IP subnet that is geographically a neighbor of the visiting IP subnet. Next network (to be visited) The IP subnet that that the mobile node will be connected to (i.e., to which it handsover). Previous network - i.e., Previously visited network The IP subnet that the mobile node has just visited. Jiang [Page 5] INTERNET-DRAFT Expires October, 2000 April 2000 1.3. Protocol Overview The following protocols are defined for IP multicast mobility support: Agent Discovery The MSAs may advertise their availability and the services they provide for their subnet. A mobile node utilizes these advertisement and makes a handover accordingly. Agent Discovery consists of two parts: Inter-Agent Advertisement among the MSAs and the Agent-MN Advertisement between the mobile node and its directly attached MSA. Pre-registration In advance of the handover, the mobile node pre-registers with the MSA on the next network. Based on this pre-registration the MSA establishes the multicast tree and negotiates for services (as a proxy of the mobile node). De-registration After moving to another network, a mobile node de-registers with the MSA on the previous network. De-registration explicitly removes stale states which might otherwise lead to unnecessary traffic being sent to the previous network. The following steps provide a rough outline of the operation of the MSA protocol: - MSAs advertise their presence and services (bandwidth reservation, authentication, etc.) via Agent Advertisements. A mobile node may optionally solicit an Agent Advertisement from any locally attached MSAs through an Agent Solicitation. - A mobile node about to make a handover chooses one or more most-likely next network (perhaps via a movement prediction algorithm) and sends Pre-registration(s) to the MSA on the potential next network(s). - After authentication and following negotiation between the mobile node and each of these MSAs, these MSAs can now act as a proxy for the mobile node in setting up the requested multicast sessions. IGMP messages are exchanged between the MSA and its directly attached multicast routers. - As soon as the mobile node arrives at the next network, it resumes receiving the IP multicast traffic with the minimum possible latency, since the join occurred even before it arrived. Jiang [Page 6] INTERNET-DRAFT Expires October, 2000 April 2000 - Once confirmed that it is successfully receiving IP multicast traffic, the mobile node sends De-registrations to the MSA on the preciously visited network. If this mobile node was the last mobile member in a multicast group on the previous network, the MSA sends a IGMPv2 Leave Group message for that specific multicast group. 1.4. Message Format The MSA protocol messages are quite similar to the Mobile IP message format. One reason is that both are tackling the IP mobility problem, so that the MSA can be integrated with Mobile IP agents in one unit. Another reason is that Mobile IP protocol messages provide a flexible way to make protocol extensions. The MSA protocol defines several new control messages: Pre-registration De-registration They are sent with UDP [7] using the well-known port number 434, the same port number used for Mobile IP Registration Request/Reply messages. Inter-Agent Advertisement Inter-Agent Advertisement has its own message format. It uses multicast datagrams instead of unicast datagrams. The involved MSAs are allocated a dedicated multicast group, to which all MSAs are both senders and receivers. MSA protocol defines a general Extension mechanism to allow optional information to be carried by MSA control messages or by ICMP Router Discovery messages [5] (just as in Mobile IP). Each of these Extensions is encoded in the following Type-Length-Value format: 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Data ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type Indicates the particular type of Extension. Length Indicates the length (in bytes) of the data field within this Extension. The length does NOT include the Type and Length bytes. Jiang [Page 7] INTERNET-DRAFT Expires October, 2000 April 2000 Data The particular data associated with this Extension. This field may be zero or more bytes in length. The format and length of the data field are determined by the type and length fields. The extension messages are: Those appearing in the ICMP Router Discovery message Agent-MN Advertisement Extension Registration Confirm Extension MN History Extension Those appearing in the MSA protocol control message MN Authentication Extension 2. Agent Discovery The Agent Discovery protocol is used to advertise the presence of MSAs and their services. Unlike Mobile IP, mobile nodes do not use MSA Agent Discovery protocol to determine its current location or to detect the node's movement. For the MSA architecture, movement detection can either be performed with the help of Mobile IP or by using link layer mechanisms. Because a mobile node wants to (quickly) use the services on its next network, movement prediction is a very important part of the MSA architecture. In this draft, however, we do not specify the way to do movement prediction. 2.1. Inter-Agent Advertisement A group of cooperating MSAs form their own multicast group to advertise their availability and services to each other. The Inter-Agent Advertisements are not directly received by the mobile nodes. The address of the multicast group can either be a administrative multicast address or other pre-defined addresses. The most important field within a Inter-Agent Advertisement is the MSA's unicast IP address. Using this address a mobile node can pre-register. Inter-Agent Advertisement can also advertise the services that the local MSA provides and the current link situation of the local network. These are done by using the extensions. IP fields: Source Address Typically the MSA interface address from which the message is sent. Destination Address The multicast address for the MSA group. Jiang [Page 8] INTERNET-DRAFT Expires October, 2000 April 2000 UDP fields: Source Port variable Destination Port TBN The UDP header is followed by the advertisement fields shown below: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NetType|A|R| Reserved | Current Free Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Zero or more Neighboring MSA Addresses | | ... | Lifetime The valid time period for a Inter-Agent Advertisement, measured in seconds. Sequence Number The count of Agent Advertisement messages sent since the agent was initialized. NetType The link layer network that the MSA is attached to, for instance, WLAN (1), Ethernet (2), GPRS (3), etc. A Authentication required. R Resource reservation available. Reserved For future extension. Current Free Bandwidth The estimated spare bandwidth available (in kbps) in the network, used for adaptive applications, e.g., layered multicast applications. Neighboring MSA address Unicast IP address of neighboring MSA's. 2.2. Agent-MN advertisement The Agent-MN advertisement makes use of the Mobile IP Agent Advertisement Extensions of the ICMP Router Advertisement. Advertisement messages are transmitted by a MSA to the mobile nodes which are on the same network. The information advertised by the MSA is either directly retrieved from the Inter-agent Discovery messages, or derived from them. Within an Agent Advertisement message, ICMP Router Advertisement fields of the message have the same requirements as in Mobile IP. Jiang [Page 9] INTERNET-DRAFT Expires October, 2000 April 2000 2.2.1. Neighboring Network Extension 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSA Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NetType|A|R| | Current Free Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSA Address n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NetType|A|R| | Current Free Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBN Length (2+4*N), where N is the number of MSA addresses advertised. Sequence Number The count of Agent Advertisement messages sent since the agent was initialized MSA Address n The neighboring MSA's unicast IP address to which a mobile node can send pre-registration requests to. 2.3. Agent Solicitation Mobile nodes may send an Agent Solicitation message when moving to the next network. An Agent Solicitation uses the ICMP Router Solicitation with the IP TTL set to 1. 2.3.1. MSA History Extension In the MSA History Extension, the mobile node records the most recently visited MSAs in reverse sequence. The current serving MSA can determine its neighboring peers from the history list. Jiang [Page 10] INTERNET-DRAFT Expires October, 2000 April 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 | Length |O 1|O 2|O 3|O 4|O 5|O 6|O 7|O 8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Visited MSA 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp in 1 | Timestamp out 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Visited MSA n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp in n | Timestamp out n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBN Length (2+4*N) O n Optionally records the overlap status between the network n and network (n-1). Possible values are: 0 non-overlap, 1 partial overlap, 2 full overlap. Visited MSA n The MSA that has been visited by the mobile node, 1 is the most recently visited, while n is the MSA visited n hops back. Timestamp in/out n The time (in seconds) when the mobile node first receives an Agent advertisement (in), and the time when the mobile node sends a Pre-registration (out). 2.4. MSA considerations Every MSA must send Agent advertisements. However, it must limit the rate at which it sends broadcast or multicast Agent Advertisements. A recommended maximum rate is once per second. For Inter-Agent Advertisement, all the involved MSAs must be both senders and receivers. To avoid synchronization of the advertisement messages, sending to the multicast group should be randomized in time. Each MSA keeps a table including a list of peer MSAs serving their own network and their corresponding services and information. By collecting the MSA History Extensions, MSAs are able to work out a map of the network topology with MSA services. If MSA is deployed on each network, full geographic topology of the networks can be revealed. This map can optionally be advertised to the mobile nodes for aiding movement prediction. The detailed operation is not discussed in this draft. Jiang [Page 11] INTERNET-DRAFT Expires October, 2000 April 2000 2.5. Mobile Nodes Considerations In order to take advantage of the MSAs, mobile nodes may process received Agent Advertisements. They may report their MSA history list by sending MSA History Extensions. There might be loops in the history list. Mobile nodes can use this information and the timestamps together with the map information to analyze the user's movement behavior, which aids movement prediction. In the MSA History Extension, the information of whether the neighboring networks are overlapped or not is optional. One straight forward mechanism possibly can be used is for the mobile node to monitor all the network interfaces. If the mobile node can hear simultaneously signals from the neighboring networks, it can assume the networks are overlapped. Multiple wireless interfaces are needed and required to monitor the channels when the neighboring networks are heterogeneous. 3. Pre-registration Pre-registration is the key method for a mobile node to enable seamless handover relative to multicast. By pre-registration, a mobile node can: - Negotiate services on the next network. - Request that the corresponding MSA set up services in advance; in the case of multicast, the MSA helps to set up the multicast tree. Pre-registration has one new control message type: Pre-registration The MSAs use the UDP port 434 for listening to the Pre-registrations. For each multicast group, the MSA creates an entry in its mobile multicast table. The reason to use the same well-known UDP port as Mobile IP registration is that the MSA can also act as a Mobile IP Home Agent or Foreign Agent. It can also be used for pre-registration for IP unicast (which is not developed further in this draft). 3.1. Pre-registration A mobile node sends a pre-registration to the MSA on the next network before it makes a handover. This message contains a timestamp and all the multicast groups that are currently active in the mobile node. Pre-registration does not require feedback from the MSA, because the mobile node might have left the current visiting network before the feedback is available. In order to improve reliability, the mobile node is required to send the same pre-registration 3 times. Jiang [Page 12] INTERNET-DRAFT Expires October, 2000 April 2000 IP fields: Source Address Typically the mobile node interface address (a unicast IP address) from which the message is sent. Destination Address The unicast address of the MSA on the next network. UDP fields: Source Port variable Destination Port 434 The UDP header is followed by the Mobile IP fields shown below: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or more Multicast Address(es) | | ... | Type TBN Reserved For future use. Lifetime The number of seconds remaining before the registration is considered expired. Multicast Addresses The multicast address for each group that the mobile node is participating as receiver. 3.2. Registration Confirm Extension Once the MSA receives a pre-registration, it initiates the process to establish the corresponding multicast tree. At the same time it checks if the multicast group in the message is present on the local network. If not, it will setup a timer which has the value of "Lifetime" in the Pre-registration message. During the "Lifetime" period, the MSA waits for a Registration Confirm from the mobile node. The mobile node sends the Registration Confirm to the MSA only after it has moved to the next network and successfully received the first multicast datagram. After receiving the Registration Confirm, the MSA stop the timer and send a De-registration to the MSA on the previous network. The way to find out the previous network is by looking for the mobile node's identity and its MSA history list. Jiang [Page 13] INTERNET-DRAFT Expires October, 2000 April 2000 The Registration Confirm Extension makes use of the ICMP Router Solicitation Extension: 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 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous MSA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or more multicast address | | ... | Type TBN Length (2+4*N) Previous MSA The MSA on the previous network that the De-registration message will be sent to. Multicast Address The multicast address that the mobile node is currently participating as receiver. 3.3. MSA considerations 3.3.1. Visitor Counter A MSA maintains a visitor counter for each multicast group that are pre-registered by the mobile nodes. The counter records the number of mobile nodes on the network are receiving the corresponding multicast group. The counter increases by one every time the MSA receives a Registration Confirm for that multicast group, decreases by one when the MSA receives a De-registration for that multicast group. A counter is created when the MSA receives the first Pre-registration for that multicast group. But the counter number is not initialized until the MSA receives the first Registration Confirm. If the timer set by the MSA for Registration Confirm expires, the counter is removed. 3.3.2. Mapping Table Every MSA maintains a Mapping Table to reveal the relations among the MSA enabled networks. The mapping information either comes from the mobile node's MSA History Extension or by manual configuration when the MSAs are setup. The MSAs exchange the information with each other via the Inter-Agent Advertisement, thus every MSA can compute the full map on its own. Jiang [Page 14] INTERNET-DRAFT Expires October, 2000 April 2000 A Mapping Table has following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer MSA Address | HopCount | Overlap | Services | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 130.237.216.146 | 3 | 0 | AR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 130.237.15.178 | 0 | 1 | A | | ... | ... | ... | ... | Peer MSA Address Normally the unicast IP address the peer MSA uses for receiving the Pre-registrations. HopCount It indicates how many networks away the peer MSA is. When the MSAs are not fully deployed in the networks, the HopCount is only meaningful for those networks with MSA. Overlap HopCount value 0 indicates the network served by the peer MSA and the local networks are overlapped. Overlap 1 indicates they are partially overlapped. Services The services that the peer MSA provides, it has the same convention as in the Inter-Agent Advertisement. 3.3.3. IGMPv2 Process On the MSA's directly attached network, the MSA acts as an individual IGMP entity as the other nodes do on the network. To the registering mobile nodes, the MSA functions as the IGMP proxy. The MSA should immediately transmit an unsolicited Membership Report for that group when a new Visitor Counter is initialized for a multicast group. It should send a Leave Group message to the all-routers multicast group (224.0.0.2) when a multicast group entry is removed. The MSA is only responsible for establishing the multicast tree if it is not already done for the pre-registered mobile nodes. Once a mobile node is on the MSA's directly attached network, IGMP messages are exchanged in the normal way between the mobile host and the multicast routers. 3.3.4. Multicast Routing Protocol Process Once the IGMP process in a multicast router receives a membership report for a new group, it will notify the multicast router to add a routing entry for the corresponding multicast group in its routing table. Usually the multicast router immediately start the tree establishing process. It sends a "join/prune" message (in PIM) Jiang [Page 15] INTERNET-DRAFT Expires October, 2000 April 2000 or "graft" message (in DVMRP) to their up-streaming routers. The latency in this process is introduced by the processing time and propagation delay. This latency normally is not much, however, when the up-streaming multicast router is geographically far away or the networks are not stable, the propagation delay would be significant. 3.3.5. Other Services Other services may be available as options in the MSA. All these services may use the extensions of Pre-registration to negotiate and use extensions of Inter-Agent Advertisement to advertise. One of these services is that the MSA can buffer some multicast packets for the coming mobile node if it is asked by that mobile node. Another is that MSA acts as a multicast router on the local network which establishes tunnels with other MSAs or multicast Routers. These services are not parts of this draft specification. 3.4. Mobile Nodes Considerations A mobile node sends Pre-registrations via UDP datagram with the destination port 434, the destination IP address is the MSA on the next network. It listens to the ICMP Router Advertisement to determine the default router. No feedback is needed in the Pre-registration protocol. In addition, authentication can use the extension mechanism as done in Mobile IP. It is quite possible that after a mobile node sends one or more Pre-registrations to the MSA on the next network, it does not handover to that network. Without receiving a Registration Confirm during the "Lifetime" period (specified in the Pre-registration), the MSA will "prune" the multicast tree if there are no other members on its local network. The mobile node must not trigger another pre-registration process within the "Lifetime" period. After the "Lifetime" interval, it may do a pre-registration according to the new situation and the movement prediction mechanisms. 4. De-registration De-registration is used for de-registering with the MSA on the previous network. When the Visitor Counter for a multicast group reaches 0, the MSA acting as an ordinary IGMP entity sends an IGMP Leave Group message for that multicast group too the multicast routers. This procedure eliminates the IGMP leaving latency on the previous network if there are no fixed members on the previous network. IP fields: Source Address Typically the mobile node interface address (a unicast IP address) from which the message is sent. Jiang [Page 16] INTERNET-DRAFT Expires October, 2000 April 2000 Destination Address The MSA on the previous network. UDP fields: Source Port variable Destination Port 434 The UDP header is followed by the Mobile IP fields shown below: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | One or more Multicast Address | | ... | Type TBN Reserved For future use. Multicast Address The multicast group that the mobile node has participated as receiver on the previous network. De-registration uses UDP and does not require the feed back, the mobile node should send De-registration 3 times in sequence. 5. Security Considerations The major security attacks may come from: 1.The forged Inter-Agent advertisements may prevent the mobile nodes from knowing the correct network situation, which will lead to wrong handover decisions. 2.The forged Pre-registrations or De-registrations may trigger the MSAs to establish or tear down the multicast tree improperly. Too many such messages may overload a MSA. These attacks can be to large extend avoided by using authentication among the MSAs and mobile nodes. 6. Performance Measurements We have simply implemented the protocol in our own testbed. Measurements have been made to test how much handover performance regarding to handover latency can be improved by using pre-registration in with the MSA architecture. IGMPv2 and PIM-SM are used in the testbed, with IGMP Membership Query Interval Jiang [Page 17] INTERNET-DRAFT Expires October, 2000 April 2000 configured to 60 seconds and Max Response Time configured to 10 seconds. Results show that without pre-registration the average handover latency is around 32 seconds, in which 27 seconds due to IGMP Membership Query waiting, 5 seconds due to the random back off in sending IGMP Membership Report. In our testbed, the closest up-streaming multicast router is always close to the leaf multicast router and the networks are stable, so the tree establishing latency is only around several tens of milliseconds. By using pre-registration with MSA, all the IGMP and tree establishing processes are done in advance of the mobile node's handover. Our measurements show that the major latency is from the physical movement. Since we used a SNMP controlled multi-segment 10BT Ethernet hub to emulate the handover, the physical movement latency is around several milliseconds. 7. Acknowledgments A lot of thanks to Chip Maguire, Bjorn Pehrson, and J-O Vatn for the discussions and comments on this draft. 8. References [1] C. Perkins, "IP Mobility Support", RFC 2002, October 1996. [2] W. Fenner, "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [3] Estrin, et. al., "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. [4] Waitzman, Partridge & Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1998. [5] Deering, S., Editor, "ICMP Router Discovery Messages", RFC 1256, September 1991. [6] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989. [7] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [8] J. Moy, "Multicast Extensions to OSPF", RFC 1584, March 1994. [9] S. Glass, S. Jacobs, C. Perkins, "Mobile IP authentication, authorization, and accounting requirements", draft-ietf-mobileip-aaa-reqs-00.txt, October 1999. Jiang [Page 18] INTERNET-DRAFT Expires October, 2000 April 2000 9. Authors' Addresses Contact Information Jiang Wu KTH/IT, Electrum 204 S-16440 Kista, Sweden Tel : +46 8 752 1484 Fax : +46 8 751 1793 Email: jiang@it.kth.se Jiang [Page 19]