tech-invite   World Map
3GPP     Specs     Glossaries     UICC       IETF     RFCs     Groups     SIP     ABNFs       T+       Search     Home

RFC 3208

 
 
 

PGM Reliable Transport Protocol Specification

Part 2 of 5, p. 12 to 40
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 12 
3.  Terms and Concepts

   Before proceeding from the preceding overview to the detail in the
   subsequent Procedures, this section presents some concepts and
   definitions that make that detail more intelligible.

3.1.  Transport Session Identifiers

   Every PGM packet is identified by a:

   TSI            transport session identifier

   TSIs MUST be globally unique, and only one source at a time may act
   as the source for a transport session.  (Note that repairers do not
   change the TSI in any RDATA they transmit).  TSIs are composed of the
   concatenation of a globally unique source identifier (GSI) and a
   source-assigned data-source port.

   Since all PGM packets originated by receivers are in response to PGM
   packets originated by a source, receivers simply echo the TSI heard
   from the source in any corresponding packets they originate.

   Since all PGM packets originated by network elements are in response
   to PGM packets originated by a receiver, network elements simply echo
   the TSI heard from the receiver in any corresponding packets they
   originate.

3.2.  Sequence Numbers

   PGM uses a circular sequence number space from 0 through ((2**32) -
   1) to identify and order ODATA packets.  Sources MUST number ODATA
   packets in unit increments in the order in which the corresponding
   application data is submitted for transmission.  Within a transmit or

Top      Up      ToC       Page 13 
   receive window (defined below), a sequence number x is "less" or
   "older" than sequence number y if it numbers an ODATA packet
   preceding ODATA packet y, and a sequence number y is "greater" or
   "more recent" than sequence number x if it numbers an ODATA packet
   subsequent to ODATA packet x.

3.3.  Transmit Window

   The description of the operation of PGM rests fundamentally on the
   definition of the source-maintained transmit window.  This definition
   in turn is derived directly from the amount of transmitted data (in
   seconds) a source retains for repair (TXW_SECS), and the maximum
   transmit rate (in bytes/second) maintained by a source to regulate
   its bandwidth utilization (TXW_MAX_RTE).

   In terms of sequence numbers, the transmit window is the range of
   sequence numbers consumed by the source for sequentially numbering
   and transmitting the most recent TXW_SECS of ODATA packets.  The
   trailing (or left) edge of the transmit window (TXW_TRAIL) is defined
   as the sequence number of the oldest data packet available for repair
   from a source.  The leading (or right) edge of the transmit window
   (TXW_LEAD) is defined as the sequence number of the most recent data
   packet a source has transmitted.

   The size of the transmit window in sequence numbers (TXW_SQNS) (i.e.,
   the difference between the leading and trailing edges plus one) MUST
   be no greater than half the PGM sequence number space less one.

   When TXW_TRAIL is equal to TXW_LEAD, the transmit window size is one.
   When TXW_TRAIL is equal to TXW_LEAD plus one, the transmit window
   size is empty.

3.4.  Receive Window

   The receive window at the receivers is determined entirely by PGM
   packets from the source.  That is, a receiver simply obeys what the
   source tells it in terms of window state and advancement.

   For a given transport session identified by a TSI, a receiver
   maintains:

   RXW_TRAIL      the sequence number defining the trailing edge of the
                  receive window, the sequence number (known from data
                  packets and SPMs) of the oldest data packet available
                  for repair from the source

Top      Up      ToC       Page 14 
   RXW_LEAD       the sequence number defining the leading edge of the
                  receive window, the greatest sequence number of any
                  received data packet within the transmit window

   The receive window is the range of sequence numbers a receiver is
   expected to use to identify receivable ODATA.

   A data packet is described as being "in" the receive window if its
   sequence number is in the receive window.

   The receive window is advanced by the receiver when it receives an
   SPM or ODATA packet within the transmit window that increments
   RXW_TRAIL.  Receivers also advance their receive windows upon receipt
   of any PGM data packet within the receive window that advances the
   receive window.

3.5.  Source Path State

   To establish the repair state required to constrain RDATA, it's
   essential that NAKs return from a receiver to a source on the reverse
   of the distribution tree from the source.  That is, they must return
   through the same sequence of PGM network elements through which the
   ODATA was forwarded, but in reverse.  There are two reasons for this,
   the less obvious one being by far the more important.

   The first and obvious reason is that RDATA is forwarded on the same
   path as ODATA and so repair state must be established on this path if
   it is to constrain the propagation of RDATA.

   The second and less obvious reason is that in the absence of repair
   state, PGM network elements do NOT forward RDATA, so the default
   behavior is to discard repairs.  If repair state is not properly
   established for interfaces on which ODATA went missing, then
   receivers on those interfaces will continue to NAK for lost data and
   ultimately experience unrecoverable data loss.

   The principle function of SPMs is to provide the source path state
   required for PGM network elements to forward NAKs from one PGM
   network element to the next on the reverse of the distribution tree
   for the TSI, establishing repair state each step of the way.  This
   source path state is simply the address of the upstream PGM network
   element on the reverse of the distribution tree for the TSI.  That
   upstream PGM network element may be more than one subnet hop away.
   SPMs establish the identity of the upstream PGM network element on
   the distribution tree for each TSI in each group in each PGM network
   element, a sort of virtual PGM topology.  So although NAKs are
   unicast addressed, they are NOT unicast routed by PGM network
   elements in the conventional sense.  Instead PGM network elements use

Top      Up      ToC       Page 15 
   the source path state established by SPMs to direct NAKs PGM-hop-by-
   PGM-hop toward the source.  The idea is to constrain NAKs to the pure
   PGM topology spanning the more heterogeneous underlying topology of
   both PGM and non-PGM network elements.

   The result is repair state in every PGM network element between the
   receiver and the source so that the corresponding RDATA is never
   discarded by a PGM network element for lack of repair state.

   SPMs also maintain transmit window state in receivers by advertising
   the trailing and leading edges of the transmit window (SPM_TRAIL and
   SPM_LEAD).  In the absence of data, SPMs MAY be used to close the
   transmit window in time by advancing the transmit window until
   SPM_TRAIL is equal to SPM_LEAD plus one.

