GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3170

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:
  1. Expedient Joins and Leaves
  2. 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
 powerful applications and application services are possible.
 "Multicast enables coordination - it is well suited to loosely
 coupled distributed systems (of people, servers, databases,
 processes, devices...)" [Estrin].
 A "multicast application" is simply defined as any application that
 sends to and/or receives from an IP multicast address.  These may or
 may not also reference IP unicast addresses, as we describe later.
 What differentiates IP multicast applications from one-to-one unicast
 applications are the other sender and receiver relationships
 multicast enables.  There are three general categories of multicast
 applications:
    One-to-Many (1toM): A single host sending to two or more (n)
    receivers
    Many-to-Many (MtoM): Any number of hosts sending to the same
    multicast group address, as well as receiving from it
    Many-to-One (Mto1): Any number of receivers sending data back to a
    (source) sender via unicast or multicast

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

                          +-----------------------------------+
                          |        Host 2->n ("many")         |
                          +-------------+---------------------+
                          |   One-Way   |       Two-Way       |
                          +-------------+---------------------|
                          |  A      B   |   C      D      E   |
              +-----------+-------------+---------------------+
              |    I/O    |             |  S(m)/  S(u)/  S(m)/|
              | Operations| S(m)   R(m) |  R(m)   R(m)   R(u) |
  +-------+---+-----------+-------------+---------------------|
  |       | 1 | S(m)      |        1toM |  MtoM               |
  | Host  | 2 | R(m)      | Mto1        |  MtoM               |
  |       +---+-----------+-------------+                     |
  |  1    | 3 | S(m)/R(m) | Mto1   1toM    MtoM               |
  |       | 4 | S(m)/R(u) |                       Mto1        |
  |("one")| 5 | S(u)/R(m) |                              Mto1 |
  +-------+---+-----------+-----------------------------------+
        Legend:    S: "Send"          (u): "unicast"
        ------     R: "Receive"       (m): "multicast"
 Table 1: Application types characterized by I/O relationships
          and destination address types (multicast or unicast)
 Table 1 defines these application types in terms of the I/O
 relationships they represent.  These categories are defined in terms
 of the combination of communication mechanisms they use.  At the IP
 level, all multicast I/O is only 1toM or MtoM and unicast is always
 one-to-one (1to1).  The Mto1 category, for example, refers to several
 possible combinations of IP-level relationships, including unicast.
 We created the Mto1 category to help differentiate between the many
 applications and services that use multicast.
               1toM:           MtoM:            Mto1:
                R1             S1/R1             S1
               /               / | \               \
              S-R2         S2/R2-+-S3/R3         S2-R
               \...            \ | /            .../
                Rn             Sn/Rn             Sn
              Legend:  S: "Sender"
              ------   R: "Receiver"
    Figure 1: Generalization of the three application categories
 Figure 1 illustrates the general model for each of the three
 multicast application categories.  Again it is worth emphasizing that
 Mto1 is an artificial category defined by the application-level

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

 relationship between sender(s) and receiver.  At the IP-level,
 multicast does not provide an Mto1 I/O mechanism, since it does not
 allow senders to limit receivers, nor even know who they are.
 Receiver information and limitations are enabled at the application
 level, as required by the multicast application.
 We describe each of these general application types in more detail
 and provide application examples of each in the sub-sections below.
 The list of examples is not comprehensive, but attempts to define the
 prominent multicast application and service types in each of the
 three general categories.  We reference the items in these lists in
 the remainder of this document as we describe their specific service
 requirements, define the challenges they present, and reference
 solutions available or under development.

3.1 One-to-Many Applications

 One-to-Many (1toM) applications have a single sender, and multiple
 simultaneous receivers.  Entry B1 in Table 1 represents the classic
 1toM relationship.  Entry B3 differs only slightly, as the sender
 also acts as receiver (i.e., it has loopback enabled).
 When people think of multicast, they most often think of broadcast-
 based multimedia applications: television (video) and radio (audio).
 This is a reasonable analogy and indeed these are significant
 multicast applications, but these are far from the extent of
 applications that multicast can enable.  Audio/Video distribution
 represents a fraction of the multicast application possibilities, and
 most do not have analogs in today's consumer broadcast industry.
    a) Scheduled audio/video (a/v) distribution: Lectures,
       presentations, meetings, or any other type of scheduled event
       whose multimedia coverage could benefit an audience (i.e.
       television and radio "broadcasts").  One or more constant-bit-
       rate (CBR) datastreams and relatively high-bandwidth demands
       characterize these applications.  When more than one datastream
       is present--as with an audio/video combination--the two are
       synchronized and one typically has a higher priority than the
       other(s).  For example, in an a/v combination it is more
       important to ensure an intelligible audio stream, than perfect
       video.
    b) Push media: News headlines, weather updates, sports scores, or
       other types of non-essential dynamic information.  "Drip-feed",
       relatively low-bandwidth data characterize these applications.

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

    c) File Distribution and Caching: Web site content, executable
       binaries, and other file-based updates sent to distributed
       end-user or replication/caching sites
    d) Announcements: Network time, multicast session schedules,
       random numbers, keys, configuration updates, (scoped) network
       locality beacons, or other types of information that are
       commonly useful.  Their bandwidth demands can vary, but
       generally they are very low bandwidth.
    e) Monitoring: Stock prices, Sensor equipment (seismic activity,
       telemetry, meteorological or oceanic readings), security
       systems, manufacturing or other types of real-time information.
       Bandwidth demands vary with sample frequency and resolution,
       and may be either constant-bit-rate or bursty (if event-
       driven).

