2.8.14 Reliable Multicast Transport (rmt)

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: 2003-05-21

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: www.ietf.org/mail-archive/working-groups/rmt/current/maillist.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
May 03  WG Decision on whether to pursue the router-assist building block work. These milestones may have to be modified accordingly
May 03  Submit WEBRC (congestion control building block) for publication as Experimental
Aug 03  Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental
Aug 03  Submit NACK building block and protocol instantiation for publication as Experimental
Dec 03  Evaluate when and how the RMT Experimental specifications will be submitted for publication as Proposed Standard, and update this charter accordingly
  • - draft-ietf-rmt-bb-tree-config-03.txt
  • - draft-ietf-rmt-bb-norm-06.txt
  • - draft-ietf-rmt-pi-norm-07.txt
  • - draft-ietf-rmt-bb-track-02.txt
  • - draft-ietf-rmt-bb-pgmcc-02.txt
  • - draft-ietf-rmt-bb-webrc-04.txt
  • - draft-ietf-rmt-bb-tfmcc-02.txt
  • - draft-ietf-rmt-bb-gra-signalling-01.txt
  • - draft-ietf-rmt-bb-fec-supp-compact-01.txt
  • - draft-ietf-rmt-flute-00.txt
  • Request For Comments:
    The Reliable Multicast Design Space for Bulk Data Transfer (RFC 2887) (51135 bytes)
    Reliable Multicast Transport Building Blocks for One-to-Many Bulk-Data Transfer (RFC 3048) (48965 bytes)
    Author Guidelines for RMT Building Blocks and Protocol Instantiation documents (RFC 3269) (25258 bytes)
    Asynchronous Layered Coding protocol instantiation (RFC 3450) (86022 bytes)
    Layered Coding Transport (LCT) Building Block (RFC 3451) (72594 bytes)
    Forward Error Correction Building Block (RFC 3452) (38368 bytes)
    The use of Forward Error Correction in Reliable Multicast (RFC 3453) (46853 bytes)

    Current Meeting Report

    Reliable Multicast Transport
    57th IETF, Vienna
    Monday, July 14th
    15:30 - 16:15
    Opening Remarks
    - Charter was updated:
       * removed TRACK as per WG consensus
       * GRA is still in, but to be discussed (see next)
    - GRA discussion: no interested party answered to the call for 
    editors/requirements issued after the last IETF. The proposal is to 
    discontinue the GRA work at this time. To be decided on the mailing list.
    NACK Oriented Reliable Multicast (NORM) Update
    Joe Macker for Brian Adamson
    NORM BB updated 06 to 07
    - http://norm.pf.itd.nrl.navy.mil has open source
    - changes to make doc more compliant with TFMRC
    PI doc updated from 05 to 06
    - modularized
    - Vincent Roca has provided feedback. In particular a header extension 
    options is currently being considered to coordinate with the FLUTE spec.
    - added congestion control fields
    - Next steps, open source will continue to mature further 
    experimentations and simulations will be performed
    - Need to decide whether we want a new WG last call for the NORM drafts, or 
    just go to the IESG.
    - Need to solve the header extension and FLUTE issue.
    FLUTE, File Delivery over Undirectional Transport
    Tony Paila
    - 00 WG draft, derived from FDALC individual submission
    - FDALC specify a particular application (usage profile) of ALC for file 
    delivery over unidirectional links
    - Toni is editor, added 3 new authors
    - believes that new draft meets requirements from last meeting
    - Proceed providing updates:
      * FDT content, XML schema from FDT syntax,
      * FDT encap streamlined, cross checked with ALC/LCT RFCs
      * how to use multiple channels, etc
      * how to describe file delivery session using SDP is now info chapter
      * receiver operation is now informational chapter
      * security considerations elaborated further
    - discussion on whether part of the SDP section should be normative 
    instead. Lorenzo to provide comments on this.
    - propose to hold last call in September and maybe add this a charter 
    - two genetically independent implementations to be ready by November with 
    some interop testing, at least one will be open source
    PGMCC Update
    Gianluca Iannaccone
    Security considerations
    One issue addressed: Session hijacking
    - session hijacking solved out authentications
    - can drive the sender to flood the network
    - breaks the election mechanism
    The rest is transport protocol responsibility
    - authentication
    - deal with the denial of service problem
    - PGMCC sender should compare ACK stream with reported loss rate and RTT 
    info reports to prevent DOS attacks
    - if violation mark acker has ineligible
    - believer ready for last call
    Lorenzo: TFMCC and PGMCC both look like they are ready  for last 
    call...need to check with TFMCC authors Lorenzo: discussed with Allison 
    about potential outside reviews of TF/PGM CC drafts form people not 
    involved with them...would be an additional step before submission to the 
    IESG Pullman: have done some experiments with TFMCC and it   appears to 


    None received.