One document matched: draft-muramoto-irtf-sam-generic-require-00.txt
INTERNET DRAFT E.Muramoto,Y.Imai,N.Kawaguchi
<draft-muramoto-irtf-sam-generic-require-00.txt> WIDE project
June, 2006
Expires January, 2007
Requirements for Scalable Adaptive Multicast Framework
in Non-GIG Networks
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 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 [2119].
Allocation policy names Specification Required, IETF Consensus
Action, and Designated Expert are to be interpreted as described in
RFC 2434 [2434]
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Scalable Adaptive Multicast (SAM) Research Group is chartered to
explore and research techniques which improve multicast performance
with respect to dimensions such as number of groups, dynamics of
group membership, dynamics of the network topology, and network
Eiichi, et al. Expires January 2007 [Page 1]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
resource constraints. This document describes requirements for SAM
framework, especially for non-GIG environment.
Table of Contents
1. Introduction
2. What is SAM
3. non-GIG requirement for SAM framework
3.1 Multicast capability
3.2 Service-connectivity cycle
3.3 Scalability problems
3.3.1 Routing convergence
3.3.2 Dynamic topology
3.3.3 Group size
3.3.4 Dynamics of group membership
3.4 Adaptivity for real-time communication
3.4.1 Latency (Delay sensitivity)
3.4.2 Data rate control & Congestion avoidance
3.4.3 Redundancy path
3.5 Capability for non stream application
3.5.1 Interactive application
3.5.2 File transfer
4 Interoperability of existing method
4.1 ALM
4.2 OM
4.3 Selfish routing
4.4 Native IP multicast
4.5 Cooperation with Network TE in overlay approach
4.6 eXplicit Multi-Unicast (Xcast)
5. Security consideration
5.1 Unexpected utilization of resources
5.2 Authorization of group membership
5.3 Mechanism to limit denial of service attack
5.4 Encryption and key distribution
6. Informative Reference
7. Author's Addresses
8. Full Copyright Statement
9. IPR Notices
Changes:
->00: - initial submission
1. Introduction
IP Multicast[1112][1075][2236][CHER][DEER][DEE2][MBONE] has achieved
great engineering success. Various protocols, SSM[3569], PIM[2362],
MSDP[FARI] and MBGP[2858] will provide firm basements for
Eiichi, et al. Expires January 2007 [Page 2]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
distribution of live contents like TV programs broadcasting all over
the Internet. And bulk content delivery could be achieved by
standardized RMT protocols [RMT].
On the other hand, it is possible to improve multicast performance
with respect to dimensions such as number of groups, dynamics of
group membership, dynamics of the network topology, and network
resource constraints. Alternative technologies such as end-system
multicast [ESM], [YOID], [NICE], [ALMI], [TAG], [DTO], [CAN],
[BAYEUX], [XCID] and overlay multicast[SCX], [OVERCAST], [RMX],
[MSN], [OMNI], [AKAMAI], [IBEAM] have been demonstrated to achieve
such improvement. But these mechanisms have not been integrated into
a unified architecture and operational design.
SAM (Scalable Adaptive Multicast) research group[SAM] is chartered to
explore and research such techniques. This document describes
requirements for SAM framework, especially for non-GIG environment.
2. What is SAM
The Scalable Adaptive Multicast (SAM) Research Group is chartered to
explore and research techniques which improve multicast performance
with respect to dimensions such as number of groups, dynamics of
group membership, dynamics of the network topology, and network
resource constraints. The RG will investigate approaches based on
application layer multicast (ALM), overlay multicast (OM), and native
IP multicast, as well as hybrid approaches. A key design
consideration is the placement of multicast state information along
the multicast path, including packet headers, end hosts, and network
nodes, where placement may be determined adaptively.
3. non-GIG requirement for SAM framework
The Global Information Grid (GIG)[GIG] is a large and complex
undertaking that is intended to integrate virtually all of the
information systems, services, and applications in the US Department
of Defense (DoD) into one seamless, re-liable, and secure network.
But in this document, we enumerate requirement for SAM framework
which is NOT specific to GIG.
This section describes the non-GIG requirements.
3.1 Multicast capability
SAM framework must support point to multipoint communication and may
support multipoint to multipoint communication. Native IP multicast
can support one to many bulk data transfer and broadcasting. SAM
Eiichi, et al. Expires January 2007 [Page 3]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
framework provides compliment and integrated method of one to many
and many to many communication.
3.2 Service-connectivity cycle
To start up a networking, it is quite important to minimize the
change to existing network infrastructure [MOSSDAV]. Native IP
multicast requires infrastructure support and it sometimes cause
difficulty to evolve because initial proposals always looks very
ambitions and it is very hard for multiple organizations (i.e.
carriers, ISPs) to negotiate and to agree to deploy something at the
same time. User initiate start up function and incremental
deployment function is quite important for SAM-RG to design the SAM
framework.
3.3 Scalability problems
SAM framework should support various scalabilities. This section
enumerates the scalability problems.
3.3.1 Fast routing convergence
Multicast distribution tree must be maintained even if the unicast
routing path is changed. The convergence period should be short. This
requirement is common among Native IP multicast, ALM, OM and the
future hybrid SAM solutions.
3.3.2 Dynamic topology change
Multicast forwarding functions (i.e. router or receiver) are not
always settled in fixed locations. Mobile [NEMO] and MANET [MANET]
situation might be assumed. In such a situation, the router location
and link topology are dynamically changed. Multicast distribution
tree must be maintained in such case too.
3.3.3 Group size
The number of group all over the Internet would be quite large. We
should assume millions of human group communication and multiple
sensors(i.e. machine to machine) networks all over the world.
3.3.4 Dynamic management of group membership
Many communications would be generated at the same time all over the
world. And it is necessary to assume frequent change of group
membership for the management mechanism.
3.4 Adaptivity for real-time communication
Eiichi, et al. Expires January 2007 [Page 4]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
In the real-time group communication over the best effort network,
adaptation mechanism is necessary. This section describes describe
the requirement for real-time group communication.
3.4.1 Latency (Delay sensitivity)
The end to end delay of the conversation over the network should be
shorten. The delivery path of the multipoint communication should be
optimized to shorten the total transmission delay.
3.4.2 Data rate control & Congestion avoidance
In SAM framework, overlay such approach as ALM or OM might be taken.
in such a situation, multiple delivery path might share a physical
network link. The mechanis to fairly share the bandwidth and to avoid
congestion would be necessary.
3.4.3 Redundancy path
In SAM framework, the receiver might take a part of forwarder. The
membership of the forwarding path might be unexpectedly changed
without relationship to the membership of real-time group
communication. The management mechanism should take care about such
situations.
3.5 Capability for non streaming application
There exist strong requirement of the collaboration over the
Internet. This section enumerates requirement for non streaming
application.
3.5.1 Interactive application
Internet game and collaboration tools like white board or remote
presentation are the representatives of interactive applications.
Such application might exchanges bursty or intermittent traffic
between participants. Both of latency and reliability might be the
most important for those applications.
3.5.2 File transfer
Sharing file between participants are required in multipoint group
communications. Casual file sharing like instant message should be
achieved easily in SAM framework.
3.5.3 Data collection
Data collection from remote sensor is required. Bi-directional
Eiichi, et al. Expires January 2007 [Page 5]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
distribution tree in SAM framework might be used for such purpose.
4 Interoperability of existing methods
Application layer multicast (ALM), overlay multicast (OM), and native
IP multicast are separately developed. Harmonizing of those
technologies might be one of the requirements for SAM framework. This
section explains each technology and harmonization briefly.
4.1 ALM
Application layer multicast generates distribution tree between
terminals. Logical group management function or the joining algorithm
automatically calculates optimal path for all participations.
4.2 OM
Overlay multicast connects each individual multicast enable network
by unicast tunneling. Addressing space of multicast group can be
maintain by transform function. As ALM, logical group management
function calculates optimal path between networks.
4.3 Selfish routing
Many research points out problems of selfish routing in overlay
approach [TAON], [SROU], [CMP], [ITOL], [PAA], [EEA]. The logical
group management function optimize their own performance goals not
considering system-wide criteria. It means traffic cannot be
controlled by the network operator.
4.4 Native IP multicast
Native IP multicast manages receivers in the distributed method. Edge
router aggregates tree construction request and routing algorithm
finds source and generates distribution tree between edge routers.
Trees are constructed from leaf (i.e. edge router) to root (i.e. the
source) based on the unicast routing information. Network operator
can imagine the tree construction and control it. It means trees and
traffic can be managed by the network operator.
4.5 Cooperation with Network TE in overlay approach
Network traffic could be controlled by the network operator to keep
network healthy and grown up effectively. Overlay approaches have
problem about selfish routing and bandwidth consuming. But SAM
framework should provide the chance to traffic engineering while
forming distribution tree or transmitting real-time streaming.
Eiichi, et al. Expires January 2007 [Page 6]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
4.6 eXplicit Multi-Unicast (Xcast)
eXplicit Multi-Unicast (Xcast) is a new multicast scheme with
complementary scaling properties: Xcast supports a very large number
of small multicast sessions. Xcast achieves this by explicitly
encoding the list of destinations in the data packets, instead of
using a multicast group address. Therefore, the data packets has
knowledge about distribution tree. It might means Xcast packet could
give the network operator the chance to estimate the traffic trend
and to increase the bandwidth properly.
5. Security consideration
5.1 Unexpected utilization of resources
Some overlay approach try to use the unused resource on the Internet.
They try to make efficient and robust path using other person's
resources. But in real time communication, resource might be used
heavily and continuously. It sometimes suffer the resource owner
unexpectedly. Unexpected resource use could be avoided in SAM
framework.
5.2 Authorization of group membership
Native IP multicast aggregates receiver join request at the edge
router and the edge router need not manage individual receiver in
normal case. It provides receiver initiated multipoint communication.
But it also give the chance to malicious receiver to be a black hole
sink for all multicast group. Authorization of group membership
should be supported in SAM framework.
5.3 Mechanism to limit denial of service attack
Multi-point overlay approach essentially has the function to
duplicate packet and forward to multipoint. The mechanism to limit
denial of service attack should be thought while designing SAM
framework.
5.4 Encryption and key distribution
It should be possible for a source to protect streaming content from
viewing by intermediate nodes that are not part of the group. Point
to multipoint association and key distribution mechanism should be
carefully designed.
15. Informative References
Eiichi, et al. Expires January 2007 [Page 7]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
[1112] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[1075] D. Waitzman, C. Partridge, S.E. Deering, Distance Vector Multi-
cast Routing Protocol, RFC 1075, November 1988.
[2236] W. Fenner, Internet Group Management Protocol, Version 2, RFC
2236, Nov. 1997.
[CHER] David R. Cheriton , Stephen E. Deering, Host groups: a multicast
extension for datagram internetworks, Proceedings of the ninth
symposium on Data communications, p.172-179, September 1985,
Whistler Moutain, British Columbia, Canada
[DEER] S. Deering, "Multicast Routing in a datagram internetwork", PhD
thesis, December 1991.
[DEE2] S. Deering, D. Estrin, D. Farinacci, V. Jacobson, C. Liu, and L.
Wei. The Pim Architecture for Wide-area Multicast Routing, ACM
Transactions on Networks, April 1996
[FARI] D. Farinacci, "Multicast Source Discovery Protocol", draft-fari-
nacci-msdp-00.txt, June 1998.
[3569] S. Bhattacharyya, "An Overview of Source-Specific Multicast
(SSM)", RFC 3569,July 2003
[MBONE] Frequently Asked Questions (FAQ) on the Multicast Backbone
(MBONE), ftp://venera.isi.edu/mbone/faq.txt
[2362] D. Estrin,et.al, "Protocol Independent Multicast-Sparse Mode
(PIM-SM): Protocol Specification.", RFC 2362, June 1998
[2858] T. Bates, Y. Rekhter, R. Chandra, D. Katz.,"Multiprotocol Exten-
sions for BGP-4", RFC 2858, June 2000
[RMT] Reliable Multicast Transport Working Group web site,
http://www.ietf.org/html.charters/rmt-charter.html, June 15,
1999
[ESM] Y.-H. Chu, S. G. Rao, and H. Zhang. A case for end system multi-
cast. In Proceedings of ACM Sigmetrics, June 2000.
[YOID] P. Francis. Yoid: Extending the Multicast Internet Architecture.
White papar, http://www.aciri.org/yoid/.
Eiichi, et al. Expires January 2007 [Page 8]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
[NICE] S. Banerjee, C. Kommareddy, and B. Bhattacharjee. Scalable
application layer multicast. In Proceedings of ACM SIGCOMM,Aug.
2002.
[ALMI] D. Pendarakis, S. Shi, D. Verma, and M. Waldvogel. ALMI: An
application level multicast infrastructure. In Proceedings of
the 3rd USENIX Symposium on Internet Technologies and Sys-
tems,Mar. 2001.
[TAG] M. Kwon and S. Fahmy. Topology aware overlay networks forgroup
communication. In Proceedings of NOSSDAV, May 2002
[DTO] J. Liebeherr, M. Nahas, and W. Si. Application-layer multicast-
ing with delaunay triangulation overlays. IEEE Journal on
Selected Areas in Communications, 20(8):1472?1488, Oct. 2002.
[CAN] S. Ratnasamy, M. Handley, R. Karp, and S. Shenker. Application-
level multicast using content-addressable networks. In Proceed-
ings of NGC, Nov. 2001.
[BAYEUX]
S. Q. Zhuang, B. Y. Zhao, A. D. Joseph, R. H. Katz, and J. D.
Kubiatowicz. Bayeux: An architecture for scalable and fault-tol-
erant wide-area data dissemination. In Proceedings of NOSS-
DAV'01, June 2001
[SCX] Y. Chawathe, S. McCanne, and E. A. Brewer. An Architecture for
Internet Content Distributions as an Infrastructure Service,
2000. Unpublished, http://www.cs.berkeley.edu/yatin/papers/.
[OVERCAST]
J. Jannotti, D. K. Gifford, K. L. Johnson, M. F. Kaashoek, and
J. W. O. Jr. Overcast: Reliable multicasting with an overlay
network. In Proceedings of USENIX Symposium on Operating Systems
Design and Implementation, Oct. 2000.
[RMX] Y. Chawathe, S. McCanne, and E. A. Brewer. RMX: Reliable multi-
cast for heterogeneous networks. In Proceedings of IEEE INFOCOM,
Mar. 2000.
[MSN] S. Shi and J. S. Turner. Routing in overlay multicast networks.
In Proceedings of IEEE INFOCOM, June 2002.
[OMNI] S. Banerjee, C. Kommareddy, K. Kar, B. Bhattacharjee, and S.
Khuller. Construction of an efficient overlay multicast infra-
structure for real-time applications. In Proceedings of IEEE
INFOCOM, Apr. 2003.
Eiichi, et al. Expires January 2007 [Page 9]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
[AKAMAI]
Akamai Technologies, Inc. http://www.akamai.com.
[IBEAM] iBeam Broadcasting Corp. http://www.ibeam.com.
[XCID] R. Boivie, N. Feldman , Y. Imai , W. Livens , D. Ooms, O. Pari-
daens, "Explicit Multicast (Xcast) Basic Specification", draft-
ooms-xcast-basic-spec-09.txt, December 2005.
[GIG] A. De Simone, J. Tarr,"Defining the GIG Core", draft-gig-defin-
ing-the-core-desimone-tarr-051030.pdf, October 2005.
[SAM] "Scalable Adaptive Multicast Research Group" charter,
http://www.irtf.org/charter?gtype=rg&group=samrg, June 2006.
[TAON] Junghee Han, David Watson, and Farnam Jahanian, Topology Aware
Overlay Networks, INFOCOM 2005
[SROU] Lili Qiu, Yang Richard Yang, Yin Zhang, Scott Shenker, On Self-
ish Routing in Internet-Like Environments, SIGCOMM 2003
[CMP] Li Lao, Jun-Hong Cui, Mario Gerla, Dario Maggiorini,A Compara-
tive Study of Multicast Protocols: Top, Bottom, or In theMid-
dle?, UCLA, GI2005
[ITOL] Zhi Li and Prasant Mohapatra,The Impact of Topology on Overlay
Routing Service, SIGCOMM 2003
[PAA] Zhu, W.; SunGuestEditor, M.-T.; ChenGuestEditor, L.-G.; Sikora,
T,Proceedings of the IEEE Volume 93, Issue 1, Jan 2005
[EEA] Wenjie Wang, Cheng Jin, Sugih Jamin, Network Overlay Construc-
tion under Limited End-to-End Addressability,INFOCOM2005
[MOSSDAV]
Mostafa H. Ammar, "Why Johnny Can't Multicast, Lessons about the
Evolution of the Internet", 13th Intl. Workshop on Network and
Operating Sys. Support for Digital Audio and Video (NOSSDAV
2003)
[NEMO] "Network Mobility (nemo)",IETF working group charter,
http://www.ietf.org/html.charters/nemo-charter.html
[MANET] "Mobile Ad-hoc Networks (manet)" IETF working group charter,
http://www.ietf.org/html.charters/manet-charter.html
[2434] Narten, T., and Alvestrand, H., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October, 1998.
Eiichi, et al. Expires January 2007 [Page 10]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
[2119] Bradner, S., "Key words for use in RFCs to Indicate requirement
Levels", BCP 14, RFC 2119, March 1997.
[3667] S. Bradner,"IETF Rights in Contributions",RFC 3667, February
2004
16. Authors Addresses
Eiichi Muramoto
WIDE project in Japan
E-mail: muramoto@wide.ad.jp
Yuji Imai
WIDE project in Japan
E-mail: ug@xcast.jp
Nobuo Kawaguchi
WIDE project in Japan
E-mail: kawaguti@nagoya-u.jp
17. Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
18. 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.
Eiichi, et al. Expires January 2007 [Page 11]
Internet Draftdraft-muramoto-irtf-sam-generic-require-00.txt June 2006
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eiichi, et al. Expires January 2007 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 07:15:38 |