+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| payload_data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_INFO Message Format
The "version", "type", "hdr_len", "sequence", and "source_id" fields
form the NORM Common Message Header as described in Section 4.1. The
value of "hdr_len" field when no header extensions are present is 4.
The "instance_id", "grtt", "backoff", "gsize", "flags", "fec_id", and
"object_transport_id" fields carry the same information and serve the
same purpose as with NORM_DATA messages. These values allow the
receiver to prepare appropriate buffering, etc, for further
transmissions from the sender when NORM_INFO is the first message
received.
As with NORM_DATA messages, the NORM FTI Header Extension (EXT_FTI)
may be optionally applied to NORM_INFO messages. To conserve
protocol overhead, some NORM implementations may wish to apply the
EXT_FTI when used to NORM_INFO messages only and not to NORM_DATA
messages.
The NORM_INFO "payload_data" field contains sender application-
defined content which can be used by receiver applications for
various purposes as described above.
4.2.3. NORM_CMD Messages
NORM_CMD messages are transmitted by senders to perform a number of
different protocol functions. This includes functions such as
round-trip timing collection, congestion control functions,
synchronization of sender/receiver repair "windows", and notification
of sender status. A core set of NORM_CMD messages is enumerated.
Additionally, a range of command types remain available for potential
application-specific use. Some NORM_CMD types may have dynamic
content attached. Any attached content will be limited to maximum
length of the sender NormSegmentSize to retain the atomic nature of
commands. All NORM_CMD messages begin with a common set of fields,
after the usual NORM message common header. The standard NORM_CMD
fields are:
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=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor | |
+-+-+-+-+-+-+-+-+ NORM_CMD Content +
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD Standard Fields
The "version", "type", "hdr_len", "sequence", and "source_id" fields
form the NORM Common Message Header as described in Section 4.1. The
value of the "hdr_len" field for NORM_CMD messages without header
extensions present depends upon the "flavor" field.
The "instance_id", "grtt", "backoff", and "gsize" fields provide the
same information and serve the same purpose as with NORM_DATA and
NORM_INFO messages. The "flavor" field indicates the type of command
to follow. The remainder of the NORM_CMD message is dependent upon
the command type ("flavor"). NORM command flavors include:
+----------------------+-------------+---------------------------------+
| Command |Flavor Value | Purpose |
+----------------------+-------------+---------------------------------+
|NORM_CMD(FLUSH) | 1 | Used to indicate sender |
| | | temporary end-of-transmission. |
| | | (Assists in robustly initiating |
| | | outstanding repair requests from|
| | | receivers). May also be |
| | | optionally used to collect |
| | | positive acknowledgment of |
| | | reliable reception from subset |
| | | of receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(EOT) | 2 | Used to indicate sender |
| | | permanent end-of-transmission. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(SQUELCH) | 3 | Used to advertise sender’s |
| | | current repair window in |
| | | response to out-of-range NACKs |
| | | from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(CC) | 4 | Used for GRTT measurement and |
| | | collection of congestion control|
| | | feedback. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(REPAIR_ADV) | 5 | Used to advertise sender’s |
| | | aggregated repair/feedback state|
| | | for suppression of unicast |
| | | feedback from receivers. |
+----------------------+-------------+---------------------------------+
|NORM_CMD(ACK_REQ) | 6 | Used to request application- |
| | | defined positive acknowledgment |
| | | from a list of receivers |
| | | (OPTIONAL). |
+----------------------+-------------+---------------------------------+
|NORM_CMD(APPLICATION) | 7 | Used for application-defined |
| | | purposes which may need to |
| | | temporarily preempt data |
| | | transmission (OPTIONAL). |
+----------------------+-------------+---------------------------------+
4.2.3.1. NORM_CMD(FLUSH) Message
The NORM_CMD(FLUSH) command is sent when the sender reaches the end
of all data content and pending repairs it has queued for
transmission. This may indicate a temporary or permanent end of data
transmission, but the sender is still willing to respond to repair
requests. This command is repeated once per 2*GRTT to excite the
receiver set for any outstanding repair requests up to and including
the transmission point indicated within the NORM_CMD(FLUSH) message.
The number of repeats is equal to NORM_ROBUST_FACTOR unless a list of
receivers from which explicit positive acknowledgment is expected
("acking_node_list") is given. In that case, the "acking_node_list"
is updated as acknowledgments are received and the NORM_CMD(FLUSH) is
repeated according to the mechanism described in Section 5.5.3. The
greater the NORM_ROBUST_FACTOR, the greater the probability that all
applicable receivers will be excited for acknowledgment or repair
requests (NACKs) _and_ that the corresponding NACKs are delivered to
the sender. If a NORM_NACK message interrupts the flush process, the
sender will re-initiate the flush process after any resulting repair
transmissions are completed.
Note that receivers also employ a timeout mechanism to self-initiate
NACKing (if there are outstanding repair needs) when no messages of
any type are received from a sender. This inactivity timeout is
related to 2*GRTT*NORM_ROBUST_FACTOR and will be discussed more
later. With a sufficient NORM_ROBUST_FACTOR value, data content is
delivered with a high assurance of reliability. The penalty of a
large NORM_ROBUST_FACTOR value is potentially excess sender
NORM_CMD(FLUSH) transmissions and a longer timeout for receivers to
self-initiate the terminal NACK process.
For finite-size transport objects such as NORM_OBJECT_DATA and
NORM_OBJECT_FILE, the flush process (if there are no further pending
objects) occurs at the end of these objects. Thus, FEC repair
information is always available for repairs in response to repair
requests elicited by the flush command. However, for
NORM_OBJECT_STREAM, the flush may occur at any time, including in the
middle of an FEC coding block if systematic FEC codes are employed.
In this case, the sender will not yet be able to provide FEC parity
content as repair for the concurrent coding block and will be limited
to explicitly repairing stream data content for that block.
Applications that anticipate frequent flushing of stream content
SHOULD be judicious in the selection of the FEC coding block size
(i.e., do not use a very large coding block size if frequent flushing
occurs). For example, a reliable multicast application transmitting
an on-going series of intermittent, relatively small messaging
content will need to trade-off using the NORM_OBJECT_DATA paradigm
versus the NORM_OBJECT_STREAM paradigm with an appropriate FEC coding
block size. This is analogous to application trade-offs for other
transport protocols such as the selection of different TCP modes of
operation such as "no delay", etc.
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=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 1 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| acking_node_list (if applicable) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(FLUSH) Message Format
In addition to the NORM common message header and standard NORM_CMD
fields, the NORM_CMD(FLUSH) message contains fields to identify the
current status and logical transmit position of the sender.
The "fec_id" field indicates the FEC type used for the flushing
"object_transport_id" and implies the size and format of the
"fec_payload_id" field. Note the "hdr_len" value for the
NORM_CMD(FLUSH) message is 4 plus the size of the "fec_payload_id"
field when no header extensions are present.
The "object_transport_id" and "fec_payload_id" fields indicate the
sender’s current logical "transmit position". These fields are
interpreted in the same manner as in the NORM_DATA message type.
Upon receipt of the NORM_CMD(FLUSH), receivers are expected to check
their completion state _through_ (including) this transmission
position. If receivers have outstanding repair needs in this range,
they SHALL initiate the NORM NACK Repair Process as described in
Section 5.3. If receivers have no outstanding repair needs, no
response to the NORM_CMD(FLUSH) is generated.
For NORM_OBJECT_STREAM objects using systematic FEC codes, receivers
MUST request "explicit-only" repair of the identified
"source_block_number" if the given "encoding_symbol_id" is less than
the "source_block_len". This condition indicates the sender has not
yet completed encoding the corresponding FEC block and parity content
is not yet available. An "explicit-only" repair request consists of
NACK content for the applicable "source_block_number" which does not
include any requests for parity-based repair. This allows NORM
sender applications to "flush" an ongoing stream of transmission when
needed, even if in the middle of an FEC block. Once the sender
resumes stream transmission and passes the end of the pending coding
block, subsequent NACKs from receivers SHALL request parity-based
repair as usual. Note that the use of a systematic FEC code is
assumed here. Normal receiver NACK initiation and construction is
discussed in detail in Section 5.3. The OPTIONAL "acking_node_list"
field contains a list of NormNodeIds for receivers from which the
sender is requesting explicit positive acknowledgment of reception up
through the transmission point identified by the
"object_transport_id" and "fec_payload_id" fields. The length of the
list can be inferred from the length of the received NORM_CMD(FLUSH)
message. When the "acking_node_list" is present, the lightweight
positive acknowledgment process described in Section 5.5.3 SHALL be
observed.
4.2.3.2. NORM_CMD(EOT) Message
The NORM_CMD(EOT) command is sent when the sender reaches permanent
end-of-transmission with respect to the NormSession and will not
respond to further repair requests. This allows receivers to
gracefully reach closure of operation with this sender (without
requiring any timeout) and free any resources that are no longer
needed. The NORM_CMD(EOT) command SHOULD be sent with the same
robust mechanism as used for NORM_CMD(FLUSH) commands to provide a
high assurance of reception by the receiver set.
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=3| hdr_len | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 2 | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(EOT) Message Format
The value of the "hdr_len" field for NORM_CMD(EOT) messages without
header extensions present is 4. The "reserved" field is reserved for
future use and MUST be set to an all ZERO value. Receivers MUST
ignore the "reserved" field.
4.2.3.3. NORM_CMD(SQUELCH) Message
The NORM_CMD(SQUELCH) command is transmitted in response to outdated
or invalid NORM_NACK content received by the sender. Invalid
NORM_NACK content consists of repair requests for NormObjects for
which the sender is unable or unwilling to provide repair. This
includes repair requests for outdated objects, aborted objects, or
those objects which the sender previously transmitted marked with the
NORM_FLAG_UNRELIABLE flag. This command indicates to receivers what
content is available for repair, thus serving as a description of the
sender’s current "repair window". Receivers SHALL not generate
repair requests for content identified as invalid by a
NORM_CMD(SQUELCH).
The NORM_CMD(SQUELCH) command is sent once per 2*GRTT at the most.
The NORM_CMD(SQUELCH) advertises the current "repair window" of the
sender by identifying the earliest (lowest) transmission point for
which it will provide repair, along with an encoded list of objects
from that point forward that are no longer valid for repair. This
mechanism allows the sender application to cancel or abort
transmission and/or repair of specific previously enqueued objects.
The list also contains the identifiers for any objects within the
repair window that were sent with the NORM_FLAG_UNRELIABLE flag set.
In normal conditions, it is expected the NORM_CMD(SQUELCH) will be
needed infrequently, and generally only to provide a reference repair
window for receivers who have fallen "out-of-sync" with the sender
due to extremely poor network conditions.
The starting point of the invalid NormObject list begins with the
lowest invalid NormTransportId greater than the current "repair
window" start from the invalid NACK(s) that prompted the generation
of the squelch. The length of the list is limited by the sender’s
NormSegmentSize. This allows the receivers to learn the status of
the sender’s applicable object repair window with minimal
transmission of NORM_CMD(SQUELCH) commands. The format of the
NORM_CMD(SQUELCH) message is:
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 = 3 | sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| source_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| instance_id | grtt |backoff| gsize |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flavor = 3 | fec_id | object_transport_id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fec_payload_id |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| invalid_object_list |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_CMD(SQUELCH) Message Format
In addition to the NORM common message header and standard NORM_CMD
fields, the NORM_CMD(SQUELCH) message contains fields to identify the
earliest logical transmit position of the sender’s current repair
window and an "invalid object list" beginning with the index of the
logically earliest invalid repair request from the offending NACK
message which initiated the squelch transmission.
The "object_transport_id" and "fec_payload_id" fields are
concatenated to indicate the beginning of the sender’s current repair
window (i.e., the logically earliest point in its transmission
history for which the sender can provide repair). The "fec_id" field
implies the size and format of the "fec_payload_id" field. This
serves as an advertisement of a "synchronization point" for receivers
to request repair. Note, that while an "encoding_symbol_id" may be
included in the "fec_payload_id" field, the sender’s repair window
SHOULD be aligned on FEC coding block boundaries and thus the
"encoding_symbol_id" SHOULD be zero.
The "invalid_object_list" is a list of 16-bit NormTransportIds that,
although they are within the range of the sender’s current repair
window, are no longer available for repair from the sender. For
example, a sender application may dequeue an out-of-date object even
though it is still within the repair window. The total size of the
"invalid_object_list" content is can be determined from the packet’s
payload length and is limited to a maximum of the NormSegmentSize of
the sender. Thus, for very large repair windows, it is possible that
a single NORM_CMD(SQUELCH) message may not be capable of listing the
entire set of invalid objects in the repair window. In this case,
the sender SHALL ensure that the list begins with a NormObjectId that
is greater than or equal to the lowest ordinal invalid NormObjectId
from the NACK message(s) that prompted the NORM_CMD(SQUELCH)
generation. The NormObjectIds in the "invalid_object_list" MUST be
greater than the "object_transport_id" marking the beginning of the
sender’s repair window. This insures convergence of the squelch
process, even if multiple invalid NACK/ squelch iterations are
required. This explicit description of invalid content within the
sender’s current window allows the sender application (most notably
for discrete "object" based transport) to arbitrarily invalidate
(i.e., dequeue) portions of enqueued content (e.g., certain objects)
for which it no longer wishes to provide reliable transport.
4.2.3.4. NORM_CMD(CC) Message
The NORM_CMD(CC) messages contains fields to enable sender-to-
receiver group greatest round-trip time (GRTT) measurement and to
excite the group for congestion control feedback. A baseline NORM