3.2 Many-to-Many Applications

 In many-to-Many (MtoM) applications two or more of the receivers also
 act as senders.  In other words, MtoM applications are characterized
 by two-way multicast communications.
 The many-to-many capabilities of IP multicast enable the most unique
 and powerful applications.  Each host running an MtoM application may
 receive data from multiple senders while it also sends data to all of
 them.  As a result, many-to-many applications often present complex
 coordination and management challenges.
    f) Multimedia Conferencing: Audio/Video and whiteboard comprise
       the classic conference application.  Having multiple
       datastreams with different priorities characterizes this type
       of application.  Co-ordination issues--such as determining who
       gets to talk when--complicate their development and usability.
       There are common heuristics and "rules of play", but no
       standards exist for managing conference group dynamics.
    g) Synchronized Resources: Shared distributed databases of any
       type (schedules, directories, as well as traditional
       Information System databases).
    h) Concurrent Processing: Distributed parallel processing.
    i) Collaboration: Shared document editing.
    j) Distance Learning: This is a one-to-many a/v distribution
       application with "upstream" capability that allows receivers to
       question the speaker(s).

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

    k) Chat Groups: These are like text-based conferences, but may
       also provide simulated representations ("avatars") for each
       "speaker" in simulated environments.
    l) Distributed Interactive Simulations [DIS]: Each object in a
       simulation multicasts descriptive information (e.g., telemetry)
       so all other objects can render the object, and interact as
       necessary.  The bandwidth demands for these can be tremendous,
       as the number of objects and the resolution of descriptive
       information increases.
    m) Multi-player Games: Many multi-player games are simply
       distributed interactive simulations, and may include chat group
       capabilities.  Bandwidth usage can vary widely, although
       today's first-generation multi-player games attempt to minimize
       bandwidth usage to increase the target audience (many of whom
       still use dial-up modems).
    n) Jam Sessions: Shared encoded audio (e.g., music).  The
       bandwidth demands vary based on the encoding technique, sample
       rate, sample resolution, number of channels, etc.

3.3 Many-to-One Applications

 Unlike the one-to-many and many-to-many application categories, the
 many-to-one (Mto1) category does not represent a communications
 mechanism at the IP layer.  Mto1 applications have multiple senders
 and one (or a few) receiver(s), as defined by the application layer.
 Table 1 shows that Mto1 applications can be one-way or use a two-way
 request/response type protocol, where either senders or receiver(s)
 may generate the request.  Figure 2 characterizes the I/O
 relationship possibilities in Mto1 applications:
 Mto1 applications have many scaling issues.  Too many simultaneous
 senders can potentially overwhelm receiver(s), a condition
 characterized as an "implosion problem".   Another considerable
 scaling problem is the large amount of state in the network that
 having many multicast senders generates.  This is largely transparent
 to applications and the effect may be diminished in the future with
 the use of bi-directional trees in multicast routing protocols, but
 nonetheless it should be considered by application designers.

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

 1)  S1        2)  S1            3)  S1           4)  S1
       \             \                 \                \
     S2-R          S2-R              S2-R             S2-R
    .../          .../              .../             .../
     Sn            Sn                Sn               Sn
    Data(m)     Request(m)       Request(m)       Request(u)
    ------>     ---------->     <----------       ---------->
                Response(u)      Response(u)      Response(m)
               <-----------      ----------->    <----------
     Figure 2: Characterization of Mto1 I/O possibilities
 No standards yet exist for alternate and equivalent Mto1 application
 designs, but there are a number of possibilities to consider [HNRS].
 Since the main advantage of using multicast in a Mto1 application is
 that senders need not know the receiver(s) unicast address(es), one
 alternative is for each receiver to advertise its unicast address via
 multicast.  However, since this strategy still leaves the potential
 for implosion on each receiver, additional strategies may be needed
 to distribute the load.  For example, it may be possible to increase
 the number of receivers (in a "flat" receiver topology) or establish
 localized receivers (in a "hierarchical" topology) as used in "local
 recovery" (section 5.3).  Such methods have coordination issues, and
 since standard solutions have not yet been identified, Mto1
 application developers should consider their alternatives carefully.
    o) Resource Discovery: Service Location, for example, leverages IP
       Multicast to enable something like a "host anycasting service"
       capability [AnyCast]: A multicast receiver to send a query to a
       group address, to elicit responses from the closest host so
       they can satisfy the request.  The responses might also contain
       information that allows the receiver to determine the most
       appropriate (e.g., closest) service provider to use.
          In Table 1, this application is entry D4.  It is also
          illustrated in Figure 2 by possibility number 3.
          Alternately, the response could be to a multicast rather
          than unicast address, although technically that would make
          it an MtoM application type (this is how the Service
          Location Protocol [SLP] operates, when a user agent attempts
          to locate a directory agent).
    p) Data Collection: This is the converse of a one-to-many
       "monitoring" application described earlier.  In this case there
       may be any number of distributed "sensors" that send data to a
       data collection host.  The sensors might send updates in
       response to a request from the data collector, or send

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

       continuously at regular intervals, or send spontaneously when a
       pre-defined event occurs.  Bandwidth demands can vary based on
       sample frequency and resolution.
       This is illustrated in Table 1 by entries A1 and A3, the only
       difference being that A3 has a loopback interface.  In Figure
       2, this is possibility number 1.  Since the number of receivers
       can easily be more than one, this is really an MtoM
       application.
    q) Auctions: The "auctioneer" starts the bidding by describing
       whatever it is for sale (product or service or whatever), and
       receivers send their bids privately or publicly (i.e., to a
       unicast or multicast address).
       This is possibility number 2 in Figure 2, and D5 in Table 1.
       The response could be sent to a multicast address, although
       technically that would make it an MtoM application.
    r) Polling: The "pollster" sends out a question, and the "pollees"
       respond with answers.  This is possibility number 2 in Figure
       2, and could also be characterized as an MtoM application if
       the response is to a multicast address.
    s) Jukebox: Allows near-on-demand a/v playback.  Receivers use an
       "out-of-band" protocol mechanism (via web, email, unicast or
       multicast requests, etc.) to send their playback request into a
       scheduling queue [IMJ].
       This is characterized by possibility number 4 in Figure 2, and
       entry D4 in Table 1.  The initial unicast request is the only
       difference between this type of application and a typical 1toM.
       If that initial request were sent to a multicast address, this
       would effectively be an MtoM application.
    t) Accounting: This is basically data collection but is worth
       separating since it is such an important application.  In some
       multicast applications it is imperative to know information
       about each receiver, possibly in real-time.  But such
       information can be overwhelming [MRM].  Current mechanisms,
       like RTCP (which is actually MtoM since it is multicast but
       could be made Mto1), use scaling techniques but trade-off
       information granularity.  As a group grows the total amount of
       feedback is constant but each receiver sends less.

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