3.6.  Packet Contents

   This section just provides enough short-hand to make the Procedures
   intelligible.  For the full details of packet contents, please refer
   to Packet Formats below.

3.6.1.  Source Path Messages

3.6.1.1.  SPMs

   SPMs are transmitted by sources to establish source-path state in PGM
   network elements, and to provide transmit-window state in receivers.

   SPMs are multicast to the group and contain:

   SPM_TSI        the source-assigned TSI for the session to which the
                  SPM corresponds

   SPM_SQN        a sequence number assigned sequentially by the source
                  in unit increments and scoped by SPM_TSI

      Nota Bene: this is an entirely separate sequence than is used to
      number ODATA and RDATA.

   SPM_TRAIL      the sequence number defining the trailing edge of the
                  source's transmit window (TXW_TRAIL)

   SPM_LEAD       the sequence number defining the leading edge of the
                  source's transmit window (TXW_LEAD)

   SPM_PATH       the network-layer address (NLA) of the interface on
                  the PGM network element on which the SPM is forwarded

Top      Up      ToC       Page 16 
3.6.2.  Data Packets

3.6.2.1.  ODATA - Original Data

   ODATA packets are transmitted by sources to send application data to
   receivers.

   ODATA packets are multicast to the group and contain:

   OD_TSI         the globally unique source-assigned TSI

   OD_TRAIL       the sequence number defining the trailing edge of the
                  source's transmit window (TXW_TRAIL)

                  OD_TRAIL makes the protocol more robust in the face of
                  lost SPMs.  By including the trailing edge of the
                  transmit window on every data packet, receivers that
                  have missed any SPMs that advanced the transmit window
                  can still detect the case, recover the application,
                  and potentially re-synchronize to the transport
                  session.

   OD_SQN         a sequence number assigned sequentially by the source
                  in unit increments and scoped by OD_TSI

3.6.2.2.  RDATA - Repair Data

   RDATA packets are repair packets transmitted by sources or DLRs in
   response to NAKs.

   RDATA packets are multicast to the group and contain:

   RD_TSI         OD_TSI of the ODATA packet for which this is a repair

   RD_TRAIL       the sequence number defining the trailing edge of the
                  source's transmit window (TXW_TRAIL).  This is updated
                  to the most current value when the repair is sent, so
                  it is not necessarily the same as OD_TRAIL of the
                  ODATA packet for which this is a repair

   RD_SQN         OD_SQN of the ODATA packet for which this is a repair

3.6.3.  Negative Acknowledgments

3.6.3.1.  NAKs - Negative Acknowledgments

   NAKs are transmitted by receivers to request repairs for missing data
   packets.

Top      Up      ToC       Page 17 
   NAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:

   NAK_TSI        OD_TSI of the ODATA packet for which a repair is
                  requested

   NAK_SQN        OD_SQN of the ODATA packet for which a repair is
                  requested

   NAK_SRC        the unicast NLA of the original source of the missing
                  ODATA.

   NAK_GRP        the multicast group NLA

3.6.3.2.  NNAKs - Null Negative Acknowledgments

   NNAKs are transmitted by a DLR that receives NAKs redirected to it by
   either receivers or network elements to provide flow-control feed-
   back to a source.

   NNAKs are unicast (PGM-hop-by-PGM-hop) to the source and contain:

   NNAK_TSI       NAK_TSI of the corresponding re-directed NAK.

   NNAK_SQN       NAK_SQN of the corresponding re-directed NAK.

   NNAK_SRC       NAK_SRC of the corresponding re-directed NAK.

   NNAK_GRP       NAK_GRP of the corresponding re-directed NAK.

3.6.4.  Negative Acknowledgment Confirmations

3.6.4.1.  NCFs - NAK confirmations

   NCFs are transmitted by network elements and sources in response to
   NAKs.

   NCFs are multicast to the group and contain:

   NCF_TSI        NAK_TSI of the NAK being confirmed

   NCF_SQN        NAK_SQN of the NAK being confirmed

   NCF_SRC        NAK_SRC of the NAK being confirmed

   NCF_GRP        NAK_GRP of the NAK being confirmed

Top      Up      ToC       Page 18 
3.6.5.  Option Encodings

   OPT_LENGTH      0x00 - Option's Length

   OPT_FRAGMENT    0x01 - Fragmentation

   OPT_NAK_LIST    0x02 - List of NAK entries

   OPT_JOIN        0x03 - Late Joining

   OPT_REDIRECT    0x07 - Redirect

   OPT_SYN         0x0D - Synchronization

   OPT_FIN         0x0E - Session Fin   receivers, conventional
                          feedbackish

   OPT_RST         0x0F - Session Reset

   OPT_PARITY_PRM  0x08 - Forward Error Correction Parameters

   OPT_PARITY_GRP  0x09 - Forward Error Correction Group Number

   OPT_CURR_TGSIZE 0x0A - Forward Error Correction Group Size

   OPT_CR          0x10 - Congestion Report

   OPT_CRQST       0x11 - Congestion Report Request

   OPT_NAK_BO_IVL  0x04 - NAK Back-Off Interval

   OPT_NAK_BO_RNG  0x05 - NAK Back-Off Range

   OPT_NBR_UNREACH 0x0B - Neighbor Unreachable

   OPT_PATH_NLA    0x0C - Path NLA

   OPT_INVALID     0x7F - Option invalidated

4.  Procedures - General

   Since SPMs, NCFs, and RDATA must be treated conditionally by PGM
   network elements, they must be distinguished from other packets in
   the chosen multicast network protocol if PGM network elements are to
   extract them from the usual switching path.

Top      Up      ToC       Page 19 
   The most obvious way for network elements to achieve this is to
   examine every packet in the network for the PGM transport protocol
   and packet types.  However, the overhead of this approach is costly
   for high-performance, multi-protocol network elements.  An
   alternative, and a requirement for PGM over IP multicast, is that
   SPMs, NCFs, and RDATA MUST be transmitted with the IP Router Alert
   Option [6].  This option gives network elements a network-layer
   indication that a packet should be extracted from IP switching for
   more detailed processing.

