idnits 2.17.1 draft-ooms-xcast-basic-spec-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1559. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1565. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 23 characters in excess of 72. ** The abstract seems to contain references ([1112]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 137 has weird spacing: '...n state infor...' == Line 393 has weird spacing: '...ividual multi...' -- 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) == Unused Reference: '2236' is defined on line 1397, but no explicit reference was found in the text == Unused Reference: '2401' is defined on line 1400, but no explicit reference was found in the text == Unused Reference: '2460' is defined on line 1403, but no explicit reference was found in the text == Unused Reference: 'BOIV' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'DOOR' is defined on line 1430, but no explicit reference was found in the text == Unused Reference: 'MBONE' is defined on line 1446, but no explicit reference was found in the text == Unused Reference: 'PERL' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'BCP-2004' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: '2434' is defined on line 1472, but no explicit reference was found in the text == Unused Reference: '2119' is defined on line 1475, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1770 (Obsoleted by RFC 6814) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-02) exists of draft-boivie-sgm-01 -- No information found for draft-fari-nacci-msdp - is the name correct? == Outdated reference: A later version (-04) exists of draft-holbrook-ssm-00 == Outdated reference: A later version (-02) exists of draft-paridaens-xcast-sec-framework-01 == Outdated reference: A later version (-03) exists of draft-perlman-simple-multicast-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 19 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT R. Boivie, N. Feldman 3 IBM 4 Y. Imai 5 WIDE / Fujitsu 6 W. Livens 7 ESCAUX 8 D. Ooms 9 OneSparrow 10 O. Paridaens 11 Alcatel 12 July, 2007 13 Expires January, 2008 15 Explicit Multicast (Xcast) Concepts and Options 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). All Rights Reserved. 44 Abstract 46 While traditional IP multicast schemes [1112] are scalable for very 47 large multicast groups, they have scalability issues with a very 48 large number of distinct multicast groups. This document describes 49 Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with 50 complementary scaling properties: Xcast supports a very large number 51 of small multicast sessions. Xcast achieves this by explicitly 52 encoding the list of destinations in the data packets, instead of 53 using a multicast group address. 55 This document discusses Xcast concepts and options in several areas; 56 it does not provide a complete technical specification. 58 Table of Contents 60 1. Introduction 61 2. Xcast Overview 62 3. The cost of the traditional IP multicast schemes 63 4. Motivation 64 5. Application 65 6. Xcast Flexibility 66 7. Xcast Control Plane Options 67 7.1. SIP Control Plane for Xcast 68 7.2. Receiver-Initiated Join for Xcast 69 8. Optional information 70 8.1. List of ports 71 8.2. List of DSCPs 72 8.3. Channel Identifier 73 9. Possible Xcast Packet Encoding 74 9.1. General 75 9.2. IPv4 76 9.2.1. IPv4 header 77 9.2.2. Xcast4 header 78 9.3. IPv6 79 9.3.1. IPv6 header 80 9.3.2. Xcast6 header 81 9.3.2.1. Routing Extension header 82 9.3.2.2. Destination Extension header 83 10. Impact on Upper Layer Protocols 84 10.1. Checksum calculation in UDP and ICMP 85 10.2. IPsec Authentication header 86 11. Gradual Deployment 87 11.1. Tunneling 88 11.2. Premature X2U 89 11.3. Semi-permeable tunneling (IPv6 only) 90 11.4. Special case: deployment without network support 91 11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast in a Not-so-Small Network 92 12. (Socket) API 93 13. Unresolved issues 94 14. Security Considerations 95 15. IANA Considerations 96 16. Informative Reference 97 17. Author's Addresses 98 18. Full Copyright Statement 99 19. IPR Notices 101 1. Introduction 103 While traditional IP multicast schemes [1112] are scalable for very 104 large multicast groups, they have scalability issues with a very 105 large number of distinct multicast groups. This document describes 106 Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with 107 complementary scaling properties: Xcast supports a very large number 108 of small multicast sessions. Xcast achieves this by explicitly 109 encoding the list of destinations in the data packets, instead of 110 using a multicast group address. This document discusses Xcast 111 concepts and options in several areas; it does not provide a complete 112 technical specification. 114 Multicast, the ability to efficiently send data to a group of 115 destinations, is becoming increasingly important for applications 116 such as IP telephony and video-conferencing. 118 Two kinds of multicast seem to be important: a broadcast-like 119 multicast that sends data to a very large number of destinations, and 120 a "narrowcast" multicast that sends data to a fairly small group. An 121 example of the first is the audio and video multicasting of a 122 presentation to all employees in a corporate intranet. An example of 123 the second is a videoconference involving 3 or 4 parties. For reasons 124 described below, it seems prudent to use different mechanisms for 125 these two cases. As the reliable multicast transport group has 126 stated: "it is believed that a 'one size fits all' protocol will be 127 unable to meet the requirements of all applications" [RMT]. Note that 128 the 1998 IAB Routing Workshop [2902] came to the same conclusion: 129 "For example, providing for many groups of small conferences (a small 130 number of widely dispersed people) with global topological scope 131 scales badly given the current multicast model". 133 Today's multicast schemes can be used to minimize bandwidth 134 consumption. Explicit Multi-Unicast (Xcast) also can be used to 135 minimize bandwidth consumption for "small groups". But it has an 136 additional advantage as well. Xcast eliminates the per session 137 signaling and per session state information of traditional IP 138 multicast schemes and this allows Xcast to support very large numbers 139 of multicast sessions. And this scalability is important since it 140 enables important classes of applications such as IP telephony, 141 videoconferencing, collaborative applications, networked games etc. 142 where there are typically very large numbers of small multicast 143 groups. 145 Interestingly, the idea for Xcast has been around for some time 146 although this was not immediately known to the 3 groups that 147 independently re-invented it in the late 1990's. In fact the very 148 first proposal of the multicast concept in the Internet community, by 149 Lorenzo Aguilar in his 1984 SIGCOMM paper [AGUI] proposed the use of 150 an explicit list of destinations discussed in more detail below. At 151 about the same time, David Cheriton and Stephen Deering developed 152 Host Group Multicast in 1985 [CHER]. 154 The Internet community compared the 2 proposals and concluded that a 155 single mechanism was preferable to multiple mechanisms. Further, 156 since Aguilar's proposal seemed to have serious scaling problems, the 157 Host Group model was adopted. 159 However for reasons described below, we believe it makes sense to use 160 different mechanisms for the two different kinds of multicast 161 discussed above. While Host Group multicast may have been sufficient 162 in the Internet of 1985, we believe that Xcast can be an important 163 complement to Host Group multicast in the Internet of the 21st 164 century. 166 2. Xcast Overview 168 In this document the following terminology will be used: 170 - Session: in Xcast the term 'multicast session' will be used instead 171 of 'multicast group' to avoid the strong association of multicast 172 groups with multicast group addresses in traditional IP multicast. 174 - Channel: in a session with multiple senders (e.g. a video 175 conference), the flow sourced by one sender will be called a channel. 176 So a session can contain one or more channels. 178 In the Host Group Model the packet carries a multicast address as a 179 logical identifier of all group members. In Xcast, the source node 180 keeps track of the destinations in the multicast channel that it 181 wants to send packets to. 183 The source encodes the list of destinations in the Xcast header, and 184 then sends the packet to a router. Each router along the way parses 185 the header, partitions the destinations based on each destination's 186 next hop, and forwards a packet with an appropriate Xcast header to 187 each of the next hops. 189 When there is only one destination left, the Xcast packet can be 190 converted into a normal unicast packet, which can be unicasted along 191 the remainder of the route. This is called X2U (Xcast to Unicast). 193 For example, suppose that A is trying to get packets distributed to 194 B, C & D in Figure 1 below: 196 R4 ---- B 197 / 198 / 199 A----- R1 ---- R2 ---- R3 R8 ---- C 200 \ / 201 \ / 202 R5 ---- R6 ---- R7 203 \ 204 \ 205 R9 ---- D 206 Figure 1 208 This is accomplished as follows: A sends an Xcast packet with the 209 list of destinations in its Xcast header to the first router, R1. 211 Since the Xcast header will be slightly different for IPv4 and IPv6 212 we won't reveal any details on the encoding of the Xcast header in 213 this section (see section 9). So, ignoring the details, the packet 214 that A sends to R1 looks like this: 216 [ src = A | dest = B C D | payload ] 218 When R1 receives this packet, it needs to properly process the Xcast 219 header. The processing that a router does on receiving one of these 220 Xcast packets is as follows: 222 - Perform a route table lookup to determine the next hop for each of 223 the destinations listed in the packet. 225 - Partition the set of destinations based on their next hops. 227 - Replicate the packet so that there's one copy of the packet for 228 each of the next hops found in the previous steps. 230 - Modify the list of destinations in each of the copies so that the 231 list in the copy for a given next hop includes just the destinations 232 that ought to be routed through that next hop. 234 - Send the modified copies of the packet on to the next hops. 236 - Optimization: If there is only one destination for a particular 237 next hop, the packet can be sent as a standard unicast packet to the 238 destination (X2U). 240 So, in the example above, R1 will send a single packet on to R2 with 241 a destination list of < B C D > and R2 will send a single packet to 242 R3 with the same destination list. 244 When R3 receives the packet, it will, by the algorithm above, send 245 one copy of the packet to next hop R5 with an Xcast list of < C D >, 246 and one ordinary unicast packet addressed to < B > to R4. R4 will 247 receive a standard unicast packet and forward it on to < B >. R5 will 248 forward the Xcast packet that it receives on to R6 which will pass it 249 on to R7. When the packet reaches R7, R7 will transmit ordinary 250 unicast packets addressed to < C > and < D > respectively. R8 and R9 251 will receive standard unicast packets, and forward the packets on to 252 < C > and < D > respectively. 254 It's important that the Xcast packet that is sent to a given next hop 255 only includes destinations for which that next hop is the next hop 256 listed in the route table. If the list of destinations in the packet 257 sent to R4, for example, had also included C and D, R4 would send 258 duplicate packets. 260 Note that when routing topology changes, the routing for an Xcast 261 channel will automatically adapt to the new topology since the path 262 an Xcast packet takes to a given destination always follows the 263 ordinary, unicast routing for that destination. 265 3. The cost of the traditional IP multicast schemes 267 Traditional IP multicast schemes [DEER, DEE2, FARI] were designed to 268 handle very large multicast groups. These work well if one is trying 269 to distribute broadcast-like channels all around the world but they 270 have scalability problems when there is a very large number of 271 groups. 273 The characteristics of the traditional IP multicast model are 274 determined by its two components: the Host Group model [DEER] and a 275 Multicast Routing Protocol. Both components make multicast very 276 different from unicast. 278 In the Host Group model, a group of hosts is identified by a 279 multicast group address, which is used both for subscriptions and 280 forwarding. This model has two main costs: 282 - Multicast address allocation: The creator of a multicast group 283 must allocate a multicast address which is unique in its scope 284 (scope will often be global). This issue is being addressed by 285 the Malloc working group, which is proposing a set of Multicast 286 Address Allocation Servers (MAAS) and three protocols (MASC, AAP, 287 MADCAP). 289 - Destination unawareness: When a multicast packet arrives in a 290 router, the router can determine the next hops for the packet, but 291 knows nothing about the ultimate destinations of the packet, nor 292 about how many times the packet will be duplicated later on in the 293 network. This complicates the security, accounting and policy 294 functions. 296 In addition to the Host Group model, a routing algorithm is required 297 to maintain the member state and the delivery tree. This can be done 298 using a (truncated) broadcast algorithm or a multicast algorithm 299 [DEER]. Since the former consumes too much bandwidth by 300 unnecessarily forwarding packets to some routers, only the multicast 301 algorithms are considered. These multicast routing protocols have 302 the following costs: 304 - Connection state: The multicast routing protocols exchange 305 messages that create state for each (source, multicast group) in 306 all the routers that are part of the point-to-multipoint tree. 307 This can be viewed as "per flow" signaling that creates multicast 308 connection state, possibly yielding huge multicast forwarding 309 tables. Some of these schemes even disseminate this multicast 310 routing information to places where it isn't necessarily needed 311 [1075]. Other schemes try to limit the amount of multicast 312 routing information that needs to be disseminated, processed and 313 stored throughout the network. These schemes (e.g. [2201]) use a 314 "shared distribution tree" that is shared by all the members of a 315 multicast group and they try to limit the distribution of 316 multicast routing information to just those nodes that "really 317 need it". But these schemes also have problems. Because of the 318 shared tree, they use less than optimal paths in routing packets 319 to their destinations and they tend to concentrate traffic in 320 small portions of a network. And these schemes still involve lots 321 of "per flow" signaling and "per flow" state. 323 - Source advertisement mechanism: Multicast routing protocols 324 provide a mechanism by which members get 'connected' to the 325 sources for a certain group without knowing the sources 326 themselves. In sparse-mode protocols [2201, DEE2], this is 327 achieved by having a core node, which needs to be advertised in 328 the complete domain. On the other hand, in dense-mode protocols 329 [1075] this is achieved by a "flood and prune" mechanism. Both 330 approaches raise additional scalability issues. 332 - Interdomain routing: Multicast routing protocols that rely on a 333 core node [2201, DEE2] additionally need an interdomain multicast 334 routing protocol (e.g. [FARI]). 336 The cost of multicast address allocation, destination unawareness and 337 the above scalability issues lead to a search for other multicast 338 schemes. Source-Specific Multicast (SSM) [HOLB] addresses some of 339 the above drawbacks: in SSM a host joins a specific source, thus the 340 channel is identified by the couple (source address, multicast 341 address). This approach avoids multicast address allocation as well 342 as the need for an interdomain routing protocol. The source 343 advertisement is taken out of the multicast routing protocol and is 344 moved to an out-of-band mechanism (e.g. web page). 346 Note that SSM still creates state and signaling per multicast channel 347 in each on-tree node. Figure 2 depicts the above costs as a function 348 of the number of members in the session or channel. All the costs 349 have a hyperbolic behavior. 351 cost of the traditional 352 IP multicast model 353 per member 354 ^ 355 | costly| OK 356 | <-----|-----> 357 | . | 358 | .. | 359 | ..|.. 360 | | ......... 361 | | ........ 362 +---------------------------> 363 | number of members 364 v 365 alternative=Xcast 366 Figure 2 368 The traditional IP multicast model becomes expensive for its members 369 if the groups are small. Small groups are typical for conferencing, 370 gaming and collaborative applications. These applications are well- 371 served by Xcast. 373 In practice, traditional IP multicast routing protocols impose 374 limitations on the number of groups and the size of the network in 375 which they are deployed. For Xcast these limitations do not exist. 377 4. Motivation 379 Xcast takes advantage of one of the fundamental tenets of the 380 Internet "philosophy", namely that one should move complexity to the 381 edges of the network and keep the middle of the network simple. This 382 is the principle that guided the design of IP and TCP and it's the 383 principle that has made the incredible growth of the Internet 384 possible. For example, one reason that the Internet has been able to 385 scale so well is that the routers in the core of the network deal 386 with large CIDR blocks as opposed to individual hosts or individual 387 "connections". The routers in the core don't need to keep track of 388 the individual TCP connections that are passing through them. 389 Similarly, the IETF's diffserv effort is based on the idea that the 390 routers shouldn't have to keep track of a large number of individual 391 RSVP flows that might be passing through them. It's the authors' 392 belief that the routers in the core shouldn't have to keep track of a 393 large number of individual multicast flows either. 395 Compared to traditional IP multicast, Xcast has the following 396 advantages: 398 1) Routers do not have to maintain state per session (or per channel) 399 [SOLA]. This makes Xcast very scalable in terms of the number of 400 sessions that can be supported since the nodes in the network do not 401 need to disseminate or store any multicast routing information for 402 these sessions. 404 2) No multicast address allocation required. 406 3) No need for multicast routing protocols (neither intra- nor 407 interdomain). Xcast packets always take the "right" path as 408 determined by the ordinary unicast routing protocols. 410 4) No core node, so no single point of failure. Unlike the shared 411 tree schemes, Xcast minimizes network latency and maximizes network 412 "efficiency". 414 5) Symmetric paths are not required. Traditional IP multicast 415 routing protocols create non-shortest-path trees if paths are not 416 symmetric. (A path between two nodes A and B is symmetric if the path 417 is both the shortest path from A to B as well as the shortest path 418 from B to A.) It is expected that an increasing number of paths in 419 the Internet will be asymmetric in the future as a result of traffic 420 engineering and policy routing, and thus the traditional IP multicast 421 schemes will result in an increasing amount of suboptimal routing. 423 6) Automatic reaction to unicast reroutes. Xcast will react 424 immediately to unicast route changes. In traditional IP multicast 425 routing protocols a communication between the unicast and the 426 multicast routing protocol needs to be established. In many 427 implementations this is on a polling basis, yielding a slower 428 reaction to e.g. link failures. It may also take some time for 429 traditional IP multicast routing protocols to fix things up if there 430 is a large number of groups that need to be fixed. 432 7) Easy security and accounting. In contrast with the Host Group 433 Model, in Xcast all the sources know the members of the multicast 434 channel, which gives the sources the means to e.g. reject certain 435 members or count the traffic going to certain members quite easily. 436 Not only a source, but also a border router is able to determine how 437 many times a packet will be duplicated in its domain. It also 438 becomes easier to restrict the number of senders or the bandwidth per 439 sender. 441 8) Heterogeneous receivers. Besides the list of destinations, the 442 packet could (optionally) also contain a list of DiffServ CodePoints 443 (DSCPs). While traditional IP multicast protocols have to create 444 separate groups for each service class, Xcast incorporates the 445 possibility of having receivers with different service requirements 446 within one multicast channel. 448 9) Xcast packets can make use of traffic engineered unicast paths. 450 10) Simple implementation of reliable protocols on top of Xcast, 451 because Xcast can easily address a subset of the original list of 452 destinations to do a retransmission. 454 11) Flexibility (see section 6). 456 12) Easy transition mechanisms (see section 11). 458 It should be noted that Xcast has a number of disadvantages as well: 460 1) Overhead. Each packet contains all remaining destinations. But, 461 the total amount of data is still much less than for unicast (payload 462 is only sent once). A method to compress the list of destination 463 addresses might be useful. 465 2) More complex header processing. Each destination in the packet 466 needs a routing table lookup. So an Xcast packet with n destinations 467 requires the same number of routing table lookups as n unicast 468 headers. Additionally, a different header has to be constructed per 469 next hop. Note however that: 471 a) Since Xcast will typically be used for super-sparse sessions, 472 there will be a limited number of branching points, compared to 473 non-branching points. Only in a branching point do new headers 474 need to be constructed. 476 b) The header construction can be reduced to a very simple 477 operation: overwriting a bitmap. 479 c) Among the non-branching points, a lot of them will contain only 480 one destination. In these cases normal unicast forwarding can be 481 applied. 483 d) By using a hierarchical encoding of the list of destinations in 484 combination with the aggregation in the forwarding tables the 485 forwarding can be accelerated ([OOMS]). 487 e) When the packet enters a region of the network where link 488 bandwidth is not an issue anymore, the packet can be transformed 489 by a Premature X2U. Premature X2U (see section 11.2) occurs when 490 a router decides to transform the Xcast packet for one or more 491 destinations into unicast packets. This avoids more complex 492 processing downstream. 494 f) Other mechanisms to reduce the processing have been described 495 in [IMAI] (tractable list) and [OOMS] (caching), but are not (yet) 496 part of the Xcast specification. 498 3) Xcast only works with a limited number of receivers. 500 5. Application 502 While Xcast is not suitable for multicast sessions with a large 503 number of members, such as the broadcast of an IETF meeting, it does 504 provide an important complement to existing multicast schemes in that 505 it can support very large numbers of small sessions. Thus Xcast 506 enables important applications such as IP telephony, 507 videoconferencing, multi-player games, collaborative e-meetings etc. 508 The number of these sessions will become huge. 510 Some may argue that it is not worthwhile to use multicast for 511 sessions with a limited number of members, and use unicast instead. 512 But in some cases limited bandwidth in the "last mile" makes it 513 important to have some form of multicast as the following example 514 illustrates. Assume n residential users that set up a video 515 conference. Typically access technologies are asymmetric (e.g. xDSL, 516 GPRS or cable modem). So, a host with xDSL has no problem receiving 517 n-1 basic 100kb/s video channels, but the host is not able to send 518 its own video data n-1 times at this rate. Because of the limited 519 and often asymmetric access capacity, some type of multicast is 520 mandatory. 522 A simple but important application of Xcast lies in bridging the 523 access link. The host sends the Xcast packet with the list of 524 unicast addresses and the first router performs a Premature X2U. 526 Since Xcast is not suitable for large groups, Xcast will not replace 527 the traditional IP multicast model, but it does offer an alternative 528 for multipoint-to-multipoint communications when there can be very 529 large numbers of small sessions. 531 6. Xcast Flexibility 533 The main goal of multicast is to avoid duplicate information flowing 534 over the same link. By using traditional IP multicast instead of 535 unicast, bandwidth consumption decreases while the state and 536 signaling per session increases. Xcast has a cost of 0 in these 2 537 dimensions, but it does introduce a third dimension corresponding to 538 the header processing per packet. This three dimensional space is 539 depicted in Figure 3. 541 state&signaling 542 per session 543 in router 544 ^ 545 | 546 | 547 .... 548 B | .... 549 . | .... 550 . | .... 551 . | .... 552 . +------------------..---> processing 553 . / .... C per packet 554 . / ..... in router 555 . / ..... 556 . / ..... 557 ./ ..... 558 /A.... 559 / 560 / 561 link bandwidth 563 Figure 3 565 One method of delivering identical information from a source to n 566 destinations is to unicast the information n times (A in Figure 3). 567 A second method, the traditional IP multicast model (B in Figure 3) 568 sends the information only once to a multicast address. In Xcast the 569 information is sent only once, but the packet contains a list of 570 destinations (point C). 572 The three points A, B and C define a plane (indicated with dots in 573 Figure 3): a plane of conservation of misery. All three approaches 574 have disadvantages. The link bandwidth is a scarce resource, 575 especially in access networks. State&signaling/session encounters 576 limitations when the number of sessions becomes large and an 577 increased processing/packet is cumbersome for high link speeds. 579 One advantage of Xcast is that it allows a router to move within this 580 plane of conservation of misery based upon its location in a network. 581 For example in the core of the network, a cache could be used to move 582 along the line from C to B without introducing any per-flow 583 signaling. Another possibility, as suggested above, is to use 584 premature X2U to move along the line from C to A in an access network 585 if there is an abundance of bandwidth in the backbone. 587 7. Xcast Control Plane Options 589 Unlike traditional IP multicast schemes, Xcast does not specify a 590 "control plane". There is no IGMP, and as mentioned above, there are 591 no intradomain or interdomain multicast routing protocols. With 592 Xcast, the means by which multicast sessions are defined is an 593 application level issue and applications are not confined to the 594 model in which hosts use IGMP to join a multicast session. For 595 example: 597 - some applications might want to use an IGMP-like receiver-join 598 model. 600 - other applications might want to use a model in which a user places 601 a call to the party or parties that he or she wants to talk to 602 (similar to the way that one puts together a conference call today 603 using the buttons on one's telephone). 605 - one might define a session based on the cells that are close to a 606 moving device in order to provide for a "smooth handoff" between 607 cells when the moving device crosses cell boundaries. 609 - in some applications the members of the session might be specified 610 as arguments on a command line. 612 - one might define an application that uses GPS to send video from a 613 bank robbery to the 3 police cars that are closest to the bank being 614 robbed. 616 Thus, the application developer is not limited to the receiver- 617 initiated joins of the IGMP model. There will be multiple ways in 618 which an Xcast sender determines the addresses of the members of the 619 channel. 621 For the purpose of establishing voice and multimedia conferences over 622 IP networks, several control planes have already been defined, 623 including SIP [2543] and H.323[H323]. 625 7.1. SIP Control Plane for Xcast 627 In SIP, a host takes the initiative to set up a session. With the 628 assistance of a SIP server a session is created. The session state 629 is kept in the hosts. Data delivery can be achieved by several 630 mechanisms: meshed unicast, bridged or multicast. Note that for the 631 establishment of multicast delivery, a multicast protocol and 632 communication with Multicast Address Allocation Servers (MAAS) are 633 still required. 635 In "meshed unicast" or "multi-unicasting", the application keeps 636 track of the participants' unicast addresses and sends a unicast to 637 each of those addresses. For reasons described in section 3, multi- 638 unicasting rather than multicast is the prevalent solution in use 639 today. It's a simple matter to replace multi-unicast code with Xcast 640 code. All that the developer has to do is replace a loop that sends a 641 unicast to each of the participants by a single "xcast_send" that 642 sends the data to the participants. Thus it's easy to incorporate 643 Xcast into real conferencing applications. 645 Both Xcast and SIP address super-sparse multicast sessions. It turns 646 out that Xcast (a very flexible data plane mechanism) can be easily 647 integrated with SIP (a very flexible control plane protocol). When 648 an application decides to use Xcast forwarding it does not affect its 649 interface to the SIP agent: it can use the same SIP messages as it 650 would for multi-unicasting. SIP could be used with Xcast to support 651 the conferencing model mentioned above in which a caller places a 652 call to several parties. 654 7.2 Receiver-Initiated Join for Xcast 656 In the previous section, it was discussed how to establish an Xcast 657 session among well known participants of a multi-party conference. In 658 some cases, it is useful for participants to be able to join a 659 session without being invited. For example, the chairman of a video 660 chat may want to leave the door of their meeting open for newcomers. 661 The IGMP-like receiver-initiated join model mentioned above can be 662 implemented by introducing a server that hosts can talk to, to join a 663 conference. 665 8. Optional information 667 8.1. List of ports 668 Although an extension to SIP could be arranged such that all 669 participants in a session use the same transport (UDP) port number, 670 in the general case it is possible for each participant to listen on 671 a different port number. To cover this case, the Xcast packet 672 optionally contains a list of port numbers. 674 If the list of port numbers is present, the destination port number 675 in the transport layer header will be set to zero. On X2U the 676 destination port number in the transport layer header will be set to 677 the port number corresponding to the destination of the unicast 678 packet. 680 8.2. List of DSCPs 682 The Xcast packet could (optionally) also contain a list of DiffServ 683 CodePoints (DSCPs). While traditional IP multicast protocols have to 684 create separate groups for each service class, Xcast incorporates the 685 possibility of having receivers with different service requirements 686 within one channel. 688 The DSCP in the IP header will be set to the most demanding DSCP of 689 the list of DSCPs. This DSCP in the IP header will determine e.g. 690 the scheduler to use. 692 If two destinations, with the same next-hop, have 'non-mergable' 693 DSCPs, two Xcast packets will be created. 'Non-mergable' meaning that 694 one can not say that one is more or less stringent than the other. 696 8.3. Channel Identifier 698 Optionally a sender can decide to add an extra number in the Xcast 699 header: the Channel Identifier. If the source does not want to use 700 this option it must set the Channel Identifier to zero. If the 701 Channel Identifier is non-zero the pair (Source Address, Channel 702 Identifier) must uniquely identify the channel (note that this is 703 similar to the (S, G) pair in SSM). This document does not assign 704 any other semantics to the Channel Identifier besides the one above. 706 This Channel Identifier could be useful for several purposes: 708 1) A key to a caching table [OOMS]. 710 2) "Harmonization" when used with Host Group Multicast (to be 711 discussed in greater detail in another document). 713 3) An identifier of the channel in error, flow control, etc. messages 715 4) It gives an extra de-multiplexing possibility (beside the port- 716 number) 718 5) ... 720 the size of the channel identifier and its semantics are TBD. 722 9. Possible Xcast Packet Encoding 724 9.1. General 726 The source address field of the IP header contains the address of the 727 Xcast sender. The destination address field carries the All-Xcast- 728 Routers address (to be assigned link-local multicast address), this 729 is to have a fixed value. Every Xcast router joins this multicast 730 group. The reasons for putting a fixed number in the destination 731 field are: 733 1) The destination address field is part of the IP pseudo header and 734 the latter is covered by transport layer checksums (e.g. UDP 735 checksum). So the fixed value avoids a (delta) recalculation of the 736 checksum. 738 2) The IPsec AH covers the IP header destination address hence 739 preventing any modification to that field. Also, both AH and ESP 740 payloads cover the whole UDP packet (via authentication and/or 741 encryption). The UDP checksum cannot therefore be updated if the IP 742 header destination address were to change. 744 3) In Xcast for IPv6 the Routing Extension shall be used, this header 745 extension is only checked by a router if the packet is destined to 746 this router. This is achieved by making all Xcast routers part of 747 the All_Xcast_Routers group. 749 4) Normally Xcast packets are only visible to Xcast routers. 750 However, if a non-Xcast router receives an Xcast packet by accident 751 (or by criminal intent), it will not send ICMP errors since the Xcast 752 packet carries a multicast address in the destination address field 753 ([1812]). 755 Note that some benefits only hold when the multicast address stays in 756 the destination field until it reaches the end-node (thus not 757 combinable with X2U). 759 9.2. IPv4 761 [AGUI] and [1770] proposed (for a slightly different purpose) to 762 carry multiple destinations in the IPv4 option. But because of the 763 limited flexibility (limited size of the header), Xcast will follow 764 another approach. The list of destinations will be encoded in a 765 separate header. The Xcast header for IPv4 (in short, Xcast4) would 766 be carried between the IPv4 header and the transport layer header. 768 [IPv4 header | Xcast4 | transport header | payload ] 770 Note also that since the Xcast header is added to the data portion of 771 the packet, if the sender wishes to avoid IP fragmentation, it must 772 take the size of the Xcast header into account. 774 9.2.1. IPv4 header 776 The Xcast4 header is carried on top of an IP header. The IP header 777 will carry the protocol number listed as usable for experimental 778 purposes in RFC [4727]. See also Section 15. The source address field 779 contains the address of the Xcast sender. The destination address 780 field carries the All_Xcast_Routers address. 782 9.2.2. Xcast4 header 784 The Xcast4 header is format depicted in Figure 4. It is composed of 785 two parts: a fixed part (first 12 octets) and two variable length 786 parts that are specified by the fixed part. 788 0 1 2 3 789 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 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 |VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | CHANNEL IDENTIFIER | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | PROT ID | LENGTH | RESV | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | List of Addresses and DSCPs | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | List of Port Numbers (optional) | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Figure 4 804 VERSION = Xcast version number. This document describes version 1. 806 A = Anonymity bit: if this bit is set the destination addresses for 807 which the corresponding bit in the bitmap is zero must be overwritten 808 by zero. 810 X = Xcast bit: if this bit is set a router must not reduce the Xcast 811 packet to unicast packet(s), i.e. the packet must stay an Xcast 812 packet end-to-end. This bit can be useful when IPsec is applied. If 813 this bit is cleared a router should apply X2U if there is only one 814 destination left in the Xcast packet. In some cases a router could 815 decide not to apply X2U to a packet with the Xcast bit cleared, e.g. 816 the router has no directly connected hosts and wants to avoid the 817 extra processing required by X2U. 819 D = DSCP bit: if this bit is set the packet will contain a DS-byte 820 for each destination. 822 P = Port bit: if this bit is set the packet will contain a port 823 number for each destination. 825 NBR_OF_DEST = the number of original destinations. 827 CHECKSUM = A checksum on the Xcast header only. This is verified and 828 recomputed at each point that the Xcast header is processed. The 829 checksum field is the 16 bit one's complement of the one's complement 830 sum of all the bytes in the header. For purposes of computing the 831 checksum, the value of the checksum field is zero. It is not clear 832 yet whether a checksum is needed (ffs). If only one destination is 833 wrong it can still be useful to forward the packet to N-1 correct 834 destinations and 1 incorrect destination. 836 CHANNEL IDENTIFIER = 4 octets Channel Identifier (see section 8.3). 837 Since it is located within the first 8 bytes of the header, it will 838 be returned in ICMP messages. 840 PROT ID = specifies the protocol of the following header. 842 LENGTH = length of the Xcast header in 4-octet words. This field 843 puts an upper boundary to the number of destinations. This value is 844 also determined by the NBR_OF_DEST field and the D and P bits. 846 RESV = R = Reserved. It must be zero on transmission and must be 847 ignored on receipt. 849 The first variable part is the 'List of Addresses and DSCPs', the 850 second variable part is the 'List of Port Numbers'. Both are 4-octet 851 aligned. The second variable part is only present if the P-bit is 852 set. 854 Figure 5 gives an example of the variable part for the case that the 855 P-bit is set and the D-bit is cleared (in this example N is odd): 857 0 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | BITMAP | 861 ~ ~ 862 | | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Destination 1 | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 ~ ... ~ 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Destination N | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Port 1 | Port 2 | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 ~ ... ~ 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Port N | padding | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 Figure 5 878 BITMAP = every destination has a corresponding bit in the bitmap to 879 indicate whether the destination is still valid on this branch of the 880 tree. The first bit corresponds to the first destination in the 881 list. This field is 4-octet aligned (e.g. for 49 destinations there 882 will be a 64-bit bitmap). If Xcast is applied in combination with 883 IPsec, the bitmap - since it can change on route - has to be moved to 884 a new to be defined IPv4 option. 886 List of Destinations. Each address size is four octets. 888 List of Port Numbers. List of two octet destination port number(s), 889 where each port corresponds in placement to the preceding Destination 890 Address. 892 9.3. IPv6 894 The Xcast6 header encoding is similar to IPv4, except that Xcast 895 information would be stored in IPv6 extension headers. 897 [IPv6 header | Xcast6 | transport header | payload ] 899 9.3.1. IPv6 header 901 The IPv6 header will carry the NextHeader value 'Routing Extension'. 902 The source address field contains the address of the Xcast sender. 903 The destination address field carries the All_Xcast_Routers address. 905 9.3.2. Xcast6 header 907 The Xcast6 header is also composed of a fixed and two variable parts. 908 The fixed and the first variable part is carried in a Routing 909 Extension. The second variable part is carried in a Destination 910 Extension. 912 9.3.2.1. Routing Extension header 914 The P-bit of Xcast4 is not present because it is implicit by the 915 presence or absence of the Destination Extension (Figure 6). 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Next Header | HdrExtLen |RouteType=Xcast| 0 | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 |VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | CHANNEL IDENTIFIER | 925 ~ ~ 926 | | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | List of Addresses and DSCPs | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 Figure 6 932 HdrExtLen = The header length is expressed in 8-octets, thus a 933 maximum of 127 destinations can be listed (this is why NBR_OF_DEST is 934 7-bit). 936 RouteType = Xcast (see Section 15) 938 The fourth octet is set to 0. 940 R = Reserved. 942 CHANNEL IDENTIFIER = 16 octets Channel Identifier (see section 8.3). 944 The other fields are defined in section 9.2.2. 946 The 'List of Addresses and DSCPs' is 8-octet aligned. The size of 947 the bitmap is determined by the number of destinations and is a 948 multiple of 64 bits. 950 9.3.2.2. Destination Extension header 952 Optionally the Destination Extension (Figure 7) is present to specify 953 the list of Port Numbers. The destination header is only evaluated 954 by the destination node. 956 0 1 2 3 957 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 958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 | Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | List of Port Numbers | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 Figure 7 965 For the Option Type for Ports, see Section 15. The first three bits 966 must be 010 to indicate that the packet must be discarded if the 967 option is unknown and that the option can not be changed en-route. 969 The number of Ports must be equal to the number of destinations 970 specified in the Routing header. 972 10. Impact on Upper Layer Protocols 974 Some fields in the Xcast header(s) can be modified as the packet 975 travels along its delivery path. This has an impact on: 977 10.1. Checksum calculation in transport layer headers 979 In transport layer headers, the target of the checksum calculation 980 includes the IP pseudo header, transport header and payload (IPv6 981 header extensions are not a target). 983 The transformation of an Xcast packet to a normal unicast packet - 984 (premature) X2U - replaces the multicast address in the IP header 985 destination field by the address of a final destination. If the 986 Xcast header contains a Port List, the port number in the transport 987 layer (which should be zero) also needs to be replaced by the port 988 number corresponding to the destination. This requires a 989 recalculation of these checksums. Note that this does not require a 990 complete recalculation of the checksum, only a delta calculation, 991 e.g. for IPv4: 993 Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp') 995 In which "'" indicates the new values, "da" the destination address, 996 "dp" the destination port and "H" and "L" respectively the higher and 997 lower 16 bit. 999 10.2. IPsec 1001 This is described in [PARI]. 1003 11. Gradual Deployment 1005 11.1. Tunneling 1007 One way to deploy Xcast in a network that has routers that have no 1008 knowledge of Xcast is to setup "tunnels" between Xcast peers (MBone 1009 approach). This enables the creation of a virtual network layered on 1010 top of an existing network [2003]. The Xcast routers exchange and 1011 maintain Xcast routing information via any standard unicast routing 1012 protocol (e.g. RIP, OSPF, ISIS, BGP). The Xcast routing table that is 1013 created is simply a standard unicast routing table that contains the 1014 destinations that have Xcast connectivity, along with their 1015 corresponding Xcast next hops. In this way, packets may be forwarded 1016 hop-by-hop to other Xcast routers, or may be "tunneled" through non- 1017 Xcast routers in the network. 1019 For example, suppose that A is trying to get packets distributed to 1020 B, C & D in Figure 8 below, where "X" routers are Xcast-capable, and 1021 "R" routers are not. Figure 9 shows the routing tables created via 1022 the Xcast tunnels: 1024 R4 ---- B 1025 / 1026 / 1027 A ----- X1 ---- R2 ---- X3 R8 ---- C 1028 \ / 1029 \ / 1030 R5 ---- R6 ---- X7 1031 \ 1032 \ 1033 R9 ---- D 1034 Figure 8 1036 Router X1 establishes a tunnel to Xcast peer X3. Router X3 1037 establishes a tunnel to Xcast peers X1 and X7. Router X7 establishes 1038 a tunnel to Xcast peer X3. 1040 X1 routing table: X3 routing table: X7 routing table: 1041 Dest | NextHop Dest | NextHop Dest | NextHop 1042 ------+---------- ------+--------- ------+--------- 1043 B | X3 A | X1 A | X3 1044 C | X3 C | X7 B | X3 1045 D | X3 D | X7 1047 Figure 9 1049 The source A will send an Xcast packet to its default Xcast router, 1050 X1, that includes the list of destinations for the packet. The packet 1051 on the link between X1 and X3 is depicted in Figure 10: 1053 +----------+ 1054 | payload | 1055 +----------+ 1056 | UDP | 1057 +----------+ 1058 | Xcast | 1059 | B,C,D | 1060 | prot=UDP | 1061 +----------+ 1062 | inner IP | 1063 | src=A | 1064 |dst=All_X_| 1065 |prot=Xcast| 1066 +----------+ 1067 | outer IP | 1068 | src=X1 | 1069 | dst=X3 | 1070 | prot=IP | 1071 +----------+ 1072 Figure 10 1074 When X3 receives this packet, it processes it as follows: 1076 - Perform a route table lookup in the Xcast routing table to 1077 determine the Xcast next hop for each of the destinations listed in 1078 the packet. 1080 - If no Xcast next hop is found, replicate the packet and send a 1081 standard unicast to the destination. 1083 - For those destinations for which an Xcast next hop is found, 1084 partition the destinations based on their next hops. 1086 - Replicate the packet so that there's one copy of the packet for 1087 each of the Xcast next hops found in the previous steps. 1089 - Modify the list of destinations in each of the copies so that the 1090 list in the copy for a given next hop includes just the destinations 1091 that ought to be routed through that next hop. 1093 - Send the modified copies of the packet on to the next hops. 1095 - Optimization: If there is only one destination for a particular 1096 Xcast next hop, send the packet as a standard unicast packet to the 1097 destination, since there is no advantage to forwarding it as an Xcast 1098 packet. 1100 So, in the example above, X1 will send a single packet on to X3 with 1101 a destination list of < B C D >. This packet will be received by R2 1102 as a unicast packet with destination X3, and R2 will forward it on, 1103 having no knowledge of Xcast. When X3 receives the packet, it will, 1104 by the algorithm above, send one copy of the packet to destination < 1105 B > as an ordinary unicast packet, and 1 copy of the packet to X7 1106 with a destination list of < C D >. R4, R5, and R6 will behave as 1107 standard routers with no knowledge of Xcast. When X7 receives the 1108 packet, it will parse the packet and transmit ordinary unicast 1109 packets addressed to < C > and < D > respectively. 1111 The updating of this route table while simple in an intra-domain 1112 environment would be more complex in an inter-domain environment. 1113 Thus the use of tunneling in an inter-domain environment requires 1114 further consideration. 1116 11.2. Premature X2U 1118 If a router discovers that its downstream neighbor is not Xcast 1119 capable, it can perform a Premature X2U, i.e. send a unicast packet 1120 for each destination in the Xcast header which has this neighbor as a 1121 next hop. Thus duplication is done before the Xcast packet reached 1122 its actual branching point. 1124 A mechanism (protocol/protocol extension) to discover the Xcast 1125 capability of a neighbor is ffs. Among others, one could think of an 1126 extension to a routing protocol to advertise Xcast capabilities or 1127 one could send periodic 'Xcast pings' to its neighbors (send an Xcast 1128 packet that contains its own address as a destination and check 1129 whether the packet returns). 1131 11.3. Semi-permeable tunneling (IPv6 only) 1133 This is an optimization of tunneling in the sense that it does not 1134 require (manual) configuration of tunnels. It is enabled by adding a 1135 Hop-by-Hop Xcast6 header. An IPv6 packet can initiate/trigger 1136 additional processing in the on-route routers by using the IPv6 Hop- 1137 by-hop option. 1139 The type of the Xcast6 Hop-by-hop option has a prefix '00' so that 1140 routers that cannot recognize Xcast6 can treat the Xcast6 datagram as 1141 a normal IPv6 datagram and forward toward the destination in the IPv6 1142 header. 1144 Packets will be delivered to all members if at least all 1145 participating hosts are upgraded. 1147 When the source A sends an Xcast packet via semi-permeable tunneling 1148 to destinations B, C and D it will create the packet of Figure 11. 1149 One of the final destinations will be put in the destination address 1150 field of the outer IP header. 1152 +----------+ 1153 | payload | 1154 +----------+ 1155 | UDP | 1156 +----------+ 1157 | Xcast | 1158 | | 1159 +----------+ 1160 | inner IP | 1161 | src=A | 1162 |dst=All_X_| 1163 |prot=Xcast| 1164 +----------+ 1165 | Xcast | 1166 |SP-tunnel | 1167 |Hop-by-hop| 1168 +----------+ 1169 | outer IP | 1170 | src=A | 1171 | dst=B | 1172 | prot=IP | 1173 +----------+ 1174 Figure 11 1176 Semi-permeable tunneling is a special tunneling technology that 1177 permits intermediate Xcast routers on a tunnel to check the 1178 destinations and branch if destinations have a different next hop. 1180 Note that with the introduction of an Xcast IPv4 option, this 1181 technique could also be applied in IPv4 networks. 1183 11.4. Special case: deployment without network support 1184 A special method of deploying Xcast is possible by upgrading only the 1185 hosts. By applying tunneling (see section 11.1 and 11.3) with one of 1186 the final destinations as tunnel endpoint, the Xcast packet will be 1187 delivered to all destinations when all the hosts are Xcast aware. 1188 Both normal and semi-permeable tunneling can be used. 1190 If host B receives this packet, in the above example, it will notice 1191 the other destinations in the Xcast header. B will create a new 1192 Xcast packet and will send it to one of the remaining destinations. 1194 In the case of Xcast6 and semi-permeable tunneling, Xcast routers can 1195 be introduced in the network without the need of configuring tunnels. 1197 The disadvantages of this method are that: 1199 - all hosts in the session need to be upgraded. 1201 - non-optimal routing. 1203 - anonymity issue: hosts can know the identity of other parties in 1204 the session (which is not a big issue in conferencing, but maybe for 1205 some other application?). 1207 - host has to perform network functions and needs an upstream link 1208 which has the same bandwidth as its downstream link. 1210 11.5 Using a Small Number of Xcast-Aware Routers to Provide Xcast in a 1211 Not-so-Small Network 1213 In this approach, an xcast packet uses a special 32-bit unicast 1214 address in the destination field of the IP header. In the simplest 1215 version of this scheme, there might be only a single xcast-aware 1216 router in a network. This xcast-aware router looks like a "server" to 1217 the other routers and it is configured so that its IP address (or one 1218 of its IP addresses) corresponds to the "special" 32-bit address. 1219 Thus when xcast clients send xcast packets, the non-xcast-aware 1220 routers will route these packets to the xcast-aware router and the 1221 xcast-aware router can "explode" (X2U) them into an appropriate set 1222 of unicast packets. This allows clients anywhere in a network to use 1223 xcast to overcome the problem of limited bandwidth in the "first 1224 mile" with a minimum number of xcast-aware routers (i.e. 1). 1226 Another possibility is to deploy a few of these xcast-aware routers 1227 at various points in the network and configure each of these with the 1228 special 32-bit address. This provides redundancy, eliminating the 1229 single point of failure, and reduces the distance an xcast packet 1230 needs to travel to reach an xcast-aware router, reducing network 1231 latencies. In this case, the xcast-aware routers appear to be a 1232 single server that is "multihomed" (i.e. connected to the network at 1233 more than one place) and the non-xcast-aware routers will, via 1234 ordinary unicast routing, deliver packets that are addressed to this 1235 "multihomed virtual server" via the shortest available path. 1237 (Note that this scheme of delivering packets to any host in a group 1238 is also known as an "anycast" and is described in more detail in 1239 RFC's 1546, 2526 and 3068. Note too that RFC 1546 says: 1241 The important observation is that multiple routes to an anycast 1242 address appear to a router as multiple routes to a unicast 1243 destination, and the router can use standard algorithms to 1244 choose the best route.) 1246 12. (Socket) API 1248 In the most simple use of Xcast, the final destinations of an Xcast 1249 packet receive an ordinary unicast UDP packet. This means that hosts 1250 can receive an Xcast packet with a standard, unmodified TCP/IP stack. 1252 Hosts can also transmit Xcast packets with a standard TCP/IP stack 1253 with a small Xcast library that sends Xcast packets on a raw socket. 1254 This has been used to implement Xcast based applications on both Unix 1255 and Windows platforms without any kernel changes. 1257 Another possibility is to modify the sockets interface slightly. For 1258 example, one might add an "xcast_sendto" function that works like 1259 "sendto" but that uses a list of destination addresses in place of 1260 the single address that "sendto" uses. 1262 13. Unresolved issues 1264 Additional work is needed in several areas. 1266 13.1 The format of the "list of addresses" 1268 Additional details need to be specified. For example, in the IPv4 1269 case, the format of the DSCPs option needs to be specified. 1271 13.2 The size of Channel Identifier 1273 The size of the channel identifiers in IPv4 and IPv6 are different in 1274 this document. 32 bits might be sufficient for both IPv6 and IPv4. 1276 13.3 Incremental Deployment 1278 Several possible methods of incremental deployment are discussed in 1279 this document including tunneling, premature X2U etc.. Additional 1280 work is needed to determine the best means of incremental deployment 1281 for an intra-domain as well as an inter-domain deployment of xcast. 1282 If tunneling is used, additional details need to be specified (e.g. 1283 tunneling format, use of tunnels in the inter-domain case.) 1285 13.4 DSCP usage 1287 DSCP usage needs some work. DSCP's may have to be rewritten as 1288 packets cross inter-domain boundaries. 1290 13.5 Traversing a firewall or NAT products 1292 The usage of a different carried protocol type for IPv4 may cause 1293 difficulty in traversing some firewall and NAT products. 1295 13.6 The size of BITMAP 1297 Given that this is designed for small groups, it might make sense to 1298 simply mandate a fixed size for the Bitmap. 1300 14. Security Considerations 1302 The list of destinations in Xcast is provided by an application layer 1303 that manages group membership as well as authorization if 1304 authorization is desired. 1306 Since a source has the list of destinations and can make changes to 1307 the list, it has more control over where its packets go than in 1308 traditional multicast and can prevent anonymous eavesdroppers from 1309 joining a multicast session for example. 1311 Some forms of denial-of-service attack can use Xcast to increase 1312 their "effect". A smurf attack for example sends an ICMP Echo 1313 Request in which the source address in the packet is set to the 1314 address of the target of the attack so that the target will receive 1315 the ICMP echo reply. With Xcast, the ICMP Echo Request could be sent 1316 to a list of destinations which could cause each member of the list 1317 to send an Echo Reply to the target. 1319 Measures have been taken in traditional multicast to avoid this kind 1320 of attack. A router or host can be configured so that it will not 1321 reply to ICMP requests addressed to a multicast address. The Reverse 1322 Path Forwarding check in traditional multicast architectures also 1323 helps limit these attacks. In Xcast, it can be difficult for a host 1324 to recognize that an ICMP request has been addressed to multiple 1325 destinations since the packet may be an ordinary unicast packet by 1326 the time it reaches the host. On the other hand, a router can detect 1327 Xcast packets that are used to send ICMP requests to multiple 1328 destinations and can be configured to drop those packets. Note too, 1329 that since Xcast sends packets to a short list of destinations, the 1330 problem of sending attack packets to multiple destination is less of 1331 a problem than in traditional multicast. Obviously, the use of IPsec 1332 to provide confidentiality and/or authentication can further diminish 1333 the risk of this type of attack. 1335 The problem of secure group communications has been addressed by the 1336 Multicast Security (msec) working group which has defined an 1337 architecture for securing IP-multicast-based group communications 1338 [3740]. Many of the concepts discussed in the msec working group 1339 such as managing group membership, identifying and authenticating 1340 group members, protecting the confidentiality and integrity of 1341 multicast traffic and managing and securely distributing and 1342 refreshing keys also apply to Xcast-based group communications. And 1343 many of the same mechanisms seem to apply. One significant 1344 difference between multicast and Xcast is the fact that the Xcast 1345 header (or at least a bitmap in the Xcast header) needs to change as 1346 an Xcast packet travels from a source to a destination. This affects 1347 the use of IPsec and suggests that at least the Xcast header bitmap 1348 must be in a "mutable" field. A complete solution for securing 1349 Xcast-based group communications addressing all the issues listed 1350 above will be the subject of additional work which will be discussed 1351 in one or more additional documents. We expect that this effort will 1352 build on the work that has already been done in the msec working 1353 group. 1355 15. IANA Considerations 1357 Experimentation with the Xcast protocol requires the use of protocol 1358 numbers maintained by IANA. For example, to implement XCAST6, 1359 implementations must agree on four protocol numbers: 1361 (1) Multicast Address for All_Xcast_Routers 1362 (2) Routing Type of IPv6 Routing Header 1363 (3) Option Type of IPv6 Destination Option Header 1364 (4) Option Type of IPv6 Hop-by-Hop Options Header 1366 A protocol implementer may temporarily experiment with Xcast by using 1367 the values set aside for experimental use in RFC[4727]. An 1368 implementer must verify that no other experiment uses the same values 1369 on the Xcast testbed at the same time. 1371 A future revision of the Xcast specification published on the 1372 standards track is required before IANA can assign permanent registry 1373 entries for Xcast. Implementors should be aware that they will need 1374 to modify their implementations when such permanent allocations are 1375 made. 1377 16. Informative References 1379 [1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 1380 August 1989. 1382 [1075] D. Waitzman, C. Partridge, S.E. Deering, Distance Vector Multi- 1383 cast Routing Protocol, RFC 1075, November 1988. 1385 [1770] C. Graff, "IPv4 Option for Sender Directed Multi-Destination 1386 Delivery", RFC1770, March 1995. 1388 [1812] F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 1389 1995. 1391 [2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1392 1996. 1394 [2201] A. Ballardie, Core Based Trees (CBT) Multicast Routing Architec- 1395 ture, RFC 2201, Sept. 1997. 1397 [2236] W. Fenner, Internet Group Management Protocol, Version 2, RFC 1398 2236, Nov. 1997. 1400 [2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 1401 Protocol", RFC2401, November 1998. 1403 [2460] S. Deering, R. Hinden. Internet Protocol, Version 6 (IPv6), 1404 RFC2460, December 1998. 1406 [2543] M. Handley, H. Schulzrinne, E. Schooler, J, Rosenberg, "SIP: 1407 Session Initiation Protocol", RFC2543, March 1999. 1409 [2902] S. Deering, S. Hares, C. Perkins, R. Perlman, "Overview of the 1410 1998 IAB Routing Workshop", RFC2902, August 2000. 1412 [AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting", Sig- 1413 comm84, March 1984. 1415 [CHER] David R. Cheriton , Stephen E. Deering, Host groups: a multicast 1416 extension for datagram internetworks, Proceedings of the ninth 1417 symposium on Data communications, p.172-179, September 1985, 1418 Whistler Moutain, British Columbia, Canada 1420 [BOIV] R. Boivie, N. Feldman, "Small Group Multicast", draft-boivie- 1421 sgm-01.txt, July 2000. 1423 [DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD 1424 thesis, December 1991. 1426 [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. 1427 Wei. The Pim Architecture for Wide-area Multicast Routing, ACM 1428 Transactions on Networks, April 1996 1430 [DOOR] B. Van Doorselaer, D. Ooms, "SIP for the establishment of xcast- 1431 based multiparty conferences", draft-van-doorselaer-sip- 1432 xcast-00.txt, July 2000. 1434 [FARI] D. Farinacci, "Multicast Source Discovery Protocol", draft-fari- 1435 nacci-msdp-00.txt, June 1998. 1437 [H323] ITU-T Recommendation H.323 (2000), Packet-Based Multimedia Com- 1438 munications Systems. 1440 [HOLB] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", draft- 1441 holbrook-ssm-00.txt, March 2000. 1443 [IMAI] Y. Imai, Multiple Destination option on IPv6 (MDO6), , September 2000 1446 [MBONE] Frequently Asked Questions (FAQ) on the Multicast Backbone 1447 (MBONE), ftp://venera.isi.edu/mbone/faq.txt 1449 [OOMS] D. Ooms, W. Livens, Connectionless Multicast, , April 2000 1452 [PARI] O. Paridaens, D. Ooms, Security Framework for Explicit Multi- 1453 cast, draft-paridaens-xcast-sec-framework-01.txt, November 2000. 1455 [PERL] R. Perlman, "Simple Multicast: A design for Simple, Low-overhead 1456 Multicast", draft-perlman-simple-multicast-02.txt, February 1457 1999. 1459 [RMT] Reliable Multicast Transport Working Group web site, 1460 http://www.ietf.org/html.charters/rmt-charter.html, June 15, 1461 1999 1463 [SOLA] M. Sola, M. Ohta, T. Maeno. Scalability of Internet Multicast 1464 Protocols, INET'98, http://www.isoc.org/inet98/proceed- 1465 ings/6d/6d_3.htm 1467 [BCP-2004] 1468 H. Hsu.et al., Best Current Practices of XCAST (Explicit Multi- 1469 Unicast) by 2004, http://www.ietf.org/internet-drafts/draft-hsu- 1470 xcast-bcp-2004-01.txt 1472 [2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA 1473 Considerations Section in RFCs", RFC 2434, October, 1998. 1475 [2119] Bradner, S., "Key words for use in RFCs to Indicate requirement 1476 Levels", BCP 14, RFC 2119, March 1997. 1478 [4727] B. Fenner, "Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, 1479 UDP, and TCP Headers", RFC 4727, November 2006. 1481 [3740] T. Hardjono, B. Weis, "The Multicast Group Security Architec- 1482 ture", RFC 3740, March 2004. 1484 17. Authors Addresses 1486 Rick Boivie 1487 IBM T. J. Watson Research Center 1488 19 Skyline Drive 1489 Hawthorne, NY 10532 1490 Phone: 914-784-3251 1491 Email: rhboivie@us.ibm.com 1493 Nancy Feldman 1494 IBM T. J. Watson Research Center 1495 19 Skyline Drive 1496 Hawthorne, NY 10532 1497 Email: nkfeldman@yahoo.com 1499 Yuji Imai 1500 Fujitsu LABORATORIES Ltd. 1501 1-1, Kamikodanaka 4-Chome, Nakahara-ku, Kawasaki 211-8588, Japan 1502 Phone : +81-44-754-2628 1503 Fax : +81-44-754-2793 1504 E-mail: ug@xcast.jp 1506 Wim Livens 1507 ESCAUX 1508 Krijtstraat 17, 2600 Berchem, Belgium. 1509 E-mail: wim@livens.net 1510 Dirk Ooms 1511 OneSparrow 1512 Belegstraat 13; 2018 Antwerp; Belgium 1513 E-mail: dirk@onesparrow.com 1515 Olivier Paridaens 1516 Alcatel Network Strategy Group 1517 Fr. Wellesplein 1, 2018 Antwerpen, Belgium. 1518 Phone : 32 3 2409320 1519 E-mail: Olivier.Paridaens@alcatel.be 1521 Eiichi Muramoto (editor) 1522 Matsushita Electric Industrial Co., Ltd. 1523 4-12-4 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8587, Japan 1524 Phone : +81-3-6710-2031 1525 E-mail: muramoto@xcast.jp 1527 18. Full Copyright Statement 1529 Copyright (C) The IETF Trust (2007). This document is subject 1530 to the rights, licenses and restrictions contained in BCP 78, and 1531 except as set forth therein, the authors retain all their rights. 1533 This document and the information contained herein 1534 are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1535 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 1536 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK 1537 FORCE DISCLAIM 1538 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1539 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1540 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1541 OR FITNESS FOR A PARTICULAR PURPOSE. 1543 19. IPR Notices 1545 The IETF takes no position regarding the validity or scope of any 1546 Intellectual Property Rights or other rights that might be claimed 1547 to pertain to the implementation or use of the technology 1548 described in this document or the extent to which any license 1549 under such rights might or might not be available; nor does it 1550 represent that it has made any independent effort to identify any 1551 such rights. Information on the procedures with respect to 1552 rights in RFC documents can be found in BCP 78 and BCP 79. 1554 Copies of IPR disclosures made to the IETF Secretariat and any 1555 assurances of licenses to be made available, or the result of an 1556 attempt made to obtain a general license or permission for the use 1557 of such proprietary rights by implementers or users of this 1558 specification can be obtained from the IETF on-line IPR repository 1559 at http://www.ietf.org/ipr. 1561 The IETF invites any interested party to bring to its attention 1562 any copyrights, patents or patent applications, or other 1563 proprietary rights that may cover technology that may be required 1564 to implement this standard. Please address the information to the 1565 IETF at ietf-ipr@ietf.org. 1567 Acknowledgement 1569 Funding for the RFC Editor function is currently provided by the 1570 Internet Society.