idnits 2.17.1 draft-boivie-sgm-02.txt: 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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. ** The abstract seems to contain references ([1-10], [10]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 666: '...t, an SGM router MUST NOT convert the ...' RFC 2119 keyword, line 667: '...t(s), i.e. the packet MUST stay an SGM...' RFC 2119 keyword, line 674: '...the bitmap is zero MUST be overwritten...' RFC 2119 keyword, line 717: '... the SGM network. Each SGM router MUST...' RFC 2119 keyword, line 719: '... packet MUST be discarded....' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (February 2001) is 8472 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) -- Looks like a reference, but probably isn't: '1-10' on line 38 == Unused Reference: '2' is defined on line 560, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 572, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 578, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 584, but no explicit reference was found in the text ** Downref: Normative reference to an Experimental RFC: RFC 1075 (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Historic RFC: RFC 1584 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Historic RFC: RFC 2189 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 2201 (ref. '6') ** Obsolete normative reference: RFC 2362 (ref. '8') (Obsoleted by RFC 4601, RFC 5059) -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2543 (ref. '13') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. '14' Summary: 12 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Rick Boivie 3 Expires: August 2001 Nancy Feldman 4 IBM Watson Research Center 6 February 2001 8 Small Group Multicast 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 Abstract 35 Multicast has become increasingly important with the emergence of 36 network-based applications such as IP telephony and video 37 conferencing. The Internet community has done a significant amount 38 of work on IP multicast over the last decade [1-10] and as a 39 result, there are a number of multicast applications that are used 40 today on the Mbone, the multicast-capable virtual network that is 41 layered on top of (portions of) the Internet [10]. However, while 42 today's multicast schemes are scaleable in the sense that they can 43 support very large multicast groups, there are scalability issues 44 when a network needs to support a very large number of distinct 45 multicast groups. This document describes a new scheme for 46 multicast that complements the existing schemes. Whereas the 47 existing schemes can support a limited number of very large 48 multicast groups, the scheme described here can support a very 50 IETF Draft Small Group Multicast February 2001 52 large number of small multicast groups. 54 1. Introduction 56 Multicast, the ability to efficiently send data to a group of 57 destinations, is becoming increasingly important for applications 58 such as IP telephony, video-conferencing, video distribution, 59 collaborative work environments, multiparty networked games, etc. 61 There seem to be two kinds of multicasts that are important: a 62 broadcast-like multicast that sends data to a very large number of 63 destinations and a "narrowcast" multicast that sends data to a 64 fairly small group. An example of the first is the audio & video 65 multicasting of a working group session from an IETF meeting to 66 sites all around the world. An example of the second is a 67 videoconference involving 3 or 4 parties. For reasons described 68 below, it seems prudent to use different mechanisms for these two 69 cases. As the reliable multicast transport group has stated: "it 70 is believed that a 'one size fits all' protocol will be unable to 71 meet the requirements of all applications" [11]. 73 1.1. Current Multicast Schemes 75 Current multicast schemes [1,3,4,6,8] were designed to handle very 76 large multicast groups. These work well if one is trying to 77 distribute broadcast-like channels all around the world but they 78 have scalability problems when there is a very large number of 79 groups. 81 In some of these schemes, the nodes in the network build a 82 multicast distribution tree for each 83 pair and they disseminate this multicast routing information to 84 places where it isn't necessarily needed, which leads to scaling 85 problems if there are a large number of multicast groups. 87 Some other schemes try to limit the amount of multicast routing 88 information that needs to be disseminated, processed and stored 89 throughout the network. These schemes use a "shared distribution 90 tree" that is shared by all the members of a multicast group and 91 they try to limit the distribution of multicast routing 92 information to just those nodes that "really need it". But these 93 schemes also have problems. Because of the shared tree, they use 94 less than optimal paths in routing packets to their destinations 95 and they tend to concentrate traffic in small portions of a 96 network. They also require that all of the routers in a multicast 97 tree "signal", process and store multicast routing information. 98 And they require that multicast routing information for the 99 various multicast groups be communicated across inter-AS 100 administrative boundaries. These requirements cause scalability 102 IETF Draft Small Group Multicast February 2001 104 problems and increase administrative complexity if there are a 105 large number of multicast groups. 107 2. Small Group Multicast (SGM) 109 2.1. Overview 111 The "Small Group Multicast" (SGM) scheme described here attempts 112 to eliminate these problems for the case of small groups. In SGM, 113 the source node keeps track of the destinations that it wants to 114 send packets to, and creates packet headers that contain the list 115 of destination addresses. SGM-capable routers receive these 116 packets, parse the SGM headers and use the ordinary unicast route 117 table to determine how to route the packet to each destination. 118 This eliminates the need for class D addresses, as well as the 119 need for network routers to store state for the various multicast 120 groups. This makes SGM very scaleable in terms of the number of 121 groups that can be supported since the nodes in the network do not 122 need to disseminate or store any multicast routing information for 123 these groups. And since it doesn't use any multicast routing 124 protocol, there are no inter-AS multicast routing "peering" issues 125 to contend with. SGM has the additional benefit that packets 126 always take the "right" path as determined by the ordinary unicast 127 route protocols. Unlike the shared tree schemes, SGM minimizes 128 network latency and maximizes network "efficiency". This removes 129 some important obstacles that have, to this point, prevented the 130 widespread acceptance and adoption of multicast. Thus, SGM makes 131 multicast practical for very large numbers of small groups, which 132 as suggested above is a very important case. Note that while SGM 133 is not suitable for large multicast groups, such as the broadcast 134 of an IETF meeting, it does provide an important complement to 135 existing multicast schemes in that it can support very large 136 numbers of small groups. 138 SGM takes advantage of one of the fundamental tenets of the 139 Internet "philosophy", namely that one should move complexity to 140 the edges of the network and keep the middle of the network 141 simple. This is the principle that guided the design of IP and TCP 142 and it's the principle that has made the incredible growth of the 143 Internet possible. For example, one reason that the Internet has 144 been able to scale so well is that the routers in the core of the 145 network deal with large CIDR blocks as opposed to individual hosts 146 or individual "connections". The routers in the core don't need to 147 keep track of the individual TCP connections that are passing 148 through them. Similarly, the IETF's diffserv effort is based on 149 the idea that the routers shouldn't have to keep track of a large 150 number of individual RSVP flows that might be passing through 151 them. It's the authors' belief that the routers in the core 152 shouldn't have to keep track of a large number of individual 154 IETF Draft Small Group Multicast February 2001 156 multicast flows either. 158 2.2. Mechanism 160 In Small Group Multicast, the source node keeps track of the 161 destinations that it wants to send packets to. The source encodes 162 a list of unicast destinations in an SGM header that follows the 163 L3 header, and then sends the packet to a router. Each router 164 along the way parses the SGM header, partitions the destinations 165 based on each destination's next hop, and forwards an appropriate 166 SGM packet to each of the next hops. Each "final" hop removes the 167 SGM encoding, and forwards the data as a standard unicast packet 168 to its destination. 170 For example, suppose that A is trying to get packets distributed 171 to B, C & D in figure 1 below: 173 R4 ---- B 174 / 175 / 176 A ----- R1 ---- R2 ---- R3 R8 ---- C 177 \ / 178 \ / 179 R5 ---- R6 ---- R7 180 \ 181 \ 182 R9 ---- D 183 Figure 1 185 This is accomplished as follows: A sends an SGM packet to its 186 default router, R1, that includes the list of destinations for the 187 packet. Ignoring some details, the packet that A sends to R1 might 188 look like this: 190 Level 3 header: 191 < dest = R1 > 192 < src = A > 193 < protocol = small group multicast > (new protocol type) 195 Level "3.5" header: 196 < dest = B C D > 197 < src = A > 199 followed by the payload that A wants delivered to B, C and D. 201 (Note that the SGM layer is said to be at "level 3.5" since it's 202 between IP and UDP in the IP protocol stack. SGM is carried within 203 an IP datagram and it carries a UDP payload.) 205 IETF Draft Small Group Multicast February 2001 207 When R1 receives this packet, it needs to properly process the SGM 208 header. The processing that a router does on receiving one of 209 these small group multicast packets is as follows: 211 o Perform a route table lookup to determine the next hop for each 212 of the destinations listed in the packet. 213 o Partition the set of destinations based on their next hops. 214 o Replicate the packet so that there's one copy of the packet for 215 each of the next hops found in the previous steps. 216 o Modify the list of destinations in each of the copies so that 217 the list in the copy for a given next hop includes just the 218 destinations that ought to be routed through that next hop. 219 o Send the modified copies of the packet on to the next hops. 220 o Optimization: If there is only one destination for a particular 221 SGM next hop, send the packet as a standard unicast packet to the 222 destination, as there is no multicast gain by formatting it as 223 an SGM packet. 225 So, in the example above, R1 will send a single packet on to R2 226 with a destination list of < B C D > and R2 will send a single 227 packet to R3 with the same destination list. 229 When R3 receives the packet, it will, by the algorithm above, send 230 one copy of the packet to destination R5 with an SGM list of < C D 231 >, and one ordinary unicast packet addressed to < B >. R4 will 232 receive a standard unicast packet and forward it on to < B >. R5 233 will forward the SGM packet that it receives on to R6 which will 234 pass it on to R7. When the packet reaches R7, R7 will transmit 235 ordinary unicast packets addressed to < C > and < D > 236 respectively. R8 and R9 will receive standard unicast packets, and 237 forward the packets on to < C > and < D > respectively. 239 It's important that the SGM packet that is sent to a given next 240 hop only includes destinations for which that next hop is the next 241 hop listed in the route table. If the list of destinations in the 242 packet sent to R4, for example, had also included C and D, R4 243 would send extra packets on to those nodes on a less than optimum 244 path. This could waste a lot of bandwidth if one is, for example, 245 multicasting a videoconference. And this could cause serious 246 problems when route loops occur since a multicast packet could 247 "spray" large numbers of packets in a number of different 248 directions as it travels around a loop. Since the SGM packet that 249 is sent to a given next hop only includes the destinations that 250 are supposed to be reached through that next hop, these problems 251 are eliminated. 253 Note that when routing topology changes, the routing for a 254 multicast flow will automatically adapt to the new topology since 255 the path a multicast packet takes to a given destination always 256 follows the ordinary, unicast routing for that destination. 258 IETF Draft Small Group Multicast February 2001 260 Note also that since the SGM header is added to the data portion 261 of the packet, if the sender wishes to avoid IP fragmentation, it 262 must take the size of the SGM header into account. 264 See the Appendix for the SGM encoding formats. 266 3. Interoperability with Today's Routers 268 In the description above all of the routers in the network were 269 "SGM-capable". But the scheme can also be used in an environment 270 that includes routers that have no knowledge of SGM. This is 271 important since it allows SGM to be used without upgrading all the 272 routers in a network. There are two methods that can be used: the 273 first uses SGM "tunnels"; the second, icmp unreachable messages. 275 3.1. SGM Tunnels 277 One way to deploy SGM in a network that has routers that have no 278 knowledge of SGM is to setup "tunnels" between SGM peers. This 279 enables the creation of a virtual network layered on top of an 280 existing network. The SGM routers exchange and maintain SGM 281 routing information via any standard unicast routing protocol 282 (e.g. RIP, OSPF, ISIS). The SGM routing table that is created is 283 simply a standard unicast routing table that contains the 284 destinations that have SGM connectivity, along with their 285 corresponding SGM next hops. In this way, packets may be forwarded 286 hop-by-hop to other SGM routers, or may be "tunneled" through non- 287 SGM routers in the network. 289 For example, suppose that A is trying to get packets distributed 290 to B, C & D in figure 2 below, where "S" routers are SGM-capable, 291 and "R" routers are not. Figure 3 shows the routing tables created 292 via the SGM tunnels: 294 R4 ---- B 295 / 296 / 297 A ----- S1 ---- R2 ---- S3 R8 ---- C 298 \ / 299 \ / 300 R5 ---- R6 ---- S7 301 \ 302 \ 303 R9 ---- D 304 Figure 2 306 Router S1 establishes a tunnel to SGM peer S3. 308 IETF Draft Small Group Multicast February 2001 310 Router S3 establishes a tunnel to SGM peers S1 and S7. 311 Router S7 establishes a tunnel to SGM peer S3. 313 S1 routing table: S3 routing table: S7 routing table: 314 Dest | NextHop Dest | NextHop Dest | NextHop 315 ------+---------- ------+--------- ------+--------- 316 B | S3 A | S1 A | S3 317 C | S3 C | S7 B | S3 318 D | S3 D | S7 320 Figure 3 322 The source A will send an SGM packet to its default SGM router, 323 S1, that includes the list of destinations for the packet. As 324 described in section 2.2, the packet that A sends to S1 might look 325 like this: 327 Level 3 header: 328 < dest = S1 > 329 < src = A > 330 < protocol = small group multicast > (new protocol type) 332 Level "3.5" header: 333 < dest = B C D > 334 < src = A > 336 followed by the payload that A wants delivered to B, C and D. 338 When S1 receives this packet it needs to properly process the 339 multicast. The processing that this router does on receiving one 340 of these small group multicast packets is as follows: 342 o Perform a route table lookup in the SGM routing table to 343 determine the SGM next hop for each of the destinations listed in 344 the packet. 345 o If no SGM next hop is found, replicate the packet and send a 346 standard unicast to the destination. 347 o For those destinations for which an SGM next hop is found, 348 partition destinations based on their next hops. 349 o Replicate the packet so that there's one copy of the packet for 350 each of the SGM next hops found in the previous steps. 351 o Modify the list of destinations in each of the copies so that 352 the list in the copy for a given next hop includes just the 353 destinations that ought to be routed through that next hop. 354 o Send the modified copies of the packet on to the next hops. 355 o Optimization: If there is only one destination for a particular 356 SGM next hop, send the packet as a standard unicast packet to the 357 destination, as there is no multicast gain by formatting it as an 358 SGM packet. 360 IETF Draft Small Group Multicast February 2001 362 So, in the example above, S1 will send a single packet on to S3 363 with a destination list of < B C D >. This packet will be received 364 by R2 as a unicast packet with destination S3, and R2 will forward 365 it on, having no knowledge of SGM. When S3 receives the packet, it 366 will, by the algorithm above, send one copy of the packet to 367 destination < B > as an ordinary unicast packet, and 1 copy of the 368 packet to S7 with a destination list of < C D >. R4, R5, and R6 369 will behave as standard routers with no knowledge of SGM. When S7 370 receives the packet, it will parse the packet and transmit 371 ordinary unicast packets addressed to < C > and < D > 372 respectively. 374 By using tunnels, packets follow the "best possible" path to the 375 various destinations (as determined by the unicast routing 376 protocols), while at the same minimizing the total number of 377 packets that must be transmitted on the network. 379 3.2. ICMP 381 A second method for the gradual deployment of SGM in IP networks 382 is based on the use of ICMP. In this case, forwarding follows as 383 described in figure 1 (see section 2.2). However, an assumption is 384 made that any router receiving an SGM packet that does not 385 understand this new protocol will send an icmp message back to the 386 source. This is a router requirement as specified in RFC1812, 387 "Requirements for IP Version 4 Routers" [12]. Section 5.2.7.1 of 388 RFC1812 says that a router should send an ICMP Destination 389 Unreachable message with a code of 2, signifying Protocol 390 Unreachable, if the transport protocol designated in a datagram is 391 not supported in the transport layer of the final destination. 393 Thus, a router that doesn't understand this new protocol should 394 send an icmp "destination unreachable, protocol unreachable" 395 message back to the source. (If the icmp message is lost for some 396 reason, a subsequent small group multicast packet will cause 397 another icmp to be sent.) This enables the source to know when a 398 router doesn't understand the new protocol. Furthermore, since the 399 icmp message will include the initial part of the original packet, 400 the source will also know the destinations that are not reachable 401 via SGM, so the source can use unicast packets to reach those 402 destinations. When routing topology changes, additional icmp 403 "destination unreachable, protocol unreachable" messages may be 404 generated and the source may use unicasts for additional 405 destinations. The source can also periodically send an SGM packet 406 to the destinations that are on its "unicast list" i.e. the list 407 of nodes that it is reaching via unicast. Destinations that become 408 reachable via SGM (i.e. those do not appear in subsequent icmp 409 "destination unreachable, protocol unreachable" messages) can then 410 be removed from the unicast list. (Note that another possibility 412 IETF Draft Small Group Multicast February 2001 414 would be to send an SGM "ping" periodically to the set of 415 destinations and then use unicast to reach those destinations that 416 don't respond to the ping). 418 Thus, Small Group Multicast can perform some multicasting in an 419 environment that includes "legacy" routers which do not understand 420 SGM. It won't work particularly well if there are many routers 421 that don't understand SGM but this backwards compatibility may be 422 important since it makes some of the benefits of multicast 423 possible before all the routers in a network have been upgraded. 424 This can be very useful since it may take some time to upgrade all 425 the routers in a large network. 427 The use of the above method requires the bitmap style SGM packet 428 encoding (see Appendix A.1.1). 430 4. Host Considerations 432 4.1. Control Plane 434 Unlike today's multicast schemes, SGM has no "control plane". 435 There is no IGMP, and as mentioned above, there are no intradomain 436 or interdomain multicast routing protocols or source discovery 437 protocols. With SGM, the means by which multicast groups are 438 defined is an application level issue and applications are not 439 confined to the model in which hosts use IGMP to join a multicast 440 group. 442 This allows applications such as voice and multimedia conferencing 443 to be programmed in a very natural way, i.e. the user can place 444 the call to the parties he or she wants to talk to as he or she 445 would using the conferencing buttons on his or her telephone. The 446 application developer is not limited to the receiver-initiated 447 joins of the IGMP model. 449 Although there is no SGM "control plane", several control planes 450 have been defined for the establishment of voice and multimedia 451 conferences over IP networks, including SIP[13] and H.323[14]. 453 These protocols use two mechanisms in establishing sessions among 454 multiple participants: multicast using today's IP multicast 455 schemes and "multi-unicasting". In "multi-unicasting", the 456 application keeps track of the participants' unicast addresses and 457 sends a unicast to each of those addresses. For reasons described 458 in the introductory section of this paper, multi-unicasting rather 459 than multicast is the prevalent solution in use today. 461 It's a simple matter to replace multi-unicast code with SGM 462 multicast. All that the developer has to do is replace a loop that 464 IETF Draft Small Group Multicast February 2001 466 sends a unicast to each of the participants by a single "sgm_send" 467 that sends the data to the participants. Thus it's a simple matter 468 to incorporate SGM into real conferencing applications. 470 It's also worth mentioning that although SGM doesn't depend on a 471 receiver-initiated join, the receiver-initiated join model can be 472 implemented, if desired, by introducing a server that hosts can 473 talk to join a conference. 475 4.2. SGM API 477 As mentioned earlier, each of the final destinations of an SGM 478 packet receives an ordinary UDP packet. This means that hosts can 479 receive an SGM multicast with a standard, unmodified TCP/IP stack. 480 Hosts can also transmit SGM packets with a standard TCP/IP stack 481 with a small SGM library that sends SGM packets on a raw socket. 482 This has been used to implement SGM based applications on both 483 Unix and Windows platforms without any kernel changes. 485 Another possibility is to modify the sockets interface slightly. 486 For example, one might add an "sgm_sendto" function that works 487 like sendto but that uses a list of destination addresses in place 488 of the single address that sendto uses. 490 5. Summary 492 In summary, the disadvantages of Small Group Multicast are: 493 o the extra bytes that are sent in a multicast packet for the list 494 of destinations. 495 o the need to use unicast packets in some cases to reach 496 destinations that are behind "legacy" routers. 497 o the need for a new IP stack in hosts (unless raw sockets are 498 available in which case SGM packets can be sent over a raw 499 socket). 500 o the fact that SGM is not suitable for huge broadcast-like 501 multicasts. It's targeted for "small" conferences. 503 The key advantages are: 504 o it's very scaleable; it can handle a very large number of small 505 groups. 506 o the work involved is limited to just the nodes that are on the 507 multicast tree. 508 o no per flow state information is stored on the routers. 509 o no multicast route protocol messages are communicated or 510 processed; no intra-AS or inter-AS route protocols. 511 o minimum administrative complexity; no need for complicated inter- 512 AS peering agreements; it's just as easy for a network 513 administrator to support multicast as it is to support unicast, 514 and it will be just as easy to support multicast across the 516 IETF Draft Small Group Multicast February 2001 518 Internet as it is to support unicast. 519 o traffic follows the correct paths; traffic is not concentrated 520 in a small part of the network; minimum network latency; maximum 521 network "efficiency". 522 o no need for class D addresses which means: 523 - no need for a server that hands out class D addresses which 524 can be a bottleneck or a point of failure. 525 - no one can join the class D group and "eavesdrop" on the 526 class D address; the source knows who he's sending to. 527 o SGM can be easily adapted to provide a "reliable multicast". 529 The advantages of Small Group Multicast suggest that this scheme 530 can be a very useful complement to the existing multicast schemes. 531 Whereas the existing schemes can support a limited number of very 532 large multicast groups, SGM can support a huge number (i.e. 533 virtually an unlimited number) of small multicast groups and thus 534 can play an important role in supporting applications such as 535 conferencing applications on the Internet. 537 6. Security Considerations 539 An "eavesdropper" cannot join a multicast "group", as the source 540 controls the membership of the multicast transmissions. Also, 541 there is no need for a server to hand out class D addresses which 542 could be subject to "denial of service" or other forms of attack. 544 7. Acknowledgements 546 The authors would like to thank Brian Carpenter, Dirk Ooms and 547 Yuji Imai for their feedback and ideas. The authors would also 548 like to thank Orit Levin of RADVision, and Pat Galvin and Jeff 549 Durham of DataBeam, for providing an application developer's 550 perspective. We also thank Joe Mambretti and Ralph Demuth of 551 iCAIR, as well as Micah Beck and Bert Dempsey, co-leads of the 552 Internet2 Distributed Storage Infrastructure Initiative, for their 553 support in deploying SGM in the Internet2 environment. 555 8. References 557 [1] RFC 1075, Distance Vector Multicast Routing Protocol, D. 558 Waitzman, C. Partridge, S.E. Deering, Nov. 1988 560 [2] S.E. Deering. Multicast Routing in a Datagram Internetwork. 561 Ph.D. thesis, Electrical Engineering Dept., Stanford University, 562 Dec. 1991 564 [3] RFC 1584, Multicast Extensions to OSPF, J. Moy, March 1994 566 IETF Draft Small Group Multicast February 2001 568 [4] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and 569 L. Wei. The Pim Architecture for Wide-area Multicast Routing, ACM 570 Transactions on Networks, April 1996 572 [5] RFC 2189, Core Based Trees (CBT version 2) Multicast Routing 573 Protocol Specification, A. Ballardie, Sept., 1997 575 [6] RFC 2201, Core Based Trees (CBT) Multicast Routing 576 Architecture, A. Ballardie, Sept. 1997 578 [7] RFC 2236, Internet Group Management Protocol, Version 2, W. 579 Fenner, Nov. 1997 581 [8] RFC 2362, Protocol Independent Multicast-Sparse Mode (PIM-SM): 582 Protocol Specification, D. Estrin et al, June 1998 584 [9] D. Estrin, D. Farinacci, V. Jacobson, C. Liu, L. Wei, P. 585 Sharma, and A. Helmy, "Protocol Independent Multicast-dense Mode 586 (pim-dm): Protocol Specification", Work in Progress. 588 [10] Frequently Asked Questions (FAQ) on the Multicast Backbone 589 (MBONE), ftp://venera.isi.edu/mbone/faq.txt 591 [11] Reliable Multicast Transport Working Group web site, 592 http://www.ietf.org/html.charters/rmt-charter.html, June 15, 1999 594 [12] RFC 1812, Requirements for IP Version 4 Routers, F. Baker, 595 June 1995 597 [13] RFC 2543, SIP: Session Initiation Protocol, M. Handley et al, 598 March 1999 600 [14] ITU-T Recommendation H.323 (2000), Packet-Based Multimedia 601 Communications Systems 603 9. Authors 605 Rick Boivie 606 IBM T. J. Watson Research Center 607 30 Saw Mill River Rd. 608 Hawthorne, NY 10532 609 Phone: 914-784-3251 610 Email: rhboivie@us.ibm.com 612 Nancy Feldman 613 IBM T. J. Watson Research Center 614 30 Saw Mill River Rd. 615 Hawthorne, NY 10532 616 Phone: 914-784-3254 617 Email: nkf@us.ibm.com 619 IETF Draft Small Group Multicast February 2001 621 A. Appendix: SGM Encoding 623 This appendix describes the packet formats for SGM layered on IP. 624 An SGM header is comprised of a fixed header followed by one or 625 more destination lists. 627 SGM packets are assigned IP protocol type: 628 IPPROTO_SGM 0xTBA 630 A.1. Fixed Header 632 The SGM fixed header may be either a bitmap-style header or a 633 vanilla-style header, as determined by the bitmap bit within the 634 fixed header. 636 A.1.1 Bitmap Fixed Header 638 The bitmap fixed header allows for efficient SGM header 639 processing. Each destination corresponds to a bit in the bitmap; 640 if set, then a packet should be forwarded to the corresponding 641 destination; if clear, then the corresponding destination is 642 ignored. A modification to the destination list is achieved by 643 simply overwriting the appropriate bits in the bitmap. 645 The bitmap fixed header encoding is as follows: 647 0 1 2 3 648 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 |Version|B|S|A|r| Bitmap . . . 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | GroupId | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Checksum | TTL | Reserved | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 Version 658 Four-bit field indicating the format of the SGM header. This 659 document describes version 1. 661 B-bit (Bitmap header) 662 If this bit is set, the bitmap-style header is in use, else the 663 vanilla header is in use. See section A.1.2. 665 S-bit(SGM header persistence) 666 If this bit is set, an SGM router MUST NOT convert the SGM 667 packet to unicast packet(s), i.e. the packet MUST stay an SGM 668 packet end-to-end. 670 IETF Draft Small Group Multicast February 2001 672 A-bit (Anonymity) 673 If this bit is set, the destination address for which the 674 corresponding bit in the bitmap is zero MUST be overwritten 675 with zeros. 677 r-bit (Reserved) 678 Reserved bit. It must be zero on transmission and must be ignored 679 on receipt. 681 Bitmap 682 This five octet field is a bitmap which corresponds to the SGM 683 destinations in the header, such that the first SGM destination 684 corresponds to the first bit, the second destination 685 corresponds to the second bit, and so on. The i-th bit is set 686 if the packet should be forwarded to the i-th destination. 688 Note that when an ICMP error message is returned to the 689 originating sender, it is guaranteed to contain only the first 690 64-bits of the original IP datagram payload. Due to this 691 limitation in the size of the ICMP error message, a size of 692 five bytes was chosen for the bitmap. This is the maximum size 693 that can be accommodated which still returns sufficient 694 information in the ICMP error message, such that the sender can 695 determine which destinations are not reachable via SGM (see 696 section 3.2). Five bytes enforces a limit of at most forty 697 destinations included within an SGM packet. If more than forty 698 destinations are required, the vanilla style SGM header may be 699 used (see section A.1.2). 701 GroupID 702 Two octet field that uniquely identifies a group of SGM 703 destinations. This is returned in an ICMP error message, and 704 may be used to correlate the error with the originating SGM 705 group. 707 Checksum 708 Two octet checksum on the SGM header only. This is verified and 709 recomputed at each point that the SGM header is modified. The 710 checksum field is the 16 bit one's complement of the one's 711 complement sum of all the bytes in the header. For purposes of 712 computing the checksum, the value of the checksum field is 713 zero. 715 TTL (Time-to-Live) 716 One octet field indicating the maximum time the SGM packet is 717 allowed to remain in the SGM network. Each SGM router MUST 718 decrement this field by one; if it is decremented to zero, the 719 packet MUST be discarded. 721 IETF Draft Small Group Multicast February 2001 723 Reserved 724 One octet reserved field. It must be zero on transmission and must 725 be ignored on receipt. 727 A.1.2 Vanilla Fixed Header 729 The vanilla header does not contain a bitmap; SGM routers remove 730 destinations when they are no longer on the forwarding path. This 731 type of header gives the sender the opportunity to have a 732 virtually unlimited number of destinations. However, this requires 733 more per-router processing overhead than the bitmap header, as a 734 modification to destination list requires the building of a new 735 SGM header. Also note that this header style is not compatible 736 with the ICMP deployment method (see section 3.2) 738 The vanilla fixed header encoding is as follows: 740 0 1 2 3 741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 |Version|B|S|res| TTL | Checksum | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Version 747 Four-bit field indicating the format of the SGM header. This 748 document describes version 1. 750 B-bit (Bitmap header) 751 If this bit is set, the bitmap-style header is in use, else the 752 vanilla header is in use. See section A.1.1. 754 S-bit(SGM header persistence) 755 If this bit is set, an SGM router MUST NOT convert the SGM 756 packet to unicast packet(s), i.e. the packet MUST stay an SGM 757 packet end-to-end. 759 res (reserved) 760 Reserved two bits. They must be zero on transmission and must be 761 ignored on receipt. 763 TTL (Time-to-Live) 764 One octet field indicating the maximum time the SGM packet is 765 allowed to remain in the SGM network. Each SGM router MUST 766 decrement this field by one; if it is decremented to zero, the 767 packet MUST be discarded. 769 Checksum 770 Two octet checksum on the SGM header. This is verified and 771 recomputed at each point that the SGM header is processed. The 773 IETF Draft Small Group Multicast February 2001 775 checksum field is the 16 bit one's complement of the one's 776 complement sum of all the bytes in the header. For purposes of 777 computing the checksum, the value of the checksum field is zero. 779 A.2. Destination List 781 The destination list is comprised of a fixed segment followed by a 782 variable length destination field. The destination field encoding 783 is determined by the protocol and address family fields. 785 The destination fixed header encoding is as follows: 787 0 1 2 3 788 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | DestCnt | Protocol | Address Family | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Destination(s) (variable) ... 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 DestCnt 796 One octet field containing the total number of destinations for 797 the following Address family. 799 Protocol 800 One octet field containing the protocol of the receiving port 801 for the following SGM destinations, e.g. IPPROTO_UDP (see 802 section A.2.1). 804 Address family 805 Two octet field containing the identity of the Network Layer 806 protocol associated with the DestAddress(es) that follow (see 807 rfc 1700). 809 A.2.1 Destination(s): Protocol UDP 811 The list of UDP destination(s) for the address family specified. A 812 UDP "destination" is an IP-address/UDP-port pair. 814 The encoding is as follows: 816 IETF Draft Small Group Multicast February 2001 818 0 1 2 3 819 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | DestAddress(es) ... 822 ~ 823 | 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | PortNum(s) | ... 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 ~ 828 | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 DestAddress(es) 832 List of destination address(es). Each address length is four 833 bytes for IPv4 and sixteen bytes for IPv6. 835 PortNum(s) 836 List of two octet destination port number(s), where each port 837 corresponds in placement to the preceding DestAddress(es).