GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3048

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

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

    how router assist can provide fine grained congestion control for
    ALC protocols.  Router assist protocols can be designed to
    complement all protocol families described above.
 Note that the distinction in protocol families in not necessarily
 precise and mutually exclusive.  Actual protocols may use a
 combination of the mechanisms belonging to different classes.  For
 example, hybrid NACK/ACK based protocols (such as [WBPM98]) are
 possible.  Other examples are protocols belonging to class 1 through
 3 that take advantage of router support.

2. Building Blocks Rationale

 As specified in RFC 2357 [MRBP98], no single reliable multicast
 protocol will likely meet the needs of all applications.  Therefore,
 the IETF expects to standardize a number of protocols that are
 tailored to application and network specific needs.  This document
 concentrates on the requirements for "one-to-many bulk-data
 transfer", but in the future, additional protocols and building-
 blocks are expected that will address the needs of other types of
 applications, including "many-to- many" applications.  Note that
 bulk-data transfer does not refer to the timeliness of the data,
 rather it states that there is a large amount of data to be
 transferred in a session.  The scope and approach taken for the
 development of protocols for these additional scenarios will depend
 upon large part on the success of the "building-block" approach put
 forward in this document.

2.1. Building Blocks Advantages

 Building a large piece of software out of smaller modular components
 is a well understood technique of software engineering.  Some of the
 advantages that can come from this include:
 o  Specification Reuse.  Modules can be used in multiple protocols,
    which reduces the amount of development time required.
 o  Reduced Complexity.  To the extent that each module can be easily
    defined with a simple API, breaking a large protocol in to smaller
    pieces typically reduces the total complexity of the system.
 o  Reduced Verification and Debugging Time.  Reduced complexity
    results in reduced time to debug the modules.  It is also usually
    faster to verify a set of smaller modules than a single larger
    module.

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

 o  Easier Future Upgrades.  There is still ongoing research in
    reliable multicast, and we expect the state of the art to continue
    to evolve.  Building protocols with smaller modules allows them to
    be more easily upgraded to reflect future research.
 o  Common Diagnostics.  To the extent that multiple protocols share
    common packet headers, packet analyzers and other diagnostic tools
    can be built which work with multiple protocols.
 o  Reduces Effort for New Protocols.  As new application requirements
    drive the need for new standards, some existing modules may be
    reused in these protocols.
 o  Parallelism of Development.  If the APIs are defined clearly, the
    development of each module can proceed in parallel.

2.2. Building Block Risks

 Like most software specification, this technique of breaking down a
 protocol in to smaller components also brings tradeoffs.  After a
 certain point, the disadvantages outweigh the advantages, and it is
 not worthwhile to further subdivide a problem.  These risks include:
 o  Delaying Development.  Defining the API for how each two modules
    inter-operate takes time and effort.  As the number of modules
    increases, the number of APIs can increase at more than a linear
    rate.  The more tightly coupled and complex a component is, the
    more difficult it is to define a simple API, and the less
    opportunity there is for reuse.  In particular, the problem of how
    to build and standardize fine grained building blocks for a
    transport protocol is a difficult one, and in some cases requires
    fundamental research.
 o  Increased Complexity.  If there are too many modules, the total
    complexity of the system actually increases, due to the
    preponderance of interfaces between modules.
 o  Reduced Performance.  Each extra API adds some level of processing
    overhead.  If an API is inserted in to the "common case" of packet
    processing, this risks degrading total protocol performance.
 o  Abandoning Prior Work.  The development of robust transport
    protocols is a long and time intensive process, which is heavily
    dependent on feedback from real deployments.  A great deal of work
    has been done over the past five years on components of protocols
    such as RMTP-II, SRM, and PGM.  Attempting to dramatically re-
    engineer these components risks losing the benefit of this prior
    work.

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

2.3. Building Block Requirements

 Given these tradeoffs, we propose that a building block must meet the
 following requirements:
 o  Wide Applicability.  In order to have confidence that the
    component can be reused, it should apply across multiple protocol
    families and allow for the component's evolution.
 o  Simplicity.  In order to have confidence that the specification of
    the component APIs will not dramatically slow down the standards
    process, APIs must be simple and straight forward to define.  No
    new fundamental research should be done in defining these APIs.
 o  Performance.  To the extent possible, the building blocks should
    attempt to avoid breaking up the "fast track", or common case
    packet processing.

