draft-ietf-rmt-pi-norm-revised-03.txt   draft-ietf-rmt-pi-norm-revised-04.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: 30 March 2007 Universitaet Bremen TZI Expires: 30 September 2007 Universitaet Bremen TZI
M. Handley M. Handley
UCL UCL
J. Macker J. Macker
NRL NRL
September 2006
Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
draft-ietf-rmt-pi-norm-revised-03 draft-ietf-rmt-pi-norm-revised-04
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 39 skipping to change at page 1, line 38
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 March 30, 2007. This Internet-Draft will expire on September 30, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Trust (2007).
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 7 skipping to change at page 3, line 7
both reciprocal multicast routing among senders and receivers and both reciprocal multicast routing among senders and receivers and
with asymmetric connectivity (possibly a unicast return path) between with asymmetric connectivity (possibly a unicast return path) between
the senders and receivers. The protocol offers a number of features the senders and receivers. The protocol offers a number of features
to allow different types of applications or possibly other higher to allow different types of applications or possibly other higher
level transport protocols to utilize its service in different ways. level transport protocols to utilize its service in different ways.
The protocol leverages the use of FEC-based repair and other IETF The 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.
Table of Contents Table of Contents
1. Introduction and Applicability. . . . . . . . . . . . . . . . . . 4 1. Introduction and Applicability. . . . . . . . . . . . . . . . . . 5
1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . . . . 5 1.1. NORM Delivery Service Model. . . . . . . . . . . . . . . . . . 6
1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . . . . 7 1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . . . . 8
1.3. Environmental Requirements and Considerations. . . . . . . . . 8 1.3. Environmental Requirements and Considerations. . . . . . . . . 9
2. Architecture Definition . . . . . . . . . . . . . . . . . . . . . 8 2. Architecture Definition . . . . . . . . . . . . . . . . . . . . . 9
2.1. Protocol Operation Overview. . . . . . . . . . . . . . . . . . 10 2.1. Protocol Operation Overview. . . . . . . . . . . . . . . . . . 11
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . . . 11 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . . . 12
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . 13
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . . . 12 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . . . 13
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. NORM Common Message Header and Extensions. . . . . . . . . . . 15 4.1. NORM Common Message Header and Extensions. . . . . . . . . . . 16
4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Sender Messages. . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . . . . 17 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . . . . 27 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . . . . 28
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . . . . 29 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . . . . 30
4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . . . . 47 4.3. Receiver Messages. . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . . . . 47 4.3.1. NORM_NACK Message . . . . . . . . . . . . . . . . . . . . . 48
4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . . . . . . 54 4.3.2. NORM_ACK Message. . . . . . . . . . . . . . . . . . . . . . 55
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . . . 56 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . . . 57
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . . . . 56 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . . . . 57
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . . . 56 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . . . 57
5.1. Sender Initialization and Transmission . . . . . . . . . . . . 58 5.1. Sender Initialization and Transmission . . . . . . . . . . . . 59
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . . . . 59 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . . . . 60
5.2. Receiver Initialization and Reception. . . . . . . . . . . . . 60 5.2. Receiver Initialization and Reception. . . . . . . . . . . . . 61
5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . . . . 60 5.3. Receiver NACK Procedure. . . . . . . . . . . . . . . . . . . . 61
5.4. Sender NACK Processing and Response. . . . . . . . . . . . . . 63 5.4. Sender NACK Processing and Response. . . . . . . . . . . . . . 64
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . . . . 63 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . . . . 64
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . . . . 64 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . . . . 65
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . . . . 65 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . . . . 66
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . . . . . . 66 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation. . . . . . . . . . . 67
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . . . 66 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . . . 67
5.5.1. Greatest Round-trip Time Collection . . . . . . . . . . . . 66 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . . . . 68
5.5.2. NORM Congestion Control Operation . . . . . . . . . . . . . 68 5.5.2. NORM Congestion Control Operation . . . . . . . . . . . . . 69
5.5.3. NORM Positive Acknowledgment Procedure. . . . . . . . . . . 76 5.5.3. NORM Positive Acknowledgment Procedure. . . . . . . . . . . 78
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . . . . 79 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . . . . 80
6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . . . 80
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 80 6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . . . 81
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.1.1. IPSec Approach. . . . . . . . . . . . . . . . . . . . . . . 82
9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 81 6.1.2. IPSec Requirements. . . . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 82 6.1.2.1. Selectors. . . . . . . . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.1.2.2. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 82 6.1.2.3. Key Management . . . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References. . . . . . . . . . . . . . . . . . . . 83 6.1.2.4. Security Policy. . . . . . . . . . . . . . . . . . . . . 85
12. Author Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 6.1.2.5. Authentication and Encryption. . . . . . . . . . . . . . 85
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 86 6.1.2.6. Availability . . . . . . . . . . . . . . . . . . . . . . 85
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 85
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . . . 86
9. Changes from RFC3940. . . . . . . . . . . . . . . . . . . . . . . 87
10. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . 88
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
11.1. Normative References. . . . . . . . . . . . . . . . . . . . . 88
11.2. Informative References. . . . . . . . . . . . . . . . . . . . 89
12. Author Addresses . . . . . . . . . . . . . . . . . . . . . . . . 91
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 92
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 40 skipping to change at page 5, line 40
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 the definitions necessary to fully specify a This memo contains the definitions necessary to fully specify a
Reliable Multicast Transport protocol in accordance with RFC 2357. Reliable Multicast Transport protocol in accordance with RFC 2357.
RFC3940 [8] contained a previous description of the NORM Protocol RFC3940 [10] contained a previous description of the NORM Protocol
specification described in this document. RF3940 was published in specification described in this document. RF3940 was published in
the "Experimental" category. It was the stated intent of the RMT the "Experimental" category. It was the stated intent of the RMT
working group to re-submit this specifications as an IETF Proposed working group to re-submit this specifications as an IETF Proposed
Standard in due course. Standard in due course.
This Proposed Standard specification is thus based on RFC3940 [8] and This Proposed Standard specification is thus based on RFC3940 [10]
has been updated according to accumulated experience and growing and has been updated according to accumulated experience and growing
protocol maturity since the publication of RFC3940. Said experience protocol maturity since the publication of RFC3940. Said experience
applies both to this specification itself and to congestion control applies both to this specification itself and to congestion control
strategies related to the use of this specification. strategies related to the use of this specification.
The differences between RFC3940 [8] and this document are listed in The differences between RFC3940 [10] and this document are listed in
Section 9. 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) [9], Session Announcement Protocol Session Description Protocol (SDP) [11], Session Announcement
(SAP) [10], etc.). Protocol (SAP) [12], 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 19 skipping to change at page 8, 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 [11]. NORM is a protocol centered around for reliability is required [13]. 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 [12]. FEC-based repair can be used to transmission robustness [14]. 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 [13] in a NACK-oriented protocol. The principal repair transmissions [15] 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 [14]. NORM dynamically measures the techniques is described in [16]. 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 [15]. quantity of feedback for this type of protocol is described in [17].
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.
skipping to change at page 8, line 22 skipping to change at page 9, line 22
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) [16] where there may only be unicast routing service Multicast (SSM) [18] 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 26 skipping to change at page 11, 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) [17] with reduced (e.g., unidirectional routing, satellite, cable) [19] 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 12, 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 [18]. NORM also makes use of Forward Error Correction instantiation [20]. 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 [12]. NORM uses the FEC Payload ID as robustness as described in [14]. 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 [21] and [6]. Congestion Control (TFMCC) scheme described in [24] 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 13, line 4 skipping to change at page 14, 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 [19]. requirements described in RFC 2357 [21].
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 37 skipping to change at page 17, line 37
product of expected network connections. product of expected network 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 [20] may be applicable to use for Time Protocol (RTP) specification [22] 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 20, line 20 skipping to change at page 21, line 20
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 [21]). This value is used to control is also referred to as R_max in [24]). 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" SHALL be set to MAX(grttMeasured, advertised "grtt" SHALL 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 22, line 48 skipping to change at page 23, line 48
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 [22]. or additional FEC Scheme IETF FEC Basic Schemes document [25]. 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 [22]. for the Small Block Systematic FEC Scheme identified document [25]. 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. Some applications may dynamically "shorten"
specific symbol (segment) within the coding block the attached code blocks when the pending information content is not predictable
payload conveys. Depending upon the value of the (e.g. real-time message streams). In that case, the
"source_block_len" value given for an "encoding_symbol_id" that
contains FEC parity content SHALL take precedence over the
"source_block_len" value provided for any packets containing source
symbols. Also, the "source_block_len" value given for an ordinally
higher "encoding_symbol_id" SHALL take precedence over the
"source_block_len" given for prior encoding symbols. The reason for
this is that the sender may only know the maximum source block length
at the time is transmitting source symbols, but then subsequently
"shorten" the code and then provide that last source symbol and/or
encoding symbols with FEC parity content. The "encoding_symbol_id"
identifies which specific symbol (segment) within the coding block
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
numbered less than the source_block_len contain original application numbered less than the source_block_len contain original application
data while segments greater than or equal to source_block_len contain data while segments greater than or equal to source_block_len contain
parity symbols calculated for the block. The concatenation of parity symbols calculated for the block. The concatenation of
object_transport_id::fec_payload_id can be viewed as a unique object_transport_id::fec_payload_id can be viewed as a unique
transport protocol data unit identifier for the attached segment with transport protocol data unit identifier for the attached segment with
respect to the NORM sender's instance within a session. respect to the NORM sender's instance within a session.
skipping to change at page 33, line 13 skipping to change at page 34, line 13
the "source_block_len". This condition indicates the sender has not the "source_block_len". This condition indicates the sender has not
yet completed encoding the corresponding FEC block and parity content yet completed encoding the corresponding FEC block and parity content
is not yet available. An "explicit-only" repair request consists of is not yet available. An "explicit-only" repair request consists of
NACK content for the applicable "source_block_number" which does not NACK content for the applicable "source_block_number" which does not
include any requests for parity-based repair. This allows NORM include any requests for parity-based repair. This allows NORM
sender applications to "flush" an ongoing stream of transmission when sender applications to "flush" an ongoing stream of transmission when
needed, even if in the middle of an FEC block. Once the sender needed, even if in the middle of an FEC block. Once the sender
resumes stream transmission and passes the end of the pending coding resumes stream transmission and passes the end of the pending coding
block, subsequent NACKs from receivers SHALL request parity-based block, subsequent NACKs from receivers SHALL request parity-based
repair as usual. Note that the use of a systematic FEC code is repair as usual. Note that the use of a systematic FEC code is
assumed here. Normal receiver NACK initiation and construction is assumed here. It should also be noted that a sender has the option
discussed in detail in Section 5.3. The OPTIONAL "acking_node_list" of arbitrarily shortening a given code block when such an application
field contains a list of NormNodeIds for receivers from which the "flush" occurs. In this case, the receiver will request explicit
sender is requesting explicit positive acknowledgment of reception up repair, but the sender MAY provide FEC-based repair (parity segments)
through the transmission point identified by the in response. These parity segments MUST contain the corrected
"object_transport_id" and "fec_payload_id" fields. The length of the "source_block_len" for the shortened block and that
list can be inferred from the length of the received NORM_CMD(FLUSH) "source_block_len" associated with segments containing parity content
message. When the "acking_node_list" is present, the lightweight SHALL overrride the previously advertised "source_block_len".
positive acknowledgment process described in Section 5.5.3 SHALL be Similarly, the "source_block_len" associated with the highest ordinal
observed. "encoding_symbol_id" shall take precedence over prior symbols when a
difference (e.g., due to code shortening at the sender) occurs.
Normal receiver NACK initiation and construction is discussed in
detail in Section 5.3. The OPTIONAL "acking_node_list" field
contains a list of NormNodeIds for receivers from which the sender is
requesting explicit positive acknowledgment of reception up through
the transmission point identified by the "object_transport_id" and
"fec_payload_id" fields. The length of the list can be inferred from
the length of the received NORM_CMD(FLUSH) message. When the
"acking_node_list" is present, the lightweight positive
acknowledgment process described in Section 5.5.3 SHALL be observed.
4.2.3.2. NORM_CMD(EOT) Message 4.2.3.2. NORM_CMD(EOT) Message
The NORM_CMD(EOT) command is sent when the sender reaches permanent The NORM_CMD(EOT) command is sent when the sender reaches permanent
end-of-transmission with respect to the NormSession and will not end-of-transmission with respect to the NormSession and will not
respond to further repair requests. This allows receivers to respond to further repair requests. This allows receivers to
gracefully reach closure of operation with this sender (without gracefully reach closure of operation with this sender (without
requiring any timeout) and free any resources that are no longer requiring any timeout) and free any resources that are no longer
needed. The NORM_CMD(EOT) command SHOULD be sent with the same needed. The NORM_CMD(EOT) command SHOULD be sent with the same
robust mechanism as used for NORM_CMD(FLUSH) commands to provide a robust mechanism as used for NORM_CMD(FLUSH) commands to provide a
skipping to change at page 40, line 51 skipping to change at page 41, 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 [15]. multicasting it among the group [17].
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 42, 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) [23]) is used within a General Multicast Congestion Control (PGMCC) [26]) 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 66, line 14 skipping to change at page 67, line 14
transmission. Lower ordinal invalid "object_transport_ids" should be transmission. Lower ordinal invalid "object_transport_ids" should be
included only while the NORM_CMD(SQUELCH) payload is less than the included only while the NORM_CMD(SQUELCH) payload is less than the
sender's NormSegmentSize parameter. sender's NormSegmentSize parameter.
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation
When a NORM sender receives NORM_NACK messages from receivers via When a NORM sender receives NORM_NACK messages from receivers via
unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to
advertise its accumulated repair state to the receiver set since the advertise its accumulated repair state to the receiver set since the
receiver set is not directly sharing their repair needs via multicast receiver set is not directly sharing their repair needs via multicast
communication. The NORM_CMD(REPAIR_ADV) message is multicast to the communication. A NORM sender implementation MAY use a separate port
number from the NormSession port number as the source port for its
transmissions. Thus NORM receivers can direct any _unicast_ feedback
messages to this sender port number that is distinct from the
"session" port number. Then, the NORM sender implementation can
discriminate unicast feedback messages from multicast feedback
messages when there is a mix of multicast and unicast feedback
receivers. The NORM_CMD(REPAIR_ADV) message is multicast to the
receiver set by the sender. The payload portion of this message has receiver set by the sender. The payload portion of this message has
content in the same format as the NORM_NACK receiver message payload. content in the same format as the NORM_NACK receiver message payload.
Receivers are then able to perform feedback suppression in the same Receivers are then able to perform feedback suppression in the same
manner as with NORM_NACK messages directly received from other manner as with NORM_NACK messages directly received from other
receivers. Note the sender does not merely retransmit NACK content receivers. Note the sender does not merely retransmit NACK content
it receives, but instead transmits a representation of its aggregated it receives, but instead transmits a representation of its aggregated
repair state. The transmission of NORM_CMD(REPAIR_ADV) messages are repair state. The transmission of NORM_CMD(REPAIR_ADV) messages are
subject to the sender transmit rate limit and NormSegmentSize subject to the sender transmit rate limit and NormSegmentSize
limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum limitation. When the NORM_CMD(REPAIR_ADV) message is of maximum
size, receivers SHALL consider the maximum ordinal transmission size, receivers SHALL consider the maximum ordinal transmission
skipping to change at page 68, line 14 skipping to change at page 69, line 21
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
[6]. This congestion control scheme is REQUIRED for operation within [6]. This congestion control scheme is REQUIRED for operation within
the general Internet unless the NORM implementation is adapted to use the general Internet unless the NORM implementation is adapted to use
another IETF-sanctioned reliable multicast congestion control another IETF-sanctioned reliable multicast congestion control
mechanism (e.g., PGMCC [23]). With this TFMCC-based approach, the mechanism (e.g., PGMCC [26]). 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 [24], a steady-state sender transmission rate, to be As described in [27], 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
exponentially weighted moving average (EWMA) of transmitted exponentially weighted moving average (EWMA) of transmitted
packet sizes to account for variable message sizes). packet sizes to account for variable message sizes).
tRTT = The RTT estimate of the current "current limiting receiver" tRTT = The RTT estimate of the current "current limiting receiver"
(CLR). (CLR).
skipping to change at page 74, line 29 skipping to change at page 75, line 32
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 [21], the estimation of currently selected CLR. As noted in [24], 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 34 skipping to change at page 80, line 37
The same security considerations that apply to the NORM, TFMCC, and The same security considerations that apply to the NORM, TFMCC, and
FEC Building Blocks also apply to the NORM protocol. In addition to FEC Building Blocks also apply to the NORM protocol. In addition to
vulnerabilities that any IP and IP multicast protocol implementation vulnerabilities that any IP and IP multicast protocol implementation
may be generally subject to, the NACK-based feedback of NORM may be may be generally subject to, the NACK-based feedback of NORM may be
exploited by replay attacks which force the NORM sender to exploited by replay attacks which force the NORM sender to
unnecessarily transmit repair information. This MAY be addressed by unnecessarily transmit repair information. This MAY be addressed by
network layer IP security implementations that guard against this network layer IP security implementations that guard against this
potential security exploitation. The NORM protocol is compatible potential security exploitation. The NORM protocol is compatible
with the use of the IP security (IPsec) architecture described in with the use of the IP security (IPsec) architecture described in
[25]. It is RECOMMENDED that such IP security mechanisms be used [7]. and the IPSec Encapsulating Security Payload (ESP) protocol or
when available. Another possible approach is for NORM senders to use Authentication Header (AF) extension MAY be used to secure IP packets
the "sequence" field from the NORM Common Message Header to detect transmitted by NORM participants.
replay attacks. This can be accomplished if the NORM sender is
willing to maintain state on receivers which are NACKing. A cache of Alternatively, a header extension may be applied to the NORM protocol
such receiver state can be used to provide protection against NACK to provide authentication of NORM messages. For this purpose the
replay attacks. NORM receivers SHOULD also also maintain similar EXT_AUTH header extension (HET = 1) is defined. The format of this
state for protection against possible replay of other receiver header extension and its processing is outside the scope of this
messages as well. For example, a receiver could be suppressed from 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
also provide for encryption of NORM message payloads as well as
authentication. The use of this approach as compared to IPSec can
allow for header compression techniques to be applied jointly to IP
and NORM protocol headers. In cases where security analysis deems
that encryption of NORM protocol header content is beneficial or
necessary, the aforementioned use of IPSec ESP may be more
appropriate. If EXT_AUTH is present, whatever packet authentication
checks that can be performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and performing any
congestion control-related action on it. Some packet authentication
schemes impose a delay of several seconds between when a packet is
received and when the packet is fully authenticated. Any congestion
control related action that is appropriate MUST NOT be postponed by
any such full packet authentication.
It is RECOMMENDED that such security mechanisms be used when
available. It should be noted that NORM participants can use the
"sequence" field from the NORM Common Message Header to detect replay
attacks. This can be accomplished if the NORM sender is willing to
maintain state on receivers which are NACKing. A cache of such
receiver state can be used to provide protection against NACK replay
attacks. NORM receivers SHOULD also also maintain similar state for
protection against possible replay of other receiver messages in ASM
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 confidientiality of application data and of messages to provide confidientiality 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 Secure RECOMMENDED that an approach such as described in the Group Domain of
Association Key Management Protocol (GSAKMP) [26] for automated key Interpretation (GDOI) [28], Multimedia Internet KEYing (MIKEY) [29]
management is applied. or Group Secure Association Key Management Protocol (GSAKMP) [30]
specifications for automated key management is 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 does not alone guarantee integrity of repair for scalability, this does not alone 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
This section describes a baseline mode of secure NORM protocol
operation based on application of the IPSec security protocol. This
approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to NORM
security, including other forms of IPSec application, MAY be
specified in the future. For example, the use of the EXT_AUTH header
extension could enable NORM-specific authentication or security
encapsulation headers similar to those of IPSec to be specified and
inserted into the NORM protocol message headers. This would allow
header compression techniques to be applied to IP and NORM protocol
headers when needed in a similar fashion to that of RTP [22] and as
preserved in the specification for Secure Real Time Protocol (SRTP)
[23]. The baseline approach described is applicable to NORM
operation configured for SSM (or SSM-like) operation where there is a
single sender and the receivers are providing unicast feedback. This
form of NORM operation allows for IPSec to be used with a manageable
number of security associations (SA).
6.1.1. IPSec Approach
For NORM one-to-many SSM operation with unicast feedback from
receivers, each node SHALL be configured with two transport mode
IPSec security associations and corresponding Security Policy
Database (SDP) entries. One entry will be used for sender-to-group
multicast packet authentication and optionally encryption while the
other entry will be used to provide security for the unicast feedback
messaging from the receiver(s) to the sender.
The NORM sender SHALL use an IPSec SA configured for ESP protocol [8]
operation with the option for data origination authentication
enabled. It is also RECOMMENDED that this IPSec ESP SA be also
configured to provide confidentiality protection for IP packets
containing NORM protocol messages. This is suggested to make the
realization of complex replay attacks much more difficult. The
encryption key for this SA SHALL be preplaced at the sender and
receiver(s) prior to NORM protocol operation. Use of automated key
management is RECOMMENDED as a rekey SHALL be required prior to
expiration of the sequence space for the SA. This is necessary so
that receivers may use the built-in IPSec replay attack protection
possible for an IPSec SA with a single source (the NORM sender).
Thus the receivers SHALL enable replay attack protection for this SA
used to secure NORM sender traffic. An IPSec SPD entry MUST be
configured to process outbound packets to the session (destination)
address and UDP port number of the applicable (NormSession).
The NORM receiver(s) MUST be configured with the SA and SPD entry to
properly process the IPSec-secured packets from the sender. The NORM
receiver(s) SHALL also use a common, second IPSec SA (common Security
Parameter Index (SPI) and encryption key) configured for ESP
operation with the option for data origination authentication
enabled. Similar to the NORM sender, is is RECOMMENDED this IPSec
ESP SA be also configured to provide confidentiality protection for
IP packets containing NORM protocol messages. The receivers MUST
have an IPSec SPD entry configured to process outbound NORM/UDP
packets directed to the NORM sender source address and port number
using this second SA. As noted for NORM unicast feedback, the
sender's transmission port number SHOULD be distinct from the
multicast session port number to allow discrimination between unicast
and multicast feedback messages when access to the IP destination
address is not possible (e.g., a user-space NORM implementation).
For processing of packets from receivers, the NORM sender SHALL be
configured with this common, second SA (and the corresponding SPD
entry needed) in order to properly process messages from the
receiver. Note that built-in IPSec replay attack protection for this
second SA at the sender MUST be disabled.
Multiple receivers using a common IPSec SA for traffic directed to
the NORM sender (i.e., many-to-one) prevents the use of built-in
IPSec replay attack protection by the NORM sender with current IPSec
implementations. So, to support a fully secure mode of operation,
the NORM sender implementation MUST provide replay attack protection
based upon the "sequence" field of NORM protocol messages from
receivers. This can be accomplished with high assurance of security,
even with the limited size (16-bits) of this field, because
1) NORM receiver NACK and non-CLR ACK feedback messages are
sparse.
2) The more frequent NORM ACK feedback from CLR or PLR nodes
are only a small set of receivers for which the sender must
keep more persistent replay attack state.
3) NORM NACK feedback messages that precede the sender's
current repair window do not significantly impact protocol
operation (generation of NORM_CMD(SQUELCH) is limited) and
could be in fact ignored. This means the sender can prune
any replay attack state for receivers that precede the
current repair window.
4) NORM ACK messages correspond to either a specific sender
"ack_id", the sender "cc_sequence" for ACKs sent in response
to NORM_CMD(CC), or the sender's current repair window in
the case of ACKs sent in response to NORM_CMD(FLUSH). Thus,
the sender can prune any replay attack state for receivers
that precede the current applicable sequence or repair
window space.
Note that use of ESP confidentiality, as RECOMMENDED, for secure NORM
protocol operation makes it more difficult for adversaries to conduct
effective replay attacks. Additionally, it should be noted that a
NORM sender implementation with access to the full ESP protocol
header could also use the ESP sequence information to make this form
of replay attack protection even more robust. The design of this
baseline security approach for NORM intentionally places any more
complex processing state or processing (e.g. replay attack protection
given multiple receivers) at the NORM sender since NORM receiver
implementations may need to have a more "light-weight" realization in
many cases.
This baseline approach can be used for NORM protocol sessions with
multiple senders if the SA pairs described are established for each
sender. For small-sized groups, it is even possible that many-to-
many (ASM) IPSec configuration could be achieved where each
participant uses a unique SA (with a unique SPI). This does not
scale to larger group sizes given the complex set of SA and SPD
entries each participant would need to maintain.
It is anticipated in early deployments of this baseline approach to
NORM security that key management will be conducted out-of-band with
respect to NORM protocol operation. In the case of one-to-many NORM
operation, it is possible that receivers may retrieve keying
information from a central server as needed or otherwise conduct
group key updates with a similar centralized approach. However, it
may be possible with some key management schemes for rekey messages
to be transmitted to the group as a message or transport object
within the NORM reliable transfer session. Similarly, for group-wise
communication sessions it is possible that potential group
participants may request keying and/or rekeying as part of NORM
communications. Additional specification is necessary to define an
in-band key managment scheme for NORM sessions perhaps using the
mechanisms of the automated group key management specifications cited
in this document.
6.1.2. IPSec Requirements
In order to implement this secure mode of NORM protocol operation,
the following IPSec capabilities are required.
6.1.2.1. Selectors
The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD.
6.1.2.2. Mode
IPSec in transport mode MUST be supported. The use of IPSec
processing for secure NORM traffic SHOULD also be "required" such
that unauthenticated packets are not received by the NORM protocol
implementation. [7].
6.1.2.3. Key Management
An automated key management scheme for group key distribution and
rekeying such as GDOI [28], GSAKMP [30], or MIKEY [29] SHOULD be
used. Relatively short-lived NORM sessions MAY be able to use Manual
Keying with a single, preplaced key, particularly if Extended
Sequence Numbering (ESN) [8] is available in the IPSec 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 included in the
NORM application reliable data transmission if appropriate interfaces
were available between the NORM application and the key management
daemon.
6.1.2.4. Security Policy
Receivers SHOULD accept connections only from the designated,
authorized sender(s). It is expected that appropriate key management
will provide encryption keys only to receivers authorized to
participate in a designated session. The approach outlined here
allows receiver sets to be controlled on a per-sender basis.
6.1.2.5. Authentication and Encryption
Large NORM group sizes will necessitate some form of key management
that does rely upon shared secrets. The GDOI and GSAKMP protocols
mentioned here allow for certificate-based authentication. These
certificates SHOULD use IP addresses for authentication although it
may alternatively possible to have authentication associated with
pre-assigned NormNodeId values. However, it is likely that available
group key management implementations will not be NORM-specific.
6.1.2.6. Availability
The IPSec requirements profile outlined here is commonly available on
many potential NORM hosts. The principal issue is that configuration
and operation of IPSec typically requires privileged user
authorization. Automated key management implementations are
typically configured with the privileges necessary to effect system
IPSec configuration needed.
7. IANA Considerations 7. IANA Considerations
Header extension identifiers for the NORM protocol are subject to Header extension identifiers for the NORM protocol are subject to
IANA registration. Additionally, building blocks components used by IANA registration. Additionally, building blocks components used by
this NORM Protocol specification may introduce additional IANA this NORM Protocol specification may introduce additional IANA
considerations. In particular, the FEC Building Block used by NORM considerations. In particular, the FEC Building Block used by NORM
does require IANA registration of the FEC codecs used. The does require IANA registration of the FEC codecs used. The
registration instructions for FEC codecs are provided in [5]. registration instructions for FEC codecs are provided in [5].
7.1. 7.1.
skipping to change at page 80, line 32 skipping to change at page 86, line 20
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 indentifier value assignment requests are granted on a extension indentifier value assignment requests are granted on a
"Specification Required" basis as defined in [7]. Additional header "Specification Required" basis as defined in [9]. Additional header
extension specifications MUST include a description of protocol extension specifications MUST include a description of protocol
actions to be taken when the the extended header is encountered by a actions to be taken when the the extended header is encountered by a
protocol implementation not supporting that specific option. For protocol implementation not supporting that specific option. For
example, it may be possible for protocol implementations to ignore example, it may be possible for protocol implementations to ignore
unknown header extensions in many cases. 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":
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
|Value | Name | Reference | |Value | Name | Reference |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| 1 | EXT_AUTH | This specification |
+------+-----------+-----------------------------------------------+
| 3 | EXT_CC | This specification | | 3 | EXT_CC | This specification |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| 64 | EXT_FTI | This specification | | 64 | EXT_FTI | This specification |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| 128 | EXT_RATE | 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
skipping to change at page 81, line 50 skipping to change at page 87, line 29
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. Changes from RFC3940 9. Changes from RFC3940
This section lists the changes between the Experimental version of This section lists the changes between the Experimental version of
this specification, [8], and this version: this specification, [10], and this version:
1) Removal of the NORM_FLAG_MSG_START for NORM_OBJECT_STREAM, 1) Removal of the NORM_FLAG_MSG_START for NORM_OBJECT_STREAM,
replacing it with the "payload_msg_start" field in the FEC- replacing it with the "payload_msg_start" field in the FEC-
encoded preamble of the NORM_OBJECT_STREAM NORM_DATA payload, encoded preamble of the NORM_OBJECT_STREAM NORM_DATA payload,
2) Definition of IANA namespace for header extension assignment, 2) Definition of IANA namespace for header extension assignment,
3) Removal of file blocking scheme description that is now 3) Removal of file blocking scheme description that is now
specified in the FEC Building Block document [5], specified in the FEC Building Block document [5],
4) Removal of restriction of NORM receiver feedback message rate 4) Removal of restriction of NORM receiver feedback message rate
to local NORM sender rate (this caused congestion control to local NORM sender rate (this caused congestion control
failures in high speed operation and the extremely low failures in high speed operation and the extremely low
feedback rate of the NORM protocol as compared to TCP avoids feedback rate of the NORM protocol as compared to TCP avoids
any resultant impact to the network [27]), any resultant impact to the network [31]),
5) Correction of errors in some message format descriptions, and 5) Correction of errors in some message format descriptions, and
6) Correction of inconsistency in specification of the inactivity 6) Correction of inconsistency in specification of the inactivity
timeout. timeout.
7) Addition of IPSec secure mode description with IPSec
requirements.
8) Clarification of interpretation of "Source Block Length" when
FEC codes are arbitrarily shortened by the sender.
10. Acknowledgments (and these are not Negative) 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.
11. References 11. References
skipping to change at page 83, line 12 skipping to change at page 88, line 45
Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb- Negative-Acknowledgement (NACK) Building Blocks", draft-ietf-rmt-bb-
norm-revised-02, September 2006. norm-revised-02, September 2006.
[5] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction [5] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction
(FEC) Building Block", draft-ietf-rmt-fec-bb-revised-03, January (FEC) Building Block", draft-ietf-rmt-fec-bb-revised-03, January
2006. 2006.
[6] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion [6] J. Widmer and M. Handley, "TCP-Friendly Multicast Congestion
Control (TFMCC) Protocol Specification", RFC 4654, August 2006. Control (TFMCC) Protocol Specification", RFC 4654, August 2006.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [7] S. Kent and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[8] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC 4303,
December 2005.
[9] 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.
11.2. Informative References 11.2. Informative References
[8] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative- [10] Adamson, B., Bormann, C., Handley, M., and J. Macker, "Negative-
Acknowledgement (NACK)-Oriented Reliable Multicast (NORM) Protocol", Acknowledgement (NACK)-Oriented Reliable Multicast (NORM) Protocol",
RFC 3940, November 2004. RFC 3940, November 2004.
[9] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", [11] Handley, M. and V. Jacobson, "SDP: Session Description
RFC 2327, April 1998. Protocol", RFC 2327, April 1998.
[10] Handley, M., Perkins, C., and E. Whelan, "Session Announcement [12] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000. Protocol", RFC 2974, October 2000.
[11] S. Pingali, D. Towsley, J. Kurose, "A Comparison of Sender- [13] 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.
[12] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and [14] 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.
[13] Macker, J. and B. Adamson, "The Multicast Dissemination Protocol [15] 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.
[14] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback", [16] Nonnenmacher, J. and E. Biersack, "Optimal Multicast Feedback",
Proc. IEEE INFOCOMM, p. 964, March/April 1998. Proc. IEEE INFOCOMM, p. 964, March/April 1998.
[15] J. Macker, B. Adamson, "Quantitative Prediction of Nack Oriented [17] 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.
[16] H.W. Holbrook, "A Channel Model for Multicast", Ph.D. [18] 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.
[17] D. Gossink, J. Macker, "Reliable Multicast and Integrated Parity [19] 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.
[18] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd, S., [20] 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.
[19] Mankin, A., Romanow, A., Bradner, S., and V. Paxson, "IETF [21] 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.
[20] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, [22] 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.
[21] J. Widmer and M. Handley, "Extending Equation-Based Congestion [23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real Time Transport Protocol", RFC 3711, March
2004.
[24] 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.
[22] Watson, M., "Basic Forward Error Correction (FEC) Schemes", [25] Watson, M., "Basic Forward Error Correction (FEC) Schemes",
Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-02, March Internet-Draft draft-ietf-rmt-bb-fec-basic-schemes-revised-02, March
2006. 2006.
[23] L. Rizzo, "pgmcc: A TCP-Friendly Single-Rate Multicast [26] 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.
[24] J. Padhye, V. Firoiu, D. Towsley, and J. Kurose, "Modeling TCP [27] 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.
[25] Kent, S. and R. Atkinson, "Security Architecture for the [28] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group
Internet Protocol", RFC 2401, November 1998. Domain of Interpretation", RFC 3547, July 2003.
[26] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP: [29] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, August 2004.
[30] Harney, H., Meth, U., Colegrove, A., and G. Gross, "GSAKMP:
Group Secure Association Key Management Protocol", RFC 4535, June Group Secure Association Key Management Protocol", RFC 4535, June
2006. 2006.
[27] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism [31] Adamson, B. and J. Macker, "A TCP-Friendly, Rate-based Mechanism
for NACK-Oriented Reliable Multicast Congestion Control", IEEE for NACK-Oriented Reliable Multicast Congestion Control", IEEE
GLOBECOMM 2001, November 2001. GLOBECOMM 2001, November 2001.
12. Author Addresses 12. Author 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
skipping to change at page 86, line 7 skipping to change at page 92, line 7
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
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Trust (2007).
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, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 65 change blocks. 
134 lines changed or deleted 411 lines changed or added

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