2.7.12 Reliable Multicast Transport (rmt)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional RMT Web Page

Last Modified: 2005-07-06


Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>

Transport Area Director(s):

Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>

Transport Area Advisor:

Allison Mankin <mankin@psg.com>

Mailing Lists:

General Discussion: rmt@ietf.org
To Subscribe: rmt-request@ietf.org
In Body: subscribe
Archive: http://www.ietf.org/mail-archive/web/rmt/index.html

Description of Working Group:

The purpose of this WG is to standardize reliable multicast transport.

Initial efforts have focused solely on the standardization of the
one-to-many transport of large amounts of data. Due to the large
number of applications that fall into this category, and the sometimes
orthogonal requirements these applications exhibit, it is believed
that a "one size fits all" protocol will be unable to meet the
requirements of all applications. In recognition of this observation,
this working group will standardize two protocol instantiations,
initially as Experimental protocols, and then as warranted, in the
standards track, from the following families:

1) A NACK-based protocol.
2) An "Asynchronous Layered Coding protocol that uses Forward Error

The WG will carry out protocol standardization in general by composing
a a set of RFCs that specify

- building blocks: A set of easily-separable coarse-grained modular
components that are common to multiple protocols along with abstract
APIs that define a building block's access methods and their

- protocol instantiations: Specifications that define the necessary
gluing logic and minimal additional functionality required to realize
a working protocol from one or more building blocks. These
specifications will also include an abstract API that defines the
interface between the protocol implementation and an application.

The WG has previously completed work on three documents to assist in
the standardization process. RFC2887 describes the design-space in
which the one-to-many transport protocols will be developed. RFC3048
explains the concepts of building-blocks and protocol
instantiations. RFC3269 provides guidelines to authors of drafts that
specify building-blocks and protocol instantiations.

The WG will generate and submit for standardization drafts of the
following building-blocks for use in the construction of the two
protocols: congestion control, negative acknowledgments, forward error
correction, and to address the RFC 2357 security requirements.

Generic mechanisms for router assist are also considered for an
additional building block. Initial work on the framework for
router-assist has already been performed, the WG will evaluate whether
to complete this task basing on available resource and interest.

The WG will also standardize and generate RFCs for the following two
protocol instantiations: A NACK-based protocol, and an Asynchronous
Layered Coding (ALC) protocol that uses Forward Error Correction.
RFC 3450 is the Experimental RFC of the ALC protocol instantiation.

If new requirements are identified that cannot be satisfied with the
building-blocks and protocol instantiations described above, the Area
Directors in consultation with the IESG may add additional
building-blocks and protocol instantiations to the working group

This working group will work closely with the Internet Research Task
Force (IRTF) groups on Reliable Multicast (RMRG) and
Secure Multicast (SMUG), especially for meeting the congestion control
and security requirements mandated by RFC 2357. This working group may
work with the Area Directors to recharter to standardize reliable
multicast for additional scenarios beyond the one-to-many transport of
bulk data once they are sufficiently well understood.

Goals and Milestones:

