One document matched: draft-hsu-xcast-bcp-2004-01.txt
Differences from draft-hsu-xcast-bcp-2004-00.txt
INTERNET DRAFT C. Hsu, E.Muramoto, J. Buford
<draft-hsu-xcast-bcp-2004-01.txt> Panasonic
Y. Imai
WIDE Project/Fujitsu Lab
Ali Boudani
IRISA-France
R. Boivie
IBM
July, 2005
Expires January, 2006
Best Current Practices of XCAST (Explicit Multi-Unicast) by 2004
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 BCP 79.
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 January 2006 [Page 1]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
Abstract
In 2000, XCAST (Explicit Multi-Unicast) was first proposed as a
protocol intended for small group multicasting. It combined three
similar datagram simulcasting protocols that were submitted as
earlier Internet Drafts by a number of different research groups.
After that, researchers in those groups worked together to further
develop, experiment and conduct standardization in IETF as well as in
the open source community. This resulted in several implementations
of protocol stacks, systems of multi-party video conference and group
management, and mechanisms for harmonizing XCAST with ASM and SSM. In
addition, an XCAST backbone for various experiments has been launched
to operate inter-continentally.
One of the main purposes of this document is to summarize the efforts
undertaken by XCAST community as "best current practices" that would
then be formally introduced to the IETF/IRTF community. In addition,
we raise an issue concerning IANA resource allocation, which prevents
us from widely expanding our experimental networks as well as
distributing our software. Finally, we request IESG and other experts
to check the validity of our proposed protocol and make any
suggestions about how IANA can assign appropriate resources
accordingly.
Table of Contents
1. Standardization Efforts
2. Development
2.1 Protocol Stacks
2.2 Applications
3. Experimental Networks
4. Harmonization with ASM and SSM
4.1 XCAST+
4.2 SEM
5. Unsolved Problems
6. IANA Considerations
7. Security Considerations
8. References
9. Authors Addresses
Hsu, et al. Expires January 2006 [Page 2]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
10. Full Copyright Statement
11. IPR Notices
Changes:
00->01: added the section "Research Topics and Unsolved Problems".
1. Standardization Efforts
XCAST (Explicit Multi-Unicast) is a datagram delivery protocol for
efficient small group communications. It is based on the idea that a
datagram is transmitted with an "explicit list of unicast addresses
of multiple destinations" and each intermediate node (e.g., router),
according to the information stored in the explicit list, forwards
and branches (if needed) the datagram subsequently to the appropriate
next hop by referring to its unicast routing table.
In 1999, three documents were submitted as Internet-Drafts [CLM, SGM,
MDO6]. Since the targeted area and mechanisms proposed in those I-Ds
were similar, Ooms et al. combined the ideas of those I-Ds and came
out with an Internet-Draft called "XCAST Basic Specification" [basic-
spec] in 2000. At the same time, the authors of XCAST Basic
Specification noticed an earlier proposal similar to their approach
has been published by Aguilar [Aguilar].
They started an introduction to XCAST technology at the MADDOGS, one
of the Routing Area meetings in IETF, and received suggestions about
moving forward to hold an IRTF RG or a BOF in 2001. Given the early
stage of the activity, substantial running systems and strong demand
from users, operators and service providers were not available, so
when the first XCAST BOF was held in IETF, a consensus could not be
reached at that time.
After that, with increasing demands from users, the XCAST community
has become ever larger with more nodes and running networks. Status
of the XCAST community has been periodically reported to and
discussed with IESG members, routing area directors (Abha, Bill and
Alex) and transport area director Allison. The I-D, XCAST Basic
Specification, has been updated to version 8. The differences among
each version are trivial, showing that the proposed protocol is
relatively stable.
2. Development
To prove the concept, validity, interoperability and effectiveness of
Hsu, et al. Expires January 2006 [Page 3]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
this protocol, the XCAST community has collaborated to develop a
variety of XCAST-based software ranging from protocol stacks to
applications.
2.1 Protocol Stacks
2.1.1 XCAST4
IBM and Alcatel have implemented an XCAST protocol stack for IPv4 on
Linux and FreeBSD respectively. To validate their implementations,
they have conducted an experiment via inter-continental Internet
where the exchange of text messages was successful. The IBM version
is publicly available.
2.1.2 XCAST6
WIDE project/Fujitsu Laboratories and ETRI/Soongsil University have
implemented XCAST protocol stacks for IPv6 on NetBSD/FreeBSD and
Linux respectively. To verify multi-platform interoperability, they
have conducted conformance tests using XCAST with modified MBone
tools (vic & rat). A demonstration of multipoint video conferencing
and collaborative working among participants in Japan and Korea was
held at IETF 54 Yokohama. The ETRI/Soongsil University version is
publicly available [SNU-XCAST6]. The original release of WIDE
project/Fujitsu Laboratories is being maintained by the XCAST fan
club in Japan, and modified versions of the stable distributions of
NetBSD/FreeBSD are released on sourceforge.net accordingly
[XCAST6-kit].
2.2 Applications
2.2.1 MBone Tools
Well-known Mbone tools VIC and RAT have been modified and integrated
with XCAST. On the sender side, instead of binding the multicast
group address to the socket, the modified tools call XCASTAddMember()
to append each unicast address of the participated node. On the
receiver side, no modification is necessary since the payload of an
XCAST datagram can be acquired by calling ordinary recv() function.
The total amount of additional code is less than 200 lines for vic
and 150 lines for rat.
2.2.2 xcgroup
To use the above-mentioned Mbone tools, operators need to specify a
long list of IP addresses before conducting an experiment. This,
however, might not always be appropriate, since it is difficult to
maintain consistent membership information, i.e., the set of unicast
Hsu, et al. Expires January 2006 [Page 4]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
addresses of XCAST nodes, among the participants.
To solve this problem, we created a CGI script for httpd and a client
program called "xcgroup". Operators invoke xcgroup with a URL of CGI
for managing the information of group name and its membership (i.e.,
participating nodes). Client xcgroup periodically sends a query to
the CGI script by http and the CGI script acquires the IPv6 source
address of the query and records it in a list. Then it retrieves all
the IPv6 source addresses recorded in the list and provides the
client program that information. As a result, consistent membership
information among the participants can be provided. Xcgroup announces
the list of acquired unicast addresses for Mbone tools via mbus
[rfc3259].
2.2.3 ping6x, traceroute6x
Semi-permeable tunneling, one of the incremental deployment
technologies adopted in XCAST, is utilized to forward the received
XCAST packets to the next XCAST router by referring to the routing
information obtained via any of the unicast routing protocols. This
approach, however, lacks a mechanism to check the reachability of an
overlay XCAST delivery tree. For this purpose, ping6x and
traceroute6x were developed by modifying existing ping6 and
traceroute6.
To identify an overlay XCAST delivery tree, operators simply send a
probing packet to one of the specific destinations listed in the
XCAST header, since an XCAST datagram is treated as an ordinary
packet by non-XCAST routers, ICMP response similar to those in
unicast ping6 or traceroute6 can be obtained. As a result, the
reachability of the overlay XCAST delivery tree can be identified by
referring to the information of all the ICMP responses.
2.2.4 Live CDs
To use XCAST6, it is necessary to re-compile the kernel and install a
new library. This prevents a wider acceptance and use of XCAST
technology. To alleviate this problem, some open source communities
based on NetBSD and FreeBSD, have collaborated and developed a Live
CD solution for XCAST6. These Live CDs are called Ebifurya CD and
XCAST6 enable FreeSBIE. The Live CD solution includes a pre-installed
bootable image containing XCAST-based Mbone tools, USB camera tools,
sound card drivers with utilities and an xcgroup client program.
3. Experimental Networks
To prove the concept of XCAST, WIDE XCAST WG started operating a
weekly video conference meeting using an early version of XCAST,
Hsu, et al. Expires January 2006 [Page 5]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
i.e., Multiple Destination Option of IPv6, among seven Japanese
organizations and one university in the USA in 2000 via the WIDE
6Bone. Since the delivery tree was constructed using semi-permeable
tunneling technology at the beginning stage of the experiment,
improper daisy-chained connections always resulted in poor
performance. To overcome this problem, they launched another project
called X6Bone to construct a virtual network with v6/v4 tunnels
connecting many SOHO routers to a HUB branch XCAST router via ADSL.
With this, the transmission of XCAST datagrams could be branched at
the HUB router, thus eliminating the problem of inefficient daisy-
chained connections. In addition, a bi-monthly event called "Midnight
XCAST party" where a number of SOHO users were connected via
commercial ADSL had been held successfully 15 times.
By July of 2005, the number of groups joining the weekly meeting has
increased to nine organizations including BSD User groups, Linux User
groups, XCAST protocol user groups and IRISA/France. This is achieved
by allocating a delegated /40 prefix of IPv6 address space for each
group and then each group redistributes /48 for its members
respectively.
These results demonstrate that the concept of XCAST is feasible.
Since XCAST only requires the operation of current existing unicast
routing controls, it is extremely easy to operate compared to PIM.
4. Harmonization with ASM and SSM
For mass distribution services, such as live event broadcastings in
IETF, on-demand streaming videos and large-scale distance learning
courses, ASM/SSM is the most efficient mechanism to realize such
services since it is scalable with respect to the number of
receivers. On the other hand, for personal usage such as conducting a
small scale business meeting, chatting with a group of friends and
playing a multi-party on-line game, XCAST is the preferred means
since it does not require any routing state to be maintained in the
intermediate routers, thus it is scalable with respect to the number
of simultaneous small group formed.
We believe the combined use of ASM, unicast and XCAST further enables
the provision of wider service offerings. This section summarizes
current approaches to the harmonization of ASM, SSM and XCAST.
4.1 XCAST+
XCAST+ is an extension of XCAST intended 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
Hsu, et al. Expires January 2006 [Page 6]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
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 then 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. After that, each DR converts the
XCAST packet to a multicast packet using the XCAST-to-Multicast
protocol (X2M) and sends it in its subnetworks.
4.2 SEM
As mentioned above, XCAST+ is designed to support a large number of
medium-sized groups. However, since the delivery mechanism used from
source DR to destination DRs is similar to that of the original
XCAST, the problem of the limited number of DRs that can be included
in the list of destinations still remains.
To solve this problem, SEM (Simple Explicit Multicast) introduces the
idea of deploying routers at branching point of the XCAST delivery
tree. This idea is similar to that proposed in REUNITE [REUNITE].
Both protocols require branching routers to keep state of (S,G) and
next branching router. The major difference between SEM and REUNITE
is how to maintain the state in each router. REUNITE periodically
sends probing packets back from DRs to S and checks the status of the
branch points. On the other hand, SEM forwards the probing packets
from S to DRs using XCAST+. With this, the SEM delivery tree is not
affected even if asymmetry exists in the unicast routing paths.
5. Unsolved Problems
As described in previous sections, XCAST experimentation is quite
active, and multiple implementations have been developed by several
research groups around the world. However, there remain some issues
that need to be resolved. This section aims to identify those issues
and provide guidance for current practices and further directions.
5.1 Group management
To allow application developers to utilize their own application-
specific group management functions with XCAST without thinking about
group address assignment or specific XCAST capabilities, the group
management function of XCAST should be completely separated from the
function of XCAST-based forwarding or routing. There are several
research topics that focus on how to integrate the group formation
Hsu, et al. Expires January 2006 [Page 7]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
and management functions of social networking or other interactive
communication applications with XCAST-based forwarding or routing
technology.
5.2 Transport Layer Support
Transport layer support plays a crucial role in achieving effective
date exchange among the participating nodes in an XCAST group.
Adequate congestion control, flow control and reliable end-to-end
delivery are examples of transport layer protocols. There are several
research topics that focus on how to avoid the congestion by
observing the network conditions with a light-weight protocol, how to
quickly isolate the congestion and how to fairly allocate sharing
network resource among connections between sender and multiple
receivers.
5.3 Harmonization with Broadcast
In addition to the harmonization models introduced in section 4,
there are several research topics that focus on how to effectively
utilize the broadcast capability of existing access systems, such as
satellite or wireless, with XCAST.
5.4 XCAST Tunneling
It must be clarified that XCAST tunneling has the scope of
applicability intended for inter-domain use. Although, as stated in
section 11.1 of [Basic], XCAST routers could exchange and maintain
routing information using any of standard protocols such as RIP,
OSPF, ISIS and BGP, this, however, needs to be further investigated.
In the case of intra-domain use, it might be enough to append
capability information to current intra-domain routing protocols and
facilitate the exchange of XCAST routing information, however in the
case of inter-domain use, injecting the entire BGP routing table into
the XCAST routing table might not be applicable.
In addition, the actual tunnel encapsulation, either IP in IP, GRE or
simply using the next XCAST router as the IP destination in the
regular IP header (i.e., without wrapper), is currently not concrete.
Furthermore, if multiple tunneling methods are to be adopted in
XCAST, mechanisms of how the participating nodes learn about what
modes they and their peer nodes are using, e.g, via manually
configured or automatically detected, need to be further discussed.
5.5 DSCP Operation
Although the usage of DSCP (DiffServ Code Point) option was described
Hsu, et al. Expires January 2006 [Page 8]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
in section 8.2 of [Basic], the feasibility of its inter-domain use,
such as re-writing the DSCP when packets cross domain boundaries or
re-mapping DSCP when packets cross domain using XCAST tunneling,
needs to be further investigated.
5.6 NAT Traversal and Firewall Penetration
Solutions and approaches to the potential problems of NAT traversal
and firewall penetration that arise in the usage of a different
carried protocol type for IPv4, need to be further discussed.
5.7 BITMAP Handling
To simplify the processing required in handling BITMAP in the list of
destination of XCAST router, the type of the length of the BITMAP
(i.e., fixed sized or variable) and its effects need to be further
determined.
5.8 Network Deployment
We believe that the total amount of traffic generated by XCAST-based
group communication in the Internet backbone can be dramatically
decreased if XCAST routers could be appropriately deployed in
strategic points throughout the network. A deeper understanding of
the requirement of the above-mentioned network deployment and an in-
depth discussion of how to strategically places XCAST routers in the
current or future Internet backbone (e.g., instead of placing XCAST
routers into the core part of the backbone, it might be enough to
deploy them at the edge) are needed.
6. IANA Considerations
We had requested the IANA resource for XCAST in 2000 but the request
was rejected due to the lack of suggestions from IESG and protocol
experts.
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 are currently using protocol option values which are not
officially assigned by IANA.
To avoid confusion, we need experimental IANA resources described in
a separate Internet Draft for Informational RFC [xc-iana]. In
addition, we request IESG or other protocol experts to examine the
validity of our proposal and make any suggestion to IANA accordingly.
7. Security Considerations
Hsu, et al. Expires January 2006 [Page 9]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
This document has no known security implications.
8. 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 January 2006 [Page 10]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 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.
[rfc3259] J. Ott, et al., "A Message Bus for Local Coordination",
RFC3259, April 2002
[xc-iana] C. Hsu, et al., "IANA Considerations for XCAST (Explicit
Multi-Unicast)", internet draft, http://www.ietf.org/inter-
net-drafts/draft-hsu-xcast-iana-considerations-00.txt, April
2005.
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate require-
ment Levels", BCP 14, RFC 2119, March 1997.
9. 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
Hsu, et al. Expires January 2006 [Page 11]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
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
Rick Boivie
IBM T. J. Watson Research Center
19 Skyline Drive
Hawthorne, NY 10532
Phone: 914-784-3251
Email: rhboivie@us.ibm.com
10. 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.
11. 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.
Hsu, et al. Expires January 2006 [Page 12]
Internet Draft draft-hsu-xcast-bcp-2004-01.txt July 2005
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 January 2006 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 09:05:00 |