idnits 2.17.1 draft-ietf-malloc-arch-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 2 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 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-07) exists of draft-ietf-malloc-madcap-04 == Outdated reference: A later version (-04) exists of draft-ietf-malloc-aap-01 -- Possible downref: Normative reference to a draft: ref. '5' == Outdated reference: A later version (-06) exists of draft-ietf-malloc-masc-01 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-masc (ref. '6') ** Obsolete normative reference: RFC 1771 (ref. '8') (Obsoleted by RFC 4271) == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-03 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. '9') Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MALLOC Working Group M. Handley 2 INTERNET-DRAFT AT&T Research 3 April 28, 1999 D. Thaler 4 Expires October 1999 Microsoft 5 D. Estrin 6 ISI 8 The Internet Multicast Address Allocation Architecture 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (1999). All Rights Reserved. 37 1. Abstract 39 This document proposes a multicast address allocation architecture 40 for the Internet. The architecture is three layered, comprising a 41 host-server protocol, an intra-domain server-server protocol, and 42 an inter-domain protocol. 44 2. Introduction 46 This document proposes a multicast address allocation architecture 47 for the Internet. This architecture is designed to scale to 48 allocating a very large proportion of the 270 million IPv4 49 multicast addresses available. It will also perform well in an 50 IPv6 environment where addresses are not a scare resource, but it 51 is not currently clear whether different mechanisms would be more 52 appropriate if good address space packing were not a primary 53 requirement. 55 As with unicast addresses, the usage of any given address is 56 limited in two dimensions: 58 Lifetime: 59 an address has a start time and a (possibly infinite) end 60 time, between which it is valid. 62 Scope: 63 an address is valid over a specific area of the network. For 64 example, it may be globally valid, or it may be a private 65 address which is valid only within a local area. 67 This architecture assumes that the primary scoping mechanism in 68 use is administrative scoping, as described in RFC 2365 [1]. 69 While olutions that work for TTL scoping are possible, they 70 introduce significant additional complication for address 71 allocation [2]. Moreover, TTL scoping is a poor solution for 72 multicast scope control, and our assumption is that TTL scoping of 73 sessions will cease to be used before this architecture is widely 74 used. 76 3. Requirements 78 >From a design point of view, the important properties of multicast 79 allocation mechanisms are robustness, timeliness, low probability 80 of clashing allocations, and good address space utilization. 81 Where this interacts with multicast routing, it is desirable for 82 multicast addresses to be allocated in a manner that aids 83 aggregation of routing state. 85 o Robustness 86 The robustness requirement is that an application requiring the 87 allocation of an address should always be able to obtain one, 88 even in the presence of other network failures. 90 o Timeliness 91 From a timeliness point of view, a short delay of up to a few 92 seconds is probably acceptable before the client is given an 93 address with reasonable confidence in its uniqueness. If the 94 session is defined in advance, the address should be allocated 95 as soon as possible, and should not wait until just before the 96 session starts. It is acceptable to change the multicast 97 addresses used by the session up until the time when the 98 session actually starts, but this should only be done when it 99 averts a significant problem such as an address clash that was 100 discovered after initial session definition. 102 o Availability, Correctness, and Address Space Packing 103 A multicast address allocation scheme should always be 104 available, and always able to allocate an address that can be 105 guaranteed not to clash with that of another session. However, 106 to guarantee no clashes would require a top-down partitioning 107 of the address space, and to do this in a manner that provides 108 sufficient spare space in a partition to give a reasonable 109 degree of assurance that an addresses can still be allocated 110 for a significant time in the event of a network partitioning 111 would result in significant fragmentation of the address space. 112 In addition, providing backup allocation servers in such a 113 hierarchy, so that fail-over (including partitioning of a 114 server and its backup from each other) does not cause 115 collisions would add further to the address space 116 fragmentation. 118 Given that we cannot achieve constant availability, guarantee 119 no clashes, and achieve good address space usage, we must 120 prioritize these properties. We believe that achieving good 121 address space packing and constant availability are more 122 important than guaranteeing that address clashes never occur. 123 What we aim for is a high probability that an address clash 124 does not occur, but we accept that there is a finite 125 probability of this happening. Should a clash occur, either 126 the clash can be detected and addresses changed, or hosts 127 receiving additional traffic can prune that traffic using 128 source-specific prunes available in IGMP version 3, and so we 129 do not believe that this is a disastrous situation. 131 In summary, tolerating the possibility of clashes is likely to 132 allow allocation of a very high proportion of the address space 133 in the presence of network conditions such as those observed in 134 [3]. We believe that we can get good packing and good 135 availability with very good collision avoidance, while we would 136 have to compromise packing and availability significantly to 137 avoid all collisions. 139 3.1. Address Dynamics 141 Multicast addresses may be allocated in any of three ways: 143 Static: 144 Statically allocated addresses are allocated by IANA for 145 specific protocols that require well-known addresses to work. 146 Examples of static addresses are 224.0.1.1 which is used for 147 the Network Time Protocol and 224.2.127.255 which is used for 148 global scope multicast session announcements. Applications 149 that use multicast for bootstrap purposes should not normally 150 be given their own static multicast address, but should 151 bootstrap themselves using a well-known service location 152 address which can be used to announce the binding between 153 local services and multicast addresses. 155 Static addresses typically have a permanent lifetime, and a 156 scope defined by the scope range in which they reside. As 157 such, a static address is valid everywhere (although the set 158 of receivers may be different depending on location), and may 159 be hard-coded into applications, devices, embedded systems, 160 etc. Static addresses are also useful for devices which 161 support sending but not receiving multicast IP datagrams 162 (Level 1 conformance as specified in RFC 1112 [7]), or even 163 are incapable of receiving any data at all, such as a 164 wireless broadcasting device. 166 Scope-relative: 167 RFC 2365 [1] provides for the highest 256 addresses in every 168 scope range to be reserved for relative assignments. 170 Relative assignments are also made by IANA and consist of an 171 offset which is valid in every scope. Relative addresses are 172 reserved for infrastructure protocols which require an 173 address in every scope, and this offset may be hard-coded 174 into applications, devices, embedded systems, etc. Such 175 devices must have a way (e.g. via MZAP [9] or via MADCAP [4]) 176 to obtain the list of scopes in which they reside. 178 The offsets assigned typically have a permanent lifetime, and 179 are valid in every scope and location. Hence, the scope- 180 relative address in a given scope range has a lifetime equal 181 to that of the scope range in which it falls. 183 Dynamic: 184 For most purposes, the correct way to use multicast is to 185 obtain a dynamic multicast address. These addresses are 186 provided on demand and have a specific lifetime. An 187 application should request an address only for as long as it 188 expects to need the address. Under some circumstances, an 189 address will be granted for a period of time that is less 190 than the time that was requested. This will occur rarely if 191 the request is for a reasonable amount of time. Applications 192 should be prepared to cope with this when it occurs. At any 193 time during the lifetime of an existing address, applications 194 may also request an extension of the lifetime, and such 195 extensions will be granted when possible. When the address 196 extension is not granted, the application is expected to 197 request a new address to take over from the old address when 198 it expires, and to be able to cope with this situation 199 gracefully. As with unicast addresses, no guarantee of 200 reachability of an address is provided by the network once 201 the lifetime expires. 203 These restrictions on address lifetime are necessary to permit the 204 address allocation architecture to self-organize around current 205 address usage patterns in a manner that ensures addresses are 206 aggregatable and multicast routing is reasonably close to optimal. 207 In contrast, statically allocated addresses may be given sub- 208 optimal routing. 210 4. Overview of the Architecture 212 There are three parts to this architecture: 214 o A protocol (MADCAP [4]) that a multicast client uses to 215 request a multicast address from a local multicast address 216 allocation server (MAAS). 218 o An intra-domain protocol (AAP [5]) that MAAS's use to claim 219 multicast addresses and inform their peer MAAS's which 220 addresses are in use. 222 o An inter-domain protocol (MASC [6]) that allocates multicast 223 address sets to domains. Individual addresses are allocated 224 out of these sets by MAAS's. NOTE: need to mention other 225 experiments, including 233/8 here. 227 We have three protocols because they serve slightly different 228 purposes and require different design tradeoffs. An overview 229 of how these protocols fit together is shown in figure 1. 231 +--------------------------+ +------------------------+ 232 | | | | 233 | to other peers | | to other peers | 234 | || // | | || // || | 235 | MASC3 | | MASC4 MASC5 | 236 +------------||------------+ +-------||----//---------+ 237 ||MASC TCP peerings || // 238 +------------||------------------------------||--//-----------+ 239 | MASC1===========================MASC2 | 240 | ^ ^ | 241 | +----------------+-------------+ | 242 | | multicast|AAP | | 243 | MAAS1<--/ | +---> MAAS3 | 244 | ^ ^ v ^ | 245 | . . MAAS2 . | 246 | . .MADCAP ^ .MADCAP | 247 | v v .MADCAP v | 248 | Client1 Client2 v Client4 | 249 | Client3 | 250 +-------------------------------------------------------------+ 251 Figure 1: An Overview of the Multicast Address Allocation Architecture 253 4.1. Allocation Domains 255 In this document we use the term allocation domain. An allocation 256 domain is an administratively scoped multicast-capable region of 257 the network. We expect that allocation domains will normally 258 coincide with unicast Autonomous Systems (AS's). 260 If an AS is too large, or the network administrator wishes to run 261 different intra-domain multicast routing in different parts of an 262 AS, that AS can be split by manual setup of a multicast boundary 263 that is not a BGP unicast boundary. This is done by setting up a 264 multicast boundary dividing the unicast AS into two or more 265 multicast allocation domains. 267 If an AS is too small, we'll get address space fragmentation if 268 the AS is its own allocation domain. Here, there is no real 269 reason why the border router to the site need run MASC, even 270 though it runs BGP. The domain can use AAP directly to talk to 271 the MAAS's of its provider, and not cause any additional 272 fragmentation. An AS should probably take this course of action 273 if: 275 o it's connected to a single provider. 277 o it does not provide transit for another AS. 279 o it has fewer than N multicast addresses of larger than AS 280 scope allocated on average. The strawman value for N is 256. 282 4.2. Multicast Address Dynamic Client Allocation Protocol 283 (MADCAP) 285 MADCAP is used by a client to request an address from a MAAS. 286 When the server grants an address, it becomes the server's 287 responsibility to ensure that this address is not then reused 288 elsewhere within the same scope. 290 4.3. Address Allocation Protocol (AAP) 292 AAP is used by a MAAS to claim multicast addresses that it has 293 allocated, and if necessary to defend these addresses if another 294 MAAS server attempts to allocate the same address. A MAAS keeps 295 track of all the other multicast addresses in use within the same 296 allocation domain, and when it allocates an address it ensures 297 that the address is not already in use. AAP is also used by nodes 298 running MASC to inform the MAAS's of the address set (consisting 299 of a list of address/mask/lifetime tuples) that is available. 300 Under normal conditions, a MAAS should only allocate an address 301 from the unused addresses in this advertised set. 303 AAP uses multicast, and operates on a timescale of milliseconds to 304 seconds. 306 NOTE: need to update the above to mention the pool method, which 307 doesn't entail any waiting in the typical case. 309 4.4. Multicast Address Set Claim (MASC) Protocol 311 MASC is used by nodes (typically these nodes are routers) to claim 312 address sets that satisfy the needs of the MAAS's within their 313 allocation domain. Thus when a MASC node discovers that there are 314 close to insufficient multicast addresses available for AAP to 315 perform well, the MASC node claims a larger address set. MASC is 316 hierarchical (matching provider-customer relationships among 317 ISPs), so MASC nodes below the top level see address set 318 advertisements by higher level MASC nodes, and must choose new 319 address sets from those being advertised. Address sets are also 320 claimed with a lifetime, and that lifetime cannot be longer than 321 the lifetime of the parent address set. When the lifetime of an 322 address set expires, that set will normally be given up. At this 323 point AAP should no longer be advertising addresses from the set. 324 However, if there is still sufficient demand, and the parent set 325 is renewed, then the address set may be renewed. Typically each 326 allocation domain will be advertising several address sets with 327 different lifetimes at any time, allowing the MAAS's to choose 328 appropriate addresses for their clients. 330 MASC uses unicast TCP. MASC cannot use multicast since inter- 331 domain multicast routing may rely on the address sets allocated by 332 MASC to build trees of domains. Typically MASC is performed in 333 routers that are running BGP [8], and the TCP connections parallel 334 those used by BGP. 336 5. Overview of the Allocation Process 338 Assuming that allocation has been performed for some time (the 339 startup conditions for MASC are slightly more complex), then one 340 or more MASC nodes bordering an allocation domain will be 341 advertising address sets into the domain using multicast AAP. 343 MAAS's within the domain receive these address sets and cache them 344 as the currently allowable addresses for that domain. These 345 address sets are unconditionally valid for their advertised 346 lifetime and cannot be revoked before their lifetime has expired. 348 NOTE: also need to mention getting range from MZAP for small 349 scopes, and possibly getting range via other methods, such as 350 233/8-style configuration. 352 A MAAS also receives individual domain-wide multicast address 353 claims via AAP from other MAAS's within the domain. It also 354 caches these addresses as being in use for their reported 355 lifetime. 357 When a client needs a multicast address, it locally multicasts a 358 request for scope information using MADCAP. Any local MAAS can 359 respond. A responding MAAS provides a list of valid scopes to the 360 client. The client then chooses a scope, and requests an address 361 from that MAAS for a certain time interval. 363 The MAAS then chooses an address from those not currently used in 364 the range for the scope, that satisfies the requested time 365 interval (if possible), and advertises this domain-wide using AAP. 366 If no clashing AAP claim is received within a short time interval, 367 then the address is returned to the client by MADCAP. If a 368 clashing claim is received by the MAAS, then it chooses a 369 different address and tries again. 371 If no address set is long enough to match the requested time 372 interval, then the MAAS truncates the time interval to that of the 373 longest address set available before advertising the address using 374 AAP. 376 6. TODO 378 o Mention other experiments such as the 233/8 experiment. 380 o Discuss divisible ("big") vs indivisible ("small") scopes. 381 (For small scopes, MAAS's just use the full address range 382 provided by MZAP, whereas for big scopes, MASC is used to 383 subdivide the space.) 385 o Mention stable storage requirement for MAASs but not MASC 386 nodes. 388 7. References 390 [1] D. Meyer, "Administratively Scoped IP Multicast", BCP 23, RFC 391 2365, July 1998. 393 [2] Mark Handley, "Multicast Session Directories and Address 394 Allocation", Chapter 6 of PhD Thesis entitled "On Scalable 395 Multimedia Conferencing Systems", University of London, 1997. 396 http://north.east.isi.edu/ mjh/thesis.ps.gz 398 [3] Mark Handley, "An Analysis of Mbone Performance", Chapter 4 399 of PhD Thesis entitled "On Scalable Multimedia Conferencing 400 Systems", University of London, 1997. 401 http://north.east.isi.edu/ mjh/thesis.ps.gz 403 [4] Patel, B., Shah, M., and S. Hanna, "Multicast Address Dynamic 404 Client Allocation Protocol (MADCAP)", draft-ietf-malloc- 405 madcap-04.txt, February 1999. 407 [5] Handley, M., "Multicast Address Allocation Protocol (AAP)", 408 draft-ietf-malloc-aap-01.txt, August 1998. 410 [6] Estrin, D., Govindan, R., Handley, M., Kumar, S., Radoslavov, 411 P., and D. Thaler, "The Multicast Address-Set Claim (MASC) 412 Protocol", draft-ietf-malloc-masc-01.txt, August 1998. 414 [7] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, 415 August 1989. 417 [8] Yekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- 418 4)", RFC 1771, March 1995. 420 [9] Handley, M., Thaler, D., and R. Kermode, "Multicast-Scope 421 Zone Announcement Protocol (MZAP)", draft-ietf-mboned-mzap- 422 03.txt, February 1999.