rfc3170.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,463 行 · 第 1/5 页

Network Working Group                                           B. Quinn
Request for Comments: 3170                                Celox Networks
Category: Informational                                      K. Almeroth
                                                        UC-Santa Barbara
                                                          September 2001


                       IP Multicast Applications:
                        Challenges and Solutions

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the challenges involved with designing and
   implementing multicast applications.  It is an introductory guide for
   application developers that highlights the unique considerations of
   multicast applications as compared to unicast applications.

   To this end, the document presents a taxonomy of multicast
   application I/O models and examples of the services they can support.
   It then describes the service requirements of these multicast
   applications, and the recent and ongoing efforts to build protocol
   solutions to support these services.

Table of Contents

   1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.2 Focus and Scope. . . . . . . . . . . . . . . . . . . . . . . 3
   2. IP Multicast-enabled Network. . . . . . . . . . . . . . . . . . 3
     2.1 Essential Protocol Components. . . . . . . . . . . . . . . . 4
       2.1.1 Expedient Joins and Leaves . . . . . . . . . . . . . . . 5
       2.1.2 Send without a Join. . . . . . . . . . . . . . . . . . . 5
   3. IP Multicast Application Taxonomy . . . . . . . . . . . . . . . 6
     3.1 One-to-Many Applications . . . . . . . . . . . . . . . . . . 8
     3.2 Many-to-Many Applications. . . . . . . . . . . . . . . . . . 9
     3.3 Many-to-One Applications . . . . . . . . . . . . . . . . . .10
   4. Common Multicast Service Requirements . . . . . . . . . . . . .13
     4.1 Bandwidth Requirements . . . . . . . . . . . . . . . . . . .13



Quinn, et al.                Informational                      [Page 1]

RFC 3170               IP Multicast Applications          September 2001


     4.2 Delay Requirements . . . . . . . . . . . . . . . . . . . . .13
   5. Unique Multicast Service Requirements . . . . . . . . . . . . .14
     5.1 Address Management . . . . . . . . . . . . . . . . . . . . .16
     5.2 Session Management . . . . . . . . . . . . . . . . . . . . .16
     5.3 Heterogeneous Receiver Support . . . . . . . . . . . . . . .18
     5.4 Reliable Data Delivery . . . . . . . . . . . . . . . . . . .20
     5.5 Security . . . . . . . . . . . . . . . . . . . . . . . . . .21
     5.6 Synchronized Play-Out. . . . . . . . . . . . . . . . . . . .23
   6. Service APIs. . . . . . . . . . . . . . . . . . . . . . . . . .23
   7. Security Considerations . . . . . . . . . . . . . . . . . . . .24
   8. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . .24
   9. References. . . . . . . . . . . . . . . . . . . . . . . . . . .24
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .27
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .28

1. Introduction

   IP Multicast will play a prominent role on the Internet in the coming
   years.  It is a requirement, not an option, if the Internet is going
   to scale.  Multicast allows application developers to add more
   functionality without significantly impacting the network.

   Developing multicast-enabled applications is ostensibly simple.
   Having datagram access allows any application to send to a multicast
   address.  A multicast application need only increase the Internet
   Protocol (IP) time-to-live (TTL) value to more than 1 (the default
   value) to allow outgoing datagrams to traverse routers.  To receive a
   multicast datagram, applications join the multicast group, which
   transparently generates an [IGMPv2, IGMPv3] group membership report.

   This apparent simplicity is deceptive, however.  Enabling multicast
   support in applications and protocols that can scale well on a
   heterogeneous network is a significant challenge.  Specifically,
   sending constant bit rate datastreams, reliable data delivery,
   security, and managing many-to-many communications all require
   special consideration.  Some solutions are available, but many of
   these services are still active research areas.

1.1 Motivation

   The purpose of this document is to provide a framework for
   understanding the challenges of designing and implementing multicast
   applications.  In order to use multicast communications correctly,
   application developers must first understand the various I/O models
   and the network services (in addition to basic multicast
   communication) that are required.  Secondly, application developers





Quinn, et al.                Informational                      [Page 2]

RFC 3170               IP Multicast Applications          September 2001


   need to be aware of efforts underway to provide these services.  Such
   efforts range in maturity from deployed commercial products to basic
   research efforts to evaluate feasibility.

   Multicast-based applications and services will play an important role
   in the future of the Internet as continued multicast deployment
   encourages their use and development.  It is important that
   developers be aware of the issues and solutions available--and
   especially of their limitations--in order to avoid protocols that
   negatively impact networks (thereby counter-acting the benefits of
   multicast) or wasting their efforts "re-inventing the wheel".

   The hope is that by raising developers' awareness, we can adjust
   their expectations of finding solutions and lead them to successful,
   scalable, and "network-friendly" development efforts.

