rfc3170.txt

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

   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