4. Common Multicast Service Requirements

 Some multicast application service requirements are common to unicast
 network applications as well.  We characterize two of them here--
 bandwidth and delay requirements.

4.1 Bandwidth Requirements

 Figure 3 shows multicast applications approximate bandwidth
 requirements.
 Unicast and multicast applications both need to design applications
 to adapt to the variability of network conditions.  But as we
 describe in section 5.3, it is the need to accommodate multiple
 heterogeneous multicast receivers--with their diversity of bandwidth
 capacity and delivery delays--that presents the unique challenge for
 multicast applications to satisfy these requirements.
        |
   1toM |     b, d          c, e               a
        |
   MtoM |       k           g, i        f, h, j, l, m, n
        |
   Mto1 |   o, q, r         p, t               s
        |
        +-----------------------------------------------
          Low Bandwidth                  High Bandwidth
         Figure 3: Bandwidth Requirements of applications

4.2 Delay Requirements

 Aside from those with time-sensitive data (e.g., stock prices, and
 real-time monitoring information), most one-to-many applications have
 a high tolerance for delay and delay variance (jitter).  Constant
 bit-rate (CBR) data--such as streaming media (audio/video)--are
 sensitive to jitter, but applications commonly counteract the effects
 by buffering data and delaying playback.
 Most many-to-one and many-to-many multicast applications are
 intolerant of delays because they are bidirectional, interactive and
 request/response dependent.  As a result, delays should be minimized,
 since they can adversely affect the application's usability.
 This need to minimize delays is most evident in (two-way) conference
 applications, where users cannot converse effectively if the audio or
 video is delayed more than 500 milliseconds.  For this and other

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

 examples see Figure 4, which plots multicast applications on a
 (coarse) scale of sensitivity to delivery delays.
        |
   1toM |     b, c         a, d                e
        |
   MtoM |               g, i, j, k       f, h, l, m, n
        |
   Mto1 |      r        o, p, s, t             q
        |
        +-----------------------------------------------
          Delay Tolerant                Delay Intolerant
         Figure 4: Delay tolerance of application types
 For delay-intolerant multicast (or unicast) applications, quality of
 service (QoS) is the only option.  IP networks currently provide only
 "best effort" delivery, so data are subject to variable router
 queuing delays and loss due to network congestion (router queue
 overflows).  IP QoS standards do exist now [RSVP] and efforts to
 enable end-to-end QoS support in the Internet are underway [E2EQOS].
 However, QoS support is an IP network infrastructure consideration.
 Although there are multicast-specific challenges for implementing QoS
 in the network for multicast flows, they are beyond the control of
 applications, so further discussion of the QoS protocols and services
 is beyond the scope of this document.

