draft-ietf-rmt-pi-norm-revised-00.txt   draft-ietf-rmt-pi-norm-revised-01.txt 
Reliable Multicast Transport (RMT) B. Adamson Reliable Multicast Transport (RMT) B. Adamson
Working Group NRL Working Group NRL
Internet-Draft C. Bormann Internet-Draft C. Bormann
Expires: 17 March 2006 Universitaet Bremen TZI Expires: 02 September 2006 Universitaet Bremen TZI
M. Handley M. Handley
UCL UCL
J. Macker J. Macker
NRL NRL
October 2005 March 2006
Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
draft-ietf-rmt-pi-norm-revised-00 draft-ietf-rmt-pi-norm-revised-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 17, 2006. This Internet-Draft will expire on March 17, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
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" mechanisms to allow for operation with minimal "a priori"
skipping to change at page 3, line 21 skipping to change at page 3, line 21
2. Architecture Definition . . . . . . . . . . . . . . . . . . . . . 8 2. Architecture Definition . . . . . . . . . . . . . . . . . . . . . 8
2.1. Protocol Operation Overview. . . . . . . . . . . . . . . . . . 10 2.1. Protocol Operation Overview. . . . . . . . . . . . . . . . . . 10
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . . . 11 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . . . 11
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 12
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . . . 12 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . . . 12
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. NORM Common Message Header and Extensions. . . . . . . . . . . 15 4.1. NORM Common Message Header and Extensions. . . . . . . . . . . 15
4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . . . . 17
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . . . . 17
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . . . . 27 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . . . . 27
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . . . . 28 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . . . . 29
4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . . . . 47 4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . . . . 47
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . . . . 47 4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . . . . 47
4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . . . . . . 54 4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . . . . . . 54
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . . . 56 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . . . 56
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . . . . 56 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . . . . 56
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . . . 56 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . . . 56
5.1. Sender Initialization and Transmission . . . . . . . . . . . . 58 5.1. Sender Initialization and Transmission . . . . . . . . . . . . 58
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . . . . 59 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . . . . 59
5.2. Receiver Initialization and Reception. . . . . . . . . . . . . 60 5.2. Receiver Initialization and Reception. . . . . . . . . . . . . 60
5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . . . . 60 5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . . . . 60
skipping to change at page 3, line 44 skipping to change at page 3, line 44
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . . . . 64 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . . . . 64
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . . . . 65 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . . . . 65
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . . . . . . 66 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . . . . . . 66
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . . . 66 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . . . 66
5.5.1. Greatest Round-trip Time Collection . . . . . . . . . . . . 66 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . . . . 66
5.5.2. NORM Congestion Control Operation . . . . . . . . . . . . . 67 5.5.2. NORM Congestion Control Operation . . . . . . . . . . . . . 67
5.5.3. NORM Positive Acknowledgment Procedure. . . . . . . . . . . 76 5.5.3. NORM Positive Acknowledgment Procedure. . . . . . . . . . . 76
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . . . . 79 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . . . . 79
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 79
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 80
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 80 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 81
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 80 9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 81
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 82
10.1. Normative References. . . . . . . . . . . . . . . . . . . . . 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
10.2. Informative References. . . . . . . . . . . . . . . . . . . . 81 11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 82
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 84 11.2. Informative References. . . . . . . . . . . . . . . . . . . . 82
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 85 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 85
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 86
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 4, line 38 skipping to change at page 4, line 38
delays. delays.
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 RFC 3269 [1]. The key words "MUST", "MUST guidelines provided in RFC 3269 [1]. The key words "MUST", "MUST
NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in BCP 14, RFC 2119 [2]. interpreted as described in BCP 14, RFC 2119 [2].
Statement of Intent Statement of Intent
This memo contains part of the definitions necessary to fully specify This memo contains the definitions necessary to fully specify a
a Reliable Multicast Transport protocol in accordance with RFC 2357. Reliable Multicast Transport protocol in accordance with RFC 2357.
As per RFC 2357, the use of any reliable multicast protocol in the RFC3940 [8] contained a previous description of the NORM Protocol
Internet requires an adequate congestion control scheme. specification described in this document. RF3940 was published in
the "Experimental" category. It was the stated intent of the RMT
working group to re-submit this specifications as an IETF Proposed
Standard in due course.
While waiting for such a scheme to be available, or for an existing This Proposed Standard specification is thus based on RFC3940 [8] and
scheme to be proven adequate, the Reliable Multicast Transport has been updated according to accumulated experience and growing
working group (RMT) publishes this Request for Comments in the protocol maturity since the publication of RFC3940. Said experience
"Experimental" category. applies both to this specification itself and to congestion control
strategies related to the use of this specification.
It is the intent of RMT to re-submit this specification as an IETF The differences between RFC3940 [8] and this document are listed in
Proposed Standard as soon as the above condition is met. Section 9.
1.1. NORM Delivery Service Model 1.1. NORM Delivery Service Model
A NORM protocol instance (NormSession) is defined within the context A NORM protocol instance (NormSession) is defined within the context
of participants communicating connectionless (e.g., Internet Protocol of participants communicating connectionless (e.g., Internet Protocol
(IP) or User Datagram Protocol (UDP)) packets over a network using (IP) or User Datagram Protocol (UDP)) packets over a network using
pre-determined addresses and host port numbers. Generally, the pre-determined addresses and host port numbers. Generally, the
participants exchange packets using an IP multicast group address, participants exchange packets using an IP multicast group address,
but unicast transport may also be established or applied as an but unicast transport may also be established or applied as an
adjunct to multicast delivery. In the case of multicast, the adjunct to multicast delivery. In the case of multicast, the
participating NormNodes will communicate using a common IP multicast participating NormNodes will communicate using a common IP multicast
group address and port number that has been chosen via means outside group address and port number that has been chosen via means outside
the context of the given NormSession. Other IETF data format and the context of the given NormSession. Other IETF data format and
protocol standards exist that may be applied to describe and convey protocol standards exist that may be applied to describe and convey
the required "a priori" information for a specific NormSession (e.g., the required "a priori" information for a specific NormSession (e.g.,
Session Description Protocol (SDP) [7], Session Announcement Protocol Session Description Protocol (SDP) [9], Session Announcement Protocol
(SAP) [8], etc.). (SAP) [10], etc.).
The NORM protocol design is principally driven by the assumption of a The NORM protocol design is principally driven by the assumption of a
single sender transmitting bulk data content to a group of receivers. single sender transmitting bulk data content to a group of receivers.
However, the protocol MAY operate with multiple senders within the However, the protocol MAY operate with multiple senders within the
context of a single NormSession. In initial implementations of this context of a single NormSession. In initial implementations of this
protocol, it is anticipated that multiple senders will transmit protocol, it is anticipated that multiple senders will transmit
independent of one another and receivers will maintain state as independent of one another and receivers will maintain state as
necessary for each sender. However, in future versions of NORM, it necessary for each sender. However, in future versions of NORM, it
is possible that some aspects of protocol operation (e.g., round-trip is possible that some aspects of protocol operation (e.g., round-trip
time collection) may provide for alternate modes allowing more time collection) may provide for alternate modes allowing more
skipping to change at page 7, line 17 skipping to change at page 7, line 19
provide for repair transmission of data and/or FEC content in provide for repair transmission of data and/or FEC content in
response to NACK messages received from the receiver group. response to NACK messages received from the receiver group.
Mechanisms for "out-of-band" information and other transport control Mechanisms for "out-of-band" information and other transport control
mechanisms are specified for use by applications to form complete mechanisms are specified for use by applications to form complete
reliable multicast solutions for different purposes. reliable multicast solutions for different purposes.
1.2. NORM Scalability 1.2. NORM Scalability
Group communication scalability requirements lead to adaptation of Group communication scalability requirements lead to adaptation of
negative acknowledgment (NACK) based protocol schemes when feedback negative acknowledgment (NACK) based protocol schemes when feedback
for reliability is required [9]. NORM is a protocol centered around for reliability is required [11]. NORM is a protocol centered around
the use of selective NACKs to request repairs of missing data. NORM the use of selective NACKs to request repairs of missing data. NORM
provides for the use of packet-level forward error correction (FEC) provides for the use of packet-level forward error correction (FEC)
techniques for efficient multicast repair and optional proactive techniques for efficient multicast repair and optional proactive
transmission robustness [10]. FEC-based repair can be used to transmission robustness [12]. FEC-based repair can be used to
greatly reduce the quantity of reliable multicast repair requests and greatly reduce the quantity of reliable multicast repair requests and
repair transmissions [11] in a NACK-oriented protocol. The principal repair transmissions [13] in a NACK-oriented protocol. The principal
factor in NORM scalability is the volume of feedback traffic factor in NORM scalability is the volume of feedback traffic
generated by the receiver set to facilitate reliability and generated by the receiver set to facilitate reliability and
congestion control. NORM uses probabilistic suppression of redundant congestion control. NORM uses probabilistic suppression of redundant
feedback based on exponentially distributed random backoff timers. feedback based on exponentially distributed random backoff timers.
The performance of this type of suppression relative to other The performance of this type of suppression relative to other
techniques is described in [12]. NORM dynamically measures the techniques is described in [14]. NORM dynamically measures the
group's roundtrip timing status to set its suppression and other group's roundtrip timing status to set its suppression and other
protocol timers. This allows NORM to scale well while maintaining protocol timers. This allows NORM to scale well while maintaining
reliable data delivery transport with low latency relative to the reliable data delivery transport with low latency relative to the
network topology over which it is operating. network topology over which it is operating.
Feedback messages can be either multicast to the group at large or Feedback messages can be either multicast to the group at large or
sent via unicast routing to the sender. In the case of unicast sent via unicast routing to the sender. In the case of unicast
feedback, the sender "advertises" the feedback state to the group to feedback, the sender "advertises" the feedback state to the group to
facilitate feedback suppression. In typical Internet environments, facilitate feedback suppression. In typical Internet environments,
it is expected that the NORM protocol will readily scale to group it is expected that the NORM protocol will readily scale to group
sizes on the order of tens of thousands of receivers. A study of the sizes on the order of tens of thousands of receivers. A study of the
quantity of feedback for this type of protocol is described in [13]. quantity of feedback for this type of protocol is described in [15].
NORM is able to operate with a smaller amount of feedback than a NORM is able to operate with a smaller amount of feedback than a
single TCP connection, even with relatively large numbers of single TCP connection, even with relatively large numbers of
receivers. Thus, depending upon the network topology, it is possible receivers. Thus, depending upon the network topology, it is possible
that NORM may scale to larger group sizes. With respect to computer that NORM may scale to larger group sizes. With respect to computer
resource usage, the NORM protocol does _not_ require that state be resource usage, the NORM protocol does _not_ require that state be
kept on all receivers in the group. NORM senders maintain state only kept on all receivers in the group. NORM senders maintain state only
for receivers providing explicit congestion control feedback. NORM for receivers providing explicit congestion control feedback. NORM
receivers must maintain state for each active sender. This may receivers must maintain state for each active sender. This may
constrain the number of simultaneous senders in some uses of NORM. constrain the number of simultaneous senders 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 NORM Building Block [4] and the RMT FEC Building Block [5] to the RMT NORM Building Block [4], the RMT FEC Building Block [5],
also apply to the NORM protocol. and the RMT TCP-Friendly Multicast Congestion Control (TFMCC)
Building Block [6], 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 RFC 1112 [3], but SHALL also be capable of (ASM) model defined in RFC 1112 [3], but SHALL also be capable of
scalable operation in asymmetric topologies such as Source Specific scalable operation in asymmetric topologies such as Source Specific
Multicast (SSM) [14] where there may only be unicast routing service Multicast (SSM) [16] where there may only be unicast routing service
from the receivers to the sender(s). from the receivers to the 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
skipping to change at page 10, line 25 skipping to change at page 10, line 26
segments/symbols for the bulk data/file or stream NormObjects being segments/symbols for the bulk data/file or stream NormObjects being
transferred. By default, redundant FEC symbols are sent only in transferred. By default, redundant FEC symbols are sent only in
response to receiver repair requests (NACKs) and thus normally little response to receiver repair requests (NACKs) and thus normally little
or no additional transmission overhead is imposed due to FEC or no additional transmission overhead is imposed due to FEC
encoding. However, the NORM implementation MAY be optionally encoding. However, the NORM implementation MAY be optionally
configured to proactively transmit some amount of redundant FEC configured to proactively transmit some amount of redundant FEC
symbols along with the original content to potentially enhance symbols along with the original content to potentially enhance
performance (e.g., improved delay) at the cost of additional performance (e.g., improved delay) at the cost of additional
transmission overhead. This option may be sensible for certain transmission overhead. This option may be sensible for certain
network conditions and can allow for robust, asymmetric multicast network conditions and can allow for robust, asymmetric multicast
(e.g., unidirectional routing, satellite, cable) [15] with reduced (e.g., unidirectional routing, satellite, cable) [17] with reduced
receiver feedback, or, in some cases, no feedback. receiver feedback, or, in some cases, no feedback.
A sender message of type NORM_INFO is also defined and is used to A sender message of type NORM_INFO is also defined and is used to
carry OPTIONAL "out-of-band" context information for a given carry OPTIONAL "out-of-band" context information for a given
transport object. A single NORM_INFO message can be associated with transport object. A single NORM_INFO message can be associated with
a NormObject. Because of its atomic nature, missing NORM_INFO a NormObject. Because of its atomic nature, missing NORM_INFO
messages can be NACKed and repaired with a slightly lower delay messages can be NACKed and repaired with a slightly lower delay
process than NORM's general FEC-encoded data content. NORM_INFO may process than NORM's general FEC-encoded data content. NORM_INFO may
serve special purposes for some bulk transfer, reliable multicast serve special purposes for some bulk transfer, reliable multicast
applications where receivers join the group mid-stream and need to applications where receivers join the group mid-stream and need to
skipping to change at page 11, line 49 skipping to change at page 11, line 49
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 Nack-Oriented Reliable Multicast (NORM) concepts presented in the Nack-Oriented Reliable Multicast (NORM)
Building Block document [4]. This includes the basic NORM Building Block document [4]. This includes the basic NORM
architecture and the data transmission, repair, and feedback architecture and the data transmission, repair, and feedback
strategies discussed in that document. Additional reliable multicast strategies discussed in that document. Additional reliable multicast
building blocks are applied in creating the full NORM protocol building blocks are applied in creating the full NORM protocol
instantiation [16]. NORM also makes use of Forward Error Correction instantiation [18]. NORM also makes use of Forward Error Correction
encoding techniques for repair messaging and optional transmission encoding techniques for repair messaging and optional transmission
robustness as described in [10]. NORM uses the FEC Payload ID as robustness as described in [12]. NORM uses the FEC Payload ID as
specified by the FEC Building Block Document [5]. Additionally, for specified by the FEC Building Block Document [5]. Additionally, for
congestion control, this document includes a baseline congestion congestion control, this document includes a baseline congestion
control mechanism (NORM-CC) based on the TCP-Friendly Multicast control mechanism (NORM-CC) based on the TCP-Friendly Multicast
Congestion Control (TFMCC) scheme described in [19]. Congestion Control (TFMCC) scheme described in [21] and [6].
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 tradeoffs involved transport arena. There are numerous engineering tradeoffs 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 12, line 51 skipping to change at page 13, line 4
feedback suppression backoff timeouts. This yields improved group feedback suppression backoff timeouts. This yields improved group
size scalability. NORM can operate with reduced buffering but at a size scalability. NORM can operate with reduced buffering but at a
cost of decreased efficiency (lower relative goodput) and reduced cost of decreased efficiency (lower relative goodput) and reduced
group size scalability. group size scalability.
3. Conformance Statement 3. Conformance Statement
This Protocol Instantiation document, in conjunction with the RMT This Protocol Instantiation document, in conjunction with the RMT
Building Block documents of [4] and [5], completely specifies a Building Block documents of [4] and [5], completely specifies a
working reliable multicast transport protocol that conforms to the working reliable multicast transport protocol that conforms to the
requirements described in RFC 2357 [17]. requirements described in RFC 2357 [19].
This document specifies the following message types and mechanisms This document specifies the following message types and mechanisms
which are REQUIRED in complying NORM protocol implementations: which are REQUIRED in complying NORM protocol implementations:
+---------------------+-----------------------------------------------+ +---------------------+-----------------------------------------------+
| Message Type | Purpose | | Message Type | Purpose |
+---------------------+-----------------------------------------------+ +---------------------+-----------------------------------------------+
|NORM_DATA | Sender message for application data | |NORM_DATA | Sender message for application data |
| | transmission. Implementations must support | | | transmission. Implementations must support |
| | at least one of the NORM_OBJECT_DATA, | | | at least one of the NORM_OBJECT_DATA, |
| | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM | | | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM |
skipping to change at page 16, line 33 skipping to change at page 16, line 33
connections. connections.
The "source_id" field is a 32-bit value identifying the node that The "source_id" field is a 32-bit value identifying the node that
sent the message. A participant's NORM node identifier (NormNodeId) sent the message. A participant's NORM node identifier (NormNodeId)
can be set according to application needs but unique identifiers must can be set according to application needs but unique identifiers must
be assigned within a single NormSession. In some cases, use of the be assigned within a single NormSession. In some cases, use of the
host IP address or a hash of it can suffice, but alternative host IP address or a hash of it can suffice, but alternative
methodologies for assignment and potential collision resolution of methodologies for assignment and potential collision resolution of
node identifiers within a multicast session need to be considered. node identifiers within a multicast session need to be considered.
For example, the "source identifier" mechanism defined in the Real- For example, the "source identifier" mechanism defined in the Real-
Time Protocol (RTP) specification [18] may be applicable to use for Time Protocol (RTP) specification [20] may be applicable to use for
NORM node identifiers. At this point in time, the protocol makes no NORM node identifiers. At this point in time, the protocol makes no
assumptions about how these unique identifiers are actually assigned. assumptions about how these unique identifiers are actually assigned.
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.
skipping to change at page 18, line 24 skipping to change at page 18, line 24
| instance_id | grtt |backoff| gsize | | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id | | flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id | | fec_payload_id |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) | | header_extensions (if applicable) |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_msg_start* | payload_len* | | payload_len* | payload_msg_start* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_offset* | | payload_offset* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data* | | payload_data* |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_DATA Message Format NORM_DATA Message Format
*NOTE: The "payload_msg_start", "payload_len" and "payload_offset" *IMPORTANT NOTE: The "payload_len", "payload_msg_start" and
fields are present only for objects of type NORM_OBJECT_STREAM. "payload_offset" fields are present only for objects of type
NORM_OBJECT_STREAM.
The "payload_msg_start" field is used to mark the location (within The "payload_msg_start" field is used to mark the location (within
the "payload_data") field of the start byte of an application-defined the "payload_data") field of the start byte of an application-defined
message boundary. Note that the "payload_msg_start" is the byte message boundary. Note that the "payload_msg_start" is the byte
offset of the message boundary plus one. Thus, a value of offset of the message boundary plus one. Thus, a value of
"payload_msg_start" equal to ZERO denotes that no message boundary is "payload_msg_start" equal to ZERO denotes that no message boundary is
present, while a "payload_msg_start" value of ONE indicates the present, while a "payload_msg_start" value of ONE indicates the
message boundary is aligned with the beginning of the "payload_data" message boundary is aligned with the beginning of the "payload_data"
field. This allows NORM receiver applications to "synchronize" with field. This allows NORM receiver applications to "synchronize" with
NORM senders and to be able to properly interpret application layer NORM senders and to be able to properly interpret application layer
data when joining a NORM session already in progress. The NORM data when joining a NORM session already in progress. The NORM
sender implementation SHOULD provide a mechanism for the application sender implementation SHOULD provide a mechanism for the application
to mark such message boundaries and set the "payload_msg_start" value to mark such message boundaries and set the "payload_msg_start" value
accordingly. The "payload_msg_start" value will always be less than accordingly. The "payload_msg_start" value will always be less than
or equal to the "payload_len" value. or equal to the "payload_len" value except for the special case of
"payload_len = 0", that indicates the "payload_msg_start" field
should be interpreted as a "stream control code" (See description
below).
The "payload_len" and "payload_offset" fields allow senders to The "payload_len" and "payload_offset" fields allow senders to
arbitrarily vary the size of NORM_DATA payload segments for streams. arbitrarily vary the size of NORM_DATA payload segments for streams.
This allows applications to flush transmitted streams as needed to This allows applications to flush transmitted streams as needed to
meet unique streaming requirements. For objects of types meet unique streaming requirements. For objects of types
NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary
since the receiver can calculate the payload length and offset since the receiver can calculate the payload length and offset
information from the "fec_payload_id" using the block partioning information from the "fec_payload_id" using the block partioning
algorithm described in the FEC Building Block document [5]. When algorithm described in the FEC Building Block document [5]. When
systematic FEC codes (e.g., "fec_id" = 129) are used, the systematic FEC codes (e.g., "fec_id" = 129) are used, the
skipping to change at page 19, line 48 skipping to change at page 19, line 51
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.
The "grtt" field contains a non-linear quantized representation of The "grtt" field contains a non-linear quantized representation of
the sender's current estimate of group round-trip time (GRTT) (this the sender's current estimate of group round-trip time (GRTT) (this
is also referred to as R_max in [19]). This value is used to control is also referred to as R_max in [21]). This value is used to control
timing of the NACK repair process and other aspects of protocol timing of the NACK repair process and other aspects of protocol
operation as described in this document. Normally, the advertised operation as described in this document. Normally, the advertised
"grtt" value will correspond to what the sender has measured based "grtt" value will correspond to what the sender has measured based
on feedback from the group, but, at low transmission rates, the on feedback from the group, but, at low transmission rates, the
advertised "grtt" SHOULD be set to MAX(grttMeasured, advertised "grtt" SHOULD be set to MAX(grttMeasured,
NormSegmentSize/senderRate) where the "NormSegmentSize" is sender's NormSegmentSize/senderRate) where the "NormSegmentSize" is sender's
segment size in bytes and the "senderRate" is the sender's current segment size in bytes and the "senderRate" is the sender's current
transmission rate in bytes per second. The algorithm for encoding transmission rate in bytes per second. The algorithm for encoding
and decoding this field is described in the RMT NORM Building Block and decoding this field is described in the RMT NORM Building Block
document [4]. document [4].
skipping to change at page 20, line 31 skipping to change at page 20, line 35
where the most significant bit value of 0 or 1 represents a mantissa where the most significant bit value of 0 or 1 represents a mantissa
of 1 or 5, respectively and the three least significant bits of 1 or 5, respectively and the three least significant bits
incremented by one represent a base 10 exponent (order of magnitude). incremented by one represent a base 10 exponent (order of magnitude).
For examples, a field value of "0x0" represents 1.0e+01 (10), a value For examples, a field value of "0x0" represents 1.0e+01 (10), a value
of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02 of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02
(100), and a value of "0xf" represents 5.0e+08. For NORM feedback (100), and a value of "0xf" represents 5.0e+08. For NORM feedback
suppression purposes, the group size does not need to be represented suppression purposes, the group size does not need to be represented
with a high degree of precision. The group size may even be with a high degree of precision. The group size may even be
estimated somewhat conservatively (i.e., overestimated) to maintain estimated somewhat conservatively (i.e., overestimated) to maintain
low levels of feedback traffic. A default group size estimate of low levels of feedback traffic. A default group size estimate of
10,000 ("gsize" = 0x4) is recommended for general purpose reliable 10,000 ("gsize" = 0x3) is recommended for general purpose reliable
multicast applications using the NORM protocol. multicast applications using the NORM protocol.
The "flags" field contains a number of different binary flags The "flags" field contains a number of different binary flags
providing information and hints regarding how the receiver should providing information and hints regarding how the receiver should
handle the identified object. Defined flags in this field include: handle the identified object. Defined flags in this field include:
+---------------------+-------+------------------------------------------+ +---------------------+-------+------------------------------------------+
| Flag | Value | Purpose | | Flag | Value | Purpose |
+---------------------+-------+------------------------------------------+ +---------------------+-------+------------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair | |NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair |
skipping to change at page 22, line 46 skipping to change at page 22, line 46
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 as described in the given in the descriptions of specific FEC schemes as described in the
IETF FEC Basic Schemes document [20]. or additional FEC Scheme IETF FEC Basic Schemes document [22]. or additional FEC Scheme
documents that may be defined. As an example, the format of the documents that may be defined. As an example, the format of the
"fec_payload_id" format for Small Block, Systematic codes ("fec_id" = "fec_payload_id" format for Small Block, Systematic codes ("fec_id" =
129) is given here: 129) 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 Field ("fec_payload_id") Format Example FEC Payload ID Field ("fec_payload_id") Format
for Small Block, Systematic Codes ("fec_id" = 129) for Small Block, Systematic Codes ("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 given by the FEC Basic Schemes fields of the FEC Payload ID format given by the FEC Basic Schemes
document [20]. for the Small Block Systematic FEC Scheme identified document [22]. for the Small Block Systematic FEC Scheme identified
by a "fec_id" value of 129. The "source_block_number" identifies the by a "fec_id" value of 129. The "source_block_number" identifies the
coding block's relative position with a NormObject. Note that, for coding block's relative position with a NormObject. Note that, for
NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may NormObjects of type NORM_OBJECT_STREAM, the "source_block_number" may
wrap for very long lived sessions. The "source_block_len" indicates wrap for very long lived sessions. The "source_block_len" indicates
the number of user data segments in the identified coding block. the number of user data segments in the identified coding block.
Given the "source_block_len" information of how many symbols of Given the "source_block_len" information of how many symbols of
application data are contained in the block, the receiver can application data are contained in the block, the receiver can
determine whether the attached segment is data or parity content and determine whether the attached segment is data or parity content and
treat it appropriately. The "encoding_symbol_id" identifies which treat it appropriately. The "encoding_symbol_id" identifies which
specific symbol (segment) within the coding block the attached specific symbol (segment) within the coding block the attached
skipping to change at page 26, line 11 skipping to change at page 26, line 11
of parity segments available from the sender for the coding blocks. of parity segments available from the sender for the coding blocks.
This field MAY be interpreted differently for other systematic codes This field MAY be interpreted differently for other systematic codes
as they are defined. as they are defined.
The payload portion of NORM_DATA messages includes source data or FEC The payload portion of NORM_DATA messages includes source data or FEC
encoded application content. Again, the content of this payload encoded application content. Again, the content of this payload
depends upon the FEC scheme being employed. Additionally, support depends upon the FEC scheme being employed. Additionally, support
for streaming using the NORM_OBJECT_STREAM type, necessitates some for streaming using the NORM_OBJECT_STREAM type, necessitates some
additional content in the payload. additional content in the payload.
The "payload_msg_start", "payload_len" and "payload_offset" fields The "payload_len", "payload_msg_start", and "payload_offset" fields
are present ONLY for transport objects of type NORM_OBJECT_STREAM. are present ONLY for transport objects of type NORM_OBJECT_STREAM.
For senders employing systematic FEC encoding, these fields contain For senders employing systematic FEC encoding, these fields contain
values that can be interpreted directly for NORM_DATA messages values that can be interpreted directly for NORM_DATA messages
containing original application source data content. But, for containing original application source data content. But, for
NORM_DATA messages containing calculated parity content, these fields NORM_DATA messages containing calculated parity content, these fields
will contain values computed by FEC encoding of the will contain values computed by FEC encoding of the
"payload_msg_start", "payload_len" and "payload_offset" values of the "payload_msg_start", "payload_len" and "payload_offset" values of the
NORM_DATA data segments for the corresponding FEC coding block and NORM_DATA data segments for the corresponding FEC coding block and
cannot be interpreted directoly. The actual "payload_msg_start", cannot be interpreted directly. The actual "payload_msg_start",
"payload_len" and "payload_offset" values of missing data content can "payload_len" and "payload_offset" values of missing data content can
be determined upon decoding a FEC coding block. Note that these be determined upon decoding a FEC coding block. Note that these
fields do NOT contribute to the value of the NORM_DATA "hdr_len" fields do NOT contribute to the value of the NORM_DATA "hdr_len"
field. These fields are present only when the "flags" portion of the field. These fields are present only when the "flags" portion of the
NORM_DATA message indicate the transport object is of type NORM_DATA message indicate the transport object is of type
NORM_OBJECT_STREAM. NORM_OBJECT_STREAM.
The "payload_msg_start" field, when set to a non-zero value, The "payload_len" value, when non-zero, indicates the size, in bytes,
indicates that the associated "payload_data" content contains an of the source content contained in the "payload_data" field. If the
application-defined message boundary (start-of-message). When such a "payload_len" value is equal to ZERO, this indicates that the
message boundary is indicated, the first byte of an application- "payload_msg_start" field should be alternatively interpreted as a
defined message, with respect to the "payload_data" field, will be stream control code. The only stream control code currently defined
found at an offset of "payload_msg_start - 1" bytes. Thus, if a is NORM_STREAM_END = 0. This code indicates that the sender is
NORM_OBJECT_STREAM NORM_DATA payload contains the start of an terminating transmission of stream content at the corresponding
application message at the first byte of the "payload_data" field, position in the stream and the receiver should not expect content (or
the value of the "payload_msg_start" field will be '1'. Again, if NACK for content) following that position in the stream. Future
the value of the "payload_msg_start" field is ZERO, no message versions of this specification may define additional stream control
boundary is indicated. It is RECOMMENDED that NORM implementations codes if necessary.
provide sender stream applications with a capability to mark message
boundaries in this manner. Similarly, the NORM receiver SHOULD
enable the application to recover such message boundary information.
This enables NORM receivers to "synchronize" with transmitted message
stream content in a meaningful way (i.e., meaningful to the
application) at any time, whether joining the session late, or
departing the session and returning.
The "payload_len" and "payload_offset" fields indicate the size and When the "payload_len" value is non-zero, the "payload_msg_start"
relative position (within the stream) of the source content contained field, when it is set to a non-zero value, indicates that the
in the "payload_data" field. Note that for long-lived streams, the associated "payload_data" content contains an application-defined
message boundary (start-of-message). When such a message boundary is
indicated, the first byte of an application-defined message, with
respect to the "payload_data" field, will be found at an offset of
"payload_msg_start - 1" bytes. Thus, if a NORM_OBJECT_STREAM
NORM_DATA payload contains the start of an application message at the
first byte of the "payload_data" field, the value of the
"payload_msg_start" field will be '1'. Again, if the value of the
"payload_msg_start" field is ZERO, no message boundary is indicated.
It is RECOMMENDED that NORM implementations provide sender stream
applications with a capability to mark message boundaries in this
manner. Similarly, the NORM receiver SHOULD enable the application
to recover such message boundary information. This enables NORM
receivers to "synchronize" with transmitted message stream content in
a meaningful way (i.e., meaningful to the application) at any time,
whether joining the session late, or departing the session and
returning.
and "payload_offset" fields indicate the size and relative position
(within the stream) of the source content contained in the
"payload_data" field. Note that for long-lived streams, the
"payload_offset" field may wrap. "payload_offset" field may wrap.
The "payload_data" field contains the original application source or The "payload_data" field contains the original application source or
parity content for the symbol identified by the "fec_payload_id". parity content for the symbol identified by the "fec_payload_id".
The length of this field SHALL be limited to a maximum of the The length of this field SHALL be limited to a maximum of the
sender's NormSegmentSize bytes as given in the FTI for the object. sender's NormSegmentSize bytes as given in the FTI for the object.
Note the length of this field for messages containing parity content Note the length of this field for messages containing parity content
will always be of length NormSegmentSize. When encoding data will always be of length NormSegmentSize. When encoding data
segments of varying sizes, the FEC encoder SHALL assume ZERO value segments of varying sizes, the FEC encoder SHALL assume ZERO value
padding for data segments with length less than the NormSegmentSize. padding for data segments with length less than the NormSegmentSize.
skipping to change at page 36, line 26 skipping to change at page 36, line 26
for discrete "object" based transport) to arbitrarily invalidate for discrete "object" based transport) to arbitrarily invalidate
(i.e., dequeue) portions of enqueued content (e.g., certain objects) (i.e., dequeue) portions of enqueued content (e.g., certain objects)
for which it no longer wishes to provide reliable transport. for which it no longer wishes to provide reliable transport.
4.2.3.4. NORM_CMD(CC) Message 4.2.3.4. NORM_CMD(CC) Message
The NORM_CMD(CC) messages contains fields to enable sender-to- The NORM_CMD(CC) messages contains fields to enable sender-to-
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 [19] is described in Multicast Congestion Control (TFMCC) scheme of [6] is described in
Section 5.5.2 of this document. The NORM_CMD(CC) message is usually Section 5.5.2 of this document. The NORM_CMD(CC) message is usually
transmitted as part of NORM-CC congestion control operation. A NORM transmitted as part of NORM-CC congestion control operation. A NORM
header extension is defined below to be used with the NORM_CMD(CC) header extension is defined below to be used with the NORM_CMD(CC)
message to support NORM-CC operation. Different header extensions message to support NORM-CC operation. Different header extensions
may be defined for the NORM_CMD(CC) (and/or other NORM messages as may be defined for the NORM_CMD(CC) (and/or other NORM messages as
needed) to support alternative congestion control schemes in the needed) to support alternative congestion control schemes in the
future. If NORM is operated in a private network with congestion future. If NORM is operated in a private network with congestion
control operation disabled, the NORM_CMD(CC) message is then used for control operation disabled, the NORM_CMD(CC) message is then used for
GRTT measurement only and may optionally be sent less frequently than GRTT measurement only and may optionally be sent less frequently than
with congestion control operation. with congestion control operation.
skipping to change at page 37, line 41 skipping to change at page 37, line 41
header extensions are present is 6. header extensions are present is 6.
The "reserved" field is for potential future use and MUST be set to The "reserved" field is for potential future use and MUST be set to
ZERO in this version of the NORM protocol and its baseline NORM-CC ZERO in this version of the NORM protocol and its baseline NORM-CC
congestion control scheme. It may be possible that alternative congestion control scheme. It may be possible that alternative
congestion control schemes may use the NORM_CMD(CC) message defined congestion control schemes may use the NORM_CMD(CC) message defined
here and leverage the "reserved" field for scheme-specific purposes. here and leverage the "reserved" field for scheme-specific purposes.
The "cc_sequence" field is a sequence number applied by the sender. The "cc_sequence" field is a sequence number applied by the sender.
For NORM-CC operation, it is used to provide functionality equivalent For NORM-CC operation, it is used to provide functionality equivalent
to the "feedback round number" (fb_nr)described in [19]. The most to the "feedback round number" (fb_nr)described in [6]. The most
recently received "cc_sequence" value is recorded by receivers and recently received "cc_sequence" value is recorded by receivers and
can be fed back to the sender in congestion control feedback can be fed back to the sender in congestion control feedback
generated by the receivers for that sender. The "cc_sequence" number generated by the receivers for that sender. The "cc_sequence" number
can also be used in NORM implementations to assess how recently a can also be used in NORM implementations to assess how recently a
receiver has received NORM_CMD(CC) probes from the sender. This can receiver has received NORM_CMD(CC) probes from the sender. This can
be useful instrumentation for complex or experimental multicast be useful instrumentation for complex or experimental multicast
routing environments. routing environments.
The "send_time" field is a timestamp indicating the time that the The "send_time" field is a timestamp indicating the time that the
NORM_CMD(CC) message was transmitted. This consists of a 64-bit NORM_CMD(CC) message was transmitted. This consists of a 64-bit
skipping to change at page 38, line 33 skipping to change at page 38, line 33
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 128 | reserved | send_rate | | het = 128 | reserved | send_rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM-CC Rate Header Extension Format (EXT_RATE) NORM-CC Rate Header Extension Format (EXT_RATE)
The "send_rate" field indicates the sender's current transmission The "send_rate" field indicates the sender's current transmission
rate in bytes per second. The 16-bit "send_rate" field consists of rate in bytes per second. The 16-bit "send_rate" field consists of
12 bits of mantissa in the most significant portion and 4 bits of 12 bits of mantissa in the most significant portion and 4 bits of
base 10 exponent (order of magnitude) information in the least base 10 integer exponent (E) information in the least significant
significant portion. The 12-bit mantissa portion of the field is portion. The 12-bit mantissa portion of the field is scaled such
scaled such that a floating point value of 0.0 corresponds to 0 and a that a base 10 mantissa (M) floating point value of 0.0 corresponds
floating point value of 10.0 corresponds to 4096. Thus: to 0 and a value of 10.0 corresponds to 4096 in the upper 12 bits of
the 16-bit "send_rate" field . Thus:
send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) | Value_exponent; send_rate = (((int)(M * 4096.0 / 10.0 + 0.5)) << 4) | E;
For example, to represent a transmission rate of 256kbps (3.2e+04 For example, to represent a transmission rate of 256kbps (3.2e+04
bytes per second), the lower 4 bits of the 16-bit field contain a bytes per second), the lower 4 bits of the 16-bit field contain a
value of 0x04 to represent the exponent while the upper 12 bits value of 0x04 to represent the exponent (E) while the upper 12 bits
contain a value of 0x51f as determined from the equation given above: contain a value of 0x51f (M) as determined from the equation given
above:
send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4; send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;
= (0x51f << 4) | 0x4 = (0x51f << 4) | 0x4
= 0x51f4 = 0x51f4
To decode the "send_rate" field, the following equation can be used: To decode the "send_rate" field, the following equation can be used:
value = (send_rate >> 4) * 10.0 / 4096.0 * power(10.0, (send_rate & x000f)) value = (send_rate >> 4) * 10.0 / 4096.0 * power(10.0, (send_rate & x000f))
Note the maximum transmission rate that can be represented by this Note the maximum transmission rate that can be represented by this
scheme is approximately 9.99e+15 bytes per second. scheme is approximately 9.99e+15 bytes per second.
When this extension is present, a "cc_node_list" may be attached as When this extension is present, a "cc_node_list" may be attached as
the payload of the NORM_CMD(CC) message. The presence of this header the payload of the NORM_CMD(CC) message. The presence of this header
extension also implies that NORM receivers should respond according extension also implies that NORM receivers should respond according
skipping to change at page 40, line 51 skipping to change at page 40, line 51
4.2.3.5. NORM_CMD(REPAIR_ADV) Message 4.2.3.5. NORM_CMD(REPAIR_ADV) Message
The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise" The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise"
its aggregated repair state from NORM_NACK messages accumulated its aggregated repair state from NORM_NACK messages accumulated
during a repair cycle and/or congestion control feedback received. during a repair cycle and/or congestion control feedback received.
This message is sent only when the sender has received NORM_NACK This message is sent only when the sender has received NORM_NACK
and/or NORM_ACK(CC) (when congestion control is enabled) messages via and/or NORM_ACK(CC) (when congestion control is enabled) messages via
unicast transmission instead of multicast. By "echoing" this unicast transmission instead of multicast. By "echoing" this
information to the receiver set, suppression of feedback can be information to the receiver set, suppression of feedback can be
achieved even when receivers are unicasting that feedback instead of achieved even when receivers are unicasting that feedback instead of
multicasting it among the group [13]. multicasting it among the group [15].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 51 skipping to change at page 41, line 51
be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting
(in terms of congestion control feedback suppression) congestion (in terms of congestion control feedback suppression) congestion
control response. This allows the NORM_CMD(REPAIR_ADV) message to control response. This allows the NORM_CMD(REPAIR_ADV) message to
suppress receiver congestion control responses as well as NACK suppress receiver congestion control responses as well as NACK
feedback messages. The field is defined as a header extension so feedback messages. The field is defined as a header extension so
that alternative congestion control schemes may be used with NORM that alternative congestion control schemes may be used with NORM
without revision to this document. A NORM-CC Feedback Header without revision to this document. A NORM-CC Feedback Header
Extension (EXT_CC) is defined to encapsulate congestion control Extension (EXT_CC) is defined to encapsulate congestion control
feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV) feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV)
messages. If another congestion control technique (e.g., Pragmatic messages. If another congestion control technique (e.g., Pragmatic
General Multicast Congestion Control (PGMCC) [21]) is used within a General Multicast Congestion Control (PGMCC) [23]) is used within a
NORM implementation, an additional header extension MAY need to be NORM implementation, an additional header extension MAY need to be
defined encapsulate any required feedback content. The NORM-CC defined encapsulate any required feedback content. The NORM-CC
Feedback Header Extension format is: Feedback Header Extension format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het = 3 | hel = 3 | cc_sequence | | het = 3 | hel = 3 | cc_sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cc_flags | cc_rtt | cc_loss | | cc_flags | cc_rtt | cc_loss |
skipping to change at page 68, line 6 skipping to change at page 68, line 6
conducting congestion control rate adjustment. NORM operation conducting congestion control rate adjustment. NORM operation
without congestion control should be considered only in closed without congestion control should be considered only in closed
networks. networks.
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
[19]. This congestion control scheme is REQUIRED for operation [6]. This congestion control scheme is REQUIRED for operation within
within the general Internet unless the NORM implementation is adapted the general Internet unless the NORM implementation is adapted to use
to use another IETF-sanctioned reliable multicast congestion control another IETF-sanctioned reliable multicast congestion control
mechanism (e.g., PGMCC [21]). With this TFMCC-based approach, the mechanism (e.g., PGMCC [23]). With this TFMCC-based approach, the
transmissions of NORM senders are controlled in a rate-based manner transmissions of NORM senders are controlled in a rate-based manner
as opposed to window-based congestion control algorithms as in TCP. as opposed to window-based congestion control algorithms as in TCP.
However, it is possible that the NORM protocol message set may However, it is possible that the NORM protocol message set may
alternatively be used to support a window-based multicast congestion alternatively be used to support a window-based multicast congestion
control scheme such as PGMCC. The details of that alternative may be control scheme such as PGMCC. The details of that alternative may be
described separately or in a future revision of this document. In described separately or in a future revision of this document. In
either case (rate-based TFMCC or window-based PGMCC), successful either case (rate-based TFMCC or window-based PGMCC), successful
control of sender transmission depends upon collection of sender-to- control of sender transmission depends upon collection of sender-to-
receiver packet loss estimates and RTTs to identify the congestion receiver packet loss estimates and RTTs to identify the congestion
control bottleneck path(s) within the multicast topology and adjust control bottleneck path(s) within the multicast topology and adjust
the sender rate accordingly. The receiver with loss and RTT the sender rate accordingly. The receiver with loss and RTT
estimates that correspond to the lowest resulting calculated estimates that correspond to the lowest resulting calculated
transmission rate is identified as the "current limiting receiver" transmission rate is identified as the "current limiting receiver"
(CLR). In the case of a "tie" (where candidate CLRs are within 10% (CLR). In the case of a "tie" (where candidate CLRs are within 10%
of the same calculated rate), the receiver with the largest RTT value of the same calculated rate), the receiver with the largest RTT value
SHOULD be designated as the CLR. SHOULD be designated as the CLR.
As described in [22], a steady-state sender transmission rate, to be As described in [24], a steady-state sender transmission rate, to be
"friendly" with competing TCP flows can be calculated as: "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"
packet size can be determined by the sender as an packet size can be determined by the sender as an
skipping to change at page 74, line 29 skipping to change at page 74, line 29
congestion control feedback once per K*GRTT intervals. Note, congestion control feedback once per K*GRTT intervals. Note,
however, that as the session progresses, different receivers will be however, that as the session progresses, different receivers will be
responding to different NORM_CMD(CC) messages and there will be responding to different NORM_CMD(CC) messages and there will be
relatively continuous feedback of congestion control information relatively continuous feedback of congestion control information
while the sender is active. while the sender is active.
5.5.2.3. Congestion Control Rate Adjustment 5.5.2.3. Congestion Control Rate Adjustment
During steady-state operation, the sender will directly adjust its During steady-state operation, the sender will directly adjust its
transmission rate to the rate indicated by the feedback from its transmission rate to the rate indicated by the feedback from its
currently selected CLR. As noted in [19], the estimation of currently selected CLR. As noted in [21], the estimation of
parameters (loss and RTT) for the CLR will generally constrain the parameters (loss and RTT) for the CLR will generally constrain the
rate changes possible within acceptable bounds. For rate increases, rate changes possible within acceptable bounds. For rate increases,
the sender SHALL observe a maximum rate of increase of one packet per the sender SHALL observe a maximum rate of increase of one packet per
RTT at all times during steady-state operation. RTT at all times during steady-state operation.
The sender processes congestion control feedback from the receivers The sender processes congestion control feedback from the receivers
and selects the CLR based on the lowest rate receiver. Receiver and selects the CLR based on the lowest rate receiver. Receiver
rates are either determined directly from the slow start "cc_rate" rates are either determined directly from the slow start "cc_rate"
provided by the receiver in the NORM-CC Feedback header extension or provided by the receiver in the NORM-CC Feedback header extension or
by performing the equation-based calculation using individual RTT and by performing the equation-based calculation using individual RTT and
skipping to change at page 79, line 46 skipping to change at page 79, line 46
accomplished if the NORM packets are cryptographically protected and accomplished if the NORM packets are cryptographically protected and
the sender is willing to maintain state on receivers which are the sender is willing to maintain state on receivers which are
NACKing. A cache of receiver state may provide some protection NACKing. A cache of receiver state may provide some protection
against replay attacks. Note that the "sequence" field of NORM against replay attacks. Note that the "sequence" field of NORM
messages should be incremented with independent values for different messages should be incremented with independent values for different
destinations (e.g., group-addressed versus unicast-addressed messages destinations (e.g., group-addressed versus unicast-addressed messages
versus "receiver" messages). Thus, the congestion control loss versus "receiver" messages). Thus, the congestion control loss
estimation function of the "sequence" field can be preserved for estimation function of the "sequence" field can be preserved for
sender messages when receiver messages are unicast to the sender. sender messages when receiver messages are unicast to the sender.
The NORM protocol is compatible with the use of the IP security The NORM protocol is compatible with the use of the IP security
(IPsec) architecture described in [23]. It is important to note that (IPsec) architecture described in [25]. It is important to note that
while NORM does leverage FEC-based repair for scalability, this does while NORM does leverage FEC-based repair for scalability, this does
not alone guarantee integrity of received data. Application-level not alone guarantee integrity of received data. Application-level
integrity-checking of data content is highly RECOMMENDED. integrity-checking of data content is highly RECOMMENDED.
7. IANA Considerations 7. IANA Considerations
No information in this specification is currently subject to IANA Header extension identifiers for the NORM protocol are subject to
registration. However, several Header Extensions are defined within IANA registration. Additionally, building blocks components used by
this document. If/when additional Header Extensions are developed, this NORM Protocol specification may introduce additional IANA
the first RFC MUST establish an IANA registry for them, with a considerations. In particular, the FEC Building Block used by NORM
"Specification Required" policy [6] and all Header Extensions, does require IANA registration of the FEC codecs used. The
including those in the present document, MUST be registered registration instructions for FEC codecs are provided in [5].
thereafter. Additionally, building blocks components used by NORM
may introduce additional IANA considerations. In particular, the FEC 7.1.
Building Block used by NORM does require IANA registration of the FEC
codecs used. The registration instructions for FEC codecs are This document defines a name-space for NORM Header Extensions named:
provided in [5]. ietf:rmt:norm:extensions
These values represent extended header fields that allow the protocol
functionality to be expanded to include additional optional features
and operating modes. The values that can be assigned within the
"ietf:rmt:norm:extension" name-space are numeric indexes in the range
[0, 255], boundaries included. Values in the range [0,127] indicate
variable length extended header fields while values in the range
[128,255] indicate extension of a fixed 4-byte length. NORM header
extension indentifier value assignment requests are granted on a
"Specification Required" basis as defined in [7]. Additional header
extension specifications MUST include a description of protocol
actions to be taken when the the extended header is encountered by a
protocol implementation not supporting that specific option. For
example, it may be possible for protocol implementations to ignore
unknown header extensions in many cases.
This specification registers the following NORM Header Extension
types in namespace "ietf:rmt:norm:extensions":
+------+-----------+-----------------------------------------------+
|Value | Name | Reference |
+------+-----------+-----------------------------------------------+
| 3 | EXT_CC | This specification |
+------+-----------+-----------------------------------------------+
| 64 | EXT_FTI | This specification |
+------+-----------+-----------------------------------------------+
| 128 | EXT_RATE | This specification |
+------+-----------+-----------------------------------------------+
8. Suggested Use 8. Suggested Use
The present NORM protocol is seen as useful tool for the reliable The present NORM protocol is seen as useful tool for the reliable
data transfer over generic IP multicast services. It is not the data transfer over generic IP multicast services. It is not the
intention of the authors to suggest it is suitable for supporting intention of the authors to suggest it is suitable for supporting
all envisioned multicast reliability requirements. NORM provides a all envisioned multicast reliability requirements. NORM provides a
simple and flexible framework for multicast applications with a simple and flexible framework for multicast applications with a
degree of concern for network traffic implosion and protocol overhead degree of concern for network traffic implosion and protocol overhead
efficiency. NORM-like protocols have been successfully demonstrated efficiency. NORM-like protocols have been successfully demonstrated
skipping to change at page 81, line 5 skipping to change at page 81, line 34
A sender-only repair approach often makes additional engineering A sender-only repair approach often makes additional engineering
sense in asymmetric networks. NORM's unicast feedback capability may sense in asymmetric networks. NORM's unicast feedback capability may
be suitable for use in asymmetric networks or in networks where only be suitable for use in asymmetric networks or in networks where only
unidirectional multicast routing/delivery service exists. Asymmetric unidirectional multicast routing/delivery service exists. Asymmetric
architectures supporting multicast delivery are likely to make up an architectures supporting multicast delivery are likely to make up an
important portion of the future Internet structure (e.g., important portion of the future Internet structure (e.g.,
DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer DBS/cable/PSTN hybrids) and efficient, reliable bulk data transfer
will be an important capability for servicing large groups of will be an important capability for servicing large groups of
subscribed receivers. subscribed receivers.
9. Acknowledgments (and these are not Negative) 9. Changes from RFC3940
This section lists the changes between the Experimental version of
this specification, [8], and this version:
1) Removal of the NORM_FLAG_MSG_START for NORM_OBJECT_STREAM,
replacing it with the "payload_msg_start" field in the FEC-
encoded preamble of the NORM_OBJECT_STREAM NORM_DATA payload,
2) Definition of IANA namespace for header extension assignment,
3) Removal of file blocking scheme description that is now
specified in the FEC Building Block document [5],
4) Removal of restriction of NORM receiver feedback message rate
to local NORM sender rate (this caused congestion control
failures in high speed operation and the extremely low
feedback rate of the NORM protocol avoids any resultant impact
to the network anyway [26]) , and
5) Correction of errors in some message format descriptions.
10. Acknowledgments (and these are not Negative)
The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh, The authors would like to thank Rick Jones, Vincent Roca, Rod Walsh,
Toni Paila, Michael Luby, and Joerg Widmer for their valuable input Toni Paila, Michael Luby, and Joerg Widmer for their valuable input
and comments on this document. The authors would also like to thank and comments on this document. The authors would also like to thank
the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for the RMT working group chairs, Roger Kermode and Lorenzo Vicisano, for
their support in development of this specification, and Sally Floyd their support in development of this specification, and Sally Floyd
for her early input into this document. for her early input into this document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[1] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable [1] Kermode, R. and L. Vicisano, "Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol Instantiation Multicast Transport (RMT) Building Blocks and Protocol Instantiation
documents", RFC 3269, April 2002. documents", RFC 3269, April 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC [3] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
1112, August 1989. 1112, August 1989.
[4] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative- [4] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Multicast
Acknowledgement (NACK)-Oriented Reliable Multicast (NORM) Building Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb-
Blocks", RFC 3941, November 2004. norm-revised-01, March 2006.
[5] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and [5] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction
J. Crowcroft, "Forward Error Correction (FEC) Building Block", RFC (FEC) Building Block", draft-ietf-rmt-fec-bb-revised-03, January
3452, December 2002. 2006.
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [6] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion
Control Protocol Specification", draft-ietf-rmt-bb-tfmcc-06, March
2006.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
10.2. Informative References 11.2. Informative References
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", [8] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-
Acknowledgement (NACK)-Oriented Reliable Multicast (NORM) Protocol",
RFC 3940, November 2004.
[9] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
RFC 2327, April 1998. RFC 2327, April 1998.
[8] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[9] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender- [11] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender-
Initiated and Receiver-Initiated Reliable Multicast Protocols", In Initiated and Receiver-Initiated Reliable Multicast Protocols", In
Proc. INFOCOM, San Francisco CA, October 1993. Proc. INFOCOM, San Francisco CA, October 1993.
[10] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and [12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and
J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable
Multicast", RFC 3453, December 2002. Multicast", RFC 3453, December 2002.
[11] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol [13] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol
(MDP) Toolkit", Proc. IEEE MILCOM 99, October 1999. (MDP) Toolkit", Proc. IEEE MILCOM 99, October 1999.
[12] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", [14] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback",
Proc. IEEE INFOCOMM, p. 964, March/April 1998. Proc. IEEE INFOCOMM, p. 964, March/April 1998.
[13] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented [15] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented
Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October Reliable Multicast (NORM) Feedback", Proc. IEEE MILCOM 2002, October
2002. 2002.
[14] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. [16] H.W. Holbrook, "A Channel Model for Multicast", Ph.D.
Dissertation, Stanford University, Department of Computer Science, Dissertation, Stanford University, Department of Computer Science,
Stanford, California, August 2001. Stanford, California, August 2001.
[15] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity [17] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity
Retransmission with Channel Estimation", IEEE GLOBECOMM 98', Retransmission with Channel Estimation", IEEE GLOBECOMM 98',
September 1998. September 1998.
[16] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [18] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S.,
and M. Luby, "Reliable Multicast Transport Building Blocks for One- and M. Luby, "Reliable Multicast Transport Building Blocks for One-
to-Many Bulk-Data Transfer", RFC 3048, January 2001. to-Many Bulk-Data Transfer", RFC 3048, January 2001.
[17] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF [19] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and Application Criteria for Evaluating Reliable Multicast Transport and Application
Protocols", RFC 2357, June 1998. Protocols", RFC 2357, June 1998.
[18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [20] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC
3550, July 2003. 3550, July 2003.
[19] J. Widmer and M. Handley, "Extending Equation-Based Congestion [21] J. Widmer and M. Handley, "Extending Equation-Based Congestion
Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego, Control to Multicast Applications", Proc ACM SIGCOMM 2001, San Diego,
August 2001. August 2001.
[20] Watson, M., "Basic Forward Error Correction (FEC) Schemes", [22] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-00, July Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-02, March
2005. 2006.
[21] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast [23] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast
Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August Congestion Control Scheme", Proc ACM SIGCOMM 2000, Stockholm, August
2000. 2000.
[22] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP [24] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP
Throughput: A Simple Model and its Empirical Validation", Proc ACM Throughput: A Simple Model and its Empirical Validation", Proc ACM
SIGCOMM 1998. SIGCOMM 1998.
[23] Kent, S. and R. Atkinson, "Security Architecture for the [25] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
11. Authors' Addresses [26] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism
for NACK-Oriented Reliable Multicast Congestion Control", IEEE
GLOBECOMM 2001, November 2001.
12. Authors' Addresses
Brian Adamson Brian Adamson
Naval Research Laboratory Naval Research Laboratory
Washington, DC, USA, 20375 Washington, DC, USA, 20375
EMail: adamson@itd.nrl.navy.mil EMail: adamson@itd.nrl.navy.mil
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
skipping to change at page 85, line 5 skipping to change at page 86, line 5
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, USA, 20375 Washington, DC, USA, 20375
EMail: macker@itd.nrl.navy.mil EMail: macker@itd.nrl.navy.mil
12. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 End of changes. 74 change blocks. 
133 lines changed or deleted 217 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/