draft-ietf-rmt-pi-norm-revised-09.txt   draft-ietf-rmt-pi-norm-revised-10.txt 
Network Working Group B. Adamson Network Working Group B. Adamson
Internet-Draft Naval Research Laboratory Internet-Draft Naval Research Laboratory
Obsoletes: 3940 (if approved) C. Bormann Obsoletes: 3940 (if approved) C. Bormann
Intended status: Standards Track Universitaet Bremen TZI Intended status: Standards Track Universitaet Bremen TZI
Expires: September 10, 2009 M. Handley Expires: October 22, 2009 M. Handley
University College London University College London
J. Macker J. Macker
Naval Research Laboratory Naval Research Laboratory
March 9, 2009 April 20, 2009
NACK-Oriented Reliable Multicast Protocol NACK-Oriented Reliable Multicast Protocol
draft-ietf-rmt-pi-norm-revised-09 draft-ietf-rmt-pi-norm-revised-10
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 September 10, 2009. This Internet-Draft will expire on October 22, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 2, line 35 skipping to change at page 3, line 5
Control Protocol (TCP). It is capable of operating with both Control Protocol (TCP). It is capable of operating with both
reciprocal multicast routing among senders and receivers and with reciprocal multicast routing among senders and receivers and with
asymmetric connectivity (possibly a unicast return path) between the asymmetric connectivity (possibly a unicast return path) between the
senders and receivers. The protocol offers a number of features to senders and receivers. The protocol offers a number of features to
allow different types of applications or possibly other higher level allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways. The transport protocols to utilize its service in different ways. The
protocol leverages the use of FEC-based repair and other IETF protocol leverages the use of FEC-based repair and other IETF
reliable multicast transport (RMT) building blocks in its design. reliable multicast transport (RMT) building blocks in its design.
This document obsoletes RFC 3940. This document obsoletes RFC 3940.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction and Applicability . . . . . . . . . . . . . . . . 5 1. Introduction and Applicability . . . . . . . . . . . . . . . . 5
1.1. NORM Data Delivery Service Model . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.2. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 8 1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 6
1.3. Environmental Requirements and Considerations . . . . . . 9 1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 8
1.4. Environmental Requirements and Considerations . . . . . . 9
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9
2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 11 2.1. Protocol Operation Overview . . . . . . . . . . . . . . . 11
2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 13 2.2. Protocol Building Blocks . . . . . . . . . . . . . . . . . 13
2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . 13 2.3. Design Tradeoffs . . . . . . . . . . . . . . . . . . . . . 13
3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14 3. Conformance Statement . . . . . . . . . . . . . . . . . . . . 14
4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. NORM Common Message Header and Extensions . . . . . . . . 16 4.1. NORM Common Message Header and Extensions . . . . . . . . 16
4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 19 4.2. Sender Messages . . . . . . . . . . . . . . . . . . . . . 19
4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 19 4.2.1. NORM_DATA Message . . . . . . . . . . . . . . . . . . 19
4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 29 4.2.2. NORM_INFO Message . . . . . . . . . . . . . . . . . . 29
4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 30 4.2.3. NORM_CMD Messages . . . . . . . . . . . . . . . . . . 30
4.3. Receiver Messages . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 53 4.3.2. NORM_ACK Message . . . . . . . . . . . . . . . . . . . 54
4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 55 4.4. General Purpose Messages . . . . . . . . . . . . . . . . . 56
4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 55 4.4.1. NORM_REPORT Message . . . . . . . . . . . . . . . . . 56
5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 55 5. Detailed Protocol Operation . . . . . . . . . . . . . . . . . 56
5.1. Sender Initialization and Transmission . . . . . . . . . . 57 5.1. Sender Initialization and Transmission . . . . . . . . . . 58
5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 58 5.1.1. Object Segmentation Algorithm . . . . . . . . . . . . 59
5.2. Receiver Initialization and Reception . . . . . . . . . . 59 5.2. Receiver Initialization and Reception . . . . . . . . . . 60
5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 59 5.3. Receiver NACK Procedure . . . . . . . . . . . . . . . . . 60
5.4. Sender NACK Processing and Response . . . . . . . . . . . 61 5.4. Sender NACK Processing and Response . . . . . . . . . . . 62
5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 62 5.4.1. Sender Repair State Aggregation . . . . . . . . . . . 63
5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 63 5.4.2. Sender FEC Repair Transmission Strategy . . . . . . . 64
5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 64 5.4.3. Sender NORM_CMD(SQUELCH) Generation . . . . . . . . . 65
5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 64 5.4.4. Sender NORM_CMD(REPAIR_ADV) Generation . . . . . . . . 65
5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 65 5.5. Additional Protocol Mechanisms . . . . . . . . . . . . . . 66
5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 65 5.5.1. Greatest Round-trip Time Collection . . . . . . . . . 66
5.5.2. NORM Congestion Control Operation . . . . . . . . . . 66 5.5.2. NORM Congestion Control Operation . . . . . . . . . . 67
5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 74 5.5.3. NORM Positive Acknowledgment Procedure . . . . . . . . 75
5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 76 5.5.4. Group Size Estimate . . . . . . . . . . . . . . . . . 77
6. Security Considerations . . . . . . . . . . . . . . . . . . . 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 77
6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 78 6.1. Baseline Secure NORM Operation . . . . . . . . . . . . . . 79
6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 78 6.1.1. IPsec Approach . . . . . . . . . . . . . . . . . . . . 79
6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 81 6.1.2. IPsec Requirements . . . . . . . . . . . . . . . . . . 82
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83
7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 82 7.1. Explicit IANA Assignment Guidelines . . . . . . . . . . . 83
8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 83 7.1.1. NORM Header Extension Types . . . . . . . . . . . . . 83
9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 83 7.1.2. NORM Stream Control Codes . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 7.1.3. NORM_CMD Message Sub-types . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8. Suggested Use . . . . . . . . . . . . . . . . . . . . . . . . 86
11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 9. Changes from RFC3940 . . . . . . . . . . . . . . . . . . . . . 86
11.2. Informative References . . . . . . . . . . . . . . . . . . 85 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 87
11.1. Normative References . . . . . . . . . . . . . . . . . . . 87
11.2. Informative References . . . . . . . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
1. Introduction and Applicability 1. Introduction and Applicability
The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM) The Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol is designed to provide reliable transport of data from one protocol is designed to provide reliable transport of data from one
or more sender(s) to a group of receivers over an IP multicast or more sender(s) to a group of receivers over an IP multicast
network. The primary design goals of NORM are to provide efficient, network. The primary design goals of NORM are to provide efficient,
scalable, and robust bulk data (e.g., computer files, transmission of scalable, and robust bulk data (e.g., computer files, transmission of
persistent data) transfer across possibly heterogeneous IP networks persistent data) transfer across possibly heterogeneous IP networks
and topologies. The NORM protocol design provides support for and topologies. The NORM protocol design provides support for
skipping to change at page 5, line 31 skipping to change at page 5, line 31
multicast session. NORM is designed to be self-adapting to a wide multicast session. NORM is designed to be self-adapting to a wide
range of dynamic network conditions with little or no pre- range of dynamic network conditions with little or no pre-
configuration. The protocol is purposely designed to be tolerant of configuration. The protocol is purposely designed to be tolerant of
inaccurate timing estimations or lossy conditions that may occur in inaccurate timing estimations or lossy conditions that may occur in
many networks including mobile and wireless. The protocol is also many networks including mobile and wireless. The protocol is also
designed to exhibit convergence and efficient operation even in designed to exhibit convergence and efficient operation even in
situations of heavy packet loss and large queuing or transmission situations of heavy packet loss and large queuing or transmission
delays. This document obsoletes RFC 3940. delays. This document obsoletes RFC 3940.
This document is a product of the IETF RMT WG and follows the This document is a product of the IETF RMT WG and follows the
guidelines provided in [RFC3269]. guidelines provided in RFC 3269.
Statement of Intent Statement of Intent
This memo contains the definitions necessary to fully specify a This memo contains the definitions necessary to fully specify a
Reliable Multicast Transport protocol in accordance with the criteria Reliable Multicast Transport protocol in accordance with the criteria
of [RFC2357]. A prior document, [RFC3940], contained a previous of RFC 2357. A prior document, RFC 3940, contained a previous
description of the NORM Protocol specification described in this description of the NORM Protocol specification described in this
document. RFC3940 was published in the "Experimental" category. It document. RFC3940 was published in the "Experimental" category. It
was the stated intent of the RMT working group to re-submit this was the stated intent of the RMT working group to re-submit this
specifications as an IETF Proposed Standard in due course. specifications as an IETF Proposed Standard in due course.
This Proposed Standard specification is thus based on [RFC3940] and This Proposed Standard specification is thus based on RFC 3940 and
has been updated according to accumulated experience and growing 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] and this document are listed in The differences between RFC 3940 and this document are listed in
Section 9. Section 9.
1.1. NORM Data Delivery Service Model 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
1.2. NORM Data 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
skipping to change at page 8, line 10 skipping to change at page 8, line 16
To summarize, the NORM protocol provides reliable transport of To summarize, the NORM protocol provides reliable transport of
different types of data content (including potentially mixed types). different types of data content (including potentially mixed types).
The senders enqueue and transmit bulk content in the form of static The senders enqueue and transmit bulk content in the form of static
data or files and/or non-finite, ongoing stream types. NORM senders data or files and/or non-finite, ongoing stream types. NORM senders
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.3. 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 [RmComparison]. NORM is a protocol for reliability is required [RmComparison]. NORM is a protocol
centered around the use of selective NACKs to request repairs of centered around the use of selective NACKs to request repairs of
missing data. NORM provides for the use of packet-level forward missing data. NORM provides for the use of packet-level forward
error correction (FEC) techniques for efficient multicast repair and error correction (FEC) techniques for efficient multicast repair and
optional proactive transmission robustness [RFC3453]. FEC-based optional proactive transmission robustness [RFC3453]. FEC-based
repair can be used to greatly reduce the quantity of reliable repair can be used to greatly reduce the quantity of reliable
multicast repair requests and repair transmissions [MdpToolkit] in a multicast repair requests and repair transmissions [MdpToolkit] in a
skipping to change at page 9, line 5 skipping to change at page 9, line 9
feedback than a single TCP connection, even with relatively large feedback than a single TCP connection, even with relatively large
numbers of receivers. Thus, depending upon the network topology, it numbers of receivers. Thus, depending upon the network topology, it
is possible that NORM may scale to larger group sizes. With respect is possible that NORM may scale to larger group sizes. With respect
to computer resource usage, the NORM protocol does NOT require that to computer resource usage, the NORM protocol does NOT require that
state be kept on all receivers in the group. NORM senders maintain state be kept on all receivers in the group. NORM senders maintain
state only for receivers providing explicit congestion control state only for receivers providing explicit congestion control
feedback. However, NORM receivers must maintain state for each feedback. However, NORM receivers must maintain state for each
active sender. This may constrain the number of simultaneous senders active sender. This may constrain the number of simultaneous senders
in some uses of NORM. in some uses of NORM.
1.3. Environmental Requirements and Considerations 1.4. Environmental Requirements and Considerations
All of the environmental requirements and considerations that apply All of the environmental requirements and considerations that apply
to the RMT Multicast NACK Building Block[RFC5401], FEC Building to the RMT Multicast NACK Building Block[RFC5401], FEC Building
Block[RFC5052], and TCP-Friendly Multicast Congestion Control (TFMCC) Block[RFC5052], and TCP-Friendly Multicast Congestion Control (TFMCC)
Building Block[RFC4654], also apply to the NORM protocol. Building Block[RFC4654], also apply to the NORM protocol.
The NORM protocol SHALL be capable of operating in an end-to-end The NORM protocol SHALL be capable of operating in an end-to-end
fashion with no assistance from intermediate systems beyond basic IP fashion with no assistance from intermediate systems beyond basic IP
multicast group management, routing, and forwarding services. While multicast group management, routing, and forwarding services. While
the techniques utilized in NORM are principally applicable to flat, the techniques utilized in NORM are principally applicable to flat,
end-to-end IP multicast topologies, they could also be applied in the end-to-end IP multicast topologies, they could also be applied in the
sub-levels of hierarchical (e.g., tree-based) multicast distribution sub-levels of hierarchical (e.g., tree-based) multicast distribution
if so desired. NORM can make use of reciprocal (among senders and if so desired. NORM can make use of reciprocal (among senders and
receivers) multicast communication under the Any-Source Multicast receivers) multicast communication under the Any-Source Multicast
(ASM) model defined in [RFC1112], but SHALL also be capable of (ASM) model defined in RFC 1112, but SHALL also be capable of
scalable operation in asymmetric topologies such as [RFC4607] where scalable operation in asymmetric topologies such as Source-Specific
there may only be unicast routing service from the receivers to the Multicast (SSM)[RFC4607] where there may only be unicast routing
sender(s). service 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
A NormSession is comprised of participants (NormNodes) acting as A NormSession is comprised of participants (NormNodes) acting as
skipping to change at page 13, line 12 skipping to change at page 13, line 16
acknowledgment from receivers, other "NORM_ACK" messages are defined acknowledgment from receivers, other "NORM_ACK" messages are defined
and available for use. and available for use.
2.2. Protocol Building Blocks 2.2. Protocol Building Blocks
The operation of the NORM protocol is based primarily upon the The operation of the NORM protocol is based primarily upon the
concepts presented in the Multicast NACK Building Block concepts presented in the Multicast NACK Building Block
document[RFC5401]. This includes the basic NORM architecture and the document[RFC5401]. This includes the basic NORM architecture and the
data transmission, repair, and feedback strategies discussed in that data transmission, repair, and feedback strategies discussed in that
document. Additional reliable multicast building blocks, as document. Additional reliable multicast building blocks, as
described in [RFC3048], are applied in creating the full NORM described in RFC 3048, are applied in creating the full NORM protocol
protocol instantiation . NORM also makes use of Forward Error instantiation . NORM also makes use of Forward Error Correction
Correction encoding techniques for repair messaging and optional encoding techniques for repair messaging and optional transmission
transmission robustness as described in [RFC3453]. NORM uses the FEC robustness as described in RFC 3453. NORM uses the FEC Payload ID as
Payload ID as specified by the FEC Building Block document [RFC5052]. specified by the FEC Building Block document [RFC5052].
Additionally, for congestion control, this document fully specifies a Additionally, for congestion control, this document fully specifies a
baseline congestion control mechanism (NORM-CC) based on the TCP- baseline congestion control mechanism (NORM-CC) based on the TCP-
Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] scheme and Friendly Multicast Congestion Control (TFMCC) [TfmccPaper] scheme and
[RFC4654]. RFC 4654.
2.3. Design Tradeoffs 2.3. Design Tradeoffs
While the various features of NORM are designed to provide some While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering trade-offs involved transport arena. There are numerous engineering trade-offs involved
in reliable multicast transport design and this requires an increased in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations. awareness of application and network architecture considerations.
Performance requirements affecting design can include: group size, Performance requirements affecting design can include: group size,
skipping to change at page 14, line 15 skipping to change at page 14, line 19
Large buffer sizes allow the NORM protocol to perform most Large buffer sizes allow the NORM protocol to perform most
efficiently in large delay-bandwidth topologies and allow for longer efficiently in large delay-bandwidth topologies and allow for longer
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 [RFC5401] and [RFC5052], completely Building Block documents of RFC 5401 and RFC 5052, completely
specifies a working reliable multicast transport protocol that specifies a working reliable multicast transport protocol that
conforms to the requirements described in RFC 2357 [RFC2357]. conforms to the requirements described in RFC 2357.
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 | | | transmission. Implementations must |
| | support at least one of the | | | support at least one of the |
skipping to change at page 23, line 45 skipping to change at page 23, line 45
course of its transmission within a NORM session, an object is course of its transmission within a NORM session, an object is
uniquely identified by the concatenation of the sender "source_id" uniquely identified by the concatenation of the sender "source_id"
and the given "object_transport_id". Note that "NORM_INFO" messages and the given "object_transport_id". Note that "NORM_INFO" messages
associated with the identified object carry the same associated with the identified object carry the same
"object_transport_id" value. "object_transport_id" value.
The "fec_payload_id" identifies the attached "NORM_DATA" "payload" The "fec_payload_id" identifies the attached "NORM_DATA" "payload"
content. The size and format of the "fec_payload_id" field depends content. The size and format of the "fec_payload_id" field depends
upon the FEC type indicated by the "fec_id" field. These formats are upon the FEC type indicated by the "fec_id" field. These formats are
given in the descriptions of specific FEC schemes such as those given in the descriptions of specific FEC schemes such as those
described in the IETF FEC Basic Schemes specification[RFC5445] described in the IETF FEC Basic Schemes specification[RFC5445] or in
[RFC5445] or in additional FEC Scheme documents that may be defined. additional FEC Scheme documents that may be defined. As an example,
As an example, the format of the "fec_payload_id" format for Small the format of the "fec_payload_id" format for Small Block, Systematic
Block, Systematic codes ("fec_id" = 129) from the FEC Basic Schemes codes ("fec_id" = 129) from the FEC Basic Schemes
specification[RFC5445] is given here: specification[RFC5445] 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 26, line 30 skipping to change at page 26, line 30
The size of the EXT_FTI header extension may be different for other The size of the EXT_FTI header extension may be different for other
FEC schemes. FEC schemes.
The 48-bit "object_size" serves the purpose described previously. The 48-bit "object_size" serves the purpose described previously.
The "fec_instance_id" corresponds to the "FEC Instance ID" described The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [RFC5052]. In this case, the in the FEC Building Block document [RFC5052]. In this case, the
"fec_instance_id" is a value corresponding to the particular type of "fec_instance_id" is a value corresponding to the particular type of
Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8), Small Block Systematic Code being used (e.g., Reed-Solomon GF(2^8),
Reed-Solomon GF(2^16), etc). The standardized assignment of FEC Reed-Solomon GF(2^16), etc). The standardized assignment of FEC
Instance ID values is described in [RFC5052]. Instance ID values is described in RFC 5052.
The "segment_size" field indicates the sender's current setting for The "segment_size" field indicates the sender's current setting for
maximum message payload content (in bytes). This allows receivers to maximum message payload content (in bytes). This allows receivers to
allocate appropriate buffering resources and to determine other allocate appropriate buffering resources and to determine other
information in order to properly process received data messaging. information in order to properly process received data messaging.
Typically, FEC parity symbol segments will be of this size. Typically, FEC parity symbol segments will be of this size.
The "fec_max_block_len" indicates the current maximum number of user The "fec_max_block_len" indicates the current maximum number of user
data segments per FEC coding block to be used by the sender during data segments per FEC coding block to be used by the sender during
the session. This allows receivers to allocate appropriate buffer the session. This allows receivers to allocate appropriate buffer
skipping to change at page 27, line 49 skipping to change at page 27, line 49
The "payload_len" value, when non-zero, indicates the length (in The "payload_len" value, when non-zero, indicates the length (in
bytes) of the source content contained in the associated bytes) of the source content contained in the associated
"payload_data" field. However, when the "payload_len" value is equal "payload_data" field. However, when the "payload_len" value is equal
to ZERO, this indicates that the "payload_msg_start" field should be to ZERO, this indicates that the "payload_msg_start" field should be
alternatively interpreted as a "stream_control_code". The only alternatively interpreted as a "stream_control_code". The only
"stream_control_code" value defined is "NORM_STREAM_END = 0". The "stream_control_code" value defined is "NORM_STREAM_END = 0". The
"NORM_STREAM_END" code indicates that the sender is terminating "NORM_STREAM_END" code indicates that the sender is terminating
transmission of stream content at the corresponding position in the transmission of stream content at the corresponding position in the
stream and the receiver should not expect content (or NACK for any stream and the receiver should not expect content (or NACK for any
content) following that position in the stream. Future versions of content) following that position in the stream. It is expected that
this specification may define additional stream control codes if additional specifications may extend the functionality of the NORM
necessary. stream transport mode by defining additional stream control codes.
These control codes are delivered to the recipient application
reliably, in-order with respect to the streamed application data
content.
The "payload_msg_start" field serves one of two exclusive purposes. The "payload_msg_start" field serves one of two exclusive purposes.
When the "payload_len" value is non-zero, the "payload_msg_start" When the "payload_len" value is non-zero, the "payload_msg_start"
field, when also set to a non-zero value, indicates that the field, when also set to a non-zero value, indicates that the
associated "payload_data" content contains an application-defined associated "payload_data" content contains an application-defined
message boundary (start-of-message). When such a message boundary is message boundary (start-of-message). When such a message boundary is
indicated, the first byte of an application-defined message, with indicated, the first byte of an application-defined message, with
respect to the "payload_data" field, will be found at an offset of respect to the "payload_data" field, will be found at an offset of
"payload_msg_start - 1" bytes. Thus, if a "NORM_DATA" payload for a "payload_msg_start - 1" bytes. Thus, if a "NORM_DATA" payload for a
"NORM_OBJECT_STREAM" contains the start of an application message at "NORM_OBJECT_STREAM" contains the start of an application message at
skipping to change at page 32, line 38 skipping to change at page 33, line 8
A default value of "NORM_ROBUST_FACTOR" equal to 20 is RECOMMENDED. A default value of "NORM_ROBUST_FACTOR" equal to 20 is RECOMMENDED.
If a "NORM_NACK" message interrupts the flush process, the sender If a "NORM_NACK" message interrupts the flush process, the sender
SHALL re-initiate the flush process after any resulting repair SHALL re-initiate the flush process after any resulting repair
transmissions are completed. transmissions are completed.
Note that receivers also employ a timeout mechanism to self-initiate Note that receivers also employ a timeout mechanism to self-initiate
NACKing (if there are outstanding repair needs) when no messages of NACKing (if there are outstanding repair needs) when no messages of
any type are received from a sender. This inactivity timeout is any type are received from a sender. This inactivity timeout is
related to the "NORM_CMD(FLUSH)" and "NORM_ROBUST_FACTOR" and is related to the "NORM_CMD(FLUSH)" and "NORM_ROBUST_FACTOR" and is
specified in Section 5.3. Receivers SHALL self-initiate the NACK specified in Section 5.3. Receivers SHALL self-initiate the NACK
repair process when the inactivity has expired for a specific sender repair process when the inactivity timeout has expired for a specific
and the receiver has pending repairs needed from that sender. With a sender and the receiver has pending repairs needed from that sender.
sufficiently large "NORM_ROBUST_FACTOR" value, data content is With a sufficiently large "NORM_ROBUST_FACTOR" value, data content is
delivered with a high assurance of reliability. The penalty of a delivered with a high assurance of reliability. The penalty of a
large "NORM_ROBUST_FACTOR" value is the potential transmission of large "NORM_ROBUST_FACTOR" value is the potential transmission of
excess "NORM_CMD(FLUSH)" messages and a longer inactivity timeout for excess "NORM_CMD(FLUSH)" messages and a longer inactivity timeout for
receivers to self-initiate a terminal NACK process. receivers to self-initiate a terminal NACK process.
For finite-size transport objects such as "NORM_OBJECT_DATA" and For finite-size transport objects such as "NORM_OBJECT_DATA" and
"NORM_OBJECT_FILE", the flush process (if there are no further "NORM_OBJECT_FILE", the flush process (if there are no further
pending objects) occurs at the end of these objects. Thus, FEC pending objects) occurs at the end of these objects. Thus, FEC
repair information is always available for repairs in response to repair information is always available for repairs in response to
repair requests elicited by the flush command. However, for repair requests elicited by the flush command. However, for
skipping to change at page 37, line 44 skipping to change at page 38, line 35
object transport) to arbitrarily invalidate (i.e., dequeue) portions object transport) to arbitrarily invalidate (i.e., dequeue) portions
of enqueued content (e.g., certain objects) for which it no longer of enqueued content (e.g., certain objects) for which it no longer
wishes to provide reliable transport. wishes to provide reliable transport.
4.2.3.4. NORM_CMD(CC) Message 4.2.3.4. NORM_CMD(CC) Message
The "NORM_CMD(CC)" messages contains fields to enable sender-to- The "NORM_CMD(CC)" messages contains fields to enable sender-to-
receiver group greatest round-trip time (GRTT) measurement and to receiver group greatest round-trip time (GRTT) measurement and to
excite the group for congestion control feedback. A baseline NORM excite the group for congestion control feedback. A baseline NORM
congestion control scheme (NORM-CC), based on the TCP-Friendly congestion control scheme (NORM-CC), based on the TCP-Friendly
Multicast Congestion Control (TFMCC) scheme of [RFC4654] is described Multicast Congestion Control (TFMCC) scheme of RFC 4654 is fully
in Section 5.5.2 of this document. The "NORM_CMD(CC)" message is specified in Section 5.5.2 of this document. The "NORM_CMD(CC)"
usually transmitted as part of NORM-CC congestion control operation. message is usually transmitted as part of NORM-CC congestion control
A NORM header extension is defined below to be used with the operation. A NORM header extension is defined below to be used with
"NORM_CMD(CC)" message to support NORM-CC operation. Different the "NORM_CMD(CC)" message to support NORM-CC operation. Different
header extensions may be defined for the "NORM_CMD(CC)" (and/or other header extensions may be defined for the "NORM_CMD(CC)" (and/or other
NORM messages as needed) to support alternative congestion control NORM messages as needed) to support alternative congestion control
schemes in the future. If NORM is operated in a network where schemes in the future. If NORM is operated in a network where
resources are explicitly dedicated to the NORM session and therefore resources are explicitly dedicated to the NORM session and therefore
congestion control operation is disabled, the "NORM_CMD(CC)" message congestion control operation is disabled, the "NORM_CMD(CC)" message
is then used soley for GRTT measurement and may optionally be sent is then used soley for GRTT measurement and may optionally be sent
less frequently than with congestion control operation. less frequently than with congestion control operation.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=3| hdr_len | sequence | |version| type=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id | | source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize | | instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 4 | reserved | cc_sequence | | flavor = 4 | reserved | cc_sequence |
skipping to change at page 38, line 44 skipping to change at page 39, line 41
header extensions are present is 6. header extensions are present is 6.
The "reserved" field is for potential future use and MUST be set to The "reserved" field is for potential future use and MUST be set to
ZERO in this version of the NORM protocol and its baseline NORM-CC ZERO in this version of the NORM protocol and its baseline NORM-CC
congestion control scheme. It may be possible that alternative congestion control scheme. It may be possible that alternative
congestion control schemes may use the "NORM_CMD(CC)" message defined congestion control schemes may use the "NORM_CMD(CC)" message defined
here and leverage the "reserved" field for scheme-specific purposes. here and leverage the "reserved" field for scheme-specific purposes.
The "cc_sequence" field is a sequence number applied by the sender. The "cc_sequence" field is a sequence number applied by the sender.
For NORM-CC operation, it is used to provide functionality equivalent For NORM-CC operation, it is used to provide functionality equivalent
to the "feedback round number" ("fb_nr")described in [RFC4654]. The to the "feedback round number" ("fb_nr") described in RFC 4654. The
most recently received "cc_sequence" value is recorded by receivers most recently received "cc_sequence" value is recorded by receivers
and can be fed back to the sender in congestion control feedback and can be fed back to the sender in congestion control feedback
generated by the receivers for that sender. The "cc_sequence" number generated by the receivers for that sender. The "cc_sequence" number
can also be used in NORM implementations to assess how recently a can also be used in NORM implementations to assess how recently a
receiver has received "NORM_CMD(CC)" probes from the sender. This receiver has received "NORM_CMD(CC)" probes from the sender. This
can be useful instrumentation for complex or experimental multicast can be useful instrumentation for complex or experimental multicast
routing environments. routing environments.
The "send_time" field is a timestamp indicating the time that the The "send_time" field is a timestamp indicating the time that the
"NORM_CMD(CC)" message was transmitted. This consists of a 64-bit "NORM_CMD(CC)" message was transmitted. This consists of a 64-bit
skipping to change at page 55, line 35 skipping to change at page 56, line 35
"server_id". "server_id".
4.4. General Purpose Messages 4.4. General Purpose Messages
Some additional message formats are defined for general purpose in Some additional message formats are defined for general purpose in
NORM multicast sessions whether the participant is acting as a sender NORM multicast sessions whether the participant is acting as a sender
and/or receiver within the group. and/or receiver within the group.
4.4.1. NORM_REPORT Message 4.4.1. NORM_REPORT Message
This is an optional message generated by NORM participants. This This is an OPTIONAL message generated by NORM participants. This
message could be used for periodic performance reports from receivers message may be used for periodic performance reports from receivers
in experimental NORM implementations. The format of this message is in experimental NORM implementations. The format of this message is
currently undefined. Experimental NORM implementations may define currently undefined. Experimental NORM implementations may define
"NORM_REPORT" formats as needed for test purposes. These report "NORM_REPORT" formats as needed for test purposes. These report
messages SHOULD be disabled for interoperability testing between messages SHOULD be disabled for interoperability testing between
different NORM implementations. different compliant NORM implementations.
5. Detailed Protocol Operation 5. Detailed Protocol Operation
This section describes the detailed interactions of senders and This section describes the detailed interactions of senders and
receivers participating in a NORM session. A simple synopsis of receivers participating in a NORM session. A simple synopsis of
protocol operation is given here: protocol operation is given here:
1. The sender periodically transmits "NORM_CMD(CC)" messages as 1. The sender periodically transmits "NORM_CMD(CC)" messages as
needed to initialize and collect round-trip timing and congestion needed to initialize and collect round-trip timing and congestion
control feedback from the receiver set. control feedback from the receiver set.
skipping to change at page 76, line 48 skipping to change at page 77, line 48
It is possible that group size may be algorithmically approximated It is possible that group size may be algorithmically approximated
from the volume of congestion control feedback messages which follow from the volume of congestion control feedback messages which follow
the exponentially weighted random backoff. However, the the exponentially weighted random backoff. However, the
specification of such an algorithm is currently beyond the scope of specification of such an algorithm is currently beyond the scope of
this document. this document.
6. Security Considerations 6. Security Considerations
The same security considerations that apply to the Multicast The same security considerations that apply to the Multicast
NACK[RFC5401], TFMCC[RFC4654], and FEC[RFC5052] Building Blocks also NACK[RFC5401], TFMCC[RFC4654], and FEC[RFC5052] Building Blocks also
apply to the NORM protocol. In addition to vulnerabilities that any apply to the NORM protocol. In addition to the vulnerabilities that
IP and IP multicast protocol implementation may be generally subject any IP and IP multicast protocol implementation may be generally
to, the NACK-based feedback of NORM may be exploited by replay subject to, the NACK-based feedback of NORM may be exploited by
attacks which force the NORM sender to unnecessarily transmit repair replay attacks which force the NORM sender to unnecessarily transmit
information. This MAY be addressed by network layer IP security repair information. This MAY be addressed by network layer IP
implementations that guard against this potential security security implementations that guard against this potential security
exploitation. The NORM protocol is compatible with the use of IP exploitation or alternatively with a security mechanism that uses the
security (IPsec)[RFC4301] and the IPsec Encapsulating Security "EXT_AUTH" header extension for similar purposes. Such security
Payload (ESP) protocol or Authentication Header (AF) extension MAY be mechanisms SHOULD be deployed and used when available.
used to secure IP packets transmitted by NORM participants.
Alternatively, a header extension may be applied to the NORM protocol The NORM protocol is compatible with the use of IP security
to provide authentication of NORM messages. For this purpose the (IPsec)[RFC4301] and the IPsec Encapsulating Security Payload (ESP)
"EXT_AUTH" header extension (HET = 1) is defined. The format of this protocol or Authentication Header (AF) extension can be used to
header extension and its processing is outside the scope of this secure IP packets transmitted by NORM participants. A baseline
approach to secure NORM operation using IPsec is described below.
Compliant implementations of this specification are REQUIRED to be
compatible with IPsec usage as described in Section 6.1.
Additionally, the "EXT_AUTH" header extension (HET = 1) is defined
for use by security mechanisms to provide an alternative form of
authentication and/or encryption of NORM messages. The format of
this header extension and its processing is outside the scope of this
document and is to be communicated out-of-band as part of the session document and is to be communicated out-of-band as part of the session
description. It is possible that an EXT_AUTH implementation of MAY description. It is possible that an EXT_AUTH implementation of MAY
also provide for encryption of NORM message payloads as well as also provide for encryption of NORM message payloads as well as
authentication. The use of this approach as compared to IPsec can authentication. The use of this approach as compared to IPsec can
allow for header compression techniques to be applied jointly to IP allow for header compression techniques to be applied jointly to IP
and NORM protocol headers. In cases where security analysis deems and NORM protocol headers. In cases where security analysis deems
that encryption of NORM protocol header content is beneficial or that encryption of NORM protocol header content is beneficial or
necessary, the aforementioned use of IPsec ESP may be more necessary, the aforementioned use of IPsec ESP may be more
appropriate. If EXT_AUTH is present, whatever packet authentication appropriate. If EXT_AUTH is present, whatever packet authentication
checks that can be performed immediately upon reception of the packet checks that can be performed immediately upon reception of the packet
SHOULD be performed before accepting the packet and performing any MUST be performed before accepting the packet and performing any
congestion control-related action on it. Some packet authentication congestion control-related action on it. Some packet authentication
schemes impose a delay of several seconds between when a packet is schemes impose a delay of several seconds between when a packet is
received and when the packet is fully authenticated. Any congestion received and when the packet can be fully authenticated. Any
control related action that is appropriate MUST NOT be postponed by congestion control related action that is appropriate MUST NOT be
any such full packet authentication. Consideration SHOULD also be postponed by any such full packet authentication.
given to the potential for replay-attacks that would transplant
authenticated packets from one NORM session to another to disrupt
service. To avoid this potential, unique keys SHOULD be used on a
per-session basis or NORM sender nodes SHOULD use unique
"instance_id" identifiers that are managed as part of the security
association for the sessions.
It is RECOMMENDED that such security mechanisms be used when Consideration MUST also be given to the potential for replay-attacks
available. It should be noted that NORM participants can use the that would transplant authenticated packets from one NORM session to
"sequence" field from the NORM Common Message Header to detect replay another to disrupt service. To avoid this potential, unique keys
attacks. This can be accomplished if the NORM sender is willing to SHOULD be assigned on a per-session basis or NORM sender nodes SHOULD
maintain state on receivers which are NACKing. A cache of such be configured to use unique "instance_id" identifiers that are
receiver state can be used to provide protection against NACK replay managed as part of the security association for the sessions.
attacks. NORM receivers SHOULD also maintain similar state for
protection against possible replay of other receiver messages in ASM It should be noted that NORM implementations can use the "sequence"
operation as well. For example, a receiver could be suppressed from field from the NORM Common Message Header to detect replay attacks.
providing NACK or congestion control feedback by replay of certain This can be accomplished if the NORM sender maintains state on
receiver messages. For these reasons, authentication of NORM receivers which are NACKing. A cache of such receiver state can be
messages (e.g., via IPsec) is RECOMMENDED for protection against used to provide protection against NACK replay attacks. NORM
similar attacks that might use fabricated messages. Also, encryption receivers MUST also maintain similar state for protection against
of messages to provide confidentiality of application data and possible replay of other receiver messages in ASM operation as well.
protect privacy of users MAY also be applied using IPsec or similar For example, a receiver could be suppressed from providing NACK or
mechanisms. When any such cryptographic measures are used, it is congestion control feedback by replay of certain receiver messages.
RECOMMENDED that an approach such as described in the Group Domain of For these reasons, authentication of NORM messages (e.g., via IPsec)
SHOULD be applied for protection against similar attacks that use
fabricated messages. Also, encryption of messages to provide
confidentiality of application data and protect privacy of users MAY
also be applied using IPsec or similar mechanisms.
When any applicable security measures are used, automated key
management mechanisms such as those described in the Group Domain of
Interpretation (GDOI)[RFC3547], Multimedia Internet KEYing Interpretation (GDOI)[RFC3547], Multimedia Internet KEYing
(MIKEY)[RFC3830] or Group Secure Association Key Management Protocol (MIKEY)[RFC3830] or Group Secure Association Key Management Protocol
(GSAKMP)[RFC4535] specifications for automated key management is (GSAKMP)[RFC4535] specifications SHOULD be applied.
applied.
It is also important to note that while NORM does leverage FEC-based It is also important to note that while NORM does leverage FEC-based
repair for scalability, this alone does not guarantee integrity of repair for scalability, this alone does not guarantee integrity of
received data. Application-level integrity-checking of data content received data. Application-level integrity-checking of received data
is highly RECOMMENDED. content is highly RECOMMENDED.
6.1. Baseline Secure NORM Operation 6.1. Baseline Secure NORM Operation
This section describes a baseline mode of secure NORM protocol This section describes a baseline mode of secure NORM protocol
operation based on application of the IPsec security protocol. This operation based on application of the IPsec security protocol. This
approach is documented here to provide a reference, interoperable approach is documented here to provide a reference, interoperable
secure mode of operation. However, additional approaches to NORM secure mode of operation. However, additional approaches to NORM
security, including other forms of IPsec application, MAY be security, including other forms of IPsec application, MAY be
specified in the future. For example, the use of the EXT_AUTH header specified in the future. For example, the use of the EXT_AUTH header
extension could enable NORM-specific authentication or security extension could enable NORM-specific authentication or security
skipping to change at page 79, line 30 skipping to change at page 80, line 37
properly process the IPsec-secured packets from the sender. The NORM properly process the IPsec-secured packets from the sender. The NORM
receiver(s) SHALL also use a common, second IPsec SA (common Security receiver(s) SHALL also use a common, second IPsec SA (common Security
Parameter Index (SPI) and encryption key) configured for ESP Parameter Index (SPI) and encryption key) configured for ESP
operation with the option for data origination authentication operation with the option for data origination authentication
enabled. Similar to the NORM sender, is RECOMMENDED this IPsec ESP enabled. Similar to the NORM sender, is RECOMMENDED this IPsec ESP
SA be also configured to provide confidentiality protection for IP SA be also configured to provide confidentiality protection for IP
packets containing NORM protocol messages. The receivers MUST have packets containing NORM protocol messages. The receivers MUST have
an IPsec SPD entry configured to process outbound NORM/UDP packets an IPsec SPD entry configured to process outbound NORM/UDP packets
directed to the NORM sender source address and port number using this directed to the NORM sender source address and port number using this
second SA. As noted for NORM unicast feedback, the sender's second SA. As noted for NORM unicast feedback, the sender's
transmission port number SHOULD be distinct from the multicast transmission port number SHOULD be selected to be distinct from the
session port number to allow discrimination between unicast and multicast session port number to allow discrimination between unicast
multicast feedback messages when access to the IP destination address and multicast feedback messages when access to the IP destination
is not possible (e.g., a user-space NORM implementation). For address is not possible (e.g., a user-space NORM implementation).
processing of packets from receivers, the NORM sender SHALL be For processing of packets from receivers, the NORM sender SHALL be
configured with this common, second SA (and the corresponding SPD configured with this common, second SA (and the corresponding SPD
entry needed) in order to properly process messages from the entry needed) in order to properly process messages from the
receiver. Note that built-in IPsec replay attack protection for this receiver.
second SA at the sender MUST be disabled.
Multiple receivers using a common IPsec SA for traffic directed to 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 the NORM sender (i.e., many-to-one) typically prevents the use of
IPsec replay attack protection by the NORM sender with current IPsec built-in IPsec replay attack protection by the NORM sender with
implementations. So, to support a fully secure mode of operation, current IPsec implementations. Thus the built-in IPsec replay attack
protection for this second SA at the sender MUST be disabled unless
the particular IPsec implementation manages its replay protection on
a per-source basis. So, to support a fully secure mode of operation,
the NORM sender implementation MUST provide replay attack protection the NORM sender implementation MUST provide replay attack protection
based upon the "sequence" field of NORM protocol messages from based upon the "sequence" field of NORM protocol messages from
receivers. This can be accomplished with high assurance of security, receivers. This can be accomplished with high assurance of security,
even with the limited size (16-bits) of this field, because even with the limited size (16-bits) of this field, because
1. NORM receiver NACK and non-CLR ACK feedback messages are sparse. 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 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 only a small set of receivers for which the sender must keep more
persistent replay attack state. persistent replay attack state.
3. "NORM_NACK" feedback messages that precede the sender's current 3. "NORM_NACK" feedback messages that precede the sender's current
repair window do not significantly impact protocol operation repair window do not significantly impact protocol operation
(generation of "NORM_CMD(SQUELCH)" is limited) and could be in (generation of "NORM_CMD(SQUELCH)" is limited) and could be in
fact ignored. This means the sender can prune any replay attack fact ignored. This means the sender can prune any replay attack
state for receivers that precede the current repair window. state for receivers that precede the current repair window.
4. "NORM_ACK" messages correspond to either a specific sender 4. "NORM_ACK" messages correspond to either a specific sender
"ack_id", the sender "cc_sequence" for ACKs sent in response to "ack_id", the sender "cc_sequence" for ACKs sent in response to
skipping to change at page 80, line 20 skipping to change at page 81, line 26
(generation of "NORM_CMD(SQUELCH)" is limited) and could be in (generation of "NORM_CMD(SQUELCH)" is limited) and could be in
fact ignored. This means the sender can prune any replay attack fact ignored. This means the sender can prune any replay attack
state for receivers that precede the current repair window. state for receivers that precede the current repair window.
4. "NORM_ACK" messages correspond to either a specific sender 4. "NORM_ACK" messages correspond to either a specific sender
"ack_id", the sender "cc_sequence" for ACKs sent in response to "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 "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 of ACKs sent in response to "NORM_CMD(FLUSH)". Thus, the sender
can prune any replay attack state for receivers that precede the can prune any replay attack state for receivers that precede the
current applicable sequence or repair window space. current applicable sequence or repair window space.
Note that use of ESP confidentiality, as RECOMMENDED, for secure NORM Note that use of ESP confidentiality for secure NORM protocol
protocol operation makes it more difficult for adversaries to conduct operation makes it more difficult for adversaries to conduct any form
effective replay attacks. Additionally, it should be noted that a of replay attacks. Additionally, it should be noted that a NORM
NORM sender implementation with access to the full ESP protocol sender implementation with access to the full ESP protocol header
header could also use the ESP sequence information to make this form could also use the ESP sequence information to make replay attack
of replay attack protection even more robust. The design of this protection even more robust, by maintaining per-source sequence
baseline security approach for NORM intentionally places any more state. The design of this baseline security approach for NORM
complex processing state or processing (e.g. replay attack protection intentionally places any more complex processing state or processing
given multiple receivers) at the NORM sender since NORM receiver (e.g. replay attack protection given multiple receivers) at the NORM
implementations may need to have a more light-weight realization in sender since NORM receiver implementations may need to have a more
many cases. light-weight realization in many cases.
This baseline approach can be used for NORM protocol sessions with This baseline approach can be used for NORM protocol sessions with
multiple senders if the SA pairs described are established for each multiple senders if the SA pairs described are established for each
sender. For small-sized groups, it is even possible that many-to- sender. For small-sized groups, it is even possible that many-to-
many (ASM) IPsec configuration could be achieved where each many (ASM) IPsec configuration could be achieved where each
participant uses a unique SA (with a unique SPI). This does not 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 scale to larger group sizes given the complex set of SA and SPD
entries each participant would need to maintain. entries each participant would need to maintain.
It is anticipated in early deployments of this baseline approach to It is anticipated in early deployments of this baseline approach to
skipping to change at page 81, line 21 skipping to change at page 82, line 28
6.1.2.1. Selectors 6.1.2.1. Selectors
The implementation MUST be able to use the source address, The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD. selectors in the SPD.
6.1.2.2. Mode 6.1.2.2. Mode
IPsec in transport mode MUST be supported. The use of IPsec[RFC4301] IPsec in transport mode MUST be supported. The use of IPsec[RFC4301]
processing for secure NORM traffic SHOULD also be REQUIRED such that processing for secure NORM traffic MUST be configured such that
unauthenticated packets are not received by the NORM protocol unauthenticated packets are not received by the NORM protocol
implementation . implementation .
6.1.2.3. Key Management 6.1.2.3. Key Management
An automated key management scheme for group key distribution and An automated key management scheme for group key distribution and
rekeying such as GDOI[RFC3547], GSAKMP[RFC4535], or MIKEY[RFC3830] rekeying such as GDOI[RFC3547], GSAKMP[RFC4535], or MIKEY[RFC3830] is
SHOULD be used. Relatively short-lived NORM sessions MAY be able to RECOMMENDED for use. Relatively short-lived NORM sessions MAY be
use Manual Keying with a single, preplaced key, particularly if able to use Manual Keying with a single, preplaced key, particularly
Extended Sequence Numbering (ESN) [RFC4303] is available in the IPsec if Extended Sequence Numbering (ESN) [RFC4303] is available in the
implementation used. It should also be noted that it may be possible IPsec implementation used. It should also be noted that it may be
for key update messages (e.g., the GDOI GROUPKEY-PUSH message) to be possible for key update messages (e.g., the GDOI GROUPKEY-PUSH
included in the NORM application reliable data transmission if message) to be included as part of the NORM application reliable data
appropriate interfaces were available between the NORM application transmission if appropriate interfaces are available between the NORM
and the key management daemon. application and the key management daemon.
6.1.2.4. Security Policy 6.1.2.4. Security Policy
Receivers SHOULD accept connections only from the designated, Receivers MUST accept protocol messages only from the designated,
authorized sender(s). It is expected that appropriate key management authorized sender(s). It is expected that appropriate key management
will provide encryption keys only to receivers authorized to will provide encryption keys only to receivers authorized to
participate in a designated session. The approach outlined here participate in a designated session. The approach outlined here
allows receiver sets to be controlled on a per-sender basis. allows receiver sets to be controlled on a per-sender basis.
6.1.2.5. Authentication and Encryption 6.1.2.5. Authentication and Encryption
Large NORM group sizes will necessitate some form of key management Large NORM group sizes will necessitate some form of key management
that does rely upon shared secrets. The GDOI and GSAKMP protocols that does rely upon shared secrets. The GDOI and GSAKMP protocols
mentioned here allow for certificate-based authentication. These mentioned here allow for certificate-based authentication. It is
certificates SHOULD use IP addresses for authentication although it RECOMMENDED these certificates use IP addresses for authentication
may alternatively possible to have authentication associated with although it may alternatively possible to have authentication
pre-assigned NormNodeId values. However, it is likely that available associated with pre-assigned NormNodeId values. However, it is
group key management implementations will not be NORM-specific. likely that available group key management implementations will not
be NORM-specific.
6.1.2.6. Availability 6.1.2.6. Availability
The IPsec requirements profile outlined here is commonly available on The IPsec requirements profile outlined here is commonly available on
many potential NORM hosts. The principal issue is that configuration many potential NORM hosts. The principal issue is that configuration
and operation of IPsec typically requires privileged user and operation of IPsec typically requires privileged user
authorization. Automated key management implementations are authorization. Automated key management implementations are
typically configured with the privileges necessary to effect system typically configured with the privileges necessary to effect system
IPsec configuration needed. IPsec configuration needed.
7. IANA Considerations 7. IANA Considerations
Header extension identifiers for the NORM protocol are subject to Values of NORM Header Extension Types, Stream Control Codes, and
IANA registration. Additionally, building blocks components used by "NORM_CMD" message sub-types are subject to IANA registration. They
this NORM Protocol specification may introduce additional IANA are in the registry named "Reliable Multicast Transport (RMT) NORM
considerations. In particular, the FEC Building Block used by NORM Protocol Parameters" located at time of publication at:
does require IANA registration of the FEC codecs used. The
registration instructions for FEC codecs are provided in [RFC5052]. http:///www.iana.org/assignments/norm-parameters
It should be also noted that reliable multicast building block
components used by this specification also have their respective IANA
considerations and those documents should be consulted accordingly.
In particular, the FEC Building Block used by NORM does require IANA
registration of the FEC codecs used. The registration instructions
for FEC codecs are provided in RFC 5052.
7.1. Explicit IANA Assignment Guidelines 7.1. Explicit IANA Assignment Guidelines
This document defines a name-space for NORM Header Extensions named: This document introduces three namespaces that are registered for the
NORM Header Extension Types, Stream Control Codes and "NORM_CMD"
Message Sub-types. This section describes explicit IANA assignment
guidelines for each of these.
"ietf:rmt:norm:extensions" 7.1.1. NORM Header Extension Types
These values represent extended header fields that allow the protocol This document defines a namespace for NORM Header Extension Types
functionality to be expanded to include additional optional features named:
"ietf:rmt:norm:extension"
The NORM Header Extension Type field is an 8-bit value. The values
of this field identify extended header content that allows the
protocol functionality to be expanded to include additional 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" namespace 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 extensions of a fixed 4-byte length. NORM Header
extension identifier value assignment requests are granted on a Extension Type value assignment requests are granted on a
"Specification Required" basis as defined in [RFC5226]. Additional "Specification Required" basis as defined in RFC 5226. Additional
header extension specifications MUST include a description of header extension specifications MUST include a description of
protocol actions to be taken when the extended header is encountered protocol actions to be taken when the extended header is encountered
by a protocol implementation not supporting that specific option. by a protocol implementation not supporting that specific option.
For example, it may be possible for protocol implementations to For example, it may be possible for protocol implementations to
ignore unknown header extensions in many cases. ignore unknown header extensions in many cases.
This specification registers the following NORM Header Extension This specification registers the following NORM Header Extension
types in namespace "ietf:rmt:norm:extensions": Types:
+-------+------------+--------------------+ +-------+------------+--------------------+
| Value | Name | Reference | | Value | Name | Reference |
+-------+------------+--------------------+ +-------+------------+--------------------+
| 1 | "EXT_AUTH" | This specification | | 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 |
+-------+------------+--------------------+ +-------+------------+--------------------+
7.1.2. NORM Stream Control Codes
This document defines a namespace for NORM Stream Control Codes
named:
"ietf:rmt:norm:streamControlCode"
NORM Stream Control Codes are 16-bit values that may be inserted
within a "NORM_OBJECT_STREAM" delivery object to convey sequenced,
out-of-band (with respect to the stream data) control signaling
applicable to the referenced stream object. These control codes are
expected to be delivered to the application or protocol
implementation with the reliable delivery, in-order with respect to
the their inserted position within the stream. NORM Stream Control
Code value assignment requests are granted on a "Specification
Required" basis as defined in RFC 5226. Additional header extension
specifications MUST include a description of protocol actions to be
taken when the extended header is encountered by a protocol
implementation not supporting that specific option.
This specification registers the following NORM Stream Control Code:
+-------+-------------------+--------------------+
| Value | Name | Reference |
+-------+-------------------+--------------------+
| 0 | "NORM_STREAM_END" | This specification |
+-------+-------------------+--------------------+
7.1.3. NORM_CMD Message Sub-types
This document defines a namespace for "NORM_CMD" Message Sub-types
named:
"ietf:rmt:norm:command"
It is possible that specifications extending NORM may wish to define
additional "NORM_CMD" messages to enhance protocol functionality.
The "NORM_CMD" sub-type field is an 8-bit value. Note that the
specification already provides for an "application-defined"
"NORM_CMD" message sub-type that may be used at the discretion of
individual applications using NORM for transport. These
"application-defined" commands may be suitable for many application-
specific purposes and do not require standards action. In any case,
such additional messages SHALL be subject to the same congestion
control constraints as the existing NORM sender message set.
The current specification defines a number of "NORM_CMD" message sub-
types that senders can use to signal the receivers in various aspects
of NORM protocol operation. This specification registers the
following "NORM_CMD" Message Sub-types:
+-------+-------------------------+--------------------+
| Value | Name | Reference |
+-------+-------------------------+--------------------+
| 1 | "NORM_CMD(FLUSH)" | This specification |
| 2 | "NORM_CMD(EOT)" | This specification |
| 3 | "NORM_CMD(SQUELCH)" | This specification |
| 4 | "NORM_CMD(CC)" | This specification |
| 5 | "NORM_CMD(REPAIR_ADV)" | This specification |
| 6 | "NORM_CMD(ACK_REQ)" | This specification |
| 7 | "NORM_CMD(APPLICATION)" | This specification |
+-------+-------------------------+--------------------+
8. Suggested Use 8. Suggested Use
The present NORM protocol is seen as useful tool for the reliable The present NORM protocol is seen as useful tool for the reliable
data transfer over generic IP multicast services. It is not the data transfer over generic IP multicast services. It is not the
intention of the authors to suggest it is suitable for supporting all intention of the authors to suggest it is suitable for supporting all
envisioned multicast reliability requirements. NORM provides a envisioned multicast reliability requirements. NORM provides a
simple and flexible framework for multicast applications with a simple and flexible framework for multicast applications with a
degree of concern for network traffic implosion and protocol overhead degree of concern for network traffic implosion and protocol overhead
efficiency. NORM-like protocols have been successfully demonstrated efficiency. NORM-like protocols have been successfully demonstrated
within the MBone for bulk data dissemination applications, including within the MBone for bulk data dissemination applications, including
skipping to change at page 83, line 46 skipping to change at page 86, line 37
networks where only unidirectional multicast routing/delivery service networks where only unidirectional multicast routing/delivery service
exists. Asymmetric architectures supporting multicast delivery are exists. Asymmetric architectures supporting multicast delivery are
likely to make up an important portion of the future Internet likely to make up an important portion of the future Internet
structure (e.g., DBS/cable/PSTN hybrids) and efficient, reliable bulk structure (e.g., DBS/cable/PSTN hybrids) and efficient, reliable bulk
data transfer will be an important capability for servicing large data transfer will be an important capability for servicing large
groups of subscribed receivers. groups of 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, [RFC3940], and this version: this specification, RFC 3940, 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 specified 3. Removal of file blocking scheme description that is now specified
in the FEC Building Block document [RFC5052], in the FEC Building Block document [RFC5052],
4. Removal of restriction of NORM receiver feedback message rate to 4. Removal of restriction of NORM receiver feedback message rate to
local NORM sender rate (This caused congestion control failures local NORM sender rate (This caused congestion control failures
in high speed operation. The extremely low feedback rate of the in high speed operation. The extremely low feedback rate of the
NORM protocol as compared to TCP avoids any resultant impact to NORM protocol as compared to TCP avoids any resultant impact to
the network as shown in [Mdpcc]), the network as shown in [Mdpcc]),
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 7. Addition of IPsec secure mode description with IPsec
requirements. requirements.
8. Clarification of interpretation of "Source Block Length" when FEC 8. Addition of the EXT_AUTH header extension definition.
9. Clarification of interpretation of "Source Block Length" when FEC
codes are arbitrarily shortened by the sender. codes are arbitrarily shortened by the sender.
10. Acknowledgments 10. Acknowledgments
(and these are not Negative) (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
skipping to change at page 85, line 5 skipping to change at page 87, line 43
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error [RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error
Correction (FEC) Building Block", RFC 5052, August 2007. Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker, [RFC5401] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"Multicast Negative-Acknowledgment (NACK) Building "Multicast Negative-Acknowledgment (NACK) Building
Blocks", RFC 5401, November 2008. Blocks", RFC 5401, November 2008.
skipping to change at page 86, line 41 skipping to change at page 89, line 39
"Negative-acknowledgment (NACK)-Oriented Reliable "Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004. Multicast (NORM) Protocol", RFC 3940, November 2004.
[RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross, [RFC4535] Harney, H., Meth, U., Colegrove, A., and G. Gross,
"GSAKMP: Group Secure Association Key Management "GSAKMP: Group Secure Association Key Management
Protocol", RFC 4535, June 2006. Protocol", RFC 4535, June 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4654] Widmer, J. and M. Handley, "TCP-Friendly Multicast
Congestion Control (TFMCC): Protocol Specification",
RFC 4654, August 2006.
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) [RFC5445] Watson, M., "Basic Forward Error Correction (FEC)
Schemes", RFC 5445, March 2009. Schemes", RFC 5445, March 2009.
[RmComparison] [RmComparison]
Pingali, S., Towsley, D., and J. Kurose, "A Comparison of Pingali, S., Towsley, D., and J. Kurose, "A Comparison of
Sender-Initiated and Receiver-Initiated Reliable Multicast Sender-Initiated and Receiver-Initiated Reliable Multicast
Protocols", Proc. INFOCOMM, San Francisco CA, Protocols", Proc. INFOCOMM, San Francisco CA,
October 1993. October 1993.
[TcpModel] [TcpModel]
 End of changes. 56 change blocks. 
189 lines changed or deleted 287 lines changed or added

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