headers
Internet-Drafts | 1 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-bb-fec-raptor-object-07.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: Raptor Forward Error Correction Scheme for Object Delivery
	Author(s)	: M. Luby, et al.
	Filename	: draft-ietf-rmt-bb-fec-raptor-object-07.txt
	Pages		: 52
	Date		: 2007-3-1
	
This document describes a Fully-Specified FEC scheme, corresponding
   to FEC Encoding ID 1, for the Raptor forward error correction code
   and its application to reliable delivery of data objects.

   Raptor is a fountain code, i.e., as many encoding symbols as needed
   can be generated by the encoder on-the-fly from the source symbols of
   a source block of data.  The decoder is able to recover the source
   block from any set of encoding symbols only slightly more in number
   than the number of source symbols.

   The Raptor code described here is a systematic code, meaning that all
   the source symbols are among the encoding symbols that can be
   generated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-raptor-object-07.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Roca | 6 Mar 2007 13:03
Picon

TESLA I-D update + change in the EXT_AUTH format

Hello everybody,

A few points:

1- FYI we updated the TESLA I-D (which expired in the mean-time):

http://www.ietf.org/internet-drafts/draft-ietf-msec-tesla-for-alc-norm-01.txt

2- I think we should update the LCT document, section 5.2.1, when
describing EXT_AUTH, HET=1. It is said that:
         The format of this Header Extension and its processing is
         outside the scope of this document and is to be communicated
         out-of-band as part of the session description.

I don't agree for the following reason.
There are several ways to perform packet content integrity verification
and packet sender authentication. One solution is to digitally sign the
packet, another one is to use TESLA (and other techniques exist)...

I believe we should require (i.e. say in LCT I-D) that the EXT_AUTH
Header Extension Content field starts with a reserved "authentication
scheme identifier" field (4 bits are sufficient). I don't think we need
to reserve the identifier values in the LCT I-D since it could be done
in the I-D that specifies an authentication scheme (e.g. TESLA I-D),
as we do with FEC Enc IDs (or maybe we can do an exception for digital
signatures).

The proposed EXT_AUTH format would be:

      0                   1                   2                   3
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Adamson | 7 Mar 2007 21:31
Picon
Picon

Draft IETF 68 RMT WG Agenda Posted

A draft agenda for the IETF 68 RMT WG Meeting has been posted to:

http://www.ietf.org/proceedings/07mar/agenda/rmt.txt

Please let Lorenzo or I know if anything was missed or needs to be 
added.  For those providing presentations, if you can provide them 
prior to the meeting, I can post them to the "Meeting Materials" page 
for access to remote participants.

best regards,

--

-- 
Brian

Brian Adamson
<adamson <at> itd.nrl.navy.mil>
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 8 Mar 2007 21:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-pi-norm-revised-04.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
	Author(s)	: B. Adamson, et al.
	Filename	: draft-ietf-rmt-pi-norm-revised-04.txt,.ps,.pdf
	Pages		: 86
	Date		: 2007-3-8
	
This document describes the messages and procedures of the Negative-
   acknowledgment (NACK) Oriented Reliable Multicast (NORM) protocol.
   This protocol is designed to provide end-to-end reliable transport of
   bulk data objects or streams over generic IP multicast routing and
   forwarding services.  NORM uses a selective, negative acknowledgment
   mechanism for transport reliability and offers additional protocol
   mechanisms to allow for operation with minimal "a priori"
   coordination among senders and receivers.  A congestion control
   scheme is specified to allow the NORM protocol to fairly share
   available network bandwidth with other transport protocols such as
   Transmission Control Protocol (TCP).  It is capable of operating with
   both reciprocal multicast routing among senders and receivers and
   with asymmetric connectivity (possibly a unicast return path) between
   the senders and receivers.  The protocol offers a number of features
   to allow different types of applications or possibly other higher
   level transport protocols to utilize its service in different ways.
   The protocol leverages the use of FEC-based repair and other IETF
   reliable multicast transport (RMT) building blocks in its design.

A URL for this Internet-Draft is:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Watson | 20 Mar 2007 18:33
Favicon

Re: One more comment on draft-ietf-rmt-fec-bb-revised-05

-06 submitted - sorry for the delay.

It should have been referenced from the introduction - but that was
referencing RFC3926 instead of RFC3296, and the latter just happened to also
be referenced by the document.

...Mark

On 2/26/07 12:46 AM, "Magnus Westerlund" <magnus.westerlund <at> ericsson.com>
wrote:

> Hi Mark,
> 
> It seems that you will have to do one more spin of this draft. There is
> a warning nit that has to do with that reference [5] is not used in the
> text. Either included it somewhere in the text or remove it from the list.
> 
> See the last one of the checked references.
> http://tools.ietf.org/wg/rmt/draft-ietf-rmt-fec-bb-revised/draft-ietf-rmt-fec-
> bb-revised-05.nits.txt
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Wenger | 21 Mar 2007 17:56

OMA BCAST liaison reply

