headers
Internet-Drafts | 3 Jan 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-flute-revised-01.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		: FLUTE - File Delivery over Unidirectional 
                          Transport
	Author(s)	: T. Paila, et al.
	Filename	: draft-ietf-rmt-flute-revised-01.txt
	Pages		: 34
	Date		: 2006-1-3
	
This document defines FLUTE, a protocol for the unidirectional
   delivery of files over the Internet, which is particularly suited to
   multicast networks.  The specification builds on Asynchronous Layered
   Coding, the base protocol designed for massively scalable multicast
   distribution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-01.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 logging in,
type "cd internet-drafts" and then
	"get draft-ietf-rmt-flute-revised-01.txt".

A list of Internet-Drafts directories can be found in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lorenzo Vicisano | 5 Jan 2006 04:42
Picon
Favicon

Re: FEC ID allocation

Given that this thread is stalling without consensus, I propose to
dismiss the proposal of changing the strategy for allocating FEC
Encoding IDs and sticking with the policy specified in
draft-ietf-rmt-fec-bb-revised-02: "IETF Consensus".
draft-ietf-rmt-fec-bb-revised-02 already went through WG last call
without major revision needed.

If however you have new points to make, please speak now.

	thank you,
	Lorenzo

On Wed, Nov 23, 2005 at 09:47:27AM -0800, Lorenzo Vicisano wrote:
> At the Vancouver meeting we had a discussion on possibly revising the
> strategy for allocating FEC Encoding IDs. The discussion was
> inconclusive and hence it was decided to bring this issue to the list,
> starting a 1-week WG last-call on it.
> 
> The current strategy for allocating FEC Encoding IDs is
> 
>   A) IETF-Consensus, i.e. requiring an IETF RFC that specifies all the
>      requested information (see draft-ietf-rmt-fec-bb-revised-02) and that
>      instructs IANA to assign a specific ID.
> 
> One alternative proposal on the table was to transform IETF consensus into
> 
>   B) Standard Action, i.e. requiring a Standard-Track IESG approved
>      RFC
> 
> Another was:
(Continue reading)

Permalink | Reply | 3 comments |
headers
toni.paila | 9 Jan 2006 01:00
Picon

[EXP2STD] FLUTE revised -01

Hello RMT folks, dear co-authors of FLUTE,

You can now access revised FLUTE specification at:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-01.txt

The document now incorporates all the comments that were given both in the previous IETF meeting as well via
this mailing list. The differences between RFC3926 and the FLUTE-revised-01 are listed in Section 11 of
the latter.

While most of the changes are simple, I would like to get your attention to one slightly (seemingly) greater
change. Namely, the specification of EXT_FTI is no longer a part of FLUTE specification. Per agreement
with Mark Watson, we decided the more natural place for EXT_FTI is the LCT BB specifiation. Mark promised
to include the EXT_FTI in the next release of LCT BB. Hence, the FLUTE-revised-01 just refers to LCT BB for
the EXT_FTI specification.

Lorenzo, what is your plan taking this I-D (FLUTE-revised-01) forward and progressing along with
standards track?

Regards,
 Toni

> -----Original Message-----
> From: i-d-announce-bounces <at> ietf.org
> [mailto:i-d-announce-bounces <at> ietf.org]
> Sent: 03 January, 2006 22:50
> To: i-d-announce <at> ietf.org
> Cc: rmt <at> ietf.org
> Subject: I-D ACTION:draft-ietf-rmt-flute-revised-01.txt 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 18 Jan 2006 15:08
Picon
Favicon

draft-ietf-rmt-bb-lct-revised-01 is draft-ietf-rmt-pi-alc-revised-01

Hi,

There was some submission error when draft-ietf-rmt-bb-lct-revised was 
submitted. Because the content is really that one of pi-alc-revised-01. 
Can some one please submit the correct versions?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
Permalink | Reply | 0 comments |
headers
Magnus Westerlund | 18 Jan 2006 15:25
Picon
Favicon

How is the FEC instance ID field in the EXT_FTI header defined?

Hi,

Due to the missing LCT revised specification draft version 01 I do have 
to ask this question. It might be answered by that draft, that I don't 
know as I can't get hold of it.

But the real question is: Is the FEC Instance ID field present or not in 
the EXT_FTI header when the FEC encoding ID is less than 128? The RFC 
3926 text:
    FEC Instance ID, optional, 16 bits:

    This field is used for FEC Instance ID.  It is only present if the
    value of FEC Encoding ID is in the range of 128-255.  When the value
    of FEC Encoding ID is in the range of 0-127, this field is set to 0.

Which says both that it shouldn't be there and have a value. Please 
clarify this for me.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com
Permalink | Reply | 0 comments |
headers
Mark Watson | 18 Jan 2006 15:39
Favicon

RE: draft-ietf-rmt-bb-lct-revised-01 isdraft-ietf-rmt-pi-alc-revised-01

Hi Magnus,

The correct draft was submitted but the wrong one was posted in the
directory - we asked for this to be fixed a long time ago and I thought
it had been done. I have re-submitted the correct draft.

