draft-ietf-rmt-pi-norm-revised-08.txt   draft-ietf-rmt-pi-norm-revised-09.txt 
Network Working Group B. Adamson Network Working Group B. Adamson
Internet-Draft Naval Research Laboratory Internet-Draft Naval Research Laboratory
Intended status: Standards Track C. Bormann Obsoletes: 3940 (if approved) C. Bormann
Expires: June 20, 2009 Universitaet Bremen TZI Intended status: Standards Track Universitaet Bremen TZI
M. Handley Expires: September 10, 2009 M. Handley
University College London University College London
J. Macker J. Macker
Naval Research Laboratory Naval Research Laboratory
December 17, 2008 March 9, 2009
NACK-Oriented Reliable Multicast Protocol NACK-Oriented Reliable Multicast Protocol
draft-ietf-rmt-pi-norm-revised-08 draft-ietf-rmt-pi-norm-revised-09
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 20, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes the messages and procedures of the Negative- This document describes the messages and procedures of the Negative-
ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol. ACKnowledgment (NACK) Oriented Reliable Multicast (NORM) Protocol.
This protocol is designed to provide end-to-end reliable transport of This protocol is designed to provide end-to-end reliable transport of
bulk data objects or streams over generic IP multicast routing and bulk data objects or streams over generic IP multicast routing and
forwarding services. NORM uses a selective, negative acknowledgment forwarding services. NORM uses a selective, negative acknowledgment
mechanism for transport reliability and offers additional protocol mechanism for transport reliability and offers additional protocol
mechanisms to allow for operation with minimal a priori coordination mechanisms to allow for operation with minimal a priori coordination
skipping to change at page 2, line 15 skipping to change at page 2, line 33
specified to allow the NORM protocol to fairly share available specified to allow the NORM protocol to fairly share available
network bandwidth with other transport protocols such as Transmission network bandwidth with other transport protocols such as Transmission
Control Protocol (TCP). It is capable of operating with both Control Protocol (TCP). It is capable of operating with both
reciprocal multicast routing among senders and receivers and with reciprocal multicast routing among senders and receivers and with
asymmetric connectivity (possibly a unicast return path) between the asymmetric connectivity (possibly a unicast return path) between the
senders and receivers. The protocol offers a number of features to senders and receivers. The protocol offers a number of features to
allow different types of applications or possibly other higher level allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways. The transport protocols to utilize its service in different ways. The
protocol leverages the use of FEC-based repair and other IETF protocol leverages the use of FEC-based repair and other IETF
reliable multicast transport (RMT) building blocks in its design. reliable multicast transport (RMT) building blocks in its design.
This document obsoletes RFC 3940.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119]. this document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Applicability . . . . . . . . . . . . . . . . 5 1. Introduction and Applicability . . . . . . . . . . . . . . . . 5
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 11 2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 11
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 13 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 13
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . 13 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . 13
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. NORM Common Message Header and Extensions . . . . . . . . 16 4.1. NORM Common Message Header and Extensions . . . . . . . . 16
4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 19 4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 19 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 19
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 29 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 29
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 30 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 30
4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 48 4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 47
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . 48 4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . 47
4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 54 4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 53
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 56 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 55
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 56 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 55
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 56 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 55
5.1. Sender Initialization and Transmission . . . . . . . . . . 58 5.1. Sender Initialization and Transmission . . . . . . . . . . 57
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 59 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 58
5.2. Receiver Initialization and Reception . . . . . . . . . . 60 5.2. Receiver Initialization and Reception . . . . . . . . . . 59
5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 60 5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 59
5.4. Sender NACK Processing and Response . . . . . . . . . . . 62 5.4. Sender NACK Processing and Response . . . . . . . . . . . 61
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 63 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 62
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 64 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 63
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 65 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 64
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 64
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 65
5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 66 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 65
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67 5.5.2. NORM Congestion Control Operation . . . . . . . . . . 66
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75 5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 74
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 76
6. Security Considerations . . . . . . . . . . . . . . . . . . . 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 76
6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 79 6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 78
6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 79 6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 78
6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 82 6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 81
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82
7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 83 7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 82
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 84 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 83
9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 84 9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 83
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1. Normative References . . . . . . . . . . . . . . . . . . . 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84
11.2. Informative References . . . . . . . . . . . . . . . . . . 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 85
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87
Intellectual Property and Copyright Statements . . . . . . . . . . 90
1. Introduction and Applicability 1. Introduction and Applicability
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol is designed to provide reliable transport of data from one protocol is designed to provide reliable transport of data from one
or more sender(s) to a group of receivers over an IP multicast or more sender(s) to a group of receivers over an IP multicast
network. The primary design goals of NORM are to provide efficient, network. The primary design goals of NORM are to provide efficient,
scalable, and robust bulk data (e.g., computer files, transmission of scalable, and robust bulk data (e.g., computer files, transmission of
persistent data) transfer across possibly heterogeneous IP networks persistent data) transfer across possibly heterogeneous IP networks
and topologies. The NORM protocol design provides support for and topologies. The NORM protocol design provides support for
skipping to change at page 5, line 28 skipping to change at page 5, line 28
participants. To accommodate this capability, NORM protocol message participants. To accommodate this capability, NORM protocol message
headers contain some common information allowing receivers to easily headers contain some common information allowing receivers to easily
synchronize to senders throughout the lifetime of a reliable synchronize to senders throughout the lifetime of a reliable
multicast session. NORM is designed to be self-adapting to a wide multicast session. NORM is designed to be self-adapting to a wide
range of dynamic network conditions with little or no pre- range of dynamic network conditions with little or no pre-
configuration. The protocol is purposely designed to be tolerant of configuration. The protocol is purposely designed to be tolerant of
inaccurate timing estimations or lossy conditions that may occur in inaccurate timing estimations or lossy conditions that may occur in
many networks including mobile and wireless. The protocol is also many networks including mobile and wireless. The protocol is also
designed to exhibit convergence and efficient operation even in designed to exhibit convergence and efficient operation even in
situations of heavy packet loss and large queuing or transmission situations of heavy packet loss and large queuing or transmission
delays. delays. This document obsoletes RFC 3940.
This document is a product of the IETF RMT WG and follows the This document is a product of the IETF RMT WG and follows the
guidelines provided in [RFC3269]. guidelines provided in [RFC3269].
Statement of Intent Statement of Intent
This memo contains the definitions necessary to fully specify a This memo contains the definitions necessary to fully specify a
Reliable Multicast Transport protocol in accordance with the criteria Reliable Multicast Transport protocol in accordance with the criteria
of [RFC2357]. A prior document, [RFC3940], contained a previous of [RFC2357]. A prior document, [RFC3940], contained a previous
description of the NORM Protocol specification described in this description of the NORM Protocol specification described in this
skipping to change at page 9, line 9 skipping to change at page 9, line 9
state be kept on all receivers in the group. NORM senders maintain state be kept on all receivers in the group. NORM senders maintain
state only for receivers providing explicit congestion control state only for receivers providing explicit congestion control
feedback. However, NORM receivers must maintain state for each feedback. However, NORM receivers must maintain state for each
active sender. This may constrain the number of simultaneous senders active sender. This may constrain the number of simultaneous senders
in some uses of NORM. in some uses of NORM.
1.3. Environmental Requirements and Considerations 1.3. Environmental Requirements and Considerations
All of the environmental requirements and considerations that apply All of the environmental requirements and considerations that apply
to the RMT Multicast NACK Building Block [RFC5401], FEC Building to the RMT Multicast NACK Building Block [RFC5401], FEC Building
Block [RFC5052], and TCP-Friendly Multicast Congestion Control Block[RFC5052], and TCP-Friendly Multicast Congestion Control (TFMCC)
(TFMCC) Building Block [RFC4654], also apply to the NORM protocol. Building Block[RFC4654], also apply to the NORM protocol.
The NORM protocol SHALL be capable of operating in an end-to-end The NORM protocol SHALL be capable of operating in an end-to-end
fashion with no assistance from intermediate systems beyond basic IP fashion with no assistance from intermediate systems beyond basic IP
multicast group management, routing, and forwarding services. While multicast group management, routing, and forwarding services. While
the techniques utilized in NORM are principally applicable to flat, the techniques utilized in NORM are principally applicable to flat,
end-to-end IP multicast topologies, they could also be applied in the end-to-end IP multicast topologies, they could also be applied in the
sub-levels of hierarchical (e.g., tree-based) multicast distribution sub-levels of hierarchical (e.g., tree-based) multicast distribution
if so desired. NORM can make use of reciprocal (among senders and if so desired. NORM can make use of reciprocal (among senders and
receivers) multicast communication under the Any-Source Multicast receivers) multicast communication under the Any-Source Multicast
(ASM) model defined in [RFC1112], but SHALL also be capable of (ASM) model defined in [RFC1112], but SHALL also be capable of
scalable operation in asymmetric topologies such as Source-Specific scalable operation in asymmetric topologies such as [RFC4607] where
Multicast (SSM) [RFC4607] where there may only be unicast routing there may only be unicast routing service from the receivers to the
service from the receivers to the sender(s). sender(s).
NORM is compatible with IPv4 and IPv6. Additionally, NORM may be NORM is compatible with IPv4 and IPv6. Additionally, NORM may be
used with networks employing Network Address Translation (NAT) used with networks employing Network Address Translation (NAT)
providing the NAT device supports IP multicast and/or can cache UDP providing the NAT device supports IP multicast and/or can cache UDP
traffic source port numbers for remapping feedback traffic from traffic source port numbers for remapping feedback traffic from
receivers to the sender(s). receivers to the sender(s).
2. Architecture Definition 2. Architecture Definition
A NormSession is comprised of participants (NormNodes) acting as A NormSession is comprised of participants (NormNodes) acting as
skipping to change at page 13, line 8 skipping to change at page 13, line 8
The feedback volume of these congestion control "NORM_ACK" messages The feedback volume of these congestion control "NORM_ACK" messages
is controlled using the same timer-based probabilistic suppression is controlled using the same timer-based probabilistic suppression
techniques as for "NORM_NACK" messages to avoid feedback implosion. techniques as for "NORM_NACK" messages to avoid feedback implosion.
In order to meet potential application requirements for positive In order to meet potential application requirements for positive
acknowledgment from receivers, other "NORM_ACK" messages are defined acknowledgment from receivers, other "NORM_ACK" messages are defined
and available for use. and available for use.
2.2. Protocol Building Blocks 2.2. Protocol Building Blocks
The operation of the NORM protocol is based primarily upon the The operation of the NORM protocol is based primarily upon the
concepts presented in the Multicast NACK Building Block document concepts presented in the Multicast NACK Building Block
[RFC5401]. This includes the basic NORM architecture and the data document[RFC5401]. This includes the basic NORM architecture and the
transmission, repair, and feedback strategies discussed in that data transmission, repair, and feedback strategies discussed in that
document. Additional reliable multicast building blocks, as document. Additional reliable multicast building blocks, as
described in [RFC3048], are applied in creating the full NORM described in [RFC3048], are applied in creating the full NORM
protocol instantiation . NORM also makes use of Forward Error protocol instantiation . NORM also makes use of Forward Error
Correction encoding techniques for repair messaging and optional Correction encoding techniques for repair messaging and optional
transmission robustness as described in [RFC3453]. NORM uses the FEC transmission robustness as described in [RFC3453]. NORM uses the FEC
Payload ID as specified by the FEC Building Block document [RFC5052]. Payload ID as specified by the FEC Building Block document [RFC5052].
Additionally, for congestion control, this document fully specifies a Additionally, for congestion control, this document fully specifies a
baseline congestion control mechanism (NORM-CC) based on the TCP- baseline congestion control mechanism (NORM-CC) based on the TCP-
Friendly Multicast Congestion Control (TFMCC) scheme of [TfmccPaper] Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] scheme and
and [RFC4654]. [RFC4654].
2.3. Design Tradeoffs 2.3. Design Tradeoffs
While the various features of NORM are designed to provide some While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering trade-offs involved transport arena. There are numerous engineering trade-offs involved
in reliable multicast transport design and this requires an increased in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations. awareness of application and network architecture considerations.
Performance requirements affecting design can include: group size, Performance requirements affecting design can include: group size,
skipping to change at page 17, line 27 skipping to change at page 17, line 27
| "NORM_REPORT" | 6 | | "NORM_REPORT" | 6 |
+---------------+-------+ +---------------+-------+
The 8-bit "hdr_len" field indicates the number of 32-bit words that The 8-bit "hdr_len" field indicates the number of 32-bit words that
comprise the given message's header portion. This is used to comprise the given message's header portion. This is used to
facilitate header extensions that may be applied. The presence of facilitate header extensions that may be applied. The presence of
header extensions are implied when the "hdr_len" value is greater header extensions are implied when the "hdr_len" value is greater
than the base value for the given message "type". than the base value for the given message "type".
The "sequence" field is a 16-bit value that is set by the message The "sequence" field is a 16-bit value that is set by the message
originator as a monotonically increasing number incremented with each originator. The "sequence" field serves two separate purposes,
NORM message transmitted. Note that two independent "sequence" depending upon the message type:
spaces MUST be maintained. One sequence space SHALL be kept for NORM 1. NORM senders MUST set the "sequence" field of sender messages
sender messages ("NORM_INFO", "NORM_DATA", and "NORM_CMD") generated, ("NORM_INFO", "NORM_DATA", and "NORM_CMD") so that receivers can
and a separate, independent "sequence" space SHALL be kept for NORM monitor the "sequence" value to maintain an estimate of packet
receiver messages ("NORM_NACK" and "NORM_NACK"). The sender message loss that can be used for congestion control purposes (See
"sequence" value can be monitored by receiving nodes to detect packet Section 5.5.2 for a detailed description of NORM Congestion
losses in the transmissions from a sender and used to estimate raw Control operation). A monotonically-increasing sequence number
packet loss for congestion control purposes. Note that this value is space MUST be maintained to mark NORM sender messages in this
NOT used in the NORM protocol to detect missing reliable data content way. Note that this "sequence" number is explicitly NOT used in
and does NOT identify the application data or FEC payload that may be NORM as part of its reliability procedures. The NORM object and
attached. The "sequence" field may also be leveraged for protection FEC payload identifiers are used to detect missing content for
from message replay attacks, particularly of "NORM_NACK" or other reliable transfer purposes.
feedback messages. For this reason, NORM receiver messages are also 2. NORM receivers SHOULD set the "sequence" field to support
sequence numbered. An independent sequence space MUST be used for protection from message replay attacks of "NORM_NACK" or
receiver messages because when receivers generate unicast "NORM_NACK" "NORM_NACK" messages. Note that, depending upon configuration,
or "NORM_ACK" messages, those messages will not be visible to the NORM feedback messages may be sent to the session multicast
group at large that may be performing loss estimation. Also, NORM address or unicast address[es] of the active NORM sender[s].
congestion control is applied only to sender messages. The size of Thus, a separate, monotonically-increasing sequence number space
the "sequence" field is intended to be sufficient to allow detection MUST be maintained for each destination address to which the NORM
of a reasonable range of packet loss within the delay-bandwidth receiver is transmitting feedback messages.
product of expected network connections.
The "source_id" field is a 32-bit value identifying the node that Note that these two separate purposes necessitate the maintenance of
sent the message. A participant's NORM node identifier (NormNodeId) separate sequence spaces to support the functions described here.
can be set according to application needs but unique identifiers must And, in the case of NORM receivers, additional sequence spaces are
be assigned within a single NormSession. In some cases, use of the needed when feedback messages are sent to the sender unicast
host IP address or a hash of it can suffice, but alternative address[es] instead of the session address.
methodologies for assignment and potential collision resolution of
node identifiers within a multicast session need to be considered. The "source_id" field is a 32-bit value that uniquely identifies the
For example, the "source identifier" mechanism defined in the Real- node that sent the message within the context of a single
Time Protocol (RTP) specification [RFC3550] may be applicable to use NormSession. This value is termed the NORM node identifier
for NORM node identifiers. At this point in time, the protocol makes (NormNodeId) and unique NormNodeId identifiers MUST be assigned
no assumptions about how these unique identifiers are actually within a single NormSession. In some cases, use of the host IP
assigned. address or a hash of it can suffice, but alternative methodologies
for assignment and potential collision resolution of node identifiers
within a multicast session SHOULD be considered. For example, the
techniques for managing the 32-bit "synchronization source" (SSRC)
identifiers defined in the Real-Time Protocol (RTP) specification
[RFC3550] are applicable for use with NORM node identifiers. In most
deployments of the NORM protocol to date, the NormNodeId assignments
are administratively configured.
NORM Header Extensions NORM Header Extensions
When header extensions are applied, they follow the message type's When header extensions are applied, they follow the message type's
base header and precede any payload portion. There are two formats base header and precede any payload portion. There are two formats
for header extensions, both of which begin with an 8-bit "het" for header extensions, both of which begin with an 8-bit "het"
(header extension type) field. One format is provided for variable- (header extension type) field. One format is provided for variable-
length extensions with "het" values in the range from 0 through 127. length extensions with "het" values in the range from 0 through 127.
The other format is for fixed length (one 32-bit word) extensions The other format is for fixed length (one 32-bit word) extensions
with "het" values in the range from 128 through 255. These formats with "het" values in the range from 128 through 255. These formats
skipping to change at page 20, line 43 skipping to change at page 20, line 43
"payload_offset" fields are present ONLY for objects of type "payload_offset" fields are present ONLY for objects of type
"NORM_OBJECT_STREAM". These fields, as with the entire payload, are "NORM_OBJECT_STREAM". These fields, as with the entire payload, are
subject to any FEC encoding used. Thus, when systematic FEC codes subject to any FEC encoding used. Thus, when systematic FEC codes
are used, these values may be directly interpreted for packets are used, these values may be directly interpreted for packets
containing source symbols only while packets containing FEC parity containing source symbols only while packets containing FEC parity
content require decoding before these fields can be interpreted. content require decoding before these fields can be interpreted.
The "version", "type", "hdr_len", "sequence", and "source_id" fields The "version", "type", "hdr_len", "sequence", and "source_id" fields
form the NORM Common Message Header as described in Section 4.1. The form the NORM Common Message Header as described in Section 4.1. The
value of the "NORM_DATA" "type" field is 2. The "NORM_DATA" base value of the "NORM_DATA" "type" field is 2. The "NORM_DATA" base
"hdr_len" value is 4 (32-bit words) plus the size of the "hdr_len" value is 4 (i.e. 4 32-bit words) plus the size of the
"fec_payload_id" field. The "fec_payload_id" field size depends upon "fec_payload_id" field. The "fec_payload_id" field size depends upon
the FEC encoding type referenced by the "fec_id" field. For example, the FEC encoding type referenced by the "fec_id" field. For example,
when small block, systematic codes are used, a "fec_id" value of 129 when small block, systematic codes are used, a "fec_id" value of 129
is indicated and the size of the "fec_payload_id" is two 32-bit is indicated and the size of the "fec_payload_id" is two 32-bit
words. In this case the . The "fec_id" field is used to indicate words. In this case the "NORM_DATA" base "hdr_len" value is 6. The
the FEC coding type. For example, when small block, systematic codes cumulative size of any header extensions applied is added into the
are used, a "fec_id" value of 129 is indicated and the size of the "hdr_len" field.
"fec_payload_id" is two 32-bit words. In this case the "NORM_DATA"
base "hdr_len" value is 6. The cumulative size of any header
extensions applied is added into the "hdr_len" field.
The "instance_id" field contains a value generated by the sender to The "instance_id" field contains a value generated by the sender to
uniquely identify its current instance of participation in the uniquely identify its current instance of participation in the
NormSession. This allows receivers to detect when senders have NormSession. This allows receivers to detect when senders have
perhaps left and rejoined a session in progress. When a sender perhaps left and rejoined a session in progress. When a sender
(identified by its "source_id") is detected to have a new (identified by its "source_id") is detected to have a new
"instance_id", the NORM receivers SHOULD drop their previous state on "instance_id", the NORM receivers SHOULD drop their previous state on
the sender and begin reception anew, or at least treat this the sender and begin reception anew, or at least treat this
"instance" as a new, separate sender. "instance" as a new, separate sender.
skipping to change at page 23, line 49 skipping to change at page 23, line 45
course of its transmission within a NORM session, an object is course of its transmission within a NORM session, an object is
uniquely identified by the concatenation of the sender "source_id" uniquely identified by the concatenation of the sender "source_id"
and the given "object_transport_id". Note that "NORM_INFO" messages and the given "object_transport_id". Note that "NORM_INFO" messages
associated with the identified object carry the same associated with the identified object carry the same
"object_transport_id" value. "object_transport_id" value.
The "fec_payload_id" identifies the attached "NORM_DATA" "payload" The "fec_payload_id" identifies the attached "NORM_DATA" "payload"
content. The size and format of the "fec_payload_id" field depends content. The size and format of the "fec_payload_id" field depends
upon the FEC type indicated by the "fec_id" field. These formats are upon the FEC type indicated by the "fec_id" field. These formats are
given in the descriptions of specific FEC schemes such as those given in the descriptions of specific FEC schemes such as those
described in the IETF FEC Basic Schemes described in the IETF FEC Basic Schemes specification[RFC5445]
[I-D.ietf-rmt-bb-fec-basic-schemes-revised] specification or in [RFC5445] or in additional FEC Scheme documents that may be defined.
additional FEC Scheme documents that may be defined. As an example, As an example, the format of the "fec_payload_id" format for Small
the format of the "fec_payload_id" format for Small Block, Systematic Block, Systematic codes ("fec_id" = 129) from the FEC Basic Schemes
codes ("fec_id" = 129) from the FEC Basic Schemes specification[RFC5445] is given here:
[I-D.ietf-rmt-bb-fec-basic-schemes-revised] specification is given
here:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_number | | source_block_number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_block_len | encoding_symbol_id | | source_block_len | encoding_symbol_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example: FEC Payload Id Format for "fec_id" = 129 Example: FEC Payload Id Format for 'fec_id' = 129
In this example FEC payload identifier, the "source_block_number", In this example FEC payload identifier, the "source_block_number",
"source_block_len", and "encoding_symbol_id" fields correspond to the "source_block_len", and "encoding_symbol_id" fields correspond to the
"Source Block Number", "Source Block Length, and "Encoding Symbol ID" "Source Block Number", "Source Block Length, and "Encoding Symbol ID"
fields of the FEC Payload ID format for Small Block Systematic FEC fields of the FEC Payload ID format for Small Block Systematic FEC
Schemes identified by a "fec_id" value of 129 as specified by the FEC Schemes identified by a "fec_id" value of 129 as specified by the FEC
Basic Schemes [I-D.ietf-rmt-bb-fec-basic-schemes-revised] document . Basic Schemes specifcation[RFC5445]. The "source_block_number"
The "source_block_number" identifies the coding block's relative identifies the coding block's relative position with a NormObject.
position with a NormObject. Note that, for NormObjects of type Note that, for NormObjects of type "NORM_OBJECT_STREAM", the
"NORM_OBJECT_STREAM", the "source_block_number" may wrap for very "source_block_number" may wrap for very long lived sessions. The
long lived sessions. The "source_block_len" indicates the number of "source_block_len" indicates the number of user data segments in the
user data segments in the identified coding block. Given the identified coding block. Given the "source_block_len" information of
"source_block_len" information of how many symbols of application how many symbols of application data are contained in the block, the
data are contained in the block, the receiver can determine whether receiver can determine whether the attached segment is data or parity
the attached segment is data or parity content and treat it content and treat it appropriately. Some applications may
appropriately. Some applications may dynamically "shorten" code dynamically "shorten" code blocks when the pending information
blocks when the pending information content is not predictable (e.g. content is not predictable (e.g. real-time message streams). In that
real-time message streams). In that case, the "source_block_len" case, the "source_block_len" value given for an "encoding_symbol_id"
value given for an "encoding_symbol_id" that contains FEC parity that contains FEC parity content SHALL take precedence over the
content SHALL take precedence over the "source_block_len" value "source_block_len" value provided for any packets containing source
provided for any packets containing source symbols. Also, the symbols. Also, the "source_block_len" value given for an ordinally
"source_block_len" value given for an ordinally higher higher "encoding_symbol_id" SHALL take precedence over the
"encoding_symbol_id" SHALL take precedence over the
"source_block_len" given for prior encoding symbols. The reason for "source_block_len" given for prior encoding symbols. The reason for
this is that the sender may only know the maximum source block length this is that the sender may only know the maximum source block length
at the time is transmitting source symbols, but then subsequently at the time is transmitting source symbols, but then subsequently
"shorten" the code and then provide that last source symbol and/or "shorten" the code and then provide that last source symbol and/or
encoding symbols with FEC parity content. The "encoding_symbol_id" encoding symbols with FEC parity content. The "encoding_symbol_id"
identifies which specific symbol (segment) within the coding block identifies which specific symbol (segment) within the coding block
the attached payload conveys. Depending upon the value of the the attached payload conveys. Depending upon the value of the
"encoding_symbol_id" and the associated "source_block_len" parameters "encoding_symbol_id" and the associated "source_block_len" parameters
for the block, the symbol (segment) referenced may be a user data or for the block, the symbol (segment) referenced may be a user data or
an FEC parity segment. For systematic codes, encoding symbols an FEC parity segment. For systematic codes, encoding symbols
skipping to change at page 26, line 22 skipping to change at page 26, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 64 | hel = 4 | object_size (msb) | | het = 64 | hel = 4 | object_size (msb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| object_size (lsb) | | object_size (lsb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_instance_id | segment_size | | fec_instance_id | segment_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_max_block_len | fec_num_parity | | fec_max_block_len | fec_num_parity |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example: EXT_FTI Header Extension Format for "fec_id" = 129 Example: EXT_FTI Header Extension Format for 'fec_id' = 129
In this example (for "fec_id" = 129), the "hel" field value is 4. In this example (for "fec_id" = 129), the "hel" field value is 4.
The size of the EXT_FTI header extension may be different for other The size of the EXT_FTI header extension may be different for other
FEC schemes. FEC schemes.
The 48-bit "object_size" serves the purpose described previously. The 48-bit "object_size" serves the purpose described previously.
The "fec_instance_id" corresponds to the "FEC Instance ID" described The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [RFC5052]. In this case, the in the FEC Building Block document [RFC5052]. In this case, the
"fec_instance_id" is a value corresponding to the particular type of "fec_instance_id" is a value corresponding to the particular type of
skipping to change at page 27, line 46 skipping to change at page 27, line 42
segments of the corresponding coding block. The actual segments of the corresponding coding block. The actual
"payload_msg_start", "payload_len" and "payload_offset" values of "payload_msg_start", "payload_len" and "payload_offset" values of
missing data content can be determined upon decoding a FEC coding missing data content can be determined upon decoding a FEC coding
block. Note that these fields do NOT contribute to the value of the block. Note that these fields do NOT contribute to the value of the
"NORM_DATA" "hdr_len" field. These fields are present only when the "NORM_DATA" "hdr_len" field. These fields are present only when the
"flags" portion of the "NORM_DATA" message indicate the transport "flags" portion of the "NORM_DATA" message indicate the transport
object is of type "NORM_OBJECT_STREAM". object is of type "NORM_OBJECT_STREAM".
The "payload_len" value, when non-zero, indicates the length (in The "payload_len" value, when non-zero, indicates the length (in
bytes) of the source content contained in the associated bytes) of the source content contained in the associated
"payload_data" field. When the "payload_len" value is equal to ZERO, "payload_data" field. However, when the "payload_len" value is equal
this indicates that the "payload_msg_start" field should be to ZERO, this indicates that the "payload_msg_start" field should be
alternatively interpreted as a "stream_control_code". The only alternatively interpreted as a "stream_control_code". The only
"stream_control_code" value currently defined is "NORM_STREAM_END = "stream_control_code" value defined is "NORM_STREAM_END = 0". The
0". The "NORM_STREAM_END" code indicates that the sender is "NORM_STREAM_END" code indicates that the sender is terminating
terminating transmission of stream content at the corresponding transmission of stream content at the corresponding position in the
position in the stream and the receiver should not expect content (or stream and the receiver should not expect content (or NACK for any
NACK for any content) following that position in the stream. Future content) following that position in the stream. Future versions of
versions of this specification may define additional stream control this specification may define additional stream control codes if
codes if necessary. Values of "stream_control_code" that are not necessary.
understood SHOULD be ignored.
The "payload_msg_start" field serves one of two exclusive purposes. The "payload_msg_start" field serves one of two exclusive purposes.
When the "payload_len" value is non-zero, the "payload_msg_start" When the "payload_len" value is non-zero, the "payload_msg_start"
field, when also set to a non-zero value, indicates that the field, when also set to a non-zero value, indicates that the
associated "payload_data" content contains an application-defined associated "payload_data" content contains an application-defined
message boundary (start-of-message). When such a message boundary is message boundary (start-of-message). When such a message boundary is
indicated, the first byte of an application-defined message, with indicated, the first byte of an application-defined message, with
respect to the "payload_data" field, will be found at an offset of respect to the "payload_data" field, will be found at an offset of
"payload_msg_start - 1" bytes. Thus, if a "NORM_DATA" payload for a "payload_msg_start - 1" bytes. Thus, if a "NORM_DATA" payload for a
"NORM_OBJECT_STREAM" contains the start of an application message at "NORM_OBJECT_STREAM" contains the start of an application message at
skipping to change at page 36, line 35 skipping to change at page 35, line 45
The "NORM_CMD(SQUELCH)" command is transmitted in response to The "NORM_CMD(SQUELCH)" command is transmitted in response to
outdated or invalid "NORM_NACK" content received by the sender. outdated or invalid "NORM_NACK" content received by the sender.
Invalid "NORM_NACK" content consists of repair requests for Invalid "NORM_NACK" content consists of repair requests for
NormObjects for which the sender is unable or unwilling to provide NormObjects for which the sender is unable or unwilling to provide
repair. This includes repair requests for outdated objects, aborted repair. This includes repair requests for outdated objects, aborted
objects, or those objects which the sender previously transmitted objects, or those objects which the sender previously transmitted
marked with the "NORM_FLAG_UNRELIABLE" flag. This command indicates marked with the "NORM_FLAG_UNRELIABLE" flag. This command indicates
to receivers what content is available for repair, thus serving as a to receivers what content is available for repair, thus serving as a
description of the sender's current "repair window". Receivers SHALL description of the sender's current "repair window". Receivers SHALL
not generate repair requests for content identified as invalid by a NOT generate repair requests for content identified as invalid by a
"NORM_CMD(SQUELCH)". "NORM_CMD(SQUELCH)".
The "NORM_CMD(SQUELCH)" command is sent once per "2*GRTT" at the The "NORM_CMD(SQUELCH)" command is sent once per "2*GRTT" at the
most. The "NORM_CMD(SQUELCH)" advertises the current "repair window" most. The "NORM_CMD(SQUELCH)" advertises the current "repair window"
of the sender by identifying the earliest (lowest) transmission point of the sender by identifying the earliest (lowest) transmission point
for which it will provide repair, along with an encoded list of for which it will provide repair, along with an encoded list of
objects from that point forward that are no longer valid for repair. objects from that point forward that are no longer valid for repair.
This mechanism allows the sender application to cancel or abort This mechanism allows the sender application to cancel or abort
transmission and/or repair of specific previously enqueued objects. transmission and/or repair of specific previously enqueued objects.
The list also contains the identifiers for any objects within the The list also contains the identifiers for any objects within the
repair window that were sent with the "NORM_FLAG_UNRELIABLE" flag repair window that were sent with the "NORM_FLAG_UNRELIABLE" flag
set. In normal conditions, it is expected the "NORM_CMD(SQUELCH)" set. In normal conditions, it is expected the "NORM_CMD(SQUELCH)"
will be needed infrequently, and generally only to provide a will be needed infrequently, and generally only to provide a
reference repair window for receivers who have fallen "out-of-sync" reference repair window for receivers who have fallen "out-of-sync"
with the sender due to extremely poor network conditions. with the sender due to extremely poor network conditions.
The starting point of the invalid NormObject list begins with the The starting point of the invalid NormObject list begins with the
skipping to change at page 38, line 42 skipping to change at page 37, line 51
receiver group greatest round-trip time (GRTT) measurement and to receiver group greatest round-trip time (GRTT) measurement and to
excite the group for congestion control feedback. A baseline NORM excite the group for congestion control feedback. A baseline NORM
congestion control scheme (NORM-CC), based on the TCP-Friendly congestion control scheme (NORM-CC), based on the TCP-Friendly
Multicast Congestion Control (TFMCC) scheme of [RFC4654] is described Multicast Congestion Control (TFMCC) scheme of [RFC4654] is described
in Section 5.5.2 of this document. The "NORM_CMD(CC)" message is in Section 5.5.2 of this document. The "NORM_CMD(CC)" message is
usually transmitted as part of NORM-CC congestion control operation. usually transmitted as part of NORM-CC congestion control operation.
A NORM header extension is defined below to be used with the A NORM header extension is defined below to be used with the
"NORM_CMD(CC)" message to support NORM-CC operation. Different "NORM_CMD(CC)" message to support NORM-CC operation. Different
header extensions may be defined for the "NORM_CMD(CC)" (and/or other header extensions may be defined for the "NORM_CMD(CC)" (and/or other
NORM messages as needed) to support alternative congestion control NORM messages as needed) to support alternative congestion control
schemes in the future. If NORM is operated in a private network with schemes in the future. If NORM is operated in a network where
congestion control operation disabled, the "NORM_CMD(CC)" message is resources are explicitly dedicated to the NORM session and therefore
then used for GRTT measurement only and may optionally be sent less congestion control operation is disabled, the "NORM_CMD(CC)" message
frequently than with congestion control operation. is then used soley for GRTT measurement and may optionally be sent
less frequently than with congestion control operation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence | |version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id | | source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize | | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 4 | reserved | cc_sequence | | flavor = 4 | reserved | cc_sequence |
skipping to change at page 44, line 41 skipping to change at page 44, line 11
field. For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the field. For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the
"cc_rtt" field value to the largest non-CLR/non-PLR RTT it has "cc_rtt" field value to the largest non-CLR/non-PLR RTT it has
measured from receivers for the current feedback round. measured from receivers for the current feedback round.
The "cc_loss" field represents the receiver's current packet loss The "cc_loss" field represents the receiver's current packet loss
fraction estimate for the indicated source. The loss fraction is a fraction estimate for the indicated source. The loss fraction is a
value from 0.0 to 1.0 corresponding to a range of zero to 100 percent value from 0.0 to 1.0 corresponding to a range of zero to 100 percent
packet loss. The 16-bit "cc_loss" value is calculated by the packet loss. The 16-bit "cc_loss" value is calculated by the
following formula: following formula:
"cc_loss" = decimal_loss_fraction * 65535.0 "cc_loss" = floor(decimal_loss_fraction * 65535.0)
For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the For "NORM_CMD(REPAIR_ADV)" messages, the sender SHALL set the
"cc_loss" field value to the largest non-CLR/non-PLR loss estimate it "cc_loss" field value to the largest non-CLR/non-PLR loss estimate it
has received from receivers for the current feedback round. has received from receivers for the current feedback round.
The "cc_rate" field represents the receivers current local congestion The "cc_rate" field represents the receivers current local congestion
control rate. During "slow start", when the receiver has detected no control rate. During "slow start", when the receiver has detected no
loss, this value is set to twice the actual rate it has measured from loss, this value is set to twice the actual rate it has measured from
the corresponding sender and the "NORM_FLAG_CC_START" is set in the the corresponding sender and the "NORM_FLAG_CC_START" is set in the
"cc_flags' field. Otherwise, the receiver calculates a congestion "cc_flags' field. Otherwise, the receiver calculates a congestion
skipping to change at page 58, line 12 skipping to change at page 57, line 12
each of these aspects that need to be addressed for successful, each of these aspects that need to be addressed for successful,
efficient, robust, and scalable NORM protocol operation. efficient, robust, and scalable NORM protocol operation.
5.1. Sender Initialization and Transmission 5.1. Sender Initialization and Transmission
Upon startup, the NORM sender immediately begins sending Upon startup, the NORM sender immediately begins sending
"NORM_CMD(CC)" messages to collect round trip timing and other "NORM_CMD(CC)" messages to collect round trip timing and other
information from the potential group. If NORM-CC congestion control information from the potential group. If NORM-CC congestion control
operation is enabled, the NORM-CC Rate header extension MUST be operation is enabled, the NORM-CC Rate header extension MUST be
included in these messages. Congestion control operation SHALL be included in these messages. Congestion control operation SHALL be
observed at all times when operating in the general Internet. Even observed at all times when not operating using dedicated resources,
if congestion control operation is disabled at the sender, it may be like in the general Internet. Even if congestion control operation
desirable to use the "NORM_CMD(CC)" messaging to collect feedback is disabled at the sender, it may be desirable to use the
from the group using the baseline NORM-CC feedback mechanisms. This "NORM_CMD(CC)" messaging to collect feedback from the group using the
proactive feedback collection can be used to establish a GRTT baseline NORM-CC feedback mechanisms. This proactive feedback
estimate prior to data transmission and potential NACK operation. collection can be used to establish a GRTT estimate prior to data
transmission and potential NACK operation.
In some cases, applications may wish for the sender to also proceed In some cases, applications may wish for the sender to also proceed
with data transmission immediately. In other cases, the sender may with data transmission immediately. In other cases, the sender may
wish to defer data transmission until it has received some feedback wish to defer data transmission until it has received some feedback
or request from the receiver set indicating that receivers are indeed or request from the receiver set indicating that receivers are indeed
present. Note, in some applications (e.g., web push), this present. Note, in some applications (e.g., web push), this
indication may come out-of-band with respect to the multicast session indication may come out-of-band with respect to the multicast session
via other means. As noted, the periodic transmission of via other means. As noted, the periodic transmission of
"NORM_CMD(CC)" messages may precede actual data transmission in order "NORM_CMD(CC)" messages may precede actual data transmission in order
to have an initial GRTT estimate. to have an initial GRTT estimate.
skipping to change at page 61, line 7 skipping to change at page 60, line 7
advertised in the "grtt" field of NORM sender messages. A minimum advertised in the "grtt" field of NORM sender messages. A minimum
""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver ""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver
SHOULD reset this inactivity timer and repeat NACK initiation upon SHOULD reset this inactivity timer and repeat NACK initiation upon
timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon
the application's need for persistence by its receivers. It is also the application's need for persistence by its receivers. It is also
important that receivers rescale the ""T_inactivity"" timeout as the important that receivers rescale the ""T_inactivity"" timeout as the
sender's advertised GRTT changes. sender's advertised GRTT changes.
The NACKing procedure begins with a random backoff timeout. The The NACKing procedure begins with a random backoff timeout. The
duration of the backoff timeout is chosen using the "RandomBackoff" duration of the backoff timeout is chosen using the "RandomBackoff"
algorithm described in the Multicast NACK Building Block document algorithm described in the Multicast NACK Building Block
[RFC5401] using ("Ksender*GRTTsender") for the "maxTime" parameter document[RFC5401] using ("Ksender*GRTTsender") for the "maxTime"
and the sender advertised group size ("GSIZEsender") as the parameter and the sender advertised group size ("GSIZEsender") as the
"groupSize" parameter. NORM senders provide values for "GRTTsender", "groupSize" parameter. NORM senders provide values for "GRTTsender",
"Ksender" and "GSIZEsender" via the "grtt", "backoff", and "gsize" "Ksender" and "GSIZEsender" via the "grtt", "backoff", and "gsize"
fields of transmitted messages. The "GRTTsender" value is determined fields of transmitted messages. The "GRTTsender" value is determined
by the sender based on feedback it has received from the group while by the sender based on feedback it has received from the group while
the "Ksender" and "GSIZEsender" values may determined by application the "Ksender" and "GSIZEsender" values may determined by application
requirements and expectations or ancillary information. The backoff requirements and expectations or ancillary information. The backoff
factor ""Ksender"" MUST be greater than "one" to provide for factor ""Ksender"" MUST be greater than "one" to provide for
effective feedback suppression. A value of "K = 4" is RECOMMENDED effective feedback suppression. A value of "K = 4" is RECOMMENDED
for the Any Source Multicast (ASM) model while a value of "K = 6" is for the Any Source Multicast (ASM) model while a value of "K = 6" is
RECOMMENDED for Single Source Multicast (SSM) operation. RECOMMENDED for Single Source Multicast (SSM) operation.
skipping to change at page 67, line 42 skipping to change at page 66, line 42
5.5.2. NORM Congestion Control Operation 5.5.2. NORM Congestion Control Operation
This section describes baseline congestion control operation for the This section describes baseline congestion control operation for the
NORM protocol (NORM-CC). The supporting NORM message formats and NORM protocol (NORM-CC). The supporting NORM message formats and
approach described here are an adaptation of the equation-based TCP- approach described here are an adaptation of the equation-based TCP-
Friendly Multicast Congestion Control (TFMCC) approach described in Friendly Multicast Congestion Control (TFMCC) approach described in
[RFC4654]. This congestion control scheme is REQUIRED for operation [RFC4654]. This congestion control scheme is REQUIRED for operation
within the general Internet unless the NORM implementation is adapted within the general Internet unless the NORM implementation is adapted
to use another IETF-sanctioned reliable multicast congestion control to use another IETF-sanctioned reliable multicast congestion control
mechanism (e.g., PGMCC [PgmccPaper]). With this TFMCC-based mechanism. With this TFMCC-based approach, the transmissions of NORM
approach, the transmissions of NORM senders are controlled in a rate- senders are controlled in a rate-based manner as opposed to window-
based manner as opposed to window-based congestion control algorithms based congestion control algorithms as in TCP. However, it is
as in TCP. However, it is possible that the NORM protocol message possible that the NORM protocol message set may alternatively be used
set may alternatively be used to support a window-based multicast to support a window-based multicast congestion control scheme such as
congestion control scheme such as PGMCC. The details of that PGMCC. The details of that alternative may be described separately
alternative may be described separately or in a future revision of or in a future revision of this document. In either case (rate-based
this document. In either case (rate-based TFMCC or window-based TFMCC or window-based PGMCC), successful control of sender
PGMCC), successful control of sender transmission depends upon transmission depends upon collection of sender-to-receiver packet
collection of sender-to-receiver packet loss estimates and RTTs to loss estimates and RTTs to identify the congestion control bottleneck
identify the congestion control bottleneck path(s) within the path(s) within the multicast topology and adjust the sender rate
multicast topology and adjust the sender rate accordingly. The accordingly. The receiver with loss and RTT estimates that
receiver with loss and RTT estimates that correspond to the lowest correspond to the lowest resulting calculated transmission rate is
resulting calculated transmission rate is identified as the "current identified as the "current limiting receiver" (CLR). In the case of
limiting receiver" (CLR). In the case of a tie (where candidate CLRs a tie (where candidate CLRs are within 10% of the same calculated
are within 10% of the same calculated rate), the receiver with the rate), the receiver with the largest RTT value SHOULD be designated
largest RTT value SHOULD be designated as the CLR. as the CLR.
As described in [TcpModel], a steady-state sender transmission rate, As described in [TcpModel], a steady-state sender transmission rate,
to be "friendly" with competing TCP flows can be calculated as: to be "friendly" with competing TCP flows can be calculated as:
S S
Rsender = ---------------------------------------------------------- Rsender = ----------------------------------------------------------
tRTT*(sqrt((2/3)*p) + 12*sqrt((3/8)*p) * p * (1 + 32*(p^2))) tRTT*(sqrt((2/3)*p) + 12*sqrt((3/8)*p) * p * (1 + 32*(p^2)))
where where
"S" = nominal transmitted packet size. (In NORM, the "nominal" "S" = nominal transmitted packet size. (In NORM, the "nominal"
skipping to change at page 68, line 43 skipping to change at page 67, line 43
transmissions and serve several purposes: transmissions and serve several purposes:
1. Stimulate explicit feedback from the general receiver set to 1. Stimulate explicit feedback from the general receiver set to
collect congestion control information. collect congestion control information.
2. Communicate state to the receiver set on the sender's current 2. Communicate state to the receiver set on the sender's current
congestion control status including details of the CLR. congestion control status including details of the CLR.
3. Initiate rapid (immediate) feedback from the CLR in order to 3. Initiate rapid (immediate) feedback from the CLR in order to
closely track the dynamics of congestion control for that current closely track the dynamics of congestion control for that current
worst path in the group multicast topology. worst path in the group multicast topology.
The format of the "NORM_CMD(CC)" message is describe in Section 4.2.3 The format of the "NORM_CMD(CC)" message is described in
of this document. The "NORM_CMD(CC)" message contains information to Section 4.2.3 of this document. The "NORM_CMD(CC)" message contains
allow measurement of RTTs, to inform the group of the congestion information to allow measurement of RTTs, to inform the group of the
control CLR, and to provide feedback of individual RTT measurements congestion control CLR, and to provide feedback of individual RTT
to the receivers in the group. The "NORM_CMD(CC)" also provides for measurements to the receivers in the group. The "NORM_CMD(CC)" also
exciting feedback from OPTIONAL "potential limiting receiver" (PLR) provides for exciting feedback from OPTIONAL "potential limiting
nodes that may be determined administratively or possibly receiver" (PLR) nodes that may be determined administratively or
algorithmically based on congestion control feedback. PLR nodes are possibly algorithmically based on congestion control feedback. PLR
receivers that have been identified to have potential for (perhaps nodes are receivers that have been identified to have potential for
soon) becoming the CLR and thus immediate, up-to-date feedback is (perhaps soon) becoming the CLR and thus immediate, up-to-date
beneficial for congestion control performance. The details of PLR feedback is beneficial for congestion control performance. The PLR
selection are not discussed in this document. list may be populated with a small number of receivers the sender
identifies as approaching the CLR loss and delay conditions based on
feedback from the group.
5.5.2.1. NORM_CMD(CC) Transmission 5.5.2.1. NORM_CMD(CC) Transmission
The "NORM_CMD(CC)" message is transmitted periodically by the sender The "NORM_CMD(CC)" message is transmitted periodically by the sender
along with its normal data transmission. Note that the repeated along with its normal data transmission. Note that the repeated
transmission of "NORM_CMD(CC)" messages may be initiated some time transmission of "NORM_CMD(CC)" messages may be initiated some time
before transmission of user data content at session startup. This before transmission of user data content at session startup. This
may be done to collect some estimation of the current state of the may be done to collect some estimation of the current state of the
multicast topology with respect to group and individual RTT and multicast topology with respect to group and individual RTT and
congestion control state. congestion control state.
skipping to change at page 77, line 46 skipping to change at page 76, line 46
RECOMMENDED for use as the group size estimate. RECOMMENDED for use as the group size estimate.
It is possible that group size may be algorithmically approximated It is possible that group size may be algorithmically approximated
from the volume of congestion control feedback messages which follow from the volume of congestion control feedback messages which follow
the exponentially weighted random backoff. However, the the exponentially weighted random backoff. However, the
specification of such an algorithm is currently beyond the scope of specification of such an algorithm is currently beyond the scope of
this document. this document.
6. Security Considerations 6. Security Considerations
The same security considerations that apply to the NORM, TFMCC, and The same security considerations that apply to the Multicast
FEC Building Blocks also apply to the NORM protocol. In addition to NACK[RFC5401], TFMCC[RFC4654], and FEC[RFC5052] Building Blocks also
vulnerabilities that any IP and IP multicast protocol implementation apply to the NORM protocol. In addition to vulnerabilities that any
may be generally subject to, the NACK-based feedback of NORM may be IP and IP multicast protocol implementation may be generally subject
exploited by replay attacks which force the NORM sender to to, the NACK-based feedback of NORM may be exploited by replay
unnecessarily transmit repair information. This MAY be addressed by attacks which force the NORM sender to unnecessarily transmit repair
network layer IP security implementations that guard against this information. This MAY be addressed by network layer IP security
potential security exploitation. The NORM protocol is compatible implementations that guard against this potential security
with the use of the IP security (IPsec) architecture described in exploitation. The NORM protocol is compatible with the use of IP
[RFC4301] and the IPsec Encapsulating Security Payload (ESP) protocol security (IPsec)[RFC4301] and the IPsec Encapsulating Security
or Authentication Header (AF) extension MAY be used to secure IP Payload (ESP) protocol or Authentication Header (AF) extension MAY be
packets transmitted by NORM participants. used to secure IP packets transmitted by NORM participants.
Alternatively, a header extension may be applied to the NORM protocol Alternatively, a header extension may be applied to the NORM protocol
to provide authentication of NORM messages. For this purpose the to provide authentication of NORM messages. For this purpose the
"EXT_AUTH" header extension (HET = 1) is defined. The format of this "EXT_AUTH" header extension (HET = 1) is defined. The format of this
header extension and its processing is outside the scope 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 document and is to be communicated out-of-band as part of the session
description. It is possible that an EXT_AUTH implementation of MAY description. It is possible that an EXT_AUTH implementation of MAY
also provide for encryption of NORM message payloads as well as also provide for encryption of NORM message payloads as well as
authentication. The use of this approach as compared to IPsec can authentication. The use of this approach as compared to IPsec can
allow for header compression techniques to be applied jointly to IP allow for header compression techniques to be applied jointly to IP
skipping to change at page 79, line 8 skipping to change at page 78, line 8
protection against possible replay of other receiver messages in ASM protection against possible replay of other receiver messages in ASM
operation as well. For example, a receiver could be suppressed from operation as well. For example, a receiver could be suppressed from
providing NACK or congestion control feedback by replay of certain providing NACK or congestion control feedback by replay of certain
receiver messages. For these reasons, authentication of NORM receiver messages. For these reasons, authentication of NORM
messages (e.g., via IPsec) is RECOMMENDED for protection against messages (e.g., via IPsec) is RECOMMENDED for protection against
similar attacks that might use fabricated messages. Also, encryption similar attacks that might use fabricated messages. Also, encryption
of messages to provide confidentiality of application data and of messages to provide confidentiality of application data and
protect privacy of users MAY also be applied using IPsec or similar protect privacy of users MAY also be applied using IPsec or similar
mechanisms. When any such cryptographic measures are used, it is mechanisms. When any such cryptographic measures are used, it is
RECOMMENDED that an approach such as described in the Group Domain of RECOMMENDED that an approach such as described in the Group Domain of
Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY) Interpretation (GDOI)[RFC3547], Multimedia Internet KEYing
[RFC3830] or Group Secure Association Key Management Protocol (MIKEY)[RFC3830] or Group Secure Association Key Management Protocol
(GSAKMP) [RFC4535] specifications for automated key management is (GSAKMP) [RFC4535] specifications for automated key management is
applied. applied.
It is also important to note that while NORM does leverage FEC-based It is also important to note that while NORM does leverage FEC-based
repair for scalability, this alone does not guarantee integrity of repair for scalability, this alone does not guarantee integrity of
received data. Application-level integrity-checking of data content received data. Application-level integrity-checking of data content
is highly RECOMMENDED. is highly RECOMMENDED.
6.1. Baseline Secure NORM Operation 6.1. Baseline Secure NORM Operation
This section describes a baseline mode of secure NORM protocol This section describes a baseline mode of secure NORM protocol
operation based on application of the IPsec security protocol. This operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to NORM secure mode of operation. However, additional approaches to NORM
security, including other forms of IPsec application, MAY be security, including other forms of IPsec application, MAY be
specified in the future. For example, the use of the EXT_AUTH header specified in the future. For example, the use of the EXT_AUTH header
extension could enable NORM-specific authentication or security extension could enable NORM-specific authentication or security
encapsulation headers similar to those of IPsec to be specified and encapsulation headers similar to those of IPsec to be specified and
inserted into the NORM protocol message headers. This would allow inserted into the NORM protocol message headers. This would allow
header compression techniques to be applied to IP and NORM protocol header compression techniques to be applied to IP and NORM protocol
headers when needed in a similar fashion to that of RTP [RFC1889] and headers when needed in a similar fashion to that of RTP[RFC3550] and
as preserved in the specification for Secure Real Time Protocol as preserved in the specification for Secure Real Time Protocol
(SRTP) [RFC3711]. (SRTP) [RFC3711].
The baseline approach described is applicable to NORM operation The baseline approach described is applicable to NORM operation
configured for SSM (or SSM-like) operation where there is a single configured for SSM (or SSM-like) operation where there is a single
sender and the receivers are providing unicast feedback. This form sender and the receivers are providing unicast feedback. This form
of NORM operation allows for IPsec to be used with a manageable of NORM operation allows for IPsec to be used with a manageable
number of security associations (SA). number of security associations (SA).
6.1.1. IPsec Approach 6.1.1. IPsec Approach
skipping to change at page 82, line 20 skipping to change at page 81, line 20
the following IPsec capabilities are required. the following IPsec capabilities are required.
6.1.2.1. Selectors 6.1.2.1. Selectors
The implementation MUST be able to use the source address, The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD. selectors in the SPD.
6.1.2.2. Mode 6.1.2.2. Mode
IPsec in transport mode MUST be supported. The use of IPsec IPsec in transport mode MUST be supported. The use of IPsec[RFC4301]
[RFC4301] processing for secure NORM traffic SHOULD also be REQUIRED processing for secure NORM traffic SHOULD also be REQUIRED such that
such that unauthenticated packets are not received by the NORM unauthenticated packets are not received by the NORM protocol
protocol implementation . implementation .
6.1.2.3. Key Management 6.1.2.3. Key Management
An automated key management scheme for group key distribution and An automated key management scheme for group key distribution and
rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830] rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830]
SHOULD be used. Relatively short-lived NORM sessions MAY be able to SHOULD be used. Relatively short-lived NORM sessions MAY be able to
use Manual Keying with a single, preplaced key, particularly if use Manual Keying with a single, preplaced key, particularly if
Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec
implementation used. It should also be noted that it may be possible implementation used. It should also be noted that it may be possible
for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be
skipping to change at page 83, line 40 skipping to change at page 82, line 40
"ietf:rmt:norm:extensions" "ietf:rmt:norm:extensions"
These values represent extended header fields that allow the protocol These values represent extended header fields that allow the protocol
functionality to be expanded to include additional optional features functionality to be expanded to include additional optional features
and operating modes. The values that can be assigned within the and operating modes. The values that can be assigned within the
"ietf:rmt:norm:extension" name-space are numeric indexes in the range "ietf:rmt:norm:extension" name-space are numeric indexes in the range
{0, 255}, boundaries included. Values in the range {0,127} indicate {0, 255}, boundaries included. Values in the range {0,127} indicate
variable length extended header fields while values in the range variable length extended header fields while values in the range
{128,255} indicate extension of a fixed 4-byte length. NORM header {128,255} indicate extension of a fixed 4-byte length. NORM header
extension identifier value assignment requests are granted on a extension identifier value assignment requests are granted on a
"Specification Required" basis as defined in [RFC2434]. Additional "Specification Required" basis as defined in [RFC5226]. Additional
header extension specifications MUST include a description of header extension specifications MUST include a description of
protocol actions to be taken when the extended header is encountered protocol actions to be taken when the extended header is encountered
by a protocol implementation not supporting that specific option. by a protocol implementation not supporting that specific option.
For example, it may be possible for protocol implementations to For example, it may be possible for protocol implementations to
ignore unknown header extensions in many cases. ignore unknown header extensions in many cases.
This specification registers the following NORM Header Extension This specification registers the following NORM Header Extension
types in namespace "ietf:rmt:norm:extensions": types in namespace "ietf:rmt:norm:extensions":
+-------+------------+--------------------+ +-------+------------+--------------------+
skipping to change at page 85, line 41 skipping to change at page 84, line 41
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Multicast Negative-Acknowledgment (NACK) Building "Multicast Negative-Acknowledgment (NACK) Building
Blocks", RFC 5401, November 2008. Blocks", RFC 5401, November 2008.
11.2. Informative References 11.2. Informative References
[FecHybrid] [FecHybrid]
Gossink, D. and J. Macker, "Reliable Multicast and Gossink, D. and J. Macker, "Reliable Multicast and
Integrated Parity Retransmission with Channel Estimation", Integrated Parity Retransmission with Channel Estimation",
IEEE Globecomm , 1998. IEEE Globecomm , 1998.
[I-D.ietf-rmt-bb-fec-basic-schemes-revised]
Watson, M., "Basic Forward Error Correction (FEC)
Schemes", draft-ietf-rmt-bb-fec-basic-schemes-revised-06
(work in progress), October 2008.
[McastFeedback] [McastFeedback]
Nonnenmacher, J. and E. Biersack, "Optimal Multicast Nonnenmacher, J. and E. Biersack, "Optimal Multicast
Feedback", IEEE INFOCOM, p. 964, March/April 1998. Feedback", IEEE INFOCOM, p. 964, March/April 1998.
[MdpToolkit] [MdpToolkit]
Macker, J. and B. Adamson, "The Multicast Dissemination Macker, J. and B. Adamson, "The Multicast Dissemination
Protocol (MDP) Toolkit", Proc. IEEE MILCOM , October 1999. Protocol (MDP) Toolkit", Proc. IEEE MILCOM , October 1999.
[Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based [Mdpcc] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based
Mechanism for NACK-Oriented Reliable Multicast Congestion Mechanism for NACK-Oriented Reliable Multicast Congestion
skipping to change at page 87, line 5 skipping to change at page 85, line 44
[NormFeedback] [NormFeedback]
Adamson, B. and J. Macker, "Quantitative Prediction of Adamson, B. and J. Macker, "Quantitative Prediction of
NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE NACK-Oriented Reliable Multicast (NORM) Feedback", IEEE
MILCOM , October 2002. MILCOM , October 2002.
[PgmccPaper] [PgmccPaper]
Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast Rizzo, L., "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", ACM SIGCOMM , August 2000. Congestion Control Scheme", ACM SIGCOMM , August 2000.
[RFC1889] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", RFC 1889, January 1996.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998. Application Protocols", RFC 2357, June 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M.,
Floyd, S., and M. Luby, "Reliable Multicast Transport Floyd, S., and M. Luby, "Reliable Multicast Transport
Building Blocks for One-to-Many Bulk-Data Transfer", Building Blocks for One-to-Many Bulk-Data Transfer",
RFC 3048, January 2001. RFC 3048, January 2001.
[RFC3269] Kermode, R. and L. Vicisano, "Author Guidelines for
Reliable Multicast Transport (RMT) Building Blocks and
Protocol Instantiation documents", RFC 3269, April 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002. (FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 88, line 6 skipping to change at page 86, line 45
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast [RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification", Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006. RFC 4654, August 2006.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, March 2009.
[RmComparison] [RmComparison]
Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Pingali, S., Towsley, D., and J. Kurose, "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Sender-Initiated and Receiver-Initiated Reliable Multicast
Protocols", Proc. INFOCOMM, San Francisco CA, Protocols", Proc. INFOCOMM, San Francisco CA,
October 1993. October 1993.
[TcpModel] [TcpModel]
Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical "Modeling TCP Throughput: A Simple Model and its Empirical
Validation", ACM SIGCOMM , 1998. Validation", ACM SIGCOMM , 1998.
skipping to change at page 89, line 4 skipping to change at page 87, line 40
Email: cabo@tzi.org Email: cabo@tzi.org
Mark Handley Mark Handley
University College London University College London
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
UK UK
Email: M.Handley@cs.ucl.ac.uk Email: M.Handley@cs.ucl.ac.uk
Joe Macker Joe Macker
Naval Research Laboratory Naval Research Laboratory
Washington, DC 20375 Washington, DC 20375
USA USA
Email: macker@itd.nrl.navy.mil Email: macker@itd.nrl.navy.mil
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 43 change blocks. 
214 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/