It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.
NORM operates on top of the User Datagram Protocol (UDP), and ensures reliable communication based upon a negative acknowledgement (NACK), selective Automatic Repeat Request (ARQ) mechanism, as opposed to the positive acknowledgement (ACK) approach that the standard Transmission Control Protocol (TCP) uses.
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.
The TCP protocol is the principal means of ensuring reliable unicast (point-to-point) transport.
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.
[1] 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 (MDP)[2] was an initial attempt to ensure reliability and to address the problem of ACK implosions through the use of NACKs.
MDP also used packet-level forward error correction coding concepts as a repair mechanism.
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.
A fundamental assumption about a NORM session is that it will consist of a single transmitter communicating with a group of receivers.
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.
[15] These messages serve to collect round-trip timing, gather and send data related to congestion control, synchronize repair windows, and make notifications of a sender's status.
... NORM_NACK messages, defined in RFC 5740 Section 4.3.1, are used primarily for receivers to request repairs of sender content.
[16] Additionally, these messages contain fields to provide information to the sender(s) related to round-trip timing collection and congestion control.
... NORM_ACK messages, defined in RFC 5740 4.3.2, are used primarily to support congestion control operations and round-trip timing measurements.
At the same time, the sender periodically transmits NORM_CMD(CC) messages as needed to collect feedback information necessary for congestion control and other session management activities.
[5] Unlike the connection-oriented TCP protocol, NORM does not establish a session with a setup mechanism (i.e., a three-way handshake).
A range of NORM_CMD message sub-types is reserved to support session control protocols that may be developed in the future.
NORM uses a TCP-Friendly congestion control scheme that enables it to fairly share available bandwidth with TCP and other transport protocols.
This can lead to limitations in wireless networks, where packet loss is often due to bit errors or contention.
With this option the sender requests positive acknowledgement from a specific set of receivers regarding the successful reception of a designated point, or watermark, in the current transmission.
This option is based on a lack of negative acknowledgement (NACK) repair requests from the receiver set.
This option holds transmit data and limits repair window advancement based on group round-trip timing (GRTT) and NACK activity.
This option deliberately disables flow control mechanisms and allows the application to push transmission forward with newly enqueued data in a best effort manner.
If a large number of receivers NACK simultaneously, this could overwhelm the sender as well as the entire network.
The United States Naval Research Laboratory maintains a freely-available, reference implementation of the NORM protocol on GitHub.