3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W
NORM
Click on the red underlined text to get to the source
... Negative-acknowledgment (NACK) Oriented Reliable Multicast (NORM)
protocol is designed to provide reliable transport of data from one
...
... IP multicast
network. The primary design goals of NORM are to provide efficient,
scalable, and robust bulk data (e.g., computer files, transmission of
persistent data) transfer across possibly heterogeneous IP networks ...
... IP networks
and topologies. The NORM protocol design provides support for
distributed multicast session ...
... overhead for control information and timing synchronization among
participants. To accommodate this capability, NORM protocol message
headers ...
... lifetime of a reliable
multicast session. NORM is designed to be self-adapting to a wide
range of dynamic network conditions with little or no pre-
...
... 8], etc.).
The NORM protocol design is principally driven by the assumption of a
single sender ...
... necessary for each sender. However, in future versions of NORM, it
is possible that some aspects of protocol operation (e.g., round-trip
time ...
... senders.
NORM provides for three types of bulk data content objects
(NormObjects) to be reliably transported. These types include:
...
... (NormObjects) to be reliably transported. These types include:
1) static computer memory data content (NORM_OBJECT_DATA type),
...
... STREAM
type).
The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is
simply to provide a "hint ...
...
The distinction between NORM_OBJECT_DATA and NORM_OBJECT_FILE is
simply to provide a "hint" to receivers ...
...
transport object types, too. The use of the NORM_OBJECT_STREAM type
is at the application's discretion and could be used to carry static
...
... STREAM type
is at the application's discretion and could be used to carry static
data or file content also. The NORM reliable stream service opens up
...
... additional possibilities such as serialized reliable messaging or
other unbounded, perhaps dynamically produced content. The
NORM_OBJECT_STREAM provides for reliable transport analogous to that
...
... of the Transmission Control Protocol (TCP), although NORM receivers
will be able to begin receiving stream ...
... The applicability of this feature will depend upon the application.
The NORM protocol also allows for a small amount of "out-of-band"
data (sent as NORM ...
... NORM protocol also allows for a small amount of "out-of-band"
data (sent as NORM_INFO messages) to be attached to the data content
objects transmitted by the sender. This readily-available "out-of-
...
... coordination among senders and receivers. The NORM_INFO content is
designed to be atomic in that its size MUST fit into the payload
...
... designed to be atomic in that its size MUST fit into the payload
portion of a single NORM message.
NORM ...
... NORM message.
NORM does _not_ provide for global or application-level
identification of data content within in its message headers ...
... identification of data content within in its message headers. Note
the NORM_INFO out-of-band data mechanism could be leveraged by the
application for this purpose if desired, or identification could
...
... out-of-band data mechanism could be leveraged by the
application for this purpose if desired, or identification could
alternatively be embedded within the data content. NORM does
identify transmitted content (NormObjects) with transport identifiers ...
... identifiers
(NormTransportIds) are assigned in a monotonically increasing fashion
by each NORM sender during the course of a NormSession. Each sender
maintains its NormTransportId assignments independently so that
...
... are assigned from a large, but fixed, numeric space in increasing
order and may be reassigned during long-lived sessions. The NORM
protocol provides mechanisms so that the sender application may
...
... meet their goals.
To summarize, the NORM protocol provides reliable transport of
different types of data content (including potentially mixed types).
...
... senders enqueue and transmit bulk content in the form of static
data or files and/or non-finite, ongoing stream types. NORM senders
provide for repair transmission of data and/or FEC content in
...
... NORM Scalability ...
... for reliability is required [9]. NORM is a protocol centered around
the use of selective NACKs to request repairs of missing data. NORM ...
... NORM is a protocol centered around
the use of selective NACKs to request repairs of missing data. NORM
provides for the use of packet-level forward error correction (FEC ...
... NACK-oriented protocol. The principal
factor in NORM scalability is the volume of feedback traffic
...
... reliability and
congestion control. NORM uses probabilistic suppression of redundant
feedback based on exponentially distributed random backoff timers.
...
... performance of this type of suppression relative to other
techniques is described in [12]. NORM dynamically measures the
group's roundtrip timing status to set its suppression and other
...
... group's roundtrip timing status to set its suppression and other
protocol timers. This allows NORM to scale well while maintaining
reliable data delivery transport ...
... facilitate feedback suppression. In typical Internet environments,
it is expected that the NORM protocol will readily scale to group
sizes on the order of tens of thousands of receivers ...
... quantity of feedback for this type of protocol is described in [13].
NORM is able to operate with a smaller amount of feedback than a
single TCP connection, even with relatively large numbers of
...
... receivers. Thus, depending upon the network topology, it is possible
that NORM may scale to larger group sizes. With respect to computer
resource usage, the NORM ...
... NORM may scale to larger group sizes. With respect to computer
resource usage, the NORM protocol does _not_ require that state be
kept on all receivers ...
... for receivers providing explicit congestion control feedback. NORM
receivers must maintain state for each active sender ...
... requirements and considerations that apply
to the RMT NORM Building Block [4] and the RMT FEC ...
... NORM protocol.
The NORM protocol SHALL be capable of operating in an end-to-end
fashion with no assistance from intermediate systems beyond basic IP
multicast ...
... routing, and forwarding services. While
the techniques utilized in NORM are principally applicable to "flat"
end-to-end IP multicast ...
... tree-based) multicast distribution
if so desired. NORM can make use of reciprocal (among senders and
receivers ...
... NORM is compatible with IPv4 and IPv6. Additionally, NORM may be
used with networks employing Network Address Translation ...
... senders and/or receivers. NORM senders transmit data content in the
form of NormObjects to the session destination address ...
... form of NormObjects to the session destination address and the NORM
receivers attempt to reliably receive the transmitted content using
negative acknowledgments to request repair. Each NormNode within a
...
... transmitting within the
context of a single NORM session (i.e., many-to-many operation), any
type of interactive coordination among NORM senders ...
... NORM session (i.e., many-to-many operation), any
type of interactive coordination among NORM senders is assumed to be
controlled by the application or higher protocol layer. There are
...
... application layer coordination.
As previously noted, NORM allows for reliable transmission of three
different basic types of data content. The first type is
NORM ...
... NORM allows for reliable transmission of three
different basic types of data content. The first type is
NORM_OBJECT_DATA, which is used for static, persistent blocks of data
content maintained in the sender's application memory storage. The
...
... content maintained in the sender's application memory storage. The
second type is NORM_OBJECT_FILE, which corresponds to data stored in
the sender's non-volatile file system ...
... file system. The NORM_OBJECT_DATA and
NORM_OBJECT_FILE types both represent "NormObjects" of finite but
potentially very large size. The third type of data content is
...
... FILE types both represent "NormObjects" of finite but
potentially very large size. The third type of data content is
NORM_OBJECT_STREAM, which corresponds to an ongoing transmission of
undefined length. This is analogous to the reliable stream ...
... stream
content is application-defined and may be byte or message oriented.
The NORM protocol provides for "flushing" of the stream to expedite
delivery ...
... stream to expedite
delivery or possibly enforce application message boundaries. NORM
protocol implementations may offer either (or both) in-order delivery
...
... stream to the
receiver application. In either case, NORM sender and receiver
implementations provide buffering ...
... FEC codes are used, the payload
of NORM_DATA messages sent for the first portion of a FEC encoding ...
... sender's NormNodeId,
NormInstanceId, and a temporary NormObjectTransportId. Depending
upon the implementation, individual NORM senders may manage their
NormInstanceIds independently, or a common NormInstanceId may be
agreed upon for all participating nodes ...
... session if needed as
a session identifier. NORM NormObjectTransportId data content
identifiers are sender ...
... identifiers may be re-used. Note that globally
unique identification of transported data content is not provided by
NORM and, if required, must be managed by the NORM application. The
individual segments ...
... unique identification of transported data content is not provided by
NORM and, if required, must be managed by the NORM application. The
individual segments or symbols of the NormObject are further
...
...
A NORM sender primarily generates messages of type NORM_DATA. These
messages carry original data segments ...
...
A NORM sender primarily generates messages of type NORM_DATA. These
messages carry original data segments or FEC ...
... FEC
encoding. However, the NORM implementation MAY be optionally
configured to proactively transmit some amount of redundant FEC
...
...
A sender message of type NORM_INFO is also defined and is used to
carry OPTIONAL "out-of-band" context ...
... 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
...
... 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 ...
... 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
...
... process than NORM's general FEC-encoded data content. NORM_INFO may
serve special purposes for some bulk transfer, reliable multicast
...
... 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 ...
... 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 ...
... 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 ...
... round trip time estimation, receiver
synchronization, and optional positive acknowledgment requests or
application defined commands. The transmission of NORM_CMD messages
from the sender ...
... 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 ...
... NORM receivers generate messages of type NORM_NACK or NORM_ACK in
response to transmissions of data and commands from a sender ...
... 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 ...
... data packets and end-of-transmission
commands from the sender. NORM_ACK messages are generated in
response to certain commands transmitted by the sender ...
... 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 ...
... sender. The
feedback volume of these congestion control NORM_ACK messages is
controlled using the same timer ...
... 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 ...
... application requirements for positive
acknowledgment from receivers, other NORM_ACK messages are defined
and available for use. All sender and receiver ...
... quantity of multicast data transmitted by the group. When NORM's
congestion control algorithm is enabled the rate for senders ...
...
The operation of the NORM protocol is based primarily upon the
concepts presented in the Nack-Oriented Reliable Multicast (NORM ...
... 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 ...
... 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 ...
... encoding techniques for repair messaging and optional transmission
robustness as described in [10]. NORM uses the FEC Payload ID as
...
... congestion control, this document includes a baseline congestion
control mechanism (NORM-CC) based on the TCP-Friendly Multicast
Congestion Control (TFMCC ...
...
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 ...
... congestion
control, and transport across low capacity connections. NORM
contains various parameters to accommodate many of these differing
requirements ...
... 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 ...
... 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 ...
... bandwidth product
of the network topology. NORM performs best when allowed more
buffering resources than typical point-to-point ...
... point-to-point transport protocols.
This is because NORM feedback suppression is based upon randomly-
delayed transmissions from the receiver set, rather than immediately
...
... performance.
Large buffer sizes allow the NORM protocol to perform most
efficiently in large delay-bandwidth topologies ...
... 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 ...
... 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 |
...
... application data |
| | transmission. Implementations must support |
| | at least one of the NORM_OBJECT_DATA, |
| | NORM_OBJECT_FILE, or NORM ...
... Object Transmission Information header |
| | extension is OPTIONAL with NORM_DATA |
| | messages. |
+--------------------+-----------------------------------------------+
...
... | | messages. |
+--------------------+-----------------------------------------------+
|NORM_CMD(FLUSH) | Sender command to excite receivers ...
... Sender command to excite receivers for repair |
| | requests in lieu of ongoing NORM_DATA |
| | transmissions. Note the use of the |
| | NORM ...
... NORM_DATA |
| | transmissions. Note the use of the |
| | NORM_CMD(FLUSH) for positive acknowledgment |
| | of data receipt is OPTIONAL. |
...
... | | of data receipt is OPTIONAL. |
+--------------------+-----------------------------------------------+
|NORM_CMD(SQUELCH) | Sender command to advertise its current valid ...
... | | for repair. |
+--------------------+-----------------------------------------------+
|NORM_CMD(REPAIR_ADV)| Sender command to advertise current repair |
...
... topologies. |
+--------------------+-----------------------------------------------+
|NORM_CMD(CC) | Sender ...
... round trip timing collection is used). |
+--------------------+-----------------------------------------------+
|NORM_NACK | Receiver message used to request repair of |
...
...
+--------------------+-----------------------------------------------+
|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 ...
... Sender message for providing ancillary |
| | context information associated with NORM |
| | transport objects. The use of the NORM ...
... Object Transmission Information header |
| | extension is OPTIONAL with NORM_INFO |
| | messages. |
+----------------------+----------------------------------------------+
...
... | | messages. |
+----------------------+----------------------------------------------+
|NORM_CMD(EOT) | Sender command to indicate it has reached |
...
... | | respond to repair requests. |
+----------------------+----------------------------------------------+
|NORM_CMD(ACK_REQ) | Sender ...
... | | sent outside of the context of the bulk data |
| | content being transmitted. The NORM Positive|
| | Acknowledgment Procedure associated with this|
| | message type ...
... message type is OPTIONAL. |
+----------------------+----------------------------------------------+
|NORM_CMD(APPLICATION) | Sender command containing application-defined|
...
... | | bulk data content being transmitted. |
+----------------------+----------------------------------------------+
|NORM_REPORT | Optional message type reserved for |
| | experimental ...
... message type reserved for |
| | experimental implementations of the NORM |
| | protocol. |
+----------------------+----------------------------------------------+
...
...
As mentioned in Section 2.1, there are two primary classes of NORM
messages: sender messages and receiver ...
... DATA message types are generated by senders of
data content, and NORM_NACK and NORM_ACK messages ...
... message type of
NORM_REPORT is also provided for experimental purposes. This section
describes the message formats ...
... 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 ...
... 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 ...
... 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
...
... leverages the transport features of UDP. The NORM messages are
independent of network addresses ...
... 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
...
... 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 ...
... expand the functionality of the NORM protocol without revision to
this document. All NORM protocol messages begin with a common header
...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Common Message Header Format
...
... 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
...
... 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:
...
... 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 ...
... 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 ...
... 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 ...
... 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 ...
... 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 ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Variable Length Header Extension Format
...
... Header Extension Content |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM Fixed Length (32-bit) Header Extension Format
...
... header extension
format is defined for each header extension type defined for NORM
messages. Some header extensions are defined within this document
...
... messages. Some header extensions are defined within this document
for NORM baseline FEC and congestion control operations.
...
... NORM_INFO messages contain
application data content while NORM_CMD messages are used for various
protocol control functions.
...
... NORM_DATA Message ...
... 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 ...
... NORM senders. These messages are used to encapsulate
segmented data content for objects of type NORM_OBJECT_DATA,
NORM_OBJECT_FILE, and NORM ...
... segmented data content for objects of type NORM_OBJECT_DATA,
NORM_OBJECT_FILE, and NORM_OBJECT_STREAM. NORM ...
... application data content.
The format of NORM_DATA messages is comprised of three logical
portions: 1) a fixed-format NORM ...
... NORM_DATA messages is comprised of three logical
portions: 1) a fixed-format NORM_DATA header portion, 2) a FEC
...
... application data content. Note for objects of type
NORM_OBJECT_STREAM, the payload portion contains additional fields
...
... payload portion contains additional fields
used to appropriately recover stream content. NORM implementations
MAY also extend the NORM_DATA header ...
... stream content. NORM implementations
MAY also extend the NORM_DATA header to include a FEC Object
Transmission Information ...
... 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 ...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NORM_DATA Message Format
...
... payload_len" and "payload_offset"
fields are present only for objects of type NORM_OBJECT_STREAM. The
"payload ...
... payload_offset" fields allow senders to
arbitrarily vary the size of NORM_DATA payload segments for streams.
...
... meet unique streaming requirements. For objects of types
NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary
since the receiver ...
... requirements. For objects of types
NORM_OBJECT_FILE and NORM_OBJECT_DATA, these fields are unnecessary
since the receiver can calculate the payload length ...
... in Section 5.1.1. The "payload_reserved" field is kept for
anticipated future NORM stream control functions. When systematic
FEC ...
... encapsulated application data segment for those NORM_DATA
messages containing source data symbols. In NORM_DATA messages ...
... segment for those NORM_DATA
messages containing source data symbols. In NORM_DATA messages that
contain parity information, these fields are not actual length or
...
... 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 NORM ...
... NORM Common Message Header as described in Section 4.1. The
value of the NORM_DATA "type" field is 2. The NORM_DATA _base_
"hdr_len" value is 4 (32-bit ...
... Message Header as described in Section 4.1. The
value of the NORM_DATA "type" field is 2. The NORM_DATA _base_
"hdr_len" value is 4 (32-bit words) plus the size of the
...
... payload_id" is two 32-bit words.
In this case the NORM_DATA base "hdr_len" value is 6. The cumulative
size of any header extensions ...
... sender
(identified by its "source_id") is detected to have a new
"instance_id", the NORM receivers SHOULD drop their previous state on
the sender ...
... maximum backoff timer value used in the timer-based NORM NACK
feedback suppression. This 4-bit ...
... sender's backoff factor parameter "Ksender". Recommended values and
their use are described in the NORM receiver NACK procedure
description in Section 5.3. The "gsize" field contains a
...
... of "0x8" represents 5.0e+01 (50), a value of "0x1" represents 1.0e+02
(100), and a value of "0xf" represents 5.0e+08. For NORM feedback
suppression purposes, the group size does not need to be represented
...
... 10,000 ("gsize" = 0x4) is recommended for general purpose reliable
multicast applications using the NORM protocol.
The "flags" field contains a number of different binary flags
...
... | Flag | Value | Purpose |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_REPAIR | 0x01 | Indicates message is a repair |
| | | transmission |
+--------------------+-------+-----------------------------------------+
...
... | | | transmission |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_EXPLICIT | 0x02 | Indicates a repair segment intended to |
| | | meet a specific receiver ...
... | | | filling. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO for |
| | | object. |
...
... +--------------------+-------+-----------------------------------------+
|NORM_FLAG_INFO | 0x04 | Indicates availability of NORM_INFO for |
| | | object. |
+--------------------+-------+-----------------------------------------+
...
... | | | object. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_UNRELIABLE| 0x08 | Indicates that repair transmissions for |
| | | the specified object will be unavailable|
...
... | | | (One-shot, best effort transmission). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_FILE | 0x10 | Indicates object is "file-based" data |
| | | (hint to use disk storage for |
...
... | | | reception). |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_STREAM | 0x20 | Indicates object is of type |
| | | NORM ...
... NORM_FLAG_STREAM | 0x20 | Indicates object is of type |
| | | NORM_OBJECT_STREAM. |
+--------------------+-------+-----------------------------------------+
...
... STREAM. |
+--------------------+-------+-----------------------------------------+
|NORM_FLAG_MSG_START | 0x40 | Marks the first segment of application |
...
... segment of application |
| | | messages embedded in |
| | | NORM_OBJECT_STREAMs. |
+--------------------+-------+-----------------------------------------+
...
... +--------------------+-------+-----------------------------------------+
NORM_FLAG_REPAIR is set when the associated message is a repair
transmission. This information can be used by receivers to help
...
... NACK process upon receipt
of new (non-repair) data content. NORM_FLAG_EXPLICIT is used to mark
repair messages sent when the data sender has exhausted its ability
...
... multicast topology with disparate
repair needs. NORM_FLAG_INFO is set only when optional NORM_INFO
content is actually available for the associated object. Thus,
...
... topology with disparate
repair needs. NORM_FLAG_INFO is set only when optional NORM_INFO
content is actually available for the associated object. Thus,
receivers ...
... receivers will NACK for retransmission of NORM_INFO only when it is
available for a given object. NORM_FLAG_UNRELIABLE is set when the
...
... retransmission of NORM_INFO only when it is
available for a given object. NORM_FLAG_UNRELIABLE is set when the
sender wishes to transmit an object with only "best effort" delivery ...
... sender wishes to transmit an object with only "best effort" delivery
and will not supply repair transmissions for the object. NORM
receivers SHOULD NOT execute repair requests for objects marked with
the NORM_FLAG_UNRELIABLE flag. Note that receivers ...
... and will not supply repair transmissions for the object. NORM
receivers SHOULD NOT execute repair requests for objects marked with
the NORM_FLAG_UNRELIABLE flag. Note that receivers may inadvertently
request repair of such objects when all segments ...
... transport_id" sequence is noted). In this case, the sender
should invoke the NORM_CMD(SQUELCH) process as described in Section
4.2.3. NORM ...
... NORM_CMD(SQUELCH) process as described in Section
4.2.3. NORM_FLAG_FILE can be set as a "hint" from the sender that
...
... the associated object should be stored in non-volatile storage.
NORM_FLAG_STREAM is set when the identified object is of type
NORM ...
... NORM_FLAG_STREAM is set when the identified object is of type
NORM_OBJECT_STREAM. When NORM_FLAG_STREAM ...
... NORM_FLAG_STREAM is set, the
NORM_FLAG_MSG_START can be optionally used to mark the first data
segments ...
... segments of application-layer messages transported within the NORM
stream. This allows NORM receiver ...
... NORM
stream. This allows NORM receiver applications to "synchronize" with
NORM senders and to be able to properly interpret application layer ...
... stream. This allows NORM receiver applications to "synchronize" with
NORM senders and to be able to properly interpret application layer
data when joining a NORM ...
... NORM senders and to be able to properly interpret application layer
data when joining a NORM session already in progress. In practice,
the NORM ...
... NORM session already in progress. In practice,
the NORM implementation MAY set this flag for the segment transmitted
following an explicit "flush" of the stream ...
... FEC
encoded content. Small block, systematic codes ("fec_id" = 129) are
expected to be used for most NORM purposes and the NORM_OBJECT_STREAM
...
... encoded content. Small block, systematic codes ("fec_id" = 129) are
expected to be used for most NORM purposes and the NORM_OBJECT_STREAM
requires systematic FEC ...
... current state kept for a given source). During the
course of its transmission within a NORM session, an object is
uniquely identified by the concatenation ...
... sender "source_id"
and the given "object_transport_id". Note that NORM_INFO messages
associated with the identified object carry the same
"object_transport ...
...
The "fec_payload_id" identifies the attached NORM_DATA "payload"
content. The size and format of the "fec_payload ...
... 5]. The "source_block_number" identifies the coding block's
relative position with a NormObject. Note that, for NormObjects of
type NORM_OBJECT_STREAM, the "source_block_number" may wrap for very
long lived sessions ...
... identifier for the attached segment with
respect to the NORM sender's instance within a session.
...
... FEC Building Block document [5]) is required to properly receive and
decode NORM transport objects. This information MAY be provided as
out-of-band</