One document matched: draft-crowcroft-rmfp-00.txt

Network Working Group                                   J Crowcroft (UCL)
                                                             Z Wang (UCL)
Internet-Draft                                              A Ghosh (UTS)
<draft-crowcroft-rmfp-00.txt>                              C Diot (INRIA)
                                                                Nov 1996


             RMFP: A Reliable Multicast Framing Protocol

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
docu ments 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   ds.internic.net   (US  East  Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

The  distribution  of  this memo is unlimited.  It is filed as
<draft-crowcorft-rmfp-01.txt>, and  expires 15 May, 1997.
Please  send comments to the authors.

1. Introduction

There  has been considerable interest in reliable multicast, and
a number of reliable multicast transport systems have been
proposed in the past years.

Reliable multicast transport is considerably more complex than
reliable unicast. It is difficult to build a generic reliable
transport protocol for muitlcast, 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 provides 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, RMFP is different from RTP, as 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. RMFP Packet Format

RMFP packet header inclcudes common per-packet related fields. An
application may include application-specific fields in a
preamble header.

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |R|E| FLAGS | PAYLOAD TYPE  |        SEQUENCE NUMBER        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SOURCE ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           OFFSET                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Version(V): 2 bits
    This field identifies the version of RMFP.

Retransmission (R): 1 bit
    This bit, when set, indicates that it is a retransmitted
    information.

Forward Error Correction (E): 1 bit
    This bit, when set, indicates that FEC is used. The exact
    format of FEC is determined by Payload Type and its profile.

Flags: 4 bits
    The flags are used for indicating significant features such
    as object (or ADUs) boundaries. Object boundaries can be used for
    multiplexing multiple objects within a single session. For
    example, one can multicast several files within one session.

    0000: reserved
    0001: start mark - the start of an object
    0010: end mark - the end of an object
    other: reserved

Payload Type: 8 bits
    This field identifies the format of the payload and
    determines its intepretation by the application.
    Profiles will be defined for each payload type.

Sequence Number: 16 bits

    The sequence number increments by one for each data packet
    sent. Sequence number can be used to determine packet
    losses (including both data packet and retransmitted packets)

Source ID: 32 bits
    This field identifies the source. It is generated randomly
    similar to the SSRC field in RTP. It can be used to detect
    packet losses.

Offset: 64 bits
    This field identifies the position of the data relative to
    the beginning of the session.


3. RMFP Control Packet Format

RMFP control packets include sender's report packets and
receiver's report packets.

Sender's Report Packet

Sender's report is sent periodically by the sender about the
data transmitted in the session.

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 |  RESERVED | PAYLOAD TYPE  |         HEADER LENGTH         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SOURCE ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        NTP TIMESTAMP                          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   HIGHEST OCTET NUMBER SENT                   |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  MAXIMUM OCTET NUMBER EXPECTED                |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          OBJECT NAME                          |
|                              ...                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Version(V): 2 bits
    This field identifies the version number.

Payload Type: 8 bits
    This field is set to xxx for Sender's Report Packets

Header Length: 16 bits
    This field specifies the length of the header.

Source ID: 32 bits
    This field identifies the source of the sender

NTP Timestamp: 64 bits
    The NTP timestamp when the report is sent.

Highest Octet Number Sent: 64 bits
    This field indicates the data sent at the time the report
    is sent.

Maximum Octet Number Expected: 64 bits
    This field indicates the total size of the object. An
    application may use the information to allocate space for the
    session. Set to zero if the size is unknown.

Object Name
    This is a variable length field identifying the name of the
    object. It may be a filename, a URL, a message name etc.


Receiver's Report Packet

Receiver's report is periodically sent by the receivers to
give feedback on congestion and packet losses.


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 |  RESERVED   | PAYLOAD TYPE  |       HEADER LENGTH         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SOURCE ID                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                HIGHEST OCTET NUMBER RECEIVED                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                LAST SENDER'S REPORT TIMESTAMP                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               DELAY SINCE LAST SENDER'S REPORT                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FRACTION LOST |                    RESERVED                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       SPAN BLOCKS                             |
|                             .....                             |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+


Version(V): 2 bits
    This field identifies the version number.

Payload Type: 8 bits
    This field is set to xxx for Receiver's Report Packets

Header Length: 16 bits
    This field specifies the length of the header.

Source ID: 32 bits
    This field identifies the source of the report

Highest Octet Number Received: 64 bits
    This field indicates the highest octet of the data received so far.

Last Sender's Report Timestamp: 32 bits
    The middle 32 bits of the NTP Timestamp of the most recent
    Sender's Report

Delay Since Last Sender's Report: 32 bits
    The delay, expressed in units of 1/65536 seconds, between
    receiving last Sender's report and sending of this report

Fraction Lost: 8 bits
    The fraction of packets lost since last Sender's 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. The information may be
    used for congestion control, error recovery purpose by the
    sender.

SPAN Blocks: 64 bits + 32 bits each block
    Each block specifies the offset number and the length of
    a missing data block. The information is used for
    retransmission of lost packets.


4. Open Issues

Profiles for applications

Various and numerous mechanisms can be used to control reliability.
Consequently, control information specific to each mechanism
cannot be provided ion the RMFP protocol. We propose a profile to be
defined for each mechanism. The SRM profile could be based on Parnes' work
on reliable RTP, for example. Other profiles could be defined for the
various FEC types.

Explicit join/leave

Some reliable applications may need an explicit Join and Leave mechanism.
It is not clear to us today how this facility should be provided, or if it
has to be provided in RMFP (using reports or a new packet type).


5. Authors's Addresses

J Crowcroft, Zheng Wang
{j.crowcroft, z.wang}@cs.ucl.ac.uk
Department of Computer Science
University College London
Gower Street
London
WC1E 6BT

Atanu Ghosh
atanu@socs.uts.EDU.AU
School of Computing Sciences
University of Technology
Sydney
PO Box 123 , Broadway
NSW 2007
Australia

Christophe Diot
Christophe.Diot@sophia.inria.fr
INRIA
Sophia Antipolis, 2004
route des Lucioles
BP93 06902
France