draft-ietf-rmt-pi-norm-revised-10.txt   draft-ietf-rmt-pi-norm-revised-11.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: October 22, 2009 M. Handley Expires: October 26, 2009 M. Handley
University College London University College London
J. Macker J. Macker
Naval Research Laboratory Naval Research Laboratory
April 20, 2009 April 24, 2009
NACK-Oriented Reliable Multicast Protocol NACK-Oriented Reliable Multicast Protocol
draft-ietf-rmt-pi-norm-revised-10 draft-ietf-rmt-pi-norm-revised-11
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 October 22, 2009. This Internet-Draft will expire on October 26, 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 32 skipping to change at page 2, line 32
among senders and receivers. A congestion control scheme is among senders and receivers. A congestion control scheme is
specified to allow the NORM protocol to fairly share available specified to allow the NORM protocol to fairly share available
network bandwidth with other transport protocols such as Transmission network bandwidth with other transport protocols such as Transmission
Control Protocol (TCP). It is capable of operating with both Control Protocol (TCP). It is capable of operating with both
reciprocal multicast routing among senders and receivers and with reciprocal multicast routing among senders and receivers and with
asymmetric connectivity (possibly a unicast return path) between the asymmetric connectivity (possibly a unicast return path) between the
senders and receivers. The protocol offers a number of features to senders and receivers. The protocol offers a number of features to
allow different types of applications or possibly other higher level allow different types of applications or possibly other higher level
transport protocols to utilize its service in different ways. The transport protocols to utilize its service in different ways. The
protocol leverages the use of FEC-based repair and other IETF protocol leverages the use of FEC-based repair and other IETF
reliable multicast transport (RMT) building blocks in its design. Reliable Multicast Transport (RMT) building blocks in its design.
This document obsoletes RFC 3940. This document obsoletes RFC 3940.
Table of Contents Table of Contents
1. Introduction and Applicability . . . . . . . . . . . . . . . . 5 1. Introduction and Applicability . . . . . . . . . . . . . . . . 5
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 6 1.2. NORM Data Delivery Service Model . . . . . . . . . . . . . 6
1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 8 1.3. NORM Scalability . . . . . . . . . . . . . . . . . . . . . 8
1.4. Environmental Requirements and Considerations . . . . . . 9 1.4. Environmental Requirements and Considerations . . . . . . 9
2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9 2. Architecture Definition . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 5, line 28 skipping to change at page 5, line 28
participants. To accommodate this capability, NORM protocol message participants. To accommodate this capability, NORM protocol message
headers contain some common information allowing receivers to easily headers contain some common information allowing receivers to easily
synchronize to senders throughout the lifetime of a reliable synchronize to senders throughout the lifetime of a reliable
multicast session. NORM is designed to be self-adapting to a wide multicast session. NORM is designed to be self-adapting to a wide
range of dynamic network conditions with little or no pre- range of dynamic network conditions with little or no pre-
configuration. The protocol is purposely designed to be tolerant of configuration. The protocol is purposely designed to be tolerant of
inaccurate timing estimations or lossy conditions that may occur in inaccurate timing estimations or lossy conditions that may occur in
many networks including mobile and wireless. The protocol is also many networks including mobile and wireless. The protocol is also
designed to exhibit convergence and efficient operation even in designed to exhibit convergence and efficient operation even in
situations of heavy packet loss and large queuing or transmission situations of heavy packet loss and large queuing or transmission
delays. This document obsoletes RFC 3940. delays. This document obsoletes the Experimental RFC 3940
specification.
This document is a product of the IETF RMT WG and follows the This document is a product of the IETF RMT working group and follows
guidelines provided in RFC 3269. the guidelines provided in the Author Guidelines for Reliable
Multicast Transport (RMT) Building Blocks and Protocol Instantiation
documents [RFC3269].
Statement of Intent Statement of Intent
This memo contains the definitions necessary to fully specify a This memo contains the definitions necessary to fully specify a
Reliable Multicast Transport protocol in accordance with the criteria Reliable Multicast Transport protocol in accordance with the criteria
of RFC 2357. A prior document, RFC 3940, contained a previous of IETF Criteria for Evaluating Reliable Multicast Transport and
description of the NORM Protocol specification described in this Application Protocols [RFC2357]. The NORM specification described in
document. RFC 3940 was published in the "Experimental" category. It this document was previously published in the "Experimental Category"
was the stated intent of the RMT working group to re-submit this [RFC3940]. It was the stated intent of the RMT working group to re-
specifications as an IETF Proposed Standard in due course. submit this specifications as an IETF Proposed Standard in due
course. This Proposed Standard specification is thus based on RFC
This Proposed Standard specification is thus based on RFC 3940 and 3940 and has been updated according to accumulated experience and
has been updated according to accumulated experience and growing growing protocol maturity since the publication of RFC 3940. Said
protocol maturity since the publication of RFC 3940. Said experience experience applies both to this specification itself and to
applies both to this specification itself and to congestion control congestion control strategies related to the use of this
strategies related to the use of this specification. specification. The differences between RFC 3940 and this document
are listed in Section 9.
The differences between RFC 3940 and this document are listed in
Section 9.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. NORM Data Delivery Service Model 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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
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.4. 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 Multicast NACK Building Block [RFC5401], FEC Building Block
Block[RFC5052], and TCP-Friendly Multicast Congestion Control (TFMCC) [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 RFC 1112, but SHALL also be capable of (ASM) model defined in Host Extensions for IP Multicasting [RFC1112],
scalable operation in asymmetric topologies such as Source-Specific but SHALL also be capable of scalable operation in asymmetric
Multicast (SSM)[RFC4607] where there may only be unicast routing topologies such as Source-Specific Multicast (SSM) [RFC4607] where
service from the receivers to the sender(s). there may only be unicast routing 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 13
The feedback volume of these congestion control "NORM_ACK" messages The feedback volume of these congestion control "NORM_ACK" messages
is controlled using the same timer-based probabilistic suppression is controlled using the same timer-based probabilistic suppression
techniques as for "NORM_NACK" messages to avoid feedback implosion. techniques as for "NORM_NACK" messages to avoid feedback implosion.
In order to meet potential application requirements for positive In order to meet potential application requirements for positive
acknowledgment from receivers, other "NORM_ACK" messages are defined acknowledgment from receivers, other "NORM_ACK" messages are defined
and available for use. and available for use.
2.2. Protocol Building Blocks 2.2. Protocol Building Blocks
The operation of the NORM protocol is based primarily upon the The operation of the NORM protocol is based primarily upon the
concepts presented in the Multicast NACK Building Block concepts presented in the Multicast NACK Building Block [RFC5401]
document[RFC5401]. This includes the basic NORM architecture and the document. This includes the basic NORM architecture and the data
data transmission, repair, and feedback strategies discussed in that transmission, repair, and feedback strategies discussed in that
document. Additional reliable multicast building blocks, as document. The reliable multicast building block approach, as
described in RFC 3048, are applied in creating the full NORM protocol described in Reliable Multicast Transport Building Blocks for One-to-
instantiation . NORM also makes use of Forward Error Correction Many Bulk-Data Transfer [RFC3048], is applied in creating the full
NORM protocol instantiation. NORM also makes use of the parity-based
encoding techniques for repair messaging and optional transmission encoding techniques for repair messaging and optional transmission
robustness as described in RFC 3453. NORM uses the FEC Payload ID as robustness as described in The Use of Forward Error Correction (FEC)
in Reliable Multicast [RFC3453]. NORM uses the FEC 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) scheme[TfmccPaper],
RFC 4654. [RFC4654].
2.3. Design Tradeoffs 2.3. Design Tradeoffs
While the various features of NORM are designed to provide some While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering trade-offs involved transport arena. There are numerous engineering trade-offs involved
in reliable multicast transport design and this requires an increased in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations. awareness of application and network architecture considerations.
Performance requirements affecting design can include: group size, Performance requirements affecting design can include: group size,
skipping to change at page 14, line 18 skipping to change at page 14, line 21
utilization, group size scalability, and efficiency of performance. utilization, group size scalability, and efficiency of performance.
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 RMT Protocol Instantiation document, in conjunction with the
Building Block documents of RFC 5401 and RFC 5052, completely Multicast Negative-Acknowledgment (NACK) [RFC5401] and Forward Error
specifies a working reliable multicast transport protocol that Correction (FEC) [RFC5052] Building Blocks, completely specifies a
conforms to the requirements described in RFC 2357. working reliable multicast transport protocol that 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 21, line 23 skipping to change at page 21, line 23
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 [TfmccPaper]). This value is used is also referred to as "R_max" in [TfmccPaper]). This value is used
to control timing of the NACK repair process and other aspects of to control timing of the NACK repair process and other aspects of
protocol operation as described in this document. Normally, the protocol operation as described in this document. Normally, the
advertised "grtt" value will correspond to what the sender has advertised "grtt" value will correspond to what the sender has
measured based on feedback from the group, but, at low transmission measured based on feedback from the group, but, at low transmission
rates, the advertised "grtt" SHALL be set to "MAX(grttMeasured, rates, the 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 Multicast NACK and decoding this field is described in the Multicast NACK Building
Building Block document[RFC5401]. Block [RFC5401].
The "backoff" field value is used by receivers to determine the The "backoff" field value is used by receivers to determine the
maximum backoff timer value used in the timer-based NORM NACK maximum backoff timer value used in the timer-based NORM NACK
feedback suppression. This 4-bit field supports values from 0-15 feedback suppression. This 4-bit field supports values from 0-15
which is multiplied by the sender GRTT to determine the maximum which is multiplied by the sender GRTT to determine the maximum
backoff timeout. The "backoff" field informs the receivers of the backoff timeout. The "backoff" field informs the receivers of the
sender's backoff factor parameter "Ksender". Recommended values and sender's backoff factor parameter "Ksender". Recommended values and
their use are described in the NORM receiver NACK procedure their use are described in the NORM receiver NACK procedure
description in Section 5.3. description in Section 5.3.
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] or in described in the FEC Basic Schemes [RFC5445] specification or in
additional FEC Scheme documents that may be defined. As an example, other FEC Schemes. As an example, the format of the "fec_payload_id"
the format of the "fec_payload_id" format for Small Block, Systematic format for Small Block, Systematic codes ("fec_id" = 129) from theFEC
codes ("fec_id" = 129) from the FEC Basic Schemes Basic Schemes [RFC5445] specification 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Example: FEC Payload Id Format for 'fec_id' = 129 Example: FEC Payload Id Format for 'fec_id' = 129
In this example FEC payload identifier, the "source_block_number", In this example FEC payload identifier, the "source_block_number",
"source_block_len", and "encoding_symbol_id" fields correspond to the "source_block_len", and "encoding_symbol_id" fields correspond to the
"Source Block Number", "Source Block Length, and "Encoding Symbol ID" "Source Block Number", "Source Block Length, and "Encoding Symbol ID"
fields of the FEC Payload ID format for Small Block Systematic FEC fields of the FEC Payload ID format for Small Block Systematic FEC
Schemes identified by a "fec_id" value of 129 as specified by the FEC Schemes identified by a "fec_id" value of 129 as specified by the FEC
Basic Schemes specifcation[RFC5445]. The "source_block_number" Basic Schemes [RFC5445] specification. The "source_block_number"
identifies the coding block's relative position with a NormObject. identifies the coding block's relative position with a NormObject.
Note that, for NormObjects of type "NORM_OBJECT_STREAM", the Note that, for NormObjects of type "NORM_OBJECT_STREAM", the
"source_block_number" may wrap for very long lived sessions. The "source_block_number" may wrap for very long lived sessions. The
"source_block_len" indicates the number of user data segments in the "source_block_len" indicates the number of user data segments in the
identified coding block. Given the "source_block_len" information of identified coding block. Given the "source_block_len" information of
how many symbols of application data are contained in the block, the how many symbols of application data are contained in the block, the
receiver can determine whether the attached segment is data or parity receiver can determine whether the attached segment is data or parity
content and treat it appropriately. Some applications may content and treat it appropriately. Some applications may
dynamically "shorten" code blocks when the pending information dynamically "shorten" code blocks when the pending information
content is not predictable (e.g. real-time message streams). In that content is not predictable (e.g. real-time message streams). In that
skipping to change at page 25, line 6 skipping to change at page 25, line 6
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 numbered less than the "source_block_len" contain original
application data while segments greater than or equal to application data while segments greater than or equal to
"source_block_len" contain parity symbols calculated for the block. "source_block_len" contain parity symbols calculated for the block.
The concatenation of "object_transport_id::fec_payload_id" can be The concatenation of "object_transport_id::fec_payload_id" can be
viewed as a unique transport protocol data unit identifier for the viewed as a unique transport protocol data unit identifier for the
attached segment with respect to the NORM sender's instance within a attached segment with respect to the NORM sender's instance within a
session. session.
Additional FEC Object Transmission Information (FTI) (as described in Additional FEC Object Transmission Information (FTI) (as described in
the FEC Building Block document [RFC5052]) is required to properly the FEC Building Block [RFC5052]) is required to properly receive and
receive and decode NORM transport objects. This information MAY be decode NORM transport objects. This information MAY be provided as
provided as out-of-band session information. However, in some cases, out-of-band session information. However, in some cases, it may be
it may be useful for the sender to include this information "in-band" useful for the sender to include this information "in-band" to
to facilitate receiver operation with minimal pre-configuration. For facilitate receiver operation with minimal pre-configuration. For
this purpose, the NORM FEC Object Transmission Information Header this purpose, the NORM FEC Object Transmission Information Header
Extension (EXT_FTI) is defined. This header extension MAY be applied Extension (EXT_FTI) is defined. This header extension MAY be applied
to "NORM_DATA" and "NORM_INFO" messages to provide this necessary to "NORM_DATA" and "NORM_INFO" messages to provide this necessary
information. The format of the EXT_FTI consists of two parts, a information. The format of the EXT_FTI consists of two parts, a
general part that contains the size of the associated transport general part that contains the size of the associated transport
object and a portion that depends upon the FEC scheme being used. object and a portion that depends upon the FEC scheme being used.
The "fec_id" field in "NORM_DATA" and "NORM_INFO" messages identifies The "fec_id" field in "NORM_DATA" and "NORM_INFO" messages identifies
the FEC scheme. The format of the EXT_FTI general part is given the FEC scheme. The format of the EXT_FTI general part is given
here. here.
skipping to change at page 26, line 26 skipping to change at page 26, line 26
Example: EXT_FTI Header Extension Format for 'fec_id' = 129 Example: EXT_FTI Header Extension Format for 'fec_id' = 129
In this example (for "fec_id" = 129), the "hel" field value is 4. In this example (for "fec_id" = 129), the "hel" field value is 4.
The size of the EXT_FTI header extension may be different for other The size of the EXT_FTI header extension may be different for other
FEC schemes. FEC schemes.
The 48-bit "object_size" serves the purpose described previously. The 48-bit "object_size" serves the purpose described previously.
The "fec_instance_id" corresponds to the "FEC Instance ID" described The "fec_instance_id" corresponds to the "FEC Instance ID" described
in the FEC Building Block document [RFC5052]. In this case, the in the FEC Building Block [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 RFC 5052. 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
space for buffering blocks transmitted by the sender. space for buffering blocks transmitted by the sender.
The "fec_num_parity" corresponds to the "maximum number of encoding The "fec_num_parity" corresponds to the "maximum number of encoding
symbols that can be generated for any source block" as described in symbols that can be generated for any source block" as described in
for FEC Object Transmission Information for Small Block Systematic for FEC Object Transmission Information for Small Block Systematic
Codes in the FEC Building Block document [RFC5052]. For example, Codes in the FEC Building Block [RFC5052]. For example, Reed-Solomon
Reed-Solomon codes may be arbitrarily shortened to create different codes may be arbitrarily shortened to create different code
code variations for a given block length. In the case of Reed- variations for a given block length. In the case of Reed-Solomon
Solomon (GF(2^8) and GF(2^16)) codes, this value indicates the (GF(2^8) and GF(2^16)) codes, this value indicates the maximum number
maximum number of parity segments available from the sender for the of parity segments available from the sender for the coding blocks.
coding blocks. This field MAY be interpreted differently for other This field MAY be interpreted differently for other systematic codes
systematic codes as they are defined. as they are defined.
The payload portion of "NORM_DATA" messages includes source data or The payload portion of "NORM_DATA" messages includes source data or
FEC encoded application content. The content of this payload depends FEC encoded application content. The content of this payload depends
upon the FEC scheme being employed, and support for streaming using upon the FEC scheme being employed, and support for streaming using
the "NORM_OBJECT_STREAM" type, when applicable, necessitates some the "NORM_OBJECT_STREAM" type, when applicable, necessitates some
additional content in the payload. additional content in the payload.
The "payload_len", "payload_msg_start", and "payload_offset" fields The "payload_len", "payload_msg_start", and "payload_offset" fields
are present ONLY for transport objects of type "NORM_OBJECT_STREAM". are present ONLY for transport objects of type "NORM_OBJECT_STREAM".
These fields allow senders to arbitrarily vary the size of These fields allow senders to arbitrarily vary the size of
"NORM_DATA" payload segments for streams. This allows applications "NORM_DATA" payload segments for streams. This allows applications
to flush transmitted streams as needed to meet unique streaming to flush transmitted streams as needed to meet unique streaming
requirements. For objects of types "NORM_OBJECT_FILE" and requirements. For objects of types "NORM_OBJECT_FILE" and
"NORM_OBJECT_DATA", these fields are unnecessary since the receiver "NORM_OBJECT_DATA", these fields are unnecessary since the receiver
can calculate the payload length and offset information from the can calculate the payload length and offset information from the
"fec_payload_id" using the REQUIRED block partitioning algorithm "fec_payload_id" using the REQUIRED block partitioning algorithm
described in the FEC Building Block document [RFC5052]. When described in the FEC Building Block [RFC5052]. When systematic FEC
systematic FEC codes (e.g., "fec_id" = 129) are used, the codes (e.g., "fec_id" = 129) are used, the "payload_len",
"payload_len", "payload_msg_start", and "payload_offset" fields "payload_msg_start", and "payload_offset" fields contain actual
contain actual payload_data length, message start index (or stream payload_data length, message start index (or stream control code),
control code), and byte offset values for the associated application and byte offset values for the associated application stream data
stream data segment (the remainder of the "payload_data" field segment (the remainder of the "payload_data" field content) for those
content) for those "NORM_DATA" messages containing source data "NORM_DATA" messages containing source data symbols. In "NORM_DATA"
symbols. In "NORM_DATA" messages that contain FEC parity content, messages that contain FEC parity content, these fields do not contain
these fields do not contain values that can be directly interpreted, values that can be directly interpreted, but instead are values
but instead are values computed from FEC encoding the "payload_len", computed from FEC encoding the "payload_len", "payload_msg_start",
"payload_msg_start", and "payload_offset" fields for the source data and "payload_offset" fields for the source data segments of the
segments of the corresponding coding block. The actual corresponding coding block. The actual "payload_msg_start",
"payload_msg_start", "payload_len" and "payload_offset" values of "payload_len" and "payload_offset" values of missing data content can
missing data content can be determined upon decoding a FEC coding be determined upon decoding a FEC coding block. Note that these
block. Note that these fields do NOT contribute to the value of the fields do NOT contribute to the value of the "NORM_DATA" "hdr_len"
"NORM_DATA" "hdr_len" field. These fields are present only when the field. These fields are present only when the "flags" portion of the
"flags" portion of the "NORM_DATA" message indicate the transport "NORM_DATA" message indicate the transport object is of type
object is of type "NORM_OBJECT_STREAM". "NORM_OBJECT_STREAM".
The "payload_len" value, when non-zero, indicates the length (in The "payload_len" value, when non-zero, indicates the length (in
bytes) of the source content contained in the associated bytes) of the source content contained in the associated
"payload_data" field. 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
skipping to change at page 29, line 10 skipping to change at page 29, line 10
in the session, but may possibly vary on a per-object basis. The in the session, but may possibly vary on a per-object basis. The
NormSegmentSize is expected to be configurable by the sender NormSegmentSize is expected to be configurable by the sender
application prior to session participation as needed for network application prior to session participation as needed for network
topology maximum transmission unit (MTU) considerations. For IPv6, topology maximum transmission unit (MTU) considerations. For IPv6,
MTU discovery may be possibly leveraged at session startup to perform MTU discovery may be possibly leveraged at session startup to perform
this configuration. The "payload_data" content may be delivered this configuration. The "payload_data" content may be delivered
directly to the application for source symbols (when systematic FEC directly to the application for source symbols (when systematic FEC
encoding is used) or upon decoding of the FEC block. For encoding is used) or upon decoding of the FEC block. For
"NORM_OBJECT_FILE" and "NORM_OBJECT_STREAM" objects, the data segment "NORM_OBJECT_FILE" and "NORM_OBJECT_STREAM" objects, the data segment
length and offset can be calculated using the block partitioning length and offset can be calculated using the block partitioning
algorithm described in the FEC Building Block document [RFC5052]. algorithm described in the FEC Building Block [RFC5052]. For
For "NORM_OBJECT_STREAM" objects, the length and offset is obtained "NORM_OBJECT_STREAM" objects, the length and offset is obtained from
from the segment's corresponding embedded "payload_len" and the segment's corresponding embedded "payload_len" and
"payload_offset" fields. "payload_offset" fields.
4.2.2. NORM_INFO Message 4.2.2. NORM_INFO Message
The "NORM_INFO" message is used to convey OPTIONAL, application- The "NORM_INFO" message is used to convey OPTIONAL, application-
defined, out-of-band context information for transmitted NormObjects. defined, out-of-band context information for transmitted NormObjects.
An example "NORM_INFO" use for bulk file transfer is to place MIME An example "NORM_INFO" use for bulk file transfer is to place MIME
type information for the associated file, data, or stream object into type information for the associated file, data, or stream object into
the "NORM_INFO" payload. Receivers may use the "NORM_INFO" content the "NORM_INFO" payload. Receivers may use the "NORM_INFO" content
to make a decision as whether to participate in reliable reception of to make a decision as whether to participate in reliable reception of
skipping to change at page 42, line 15 skipping to change at page 42, line 15
| | | session and its feedback should | | | | session and its feedback should |
| | | not be considered in congestion | | | | not be considered in congestion |
| | | control operation. | | | | control operation. |
+----------------------+-------+------------------------------------+ +----------------------+-------+------------------------------------+
The "cc_rtt" contains a quantized representation of the RTT as The "cc_rtt" contains a quantized representation of the RTT as
measured by the sender with respect to the indicated receiver. This measured by the sender with respect to the indicated receiver. This
field is valid only if the "NORM_FLAG_CC_RTT" flag is set in the field is valid only if the "NORM_FLAG_CC_RTT" flag is set in the
"cc_flags" field. This one byte field is a quantized representation "cc_flags" field. This one byte field is a quantized representation
of the RTT using the algorithm described in the Multicast NACK of the RTT using the algorithm described in the Multicast NACK
Building Block document[RFC5401]. Building Block [RFC5401].
The "cc_rate" field contains a representation of the receiver's The "cc_rate" field contains a representation of the receiver's
current calculated (during steady-state congestion control operation) current calculated (during steady-state congestion control operation)
or twice its measured (during the slow start phase) congestion or twice its measured (during the slow start phase) congestion
control rate. This field is encoded and decoded using the same control rate. This field is encoded and decoded using the same
technique as described for the "NORM_CMD(CC)" "send_rate" field. technique as described for the "NORM_CMD(CC)" "send_rate" field.
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 The "NORM_CMD(REPAIR_ADV)" message is used by the sender to
skipping to change at page 58, line 47 skipping to change at page 58, line 47
means. Additionally, applications may leverage the use of means. Additionally, applications may leverage the use of
"NORM_INFO" messages associated with the session data objects in the "NORM_INFO" messages associated with the session data objects in the
session to provide application-specific context information for the session to provide application-specific context information for the
session and data being transmitted. These mechanisms allow for session and data being transmitted. These mechanisms allow for
operation with minimal pre-coordination among the senders and operation with minimal pre-coordination among the senders and
receivers. receivers.
The NORM sender begins segmenting application-enqueued data into The NORM sender begins segmenting application-enqueued data into
"NORM_DATA" segments and transmitting it to the group. For objects "NORM_DATA" segments and transmitting it to the group. For objects
of type "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE", the segmentation of type "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE", the segmentation
algorithm described in FEC Building Block document [RFC5052] is algorithm described in FEC Building Block [RFC5052] is RECOMMENDED.
RECOMMENDED. For objects of type "NORM_OBJECT_STREAM", segmentation For objects of type "NORM_OBJECT_STREAM", segmentation will typically
will typically be into uniform FEC coding block sizes, with be into uniform FEC coding block sizes, with individual segment sizes
individual segment sizes controlled by the application. In most controlled by the application. In most cases, the application and
cases, the application and NORM implementation SHOULD strive to NORM implementation SHOULD strive to produce full-sized
produce full-sized ("NormSegmentSize") segments when possible. The ("NormSegmentSize") segments when possible. The rate of transmission
rate of transmission is controlled via congestion control mechanisms is controlled via congestion control mechanisms or is a fixed rate if
or is a fixed rate if desired for closed network operations. The desired for closed network operations. The receivers participating
receivers participating in the multicast group provide feedback to in the multicast group provide feedback to the sender as needed.
the sender as needed. When the sender reaches the end of data it has When the sender reaches the end of data it has enqueued for
enqueued for transmission or any pending repairs, it transmits a transmission or any pending repairs, it transmits a series of
series of "NORM_CMD(FLUSH)" messages at a rate of one per "2*GRTT". "NORM_CMD(FLUSH)" messages at a rate of one per "2*GRTT". Receivers
Receivers may respond to these "NORM_CMD(FLUSH)" messages with may respond to these "NORM_CMD(FLUSH)" messages with additional
additional repair requests. A protocol parameter repair requests. A protocol parameter ""NORM_ROBUST_FACTOR""
""NORM_ROBUST_FACTOR"" determines the number of flush messages sent. determines the number of flush messages sent. If receivers request
If receivers request repair, the repair is provided and flushing repair, the repair is provided and flushing occurs again at the end
occurs again at the end of repair transmission. The sender may of repair transmission. The sender may attach an OPTIONAL
attach an OPTIONAL "acking_node_list" to "NORM_CMD(FLUSH)" containing "acking_node_list" to "NORM_CMD(FLUSH)" containing the NormNodeIds
the NormNodeIds for receivers from which it expects explicit positive for receivers from which it expects explicit positive acknowledgment
acknowledgment of reception. The "NORM_CMD(FLUSH)" message may be of reception. The "NORM_CMD(FLUSH)" message may be also used for
also used for this optional function any time prior to the end of this optional function any time prior to the end of data enqueued for
data enqueued for transmission with the "NORM_CMD(FLUSH)" messages transmission with the "NORM_CMD(FLUSH)" messages multiplexed with
multiplexed with ongoing data transmissions. The OPTIONAL NORM ongoing data transmissions. The OPTIONAL NORM positive
positive acknowledgment procedure is described in Section 5.5.3. acknowledgment procedure is described in Section 5.5.3.
5.1.1. Object Segmentation Algorithm 5.1.1. Object Segmentation Algorithm
NORM senders and receivers MUST use a common algorithm for logically NORM senders and receivers MUST use a common algorithm for logically
segmenting transport data into FEC encoding blocks and symbols so segmenting transport data into FEC encoding blocks and symbols so
that appropriate NACKs can be constructed to request repair of that appropriate NACKs can be constructed to request repair of
missing data. NORM FEC coding blocks are comprised of multi-byte missing data. NORM FEC coding blocks are comprised of multi-byte
symbols (segments) that are transmitted in the payload of "NORM_DATA" symbols (segments) that are transmitted in the payload of "NORM_DATA"
messages. Each "NORM_DATA" message will contain one or more source messages. Each "NORM_DATA" message will contain one or more source
or encoding symbol(s) identified by the "fec_payload_id" field and or encoding symbol(s) identified by the "fec_payload_id" field and
the NormSegmentSize sender parameter defines the maximum size (in the NormSegmentSize sender parameter defines the maximum size (in
bytes) of the "payload_data" field containing the content (a bytes) of the "payload_data" field containing the content (a
"segment"). The FEC encoding type and associated parameters govern "segment"). The FEC encoding type and associated parameters govern
the source block size (number of source symbols per coding block, the source block size (number of source symbols per coding block,
etc.). NORM senders and receivers use these FEC parameters, along etc.). NORM senders and receivers use these FEC parameters, along
with the NormSegmentSize and transport object size to compute the with the NormSegmentSize and transport object size to compute the
source block structure for transport objects. These parameters are source block structure for transport objects. These parameters are
provided in the FEC Object Transmission Information for each object. provided in the FEC Object Transmission Information for each object.
The block partitioning algorithm described in the FEC Building Block The block partitioning algorithm described in the FEC Building Block
document [RFC5052] is RECOMMENDED for use to compute a source block [RFC5052] is RECOMMENDED for use to compute a source block structure
structure such that all source blocks are as close to being equal such that all source blocks are as close to being equal length as
length as possible. This helps avoid the performance disadvantages possible. This helps avoid the performance disadvantages of "short"
of "short" FEC blocks. Note this algorithm applies only to the FEC blocks. Note this algorithm applies only to the statically-sized
statically-sized "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE" transport "NORM_OBJECT_DATA" and "NORM_OBJECT_FILE" transport object types
object types where the object size is fixed and predetermined. For where the object size is fixed and predetermined. For
"NORM_OBJECT_STREAM" objects, the object is segmented according to "NORM_OBJECT_STREAM" objects, the object is segmented according to
the maximum source block length given in the FEC Transmission the maximum source block length given in the FEC Transmission
Information, unless the FEC Payload ID indicates an alternative size Information, unless the FEC Payload ID indicates an alternative size
for a given block. for a given block.
5.2. Receiver Initialization and Reception 5.2. Receiver Initialization and Reception
The NORM protocol is designed such that receivers may join and leave The NORM protocol is designed such that receivers may join and leave
the group at will. However, some applications may be constrained the group at will. However, some applications may be constrained
such that receivers need to be members of the group prior to start of such that receivers need to be members of the group prior to start of
skipping to change at page 61, line 7 skipping to change at page 61, line 7
advertised in the "grtt" field of NORM sender messages. A minimum advertised in the "grtt" field of NORM sender messages. A minimum
""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver ""T_inactivity"" value of 1 second is RECOMMENDED. The NORM receiver
SHOULD reset this inactivity timer and repeat NACK initiation upon SHOULD reset this inactivity timer and repeat NACK initiation upon
timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon timeout for up to "NORM_ROBUST_FACTOR" times or more depending upon
the application's need for persistence by its receivers. It is also the application's need for persistence by its receivers. It is also
important that receivers rescale the ""T_inactivity"" timeout as the important that receivers rescale the ""T_inactivity"" timeout as the
sender's advertised GRTT changes. sender's advertised GRTT changes.
The NACKing procedure begins with a random backoff timeout. The The NACKing procedure begins with a random backoff timeout. The
duration of the backoff timeout is chosen using the "RandomBackoff" duration of the backoff timeout is chosen using the "RandomBackoff"
algorithm described in the Multicast NACK Building Block algorithm described in the Multicast NACK Building Block [RFC5401]
document[RFC5401] using ("Ksender*GRTTsender") for the "maxTime" using ("Ksender*GRTTsender") for the "maxTime" parameter and the
parameter and the sender advertised group size ("GSIZEsender") as the sender advertised group size ("GSIZEsender") as the "groupSize"
"groupSize" parameter. NORM senders provide values for "GRTTsender", parameter. NORM senders provide values for "GRTTsender", "Ksender"
"Ksender" and "GSIZEsender" via the "grtt", "backoff", and "gsize" and "GSIZEsender" via the "grtt", "backoff", and "gsize" fields of
fields of transmitted messages. The "GRTTsender" value is determined transmitted messages. The "GRTTsender" value is determined by the
by the sender based on feedback it has received from the group while sender based on feedback it has received from the group while the
the "Ksender" and "GSIZEsender" values may determined by application "Ksender" and "GSIZEsender" values may determined by application
requirements and expectations or ancillary information. The backoff requirements and expectations or ancillary information. The backoff
factor ""Ksender"" MUST be greater than "one" to provide for factor ""Ksender"" MUST be greater than "one" to provide for
effective feedback suppression. A value of "K = 4" is RECOMMENDED effective feedback suppression. A value of "K = 4" is RECOMMENDED
for the Any Source Multicast (ASM) model while a value of "K = 6" is for the Any Source Multicast (ASM) model while a value of "K = 6" is
RECOMMENDED for Single Source Multicast (SSM) operation. RECOMMENDED for Single Source Multicast (SSM) operation.
Thus: Thus:
T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender) T_backoff = RandomBackoff(Ksender*GRTTsender, GSIZEsender)
To avoid the possibility of NACK implosion in the case of sender or To avoid the possibility of NACK implosion in the case of sender or
skipping to change at page 66, line 47 skipping to change at page 66, line 47
Then, when the receivers generate feedback messages to the sender, an Then, when the receivers generate feedback messages to the sender, an
adjusted version of the sender timestamp is embedded in the feedback adjusted version of the sender timestamp is embedded in the feedback
message ("NORM_NACK" or "NORM_ACK"). The adjustment adds the amount message ("NORM_NACK" or "NORM_ACK"). The adjustment adds the amount
of time the receiver held the timestamp before generating its of time the receiver held the timestamp before generating its
response. Upon receipt of this adjusted timestamp, the sender is response. Upon receipt of this adjusted timestamp, the sender is
able to calculate the round-trip time to that receiver. able to calculate the round-trip time to that receiver.
The round-trip time for each receiver is fed into an algorithm that The round-trip time for each receiver is fed into an algorithm that
weights and smoothes the values for a conservative estimate of the weights and smoothes the values for a conservative estimate of the
GRTT. The algorithm and methodology are described in the Multicast GRTT. The algorithm and methodology are described in the Multicast
NACK Building Block document[RFC5401] in the section entitled "One- NACK Building Block [RFC5401] in the section entitled "One-to-Many
to-Many Sender GRTT Measurement". A conservative estimate helps Sender GRTT Measurement". A conservative estimate helps guarantee
guarantee feedback suppression at a small cost in overall protocol feedback suppression at a small cost in overall protocol repair
repair delay. The sender's current estimate of GRTT is advertised in delay. The sender's current estimate of GRTT is advertised in the
the "grtt" field found in all NORM sender messages. The advertised "grtt" field found in all NORM sender messages. The advertised GRTT
GRTT is also limited to a minimum of the nominal inter-packet is also limited to a minimum of the nominal inter-packet transmission
transmission time given the sender's current transmission rate and time given the sender's current transmission rate and system clock
system clock granularity. The reason for this additional limit is to granularity. The reason for this additional limit is to keep the
keep the receiver somewhat event-driven by making sure the sender has receiver somewhat event-driven by making sure the sender has had
had adequate time to generate any response to repair requests from adequate time to generate any response to repair requests from
receivers given transmit rate limitations due to congestion control receivers given transmit rate limitations due to congestion control
or configuration. or configuration.
When the NORM-CC Rate header extension is present in "NORM_CMD(CC)" When the NORM-CC Rate header extension is present in "NORM_CMD(CC)"
messages, the receivers respond to "NORM_CMD(CC)" messages as messages, the receivers respond to "NORM_CMD(CC)" messages as
described in Section 5.5.2, "NORM Congestion Control Operation". The described in Section 5.5.2, "NORM Congestion Control Operation". The
"NORM_CMD(CC)" messages are periodically generated by the sender as "NORM_CMD(CC)" messages are periodically generated by the sender as
described for congestion control operation. This provides for described for congestion control operation. This provides for
proactive, but controlled, feedback from the group in the form of proactive, but controlled, feedback from the group in the form of
"NORM_ACK" messages. This provides for GRTT feedback even if no "NORM_ACK" messages. This provides for GRTT feedback even if no
skipping to change at page 67, line 38 skipping to change at page 67, line 38
group per congestion control operation even though the sender may not group per congestion control operation even though the sender may not
be conducting congestion control rate adjustment. NORM operation be conducting congestion control rate adjustment. NORM operation
without congestion control should be considered only in closed without congestion control should be considered only in closed
networks. networks.
5.5.2. NORM Congestion Control Operation 5.5.2. NORM Congestion Control Operation
This section describes baseline congestion control operation for the This section describes baseline congestion control operation for the
NORM protocol (NORM-CC). The supporting NORM message formats and NORM protocol (NORM-CC). The supporting NORM message formats and
approach described here are an adaptation of the equation-based TCP- approach described here are an adaptation of the equation-based TCP-
Friendly Multicast Congestion Control (TFMCC) approach described in Friendly Multicast Congestion Control (TFMCC) approach[RFC4654].
[RFC4654]. This congestion control scheme is REQUIRED for operation This congestion control scheme is REQUIRED for operation within the
within the general Internet unless the NORM implementation is adapted general Internet unless the NORM implementation is adapted to use
to use another IETF-sanctioned reliable multicast congestion control another IETF-sanctioned reliable multicast congestion control
mechanism. With this TFMCC-based approach, the transmissions of NORM mechanism. With this TFMCC-based approach, the transmissions of NORM
senders are controlled in a rate-based manner as opposed to window- senders are controlled in a rate-based manner as opposed to window-
based congestion control algorithms as in TCP. However, it is based congestion control algorithms as in TCP. However, it is
possible that the NORM protocol message set may alternatively be used possible that the NORM protocol message set may alternatively be used
to support a window-based multicast congestion control scheme such as to support a window-based multicast congestion control scheme such as
PGMCC. The details of that alternative may be described separately PGMCC. The details of that alternative may be described separately
or in a future revision of this document. In either case (rate-based or in a future revision of this document. In either case (rate-based
TFMCC or window-based PGMCC), successful control of sender TFMCC or window-based PGMCC), successful control of sender
transmission depends upon collection of sender-to-receiver packet transmission depends upon collection of sender-to-receiver packet
loss estimates and RTTs to identify the congestion control bottleneck loss estimates and RTTs to identify the congestion control bottleneck
skipping to change at page 71, line 22 skipping to change at page 71, line 22
form of a "NORM_ACK" to this message. When a "NORM_CMD(CC)" is form of a "NORM_ACK" to this message. When a "NORM_CMD(CC)" is
received, non-CLR or non-PLR nodes initiate random feedback backoff received, non-CLR or non-PLR nodes initiate random feedback backoff
timeouts similar to that used when the receiver initiates a repair timeouts similar to that used when the receiver initiates a repair
cycle (see Section 5.3) in response to detection of data loss. The cycle (see Section 5.3) in response to detection of data loss. The
backoff timeout for the congestion control response is generated as backoff timeout for the congestion control response is generated as
follows: follows:
T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender) T_backoff = RandomBackoff(K*GRTTsender, GSIZEsender)
The ""RandomBackoff()"" algorithm provides a truncated exponentially The ""RandomBackoff()"" algorithm provides a truncated exponentially
distributed random number and is described in the Multicast NACK distributed random number and is described in the Multicast NACK
Building Block document[RFC5401]. The same backoff factor "K = Building Block [RFC5401]. The same backoff factor "K = Ksender" MAY
Ksender" MAY be used as with "NORM_NACK" suppression. However, in be used as with "NORM_NACK" suppression. However, in cases where the
cases where the application purposefully specifies a very small application purposefully specifies a very small "Ksender" backoff
"Ksender" backoff factor to minimize the NACK repair process latency factor to minimize the NACK repair process latency (trading off group
(trading off group size scalability), it is RECOMMENDED that a larger size scalability), it is RECOMMENDED that a larger backoff factor for
backoff factor for congestion control feedback is maintained, since congestion control feedback is maintained, since there may often be a
there may often be a larger volume of congestion control feedback larger volume of congestion control feedback than NACKs in many cases
than NACKs in many cases and some congestion control feedback latency and some congestion control feedback latency may be tolerable where
may be tolerable where reliable delivery latency is not. As reliable delivery latency is not. As previously noted, a backoff
previously noted, a backoff factor value of "K = 4" is generally factor value of "K = 4" is generally recommended for ASM operation
recommended for ASM operation and "K = 6" for SSM operation. A and "K = 6" for SSM operation. A receiver SHALL cancel the backoff
receiver SHALL cancel the backoff timeout and thus its pending timeout and thus its pending transmission of a "NORM_ACK(RTT)"
transmission of a "NORM_ACK(RTT)" message under the following message under the following conditions:
conditions:
1. The receiver generates another feedback message ("NORM_NACK" or 1. The receiver generates another feedback message ("NORM_NACK" or
other "NORM_ACK") before the congestion control feedback timeout other "NORM_ACK") before the congestion control feedback timeout
expires (these messages will convey the current congestion expires (these messages will convey the current congestion
control feedback information), control feedback information),
2. A "NORM_CMD(CC)" or other receiver feedback with an ordinally 2. A "NORM_CMD(CC)" or other receiver feedback with an ordinally
greater "cc_sequence" field value is received before the greater "cc_sequence" field value is received before the
congestion control feedback timeout expires (this is similar to congestion control feedback timeout expires (this is similar to
the TFMCC feedback round number), the TFMCC feedback round number),
3. When the "T_backoff" is greater than "1*GRTTsender". This 3. When the "T_backoff" is greater than "1*GRTTsender". This
skipping to change at page 77, line 46 skipping to change at page 77, line 46
RECOMMENDED for use as the group size estimate. RECOMMENDED for use as the group size estimate.
It is possible that group size may be algorithmically approximated It is possible that group size may be algorithmically approximated
from the volume of congestion control feedback messages which follow from the volume of congestion control feedback messages which follow
the exponentially weighted random backoff. However, the the exponentially weighted random backoff. However, the
specification of such an algorithm is currently beyond the scope of specification of such an algorithm is currently beyond the scope of
this document. this document.
6. Security Considerations 6. Security Considerations
The same security considerations that apply to the Multicast The same security considerations that apply to the Multicast NACK
NACK[RFC5401], TFMCC[RFC4654], and FEC[RFC5052] Building Blocks also [RFC5401], TFMCC [RFC4654], and FEC [RFC5052] Building Blocks also
apply to the NORM protocol. In addition to the vulnerabilities that apply to the NORM protocol. In addition to the vulnerabilities that
any IP and IP multicast protocol implementation may be generally any IP and IP multicast protocol implementation may be generally
subject to, the NACK-based feedback of NORM may be exploited by subject to, the NACK-based feedback of NORM may be exploited by
replay attacks which force the NORM sender to unnecessarily transmit replay attacks which force the NORM sender to unnecessarily transmit
repair information. This MAY be addressed by network layer IP repair information. This MAY be addressed by network layer IP
security implementations that guard against this potential security security implementations that guard against this potential security
exploitation or alternatively with a security mechanism that uses the exploitation or alternatively with a security mechanism that uses the
"EXT_AUTH" header extension for similar purposes. Such security "EXT_AUTH" header extension for similar purposes. Such security
mechanisms SHOULD be deployed and used when available. mechanisms SHOULD be deployed and used when available.
The NORM protocol is compatible with the use of IP security The NORM protocol is compatible with the use of IP security (IPsec)
(IPsec)[RFC4301] and the IPsec Encapsulating Security Payload (ESP) [RFC4301] and the IPsec Encapsulating Security Payload (ESP) protocol
protocol or Authentication Header (AF) extension can be used to or Authentication Header (AF) extension can be used to secure IP
secure IP packets transmitted by NORM participants. A baseline packets transmitted by NORM participants. A baseline approach to
approach to secure NORM operation using IPsec is described below. secure NORM operation using IPsec is described below. Compliant
Compliant implementations of this specification are REQUIRED to be implementations of this specification are REQUIRED to be compatible
compatible with IPsec usage as described in Section 6.1. with IPsec usage as described in Section 6.1.
Additionally, the "EXT_AUTH" header extension (HET = 1) is defined Additionally, the "EXT_AUTH" header extension (HET = 1) is defined
for use by security mechanisms to provide an alternative form of for use by security mechanisms to provide an alternative form of
authentication and/or encryption of NORM messages. The format of authentication and/or encryption of NORM messages. The format of
this header extension and its processing is outside the scope of this this header extension and its processing is outside the scope of this
document and is to be communicated out-of-band as part of the session document and is to be communicated out-of-band as part of the session
description. It is possible that an EXT_AUTH implementation of MAY description. It is possible that an EXT_AUTH implementation of MAY
also provide for encryption of NORM message payloads as well as also provide for encryption of NORM message payloads as well as
authentication. The use of this approach as compared to IPsec can authentication. The use of this approach as compared to IPsec can
allow for header compression techniques to be applied jointly to IP allow for header compression techniques to be applied jointly to IP
skipping to change at page 79, line 14 skipping to change at page 79, line 14
receivers MUST also maintain similar state for protection against receivers MUST also maintain similar state for protection against
possible replay of other receiver messages in ASM operation as well. possible replay of other receiver messages in ASM operation as well.
For example, a receiver could be suppressed from providing NACK or For example, a receiver could be suppressed from providing NACK or
congestion control feedback by replay of certain receiver messages. congestion control feedback by replay of certain receiver messages.
For these reasons, authentication of NORM messages (e.g., via IPsec) For these reasons, authentication of NORM messages (e.g., via IPsec)
SHOULD be applied for protection against similar attacks that use SHOULD be applied for protection against similar attacks that use
fabricated messages. Also, encryption of messages to provide fabricated messages. Also, encryption of messages to provide
confidentiality of application data and protect privacy of users MAY confidentiality of application data and protect privacy of users MAY
also be applied using IPsec or similar mechanisms. also be applied using IPsec or similar mechanisms.
When any applicable security measures are used, automated key When applicable security measures are used, automated key management
management mechanisms such as those described in the Group Domain of mechanisms such as those described in the Group Domain of
Interpretation (GDOI)[RFC3547], Multimedia Internet KEYing Interpretation (GDOI) [RFC3547], Multimedia Internet KEYing (MIKEY)
(MIKEY)[RFC3830] or Group Secure Association Key Management Protocol [RFC3830] or Group Secure Association Key Management Protocol
(GSAKMP)[RFC4535] specifications SHOULD be applied. (GSAKMP)[RFC4535] specifications SHOULD be 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 received data received data. Application-level integrity-checking of received data
content 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
skipping to change at page 82, line 27 skipping to change at page 82, line 27
the following IPsec capabilities are required. the following IPsec capabilities are required.
6.1.2.1. Selectors 6.1.2.1. Selectors
The implementation MUST be able to use the source address, The implementation MUST be able to use the source address,
destination address, protocol (UDP), and UDP port numbers as destination address, protocol (UDP), and UDP port numbers as
selectors in the SPD. selectors in the SPD.
6.1.2.2. Mode 6.1.2.2. Mode
IPsec in transport mode MUST be supported. The use of IPsec[RFC4301] IPsec in transport mode MUST be supported. The use of IPsec
processing for secure NORM traffic MUST be configured such that [RFC4301] processing for secure NORM traffic MUST be configured such
unauthenticated packets are not received by the NORM protocol that 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] is rekeying such as GDOI [RFC3547], GSAKMP [RFC4535], or MIKEY [RFC3830]
RECOMMENDED for use. Relatively short-lived NORM sessions MAY be is RECOMMENDED for use. Relatively short-lived NORM sessions MAY be
able to use Manual Keying with a single, preplaced key, particularly able to use Manual Keying with a single, preplaced key, particularly
if Extended Sequence Numbering (ESN) [RFC4303] is available in the if Extended Sequence Numbering (ESN) [RFC4303] is available in the
IPsec implementation used. It should also be noted that it may be IPsec implementation used. It should also be noted that it may be
possible for key update messages (e.g., the GDOI GROUPKEY-PUSH possible for key update messages (e.g., the GDOI GROUPKEY-PUSH
message) to be included as part of the NORM application reliable data message) to be included as part of the NORM application reliable data
transmission if appropriate interfaces are available between the NORM transmission if appropriate interfaces are available between the NORM
application and the key management daemon. application and the key management daemon.
6.1.2.4. Security Policy 6.1.2.4. Security Policy
skipping to change at page 84, line 14 skipping to change at page 84, line 14
"ietf:rmt:norm:extension" "ietf:rmt:norm:extension"
The NORM Header Extension Type field is an 8-bit value. The values The NORM Header Extension Type field is an 8-bit value. The values
of this field identify extended header content that allows the of this field identify extended header content that allows the
protocol functionality to be expanded to include additional features 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" namespace 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 extensions of a fixed 4-byte length. NORM Header {128,255} indicate extensions of a fixed 4-byte length. This
Extension Type value assignment requests are granted on a specification registers the following NORM Header Extension Types:
"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.
For example, it may be possible for protocol implementations to
ignore unknown header extensions in many cases.
This specification registers the following NORM Header Extension
Types:
+-------+------------+--------------------+ +-------+------------+--------------------+
| 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 |
+-------+------------+--------------------+ +-------+------------+--------------------+
Requests for assignment of additional NORM Header Extension Type
values are granted on a "Specification Required" basis as defined by
IANA Guidelines [RFC5226]. Any such header extension specifications
MUST include a description of protocol actions to be taken when the
extension type is encountered by a protocol implementation not
supporting that specific option. For example, it may be possible for
protocol implementations to ignore unknown header extensions in many
cases.
7.1.2. NORM Stream Control Codes 7.1.2. NORM Stream Control Codes
This document defines a namespace for NORM Stream Control Codes This document defines a namespace for NORM Stream Control Codes
named: named:
"ietf:rmt:norm:streamControlCode" "ietf:rmt:norm:streamControlCode"
NORM Stream Control Codes are 16-bit values that may be inserted NORM Stream Control Codes are 16-bit values that may be inserted
within a "NORM_OBJECT_STREAM" delivery object to convey sequenced, within a "NORM_OBJECT_STREAM" delivery object to convey sequenced,
out-of-band (with respect to the stream data) control signaling out-of-band (with respect to the stream data) control signaling
applicable to the referenced stream object. These control codes are applicable to the referenced stream object. These control codes are
expected to be delivered to the application or protocol to be delivered to the application or protocol implementation with
implementation with the reliable delivery, in-order with respect to reliable delivery, in-order with respect to the their inserted
the their inserted position within the stream. NORM Stream Control position within the stream. This specification registers the
Code value assignment requests are granted on a "Specification following NORM Stream Control Code:
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 | | Value | Name | Reference |
+-------+-------------------+--------------------+ +-------+-------------------+--------------------+
| 0 | "NORM_STREAM_END" | This specification | | 0 | "NORM_STREAM_END" | This specification |
+-------+-------------------+--------------------+ +-------+-------------------+--------------------+
Additional NORM Stream Control Code value assignment requests are
granted on a "Specification Required" basis as defined by IANA
Guidelines [RFC5226]. The full 16-bit space outside of the value
assigned in this specification are available for future assignment.
Note that in addition to describing the control code's expected
interpretation, such specifications MUST include a description of
protocol actions to be taken when the control code is encountered by
a protocol implementation not supporting that specific option.
7.1.3. NORM_CMD Message Sub-types 7.1.3. NORM_CMD Message Sub-types
This document defines a namespace for "NORM_CMD" Message Sub-types This document defines a namespace for "NORM_CMD" Message Sub-types
named: named:
"ietf:rmt:norm:command" "ietf:rmt:norm:command"
It is possible that specifications extending NORM may wish to define The "NORM_CMD" sub-type field is an 8-bit value with valid values in
additional "NORM_CMD" messages to enhance protocol functionality. the range of 1-255. Note the value 0 is reserved to indicate an
The "NORM_CMD" sub-type field is an 8-bit value. Note that the invalid "NORM_CMD" message sub-type. The current specification
specification already provides for an "application-defined" defines a number of "NORM_CMD" message sub-types that senders can use
"NORM_CMD" message sub-type that may be used at the discretion of to signal the receivers in various aspects of NORM protocol
individual applications using NORM for transport. These operation. This specification registers the following "NORM_CMD"
"application-defined" commands may be suitable for many application- Message Sub-types:
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 | | Value | Name | Reference |
+-------+-------------------------+--------------------+ +-------+-------------------------+--------------------+
| 0 | reserved | This specification |
| 1 | "NORM_CMD(FLUSH)" | This specification | | 1 | "NORM_CMD(FLUSH)" | This specification |
| 2 | "NORM_CMD(EOT)" | This specification | | 2 | "NORM_CMD(EOT)" | This specification |
| 3 | "NORM_CMD(SQUELCH)" | This specification | | 3 | "NORM_CMD(SQUELCH)" | This specification |
| 4 | "NORM_CMD(CC)" | This specification | | 4 | "NORM_CMD(CC)" | This specification |
| 5 | "NORM_CMD(REPAIR_ADV)" | This specification | | 5 | "NORM_CMD(REPAIR_ADV)" | This specification |
| 6 | "NORM_CMD(ACK_REQ)" | This specification | | 6 | "NORM_CMD(ACK_REQ)" | This specification |
| 7 | "NORM_CMD(APPLICATION)" | This specification | | 7 | "NORM_CMD(APPLICATION)" | This specification |
+-------+-------------------------+--------------------+ +-------+-------------------------+--------------------+
Future specifications extending NORM may wish to define additional
"NORM_CMD" messages to enhance protocol functionality. "NORM_CMD"
message sub-type value assignment requests are granted on a
"Specification Required" basis as defined by IANA Guidelines
[RFC5226]. Note that in addition to describing the command sub-
type's expected interpretation, specifications MUST include a
description of protocol actions to be taken when the command is
encountered by a protocol implementation not supporting that specific
option.
Note that this 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.
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
 End of changes. 42 change blocks. 
208 lines changed or deleted 226 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/