idnits 2.17.1 draft-ohta-static-multicast-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-04-26) 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '... MUST and DNS dynamic update w...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 36 has weird spacing: '...on list based...' == Line 313 has weird spacing: '...address is ac...' -- 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 (March 1998) is 9539 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) == Unused Reference: 'CBT' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'PIM' is defined on line 414, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'MANOLO' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Possible downref: Non-RFC (?) normative reference: ref. 'CBT' -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT M. Ohta 3 draft-ohta-static-multicast-00.txt Tokyo Institute of Technology 4 J. Crowcroft 5 University College London 6 March 1998 8 Static Multicast 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 The current IP Multicast model appears to achieve a level of 31 simplicity by extending the IP unicast addressing model (historically 32 the classful A,B, and C net numbers) from the mask and longest match 33 schemes of CIDR, with a new classful address space, class D. The 34 routing systems have been also built in a deceptively simple way in 35 one of three manners - either broadcast and prune (DVMRP, Dense Mode 36 PIM), destination list based tree computation (MOSPF) or single 37 centered trees (current sparse mode PIM and CBT). The multicast 38 service creates the illusion of a spectrum that one can "tune in to", 39 as an application writer. Due to this view, many have seen the 40 multicast pilot service, the Mbone, as a worldwide Ethernet, where 41 simple distributed algorithms can be used to allocate "wavelengths" 42 and advertise them through "broadcast" on a channel (the session 43 directory), associated with a spectrum. 45 These three pieces of the picture have tempted people to construct a 46 distributed architecture for a number of next level services that 47 cannot work at more than a modest scale, since they ignore the basic 48 spirit of location independence for senders and receivers of IP 49 packets, whether unicast or multicast. The problem is that many of 50 these services are attempting to group activities at source, when it 51 is only at join time that user grouping becomes apparent (if you 52 like, multicast usage is a good example of very late binding). These 53 services include Address Allocation and Session Creation, 54 Advertisement and Discovery. 56 This memo proposes approaches to solve some current multicast 57 problems rather statically with DNS and URL based approach, and avoid 58 the misguided pitfalls of trying to use address allocation to 59 implement traffic aggregation for different sources or aggregation of 60 multicast route policy control through control of such aggregated 61 sources. 63 Note that a minor level of aggregation occurs in applications which 64 source cumulative layered data (e.g. audio/video/game data - ref 65 vic/rat/rlc) - this memo is orthogonal to such an approach, which in 66 any case ony results in a small constant factor reduction in state. 68 A lot of the IP multicast additional pieces of baggage are associated 69 with the multimedia conferencing on Mbone - however, the commercial 70 internet use of multicast includes many other applications - for 71 these, SDR may not be the best directory model. 73 1. Introduction 75 Multicast and related applications have traditionally been developed 76 in Routing and Transport areas. Naturally, designers have tried to 77 solve many problems using techniques familiar to those working in the 78 routing and transport areas, that is, with flooding or multicast. 80 Of course, global flooding or multicast do not scale very well, which 81 means that scalable solutions that make use of these techniques only 82 are often impossible in the world wide Internet. 84 An attempt to reduce the scalability requirement to localize 85 multicast and flooding area through TTL or administrative scoping 86 (intra-site, intra-provider multicast etc.) works only in a small 87 scale experiment like Mbone. In the real Internet, senders and 88 receivers of multicast communication, in general, may be using 89 different providers and are distributed beyond AS boundaries. 91 As a result, there was a hope that address aggregation and unicast 92 area topology report aggregation can solve the multicast scalability 93 problems in the same way that they have bailed out the unicast 94 Internet from problems with limitation of router memory and the 95 capacity needed for route update reports: 97 a) Unicast addresses refer to a location, however. Multicast 98 addresses are logical addresses, and refer to sets of members who 99 may be anywhere, and may be sent to by sources which are also in 100 more than one of many places. This means that for unrelated 101 multicast group (and we anticipate that, in general, we can expect 102 relationship between groups only when the groups belongs to a 103 single application and that there is far more group that is 104 unrelated than there is group that is related), there is no 105 meaningful allocation at session creation time of a mask/prefix 106 style multicast address, either for destination group, or sources. 108 b) To control the amount of state and routing control messages, 109 the Internet has divided the routing systems into autonomous 110 systems/regions, which can run their own routing, and need only 111 report summarized information at the edge to another region. This 112 serves two purposes in the Unicast world: 114 1/ Inter-domain routing protocols can be deployed that are 115 different in different areas (this may be applied recursively). 117 2/ Summarization can be applied at "min-cut" points in the 118 topology, and reachability information only needs to be 119 exported/imported across borders. 121 Note that, autonomous system boundaries are merely for operational 122 purpose of easy policy description. The boundary does not 123 contribute to protocol issues to reduce the amount of routing 124 information, which is accomplished with multi-layered OSPF without 125 BGP. 127 With multicast, while one could define inter-working boundaries and 128 functions as the IDMR WG has, the principle goal of scaling the 129 reports at a border cannot be achieved in a location independent 130 manner (in the sense that without moving all the receivers to a 131 particular region, there is no aggregation feasible). 133 As a result of this confusion, intra-domain multicast protocols, 134 which are expected to operate within a single AS have been developed 135 that scale poorly, even though there was no known inter domain 136 multicast protocol which solves the scalability problem. 138 It has been shown [MANOLO] that aggregation of multicast routing 139 table entries, the number of which is a major scalability problem for 140 IP multicast, is, in general, impossible. 142 The impossibility proof assumes nothing about QoS. That is, 143 multicast QoS Flow state can be aggregated as good/bad as multicast 144 best effort communication. RSVP may be extended to aggregate RSVP 145 requests of strongly interrelated flows, for example, for streams 146 with layered encoding, which may or may not share a single multicast 147 address, latter case of which may result in a small constant factor 148 of routing table entry reduction. 150 There may be a counter argument that a broadcast/prune in region (== 151 big ether) and spare in other region for clumpy cast can overcome the 152 problem. However, forwarding for "spare in other region" needs a 153 routing table entry of its own. Moreover, even in the region, 154 "broadcast/prune" scales worse than the theoretical lower bound of 155 PIM-SM/CBT [MANOLO]. 157 Thus, it is now necessary to thoroughly reconsider the architecture 158 of multicast, Given a theoretical lower bound of multicast routing 159 table entries, now is the time to find a multicast algorithm to 160 achieve that lower bound. It is also meaningful to make the multicast 161 architecture independent of unicast address hierarchy. 163 Fortunately, some problems can easily be solved for many common cases 164 using techniques available in other areas without scalability 165 problems. 167 Since the legacy multicast architecture was constructed carefully 168 assuming routing table aggregation possible, it is necessary to 169 change some of it to deploy new techniques. To solve hard 170 scalability problems, it is necessary to recognize that all the 171 details of all the protocols are tightly interrelated. 173 The multicast problems identified to be better solved in internet or 174 application area in this memo are: 176 Multicast Address Allocation 178 There was a proposal to allocate multicast address dynamically 179 along the unicast address hierarchy. Such an allocation policy 180 was expected to enhance the possibility of aggregation. 181 However, as shown in the next section, it is impossible to 182 aggregate multicast routing table. Then, while it is still 183 possible to aggregate multicast address allocation, it is not 184 meaningful. 186 However, it is meaningful to allocate multicast addresses 187 statically through the DNS. 189 Multicast Core/RP Location 191 CBT and PIM-SM were developed as intra-domain multicast 192 protocols designed to be independent of the underlying unicast 193 routing protocols. Naturally, they achieve the lower bound of 194 spatial routing table size complexity. However, CBT and PIM-SM 195 are not totally independent of unicast routing architecture, 196 since they depends on flooding within an AS to locate the core 197 or rendez-vous point. While this scales a little better than 198 static assignment, it is still fairly bad. On the other hand, 199 it is straight forward to use DNS to map from DNS multicast 200 name to multicast address, core and RP. This solution may not 201 be an option when dynamic multicast address assignment was a 202 MUST and DNS dynamic update was not possible. However, this is 203 now rectified since DNS update is being implemented now. 205 Multicast Session Announcement 207 The announcement of multicast sessions can be performed over a 208 special multicast channel. But the approach does not scale if 209 the number of multicast channels increases. Of course, it is 210 possible to introduce hierarchy of multicast session 211 announcement channels. The real world complex structure makes 212 the relationships between session announcement a complex 213 network. Then, users join a session directory hierarchy by 214 joining a group for some level, following the hierarchy, or 215 following short-cut or following links, changing between 216 several multicast groups to reach the final destination 217 multicast for the session they seek. But as is proven, 218 multicast costs routing table entries and associated protocol 219 processing power of routers if a data of the multicast flows 220 over the routers. So, it is desirable to constrain the number 221 of multicast channels to be as small as possible. 223 If, instead, we use WWW as EPG (Electric Program Guide) and 224 embed SDP or SMIL information in RTP URLs, it can be used as 225 multicast session announcement with arbitrary complex structure 226 of hierarchy, short-cut or links with some caching, and we can 227 use search techniques on this static data more easily. 229 Of course, neither DNS nor WWW scale automatically: they must 230 continue to scale anyway and a lot of effort was already and will 231 continue to be paid to make them better scale, more dynamic and more 232 secure and their servers are becoming more capable (caching etc). 233 DNS will be used for unicast name to address lookup forever and WWW 234 will be the preferred way to retrieve information. 236 2. Meaningless Aggregation of Multicast Addresses 238 It is, in general, impossible to aggregate multicast routing table 239 entries. 241 The minimum amount of state in each multicast router must be 242 proportional to the number of multicast data flows which are running 243 over it. 245 The locations of receivers are different, multicast application by 246 multicast application. Multicast forwarding must be performed over a 247 tree of receivers. The sources are different too. Thus, the tree is 248 different multicast by multicast. 250 It is possible to aggregate multicast address allocation by making 251 multicast location dependent with, say, a root domain. Then, it is 252 possible to aggregate routing table entries to the root domain. For 253 some type of central set of agencies (traditional broadcast TV/Radio) 254 it might be possible to site their feeds at the same places in the 255 Internet. But this is antithetical to the arbitrary growth allowed by 256 random siting/evolution of content providers today, even in the Web. 257 Sheer numbers preclude building unicast pipes from each source to a 258 central set of sites. 260 However, it is still impossible to aggregate routing table entries to 261 the receivers. The distribution pattern of receivers is unrelated to 262 the location of the root domain. That is, a separate routing table 263 entry is necessary for each multicast application. 265 A group of multicast receivers sharing a root domain may still have 266 weak relationships in that most of them do not have any member in 267 domains far from the root domain. Then, it is possible to share a 268 default routing table entry, not to forward anything. But, such an 269 entry is meaningless, because there is no data packet that will be 270 forwarded for the entry and we still need unaggregated routing table 271 entries for each multicast running over multicast routers. 273 Alternatively, it is possible to assign multicast addresses 274 aggregated according to the statically or runtime detected 275 distribution pattern of the receiver hosts, areas or domains. 276 However, even with 32 receiver hosts, areas or domains, we need 32 277 bits for the aggregation prefix of the multicast addresses, which is 278 too many for IPv4. Even IPv6 address space does not help a lot (96 279 receivers is not a great step forward!). Moreover, as the multicast 280 membership changes dynamically, the multicast address itself must 281 change dynamically. 283 That is, according to the current model of the Internet multicast, it 284 is impossible to aggregate multicast routing table entries. 286 It is meaningless to try to aggregate multicast address assignment. 288 Still, it, of course, is meaningful and necessary to hierarchically 289 delegate multicast address allocation. 291 3. The Difficulty of (Multicast) Address Assignment 293 Compared to the administrative effort for unicast address assignment 294 by IANA, Internic, RIPE, APNIC and all the country NICs and 295 development of the policy they used, it is trivially easy to develop 296 a DHCP protocol. The difficulty with DHCP was in the fact that the 297 clients can not be reached by its IP address. It is even more 298 trivial to develop a DHCP-like dynamic multicast address assignment 299 protocol for clients unicast addresses which are already established. 300 It could be as simple as a new option field of DHCP. 302 However, such a use of DHCP is meaningless, unless an administrator 303 of the DHCP server has been delegated a block of unicast addresses 304 and establishes a policy on how to assign them to clients. 305 Similarly, we can argue that the DHCP-like mechanism for multicast is 306 not a good solution. 308 Basically, multicast address assignment is not a protocol issue. 310 4. Recycling the Unicast Policy, Mechanism and Established Address 311 Assignment for Multicast Policy, Mechanism and Address Assignment 313 If rather static allocation of multicast address is acceptable, it 314 is possible to reuse the policy, mechanism, address assignment and 315 protocol of unicast address assignment for multicast addresses.. 317 For example, if we decide to use 225.0.0.0/8 for the static 318 allocation, it is trivial to delegate the authority of multicast 319 address 225.1.2.3 to an administrator of 3.2.1.in-addr.arpa, the 320 administrator of 1.2.3.0/24. 322 We can simply define that the multicast DNS name should be looked up 323 as: 325 3.2.192.225.in-addr.arpa. CNAME mcast.3.2.192.in-addr.arpa. 327 mcast.3.2.192.in-addr.arpa. PTR bbc.com. 329 bbc.com. A 225.192.2.3 331 Then, if we construct applications that check the reverse mapping, 332 unauthorized use of multicast addresses will be automatically 333 rejected, which is what we are doing today with unicast addresses. 335 Note that the administrator of 3.2.192.in-addr.arpa is not the final 336 person to be delegated the address but can further delegate the 337 authority of mcast.3.2.192.in-addr.arpa. to someone else. 339 It should also be noted that, while the delegation uses the existing 340 policy, mechanism, assignment and protocol, it does not mean that the 341 multicast address must be used within the unicast routing domain of 342 the unicast address block. 344 Just as MX servers or name servers can be located anywhere in the 345 Internet regardless of the location of the hosts under the DNS domain 346 they are serving, multicast channels can be used anywhere in the 347 world. 349 The assingment policy automatically assure global uniqueness. But, 350 it is still possible to have multicast addresses with local scopes, 351 as long as they share globally unique well known DNS names, which is 352 what we are using for intra-subnet multicast with IANA assigned well 353 known names [IANA]. 355 5. Core/RP location 357 The location of core of CBT or rendez-vous point of PIM-SM through 358 DNS is straight forward as: 360 bbc.com. A 255.192.2.3 361 RVP london-station.bbc.com. 363 or 365 bbc.com. A 255.192.2.3 366 CORE london-station.bbc.com. 368 Again, just as MX servers or name servers can be located anywhere in 369 the Internet regardless of the location of the hosts under the DNS 370 domain they are serving, core or rendez-vous points can be located 371 anywhere in the world. 373 CORE and RVP RRs have exactly the same syntax as PTR RR. Their query 374 type values are . While the current CBT nor 375 PIM-SM does not allow a single multicast group has multiple cores or 376 rendez-vous points, future extension may. Thus, at the DNS level, a 377 single node may have multiple CORE or RVP RRs. That is, the following 378 DNS node is a valid node: 380 bbc.com. A 255.192.2.3 381 RVP london-station.bbc.com. 382 RVP wales-station.bbc.com. 384 6. Session Announcement 386 The proposal is essentially to use a URL of RTP combined with SDP 387 like: 389 rtp://london-station.bbc.com/?t=2873397496+2873404696& 390 m=audio+3456+RTP/AVP+0&m=video+2232+RTP/AVP+31 392 The URL contains all the necessary information to establish a 393 session, including the domain name (or multicast address), port 394 number(s), RTP payload type and optional QoS requirement. 396 Then, users surfing over WWW can actively search or randomly 397 encounter some multicast or unicast RTP URL. 399 If the user clicks the label of the URL, the user will be queried 400 whether he want to receive (should be default for multicast) or send 401 data or both (should be default for unicast). He will also queried 402 the source or destination of the data with appropriate default (his 403 TV at the living room) and the multicast session begins, if 404 necessary, with RSVP. 406 7. References 408 [MANOLO] http://web.jet.es/sola/inet98.html 410 [IANA] 412 [CBT] 414 [PIM] 416 8. Security Considerations 418 (to be written) 420 9. Authors' Addresses 422 Masataka Ohta 423 Computer Center 424 Tokyo Institute of Technology 425 2-12-1, O-okayama, Meguro-ku 426 Tokyo 152, JAPAN 428 Phone: +81-3-5734-3299 429 Fax: +81-3-5734-3415 430 EMail: mohta@necom830.hpcl.titech.ac.jp 432 Jon Crowcroft 433 Dept. of Computer Science 434 University College London 435 London WC1E 6BT, UK 437 EMail: j.crowcroft@cs.ucl.ac.uk