1.2 Focus and Scope

   Our initial premise is that the multicast infrastructure is
   transparent to applications, so it is not directly relevant to this
   discussion.  Our focus here is on multicast application protocol
   services, so this document explicitly avoids any discussion of
   multicast routing issues.  We identify and describe the multicast-
   specific issues involved with developing applications.

   We assume the reader has a general understanding of the mechanics of
   multicast, and in this respect we intend to compliment other
   introductory documents [BeauW, Maufer, Miller].  Since this is an
   introductory survey rather than a comprehensive examination, we refer
   readers to other multicast application requirements descriptions [RM,
   LSMA, Miller] for more detail.

   In the remainder of this document we first define the term "IP
   multicast enabled network", the multicast infrastructure and
   essential multicast services.  Next we describe the types of new
   functionality that multicast applications can enable and their
   requirements.  We then examine the services that satisfy these
   requirements, the challenges they present, and provide a brief survey
   of the solutions available or under development.  We wrap up with a
   discussion of application programming interfaces (APIs) for multicast
   services.

2. IP Multicast Enabled Network

   An "IP multicast-enabled network" provides end-to-end services in the
   IP network infrastructure to allow any IP host to send datagrams to
   an IP multicast address that any number of other IP hosts widely
   dispersed can receive.



Quinn, et al.                Informational                      [Page 3]

RFC 3170               IP Multicast Applications          September 2001


   There are two kinds of multicast-enabled networks available.  The
   first is based on the original multicast service model as defined in
   RFC 1112 [Deering].  In this model, a receiver simply joins the group
   and does not need to know the identity of the source(s).  This model
   is known by a number of names including Internet Standard Multicast
   (ISM), Internet Traditional Multicast (ITM), Deering multicast, etc.
   The second kind of multicast modifies the original service model such
   that in addition to knowing the group address, a receiver must know
   the set of relevant sources.  This type of multicast is called Source
   Specific Multicast (SSM) [SSM].  It becomes the application's
   responsibility to know what kind of multicast capability the network
   provides.  Currently, the only way for an application to know the
   type of multicast is based on the group address.  If the group is in
   the 232/8 range, the application should assume SSM is the service
   model.  Otherwise, the application should assume source-generic
   multicast is the service model.

   At the time of this writing, end-to-end "global" multicast service is
   not yet available, but the size of the "multicast-enabled" Internet
   is growing.  Recent development and deployment of interdomain
   multicast routing protocols and multicast-friendly Internet exchanges
   have enabled peering between major ISPs.  This, along with the
   increasing availability of compelling content, is spurring deployment
   and availability of the IP Multicast Enabled Network.

   In the remainder of this document we assume that the multicast-
   enabled network is already ubiquitous.  Since such a large and
   growing portion of the global Internet is IP multicast-enabled now,
   and many enterprise networks (intranets) are also, this perspective
   is relevant today.

2.1 Essential Protocol Components

   An IP multicast enabled network requires two essential protocol
   components:

     1) An IP host-based protocol to allow a receiver application to
        notify a local router(s) that it has joined the group, and
        initiate the data flow from all sender(s) within the scope

     2) An IP router-based protocol to allow any routers with multicast
        group members (receivers) on their local networks to communicate
        with other routers to ensure that all datagrams sent to the
        group address are forwarded to all receivers within the intended
        scope






Quinn, et al.                Informational                      [Page 4]

RFC 3170               IP Multicast Applications          September 2001


   Ideally, these protocol components are transparent to multicast
   applications.  However, there are two aspects of their functionality
   requirements that are worth mentioning specifically, since they
   affect application performance and design.  These are the multicast
   application requirements for:

     - Expedient Joins and Leaves
     - Sends without a Join

2.1.1 Expedient Joins and Leaves

   Some applications require expedient group joins and leaves, as their
   usability or functionality are sensitive to the latency involved with
   joining and leaving a group.

      Join Latency: The time it takes for data to begin flowing after an
      application issues a command to join a multicast group

      Leave Latency: The time it takes for data to stop flowing after an
      application issues a command to leave a multicast group
      [IGMPv2,IGMPv3]

   For example, using distributed a/v as a multicast-based "television"
   must allow users to "channel surf"--changing channels frequently.
   Each channel change generates a group leave and group join, so delays
   in either will affect usability.  In a sense, this is more of a user
   requirement than an application requirement.

   The functionality of distributed interactive simulations [DIS] is
   often sensitive to join/leave latency.  This is particularly true
   when trying to exchange information to represent fast moving objects
   that quickly enter and exit the scope of a simulated environment
   (e.g., low-flying, fast-moving aircraft).  If the join latency is too
   long, the information provided may be old by the time it is received.

   A fast leave phase is highly desirable both for effective congestion
   control mechanisms, to stop undesirable flows quickly, and for the
   network in general, to better filter unwanted traffic [Rizzo].
   Applications cannot affect control over either join or leave latency,
   but are dependent on the multicast infrastructure to enable expedient
   operations.  This is a basic multicast service requirement.

2.1.2 Sends without a Join

   Applications that send to a multicast address should be able to start
   sending immediately, without having to join the destination group
   first.  This is important for embedded devices and bursty-source
   applications with low-delay delivery requirements.



Quinn, et al.                Informational                      [Page 5]

RFC 3170               IP Multicast Applications          September 2001


   The current IGMP-based multicast host model and all current
   implementations allow senders to send to a group without joining it
   as a standard feature.

3. IP Multicast Application Taxonomy

   With an IP multicast-enabled network available, some unique and