rfc3048.txt

最新的RFC

Network Working Group                                         B. Whetten
Request for Comments: 3048                                      Talarian
Category: Informational                                      L. Vicisano
                                                                   Cisco
                                                              R. Kermode
                                                                Motorola
                                                              M. Handley
                                                                 ACIRI 9
                                                                S. Floyd
                                                                   ACIRI
                                                                 M. Luby
                                                        Digital Fountain
                                                            January 2001


      Reliable Multicast Transport Building Blocks for One-to-Many
                           Bulk-Data Transfer

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 a framework for the standardization of bulk-
   data reliable multicast transport.  It builds upon the experience
   gained during the deployment of several classes of contemporary
   reliable multicast transport, and attempts to pull out the
   commonalities between these classes of protocols into a number of
   building blocks.  To that end, this document recommends that certain
   components that are common to multiple protocol classes be
   standardized as "building blocks".  The remaining parts of the
   protocols, consisting of highly protocol specific, tightly
   intertwined functions, shall be designated as "protocol cores".
   Thus, each protocol can then be constructed by merging a "protocol
   core" with a number of "building blocks" which can be re-used across
   multiple protocols.








Whetten, et al.              Informational                      [Page 1]

RFC 3048                  RMT Building Blocks               January 2001


Table of Contents

   1 Introduction ..................................................  2
   1.1 Protocol Families ...........................................  5
   2 Building Blocks Rationale .....................................  6
   2.1 Building Blocks Advantages ..................................  6
   2.2 Building Block Risks ........................................  7
   2.3 Building Block Requirements .................................  8
   3 Protocol Components ...........................................  8
   3.1 Sub-Components Definition ...................................  9
   4 Building Block Recommendations ................................ 12
   4.1 NACK-based Reliability ...................................... 13
   4.2 FEC coding .................................................. 13
   4.3 Congestion Control .......................................... 13
   4.4 Generic Router Support ...................................... 14
   4.5 Tree Configuration .......................................... 14
   4.6 Data Security ............................................... 15
   4.7 Common Headers .............................................. 15
   4.8 Protocol Cores .............................................. 15
   5 Security ...................................................... 15
   6 IANA Considerations ........................................... 15
   7 Conclusions ................................................... 16
   8 Acknowledgements .............................................. 16
   9 References .................................................... 16
   10 Authors' Addresses ........................................... 19
   11 Full Copyright Statement ..................................... 20

1.  Introduction

   RFC 2357 lays out the requirements for reliable multicast protocols
   that are to be considered for standardization by the IETF.  They
   include:

   o  Congestion Control.  The protocol must be safe to deploy in the
      widespread Internet.  Specifically, it must adhere to three
      mandates:  a) it must achieve good throughput (i.e., it must not
      consistently overload links with excess data or repair traffic),
      b) it must achieve good link utilization, and c) it must not
      starve competing flows.

   o  Scalability.  The protocol should be able to work under a variety
      of conditions that include multiple network topologies, link
      speeds, and the receiver set size.  It is more important to have a
      good understanding of how and when a protocol breaks than when it
      works.






Whetten, et al.              Informational                      [Page 2]