5. Unique Multicast Service Requirements

 The three application categories described earlier are very general
 in nature.  Within each category and even among each of the
 application types, specific application instances have a variety of
 application requirements.  One-to-many application types are
 relatively simple to develop, but as we pointed out there are
 challenges involved with developing many-to-one and many-to-many
 applications.  Some of these have requirements bandwidth and delay
 requirements, similar to unicast applications.
 Multicast applications can be further differentiated from unicast
 applications and from each other by the services they require.  In
 this section we provide a survey of the various services that have
 unique requirements for multicast applications.

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

  +--------------------------------------------------------------+
  |                  Multicast Application                       |
  +--------------------------------------+   +-------------------+
  +-------------------------------------+|   |+--------++--------+
  |          Multicast Security         ||   ||        ||        |
  +----------------------+   +----------+|   || System ||        |
  +----------++---------+|   |+---------+|   ||  Time  || Codecs |
  | Reliable || Address ||   || Session ||   ||        ||        |
  | Delivery ||   Mgt   ||   ||   Mgt   ||   ||        ||        |
  +----------++---------++---++---------++---++--------++--------+
  +----------------------------------------++--------------------+
  |     Basic IP Multicast Service         ||     IP Unicast     |
  |       (e.g., UDP and IGMPv2/v3)        ||      Service       |
  +----------------------------------------++--------------------+
          Figure 5: Multicast service requirements summary
 Here's the list of multicast application service requirements:
    Address Management - Selection and coordinated of address
    allocation.  The need is to provide assurances against "address
    collision" and to provide address ownership.
    Session Management - Perform application-layer services on top of
    multicast transport.  These services depend heavily on the
    application but include functions like session advertisement,
    billing, group member monitoring, key distribution, etc.
    Heterogeneous Receiver Support - Sending to receivers with a wide
    variety of bandwidth capacities, latency characteristics, and
    network congestion requires feedback to monitor receiver
    performance.
    Reliable Data Delivery - Ensuring that all data sent is received
    by all receivers.
    Security - Ensuring content privacy among dynamic multicast group
    memberships, and limiting senders.
    Synchronized Play-Out - Allow multiple receivers to "replay" data
    received in synchronized fashion.
 In the remainder of this section, we describe each of these
 application services in more detail, the challenges they present, and
 the status of standardized solutions.

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

5.1 Address Management

 One of the first questions facing a multicast application developer
 is what multicast address to use.  Multicast addresses are not
 assigned to individual hosts, assignments can change dynamically, and
 addresses sometimes have semantics of their own (e.g., Admin
 Scoping).  Multicast applications require an address management
 service that provides address allocation or assignment queries.
 There are a number of ways for applications to learn about multicast
 addresses:
    Hard-Coded: Software configuration, encoded in a binary
    executable, or burned into ROM in embedded devices.  These
    applications typically reference IANA statically allocated
    multicast addresses (including relative addresses).
    Advertised: Session announcements (as described in the next
    section), or via another "out-of-band" query or discovery protocol
    mechanism.
    Algorithmically Derived: Using a programmatic algorithm to
    allocate a statistically random (unused) address.
      |
 1toM |    c, e          a, b                d
      |
 MtoM |               f, j, k, n        g, h, i, l, m
      |
 Mto1 |    r            o, p, s             q, t
      |
      +-----------------------------------------------
        Hard-Coded       Advertised      Algorithmic
    Figure 6: Multicast address usage for application types
 In almost all cases, application designers should assume that
 multicast addresses are to be dynamic.  Very little of the multicast
 address space is available for static assignment by IANA [MADDR].
 Also, given the host-specific addressing available with SSM,
 Internet-wide, static address assignment is expected to be very rare.

5.2 Session Management

 Session management is one of the most misunderstood services with
 respect to multicast.  Most application developers assume that
 multicast will provide services like security, encryption,
 reliability, session advertisement, monitoring, billing, etc.  In
 fact, multicast is simply a transport mechanism that provides end-

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

 to-end delivery.  All of the other services are application-layer
 services that must be provided by each particular application.
 Furthermore, in most cases there are not defined standards for how
 these functions should be provided.  The particular functions are
 dependent on the particular needs of the application, and no single
 method (or standard) can be made to be sufficient for all cases.
 While there are no generic solutions which provide all session
 management functions, there are some protocols and common techniques
 that provide support for some of the functions.  Techniques for
 congestion control and heterogeneous receiver support are discussed
 in Section 5.3.  Protocols for reliability are discussed in Section
 5.4.  Security considerations are discussed in Section 5.5.
 With respect to session advertisement, there are a number of
 mechanisms for advertising sessions.  One commonly used technique is
 to advertise sessions via the WWW.  Users can join a group by
 clicking on URLs, and then having a response returned to the user
 that includes the group address and maybe information about group
 source(s).  Another mechanism is the session description protocol
 [SDP].  It provides a format for representing information about
 sessions, but it does not provide the transport for dissemination of
 these session descriptions, nor does it provide address allocation
 and management.  SDP only provides the syntax for describing session
 attributes.
 SDP session descriptions may be conveyed publicly or privately by
 means of any number of transports including web (HTTP) and MIME
 encoded email.  The session announcement protocol [SAP] is the de
 facto standard transport and many multicast-enabled applications
 currently use it.  SAP limits distribution via multicast scoping, but
 the current protocol definition has scaling issues that need to be
 addressed.  Specifically, the initialization latency for a session
 directory can be quite long, and it increases in proportion to the
 number of session announcements.  This is to an extent a multicast
 infrastructure issue, however, as this level of protocol detail
 should be transparent to applications.
 The session management service needs to:
  1. Advertise scheduled sessions
  2. Provide a query mechanism for retrieving

