INTERNET-DRAFT Jiwoong Lee Expires: Jun 2002 KTF Advanced Lab 27 December 2001 Multicast Avalanche Avoidance in Mobile IP (MAAMIP) 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 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 obsolete by other documents at anytime. 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. All remarks may be forwarded to author's email address or to Xcast IG(Incubation Group) homepage http://www.xcast-ig.org. Abstract While it is a necessary feature that the home agent tunnels multicast packets to mobile nodes away from home, it can cause severe network congestion on the forward path between the home agent and the care-of address nodes, because of the unicast tunneling of multicast packets. Multicast avalanche avoidance in Mobile IP (MAAMIP) is designed to avoid the network congestion by using of Explicit multicast tunneling. Explicit multicast tunneling in Mobile IP enables avoidance of network congestion and realizes the true bandwidth saving, which is the primitive goal of multicast. Jiwoong Lee Expire Jun 2002 [Page 1] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 1. Introduction Mobile IP[1, 2] is a network layer protocol that enables an Internet node to be accessible from the rest of the Internet even though it changes its attached network. A mobile node away from its home can receive Internet multicast packets either with home network subscription or with local network subscription. If available, the local network subscription is superior to the home network subscription in following points; - Optimized delivery path of multicast from the source - Less overhead in dynamic tunnel management - No requirement of nested encapsulation Nevertheless, home network subscription is necessary in some ser- vice and topologies. The details are explained in Section 1.1. Even though the home network subscription is required, it can cause a severe scalability problem in Mobile IP network. A single incoming multicast packet is converted into many number of unicast- encapsulated multicast packets, as if a small snowball induces avalanche. It is named as Multicast avalanche in Mobile IP and its detail is explained in Section 1.2. Section 1.4 introduces three new Internet multicast protocols called Explicit multicast (Xcast), Xcast delivery in Mobile IP network (XMIP), and Xcast tunneling (Xtun). Based on these new protocols, a solution to Multicast avalanche in Mobile IP is proposed - Multicast avalanche avoidance in Mobile IP. Section 2 overviews the protocol operations, which are specified in Section 3. 1.1. Multicast routing over Mobile IP In Mobile IP, a mobile node away from home can join the Host Group Model multicast session in one of two ways: home network subscription via home agent or local network subscription via a local multicast router in the visiting network. If a mobile node joins a multicast session via a local multicast router, one benefit of this approach is better route optimization along the multicast delivery path. However, if the mobile node needs to receive multicast packets unceasingly while moving, the following requirements must be satisfied: Jiwoong Lee Expire Jun 2002 [Page 2] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 - Every visiting network must provide at least one accessible multicast router. - The session must be widely available, over every visiting network. The problem of these requirements is the fact that they are practically in-achievable in many networks. - There might be no multicast router available in the visiting network. - Even though there is at least one multicast router in the visiting network, multicast service to the visiting mobile node in the foreign network might be administratively prohibited. - The multicast session necessary to the mobile node might be scope-limited; Any private session might be unavailable out- side the home network. Even public sessions might not be reachable to some foreign networks due to the limitation of delivery coverage. (Time To Live expiration of multicast packets.) Because it is not probable that above restrictions are always avoidable at every foreign network visited by mobile nodes, the home network subscription SHOULD be available to mobile nodes for the sake of the stable multicast service. 1.2. Multicast Avalanche - Performance degradation of home network sub- scription In order for the home agent to deliver incoming multicast packets to the registered mobile node who subscribed to multicast groups, except ones who did not, it is necessary that the home agent address the exact destination - where to deliver the multicast packets. For this reason when a home agent forwards an incoming multicast packet to the registered mobile nodes, this packet SHOULD be directly tunneled to the care-of address of the mobile node if it uses co-located care-of address, or MUST be first encapsulated in a unicast packet addressed to mobile node's home address and subsequently tunneled to mobile node's care-of address. This is the requirement of [1]. On the basis of these operations, every multicast packet SHOULD be separately tunneled to each registered mobile node. Since a single incoming multicast packet causes multiplication process at the home agent and multiple encapsulation as many as the number of the registered mobile nodes that subscribed multicast groups via home Jiwoong Lee Expire Jun 2002 [Page 3] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 agent, the forward paths between the home agent and the mobile nodes will be congested that times more. The packets encapsulated by the home agent does essentially carry the same payload, which is the original multicast packet. Therefore the primitive goal of multicast technology as bandwidth saving on shared paths is disregarded. This phenomenon is named as Multicast avalanche from now. Some research papers[4] call this as tunnel convergence problem. Multicast avalanche radically degrades the scalability of the Mobile IP network. The effective coverage of multicast avalanche spans all routing paths between the home agent and foreign networks from where mobile nodes subscribes multicast groups via home network subscription. 1.3. Mobile IP multicast in wireless cellular network The 3G wireless cellular system is regarded as the first commercial network that provides Mobile IP service. This system generally covers nation-wide area. Most of paths between home network- foreign network belong to the carrier's backbone network, whose bandwidth is directly connected to carrier's expense. Multicast service via home network subscription apparently overloads the carrier's backbone network, and the home agent. 1.4. An alternative: Explicit multicast over Mobile IP Explicit multicast (Xcast)[5] is a new kind of Internet multicast that has different genealogy from the traditional multicast schemes - the host group model multicast, which is based on RFC 1112[3]. Instead of being addressed to a group-specific multicast address, Xcast packets are addressed to a pre-defined link-local multicast address, named 'All_Xcast_Routers' for hop-by-hop forwarding and carries unicast addresses of destinations within themselves. Since Xcast routing is based neither on multicast address nor pre- established multicast routing table but solely on unicast addresses of destinations, Xcast utilizes the existing unicast Forwarding Information Base and does not require routing/group management information exchange, which is on the contrary required in the host group model based multicast.[6] Explicit multicast over Mobile IP (XMIP) [6] deals with the operations of mobile agents and mobile nodes in Mobile IP so that an Xcast-capable home agent receives Xcast packets on behalf of its registered mobile nodes and tunnels the packets to them. In order to tunnel an Xcast packet, the home agent encapsulates it within an Xcast packet (Xcast-in-Xcast tunneling). Xcast tunneling is a 1-to- Jiwoong Lee Expire Jun 2002 [Page 4] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 n style tunneling, that is, the tunnel has a single ingress-node and multiple egress-nodes. Utilizing Xcast feature, this new type of tunneling can be defined in the Internet. Bitmap inheritance technique helps the destinations of the original packet to be appropriately demultiplexed at each of tunnel egress-nodes. The original packet MAY be encapsulated within a unicast packet in some special cases. (Xcast-in-Unicast tunneling). Tunneling of Xcast packet is defined in Xcast Tunneling[7]. XMIP(Explicit Multicast delivery over Mobile IP) can be easily extended to support mobile agents to successfully deliver incoming host group model multicast packets to mobile nodes. Xcast tunneling instead of multiple unicast tunnelings does not cause network congestion; a single Xcast tunnel packet can reach all subscribing mobile nodes in foreign networks. This tunneling is called as Multicast-in-Xcast (M-in-X) tunneling and is defined in Section 7 of [7]. With M-in-X tunneling, the original multicast packets received by the home agent can be delivered to all subscribing mobile nodes with minimum bandwidth consumption, while the original packets are untouched. This technology used in avoiding network congestion in Mobile IP is named as Multicast avalanche avoidance in Mobile IP(MAAMIP). With MAAMIP, "A single packet per a link", the goal of Internet multicast can be conserved. 1.5. Terminology 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 RFC 2119[10]. In addition, this document frequently uses the following terms: Xcast Explicit Multicast MAAMIP Multicast avalanche avoidance in Mobile IP. XMIP Explicit Multicast delivery over Mobile IP X-in-X Xcast encapsulation within Xcast packet X-in-U Xcast encapsulation within Unicast packet Jiwoong Lee Expire Jun 2002 [Page 5] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 M-in-X Host group model multicast encapsulation within Xcast packet {} Inside of this braces means a complete copy of Internet packet. Home network subscription The multicast group subscription of mobile node via the home agent. This action includes the IGMP membership report to the home agent from the mobile node away from home. Local network subscription The multicast group subscription of mobile node via the local multicast route located in the visiting network. This action includes he IGMP membership report to the local multicast router. 2. Operation overview A home agent provides MAAMIP service to the mobile nodes that have participated in multicast groups with home network subscription. The home agent MUST know the home addresses of the mobile nodes that have requested subscription to a specific multicast group before it receives host group model multicast packets on behalf of the mobile nodes. When the home agent receives host group model multicast packets on behalf of the mobile nodes, it tunnels them to the mobile nodes. If mobile nodes are registered themselves with the home agent by using co-located care-of addresses, the home agent MUST encapsulate any incoming multicast packet within an Xcast packet addressed to the co-located care-of addresses of the mobile nodes. This is called M-in-X tunneling and tunneling scheme is specified in Section 7 of [7]. Otherwise, the home agent SHOULD encapsulate the incoming multicast packet within an Xcast packet addressed to the home addresses of all the subscribing mobile nodes (M-in-X), and encapsulate this tunnel packet within another Xcast packet, which is addressed to the foreign-agent care-of addresses of the subscribing mobile nodes (X-in-X). Alternatively, the home agent MAY encapsulate an incoming multicast packet within an Xcast packet, which is addressed to the home addresses of the subscribing mobile nodes who share the same foreign-agent care-of address in a visiting network (M-in-X), and encapsulate this tunnel packet within a unicast packet, which is addressed to the foreign-agent care-of address (X-in-U). Jiwoong Lee Expire Jun 2002 [Page 6] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 Mobile agents and mobile nodes MUST understand XMIP[6] and Xtun[7] to provide MAAMIP service. The intermediate routers between the home agent and the mobile nodes MUST understand Xcast routing. 3. Protocol Operations 3.1. HA Operations The home agent supporting delivery of host group model multicast packets to its registered mobile nodes away from home MUST know which multicast group each mobile node participates in with home network subscription. If there is at least one mobile node which subscribes a multicast group, the home agent MUST receive the multicast packet of that group on behalf of the mobile node. The home agent does not receive host group model multicast packets on behalf of mobile nodes who reside in the home network (or home link.) 3.1.1. In IPv6 In IPv6, all the mobile nodes away from home use co-located care-of addresses. When the home agent receives a multicast packet, it MUST encapsulate the packet within an Xcast packet. The tunnel Xcast packet MUST be addressed to care-of addresses of all the subscribing mobile nodes, if the addressing space in the packet is allowed. Because one mobile node requires more than 128bit space in the tunnel header, the number of the tunnel egress-nodes is limited by Maximum Transfer Unit (MTU) of the forward links, and by the technical limit of the number of the addresses in an Xcast header - 127 addresses. Therefore if there are too many subscribing mobile nodes for a multicast group that those addresses cannot be addressed in one Xcast tunnel header, then the home agent MUST replicate the original multicast packet so as that all the care-of addresses of the subscribing mobile nodes can be addressed in the tunnel Xcast headers of multiple packets. The tunnel header MUST satisfy the following format: - The Source Address of the tunnel packet MUST be the address of the home agent. - The Destination Extension Header specifying Port List MUST NOT appear. - The A-bit, X-bit and D-bit in the Routing Extension header MAY be set as 1 according to the administrative policy at the home Jiwoong Lee Expire Jun 2002 [Page 7] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 agent. - The Channel Identifier in the Routing Extension header MAY be set. If set, the value of the Channel Identifier MUST be the Destination Address of the original multicast packet. 3.1.2. In IPv4 In IPv4, mobile nodes away from home use either co-located care-of addresses or foreign-agent care-of addresses. If mobile nodes subscribing a multicast group have registered themselves with the home agent using co-located care-of addresses, the home agent MUST tunnel the original multicast packet in M-in-X style; that is, the home agent MUST encapsulate the original multicast packet within an Xcast packet, which is addressed to the care-of address of each node in that group, if the addressing space in the packet is allowed. If mobile nodes subscribing a multicast group have registered themselves with the home agent using foreign-agent care-of addresses, the home agent tunnels the original multicast packet in one of two styles for this group of nodes; the home agent SHOULD first encapsulate the original multicast packet within an Xcast packet which is addressed to the home address of each node in that group (M-in-X tunneling), and then encapsulate this Xcast packet within another Xcast packet which is addressed to the registered foreign-agent care-of addresses of mobile nodes in that group (X- in-X tunneling). Consequently, the home agent performs {M-in- X}-in-X tunneling as a nested tunneling. The home agent MUST follow all the detailed Xcast tunneling mechanism specified in [7]. Otherwise, the home agent MAY first replicate the original multicast packet as many as the number of the foreign-agent care-of addresses which the mobile nodes subscribing a multicast group have registered themselves with the home agent by using. After this, it MUST encapsulate each copy of the multicast packets within an Xcast packet, which is addressed to the home addresses of the mobile nodes sharing the same foreign-agent care-of address in a visiting network, and then MUST encapsulate the tunnel packet within a unicast packet, which is addressed to that foreign-agent care-of address. Consequently, the home agent performs {M-in-X}-in-U tunneling as a nested tunneling. The home agent MUST follow all the detailed Xcast tunneling mechanism specified in [7]. For all cases, the tunnel header MUST satisfy the following format: - The Source Address of the tunnel packet MUST be the address of the home agent. Jiwoong Lee Expire Jun 2002 [Page 8] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 - The P-bit in the Xcast header MUST be set as 0 and correspond- ingly Port List MUST NOT appear. - The A-bit, X-bit and D-bit in the Xcast header MAY be set as 1 according to the administrative policy at the home agent. - The Channel Identifier in the Xcast header MAY be set. If set, the value of the Channel Identifier MUST be the Destina- tion Address of the original multicast packet. 3.2. FA Operations The foreign agent operations are only applicable in IPv4 case. There are two forms in which the home agent tunnels the original multicast packet to the foreign agent. They are {M-in-X}-in-X and {M-in-X}-in-U. Whatever the tunnel packet is in form of, when the foreign agent receives the tunneled Xcast packet, it MUST decapsulate the received packet and route the original packet if the outermost tunnel packet is addressed to its address. 3.3. MN Operations Mobile nodes MUST have the Xcast decapsulation capability to receive the Xcast-tunneled multicast packets. A mobile node MUST decapsulate the tunnel packet if the tunnel Xcast packet is addressed to its home address or its co-located care-of address. If the received tunnel packet is not addressed to its home address nor its co-located care-of address, it MUST discard this tunnel packet. When the mobile node receives a tunneled multicast packet, it loops back the original packet to its network module after decapsulation. 4. Security Considerations Since the original multicast packet is encapsulated within a packet with its destination specified, the confidentiality-sensitive multicast data can be delivered in more controlled manner. The home agent MAY be administratively configured to allow / disregard the IGMP[8] membership report from the particular mobile node residing at a particular foreign network. When a mobile node has registered itself with the home agent by using a foreign-agent, if the home agent does not trust the foreign agent it MAY refuse tunneling the original multicast packet to that foreign agent. Jiwoong Lee Expire Jun 2002 [Page 9] INTERNET-DRAFT Multicast Avalanche Avoidance Dec 2001 Reference [1] C. Perkins, IP Mobility Support for IPv4, revised, draft-ietf- mobileip-rfc2002-bis-06.txt, June 2001 [2] D. Johnson and C. Perkins, Mobility Support in IPv6, draft-ietf- mobileip-ipv6-14.txt, July 2001 [3] S. Deering, Host Extensions for IP Multicasting, RFC 1112, August 1989. [4] T. G. Harrison, C. L. Williamson, et al., Mobile Multicast (MoM) Protocol: Multicast Support for Mobile Hosts, ACM/IEEE MOBICOM'97, September 1997 [5] R. Boivie, Y. Imai, W. Livens, D. Ooms, and O. Paridaens, Explicit Multicast Basic Specification, draft-ooms-xcast-basic-spec-01.txt, March 2001 [6] J.Lee, M. Shin, Explicit Multicast over Mobile IP, draft-lee-xcast- mobileip-00.txt, November 2001 [7] J. Lee, Explicit Multicast Tunneling, draft-lee-xcast-tunnel- ing-00.txt, December 2001 [8] W. Fenner, Internet Group Management Protocol, Version 2, RFC 2236, November 1997 [9] S. Deering and R. Hinden, Internet Protocol, Version 6 (IPv6) Spec- ification, RFC 2460, December 1998 [10] Scott Bradner, Key words for use in RFCs to Indicate Requirement Levels, RFC 2119, March 1997 Author's Address Jiwoong Lee Korea Telecom Freetel Advanced Lab 1321-11 Seocho-Dong Seocho-Ku Seoul Korea, Republic of Phone : +82-2-3488-0416 Email : porce@ktf.com Jiwoong Lee Expire Jun 2002 [Page 10]