INTERNET-DRAFT Expire in six months Chang Won Son Soo Hyoung Oh Ji Yeon Son ETRI ver. 1. April 1996 Distributed Dynamic Multicast Address(DDMA) Assignment in Internet Status of this Memo 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents a dynamic multicast address allocation and distribution scheme in the Internet address space. By the scheme a multcast address for a multicasted session is chosen by a host based on its own host address and port number of the session. I. Introduction Unlike a host address, which identifies a host in a network, a multicast address identifies a group of hosts. Theologically, the number of possible groups by the hosts have an exponential relationship to the number of hosts in a network. Thus, it is impractical to assign a multicast address for each possible groups. More attractive approaches are dynamical allocation schemes, by which a multicast address is allocated when a group is in session, then the address is released during dismantle of the session. The address can be reclaimed by other group sessions. While a multicast address is temporal address in the dynamic allocation schemes, the address should be allocated on demand. There are two distinguishable approaches. First, the address can be allocated by a multicast name server. The server is responsible to provide a globally unique multicast address by maintaining allocated address list. The list can be managed by a single server, or it can be distributed in multiple servers. Secondly, the address can be allocated by individual hosts. One of the simple solutions of the later approach is the random pick approach. With this approach, a host choose a multicast address randomly, then it advertises the address to find out that whether or not the address is claimed by any other hosts. If not, the address can be used by the host. Otherwise, the host picks another address. The process continues until an usable address can be found. The above approaches have significant address resolution delay and traffic. A distributed multicast allocation scheme proposed by [Pej] fixes the problems. In the approach, each individual host selects a multicast address which is based on its host address and port number of the multicast address requesting session. Since the tuple of host address and port number is globally unique, the uniqueness of the address can be achievable. The original scheme by [Pej] has some limitations, such as all multicast addresses which allocated within a subnetwork have same multicast network address, so that the multicast address can not be distinguishable by network layer, unless every hosts and gateways are modified to take the port number. This paper defines a distributed dynamic multicast addressing scheme, which is based on [Pej]. II. Distributed Multicast Address Allocation In the Internet environment, a host address is used to identify a node within a network, then port address is used to identify an endpoint of a data stream within the host. The host address and port address tuple identifies a globally unique endpoint of a data stream. Thus, a multicast address assigned by a host with the tuple should be globally unique. Currently, the host address consists of 4 octets and the port number consists of 2 octets. To be identified as a multicast address, the first octet of the Internet address should be chosen from 224 to 239. With the address components, globally unique multicast address can be assigned by 7 octets. As figure 1, the multicast address is constructed with multicast network address(1) and multicast port number(2). The highest octet of multicast network address is in [224-239] to indicate that the address is a multicast address. Then the other octets are taken from lower 3 octets of host network address. The highest octet of the host network address is used for low octet of the multicast port number. For the compatibility with existing address scheme, the 2 octets of port space is mapped into high octet of the multicast port number. If we consider that there are 16 choices in the highest octet of multicast network address for each hosts, each host can assign at most 4096 globally unique multicasted sessions without external assistance. Host IP Address Port +---------+ +-- ---+ | a.b.c.d | | u.v | +---------+ +------+ | | | | V V +---------------------------------------------------+ | +--------------+ (1) +--------+ (2) | | |224-239.b.c.d | |(u*v).a | | | +--------------+ +--------+ | +---------------------------------------------------+ Figure 1. Multicast Address allocation from Host Address Internet address is composed of domain and host address fields. In each domain all hosts have the same value in domain address field. The domain is classified as A, B, C and D. All hosts within a class C domain have the same address value in highest 3 octets of the address. All hosts within a class B domain have the same address value in highest 2 octets of the address. All hosts within a class A domain have the same address value in highest 1 octets of the address. The class D domain is assigned for multicast address. By using last 3 octets for multicast addressing, each host can assign locally unique multicast network address within a domain(A,B,C). III. Single Domain network Multicast sessions which are assigned by different hosts do not interfere each other within a domain. In figure 2, hosts A, B and C has an established multicast session with a multicast network address a which is allocated by host A. And host C, D, and E has an established multicast session with a multicast network address c which is allocated by host C. Then host A and B only receives multicasted data with multicast network address a. The host D and E only receives multicasted data with multicast network address c. And host C receives multicasted data with multicast network address a and c. As the result, the multicast network traffic between host A, B, and C with multicast network address assigned by host A does not interfere with the multicast network traffic between host C, D, and E with multicast network address assigned by host C. A B C D E | | | | | | | | | | |(a) |(a) |(a,c) |(c) |(c) ------+--------------+----------+---------+--------------+--- Network Address 10.x.x.x Figure 2. Single Domain Network IV. Network with Sub-domains Multicast sessions which are assigned by different hosts do not interfere each other within sub-domains from class A or class B network. Suppose above network has sub-domains, and the sub-domains are connected by routers. Then the multicast network addresses which are assigned by individual hosts in the domain still have different values each other. By that, the above statement is also true. In figure 3, hosts A, B, C, and D has an established multicast session with a multicast network address a which is allocated by host A. And host D, E, and F has an established multicast session with a multicast network address e which is allocated by host E. Then host A, B, and C only receives multicasted data with multicast address a. The host E and F only receives multicasted data with multicast network address e. And the host D receives multicasted data with multicast network address a and e. As the result, the multicast network traffic between host A, B, C, and D with multicast network address assigned by host A, does not interfere with the multicast network traffic between host D, E, and F with multicast network address assigned by host E. More importantly, the router between the subnetwork 10.1.x.x and 10.2.x.x does not route unnecessary multicast traffic. A B C D | | | | | | | | |(a) |(a) |(a) |(a,e) ------+--------------+--------+--------+-------+--- Network Address 10.1.x.x | |(e) R (router) |(e) 10.2.x.x ------+---------+-------+------ |(e) |(e) | | | | E F Figure 3. Network with Sub-domains V. Inter-domain Network Multicast sessions which are assigned by different hosts may interfere each other over inter domain routers. Suppose, subnetworks from different domains are connected by routers. Then there are possibilities that multiple hosts assign the identical multicast network address. In figure 4, there is a router R which interconnects networks in domain address 10.1.x.x, and domain address 132.1.x.x. As previous example in figure 3, hosts A, B, C, and D has an established multicast session with a multicast network address a which is allocated by host A. And host D, E, and F has an established multicast session with a multicast network address e which is allocated by host E, and both hosts pick the same multicast address prefix(230). Now, if the host address of A is 10.1.10.1, the host address of E is 132.1.10.1 then the multicast network address a and e become 230.1.10.1. As the result, the multicast sessions can not be distinguishable by network layer. That involves two problems: 1) Unnecessary multicasted traffic may cross the router. 2) Each multicasting host receives unwanted multicasted traffic. The first problem can be fixed by modifying router R. So that, the router uses multicast port number to route the multicasted session. We need to notice that modification of routers is only required on the inter- domain routers. All internal routers do not need to be modified for the purpose. It is quite important that the number of inter-domain routers is a fraction of total number of routers in a large domained network. The second problem has no simple solution, unless each host is modified in network layer protocol to use the multicast port number to decide whether or not it accepts and delivers multicast traffic to higher layer. However, the possibility is not large by the reasons as follow: 1) There exists only 256 or smaller number of hosts which has same value in lower 3 octets of the host address in whole Internet environment. 2) It is more likely that most multicasted sessions are retained within an organization or domain. A B C D | | | | | | | | |(a) |(a) |(a) |(a,e) ------+--------------+--------+--------+------+--- Network Address 10.1.x.x | |(e) R (router) |(e) 132.1.x.x -----+---------+-------+----- |(e) |(e) | | | | E F Figure 4 . Inter-domain Network VI. Limitations The limitation of the proposed scheme not yet stated is as follow: If a host has multiple concurrent multicast sessions, then the sessions have identical multicast network address. Suppose in figure 1, a host A has multicast sessions S1 and S2. The session S1 has established between host A, C, and E. The session S2 has established between host A, B, and D. If the two sessions has the same value in the highest octet of the multicast address. Then the multicast network address of session S1 and S2 become identical. Therefore, the hosts B,C,D, and E can not distinguish the session S1 and S2 by multicast network address alone. That makes the host C and E receives unnecessary multicasted traffic of session S2, and the host B and D receives unnecessary multicasted traffic of session S1. It could be quite burden to each host especially when a host generates a large number of multicast sessions. There are two possible solutions for this problem. First, the network layer protocol can be modified as stated above by that network layer can filter out unnecessary multicast traffic with multicast port number. Secondly, we can provide fair chance to allocate a multicast address to every hosts in a network. In general a local area network is a group of interconnected hosts, some of them are high powered machines and the others are less powerful hosts such as workstations. Most less powered hosts only have a few multicast sessions at any moment. If a host has a large number of multicast sessions, the host is more likely be a high powered machine which is used as a server for applications. To resolve the problem, multicast address for a session can be allocated one of the clients for each multicast session. If the second scheme is used properly, it is the most effective and acceptable solution for the most of networking environment. VII. Multicast Address distribution in Internet The multicast address(session address) allocated by one of the hosts in a multicasted connection can not be used until the address is distributed to every hosts in the connection, then the hosts bind themselves to the address. For the purpose, a secondary address is introduced, multicasted application address is the one. The multicasted application address provides similar function to the well known port number in the Internet. With the address each hosts can accept any incoming session establishment requests, in the request the multicast session address is distributed to every hosts in the session. For the distributed multicast address allocation scheme, a part of Internet multicast address can be reserved, for instance, 225.x.x.x is used for multicasted application addresses, and 226.x.x.x is used for multicasted session addresses. With 225.x.x.x, Internet can define at most 2**24 applications. And with 226.x.x.x each host can assign 256 concurrent multicast sessions. Internet already assigned some parts of 224.x.x.x for special purpose. Therefore, multicast address [257- 239].x.x.x is still available for other multicast addressing schemes. The distributed multicast address allocation scheme is also applicable for the immersing Internet addressing scheme (IPV6), by extending the size of each field. References [Pej] Sassan Pejhan, Alexandros Eleftheriadis, and Dimitris Anastassiou, "Distributed Multicast Address Management in the Global Internet," IEEE Journal on Selected Areas in Communications. Vol. 13, No. 3, pp. 1445-1456, October 1995. [Postel] J. Reynolds and J. Postel, "Assigned numbers," RFC1340, July 1992. [Elef] Eleftheriadis, A., Pejhan, S. and Anastassiou, D., "Address Management and Connection Control for Multicast Communication Application," Proceedings of IEEE INFOCOM, pp. 386-393, April 1995. [Deer] Deering, S., "Host Groups: A Multicast Extention for Datagram Internetworks," RFC1112, Stanford University, July 1989. Author's Address Chang Won Son Soo Hyoung Oh Ji Yeon Son Computer Communications Section Electronics and Telecommunications Research Institute P.O.Box 106, Yusong, Taejon, 305-600 Korea Tel: 082-42-860-5583 Fax: 082-42-860-6671 Email: son@com1.etri.re.kr