rfc1458.txt

RFC 的详细文档！

Network Working Group                                        R. Braudes
Request for Comments: 1458                                    S. Zabele
                                                                   TASC
                                                               May 1993


                  Requirements for Multicast Protocols

Status of this Memo

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

Summary

   Multicast protocols have been developed over the past several years
   to address issues of group communication.  Experience has
   demonstrated that current protocols do not address all of the
   requirements of multicast applications.  This memo discusses some of
   these unresolved issues, and provides a high-level design for a new
   multicast transport protocol, group address and membership authority,
   and modifications to existing routing protocols.

Table of Contents

   1.    Introduction  . . . . . . . . . . . . . . . . . . . . . . .   2
   2.    The Image Communication Problem   . . . . . . . . . . . . .   2
   2.1   Scope   . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.2   Requirements  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.    Review of Existing Multicast Protocols  . . . . . . . . . .   4
   3.1   IP/Multicast  . . . . . . . . . . . . . . . . . . . . . . .   4
   3.2   XTP   . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.3   ST-II   . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.4   MTP   . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   3.5   Summary   . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.    Reliable Adaptive Multicast Service   . . . . . . . . . . .   9
   4.1   The Multicast Group Authority   . . . . . . . . . . . . . .   9
   4.1.1 Address Management  . . . . . . . . . . . . . . . . . . . .   9
   4.1.2 Service Registration, Requests, Release, and Group
         Membership Maintenance  . . . . . . . . . . . . . . . . . .  10
   4.2   The Reliable Adaptive Multicast Protocol (RAMP)   . . . . .  11
   4.2.1 Quality of Service Levels   . . . . . . . . . . . . . . . .  12
   4.2.2 Error Recovery  . . . . . . . . . . . . . . . . . . . . . .  12
   4.2.3 Flow Control  . . . . . . . . . . . . . . . . . . . . . . .  13
   4.3   Routing Support   . . . . . . . . . . . . . . . . . . . . .  14
   4.3.1 Path Set-up   . . . . . . . . . . . . . . . . . . . . . . .  14
   4.3.2 Path Tear-down  . . . . . . . . . . . . . . . . . . . . . .  15



Braudes & Zabele                                                [Page 1]

RFC 1458          Requirements for Multicast Protocols          May 1993


   4.3.3 Multicast Routing Based on Quality of Service   . . . . . .  15
   4.3.4 Quality of Service Based Packet Loss  . . . . . . . . . . .  15
   5.    Interactions Among the Components: An Example   . . . . . .  15
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  18
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  18
   Security Considerations   . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

1.  Introduction

   Multicast protocols have been developed to support group
   communications.  These protocols use a one-to-many paradigm for
   transmission, typically using class D Internet Protocol (IP)
   addresses to specify specific multicast groups.  While designing
   network services for reliable transmission of very large imagery as
   part of the DARPA-sponsored ImNet program, we have reviewed existing
   multicast protocols and have determined that none meet all of the
   requirements of image communications [3].  This RFC reviews the
   current state of multicast protocols, highlights the missing
   features, and motivates the design and development of an enhanced
   multicast protocol.

   First, the requirements for network services and underlying protocols
   related to image communications are presented.  Existing protocols
   are then reviewed, and an analysis of each protocol against the
   requirements is presented.  The analyses identify the need for a new
   multicast protocol.  Finally, the features of an ideal reliable
   multicast protocol that adapts to network congestion in the
   transmission of large data volumes are presented.  Additional network
   components needed to fully support the new protocol, including a
   Multicast Group Authority and modifications to existing routing
   protocols, are also introduced.

2.  The Image Communications Problem

2.1 Scope

   Image management and communications systems are evolving from film-
   based systems toward an all-digital environment where imagery is
   acquired, transmitted, analyzed, and stored using digital computer
   and communications technologies.  The throughput required for
   communicating large numbers of very large images is extremely large,
   consisting of thousands of terabytes of imagery per day.  Temporal
   requirements for capture and dissemination of single images are
   stringent, ranging from seconds to at most several minutes.  Imagery
   will be viewed by hundreds of geographically distributed users who
   will require on-demand, interactive access to the data.




Braudes & Zabele                                                [Page 2]

RFC 1458          Requirements for Multicast Protocols          May 1993


   Traditional imaging applications involve images on the order of 512
   by 512 pixels.  In contrast, a single image used for remote sensing
   can have tens of thousands of pixels on a side.  Multiplying the data
   volume associated with remotely sensed images by even a small number
   of users clearly motivates moving beyond the current suite of
   reliable protocols.

   Basic image communication applications involve distribution of
   individual images to multiple users for both individual and
   collaborative analyses, and network efficiency requires the use of
   multicast protocols.  Areas where multicasting offers significant
   advantages include real-time image acquisition and dissemination,
   distribution of annotated image-based reports, and image
   conferencing.  Images are viewed on a heterogeneous set of
   workstations with differing processing and display capabilities,
   traveling over a heterogeneous network with bandwidths varying by up
   to six orders of magnitude between the initial down link and the
   slowest end user.

