configured to proactively transmit some amount of redundant FEC
symbols along with the original content to potentially enhance
performance (e.g., improved delay) at the cost of additional
transmission overhead. This option may be sensible for certain
network conditions and can allow for robust, asymmetric multicast
(e.g., unidirectional routing, satellite, cable) [15] with reduced
receiver feedback, or, in some cases, no feedback.
A sender message of type NORM_INFO is also defined and is used to
carry OPTIONAL "out-of-band" context information for a given
transport object. A single NORM_INFO message can be associated with
a NormObject. Because of its atomic nature, missing NORM_INFO
messages can be NACKed and repaired with a slightly lower delay
process than NORM’s general FEC-encoded data content. NORM_INFO may
serve special purposes for some bulk transfer, reliable multicast
applications where receivers join the group mid-stream and need to
ascertain contextual information on the current content being
transmitted. The NACK process for NORM_INFO will be described later.
When the NORM_INFO message type is used, its transmission should
precede transmission of any NORM_DATA message for the associated
NormObject.
The sender also generates messages of type NORM_CMD to assist in
certain protocol operations such as congestion control, end-of-
transmission flushing, round trip time estimation, receiver
synchronization, and optional positive acknowledgment requests or
application defined commands. The transmission of NORM_CMD messages
from the sender is accomplished by one of three different procedures.
These procedures are: single, best effort unreliable transmission of
the command; repeated redundant transmissions of the command; and
positively-acknowledged commands. The transmission technique used
for a given command depends upon the function of the command.
Several core commands are defined for basic protocol operation.
Additionally, implementations MAY wish to consider providing the
OPTIONAL application-defined commands that can take advantage of the
transmission methodologies available for commands. This allows for
application-level session management mechanisms that can make use of
information available to the underlying NORM protocol engine (e.g.,
round-trip timing, transmission rate, etc.).
NORM receivers generate messages of type NORM_NACK or NORM_ACK in
response to transmissions of data and commands from a sender. The
NORM_NACK messages are generated to request repair of detected data
transmission losses. Receivers generally detect losses by tracking
the sequence of transmission from a sender. Sequencing information
is embedded in the transmitted data packets and end-of-transmission
commands from the sender. NORM_ACK messages are generated in
response to certain commands transmitted by the sender. In the
general (and most scalable) protocol mode, NORM_ACK messages are sent
only in response to congestion control commands from the sender. The
feedback volume of these congestion control NORM_ACK messages is
controlled using the same timer-based probabilistic suppression
techniques as for NORM_NACK messages to avoid feedback implosion. In
order to meet potential application requirements for positive
acknowledgment from receivers, other NORM_ACK messages are defined
and available for use. All sender and receiver transmissions are
subject to rate control governed by a peak transmission rate set for
each participant by the application. This can be used to limit the
quantity of multicast data transmitted by the group. When NORM’s
congestion control algorithm is enabled the rate for senders is
automatically adjusted. In some networks, it may be desirable to
establish minimum and maximum bounds for the rate adjustment
depending upon the application even when dynamic congestion control
is enabled. However, in the case of the general Internet, congestion
control policy SHALL be observed that is compatible with coexistent
TCP flows.
2.2. Protocol Building Blocks
The operation of the NORM protocol is based primarily upon the
concepts presented in the Nack-Oriented Reliable Multicast (NORM)
Building Block document [4]. This includes the basic NORM
architecture and the data transmission, repair, and feedback
strategies discussed in that document. Additional reliable multicast
building blocks are applied in creating the full NORM protocol
instantiation [16]. NORM also makes use of Forward Error Correction
encoding techniques for repair messaging and optional transmission
robustness as described in [10]. NORM uses the FEC Payload ID as
specified by the FEC Building Block Document [5]. Additionally, for
congestion control, this document includes a baseline congestion
control mechanism (NORM-CC) based on the TCP-Friendly Multicast
Congestion Control (TFMCC) scheme described in [19].
2.3. Design Tradeoffs
While the various features of NORM are designed to provide some
measure of general purpose utility, it is important to emphasize the
understanding that "no one size fits all" in the reliable multicast
transport arena. There are numerous engineering tradeoffs involved
in reliable multicast transport design and this requires an increased
awareness of application and network architecture considerations.
Performance requirements affecting design can include: group size,
heterogeneity (e.g., capacity and/or delay), asymmetric delivery,
data ordering, delivery delay, group dynamics, mobility, congestion
control, and transport across low capacity connections. NORM
contains various parameters to accommodate many of these differing
requirements. The NORM protocol and its mechanisms MAY be applied in
multicast applications outside of bulk data transfer, but there is an
assumed model of bulk transfer transport service that drives the
trade-offs that determine the scalability and performance described
in this document.
The ability of NORM to provide reliable data delivery is also
governed by any buffer constraints of the sender and receiver
applications. NORM protocol implementations SHOULD be designed to
operate with the greatest efficiency and robustness possible within
application-defined buffer constraints. Buffer requirements for
reliability, as always, are a function of the delay-bandwidth product
of the network topology. NORM performs best when allowed more
buffering resources than typical point-to-point transport protocols.
This is because NORM feedback suppression is based upon randomly-
delayed transmissions from the receiver set, rather than immediately
transmitted feedback. There are definitive tradeoffs between buffer
utilization, group size scalability, and efficiency of performance.
Large buffer sizes allow the NORM protocol to perform most
efficiently in large delay-bandwidth topologies and allow for longer
feedback suppression backoff timeouts. This yields improved group
size scalability. NORM can operate with reduced buffering but at a
cost of decreased efficiency (lower relative goodput) and reduced
group size scalability.
3. Conformance Statement
This Protocol Instantiation document, in conjunction with the RMT
Building Block documents of [4] and [5], completely specifies a
working reliable multicast transport protocol that conforms to the
requirements described in RFC 2357 [17].
This document specifies the following message types and mechanisms
which are REQUIRED in complying NORM protocol implementations:
+--------------------+-----------------------------------------------+
| Message Type | Purpose |
+--------------------+-----------------------------------------------+
|NORM_DATA | Sender message for application data |
| | transmission. Implementations must support |
| | at least one of the NORM_OBJECT_DATA, |
| | NORM_OBJECT_FILE, or NORM_OBJECT_STREAM |
| | delivery services. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_DATA |
| | messages. |
+--------------------+-----------------------------------------------+
|NORM_CMD(FLUSH) | Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM_DATA |
| | transmissions. Note the use of the |
| | NORM_CMD(FLUSH) for positive acknowledgment |
| | of data receipt is OPTIONAL. |
+--------------------+-----------------------------------------------+
|NORM_CMD(SQUELCH) | Sender command to advertise its current valid |
| | repair window in response to invalid requests |
| | for repair. |
+--------------------+-----------------------------------------------+
|NORM_CMD(REPAIR_ADV)| Sender command to advertise current repair |
| | (and congestion control state) to group when |
| | unicast feedback messages are detected. Used |
| | to control/suppress excessive receiver |
| | feedback in asymmetric multicast topologies. |
+--------------------+-----------------------------------------------+
|NORM_CMD(CC) | Sender command used in collection of round |
| | trip timing and congestion control status |
| | from group (this may be OPTIONAL if |
| | alternative congestion control mechanism and |
| | round trip timing collection is used). |
+--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
| | missing transmitted content. |
+--------------------+-----------------------------------------------+
+--------------------+-----------------------------------------------+
|NORM_ACK | Receiver message used to proactively provide |
| | feedback for congestion control purposes. |
| | Also used with the OPTIONAL NORM Positive |
| | Acknowledgment Process. |
+--------------------+-----------------------------------------------+
This document also describes the following message types and
associated mechanisms which are OPTIONAL for complying NORM protocol
implementations:
+----------------------+----------------------------------------------+
| Message Type | Purpose |
+----------------------+----------------------------------------------+
|NORM_INFO | Sender message for providing ancillary |
| | context information associated with NORM |
| | transport objects. The use of the NORM FEC |
| | Object Transmission Information header |
| | extension is OPTIONAL with NORM_INFO |
| | messages. |
+----------------------+----------------------------------------------+
|NORM_CMD(EOT) | Sender command to indicate it has reached |
| | end-of-transmission and will no longer |
| | respond to repair requests. |
+----------------------+----------------------------------------------+
|NORM_CMD(ACK_REQ) | Sender command to support application- |
| | defined, positively acknowledged commands |
| | sent outside of the context of the bulk data |
| | content being transmitted. The NORM Positive|
| | Acknowledgment Procedure associated with this|
| | message type is OPTIONAL. |
+----------------------+----------------------------------------------+
|NORM_CMD(APPLICATION) | Sender command containing application-defined|
| | commands sent outside of the context of the |
| | bulk data content being transmitted. |
+----------------------+----------------------------------------------+
|NORM_REPORT | Optional message type reserved for |
| | experimental implementations of the NORM |
| | protocol. |
+----------------------+----------------------------------------------+
4. Message Formats
As mentioned in Section 2.1, there are two primary classes of NORM
messages: sender messages and receiver messages. NORM_CMD,
NORM_INFO, and NORM_DATA message types are generated by senders of
data content, and NORM_NACK and NORM_ACK messages generated by
receivers within a NormSession. An auxiliary message type of
NORM_REPORT is also provided for experimental purposes. This section
describes the message formats used by the NORM protocol. These
messages and their fields are referenced in the detailed functional
description of the NORM protocol given in Section 5. Individual NORM
messages are designed to be compatible with the MTU limitations of
encapsulating Internet protocols including IPv4, IPv6, and UDP. The
current NORM protocol specification assumes UDP encapsulation and
leverages the transport features of UDP. The NORM messages are
independent of network addresses and can be used in IPv4 and IPv6
networks.
4.1. NORM Common Message Header and Extensions
There are some common message fields contained in all NORM message
types. Additionally, a header extension mechanism is defined to
expand the functionality of the NORM protocol without revision to
this document. All NORM protocol messages begin with a common header
with information fields as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type | hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Common Message Header Format
The "version" field is a 4-bit value indicating the protocol version
number. NORM implementations SHOULD ignore received messages with
version numbers different from their own. This number is intended to
indicate and distinguish upgrades of the protocol which may be non-
interoperable. The NORM version number for this specification is 1.
The message "type" field is a 4-bit value indicating the NORM
protocol message type. These types are defined as follows:
Message Value
NORM_INFO 1
NORM_DATA 2
NORM_CMD 3
NORM_NACK 4
NORM_ACK 5
NORM_REPORT 6
The 8-bit "hdr_len" field indicates the number of 32-bit words that
comprise the given message’s header portion. This is used to
facilitate header extensions that may be applied. The presence of
header extensions are implied when the "hdr_len" value is greater
than the base value for the given message "type".
The "sequence" field is a 16-bit value that is set by the message
originator as a monotonically increasing number incremented with each
NORM message transmitted to a given destination address. A
"sequence" field number space SHOULD be maintained for messages sent
to the NormSession group address. This value can be monitored by
receiving nodes to detect packet losses in the transmission from a
sender and used in estimating raw packet loss for congestion control
purposes. Note that this value is NOT used in the NORM protocol to
detect missing reliable data content and does NOT identify the
application data or FEC payload that may be attached. With message
authentication, the "sequence" field may also be leveraged for
protection from message "replay" attacks, particularly of NORM_NACK
or other feedback messages. In this case, the receiver node should
maintain a monotonically increasing "sequence" field space for each
destination to which it transmits (this may be multiple destinations
when unicast feedback is used). The size of this field is intended
to be sufficient to allow detection of a reasonable range of packet
loss within the delay-bandwidth product of expected network
connections.
The "source_id" field is a 32-bit value identifying the node that
sent the message. A participant’s NORM node identifier (NormNodeId)
can be set according to application needs but unique identifiers must
be assigned within a single NormSession. In some cases, use of the
host IP address or a hash of it can suffice, but alternative
methodologies for assignment and potential collision resolution of
node identifiers within a multicast session need to be considered.
For example, the "source identifier" mechanism defined in the Real-
Time Protocol (RTP) specification [18] may be applicable to use for
NORM node identifiers. At this point in time, the protocol makes no
assumptions about how these unique identifiers are actually assigned.
NORM Header Extensions
When header extensions are applied, they follow the message type’s
base header and precede any payload portion. There are two formats
for header extensions, both of which begin with an 8-bit "het"
(header extension type) field. One format is provided for variable-
length extensions with "het" values in the range from 0 through 127.
The other format is for fixed length (one 32-bit word) extensions
with "het" values in the range from 128 through 255. These formats
are given here:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het <=127 | hel | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Header Extension Content |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Variable Length Header Extension Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| het >=128 | reserved | Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Fixed Length (32-bit) Header Extension Format
The "Header Extension Content" portion of these header extension
format is defined for each header extension type defined for NORM
messages. Some header extensions are defined within this document
for NORM baseline FEC and congestion control operations.
4.2. Sender Messages
NORM sender messages include the NORM_DATA type, the NORM_INFO type,
and the NORM_CMD type. NORM_DATA and NORM_INFO messages contain
application data content while NORM_CMD messages are used for various
protocol control functions.
4.2.1. NORM_DATA Message
The NORM_DATA message is expected to be the predominant type
transmitted by NORM senders. These messages are used to encapsulate
segmented data content for objects of type NORM_OBJECT_DATA,
NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. NORM_DATA messages may
contain original or FEC-encoded application data content.
The format of NORM_DATA messages is comprised of three logical
portions: 1) a fixed-format NORM_DATA header portion, 2) a FEC
Payload ID portion with a format dependent upon the FEC encoding
used, and 3) a payload portion containing source or encoded
application data content. Note for objects of type
NORM_OBJECT_STREAM, the payload portion contains additional fields
used to appropriately recover stream content. NORM implementations
MAY also extend the NORM_DATA header to include a FEC Object
Transmission Information (EXT_FTI) header extension. This allows
NORM receivers to automatically allocate resources and properly
perform FEC decoding without the need for pre-configuration or out-
of-band information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|version| type=2| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| header_extensions (if applicable) |