Regards,

Mark

-----Original Message-----
From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On Behalf Of
Magnus Westerlund
Sent: Wednesday, January 18, 2006 9:09 AM
To: rmt <at> ietf.org
Subject: [Rmt] draft-ietf-rmt-bb-lct-revised-01
isdraft-ietf-rmt-pi-alc-revised-01

Hi,

There was some submission error when draft-ietf-rmt-bb-lct-revised was 
submitted. Because the content is really that one of pi-alc-revised-01. 
Can some one please submit the correct versions?

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Watson | 18 Jan 2006 17:45
Favicon

RE: How is the FEC instance ID field in the EXT_FTI headerdefined?

Magnus,

Actually, ETX_FTI is formally defined in (the new) ALC, but that just
defines the Header Extension Type (64) and says that the content is the
"Encoded FEC Object Transmission Information" which (according to the
FEC BB) MUST be defined independently by each FEC Scheme.

So, for FEC Schemes with FEC Encoding ID < 128 they do not need to
include the (redundant) FEC Instance ID.

However, for the previously defined FEC Schemes then in
draft-ietf-rmt-bb-fec-basic-schemes-revised-01.html I defined the
"Encoded FEC Object Transmission Information" to match the previous
definition - in particular for the Compact No-Code, the bytes
corresponding to the FEC Instance ID are included but marked as
reserved. So, we have backwards compatibility for the existing FEC
Schemes and flexibility for future ones.

Regards,

Mark

-----Original Message-----
From: rmt-bounces <at> ietf.org [mailto:rmt-bounces <at> ietf.org] On Behalf Of
Magnus Westerlund
Sent: Wednesday, January 18, 2006 9:25 AM
To: rmt <at> ietf.org
Subject: [Rmt] How is the FEC instance ID field in the EXT_FTI
headerdefined?
(Continue reading)

Permalink | Reply | 501 comments |
headers
Magnus Westerlund | 19 Jan 2006 11:33
Picon
Favicon

Re: How is the FEC instance ID field in the EXT_FTI headerdefined?

So the correct interpretation of RFC 3926 in this regard for existing 
schemes (for example Raptor and No-compact code) is that the FEC 
Instance ID field is present but always set to 0?

The text that I cited could have been interpretead either way.

Cheers

Magnus

Mark Watson wrote:
> Magnus,
> 
> Actually, ETX_FTI is formally defined in (the new) ALC, but that just
> defines the Header Extension Type (64) and says that the content is the
> "Encoded FEC Object Transmission Information" which (according to the
> FEC BB) MUST be defined independently by each FEC Scheme.
> 
> So, for FEC Schemes with FEC Encoding ID < 128 they do not need to
> include the (redundant) FEC Instance ID.
> 
> However, for the previously defined FEC Schemes then in
> draft-ietf-rmt-bb-fec-basic-schemes-revised-01.html I defined the
> "Encoded FEC Object Transmission Information" to match the previous
> definition - in particular for the Compact No-Code, the bytes
> corresponding to the FEC Instance ID are included but marked as
> reserved. So, we have backwards compatibility for the existing FEC
> Schemes and flexibility for future ones.
> 
> Regards,
(Continue reading)

Permalink | Reply | 501 comments |
headers
mark | 19 Jan 2006 14:14
Favicon

Re: How is the FEC instance ID field in the EXT_FTI headerdefined?

Magnus,

Yes, that interpretation is correct. The field is present but set to zero in the already-defined
fully-specified schemes.

...Mark

Sent from my BlackBerry wireless handheld.

-----Original Message-----
From: Magnus Westerlund <magnus.westerlund <at> ericsson.com>
Date: Thu, 19 Jan 2006 11:33:43 
To:Mark Watson <mark <at> digitalfountain.com>
Cc:rmt <at> ietf.org
Subject: Re: [Rmt] How is the FEC instance ID field in the EXT_FTI headerdefined?

So the correct interpretation of RFC 3926 in this regard for existing 
schemes (for example Raptor and No-compact code) is that the FEC 
Instance ID field is present but always set to 0?

The text that I cited could have been interpretead either way.

Cheers

Magnus

Mark Watson wrote:
> Magnus,
> 
> Actually, ETX_FTI is formally defined in (the new) ALC, but that just
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Watson | 26 Jan 2006 09:49
Favicon

draft-ietf-rmt-bb-lct-revised-01 and draft-ietf-rmt-fec-bb-revised-03

All,

 

The link to draft-ietf-rmt-bb-lct-revised-01 has finally been corrected and you can now find the correct document at http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-lct-revised-01.txt (but watch out for old copies that you browser has cached).

 

I have also submitted draft-ietf-rmt-fec-bb-revised-03, which includes the agreed text giving the rationale for the move to PS along with section explaining the changes from the Experimental RFC. This should appear shortly at http://www.ietf.org/internet-drafts/draft-ietf-rmt-fec-bb-revised-03.txt.

 

Regards,

 

Mark

_______________________________________________
Rmt mailing list
Rmt <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rmt
Permalink | Reply | 1 comment |

Gmane