5.  Procedures - Sources

5.1.  Data Transmission

   Since PGM relies on a purely rate-limited transmission strategy in
   the source to bound the bandwidth consumed by PGM transport sessions,
   an assortment of techniques is assembled here to make that strategy
   as conservative and robust as possible.  These techniques are the
   minimum REQUIRED of a PGM source.

5.1.1.  Maximum Cumulative Transmit Rate

   A source MUST number ODATA packets in the order in which they are
   submitted for transmission by the application.  A source MUST
   transmit ODATA packets in sequence and only within the transmit
   window beginning with TXW_TRAIL at no greater a rate than
   TXW_MAX_RTE.

   TXW_MAX_RTE is typically the maximum cumulative transmit rate of SPM,
   ODATA, and RDATA.  Different transmission strategies MAY define
   TXW_MAX_RTE as appropriate for the implementation.

5.1.2.  Transmit Rate Regulation

   To regulate its transmit rate, a source MUST use a token bucket
   scheme or any other traffic management scheme that yields equivalent
   behavior.  A token bucket [7] is characterized by a continually
   sustainable data rate (the token rate) and the extent to which the
   data rate may exceed the token rate for short periods of time (the
   token bucket size).  Over any arbitrarily chosen interval, the number
   of bytes the source may transmit MUST NOT exceed the token bucket
   size plus the product of the token rate and the chosen interval.

   In addition, a source MUST bound the maximum rate at which successive
   packets may be transmitted using a leaky bucket scheme drained at a
   maximum transmit rate, or equivalent mechanism.

Top      Up      ToC       Page 20 
5.1.3.  Outgoing Packet Ordering

   To preserve the logic of PGM's transmit window, a source MUST
   strictly prioritize sending of pending NCFs first, pending SPMs
   second, and only send ODATA or RDATA when no NCFs or SPMs are
   pending.  The priority of RDATA versus ODATA is application
   dependent.  The sender MAY implement weighted bandwidth sharing
   between RDATA and ODATA.  Note that strict prioritization of RDATA
   over ODATA may stall progress of ODATA if there are receivers that
   keep generating NAKs so as to always have RDATA pending (e.g. a
   steady stream of late joiners with OPT_JOIN).  Strictly prioritizing
   ODATA over RDATA may lead to a larger portion of receivers getting
   unrecoverable losses.

5.1.4.  Ambient SPMs

   Interleaved with ODATA and RDATA, a source MUST transmit SPMs at a
   rate at least sufficient to maintain current source path state in PGM
   network elements.  Note that source path state in network elements
   does not track underlying changes in the distribution tree from a
   source until an SPM traverses the altered distribution tree.  The
   consequence is that NAKs may go unconfirmed both at receivers and
   amongst network elements while changes in the underlying distribution
   tree take place.

5.1.5.  Heartbeat SPMs

   In the absence of data to transmit, a source SHOULD transmit SPMs at
   a decaying rate in order to assist early detection of lost data, to
   maintain current source path state in PGM network elements, and to
   maintain current receive window state in the receivers.

   In this scheme [8], a source maintains an inter-heartbeat timer
   IHB_TMR which times the interval between the most recent packet
   (ODATA, RDATA, or SPM) transmission and the next heartbeat
   transmission.  IHB_TMR is initialized to a minimum interval IHB_MIN
   after the transmission of any data packet.  If IHB_TMR expires, the
   source transmits a heartbeat SPM and initializes IHB_TMR to double
   its previous value.  The transmission of consecutive heartbeat SPMs
   doubles IHB each time up to a maximum interval IHB_MAX.  The
   transmission of any data packet initializes IHB_TMR to IHB_MIN once
   again.  The effect is to provoke prompt detection of missing packets
   in the absence of data to transmit, and to do so with minimal
   bandwidth overhead.

Top      Up      ToC       Page 21 
5.1.6.  Ambient and Heartbeat SPMs

   Ambient and heartbeat SPMs are described as driven by separate timers
   in this specification to highlight their contrasting functions.
   Ambient SPMs are driven by a count-down timer that expires regularly
   while heartbeat SPMs are driven by a count-down timer that keeps
   being reset by data, and the interval of which changes once it begins
   to expire.  The ambient SPM timer is just counting down in real-time
   while the heartbeat timer is measuring the inter-data-packet
   interval.

   In the presence of data, no heartbeat SPMs will be transmitted since
   the transmission of data keeps setting the IHB_TMR back to its
   initial value.  At the same time however, ambient SPMs MUST be
   interleaved into the data as a matter of course, not necessarily as a
   heartbeat mechanism.  This ambient transmission of SPMs is REQUIRED
   to keep the distribution tree information in the network current and
   to allow new receivers to synchronize with the session.

   An implementation SHOULD de-couple ambient and heartbeat SPM timers
   sufficiently to permit them to be configured independently of each
   other.

5.2.  Negative Acknowledgment Confirmation

   A source MUST immediately multicast an NCF in response to any NAK it
   receives.  The NCF is REQUIRED since the alternative of responding
   immediately with RDATA would not allow other PGM network elements on
   the same subnet to do NAK anticipation, nor would it allow DLRs on
   the same subnet to provide repairs.  A source SHOULD be able to
   detect a NAK storm and adopt countermeasure to protect the network
   against a denial of service.  A possible countermeasure is to send
   the first NCF immediately in response to a NAK and then delay the
   generation of further NCFs (for identical NAKs) by a small interval,
   so that identical NCFs are rate-limited, without affecting the
   ability to suppress NAKs.

5.3.  Repairs

   After multicasting an NCF in response to a NAK, a source MUST then
   multicast RDATA (while respecting TXW_MAX_RTE) in response to any NAK
   it receives for data packets within the transmit window.

   In the interest of increasing the efficiency of a particular RDATA
   packet, a source MAY delay RDATA transmission to accommodate the
   arrival of NAKs from the whole loss neighborhood.  This delay SHOULD
   not exceed twice the greatest propagation delay in the loss
   neighborhood.

