The explicit multi-unicast (Xcast) is a variation of multicast that supports a great number of multicast sessions with a small number of recipients in each. It adds all the destination IP addresses in the IP header, instead of using a multicast address. The traditional multicast schemes over Internet Protocol (IP) scale to multicast groups with many members, but they have scalability problems for a great number of groups. Multicast schemes can be used to minimize the bandwidth consumption. Xcast minimizes bandwidth consumption for small groups, by eliminating the signaling protocols and state information for every session of the standard IP multicast scheme.
In Xcast, the source node keeps all destinations of the multicast channel through which packets will be sent. The source encodes the destinations list in the Xcast header and sends the packet to a router. Each router looks in a routing table to determine the next hop of each packet, analyzes its header, parses the destination field basing on the following jump of every destination and copies the packets as many different paths as they need to follow. After that, the router copies the packet with its correct Xcast header to every following jump. On the last hop, there is no need to make a new copy, since there is just one address in the destination field. The packet is treated just like a unicast packet, which is called Xcast to Unicast (X2U).
The IP multicast standard was designed to scale to multicast groups with many members. It works well when doing a distribution similar to broadcasting, but it has scalability problems to a large number of groups. Multicast routing protocols keep routing tables that record multicast group addresses with members. These tables might become large, that prompted alternative schemes to reduce the quantity of state information. IP Multicast protocols announce a source or maintain routes between routers. The cost of these protocols can be significant even then the size of each group is reduced.
Xcast follows philosophy that worked well to grow the Internet: keep the center of the network simple, and do the complicated operations on the sides.
Anopen source implementation was available from IBM starting in 2001.[1]AMediaWiki-based web site (English language, but registered in Japan) indicates activity from 2004 through 2007.[2]
An informational specification was published by the Internet Engineering Task Force in November 2007 as RFC 5058.[3]
Routers do not need to keep information for every session or channel. This makes Xcast very scalable about the number of sessions it can support.
There is no need to make a direction assignment.
They don't need protocols for multicast routing. They are routed correctly thanks to the common unicast protocols.
There is no critical node. Xcast minimizes the network latencies and maximizes efficiency.
Symmetric paths are not required.
With traditional IP multicast routing protocols it is necessary to establish a communication between unicast and multicast routing protocols. That means a slow error recovery. Xcast reacts immediately to unicast routing changes.
Easier security and register. With Xcast all sources know the channel members and all routers are able to know the number of times each packet has been duplicated in its domain.
The receptors can be heterogeneous since Xcast allows that every receptor is able to have its own requirements of service in each multicast channel.
Simplicity when implementing reliable protocols over Xcast.
Flexibility: unicast, multicast and Xcast represent costs of bandwidth, signalization and processing respectively. Depending on how the network is built or its load at certain moment, it may be better to use one system or another. Xcast is just another alternative.
Each packet contains all the remaining destinations, which increases its header size.
It requires more complex header processing. Every processing step looks into the routing table, so it is consulted the same number times as a unicast to each destination. A new header must be generated after every hop.
But on the other hand:
Xcast is designed for sessions with few users in each, so in many routers the headers will only have just one address.
The header building can become a very easy operation, overwrite a bit map.
When the packet reaches a region where the bandwidth is not limited, the packet can become a premature X2U.
Xcast allows efficient applications such as VoIP, video conferencing, or collaborative meetings.
These applications could be done using just unicast, but in cases with limited bandwidth, the Xcast efficiency might be useful.
On the other hand, since Xcast does not scale to groups with many members, it can not substitute for all other multicast models.
