NACK-Oriented Reliable Multicast (NORM) Transport Protocol
obsoletes
- rfc-3940 — Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
Extracted elements (33)
FEC-based repair was incorporated to reduce both the volume of NACK messages and the number of repair transmissions. A single FEC parity segment can satisfy multiple receivers' differing erasure patterns simultaneously, unlike segment-by-segment repair that would require individual retransmissions for each unique loss pattern in the group.
NACK-based feedback rather than positive ACKs was chosen for scalability: in a large multicast group, having all receivers positively acknowledge every packet would cause feedback implosion. Selective NACKs are sent only to report losses, and probabilistic suppression (via backoff timers) prevents multiple receivers from sending duplicate NACKs for the same missing segment.
NORM's 'grtt' (Group Round-Trip Time) value is carried in every sender message rather than communicated only during explicit GRTT probes. This allows newly joining receivers to immediately obtain RTT information needed to set their backoff timers, enabling rapid and correct participation without waiting for a dedicated GRTT measurement exchange.
NORM implementations SHOULD ignore received messages whose 'version' field differs from their own, as differing version numbers indicate non-interoperable protocol upgrades. The current version number is 1. This allows future protocol versions to coexist on the same multicast group without causing mis-processing.
NORM is compatible with both IPv4 and IPv6. It can operate with NAT devices provided the NAT supports IP multicast and/or can maintain UDP source port mappings for unicast return-path feedback. NORM does not define NAT traversal mechanisms itself; correct NAT behavior is an environmental prerequisite.
Each NormNode MUST have a uniquely assigned 32-bit NormNodeId within a single NormSession. NormNodeId 0x00000000 is reserved as NORM_NODE_NONE (invalid) and 0xffffffff as NORM_NODE_ANY (wildcard). Duplicate NormNodeIds would prevent proper demultiplexing of sender repair responses and congestion control.
NORM_INFO content size MUST fit into the payload portion of a single NORM message (i.e., one NormSegmentSize). This atomic constraint enables efficient repair of NORM_INFO without the multi-round FEC repair process required for NORM_DATA.
NORM receivers SHOULD set the 'sequence' field of NORM_NACK and NORM_ACK messages to enable replay-attack protection. A separate, monotonically increasing sequence number space MUST be maintained for each distinct destination address (session multicast address or sender unicast address) to which feedback is sent.
NORM senders MUST maintain a monotonically increasing sequence number space for NORM_INFO, NORM_DATA, and NORM_CMD messages so that receivers can estimate packet loss for congestion control. This 'sequence' field is explicitly NOT part of NORM reliability procedures; FEC payload identifiers detect missing content.
NORM SHALL be capable of operating end-to-end with no assistance from intermediate systems beyond basic IP multicast group management, routing, and forwarding. It SHALL also operate in asymmetric topologies (e.g., SSM) where only unicast return paths are available from receivers to senders.
Receivers SHOULD NOT execute repair requests (NACKs) for objects marked with NORM_FLAG_UNRELIABLE, since the sender will not provide repair for those objects. If a receiver erroneously NACKs such an object, the sender SHALL respond with NORM_CMD(SQUELCH) to suppress further invalid requests.
Sender messages (NORM_INFO, NORM_DATA, NORM_CMD) SHALL be governed by congestion control for Internet use. In the general Internet, the congestion control policy SHALL be compatible with coexistent TCP flows.
Small block, systematic FEC codes (fec_id=129) are RECOMMENDED for most NORM purposes and are specifically RECOMMENDED for NORM_OBJECT_STREAM transport for most efficient performance.
NORM congestion control (NORM-CC) is based on the TCP-Friendly Multicast Congestion Control (TFMCC) scheme. The sender collects round-trip timing via NORM_CMD(CC) and NORM_ACK feedback to dynamically adjust its transmission rate to be TCP-fair. The 'grtt' field in every sender message advertises the sender's current Group Round-Trip Time estimate.
NORM defines six message types: NORM_INFO(1) for out-of-band context, NORM_DATA(2) for application data/FEC, NORM_CMD(3) for control functions, NORM_NACK(4) for repair requests, NORM_ACK(5) for congestion control feedback, and NORM_REPORT(6) for experimental use.
NORM defines three NormObject types: NORM_OBJECT_DATA (static memory content), NORM_OBJECT_FILE (file storage), and NORM_OBJECT_STREAM (non-finite, ongoing stream). DATA and FILE are identical in transport; the type distinction is a hint to receivers about storage allocation.
The NORM_INFO message carries application-defined out-of-band context for a NormObject (e.g., MIME type). It is atomic — its size is limited to one NormSegmentSize — allowing rapid repair. NORM_FLAG_INFO in NORM_DATA signals its availability, and NORM_INFO SHALL be transmitted as the first message for any NormObject that has one.
The NORM_OBJECT_STREAM payload uses 'payload_len' (16-bit), 'payload_msg_start' (16-bit), and 'payload_offset' (32-bit) fields to convey stream position and message boundaries. When payload_len=0, payload_msg_start is reinterpreted as a 'stream_control_code'; NORM_STREAM_END=0 signals that the sender will no longer repair content past that stream position.
The NORM Positive Acknowledgment Procedure allows a sender to request explicit acknowledgment of reliable receipt from a specific subset of receivers using NORM_CMD(FLUSH) or NORM_CMD(ACK_REQ). The sender uses an ACK list and timeout/retry mechanism until all listed receivers respond with NORM_ACK or the process times out.
NORM_CMD Message Sub-Types registry defines the 8-bit 'sub-type' field values: FLUSH=1, EOT=2, SQUELCH=3, CC=4, REPAIR_ADV=5, ACK_REQ=6, APPLICATION=7. Values 0 and 8–127 are unassigned; values 128–255 are reserved for private/experimental use. New assignments require IETF Consensus.
NORM Header Extension Types registry: values 0–127 are variable-length extensions (requiring 'hel' field); values 128–255 are fixed-length (one 32-bit word). EXT_FTI is assigned het=64. New assignments in ranges 0–63 and 128–191 require IETF Consensus; ranges 64–127 and 192–255 require Specification Required.
NORM Stream Control Codes registry: used in the 'payload_msg_start' field of NORM_OBJECT_STREAM payloads when 'payload_len'=0. NORM_STREAM_END=0 is the only currently defined code, signaling termination of the stream at the current position. New values require Specification Required.
IPsec requirements for baseline NORM security: when ASM multicast is used, a Group Security Association using a shared key is needed. For SSM or unicast return path configurations, individual ESP Security Associations between each sender-receiver pair may be used instead. ESP with non-NULL encryption is RECOMMENDED to provide confidentiality in addition to integrity.
NORM does not provide built-in message authentication or confidentiality. The baseline security approach relies on IPsec (ESP in tunnel or transport mode) to provide data origin authentication and integrity. Without authentication, NORM is vulnerable to bogus NACK injection, NACK flooding causing DoS via excessive repair transmissions, and injection of false sender commands to disrupt group operation.
The 'sequence' field in receiver feedback messages (NORM_NACK, NORM_ACK) provides replay attack protection when used with authentication. Receivers MUST maintain per-destination sequence number spaces, and receivers SHOULD reject messages with sequence numbers that are not monotonically increasing from a given source.
The receiver NACK procedure uses exponentially distributed random backoff timers scaled by GRTT_sender and the sender's backoff factor K_sender (carried in the 'backoff' field). Upon detecting data loss, a receiver sets a random backoff timer; if a matching repair advertisement or NACK from another receiver is seen before the timer fires, the receiver suppresses its own NACK (probabilistic suppression). If not, it transmits the NACK.
Upon receiving NACKs, the sender enters repair state aggregation: it collects NACKs over a repair window (one GRTT), aggregates the repair needs, then responds with FEC repair transmissions or NORM_CMD(SQUELCH) for out-of-range requests. After transmitting repairs, it may send NORM_CMD(REPAIR_ADV) to suppress further redundant NACKs in asymmetric topologies where receivers cannot observe each other's unicast feedback.
All NORM messages begin with a common 64-bit header containing four fields: a 4-bit 'version' (currently 1), a 4-bit 'type' (message kind), an 8-bit 'hdr_len' (header length in 32-bit words), a 16-bit 'sequence', and a 32-bit 'source_id' (NormNodeId).
NORM header extensions follow the base header and precede the payload. Variable-length extensions (het 0–127) include an 8-bit 'hel' field giving extension length in 32-bit words. Fixed-length extensions (het 128–255) are exactly one 32-bit word with no 'hel' field.
The EXT_FTI header extension (het=64) provides FEC Object Transmission Information in-band. Its general portion contains a 48-bit 'object_size' field, followed by FEC-scheme-specific content; for fec_id=129 (small block systematic codes), this adds 'fec_instance_id' (16-bit), 'segment_size' (16-bit), 'fec_max_block_len' (16-bit), and 'fec_num_parity' (16-bit).
The FEC Payload ID for small block systematic codes (fec_id=129) is 8 bytes: a 32-bit 'source_block_number', a 16-bit 'source_block_len' (number of source symbols in the block), and a 16-bit 'encoding_symbol_id'. Symbols with encoding_symbol_id >= source_block_len are FEC parity; those below are source data.
The NORM_CMD message (type=3) reuses the common header plus 'instance_id', 'grtt', 'backoff', 'gsize', and an 8-bit 'sub-type' field that selects among FLUSH(1), EOT(2), SQUELCH(3), CC(4), REPAIR_ADV(5), ACK_REQ(6), and APPLICATION(7) sub-commands, each with its own payload format.
The NORM_DATA message (type=2) carries application data or FEC symbols. Its header adds 'instance_id' (16-bit), 'grtt' (8-bit quantized RTT), 'backoff' (4-bit), 'gsize' (4-bit), 'flags' (8-bit), 'fec_id' (8-bit), and 'object_transport_id' (16-bit), followed by a variable-size 'fec_payload_id'. Stream objects additionally carry 'payload_len', 'payload_msg_start', and 'payload_offset' fields in the payload.