4.2.2.  NORM_INFO Message

   The NORM_INFO message is used to convey OPTIONAL, application-
   defined, "out-of-band" context information for transmitted
   NormObjects.  An example NORM_INFO use for bulk file transfer is to
   place MIME type information for the associated file, data, or stream
   object into the NORM_INFO payload.  Receivers may use the NORM_INFO
   content to make a decision as whether to participate in reliable
   reception of the associated object.  Each NormObject can have an
   independent unit of NORM_INFO associated with it.  NORM_DATA messages
   contain a flag to indicate the availability of NORM_INFO for a given
   NormObject.  NORM receivers may NACK for retransmission of NORM_INFO
   when they have not received it for a given NormObject.  The size of
   the NORM_INFO content is limited to that of a single NormSegmentSize

   for the given sender.  This atomic nature allows the NORM_INFO to be
   rapidly and efficiently repaired within the NORM reliable
   transmission process.

   When NORM_INFO content is available for a NormObject, the
   NORM_FLAG_INFO flag SHALL be set in NORM_DATA messages for the
   corresponding "object_transport_id" and the NORM_INFO message shall
   be transmitted as the first message for the NormObject.

      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=1|    hdr_len    |          sequence             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           source_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          instance_id          |     grtt      |backoff| gsize |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     flags     |     fec_id    |     object_transport_id       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                header_extensions (if applicable)              |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         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
   congestion control scheme (NORM-CC), based on the TCP-Friendly
   Multicast Congestion Control (TFMCC) scheme of [19] is described in
   Section 5.5.2 of this document.  The NORM_CMD(CC) message is usually
   transmitted as part of NORM-CC congestion control operation.  A NORM
   header extension is defined below to be used with the NORM_CMD(CC)
   message to support NORM-CC operation.  Different header extensions
   may be defined for the NORM_CMD(CC) (and/or other NORM messages as
   needed) to support alternative congestion control schemes in the
   future.  If NORM is operated in a private network with congestion
   control operation disabled, the NORM_CMD(CC) message is then used for
   GRTT measurement only and may optionally be sent less frequently than
   with congestion control operation.

      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 = 4  |    reserved   |          cc_sequence          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         send_time_sec                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        send_time_usec                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               header extensions (if applicable)               |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  cc_node_list (if applicable)                 |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      NORM_CMD(CC) Message Format

   The NORM common message header and standard NORM_CMD fields serve
   their usual purposes.

   The "reserved" field is for potential future use and should be set to
   ZERO in this version of the NORM protocol.

   The "cc_sequence" field is a sequence number applied by the sender.
   For NORM-CC operation, it is used to provide functionality equivalent
   to the "feedback round number" (fb_nr)described in [19].  The most
   recently received "cc_sequence" value is recorded by receivers and
   can be fed back to the sender in congestion control feedback
   generated by the receivers for that sender.  The "cc_sequence" number
   can also be used in NORM implementations to assess how recently a
   receiver has received NORM_CMD(CC) probes from the sender.  This can
   be useful instrumentation for complex or experimental multicast
   routing environments.

   The "send_time" field is a timestamp indicating the time that the
   NORM_CMD(CC) message was transmitted.  This consists of a 64-bit
   field containing 32-bits with the time in seconds ("send_time_sec")
   and 32-bits with the time in microseconds ("send_time_usec") since
   some reference time the source maintains (usually 00:00:00, 1 January
   1970).  The byte ordering of the fields is "Big Endian" network
   order.  Receivers use this timestamp adjusted by the amount of delay

   from the time they received the NORM_CMD(CC) message to the time of
   their response as the "grtt_response" portion of NORM_ACK and
   NORM_NACK messages generated.  This allows the sender to evaluate
   round-trip times to different receivers for congestion control and
   other (e.g., GRTT determination) purposes.

   To facilitate the baseline NORM-CC scheme described in Section 5.5.2,
   a NORM-CC Rate header extension (EXT_RATE) is defined to inform the
   group of the sender's current transmission rate.  This is used along
   with the loss detection "sequence" field of all NORM sender messages
   and the NORM_CMD(CC) GRTT collection process to support NORM-CC
   congestion control operation.  The format of this header extension is
   as follows:

      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    het = 128  |    reserved   |           send_rate           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            NORM-CC Rate Header Extension Format (EXT_RATE)

   The "send_rate" field indicates the sender's current transmission
   rate in bytes per second.  The 16-bit "send_rate" field consists of
   12 bits of mantissa in the most significant portion and 4 bits of
   base 10 exponent (order of magnitude) information in the least
   significant portion.  The 12-bit mantissa portion of the field is
   scaled such that a floating point value of 0.0 corresponds to 0 and a
   floating point value of 10.0 corresponds to 4096.  Thus:

   send_rate = (((int)(Value_mantissa * 4096.0 / 10.0 + 0.5)) << 4) |
   Value_exponent;

   For example, to represent a transmission rate of 256kbps (3.2e+04
   bytes per second), the lower 4 bits of the 16-bit field contain a
   value of 0x04 to represent the exponent while the upper 12 bits
   contain a value of 0x51f as determined from the equation given above:

