rfc3048.txt

最新的RFC


RFC 3048                  RMT Building Blocks               January 2001


   o  Group Key Management (since hosts may join and leave a group at
      any time) [WHA98]

   In particular, a transport protocol needs to pay particular attention
   to how it protects itself from denial of service attacks, through
   mechanisms such as lightweight authentication of control packets
   [HW99].

   With Source Specific Multicast service model (SSM), a host joins
   specifically to a sender and group pair.  Thus, SSM offers more
   security against hosts receiving traffic from a denial of service
   attack where an arbitrary sender sends packets that hosts did not
   specifically request to receive.  Nevertheless, it is recommended
   that additional protections against such attacks should be provided
   when using SSM, because the protection offered by SSM against such
   attacks may not be enough.

   Sender Authentication, Data Encryption, and Group Key Management.
   While these functions are not typically part of the transport layer
   per se, a protocol needs to understand what ramifications it has on
   data security, and may need to have special interfaces to the
   security layer in order to accommodate these ramifications.

   Transport Protection.  The primary security task for a transport
   layer is that of protecting the transport layer itself from attack.
   The most important function for this is typically lightweight
   authentication of control packets in order to prevent corruption of
   state and other denial of service attacks.

   Membership Notification.  This is the function through which the data
   source--or upper level agent in a possible hierarchical
   organization--learns about the identity and/or number of receivers or
   lower level agents.  To be scalable, this typically will not provide
   total knowledge of the identity of each receiver.

   Membership Management.  This implements the mechanisms for members to
   join and leave the group, to accept/refuse new members, or to
   terminate the membership of existing members.

   Group Membership Tracking.  As an optional feature, a protocol may
   interface with a component which tracks the identity of each receiver
   in a large group.  If so, this feature will typically be implemented
   out of band, and may be implemented by an upper level protocol.  This
   may be useful for services that require tracking of usage of the
   system, billing, and usage reports.






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


   Session Advertisement.  This publishes the session name/contents and
   the parameters needed for its reception. This function is usually
   performed by an upper layer protocol (e.g., [HPW99] and [HJ98]).

   Session Start/Stop.  These functions determine the start/stop time of
   sender and/or receivers.  In many cases this is implicit or performed
   by an upper level application or protocol.  In some protocols,
   however, this is a task best performed by the transport layer due to
   scalability requirements.

   Session Configuration/Monitoring.  Due to the potentially far
   reaching scope of a multicast session, it is particularly important
   for a protocol to include tools for configuring and monitoring the
   protocol's operation.

   Tree Configuration.  For protocols which include hierarchical
   elements (such as PGM and RMTP-II), it is important to configure
   these elements in a way that has approximate congruence with the
   multicast routing topology.  While tree configuration could be
   included as part of the session configuration tools, it is clearly
   better if this configuration can be made automatic.

4.  Building Block Recommendations

   The families of protocols introduced in section 1.1 generally use
   different mechanisms to implement the protocol functional components
   described in section 3.  This section tries to group these mechanisms
   in macro components that define protocol building blocks.

   A building block is defined as
      "a logical protocol component that results in explicit APIs for use
      by other building blocks or by the protocol client."

   Building blocks are generally specified in terms of the set of
   algorithms and packet formats that implement protocol functional
   components.  A building block may also have API's through which it
   communicates to applications and/or other building blocks.  Most
   building blocks should also have a management API, through which it
   communicates to SNMP and/or other management protocols.

   In the following section we will list a number of building blocks
   which, at this stage, seem to cover most of the functional components
   needed to implement the protocol families presented in section 1.1.
   Nevertheless this list represents the "best current guess", and as
   such it is not meant to be exhaustive.  The actual building block
   decomposition, i.e., the division of functional components into
   building blocks, may also have to be revised in the future.




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


4.1.  NACK-based Reliability

   This building block defines NACK-based loss detection/notification
   and recovery.  The major issues it addresses are implosion prevention
   (suppression) and NACK semantics (i.e., how packets to be
   retransmitted should be specified, both in the case of selective and
   FEC loss repair).  Suppression mechanisms to be considered are:

   o  Multicast NACKs
   o  Unicast NACKs and Multicast confirmation

   These suppression mechanisms primarily need to both minimize delay
   while also minimizing redundant messages.  They may also need to have
   special weighting to work with Congestion Feedback.

4.2.  FEC coding

   This building block is concerned with packet level FEC information
   when FEC codes are used either proactively or as repairs in reaction
   to lost packets.  It specifies the FEC codec selection and the FEC
   packet naming (indexing) for both reactive FEC repair and pro-active
   FEC.