information about session schedules

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

5.3 Heterogeneous Receiver Support

 The Internet is a network of networks.  IP's strength is its ability
 to enable seamless interoperability between hosts on disparate
 network media, the heterogeneous network.
 When two hosts communicate via unicast--one-to-one--across an IP
 network, it is relatively easy for senders to adapt to varying
 network conditions.  The Transmission Control Protocol (TCP) provides
 reliable data transport, and is the model of "network friendly"
 adaptability.
 TCP receivers send acknowledgements back to the sender for data
 delivered.  A TCP sender detects data loss from the data sent that is
 not acknowledged.  When it detects data loss, TCP infers that there
 is network congestion or a low-bandwidth link, and adapts by
 throttling down its send rate [SlowStart].
 User Datagram Protocol (UDP) does not enable a receiver feedback loop
 the way TCP does, since UDP does not provide reliable data delivery
 service.  As a result, it also does not have a loss detection and
 adaptive congestion control mechanism as TCP does.  However, it is
 possible for a unicast UDP application to enable similar adaptive
 algorithms to achieve the same result, or even improve on it.
 A unicast UDP application that uses a feedback mechanism to detect
 data loss and adapt the send rate, can do so better than TCP.  TCP
 automatically reduces the "congestion window" when data loss is
 detected, although the updated send rate may be slower than a CBR
 audio/video stream requires.  When a UDP application detects loss, it
 can adapt the data itself to accommodate the lower send rate.  For
 example, a UDP application can:
  1. Reduce the data resolution (e.g., send lower fidelity

audio/video by reducing sample frequency or frame rate) to

      reduce data rate.
  1. Modify the data encoding to add redundant data (e.g., forward

error correction) offset in time to avoid fate sharing. This

      could also be "layered", so a percentage of data loss will
      simply reduce fidelity rather than corrupt the data.
  1. Reduce the send rate of one datastream in order to favor another

of higher priority (e.g., sacrifice video in order to ensure

      audio delivery).

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

  1. Send data at a lower rate (i.e., with a different encoding) on a