RFC 3048                  RMT Building Blocks               January 2001


   o  Security.  The protocol must be analyzed to show what is necessary
      to allow it to cope with security and privacy issues.  This
      includes understanding the role of the protocol in data
      confidentiality and sender authentication, as well as how the
      protocol will provide defenses against denial of service attacks.

   These requirements are primarily directed towards making sure that
   any standards will be safe for widespread Internet deployment.  The
   advancing maturity of current work on reliable multicast congestion
   control (RMCC) [HFW99] in the IRTF Reliable Multicast Research Group
   (RMRG) has been one of the events that has allowed the IETF to
   charter the RMT working group.  RMCC only addresses a subset of the
   design space for reliable multicast.  Fortuitously, the requirements
   it addresses are also the most pressing application and market
   requirements.

   A protocol's ability to meet the requirements of congestion control,
   scalability, and security is affected by a number of secondary
   requirements that are described in a separate document [RFC2887].  In
   summary, these are:

   o  Ordering Guarantees.  A protocol must offer at least one of either
      source ordered or unordered delivery guarantees.  Support for
      total ordering across multiple senders is not recommended, as it
      makes it more difficult to scale the protocol, and can more easily
      be implemented at a higher level.

   o  Receiver Scalability.  A protocol should be able to support a
      "large" number of simultaneous receivers per transport group.  A
      typical receiver set could be on the order of at least 1,000 -
      10,000 simultaneous receivers per group, or could even eventually
      scale up to millions of receivers in the large Internet.

   o  Real-Time Feedback.  Some versions of RMCC may require soft real-
      time feedback, so a protocol may provide some means for this
      information to be measured and returned to the sender.  While this
      does not require that a protocol deliver data in soft real-time,
      it is an important application requirement that can be provided
      easily given real-time feedback.

   o  Delivery Guarantees.  In many applications, a logically defined
      unit or units of data is to be delivered to multiple clients,
      e.g., a file or a set of files, a software package, a stock quote
      or package of stock quotes, an event notification, a set of
      slides, a frame or block from a video.  An application data unit
      is defined to be a logically separable unit of data that is useful
      to the application.  In some cases, an application data unit may
      be short enough to fit into a single packet (e.g., an event



Whetten, et al.              Informational                      [Page 3]

RFC 3048                  RMT Building Blocks               January 2001


      notification or a stock quote), whereas in other cases an
      application data unit may be much longer than a packet (e.g., a
      software package).  A protocol must provide good throughput of
      application data units to receivers.  This means that most data
      that is delivered to receivers is useful in recovering the
      application data unit that they are trying to receive.  A protocol
      may optionally provide delivery confirmation, i.e., a mechanism
      for receivers to inform the sender when data has been delivered.
      There are two types of confirmation, at the application data unit
      level and at the packet level.  Application data unit confirmation
      is useful at the application level, e.g., to inform the
      application about receiver progress and to decide when to stop
      sending packets about a particular application data unit.  Packet
      confirmation is useful at the transport level, e.g., to inform the
      transport level when it can release buffer space being used for
      storing packets for which delivery has been confirmed.  Packet
      level confirmation may also aid in application data unit
      confirmation.

   o  Network Topologies.  A protocol must not break the network when
      deployed in the full Internet.  However, we recognize that
      intranets will be where the first wave of deployments happen, and
      so are also very important to support.  Thus, support for
      satellite networks (including those with terrestrial return paths
      or no return paths at all) is encouraged, but not required.

   o  Group Membership.  The group membership algorithms must be
      scalable.  Membership can be anonymous (where the sender does not
      know the list of receivers), or fully distributed (where the
      sender receives a count of the number of receivers, and optionally
      a list of failures).

   o  Example Applications.  Some of the applications that a RM protocol
      could be designed to support include multimedia broadcasts, real
      time financial market data distribution, multicast file transfer,
      and server replication.

   In the rest of this document the following terms will be used with a
   specific connotation: "protocol family", "protocol component",
   "building block", "protocol core", and "protocol instantiation".  A
   "protocol family" is a broad class of RM protocols which share a
   common characteristic.  In our classification, this characteristic is
   the mechanism used to achieve reliability.  A "protocol component" is
   a logical part of the protocol that addresses a particular
   functionality.  A "building block" is a constituent of a protocol
   that implements one, more than one or a part of a component.  A
   "protocol core" is the set of functionality required for the




Whetten, et al.              Informational                      [Page 4]

RFC 3048                  RMT Building Blocks               January 2001


   instantiation of a complete protocol, that is not specified by any
   building block.  Finally a "protocol instantiation" is an actual RM
   protocol defined in term of building blocks and a protocol core.

1.1.  Protocol Families

   The design-space document [RFC2887] also provides a taxonomy of the
   most popular approaches that have been proposed over the last ten
   years.  After congestion control, the primary challenge has been that
   of meeting the requirement for ensuring good throughput in a way that
   scales to a large number of receivers.  For protocols that include a
   back-channel for recovery of lost packets, the ability to take
   advantage of support of elements in the network has been found to be
   very beneficial for supporting good throughput for a large numbers of
   receivers.  Other protocols have found it very beneficial to transmit
   coded data to achieve good throughput for large numbers of receivers.

   This taxonomy breaks proposed protocols into four families.  Some
   protocols in the family provide packet level delivery confirmation
   that may be useful to the transport level.  All protocols in all
   families can be supplemented with higher level protocols that provide
   delivery confirmation of application data units.

   1  NACK only.  Protocols such as SRM [FJM95] and MDP2 [MA99] attempt
      to limit traffic by only using NACKs for requesting packet
      retransmission.  They do not require network infrastructure.

   2  Tree based ACK.  Protocols such as RMTP [LP96, PSLM97], RMTP-II
      [WBPM98] and TRAM [KCW98], use positive acknowledgments (ACKs).
      ACK based protocols reduce the need for supplementary protocols
      that provide delivery confirmation, as the ACKS can be used for
      this purpose.  In order to avoid ACK implosion in scaled up
      deployments, the protocol can use servers placed in the network.

   3  Asynchronous Layered Coding (ALC).  These protocols (examples
      include [RV97] and [BLMR98]) use sender-based Forward Error
      Correction (FEC) methods with no feedback from receivers or the
      network to ensure good throughput.  These protocols also used
      sender-based layered multicast and receiver-driven protocols to
      join and leave these layers with no feedback to the sender to
      achieve scalable congestion control.

   4  Router assist.  Like SRM, protocols such as PGM [FLST98] and
      [LG97] also use negative acknowledgments for packet recovery.
      These protocols take advantage of new router software to do
      constrained negative acknowledgments and retransmissions.  Router
      assist protocols can also provide other functionality more
      efficiently than end to end protocols.  For example, [LVS99] shows