Top      Up      ToC       Page 22 
6.  Procedures - Receivers

6.1.  Data Reception

   Initial data reception

   A receiver SHOULD initiate data reception beginning with the first
   data packet it receives within the advertised transmit window.  This
   packet's sequence number (ODATA_SQN) temporarily defines the trailing
   edge of the transmit window from the receiver's perspective.  That
   is, it is assigned to RXW_TRAIL_INIT within the receiver, and until
   the trailing edge sequence number advertised in subsequent packets
   (SPMs or ODATA or RDATA) increments past RXW_TRAIL_INIT, the receiver
   MUST only request repairs for sequence numbers subsequent to
   RXW_TRAIL_INIT.  Thereafter, it MAY request repairs anywhere in the
   transmit window.  This temporary restriction on repair requests
   prevents receivers from requesting a potentially large amount of
   history when they first begin to receive a given PGM transport
   session.

   Note that the JOIN option, discussed later, MAY be used to provide a
   different value for RXW_TRAIL_INIT.

   Receiving and discarding data packets

   Within a given transport session, a receiver MUST accept any ODATA or
   RDATA packets within the receive window.  A receiver MUST discard any
   data packet that duplicates one already received in the transmit
   window.  A receiver MUST discard any data packet outside of the
   receive window.

   Contiguous data

   Contiguous data is comprised of those data packets within the receive
   window that have been received and are in the range from RXW_TRAIL up
   to (but not including) the first missing sequence number in the
   receive window.  The most recently received data packet of contiguous
   data defines the leading edge of contiguous data.

   As its default mode of operation, a receiver MUST deliver only
   contiguous data packets to the application, and it MUST do so in the
   order defined by those data packets' sequence numbers.  This provides
   applications with a reliable ordered data flow.

Top      Up      ToC       Page 23 
   Non contiguous data

   PGM receiver implementations MAY optionally provide a mode of
   operation in which data is delivered to an application in the order
   received.  However, the implementation MUST only deliver complete
   application protocol data units (APDUs) to the application.  That is,
   APDUs that have been fragmented into different TPDUs MUST be
   reassembled before delivery to the application.

6.2.  Source Path Messages

   Receivers MUST receive and sequence SPMs for any TSI they are
   receiving.  An SPM is in sequence if its sequence number is greater
   than that of the most recent in-sequence SPM and within half the PGM
   number space.  Out-of-sequence SPMs MUST be discarded.

   For each TSI, receivers MUST use the most recent SPM to determine the
   NLA of the upstream PGM network element for use in NAK addressing.  A
   receiver MUST NOT initiate repair requests until it has received at
   least one SPM for the corresponding TSI.

   Since SPMs require per-hop processing, it is likely that they will be
   forwarded at a slower rate than data, and that they will arrive out
   of sync with the data stream.  In this case, the window information
   that the SPMs carry will be out of date.  Receivers SHOULD expect
   this to be the case and SHOULD detect it by comparing the packet lead
   and trail values with the values the receivers have stored for lead
   and trail.  If the SPM packet values are less, they SHOULD be
   ignored, but the rest of the packet SHOULD be processed as normal.

6.3.  Data Recovery by Negative Acknowledgment

   Detecting missing data packets

   Receivers MUST detect gaps in the expected data sequence in the
   following manners:

      by comparing the sequence number on the most recently received
      ODATA or RDATA packet with the leading edge of contiguous data

      by comparing SPM_LEAD of the most recently received SPM with the
      leading edge of contiguous data

   In both cases, if the receiver has not received all intervening data
   packets, it MAY initiate selective NAK generation for each missing
   sequence number.

Top      Up      ToC       Page 24 
   In addition, a receiver may detect a single missing data packet by
   receiving an NCF or multicast NAK for a data packet within the
   transmit window which it has not received.  In this case it MAY
   initiate selective NAK generation for the said sequence number.

   In all cases, receivers SHOULD temper the initiation of NAK
   generation to account for simple mis-ordering introduced by the
   network.  A possible mechanism to achieve this is to assume loss only
   after the reception of N packets with sequence numbers higher than
   those of the (assumed) lost packets.  A possible value for N is 2.
   This method SHOULD be complemented with a timeout based mechanism
   that handles the loss of the last packet before a pause in the
   transmission of the data stream.  The leading edge field in SPMs
   SHOULD also be taken into account in the loss detection algorithm.

   Generating NAKs

   NAK generation follows the detection of a missing data packet and is
   the cycle of:

      waiting for a random period of time (NAK_RB_IVL) while listening
      for matching NCFs or NAKs

      transmitting a NAK if a matching NCF or NAK is not heard

      waiting a period (NAK_RPT_IVL) for a matching NCF and recommencing
      NAK generation if the matching NCF is not received

      waiting a period (NAK_RDATA_IVL) for data and recommencing NAK
      generation if the matching data is not received

   The entire generation process can be summarized by the following
   state machine:

