One document matched: draft-hsu-xcast-bcp-2004-00.txt
INTERNET DRAFT C. Hsu, E.Muramoto, J. Buford
<draft-hsu-xcast-bcp-2004-00.txt> Panasonic
Y. Imai
WIDE Project/Fujitsu Lab
Ali Boudani
IRISA-France
R. Boivie
IBM
April, 2005
Expires October, 2005
Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
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 its 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 obsoleted by other documents at any
time. 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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [rfc2119].
Allocation policy names Specification Required, IETF Consensus
Action, and Designated Expert are to be interpreted as described in
RFC 2434 [rfc2434]
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Hsu, et al. Expires October 2005 [Page 1]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
Abstract
XCAST (Explicit Multi-Unicast) is an protocol for small group
multicasting. This document summarizes current best practices by
2004 related with XCAST.
In 1999, several researchers individually re-invented datagram
simulcasting protocol focused on small group communications and
submitted 3 specifications as Internet-Drafts. They talked and
evaluated those protocols each other and made a unified protocol
"XCAST". They also organized the community for research, develop,
experiment and standardization in IETF as well as open source
community. Their practices cover protocol stack implementations,
multi party video conference system, group management systems and
harmonization XCAST with ASM and SSM.
As the results of these efforts were disclosed publicly, open source
community applied these technologies in their distributions. As a
combined effects of these results, inter-continental XCAST backbone
for various experiments started to operate.
First purposes of this document is summarizing these efforts as the
best current practices to inform broadly in IETF/IRTF community.
Second and emphasized one is discussion about very big obstacle for
us, IANA resource allocation, that now prevents us from expanding
XCAST experimental networks and distributing our software much
broader. We require IESG and protocol experts to check validity of
our efforts and make sugestion for IANA necessary to assign
resources.
Table of Contents
1. Standardizing efforts
2. Development
2.1 Protocol Stacks
2.2 Applications
3. Harmonization with ASM and SSM
3.1 XCAST+
3.2 SEM
4. Experimental network
5. IANA consideration
6. Security Considerations
Hsu, et al. Expires October 2005 [Page 2]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
7. References
8. Authors Addresses
9. Full Copyright Statement
10. IPR Notices
1. Standardizing efforts
XCAST (Explicit Multi-Unicast) is a datagram delivery protocol for
efficient small group communications. This protocol is based on the
idea that a datagram transmitted with "explicit list of unicast
addresses of receivers" and intermediate routers forward and branch
if needed, refering unicast routing tables all routers naturally
maintain.
In 1999, 3 Internet-Drafts [CLM, SGM, MDO6] were individually
submitted. Googling the key words submitters found each other. Then,
3 groups gathered in Washington DC on 46th IETF and they started the
effort to realizing their idea, first unifying protocol, next
standardize in IETF and deploy them on the Internet.
In 2000, Ooms et al. merged their ideas and submitted it as Internet-
Draft "XCAST basic specification" [basic-spec]. Unifying them they
found the original idea was already published by Aguilar [Aguilar].
They introduced this topic in MADDOGS, Routing Area Meeting and get
suggestion to have IRTF RG or BoF. As they considered I-D was
technically matured by that time and IRTF chair agreed that, they
requested for BoF and held first one in 2001. However, they failed
to get rough consensus of IETF in that time. One of the reason
seemed that they could not show there was enough working systems and
good real demands of the users, operators and servicers.
After first BoF, they organized community much larger to get more
nodes, running network and demands of real users. They periodically
reported to and discussed with IESG members, routing area directors
(Abha, Bill and Alex) and Allison.
For these 5 years, they have been keeping I-D updated. Differences
of each version were very trivial and mechanism itself was always
stable.
2. Development
To proof the concept, validity, interoperability and effectiveness of
Hsu, et al. Expires October 2005 [Page 3]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
this protocol, community collaborated to make variety of XCAST
systems from protocol stacks to applications.
2.1 Protocol Stacks
2.1.1 XCAST4
2 groups made XCAST protocol implementation for IPv4. IBM made it on
Linux and Alcatel made it on FreeBSD. Two connected their nodes via
inter-continental Internet and exchange text chat messages. IBM
version is publicly available.
2.1.2 XCAST6
2 groups made XCAST protocol implementation for IPv6. WIDE
project/Fujitsu Laboratories made one on NetBSD and FreeBSD.
ETRI/Soongsil University made one on Linux. Two made
interoperability demonstration on IETF Yokohama, that include **
nodes in Japan and ** nodes on Korean side. They exchanged video and
audio using modified version of MBone tools, vic and rat.
[XCAST6-INTEROP-TEST] ETRI/Soongsil University version is publicly
available[SNU-XCAST6]. WIDE/Fujitsu Lab version was succeeded by
XCAST fan club in Japan and kept updated for newest stable version of
NetBSD and FreeBSD which are available at
sourceforge.net[XCAST6-kit].
2.2 Applications
2.2.1 MBone tools
On top of XCAST6 stack, Vic and Rat are modified. We found it's quite
simple and straight forward to adapt multicast functions to XCASTs'.
On the sender side, instead of bind() for multicast group address,
call XcastAddMember() for all unicast destinations. On the receiver
side, no modification is necessary because payload of XCAST datagram
can be aquired by ordinal recv() call. So, additional amount of codes
is less than 200 line for vic and 150 line for rat.
2.2.2 xcgroup
At the begining of experiments, mbone tool was with simple
modification as above. Operators must specify long list of IPv6
addresses as the argument for mbone tools. It is very troublesome to
keep membership, the set of unicast addresses of XCAST node,
consitent among the participant.
To solve the problem very easy way, we quickly hack the CGI script
for httpd and small client program "xcgroup". Operators invoke
Hsu, et al. Expires October 2005 [Page 4]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
xcgroup with URL of CGI for membership management and coterie name.
Client xcgroup periodically send query for CGI script by http. Then
CGI script keep the IPv6 source address of the http query on the list
of coterie and reply the list back. xcgroup announce acquired list of
unicast addresses for mbone tools via mbus.
It is too simple to signal rapidly like telephone call so much more
sophisticated system is desired, but good enough for current XCAST6
experiments.
2.2.3 ping6x, traceroute6x
Basically, XCAST travels via unicast routing situation, but using
gradual deployment technology like semi-permeable tunneling, it's
difficult to check reachability and find the delivery tree of XCAST
datagram. For this purpose, ping6x and traceroute6x is developed
modifying based on ping6 and traceroute6. Operators can transmit the
proving packet for one of specific destination in the list of XCAST
destination. Since XCAST datagram is treated as ordinal unicast one
by non-XCAST aware routers, they make ICMP reflection just similar
way as unicast ping6 and traceroute6. So ping6x and traceroute6x pick
up and display the ICMP reflection against for branched XCAST
datagram for designated destination.
2.2.4 Live CDs
To use XCAST6, kernel re-compile and library installation are
neccesary. It prevents novice users from start enjoying XCAST. To
ease such work, collaborators from open source community make and
distribute Live CD for XCAST6. These are based on NetBSD and FreeBSD
(FreeSBIE), including pre-install image of XCASTable mbone tools, USB
camera tools, sound card driviers with utilities and xcgroup. It's
good for novice users but also for trained users because they can set
up XCAST node firmly without mis-configuration.
3. Harminization with ASM and SSM
As they Dirk presented in the 1st BoF in XXth IETF, there are large
variety of application demands to deliver and share one datagram for
the number of receivers. He explained with followings figure. For
demands broadcast like service like live TV program distribution,
large netowrk conferences like IETF and AccessGrid, ASM and SSM is
best because it is scalable with the number of receivers. On the
other hand demand for personal usage like business talks, hobby chats
and on-line games, XCAST is good because they don't need any routing
status on the intermediate routers and scalable with the number of
groups.
Hsu, et al. Expires October 2005 [Page 5]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
And he also mentioned, potentially, combination usage of ASM, unicast
and XCAST can be cover the broad demand of such applications,
choosing method from case to case. In other words of RTM WG, "There
is no almighty protocol for all RMT needs." Inspired by this aspect,
researchers make efforts to harmonize ASM, SSM and XCAST.
3.1 Xcast+
Xcast+ is an extension of Xcast for a more efficient delivery of
multicast packets [Xcast+]. Every source or destination is associated
to a Designated Router (DR). Instead of encoding in the Xcast packet
header the set of group members, Xcast+ encodes the set of their DRs.
When a new member wants to join the group G of source S, it sends an
IGMP-join message to its DR. The DR will send a join-request message
to the source S. The DR of the source intercepts this message and
analyzes it in order to keep track of all concerned DR addresses.
When the source S wants to send a message to the group G, it sends a
multicast packet. This packet is received by its DR and converted to
an Xcast packet using the Multicast-to-Xcast algorithm (M2X). The
packet is then forwarded as in Xcast to the DRs, since the
destination list in the Xcast header contains the DR addresses
instead of the member addresses. Then, each DR converts the Xcast
packet to a multicast packet using the Xcast-to-Multicast protocol
(X2M) and sends it in its subnetworks.
3.2 SEM
XCAST+ can support large number of midium size gourp. However, since
delivery mechanism between S for DRs is simillar with XCAST, number
of DRs is limited as small as XCAST. SEM (Simple Explicit Multicast)
expand them introducing the help of routers at branching point of
delivery tree. It has similar mechanism with REUNITE [REUNITE]. Both
protocols require branching routers to keep status of (S,G) and next
branching router ISM, SSM should go and looking up this tables, they
duplicate and forward for next branches, finaly DRs. Difference of
SEM and REUNITE is how to maintain the status of routers. REUNITE
periodically send back from DRs to S and check branch status. On the
other hand, SEM probes forward the path from S to DRs delivering by
XCAST+ style. By this technique, tree shape is not effected even when
unicast routing is asymmetric.
4. Experimental network operation
Using developed systems, they started operational proof of concept of
XCAST. WIDE XACST WG began weekly video conference using early
version of XCAST, Multiple Destination Option of IPv6, among 7
Japanese organizations and 1 US University since 2000 on the WIDE
6Bone. And change the protocol onto unified IPv6 version of XCAST.
Hsu, et al. Expires October 2005 [Page 6]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
At that time, delivery path was like daisy chain using semi-permeable
tunneling technology. To enable collaborators in open source
community, who are connected narrower ADSL line, join to thier
experiments, they started X6Bone project. That is a virtual network
with v6/v4 tunnel connecting HUB branch XCAST router and SOHO router
via ADSL. Then XCAST datagram are branched on the HUB router and
daisy chain path is eliminated. By Feburary on 2005, it increased
upto 9 organizations (BSD User groups, Linux User groups, XCAST
protocol user groups and IRISA) that is delegated /40 prefix of IPv6
address space and redistribute /48 for each members.
Operating the network, they confirmed that only by unicast routing
control, XCAST works well and that is quite easier than PIM
operations.
On this network, they had bi-monthly event "Midnight XCAST party" 14
times. In order to academically confirm XCAST technology fulfil the
original basic desire of communication among human being. Various
kind of collaborators from broad area of Japan are gather to cyber
space, some one from Japanese style bar, other one from wedding
ceremony and many from their dining tables putting dishes and drinks.
They are not from big laboratories neither on the Internet2 nor
Abiline but from SOHO connected by commercial ADSL. By now, we
observe very good phenomenon to proof the concept of XCAST, but they
are not enough. We must continue this event to contribute for next
development of new-age Internet with much more pints of Sake. :-)
5. IANA consideration
Given the growing interest in XCAST and the need to conduct more
experimentation and testing between research groups, we would like to
accelerate the deployment of XCAST aware nodes and routers. However,
we use protocol option values experimentally without IANA assignment.
Because of IPv6 mechanism for datagram with unknown option, they can
pass through netowrks unaware of what XCAST is, in almost case. But
we always ask related netowrk operators to forgive us transmiting the
datagram with unknown protocol to avoid unexpected accident.
To ease this notification and ensure to avoid confilict of values, we
consider that it is better to acquire the IANA resources necessary
for XCAST experiments.
We asked IANA on 2000, but they suspended our request because they
need a suggestion from IANA or protocol experts to allocate those.
Now, we describe detailed information as separate Internet Draft for
Informational RFC. It is for asking IESG or protocol experts to check
validity of our request and make suggestion to IANA.
Hsu, et al. Expires October 2005 [Page 7]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
6. Security Considerations
This document has no known security implications.
7. References
[rfc2026] S. Bradner, "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
[rfc2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434, October,
1998.
[Aguilar] L. Aguilar. Datagram Routing for Internet Multicasting. In
ACM SIGCOMM '84 Communications Architectures and Protocols,
pages 58-63. ACM, June, 1984.
[basic] R. Boivie, et al., "Explicit Multicast (XCAST) Basic Speci-
fication",draft-ooms-xcast-basic-spec-07.txt. January 2005
Submitted for Informational RFC
[CLM] D. Ooms, W. Livens, CONNECTIONLESS MULTICAST: A novel and
scaleable method for multipoint-to-multipoint communication
in IP networks, In "Proceedings of XVII World Telecommunica-
tions Congress (WTC/ ISS 2000)", Birmingham, England, May,
2000.
[SGM] R. Boivie, et al., "Small Group Multicast: A New Solution
for Multicasting on the Internet.", IEEE Internet Computing
4(3): 75-79 (2000) http://csdl.com-
puter.org/dl/mags/ic/2000/03/w3075.htm
[MDO6] Y. Imai, et al., "MDO6: Multicast delivery system by the
list of destinations." in Japanese, Internet Conference '99,
http://www.internetconference.org/ic99/papers/demo05.pdf
[TEST-KRJP] "Xcast6 Interoperability Successfully Tested in Multicast
Linking Korea and Japan", Press Release, August 2002
http://pr.fujitsu.com/en/news/2002/08/1.html
Hsu, et al. Expires October 2005 [Page 8]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
[XCAST6-kit]
http://sourceforge.net/projects/xcast6/
[Xcast+] M. Shin, et al., "Multicast Datagram Delivery Using Xcast in
IPv6 Networks.", ICOIN 2003: 263-272
[REUNITE] I. Stoica, et al., "REUNITE: A recursive Unicast Approach to
Multicast", http://www.ieee-infocom.org/2000/papers/613.ps.
8. Authors Addresses
Chih-Chang Hsu
Matsushita Electric Industrial Co., Ltd.
4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan
Phone : +81-3-5460-2734
E-mail: hsu.mike@jp.panasonic.com
Eiichi Muramoto
Matsushita Electric Industrial Co., Ltd.
4-5-15 Higashi-shinagawa, Shinagawa-ku, Tokyo 140-8632, Japan
Phone : +81-3-5460-2734
E-mail: muramoto.eiichi@jp.panasonic.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
E-mail: kimai@flab.fujitsu.co.jp
John F. Buford
Panasonic Digital Networking Laboratory
Two Research Way, Princeton, NJ 08540, USA
Phone : +1-609-734-7342
Fax : +1-609-987-8827
E-mail: buford@research.panasonic.com
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
Hsu, et al. Expires October 2005 [Page 9]
Internet Draft draft-hsu-xcast-bcp-2004-00.txt April 2005
Rick Boivie
IBM T. J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
Phone: 914-784-3251
Email: rhboivie@us.ibm.com
7. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, 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 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.
8. IPR Notices
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.
Hsu, et al. Expires October 2005 [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-24 09:06:05 |