Done  Submit design-space, building-blocks, and guidelines drafts for publication as Informational RFCs
Done  Initial Drafts for the following building blocks: negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection
Done  Submit Initial Drafts for the two protocol instantiations.
Done  Submit Initial Draft for Congestion Control
Done  Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard
Done  Complete building blocks and protocol instantiations for ALC and submit for publication as Experimental RFC
Done  WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly
Done  Submit WEBRC (congestion control building block) for publication as Experimental
Done  Submit NACK building block and protocol instantiation for publication as Experimental
Done  Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly
Sep 05  Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental
Dec 05  Submit all the RMT Eperimental Specifications published before July 05 for publication as Proposed Standard
Apr 06  Submit all remaining RMT Eperimental Specifications for publication as Proposed Standard


  • draft-ietf-rmt-bb-fec-raptor-object-01.txt
  • draft-ietf-rmt-fec-bb-revised-00.txt
  • draft-ietf-rmt-bb-lct-revised-00.txt
  • draft-ietf-rmt-pi-alc-revised-00.txt
  • draft-ietf-rmt-bb-fec-basic-schemes-revised-00.txt

    Request For Comments:

    RFC2887 I The Reliable Multicast Design Space for Bulk Data Transfer
    RFC3048 I Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer
    RFC3269 I Author Guidelines for RMT Building Blocks and Protocol Instantiation documents
    RFC3450 E Asynchronous Layered Coding protocol instantiation
    RFC3451 E Layered Coding Transport (LCT) Building Block
    RFC3452 E Forward Error Correction Building Block
    RFC3453 I The use of Forward Error Correction in Reliable Multicast
    RFC3695 E Compact Forward Error Correction (FEC) Schemes
    RFC3738 E Wave and Equation Based Rate Control building block
    RFC3926 E FLUTE - File Delivery over Unidirectional Transport
    RFC3940 E NACK-Oriented Reliable Multicast Protocol (NORM)
    RFC3941 E NACK-Oriented Reliable Multicast (NORM) Building Blocks

    Current Meeting Report

    Reliable Multicast Transport (RMT) WG
    63rd IETF -- Paris, France
    Mon, August 1, 2005

    Lorenzo Vicisano chairing

    Many thanks to Mark Pullen, Mark Watson and Rod Walsh for taking the minutes of the meeting.
    Meeting Agenda
    	Agenda Bashing						Chairs
    	WG status Updates					Chairs
    Documents Moving towards Standard-Track Submission
    	draft-ietf-rmt-pi-alc-revised-00			Lorenzo Vicisano
    	Lorenzo Vicisano
    	revising flute (rfc3926)				Rod Walsh
    	draft-ietf-rmt-fec-bb-revised-00			Mark Watson
    Other WG (or possible WG) Documents
    	draft-ietf-rmt-bb-fec-raptor-object-01			Mark Watson
    	draft-roca-rmt-ldpc-00					Christoph Neumann
    	draft-neumann-rmt-flute-file-aggregation-01		 & Vincent Roca
    Possible New WG Work
    	draft-faurite-rmt-tesla-for-alc-norm-00			Christoph Neumann
    								 & Vincent Roca
    	draft-watson-tsgwg-fec-sf-00				Mark Watson
    Related Work
    	draft-mehta-rmt-flute-sdp-03				Rod Walsh

    WG status Updates

    See slides.

    WG goal is to get most of the Experimental drafts moved to Standard track by April 06. Stretch goal is to have all "pre-2nd-half-2005 EXP RFCs" to standard track before year end.

    Remaining items on todo list
    - Sep 05 submit TFMCC & PGMCC for Experimental RFC
    - Dec 05 submit RMT specifications published before July 05 for Standards track
    - Apr 05 submit remaining RMT specifications for Standards track

    Issue on TFMCC: went to WG last-call but there is an unresolved issue surfaced by Mark Pullen's student; author Joerg Widmer has been contacted but has not replied with resolution; Lorenzo will contact Widmer

    Move to Standard track issues
    - alc pi, lct, bb gone through initial revision.
    Need volunteers to complete the work.
    - RFC3926/FLUTE needs volunteers to revise (Rod Walsh volunteered).
    - NORM PI/BB and WEBRC CC also need volunteers (Brian Adamson volunteered).

    Possible new WG Item: applying TESLA to NORM and FLUTE

    For information: Mark Pullen's SRMP, out of scope for RMT but related, has been queued for Experimental RFC.

    FLUTE update for standard track - Rod Walsh

    Maintain on-the-wire backward compatibility with
    "experimental" spec.

    Some comments received, will include, none major.

    FDT instance schema modified to support extensibility.

    "Sensible channel ID" only agreed. Discussion (inc. mail list) on whether to allow channels varying with both port and destination for a session seems to have consensus not to allow this (i.e. were multiple "port" channels per IP destination as well as multiple IP destinations would have been used).

    Allowing other-than-UDP-transport for LCT/ALC/FLUTE (TCP, DCCP, SCTP) was raised. Minimal positive (and no negative) response to the idea but no time for detailed discussion

    FLUTEbis I-D at the end of August (delayed at the time of writing)

    FEC building block update for standard track - Mark Watson

    Intend to maintain backward compatibility with existing RFC

    Collected a variety of proposed schemes into one document. No comments received on the drafts yet. One comment from meeting participants: use the Integer Logic algorithm to avoid pitfalls in the floating-point one (defined in flute) for the object source blocks. Need to remove this piece of specification from flute.

    Raptor FEC scheme - Mark Watson

    Agreed last WG meeting to be WG item.
    Since then code was adopted by 3GPP for file delivery and streaming.
    Updated draft with fixes/alignment published.

    Discussion on assignment of FEC ID and avoid un-necessary changes since the 3GPP spec has already been published. Discussion also on whether the IETF spec can point to the 3GPP spec. One possibility is to use the IETF Spec only to allocate the FEC ID (with IANA consideration) and to refer to the 3GPP spec for the algorithm. Mark Watson to look into this issue. apart from this, document is OK for WG last-call.

    Discussion on how new FEC ID will be established when RMT shuts down: different proposals examined: new WG, do it in TSWG, do it in different WGs.

    LDPC FEC scheme - Vincent Roca

    Submitted FEC draft as under-specified as many variants can be defined.
    Lorenzo asked them to consider recasting this as fully specified for one or two variants.

    Discussion on possible IPR that Digital Fountain has disclosed on this. Vincent reports that DF has not pointed them to specifics.

    Need to discuss on the mailing list whether this should be WG Item and whether there should be a fully specified ID.

    Rod Walsh: encouraged people to submit FEC schemes (and WG to welcome them) - thinks there should be 10 or more fully-specified whereas there are only two so far.

    File Aggregation Scheme for FLUTE- Christoph Neumann

    Need to decide on the list whether this will be a WG Item.

    TESLA for ALC/NORM - Vincent Roca

    discussion on:

    - whether the draft should be split into a generic part (to be worked on in MSEC) and a ALC/NORM specific part to be worked on in RMT.

    - Canetti (MSEC chair) thinks it should not be split, doesn't matter whether is don in RMT or MSEC. RMT and MSEC chairs agreed that this work should be done in close coordination between the WGs.

    FEC Streaming Framework - Mark Watson

    Meeting very short on time, so draft announced and discussion will be in TSVWG

    FLUTE SDP - Rod Walsh

    This a non-WG document, supported by the WG.
    The document is in fast track for its 3GPP dependency.
    Authors to incorporate comments received on SDP correctness.
    Ready for WG LC (simultaneous in RMT and MMUSIC) once the generalized channel aspects (CS - "compound session" grouping) is included and verified bugless
    New I-D in September


    FLUTE-update: rfc3926bis