2.8.13 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:

       http://rmt.motlabs.com -- Additional RMT Web Page
NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-02-19

Chair(s):
Roger Kermode <Roger.Kermode@motorola.com>
Lorenzo Vicisano <lorenzo@cisco.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
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:
Additional RMT web page: http://rmt.motlabs.com

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

Initial efforts will focus 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 expects to initially standardize three protocol instantiations, one each from the the following three families:

1) A NACK-based protocol 2) A Tree-based ACK protocol 3) An "Asynchronous Layered Coding protocol that uses Forward Error Correction

The WG will carry out protocol standardization by composing 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 arguments.

- 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.

To assist in this standardization process, the WG will also complete work on three documents. The first describes the design-space in which the three one-to-many transport protocols will be developed. The second explains the concepts of building-blocks and protocol instantiations. The third provides guidelines to authors of drafts that specify building-blocks and protocol instantiations. These three documents will be initially submitted as WG drafts and subsequently proposed as Informational RFC.

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

The WG will also standardize and generate RFCs for the following three protocol instantiations: A NACK-based protocol, A Tree-based ACK protocol and an Open Loop protocol that uses Forward Error Correction.

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 deliverables.

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 three protocol instantiations.
Done  Review drafts at the Adelaide IETF
Done  Submit Initial Draft for Congestion Control
Done  Complete building-block drafts WG Last-Call and submit for publication as Proposed Standard
JUN 00  Protocol instantiations drafts submitted for publication as Proposed Standard.
DEC 01  Congestion control draft submitted for publication as Proposed Standard.
Internet-Drafts:
  • - draft-ietf-rmt-bb-tree-config-03.txt
  • - draft-ietf-rmt-bb-norm-05.txt
  • - draft-ietf-rmt-pi-norm-06.txt
  • - draft-ietf-rmt-bb-track-02.txt
  • - draft-ietf-rmt-bb-pgmcc-01.txt
  • - draft-ietf-rmt-bb-webrc-04.txt
  • - draft-ietf-rmt-bb-tfmcc-01.txt
  • - draft-ietf-rmt-bb-gra-signalling-01.txt
  • - draft-ietf-rmt-bb-fec-supp-inband-00.txt
  • Request For Comments:
    RFCStatusTitle
    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

    Current Meeting Report

    RMT WG Meeting, 56th IETF - San Francisco
    Mon, March 17, 1530-1730
    
    Many thanks to Marshall Eubanks for taking minutes.
    
    Agenda:
    
     - New Charter discussion                                      Lorenzo 
    Vicisano
     - NORM BB and PI updates                                      Brian 
    Adamson
    	draft-ietf-rmt-bb-norm-05.txt
    	draft-ietf-rmt-pi-norm-06.txt
     - New "compact" scheme FEC BB                                 Mike Luby
    
    	draft-ietf-rmt-bb-fec-supp-inband-00.txt
     - New FDALC draft                                             Toni Paila
    	draft-paila-rmt-fdalc-00.txt
     - Kick off of the "Small Group Replication Service" subgroup  Rick 
    Boivie
    
    Please see slides for the new charter.
    The main feedback on the new charter were:
      - delay the Milestone for TFMCC Experimental submission 
      - it was noted that GRA had been removed from the milestone due to 
    perceived lack of resource and interest. It was decided to try and and find 
    new resources to work on this. Tom Pusateri to investigate on this with the 
    help of Brian Adamson and in coordination with the existing GRA 
    authors. Tom to report on this in a timely fashion.
      - more comments on the "small-replication service" later in this 
    report.
    
    Brian Adamson on NORM BB and PI. Please see slides.
    Brian felt that the "implementability" status of NORM is good as long as 
    both BB and PI are used.
    
    The WG was *strongly encouraged* to provide feedback on these two 
    documents, soon to be pushed forward.
    
    Mike Luby - ALC updates. Please see slides.
    Mike is still waiting for WEBRC BB to be submitted for publication.
    
    Mike Luby on new compact FEC BB. please see slides.
    
    Toni Paila on New FDALC draft. Please see slides.
    This is not a working group item yet. The WG decided that this was to 
    become a WG item as a good completion of ALC. No need for changes in 
    charter as this is only a completion of ALC.
    
    Rick Boivie presented on Small group replication service. Please sees 
    slides.
    
    Long discussion followed on whether this work was pertinent to RMT and on 
    whether this problem had been faced/resolved elsewhere in the 
    transport or application areas. Many objected that this work did not 
    belong in RMT. Other suggested possible alternatives, for example the 
    peer-to-peer research group.
    
    The consensus seemed to be that a BOF is needed, maybe a "end-system 
    multicast" BOF.
    

    Slides

    ALC track
    NACK-Oriented Reliable Multicast (NORM) Update
    A Simple Unicast Replication Service