2.2 Requirements

   Multicast protocols used for image communications must address
   several requirements.  Setting up a multicast group first requires
   assigning a multicast group address.  All multicast traffic is then
   delivered to this address, which implies that all members of the
   group must be listening for traffic with this address.

   Within an image communications architecture such as that used for the
   ImNet program, diversity and adaptability can be accommodated by
   trading quality of service (i.e., image quality) with speed of
   transmission.  Multicast support for quality-speed trades can be
   realized either through the use of different multicast groups, where
   each group receives a different image quality, or through the use of
   a single hierarchical stream with routers (or users) extracting
   relevant portions.

   Due to the current inability of routers to support selective
   transmission of partial streams, a multiple stream approach is being
   used within ImNet.  Efficient operation using a multiple stream
   approach requires that users be able to switch streams very quickly,
   and that streams with no listeners not be disseminated.
   Consequently, rapid configuration of multicast groups and rapid
   switching between multicast groups switching is essential.

   Inevitably, network congestion or buffer overruns result in packet
   loss. A full range of transport reliability is required within an
   image communications framework. For some applications such as image
   conferencing, packet loss does not present a problem as dropped mouse



Braudes & Zabele                                                [Page 3]

RFC 1458          Requirements for Multicast Protocols          May 1993


   movements can be discarded with no meaningful degradation in utility.
   However, for functions such as image archiving or detailed image
   analysis, transport must be completely reliable, where any dropped
   packets must be retransmitted by the sender.  Additionally, several
   hierarchical image compression methods can provide useful, albeit
   degraded, imagery using a semi-reliable service, where higher level
   data is transmitted reliably and the lower level data is transmitted
   unreliably.

   In support of reliable transport, image communications services must
   also support adaptation to network congestion using flow control
   mechanisms.  Flow control regulates the quantity of data placed on
   the network per unit time interval, thereby increasing network
   efficiency by reducing the number of dropped packets and avoiding the
   need for large numbers of retransmissions.

3.  Review of Existing Multicast Protocols

   Several existing protocols provide varying levels of support for
   multicasting, including IP/Multicast [5], the Xpress Transfer
   Protocol (XTP) [11], and Experimental Internet Stream Protocol
   Version 2 (ST-II) [10].  While the Versatile Message Transaction
   Protocol (VMTP) [4] also supports multicast, it has been designed to
   support the transfer of small packets, and so is not appropriate for
   large image communications.  Additionally, a specification exists for
   the Multicast Transport Protocol (MTP) [2].

   The image communication requirements for a multicast protocol include
   multicast group address assignment, group set-up, membership
   maintenance (i.e., join, drop, and switch membership), group tear-
   down, error recovery, and flow control, as presented above.  The
   remainder of this section discusses how well each of the existing
   protocols meets these requirements.

3.1 IP/Multicast

   IP/Multicast is an extension to the standard IP network-level
   protocol that supports multicast traffic.  IP/Multicast has no
   address allocation mechanism, with addresses assigned either by an
   outside authority or by each application.  This has the potential for
   address contention among multiple applications, which would result in
   the traffic from the different groups becoming commingled.

   There is no true set-up processing for IP/Multicast; once an address
   is determined, the sender simply transmits packets to that address
   with routers determining the path(s) taken by the data.  The receiver
   side is only slightly more complex, as an application must issue an
   add membership request for IP to listen to traffic destined to the



Braudes & Zabele                                                [Page 4]

RFC 1458          Requirements for Multicast Protocols          May 1993


   desired address.  If this is the first member of a group, IP
   multicasts the request to routers on the local network using the
   Internet Group Multicast Protocol (IGMP) for inclusion in routing
   tables.  Multicast packets are then routed like all other IP packets,
   with receivers accepting traffic addressed to joined groups in
   addition to the normal host address.

   A major problem with the IP/Multicast set-up approach is informing
   hosts of multicast group addresses.  If addresses are dynamically
   allocated, then a mechanism must be established for informing
   receivers which addresses have been assigned to which groups.  This
   requires a minimum of one round trip time, with an address requested
   from a server and then returned to the receiver.

   Dropping membership in a group involves issuing a request to the
   local IP, which decrements the count of members in the IP tables.
   However, no special action is taken when group membership goes to
   zero.  Instead, a heartbeat mechanism is used in which hosts are
   periodically polled for active groups, and routers stop forwarding
   group traffic to a network only after several polls receive no
   activity requests for that group to ensure that a membership report
   is not lost or corrupted in transit.  This causes the problem of
   unneeded traffic being transmitted, due to a long periodicity for the
   heartbeat (minimum of one minute between polls); consequently there
   is no method for quickly dropping a group over a given path, impeding
   attempts to react to network congestion in real-time.

   Finally, there is no transport level protocol compatible with
   IP/Multicast that is both reliable and implements a flow control
   mechanism.

3.2 XTP

   XTP is a combined network and transport level protocol that offers
   significant support for multicast transfers.  As with IP/Multicast,
   XTP offers no inherent address management scheme, so that an outside
   authority is required.