idnits 2.17.1 draft-son-ddma-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 352 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([Pej]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 118 has weird spacing: '...osed of domai...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1996) is 10210 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'Pej' on line 308 looks like a reference -- Missing reference section? '224-239' on line 93 looks like a reference -- Missing reference section? '257-239' on line 299 looks like a reference -- Missing reference section? 'Postel' on line 313 looks like a reference -- Missing reference section? 'Elef' on line 316 looks like a reference -- Missing reference section? 'Deer' on line 320 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Expire in six months 3 Chang Won Son 4 Soo Hyoung Oh 5 Ji Yeon Son 7 ETRI 8 ver. 1. April 1996 10 Distributed Dynamic Multicast Address(DDMA) Assignment in Internet 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its 17 areas, and its working groups. Note that other groups may also 18 distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check 27 the ``1id-abstracts.txt'' listing contained in the Internet- 28 Drafts Shadow Directories on ftp.is.co.za (Africa), 29 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 30 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 32 Abstract 34 This document presents a dynamic multicast address allocation and 35 distribution scheme in the Internet address space. By the scheme 36 a multcast address for a multicasted session is chosen by a host 37 based on its own host address and port number of the session. 39 I. Introduction 41 Unlike a host address, which identifies a host in a network, a 42 multicast address identifies a group of hosts. Theologically, the 43 number of possible groups by the hosts have an exponential relationship 44 to the number of hosts in a network. Thus, it is impractical to assign 45 a multicast address for each possible groups. More attractive 46 approaches are dynamical allocation schemes, by which a multicast 47 address is allocated when a group is in session, then the address is 48 released during dismantle of the session. The address can be reclaimed 49 by other group sessions. While a multicast address is temporal address 50 in the dynamic allocation schemes, the address should be allocated on 51 demand. There are two distinguishable approaches. First, the address 52 can be allocated by a multicast name server. The server is responsible 53 to provide a globally unique multicast address by maintaining 54 allocated address list. The list can be managed by a single server, or 55 it can be distributed in multiple servers. Secondly, the address can 56 be allocated by individual hosts. One of the simple solutions of the 57 later approach is the random pick approach. With this approach, a host 58 choose a multicast address randomly, then it advertises the address to 59 find out that whether or not the address is claimed by any other hosts. 60 If not, the address can be used by the host. Otherwise, the host picks 61 another address. The process continues until an usable address can be 62 found. 64 The above approaches have significant address resolution delay and 65 traffic. A distributed multicast allocation scheme proposed by [Pej] 66 fixes the problems. In the approach, each individual host selects a 67 multicast address which is based on its host address and port number 68 of the multicast address requesting session. Since the tuple of host 69 address and port number is globally unique, the uniqueness of the 70 address can be achievable. The original scheme by [Pej] has some 71 limitations, such as all multicast addresses which allocated within a 72 subnetwork have same multicast network address, so that the multicast 73 address can not be distinguishable by network layer, unless every 74 hosts and gateways are modified to take the port number. This paper 75 defines a distributed dynamic multicast addressing scheme, which is 76 based on [Pej]. 78 II. Distributed Multicast Address Allocation 80 In the Internet environment, a host address is used to identify a node 81 within a network, then port address is used to identify an endpoint of 82 a data stream within the host. The host address and port address tuple 83 identifies a globally unique endpoint of a data stream. Thus, a 84 multicast address assigned by a host with the tuple should be globally 85 unique. Currently, the host address consists of 4 octets and the port 86 number consists of 2 octets. To be identified as a multicast address, 87 the first octet of the Internet address should be chosen from 224 to 88 239. With the address components, globally unique multicast address 89 can be assigned by 7 octets. 91 As figure 1, the multicast address is constructed with multicast 92 network address(1) and multicast port number(2). The highest octet of 93 multicast network address is in [224-239] to indicate that the address 94 is a multicast address. Then the other octets are taken from lower 3 95 octets of host network address. The highest octet of the host network 96 address is used for low octet of the multicast port number. For the 97 compatibility with existing address scheme, the 2 octets of port space 98 is mapped into high octet of the multicast port number. If we consider 99 that there are 16 choices in the highest octet of multicast network 100 address for each hosts, each host can assign at most 4096 globally 101 unique multicasted sessions without external assistance. 103 Host IP Address Port 104 +---------+ +-- ---+ 105 | a.b.c.d | | u.v | 106 +---------+ +------+ 107 | | 108 | | 109 V V 110 +---------------------------------------------------+ 111 | +--------------+ (1) +--------+ (2) | 112 | |224-239.b.c.d | |(u*v).a | | 113 | +--------------+ +--------+ | 114 +---------------------------------------------------+ 116 Figure 1. Multicast Address allocation from Host Address 118 Internet address is composed of domain and host address fields. In 119 each domain all hosts have the same value in domain address field. The 120 domain is classified as A, B, C and D. All hosts within a class C 121 domain have the same address value in highest 3 octets of the address. 122 All hosts within a class B domain have the same address value in 123 highest 2 octets of the address. All hosts within a class A domain 124 have the same address value in highest 1 octets of the address. The 125 class D domain is assigned for multicast address. By using last 3 126 octets for multicast addressing, each host can assign locally unique 127 multicast network address within a domain(A,B,C). 129 III. Single Domain network 131 Multicast sessions which are assigned by 132 different hosts do not interfere each other 133 within a domain. 135 In figure 2, hosts A, B and C has an established multicast session 136 with a multicast network address a which is allocated by host A. And 137 host C, D, and E has an established multicast session with a multicast 138 network address c which is allocated by host C. Then host A and B only 139 receives multicasted data with multicast network address a. The host D 140 and E only receives multicasted data with multicast network address c. 141 And host C receives multicasted data with multicast network address a 142 and c. As the result, the multicast network traffic between host A, B, 143 and C with multicast network address assigned by host A does not 144 interfere with the multicast network traffic between host C, D, and E 145 with multicast network address assigned by host C. 147 A B C D E 148 | | | | | 149 | | | | | 150 |(a) |(a) |(a,c) |(c) |(c) 151 ------+--------------+----------+---------+--------------+--- 152 Network Address 10.x.x.x 154 Figure 2. Single Domain Network 156 IV. Network with Sub-domains 158 Multicast sessions which are assigned by 159 different hosts do not interfere each other 160 within sub-domains from class A or class B 161 network. 163 Suppose above network has sub-domains, and the sub-domains are 164 connected by routers. Then the multicast network addresses which are 165 assigned by individual hosts in the domain still have different values 166 each other. By that, the above statement is also true. In figure 3, 167 hosts A, B, C, and D has an established multicast session with a 168 multicast network address a which is allocated by host A. And host D, 169 E, and F has an established multicast session with a multicast network 170 address e which is allocated by host E. Then host A, B, and C only 171 receives multicasted data with multicast address a. The host E and F 172 only receives multicasted data with multicast network address e. And 173 the host D receives multicasted data with multicast network address a 174 and e. As the result, the multicast network traffic between host A, B, 175 C, and D with multicast network address assigned by host A, does not 176 interfere with the multicast network traffic between host D, E, and F 177 with multicast network address assigned by host E. More importantly, 178 the router between the subnetwork 10.1.x.x and 10.2.x.x does not route 179 unnecessary multicast traffic. 181 A B C D 182 | | | | 183 | | | | 184 |(a) |(a) |(a) |(a,e) 185 ------+--------------+--------+--------+-------+--- 186 Network Address 10.1.x.x | 187 |(e) 188 R (router) 189 |(e) 10.2.x.x 190 ------+---------+-------+------ 191 |(e) |(e) 192 | | 193 | | 194 E F 195 Figure 3. Network with Sub-domains 197 V. Inter-domain Network 199 Multicast sessions which are assigned by 200 different hosts may interfere each other over 201 inter domain routers. 203 Suppose, subnetworks from different domains are connected by routers. 204 Then there are possibilities that multiple hosts assign the identical 205 multicast network address. In figure 4, there is a router R which 206 interconnects networks in domain address 10.1.x.x, and domain address 207 132.1.x.x. As previous example in figure 3, hosts A, B, C, and D has 208 an established multicast session with a multicast network address a 209 which is allocated by host A. And host D, E, and F has an established 210 multicast session with a multicast network address e which is 211 allocated by host E, and both hosts pick the same multicast address 212 prefix(230). Now, if the host address of A is 10.1.10.1, the host 213 address of E is 132.1.10.1 then the multicast network address a and e 214 become 230.1.10.1. As the result, the multicast sessions can not be 215 distinguishable by network layer. That involves two problems: 1) 216 Unnecessary multicasted traffic may cross the router. 2) Each 217 multicasting host receives unwanted multicasted traffic. The first 218 problem can be fixed by modifying router R. So that, the router uses 219 multicast port number to route the multicasted session. We need to 220 notice that modification of routers is only required on the inter- 221 domain routers. All internal routers do not need to be modified for 222 the purpose. It is quite important that the number of inter-domain 223 routers is a fraction of total number of routers in a large domained 224 network. The second problem has no simple solution, unless each host 225 is modified in network layer protocol to use the multicast port number 226 to decide whether or not it accepts and delivers multicast traffic to 227 higher layer. However, the possibility is not large by the reasons as 228 follow: 1) There exists only 256 or smaller number of hosts which has 229 same value in lower 3 octets of the host address in whole Internet 230 environment. 2) It is more likely that most multicasted sessions are 231 retained within an organization or domain. 233 A B C D 234 | | | | 235 | | | | 236 |(a) |(a) |(a) |(a,e) 237 ------+--------------+--------+--------+------+--- 238 Network Address 10.1.x.x | 239 |(e) 240 R (router) 241 |(e) 132.1.x.x 242 -----+---------+-------+----- 243 |(e) |(e) 244 | | 245 | | 246 E F 248 Figure 4 . Inter-domain Network 250 VI. Limitations 252 The limitation of the proposed scheme not yet stated is as follow: If 253 a host has multiple concurrent multicast sessions, then the sessions 254 have identical multicast network address. Suppose in figure 1, a host 255 A has multicast sessions S1 and S2. The session S1 has established 256 between host A, C, and E. The session S2 has established between host 257 A, B, and D. If the two sessions has the same value in the highest 258 octet of the multicast address. Then the multicast network address of 259 session S1 and S2 become identical. Therefore, the hosts B,C,D, and E 260 can not distinguish the session S1 and S2 by multicast network address 261 alone. That makes the host C and E receives unnecessary multicasted 262 traffic of session S2, and the host B and D receives unnecessary 263 multicasted traffic of session S1. It could be quite burden to each 264 host especially when a host generates a large number of multicast 265 sessions. There are two possible solutions for this problem. First, 266 the network layer protocol can be modified as stated above by that 267 network layer can filter out unnecessary multicast traffic with 268 multicast port number. Secondly, we can provide fair chance to 269 allocate a multicast address to every hosts in a network. In general a 270 local area network is a group of interconnected hosts, some of them 271 are high powered machines and the others are less powerful hosts such 272 as workstations. Most less powered hosts only have a few multicast 273 sessions at any moment. If a host has a large number of multicast 274 sessions, the host is more likely be a high powered machine which is 275 used as a server for applications. To resolve the problem, multicast 276 address for a session can be allocated one of the clients for each 277 multicast session. If the second scheme is used properly, it is the 278 most effective and acceptable solution for the most of networking 279 environment. 281 VII. Multicast Address distribution in Internet 283 The multicast address(session address) allocated by one of the hosts 284 in a multicasted connection can not be used until the address is 285 distributed to every hosts in the connection, then the hosts bind 286 themselves to the address. For the purpose, a secondary address is 287 introduced, multicasted application address is the one. The 288 multicasted application address provides similar function to the well 289 known port number in the Internet. With the address each hosts can 290 accept any incoming session establishment requests, in the request the 291 multicast session address is distributed to every hosts in the session. 293 For the distributed multicast address allocation scheme, a part of 294 Internet multicast address can be reserved, for instance, 225.x.x.x is 295 used for multicasted application addresses, and 226.x.x.x is used for 296 multicasted session addresses. With 225.x.x.x, Internet can define at 297 most 2**24 applications. And with 226.x.x.x each host can assign 256 298 concurrent multicast sessions. Internet already assigned some parts of 299 224.x.x.x for special purpose. Therefore, multicast address [257- 300 239].x.x.x is still available for other multicast addressing schemes. 302 The distributed multicast address allocation scheme is also applicable 303 for the immersing Internet addressing scheme (IPV6), by extending the 304 size of each field. 306 References 308 [Pej] Sassan Pejhan, Alexandros Eleftheriadis, and Dimitris 309 Anastassiou, "Distributed Multicast Address Management in the Global 310 Internet," IEEE Journal on Selected Areas in Communications. Vol. 13, 311 No. 3, pp. 1445-1456, October 1995. 313 [Postel] J. Reynolds and J. Postel, "Assigned numbers," RFC1340, July 314 1992. 316 [Elef] Eleftheriadis, A., Pejhan, S. and Anastassiou, D., "Address 317 Management and Connection Control for Multicast Communication 318 Application," Proceedings of IEEE INFOCOM, pp. 386-393, April 1995. 320 [Deer] Deering, S., "Host Groups: A Multicast Extention for Datagram 321 Internetworks," RFC1112, Stanford University, July 1989. 323 Author's Address 325 Chang Won Son 326 Soo Hyoung Oh 327 Ji Yeon Son 329 Computer Communications Section 330 Electronics and Telecommunications Research Institute 331 P.O.Box 106, Yusong, Taejon, 305-600 Korea 332 Tel: 082-42-860-5583 Fax: 082-42-860-6671 333 Email: son@com1.etri.re.kr