As per Relevance of the word building, we have this rfc below:
Network Working Group B.
Request for Comments: 3048
Category: Informational L.
R.
M.
ACIRI 9
S.
M.
Digital
January 2001
Reliable Multicast Transport Building Blocks for One-to-
Bulk-Data
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes a framework for the standardization of bulk
data reliable multicast transport. It builds upon the
gained during the deployment of several classes of
reliable multicast transport, and attempts to pull out
commonalities between these classes of protocols into a number
building blocks. To that end, this document recommends that
components that are common to multiple protocol classes
standardized as "building blocks". The remaining parts of
protocols, consisting of highly protocol specific,
intertwined functions, shall be designated as "protocol cores".
Thus, each protocol can then be constructed by merging a "
core" with a number of "building blocks" which can be re-used
multiple protocols
Whetten, et al. Informational [Page 1]
RFC 3048 RMT Building Blocks January 2001
Table of
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.
RFC 2357 lays out the requirements for reliable multicast
that are to be considered for standardization by the IETF.
include
o Congestion Control. The protocol must be safe to deploy in
widespread Internet. Specifically, it must adhere to
mandates: a) it must achieve good throughput (i.e., it must
consistently overload links with excess data or repair traffic),
b) it must achieve good link utilization, and c) it must
starve competing flows
o Scalability. The protocol should be able to work under a
of conditions that include multiple network topologies,
speeds, and the receiver set size. It is more important to have
good understanding of how and when a protocol breaks than when
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
to allow it to cope with security and privacy issues.
includes understanding the role of the protocol in
confidentiality and sender authentication, as well as how
protocol will provide defenses against denial of service attacks
These requirements are primarily directed towards making sure
any standards will be safe for widespread Internet deployment.
advancing maturity of current work on reliable multicast
control (RMCC) [HFW99] in the IRTF Reliable Multicast Research
(RMRG) has been one of the events that has allowed the IETF
charter the RMT working group. RMCC only addresses a subset of
design space for reliable multicast. Fortuitously, the
it addresses are also the most pressing application and
requirements
A protocol's ability to meet the requirements of congestion control
scalability, and security is affected by a number of
requirements that are described in a separate document [RFC2887].
summary, these are
o Ordering Guarantees. A protocol must offer at least one of
source ordered or unordered delivery guarantees. Support
total ordering across multiple senders is not recommended, as
makes it more difficult to scale the protocol, and can more
be implemented at a higher level
o Receiver Scalability. A protocol should be able to support
"large" number of simultaneous receivers per transport group.
typical receiver set could be on the order of at least 1,000 -
10,000 simultaneous receivers per group, or could even
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
information to be measured and returned to the sender. While
does not require that a protocol deliver data in soft real-time
it is an important application requirement that can be
easily given real-time feedback
o Delivery Guarantees. In many applications, a logically
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
or package of stock quotes, an event notification, a set
slides, a frame or block from a video. An application data
is defined to be a logically separable unit of data that is
to the application. In some cases, an application data unit
be short enough to fit into a single packet (e.g., an
Whetten, et al. Informational [Page 3]
RFC 3048 RMT Building Blocks January 2001
notification or a stock quote), whereas in other cases
application data unit may be much longer than a packet (e.g.,
software package). A protocol must provide good throughput
application data units to receivers. This means that most
that is delivered to receivers is useful in recovering
application data unit that they are trying to receive. A
may optionally provide delivery confirmation, i.e., a
for receivers to inform the sender when data has been delivered
There are two types of confirmation, at the application data
level and at the packet level. Application data unit
is useful at the application level, e.g., to inform
application about receiver progress and to decide when to
sending packets about a particular application data unit.
confirmation is useful at the transport level, e.g., to inform
transport level when it can release buffer space being used
storing packets for which delivery has been confirmed.
level confirmation may also aid in application data
confirmation
o Network Topologies. A protocol must not break the network
deployed in the full Internet. However, we recognize
intranets will be where the first wave of deployments happen,
so are also very important to support. Thus, support
satellite networks (including those with terrestrial return
or no return paths at all) is encouraged, but not required
o Group Membership. The group membership algorithms must
scalable. Membership can be anonymous (where the sender does
know the list of receivers), or fully distributed (where
sender receives a count of the number of receivers, and
a list of failures).
o Example Applications. Some of the applications that a RM
could be designed to support include multimedia broadcasts,
time financial market data distribution, multicast file transfer
and server replication
In the rest of this document the following terms will be used with
specific connotation: "protocol family", "protocol component",
"building block", "protocol core", and "protocol instantiation".
"protocol family" is a broad class of RM protocols which share
common characteristic. In our classification, this characteristic
the mechanism used to achieve reliability. A "protocol component"
a logical part of the protocol that addresses a
functionality. A "building block" is a constituent of a
that implements one, more than one or a part of a component.
"protocol core" is the set of functionality required for
Whetten, et al. Informational [Page 4]
RFC 3048 RMT Building Blocks January 2001
instantiation of a complete protocol, that is not specified by
building block. Finally a "protocol instantiation" is an actual
protocol defined in term of building blocks and a protocol core
1.1. Protocol
The design-space document [RFC2887] also provides a taxonomy of
most popular approaches that have been proposed over the last
years. After congestion control, the primary challenge has been
of meeting the requirement for ensuring good throughput in a way
scales to a large number of receivers. For protocols that include
back-channel for recovery of lost packets, the ability to
advantage of support of elements in the network has been found to
very beneficial for supporting good throughput for a large numbers
receivers. Other protocols have found it very beneficial to
coded data to achieve good throughput for large numbers of receivers
This taxonomy breaks proposed protocols into four families.
protocols in the family provide packet level delivery
that may be useful to the transport level. All protocols in
families can be supplemented with higher level protocols that
delivery confirmation of application data units
1 NACK only. Protocols such as SRM [FJM95] and MDP2 [MA99]
to limit traffic by only using NACKs for requesting
retransmission. They do not require network infrastructure
2 Tree based ACK. Protocols such as RMTP [LP96, PSLM97], RMTP-
[WBPM98] and TRAM [KCW98], use positive acknowledgments (ACKs).
ACK based protocols reduce the need for supplementary
that provide delivery confirmation, as the ACKS can be used
this purpose. In order to avoid ACK implosion in scaled
deployments, the protocol can use servers placed in the network
3 Asynchronous Layered Coding (ALC). These protocols (
include [RV97] and [BLMR98]) use sender-based Forward
Correction (FEC) methods with no feedback from receivers or
network to ensure good throughput. These protocols also
sender-based layered multicast and receiver-driven protocols
join and leave these layers with no feedback to the sender
achieve scalable congestion control
4 Router assist. Like SRM, protocols such as PGM [FLST98]
[LG97] also use negative acknowledgments for packet recovery
These protocols take advantage of new router software to
constrained negative acknowledgments and retransmissions.
assist protocols can also provide other functionality
efficiently than end to end protocols. For example, [LVS99]
Whetten, et al. Informational [Page 5]
RFC 3048 RMT Building Blocks January 2001
how router assist can provide fine grained congestion control
ALC protocols. Router assist protocols can be designed
complement all protocol families described above
Note that the distinction in protocol families in not
precise and mutually exclusive. Actual protocols may use
combination of the mechanisms belonging to different classes.
example, hybrid NACK/ACK based protocols (such as [WBPM98])
possible. Other examples are protocols belonging to class 1
3 that take advantage of router support
2. Building Blocks
As specified in RFC 2357 [MRBP98], no single reliable
protocol will likely meet the needs of all applications. Therefore
the IETF expects to standardize a number of protocols that
tailored to application and network specific needs. This
concentrates on the requirements for "one-to-many bulk-
transfer", but in the future, additional protocols and building
blocks are expected that will address the needs of other types
applications, including "many-to- many" applications. Note
bulk-data transfer does not refer to the timeliness of the data
rather it states that there is a large amount of data to
transferred in a session. The scope and approach taken for
development of protocols for these additional scenarios will
upon large part on the success of the "building-block" approach
forward in this document
2.1. Building Blocks
Building a large piece of software out of smaller modular
is a well understood technique of software engineering. Some of
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
defined with a simple API, breaking a large protocol in to
pieces typically reduces the total complexity of the system
o Reduced Verification and Debugging Time. Reduced
results in reduced time to debug the modules. It is also
faster to verify a set of smaller modules than a single
module
Whetten, et al. Informational [Page 6]
RFC 3048 RMT Building Blocks January 2001
o Easier Future Upgrades. There is still ongoing research
reliable multicast, and we expect the state of the art to
to evolve. Building protocols with smaller modules allows them
be more easily upgraded to reflect future research
o Common Diagnostics. To the extent that multiple protocols
common packet headers, packet analyzers and other diagnostic
can be built which work with multiple protocols
o Reduces Effort for New Protocols. As new application
drive the need for new standards, some existing modules may
reused in these protocols
o Parallelism of Development. If the APIs are defined clearly,
development of each module can proceed in parallel
2.2. Building Block
Like most software specification, this technique of breaking down
protocol in to smaller components also brings tradeoffs. After
certain point, the disadvantages outweigh the advantages, and it
not worthwhile to further subdivide a problem. These risks include
o Delaying Development. Defining the API for how each two
inter-operate takes time and effort. As the number of
increases, the number of APIs can increase at more than a
rate. The more tightly coupled and complex a component is,
more difficult it is to define a simple API, and the
opportunity there is for reuse. In particular, the problem of
to build and standardize fine grained building blocks for
transport protocol is a difficult one, and in some cases
fundamental research
o Increased Complexity. If there are too many modules, the
complexity of the system actually increases, due to
preponderance of interfaces between modules
o Reduced Performance. Each extra API adds some level of
overhead. If an API is inserted in to the "common case" of
processing, this risks degrading total protocol performance
o Abandoning Prior Work. The development of robust
protocols is a long and time intensive process, which is
dependent on feedback from real deployments. A great deal of
has been done over the past five years on components of
such as RMTP-II, SRM, and PGM. Attempting to dramatically re
engineer these components risks losing the benefit of this
work
Whetten, et al. Informational [Page 7]
RFC 3048 RMT Building Blocks January 2001
2.3. Building Block
Given these tradeoffs, we propose that a building block must meet
following requirements
o Wide Applicability. In order to have confidence that
component can be reused, it should apply across multiple
families and allow for the component's evolution
o Simplicity. In order to have confidence that the specification
the component APIs will not dramatically slow down the
process, APIs must be simple and straight forward to define.
new fundamental research should be done in defining these APIs
o Performance. To the extent possible, the building blocks
attempt to avoid breaking up the "fast track", or common
packet processing
3. Protocol
This section proposes a functional decomposition of RM bulk-
protocols from the perspective of the functional components
to an application by a transport protocol. It also covers
components that while not necessarily part of the transport protocol
are directly impacted by the specific requirements of a
multicast transport. The next section then specifies
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,
application requirements may arise during the process
standardization, hence this list must not be interpreted as
statement of what the transport layer should provide and what
should not. Nevertheless, it must be pointed out that
functional components have been deliberately omitted since they
been deemed irrelevant to the type of application considered (i.e.,
one-to-many bulk-data transfer). Among these are advanced
ordering (i.e., those which cannot be implemented through a
sequence number) and atomic delivery
It is also worth mentioning that some of the functional
listed below may be required by other functional components and
directly by the application (e.g., membership knowledge is
required to implement ACK-based reliability).
The following list covers various transport functional components
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/
| - Loss
| - Loss
o Congestion Control |
| - Congestion
| - Rate
| - Receiver
o
o Group membership |
| - Membership
| - Membership
o Session Management |
| - Group Membership
| - Session
| - Session Start/
| - Session Configuration/
o Tree
Note that not all components are required by all protocols,
upon the fully defined service that is being provided by
protocol. In particular, some minimal service models do not
many of these functions, including loss notification, loss recovery
and group membership
3.1. Sub-Components
Loss Detection/Notification. This includes how missing packets
detected during transmission and how knowledge of these events
propagated to one or more agents which are designated to recover
the transmission error. This task raises major scalability
and can lead to feedback implosion and poor throughput if
properly handled. Mechanisms based on TRACKs (tree-based
acknowledgements) or NACKs (negative acknowledgements) are the
widely used to perform this function. Mechanisms based on
combination of TRACKs and NACKs are also possible
Loss Recovery. This function responds to loss notification
through the transmission of additional packets, either in the form
copies of those packets lost or in the form of FEC packets.
manner in which this function is implemented can significantly
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
that they don't become Loss Notification events. This function
be realized through the pro-active transmission of FEC packets.
FEC packet is created from an entire application data unit [LMSSS97]
or a portion of an application data unit [RV97], [BKKKLZ95], a
that allows a receiver to recover from some packet loss
further retransmissions. The number of losses that can be
from without requiring retransmission depends on the amount of
packets sent in the first place. Loss protection can also be
to the extreme when good throughput is achieved without any
Detection/Notification and Loss Recovery functionality, as in the
family of protocols defined above
Congestion Feedback. For sender driven congestion control protocols
the receiver must provide some type of feedback on congestion to
sender. This typically involves loss rate and round trip
measurements
Rate Regulation. Given the congestion feedback, the sender then
adjust its rate in a way that is fair to the network. One
that defines this notion of fairness and other congestion
requirements is [Whetten99].
Receiver Controls. In order to avoid allowing a receiver that has
extremely slow connection to the sender to stop all progress
single rate schemes, a congestion control algorithm will
require receivers to leave groups. For multiple rate approaches
receivers of all connection speeds can have data delivered to
according to the rate of their connection without slowing down
receivers
Security. Security for reliable multicast contains a number
complex and tricky issues that stem in large part from the
multicast service model. In this service model, hosts do not
traffic to another host, but instead elect to receive traffic from
multicast group. This means that any host may join a group
receive its traffic. Conversely, hosts may also leave a group at
time. Therefore, the protocol must address how it impacts
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,
corruption of transport state, or requests for
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
any time) [WHA98]
In particular, a transport protocol needs to pay particular
to how it protects itself from denial of service attacks,
mechanisms such as lightweight authentication of control
[HW99].
With Source Specific Multicast service model (SSM), a host
specifically to a sender and group pair. Thus, SSM offers
security against hosts receiving traffic from a denial of
attack where an arbitrary sender sends packets that hosts did
specifically request to receive. Nevertheless, it is
that additional protections against such attacks should be
when using SSM, because the protection offered by SSM against
attacks may not be enough
Sender Authentication, Data Encryption, and Group Key Management
While these functions are not typically part of the transport
per se, a protocol needs to understand what ramifications it has
data security, and may need to have special interfaces to
security layer in order to accommodate these ramifications
Transport Protection. The primary security task for a
layer is that of protecting the transport layer itself from attack
The most important function for this is typically
authentication of control packets in order to prevent corruption
state and other denial of service attacks
Membership Notification. This is the function through which the
source--or upper level agent in a possible
organization--learns about the identity and/or number of receivers
lower level agents. To be scalable, this typically will not
total knowledge of the identity of each receiver
Membership Management. This implements the mechanisms for members
join and leave the group, to accept/refuse new members, or
terminate the membership of existing members
Group Membership Tracking. As an optional feature, a protocol
interface with a component which tracks the identity of each
in a large group. If so, this feature will typically be
out of band, and may be implemented by an upper level protocol.
may be useful for services that require tracking of usage of
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
the parameters needed for its reception. This function is
performed by an upper layer protocol (e.g., [HPW99] and [HJ98]).
Session Start/Stop. These functions determine the start/stop time
sender and/or receivers. In many cases this is implicit or
by an upper level application or protocol. In some protocols
however, this is a task best performed by the transport layer due
scalability requirements
Session Configuration/Monitoring. Due to the potentially
reaching scope of a multicast session, it is particularly
for a protocol to include tools for configuring and monitoring
protocol's operation
Tree Configuration. For protocols which include
elements (such as PGM and RMTP-II), it is important to
these elements in a way that has approximate congruence with
multicast routing topology. While tree configuration could
included as part of the session configuration tools, it is
better if this configuration can be made automatic
4. Building Block
The families of protocols introduced in section 1.1 generally
different mechanisms to implement the protocol functional
described in section 3. This section tries to group these
in macro components that define protocol building blocks
A building block is defined
"a logical protocol component that results in explicit APIs for
by other building blocks or by the protocol client."
Building blocks are generally specified in terms of the set
algorithms and packet formats that implement protocol
components. A building block may also have API's through which
communicates to applications and/or other building blocks.
building blocks should also have a management API, through which
communicates to SNMP and/or other management protocols
In the following section we will list a number of building
which, at this stage, seem to cover most of the functional
needed to implement the protocol families presented in section 1.1.
Nevertheless this list represents the "best current guess", and
such it is not meant to be exhaustive. The actual building
decomposition, i.e., the division of functional components
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
This building block defines NACK-based loss detection/
and recovery. The major issues it addresses are implosion
(suppression) and NACK semantics (i.e., how packets to
retransmitted should be specified, both in the case of selective
FEC loss repair). Suppression mechanisms to be considered are
o Multicast
o Unicast NACKs and Multicast
These suppression mechanisms primarily need to both minimize
while also minimizing redundant messages. They may also need to
special weighting to work with Congestion Feedback
4.2. FEC
This building block is concerned with packet level FEC
when FEC codes are used either proactively or as repairs in
to lost packets. It specifies the FEC codec selection and the
packet naming (indexing) for both reactive FEC repair and pro-
FEC
4.3. Congestion
There will likely be multiple versions of this building block
corresponding to different design policies in addressing
control. Two main approaches are considered for the time being:
source-based rate regulation with a single rate provided to all
receivers in the session, and a multiple rate receiver-
approach with different receivers receiving at different rates in
same session. The multiple rate approach may use multiple layers
multicast traffic [VRC98] or router filtering of a single
[LVS99]. The multiple rate approach is most applicable for
protocols
Both approaches are still in the phase of study, however the
seems to be mature enough [HFW99] to allow the
process to begin
At the time of writing this document, a third class of
control algorithm based on router support is beginning to emerge
the IRTF RMRG [LVS99]. This work may lead to the
standardization of one or more additional building blocks
congestion control
Whetten, et al. Informational [Page 13]
RFC 3048 RMT Building Blocks January 2001
4.4. Generic Router
The task of designing RM protocols can be made much easier by
presence of some specific support in routers. In some application
specific cases, the increased benefits afforded by the addition
special router support can justify the resulting
complexity and expense [FLST98].
Functional components which can take advantage of router
include feedback aggregation/suppression (both for loss
and congestion control) and constrained retransmission of
packets. Another component that can take advantage of router
is intentional packet filtering to provide different rates
delivery of packets to different receivers from the same
packet stream. This could be most advantageous when combined
ALC protocols [LVS99].
The process of designing and deploying these mechanisms
routers can be much slower than the one required for end-
protocol mechanisms. Therefore, it would be highly advantageous
define these mechanisms in a generic way that multiple protocols
use if it is available, but do not necessarily need to depend on
This component has two halves, a signaling protocol and actual
algorithms. The signaling protocol allows the transport protocol
request from the router the functions that it wishes to perform,
the router algorithms actually perform these functions. It is
urgent to define the signaling protocol, since it will likely
the common case protocol headers
An important component of the signaling protocol is some level
commonality between the packet headers of multiple protocols,
allows the router to recognize and interpret the headers
4.5. Tree
It has been shown that the scalability of RM protocols can be
enhanced by the insertion of some kind of retransmission or
aggregation agents between the source and receivers. These
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/
repair nodes in the middle. The internal nodes can either
dedicated software for this task, or they may be receivers that
performing dual duty
The effectiveness of these agents to assist in the delivery of
is highly dependent upon how well the logical tree they use
communicate matches the underlying routing topology. The purpose
Whetten, et al. Informational [Page 14]
RFC 3048 RMT Building Blocks January 2001
this building block would be to construct and manage the logical
connecting the agents. Ideally, this building block would
these functions in a manner that adapts to changes in
membership, routing topology, and network availability
4.6. Data
At the time of writing, the security issues are the subject
research within the IRTF Secure Multicast Group (SMuG).
for these requirements will be standardized within the IETF
ready
4.7. Common
As pointed out in the generic router support section, it is
to have some level of commonality across packet headers. It may
be useful to have common data header formats for other reasons.
building block would consist of recommendations on fields in
packet headers that protocols should make common across themselves
4.8. Protocol
The above building blocks consist of the functional components
in section 3 that appear to meet the requirements for
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
protocol standardized
5. Security
RFC 2357 specifically states that "reliable multicast Internet-
reviewed by the Transport Area Directors must explicitly explore
security aspects of the proposed design." Specifically, RMT
block works in progress must examine the denial-of-service
that can be made upon building blocks and affected by building
upon the Internet at large. This requirement is in addition to
discussions regarding data-security, that is the manipulation of
exposure of session information to unauthorized receivers.
are referred to section 5.e of RFC 2357 for further details
6. IANA
There will be more than one building block, and possibly
versions of individual building blocks as their designs are refined
For this reason, the creation of new building blocks and new
block versions will be administered via a building block
Whetten, et al. Informational [Page 15]
RFC 3048 RMT Building Blocks January 2001
that will be administered by IANA. Initially, this registry will
empty, since the building blocks described in sections 4.1 to 4.3
presented for example and design purposes. The requested
building block registry will be populated from specifications as
are approved for RFC publication (using the "Specification Required
policy as described in RFC 2434 [RFC2434]). A registration
consist of a building block name, a version number, a brief
description, a specification RFC number, and a responsible person,
which IANA will assign the type number
7.
In this document, we briefly described a number of building
that may be used for the generation of reliable multicast
to be used in the application space of one-to-many reliable bulk-
transfer. The list of building blocks presented was derived
considering the functions that a protocol in this space must
and how these functions should be grouped. This list is not
to be all-inclusive but instead to act as guide as to which
blocks are considered during the standardization process within
Reliable Multicast Transport WG
8.
This document represents an overview of a number of building
for one to many bulk data transfer that may be ready
standardization within the RMT working group. The ideas
are not those of the authors, rather they are a summarization of
years of research into multicast transport combined with the
presentations and discussions in the IRTF Reliable Multicast
Group. Although they are too numerous to list here, we
everyone who has participated in these discussions for
contributions
9.
[BKKKLZ95] J. Bloemer, M. Kalfane, M. Karpinski, R. Karp, M. Luby
D. Zuckerman, "An XOR-based Erasure Resilient
Scheme," ICSI Technical Report No. TR-95-048,
1995.
[BLMR98] J. Byers, M. Luby, M. Mitzenmacher, A. Rege, "A
Fountain Approach to Reliable Distribution of Bulk Data,"
Proc ACM SIGCOMM 98.
[FJM95] S. Floyd, V. Jacobson, S. McCanne, "A Reliable
Framework for Light-weight Sessions and Application
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, "
reliable transport protocol specification," Work
Progress
[HFW99] M. Handley, S. Floyd, B. Whetten, "Strawman
for TCP Friendly (Reliable) Multicast Congestion
(TFMCC)," Work in Progress
[HJ98] Handley, M. and V. Jacobson, "SDP: Session
Protocol", RFC 2327, April 1998.
[HPW99] M. Handley, C. Perkins, E. Whelan, "Session
Protocol," Work in Progress, June 1999.
[HW99] T. Hardjorno, B. Whetten, "Security Requirements
RMTP-II," Work in Progress, June 1999.
[RFC2887] Handley, M., Whetten, B., Kermode, R., Floyd, S.,
Vicisano, L. and M. Luby, "The Reliable Multicast
Space for Bulk Data Transfer", RFC 2887, August 2000.
[KCW98] M. Kadansky, D. Chiu, and J. Wesley, "Tree-based
multicast (TRAM)," Work in Progress
[Kermode98] R. Kermode, "Scoped Hybrid Automatic Repeat Request
Forward Error Correction," Proc ACM SIGCOMM 98,
1998.
[LDW98] M. Lucas, B. Dempsey, A. Weaver, "MESH: Distributed
Recovery for Multimedia Streams in Wide-Area
Networks".
[LESZ97] C-G. Liu, D. Estrin, S. Shenkar, L. Zhang, "Local
Recovery in SRM: Comparison of Two Approaches,"
Technical Report 97-648, Jan 1997.
[LG97] B.N. Levine, J.J. Garcua-Luna-Aceves, "Improving
Multicast Routing with Routing Labels,"
International Conference on Network Protocols (ICNP-97),
Oct 28-31, 1997, p.241-250.
[LP96] K. Lin and S. Paul. "RMTP: A Reliable Multicast
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
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. "
multicast congestion control based on router
filtering", RMT working group, June 1999, Pisa, Italy
[MA99] J. Macker, B. Adamson. "Multicast Dissemination
version 2 (MDPv2)," Work in Progress
http://manimac.itd.nrl.navy.mil/
[MRBP98] Mankin, A., Romanow, A., Brander, S. and V.Paxson, "
Criteria for Evaluating Reliable Multicast Transport
Application Protocols", RFC 2357, June 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[OXB99] O. Ozkasap, Z. Xiao, K. Birman. "Scalability of
Reliable Multicast Protocols", Work in Progress,
1999.
[PSLB97] "Reliable Multicast Transport Protocol (RMTP)," S. Paul
K. K. Sabnani, J. C. Lin, and S. Bhattacharyya,
Journal on Selected Areas in Communications, Vol. 15, No
3, April 1997.
[RV97] L. Rizzo, L. Vicisano, "A Reliable Multicast
Distribution Protocol Based on Software FEC Techniques,"
Proc. of The Fourth IEEE Workshop on the Architecture
Implementation of High Performance Communication
(HPCS'97), Sani Beach, Chalkidiki, Greece June 23-25,
1997.
[VRC98] L. Vicisano, L. Rizzo, J. Crowcroft, "TCP-Like
Control for Layered Multicast Data Transfer", Proc.
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
Multicast: Issues and Architectures," Work in Progress
[Whetten99] B. Whetten, "A Proposal for Reliable
Congestion Control Requirements," Work in Progress
http://www.talarian.com/rmtp-ii/overview.
Whetten, et al. Informational [Page 18]
RFC 3048 RMT Building Blocks January 2001
10. Authors'
Brian
Talarian Corporation
333 Distel Circle
Los Altos, CA 94022,
EMail: whetten@talarian.
Lorenzo
Cisco Systems
170 West Tasman Dr
San Jose, CA 95134,
EMail: lorenzo@cisco.
Roger
Motorola Australian Research
Level 3, 12 Lord St
Botany NSW 2019,
EMail: Roger.Kermode@motorola.
Mark Handley, Sally
ATT Center for Internet Research at ICSI
International Computer Science Institute
1947 Center Street, Suite 600,
Berkeley, CA 94704,
EMail: mjh@aciri.org, floyd@aciri.
Michael
600 Alabama
San Francisco, CA 94110
Digital Fountain, Inc
EMail: luby@digitalfountain.
Whetten, et al. Informational [Page 19]
RFC 3048 RMT Building Blocks January 2001
11. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Whetten, et al. Informational [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
