Internet DRAFT - draft-boudani-mxcast
draft-boudani-mxcast
INTERNET DRAFT Ali Boudani, Bernard Cousin
Expires: August 2003 IRISA-France
March 2003
Using Recursive Xcast Packets for Multicast Delivery
<draft-boudani-mxcast-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at anytime. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
In this document, we propose a new multicast protocol called
MXcast (Multiple Xcast Packets). This protocol uses a very simple
method to deliver multicast packets without constructing
multicast trees using the Xcast [1] and xcast+ [2] techniques.
1. Introduction
Recently several multicast mechanisms were proposed that scale
better with the number of multicast sessions than traditional
multicast does[5].
Explicit Multicast (Xcast)[1] is a newly proposed multicast scheme
to support a very large number of small multicast groups. Xcast+
[2] is an enhanced scheme for the support of receiver initiated
join in explicit multicast which complements the existing Xcast.
This is achieved by adding an IGMP join at receiver side and
sending the join request through source-specific join to the sender,
and then by explicitly encoding the list of addresses of the
multicast routers, instead of receiver addresses.
Xcast+ encoding of the destination list in IPv4 and IPv6 are the
same as Xcast. Whereas Xcast can support a very large number of
small multicast groups, Xcast+ can support a very large number of
medium size multicast groups.
In all the newly proposed protocols the source knows the addresses
of all the destinations before sending packets.
We think that when having medium group size the header processing
in every router for all packets travelling from the source to the
destinations is very expensive.
Boudani & Cousin [Page 1]
INTERNET-DRAFT MXcast March 2003
This document describes a new protocol called MXcast which uses
an efficient method to forward multicast packets.
It uses the same mechanism of Xcast+ by using a small number of
destinations. But instead of encoding the list of addresses of the
multicast routers as in Xcast+, MXcast partitions the destination's
list into multiple lists containning each a fixed number of
destinations.
MXcast encodes the lists in seperate packets and send them in Xcast
Mode.
Using MXcast will result in the following benefits :
- From the viewpoint of receivers, procedures in the control
plane are the same to existing ISM and SSM[7, 8] schemes.
Therefore, MXcast receivers do not need to use additional
control to join in MXcast session. This means that the control
plane of MXcast is compatible with the existing ISM and SSM.
A receiver that is an IGMP capable host does not need to be
an MXcast capable host.
- There can be an increase of the number of receivers, which
means MXcast can support larger size number of
members compared to that of existing Xcast and Xcast+.
Comparing with Xcast and Xcast+, the packet header
processing in MXcast is minimised and thus, MXcast can support
larger size number of members.
- Similar to ALM (Application Level Multicast) and Overlay
Multicast schemes, MXcast supports both multicast and unicast,
where multicast is used in subnet and unicast is used between
branching routers. Therefore, this will result in a more
efficient and scalable mechanism that allow to increase the
number of receivers in a subnet.
- When the scalability in ISM schemes is considered, one of the
main issues may be complexity of multicast tree construction
between multicast routers on Internet backbone. Because MXcast
uses the multicast scheme in a subnet level only (the use of
the multicast address is so simple in all other cases) ,
deployment and management are easy and simple, even if
multicast scheme is used.
2. MXcast Overview
Suppose that B, C, D, E, F and G are trying to receive
packets distributed from A in Figure 1 below:
B
/
R4 -- C
/ D
/ /
A --- R1 --- R2 --- R3 R8 -- E
\ / \
\ / F
Boudani & Cousin [Page 2]
INTERNET-DRAFT MXcast March 2003
R5 --- R6 --- R7
\
\
R9 -- G
Figure 1
This is accomplished as follows:
B, C, D, E, F and G initiate IGMP join. When R4, R8 and R9 receive
the IGMP request, they send source-specific join to A.
If the number of destinations permited (DESTPERM) in an MXcast
header is 2 that mean that 2 MXcast packets should be sent to the
destinations. (Indeed, we have :
(3 destinations)/ (DESTPERM = 2 destinations per packet) =
1.5 packets to be sent).
The first packet contains R4 as the XCast destination. the
second packet contains only R8, R9 as the Xcast destinations.
So instead of sending one Xcast packet with (R4, R8, R9) as the
Xcast destination we send two Xcast (MXcast) packets.
MXcast can be used not only for small groups but also to group
with a large number of destinations. Indeed, comparing to unicast,
MXcast reduces at least by DESTPERM the unicast flow sent to n
destinations.
It should be noted that the partition of the destination list into
multiple destination lists should be carefully considered. A good
choose of this partition will result in reducing the MXcast packets
to be send in subsequents links.
3. MXcast Packet format
Each MXcast packet (same as an Xcast+ packet) is as follow:
[ IP header | Group address | Transport header | Payload ]
The IP header contains the source address and the destination
address of the next hop branch router.
Join and leave messages could be normal SSM join and leave
messages. Thus, in order to not make confusion between SSM
and MXcast, an interval of addresses could specified to be
used only with MXcast protocol.
References
[1] R. Boivie et al., Explicit Multicast (Xcast) Basic Specification,
<draft-ooms-xcast-basic-spec-00.txt>, 2000.
Boudani & Cousin [Page 3]
INTERNET-DRAFT MXcast March 2003
[2] M. Shin et al., Explicit Multicast (Xcast+) Supporting Initiated
Join, <draft-shin-xcast-reciever-join-00.txt>, 2001
[3] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to
Multicast", http://www.ieee-infocom.org/2000/papers/613.ps.
[4] I. Stoica and al., REUNITE: A Recursive Unicast Approach to
Multicast, Tech. Rep., Carnegie Mellon University, Dec. 1999,
http://www.cs.cmu.edu/~hzhang/multicast/
[5] D. Ooms, Taxonomy of xcast/sgm proposals, <www.alcatel.com/xcast
/draft-ooms-xcast-taxonomy-00.txt>, 2000
[6] B. Van Doorselaer et al., SIP for the establishment of xcast-based
multiparty conferences, <draft-van-doorselaer-sip-xcast-00.txt>,
2000
[7] H. Holbrook and B. Cain, Source-Specific Multicast for IP, <draft-
ietf-holbrook-ssm-arch-00.txt>, 2000
[8] S. Bhattacharyya et al., A Framework for Source-Specific IP
Multicast Deployment, <draft-bhattach-pim-ssm-00.txt>, 2000
[9] H. Holbrook and B. Cain, Using IGMPv3 for Source Specific
Multicast, <draft-holbrook-idmr-igmpv3-ssm-00.txt>, 2000
[10] A. Boudani and B. Cousin, An effective Solution for Multicast
Scalability: The MPLS Multicast Tree (MMT),<draft-boudani-mpls-
multicast-tree-00.txt>, 2001
Authors Addresses
Ali Boudani
IRISA/INRIA Rennes
Campus Universitaire de Beaulieu
Avenue du General Leclerc 35042 Rennes France
Phone : (33) 02 99 84 25 37
Fax : (33) 02 99 84 25 29
E-mail : aboudani@irisa.fr
Bernard Cousin
IRISA/INRIA Rennes
Campus Universitaire de Beaulieu
Avenue du General Leclerc 35042 Rennes France
Phone : (33) 02 99 84 73 33
Fax : (33) 02 99 84 71 71
E-mail : bcousin@irisa.fr
Expiration Date: August 2003