3. Protocol Components

 This section proposes a functional decomposition of RM bulk-data
 protocols from the perspective of the functional components provided
 to an application by a transport protocol.  It also covers some
 components that while not necessarily part of the transport protocol,
 are directly impacted by the specific requirements of a reliable
 multicast transport.  The next section then specifies recommended
 building blocks that can implement these components.
 Although this list tries to cover all the most common transport-
 related needs of one-to-many bulk-data transfer applications, new
 application requirements may arise during the process of
 standardization, hence this list must not be interpreted as a
 statement of what the transport layer should provide and what it
 should not.  Nevertheless, it must be pointed out that some
 functional components have been deliberately omitted since they have
 been deemed irrelevant to the type of application considered (i.e.,
 one-to-many bulk-data transfer).  Among these are advanced message
 ordering (i.e., those which cannot be implemented through a simple
 sequence number) and atomic delivery.
 It is also worth mentioning that some of the functional components
 listed below may be required by other functional components and not
 directly by the application (e.g., membership knowledge is usually
 required to implement ACK-based reliability).
 The following list covers various transport functional components and
 splits them in sub-components.

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

 o  Data Reliability (ensuring good throughput)    |
                        | - Loss Detection/Notification
                        | - Loss Recovery
                        | - Loss Protection
 o  Congestion Control  |
                        | - Congestion Feedback
                        | - Rate Regulation
                        | - Receiver Controls
 o  Security
 o  Group membership    |
                        | - Membership Notification
                        | - Membership Management
 o  Session Management  |
                        | - Group Membership Tracking
                        | - Session Advertisement
                        | - Session Start/Stop
                        | - Session Configuration/Monitoring
 o  Tree Configuration
 Note that not all components are required by all protocols, depending
 upon the fully defined service that is being provided by the
 protocol.  In particular, some minimal service models do not require
 many of these functions, including loss notification, loss recovery,
 and group membership.

3.1. Sub-Components Definition

 Loss Detection/Notification.  This includes how missing packets are
 detected during transmission and how knowledge of these events are
 propagated to one or more agents which are designated to recover from
 the transmission error.  This task raises major scalability issues
 and can lead to feedback implosion and poor throughput if not
 properly handled.  Mechanisms based on TRACKs (tree-based positive
 acknowledgements) or NACKs (negative acknowledgements) are the most
 widely used to perform this function.  Mechanisms based on a
 combination of TRACKs and NACKs are also possible.
 Loss Recovery.  This function responds to loss notification events
 through the transmission of additional packets, either in the form of
 copies of those packets lost or in the form of FEC packets.  The
 manner in which this function is implemented can significantly affect
 the scalability of a protocol.

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

 Loss Protection.  This function attempts to mask packet-losses so
 that they don't become Loss Notification events.  This function can
 be realized through the pro-active transmission of FEC packets.  Each
 FEC packet is created from an entire application data unit [LMSSS97]
 or a portion of an application data unit [RV97], [BKKKLZ95], a fact
 that allows a receiver to recover from some packet loss without
 further retransmissions.  The number of losses that can be recovered
 from without requiring retransmission depends on the amount of FEC
 packets sent in the first place.  Loss protection can also be pushed
 to the extreme when good throughput is achieved without any Loss
 Detection/Notification and Loss Recovery functionality, as in the ALC
 family of protocols defined above.
 Congestion Feedback.  For sender driven congestion control protocols,
 the receiver must provide some type of feedback on congestion to the
 sender.  This typically involves loss rate and round trip time
 measurements.
 Rate Regulation.  Given the congestion feedback, the sender then must
 adjust its rate in a way that is fair to the network.  One proposal
 that defines this notion of fairness and other congestion control
 requirements is [Whetten99].
 Receiver Controls.  In order to avoid allowing a receiver that has an
 extremely slow connection to the sender to stop all progress within
 single rate schemes, a congestion control algorithm will often
 require receivers to leave groups.  For multiple rate approaches,
 receivers of all connection speeds can have data delivered to them
 according to the rate of their connection without slowing down other
 receivers.
 Security.  Security for reliable multicast contains a number of
 complex and tricky issues that stem in large part from the IP
 multicast service model.  In this service model, hosts do not send
 traffic to another host, but instead elect to receive traffic from a
 multicast group. This means that any host may join a group and
 receive its traffic.  Conversely, hosts may also leave a group at any
 time.  Therefore, the protocol must address how it impacts the
 following security issues:
 o  Sender Authentication (since any host can send to a group),
 o  Data Encryption (since any host can join a group)
 o  Transport Protection (denial of service attacks, through
    corruption of transport state, or requests for unauthorized
    resources)