separate multicast address and/or port number for high-loss

      receivers.
 However, with multicast applications--one-to-many or many-to-many--
 which have multiple receivers, the feedback loop design needs
 modification.  If all receivers return data loss reports
 simultaneously, the sender is easily overwhelmed in the storm of
 replies.  This is known as the "implosion problem".
 Another problem is that heterogeneous receiver capabilities can vary
 widely due to the wide range of (static) network media bandwidth
 capabilities and dynamically due to transient traffic conditions.  If
 a sender adapts its send rate and data resolution based on the loss
 rate of its worst receiver(s), then it can only service the lowest
 common denominator.  Hence, a single "crying baby" can spoil it for
 all other receivers.
 Strategies exist for dealing with these heterogeneous receiver
 problems.  Here are two examples:
   Shared Learning - When loss is detected (i.e., a sequenced packet
      isn't received), a receiver starts a random timer.  If it
      receives a data loss report sent by another receiver as it waits
      for the timer to expire, it stops the timer and does not send a
      report.  Otherwise, it sends a report when the timer expires.
      The Real-Time Protocol and its feedback-loop counterpart Real-
      Time Control Protocol [RTP/RTCP] employ a strategy similar to
      this to keep feedback traffic to 5 percent or less than the
      overall session traffic.  This technique was originally utilized
      in IGMP.
   Local Recovery - Some receivers may be designated as local
      distribution points or "transcoders" that either re-send data
      locally (possibly via unicast) when loss is reported or they re-
      encode the data for lower bandwidth receivers before re-sending.
      No standards exist for these strategies, although "local
      recovery" is used by several reliable multicast protocols.
 Adaptive multicast application design for heterogeneous receivers is
 still an active area of research.  The fundamental requirements are
 to maximize application usability, while accommodating network
 conditions in a "network friendly" manner.  In other words,
 congestion detection and avoidance are (at least) as important in
 protocol design as the user experience.  The adaptive mechanisms must
 also be stable, so they do not adapt too quickly--changing encoding
 and rates based on too little information about what may be a
 transient condition--to avoid oscillation.

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

 This "feedback loop" service necessary for support of heterogeneous
 receivers is not illustrated in the services summary in Figure 4,
 although it could be added alongside "Reliable Transport" and the
 others.  This service could be implemented within an application or
 accessed externally, as provided by the operating system or a third
 party.  See [HNRS] for a taxonomy of strategies for providing
 feedback for multicast, with the ultimate goal of developing a common
 multicast feedback protocol.

5.4 Reliable Data Delivery

 Many of the multicast application examples in our list--like
 audio/video distribution--have loss-tolerant data content.  In other
 words, the data content itself can remain useful even if some of it
 is lost.  For example, audio might have a short gap or lower fidelity
 but will remain intelligible despite some data loss.
 Other application examples--like caching and synchronized resources-
 -require reliable data delivery.  They deliver content that must be
 complete, unchanged, in sequence, and without duplicates.  The "Loss
 Intolerant" column in Figure 7 shows a list of applications with this
 requirement, while the others can tolerate varying levels of data
 loss.  The tolerance levels are typically determined by the nature of
 the data and the encoding in use.
      |
 1toM |     b             a, d               c, e
      |
 MtoM |             f, j, k, l, m, n       g, h, i
      |
 Mto1 |                o, p, r, s, t          q
      |
      +------------------------------------------------
        Loss Tolerant                   Loss Intolerant
    Figure 7: Reliability Requirements of Application types
 Some of the challenges involved with enabling reliable multicast
 transport are the same as those of sending to heterogeneous
 receivers, and some solutions are similar also.  For example, many
 reliable multicast transport protocols avoid the implosion problem by
 using negative acknowledgements (NAKs) from receivers to indicate
 what was lost.  They also use "shared learning" whereby receivers
 listen to others' NAKs and then listen for the resulting
 retransmission of data, rather than requesting retransmission by
 sending a NAK themselves.

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

 Although reliable delivery cannot change the data sent--except,
 perhaps, to use a loss-less data compression algorithm--they can use
 other adaptive techniques like sending redundant data, or adjusting
 the send rate.
 Although many reliable multicast protocol implementations exist
 [Obraczka], and a few are already available in commercial products,
 none of them are standardized.  Work is ongoing in the "Reliable
 Multicast" research group of the Internet Research Task Force [IRTF]
 to provide a better definition of the problem, the multicast
 transport requirements, and protocol mechanisms.
 Scalability is the paramount concern, and it implies the general need
 for "network friendly" protocols that detect and avoid congestion as
 they provide reliable delivery.  Other considerations are protocol
 robustness, support for "late joins", group management and security
 (which we discuss next).
 The current consensus is that due to the wide variety of multicast
 application requirements--some of which are at odds--no single
 multicast transport will likely be appropriate for all applications.
 As a result, most believe that we will eventually standardize a
 number of reliable multicast protocols, rather than a single one
 [BULK, RMT].

5.5 Security

 For any IP network application--unicast or multicast--security is
 necessary because networks comprise users with different levels of
 trust.
 Network application security is challenging, even for unicast.  And
 as the need for security increases--gauged by the risks of being
 without it--the challenges increase also.  Security system complexity
 and overhead is commensurate with the protection it provides.  "No
 one can guarantee 100% security.  But we can work toward 100% risk
 acceptance...Strong cryptography can withstand targeted attacks up to
 a point--the point at which it becomes easier to get the information
 some other way...A good design starts with a threat model: what the
 system is designed to protect, from whom, and for how long."
 [Schneier]
 Multicast applications are no different than unicast applications
 with respect to their need for security, and they require the same
 basic security services: user authentication, data integrity, data
 privacy and user privacy (anonymity).  However, enabling security for

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

 multicast applications is even more of a challenge than for unicast.
 Having multiple receivers makes a difference, as does their
 heterogeneity and the dynamic nature of multicast group memberships.
 Multicast security requirements can include any combination of the
 following services:
    Limiting Senders   - Controlling who can send to group addresses
    Limiting Receivers - Controlling who can receive
    Limiting Access    - Controlling who can "read" multicast content
    either by encrypting content or limiting receivers (which isn't
    possible yet)
    Verifying Content  - Ensuring that data originated from an
    authenticated sender and was not altered en route
    Protecting Receiver Privacy - Controlling whether sender(s) or
    other receivers know receiver identity
    Firewall Traversal - Proxying outgoing "join" requests through
    firewalls, allowing incoming or outgoing traffic through, and
    (possibly) authenticating receivers for filtering purposes and
    security [Finlayson].
 This list is not comprehensive, but includes the most commonly needed
 security services.  Different multicast applications and different
 application contexts can have very different needs with respect to
 these services, and others.  Two main issues emerge, where the
 performance of current solutions leaves much to be desired [MSec].
    Individual authentication - how is sender identity verified for
    each multicast datagram received?
    Membership revocation - how is further group access disabled for
    group members that leave the group (e.g., encryption keys in their
    possession disabled)?
 Performance is largely a factor when a user joins or leaves a group.
 For example, methods used to authenticate potential group members
 during joins or re-keying current members after a member leaves can
 involve significant processing and protocol overhead and result in
 significant delays that affect usability.

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

 Like reliable multicast, secure multicast is also under investigation
 in the Internet Research Task Force [IRTF].  Protocol mechanisms for
 many of the most important of these services--such as limiting
 senders--have not yet been defined, let alone developed and deployed.
 As is true for reliable multicast, the current consensus is that no
 single security protocol will satisfy the wide diversity of
 sometimes-contradictory requirements among multicast applications.
 Hence, multicast security will also likely require a number of
 different protocols.

5.6 Synchronized Play-Out

 This refers to having all receivers simultaneously play-out the
 multicast data they received.  This may be necessary for fairness--
 playing-out prices for auctions, or stock-prices--or to ensure
 synchronization with other receivers, such as when playing music.
 Here is an analogy to illustrate: Imagine a multi-speaker stereo
 system that is wired throughout a home (via analog).  With the stereo
 playing on all speaker sets, you will hear continuous music as you
 walk from room-to-room.
 Now imagine a house full of multi-media and network enabled computer
 systems.  Although they will all receive the same music datastream
 simultaneously via multicast, they will provide discontinuous music
 playback as you walk room-to-room.
 To provide synchronized playback that would enable continuous music
 from room-to-room would require three things:
    1) system clocks on all systems should be synchronized
    2) datastreams must be framed with timestamps
    3) you must know the playback latency of the multimedia hardware
 The third of these is the most difficult to achieve at this time.
 Hardware and drivers don't provide any mechanism for retrieving this
 information, although different audio and video devices have a wide-
 range of performance.