send_rate = (((int)((3.2 * 4096.0 / 10.0) + 0.5)) << 4) | 4;

          = (0x51f << 4) | 0x4

          = 0x51f4

To decode the "send_rate" field, the following equation can be used:

value = (send_rate >> 4) * 10.0 / 4096.0 *
        power(10.0, (send_rate & x000f))

   Note the maximum transmission rate that can be represented by this
   scheme is approximately 9.99e+15 bytes per second.

   When this extension is present, a "cc_node_list" may be attached as
   the payload of the NORM_CMD(CC) message.  The presence of this header
   extension also implies that NORM receivers should respond according
   to the procedures described in Section 5.5.2.  The "cc_node_list"
   consists of a list of NormNodeIds and their associated congestion
   control status.  This includes the current limiting receiver (CLR)
   node, any potential limiting receiver (PLR) nodes that have been
   identified, and some number of receivers for which congestion control
   status is being provided, most notably including the receivers'
   current RTT measurement.  The maximum length of the "cc_node_list"
   provides for at least the CLR and one other receiver, but may be
   configurable for more timely feedback to the group.  The list length
   can be inferred from the length of the NORM_CMD(CC) message.

   Each item in the "cc_node_list" is in the following format:

      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          cc_node_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    cc_flags   |     cc_rtt    |            cc_rate            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Congestion Control Node List Item Format

   The "cc_node_id" is the NormNodeId of the receiver which the item
   represents.

   The "cc_flags" field contains flags indicating the congestion control
   status of the indicated receiver.  The following flags are defined:

+------------------+-------+------------------------------------------+
|      Flag        | Value |                 Purpose                  |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_CLR  | 0x01  | Receiver is the current limiting         |
|                  |       | receiver (CLR).                          |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_PLR  | 0x02  | Receiver is a potential limiting         |
|                  |       | receiver (PLR).                          |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_RTT  | 0x04  | Receiver has measured RTT with respect   |
|                  |       | to sender.                               |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_START| 0x08  | Sender/receiver is in "slow start" phase |
|                  |       | of congestion control operation (i.e.,   |
|                  |       | The receiver has not yet detected any    |
|                  |       | packet loss and the "cc_rate" field is   |
|                  |       | the receiver's actual measured receive   |
|                  |       | rate).                                   |
+------------------+-------+------------------------------------------+
|NORM_FLAG_CC_LEAVE| 0x10  | Receiver is imminently leaving the       |
|                  |       | session and its feedback should not be   |
|                  |       | considered in congestion control         |
|                  |       | operation.                               |
+------------------+-------+------------------------------------------+

   The "cc_rtt" contains a quantized representation of the RTT as
   measured by the sender with respect to the indicated receiver.  This
   field is valid only if the NORM_FLAG_CC_RTT flag is set in the
   "cc_flags" field.  This one byte field is a quantized representation
   of the RTT using the algorithm described in the NORM Building Block
   document [4].  The "cc_rate" field contains a representation of the
   receiver's current calculated (during steady-state congestion control
   operation) or twice its measured (during the "slow start" phase)
   congestion control rate.  This field is encoded and decoded using the
   same technique as described for the NORM_CMD(CC) "send_rate" field.