4.3.  Congestion Control

   There will likely be multiple versions of this building block,
   corresponding to different design policies in addressing congestion
   control.  Two main approaches are considered for the time being: a
   source-based rate regulation with a single rate provided to all the
   receivers in the session, and a multiple rate receiver-driven
   approach with different receivers receiving at different rates in the
   same session.  The multiple rate approach may use multiple layers of
   multicast traffic [VRC98] or router filtering of a single layer
   [LVS99].  The multiple rate approach is most applicable for ALC
   protocols.

   Both approaches are still in the phase of study, however the first
   seems to be mature enough [HFW99] to allow the standardization
   process to begin.

   At the time of writing this document, a third class of congestion
   control algorithm based on router support is beginning to emerge in
   the IRTF RMRG [LVS99].  This work may lead to the future
   standardization of one or more additional building blocks for
   congestion control.






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


4.4.  Generic Router Support

   The task of designing RM protocols can be made much easier by the
   presence of some specific support in routers.  In some application-
   specific cases, the increased benefits afforded by the addition of
   special router support can justify the resulting additional
   complexity and expense [FLST98].

   Functional components which can take advantage of router support
   include feedback aggregation/suppression (both for loss notification
   and congestion control) and constrained retransmission of repair
   packets.  Another component that can take advantage of router support
   is intentional packet filtering to provide different rates of
   delivery of packets to different receivers from the same multicast
   packet stream.  This could be most advantageous when combined with
   ALC protocols [LVS99].

   The process of designing and deploying these mechanisms inside
   routers can be much slower than the one required for end-host
   protocol mechanisms.  Therefore, it would be highly advantageous to
   define these mechanisms in a generic way that multiple protocols can
   use if it is available, but do not necessarily need to depend on.

   This component has two halves, a signaling protocol and actual router
   algorithms.  The signaling protocol allows the transport protocol to
   request from the router the functions that it wishes to perform, and
   the router algorithms actually perform these functions.  It is more
   urgent to define the signaling protocol, since it will likely impact
   the common case protocol headers.

   An important component of the signaling protocol is some level of
   commonality between the packet headers of multiple protocols, which
   allows the router to recognize and interpret the headers.

4.5.  Tree Configuration

   It has been shown that the scalability of RM protocols can be greatly
   enhanced by the insertion of some kind of retransmission or feedback
   aggregation agents between the source and receivers.  These agents
   are then used to form a tree with the source at (or near) the root,
   the receivers at the leaves of the tree, and the aggregation/local
   repair nodes in the middle.  The internal nodes can either be
   dedicated software for this task, or they may be receivers that are
   performing dual duty.

   The effectiveness of these agents to assist in the delivery of data
   is highly dependent upon how well the logical tree they use to
   communicate matches the underlying routing topology.  The purpose of



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


   this building block would be to construct and manage the logical tree
   connecting the agents.  Ideally, this building block would perform
   these functions in a manner that adapts to changes in session
   membership, routing topology, and network availability.

4.6.  Data Security

   At the time of writing, the security issues are the subject of
   research within the IRTF Secure Multicast Group (SMuG).  Solutions
   for these requirements will be standardized within the IETF when
   ready.

4.7.  Common Headers

   As pointed out in the generic router support section, it is important
   to have some level of commonality across packet headers.  It may also
   be useful to have common data header formats for other reasons.  This
   building block would consist of recommendations on fields in their
   packet headers that protocols should make common across themselves.

4.8.  Protocol Cores

   The above building blocks consist of the functional components listed
   in section 3 that appear to meet the requirements for being
   implemented as building blocks presented in section 2.

   The other functions from section 3, which are not covered above,
   should be implemented as part of "protocol cores", specific to each
   protocol standardized.

5.  Security Considerations

   RFC 2357 specifically states that "reliable multicast Internet-Drafts
   reviewed by the Transport Area Directors must explicitly explore the
   security aspects of the proposed design."  Specifically, RMT building
   block works in progress must examine the denial-of-service attacks
   that can be made upon building blocks and affected by building blocks
   upon the Internet at large.  This requirement is in addition to any
   discussions regarding data-security, that is the manipulation of or
   exposure of session information to unauthorized receivers.  Readers
   are referred to section 5.e of RFC 2357 for further details.

6.  IANA Considerations

   There will be more than one building block, and possibly multiple
   versions of individual building blocks as their designs are refined.
   For this reason, the creation of new building blocks and new building
   block versions will be administered via a building block registry



Whetten, et al.              Informational                     [Page 15]