Internet Engineering Task Force Network Working Group
INTERNET-DRAFT J. Crowcroft (UCL)
Expires 15 Sept, 1998 L. Vicisano (UCL)
March, 1998 Z. Wang (Bell Labs)
A. Ghosh (UTS)
M. Fuchs (U. Karlsruhe)
C. Diot (INRIA)
T. Turletti (INRIA)
RMFP: A Reliable Multicast Framing Protocol
<draft-crowcroft-rmfp-02.txt>
Status of this Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. Please send comments to
the authors.
1. Introduction
There has been considerable interest in reliable multicast, and a
number of reliable multicast transport applications and systems have
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
been built in the past years, e.g. [PGM], [RMDP], [RMTP], [SRM]. A
survey of most of current reliable multicast protocols is available in
[Diot97].
Reliable multicast transport is considerably more complex than
reliable unicast. It is generally difficult to build a generic
reliable transport protocol for multicast, much as TCP is a generic
transport protocol for unicast, since different applications often
have very different reliability requirements and modes of operation.
In this document we propose a framing protocol for reliable multicast
transport - Reliable Multicast Framing Protocol (RMFP). RMFP runs over
multicast UDP and itself does not provide any reliability (or
functionality in a larger extend). Reliability and other protocol
functionalities will be defined in specific profiles. The purpose of
RMFP is to provide a common framework upon which a set of reliable
multicast systems can be built and share similar functionalities where
exist.
The philosophy of RMFP is in many respects similar to the one of RTP.
However, we believe that using RTP for reliable multicast is not a
right approach and will not lead to a clean application design.
This draft is intended to stimulate more discussion on the one issue
of a generic framing protocol for reliable multicast.
2. Design Philosophy
This section presents the key mechanisms that have been the foundation
for the specification of RMFP.
2.1. Error Control
Since RMFP is a framework for reliable multicast, the error control is
the most important issue. RMFP itself provides no error control
functionality, this is the task of the protocol profiles. However,
since RMFP follows the ALF principle [Clark90], some of the error
control functionalities have to be provided by the application.
o RMFP specifies the format of the ADUs. The sequence number field
and the FEC and retransmissions flags of the ADU header are
primarily provided for the protocol profiles to be used for error
control.
Crowcroft and al. [Page 2]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
o Any protocol profile has to be able to detect the loss of ADUs and
to initiate the retransmissions. This includes the transmission of
control information from a receiver that suffered a loss to some
group member that can perform the retransmission.
The ALF principle introduces ADUs as common unit of transmission for
all layers from the transport protocol up to the application. To
enable the unordered delivery of ADUs each ADU has an ADU name
assigned that identifies the ADU data in the application context
independent of the history of received ADUs. This ADU name is of no
meaning to the transport protocol. However, the transport protocol
uses its own naming concept to perform loss detection and recovery --
the sequence numbers.
The remainder of this section assumes, that only one sender is active
in the regarded session. This assumption simplifies the problem in a
way, but without limiting generality. If there are several senders in
a session, each sender will mark its ADUs with his source ID. Each
member of the session has its unique source ID, and all packets can be
assigned to their sender. Although the following analysis treats only
the case of sessions with a single sender, multiple senders in a
session can be regarded as independent from each other, and the
discussion corresponds to each sender respectively.
2.1.1. The Automatic Repeat Request (ARQ) mechanism
The ARQ mechanism is one of the two basic approaches to ensure
reliable data transmission, and is the most reliable. The other
mechanism, Forward Error Correction (FEC), can only reduce the loss-
rate. ARQ consists of two components: the loss detection and the loss
recovery.
Loss detection:
Even if the application does not need any ordering of the data, the
protocol will use some kind of sequence numbers to assign an order to
its ADU stream. Normally, this order corresponds to the sending
order. Losses are detected by means of gaps in the sequence number
space. The actual algorithm can reside at the receiver (receiver-based
loss detection) or at the sender (sender-based loss detection). The
loss detection algorithm uses some state information, the history of
ADUs already received successfully, and computes the necessary
information to do the loss recovery, i.e. the sequence numbers
corresponding to the lost ADUs.
Crowcroft and al. [Page 3]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
o The receiver-based algorithm detects the lost ADUs at the
receiving protocol instance, that will encode and transmit the
sequence numbers of the lost ADUs in control packets. The encoding
is mostly done in form of spans to reduce the necessary bandwidth.
The addressee of the control packets (in a unicast transmission
this is the sender) can then compute the sequence numbers of the
lost packets without other information.
o The sender-based algorithm requires that the sender is in charge
for the reliability of all the receivers. Consequently, the sender
has to keep status information on all of the receivers, see
[Levine98].
In the remainder of the report only the receiver-based approach will
be considered, since at least for multicast, the sender-based approach
has several disadvantages (a comparison of the receiver- and sender-
based approach can be found in [Pingali94]):
o To detect the gaps, the history of lost and received ADUs has to
be available. If the sender has to do this, the number of
receivers would be limited by the senders capacity in keeping this
state information.
o Since the sender has to track the history of all ADUs at all
receivers, it has to process the control packets from all
receivers. With many receivers, the sender will suffer the so-
called ack-implosion. This is an overload of the sender by
processing the control packets. Some receiver-based protocols use
the so-called NACK suppression mechanism to prevent the overload
of control packets. A receiver that suffered a loss, does not need
to send a control packet with lost ADU information, if another
receiver has done so before for the same ADU. If the
retransmission for the first request is transmitted, both
receivers will receive it.
The following two protocols have been investigated more thoroughly for
integration into RMFP as profiles:
The SRM [SRM] protocol uses a receiver-based mechanism with NACK
suppression to free the senders completely from management tasks for
special error control state information and to avoid the ack-
implosion.
The LGC protocol [Hofmann97] uses a combined approach. To prevent the
nack-implosion at the sender, LGC builds a tree structure with the
Crowcroft and al. [Page 4]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
sender as source. The control packets are not sent directly to the
sender, but are gathered at the inner nodes (group controllers) of the
tree. Thus, the sender and each of the group controllers has only to
process the control packets of its children.
Loss Recovery:
For unicast transmission, the sender of the retransmissions is always
the original sender. For multicast transmission, receivers that have
successfully received a given PDU can also retransmit that PDU to the
receivers that have lost the PDU. An example protocol is SRM, where
every group member is involved in loss recovery.
2.1.2. Forward Error Control
FEC reduces the loss-rate in sending redundancy information
additionally to the useful data. The encoding takes a block of n ADUs
and computes a given number k of redundancy packets. The n+k packets
form a transmission group. If the packets of a transmission group are
sent, it is sufficient to receive any subset of size n of the
transmission group to reconstruct the original n ADUs. However, if
more then k packets of the transmission group get lost, the losses
cannot be repaired. Thus, FEC can only reduce the packet loss-rate. An
introduction to FEC can be found in [Rizzo97].
FEC can be combined with ARQ to the so-called hybrid ARQ. This
mechanism is especially useful for reliable multicast, since it can
effectively reduce the overall loss-rate and thus retransmissions,
too. An investigation of hybrid ARQ is presented in [Nonnenmacher97].
There are several possibilities to use FEC in RMFP:
o The usage of FEC within RMFP transparent for the protocol profile,
i.e. as some layer under the profile could improve the behavior of
all profiles. The effects of such a transparent FEC mechanism have
been investigated in [Huitema96] and [Nonnenmacher97].
o FEC can be implemented as a mechanism of a protocol profile.
o The application can implement the FEC mechanism or use some
standard module provided by a RMFP implementation, see [Fuchs98].
Sequence numbers are generally ignored when the FEC bit is set.
However, specific profiles can use the sequence number field to encode
specific protocol information relative to the FEC packet. The
Crowcroft and al. [Page 5]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
transmission of an FEC packet does not increment the sequence number
counter at the source. This insulates the mechanism for detecting
normal packet loss from the FEC recovery scheme.
2.1.3. ALF and loss recovery
According to the ALF principle, the application has to handle the data
retransmission. In RMFP the protocol profiles have the task to detect
the losses and inform the application about the need of
retransmissions. The application then provides the retransmission
data. However, the protocol profiles use the sequence numbers to
identify ADUs, whereas the application requires the ADU name to
identify the ADUs. This leads to the need for a mapping between the
protocols sequence numbers and the ADU names.
The retransmissions of ADUs can only be performed by group members
that have the ADU either sent themselves or received already
successfully. Since the complete ADU contains both the sequence number
and the ADU name, the mapping information required to provide the
retransmission data is already available at the retransmitting group
member. The member can map the sequence number to the ADU name and
then the ADU name to the retransmission data. Depending on the
management of the retransmission data, the mapping may also be
performed directly from sequence number to retransmission data.
The RMFP specification doesn't specify, if the mapping from sequence
number to ADU name should be performed already at the protocol profile
or at the application; this decision is implementation dependent.
2.2. Hierarchical Naming with Objects
Additionally to the sequence number field and the ADU name there is
another field in the ADU header to support the mechanisms to identify
the data carried in the ADUs: The object ID field. It can be used to
optimize the transmission overhead caused by the ADU name.
For example, a file transfer application can put the name of the file
into the ADU name field of each ADU. If the file name includes some
path name, the file name can become considerably big. This file name,
however, doesn't change for all the ADUs belonging to the file; only
the byte-offset field varies from ADU to ADU.
The object ID field can reduce the bandwidth required by the ADU name.
Each file name used during the transmission is mapped onto a unique
object ID. The file name can then be omitted in the ADU name. The
Crowcroft and al. [Page 6]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
problem with this approach is the transmission of the mapping
information of object ID to ADU name that is required at the receivers
to process the ADUs. It can be transmitted in one of the ADUs of the
file in the ADU name field or separately as session information. In
the example, the first approach has the disadvantage, that all ADUs of
the file can only be processed, when the ADU with the file name in the
ADU name field has been received successfully. The other approach has
the disadvantage, that the session packet has to be transmitted
reliably, since the ADUs of a file are only useful, if the file name
is known.
How the object ID field is used is up to the application. It has to
find the optimal way to suit its requirements and to optimize the used
bandwidth.
Another issue is the relationship between objects and sequence
numbers. Three possibilities are suggested:
1/ The object ID is independent to the sequence number field and is
only used by the application. The ADUs are sequenced relative to
the start of the session and are not influenced by the object ID.
This is suitable for applications that require all ADUs to be
received reliably. This is the mechanism defined at the
specification the SRM profile.
2/ The sequence numbers are computed relative to the objects and the
object IDs are sequenced. If the objects are transmitted one
after the other, i.e. the ADUs of several objects are not
interleaved, every two ADUs can be compared in respect to their
sending order.
To reorder the ADUs and to detect ADU losses at the receiver, the
object IDs and sequence numbers are compared hierarchically:
Since the objects are transmitted sequentially, the sending order
of two ADUs can be computed out of the object ID, if the object
IDs of the ADUs differ. If both ADUs belong to the same object,
the sequence number decides about the order. The loss detection
is more difficult than with the first sequencing approach:
- Lost ADUs within an object are detected by gaps in the objects
sequence number name-space.
- Objects lost in total are detected by gaps in the object ID
name-space.
Crowcroft and al. [Page 7]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
- If the first or last ADUs of an object are lost, the start-of-
object/end-of-object flags are used to detect the losses.
These mechanisms are sufficient to be able to detect all possible
ADU losses, although, in the third case, it is not always
possible to determine the number of all lost ADUs and their
sequence numbers. The coding of negative acknowledgments for
retransmission requests must be performed as spans.
The problematic loss of ADUs around object boundaries (i.e. the
loss of ADUs carrying start-of-object/end-of-object flags)
imposes the constraint on the transmission order of objects: The
transmission of an object must be completed (by an ADU carrying
the end-of-object flag) before the first ADU of the next object
(i.e. an object with an object ID incremented by one) can be
sent. This limits the usability of this approach for applications
that want to transmit several objects simultaneously, e.g. a
white-board application. Such applications require the next
model.
3/ The sequence numbers are computed relative to the objects, i.e.
every object has its own sequence number space, but there is no
ordering relation between the ADUs of different objects. This
requires, however, that all control information has to refer to
each object independently, too. In [Fuchs98] a concept is
presented that is based on this model of sequencing. It allows
the receiver application to decide, which objects have to be
received reliably (semantic reliability). Another very general
approach of how this can be done is described in [Raman97].
2.3. Late-joining Receivers
An important problem for reliable multicast is the synchronization of
late-joining receivers. In general, applications may require to allow
receivers to join an ongoing session. Such receivers have to figure
out, at which point of the ADU stream they start with the receipt of
data.
The following discussion assumes, that the ADUs are sequenced relative
to the session and not relative to the objects (see [Fuchs98]), since
this is the method used in the current specification of RMFP.
In the rest of the section the term initial sequence number refers to
the sequence number of the packet with the lowest sequence number that
a receiver processes. A receiver keeps information about the initial
Crowcroft and al. [Page 8]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
sequence number for each sender independently. Similarly, the
highest-sequence-number-sent is the highest sequence number used by
the sender. For a receiver, this is actually the highest sequence
number seen from a given sender so far.
Several solutions are possible:
o The receiver uses the ADU with the lowest sequence number it
receives. It won't ask for retransmissions for any ADU with a
lower sequence number.
o The senders transmit synchronization points as session
information. Those synchronization points are sequence numbers
within their ADU stream, that are determined by the application
and are useful in the application context. A joining receiver that
receives such information, can ask for retransmission of all ADUs
starting at this synchronization point.
It is up to the application to decide, which style of receiver
synchronization to use. Consequently, the RMFP supports both. The
senders transmit the information of the style to use and if necessary
the current synchronization point within the sender report packets.
RMFP defines following behavior at a joining receiver:
1/ The receiver has no information yet. This means that the receiver
has not yet received any information about the sequence numbers
sent by the sender.
- ADU received: The sequence number of this ADU is used as an
initial sequence number.
- Highest-sequence-number-sent received: This information is
carried e.g. by a SRM heartbeat control packet. The next
sequence number is used as the initial sequence number.
- Synchronization point received: The receiver takes the
synchronization point as the first sequence number of the ADU
stream from the sender. Since the sender report packet carrying
the synchronization information also carries the highest-
sequence-number-sent, the receiver can ask for retransmission
for all ADUs starting with the synchronization point's sequence
number and up to the highest-sequence-number-sent.
Crowcroft and al. [Page 9]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
2/ The receiver is synchronized without synchronization point
received. The receiver is already synchronized due to a received
ADU or highest-sequence-number-sent information.
- ADU received: If the ADU's sequence number is lower than the
present initial sequence number for that sender, the initial
sequence number is set back to the ADU's sequence number and
missing packets starting with this sequence number are
requested for retransmission.
- Highest-sequence-number-sent received: It should be greater
than the already known initial sequence number, which has no
impact on the synchronization. If it is not, which could happen
in case of out-of-order receipt of control packets, this
information is discarded.
- Synchronization point received: If the synchronization point's
sequence number is greater than or equal to the initial
sequence number, the information is regarded as obsolete.
Otherwise, the initial sequence number is set back to the
received sequence number and the missing packets are requested
for retransmission.
3/ The receiver has already received a synchronization point. This
implies, that the synchronization process is already finished.
Received synchronization information is not considered anymore at
all, and ADUs with lower sequence numbers than the used
synchronization point are discarded.
Because of the finite sequence number space, there are problems with
the described synchronization algorithm. To ensure proper operation
the synchronization process has to be stopped after a defined span of
sequence numbers has been seen by a receiver (again independently for
each sender). In the implementation the size of the span is a quarter
of the sequence number space. At this point the receiver assumes that
it is fully synchronized.
2.4. Automatic Profile Configuration
One of the foundations that provide flexibility in RMFP are the
different protocol profiles. The protocol profiles have different
characteristics and the optimal protocol profile depends on the
scenario, i.e. the number of group members, the number of senders etc.
If it is clear at the development of an application, that one of the
protocol profiles is a good choice for all envisioned scenarios for
Crowcroft and al. [Page 10]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
the application, the application can always use that profile and every
group member always knows this profile, when it joins.
However, for some applications it might prove useful to support
several protocol profiles. The information of the profile has to be
distributed to all members. RMFP provides a mechanism for joining
members to be configured automatically by received sender control
packets. However, this mechanism works correctly only if the senders
of a session agree about the profile. RMFP provides no mechanism to
deal with conflicts, if members of the same group use different
profiles.
2.5. External Modules
Some of the standard functionality of other transport protocols have
been omitted in RMFP to allow the applications to use the transport
functionality in a more flexible way. However, many applications could
use the standard functionality. To simplify the use of RMFP it is
possible to use some implementations of this functionality as external
modules. Some possible modules are the following:
o Retransmission buffer: According to the ALF principle the
application is responsible to manage the retransmission data. This
brings flexibility, but many application programmers might want to
use the classical mechanism, a simple buffer indexed by the
sequence numbers.
o Reordering module: ALF explicitly introduces the unordered
delivery of received ADUs. Applications, that do not require the
flexibility and performance of that mechanism or are not even
capable to process the ADUs out-of-order could be implemented
simpler, if they could rely on ordered delivery.
3. The RMFP Specification
RMFP specifies three types of packets:
o Data packets (corresponding to ADUs) sent by senders.
o Control packets sent by senders and receivers control.
o Sessions packets that can be defined by the application using the
generic session packet header.
Crowcroft and al. [Page 11]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
The protocol profiles that provide the reliability can define their
own control packets. Those profile specifications are not part of the
RMFP specification, but are defined separately. Two profile
specifications for SRM and LGC can be found in [Fuchs98].
3.1. General Aspects
3.1.1. Network environment
This specification suggests an addressing scheme for the different
packet types: For each of the three packet types -- ADU, control and
session -- RMFP uses the same IP multicast address, but different UDP
ports. Since all packets can be identified due to their type field,
they could be well sent on the same IP multicast address/UDP port.
However, such an approach can lead to inefficiencies at the buffer
management, since the type of a received packet can only be retrieved
after the packet has been copied into the application buffers. That's
why RMFP relies on UDP to multiplex/demultiplex the three flows.
Some protocol profiles may need to use more addresses and/or ports or
cannot even use the global multicast groups in which every group
member takes part. However, the profile developers should seek to be
as compliant as possible to this suggestion to reduce profile specific
differences at the API.
This specification requires the application to provide a single
address/port pair for the session, the session address and the session
port.
o The data flow (all the ADUs) is assigned to the session
address/session port.
o The control flow (sender and receiver report packets as well as
the profiles' control packets) is assigned to the session
address/session port + 1.
o The session flow (all application defined session packets) is
assigned to the session address/session port + 2.
3.1.2. System environment
To avoid problems with alignment, all packet fields are naturally
aligned, e.g. all two-octet sized fields are placed on even addresses.
The packets themselves are assumed to be four-octet aligned.
Crowcroft and al. [Page 12]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
3.2. RMFP ADU Format
The RMFP ADUs have the following header format:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P|R|F|S|E|X| PAYLOAD TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SEQUENCE NUMBER | OBJECT ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| NAME LENGTH | ADU NAME :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
: ADU NAME :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The intention in designing this format was to include enough
information to be sufficient for the different protocol profiles, but
to keep the overhead small.
Version(V): 2 bits
This field identifies the version of RMFP.
Padding(P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding bytes at the end, which are not part of the
payload. The last octet of the padding contains a count of how many
bytes should be ignored. The padding bytes keep all the ADUs four-
byte aligned.
Retransmission (R): 1 bit
Set to 1 if the ADU is being retransmitted.
Forward Error Correction (F): 1 bit
Set to 1 if FEC is used.
Start of Object (S): 1 bit
Set to 1 if the ADU is the first one of an object.
End of Object (E): 1 bit
Set to 1 if the ADU is the last one of an object.
Exceptional Handling (X): 1 bit
This bit is free for use by the application. It is not processed at
Crowcroft and al. [Page 13]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
RMFP or any profile and is intended to allow the application to mark
ADUs that should be treated in a unusual way.
Payload Type: 8 bits
This field is intended to serve the application in a similar way as
the payload type field in RTP [Schulzrinne95] does. The application
can use this field to indicate the type of the payload. Some values of
this field are used to indicate control or session packets used by
RMFP and the profiles and may not be used for application purposes.
Following values are so far defined:
o 201: Sender report packets.
o 202: Receiver report packets.
o 203: Session packets.
o 205: SRM control packets.
o 206: LGC control packets.
The application can use the other values freely, however, it is
possible that other values above 200 may be used by other profiles, or
added functionality in future versions of RMFP.
Length: 16 bits
This field identifies the length of the packet in 32 bits minus one,
including the header and any padding. To count in multiples of four
bytes avoids an alignment check. This algorithm has been introduced by
RTP.
It can be used to combine several ADUs into one UDP packet. In a
compound UDP packet only the length fields allow the detection of the
ADU boundaries.
When several ADUs (original and retransmitted) are concatenated within
one UDP packet, the original ADUs should all be placed at the
beginning of the UDP packet so that receivers that do not encounter
losses can just drop the tail of the retransmitted ADUs without
processing it.
Source ID: 32 bits
This field identifies the source. The source IDs are generated
randomly similar to the SSRC field in RTP to avoid collisions between
several members.
Crowcroft and al. [Page 14]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
Sequence Number: 16 bits
The sequence number is an ADU counter. It is incremented by one for
each ADU sent. It can be used to detect ADU losses and calculate loss
rates. The exact semantics of the sequence number is determined by
the protocol profile. It is possible to count the sequence number
starting with the first ADU sent and incrementing it for each ADU
throughout the session. Another possibility would be to use the
sequence number object-relative, i.e. each object has its own counter
assigned starting at zero for its first ADU.
Object ID: 16 bits
This field identifies the object carried in the packet.
Name Length: 8 bits
This field specifies the length in bytes of the following ADU Name.
zero is a valid value, indicating that no explicit ADU name is
available.
ADU Name: variable length
The ADU name is used by the application to identify an ADU in the
application context. The contents of this field are completely
transparent to RMFP and the protocol profiles. The length of the ADU
name can be between 0 and 255 bytes. There can be unused bytes to
ensure proper alignment (32bit) within the ADU header. This field can
contain the information to identify both the object and the position
within the object of the ADU, e.g. the filename and the byte-offset
for ADUs in a file transfer application. However, the application can
also use the object IDs and sequence numbers to identify objects and
ADUs.
3.3. RMFP Control Packet Format
RMFP control packets include sender report packets and receiver report
packets. Those packets can be used by the senders and receivers
respectively to transmit session information.
3.3.1. Sender Report packet
Sender report packets are sent periodically by the sender and contain
information about the current sending state. They can help to
configure new joining receivers and provide information to detect tail
losses. The structure of the header is shown in the following figure:
Crowcroft and al. [Page 15]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P| SR | PAYLOAD TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PROFILE ID | L |S|V| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| BASE OBJECT ID | BASE SEQUENCE NUMBER |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| CURRENT OBJECT ID | HIGHEST SEQUENCE NUMBER |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| PROFILE-SPECIFIC EXTENSIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version(V): 2 bits
This field identifies the version of RMFP.
Padding(P): 1 bit
If the padding bit is set, the packet contains one or more
additional padding bytes at the end which are not part of the payload.
The last octet of the padding contains a count of how many bytes
should be ignored. Since the actual header is already aligned, the
padding flag is only necessary, if an application specific extension
is included in the packet.
SR Type: 5 bits
This field has no interpretation by RMFP and can be used by the
application, e.g. to transmit extra information like an end of
transmission indication. It might also be used to denote the type of
the application specific extension.
Payload Type: 8 bits
This field is set to 201 for sender report packets
Header Length: 16 bits
This field specifies the length of the packet in multiples of 32
bits minus one.
Source ID: 32 bits
This field identifies the sender.
Profile: 8 bits
This field indicates the type of the protocol profile used. It is
used together with the LSV, first object ID and lowest sequence number
Crowcroft and al. [Page 16]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
fields to configure late joining receivers. A receiver that wants to
join a session and does not know a-priori which protocol profile is
used, can wait for receipt of a sender report packet and configure its
protocol profile according to this field.
Lowest Sequence Valid (LSV): 2 bits
These bits define the interpretation of lowest sequence number
field:
o 00: The sequence number of the first ADU sent by the sender in
this session.
o 01: The sequence number of some position in the transmission that
can be used to synchronize.
o 10: No valid information. The sender provides no special help to
synchronize. The new receiver should synchronize its join on the
first ADU it receives.
o 11: Reserved.
If the lowest sequence number fields is valid, a late-joining receiver
can ask for retransmission back to the indicated sequence number. The
sender can choose the value of this field appropriately to mark some
logical boundary in the ADU stream.
First Object ID: 16 bits
The object ID for late-joining receivers to synchronize.
Lowest Sequence Number: 16 bits
This field encodes the sequence number for late-joining receivers to
synchronize.
Current Object ID: 16 bits
This field and the highest sequence number field are used to
indicate the current state of the sender. The receivers can use this
information to detect tail-losses.
Highest Sequence Number: 16 bits
This field comes together with the current object ID and is the
sequence number of the last ADU sent. It is used to detect tail-
losses.
Crowcroft and al. [Page 17]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
3.3.2. Receiver Report packet
Receiver report packets are sent periodically by the receivers to give
feedback on congestion and packet losses. They contain some receive
statistics for each sender. The format of this packet type is shown in
the following figure.
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P| RC | PAYLOAD TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE ID |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SENDER'S SOURCE ID 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| FRACTION LOST | RESERVED | HIGHEST SEQUENCE NUMBER |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
: :
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SENDER'S SOURCE ID N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| FRACTION LOST | RESERVED | HIGHEST SEQUENCE NUMBER |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| PROFILE-SPECIFIC EXTENSIONS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields have the following meaning:
Version(V): 2 bits
This field identifies the version of RMFP.
Padding(P): 1 bit
The padding bit is used to force alignment of the packet. It is used
in the same way as in the sender report packet.
Report Block Count(RC): 5 bits
The RC denotes, how many report blocks are contained in this packet.
Each report block consists of a sender's source ID, a fraction lost
field and a highest sequence number field.
Payload Type: 8 bits
Set to 202 for receiver report packets.
Header Length: 16 bits
This field specifies the length of the packet in multiples of 32
Crowcroft and al. [Page 18]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
bits minus one.
Source ID: 32 bits
Identifies the sender of this packet (a receiver).
Senders Source ID X: 32 bits
This field identifies the sender X corresponding to the following
fraction lost and highest sequence number information.
Fraction Lost: 8 bits
The fraction of packets lost since last receiver report, expressed
as a fixed point number with the binary point at the left edge of the
field. Fraction lost is the loss rate seen by the receiver in respect
to the sender identified by the previous sender's source ID field. The
information may be used for congestion control or error recovery (FEC)
by the sender.
Highest Sequence Number: 16 bits
Indicates the highest sequence number received from the
corresponding sender so far.
3.4. RMFP Session Packet Format
The session packets are used to enable group members to easily
exchange session information. RMFP defines a very light-weight
approach, that merely supports the sending and receiving of unreliable
data, that is marked as session information. Thus the RMFP just
defines the protocol header and provides the transmission and receipt
of such packets. There are no special packets defined for some
specific use, this is up to the application. Session packets can be
used e.g. to support the following functions:
- - Remote configuration: A sender can transmit configuration
parameters to configure other members. This mechanism is only
used to transmit parameters. The application has the
responsibility to use the parameters to configure the protocol.
- - Support at joining a session: A member joining a session has to
be informed about the current state of the session. For small
groups, it could use a special session packet to issue some
status request packet, and the senders can answer to that packet
with some status reply session packets.
The RMFP session packet has the following format:
Crowcroft and al. [Page 19]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |P| FLAGS | PAYLOAD TYPE | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version(V): 2 bits
This field identifies the version of RMFP.
Padding(P): 1 bit
The padding bit is used to force alignment of the packet. It is used
in the same way as in the sender report packet.
FLAGS: 5 bits
The usage of this field is defined by the application. It could be
used e.g. to identify different types of session packets.
Payload Type: 8 bits
This field is set to 203 for RMFP session packets.
Length: 16 bits
This field specifies the length of the packet in multiples of 32
bits minus one, including the header and any padding.
Source ID: 32 bits
This field identifies the sender of the session packet. It is
calculated like the length field of the ADU.
Crowcroft and al. [Page 20]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
Addresses of Authors
J. Crowcroft, L. Vicisano
{j.crowcroft,l.vicisano}@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street
London WC1E 6BT
UK
Zheng Wang
zhwang@dnrc.bell-labs.com
Bell Labs Lucent Tech.
101 Crawfords Corner Road
Holmdel NJ
USA
Atanu Ghosh
atanu@socs.uts.EDU.AU
School of Computing Sciences
University of Technology
Sydney
PO Box 123 , Broadway
NSW 2007
Australia
Michael Fuchs
Michael.Fuchs@telematik.informatik.uni-karlsruhe.de
Institute of Telematics
University Karlsruhe
Germany
Christophe Diot, Thierry Turletti
{cdiot,turletti}@sophia.inria.fr
INRIA Sophia Antipolis
2004 route des Lucioles
BP 93, 06902 Sophia Antipolis
France
Crowcroft and al. [Page 21]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
References
[Clark90]
D. Clark, D. Tennenhouse, Architectural Considerations for a New
Generation of Protocols, Proceedings of ACM SIGCOMM '90, Sept.
1990, pp. 201-208.
[Diot97]
C. Diot, W. Dabbous, and J. Crowcroft, Multipoint Communication:
A Survey of Protocols, Functions, and Mechanisms, IEEE/JSAC, Vol.
15, No. 3, pp. 277-290, April 1997.
[SRM]
S. Floyd, V. Jacobson, S. McCanne, C.G. Liu, and L. Zhang, A
Reliable Multicast Framework for Light-weight Session and
Application Level framing, IEEE/ACM Transactions on Networking,
Dec. 1997, Vol. 5, No 6, pp. 784-803.
[Fuchs98]
M. Fuchs, C. Diot, T. Turletti, and M. Hofmann, A Framework for
reliable Multicast in the Internet, INRIA Research report No
3363, Feb. 1998. See also the RMFP Home page at URL
``www.inria.fr/rodeo/rmfp/''.
[Hofmann97]
M. Hofmann, Enabling group communication in global network,
Proceedings of Global Networking '97, Calgary, Canada, June 1997.
[Huitema96]
C. Huitema, The case for packet level FEC, Proceedings of IFIP
5th International Workshop on Protocols for High Speed Networks
(PfHSN'96)}. INRIA, Sophia Antipolis, France, Oct. 1996.
[Levine98]
B.N. Levine, and J.J. Garcia-Luna-Aceves, A Comparison of
Reliable Multicast Protocols, to appear in ACM Multimedia Systems
Journal, August 1998.
[Nonnenmacher97]
J. Nonnenmacher, E. Biersack, and D. Towsley, Parity-Based Loss
recovery for Reliable Multicast Transmission, Proceedings of ACM
SIGCOMM '97, Sept. 1997.
[Pingali94]
S. Pingali, D. Towsley, and J. Kurose. A Comparison of Sender-
Crowcroft and al. [Page 22]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
Initiated and Receiver-Initiated Reliable Multicast Protocols,
Proceedings of SIGMETRICS'94, 1994.
[PGM]
T. Speakman, S. Farinacci, S. Lin, and A. Tweedly, Pretty Good
Multicast (PGM) Transport Protocol Specification, Internet Draft,
draft-speakman-pgm-spec-00.txt, January 1998.
[Raman97]
S. Raman, and S.R. McCanne, General Data Naming and scalable
State Announcements for Reliable Multicast, Technical report,
Computer Science Division (EECS), University of California, June
1997.
[Rizzo97]
L. Rizzo, On the feasibility of software FEC, Technical report,
Universita di Pisa, January 1997.
[RMTP]
J.C. Lin, and S. Paul, RMTP: A Reliable Multicast Transport
Protocol, Proceedings of IEEE INFOCOM '96, pp. 1414-1424.
[RMDP]
L. Rizzo, and L. Vicisano, A Reliable Multicast data Distribution
Protocol based on software FEC techniques, Proceedings of the 4th
IEEE Workshop on the Architecture and Implementation of High
Performance Communication Systems (HPCS'97), Sani Beach,
Chalkidiki, Greece June 23-25, 1997.
[Schulzrinne95]
H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A
Transport Protocol for Real-Time Applications, RFC 1889, November
1995.
[TIBnet]
TIBCO, TIBNnet White Paper,
"http://www.tibco.com/products/tibwhite.html"
[Vicisano98]
L. Vicisano, l. Rizzo, and J. Crowcroft, TCP-like congestion
control for layered multicast data transfer, to appear in
Infocom'98.
Crowcroft and al. [Page 23]
INTERNET-DRAFT draft-crowcroft-rmfp-02.txt March, 1998
Table of Contents
Status of this Memo ............................................ 1
1 Introduction .................................................. 1
2 Design Philosophy ............................................. 2
2.1 Error Control ............................................... 2
2.1.1 The Automatic Repeat Request (ARQ) mechanism .............. 3
2.1.2 Forward Error Control ..................................... 5
2.1.3 ALF and loss recovery ..................................... 6
2.2 Hierarchical Naming with Objects ............................ 6
2.3 Late-joining Receivers ...................................... 8
2.4 Automatic Profile Configuration ............................. 10
2.5 External Modules ............................................ 11
3 The RMFP Specification ........................................ 11
3.1 General Aspects ............................................. 12
3.1.1 Network environment ....................................... 12
3.1.2 System environment ........................................ 12
3.2 RMFP ADU Format ............................................. 13
3.3 RMFP Control Packet Format .................................. 15
3.3.1 Sender Report packet ...................................... 15
3.3.2 Receiver Report packet .................................... 18
3.4 RMFP Session Packet Format .................................. 19
Addresses of Authors ........................................... 21
References ..................................................... 22
Crowcroft and al. [Page 24]