4.2.3.5.  NORM_CMD(REPAIR_ADV) Message

   The NORM_CMD(REPAIR_ADV) message is used by the sender to "advertise"
   its aggregated repair state from NORM_NACK messages accumulated
   during a repair cycle and/or congestion control feedback received.
   This message is sent only when the sender has received NORM_NACK
   and/or NORM_ACK(CC) (when congestion control is enabled) messages via
   unicast transmission instead of multicast.  By "echoing" this
   information to the receiver set, suppression of feedback can be
   achieved even when receivers are unicasting that feedback instead of
   multicasting it among the group [13].

      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 = 5   |     flags     |            reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               header extensions (if applicable)               |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       repair_adv_payload                      |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  NORM_CMD(REPAIR_ADV) Message Format

   The "instance_id", "grtt", "backoff", "gsize", and "flavor" fields
   serve the same purpose as in other NORM_CMD messages.  The value of
   the "hdr_len" field when no extensions are present is 4.

   The "flags" field provide information on the NORM_CMD(REPAIR_ADV)
   content.  There is currently one NORM_CMD(REPAIR_ADV) flag defined:

                     NORM_REPAIR_ADV_FLAG_LIMIT = 0x01

   This flag is set by the sender when it is unable to fit its full
   current repair state into a single NormSegmentSize.  If this flag is
   set, receivers should limit their NACK response to generating NACK
   content only up through the maximum ordinal transmission position
   (objectId::fecPayloadId) included in the "repair_adv_content".

   When congestion control operation is enabled, a header extension may
   be applied to the NORM_CMD(REPAIR_ADV) representing the most limiting
   (in terms of congestion control feedback suppression) congestion
   control response.  This allows the NORM_CMD(REPAIR_ADV) message to
   suppress receiver congestion control responses as well as NACK
   feedback messages.  The field is defined as a header extension so
   that alternative congestion control schemes may be used with NORM
   without revision to this document.  A NORM-CC Feedback Header
   Extension (EXT_CC) is defined to encapsulate congestion control
   feedback within NORM_NACK, NORM_ACK, and NORM_CMD(REPAIR_ADV)
   messages.  If another congestion control technique (e.g., Pragmatic
   General Multicast Congestion Control (PGMCC) [20]) is used within a

   NORM implementation, an additional header extension MAY need to be
   defined to encapsulate any required feedback content.  The NORM-CC
   Feedback Header Extension format is:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     het = 3   |    hel = 3    |          cc_sequence          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    cc_flags   |     cc_rtt    |            cc_loss            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            cc_rate            |          cc_reserved          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           NORM-CC Feedback Header Extension (EXT_CC) Format

   The "cc_sequence" field contains the current greatest "cc_sequence"
   value receivers have  received in NORM_CMD(CC) messages from the
   sender.  This information assists the sender in congestion control
   operation by providing an indicator of how current ("fresh") the
   receiver's round-trip measurement reference time is and whether the
   receiver has been successfully receiving recent congestion control
   probes.  For example, if it is apparent the receiver has not been
   receiving recent congestion control probes (and thus possibly other
   messages from the sender), the sender may choose to take congestion
   avoidance measures.  For NORM_CMD(REPAIR_ADV) messages, the sender
   SHALL set the "cc_sequence" field value to the value set in the last
   NORM_CMD(CC) message sent.

   The "cc_flags" field contains bits representing the receiver's state
   with respect to congestion control operation.  The possible values
   for the "cc_flags" field are those specified for the NORM_CMD(CC)
   message node list item flags.  These fields are used by receivers in
   controlling (suppressing as necessary) their congestion control
   feedback.  For NORM_CMD(REPAIR_ADV) messages, the NORM_FLAG_CC_RTT
   should be set only when all feedback messages received by the sender
   have the flag set.  Similarly, the NORM_FLAG_CC_CLR or
   NORM_FLAG_CC_PLR should be set only when no feedback has been
   received from non-CLR or non-PLR receivers.  And the
   NORM_FLAG_CC_LEAVE should be set only when all feedback messages the
   sender has received have this flag set.  These heuristics for setting
   the flags in NORM_CMD(REPAIR_ADV) ensure the most effective
   suppression of receivers providing unicast feedback messages.

   The "cc_rtt" field SHALL be set to a default maximum value and the
   NORM_FLAG_CC_RTT flag SHALL be cleared when no receiver has yet
   received RTT measurement information.  When a receiver has received
   RTT measurement information, it shall set the "cc_rtt" value
   accordingly and set the NORM_FLAG_CC_RTT flag in the "cc_flags"
   field.

   For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_rtt"
   field value to the largest non-CLR/non-PLR RTT it has measured from
   receivers for the current feedback round.

   The "cc_loss" field represents the receiver's current packet loss
   fraction estimate for the indicated source.  The loss fraction is a
   value from 0.0 to 1.0 corresponding to a range of zero to 100 percent
   packet loss.  The 16-bit "cc_loss" value is calculated by the
   following formula:

                "cc_loss" = decimal_loss_fraction * 65535.0

   For NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
   field value to the largest non-CLR/non-PLR loss estimate it has
   received from receivers for the current feedback round.

   The "cc_rate" field represents the receivers current local congestion
   control rate.  During "slow start", when the receiver has detected no
   loss, this value is set to twice the actual rate it has measured from
   the corresponding sender and the NORM_FLAG_CC_START is set in the
   "cc_flags' field.  Otherwise, the receiver calculates a congestion
   control rate based on its loss measurement and RTT measurement
   information (even if default) for the "cc_rate" field.  For
   NORM_CMD(REPAIR_ADV) messages, the sender SHALL set the "cc_loss"
   field value to the lowest non-CLR/non-PLR "cc_rate" report it has
   received from receivers for the current feedback round.

   The "cc_reserved" field is reserved for future NORM protocol use.
   Currently, senders SHALL set this field to ZERO, and receivers SHALL
   ignore the content of this field.

   The "repair_adv_payload" is in exactly the same form as the
   "nack_content" of NORM_NACK messages and can be processed by
   receivers for suppression purposes in the same manner, with the
   exception of the condition when the NORM_REPAIR_ADV_FLAG_LIMIT is
   set.

4.2.3.6.  NORM_CMD(ACK_REQ) Message

   The NORM_CMD(ACK_REQ) message is used by the sender to request
   acknowledgment from a specified list of receivers.  This message is
   used in providing a lightweight positive acknowledgment mechanism
   that is OPTIONAL for use by the reliable multicast application.  A
   range of acknowledgment request types is provided for use at the
   application's discretion.  Provision for application-defined,
   positively-acknowledged commands allows the application to
   automatically take advantage of transmission and round-trip timing
   information available to the NORM protocol.  The details of the NORM

   positive acknowledgment process including transmission of the
   NORM_CMD(ACK_REQ) messages and the receiver response (NORM_ACK) are
   described in Section 5.5.3.  The format of the NORM_CMD(ACK_REQ)
   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|    hdr_len    |          sequence             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           source_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          instance_id          |     grtt      |backoff| gsize |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  flavor = 6   |    reserved   |    ack_type   |    ack_id     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       acking_node_list                        |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    NORM_CMD(ACK_REQ) Message Format

   The NORM common message header and standard NORM_CMD fields serve
   their usual purposes.  The value of the "hdr_len" field for
   NORM_CMD(ACK_REQ) messages with no header extension present is 4.

   The "ack_type" field indicates the type of acknowledgment being
   requested and thus implies rules for how the receiver will treat this
   request.  The following "ack_type" values are defined and are also
   used in NORM_ACK messages described later:

+---------------------+--------+---------------------------------+
|      ACK Type       | Value  |            Purpose              |
+---------------------+--------+---------------------------------+
|NORM_ACK_CC          |      1 | Used to identify NORM_ACK       |
|                     |        | messages sent in response to    |
|                     |        | NORM_CMD(CC) messages.          |
+---------------------+--------+---------------------------------+
|NORM_ACK_FLUSH       |      2 | Used to identify NORM_ACK       |
|                     |        | messages sent in response to    |
|                     |        | NORM_CMD(FLUSH) messages.       |
+---------------------+--------+---------------------------------+
|NORM_ACK_RESERVED    |   3-15 | Reserved for possible future    |
|                     |        | NORM protocol use.              |
+---------------------+--------+---------------------------------+
|NORM_ACK_APPLICATION | 16-255 | Used at application's           |
|                     |        | discretion.                     |
+---------------------+--------+---------------------------------+

   The NORM_ACK_CC value is provided for use only in NORM_ACKs generated
   in response to the NORM_CMD(CC) messages used in congestion control
   operation.  Similarly, the NORM_ACK_FLUSH is provided for use only in
   NORM_ACKs generated in response to applicable NORM_CMD(FLUSH)
   messages.  NORM_CMD(ACK_REQ) messages with "ack_type" of NORM_ACK_CC
   or NORM_ACK_FLUSH SHALL NOT be generated by the sender.

   The NORM_ACK_RESERVED range of "ack_type" values is provided for
   possible future NORM protocol use.

   The NORM_ACK_APPLICATION range of "ack_type" values is provided so
   that NORM applications may implement application-defined,
   positively-acknowledged commands that are able to leverage internal
   transmission and round-trip timing information available to the NORM
   protocol implementation.

   The "ack_id" provides a sequenced identifier for the given
   NORM_CMD(ACK_REQ) message.  This "ack_id" is returned in NORM_ACK
   messages generated by the receivers so that the sender may associate
   the response with its corresponding request.

   The "reserved" field is reserved for possible future protocol use and
   SHALL be set to ZERO by senders and ignored by receivers.

   The "acking_node_list" field contains the NormNodeIds of the current
   NORM receivers that are desired to provide positive acknowledge
   (NORM_ACK) to this request.  The packet payload length implies the
   length of the "acking_node_list" and its length is limited to the
   sender NormSegmentSize.  The individual NormNodeId items are listed
   in network (Big Endian) byte order.  If a receiver's NormNodeId is
   included in the "acking_node_list", it SHALL schedule transmission of
   a NORM_ACK message as described in Section 5.5.3.

4.2.3.7.  NORM_CMD(APPLICATION) Message

   This command allows the NORM application to robustly transmit
   application-defined commands.  The command message preempts any
   ongoing data transmission and is repeated up to NORM_ROBUST_FACTOR
   times at a rate of once per 2*GRTT.  This rate of repetition allows
   the application to observe any response (if that is the application's
   purpose for the command) before it is repeated.  Possible responses
   may include initiation of data transmission, other
   NORM_CMD(APPLICATION) messages, or even application-defined,
   positively-acknowledge commands from other NormSession participants.
   The transmission of these commands will preempt data transmission
   when they are scheduled and may be multiplexed with ongoing data
   transmission.  This type of robustly transmitted command allows NORM
   applications to define a complete set of session control mechanisms

   with less state than the transfer of FEC encoded reliable content
   requires while taking advantage of NORM transmission and round-trip
   timing information.

      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 = 7   |                    reserved                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Application-Defined Content                 |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  NORM_CMD(APPLICATION) Message Format

   The NORM common message header and NORM_CMD fields are interpreted as
   previously described.  The value of the NORM_CMD(APPLICATION)
   "hdr_len" field when no header extensions are present is 4.

   The "Application-Defined Content" area contains information in a
   format at the discretion of the application.  The size of this
   payload SHALL be limited to a maximum of the sender's NormSegmentSize
   setting.

4.3.  Receiver Messages

   The NORM message types generated by participating receivers consist
   of NORM_NACK and NORM_ACK message types.  NORM_NACK messages are sent
   to request repair of missing data content from sender transmission
   and NORM_ACK messages are generated in response to certain sender
   commands including NORM_CMD(CC) and NORM_CMD(ACK_REQ).

4.3.1.  NORM_NACK Message

   The principal purpose of NORM_NACK messages is for receivers to
   request repair of sender content via selective, negative
   acknowledgment upon detection of incomplete data.  NORM_NACK messages
   will be transmitted according to the rules of NORM_NACK generation
   and suppression described in Section 5.3.  NORM_NACK messages also
   contain additional fields to provide feedback to the sender(s) for
   purposes of round-trip timing collection and congestion control.

   The payload of NORM_NACK messages contains one or more repair
   requests for different objects or portions of those objects.  The
   NORM_NACK message format is as follows:

      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=4|    hdr_len    |            sequence           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           source_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           server_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           instance_id         |            reserved           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       grtt_response_sec                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       grtt_response_usec                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               header extensions (if applicable)               |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          nack_payload                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        NORM_NACK Message Format

   The NORM common message header fields serve their usual purposes.
   The value of the "hdr_len" field for NORM_NACK messages without
   header extensions present is 6.

   The "server_id" field identifies the NORM sender to which the
   NORM_NACK message is destined.

   The "instance_id" field contains the current session identifier given
   by the sender identified by the "server_id" field in its sender
   messages.  The sender SHOULD ignore feedback messages which contain
   an invalid "instance_id" value.

   The "grtt_response" fields contain an adjusted version of the
   timestamp from the most recently received NORM_CMD(CC) message for
   the indicated NORM sender.  The format of the "grtt_response" is the
   same as the "send_time" field of the NORM_CMD(CC).  The
   "grtt_response" value is _relative_ to the "send_time" the source
   provided with a corresponding NORM_CMD(CC) command.  The receiver
   adjusts the source's NORM_CMD(CC) "send_time" timestamp by adding the
   time differential from  when the receiver received the NORM_CMD(CC)

   to when the NORM_NACK is transmitted to calculate the value in the
   "grtt_response" field.  This is the
   "receive_to_response_differential" value used in the following
   formula:

   "grtt_response" = NORM_CMD(CC) "send_time" +
   receive_to_response_differential

   The receiver SHALL set the "grtt_response" to a ZERO value, to
   indicate that it has not yet received a NORM_CMD(CC) message from the
   indicated sender and that the sender should ignore the
   "grtt_response" in this message.

   For NORM-CC operation, the NORM-CC Feedback Header Extension, as
   described in the NORM_CMD(REPAIR_ADV} message description, is added
   to NORM_NACK messages to provide feedback on the receivers current
   state with respect to congestion control operation.  Note that
   alternative header extensions for congestion control feedback may be
   defined for alternative congestion control schemes for NORM use in
   the future.

   The "reserved" field is for potential future NORM use and SHALL be
   set to ZERO for this version of the protocol.

   The "nack_content" of the NORM_NACK message specifies the repair
   needs of the receiver with respect to the NORM sender indicated by
   the "server_id" field.  The receiver constructs repair requests based
   on the NORM_DATA and/or NORM_INFO segments it requires from the
   sender in order to complete reliable reception up to the sender's
   transmission position at the moment the receiver initiates the NACK
   Procedure as described in Section 5.3.  A single NORM Repair Request
   consists of a list of items, ranges, and/or FEC coding block erasure
   counts for needed NORM_DATA and/or NORM_INFO content.  Multiple
   repair requests may be concatenated within the "nack_payload" field
   of a NORM_NACK message.  Note that a single NORM Repair Request can
   possibly include multiple "items", "ranges", or "erasure_counts".  In
   turn, the "nack_payload" field may contain multiple repair requests.
   A single NORM Repair Request has the following format:

      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      form     |     flags     |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      repair_request_items                     |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       NORM Repair Request Format

   The "form" field indicates the type of repair request items given in
   the "repair_request_items" list.  Possible values for the "form"
   field include:

                Form          Value
         NORM_NACK_ITEMS        1
         NORM_NACK_RANGES       2
         NORM_NACK_ERASURES     3

   A "form" value of NORM_NACK_ITEMS indicates each repair request item
   in the "repair_request_items" list is to be treated as an individual
   request.  A value of NORM_NACK_RANGES indicates that the
   "repair_request_items" list consists of pairs of repair request items
   that correspond to inclusive ranges of repair needs.  And the
   NORM_NACK_ERASURES "form" indicates that the repair request items are
   to be treated individually and that the "encoding_symbol_id" portion
   of the "fec_payload_id" field of the repair request item (see below)
   is to be interpreted as an "erasure count" for the FEC coding block
   identified by the repair request item's "source_block_number".

   The "flags" field is currently used to indicate the level of data
   content for which the repair request items apply (i.e., an individual
   segment, entire FEC coding block, or entire transport object).
   Possible flag values include:

+------------------+-------+-----------------------------------------+
|      Flag        | Value |                 Purpose                 |
+------------------+-------+-----------------------------------------+
|NORM_NACK_SEGMENT | 0x01  | Indicates the listed segment(s) or range|
|                  |       | of segments are required as repair.     |
+------------------+-------+-----------------------------------------+
|NORM_NACK_BLOCK   | 0x02  | Indicates the listed block(s) or range  |
|                  |       | of blocks in entirety are required as   |
|                  |       | repair.                                 |
+------------------+-------+-----------------------------------------+
|NORM_NACK_INFO    | 0x04  | Indicates that NORM_INFO is required as |
|                  |       | repair for the listed object(s).        |
+------------------+-------+-----------------------------------------+
|NORM_NACK_OBJECT  | 0x08  | Indicates the listed object(s) or range |
|                  |       | of objects in entirety are required as  |
|                  |       | repair.                                 |
+------------------+-------+-----------------------------------------+

   When the NORM_NACK_SEGMENT flag is set, the "object_transport_id" and
   "fec_payload_id" fields are used to determine which sets or ranges of
   individual NORM_DATA segments are needed to repair content at the

   receiver.  When the NORM_NACK_BLOCK flag is set, this indicates the
   receiver is completely missing the indicated coding block(s) and
   requires transmissions sufficient to repair the indicated block(s) in
   their entirety.  When the NORM_NACK_INFO flag is set, this indicates
   the receiver is missing the NORM_INFO segment for the indicated
   "object_transport_id".  Note the NORM_NACK_INFO may be set in
   combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags, or
   may be set alone.  When the NORM_NACK_OBJECT flag is set, this
   indicates the receiver is missing the entire NormTransportObject
   referenced by the "object_transport_id".  This also implicitly
   requests any available NORM_INFO for the NormObject, if applicable.
   The "fec_payload_id" field is ignored when the flag NORM_NACK_OBJECT
   is set.

   The "length" field value is the length in bytes of the
   "repair_request_items" field.

   The "repair_request_items" field consists of a list of individual or
   range pairs of transport data unit identifiers in the following
   format.

      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     fec_id    |   reserved    |      object_transport_id      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        fec_payload_id                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    NORM Repair Request Item Format

   The "fec_id" indicates the FEC type and can be used to determine the
   format of the "fec_payload_id" field.  The "reserved" field is kept
   for possible future use and SHALL be set to a ZERO value and ignored
   by NORM nodes processing NACK content.

   The "object_transport_id" corresponds to the NormObject for which
   repair is being requested and the "fec_payload_id" identifies the
   specific FEC coding block and/or segment being requested.  When the
   NORM_NACK_OBJECT flag is set, the value of the "fec_payload_id" field
   is ignored.  When the NORM_NACK_BLOCK flag is set, only the FEC code
   block identifier portion of the "fec_payload_id" is to be
   interpreted.

   The format of the "fec_payload_id" field depends upon the "fec_id"
   field value.

   When the receiver's repair needs dictate that different forms (mixed
   ranges and/or individual items) or types (mixed specific segments
   and/or blocks or objects in entirety) are required to complete
   reliable transmission, multiple NORM Repair Requests with different
   "form" and or "flags" values can be concatenated within a single
   NORM_NACK message.  Additionally, NORM receivers SHALL construct
   NORM_NACK messages with their repair requests in ordinal order with
   respect to "object_transport_id" and "fec_payload_id" values.  The
   "nack_payload" size SHALL NOT exceed the NormSegmentSize for the
   sender to which the NORM_NACK is destined.

   NORM_NACK Content Examples:

   In these examples, a small block, systematic FEC code ("fec_id" =
   129) is assumed with a user data block length of 32 segments.  In
   Example 1, a list of individual NORM_NACK_ITEMS repair requests is
   given.  In Example 2, a list of NORM_NACK_RANGES requests _and_ a
   single NORM_NACK_ITEMS request are concatenated to illustrate the
   possible content of a NORM_NACK message.  Note that FEC coding block
   erasure counts could also be provided in each case.  However, the
   erasure counts are not really necessary since the sender can easily
   determine the erasure count while processing the NACK content.
   However, the erasure count option may be useful for operation with
   other FEC codes or for intermediate system purposes.

   Example 1:  NORM_NACK "nack_payload" for: Object 12, Coding Block 3,
   Segments 2,5,8

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   form = 1    | flags = 0x01  |       length  = 36            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 3                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 2     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 3                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 12   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 3                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 8     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Example 2:  NORM_NACK "nack_payload" for: Object 18 Coding Block 6,
   Segments 5, 6, 7, 8, 9, 10; and Object 19 NORM_INFO and Coding Block
   1, segment 3

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   form = 2    | flags = 0x01  |       length  = 24            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 18   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 6                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 5     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 18   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 6                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 10    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   form = 1    | flags = 0x05  |       length  = 12            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  fec_id = 129 |   reserved    |    object_transport_id = 19   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    source_block_number = 1                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    source_block_length = 32   |    encoding_symbol_id = 3     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.3.2.  NORM_ACK Message

   The NORM_ACK message is intended to be used primarily as part of NORM
   congestion control operation and round-trip timing measurement.  As
   mentioned in the NORM_CMD(ACK_REQ) message description, the
   acknowledgment type NORM_ACK_CC is provided for this purpose.  The
   generation of NORM_ACK(CC) messages for round-trip timing estimation
   and congestion-control operation is described in Sections 5.5.1 and
   5.5.2, respectively.  However, some multicast applications may
   benefit from some limited form of positive acknowledgment for certain
   functions.  A simple, scalable positive acknowledgment scheme is
   defined in Section 5.5.3 that can be leveraged by protocol
   implementations when appropriate.  The NORM_CMD(FLUSH) may be used
   for OPTIONAL collection of positive acknowledgment of reliable
   reception to a certain "watermark" transmission point from specific
   receivers using this mechanism.  The NORM_ACK type NORM_ACK_FLUSH is
   provided for this purpose and the format of the "nack_payload" for
   this acknowledgment type is given below.  Beyond that, a range of

   application-defined "ack_type" values is provided for use at the NORM
   application's discretion.  Implementations making use of
   application-defined positive acknowledgments may also make use the
   "nack_payload" as needed, observing the constraint that the
   "nack_payload" field size be limited to a maximum of the
   NormSegmentSize for the sender to which the NORM_ACK is destined.

      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=5|    hdr_len    |          sequence             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           source_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           server_id                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           instance_id         |    ack_type  |     ack_id     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       grtt_response_sec                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       grtt_response_usec                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               header extensions (if applicable)               |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   ack_payload (if applicable)                 |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        NORM_ACK Message Format

   The NORM common message header fields serve their usual purposes.

   The "server_id", "instance_id",  and "grtt_response" fields serve the
   same purpose as the corresponding fields in NORM_NACK messages.  And
   header extensions may be applied to support congestion control
   feedback or other functions in the same manner.

   The "ack_type" field indicates the nature of the NORM_ACK message.
   This directly corresponds to the "ack_type" field of the
   NORM_CMD(ACK_REQ) message to which this acknowledgment applies.

   The "ack_id" field serves as a sequence number so that the sender can
   verify that a NORM_ACK message received actually applies to a current
   acknowledgment request.  The "ack_id" field is not used in the case
   of the NORM_ACK_CC and NORM_ACK_FLUSH acknowledgment types.

   The "ack_payload" format is a function of the "ack_type".  The
   NORM_ACK_CC message has no attached content.  Only the NORM_ACK
   header applies.  In the case of NORM_ACK_FLUSH, a specific
   "ack_payload" format is defined:

      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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     fec_id    |   reserved    |      object_transport_id      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        fec_payload_id                         |
   |                              ...                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  NORM_ACK_FLUSH "ack_payload" Format

   The "object_transport_id" and "fec_payload_id" are used by the
   receiver to acknowledge applicable NORM_CMD(FLUSH) messages
   transmitted by the sender identified by the "server_id" field.

   The "ack_payload" of NORM_ACK messages for application-defined
   "ack_type" values is specific to the application but is limited in
   size to a maximum the NormSegmentSize of the sender referenced by the
   "server_id".

4.4.  General Purpose Messages

   Some additional message formats are defined for general purpose in
   NORM multicast sessions whether the participant is acting as a sender
   and/or receiver within the group.

4.4.1.  NORM_REPORT Message

   This is an optional message generated by NORM participants.  This
   message could be used for periodic performance reports from receivers
   in experimental NORM implementations.  The format of this message is
   currently undefined.  Experimental NORM implementations may define
   NORM_REPORT formats as needed for test purposes.  These report
   messages SHOULD be disabled for interoperability testing between
   different NORM implementations.