GXcast: Generalized Explicit Multicast Routing Protocol
draft-boudani-gxcast-02
| Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
|---|---|---|---|
| Author | Ali Boudani | ||
| Last updated | 2004-10-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Recently several multicast mechanisms were proposed that scale better with the number of multicast groups than traditional multicast does. These proposals are known as small group multicast (SGM) or explicit multicast (Xcast). Explicit multicast protocols, such as the Xcast protocol, encode the list of group members in the Xcast header of every packet. If the number of members in a group increases, routers may need to fragment an Xcast packet. Fragmented packets may not be identified as Xcast packets by routers. In this paper, we show that the Xcast protocol does not support the IP fragmentation and we show also that avoiding fragmentation induces hard-coded limits inside the protocol itself in terms of group size. First, we describe the Xcast protocol, the Xcast+ protocol (which is an extension of Xcast) and we compare these two protocols with traditional multicast protocols.We propose then a generalized version of the Xcast protocol, called GXcast, intended to permit the Xcast packets fragmentation and to support the increasing in the number of members in a multicast group.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)