6. Service APIs

 In some cases, the protocol services mentioned in this document can
 be enabled transparently by passive configuration mechanisms and
 "middleware". For example, it is conceivable that a UDP
 implementation could implicitly enable a reliable multicast protocol
 without the explicit interaction of the application.

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

 Sometimes, however, applications need explicit access to these
 services for flexibility and control.  For example, an adaptive
 application sending to a heterogeneous group of receivers using RTP
 may need to process RTCP reports from receivers in order to adapt
 accordingly (by throttling send rate or changing data encoders, for
 example) [RTP API].  Hence, there is often a need for service APIs
 that allow an application to qualify and initiate service requests,
 and receive event notifications.  In Figure 5, the top edge of the
 box for each service effectively represents its API.
 Network APIs generally reflect the protocols they support.  Their
 functionality and argument values are a (varying) subset of protocol
 message types, header fields and values.  Although some protocol
 details and actions may not be exposed in APIs--since many protocol
 mechanics need not be exposed--others are crucial to efficient and
 flexible application operation.
 A more complete examination of the application services described in
 this document might also identify the protocol features that could be
 mapped to define a (generic) API definition for that service.  APIs
 are often controversial, however.  Not only are there many language
 differences, but it is also possible to create different APIs by
 exposing different levels of detail in trade-offs between flexibility
 and simplicity.

7. Security Considerations

 See section 5.4

8. Acknowledgements

 The authors would like to acknowledge and thank the following
 individuals for their helpful feedback: Ran Canetti, Brian Haberman,
 Eric A. Hall, Kenneth C. Miller, and Dave Thaler.

