INTERNET-DRAFT Jiwoong Lee Expires: April 2001 Korea Telecom M.com Research Center October 2000 SGM support in Mobile IP 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. Abstract In the current version of mobile IP a home agent converts a incoming generic multicast datagram to multiple unicast- encapsulated datagrams addressed to each mobile node. This kind of multicast handling logically works, while suffering from the performance degradation. Small Group Multicast (SGM) is a newly developed multicast protocol whose level 3.5 header carries multiple unicast destination addresses [2]. SGM support in mobile IP enables the home agent to forward a generic multicast datagram to a foreign agent with one SGM datagram, eliminating the severe performance degradation. 1. Introduction Small Group Multicast (SGM) is a newly developed multicast protocol to support large number of small multicast groups in the Internet. It does not use multicast group address of a class D range, but uses level 3.5 destination address list which enumerates the Jiwoong Lee Expires April 2001 [Page 1] INTERNET-DRAFT SGM support in Mobile IP October 2000 unicast address of each member node. Mobile IP enables nodes to move from one IP subnet to another, via special forwarding functions of mobile agents [1]. A mobile node acquires a "care-of address" in the foreign network, to where the home agent tunnels IP datagrams for the mobile node. Because IP mobility is based on the assumption that every node registered with a home agent can be located at totally different foreign networks, a multicast datagram also is converted to multiple unicast-encapsulated multicast datagrams and forwarded separately to mobile nodes away from home. The multicast support of this kind logically works, however, can be a major performance bottleneck for a particular group of network topologies and applications for multicast service. One good example is the real time multimedia multicast service in a 3G cellular network. In 3G networks, a foreign agent can cover a metropolitan area and most of mobile nodes in this area actually can register with one home agent. If 10 mobile nodes registered with one home agent join a multicast group concurrently, the associated multicast datagram will be converted to 10 unicast- encapsulated datagrams at the home agent and they will be forwarded to each member mobile node along the same tunnel path. ("A-mass- of-multicast" problem.) As a result, the tunnel path carrying the 'multicast' datagrams of the same payload will be congested as much as that carrying the 'unicast' datagrams will be. This is the exact opposite to the original goal of multicast routing technologies. This observation has been reported in [7]. In SGM supportable mobile IP networks, when a home agent receives a generic multicast datagram addressed to a group in which the home agents' mobile nodes are participating, the datagram is converted to SGM datagrams whose destination is the associated foreign agent and whose destination address list contains the addresses of mobile nodes participating the multicast group in foreign networks. The SGM capable home agent should manage 'explicit join status' with which it remembers the join status per mobile node, as already done in generic mobile IP. Indeed, SGM support in mobile IP protocol brings following advantages; it - solves out a-mass-of-multicast problem. A SGM-capable home agent forwards multicast datagrams to its registered member mobile nodes in SGM format, instead in unicast-encapsulated multicast format, effectively making the best use of multicast benefits while the current version of mobile IP cannot [1]. - is suitable for upcoming 3G cellular networks. A few foreign agents may cover the national-wide geographical ranges in Jiwoong Lee Expires April 2001 [Page 2] INTERNET-DRAFT SGM support in Mobile IP October 2000 which large number of mobile subscribers reside. Therefore, it is highly probable that many mobile nodes registered with the same home agent are located in the same foreign network while participating in the same multicast group. This means that a- mass-of-multicast problems are liable to be induced in 3G cellular networks. Besides in 3G cellular networks, multi- party conference call will be prevalent. An efficient multicast protocol such as SGM support in mobile IP will be very necessary. - supports more flexible multicast datagram transmission. Because the SGM routes datagrams based on destinations addresses without regard to the source address, a mobile node which sends multicast datagrams directly on the visited network DOES NOT have to use only a co-located care-of address as the IP source address. Similarly, a mobile node which tunnels a multicast datagram to its home agent DOES NOT have to use only its home address as the IP source. - DOES support SGM in mobile IP. This document is in conformance with [1], [2] and [6] in matters that are not dealt with in this document. 1.1. 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 [8]. In addition, this document frequently uses the following terms: MN Mobile node FA Foreign agent HA Home agent CN Correspondent node SN Stationary node SGM Small Group Multicast FA COA Foreign agent care-of address CL COA Co-located care-of address Generic Multicast Multicast which uses the class D destination address 2. SGM support in mobile IP 2.1. Overview Jiwoong Lee Expires April 2001 [Page 3] INTERNET-DRAFT SGM support in Mobile IP October 2000 The most prevalent mobile IP architecture in IPv4 world will include the tunneling between a HA and a FA and the use of a FA COA, due to the shortage of IP address resource. The multicast datagram can be delivered to a MN in a foreign network in one of two ways; delivering via a bi-directional tunneling or via a local multicast router. This document handles following cases. - Delivery of a SGM datagram to a MN via a HA. - Delivery of a generic multicast datagram to a MN via a HA. - Sending a SGM datagram from a MN The multicast datagram delivery via a local multicast router to MN who is using CL COA is not a matter of concern in this document. 2.2. Delivery of a SGM datagram to a MN via a HA If a SGM-capable HA receives a SGM datagram addressed to itself containing registered mobile nodes' addresses in the destination address list, it MUST partition those mobile nodes into each visited network. The visited networks MAY be distinguished basically by the addresses of foreign agents. When some mobile nodes use co-located care-of addresses allocated from their visited networks, the HA MUST send the SGM datagram to them in one of two ways. The first choice is that the HA processes the SGM datagram so as to generate the multiple unicast datagrams addressed to each co-located care-of address and sends them separately via the mobile IP tunnel to each mobile node. The better one is that the HA bounces the SGM datagram to the mobile nodes with the level 3.5 destination address list which contains the care-of addresses of mobile nodes, while not using the mobile IP tunnels. The latter choice SHOULD be applied only when other kinds of security protection rather than mobile IP security protection are provided, or, not required. Such security protection mechanisms are out of the scope of this document. When some mobile nodes use foreign-agent care-of addresses, the HA processes the SGM datagrams normally so that a replicated datagram contains the address of each foreign agent as the next hop and the address of the HA as the source. 2.3. Delivery of a generic multicast datagram to a MN via a HA If a SGM-capable HA receives a generic multicast datagram, it MUST partition member mobile nodes into each visited network. The visited networks MAY be distinguished basically by the addresses of foreign agents. Jiwoong Lee Expires April 2001 [Page 4] INTERNET-DRAFT SGM support in Mobile IP October 2000 If some mobile nodes use FA COAs, the HA converts a generic multicast datagram to multiple SGM datagrams which contains the address of each foreign agent as the destination. Every converted SGM datagrams MUST have the MNs' home addresses of the associated FA as the destination address list. The very end of the destination address list of the converted SGM datagram MUST contain the class D multicast group address copied from the destination address field of the original generic multicast datagram intercepted by the HA. Similarly the very end of the destination port list MUST contain the destination port number copied from the original generic multicast datagram. A converted SGM datagram MUST use the address of the HA as the source address and the address of a FA as the destination address. Then the HA encapsulates the converted SGM datagram with the encapsulation method which was negotiated during the registration process, before forwarding the converted SGM datagram to each FA. Upon receiving the SGM datagram, a FA SHOULD look up the last field of the destination address list. If it contains class D multicast group address, the FA can send the datagram to each MN in one of the two ways. The first choice is that the FA sends to each MN the processed SGM datagram whose destination is the MN, and whose destination address list contains the class D multicast group address. The MN receives this SGM datagram and convert it into the generic multicast datagram addressed to the specified class D address. The other choice is that the FA re-converts the SGM datagram into the generic multicast datagram addressed to the specified class D multicast group address. The FA sends this to each MN who is listed in the destination address list of the SGM datagram, with the unicast link layer address. If some mobile node use CL COAs, the HA MAY send the multicast datagram in one of two ways. The first choice is that the HA encapsulates it and sends it via the mobile IP tunneling between HA and CL COA MN, as described in [1]. The optional choice is that the HA generates SGM datagrams addressed to the next SGM router, contains addresses of CL COAs in its destination address list and sends it directly. The destination address list MAY contain the multicast group address of the original generic multicast datagram at the very end field. There MUST be some way that the interim SGM routers can process this SGM datagram, without dropping the last field of the destination address list. The edge router or the end mobile node SHOULD process this special SGM datagram in the same way as described above. Note that the mobile IP tunneling vanishes at the HA and the delivery of SGM datagram to the MNs are using CL COAs without the mobile IP tunnels DOES violate the specification of [1]. The latter choice SHOULD be applied only when other kinds of security protection rather than mobile IP security protection are provided, or, not required. Such security protection mechanisms are out of the scope of this document. To convert a generic multicast datagram properly, the HA utilizes the explicit membership management table as described in section Jiwoong Lee Expires April 2001 [Page 5] INTERNET-DRAFT SGM support in Mobile IP October 2000 3.1. 2.4. MN's sending a SGM datagram Sending a SGM datagram from a MN is possible in two ways. One is to use a local SGM router, and the other is to use a home SGM router. When sending a SGM datagram via a local SGM router, the MN MAY use its home address as the source address of the SGM datagram. This is possible since SGM routing is not based on the source address. When via a home SGM router, the HA and the FA MUST establish the bi-directional tunneling before. The HA MAY NOT be a SGM router. This is possible since the MN can establish a SGM tunnel over the mobile IP reverse tunnel to the SGM router without any concern about the routing loop. 3. Routing Considerations 3.1. HA Considerations A HA MUST be a SGM-capable router to process and forward the SGM datagrams addressed to MNs. The HA MUST provide the explicit membership management. That is, the HA MUST manage a table whose record has an active multicast group address (as the first field), addresses of FAs (as the second field) who serve the MNs participating that multicast group, and MN addresses (as the third field) participating that multicast group. For the MNs who are using CL COAs, their addresses MAY be inserted as the subsidiary field of [CL_COA_MN]. The value of [CL_COA_MN] is used as an internal reference of the SGM-capable HA, and the default value of it is set as 0.0.0.0. Group1 address +-> FA1 address +-> MN1 home address | +-> MN2 home address | \-> MN3 home address | +-> FA2 address +-> MN4 home address | \-> MN5 home address | \-> [CL_COA_MN] +-> MN6 CL COA \-> MN7 CL COA Group2 address --> FA3 address +-> MN6 home address \-> MN7 home address ..... Jiwoong Lee Expires April 2001 [Page 6] INTERNET-DRAFT SGM support in Mobile IP October 2000 (Figure 1) An example of table structure for explicit membership management of a HA If a HA receives an ICMP Destination Unreachable, Protocol Unreachable message from a the FA, HA MUST convert the corresponding SGM datagram to multiple unicast datagrams addressed to each mobile node who registered with that FA, as described in [2]. 3.2. FA Considerations Upon receipt of an encapsulated SGM datagram to a FA, the FA decapsulates it and makes sure that it is addressed to the FA itself. When the FA does not understand SGM, it SHOULD send an ICMP Destination Unreachable message with a code of 2, signifying Protocol Unreachable, to the source address of the received datagram. Note that sending an ICMP Destination Unreachable message to the HA violates the regulations declared in [1] since the destination address of the decapsulated datagram here is NOT listed in its visitor list of the FA. However, sending an ICMP error message, does not result in a routing loop in this case since the source address of decapsulated datagram is the HA and the destination address of it is the FA. Therefore it SHOULD NOT be any problem. If the FA receives an SGM datagram from its registered mobile node, it handles this as a unicast datagram. 3.3. MN Considerations A mobile node always receives the unicast datagram without regards to the fact that the corresponding node sends an SGM datagram, if it is not a SGM-capable mobile router. The MN's ability to receive a SGM datagram whose destination address list contains a class D multicast group address depends on the final specification of [2]. If the MN does not understand this, it MUST generate the corresponding ICMP error message to the source of the previous SGM hop. Otherwise, it SHOULD convert the datagram to a generic multicast datagram with the specified class D address before it hands over the datagram to the application. 3.4. Compatibilities with associated specification. SGM supports introduces some violations of the specification of the generic mobile IP. Jiwoong Lee Expires April 2001 [Page 7] INTERNET-DRAFT SGM support in Mobile IP October 2000 (a) The mobile IP tunneling MAY NOT be established between HA and CL COA nodes. (b) A FA MAY generates an ICMP error message in the visited net- work. SGM supports introduces some additional requirements of the speci- fication of Small Group Multicast. (c) The addition of the class D multicast group address at the very end of the destination address list of a SGM datagram. (This requirement has not been specified in SGM I-D yet. However, Xcast BOF is continuing the consideration of adding this.) 4. Security Considerations This document introduces currently no known security threats. The security considerations of SGM support in mobile IP relies on those of [1] and [2]. This document opens a possibility that no mobile IP tunneling is used between a HA and a MN who is using a CL COA when the HA forwards a SGM datagram to the MN. This should be applied only when the security protection is not necessary or when the other kinds of protection are provided. One example of protections is IPSec[9]. They are all out of scope of this document. 5. IPv6 Considerations SGM support in mobile IPv6 [8] becomes much easier than in mobile IPv4. Because every MN uses a CL COA in mobile IPv6, the HA who receives a SGM datagram or a generic multicast datagram can send the SGM-processed datagram directly to the CL COA, without establishing any tunnel. Appendix This appendix is not a part of the SGM support in mobile IP specification. A. Datagram Flows This section explains datagram formats and their flows from a correspondent node to a mobile node, or vice versa. Some of the explanation include the delivery of legacy unicast datagram and generic multicast datagram, while clarifying the differences to the delivery of a SGM datagram. Jiwoong Lee Expires April 2001 [Page 8] INTERNET-DRAFT SGM support in Mobile IP October 2000 Section A.2 describes the cases when a mobile node receives a datagram from a correspondent node, and section A.3 vice versa. A.1. Notation For the sake of efficient description and precise understanding of datagram flows, the following notation is locally defined in this section. The datagram format follows the network-byte order. "[ ]" ::= an legitimate IP datagram "S:" ::= source address field. "D:" ::= destination address field. "A:" ::= level 3.5 source address field "L:" ::= level 3.5 destination address list field "CN" ::= address of a correspondent node. "MN" ::= home address of a mobile node. "HA" ::= address of a home agent. "FA" ::= address of a foreign agent, or foreign agent care-of address. "CL" ::= co-located care-of address "SGM" ::= level 3.5 destination address list "Grp" ::= address of a multicast group "SN" ::= address of a stationary node. "LM" ::= address of a local multicast router A.2. Reception of datagrams (1) Unicast datagram from CN to MN, who is using a FA COA. PATH: CN -> HA -> FA -> MN a. CN sends [S:CN D:MN] b. HA sends [S:HA D:FA [S:CN D:MN] ] c. FA sends [S:CN D:MN] d. MN receives [S:CN D:MN] (2) SGM datagram from CN to SN. PATH: CN -> SN (where SN makes SGM) a. CN sends [S:CN A:CN L:SGM] b. SN receives [S:CN D:SN] Notice that MN who is in the home network works as if it is a stationary node. (3) Generic multicast datagram from CN to MN, who is using a FA COA and a bi-directional join. PATH: CN -> HA -> FA -> MN a. CN sends [S:CN D:Grp] Jiwoong Lee Expires April 2001 [Page 9] INTERNET-DRAFT SGM support in Mobile IP October 2000 b. HA sends [S:HA D:FA [S:HA D:MN [S:CN D:Grp] ] ] c. FA sends [S:HA D:MN [S:CN D:Grp] ] d. MN receives [S:HA D:MN [S:CN D:Grp] ] e. MN decaps [S:CN D:Grp] HA here is assumed to be a multicast router, as described in [1]. HA (as a multicast router) MUST manage the explicit membership of mobile nodes for multicast groups in this case. (4) Generic multicast datagram from CN to MN, who is using a j CL COA and a bi-directional join. PATH: CN -> HA -> MN a. CN sends [S:CN D:Grp] b. HA sends [S:HA D:CL [S:CN D:Grp] ] c. MN receives [S:HA D:CL [S:CN D:Grp] ] d. MN decaps [S:CN D:Grp] HA here is assumed to be a multicast router, as described in [1]. HA (as a multicast router) MUST manage the explicit membership of mobile nodes for multicast groups in this case. (5) Generic multicast datagram from CN to MN, who is using a FA COA and a local multicast router. PATH: CN -> LM -> MN a. CN sends [S:CN D:Grp] b. LM sends [S:CN D:Grp] c. MN receives [S:CN D:Grp] (6) Generic multicast datagram from CN to MN, who is using a CL COA and a local multicast router. PATH: CN -> LM -> MN a. CN sends [S:CN D:Grp] b. LM sends [S:CN D:Grp] c. MN receives [S:CN D:Grp] (7) SGM datagram from CN to MN, who is using a FA COA and a bi- directional tunnel. PATH: CN -> HA -> FA -> MN a. CN sends [S:CN A:CN L:SGM] b. HA sends [S:HA D:FA [S:HA D:FA A:CN L:SGM] ] c. FA sends [S:CN D:MN] d. MN receives [S:CN D:MN] Jiwoong Lee Expires April 2001 [Page 10] INTERNET-DRAFT SGM support in Mobile IP October 2000 (8) SGM datagram from CN to MN, who is using a CL COA and a bi- directional tunnel. PATH: CN -> HA -> MN a. CN sends [S:CN A:CN L:SGM] b. HA sends [S:HA D:CL [S:CN D:MN] ] c. MN receives [S:HA D:CL [S:CN D:MN] ] d. MN decaps. This case dose not acquire any bandwidth advantage over the case of generic multicast. If [1] relaxes the tunneling requirement between HA and CL COA MN. (9) SGM datagram from CN to MN, who is using a FA COA and a local multicast router. Not the case. (10) SGM datagram from CN to MN, who is using a CL COA and a local multicast router. PATH: CN -> LM -> MN a. CN sends [S:CN A:CN L:SGM] b. LM sends [S:CN D:CL] c. MN receives [S:CN D:CL] A.3. Transmission of datagrams (1) Unicast datagram from SN to CN. PATH: SN -> CN a. SN sends [S:SN D:CN] b. CN receives [S:SN D:CN] (2) SGM datagram from SN to CN. PATH: SN -> CN a. SN sends [S:SN A:SN D:SGM] b. CN receives [S:SN D:CN] (3) Generic multicast datagram to CN from MN, who is using a FA COA and a bi-directional tunneling. PATH: MN -> FA -> HA -> CN a. MN sends [S:MN D:Grp] b. FA sends [S:FA D:HA [S:MN D:Grp] ] Jiwoong Lee Expires April 2001 [Page 11] INTERNET-DRAFT SGM support in Mobile IP October 2000 c. HA sends [S:MN D:Grp] d. CN receives [S:MN D:Grp] The home agent here is assumed to be a multicast router, as described in [1]. Encapsulating delivery style MUST be used for the reverse tunneling [6]. (4) Generic multicast datagram to CN from MN, who is using a CL COA and a bi-directional tunneling. Not the case. [6] dose NOT address this kind of tunneling. (5) Generic multicast datagram to CN from MN, who is using a FA COA and a local multicast router. Not the case. [1] does not allow this situation. (6) Generic multicast datagram to CN from MN, who is using a CL COA and local multicast router. PATH: MN -> CN a. MN sends [S:CL D:Grp] b. CN receives [S:CL D:Grp] (7) SGM datagram to CN from MN, who is using a FA COA and a bi- directional tunneling. PATH: MN -> FA -> HA -> CN a. MN sends [S:MN D:SGM] b. FA sends [S:FA D:HA [S:MN D:SGM] ] c. HA sends [S:MN D:SGM] d. CN receives [S:MN D:CN] (8) SGM datagram to CN from MN, who is using CL COA and a bi- directional tunneling. Not the case. [6] does NOT address this kind of reverse tunneling (9) SGM datagram to CN from MN, who is using FA COA and a local multicast router. Note that SGM datagram does not rely on the source-specific routing. PATH: MN -> FA -> CN a. MN sends [S:MN D:SGM] Jiwoong Lee Expires April 2001 [Page 12] INTERNET-DRAFT SGM support in Mobile IP October 2000 b. FA sends [S:MN D:SGM] c. CN receives [S:MN D:CN] (10) SGM datagram to CN from MN, who is using CL COA and a local multicast router. PATH: MN -> CN a. MN sends [S:CL D:SGM] b. CN receives [S:CL D:CN] References [1] C. Perkins, IP Mobility Support, RFC 2002, Internet Engineering Task Force, July 1997 [2] R. Boivie, Small Group Multicast (work in progress), draft-boivie- sgm-01.txt, July 2000 [3] W. Fenner, Internet Group Management Protocol, RFC 2236, Internet Engineering Task Force, November 1997 [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] S. Deering, Host Extensions for IP Multicasting, RFC 1112, Internet Engineering Task Force, August 1989 [6] G. Montenegro, Reverse Tunneling for Mobile IP, RFC 2344, Internet Engineering Task Force, May 1998 [7] Tim G. Harrison, Garey L. Williamson, Wayne L. Mackrell, Richard B. Bunt, Mobile Multicast (MoM) Protocol: Multicast Support for Mobile Hosts, Proceedings of ACM/IEEE MOBICOM '97, September 1997 [8] David B. Johnson, Charles Perkins, Mobility Support in IPv6 (work in progress), draft-ietf-mobileip-ipv6-12.txt, April 2000 [9] Kent, S., R. Atkinson, Security Architecture for the Internet Protocol, RFC 2401, Internet Engineering Task Force, November 1998 Address Jiwoong Lee Expires April 2001 [Page 13] INTERNET-DRAFT SGM support in Mobile IP October 2000 Jiwoong Lee Korea Telecom M.com Research Center 1321-11 Seocho-Dong Seocho-Ku Seoul Korea 137-070 Phone: +82-2-3488-0416 Email: porce@m018.com Jiwoong Lee Expires April 2001 [Page 14]