Whetten, et al. Informational [Page 10] 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] RFC 3048 RMT Building Blocks January 2001

 that will be administered by IANA.  Initially, this registry will be
 empty, since the building blocks described in sections 4.1 to 4.3 are
 presented for example and design purposes.  The requested IANA
 building block registry will be populated from specifications as they
 are approved for RFC publication (using the "Specification Required"
 policy as described in RFC 2434 [RFC2434]).  A registration will
 consist of a building block name, a version number, a brief text
 description, a specification RFC number, and a responsible person, to
 which IANA will assign the type number.

7. Conclusions

 In this document, we briefly described a number of building blocks
 that may be used for the generation of reliable multicast protocols
 to be used in the application space of one-to-many reliable bulk-data
 transfer.  The list of building blocks presented was derived from
 considering the functions that a protocol in this space must perform
 and how these functions should be grouped.  This list is not intended
 to be all-inclusive but instead to act as guide as to which building
 blocks are considered during the standardization process within the
 Reliable Multicast Transport WG.

8. Acknowledgements

 This document represents an overview of a number of building blocks
 for one to many bulk data transfer that may be ready for
 standardization within the RMT working group.  The ideas presented
 are not those of the authors, rather they are a summarization of many
 years of research into multicast transport combined with the varied
 presentations and discussions in the IRTF Reliable Multicast Research
 Group.  Although they are too numerous to list here, we thank
 everyone who has participated in these discussions for their
 contributions.