Top      Up      ToC       Page 25 
                              |
                              | detect missing tpdu
                              |   - clear data retry count
                              |   - clear NCF retry count
                              V
      matching NCF |--------------------------|
   <---------------|   BACK-OFF_STATE         | <----------------------
   |               | start timer(NAK_RB_IVL)  |            ^          ^
   |               |                          |            |          |
   |               |--------------------------|            |          |
   |       matching |         | timer expires              |          |
   |         NAK    |         |   - send NAK               |          |
   |                |         |                            |          |
   |                V         V                            |          |
   |               |--------------------------|            |          |
   |               |    WAIT_NCF_STATE        |            |          |
   |  matching NCF | start timer(NAK_RPT_IVL) |            |          |
   |<--------------|                          |------------>          |
   |               |--------------------------| timer expires         |
   |                    |         |         ^    - increment NCF      |
   |    NAK_NCF_RETRIES |         |         |      retry count        |
   |       exceeded     |         |         |                         |
   |                    V         -----------                         |
   |                Cancelation      matching NAK                     |
   |                                   - restart timer(NAK_RPT_IVL)   |
   |                                                                  |
   |                                                                  |
   V               |--------------------------|                       |
   --------------->|   WAIT_DATA_STATE        |----------------------->
                   |start timer(NAK_RDATA_IVL)|  timer expires
                   |                          |   - increment data
                   |--------------------------|     retry count
                      |        |           ^
     NAK_DATA_RETRIES |        |           |
         exceeded     |        |           |
                      |         -----------
                      |          matching NCF or NAK
                      V            - restart timer(NAK_RDATA_IVL)
                 Cancellation

   In any state, receipt of matching RDATA or ODATA completes data
   recovery and successful exit from the state machine.  State
   transition stops any running timers.

   In any state, if the trailing edge of the window moves beyond the
   sequence number, data recovery for that sequence number terminates.

Top      Up      ToC       Page 26 
   During NAK_RB_IVL a NAK is said to be pending.  When awaiting data or
   an NCF, a NAK is said to be outstanding.

   Backing off NAK transmission

   Before transmitting a NAK, a receiver MUST wait some interval
   NAK_RB_IVL chosen randomly over some time period NAK_BO_IVL.  During
   this period, receipt of a matching NAK or a matching NCF will suspend
   NAK generation.  NAK_RB_IVL is counted down from the time a missing
   data packet is detected.

   A value for NAK_BO_IVL learned from OPT_NAK_BO_IVL (see 16.4.1 below)
   MUST NOT be used by a receiver (i.e., the receiver MUST NOT NAK)
   unless either NAK_BO_IVL_SQN is zero, or the receiver has seen
   POLL_RND == 0 for POLL_SQN =< NAK_BO_IVL_SQN within half the sequence
   number space.

   When a parity NAK (Appendix A, FEC) is being generated, the back-off
   interval SHOULD be inversely biased with respect to the number of
   parity packets requested.  This way NAKs requesting larger numbers of
   parity packets are likely to be sent first and thus suppress other
   NAKs.  A NAK for a given transmission group suppresses another NAK
   for the same transmission group only if it is requesting an equal or
   larger number of parity packets.

   When a receiver has to transmit a sequence of NAKs, it SHOULD
   transmit the NAKs in order from oldest to most recent.

   Suspending NAK generation

   Suspending NAK generation just means waiting for either NAK_RB_IVL,
   NAK_RPT_IVL or NAK_RDATA_IVL to pass.  A receiver MUST suspend NAK
   generation if a duplicate of the NAK is already pending from this
   receiver or the NAK is already outstanding from this or another
   receiver.

   NAK suppression

   A receiver MUST suppress NAK generation and wait at least
   NAK_RDATA_IVL before recommencing NAK generation if it hears a
   matching NCF or NAK during NAK_RB_IVL.  A matching NCF must match
   NCF_TSI with NAK_TSI, and NCF_SQN with NAK_SQN.

   Transmitting a NAK

   Upon expiry of NAK_RB_IVL, a receiver MUST unicast a NAK to the
   upstream PGM network element for the TSI specifying the transport
   session identifier and missing sequence number.  In addition, it MAY

Top      Up      ToC       Page 27 
   multicast a NAK with TTL of 1 to the group, if the PGM parent is not
   directly connected.  It also records both the address of the source
   of the corresponding ODATA and the address of the group in the NAK
   header.

   It MUST repeat the NAK at a rate governed by NAK_RPT_IVL up to
   NAK_NCF_RETRIES times while waiting for a matching NCF.  It MUST then
   wait NAK_RDATA_IVL before recommencing NAK generation.  If it hears a
   matching NCF or NAK during NAK_RDATA_IVL, it MUST wait anew for
   NAK_RDATA_IVL before recommencing NAK generation (i.e. matching NCFs
   and NAKs restart NAK_RDATA_IVL).

   Completion of NAK generation

   NAK generation is complete only upon the receipt of the matching
   RDATA (or even ODATA) packet at any time during NAK generation.

   Cancellation of NAK generation

   NAK generation is cancelled upon the advancing of the receive window
   so as to exclude the matching sequence number of a pending or
   outstanding NAK, or NAK_DATA_RETRIES / NAK_NCF_RETRIES being
   exceeded.  Cancellation of NAK generation indicates unrecoverable
   data loss.

   Receiving NCFs and multicast NAKs

   A receiver MUST discard any NCFs or NAKs it hears for data packets
   outside the transmit window or for data packets it has received.
   Otherwise they are treated as appropriate for the current repair
   state.

7.  Procedures - Network Elements

7.1.  Source Path State

   Upon receipt of an in-sequence SPM, a network element records the
   Source Path Address SPM_PATH with the multicast routing information
   for the TSI.  If the receiving network element is on the same subnet
   as the forwarding network element, this address will be the same as
   the address of the immediately upstream network element on the
   distribution tree for the TSI.  If, however, non-PGM network elements
   intervene between the forwarding and the receiving network elements,
   this address will be the address of the first PGM network element
   across the intervening network elements.

Top      Up      ToC       Page 28 
   The network element then forwards the SPM on each outgoing interface
   for that TSI.  As it does so, it encodes the network address of the
   outgoing interface in SPM_PATH in each copy of the SPM it forwards.

7.2.  NAK Confirmation

   Network elements MUST immediately transmit an NCF in response to any
   unicast NAK they receive.  The NCF MUST be multicast to the group on
   the interface on which the NAK was received.

      Nota Bene: In order to avoid creating multicast routing state for
      PGM network elements across non-PGM-capable clouds, the network-
      header source address of NCFs transmitted by network elements MUST
      be set to the ODATA source's NLA, not the network element's NLA as
      might be expected.

   Network elements should be able to detect a NAK storm and adopt
   counter-measure to protect the network against a denial of service.
   A possible countermeasure is to send the first NCF immediately in
   response to a NAK and then delay the generation of further NCFs (for
   identical NAKs) by a small interval, so that identical NCFs are
   rate-limited, without affecting the ability to suppress NAKs.

   Simultaneously, network elements MUST establish repair state for the
   NAK if such state does not already exist, and add the interface on
   which the NAK was received to the corresponding repair interface list
   if the interface is not already listed.

7.3.  Constrained NAK Forwarding

   The NAK forwarding procedures for network elements are quite similar
   to those for receivers, but three important differences should be
   noted.

   First, network elements do NOT back off before forwarding a NAK
   (i.e., there is no NAK_BO_IVL) since the resulting delay of the NAK
   would compound with each hop.  Note that NAK arrivals will be
   randomized by the receivers from which they originate, and this
   factor in conjunction with NAK anticipation and elimination will
   combine to forestall NAK storms on subnets with a dense network
   element population.

   Second, network elements do NOT retry confirmed NAKs if RDATA is not
   seen; they simply discard the repair state and rely on receivers to
   re-request the repair.  This approach keeps the repair state in the
   network elements relatively ephemeral and responsive to underlying
   routing changes.

Top      Up      ToC       Page 29 
   Third, note that ODATA does NOT cancel NAK forwarding in network
   elements since it is switched by network elements without transport-
   layer intervention.

      Nota Bene: Once confirmed by an NCF, network elements discard NAK
      packets; they are NOT retained in network elements beyond this
      forwarding operation.

   NAK forwarding requires that a network element listen to NCFs for the
   same transport session.  NAK forwarding also requires that a network
   element observe two time out intervals for any given NAK (i.e., per
   NAK_TSI and NAK_SQN): NAK_RPT_IVL and NAK_RDATA_IVL.

   The NAK repeat interval NAK_RPT_IVL, limits the length of time for
   which a network element will repeat a NAK while waiting for a
   corresponding NCF.  NAK_RPT_IVL is counted down from the transmission
   of a NAK.  Expiry of NAK_RPT_IVL cancels NAK forwarding (due to
   missing NCF).

   The NAK RDATA interval NAK_RDATA_IVL, limits the length of time for
   which a network element will wait for the corresponding RDATA.
   NAK_RDATA_IVL is counted down from the time a matching NCF is
   received.  Expiry of NAK_RDATA_IVL causes the network element to
   discard the corresponding repair state (due to missing RDATA).

   During NAK_RPT_IVL, a NAK is said to be pending.  During
   NAK_RDATA_IVL, a NAK is said to be outstanding.

   A Network element MUST forward NAKs only to the upstream PGM network
   element for the TSI.

   A network element MUST repeat a NAK at a rate of NAK_RPT_RTE for an
   interval of NAK_RPT_IVL until it receives a matching NCF.  A matching
   NCF must match NCF_TSI with NAK_TSI, and NCF_SQN with NAK_SQN.

   Upon reception of the corresponding NCF, network elements MUST wait
   at least NAK_RDATA_IVL for the corresponding RDATA.  Receipt of the
   corresponding RDATA at any time during NAK forwarding cancels NAK
   forwarding and tears down the corresponding repair state in the
   network element.

7.4.  NAK elimination

   Two NAKs duplicate each other if they bear the same NAK_TSI and
   NAK_SQN.  Network elements MUST discard all duplicates of a NAK that
   is pending.

Top      Up      ToC       Page 30 
   Once a NAK is outstanding, network elements MUST discard all
   duplicates of that NAK for NAK_ELIM_IVL.  Upon expiry of
   NAK_ELIM_IVL, network elements MUST suspend NAK elimination for that
   TSI/SQN until the first duplicate of that NAK is seen after the
   expiry of NAK_ELIM_IVL.  This duplicate MUST be forwarded in the
   usual manner.  Once this duplicate NAK is outstanding, network
   elements MUST once again discard all duplicates of that NAK for
   NAK_ELIM_IVL, and so on.  NAK_RDATA_IVL MUST be reset each time a NAK
   for the corresponding TSI/SQN is confirmed (i.e., each time
   NAK_ELIM_IVL is reset).  NAK_ELIM_IVL MUST be some small fraction of
   NAK_RDATA_IVL.

   NAK_ELIM_IVL acts to balance implosion prevention against repair
   state liveness.  That is, it results in the elimination of all but at
   most one NAK per NAK_ELIM_IVL thereby allowing repeated NAKs to keep
   the repair state alive in the PGM network elements.

7.5.  NAK Anticipation

   An unsolicited NCF is one that is received by a network element when
   the network element has no corresponding pending or outstanding NAK.
   Network elements MUST process unsolicited NCFs differently depending
   on the interface on which they are received.

   If the interface on which an NCF is received is the same interface
   the network element would use to reach the upstream PGM network
   element, the network element simply establishes repair state for
   NCF_TSI and NCF_SQN without adding the interface to the repair
   interface list, and discards the NCF.  If the repair state already
   exists, the network element restarts the NAK_RDATA_IVL and
   NAK_ELIM_IVL timers and discards the NCF.

   If the interface on which an NCF is received is not the same
   interface the network element would use to reach the upstream PGM
   network element, the network element does not establish repair state
   and just discards the NCF.

   Anticipated NAKs permit the elimination of any subsequent matching
   NAKs from downstream.  Upon establishing anticipated repair state,
   network elements MUST eliminate subsequent NAKs only for a period of
   NAK_ELIM_IVL.  Upon expiry of NAK_ELIM_IVL, network elements MUST
   suspend NAK elimination for that TSI/SQN until the first duplicate of
   that NAK is seen after the expiry of NAK_ELIM_IVL.  This duplicate
   MUST be forwarded in the usual manner.  Once this duplicate NAK is
   outstanding, network elements MUST once again discard all duplicates
   of that NAK for NAK_ELIM_IVL, and so on.  NAK_RDATA_IVL MUST be reset

Top      Up      ToC       Page 31 
   each time a NAK for the corresponding TSI/SQN is confirmed (i.e.,
   each time NAK_ELIM_IVL is reset).  NAK_ELIM_IVL must be some small
   fraction of NAK_RDATA_IVL.