9. References

 [AnyCast]   Partridge, C., Mendez, T. and W. Milliken, "Host
             Anycasting Service", RFC 1546, November 1993.
 [BeauW]     B. Williamson, "Developing IP Multicast Networks, Volume
             I", (c) 2000 Cisco Press, Indianapolis IN, ISBN 1-57870-
             077-9.
 [BULK]      Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
             Floyd, S. and M. Luby, "Reliable Multicast Transport
             Building Blocks for One-to-Many Bulk-Data Transfer", RFC
             3048, January 2001.

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

 [Deering]   Deering, S., "Host Extensions for IP Multicasting", STD
             5, RFC 1112, August 1989.
 [DIS]       Pullen, J., Mytak, M. and C. Bouwens, "Limitations of
             Internet Protocol Suite for Distributed Simulation in the
             Large Multicast Environment", RFC 2502, February 1999.
 [E2EQOS]    Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L.,
             Speer, M., Braden, R. and B. Davie, "Integrated Services
             Operation over Diffserv Networks", RFC 2998, November
             2000.
 [Estrin]    D. Estrin, "Multicast: Enabler and Challenge", Caltech
             Earthlink Seminar Series, April 22, 1998.
 [Finlayson] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
             May 1999.
 [HNRS]      Hofman, Nonnenmacher, Rosenberg, Schulzrinne, "A Taxonomy
             of Feedback for Multicast", June 1999, Work in Progress.
 [IGMPv2]    Fenner, B., "Internet Group Management Protocol, Version
             2", RFC 2236, November 1997.
 [IGMPv3]    Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan,
             "Internet Group Management Protocol, Version 3", Work in
             Progress.
 [IMJ]       K. Almeroth and M. Ammar, "The Interactive Multimedia
             Jukebox (IMJ): A New Paradigm for the On-Demand Delivery
             of Audio/Video", Proceedings of the Seventh International
             World Wide Web Conference, Brisbane, AUSTRALIA, April
             1998.
 [IRTF]      Weinrib, A. and J. Postel, "The IRTF Guidelines and
             Procedures", BCP 8, RFC 2014, January 1996.
 [Kermode]   Kermode, R., "MADCAP Multicast Scope Nesting State
             Option", RFC 2907, September 2000.
 [LSMA]      Bagnall, P., Briscoe, R. and A. Poppitt, "Taxonomy of
             Communication Requirements for Large-scale Multicast
             Applications", RFC 2729, December 1999.
 [MADDR]     Albanna, Z., Almeroth, K., Meyer, D. and M. Schipper,
             "IANA Guidelines for IPv4 Multicast Address Assignments",
             BCP 51, RFC 3171, August 2001.

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

 [MASC]      Estrin, D., Govindan, R., Handley, M., Kumar, S.,
             Radoslavov, P. and D. Thaler, "The Multicast Address-Set
             Claim (MASC) Protocol", RFC 2909, September 2000.
 [Maufer]    T. Maufer, "Deploying IP Multicast in the Enterprise",
             (c) 1998 Prentice Hall, Upper Saddle River NJ ISBN 0-13-
             897687-2.
 [Miller]    C. K. Miller, "Multicast Networking and Applications",
             (c) 1999 Addison Wesley Longman, Reading MA ISBN 0-201-
             30979-3.
 [MADCAP]    Hanna, S., Patel, B. and M. Shah, "Multicast Address
             Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
             December 1999.
 [MRM]       K. Sarac, K. Almeroth, "Supporting Multicast Deployment
             Efforts: A Survey of Tools for Multicast Monitoring",
             Journal of High Speed Networking--Special Issue on
             Management of Multimedia Networking, March 2001
 [MSec]      Multicast Security (msec) IETF Working Group charter
 [MZAP]      Handley, M., Thaler, D. and R. Kermode, "Multicast-Scope
             Zone Announcement Protocol (MZAP)", RFC 2776, February
             2000.
 [Obraczka]  K. Obraczka "Multicast Transport Mechanisms: A Survey and
             Taxonomy", IEEE Communications Magazine, Vol. 36 No. 1,
             January 1998.
 [Rizzo]     L. Rizzo, "Fast Group management in IGMP", HIPPARC 98
             workshop, June 1998, UCL London
             http://www.iet.unipi.it/~luigi/hipparc98.ps.gz
 [RM]        Mankin, A.,  Romanow, A., Bradner, S. and V. Paxson,
             "IETF Criteria for Evaluating Reliable Multicast
             Transport and Application Protocols", RFC 2357, June
             1998.
 [RSVP]      Wroclawski, J., "The Use of RSVP with IETF Integrated
             Services", RFC 2210, September 1997.
 [RTP API]   H. Schulzrinne, et al, "RTP Library API Specification,"
             http://www.cs.columbia.edu/IRT/software/rtplib/rtplib-
             1.0a1/rtp_api.html

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

 [RTP/RTCP]  Schulzrinne, H., Casner, S., Frederick, R. and V.
             Jacobson, "RTP: A Transport Protocol for Real-Time
             Applications", RFC 1889, January 1996.
 [SAP]       Handley, M., Perkins, C. and E. Whelan, "Session
             Announcement Protocol", RFC 2974, October 2000.
 [SDP]       Handley, M., and V. Jacobson, "SDP: Session Description
             Protocol", RFC 2327, April 1998.
 [Schneier]  B. Schneier, "Why Cryptography Is Harder Than It Looks",
             December 1996, http://www.counterpane.com/whycrypto.html
 [SlowStart] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
             Retransmit, and Fast Recovery Algorithms", RFC 2001,
             January 1997.
 [SLP]       Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
             "Service Location Protocol", RFC 2165, June 1997.
 [SSM]       Holbrook, H. and B. Cain, "Specific Multicast for IP",
             Work in Progress.

10. Authors' Addresses

 Bob Quinn
 Celox Networks
 2 Park Central Drive
 Southborough, MA 01772
 Phone: +1 508 305 7000
 EMail: bquinn@celoxnetworks.com
 Kevin Almeroth
 Department of Computer Science
 University of California
 Santa Barbara, CA 93106-5110
 Phone: +1 805 893 2777
 EMail: almeroth@cs.ucsb.edu

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

11. Full Copyright Statement

 Copyright (C) The Internet Society (2001).  All Rights Reserved.
 This document and translations of it may be copied and furnished to
 others, and derivative works that comment on or otherwise explain it
 or assist in its implementation may be prepared, copied, published
 and distributed, in whole or in part, without restriction of any
 kind, provided that the above copyright notice and this paragraph are
 included on all such copies and derivative works.  However, this
 document itself may not be modified in any way, such as by removing
 the copyright notice or references to the Internet Society or other
 Internet organizations, except as needed for the purpose of
 developing Internet standards in which case the procedures for
 copyrights defined in the Internet Standards process must be
 followed, or as required to translate it into languages other than
 English.
 The limited permissions granted above are perpetual and will not be
 revoked by the Internet Society or its successors or assigns.
 This document and the information contained herein is provided on an
 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 TASK FORCE DISCLAIMS 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.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Quinn, et al. Informational [Page 28]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3170.txt · Last modified: 2001/09/10 18:02 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki