J.Chesterfield
E.Schooler
AT&T Labs - Research
Internet Draft J.Ott
Document: draft-ietf-avt-rtcpssm-00 Tellique Kommunikationstechnik
GmbH
Expires: August 2002 February 2002
RTCP Extensions for Single-Source Multicast Sessions
with Unicast Feedback
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies a modification to the Real-time Transport
Control Protocol (RTCP) to use unicast feedback. The proposed
extension is useful for single source multicast sessions such as
Source Specific Multicast (SSM) communication where the traditional
model of many-to-many group communication is either not possible or
not preferred. In addition, it can be applied to any group that
might benefit from a sender controlled summarised reporting
mechanism.
1. Conventions and Acronyms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119.
Chesterfield Internet Draft - Expires 2002 [Page 1]
RTCP with Unicast Feedback
2. Introduction
The Real-time Transport Protocol (RTP) [1] provides a real-time
transport mechanism suitable for unicast or Internet Standard
multicast communication between multimedia applications. Typical
uses are for real-time or near real-time group communication via
audio and video data streams. An important component of the RTP
protocol is the control channel, defined as the Real-Time Control
Protocol (RTCP). RTCP involves the periodic transmission of control
packets between group members in a session, enabling the
distribution or calculation of session specific information such as
packet loss and round trip time to other hosts, and group size
estimation. An additional advantage of providing a control channel
for a session is that a third-party session monitor can listen to
the traffic to establish network conditions and to diagnose faults
based on receiver locations.
RTP was designed to operate in a unicast mode or in the traditional
multicast mode of Any Source Multicast (ASM) group communication,
where both one-to-many and many-to-many communication are supported
via a common group address in the range 224.0.0.0 through
239.255.255.255. Typical routing protocols that enable such
communication are the Distance Vector Multicast Routing Protocol
(DVMRP) [2] or Protocol Independent Multicast (PIM) [3][4] in
combination with an Inter-domain routing protocol such as Multicast
Border Gateway Protocol (MBGP) [5] with Multicast Source Discovery
(MSDP) [6]. Such routing protocols enable a host to join a single
multicast group address and to send to or to receive data from all
members in the group with no prior knowledge of the membership. In
order to enable such a service in the network, however there is a
great deal of complexity involved at the routing level.
An alternative approach has been developed for multicast groups with
just a single sender. The Source Specific Multicast (SSM) [7] model
has the advantage of removing a great deal of the routing complexity
involved in multicast group creation and source information
distribution. The disadvantage of SSM, with respect to real-time
traffic using RTP, is that the simplification to the routing
protocols removes the ability for any member of the group to
communicate with any other member of the group without an explicit
join to that host.
The solution proposed in this draft defines a new method for
distributing control information amongst all members in a multicast
session and is designed to operate under any multicast group
communication scenario. It is, however, of particular benefit to SSM
sessions in the absence of receivers being able to communicate with
each other directly. The RTP data stream protocol itself is
unaffected. The basic architectural models to which this feedback
method could apply include:
a) SSM groups with a single sender.
Chesterfield Internet Draft - Expires December 2002 [Page 2]
RTCP with Unicast Feedback
This is the main motivation behind the unicast RTCP feedback
mechanism. The proposed extensions allow SSM groups that do not
have many-to-many communication capability to still receive RTP
data streams and to continue to participate in the RTP control
protocol, RTCP. Because SSM adopts the notion of a sender data
channel that provides a one-to-many communication facility from
the source to all the receivers in the group, the RTCP feedback
is unicast to the source on the standard RTCP port.
b) One-to-many broadcast networks.
An example of such a network is a satellite network with a
terrestrial low-bandwidth return channel or a broadband cable
link. This architecture differs very little from the SSM channel
concept, but is likely to require a translator of some kind to
render the RTP data stream onto the satellite or cable
distribution channel.
c) ASM with a single sender.
An SDP session announcement type may identify a session as having
a single sender receiving unicast RTCP feedback. Receivers join
the multicast group address and receive RTP and RTCP data from
the source on the specified address/port combinations. The RTCP
feedback is unicast back to the source on the RTCP port. This
model is not more efficient than a standard multicast group RTP
communication scenario, and is therefore not recommended to
replace the traditional mechanism. However it may be help to
prevent overtaxing multicast routing infrastructure that does not
scale as efficiently.
SSM sessions are typically assigned a value in the group address
range 232.0.0.0 through 232.255.255.255, although this is not a
requirement. A session may be assigned any valid multicast address,
as long as the local network is configured to allow source specific
joins outside the suggested SSM range. In order for a host to
receive traffic from an SSM capable source, it must support the
IGMPv3 multicast group membership reporting protocol, which enables
the host to explicitly request traffic from a (source,group) pair.
An SDP syntax is defined in Section 10 to specify the mode of
operation for the session and the session characteristics such as
the (source, group) identifier and feedback address.
The modifications proposed in this document are intended to
supplement the existing RTCP feedback mechanisms described in [1],
Section 6. For certain distribution networks, such as SSM networks,
this may be a requirement, whereas in others it is an optional
feature that may be used.
3. Basic Operation
This draft proposes two new methods to enable receiver feedback to
all members in a session. Each involves the unicasting of RTCP
packets to a source whose job it is to re-distribute the information
to the members of the group. The source must always be able to
Chesterfield Internet Draft - Expires December 2002 [Page 3]
RTCP with Unicast Feedback
communicate with all group members in order for either mechanism to
work.
The first method, the 'Simple Feedback Model', is a basic mechanism
whereby all Receiver Reports are unicast to the source and
subsequently forwarded by the source to all receivers on the
multicast RTCP channel. The advantage of using this method is that
an existing receiver implementation requires little modification in
order to use it. Instead of sending Receiver Reports to a multicast
address, a receiver uses a unicast address and still receives RTCP
traffic in the usual manner. This method also has the advantage of
being backwards compatible with RTP/RTCP implementations that do not
support unicast feedback to the source and operate using the
standard multicast group communication model, ASM. In a session that
is using ASM, such a receiver would multicast Receiver Reports to
the group address and port+1 as stated in [1]. This would still be
received by all receivers. In a session using SSM, the network
prevents any data from the receiver being distributed further than
the first hop router. Additionally, any data heard from this
receiver by other hosts on the same subnet should be filtered out by
the host IP stack and therefore will not cause any problems with
respect to the calculation of Receiver RTCP bandwidth since this
receiver will not be heard by any other members.
The second method, the 'Sender Feedback Summary Model' is a
summarised reporting scheme that provides savings in bandwidth by
consolidating all the Receiver Reports into one summary packet that
is then distributed to all the receivers. The advantage of this
scheme is apparent for large group sessions where the basic
forwarding mechanism outlined above would create a large amount of
packet replication in order to forward all the information to all
the receivers. The basic operation of the scheme is the same as the
first method, however it requires that all the members in the
session understand the new summarised packet format outlined in
Section 7.1. Additionally, the summarised scheme provides a generic
mechanism for sending distribution information about the data
reported by the whole group. Potential uses for this are addressed
in Section 7.4.
To differentiate between the two reporting mechanisms, a new SDP
identifier is created and discussed in Section 10. The method of
reporting must be decided prior to the start of the session, a
distribution source may not change the method during a session.
4. Definitions
Distribution Source: In order for unicast feedback to work, there
must only be one session distribution source for any subset of
receivers to which RTCP feedback is directed. Heterogeneous
networks comprised of ASM multiple sender groups, unicast-only
clients and/or SSM single-sender receiver groups may be
connected via translators or mixers (see Section 9 for details) to
create a single source group. In order for unicast feedback to work,
Chesterfield Internet Draft - Expires December 2002 [Page 4]
RTCP with Unicast Feedback
only one source must be responsible for distributing the RTP stream
and for forwarding RTCP information to all receivers. That source is
called the distribution source.
RTP and RTCP Channels: The data distributed from the source to the
receivers is referred to as the RTP and RTCP channels. These
channels are differentiated via the port numbers as [port] and [port
+ 1] for RTP and RTCP respectively. See [1] for further explanation
of the port numbering for these channels.
Unicast RTCP Feedback Target: For a session defined as having a
distribution source A, on ports n and n+1, the unicast RTCP feedback
target is the IP address of Source A on port n+1 unless otherwise
stated in the SDP setup information. See Section 10 for details on
how the address is specified.
SSRC: Synchronization source. A 32-bit value that uniquely
identifies each member in a session. See [1] for further
information.
Report blocks: In RTCP [1], it is encouraged to stack multiple
report blocks in Sender and Receiver Report packets. In this way, a
variable size packet is created that can include information from
one source pertaining to multiple sources in the group. The concept
of report blocks is extended in this draft to encompass Generic
Summary Report packets in which a source can optionally stack
multiple reports into one packet in order to provide additional
feedback on the RTCP traffic received from the group.
5. Packet types
The RTCP packet types defined in [1] are:
type description Payload number
SR sender report 200
RR receiver report 201
SDES source description 202
BYE goodbye 203
APP application-defined 204
These remain unmodified. Later profile extensions may be added to
these which are not covered in [1] or this document. In addition to
the existing types, two new packet types are introduced. Further
information on each of these is provided in this draft.
The new packet types are:
type description Payload number
RSI Receiver Summary Information [see Section 12]
GSR General Summary Report [see Section 12]
Within the General Summary Report packet, various types of
distribution data may be reported, each of which requires a
Chesterfield Internet Draft - Expires December 2002 [Page 5]
RTCP with Unicast Feedback
distribution type identifier. Current types addressed in this
document are:
Distribution Type Number
Packet Loss 1
Receiver Jitter 2
Round Trip Time estimation 3
SSRC distribution 4
6. Simple feedback model
6.1 Packet Formats
For this mechanism, the packet types used remain the same as for
standard RTCP feedback in [1]. Receivers still generate Receiver
Reports with information on the quality of the stream received from
the source. The distribution source still must create Sender Reports
that include timestamp information for stream synchronisation and
round trip time calculation. Both the senders and receivers are
required to send SDES packets as outlined in [1]. The rules for
generating BYE and APP packets as outlined in [1] also apply.
6.2 Distribution Source behaviour
For the simple feedback model, the source provides a simple packet
reflection mechanism. It is the default behaviour for any
distribution source and is the minimum requirement for acting as a
source to a group of receivers using unicast RTCP feedback.
The source may not stack report blocks received from different SSRCs
into one packet for retransmission to the group. Every RTCP packet
from each receiver must be reflected individually.
The source must listen for unicast RTCP data sent to the RTCP port.
All unicast data received on this port must be forwarded to the
group on the multicast RTCP channel. Any multicast data received on
this port must not be forwarded but processed as defined in [1].
The reflected traffic should not be included in the transmission
interval calculation by the source. In other words, the source
should not consider reflected packets as part of it's own control
data bandwidth allowance. The algorithm for computing the allowance
is explained in Section 9. The control bandwidth traffic included in
the calculation includes any Sender reports to the group, along with
any additional SDES and APP packets.
If an application wishes to use APP packets, it is recommended that
the 'Simple Feedback Model' be used since it is likely that all
receivers in the session will need to hear the APP specific packets.
The same applies for all other future RTCP packets that are not
defined in the base RTP specification [1]. This decision must be
made in advance of the session and indicated in the SDP
announcement.
Chesterfield Internet Draft - Expires December 2002 [Page 6]
RTCP with Unicast Feedback
6.3 Receiver behaviour
Receivers listen on the RTP and RTCP channels for data. Each
receiver calculates its share of the receiver bandwidth based on the
standard rules, i.e., 75% of the RTCP bandwidth is divided equally
between all unique SSRCs in the session. See Section 9 for further
information on the calculation of the bandwidth allowance. When a
receiver is eligible to transmit, it sends a unicast Receiver Report
packet to the RTCP port of the distribution source.
7. Sender feedback summary model
In the sender feedback summary mode, the sender is required to
summarise the information received from all the Receiver Reports
generated by the receivers and place the information into summary
reports. The sender feedback summary model introduces two new
packets. The Receiver Summary Information packet (RSI) which must be
sent by a source if the summarised feedback mechanism is selected
and the optional General Summary Report packet (GSR) that may be
appended to the RSI packet to provide more detailed information on
the overall session characteristics reported by all receivers.
The sender must send at least one Receiver Summary Information
packet for each reporting interval. The sender can additionally
stack General Summary Reports(GSRs) after the RSI packet. Each GSR
packet corresponds to the initial RSI packet and acts as an
enhancement to the basic summary information required by the
receivers to calculate their reporting time interval. For this
reason, GSR packets are not required but recommended. RSI and GSR
packets are sent in addition to the standard Sender Reports and SDES
packets outlined in [1].
7.1 Packet Formats
Chesterfield Internet Draft - Expires December 2002 [Page 7]
RTCP with Unicast Feedback
7.1.1 RSI: Receiver Summary Information RTCP Packet
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| SC | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| group size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AFL | HCNL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest interarrival jitter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver RTCP Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| collision SSRC #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
The RSI packet consists of a main report block modeled along the
same lines as a Receiver Report with optional GSR blocks appended.
The first eight bytes of header extension follow the standard RTP
header outline. This ensures backwards compatibility with older
versions that may not understand the RSI packet format but can read
the length field indicating the end of the report block. The
following fields are included:
The fields "V", "P", and "length" have the same meaning as per [1].
SC: 5 bits
The number of collision SSRC entries towards the end of the
report block. A value of 0 is allowed, indicating that no
collisions are reported.
SSRC: 32 bits
The synchronisation source identifier for the originator of the
summary report packet.
timestamp: 32 bits
The time the packet was sent. This is an unsigned integer value
displayed in NTP timestamp units to enable detection of duplicate
packets, reordering and to provide a chronological profile of the
feedback reports.
group size: 32 bits
This field provides the sender's view of the number of receivers
in a session. This should include the sender itself and any other
senders potentially connected to the session e.g. via a
mixer/translator gateway. The group size is calculated according
to the rules outlined in [1].
Chesterfield Internet Draft - Expires December 2002 [Page 8]
RTCP with Unicast Feedback
average fraction lost (AFL): 8 bits
The average fraction lost indicated by Receiver Reports forwarded
to this source, expressed as a fixed point number with the binary
point at the left edge of the field.
highest cumulative number of packets lost (HCNL): 24 bits
Highest 'cumulative number of packets lost' value out of all RTCP
RR packets since the last RSI from any of the receivers.
highest interarrival jitter: 32 bits
Highest 'interarrival jitter' value out of all RTCP RR packets
since the last RSI from any of the receivers.
receiver bandwidth: 32 bits
indicates the maximum bandwidth allocated to any single receiver
for sending RTCP data relating to the session. This is a fraction
value indicating a percentage of the session bandwidth, expressed
as a fixed point number with the binary point at the left edge of
the field.
collision SSRC: n x 32 bits
the final fields in the packet are used to identify any SSRCs
that are duplicated within the group. Usually this is handled by
the hosts upon detection of the same SSRC, however since
receivers no longer have a global view of the session, the
collision algorithm is handled by the source. SSRCs that collide
are listed in the packet and it is the responsibility of the
receiver(s) to detect the collision and select another SSRC.
7.1.2 GSR: General Summary Report RTCP Packet Header
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| BC | PT | Length |header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Sender |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |report
| ... |blocks
The GSR packet is a three-level structure composed of a header and
zero or more report blocks, each of which describes a range of
distribution values. The report blocks are a variable length, with a
fixed header and are described in subsequent sections.
The fields "V", "P", and "length" have the same meaning as per [1].
block count (BC): 5 bits
The number of report blocks contained in this packet
Chesterfield Internet Draft - Expires December 2002 [Page 9]
RTCP with Unicast Feedback
SSRC of Sender: 32 bits
The SSRC of the distribution source
7.1.3 GSR Report block
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| DT | NDB | MF | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Minimum Distribution Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Distribution Value |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Distribution Buckets |
| ... |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
distribution type (DT): 8 bits
A numeric identifier to indicate the significance of the
distribution values. The items currently defined are described in
the next sections. Additional items may be defined in a separate
profile by registering the type numbers with IANA, see Section
12.
number of distribution buckets (NDB): 12 bits
The number of distribution Buckets within the data. The size of
the bucket can be calculated using the formula, number of bits
equals (length * 4 * 8)/NDB. Providing 12 bits enables bucket
sizes as small as 2 bits for a full length packet. The bucket
size in bits must always be divisable by 2 to ensure byte
alignment. A bucket size of 2 bits is fairly restrictive,
however, and it is expected that larger bucket sizes will be more
practical for most distributions.
multiplicative factor (MF): 4 bits
Indicates the multiplicative factor to be applied to each
distribution Bucket value. Possible values are 1 - 15.
length: 8 bits
The length of the whole GSR data packet in 4 byte units. The full
length of the packet in bytes is calculated by multiplying the
length value by 4. This tells the receiver the full length of the
packet and enables the receiver to identify the bucket size. The
maximum data portion of the packet therefore may be 1008 bytes
which would provide up to 4032 data buckets of length 2 bits, or
2016 data buckets of length 4 bits etcà.
Chesterfield Internet Draft - Expires December 2002 [Page 10]
RTCP with Unicast Feedback
minimum distribution value: 32 bits
The Minimum distribution value, in combination with the Maximum
Distribution value, indicates the range covered by the Data
Bucket values.
maximum distribution value: 32 bits
The Maximum distribution value, in combination with the Minimum
Distribution value, indicates the range covered by the Data
Bucket values.
distribution buckets: each bucket is((length * 4) û 12)*8/NDB bits
The size and number of buckets depends upon the value of NDB and
the length of the packet. In order to calculate the size of the
bucket, the formula ((length * 4) û 12)*8/NDB should be used.
This indicates the division of the data space and the size of
each data point in bits. Each value must be multiplied by the
multiplicative factor.
Interpretation of the minimum, maximum and distribution values in
the report block are profile-specific and are addressed
individually. The size of the report block is variable, as indicated
by the packet length field.
7.1.4 GSR Loss report block
GSR loss report blocks indicate the distribution of losses as
reported by the receivers to the distribution source. Values are
expressed as a fixed point number with the binary point at the left
edge of the field. The distribution type is 1.
Valid results for the Minimum Distribution Value field are 0 - 99,
otherwise interpreted as 0 - 0.99. Similarly, Valid results for the
maximum distribution value field are 1 - 100, otherwise interpreted
as 0.1 - 1. The Minimum Distribution Value must always be less than
the maximum.
For examples on processing GSR loss report blocks, see the Appendix.
7.1.5 GSR Jitter report block
GSR jitter report blocks indicate the distribution of the estimated
statistical variance of the RTP data packet interarrival time
reported by the receivers to the distribution source. See [1] for
details on how the values are calculated and the relevance of the
jitter results. Jitter values are measured in timestamp units and
expressed as unsigned integers. The Minimum Distribution Value must
always be less than the maximum. The distribution type is 2.
7.1.6 GSR Round Trip Time report block
GSR round trip time reports indicate the distribution of round trip
times from the distribution source to the receivers. The
Chesterfield Internet Draft - Expires December 2002 [Page 11]
RTCP with Unicast Feedback
distribution source is the only member of the group capable of
calculating the round trip time to any other members since it is the
only sender in the group. The sender has the option of distributing
these round trip time estimations to the whole group, uses of which
are described in Section 7.4. Round trip times are measured in
timestamp units and expressed as unsigned integers. The
multiplicative factor can be used to reduce the number of bits
required to represent the values. The Minimum Distribution Value
must always be less than the maximum. The distribution type is 3.
7.1.7 SSRC Distribution report block
SSRC Distributions are an optional feature that can be provided by
the distribution source to indicate the allocation of SSRCs across
the group. SSRCs are expressed as unsigned integers. The
multiplicative factor can be used to reduce the number of bits
required to represent the values. The Minimum Distribution Value
must always be less than the maximum. The distribution type is 4.
7.2 Distribution Source behaviour
The length field of the RSI packet must be calculated over the
length of the whole RSI packet, using the method defined in [1]. The
group size must be included in the RSI packet. The source should
also calculate the Receiver RTCP bandwidth field. Typically this
value will be calculated as outlined in [1] using the group size and
session bandwidth as variables. This field however does provide the
source with the capability to control the amount of feedback from
the receivers and can be increased or decreased based on the
requirements of the source. Regardless of the value selected by the
source for the RTCP bandwidth field, the source must continue to
forward Sender reports and RSI packets at the rate allowed by its
bandwidth allocation. See Section 9 for further details.
In order to identify SSRC collisions, the source is responsible for
maintaining a record of each SSRC and the corresponding CNAME within
at least one reporting interval in order to differentiate between
clients. It is recommended that an updated list of more than one
interval be maintained to increase accuracy. This mechanism should
prevent the possibility of collisions since the combination of SSRC
and CNAME should be unique if the CNAME is generated correctly. In
the event that collisions are not detected, the effect will be an
inaccurate impression of the group size on the part of the source.
Since the statistical probability that collisions will both occur
and be undetectable is very low, the clients would have to randomly
select the same SSRC and have the same username + IP address (e.g.
using private address space behind a NAT router), this should not be
a significant concern.
For the GSR packet, the source must decide which are the most
significant feedback values to convey. The packet format provides
flexibility in the amount of detail conveyed by the data points.
There is a trade-off between the granularity of the data and the
accuracy based on the factorisation values, the number of buckets
Chesterfield Internet Draft - Expires December 2002 [Page 12]
RTCP with Unicast Feedback
and the min and max values. In order to focus on a particular region
of the distribution, the source can adjust the minimum and maximum
values and either increase the number of buckets and possibly the
factorisation, or decrease the number of buckets and provide more
accurate values. See Appendix B for detailed examples on how to
convey information in RTCP Receiver Reports as GSR information.
The results should correspond as near as possible to the values
received during the interval since the last report. The source may
stack as many report blocks as required in order to convey different
distributions. If the distribution size exceeds the largest packet
length (1008 bytes data portion), more packets may be stacked with
additional information up to the MTU of the connection.
7.3 Receiver behaviour
The receiver must process RSI packets and adapt session parameters
such as the RTCP bandwidth based on the information received. The
receiver no longer has a global view of the session, and will
therefore be unable to receive information from individual receivers
aside from itself. However, the information portrayed by the source
can be extremely detailed, providing the receiver with an accurate
view of the session quality overall, without the processing overhead
associated with listening to and analysing all the Receiver Reports.
The SSRC collision list must be checked against the SSRC selected by
the receiver to ensure there are no collisions. The group size value
provides the receiver with the data necessary to calculate it's
share of the RTCP bandwidth. This share of the bandwidth may be
overridden by the 'Receiver RTCP Bandwidth' field. This field
provides the source with the capability to control the amount of
feedback from the receivers.
The receiver can handle the GSR data as desired. This data is most
useful in providing the receiver with a more global view of the
conditions experienced by other receivers, and enables the client to
place itself within the distribution and establish the extent to
which it's reported conditions correspond to the group reports as a
whole. Appendix A provides further information and examples of data
processing at the receiver.
The receiver should assume that any report blocks in the same packet
correspond to the same data set received by the source during the
last reporting time interval. This applies to packets with multiple
blocks, where each block conveys a different range of values.
7.4 Analyzing summarised reports
Providing a distribution function in a feedback message has a number
of uses for different types of applications. Although this section
enumerates potential uses for the distribution scheme, it is
Chesterfield Internet Draft - Expires December 2002 [Page 13]
RTCP with Unicast Feedback
anticipated that future applications might benefit from it in ways
not addressed in this document. Due to the flexible nature of the
GSR packet format, future extensions may easily be added. Some of
the scenarios addressed in this section envisage potential uses
beyond a simple SSM architecture. For example, single-source group
topologies where every receiver may in fact also be capable of
becoming the source. Another example may be multiple SSM topologies
which combined make up a larger distribution tree.
A distribution function is useful as input into any algorithm,
multicast or otherwise, that could be optimized or tuned as a result
of having access to the feedback values for all group members.
Following is a list of example areas that might benefit from
distribution information:
- The parameterization of a multicast Forward Error Correction (FEC)
algorithm. Given an accurate estimate of the distribution of
reported losses, a source or other distribution agent, which does
not have a global view, would be able to tune the degree of
redundancy built in to the FEC stream. The distribution might help
to identify whether the majority of the group is experiencing high
levels of loss, or whether in fact the high loss reports are only
from a small subset of the group. Similarly, this data might enable
a receiver to make a more informed decision about whether it should
leave a group when it is a very high percentage of the worst case
reporters.
- The organization of a multicast data stream into useful layers for
layered coding schemes. The distribution of packet losses and delay
would help to identify what percentage of members experience various
loss and delay levels, and thus how the data stream bandwidth might
be partitioned to suit the group conditions.
- The establishment of a suitable feedback threshold. An application
might be interested to generate feedback values when above (or
below) a particular threshold. However, determining an appropriate
threshold may be difficult when the range and distribution of
feedback values is not known a priori. In a very large group,
knowing the distribution of feedback values would allow a reasonable
threshold value to be established, and in turn would have the
potential to prevent message implosion if many group members share
the same feedback value. A typical application might include a
sensor network that gauges temperature or some other natural
phenomenon. Another example is a network of mobile devices
interested in tracking signal power to assist with hand-off to a
different distribution device when power becomes too low.
- The tuning of Suppression algorithms. Having access to the
distribution of round trip times, bandwidth, and network loss would
allow optimization of wake-up timers and proper adjustment of the
Suppression interval bounds. In addition, biased wake-up functions
could be created not only to favor the early response from more
Chesterfield Internet Draft - Expires December 2002 [Page 14]
RTCP with Unicast Feedback
capable group members, but also to smooth out responses from
subsequent respondents and to avoid bursty response traffic.
- Leader election among a group of processes based on the maximum or
minimum of some attribute value. Knowledge of the distribution of
values would allow a group of processes to select a leader process
or processes to act on behalf of the group. Leader election can
promote scalability when group sizes become extremely large.
8. Mixer/Translator issues
The original RTP specification allows for the use of mixers and
translators in an RTP session which help to connect heterogeneous
networks into one session. There are a number of issues, however,
which are raised by the unicast feedback model proposed in this
document. The term 'mixer' refers to devices that provide data
stream multiplexing where multiple sources are combined into one
stream. Conversely, a translator does not multiplex streams, but
simply acts as a bridge between two distribution mechanisms, e.g., a
unicast-to-multicast network translator. Since the issues raised by
this draft apply equally to either a mixer or translator, they are
referred to from this point onwards generically as a gateway.
A gateway between distribution networks in a session must ensure
that all members in the session receive all the relevant traffic to
enable the usual operation by the clients. A typical use may be to
connect an older implementation of an RTP client with an SSM
distribution network, where the client is not capable of unicasting
feedback to the source. In this instance the gateway must join the
session on behalf of the client and send and receive traffic from
the session to the client. Certain hybrid scenarios may have
different requirements.
8.1 Use of a mixer-translator
The gateway must adhere to the SDP descriptor for the single source
session and use the feedback mechanism indicated. Receivers should
be aware that by introducing a gateway into the session, more than
one source may potentially be active in a session since the gateway
may be forwarding traffic from either multiple unicast sources or
from an ASM session to the SSM receivers. Receivers should still
forward unicast RTCP reports in the usual manner to the distribution
source, which in this case would be the gateway itself. It is
recommended that the simple packet reflection mechanism be used
under these circumstances since attempting to coordinate RSI + LJS
reporting between more than one source may be complicated unless the
gateway is capable of undertaking the summarisation itself.
Chesterfield Internet Draft - Expires December 2002 [Page 15]
RTCP with Unicast Feedback
8.2 Encryption and Authentication issues
Encryption and security issues are discussed in detail in Section
11. A gateway must be able to follow the same security policy as the
client in order to unicast forward RTCP data to the source, and it
therefore must be able to apply the same authentication and/or
encryption policy required for the session. Transparent bridging,
where the gateway is not acting as the distribution source, and
subsequent unicast feedback to the source is only allowed if the
gateway can conduct the same source authentication as required by
the receivers.
9. Transmission interval calculation
The Control Traffic Bandwidth referred to in [1] is an arbitrary
amount which is intended to be supplied by a session management
application (e.g., [9]) or decided based upon the bandwidth of a
single sender in a session. A receiver must calculate the number of
other members in a session based upon either its own SSRC count
determined by the forwarded Receiver Reports, or from the RSI report
from a sender.
The RTCP transmission Interval calculation remains the same as in
the original RTP specification [1]. In the original specification,
the senders are allocated 1/4 of the control traffic bandwidth if
they number 25% or less than the group size. Otherwise the
allocation for senders is the percentage of senders to group size.
The remaining bandwidth is allocated to the receivers to be divided
evenly amongst the group. The source should calculate the
transmission interval for RSI + LJS packets out of its 1/4 of the
control traffic bandwidth with a minimum transmission interval of 5
seconds.
10. SDP Extensions
The Session Description Protocol (SDP) is used as a means to
describe media sessions in terms of their transport addresses,
codecs, and other attributes. Providing RTCP feedback via unicast as
specified in this document constitutes another session parameter
needed in the session description. Similarly, parameters of SSM RTCP
feedback -- such as the mode of summarizing information at the
sender and the target unicast address to which to send feedback
information -- need to be provided. This section defines the SDP
parameters that are needed by the proposed mechanisms in this draft
(and that also need to be registered with IANA).
10.1 SSM RTCP Session Identification
A new session level attributes MUST be used to indicate the use of
unicast instead of multicast feedback: "rtcp:unicast".
Chesterfield Internet Draft - Expires December 2002 [Page 16]
RTCP with Unicast Feedback
This attribute uses one additional parameter to specify the mode of
operation.
rtcp:unicast reflection -- MUST be used to indicate packet
reflection by the RTCP target (without further processing).
rtcp:unicast gsr -- MUST be used to indicate the "General
Summary Report" mode of operation.
rtcp:unicast rsi -- MUST be used to indicate the "Receiver
Summary Information" mode of operation.
10.2 SSM Source Specification
In addition, in an SSM RTCP session, the sender(s) need to be
indicated for both source-specific joins to the multicast group as
well as for addressing RTCP packets to.
This is done following the proposal for SDP source filters
documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15].
From this specification, only the inclusion mode ("a=incl:") MUST be
used for SSM RTCP.
There SHOULD be exactly one "a=incl:" attribute listing the address
of the sender. The RTCP port MUST be derived from the m= line of
the media description.
An optional alternative feedback address may be supplied using an
attribute such as a=rtcp:<port> IN IP4 192.168.1.1.
11. Security Considerations
11.1 Assumptions
RTP/RTCP is a protocol for carrying real-time multimedia traffic,
and therefore one of the main considerations for any security
solution must be to maintain as low an overhead as possible in order
to limit processing constraints. This includes the consideration of
overhead for different types of cryptographic operations on data, as
well as considerations for deploying or creating security
infrastructure for large groups.
The distribution of session parameters, typically using SDP type
information through SAP, email or the web is beyond the scope of
this document. It is recommended, however, that the method used
should employ adequate security measures to ensure the integrity and
authenticity of the information. For the purposes of this analysis,
it is assumed that the information has already been securely
distributed out-of-band.
Chesterfield Internet Draft - Expires December 2002 [Page 17]
RTCP with Unicast Feedback
It is also assumed that the multicast or group distribution
mechanism e.g. the SSM routing tree, is not immune to source IP
address spoofing or traffic snooping. All security weaknesses are
therefore addressed from a transport level perspective or above.
11.2 Security threats
Attacks on this architecture may take a variety of forms, and in
order to identify the security weaknesses, it is important to
address these individually.
a) Denial of Service
A major area of concern would be a distributed denial of service
attack. Due to the nature of the communication architecture this
is a situation that could be generated a number of ways by using
the unicast feedback characteristic as a weakness. Since standard
multicast communication does not typically involve many to one
unicast forwarding of data, this poses new challenges for a
security solution.
b) Packet Forgery
One potential area of attack to guard against is packet forgery.
In particular, it is important to protect against the integrity
of certain influential packets since compromise of certain
control packets could directly affect the transmission
characteristics of the whole group, however for the purposes of
defining a security profile, every packet is considered equally
as important. In the case of a large group, the compromise of
RTCP traffic could have serious consequences.
c) Session Replay
An additional concern is the potential for session recording and
subsequent replay. The issue to deal with in particular in this
instance is that an attacker may not actually need to understand
the packet contents, but just simply have the ability to record
the data stream and at a later time replay it with a spoofed
source address.
d) Eavesdropping on a session
The consequences of eavesdropping by an attacker on a session may
not directly constitute a security weakness, however it might
benefit other types of attack, and should therefore be considered
as a potential threat to guard against.
11.3 Security properties
Three types of security that may be applied to combat the issues
identified above seem relevant for these contexts.
a) Data integrity
Chesterfield Internet Draft - Expires December 2002 [Page 18]
RTCP with Unicast Feedback
This ensures that the data received from the network has not been
tampered with by any third party, either maliciously or through a
network error. This type of test ensures that the packet received
is guaranteed to be in exactly the same condition as that source
intended it to be. This does not guard against the authenticity
of the source that created the packet.
b) Data authenticity
In order to determine what entity is generating certain data, an
authenticity mechanism is required. This guarantees that the
creator of the data is known to the receiver and that the
receiver can trust the content of the data assuming the data
integrity has also been secured.
c) Data confidentiality
In order to restrict information access to authorized entities,
confidentiality may also be required. This ensures that only
authorized clients can understand the data that they receive. It
does not prevent eavesdroppers receiving the traffic and having
the capability to replay information in it's original form to
other clients with the capability to understand the information.
d) Replay protection
Ensures that given some pre-determined range of either time or
session values, a host can determine whether the data was
transmitted within the given window.
11.4 Architectural Contexts
In order to understand the potential weaknesses to guard against, it
is necessary to divide the communication model into a number of
distinct contexts.
a) Source to Receiver communication
The first, and perhaps most influential context to protect, is
the ædownstreamÆ communication channel from the source to the
receivers. This is effectively the main controlling influence
over the behaviour of the group since it determines the bandwidth
allocation for each receiver and hence the rate at which the RTCP
traffic is directly unicast back to the source. All traffic that
is distributed over the downstream channel should be generated by
a single source. Both the RTP data stream and the RTCP control
data are sent over this channel. The RTCP data is indirectly
influenced by the information the source has received from the
whole group.
This context is vulnerable to all four attacks outlined in the
previous section. A denial of service attack from the source to
the receivers is possible, but less of a concern since the worst
case effect of sending large volumes of traffic over the
distribution channel has the potential to reach every receiver,
Chesterfield Internet Draft - Expires December 2002 [Page 19]
RTCP with Unicast Feedback
but only on a one-to-one basis, this is no different from the
current multicast model where an individual source may send large
volumes of traffic to a multicast group. The real danger of
denial of service attacks in this context comes indirectly via
compromise of the source RTCP traffic. If receivers are provided
with an incorrect group size estimate or bandwidth allowance, the
return traffic to the source may create a Distributed DoS effect
on the source. Similarly, an incorrect feedback address whether
as a result of a malicious attack or by mistake e.g. an IP
address typing error, could directly create a denial of service
attack on another host which must also be guarded against.
The danger of Packet forgery in the worst case may be to
maliciously instigate a denial of service attack, e.g. if an
attacker were capable of spoofing the source address and
injecting incorrect packets into the data stream or intercepting
the source RTCP traffic and modifying the fields. Other
consequences of packet forgery in this context may be the
compromise of data affecting the integrity of the data received
both in the RTP stream itself and the RTCP data in general.
The replay of a session would have the effect of recreating the
receiver feedback to the source address at a time when the source
is not expecting additional traffic from a potentially very large
group. The consequences of this type of attack may be less
effective on their own, but in combination with other attacks
might be serious.
Eavesdropping on the session would provide an attacker with
information on the charateristics of the source to receiver
traffic such as the frequency of RTCP traffic and, if
unencrypted, might also provide valuable information on
characteristics such as group size and transmission
charateristics of the receivers back to the source in addition to
enabling an attacker to listen to the media streams. In this
context, the attacker might also have access to personal
information carried in the SDES packets such as email, phone and
full username information.
b) Receiver to source or gateway communication
The second context to address is the return traffic from the
group to the source or gateway which for the purposes of this
analysis may be considered in the same light as a distribution
source. This traffic should only be RTCP type data, and should
include receiver reports, SDES information and possibly
Application specific packets. The effects of compromise on a
single or subset of receivers is less likely to have as great an
impact as the first context, however much of the responsibility
for detecting compromise of the source data stream relies on the
receivers.
The effects of compromise of the first context with respect to
critical source RTCP control information would be witnessed most
seriously in the second context. A large group of receivers may
Chesterfield Internet Draft - Expires December 2002 [Page 20]
RTCP with Unicast Feedback
unwittingly generate a distributed DoS attack on the source in
the event that the intergrity of the source RTCP channel has been
compromised and the security breach is not detectable by the
individual receivers.
In the event that packet forgery may occur in this context, the
effect may be the introduction of false RTCP traffic and/or the
creation of fake SSRC identifiers. Such an attack might slow down
the overall control channel data rate, since an incorrect
perception of the group size may be created. This might affect
external issues such as group accounting and other as yet unknown
potential uses of the distribution functionality for controlling
group behaviour such as leader election based on feedback
criteria.
A replay attack on receiver return data to the source would have
the same implications as the generation of false SSRC identifiers
and RTCP traffic to the source. It is therefore equally as
important to protect against compromise of any receiver
contribution to the RTCP channel as it is to ensure authenticity
and freshness of the data source.
Eavesdropping in this context may potentially provide an attacker
with a great deal of personal information about a large group of
receivers available from SDES packets. It would also provide an
attacker with information on group traffic generation
characteristics and parameters for calculating individual
receiver bandwidth allowance.
11.5 Requirements in each context
Some initial requirements to consider for each context in general
are that the overhead of ensuring the security of the session should
be kept as low as possible. This entails keeping the setup and
communication of shared or private keys to a minimum. The nature of
RTP/RTCP traffic is that sessions require real-time processing and
minimal overhead for communication. This means that processing
constraints imposed by techniques such as public/private key
encryption versus stream ciphers using shared keys are an important
consideration for defining this security profile.
Having identified the security weaknesses for each communication
context, security type requirements can be addressed for each.
a) The first context is concerned with denial of service attacks
through possible packet forgery. The forgery may take the form of
interception and modification of packets from the source, or
simply injecting false packets into the distribution channel. To
combat these attacks, data integrity and source authenticity are
required. The degree of confidentiality which may be deployed is
not a requirement in this context since the actual consequences
of eavesdropping do not affect the operation of the protocol,
Chesterfield Internet Draft - Expires December 2002 [Page 21]
RTCP with Unicast Feedback
however without confidentiality, access to personal and group
characteristics information would be unrestricted to an external
listener and it is therefore recommended.
b) The second context must defend against the same kinds of attacks.
Data integrity is required to ensure that interception and
modification of an individual receiverÆs RTCP traffic is not
accomplished. This is to protect against the false influence of
group control information and the possible serious compromise of
future services provided by the distribution functionality such
as leader election based on various parameters. In order to
ensure data integrity, receiver authenticity is therefore an
additional requirement in order to ensure the origin of the data
is secure. The same situation applies as in the first context
with respect to data confidentiality, and it is recommended that
precautions should be taken to protect the privacy of the data.
11.6 Overview of existing security solutions
This section addresses some existing group security mechanisms and
identifies which aspects of the security requirements they might
provide. This security analysis is a work in progress, and these
options will be explored in more detail in subsequent versions of
the draft.
SRTP provides confidentiality of the RTP and RTCP packets as well as
protection against integrity compromise and replay attacks. It
provides authentication of the data stream, however it does not
provide authentication on a per-user basis. This means that a packet
can be authenticated as having originated from one of the session
members, but it does not indicate which member. All keys for an SRTP
session are derived from a single master key which it is assumed has
been distributed via some out-of-band secure method.
A more general group security profiles which should be considered
are the Group Domain of Interpretation which provides a solution for
multicast IPSec ESP security with group authentication.
GSAKMP is perhaps the most detailed solution which provides group
access control, key generation and facilities for rekeying the whole
group.
These options will be considered individually in later releases of
the draft.
12. IANA Considerations
Based on the guidelines suggested in [10], this document proposes 2
new RTCP data payload types for consideration by IANA, and 4 new
Chesterfield Internet Draft - Expires December 2002 [Page 22]
RTCP with Unicast Feedback
sub-payload types for summary distribution types, defined in section
5.
Furthermore, four new SDP media-level attributes are defined in
Section 10.
13. Outstanding Issues
6.2 Complication with detecting unicast versus multicast transmitted
data on the same port.
Add Backwards compatibility section
Include implications of recent changes to port/port+1 rules for
RTP/RTCP traffic.
14. References
[1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP -
A Transport Protocol for Real-time Applications," Internet
Draft, draft-ietf-avt-rtp-new-10.txt, Work in Progress, July 2001.
[2] Pusateri, T, "Distance Vector Multicast Routing Protocol",
draft-ietf-idmr-dvmrp-v3-10, August 2000
[3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol
Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", draft-ietf-pim-sm-v2-new-02.txt, March 2001
[4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM-
DM" draft-ietf-pim-refresh-02.txt, November, 2000
[5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree
Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999
[6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H,
Hall, J, "Multicast Source Discovery Protocol (MSDP)", draft-ietf-
msdp-spec-06.txt, July 2000
[7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol
Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March
2000.
[8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific
Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000.
[9] Session Directory Rendez-vous (SDR), developed at University
College London by Mark Handley and the Multimedia Research Group.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
Chesterfield Internet Draft - Expires December 2002 [Page 23]
RTCP with Unicast Feedback
[11] Handley, M, Perkins, C, Whelan, E, "Session Announcement
Protocol", (SAP), RFC 2974, October 2000.
[12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., Nov 18, 1996.
[13] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source
Authentication Transform", draft-irtf-smug-tesla-00.txt.
[14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The
Secure Real Time Transport Protocol", draft-ietf-avt-srtp-01.txt.
[15] B. Quinn, "SDP Source-Filters", Internet Draft draft-ietf-
mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000.
15. Appendix
A GSR packet processing at the receiver
A.1 Algorithm
Example processing of Loss Distribution Values
X values represent the loss percentage.
Y values represent the number of receivers.
Number of x values is the NDB value
xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV)
First data point = MnDV,first ydata
then
Foreach ydata => xdata += (MnDV + (xrange / NDB))
A.2 Pseudo-code
Packet Variables -> factor,NDB,MnDVL,MaDV
Code variables -> xrange, ydata[NDB],x,y
xrange = MaDV - MnDV
x = MnDV;
B GSR packet creation at the source
See Postscript version.
C AUTHORS ADDRESSES
Julian Chesterfield
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
julian@research.att.com
Chesterfield Internet Draft - Expires December 2002 [Page 24]
RTCP with Unicast Feedback
Eve Schooler
AT&T Labs - Research
75 Willow Road
Menlo Park, CA 94025
schooler@research.att.com
Joerg Ott
Tellique Kommunikationstechnik GmbH
Berliner Str. 26
D-13507 Berlin
GERMANY
Phone: +49.30.43095-560 (sip:jo@tzi.org)
Fax: +49.30.43095-579
Email: jo@tellique.com
D FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2000). 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 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."
Chesterfield Internet Draft - Expires December 2002 [Page 25]