[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
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]