tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5740

 
 
 

NACK-Oriented Reliable Multicast (NORM) Transport Protocol

Part 3 of 4, p. 47 to 65
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 47 
4.3.  Receiver Messages

   The NORM message types generated by participating receivers consist
   of the 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

Top      Up      ToC       Page 48 
   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                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 17: 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 containing 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 delta from when the receiver received the NORM_CMD(CC) to when
   the NORM_NACK is transmitted in response to calculate the value in
   the "grtt_response" field.  This is the "receive_to_response_delta"

Top      Up      ToC       Page 49 
   value used in the following formula:
     grtt_response = NORM_CMD(CC) send_time + receive_to_response_delta

   The receiver SHALL set the "grtt_response" to a ZERO value, to
   indicate it has not yet received a NORM_CMD(CC) message from the
   indicated sender, and the sender MUST 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 receiver's current
   state with respect to congestion control operation.  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_payload" 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 needs from the sender
   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
   can be concatenated within the "nack_payload" field of a NORM_NACK
   message.  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                     |
     |                             ...                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 18: 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:

Top      Up      ToC       Page 50 
                      +--------------------+-------+
                      | 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 the
   "repair_request_items" list consists of pairs of repair request items
   corresponding to the inclusive ranges of repair needs.  The
   NORM_NACK_ERASURES "form" indicates the repair request items are to
   be treated individually and 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 needed as repair.  |
   | NORM_NACK_BLOCK   |  0x02  | Indicates the listed block(s) or     |
   |                   |        | range of blocks in entirety that are |
   |                   |        | needed as repair.                    |
   | NORM_NACK_INFO    |  0x04  | Indicates NORM_INFO is needed as     |
   |                   |        | repair for the listed object(s).     |
   | NORM_NACK_OBJECT  |  0x08  | Indicates the listed object(s) or    |
   |                   |        | range of objects in entirety are     |
   |                   |        | needed 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
   that transmissions sufficient to repair the indicated block(s) in
   their entirety are needed.  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 can be set

Top      Up      ToC       Page 51 
   in combination with the NORM_NACK_BLOCK or NORM_NACK_SEGMENT flags,
   or can 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                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 19: 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 needed 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

Top      Up      ToC       Page 52 
   "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 can 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, and 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     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 53 
    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.  The
   acknowledgment type NORM_ACK(CC) is provided for this purpose as
   described in the NORM_CMD(ACK_REQ) message description.  The
   generation of NORM_ACK(CC) messages for round-trip timing estimation
   and congestion control operation is described in Section 5.5.1 and
   Section 5.5.2, respectively.  However, some multicast applications
   can benefit from some limited form of positive acknowledgment for
   certain functions.  A simple, scalable positive acknowledgment scheme
   is defined in Section 5.5.3, which can be leveraged by protocol
   implementations when appropriate.  The NORM_CMD(FLUSH) can also 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

Top      Up      ToC       Page 54 
   application's discretion.  Implementations making use of application-
   defined positive acknowledgments MAY also make use of 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)                 |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 20: NORM_ACK Message Format

   The NORM common message header fields serve their usual purposes.
   The value of the "hdr_len" field when no header extensions are
   present is 6.

   The "server_id", "instance_id", and "grtt_response" fields serve the
   same purpose as the corresponding fields in NORM_NACK messages.
   Header extensions can 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 the sender can
   verify a received NORM_ACK message 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

Top      Up      ToC       Page 55 
   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                         |
     |                              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 of 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 can 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 compliant NORM implementations.

5.  Detailed Protocol Operation

   This section describes the detailed interactions of senders and
   receivers participating in a NORM session.  A simple synopsis of the
   protocol operation is given here:

   1.  The sender periodically transmits NORM_CMD(CC) messages as needed
       to initialize and collect round-trip timing and congestion
       control feedback from the receiver set.

Top      Up      ToC       Page 56 
   2.  The sender transmits an ordinal set of NormObjects segmented in
       the form of NORM_DATA messages labeled with NormTransportIds and
       logically identified with FEC encoding block numbers and symbol
       identifiers.  When applicable, NORM_INFO messages MAY optionally
       precede the transmission of data content for NORM transport
       objects.

   3.  As receivers detect missing content from the sender, they
       initiate repair requests with NORM_NACK messages.  The receivers
       track the sender's most recent objectTransportId::fecPayloadId
       transmit position and NACK only for content that is ordinally
       prior to that current transmit position.  The receivers schedule
       random backoff timeouts before generating NORM_NACK messages and
       wait an appropriate amount of time before repeating the NORM_NACK
       if their repair request is not satisfied.

   4.  The sender aggregates repair requests from the receivers and
       logically "rewinds" its transmit position to send appropriate
       repair messages.  The sender sends repairs for the earliest
       ordinal transmit position first and maintains this ordinal repair
       transmission sequence.  FEC parity content not previously
       transmitted for the applicable FEC coding block is used for
       repair transmissions to the greatest extent possible.  If the
       sender exhausts its available FEC parity content on multiple
       repair cycles for the same coding block, it resorts to an
       explicit repair strategy (possibly using parity content) to
       complete repairs.  (The use of explicit repair is an exception in
       general protocol operation, but the possibility does exist for
       extreme conditions).  The sender immediately assumes transmission
       of new content once it has sent pending repairs.

   5.  The sender transmits NORM_CMD(FLUSH) messages when it reaches the
       end of enqueued transmit content and pending repairs.  Receivers
       respond to the NORM_CMD(FLUSH) messages with NORM_NACK
       transmissions (following the same suppression backoff timeout
       strategy as for data) if they need further repair.

   6.  The sender transmissions are subject to rate control limits
       determined by congestion control mechanisms.  In the baseline
       NORM-CC operation, each sender in a NormSession maintains its own
       independent congestion control state.  Receivers provide
       congestion control feedback in NORM_NACK and NORM_ACK messages.
       NORM_ACK feedback for congestion control purposes is governed
       using a suppression mechanism similar to that for NORM_NACK
       messages.

   While this overall concept is relatively simple, there are details to
   each of these aspects that need to be addressed for successful,

Top      Up      ToC       Page 57 
   efficient, robust, and scalable NORM protocol operation.

5.1.  Sender Initialization and Transmission

   Upon startup, the NORM sender immediately begins sending NORM_CMD(CC)
   messages to collect round-trip timing and other information from the
   potential group.  If NORM-CC congestion control operation is enabled,
   the NORM-CC Rate header extension MUST be included in these messages.
   Congestion control operation SHALL be observed at all times when not
   operating using dedicated resources, like in the general Internet.
   Even if congestion control operation is disabled at the sender, it
   can be desirable to use the NORM_CMD(CC) messaging to collect
   feedback from the group using the baseline NORM-CC feedback
   mechanisms.  This proactive feedback collection can be used to
   establish a GRTT estimate prior to data transmission and potential
   NACK operation.

   In some cases, applications might need the sender to also proceed
   with data transmission immediately.  In other cases, the sender might
   wish to defer data transmission until it has received some feedback
   or request from the receiver set indicating receivers are indeed
   present.  Note, in some applications (e.g., web push), this
   indication MAY come out-of-band with respect to the multicast session
   via other means.  As noted, the periodic transmission of NORM_CMD(CC)
   messages MAY precede actual data transmission in order to have an
   initial GRTT estimate.

   With inclusion of the OPTIONAL NORM FEC Object Transmission
   Information Header Extension (EXT_FTI), the NORM protocol sender
   message headers can contain all information necessary to prepare
   receivers for subsequent reliable reception.  This includes FEC
   coding parameters, the sender NormSegmentSize, and other information.
   If this header extension is not used, it is presumed receivers have
   received the FEC Object Transmission Information via other means.
   Additionally, applications MAY leverage the use of NORM_INFO messages
   associated with the session data objects in the session to provide
   application-specific context information for the session and data
   being transmitted.  These mechanisms allow for operation with minimal
   pre-coordination among the senders and receivers.

   The NORM sender begins segmenting application-enqueued data into
   NORM_DATA segments and transmitting it to the group.  For objects of
   type NORM_OBJECT_DATA and NORM_OBJECT_FILE, the segmentation
   algorithm described in FEC Building Block [RFC5052] is RECOMMENDED.
   For objects of type NORM_OBJECT_STREAM, segmentation will typically
   be into uniform FEC coding block sizes, with individual segment sizes
   controlled by the application.  In most cases, the application and
   NORM implementation SHOULD strive to produce full-sized

Top      Up      ToC       Page 58 
   (NormSegmentSize) segments when possible.  The rate of transmission
   is controlled via congestion control mechanisms or is a fixed rate if
   desired for closed network operations.  The receivers participating
   in the multicast group provide feedback to the sender as needed.
   When the sender reaches the end of data it has enqueued for
   transmission or any pending repairs, it transmits a series of
   NORM_CMD(FLUSH) messages at a rate of one per 2*GRTT_sender.  Similar
   to the end of each transmitted FEC coding block during transmission,
   receivers SHALL respond to these NORM_CMD(FLUSH) messages with
   additional repair requests as needed.  A protocol parameter
   NORM_ROBUST_FACTOR determines the number of flush messages sent.  If
   receivers request repair, the repair is provided, and flushing occurs
   again at the end of repair transmission.  The sender MAY attach an
   OPTIONAL "acking_node_list" to NORM_CMD(FLUSH) containing the
   NormNodeIds for receivers from which it expects explicit positive
   acknowledgment of reception.  The NORM_CMD(FLUSH) message MAY be also
   used for this OPTIONAL purpose any time prior to the end of data
   enqueued for transmission with the NORM_CMD(FLUSH) messages
   multiplexed with ongoing data transmissions.  The OPTIONAL NORM
   positive acknowledgment procedure is described in Section 5.5.3.

5.1.1.  Object Segmentation Algorithm

   NORM senders and receivers MUST use a common algorithm for logically
   segmenting transport data into FEC encoding blocks and symbols so
   appropriate NACKs can be constructed to request repair of missing
   data.  NORM FEC coding blocks are comprised of multi-byte symbols
   (segments) transmitted in the payload of NORM_DATA messages.  Each
   NORM_DATA message will contain one or more source or encoding symbols
   identified by the "fec_payload_id" field, and the NormSegmentSize
   sender parameter defines the maximum size (in bytes) of the
   "payload_data" field containing the content (a "segment").  The FEC
   encoding type and associated parameters govern the source block size
   (number of source symbols per coding block, etc.).  NORM senders and
   receivers use these FEC parameters, along with the NormSegmentSize
   and transport object size to compute the source block structure for
   transport objects.  These parameters are provided in the FEC Object
   Transmission Information for each object.  The block partitioning
   algorithm described in the FEC Building Block [RFC5052] document is
   RECOMMENDED for use in computing a source block structure such that
   all source blocks are as close to being equal length as possible.
   This helps avoid the performance disadvantages of "short" FEC blocks.
   Note that this algorithm applies only to the statically sized
   NORM_OBJECT_DATA and NORM_OBJECT_FILE transport object types where
   the object size is fixed and predetermined.  For NORM_OBJECT_STREAM
   objects, the object is segmented according to the maximum source
   block length given in the FEC Transmission Information, unless the
   FEC Payload ID indicates an alternative size for a given block.

Top      Up      ToC       Page 59 
5.2.  Receiver Initialization and Reception

   For typical operation, NORM receivers will join a specified multicast
   group and listen on a specific port number for sender transmissions.
   As the NORM receiver receives NORM_DATA messages, it will establish
   buffering state and provide content to its application as appropriate
   for the given data type.  The NORM protocol allows receivers to join
   and leave the group at will, although some applications might need
   receivers to be members of the group prior to start of data
   transmission.  Thus, different NORM applications MAY use different
   policies to constrain the impact of new receivers joining the group
   in the middle of a session.  For example, a useful implementation
   policy is for new receivers joining the group to limit or avoid
   repair requests for transport objects already in progress.  The NORM
   sender implementation MAY impose additional constraints to limit the
   ability of receivers to disrupt reliable multicast performance by
   joining, leaving, and rejoining the group often.  Different receiver
   "join policies" might be appropriate for different applications
   and/or scenarios.  For general purpose operation, a default policy
   where receivers are allowed to request repair only for coding blocks
   with a NormTransportId and FEC coding block number greater than or
   equal to the first non-repair NORM_DATA or NORM_INFO message received
   upon joining the group is RECOMMENDED.  For objects of type
   NORM_OBJECT_STREAM, it is RECOMMENDED the join policy constrain
   receivers to begin reliable reception at the current FEC coding block
   for which non-repair content is received.

   In some deployments, different multicast receivers might have
   differing quality of network connectivity.  Some receivers may suffer
   significantly poorer performance with very limited goodput due to low
   connection rate or substantial packet loss.  Similar to the "join
   policies" described above, a NORM sender implementation MAY choose to
   enforce different "service policies" to perhaps exclude exceptionally
   poorly performing (or otherwise badly behaving) receivers from the
   group.  The sender implementation could choose to ignore NACKs from
   such receivers and/or force advancement of its logical "repair
   window" (i.e., enforcing a minimal level of service) and use the
   NORM_CMD(SQUELCH) message to advise those poor performers of its
   advance.  Note in some cases, the application may need to support the
   "weakest member" regardless of the time needed to achieve reliable
   delivery.  When implemented, the protocol instantiation SHOULD expose
   controls to the set of "join" and/or "service" policies available to
   support the needs of different applications.

5.3.  Receiver NACK Procedure

   When the receiver detects it is missing data from a sender's NORM
   transmissions, it initiates its NACKing procedure.  The NACKing

Top      Up      ToC       Page 60 
   procedure SHALL be initiated only at FEC coding block boundaries,
   NormObject boundaries, upon receipt of a NORM_CMD(FLUSH) message, or
   upon an "inactivity" timeout when NORM_DATA or NORM_INFO
   transmissions are no longer received from a previously active sender.
   The RECOMMENDED value of such an inactivity timeout is:

            T_inactivity = NORM_ROBUST_FACTOR * 2 * GRTT_sender

   where the GRTT_sender value corresponds to the GRTT estimate
   advertised in the "grtt" field of NORM sender messages.  A minimum
   T_inactivity value of 1 second is RECOMMENDED.  The NORM receiver
   SHOULD reset this inactivity timer and repeat NACK initiation upon
   timeout for up to NORM_ROBUST_FACTOR times or more depending upon the
   application's need for persistence by its receivers.  It is also
   important receivers rescale the T_inactivity timeout as the sender's
   advertised GRTT changes.

   The NACKing procedure begins with a random backoff timeout.  The
   duration of the backoff timeout is chosen using the "RandomBackoff"
   algorithm described in the Multicast NACK Building Block [RFC5401]
   document using (K_sender*GRTT_sender) for the maxTime parameter and
   the sender advertised group size (GSIZE_sender) as the groupSize
   parameter.  NORM senders provide values for GRTT_sender, K_sender and
   GSIZE_sender via the "grtt", "backoff", and "gsize" fields of
   transmitted messages.  The GRTT_sender value is determined by the
   sender based on feedback it has received from the group while the
   K_sender and GSIZE_sender values can be determined by application
   requirements and expectations or ancillary information.  The backoff
   factor K_sender MUST be greater than one to provide for effective
   feedback suppression.  A value of K_sender = 4 is RECOMMENDED for the
   Any Source Multicast (ASM) model, while a value of K_sender = 6 is
   RECOMMENDED for Single Source Multicast (SSM) operation.

   Thus:
       T_backoff = RandomBackoff(K_sender*GRTT_sender, GSIZE_sender)

   To avoid the possibility of NACK implosion in the case of sender or
   network failure during SSM operation, the receiver SHALL
   automatically suppress its NACK and immediately enter the "holdoff"
   period described below when T_backoff is greater than (K_sender-
   1)*GRTT_sender.  Otherwise, the backoff period is entered and the
   receiver MUST accumulate external pending repair state from NORM_NACK
   messages and NORM_CMD(REPAIR_ADV) messages received.  At the end of
   the backoff time, the receiver SHALL generate a NORM_NACK message
   only if the following conditions are met:

Top      Up      ToC       Page 61 
   1.  The sender's current transmit position (in terms of
       objectTransportId::fecPayloadId) exceeds the earliest repair
       position of the receiver.

   2.  The repair state accumulated from NORM_NACK and
       NORM_CMD(REPAIR_ADV) messages does not equal or supersede the
       receiver's repair needs up to the sender transmission position at
       the time the NACK procedure (backoff timeout) was initiated.

   If these conditions are met, the receiver immediately generates a
   NORM_NACK message when the backoff timeout expires.  Otherwise, the
   receiver's NACK is considered to be "suppressed" and the message is
   not sent.  At this time, the receiver begins a "holdoff" period
   during which it constrains itself to not re-initiate the NACKing
   process.  The purpose of this timeout is to allow the sender worst-
   case time to respond to the repair needs before the receiver requests
   repair again.  The value of this "holdoff" timeout (T_rcvrHoldoff) as
   described in [RFC5401] is:
                  T_rcvrHoldoff =(K_sender+2)*GRTT_sender

   The NORM_NACK message contains repair request content beginning with
   the lowest ordinal repair position of the receiver up through the
   coding block prior to the most recently heard ordinal transmission
   position for the sender.  If the size of the NORM_NACK content
   exceeds the sender's NormSegmentSize, the NACK content is truncated
   so the receiver only generates a single NORM_NACK message per NACK
   cycle for a given sender.  In summary, a single NACK message is
   generated containing the receiver's lowest ordinal repair needs.

   For each partially received FEC coding block requiring repair, the
   receiver SHALL, on its FIRST repair attempt for the block, request
   the parity portion of the FEC coding block beginning with the lowest
   ordinal parity "encoding_symbol_id" (i.e., "encoding_symbol_id" =
   "source_block_len") and request the number of FEC symbols
   corresponding to its data segment erasure count for the block.  On
   subsequent repair cycles for the same coding block, the receiver
   SHALL request only those repair symbols from the first set it has not
   yet received up to the remaining erasure count for that applicable
   coding block.  Note the sender might have transmitted other
   different, additional parity segments for other receivers that could
   also be used to satisfy the local receiver's erasure-filling needs.
   In the case where the erasure count for a partially received FEC
   coding block exceeds the maximum number of parity symbols available
   from the sender for the block (as indicated by the NORM_DATA
   "fec_num_parity" field), the receiver SHALL request all available
   parity segments plus the ordinally highest missing data segments
   needed to satisfy its total erasure needs for the block.  The goal of
   this strategy is for the overall receiver set to request a lowest

Top      Up      ToC       Page 62 
   common denominator set of repair symbols for a given FEC coding
   block.  This allows the sender to construct the most efficient repair
   transmission segment set and enables effective NACK suppression among
   the receivers even with uncorrelated packet loss.  This approach also
   does not demand synchronization among the receiver set in their
   repair requests for the sender.

   For FEC coding blocks or NormObjects missed in their entirety, the
   NORM receiver constructs repair requests with NORM_NACK_BLOCK or
   NORM_NACK_OBJECT flags set as appropriate.  The request for
   retransmission of NORM_INFO is accomplished by setting the
   NORM_NACK_INFO flag in a corresponding repair request.

5.4.  Sender NACK Processing and Response

   The principal goal of the sender is to make forward progress in the
   transmission of data its application has enqueued.  However, the
   sender will need to occasionally "rewind" its logical transmission
   point to satisfy the repair needs of receivers who have NACKed.
   Aggregation of multiple NACKs is used to determine an optimal repair
   strategy when a NACK event occurs.  Since receivers initiate the NACK
   process on coding block or object boundaries, there is some loose
   degree of synchronization of the repair process even when receivers
   experience uncorrelated data loss.

5.4.1.  Sender Repair State Aggregation

   When a sender is in its normal state of transmitting new data and
   receives a NACK, it begins a procedure to accumulate NACK repair
   state from NORM_NACK messages before beginning repair transmissions.
   Note that this period of aggregating repair state does NOT interfere
   with its ongoing transmission of new data.

   As described in [RFC5401], the period of time during which the sender
   aggregates NORM_NACK messages is equal to:

               T_sndrAggregate = (K_sender + 1) * GRTT_sender

   where K_sender is the backoff scaling value advertised to the
   receivers, and GRTT_sender is the sender's current estimate of the
   group's greatest round-trip time.  Note, for NORM unicast sessions,
   the T_sndrAggregate time can be set to ZERO since there is only one
   receiver.  Similarly, the K_sender value SHOULD be set to ZERO for
   NORM unicast sessions to minimize repair latency.

   When this period ends, the sender "rewinds" by incorporating the
   accumulated repair state into its pending transmission state and
   begins transmitting repair messages.  After pending repair

Top      Up      ToC       Page 63 
   transmissions are completed, the sender continues with new
   transmissions of any enqueued data.  Also, at this point in time, the
   sender begins a "holdoff" timeout during which time the sender
   constrains itself from initiating a new repair aggregation cycle,
   even if NORM_NACK messages arrive.  As described in [RFC5401], the
   value of this sender "holdoff" period is:

                     T_sndrHoldoff = (1 * GRTT_sender)

   If additional NORM_NACK messages are received during this sender
   "holdoff" period, the sender will immediately incorporate these late-
   arriving messages into its pending transmission state if, and only
   if, the NACK content is ordinally greater than the sender's current
   transmission position.  This "holdoff" time allows worst-case time
   for the sender to propagate its current transmission sequence
   position to the group, thus avoiding redundant repair transmissions.
   After the holdoff timeout expires, a new NACK accumulation period can
   be started (upon arrival of a NACK) in concert with the pending
   repair and new data transmission.  Recall receivers are not to
   initiate the NACK repair process until the sender's logical
   transmission position exceeds the lowest ordinal position of their
   repair needs.  With the new NACK aggregation period, the sender
   repeats the same process of incorporating accumulated repair state
   into its transmission plan and subsequently "rewinding" to transmit
   the lowest ordinal repair data when the aggregation period expires.
   Again, this is conducted in concert with ongoing new data and/or
   pending repair transmissions.

5.4.2.  Sender FEC Repair Transmission Strategy

   The NORM sender SHOULD leverage transmission of FEC parity content
   for repair to the greatest extent possible.  Recall that receivers
   use a strategy to request a lowest common denominator of explicit
   repair (including parity content) in the formation of their NORM_NACK
   messages.  Before falling back to explicitly satisfying different
   receivers' repair needs, the sender can make use of the general
   erasure-filling capability of FEC-generated parity segments.  The
   sender can determine the maximum erasure-filling needs for individual
   FEC coding blocks from the NORM_NACK messages received during the
   repair aggregation period.  Then, if the sender has a sufficient
   number (less than or equal to the maximum erasure count) of
   previously unsent parity segments available for the applicable coding
   blocks, the sender can transmit these in lieu of the specific packets
   the receiver set has requested.  The sender SHOULD NOT resort to
   explicit transmission of the receiver set's repair needs until after
   exhausting its supply of "fresh" (unsent) parity segments for a given
   coding block.  In general, if a sufficiently powerful FEC code is
   used, the need for explicit repair will be an exception, and the

Top      Up      ToC       Page 64 
   fulfillment of reliable multicast can be accomplished quite
   efficiently.  However, the ability to resort to explicit repair
   allows the protocol to be continue to operate under even very extreme
   circumstances.

   NORM_DATA messages sent as repair transmissions SHALL be flagged with
   the NORM_FLAG_REPAIR flag.  This allows receivers to obey any
   policies limiting new receivers from joining the reliable
   transmission when only repair transmissions have been received.
   Additionally, the sender SHOULD flag NORM_DATA transmissions sent as
   explicit repair with the NORM_FLAG_EXPLICIT flag.

   Although NORM end system receivers do not make use of the
   NORM_FLAG_EXPLICIT flag, this message transmission status could be
   leveraged by intermediate systems wishing to "assist" NORM protocol
   performance.  If such systems are properly positioned with respect to
   reciprocal reverse-path multicast routing, they need to sub-cast only
   a sufficient count of non-explicit parity repairs to satisfy a
   multicast routing sub-tree's erasure-filling needs for a given FEC
   coding block.  When the sender has resorted to explicit repair, then
   the intermediate systems SHOULD sub-cast all of the explicit repair
   packets to those portions of the routing tree still requiring repair
   for a given coding block.  Note the intermediate systems will need to
   conduct repair state accumulation for sub-routes in a manner similar
   to the sender's repair state accumulation in order to have sufficient
   information to perform the sub-casting.  Additionally, the
   intermediate systems could perform NORM_NACK suppression/aggregation
   as it conducts this repair state accumulation for NORM repair cycles.
   The details of this type of operation are beyond the scope of this
   document, but this information is provided for possible future
   consideration.

5.4.3.  Sender NORM_CMD(SQUELCH) Generation

   If the sender receives a NORM_NACK message for repair of data it is
   no longer supporting, the sender generates a NORM_CMD(SQUELCH)
   message to advertise its repair window and squelch any receivers from
   additional NACKing of invalid data.  The transmission rate of
   NORM_CMD(SQUELCH) messages is limited to once per 2*GRTT_sender.  The
   "invalid_object_list" (if applicable) of the NORM_CMD(SQUELCH)
   message SHALL begin with the lowest "object_transport_id" from the
   invalid NORM_NACK messages received since the last NORM_CMD(SQUELCH)
   transmission.  The list includes as many lower ordinal invalid
   "object_transport_ids" that can fit for the NORM_CMD(SQUELCH) payload
   size to less than or equal to the sender's NormSegmentSize parameter.

Top      Up      ToC       Page 65 
5.4.4.  Sender NORM_CMD(REPAIR_ADV) Generation

   When a NORM sender receives NORM_NACK messages from receivers via
   unicast transmission, it uses NORM_CMD(REPAIR_ADV) messages to
   advertise its accumulated repair state to the receiver set since the
   receiver set is not directly sharing their repair needs via multicast
   communication.  A NORM sender implementation MAY use a separate port
   number from the NormSession port number as the source port for its
   transmissions.  Thus, NORM receivers can direct any unicast feedback
   messages to this separate sender port number, distinct from the NORM
   session (or destination) port number.  Then, the NORM sender
   implementation can discriminate unicast feedback messages from
   multicast feedback messages when there is a mix of multicast and
   unicast feedback receivers.  The NORM_CMD(REPAIR_ADV) message is
   multicast to the receiver set by the sender.  The payload portion of
   this message has content in the same format as the NORM_NACK receiver
   message payload.  Receivers are then able to perform feedback
   suppression in the same manner as with NORM_NACK messages directly
   received from other receivers.  Note that the sender does not merely
   retransmit NACK content it receives, but instead transmits a
   representation of its aggregated repair state.  The transmission of
   NORM_CMD(REPAIR_ADV) messages is subject to the sender transmit rate
   limit and NormSegmentSize limitation.  When the NORM_CMD(REPAIR_ADV)
   message is of maximum size (as indicated by the flag
   NORM_REPAIR_ADV_FLAG_LIMIT), receivers SHALL consider the maximum
   ordinal transmission position value embedded in the message as the
   senders current transmission position and implicitly suppress
   requests for ordinally higher repair.  For congestion control
   operation, the sender will also need to provide any information
   needed so dynamic congestion control feedback can be suppressed among
   receivers.  This document specifies the NORM-CC Feedback Header
   Extension that is applied for baseline NORM-CC operation.  If other
   congestion control mechanisms are used within a NORM implementation,
   other header extensions MAY be defined.  Whatever content format is
   used for this purpose SHOULD ensure that maximum possible suppression
   state is conveyed to the receiver set.



(page 65 continued on part 4)

Next RFC Part