7.6.  NAK Shedding

   Network elements MAY implement local procedures for withholding NAK
   confirmations for receivers detected to be reporting excessive loss.
   The result of these procedures would ultimately be unrecoverable data
   loss in the receiver.

7.7.  Addressing NAKs

   A PGM network element uses the source and group addresses (NLAs)
   contained in the transport header to find the state for the
   corresponding TSI, looks up the corresponding upstream PGM network
   element's address, uses it to re-address the (unicast) NAK, and
   unicasts it on the upstream interface for the distribution tree for
   the TSI.

7.8.  Constrained RDATA Forwarding

   Network elements MUST maintain repair state for each interface on
   which a given NAK is received at least once.  Network elements MUST
   then use this list of interfaces to constrain the forwarding of the
   corresponding RDATA packet only to those interfaces in the list.  An
   RDATA packet corresponds to a NAK if it matches NAK_TSI and NAK_SQN.

   Network elements MUST maintain this repair state only until either
   the corresponding RDATA is received and forwarded, or NAK_RDATA_IVL
   passes after forwarding the most recent instance of a given NAK.
   Thereafter, the corresponding repair state MUST be discarded.

   Network elements SHOULD discard and not forward RDATA packets for
   which they have no repair state.  Note that the consequence of this
   procedure is that, while it constrains repairs to the interested
   subset of the network, loss of repair state precipitates further NAKs
   from neglected receivers.

8.  Packet Formats

   All of the packet formats described in this section are transport-
   layer headers that MUST immediately follow the network-layer header
   in the packet.  Only data packet headers (ODATA and RDATA) may be
   followed in the packet by application data.  For each packet type,
   the network-header source and destination addresses are specified in

Top      Up      ToC       Page 32 
   addition to the format and contents of the transport layer header.
   Recall from General Procedures that, for PGM over IP multicast, SPMs,
   NCFs, and RDATA MUST also bear the IP Router Alert Option.

   For PGM over IP, the IP protocol number is 113.

   In all packets the descriptions of Data-Source Port, Data-Destination
   Port, Type, Options, Checksum, Global Source ID (GSI), and Transport
   Service Data Unit (TSDU) Length are:

      Data-Source Port:

         A random port number generated by the source.  This port number
         MUST be unique within the source.  Source Port together with
         Global Source ID forms the TSI.

      Data-Destination Port:

         A globally well-known port number assigned to the given PGM
         application.

      Type:

         The high-order two bits of the Type field encode a version
         number, 0x0 in this instance.  The low-order nibble of the type
         field encodes the specific packet type.  The intervening two
         bits (the low-order two bits of the high-order nibble) are
         reserved and MUST be zero.

         Within the low-order nibble of the Type field:

            values in the range 0x0 through 0x3 represent SPM-like
            packets (i.e., session-specific, sourced by a source,
            periodic),

            values in the range 0x4 through 0x7 represent DATA-like
            packets (i.e., data and repairs),

            values in the range 0x8 through 0xB represent NAK-like
            packets (i.e., hop-by-hop reliable NAK forwarding
            procedures),

            and values in the range 0xC through 0xF represent SPMR-like
            packets (i.e., session-specific, sourced by a receiver,
            asynchronous).

Top      Up      ToC       Page 33 
      Options:

         This field encodes binary indications of the presence and
         significance of any options.  It also directly encodes some
         options.

         bit 0 set => One or more Option Extensions are present

         bit 1 set => One or more Options are network-significant

            Note that this bit is clear when OPT_FRAGMENT and/or
            OPT_JOIN are the only options present.

         bit 6 set => Packet is a parity packet for a transmission group
         of variable sized packets (OPT_VAR_PKTLEN).  Only present when
         OPT_PARITY is also present.

         bit 7 set => Packet is a parity packet (OPT_PARITY)

         Bits are numbered here from left (0 = MSB) to right (7 = LSB).

         All the other options (option extensions) are encoded in
         extensions to the PGM header.

      Checksum:

         This field is the usual 1's complement of the 1's complement
         sum of the entire PGM packet including header.

         The checksum does not include a network-layer pseudo header for
         compatibility with network address translation.  If the
         computed checksum is zero, it is transmitted as all ones.  A
         value of zero in this field means the transmitter generated no
         checksum.

         Note that if any entity between a source and a receiver
         modifies the PGM header for any reason, it MUST either
         recompute the checksum or clear it.  The checksum is mandatory
         on data packets (ODATA and RDATA).

      Global Source ID:

         A globally unique source identifier.  This ID MUST NOT change
         throughout the duration of the transport session.  A
         RECOMMENDED identifier is the low-order 48 bits of the MD5 [9]
         signature of the DNS name of the source.  Global Source ID
         together with Data-Source Port forms the TSI.

Top      Up      ToC       Page 34 
      TSDU Length:

         The length in octets of the transport data unit exclusive of
         the transport header.

         Note that those who require the TPDU length must obtain it from
         sum of the transport header length (TH) and the TSDU length.
         TH length is the sum of the size of the particular PGM packet
         header (type_specific_size) plus the length of any options that
         might be present.

   Address Family Indicators (AFIs) are as specified in [10].

8.1.  Source Path Messages

   SPMs are sent by a source to establish source path state in network
   elements and to provide transmit window state to receivers.

   The network-header source address of an SPM is the unicast NLA of the
   entity that originates the SPM.

   The network-header destination address of an SPM is a multicast group
   NLA.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source Port           |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Options    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Global Source ID                   ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...    Global Source ID       |           TSDU Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     SPM's Sequence Number                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Trailing Edge Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Leading Edge Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            NLA AFI            |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Path NLA                     ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
   | Option Extensions when present ...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 35 
   Source Port:

      SPM_SPORT

      Data-Source Port, together with SPM_GSI forms SPM_TSI

   Destination Port:

      SPM_DPORT

      Data-Destination Port

   Type:

      SPM_TYPE = 0x00

   Global Source ID:

      SPM_GSI

      Together with SPM_SPORT forms SPM_TSI

   SPM's Sequence Number

      SPM_SQN

      The sequence number assigned to the SPM by the source.

   Trailing Edge Sequence Number:

      SPM_TRAIL

      The sequence number defining the current trailing edge of the
      source's transmit window (TXW_TRAIL).

   Leading Edge Sequence Number:

      SPM_LEAD

      The sequence number defining the current leading edge of the
      source's transmit window (TXW_LEAD).

      If SPM_TRAIL == 0 and SPM_LEAD == 0x80000000, this indicates that
      no window information is present in the packet.