9. References

 [BKKKLZ95]  J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby,
             D.  Zuckerman, "An XOR-based Erasure Resilient Coding
             Scheme," ICSI Technical Report No. TR-95-048, August
             1995.
 [BLMR98]    J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A Digital
             Fountain Approach to Reliable Distribution of Bulk Data,"
             Proc ACM SIGCOMM 98.
 [FJM95]     S. Floyd, V. Jacobson, S. McCanne, "A Reliable Multicast
             Framework for Light-weight Sessions and Application Level
             Framing," Proc ACM SIGCOMM 95, Aug 1995 pp. 342-356.

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

 [FLST98]    D. Farinacci, S. Lin, T. Speakman, and A. Tweedly, "PGM
             reliable transport protocol specification," Work in
             Progress.
 [HFW99]     M. Handley, S. Floyd, B. Whetten, "Strawman Specification
             for TCP Friendly (Reliable) Multicast Congestion Control
             (TFMCC)," Work in Progress.
 [HJ98]      Handley, M. and V. Jacobson, "SDP: Session Description
             Protocol", RFC 2327, April 1998.
 [HPW99]     M. Handley, C. Perkins, E. Whelan, "Session Announcement
             Protocol," Work in Progress, June 1999.
 [HW99]      T. Hardjorno, B. Whetten,  "Security Requirements for
             RMTP-II," Work in Progress, June 1999.
 [RFC2887]   Handley, M., Whetten, B., Kermode, R., Floyd, S.,
             Vicisano, L. and M. Luby, "The Reliable Multicast Design
             Space for Bulk Data Transfer", RFC 2887, August 2000.
 [KCW98]     M. Kadansky, D. Chiu, and J. Wesley, "Tree-based reliable
             multicast (TRAM)," Work in Progress.
 [Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request with
             Forward Error Correction," Proc ACM SIGCOMM 98, Sept
             1998.
 [LDW98]     M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed Error
             Recovery for Multimedia Streams in Wide-Area Multicast
             Networks".
 [LESZ97]    C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local Error
             Recovery in SRM: Comparison of Two Approaches," USC
             Technical Report 97-648, Jan 1997.
 [LG97]      B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving Internet
             Multicast Routing with Routing Labels," IEEE
             International Conference on Network Protocols (ICNP-97),
             Oct 28-31, 1997, p.241-250.
 [LP96]      K. Lin and S. Paul. "RMTP: A Reliable Multicast Transport
             Protocol," IEEE INFOCOMM 1996, March 1996, pp. 1414-1424.
 [LMSSS97]   M. Luby, M. Mitzenmacher, A. Shokrollahi, D. Spielman, V.
             Stemann, "Practical Loss-Resilient Codes", Proc ACM
             Symposium on Theory of Computing, 1997.

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

 [LVS99]     M. Luby, L. Vicisano, T. Speakman. "Heterogeneous
             multicast congestion control based on router packet
             filtering", RMT working group, June 1999, Pisa, Italy.
 [MA99]      J. Macker, B. Adamson. "Multicast Dissemination Protocol
             version 2 (MDPv2)," Work in Progress,
             http://manimac.itd.nrl.navy.mil/MDP
 [MRBP98]    Mankin, A., Romanow, A., Brander, S. and V.Paxson, "IETF
             Criteria for Evaluating Reliable Multicast Transport and
             Application Protocols", RFC 2357, June 1998.
 [RFC2434]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
             October 1998.
 [OXB99]     O. Ozkasap, Z. Xiao, K. Birman.  "Scalability of Two
             Reliable Multicast Protocols", Work in Progress, May
             1999.
 [PSLB97]    "Reliable Multicast Transport Protocol (RMTP)," S. Paul,
             K. K. Sabnani, J. C. Lin, and S. Bhattacharyya, IEEE
             Journal on Selected Areas in Communications, Vol. 15, No.
             3, April 1997.
 [RV97]      L. Rizzo, L. Vicisano, "A Reliable Multicast Data
             Distribution Protocol Based on Software FEC Techniques,"
             Proc. of The Fourth IEEE Workshop on the Architecture and
             Implementation of High Performance Communication Systems
             (HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25,
             1997.
 [VRC98]     L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like Congestion
             Control for Layered Multicast Data Transfer", Proc. of
             IEEE Infocom'98, March 1998.
 [WBPM98]    B. Whetten, M. Basavaiah, S. Paul, T. Montgomery, N.
             Rastogi, J. Conlan, and T. Yeh, "THE RMTP-II PROTOCOL,"
             Work in Progress.
 [WHA98]     D. Wallner, E. Hardler, R. Agee, "Key Management for
             Multicast: Issues and Architectures," Work in Progress.
 [Whetten99] B. Whetten,  "A Proposal for Reliable Multicast
             Congestion Control Requirements," Work in Progress.
             http://www.talarian.com/rmtp-ii/overview.htm

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

10. Authors' Addresses

 Brian Whetten
 Talarian Corporation,
 333 Distel Circle,
 Los Altos, CA 94022, USA
 EMail: whetten@talarian.com
 Lorenzo Vicisano
 Cisco Systems,
 170 West Tasman Dr.
 San Jose, CA 95134, USA
 EMail: lorenzo@cisco.com
 Roger Kermode
 Motorola Australian Research Centre
 Level 3, 12 Lord St,
 Botany  NSW  2019, Australia
 EMail: Roger.Kermode@motorola.com
 Mark Handley, Sally Floyd
 ATT Center for Internet Research at ICSI,
 International Computer Science Institute,
 1947 Center Street, Suite 600,
 Berkeley, CA 94704, USA
 EMail: mjh@aciri.org, floyd@aciri.org
 Michael Luby
 600 Alabama Street
 San Francisco, CA  94110
 Digital Fountain, Inc.
 EMail: luby@digitalfountain.com

Whetten, et al. Informational [Page 19] RFC 3048 RMT Building Blocks January 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.

Whetten, et al. Informational [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3048.txt · Last modified: 2001/01/26 19:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki