Internet-Drafts | 6 Sep 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-fec-bb-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		: Forward Error Correction (FEC) Building Block
	Author(s)	: M. Watson, et al.
	Filename	: draft-ietf-rmt-fec-bb-revised-04.txt
	Pages		: 32
	Date		: 2006-9-6
	
This document describes how to use Forward Error Correction (FEC)
   codes to efficiently provide and/or augment reliability for data
   transport.  This document defines a framework for the definition of
   the information that needs to be communicated in order to use an FEC
   code for delivering content, 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.

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

(Continue reading)

Brian Adamson | 18 Sep 2006 23:31
Picon
Picon

A first cut at capturing some RMT Security Issues

Hello Lorenzo,

I have attached a document that I started to summarize potential RMT 
security issues.  I wanted to put this in front of you before putting 
it on the list and opening an unnecessary can of worms (no pun 
intended).  This document is just an exploration of risks that I 
could think of (and those areas mentioned by Magnus and others on the 
list) ... It is basically a "Security Considerations" section on 
steroids.

I spoke with Ran Atkinson about it a little bit who has some 
experience in this area and he suggested we might want to get some 
advice from Russ Housely here.

The question that stands is:  Is specifying IPSec for authentication 
and optionally confidentiality, pointing to GSAKMP (RFC 4535) for 
automated key management sufficient for the RMT transport protocol 
instantiations?   Does that answer Magnus' concerns?

  I understand that some type of automated key management may now be 
mandatory for new protocol specifications within the IETF to make 
sure security is deployable?

I am thinking of providing updated NORM documents in this regard, but 
I know we discussed putting together some kind of RMT Security 
Analysis at the last working group meeting and the attachment is my 
first cut at that kind of thing.

(The attachment is HTML because the converter for text doesn't like 
my "included" RFC references)
(Continue reading)

Internet-Drafts | 25 Sep 2006 16:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-pi-norm-revised-03.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-03.txt,.ps,.pdf
	Pages		: 86
	Date		: 2006-9-25
	
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)

Magnus Westerlund | 26 Sep 2006 11:35
Picon
Favicon

Looking for Volunteer to chair the RMT WG

We are looking for volunteers to become co-chair in RMT WG together with 
  Lorenzo Vicisano.
http://www.ietf.org/html.charters/rmt-charter.html

The main work is to continue the update of a number of experimental RFC 
to proposed standard. The main issue here is to fulfill the security 
requirements to become proposed standard. Thus some knowledge of 
security is an advantage.

If you are interested please send a response to me and Lorenzo and 
include the following information:
- Name
- Affiliation
- Major accomplishments and official positions within IETF. Please note
that there are no requirement to had held any previous WG chair position
etc.

Please send your response at the latest the 10th of October.

cheers

Magnus Westerlund
TSV AD
Internet-Drafts | 27 Sep 2006 21:50
Picon
Favicon

I-D ACTION:draft-ietf-rmt-bb-norm-revised-02.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		: Multicast Negative-Acknowledgment (NACK) Building Blocks
	Author(s)	: B. Adamson, et al.
	Filename	: draft-ietf-rmt-bb-norm-revised-02.txt,.ps,.pdf
	Pages		: 39
	Date		: 2006-9-27
	
This document discusses the creation of reliable multicast protocols
utilizing negative-acknowledgment (NACK) feedback.  The rationale for
protocol design goals and assumptions are presented.  Technical
challenges for NACK-based (and in some cases general) reliable
multicast protocol operation are identified.  These goals and
challenges are resolved into a set of functional "building blocks"
that address different aspects of reliable multicast protocol
operation.  It is anticipated that these building blocks will be
useful in generating different instantiations of reliable multicast
protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-norm-revised-02.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.

(Continue reading)


Gmane