NACK-Oriented Reliable Multicast
NACK-Oriented Reliable Multicast is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force in Request for Comments , which was published in November 2009.
NORM operates on top of the User Datagram Protocol, and ensures reliable communication based upon a negative acknowledgement, selective Automatic Repeat Request mechanism, as opposed to the positive acknowledgement approach that the standard Transmission Control Protocol uses. In other words, receivers using NORM only send feedback when they do not receive a packet, as opposed to the TCP model where receivers regularly acknowledge packet receipt as part of it protocol operation. This allows NORM to support large-scale receiver groups.
To support further scalability, NORM also employs packet erasure coding using forward error correction codes coupled with suppression of redundant NACK feedback from the receiver group. Additionally, NORM can be configured to operate with “silent receivers” relying upon its packet erasure coding for high assurance delivery, thus operating as a broadcast-only protocol. The FEC can be configured to be used either reactively or proactively, or in a hybrid manner that allows tradeoffs in latency and network overhead.
Along with supporting reliable transport, NORM also provides TCP-compatible congestion control as well as end-to-end flow control. Unlike TCP, which uses the ACK mechanism for congestion control and flow control, NORM uses separate mechanisms for each. This allows for a wide variety of configurations to meet different application data delivery needs.
NORM also supports additional signaling mechanisms to facilitate session control, application-controlled positive acknowledgement, and other functions towards building complete point-to-point and group network communications applications that are highly robust and efficient.
Although NORM was developed primarily to support multicast group communication, it also supports unicast data transfers.
Background
In the TCP/IP network model, the transport layer of the network is responsible for the reliable transport of data. The TCP protocol is the principal means of ensuring reliable unicast transport. TCP does this through an ACK mechanism.With the ACK mechanism, data packets are sequentially numbered, and the sender does not send a packet in a sequence until it receives an acknowledgement from the receiver that the previous packet has been successfully received. If the sender does not receive an ACK after a specified time period, it resends the associated packet. The sender will continue doing this until it receives an ACK. This is loosely analogous to a human listener nodding his or her head and saying "uh-huh" in a one-on-one conversation between persons.
An early problem noted with TCP's ACK mechanism was it did not work well in large multicast group communications. In multicast group communications, data packets are transmitted to a group of receivers simultaneously. In large multicast groups, the use of ACKs can create “ACK implosions,” in which a large number of simultaneous ACKs can overwhelm the sender. This is loosely analogous to a large roomful of human listeners nodding their heads and saying "uh-huh" while a speaker is talking.
The Multicast Dissemination Protocol was an initial attempt to ensure reliability and to address the problem of ACK implosions through the use of NACKs. MDP used selective negative acknowledgement to support reliability. Additionally, MDP implemented probabilistic techniques to suppress redundant NACKs in the multicast group.
MDP also used packet-level forward error correction coding concepts as a repair mechanism. Encoded parity repair packets were generally sent in response to repair requests by receivers. In this way no additional protocol overhead was added above selective retransmission methods. Additionally, MDP allowed the protocol to be optionally configured to send proactive repair packets in the original data transmission block.
MDP was a direct predecessor to NORM, with an initial IETF draft published in November 1996. The National Aeronautics and Space Administration adopted MDP for reliable file transfers during space missions., and the U.S. Army used in for tactical group messaging in its Force Battle Command Brigade and Below system.
Several other approaches to reliable multicast were being developed at approximately the same time, and in April 1999, the IETF chartered the Reliable Multicast Transport Working Group to standardize reliable multicast transport.
The RMTWG pursued the strategy of developing building blocks and protocol instantiations. This strategy avoided a "one size fits all" protocol, which in turn could accommodate the large number of applications and types of applications that reliable multicast could support.
Building blocks were defined as “a set of easily-separable coarse-grained modular components that are common to multiple protocols along with abstract APIs that define a building block's access methods and their arguments.” Initial building blocks included negative acknowledgments, forward error correction, a generic signaling mechanism for router assist, and transport protection
Protocol instantiations were defined as “specifications that define the necessary gluing logic and minimal additional functionality required to realize a working protocol from one or more building blocks.” Those specifications would also include an abstract API that defined the interface between the protocol implementation and an application. Two protocol instantiations were chosen:
- A NACK-based protocol
- An Asynchronous Layered Coding protocol
The RMTWG was disestablished in September 2013.
NORM architectural constructs
The following architectural constructs are defined in RFC 5740 Section 2, Architecture Definition.The NORM message is the fundamental NORM architectural construct. A NORM message is contained in the data field of a UDP datagram.
A NORM object refers to one of the three different types of bulk data carried in a NORM message:
- NORM_OBJECT_DATA
- NORM_OBJECT_FILE
- NORM_OBJECT_STREAM
The NORM_OBJECT_STREAM refers to streams of continuous data content. NORM supports reliable transport of streaming data similar to that of TCP, with an exception being that NORM receivers are able to join in the reception of stream content without regard for the point of time in the stream.
A NORM session refers to the exchange of information among two or more network hosts using NORM. Typically a NORM session takes place using pre-determined IP addresses and port numbers, which are usually associated with IP multicast group addresses that are determined prior to the session. These addresses may be determined using other protocols, such as the Session Description Protocol or the Session Announcement Protocol . Although NORM was specifically designed for multicast group communication, it supports unicast communication, also.
A fundamental assumption about a NORM session is that it will consist of a single transmitter communicating with a group of receivers. Multiple senders may operate in a given NORM session, although each receiver must maintain state for each sender.
A NORM node refers to an individual node taking part in a NORM session. Each node has a unique identifier. When a node transmits a NORM message, this identifier is noted as the source_id.
A NORM instance refers to an individual node in the context of a continuous segment of a NORM session. When a node joins a NORM session, it has a unique node identification as well as an instance identification. If the node leaves the session for any reason, and later rejoins the session, the node identification remains the same, but the instance identification changes. The current instance is noted as the instance_id.
NORM message structure
NORM has two general message classes, sender and receiver messages, that are defined in RFC 5740 Section 4, NORM Message Formats. NORM sender message types are: NORM_DATA, NORM_INFO, and NORM_CMD. NORM receiver message types are: NORM_NACK, NORM_ACK, and NORM_REPORT.All NORM messages consist of a mandatory common header, a message type header, and a payload section. An optional extension field that specifies the error correction encoding being used, the congestion control algorithm, or other session management information, can be inserted between the header and payload sections.
NORM Common Message Header
All NORM messages begin with the following common header, defined in RFC 5740, Section 4.1, NORM Common Message Header and Extension.;version : The protocol version number.
;type : The NORM message type.
;hdr_len : The number of 32-bit words that constitute the given message's header portion. This is used to identify the addition of header extensions. If the "hdr_len" value is greater than the base value for the given message type, it implies the presence of a header extension.
;sequence : Serves two purposes :
;source_id : The unique identify of the node that originated the message within the context of a given NORM session.
NORM_DATA Message Type
The NORM_DATA message, defined in RFC 5740 Section 4.2.1, is the most common message type transmitted by NORM senders. NORM_DATA messages carry segmented data content for NORM_OBJECT_DATA, NORM_OBJECT_FILE, and NORM_OBJECT_STREAM types.;instance_id : A unique identification of the current instance of participation in the NORM session.
;grtt : The sender's current estimate of group round-trip time.
;backoff : A value used by receivers to determine the maximum backoff timer value when using timer-based NORM NACK feedback suppression mechanisms.
;gsize : The sender's current estimate of group size.
;flags : Binary flags providing information to assist the receiver in appropriately handling the payload.
;fec_id : The FEC Encoding Identifier. This is described in the FEC Building Block document .
;object_transport_id : A value assigned by the sender to NORM objects being transmitted that receivers use for transmissions and repair requests. It is increased in a monotonically incremental manner.
;fec_payload_id : An identifier for the attached NORM_DATA payload content.
;Note 1 : payload_length, payload_msg, and payload_offset only pertain to NORM_OBJECT_STREAM content.