Network Working Group R. Boivie Request for Comments: 5058 N. Feldman Category: Experimental IBM Y. Imai WIDE / Fujitsu W. Livens ESCAUX D. Ooms OneSparrow November 2007 Explicit Multicast (Xcast) Concepts and Options Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. IESG Note This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
AbstractWhile traditional IP multicast schemes (RFC 1112) are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification.
1. Introduction ....................................................3 2. Xcast Overview ..................................................4 3. The Cost of the Traditional IP Multicast Schemes ................6 4. Motivation ......................................................9 5. Application ....................................................11 6. Xcast Flexibility ..............................................12 7. Xcast Control Plane Options ....................................13 7.1. SIP Control Plane for Xcast ...............................14 7.2. Receiver-Initiated Join for Xcast .........................14 8. Optional Information ...........................................15 8.1. List of Ports .............................................15 8.2. List of DSCPs .............................................15 8.3. Channel Identifier ........................................15 9. Possible Xcast Packet Encoding .................................16 9.1. General ...................................................16 9.2. IPv4 ......................................................17 9.2.1. IPv4 Header ........................................17 9.2.2. Xcast4 Header ......................................17 9.3. IPv6 ......................................................20 9.3.1. IPv6 Header ........................................20 9.3.2. Xcast6 Header ......................................20 126.96.36.199. Routing Extension Header ..................21 188.8.131.52. Destination Extension Header ..............21 10. Impact on Upper-Layer Protocols ...............................22 10.1. Checksum Calculation in Transport-Layer Headers ..........22 10.2. IPsec ....................................................22 11. Gradual Deployment ............................................23 11.1. Tunneling ................................................23 11.2. Premature X2U ............................................25 11.3. Semi-Permeable Tunneling (IPv6 Only) .....................25 11.4. Special Case: Deployment without Network Support .........26 11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast ............................................27 12. (Socket) API ..................................................28 13. Unresolved Issues .............................................28 13.1. The Format of the "List of Addresses" ....................28 13.2. The size of Channel Identifier ...........................28 13.3. Incremental Deployment ...................................28 13.4. DSCP usage ...............................................29 13.5. Traversing a Firewall or NAT Products ....................29 13.6. The Size of BITMAP .......................................29 14. Security Considerations .......................................29 15. IANA Considerations ...........................................30 16. Informative References ........................................31 17. Contributors ..................................................33
1112] are scalable for very large multicast groups, they have scalability issues with a very large number of distinct multicast groups. This document describes Xcast (Explicit Multi-unicast (Xcast)), a new multicast scheme with complementary scaling properties: Xcast supports a very large number of small multicast sessions. Xcast achieves this by explicitly encoding the list of destinations in the data packets, instead of using a multicast group address. This document discusses Xcast concepts and options in several areas; it does not provide a complete technical specification. Multicast, the ability to efficiently send data to a group of destinations, is becoming increasingly important for applications such as IP telephony and video-conferencing. Two kinds of multicast seem to be important: a broadcast-like multicast that sends data to a very large number of destinations, and a "narrowcast" multicast that sends data to a fairly small group [BOIV]. An example of the first is the audio and video multicasting of a presentation to all employees in a corporate intranet. An example of the second is a videoconference involving three or four parties. For reasons described below, it seems prudent to use different mechanisms for these two cases. As the Reliable Multicast Transport working group has stated: "it is believed that a 'one size fits all' protocol will be unable to meet the requirements of all applications" [RMT]. Note that the 1998 IAB Routing Workshop  came to the same conclusion: "For example, providing for many groups of small conferences (a small number of widely dispersed people) with global topological scope scales badly given the current multicast model". Today's multicast schemes can be used to minimize bandwidth consumption. Explicit Multi-Unicast (Xcast) also can be used to minimize bandwidth consumption for "small groups". But it has an additional advantage as well. Xcast eliminates the per-session signaling and per-session state information of traditional IP multicast schemes and this allows Xcast to support very large numbers of multicast sessions. This scalability is important since it enables important classes of applications such as IP telephony, videoconferencing, collaborative applications, networked games, etc., where there are typically very large numbers of small multicast groups. Interestingly, the idea for Xcast has been around for some time, although this was not immediately known to the three groups that independently re-invented it in the late 1990's. In fact the very
first proposal of the multicast concept in the Internet community, by Lorenzo Aguilar in his 1984 SIGCOMM paper [AGUI] proposed the use of an explicit list of destinations discussed in more detail below. At about the same time, David Cheriton and Stephen Deering developed Host Group Multicast in 1985 [CHER]. The Internet community compared the two proposals and concluded that a single mechanism was preferable to multiple mechanisms. Further, since Aguilar's proposal seemed to have serious scaling problems, the Host Group model was adopted. However, for reasons described below, we believe it makes sense to use different mechanisms for the two different kinds of multicast discussed above. While Host Group multicast may have been sufficient in the Internet of 1985, we believe that Xcast can be an important complement to Host Group multicast in the Internet of the 21st century. Figure 1 below:
R4 ---- B / / A----- R1 ---- R2 ---- R3 R8 ---- C \ / \ / R5 ---- R6 ---- R7 \ \ R9 ---- D Figure 1 This is accomplished as follows: A sends an Xcast packet with the list of destinations in its Xcast header to the first router, R1. Since the Xcast header will be slightly different for IPv4 and IPv6 , we won't reveal any details on the encoding of the Xcast header in this section (see Section 9). So, ignoring the details, the packet that A sends to R1 looks like this: [ src = A | dest = B C D | payload ] When R1 receives this packet, it needs to properly process the Xcast header. The processing that a router does on receiving one of these Xcast packets is as follows: - Perform a route table lookup to determine the next hop for each of the destinations listed in the packet. - Partition the set of destinations based on their next hops. - Replicate the packet so that there's one copy of the packet for each of the next hops found in the previous steps. - Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop. - Send the modified copies of the packet on to the next hops. - Optimization: If there is only one destination for a particular next hop, the packet can be sent as a standard unicast packet to the destination (X2U). So, in the example above, R1 will send a single packet on to R2 with a destination list of < B C D >, and R2 will send a single packet to R3 with the same destination list.
When R3 receives the packet, it will, by the algorithm above, send one copy of the packet to next hop R5 with an Xcast list of < C D >, and one ordinary unicast packet addressed to < B > to R4. R4 will receive a standard unicast packet and forward it on to < B >. R5 will forward the Xcast packet that it receives on to R6, which will pass it on to R7. When the packet reaches R7, R7 will transmit ordinary unicast packets addressed to < C > and < D >, respectively. R8 and R9 will receive standard unicast packets, and forward the packets on to < C > and < D >, respectively. It's important that the Xcast packet that is sent to a given next hop only includes destinations for which that next hop is the next hop listed in the route table. If the list of destinations in the packet sent to R4, for example, had also included C and D, R4 would send duplicate packets. Note that when routing topology changes, the routing for an Xcast channel will automatically adapt to the new topology since the path an Xcast packet takes to a given destination always follows the ordinary, unicast routing for that destination. DEER, DEE2, FARI] were designed to handle very large multicast groups. These work well if one is trying to distribute broadcast-like channels all around the world but they have scalability problems when there is a very large number of groups. The characteristics of the traditional IP multicast model are determined by its two components: the Host Group model [DEER] and a Multicast Routing Protocol. Both components make multicast very different from unicast. In the Host Group model, a group of hosts is identified by a multicast group address, which is used both for subscriptions and forwarding. This model has two main costs: - Multicast address allocation: The creator of a multicast group must allocate a multicast address that is unique in its scope (scope will often be global). This issue is being addressed by the MALLOC working group, which is proposing a set of Multicast Address Allocation Servers (MAAS) and three protocols (Multicast Address Set Claim (MASC), Address Allocation Protocol (AAP), Multicast Address Dynamic Client Allocation Protocol (MADCAP)).
- Destination unawareness: When a multicast packet arrives in a router, the router can determine the next hops for the packet, but knows nothing about the ultimate destinations of the packet, nor about how many times the packet will be duplicated later on in the network. This complicates the security, accounting and policy functions. In addition to the Host Group model, a routing algorithm is required to maintain the member state and the delivery tree. This can be done using a (truncated) broadcast algorithm or a multicast algorithm [DEER]. Since the former consumes too much bandwidth by unnecessarily forwarding packets to some routers, only the multicast algorithms are considered. These multicast routing protocols have the following costs: - Connection state: The multicast routing protocols exchange messages that create state for each (source, multicast group) in all the routers that are part of the point-to-multipoint tree. This can be viewed as "per flow" signaling that creates multicast connection state, possibly yielding huge multicast forwarding tables. Some of these schemes even disseminate this multicast routing information to places where it isn't necessarily needed . Other schemes try to limit the amount of multicast routing information that needs to be disseminated, processed, and stored throughout the network. These schemes (e.g., ) use a "shared distribution tree" that is shared by all the members of a multicast group and they try to limit the distribution of multicast routing information to just those nodes that "really need it". But these schemes also have problems. Because of the shared tree, they use less than optimal paths in routing packets to their destinations and they tend to concentrate traffic in small portions of a network. And these schemes still involve lots of "per flow" signaling and "per flow" state. - Source advertisement mechanism: Multicast routing protocols provide a mechanism by which members get 'connected' to the sources for a certain group without knowing the sources themselves. In sparse-mode protocols [2201, DEE2], this is achieved by having a core node, which needs to be advertised in the complete domain. On the other hand, in dense-mode protocols  this is achieved by a "flood and prune" mechanism. Both approaches raise additional scalability issues. - Inter-domain routing: Multicast routing protocols that rely on a core node [2201, DEE2] additionally need an inter-domain multicast routing protocol (e.g., [FARI]).
The cost of multicast address allocation, destination unawareness and the above scalability issues lead to a search for other multicast schemes. Source-Specific Multicast (SSM)  addresses some of the above drawbacks: in SSM, a host joins a specific source, thus the channel is identified by the couple (source address, multicast address). This approach avoids multicast address allocation as well as the need for an inter-domain routing protocol. The source advertisement is taken out of the multicast routing protocol and is moved to an out-of-band mechanism (e.g., web page). Note that SSM still creates state and signaling per multicast channel in each on-tree node. Figure 2 depicts the above costs as a function of the number of members in the session or channel. All the costs have a hyperbolic behavior. cost of the traditional IP multicast model per member ^ | costly| OK | <-----|-----> | . | | .. | | ..|.. | | ......... | | ........ +---------------------------> | number of members v alternative=Xcast Figure 2 The traditional IP multicast model becomes expensive for its members if the groups are small. Small groups are typical for conferencing, gaming, and collaborative applications. These applications are well- served by Xcast. In practice, traditional IP multicast routing protocols impose limitations on the number of groups and the size of the network in which they are deployed. For Xcast, these limitations do not exist.
SOLA]. This makes Xcast very scalable in terms of the number of sessions that can be supported since the nodes in the network do not need to disseminate or store any multicast routing information for these sessions. 2) No multicast address allocation required. 3) No need for multicast routing protocols (neither intra- nor inter-domain). Xcast packets always take the "right" path as determined by the ordinary unicast routing protocols. 4) No core node, so no single point of failure. Unlike the shared tree schemes, Xcast minimizes network latency and maximizes network "efficiency". 5) Symmetric paths are not required. Traditional IP multicast routing protocols create non-shortest-path trees if paths are not symmetric. (A path between two nodes A and B is symmetric if the path is both the shortest path from A to B as well as the shortest path from B to A.) It is expected that an increasing number of paths in the Internet will be asymmetric in the future as a result of traffic engineering and policy routing, and thus the traditional IP multicast schemes will result in an increasing amount of suboptimal routing.
6) Automatic reaction to unicast reroutes. Xcast will react immediately to unicast route changes. In traditional IP multicast routing protocols, a communication between the unicast and the multicast routing protocol needs to be established. In many implementations, this is on a polling basis, yielding a slower reaction to, e.g., link failures. It may also take some time for traditional IP multicast routing protocols to fix things up if there is a large number of groups that need to be fixed. 7) Easy security and accounting. In contrast with the Host Group Model, in Xcast all the sources know the members of the multicast channel, which gives the sources the means to, e.g., reject certain members or count the traffic going to certain members quite easily. Not only a source, but also a border router is able to determine how many times a packet will be duplicated in its domain. It also becomes easier to restrict the number of senders or the bandwidth per sender. 8) Heterogeneous receivers. Besides the list of destinations, the packet could (optionally) also contain a list of Diffserv Code Points (DSCPs). While traditional IP multicast protocols have to create separate groups for each service class, Xcast incorporates the possibility of having receivers with different service requirements within one multicast channel. 9) Xcast packets can make use of traffic-engineered unicast paths. 10) Simple implementation of reliable protocols on top of Xcast, because Xcast can easily address a subset of the original list of destinations to do a retransmission. 11) Flexibility (see Section 6). 12) Easy transition mechanisms (see Section 11). It should be noted that Xcast has a number of disadvantages as well: 1) Overhead. Each packet contains all remaining destinations. But, the total amount of data is still much less than for unicast (payload is only sent once). A method to compress the list of destination addresses might be useful. 2) More complex header processing. Each destination in the packet needs a routing table lookup. So, an Xcast packet with n destinations requires the same number of routing table lookups as n unicast headers. Additionally, a different header has to be constructed per next hop. Note however that:
a) Since Xcast will typically be used for super-sparse sessions, there will be a limited number of branching points, compared to non-branching points. Only in a branching point do new headers need to be constructed. b) The header construction can be reduced to a very simple operation: overwriting a bitmap. c) Among the non-branching points, a lot of them will contain only one destination. In these cases, normal unicast forwarding can be applied. d) By using a hierarchical encoding of the list of destinations in combination with the aggregation in the forwarding tables the forwarding can be accelerated [OOMS]. e) When the packet enters a region of the network where link bandwidth is not an issue anymore, the packet can be transformed by a Premature X2U. Premature X2U (see Section 11.2) occurs when a router decides to transform the Xcast packet for one or more destinations into unicast packets. This avoids more complex processing downstream. f) Other mechanisms to reduce the processing have been described in [IMAI] (tractable list) and [OOMS] (caching), but are not (yet) part of the Xcast specification. 3) Xcast only works with a limited number of receivers.
video channels, but the host is not able to send its own video data n-1 times at this rate. Because of the limited and often asymmetric access capacity, some type of multicast is mandatory. A simple but important application of Xcast lies in bridging the access link. The host sends the Xcast packet with the list of unicast addresses and the first router performs a Premature X2U. Since Xcast is not suitable for large groups, Xcast will not replace the traditional IP multicast model, but it does offer an alternative for multipoint-to-multipoint communications when there can be very large numbers of small sessions. Figure 3. state&signaling per session in router ^ | | .... B | .... . | .... . | .... . | .... . +------------------..---> processing . / .... C per packet . / ..... in router . / ..... . / ..... ./ ..... /A.... / / link bandwidth Figure 3
One method of delivering identical information from a source to n destinations is to unicast the information n times (A in Figure 3). A second method, the traditional IP multicast model (B in Figure 3), sends the information only once to a multicast address. In Xcast, the information is sent only once, but the packet contains a list of destinations (point C). The three points A, B, and C define a plane (indicated with dots in Figure 3): a plane of conservation of misery. All three approaches have disadvantages. The link bandwidth is a scarce resource, especially in access networks. State&signaling/session encounters limitations when the number of sessions becomes large, and an increased processing/packet is cumbersome for high-link speeds. One advantage of Xcast is that it allows a router to move within this plane of conservation of misery based upon its location in a network. For example, in the core of the network, a cache could be used to move along the line from C to B without introducing any per-flow signaling. Another possibility, as suggested above, is to use premature X2U to move along the line from C to A in an access network if there is an abundance of bandwidth in the backbone. 3376]), and as mentioned above, there are no intra- or inter- domain multicast routing protocols. With Xcast, the means by which multicast sessions are defined is an application-level issue and applications are not confined to the model in which hosts use IGMP to join a multicast session. For example: - Some applications might want to use an IGMP-like receiver-join model. - Other applications might want to use a model in which a user places a call to the party or parties that he or she wants to talk to (similar to the way that one puts together a conference call today using the buttons on one's telephone). - One might define a session based on the cells that are close to a moving device in order to provide for a "smooth handoff" between cells when the moving device crosses cell boundaries. - In some applications, the members of the session might be specified as arguments on a command line.
- One might define an application that uses GPS to send video from a bank robbery to the three police cars that are closest to the bank being robbed. Thus, the application developer is not limited to the receiver- initiated joins of the IGMP model. There will be multiple ways in which an Xcast sender determines the addresses of the members of the channel. For the purpose of establishing voice and multimedia conferences over IP networks, several control planes have already been defined, including SIP  and H.323 [H323]. Section 3, multi- unicasting (rather than multicast) is the prevalent solution in use today. It's a simple matter to replace multi-unicast code with Xcast code. All that the developer has to do is replace a loop that sends a unicast to each of the participants by a single "xcast_send" that sends the data to the participants. Thus it's easy to incorporate Xcast into real conferencing applications. Both Xcast and SIP address super-sparse multicast sessions. It turns out that Xcast (a very flexible data plane mechanism) can be easily integrated with SIP (a very flexible control plane protocol). When an application decides to use Xcast forwarding it does not affect its interface to the SIP agent: it can use the same SIP messages as it would for multi-unicasting. SIP could be used with Xcast to support the conferencing model mentioned above in which a caller places a call to several parties.
chat may want to leave the door of their meeting open for newcomers. The IGMP-like receiver-initiated join model mentioned above can be implemented by introducing a server that hosts can talk to, to join a conference.
This Channel Identifier could be useful for several purposes: 1) A key to a caching table [OOMS]. 2) "Harmonization" when used with Host Group Multicast (to be discussed in greater detail in another document). 3) An identifier of the channel in error, flow control, etc., messages. 4) It gives an extra demultiplexing possibility (beside the port- number). 5) ... The size of the channel identifier and its semantics are TBD. 4302] covers the IP header destination address, hence preventing any modification to that field. Also, both AHs and Encapsulating Security Payloads (ESPs) cover the whole UDP packet (via authentication and/or encryption). The UDP checksum cannot therefore be updated if the IP header destination address were to change. 3) In Xcast for IPv6, the Routing Extension shall be used; this header extension is only checked by a router if the packet is destined to this router. This is achieved by making all Xcast routers part of the All_Xcast_Routers group.
4) Normally Xcast packets are only visible to Xcast routers. However, if a non-Xcast router receives an Xcast packet by accident (or by criminal intent), it will not send ICMP errors since the Xcast packet carries a multicast address in the destination address field . Note that some benefits only hold when the multicast address stays in the destination field until it reaches the end-node (thus not combinable with X2U). AGUI] and  proposed (for a slightly different purpose) to carry multiple destinations in the IPv4 option. But because of the limited flexibility (limited size of the header), Xcast will follow another approach. The list of destinations will be encoded in a separate header. The Xcast header for IPv4 (in short, Xcast4) would be carried between the IPv4 header and the transport-layer header. [IPv4 header | Xcast4 | transport header | payload ] Note also that since the Xcast header is added to the data portion of the packet, if the sender wishes to avoid IP fragmentation, it must take the size of the Xcast header into account. RFC 4727 . See also Section 15. The source address field contains the address of the Xcast sender. The destination address field carries the All_Xcast_Routers address. Figure 4. It is composed of two parts: a fixed part (first 12 octets) and two variable-length parts that are specified by the fixed part.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D|P|R| NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PROT ID | LENGTH | RESV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Port Numbers (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 VERSION = Xcast version number. This document describes version 1. A = Anonymity bit: if this bit is set, the destination addresses for which the corresponding bit in the bitmap is zero must be overwritten by zero. X = Xcast bit: if this bit is set, a router must not reduce the Xcast packet to unicast packet(s), i.e., the packet must stay an Xcast packet end-to-end. This bit can be useful when IPsec  is applied. If this bit is cleared a router should apply X2U if there is only one destination left in the Xcast packet. In some cases a router could decide not to apply X2U to a packet with the Xcast bit cleared, e.g., the router has no directly connected hosts and wants to avoid the extra processing required by X2U. D = DSCP bit: if this bit is set, the packet will contain a DS byte for each destination. P = Port bit: if this bit is set, the packet will contain a port number for each destination. NBR_OF_DEST = the number of original destinations. CHECKSUM = A checksum on the Xcast header only. This is verified and recomputed at each point that the Xcast header is processed. The checksum field is the 16-bit one's complement of the one's complement sum of all the bytes in the header. For purposes of computing the checksum, the value of the checksum field is zero. It is not clear yet whether a checksum is needed (for further study). If only one destination is wrong it can still be useful to forward the packet to N-1 correct destinations and 1 incorrect destination.
CHANNEL IDENTIFIER = 4-octet Channel Identifier (see Section 8.3). Since it is located within the first 8 bytes of the header, it will be returned in ICMP messages. PROT ID = specifies the protocol of the following header. LENGTH = length of the Xcast header in 4-octet words. This field puts an upper boundary to the number of destinations. This value is also determined by the NBR_OF_DEST field and the D and P bits. RESV = R = Reserved. It must be zero on transmission and must be ignored on receipt. The first variable part is the 'List of Addresses and DSCPs', the second variable part is the 'List of Port Numbers'. Both are 4-octet aligned. The second variable part is only present if the P-bit is set. Figure 5 gives an example of the variable part for the case that the P-bit is set and the D-bit is cleared (in this example, N is odd): 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BITMAP | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port 1 | Port 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port N | padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5
BITMAP = every destination has a corresponding bit in the bitmap to indicate whether the destination is still valid on this branch of the tree. The first bit corresponds to the first destination in the list. This field is 4-octet aligned (e.g., for 49 destinations, there will be a 64-bit bitmap). If Xcast is applied in combination with IPsec, the bitmap -- since it can change en route -- has to be moved to a new to-be-defined IPv4 option. List of Destinations. Each address size is 4 octets. List of Port Numbers. List of 2-octet destination port number(s), where each port corresponds in placement to the preceding Destination Address.
Figure 6). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen |RouteType=Xcast| 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VERSION|A|X|D| R | NBR_OF_DEST | CHECKSUM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CHANNEL IDENTIFIER | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Addresses and DSCPs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 HdrExtLen = The header length is expressed in 8-octets; thus, a maximum of 127 destinations can be listed (this is why NBR_OF_DEST is 7 bits). RouteType = Xcast (see Section 15) The fourth octet is set to 0. R = Reserved. CHANNEL IDENTIFIER = 16-octet Channel Identifier (see Section 8.3). The other fields are defined in Section 9.2.2. The 'List of Addresses and DSCPs' is 8-octet aligned. The size of the bitmap is determined by the number of destinations and is a multiple of 64 bits. Figure 7) is present to specify the list of Port Numbers. The destination header is only evaluated by the destination node.
0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | HdrExtLen |Opt Type=Ports | Opt Data Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of Port Numbers | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7 For the Option Type for Ports, see Section 15. The first three bits must be 010 to indicate that the packet must be discarded if the option is unknown and that the option cannot be changed en-route. The number of Ports must be equal to the number of destinations specified in the Routing header. PARI].
MBONE]). This enables the creation of a virtual network layered on top of an existing network . The Xcast routers exchange and maintain Xcast routing information via any standard unicast routing protocol (e.g., RIP, OSPF, IS-IS, BGP). The Xcast routing table that is created is simply a standard unicast routing table that contains the destinations that have Xcast connectivity, along with their corresponding Xcast next hops. In this way, packets may be forwarded hop-by-hop to other Xcast routers, or may be "tunneled" through non- Xcast routers in the network. For example, suppose that A is trying to get packets distributed to B, C, and D in Figure 8 below, where "X" routers are Xcast-capable, and "R" routers are not. Figure 9 shows the routing tables created via the Xcast tunnels: R4 ---- B / / A ----- X1 ---- R2 ---- X3 R8 ---- C \ / \ / R5 ---- R6 ---- X7 \ \ R9 ---- D Figure 8 Router X1 establishes a tunnel to Xcast peer X3. Router X3 establishes a tunnel to Xcast peers X1 and X7. Router X7 establishes a tunnel to Xcast peer X3. X1 routing table: X3 routing table: X7 routing table: Dest | NextHop Dest | NextHop Dest | NextHop ------+---------- ------+--------- ------+--------- B | X3 A | X1 A | X3 C | X3 C | X7 B | X3 D | X3 D | X7 Figure 9
The source A will send an Xcast packet to its default Xcast router, X1, that includes the list of destinations for the packet. The packet on the link between X1 and X3 is depicted in Figure 10: +----------+ | payload | +----------+ | UDP | +----------+ | Xcast | | B,C,D | | prot=UDP | +----------+ | inner IP | | src=A | |dst=All_X_| |prot=Xcast| +----------+ | outer IP | | src=X1 | | dst=X3 | | prot=IP | +----------+ Figure 10 When X3 receives this packet, it processes it as follows: - Perform a route table lookup in the Xcast routing table to determine the Xcast next hop for each of the destinations listed in the packet. - If no Xcast next hop is found, replicate the packet and send a standard unicast to the destination. - For those destinations for which an Xcast next hop is found, partition the destinations based on their next hops. - Replicate the packet so that there's one copy of the packet for each of the Xcast next hops found in the previous steps. - Modify the list of destinations in each of the copies so that the list in the copy for a given next hop includes just the destinations that ought to be routed through that next hop. - Send the modified copies of the packet on to the next hops.
- Optimization: If there is only one destination for a particular Xcast next hop, send the packet as a standard unicast packet to the destination, since there is no advantage to forwarding it as an Xcast packet. So, in the example above, X1 will send a single packet on to X3 with a destination list of < B C D >. This packet will be received by R2 as a unicast packet with destination X3, and R2 will forward it on, having no knowledge of Xcast. When X3 receives the packet, it will, by the algorithm above, send one copy of the packet to destination < B > as an ordinary unicast packet, and 1 copy of the packet to X7 with a destination list of < C D >. R4, R5, and R6 will behave as standard routers with no knowledge of Xcast. When X7 receives the packet, it will parse the packet and transmit ordinary unicast packets addressed to < C > and < D >, respectively. The updating of this route table, while simple in an intra-domain environment, would be more complex in an inter-domain environment. Thus, the use of tunneling in an inter-domain environment requires further consideration.
Packets will be delivered to all members if at least all participating hosts are upgraded. When the source A sends an Xcast packet via semi-permeable tunneling to destinations B, C, and D, it will create the packet of Figure 11. One of the final destinations will be put in the destination address field of the outer IP header. +----------+ | payload | +----------+ | UDP | +----------+ | Xcast | | | +----------+ | inner IP | | src=A | |dst=All_X_| |prot=Xcast| +----------+ | Xcast | |SP-tunnel | |Hop-by-hop| +----------+ | outer IP | | src=A | | dst=B | | prot=IP | +----------+ Figure 11 Semi-permeable tunneling is a special tunneling technology that permits intermediate Xcast routers on a tunnel to check the destinations and branch if destinations have a different next hop. Note that with the introduction of an Xcast IPv4 option, this technique could also be applied in IPv4 networks. Sections 11.1 and 11.3) with one of the final destinations as a tunnel endpoint, the Xcast packet will be delivered to all destinations when all the hosts are Xcast aware. Both normal and semi-permeable tunneling can be used.
If host B receives this packet, in the above example, it will notice the other destinations in the Xcast header. B will create a new Xcast packet and will send it to one of the remaining destinations. In the case of Xcast6 and semi-permeable tunneling, Xcast routers can be introduced in the network without the need of configuring tunnels. The disadvantages of this method are: - all hosts in the session need to be upgraded. - non-optimal routing. - anonymity issue: hosts can know the identity of other parties in the session (which is not a big issue in conferencing, but maybe for some other application). - host has to perform network functions and needs an upstream link which has the same bandwidth as its downstream link.
Note that this scheme of delivering packets to any host in a group is also known as an "anycast" and is described in more detail in RFCs , , and . Note too that RFC 1546 says: The important observation is that multiple routes to an anycast address appear to a router as multiple routes to a unicast destination, and the router can use standard algorithms to choose the best route.
a problem than in traditional multicast. Obviously, the use of IPsec to provide confidentiality and/or authentication can further diminish the risk of this type of attack. The problem of secure group communications has been addressed by the Multicast Security (MSEC) working group, which has defined an architecture for securing IP-multicast-based group communications . Many of the concepts discussed in the MSEC working group, such as managing group membership, identifying and authenticating group members, protecting the confidentiality and integrity of multicast traffic, and managing and securely distributing and refreshing keys, also apply to Xcast-based group communications. And many of the same mechanisms seem to apply. One significant difference between multicast and Xcast is the fact that the Xcast header (or at least a bitmap in the Xcast header) needs to change as an Xcast packet travels from a source to a destination. This affects the use of IPsec and suggests that at least the Xcast header bitmap must be in a "mutable" field. A complete solution for securing Xcast-based group communications addressing all the issues listed above will be the subject of additional work which will be discussed in one or more additional documents. We expect that this effort will build on the work that has already been done in the msec working group. 4727]. An implementer must verify that no other experiment uses the same values on the Xcast testbed at the same time. A future revision of the Xcast specification published on the standards track is required before IANA can assign permanent registry entries for Xcast. Implementers should be aware that they will need to modify their implementations when such permanent allocations are made.
 Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.  Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.  Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.  Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.  Graff, C., "IPv4 Option for Sender Directed Multi-Destination Delivery", RFC 1770, March 1995.  Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.  Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.  Ballardie, A., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.  Deering, S., Hares, S., Perkins, C., and R. Perlman, "Overview of the 1998 IAB Routing Workshop", RFC 2902, August 2000.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.  Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
 Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.  Kent, S., "IP Authentication Header", RFC 4302, December 2005.  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. [AGUI] L. Aguilar, "Datagram Routing for Internet Multicasting", SIGCOMM '84, March 1984. [CHER] David R. Cheriton, Stephen E. Deering, "Host groups: a multicast extension for datagram internetworks", Proceedings of the ninth symposium on Data communications, p. 172-179, September 1985, Whistler Moutain, British Columbia, Canada. [BOIV] Boivie, R. and N. Feldman, "Small Group Multicast", Work in Progress, February 2001. [DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD thesis, December 1991. [DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L. Wei, "The Pim Architecture for Wide-area Multicast Routing", ACM Transactions on Networks, April 1996. [FARI] Farinacci, D., et al., "Multicast Source Discovery Protocol", Work in Progress, June 1998. [H323] ITU-T Recommendation H.323 (2000), Packet-Based Multimedia Communications Systems. [IMAI] Imai, Y., "Multiple Destination option on IPv6 (MDO6)", Work in Progress, September 2000, [MBONE] Casner, S., "Frequently Asked Questions (FAQ) on the Multicast Backbone (MBONE)", <ftp://ftp.isi.edu/mbone/faq.txt>. [OOMS] Ooms, D., Livens, W., and O. Paridaens, "Connectionless Multicast", Work in Progress, April 2000. [PARI] Paridaens, O., Ooms, D., and B. Sales, "Security Framework for Explicit Multicast", Work in Progress, June 2002.
[RMT] Reliable Multicast Transport Working Group web site, <http://www.ietf.org/html.charters/rmt-charter.html>, June 15, 1999. [SOLA] M. Sola, M. Ohta, T. Maeno, "Scalability of Internet Multicast Protocols", INET'98, <http://www.isoc.org/inet98/proceedings/6d/6d_3.htm>.
Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.