2.8.12 Reliable Multicast Transport (rmt)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. 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-10-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 2005  Submit remaining congestion control building blocks (TFMCC, PGMCC) for publication as Experimental
Dec 2005  Submit all the RMT Eperimental Specifications published before July 05 for publication as Proposed Standard
Apr 2006  Submit all remaining RMT Eperimental Specifications for publication as Proposed Standard


  • draft-ietf-rmt-bb-tfmcc-05.txt
  • draft-ietf-rmt-bb-fec-raptor-object-03.txt
  • draft-ietf-rmt-fec-bb-revised-02.txt
  • draft-ietf-rmt-bb-lct-revised-01.txt
  • draft-ietf-rmt-pi-alc-revised-01.txt
  • draft-ietf-rmt-bb-fec-basic-schemes-revised-01.txt
  • draft-ietf-rmt-flute-revised-00.txt
  • draft-ietf-rmt-bb-fec-ldpc-00.txt
  • draft-ietf-rmt-pi-norm-revised-00.txt
  • draft-ietf-rmt-bb-norm-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

    IETF 64 Vancouver, Canada
    RMT WG Minutes
    Many thanks to Magnus Westerlund for taking these minutes.
    Off the Agenda
        Allison asked what was happening with SDP flute draft.
        Magnus: It is being updated and we could expect an update the next few days.
    Status update
    See presentation slides.
    Moving to Standard Track:
    Brian Adamson: it would be appropriate to move TMFRC to Standard
    Track as well, as NORM can use a normative reference to it.
    Vincent Roca: implementation is progressing, but no draft has been
    submitted yet. A few more weeks than it should be available.
    Lorenzo: TESLA not on the charter need to start discussion on that
    topic. So please take this to the list.
    Moving NORM to Standard Track -- Brian Adamson
    See presentation slides.
    Lorenzo: Changes section should be included to help reviewers with
    noticing what has been changed and reduce the workload of review.
    Allison: This are the changes and why it should go forward. Section
    should be called "Changes since RFC XXXX". Some documents need to go
    together so there are no meaning to send in documents until the
    dependency are ready.
    Consensus on the above topic was the following:
       - all submissions transforming an Experimental into a Standard Tack
         RFC should contain the following:
         * a section "Changes since RFCXXXX"
         * A common note explaining the rationale for moving to Standard
           Track (this note will be the same in all document a will be
           drafted soon by the WG).
       - Dependency order should be enforced in the submission to the IESG
         (submit dependent documents later).
    Mark: On the EXT_FTI it is defined by the FEC scheme. Updated FLUTE
    has changed.  Brian: As NORM is not a ALC protocol it defines it in a
    similar way but do not reference it as it
    Mark: ALC/LCT registers its own IANA registry, should NORM use the same
    Lorenzo: Yes, two different registries should be defined.
    Allison: Write clear instructions to ensure that they are correctly
    placed in the IANA registry so these ends up under the RMT umbrella.
    Consensus on header extensions:
       - establish 2 IANA registries (one for ALC/LCT and one for NORM).
       - Write clear instructions to accomplish this in both ALC/LCT and
         NORM, choosing appropriate (hierarchical ?) names for the
       - all documents that allocate header extensions (for ALC, NORM or
         both) must contain specific IANA instructions to do so in the
         "IANA" Section.
    FLUTE Update -- Stephan Wenger
    See presentation slides.
    Stephan: Changes slides needs to go into the draft.
    Magnus: Has anyone reviewed the URN used to identify the FDT XML schema.
    Allison(side note) Needs to go to URN mailing list.
    Mark: Should reference the FEC BB not the basic FF schemes.
    Allison: Media type and URN review can happen in parallel in with the
    WGLC.  Send notice to both those mailing lists that can be found under
    non-WG mailing list at IETF page.
    FEC BB -- Mark Watson
    See presentation slides.
    Lorenzo: Is there a changes section?
    Mark: IS it ready for going to IESG.
    Lorenzo: A new WGLC does not seem necessary. Revise and declare
    intention to submit.
    Allison: If this doesn't have dependency it is fine to submit it. Only
    drafts that has dependency shouldn't be submitted until all documents
    are ready and then sent to IESG as a bunch.
    Lorenzo: FEC-raptor-object will be sent to IESG as soon as the BB is ready.
    LCT Revised -- Mark Watson
    See presentation slides.
    Mark: No comments was received on proposal to RMT and has been
    implemented. So if you do not agree to the changes then speak up.
    Lorenzo: IANA notes in FLUTE, ALC needs to have registration of their
    header extensions.  Brian: Then NORM should also define its header
    extension registry.
    Allison: IETF Review (replace IETF consensus) is a good level. As this
    forces review within IETF.
    Mark: Sounds reasonable
    Magnus: I think IETF review might be reasonable for header extensions.
    But what about fully qualified FEC schemes and there requirements?
    Allison: There are a lot of options on how IANA can handle these
    Long discussion on alternatives. Allison providing some alternatives
    and Magnus arguing for greater flexibility for IETF external
    organizations to register things. Some alternatives to IETF
    specification required was: IETF expert to approve specification
    required as complement IESG approval of specification required
    Lorenzo: Alternatives
    1. IETF consensus
    2. IETF consensus with bypass with publication required and expert review.
    3. Something else
    Lorenzo choice between the first two alternative will go for a 1 week
    Mark: Proposal for IANA rules for LCT header extension: IETF publication
    required.  No comments.
    Mark: Please report if LCT changes of sender current time field would
    cause problem.  LCT draft is not available due to errors with the
    TMFCC -- Mark Pullen
    See presentation slides.
    Mark Pullen (MarkP)
    Lorenzo: Will a new draft be resubmitted?
    MarkP: Yes, as soon as deadline for receiving comments has been passed.
    LDPC -- Vincent Roca
    See presentation slides.
    Mark: Do you mix source and repair symbols?
    Vincent: No, they will be of only one type.
    Lorenzo: IS this ready for WGLC?
    Vincent: No, next version
    Mark: To achieve good performance it most likely that you need to send
    source and repair symbol packets in random order. Draft should
    document the consideration between sending source symbols first, or
    sending them in random order.
    Mark: Please remove statement in relation to IPR that are not the
    standard IETF boiler plate.
    Lorenzo: Mark is probably correct, will double-check.
    RS fully specified code -- Vincent Roca
    See presentation slides.
    Lorenzo: Thanks very much for doing this overdue piece of work. Need
    to formally accept this as WG item. Vincent, please send a request to
    the WG mailing list.
    File Aggregation -- Vincent Roca
    See presentation slides.
    Mark: TOI question. FLUTE revised has no structure for TOI. Should all
    text be removed about the TOI in this proposal?
    Vincent: Yes, seems reasonable.
    Joerg: Running a FEC scheme over for example a website where certain
    parts need to change is counter productive.
    Lorenzo: A Question is if this should be a WG ITem. IT is a bit off charter.
    Mark: It is useful and should be supported.
    Joerg: Would you like to get other gains like compression, by doing zip on the
    MArk: The question do you need to expose for the FDT layer that these are
    separate files?
    Lorenzo: Please send mail to the list discussing these issues.
    Timestamp LCT header extension -- Stephan Wenger
    Lorenzo: Why a timestamp and not a long lived identifier?
    Vincent: What is the goal for this document. Why restricted to a specific
    protocol and the chosen.
    Mark: LCT does not have a mechanism to indicate changes, however FLUTE
    does. So you would only have to listen until the next FDT repetition
    comes around.  Lorenzo: This discussion should be included in the
    draft. This could apply to norm.
    Brain: Norm has an instance id that can indicate changes. But it is
    limited and will wrap.
    Mark: The LCT header registry is an example.  And until that is
    published we live in the current world. And the WG can publish things
    without registry request.
    Lorenzo: please start a thread on the list to decide if this will be a
    WG document.


    Agenda and WG Status Update
    FEC IDs and schemes Revision + Raptor scheme
    ALC/LCT Revision