Top      Up      ToC       Page 36 
   Path NLA:

      SPM_PATH

      The NLA of the interface on the network element on which this SPM
      was forwarded.  Initialized by a source to the source's NLA,
      rewritten by each PGM network element upon forwarding.

8.2.  Data Packets

   Data packets carry application data from a source or a repairer to
   receivers.

      ODATA:

         Original data packets transmitted by a source.

      RDATA:

         Repairs transmitted by a source or by a designated local
         repairer (DLR) in response to a NAK.

   The network-header source address of a data packet is the unicast NLA
   of the entity that originates the data packet.

   The network-header destination address of a data packet is a
   multicast group NLA.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source Port           |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Options    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Global Source ID                   ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...    Global Source ID       |           TSDU Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Data Packet Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Trailing Edge Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Option Extensions when present ...                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Data ...
   +-+-+- ...

Top      Up      ToC       Page 37 
   Source Port:

      OD_SPORT, RD_SPORT

      Data-Source Port, together with Global Source ID forms:

      OD_TSI, RD_TSI

   Destination Port:

      OD_DPORT, RD_DPORT

      Data-Destination Port

   Type:

      OD_TYPE =  0x04 RD_TYPE =  0x05

   Global Source ID:

      OD_GSI, RD_GSI

      Together with Source Port forms:

      OD_TSI, RD_TSI

   Data Packet Sequence Number:

      OD_SQN, RD_SQN

      The sequence number originally assigned to the ODATA packet by the
      source.

   Trailing Edge Sequence Number:

      OD_TRAIL, RD_TRAIL

      The sequence number defining the current trailing edge of the
      source's transmit window (TXW_TRAIL).  In RDATA, this MAY not be
      the same as OD_TRAIL of the ODATA packet for which it is a repair.

   Data:

      Application data.

Top      Up      ToC       Page 38 
8.3.  Negative Acknowledgments and Confirmations

      NAK:

         Negative Acknowledgments are sent by receivers to request the
         repair of an ODATA packet detected to be missing from the
         expected sequence.

      N-NAK:

         Null Negative Acknowledgments are sent by DLRs to provide flow
         control feedback to the source of ODATA for which the DLR has
         provided the corresponding RDATA.

   The network-header source address of a NAK is the unicast NLA of the
   entity that originates the NAK.  The network-header source address of
   NAK is rewritten by each PGM network element with its own.

   The network-header destination address of a NAK is initialized by the
   originator of the NAK (a receiver) to the unicast NLA of the upstream
   PGM network element known from SPMs.  The network-header destination
   address of a NAK is rewritten by each PGM network element with the
   unicast NLA of the upstream PGM network element to which this NAK is
   forwarded.  On the final hop, the network-header destination address
   of a NAK is rewritten by the PGM network element with the unicast NLA
   of the original source or the unicast NLA of a DLR.

      NCF:

         NAK Confirmations are sent by network elements and sources to
         confirm the receipt of a NAK.

   The network-header source address of an NCF is the ODATA source's
   NLA, not the network element's NLA as might be expected.

   The network-header destination address of an NCF is a multicast group
   NLA.

   Note that in NAKs and N-NAKs, unlike the other packets, the field
   SPORT contains the Data-Destination port and the field DPORT contains
   the Data-Source port.  As a general rule, the content of SPORT/DPORT
   is determined by the direction of the flow: in packets which travel
   down-stream SPORT is the port number chosen in the data source
   (Data-Source Port) and DPORT is the data destination port number
   (Data-Destination Port).  The opposite holds for packets which travel
   upstream.  This makes DPORT the protocol endpoint in the recipient
   host, regardless of the direction of the packet.

Top      Up      ToC       Page 39 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Source Port           |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |    Options    |           Checksum            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Global Source ID                   ... |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ...    Global Source ID       |           TSDU Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Requested Sequence Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            NLA AFI            |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Source NLA                    ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
   |            NLA AFI            |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Multicast Group NLA                ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+
   | Option Extensions when present ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...

   Source Port:

      NAK_SPORT, NNAK_SPORT

         Data-Destination Port

      NCF_SPORT

      Data-Source Port, together with Global Source ID forms NCF_TSI

   Destination Port:

      NAK_DPORT, NNAK_DPORT

         Data-Source Port, together with Global Source ID forms:

            NAK_TSI, NNAK_TSI

      NCF_DPORT

      Data-Destination Port

Top      Up      ToC       Page 40 
   Type:

      NAK_TYPE =  0x08 NNAK_TYPE = 0x09

      NCF_TYPE =  0x0A

   Global Source ID:

      NAK_GSI, NNAK_GSI, NCF_GSI

      Together with Data-Source Port forms

         NAK_TSI, NNAK_TSI, NCF_TSI

   Requested Sequence Number:

      NAK_SQN, NNAK_SQN

      NAK_SQN is the sequence number of the ODATA packet for which a
      repair is requested.

      NNAK_SQN is the sequence number of the RDATA packet for which a
      repair has been provided by a DLR.

      NCF_SQN

      NCF_SQN is NAK_SQN from the NAK being confirmed.

   Source NLA:

      NAK_SRC, NNAK_SRC, NCF_SRC

      The unicast NLA of the original source of the missing ODATA.

   Multicast Group NLA:

      NAK_GRP, NNAK_GRP, NCF_GRP

      The multicast group NLA.  NCFs MAY bear OPT_REDIRECT and/or
      OPT_NAK_LIST



(page 40 continued on part 3)

Next RFC Part