diff options
Diffstat (limited to 'doc/rfc/rfc5058.txt')
| -rw-r--r-- | doc/rfc/rfc5058.txt | 1963 |
1 files changed, 1963 insertions, 0 deletions
diff --git a/doc/rfc/rfc5058.txt b/doc/rfc/rfc5058.txt new file mode 100644 index 0000000..6bf1595 --- /dev/null +++ b/doc/rfc/rfc5058.txt @@ -0,0 +1,1963 @@ + + + + + + +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. + +Abstract + + While 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. + + + + + + +Boivie, et al. Experimental [Page 1] + +RFC 5058 Xcast Concepts and Options November 2007 + + +Table of Contents + + 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 + 9.3.2.1. Routing Extension Header ..................21 + 9.3.2.2. 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 + + + + +Boivie, et al. Experimental [Page 2] + +RFC 5058 Xcast Concepts and Options November 2007 + + +1. Introduction + + While traditional IP multicast schemes [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 [2902] + 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 + + + +Boivie, et al. Experimental [Page 3] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +2. Xcast Overview + + In this document, the following terminology will be used: + + - Session: in Xcast, the term 'multicast session' will be used + instead of 'multicast group' to avoid the strong association of + multicast groups with multicast group addresses in traditional IP + multicast. + + - Channel: in a session with multiple senders (e.g., a video + conference), the flow sourced by one sender will be called a + channel. So, a session can contain one or more channels. + + In the Host Group Model, the packet carries a multicast address as a + logical identifier of all group members. In Xcast, the source node + keeps track of the destinations in the multicast channel that it + wants to send packets to. + + The source encodes the list of destinations in the Xcast header, and + then sends the packet to a router. Each router along the way parses + the header, partitions the destinations based on each destination's + next hop, and forwards a packet with an appropriate Xcast header to + each of the next hops. + + When there is only one destination left, the Xcast packet can be + converted into a normal unicast packet, which can be unicasted along + the remainder of the route. This is called X2U (Xcast to Unicast). + + For example, suppose that A is trying to get packets distributed to + B, C, and D in Figure 1 below: + + + +Boivie, et al. Experimental [Page 4] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 + [2460], 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. + + + +Boivie, et al. Experimental [Page 5] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +3. The Cost of the Traditional IP Multicast Schemes + + Traditional IP multicast schemes [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)). + + + + + + +Boivie, et al. Experimental [Page 6] + +RFC 5058 Xcast Concepts and Options November 2007 + + + - 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 [1075]. 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., [2201]) 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 + [1075] 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]). + + + + +Boivie, et al. Experimental [Page 7] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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) [4607] 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. + + + + + + + + + + +Boivie, et al. Experimental [Page 8] + +RFC 5058 Xcast Concepts and Options November 2007 + + +4. Motivation + + Xcast takes advantage of one of the fundamental tenets of the + Internet "philosophy", namely, that one should move complexity to the + edges of the network and keep the middle of the network simple. This + is the principle that guided the design of IP and TCP and it's the + principle that has made the incredible growth of the Internet + possible. For example, one reason that the Internet has been able to + scale so well is that the routers in the core of the network deal + with large Classless Inter-Domain Routing (CIDR) blocks as opposed to + individual hosts or individual "connections". The routers in the + core don't need to keep track of the individual TCP connections that + are passing through them. Similarly, the IETF's Diffserv effort is + based on the idea that the routers shouldn't have to keep track of a + large number of individual Resource Reservation Protocol (RSVP) flows + that might be passing through them. It's the authors' belief that + the routers in the core shouldn't have to keep track of a large + number of individual multicast flows, either. + + Compared to traditional IP multicast, Xcast has the following + advantages: + + 1) Routers do not have to maintain state per session (or per channel) + [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. + + + + +Boivie, et al. Experimental [Page 9] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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: + + + + +Boivie, et al. Experimental [Page 10] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +5. Application + + While Xcast is not suitable for multicast sessions with a large + number of members, such as the broadcast of an IETF meeting, it does + provide an important complement to existing multicast schemes in that + it can support very large numbers of small sessions. Thus, Xcast + enables important applications such as IP telephony, + videoconferencing, multi-player games, collaborative e-meetings, etc. + The number of these sessions will become huge. + + Some may argue that it is not worthwhile to use multicast for + sessions with a limited number of members, and that it's preferable + to use unicast instead. But in certain cases, limited bandwidth in + the "last mile" makes it important to have some form of multicast, as + the following example illustrates. Assume n residential users set up + a video conference. Typically, access technologies are asymmetric + (e.g., xDSL, General Packet Radio Service (GPRS), or cable modem). + So, a host with xDSL has no problem receiving n-1 basic 100 kb/s + + + + +Boivie, et al. Experimental [Page 11] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +6. Xcast Flexibility + + The main goal of multicast is to avoid duplicate information flowing + over the same link. By using traditional IP multicast instead of + unicast, bandwidth consumption decreases while the state and + signaling per session increases. Xcast has a cost of 0 in these two + dimensions, but it does introduce a third dimension corresponding to + the header processing per packet. This three-dimensional space is + depicted in Figure 3. + + state&signaling + per session + in router + ^ + | + | + .... + B | .... + . | .... + . | .... + . | .... + . +------------------..---> processing + . / .... C per packet + . / ..... in router + . / ..... + . / ..... + ./ ..... + /A.... + / + / + link bandwidth + + Figure 3 + + + + + +Boivie, et al. Experimental [Page 12] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +7. Xcast Control Plane Options + + Unlike traditional IP multicast schemes, Xcast does not specify a + "control plane". There is no Internet Group Management Protocol + (IGMP [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. + + + + + +Boivie, et al. Experimental [Page 13] + +RFC 5058 Xcast Concepts and Options November 2007 + + + - 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 [3261] and H.323 [H323]. + +7.1. SIP Control Plane for Xcast + + In SIP, a host takes the initiative to set up a session. With the + assistance of a SIP server, a session is created. The session state + is kept in the hosts. Data delivery can be achieved by several + mechanisms: meshed unicast, bridged, or multicast. Note that for the + establishment of multicast delivery, a multicast protocol and + communication with Multicast Address Allocation Servers (MAAS) are + still required. + + In "meshed unicast" or "multi-unicasting", the application keeps + track of the participants' unicast addresses and sends a unicast to + each of those addresses. For reasons described in 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. + +7.2. Receiver-Initiated Join for Xcast + + In the previous section, it was discussed how to establish an Xcast + session among well known participants of a multi-party conference. + In some cases, it is useful for participants to be able to join a + session without being invited. For example, the chairman of a video + + + +Boivie, et al. Experimental [Page 14] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +8. Optional Information + +8.1. List of Ports + + Although an extension to SIP could be arranged such that all + participants in a session use the same transport (UDP) port number, + in the general case, it is possible for each participant to listen on + a different port number. To cover this case, the Xcast packet + optionally contains a list of port numbers. + + If the list of port numbers is present, the destination port number + in the transport-layer header will be set to zero. On X2U, the + destination port number in the transport-layer header will be set to + the port number corresponding to the destination of the unicast + packet. + +8.2. List of DSCPs + + The Xcast 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 channel. + + The DSCP in the IP header will be set to the most demanding DSCP of + the list of DSCPs. This DSCP in the IP header will determine, e.g., + the scheduler to use. + + If two destinations, with the same next-hop, have 'non-mergeable' + DSCPs, two Xcast packets will be created. 'Non-mergeable' meaning + that one cannot say that one is more or less stringent than the + other. + +8.3. Channel Identifier + + Optionally, a sender can decide to add an extra number in the Xcast + header: the Channel Identifier. If the source does not want to use + this option, it must set the Channel Identifier to zero. If the + Channel Identifier is non-zero, the pair (Source Address, Channel + Identifier) must uniquely identify the channel (note that this is + similar to the (S, G) pair in SSM). This document does not assign + any other semantics to the Channel Identifier besides the one above. + + + + +Boivie, et al. Experimental [Page 15] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +9. Possible Xcast Packet Encoding + +9.1. General + + The source address field of the IP header contains the address of the + Xcast sender. The destination address field carries the All-Xcast- + Routers address (to be assigned link-local multicast address); this + is to have a fixed value. Every Xcast router joins this multicast + group. The reasons for putting a fixed number in the destination + field are: + + 1) The destination address field is part of the IP pseudo header and + the latter is covered by transport layer checksums (e.g., UDP + checksum). So, the fixed value avoids a (delta) recalculation of + the checksum. + + 2) The IPsec Authentication Header (AH) [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. + + + + + + + +Boivie, et al. Experimental [Page 16] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 [1812]. + + 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). + +9.2. IPv4 + + [AGUI] and [1770] 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. + +9.2.1. IPv4 Header + + The Xcast4 header is carried on top of an IP header. The IP header + will carry the protocol number listed as usable for experimental + purposes in RFC 4727 [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. + +9.2.2. Xcast4 Header + + The Xcast4 header is format depicted in 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. + + + + + + + + + + + + + +Boivie, et al. Experimental [Page 17] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 [4301] 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. + + + + +Boivie, et al. Experimental [Page 18] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 + + + + + + + + + +Boivie, et al. Experimental [Page 19] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +9.3. IPv6 + + The Xcast6 header encoding is similar to IPv4, except that Xcast + information would be stored in IPv6 extension headers. + + [IPv6 header | Xcast6 | transport header | payload ] + +9.3.1. IPv6 Header + + The IPv6 header will carry the NextHeader value 'Routing Extension'. + The source address field contains the address of the Xcast sender. + The destination address field carries the All_Xcast_Routers address. + +9.3.2. Xcast6 Header + + The Xcast6 header is also composed of a fixed part and two variable + parts. The fixed part and the first variable part are carried in a + Routing Extension. The second variable part is carried in a + Destination Extension. + + + + + + + + + + + + + + + + + + +Boivie, et al. Experimental [Page 20] + +RFC 5058 Xcast Concepts and Options November 2007 + + +9.3.2.1. Routing Extension Header + + The P-bit of Xcast4 is not present because it is implicit by the + presence or absence of the Destination Extension (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. + +9.3.2.2. Destination Extension Header + + Optionally, the Destination Extension (Figure 7) is present to + specify the list of Port Numbers. The destination header is only + evaluated by the destination node. + + + + + + + +Boivie, et al. Experimental [Page 21] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +10. Impact on Upper-Layer Protocols + + Some fields in the Xcast header(s) can be modified as the packet + travels along its delivery path. This has an impact on: + +10.1. Checksum Calculation in Transport-Layer Headers + + In transport-layer headers, the target of the checksum calculation + includes the IP pseudo header, transport header, and payload (IPv6 + header extensions are not a target). + + The transformation of an Xcast packet to a normal unicast packet -- + (premature) X2U -- replaces the multicast address in the IP header + destination field by the address of a final destination. If the + Xcast header contains a Port List, the port number in the transport + layer (which should be zero) also needs to be replaced by the port + number corresponding to the destination. This requires a + recalculation of these checksums. Note that this does not require a + complete recalculation of the checksum, only a delta calculation, + e.g., for IPv4: + + Checksum' = ~ (~Checksum + ~daH + ~daL + daH' + daL' + ~dp + dp') + + In which "'" indicates the new values, "da" the destination address, + "dp" the destination port, and "H" and "L" the higher and lower 16 + bits, respectively. + +10.2. IPsec + + This is described in [PARI]. + + + + +Boivie, et al. Experimental [Page 22] + +RFC 5058 Xcast Concepts and Options November 2007 + + +11. Gradual Deployment + +11.1. Tunneling + + One way to deploy Xcast in a network that has routers that have no + knowledge of Xcast is to setup "tunnels" between Xcast peers (MBone + approach [MBONE]). This enables the creation of a virtual network + layered on top of an existing network [2003]. 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 + + + + + +Boivie, et al. Experimental [Page 23] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + + + + + +Boivie, et al. Experimental [Page 24] + +RFC 5058 Xcast Concepts and Options November 2007 + + + - 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. + +11.2. Premature X2U + + If a router discovers that its downstream neighbor is not Xcast + capable, it can perform a Premature X2U, i.e., send a unicast packet + for each destination in the Xcast header that has this neighbor as a + next hop. Thus, duplication is done before the Xcast packet reached + its actual branching point. + + A mechanism (protocol/protocol extension) to discover the Xcast + capability of a neighbor is for further study. Among others, one + could think of an extension to a routing protocol to advertise Xcast + capabilities, or one could send periodic 'Xcast pings' to its + neighbors (send an Xcast packet that contains its own address as a + destination and check whether the packet returns). + +11.3. Semi-Permeable Tunneling (IPv6 Only) + + This is an optimization of tunneling in the sense that it does not + require (manual) configuration of tunnels. It is enabled by adding a + Hop-by-Hop Xcast6 header. An IPv6 packet can initiate/trigger + additional processing in the on-route routers by using the IPv6 Hop- + by-hop option. + + The type of the Xcast6 Hop-by-hop option has a prefix '00' so that + routers that cannot recognize Xcast6 can treat the Xcast6 datagram as + a normal IPv6 datagram and forward it toward the destination in the + IPv6 header. + + + +Boivie, et al. Experimental [Page 25] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +11.4. Special Case: Deployment without Network Support + + A special method of deploying Xcast is possible by upgrading only the + hosts. By applying tunneling (see 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. + + + + +Boivie, et al. Experimental [Page 26] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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. + +11.5. Using a Small Number of Xcast-Aware Routers to Provide Xcast + in a Not-So-Small Network + + In this approach, an Xcast packet uses a special 32-bit unicast + address in the destination field of the IP header. In the simplest + version of this scheme, there might be only a single Xcast-aware + router in a network. This Xcast-aware router looks like a "server" + to the other routers and it is configured so that its IP address (or + one of its IP addresses) corresponds to the "special" 32-bit address. + Thus, when Xcast clients send Xcast packets, the non-Xcast-aware + routers will route these packets to the Xcast-aware router and the + Xcast-aware router can "explode" (X2U) them into an appropriate set + of unicast packets. This allows clients anywhere in a network to use + Xcast to overcome the problem of limited bandwidth in the "first + mile" with a minimum number of Xcast-aware routers (i.e., 1). + + Another possibility is to deploy a few of these Xcast-aware routers + at various points in the network and to configure each of these with + the special 32-bit address. This provides redundancy, eliminating + the single point of failure, and reduces the distance an Xcast packet + needs to travel to reach an Xcast-aware router, reducing network + latencies. In this case, the Xcast-aware routers appear to be a + single server that is "multihomed" (i.e., connected to the network at + more than one place) and the non-Xcast-aware routers will, via + ordinary unicast routing, deliver packets that are addressed to this + "multihomed virtual server" via the shortest available path. + + + + + +Boivie, et al. Experimental [Page 27] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 + [1546], [2526], and [3068]. 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. + +12. (Socket) API + + In the most simple use of Xcast, the final destinations of an Xcast + packet receive an ordinary unicast UDP packet. This means that hosts + can receive an Xcast packet with a standard, unmodified TCP/IP stack. + + Hosts can also transmit Xcast packets with a standard TCP/IP stack + with a small Xcast library that sends Xcast packets on a raw socket. + This has been used to implement Xcast-based applications on both Unix + and Windows platforms without any kernel changes. + + Another possibility is to modify the sockets interface slightly. For + example, one might add an "xcast_sendto" function that works like + "sendto" but that uses a list of destination addresses in place of + the single address that "sendto" uses. + +13. Unresolved Issues + + Additional work is needed in several areas. + +13.1. The Format of the "List of Addresses" + + Additional details need to be specified. For example, in the IPv4 + case, the format of the DSCPs option needs to be specified. + +13.2. The Size of Channel Identifier + + The size of the channel identifiers in IPv4 and IPv6 are different in + this document. 32 bits might be sufficient for both IPv6 and IPv4. + +13.3. Incremental Deployment + + Several possible methods of incremental deployment are discussed in + this document including tunneling, premature X2U, etc. Additional + work is needed to determine the best means of incremental deployment + for an intra-domain as well as an inter-domain deployment of Xcast. + If tunneling is used, additional details need to be specified (e.g., + tunneling format, use of tunnels in the inter-domain case). + + + + +Boivie, et al. Experimental [Page 28] + +RFC 5058 Xcast Concepts and Options November 2007 + + +13.4. DSCP Usage + + DSCP usage needs some work. DSCPs may have to be rewritten as + packets cross inter-domain boundaries. + +13.5. Traversing a Firewall or NAT Products + + The usage of a different, carried protocol type for IPv4 may cause + difficulty in traversing some firewall and NAT products. + +13.6. The Size of BITMAP + + Given that this is designed for small groups, it might make sense to + simply mandate a fixed size for the bitmap. + +14. Security Considerations + + The list of destinations in Xcast is provided by an application layer + that manages group membership as well as authorization if + authorization is desired. + + Since a source has the list of destinations and can make changes to + the list, it has more control over where its packets go than in + traditional multicast and can prevent anonymous eavesdroppers from + joining a multicast session, for example. + + Some forms of denial-of-service attack can use Xcast to increase + their "effect". A smurf attack, for example, sends an ICMP Echo + Request in which the source address in the packet is set to the + address of the target of the attack so that the target will receive + the ICMP echo reply. With Xcast, the ICMP Echo Request could be sent + to a list of destinations that could cause each member of the list to + send an Echo Reply to the target. + + Measures have been taken in traditional multicast to avoid this kind + of attack. A router or host can be configured so that it will not + reply to ICMP requests addressed to a multicast address. The Reverse + Path Forwarding check in traditional multicast architectures also + helps limit these attacks. In Xcast, it can be difficult for a host + to recognize that an ICMP request has been addressed to multiple + destinations since the packet may be an ordinary unicast packet by + the time it reaches the host. On the other hand, a router can detect + Xcast packets that are used to send ICMP requests to multiple + destinations and can be configured to drop those packets. Note, too, + that since Xcast sends packets to a short list of destinations, the + problem of sending attack packets to multiple destination is less of + + + + + +Boivie, et al. Experimental [Page 29] + +RFC 5058 Xcast Concepts and Options November 2007 + + + 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 + [3740]. 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. + +15. IANA Considerations + + Experimentation with the Xcast protocol requires the use of protocol + numbers maintained by IANA. For example, to implement XCAST6, + implementations must agree on four protocol numbers: + + (1) Multicast Address for All_Xcast_Routers + (2) Routing Type of IPv6 Routing Header + (3) Option Type of IPv6 Destination Option Header + (4) Option Type of IPv6 Hop-by-Hop Options Header + + A protocol implementer may temporarily experiment with Xcast by using + the values set aside for experimental use in RFC [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. + + + + + + +Boivie, et al. Experimental [Page 30] + +RFC 5058 Xcast Concepts and Options November 2007 + + +16. Informative References + + [1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast + Addresses", RFC 2526, March 1999. + + [3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC + 3068, June 2001. + + [1112] Deering, S., "Host extensions for IP multicasting", STD 5, + RFC 1112, August 1989. + + [1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector + Multicast Routing Protocol", RFC 1075, November 1988. + + [1770] Graff, C., "IPv4 Option for Sender Directed Multi-Destination + Delivery", RFC 1770, March 1995. + + [1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC + 1812, June 1995. + + [2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October + 1996. + + [2201] Ballardie, A., "Core Based Trees (CBT) Multicast Routing + Architecture", RFC 2201, September 1997. + + [2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [2902] Deering, S., Hares, S., Perkins, C., and R. Perlman, + "Overview of the 1998 IAB Routing Workshop", RFC 2902, August + 2000. + + [3261] 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. + + [3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. + Thyagarajan, "Internet Group Management Protocol, Version 3", + RFC 3376, October 2002. + + [3740] Hardjono, T. and B. Weis, "The Multicast Group Security + Architecture", RFC 3740, March 2004. + + + + + +Boivie, et al. Experimental [Page 31] + +RFC 5058 Xcast Concepts and Options November 2007 + + + [4301] Kent, S. and K. Seo, "Security Architecture for the Internet + Protocol", RFC 4301, December 2005. + + [4302] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", + RFC 4607, August 2006. + + [4727] 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. + + + +Boivie, et al. Experimental [Page 32] + +RFC 5058 Xcast Concepts and Options November 2007 + + + [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>. + +17. Contributors + + Olivier Paridaens + Alcatel Network Strategy Group + Fr. Wellesplein 1, 2018 + Antwerpen, Belgium + Phone: 32 3 2409320 + EMail: Olivier.Paridaens@alcatel.be + + Eiichi Muramoto + Matsushita Electric Industrial Co., Ltd. + 4-12-4 Higashi-shinagawa, Shinagawa-ku + Tokyo 140-8587, Japan + Phone: +81-3-6710-2031 + EMail: muramoto@xcast.jp + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Boivie, et al. Experimental [Page 33] + +RFC 5058 Xcast Concepts and Options November 2007 + + +Authors' Addresses + + Rick Boivie + IBM T. J. Watson Research Center + 19 Skyline Drive + Hawthorne, NY 10532 + Phone: 914-784-3251 + EMail: rhboivie@us.ibm.com + + Nancy Feldman + IBM T. J. Watson Research Center + 19 Skyline Drive + Hawthorne, NY 10532 + EMail: nkfeldman@yahoo.com + + Yuji Imai + Fujitsu Laboratories Ltd. + 1-1, Kamikodanaka 4-Chome, Nakahara-ku + Kawasaki 211-8588, Japan + Phone: +81-44-754-2628 + Fax : +81-44-754-2793 + EMail: ug@xcast.jp + + Wim Livens + ESCAUX + Krijtstraat 17, 2600 + Berchem, Belgium + EMail: wim@livens.net + + Dirk Ooms + OneSparrow + Belegstraat 13; 2018 + Antwerp, Belgium + EMail: dirk@onesparrow.com + + + + + + + + + + + + + + + + + +Boivie, et al. Experimental [Page 34] + +RFC 5058 Xcast Concepts and Options November 2007 + + +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 + ietf-ipr@ietf.org. + + + + + + + + + + + + +Boivie, et al. Experimental [Page 35] + |