headers
Internet-Drafts | 10 Jun 2003 13:53
Picon
Favicon

I-D ACTION:draft-ietf-rmt-bb-norm-06.txt,.ps,.pdf

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		: NACK-Oriented Reliable Multicast (NORM) Building 
                          Blocks
	Author(s)	: B. Adamson, C. Bormann, M. Handley, J. Macker
	Filename	: draft-ietf-rmt-bb-norm-06.txt,.ps,.pdf
	Pages		: 33
	Date		: 2003-6-9
	
This document discusses the creation the of negative-acknowledgment
This document discusses the creation the of negative-acknowledgment
(NACK)-oriented reliable multicast (NORM) protocols.  The rationale
for NORM goals and assumptions are presented.  Technical challenges
for NACK-oriented (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 NORM 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-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Internet-Drafts | 10 Jun 2003 13:53
Picon
Favicon

I-D ACTION:draft-ietf-rmt-pi-norm-07.txt,.ps,.pdf

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		: NACK-Oriented Reliable Multicast Protocol (NORM)
	Author(s)	: B. Adamson, C. Bormann, M. Handley, J. Macker
	Filename	: draft-ietf-rmt-pi-norm-07.txt,.ps,.pdf
	Pages		: 77
	Date		: 2003-6-9
	
This document describes the messages and procedures of the Negative-
acknowledgement (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 acknowledgement
mechanism for transport reliability and offers additional protocol
mechanisms to conduct reliable multicast sessions with limited 'a
priori' coordination among senders and receivers.  A congestion
control scheme is specified to allow the NORM protocol 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) from the
senders to 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:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-pi-norm-07.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lorenzo Vicisano | 11 Jun 2003 00:54
Picon
Favicon

WG last-call for NORM BB and PI

Please be advised that RMT Working Group last call is issued
for draft-ietf-rmt-bb-norm-06.txt and draft-ietf-rmt-pi-norm-07.txt,
starting Today.

Please send your comments to this mailing list by Wed June 25th.

	thank you,
	the RMT chairs.
Permalink | Reply | 2 comments |
headers
Internet-Drafts | 13 Jun 2003 13:51
Picon
Favicon

I-D ACTION:draft-ietf-rmt-flute-00.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-00.txt
	Pages		: 30
	Date		: 2003-6-12
	
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-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vincent Roca | 25 Jun 2003 18:06
Picon

Re: WG last-call for NORM BB and PI

Brian and al.,

Please find two comments after a _fast_ reading of the latest NORM PI
draft.

* session_id semantic, p 17:

  The NORM use of this session_id is quite different from that of ALC.
  With NORM, the session_id "uniquely identifies [the sender]
  current instance of parcipitation in the NormSession". So it does
  not identify the session (unlike it is suggested by its name)
  but a sender instance within a session. So at minimum the session_id
  name should be changed for something more explicit (eg. "sender
  instance id").

  With ALC, the session_id "uniquely identifies a session among all
  sessions from a particular sender".
  So the second part of this remark is: how is identified a NORM
  session?
  It seems there's no such mechanism (unless I missed something).
  Two sessions emanating from the same sender are probably
  distinguished by the session multicast address/UDP port... but is
  there something else?
  With ALC, the session (multicast or unicast) address is not used,
  only the {sender IP addr; TSI} tuple. It means that there is a full
  independance between the delivery mechanism (eg. the destination
  address may change while in transit) and the session identifying
  mechanism. OK, the situation is simpler in ALC since only 1-to-many
  sessions are considered, which is not the case of NORM...
  Nevertheless maybe something is missing here, for instance to
(Continue reading)

Permalink | Reply | 1 comment |
headers
Brian Adamson | 28 Jun 2003 04:33
Picon
Picon

Re: WG last-call for NORM BB and PI

I'm on vacation this week and won't likely get to update the draft 
_before_ the cutoff date, but I will see what I can do. I will be 
back in the office Tuesday.

With regards to the sessionId ... that makes sense to me ... i.e. to 
suggest that senders use a common sessionId for a common session 
instance, and I agree that how this is accomplished may be TBD ... I 
went with the "sender instance" usage because this has been an issue 
in some bulk transfer reliable  multicast applications ... when a 
sender leaves a long-lived session (crashing, terminated, etc) but 
then rejoins relatively quickly ... our implementation(s) of reliable 
multicast have used the objectId space to, if not deterministically, 
randomly to let receivers infer the rejoining sender is a "new" 
instance and they should "resync" to the sender (i.e. previous object 
transpor state they have for the sender may be invalid) ...  I have 
always felt this was a little weak, particularly that within NORM we 
now have a 16-bit objectId space, instead of the 32-bit objectId 
space used within previous protocols.  The "sender instance" usage of 
a sessionId field allows for a more robust solution to this issue ...

However, I understand the usefulness of a sessionId usage which 
allows the reliable multicast session to transcend mere multicast 
address/port number assignment ... this is probably more consistent 
with emerging concepts for transport protocols with more dynamic 
lower layers due to mobility, security, etc.
I think I understand that this is your "session collision" concern?

Perhaps the exact usage of the NORM sessionId field may become more 
well-defined as mechanisms to provide for signalling/agreement to 
sessionId values within a multicast session?  Meanwhile, the NORM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lorenzo Vicisano | 30 Jun 2003 20:40
Picon
Favicon

call for agenda items

For the Vienna meeting (Monday, July 14, 1500-1530).

Please reply to this email with your request.

Please remember the usual guidelines.

	thank you,
	the chairs.
Permalink | Reply | 0 comments |

Gmane