Folks,
please find below my proposal for a reply liaison to OMA BCAST.  Now  
bash it up :-), but remember: they asked for a reply by 23.03.07,  
which is this Friday
Stephan

> From: IETF RMT WG
> To:   OMA BCAST
> Re:   OMA-LS_0166-BCAST_to_IETF_Layered_Coding_Transport-20070215-A
>
> Dear OMA BCAST,
>
> The IETF RMT WG thanks OMA BCAST for the liaison statement on
> Layered Coding Transport, dated on 8 Feb 2007. We have
> discussed the questions and our answers are as follows:
>
> Question #1 (by OMA BCAST)
> Does IETF RMT consider the revision of LCT building block
> stable enough so that we can refer to that in OMA BCAST 1.0
> specification?
>
> Answer #1 (by IETF RMT)
> IETF RMT considers the revised LCT specification (currently in
> the state of an Internet-Draft) to be sufficiently stable for
> reference by OMA BCAST. Once the specification has been
> published as a Proposed Standard, we suggest OMA BCAST could
> update the reference to point to the RFC.
>
> Question #2 (by OMA BCAST)
> What is estimated schedule for revising the RMT RFCs on the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stephan Wenger | 21 Mar 2007 21:33

Re: OMA BCAST liaison reply

Ok. Here's the modified statement
Stephan

> From: IETF RMT WG
> To:   OMA BCAST
> Re:   OMA-LS_0166-BCAST_to_IETF_Layered_Coding_Transport-20070215-A
>
> Dear OMA BCAST,
>
> The IETF RMT WG thanks OMA BCAST for the liaison statement on
> Layered Coding Transport, dated on 8 Feb 2007. We have
> discussed the questions and our answers are as follows:
>
> Question #1 (by OMA BCAST)
> Does IETF RMT consider the revision of LCT building block
> stable enough so that we can refer to that in OMA BCAST 1.0
> specification?
>
> Answer #1 (by IETF RMT)
> IETF RMT considers the revised LCT specification (currently in
> the state of an Internet-Draft) to be sufficiently stable for
> reference by OMA BCAST. Once the specification has been
> published as a Proposed Standard, we suggest OMA BCAST could
> update the reference to point to the RFC.
>
> Question #2 (by OMA BCAST)
> What is estimated schedule for revising the RMT RFCs on the
> Standards Track?
>
> Answer #2 (by IETF RMT)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Internet-Drafts | 22 Mar 2007 15:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-fec-bb-revised-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: Forward Error Correction (FEC) Building Block
	Author(s)	: M. Watson, et al.
	Filename	: draft-ietf-rmt-fec-bb-revised-06.txt
	Pages		: 32
	Date		: 2007-3-22
	
This document describes how to use Forward Error Correction (FEC)
   codes to efficiently provide and/or augment reliability for bulk data
   transfer over IP multicast.  This document defines a framework for
   the definition of the information that needs to be communicated in
   order to use an FEC code for bulk data transfer, in addition to the
   encoded data itself, and for definition of formats and codes for
   communcation of that information.  Both information communicated with
   the encoded data itself and information that needs to be communicated
   'out-of-band' are considered.  The procedures for specifying new FEC
   codes, defining the information communication requirements associated
   with those codes and registering them with the Internet Assigned
   Numbers Authority (IANA) are also described.  The requirements on
   Content Delivery Protocols which wish to use FEC codes defined within
   this framework are also defined.  The companion document titled, "The
   Use of Forward Error Correction (FEC) in Reliable Multicast"
   describes some applications of FEC codes for delivering content.
   This document obsoletes RFC3452.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-fec-bb-revised-06.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 28 Mar 2007 14:06
Picon
Favicon

Last Call: draft-ietf-rmt-fec-bb-revised (Forward Error Correction (FEC) Building Block) to Proposed Standard

The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:

- 'Forward Error Correction (FEC) Building Block '
   <draft-ietf-rmt-fec-bb-revised-06.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2007-04-11. Exceptionally, 
comments may be sent to iesg <at> ietf.org instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-rmt-fec-bb-revised-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13112&rfc_flag=0
Permalink | Reply | 0 comments |
headers
Internet-Drafts | 29 Mar 2007 16:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-bb-fec-ldpc-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Reliable Multicast Transport Working Group of the IETF.

	Title		: Low Density Parity Check (LDPC) Staircase and
                          Triangle Forward Error Correction (FEC) 
                          Schemes
	Author(s)	: V. Roca, et al.
	Filename	: draft-ietf-rmt-bb-fec-ldpc-05.txt
	Pages		: 34
	Date		: 2007-3-29
	
This document describes two Fully-Specified FEC Schemes, LDPC-
   Staircase and LDPC-Triangle, and their application to the reliable
   delivery of objects on packet erasure channels.  These systematic FEC
   codes belong to the well known class of ``Low Density Parity Check''
   (LDPC) codes, and are large block FEC codes in these sense of
   RFC3453.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-ldpc-05.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After
(Continue reading)

Permalink | Reply | 0 comments |

Gmane