tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 3208

 
 
 

PGM Reliable Transport Protocol Specification

Part 3 of 5, p. 40 to 72
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 40 
9.  Options

   PGM specifies several end-to-end options to address specific
   application requirements.  PGM specifies options to support
   fragmentation, late joining, and redirection.

Top      Up      ToC       Page 41 
   Options MAY be appended to PGM data packet headers only by their
   original transmitters.  While they MAY be interpreted by network
   elements, options are neither added nor removed by network elements.

   Options are all in the TLV style, or Type, Length, Value.  The Type
   field is contained in the first byte, where bit 0 is the OPT_END bit,
   followed by 7 bits of type.  The OPT_END bit MUST be set in the last
   option in the option list, whichever that might be.  The Length field
   is the total length of the option in bytes, and directly follows the
   Type field.  Following the Length field are 5 reserved bits, the
   OP_ENCODED flag, the 2 Option Extensibility bits OPX and the
   OP_ENCODED_NULL flag.  Last are 7 bits designated for option specific
   information which may be defined on a per-option basis.  If not
   defined for a particular option, they MUST be set to 0.

   The Option Extensibility bits dictate the desired treatment of an
   option if it is unknown to the network element processing it.

      Nota Bene:  Only network elements pay any attention to these bits.

      The OPX bits are defined as follows:

      00 -     Ignore the option

      01 -     Invalidate the option by changing the type to OPT_INVALID
               = 0x7F

      10 -     Discard the packet

      11 -     Unsupported, and reserved for future use

   Some options present in data packet (ODATA and RDATA) are strictly
   associated with the packet content (PGM payload), OPT_FRAGMENT being
   an example.  These options must be preserved even when the data
   packet that would normally contain them is not received, but its the
   payload is recovered though the use of FEC.  PGM specifies a
   mechanism to accomplish this that uses the F (OP_ENCODED) and U
   (OP_ENCODED_NULL) bits in the option common header.  OP_ENCODED and
   OP_ENCODED_NULL MUST be normally set to zero except when the option
   is used in FEC packets to preserve original options.  See Appendix A
   for details.

   There is a limit of 16 options per packet.

Top      Up      ToC       Page 42 
   General Option 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|Opt. Specific|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Option Value                    ...    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...+-+-+

9.1.  Option extension length - OPT_LENGTH

   When option extensions are appended to the standard PGM header, the
   extensions MUST be preceded by an option extension length field
   specifying the total length of all option extensions.

   In addition, the presence of the options MUST be encoded in the
   Options field of the standard PGM header before the Checksum is
   computed.

   All network-significant options MUST be appended before any
   exclusively receiver-significant options.

   To provide an indication of the end of option extensions, OPT_END
   (0x80) MUST be set in the Option Type field of the trailing option
   extension.

9.1.1.  OPT_LENGTH - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Option Type  | Option Length |  Total length of all options  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x00

   Option Length = 4 octets

   Total length of all options

      The total length in octets of all option extensions including
      OPT_LENGTH.

   OPT_LENGTH is NOT network-significant.

Top      Up      ToC       Page 43 
9.2.  Fragmentation Option - OPT_FRAGMENT

   Fragmentation allows transport-layer entities at a source to break up
   application protocol data units (APDUs) into multiple PGM data
   packets (TPDUs) to conform with the MTU supported by the network
   layer.  The fragmentation option MAY be applied to ODATA and RDATA
   packets only.

   Architecturally, the accumulation of TSDUs into APDUs is applied to
   TPDUs that have already been received, duplicate eliminated, and
   contiguously sequenced by the receiver.  Thus APDUs MAY be
   reassembled across increments of the transmit window.

9.2.1.  OPT_FRAGMENT - Packet Extension Contents

   OPT_FRAG_OFF   the offset of the fragment from the beginning of the
                  APDU

   OPT_FRAG_LEN   the total length of the original APDU

9.2.2.  OPT_FRAGMENT - Procedures - Sources

   A source fragments APDUs into a contiguous series of fragments no
   larger than the MTU supported by the network layer.  A source
   sequentially and uniquely assigns OD_SQNs to these fragments in the
   order in which they occur in the APDU.  A source then sets
   OPT_FRAG_OFF to the value of the offset of the fragment in the
   original APDU (where the first byte of the APDU is at offset 0, and
   OPT_FRAG_OFF numbers the first byte in the fragment), and set
   OPT_FRAG_LEN to the value of the total length of the original APDU.

9.2.3.  OPT_FRAGMENT - Procedures - Receivers

   Receivers detect and accumulate fragmented packets until they have
   received an entire contiguous sequence of packets comprising an APDU.
   This sequence begins with the fragment bearing OPT_FRAG_OFF of 0, and
   terminates with the fragment whose length added to its OPT_FRAG_OFF
   is OPT_FRAG_LEN.

Top      Up      ToC       Page 44 
9.2.4.  OPT_FRAGMENT - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    First Sequence Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Offset                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x01

   Option Length = 12 octets

   First Sequence Number

      Sequence Number of the PGM DATA/RDATA packet containing the first
      fragment of the APDU.

   Offset

      The byte offset of the fragment from the beginning of the APDU
      (OPT_FRAG_OFF).

   Length

      The total length of the original APDU (OPT_FRAG_LEN).

   OPT_FRAGMENT is NOT network-significant.

9.3.  NAK List Option - OPT_NAK_LIST

   The NAK List option MAY be used in conjunction with NAKs to allow
   receivers to request transmission for more than one sequence number
   with a single NAK packet.  The option is limited to 62 listed NAK
   entries.  The NAK list MUST be unique and duplicate free.  It MUST be
   ordered, and MUST consist of either a list of selective or a list of
   parity NAKs.  In general, network elements, sources and receivers
   must process a NAK list as if they had received individual NAKs for
   each sequence number in the list.  The procedures for each are
   outlined in detail earlier in this document.  Clarifications and
   differences are detailed here.

Top      Up      ToC       Page 45 
9.3.1.  OPT_NAK_LIST - Packet Extensions Contents

   A list of sequence numbers for which retransmission is requested.

9.3.2.  OPT_NAK_LIST - Procedures - Receivers

   Receivers MAY append the NAK List option to a NAK to indicate that
   they wish retransmission of a number of RDATA.

   Receivers SHOULD proceed to back off NAK transmission in a manner
   consistent with the procedures outlined for single sequence number
   NAKs.  Note that the repair of each separate sequence number will be
   completed upon receipt of a separate RDATA packet.

   Reception of an NCF or multicast NAK containing the NAK List option
   suspends generation of NAKs for all sequence numbers within the NAK
   list, as well as the sequence number within the NAK header.

9.3.3.  OPT_NAK_LIST - Procedures - Network Elements

   Network elements MUST immediately respond to a NAK with an identical
   NCF containing the same NAK list as the NAK itself.

   Network elements MUST forward a NAK containing a NAK List option if
   any one sequence number specified by the NAK (including that in the
   main NAK header) is not currently outstanding.  That is, it MUST
   forward the NAK, if any one sequence number does not have an
   elimination timer running for it.  The NAK must be forwarded intact.

   Network elements MUST eliminate a NAK containing the NAK list option
   only if all sequence numbers specified by the NAK (including that in
   the main NAK header) are outstanding.  That is, they are all running
   an elimination timer.

   Upon receipt of an unsolicited NCF containing the NAK list option, a
   network element MUST anticipate data for every sequence number
   specified by the NAK as if it had received an NCF for every sequence
   number specified by the NAK.

9.3.4.  OPT_NAK_LIST - Procedures - Sources

   A source MUST immediately respond to a NAK with an identical NCF
   containing the same NAK list as the NAK itself.

   It MUST then multicast RDATA (while respecting TXW_MAX_RTE) for every
   requested sequence number.

Top      Up      ToC       Page 46 
9.3.5.  OPT_NAK_LIST - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Requested Sequence Number 1                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  .....                                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Requested Sequence Number N                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x02

   Option Length = 4 + (4 * number of SQNs) octets

   Requested Sequence Number

      A list of up to 62 additional sequence numbers to which the NAK
      applies.

   OPT_NAK_LIST is network-significant.

9.4.  Late Joining Option - OPT_JOIN

   Late joining allows a source to bound the amount of repair history
   receivers may request when they initially join a particular transport
   session.

   This option indicates that receivers that join a transport session in
   progress MAY request repair of all data as far back as the given
   minimum sequence number from the time they join the transport
   session.  The default is for receivers to receive data only from the
   first packet they receive and onward.

9.4.1.  OPT_JOIN - Packet Extensions Contents

   OPT_JOIN_MIN   the minimum sequence number for repair

9.4.2.  OPT_JOIN - Procedures - Receivers

   If a PGM packet (ODATA, RDATA, or SPM) bears OPT_JOIN, a receiver MAY
   initialize the trailing edge of the receive window (RXW_TRAIL_INIT)
   to the given Minimum Sequence Number and proceeds with normal data
   reception.

Top      Up      ToC       Page 47 
9.4.3.  OPT_JOIN - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Minimum Sequence Number                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type = 0x03

   Option Length = 8 octets

   Minimum Sequence Number

      The minimum sequence number defining the initial trailing edge of
      the receive window for a late joining receiver.

   OPT_JOIN is NOT network-significant.

9.5.  Redirect Option - OPT_REDIRECT

   Redirection MAY be used by a designated local repairer (DLR) to
   advertise its own address as an alternative to the original source,
   for requesting repairs.

   These procedures allow a PGM Network Element to use a DLR that is one
   PGM hop from it either upstream or downstream in the multicast
   distribution tree.  The former are referred to as upstream DLRs.  The
   latter are referred to as off-tree DLRs.  Off-Tree because even
   though they are downstream of the point of loss, they might not lie
   on the subtree affected by the loss.

   A DLR MUST receive any PGM sessions for which it wishes to provide
   retransmissions.  A DLR SHOULD respond to NCFs or POLLs sourced by
   its PGM parent with a redirecting POLR response packet containing an
   OPT_REDIRECT which provides its own network layer address.
   Recipients of redirecting POLRs MAY then direct NAKs for subsequent
   ODATA sequence numbers to the DLR rather than to the original source.
   In addition, DLRs that receive redirected NAKs for which they have
   RDATA MUST send a NULL NAK to provide flow control to the original
   source without also provoking a repair from that source.

Top      Up      ToC       Page 48 
9.5.1.  OPT_REDIRECT - Packet Extensions Contents

   OPT_REDIR_NLA  the DLR's own unicast network-layer address to which
                  recipients of the redirecting POLR MAY direct
                  subsequent NAKs for the corresponding TSI.

9.5.2.  OPT_REDIRECT - Procedures - DLRs

   A DLR MUST receive any PGM sessions for which it wishes to provide a
   source of repairs.  In addition to acting as an ordinary PGM
   receiver, a DLR MAY then respond to NCFs or relevant POLLs sourced by
   parent network elements (or even by the source itself) by sending a
   POLR containing an OPT_REDIRECT providing its own network-layer
   address.

   If a DLR can provide FEC repairs it MUST denote this by setting
   OPT_PARITY in the PGM header of its POLR response.

9.5.2.1.  Upstream DLRs

   If the NCF completes NAK transmission initiated by the DLR itself,
   the DLR MUST NOT send a redirecting POLR.

   When a DLR receives an NCF from its upstream PGM parent, it SHOULD
   send a redirecting POLR, multicast to the group.  The DLR SHOULD
   record that it is acting as an upstream DLR for the said session.
   Note that this POLR MUST have both the data source's source address
   and the router alert option in its network header.

   An upstream DLR MUST act as an ordinary PGM source in responding to
   any NAK it receives (i.e., directed to it).  That is, it SHOULD
   respond first with a normal NCF and then RDATA as usual.  In
   addition, an upstream DLR that receives redirected NAKs for which it
   has RDATA MUST send a NULL NAK to provide flow control to the
   original source.  If it cannot provide the RDATA it forwards the NAK
   to the upstream PGM neighbor as usual.

      Nota Bene: In order to propagate on exactly the same distribution
      tree as ODATA, RDATA and POLR  packets transmitted by DLRs MUST
      bear the ODATA source's NLA as the network-header source address,
      not the DLR's NLA as might be expected.

Top      Up      ToC       Page 49 
9.5.2.2.  Off-Tree DLRs

   A DLR that receives a POLL with sub-type PGM_POLL_DLR MUST respond
   with a unicast redirecting POLR if it provides the appropriate
   service.  The DLR SHOULD respond using the rules outlined for polling
   in Appendix D of this text.  If the DLR responds, it SHOULD record
   that it is acting as an off-tree DLR for the said session.

   An off-tree DLR acts in a special way in responding to any NAK it
   receives (i.e., directed to it).  It MUST respond to a NAK directed
   to it from its parent by unicasting an NCF and RDATA to its parent.
   The parent will then forward the RDATA down the distribution tree.
   The DLR uses its own and the parent's NLA addresses in the network
   header for the source and destination respectively.  The unicast NCF
   and RDATA packets SHOULD not have the router alert option.  In all
   other ways the RDATA header should be "as if" the packet had come
   from the source.

   Again, an off-tree DLR that receives redirected NAKs for which it has
   RDATA MUST originate a NULL NAK to provide flow control to the
   original source.  It MUST originate the NULL NAK before originating
   the RDATA.  This must be done to reduce the state held in the network
   element.

   If it cannot provide the RDATA for a given NAK, an off-tree DLR
   SHOULD confirm the NAK with a unicast NCF as normal, then immediately
   send a NAK for the said data packet back to its parent.

9.5.2.3.  Simultaneous Upstream and Off-Tree DLR operation

   Note that it is possible for a DLR to provide service to its parent
   and to downstream network elements simultaneously.  A downstream loss
   coupled with a loss for the same data on some other part of the
   distribution tree served by its parent could cause this.  In this
   case it may provide both upstream and off-tree functionality
   simultaneously.

   Note that a DLR differentiates between NAKs from an NE downstream or
   from its parent by comparing the network-header source address of the
   NAK with it's upstream PGM parent's NLA.  The DLR knows the parent's
   NLA from the session's SPM messages.

Top      Up      ToC       Page 50 
9.5.3.  OPT_REDIRECT - Procedures - Network Elements

9.5.3.1.  Discovering DLRs

   When a PGM router receives notification of a loss via a NAK, it
   SHOULD first try to use a known DLR to recover the loss.  If such a
   DLR is not known it SHOULD initiate DLR discovery.  DLR discovery may
   occur in two ways.  If there are upstream DLRs, the NAK transmitted
   by this router to its PGM parent will trigger their discovery, via a
   redirecting POLR.  Also, a network element SHOULD initiate a search
   for off-tree DLRs using the PGM polling mechanism, and the sub-type
   PGM_POLL_DLR.

   If a DLR can provide FEC repairs it will denote this by setting
   OPT_PARITY in the PGM header of its POLR response.  A network element
   SHOULD only direct parity NAKs to a DLR that can provide FEC repairs.

9.5.3.2.  Redirected Repair

   When it can, a network element SHOULD use upstream DLRs.

   Upon receiving a redirecting POLR, network elements SHOULD record the
   redirecting information for the TSI, and SHOULD redirect subsequent
   NAKs for the same TSI to the network address provided in the
   redirecting POLR rather than to the PGM neighbor known via the SPMs.
   Note, however, that a redirecting POLR is NOT regarded as matching
   the NAK that provoked it, so it does not complete the transmission of
   that NAK.  Only a normal matching NCF can complete the transmission
   of a NAK.

   For subsequent NAKs, if the network element has recorded redirection
   information for the corresponding TSI, it MAY change the destination
   network address of those NAKs and attempt to transmit them to the
   DLR.  No NAK for a specific SQN SHOULD be sent to an off-tree DLR if
   a NAK for the SQN has been seen on the interface associated with the
   DLR.  Instead the NAK SHOULD be forwarded upstream.  Subsequent NAKs
   for different SQNs MAY be forwarded to the said DLR (again assuming
   no NAK for them has been seen on the interface to the DLR).

   If a corresponding NCF is not received from the DLR within
   NAK_RPT_IVL, the network element MUST discard the redirecting
   information for the TSI and re-attempt to forward the NAK towards the
   PGM upstream neighbor.

Top      Up      ToC       Page 51 
   If a NAK is received from the DLR for a requested SQN, the network
   element MUST discard the redirecting information for the SQN and re-
   attempt to forward the NAK towards the PGM upstream neighbor.  The
   network element MAY still direct NAKs for different SQNs to the DLR.

   RDATA and NCFs from upstream DLRs will flow down the distribution
   tree.  However, RDATA and NCFs from off-tree DLRs will be unicast to
   the network element.  The network element will terminate the NCF, but
   MUST put the source's NLA and the group address into the network
   header and MUST add router alert before forwarding the RDATA packet
   to the distribution subtree.

   NULL NAKs from an off-tree DLR for an RDATA packet requested from
   that off-tree DLR MUST always be forwarded upstream.  The network
   element can assume that these will arrive before the matching RDATA.
   Other NULL NAKs are forwarded only if matching repair state has not
   already been created.  Network elements MUST NOT confirm or retry
   NULL NAKs and they MUST NOT add the receiving interface to the repair
   state.  If a NULL NAK is used to initially create repair state, this
   fact must be recorded so that any subsequent non-NULL NAK will not be
   eliminated, but rather will be forwarded to provoke an actual repair.
   State created by a NULL NAK exists only for NAK_ELIM_IVL.

9.5.4.  OPT_REDIRECT - Procedures - Receivers

   These procedures are intended to be applied in instances where a
   receiver's first hop router on the reverse path to the source is not
   a PGM Network Element.  So, receivers MUST ignore a redirecting POLR
   from a DLR on the same IP subnet that the receiver resides on, since
   this is likely to suffer identical loss to the receiver and so be
   useless.  Therefore, these procedures are entirely OPTIONAL.  A
   receiver MAY choose to ignore all redirecting POLRs since in cases
   where its first hop router on the reverse path is PGM capable, it
   would ignore them anyway.  Also, note that receivers will never learn
   of off-tree DLRs.

   Upon receiving a redirecting POLR, receivers SHOULD record the
   redirecting information for the TSI, and MAY redirect subsequent NAKs
   for the same TSI to the network address provided in the redirecting
   POLR rather than to the PGM neighbor for the corresponding ODATA for
   which the receiver is requesting repair.  Note, however, that a
   redirecting POLR is NOT regarded as matching the NAK that provoked
   it, so it does not complete the transmission of that NAK.  Only a
   normal matching NCF can complete the transmission of a NAK.

   For subsequent NAKs, if the receiver has recorded redirection
   information for the corresponding TSI, it MAY change the destination
   network address of those NAKs and attempt to transmit them to the

Top      Up      ToC       Page 52 
   DLR.  If a corresponding NCF is not received within NAK_RPT_IVL, the
   receiver MUST discard the redirecting information for the TSI and
   re-attempt to forward the NAK to the PGM neighbor for the original
   source of the missing ODATA.

9.5.5.  OPT_REDIRECT - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            NLA AFI            |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           DLR's NLA                     ...   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+

   Option Type = 0x07

   Option Length = 4 + NLA length

   DLR's NLA

      The DLR's own unicast network address to which recipients of the
      redirecting POLR may direct subsequent NAKs.

   OPT_REDIRECT is network-significant.

9.6.  OPT_SYN - Synchronization Option

   The SYN option indicates the starting data packet for a session.  It
   must only appear in ODATA or RDATA packets.

   The SYN option MAY be used to provide a useful abstraction to
   applications that can simplify application design by providing stream
   start notification.  It MAY also be used to let a late joiner to a
   session know that it is indeed late (i.e. it would not see the SYN
   option).

9.6.1.  OPT_SYN - Procedures - Receivers

   Procedures for receivers are implementation dependent.  A receiver
   MAY use the SYN to provide its applications with abstractions of the
   data stream.

Top      Up      ToC       Page 53 
9.6.2.  OPT_SYN - Procedures - Sources

   Sources MAY include OPT_SYN in the first data for a session.  That
   is, they MAY include the option in:

      the first ODATA sent on a session by a PGM source

      any RDATA sent as a result of loss of this ODATA packet

      all FEC packets for the first transmission group; in this case it
      is interpreted as the first packet having the SYN

9.6.3.  OPT_SYN - Procedures - DLRs

      In an identical manner to sources, DLRs MUST provide OPT_SYN in
      any retransmitted data that is at the start of a session.

9.6.4.  OPT_SYN - Packet Extension 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |E| Option Type | Option Length |Reserved |F|OPX|U|             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Option Type = 0x0D

      Option Length = 4

      OPT_SYN is NOT network-significant.

9.7.  OPT_FIN - Session Finish Option

      This FIN option indicates the last data packet for a session and
      an orderly close down.

      The FIN option MAY be used to provide an abstraction to
      applications that can simplify application design by providing
      stream end notification.

      This option MAY be present in the last data packet or transmission
      group for a session.  The FIN PGM option MUST appear in every SPM
      sent after the last ODATA for a session.  The SPM_LEAD sequence
      number in an SPM with the FIN option indicates the last known data
      successfully transmitted for the session.

Top      Up      ToC       Page 54 
9.7.1.  OPT_FIN - Procedures - Receivers

      A receiver SHOULD use receipt of a FIN to let it know that it can
      tear down its data structures for the said session once a suitable
      time period has expired (TXW_SECS).  It MAY still try to solicit
      retransmissions within the existing transmit window.

      Other than this, procedures for receivers are implementation
      dependent.  A receiver MAY use the FIN to provide its applications
      with abstractions of the data stream and to inform its
      applications that the session is ending.

      9.7.2.  OPT_FIN - Procedures - Sources

      Sources MUST include OPT_FIN in every SPM sent after it has been
      determined that the application has closed gracefully.  If a
      source is aware at the time of transmission that it is ending a
      session the source MAY include OPT_FIN in,

      the last ODATA

      any associated RDATAs for the last data

      FEC packets for the last transmission group; in this case it is
      interpreted as the last packet having the FIN

   When a source detects that it needs to send an OPT_FIN it SHOULD
   immediately send it.  This is done either by appending it to the last
   data packet or transmission group or by immediately sending an SPM
   and resetting the SPM heartbeat timer (i.e. it does not wait for a
   timer to expire before sending the SPM).  After sending an OPT_FIN,
   the session SHOULD not close and stop sending SPMs until after a time
   period equal to TXW_SECS.

9.7.3.  OPT_FIN - Procedures - DLRs

   In an identical manner to sources, DLRs MUST provide OPT_FIN in any
   retransmitted data that is at the end of a session.

Top      Up      ToC       Page 55 
9.7.4.  OPT_FIN - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x0E

   Option Length = 4

   OPT_FIN is NOT network-significant.

9.8.  OPT_RST - Session Reset Option

   The RST option MAY appear in every SPM sent after an unrecoverable
   error is identified by the source.  This acts to notify the receivers
   that the session is being aborted.  This option MAY appear only in
   SPMs.  The SPM_LEAD sequence number in an SPM with the RST option
   indicates the last known data successfully transmitted for the
   session.

9.8.1.  OPT_RST - Procedures - Receivers

   Receivers SHOULD treat the reception of OPT_RST in an SPM as an abort
   of the session.

   A receiver that receives an SPM with an OPT_RST with the N bit set
   SHOULD not send any more NAKs for the said session towards the
   source.  If the N bit (see 9.8.5) is not set, the receiver MAY
   continue to try to solicit retransmit data within the current
   transmit window.

9.8.2.  OPT_RST - Procedures - Sources

   Sources SHOULD include OPT_RST in every SPM sent after it has been
   determined that an unrecoverable error condition has occurred.  The N
   bit of the OPT_RST SHOULD only be sent if the source has determined
   that it cannot process NAKs for the session.  The cause of the
   OPT_RST is set to an implementation specific value.  If the error
   code is unknown, then the value of 0x00 is used.  When a source
   detects that it needs to send an OPT_RST it SHOULD immediately send
   it.  This is done by immediately sending an SPM and resetting the SPM
   heartbeat timer (i.e. it does not wait for a timer to expire before
   sending the SPM).  After sending an OPT_RST, the session SHOULD not
   close and stop sending SPMs until after a time period equal to
   TXW_SECS.

Top      Up      ToC       Page 56 
9.8.3.  OPT_RST - Procedures - DLRs

   None.

9.8.4.  OPT_RST - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|N|Error Code |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x0F

   Option Length = 4

   N bit

      The N bit is set to 1 to indicate that NAKs for previous ODATA
      will go unanswered from the source.  The application will tell the
      source to turn this bit on or off.

   Error Code

      The 6 bit error code field is used to forward an error code down
      to the receivers from the source.

      The value of 0x00 indicates an unknown reset reason.  Any other
      value indicates the application purposely aborted and gave a
      reason (the error code value) that may have meaning to the end
      receiver application.  These values are entirely application
      dependent.

   OPT_RST is NOT network-significant.

10.  Security Considerations

   In addition to the usual problems of end-to-end authentication, PGM
   is vulnerable to a number of security risks that are specific to the
   mechanisms it uses to establish source path state, to establish
   repair state, to forward NAKs, to identify DLRs, and to distribute
   repairs.  These mechanisms expose PGM network elements themselves to
   security risks since network elements not only switch but also
   interpret SPMs, NAKs, NCFs, and RDATA, all of which may legitimately
   be transmitted by PGM sources, receivers, and DLRs.  Short of full
   authentication of all neighboring sources, receivers, DLRs, and
   network elements, the protocol is not impervious to abuse.

Top      Up      ToC       Page 57 
   So putting aside the problems of rogue PGM network elements for the
   moment, there are enough potential security risks to network elements
   associated with sources, receivers, and DLRs alone.  These risks
   include denial of service through the exhausting of both CPU
   bandwidth and memory, as well as loss of (repair) data connectivity
   through the muddling of repair state.

   False SPMs may cause PGM network elements to mis-direct NAKs intended
   for the legitimate source with the result that the requested RDATA
   would not be forthcoming.

   False NAKs may cause PGM network elements to establish spurious
   repair state that will expire only upon time-out and could lead to
   memory exhaustion in the meantime.

   False NCFs may cause PGM network elements to suspend NAK forwarding
   prematurely (or to mis-direct NAKs in the case of redirecting POLRs)
   resulting eventually in loss of RDATA.

   False RDATA may cause PGM network elements to tear down legitimate
   repair state resulting eventually in loss of legitimate RDATA.

   The development of precautions for network elements to protect
   themselves against incidental or unsophisticated versions of these
   attacks is work outside of this spec and includes:

      Damping of jitter in the value of either the network-header source
      address of SPMs or the path NLA in SPMs.  While the network-header
      source address is expected to change seldom, the path NLA is
      expected to change occasionally as a consequence of changes in
      underlying multicast routing information.

   The extension of NAK shedding procedures to control the volume, not
   just the rate, of confirmed NAKs.  In either case, these procedures
   assist network elements in surviving NAK attacks at the expense of
   maintaining service.  More efficiently, network elements may use the
   knowledge of TSIs and their associated transmit windows gleaned from
   SPMs to control the proliferation of repair state.

   A three-way handshake between network elements and DLRs that would
   permit a network element to ascertain with greater confidence that an
   alleged DLR is identified by the alleged network-header source
   address, and is PGM conversant.

Top      Up      ToC       Page 58 
11.  Appendix A - Forward Error Correction

11.1.  Introduction

   The following procedures incorporate packet-level Reed Solomon
   Erasure correcting techniques as described in [11] and [12] into PGM.
   This approach to Forward Error Correction (FEC) is based upon the
   computation of h parity packets from k data packets for a total of n
   packets such that a receiver can reconstruct the k data packets out
   of any k of the n packets.  The original k data packets are referred
   to as the Transmission Group, and the total n packets as the FEC
   Block.

   These procedures permit any combination of pro-active FEC or on-
   demand FEC with conventional ARQ (selective retransmission) within a
   given TSI to provide any flavor of layered or integrated FEC.  The
   two approaches can be used by the same or different receivers in a
   single transport session without conflict.  Once provided by a
   source, the actual use of FEC or selective retransmission for loss
   recovery in the session is entirely at the discretion of the
   receivers.  Note however that receivers SHOULD NOT ask for selective
   retransmissions when FEC is available, nevertheless sources MUST
   provide selective retransmissions in response to selective NAKs from
   the leading partial transmission group (i.e. the most recent
   transmission group, which is not yet full).  For any group that is
   full, the source SHOULD provide FEC on demand in response to a
   selective NAK.

   Pro-active FEC refers to the technique of computing parity packets at
   transmission time and transmitting them as a matter of course
   following the data packets.  Pro-active FEC is RECOMMENDED for
   providing loss recovery over simplex or asymmetric multicast channels
   over which returning repair requests is either impossible or costly.
   It provides increased reliability at the expense of bandwidth.

   On-demand FEC refers to the technique of computing parity packets at
   repair time and transmitting them only upon demand (i.e., receiver-
   based loss detection and repair request).  On-demand FEC is
   RECOMMENDED for providing loss recovery of uncorrelated loss in very
   large receiver populations in which the probability of any single
   packet being lost is substantial.  It provides equivalent reliability
   to selective NAKs (ARQ) at no more and typically less expense of
   bandwidth.

   Selective NAKs are NAKs that request the retransmission of specific
   packets by sequence number corresponding to the sequence number of
   any data packets detected to be missing from the expected sequence
   (conventional ARQ).  Selective NAKs can be used for recovering losses

Top      Up      ToC       Page 59 
   occurring in leading partial transmission groups, i.e. in the most
   recent transmission group, which is not yet full.  The RECOMMENDED
   way of handling partial transmission groups, however, is for the data
   source to use variable-size transmission groups (see below).

   Parity NAKs are NAKs that request the transmission of a specific
   number of parity packets by count corresponding to the count of the
   number of data packets detected to be missing from a group of k data
   packets (on-demand FEC).

   The objective of these procedures is to incorporate these FEC
   techniques into PGM so that:

      sources MAY provide parity packets either pro-actively or on-
      demand, interchangeably within the same TSI,

      receivers MAY use either selective or parity NAKs interchangeably
      within the same TSI (however, in a session where on-demand parity
      is available receivers SHOULD only use parity NAKs).

      network elements maintain repair state based on either selective
      or parity NAKs in the same data structure, altering only search,
      RDATA constraint, and deletion algorithms in either case,

      and only OPTION additions to the basic packet formats are
      REQUIRED.

11.2.  Overview

   Advertising FEC parameters in the transport session

   Sources add OPT_PARITY_PRM to SPMs to provide session-specific
   parameters such as the number of packets (TGSIZE == k) in a
   transmission group.  This option lets receivers know how many packets
   there are in a transmission group, and it lets network elements sort
   repair state by transmission group number.  This option includes an
   indication of whether pro-active and/or on-demand parity is available
   from the source.

   Distinguishing parity packets from data packets

   Sources send pro-active parity packets as ODATA (NEs do not forward
   RDATA unless a repair state is present) and on-demand parity packets
   as RDATA.  A source MUST add OPT_PARITY to the ODATA/RDATA packet
   header of parity packets to permit network elements and receivers to
   distinguish them from data packets.

Top      Up      ToC       Page 60 
   Data and parity packet numbering

   Parity packets MUST be calculated over a fixed number k of data
   packets known as the Transmission Group.  Grouping of packets into
   transmission groups effectively partitions a packet sequence number
   into a high-order portion (TG_SQN) specifying the transmission group
   (TG), and a low-order portion (PKT_SQN) specifying the packet number
   (PKT-NUM in the range 0 through k-1) within that group.  From an
   implementation point of view, it's handy if k, the TG size, is a
   power of 2.  If so, then TG_SQN and PKT_SQN can be mapped side-by-
   side into the 32 bit SQN.  log2(TGSIZE) is then the size in bits of
   PKT_SQN.

   This mapping does not reduce the effective sequence number space
   since parity packets marked with OPT_PARITY allow the sequence space
   (PKT_SQN) to be completely reused in order to number the h parity
   packets, as long as h is not greater than k.

   In the case where h is greater than k, a source MUST add
   OPT_PARITY_GRP to any parity packet numbered j greater than k-1,
   specifying the number m of the group of k parity packets to which the
   packet belongs, where m is just the quotient from the integer
   division of j by k.  Correspondingly, PKT-NUM for such parity packets
   is just j modulo k.  In other words, when a source needs to generate
   more parity packets than there were original data packets (perhaps
   because of a particularly lossy line such that a receiver lost not
   only the original data but some of the parity RDATA as well), use the
   OPT_PARITY_GRP option in order to number and identify the
   transmission group of the extra packets that would exceed the normal
   sequential number space.

   Note that parity NAKs (and consequently their corresponding parity
   NCFs) MUST also contain the OPT_PARITY flag in the options field of
   the fixed header, and that in these packets, PKT_SQN MUST contain
   PKT_CNT, the number of missing packets, rather than PKT_NUM, the SQN
   of a specific missing packet.  More on all this later.

   Variable Transmission Group Size

   The transmission group size advertised in the OPT_PARITY_PRM option
   on SPMs MUST be a power of 2 and constant for the duration of the
   session.  However, the actual transmission group size used MAY not be
   constant for the duration of the session, and MAY not be a power of
   2.  When a TG size different from the one advertised in
   OPT_PARITY_PRM is used, the TG size advertised in OPT_PARITY_PRM MUST
   be interpreted as specifying the maximum effective size of the TG.

Top      Up      ToC       Page 61 
   When the actual TG size is not a power of 2 or is smaller than the
   max TG size, there will be sparse utilization of the sequence number
   space since some of the sequence numbers that would have been
   consumed in numbering a maximum sized TG will not be assigned to
   packets in the smaller TG.  The start of the next transmission group
   will always begin on the boundary of the maximum TG size as though
   each of the sequence numbers had been utilized.

   When the source decides to use a smaller group size than that
   advertised in OPT_PARITY_PRM, it appends OPT_CURR_TGSIZE to the last
   data packet (ODATA) in the truncated transmission group.  This lets
   the receiver know that it should not expect any more packets in this
   transmission group, and that it may start requesting repairs for any
   missing packets.  If the last data packet itself went missing, the
   receiver will detect the end of the group when it receives a parity
   packet for the group, an SPM with SPM_LEAD equal to OD_SQN of the
   last data packet, or the first packet of the next group, whichever
   comes first.  In addition, any parity packet from this TG will also
   carry the OPT_CURR_TGSIZE option as will any SPM sent with SPM_LEAD
   equal to OD_SQN of the last data packet.

   Variable TSDU length

   If a non constant TSDU length is used within a given transmission
   group, the size of parity packets in the corresponding FEC block MUST
   be equal to the size of the largest original data packet in the
   block.  Parity packets MUST be computed by padding the original
   packets with zeros up to the size of the largest data packet.  Note
   that original data packets are transmitted without padding.

   Receivers using a combination of original packets and FEC packets to
   rebuild missing packets MUST pad the original packets in the same way
   as the source does.  The receiver MUST then feed the padded original
   packets plus the parity packets to the FEC decoder.  The decoder
   produces the original packets padded with zeros up to the size of the
   largest original packet in the group.  In order for the receiver to
   eliminate the padding on the reconstructed data packets, the original
   size of the packet MUST be known, and this is accomplished as
   follows:

      The source, along with the packet payloads, encodes the TSDU
      length and appends the 2-byte encoded length to the padded FEC
      packets.

      Receivers pad the original packets that they received to the
      largest original packet size and then append the TSDU length to
      the padded packets.  They then pass them and the FEC packets to
      the FEC decoder.

Top      Up      ToC       Page 62 
      The decoder produces padded original packets with their original
      TSDU length appended.  Receivers MUST now use this length to get
      rid of the padding.

   A source that transmits variable size packets MUST take into account
   the fact that FEC packets will have a size equal to the maximum size
   of the original packets plus the size of the length field (2 bytes).

   If a fixed packet size is used within a transmission group, the
   encoded length is not appended to the parity packets.  The presence
   of the fixed header option flag OPT_VAR_PKTLEN in parity packets
   allows receivers to distinguish between transmission groups with
   variable sized packets and fixed-size ones, and behave accordingly.

   Payload-specific options

   Some options present in data packet (ODATA and RDATA) are strictly
   associated with the packet content (PGM payload), OPT_FRAGMENT being
   an example.  These options must be preserved even when the data
   packet that would normally contain them is not received, but its the
   payload is recovered though the use of FEC.

   To achieve this, PGM encodes the content of these options in special
   options that are inserted in parity packets.  Two flags present in
   the the option common-header are used for this process:  bit F
   (OP_ENCODED) and bit U (OP_ENCODED_NULL).

   Whenever at least one of the original packets of a TG contains a
   payload-specific option of a given type, the source MUST include an
   encoded version of that option type in all the parity packets it
   transmits.  The encoded option is computed by applying FEC encoding
   to the whole option with the exception of the first three bytes of
   the option common-header (E, Option Type, Option Length, OP_ENCODED
   and OPX fields).  The type, length and OPX of the encoded option are
   the same as the type, length and OPX in the original options.
   OP_ENCODED is set to 1 (all original option have OP_ENCODED = 0).

   The encoding is performed using the same process that is used to
   compute the payload of the parity packet. i.e. the FEC encoder is fed
   with one copy of that option type for each original packet in the TG.
   If one (or more) original packet of the TG does not contain that
   option type, an all zeroes option is used for the encoding process.
   To be able to distinguish this "dummy" option from valid options with
   all-zeroes payload, OP_ENCODED_NULL is used.  OP_ENCODED_NULL is set
   to 0 in all the original options, but the value of 1 is used in the
   encoding process if the option did not exist in the original packet.
   On the receiver side, all option with OP_ENCODED_NULL equal to 1 are
   discarded after decoding.

Top      Up      ToC       Page 63 
   When a receiver recovers a missing packet using FEC repair packets,
   it MUST also recover payload-specific options, if any.  The presence
   of these can be unequivocally detected through the presence of
   encoded options in parity packets (encoded options have OP_ENCODED
   set to 1).  Receivers apply FEC-recovery to encoded options and
   possibly original options, as they do to recover packet payloads.
   The FEC decoding is applied to the whole option with the exception of
   the first three bytes of the option common-header (E, Option Type,
   Option Length, OP_ENCODED and OPX fields).  Each decoded option is
   associated with the relative payload, unless OP_ENCODED_NULL turns
   out to be 1, in which case the decoded option is discarded.

   The decoding MUST be performed using the 1st occurrence of a given
   option type in original/parity packets.  If one or more original
   packets do not contain that option type, an option of the same type
   with zero value must be used.  This option MUST have OP_ENCODED_NULL
   equal to 1.

11.3.  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.

   OPT_PARITY        indicated in pro-active (ODATA) and on-demand
                     (RDATA) parity packets to distinguish them from
                     data packets.  This option is directly encoded in
                     the "Option" field of the fixed PGM header

   OPT_VAR_PKTLEN    MAY be present in pro-active (ODATA) and on-demand
                     (RDATA) parity packets to indicate that the
                     corresponding transmission group is composed of
                     variable size data packets.  This option is
                     directly encoded in the "Option" field of the fixed
                     PGM header

   OPT_PARITY_PRM    appended by sources to SPMs to specify session-
                     specific parameters such as the transmission group
                     size and the availability of pro-active and/or on-
                     demand parity from the source

   OPT_PARITY_GRP    the number of the group (greater than 0) of h
                     parity packets to which the parity packet belongs
                     when more than k parity packets are provided by the
                     source

Top      Up      ToC       Page 64 
   OPT_CURR_TGSIZE   appended by sources to the last data packet and any
                     parity packets in a variable sized transmission
                     group to indicate to the receiver the actual size
                     of a transmission group.  May also be appended to
                     certain SPMs

11.3.1.  Parity NAKs

   NAK_TG_SQN        the high-order portion of NAK_SQN specifying the
                     transmission group for which parity packets are
                     requested

   NAK_PKT_CNT       the low-order portion of NAK_SQN specifying the
                     number of missing data packets for which parity
                     packets are requested

      Nota Bene: NAK_PKT_CNT (and NCF_PKT_CNT) are 0-based counters,
      meaning that NAK_PKT_CNT = 0 means that 1 FEC RDATA is being
      requested, and in general NAK_PKT_CNT = k - 1 means that  k FEC
      RDATA are being requested.

11.3.2.  Parity NCFs

   NCF_TG_SQN        the high-order portion of NCF_SQN specifying the
                     transmission group for which parity packets were
                     requested

   NCF_PKT_CNT       the low-order portion of NCF_SQN specifying the
                     number of missing data packets for which parity
                     packets were requested

      Nota Bene: NCF_PKT_CNT (and NAK_PKT_CNT) are 0-based counters,
      meaning that NAK_PKT_CNT = 0 means that 1 FEC RDATA is being
      requested, and in general NAK_PKT_CNT = k - 1 means that  k FEC
      RDATA are being requested.

11.3.3.  On-demand Parity

   RDATA_TG_SQN      the high-order portion of RDATA_SQN specifying the
                     transmission group to which the parity packet
                     belongs

   RDATA_PKT_SQN     the low-order portion of RDATA_SQN specifying the
                     parity packet sequence number within the
                     transmission group

Top      Up      ToC       Page 65 
11.3.4.  Pro-active Parity

   ODATA_TG_SQN      the high-order portion of ODATA_SQN specifying the
                     transmission group to which the parity packet
                     belongs

   ODATA_PKT_SQN     the low-order portion of ODATA_SQN specifying the
                     parity packet sequence number within the
                     transmission group

11.4.  Procedures - Sources

   If a source elects to provide parity for a given transport session,
   it MUST first provide the transmission group size PARITY_PRM_TGS in
   the OPT_PARITY_PRM option of its SPMs.  This becomes the maximum
   effective transmission group size in the event that the source elects
   to send smaller size transmission groups.  If a source elects to
   provide proactive parity for a given transport session, it MUST set
   PARITY_PRM_PRO in the OPT_PARITY_PRM option of its SPMs.  If a source
   elects to provide on-demand parity for a given transport session, it
   MUST set PARITY_PRM_OND in the OPT_PARITY_PRM option of its SPMs.

   A source MUST send any pro-active parity packets for a given
   transmission group only after it has first sent all of the
   corresponding k data packets in that group.  Pro-active parity
   packets MUST be sent as ODATA with OPT_PARITY in the fixed header.

   If a source elects to provide on-demand parity, it MUST respond to a
   parity NAK for a transmission group with a parity NCF.  The source
   MUST complete the transmission of the k original data packets and the
   proactive parity packets, possibly scheduled, before starting the
   transmission of on-demand parity packets.  Subsequently, the source
   MUST send the number of parity packets requested by that parity NAK.
   On-demand parity packets MUST be sent as RDATA with OPT_PARITY in the
   fixed header.  Previously transmitted pro-active parity packets
   cannot be reused as on-demand parity packets, these MUST be computed
   with new, previously unused, indexes.

   In either case, the source MUST provide selective retransmissions
   only in response to selective NAKs from the leading partial
   transmission group.  For any group that is full, the source SHOULD
   provide FEC on demand in response to a selective retransmission
   request.

   In the absence of data to transmit, a source SHOULD prematurely
   terminate the current transmission group by including OPT_CURR_TGSIZE
   to the last data packet or to any proactive parity packets provided.

Top      Up      ToC       Page 66 
   If the last data packet has already been transmitted and there is no
   provision for sending proactive parity packets, an SPM with
   OPT_CURR_TGSIZE SHOULD be sent.

   A source consolidates requests for on-demand parity in the same
   transmission group according to the following procedures.  If the
   number of pending (i.e., unsent) parity packets from a previous
   request for on-demand parity packets is equal to or greater than
   NAK_PKT_CNT in a subsequent NAK, that subsequent NAK MUST be
   confirmed but MAY otherwise be ignored.  If the number of pending
   (i.e., unsent) parity packets from a previous request for on-demand
   parity packets is less than NAK_PKT_CNT in a subsequent NAK, that
   subsequent NAK MUST be confirmed but the source need only increase
   the number of pending parity packets to NAK_PKT_CNT.

   When a source provides parity packets relative to a transmission
   group with variable sized packets, it MUST compute parity packets by
   padding the smaller original packets with zeroes out to the size of
   the largest of the original packets.  The source MUST also append the
   encoded TSDU lengths at the end of any padding or directly to the end
   of the largest packet, and add the OPT_VAR_PKTLEN option as specified
   in the overview description.

   When a source provides variable sized transmission groups, it SHOULD
   append the OPT_CURR_TGSIZE option to the last data packet in the
   shortened group, and it MUST append the OPT_CURR_TGSIZE option to any
   parity packets it sends within that group.  In case the the last data
   packet is sent before a determination has been made to shorten the
   group and there is no provision for sending proactive parity packets,
   an SPM with OPT_CURR_TGSIZE SHOULD be sent.  The source MUST also add
   OPT_CURR_TGSIZE to any SPM that it sends with SPM_LEAD equal to
   OD_SQN of the last data packet.

   A receiver MUST NAK for the entire number of packets missing based on
   the maximum TG size, even if it already knows that the actual TG size
   is smaller.  The source MUST take this into account and compute the
   number of packets effectively needed as the difference between
   NAK_PKT_CNT and an offset computed as the difference between the max
   TG size and the effective TG size.

11.5.  Procedures - Receivers

   If a receiver elects to make use of parity packets for loss recovery,
   it MUST first learn the transmission group size PARITY_PRM_TGS from
   OPT_PARITY_PRM in the SPMs for the TSI.  The transmission group size
   is used by a receiver to determine the sequence number boundaries
   between transmission groups.

Top      Up      ToC       Page 67 
   Thereafter, if PARITY_PRM_PRO is also set in the SPMs for the TSI, a
   receiver SHOULD use any pro-active parity packets it receives for
   loss recovery, and if PARITY_PRM_OND is also set in the SPMs for the
   TSI, it MAY solicit on-demand parity packets upon loss detection.  If
   PARITY_PRM_OND is set, a receiver MUST NOT send selective NAKs,
   except in partial transmission groups if the source does not use the
   variable transmission-group size option.  Parity packets are ODATA
   (pro-active) or RDATA (on-demand) packets distinguished by OPT_PARITY
   which lets receivers know that ODATA/RDATA_TG_SQN identifies the
   group of PARITY_PRM_TGS packets to which the parity may be applied
   for loss recovery in the corresponding transmission group, and that
   ODATA/RDATA_PKT_SQN is being reused to number the parity packets
   within that group.  Receivers order parity packets and eliminate
   duplicates within a transmission group based on ODATA/RDATA_PKT_SQN
   and on OPT_PARITY_GRP if present.

   To solicit on-demand parity packets, a receiver MUST send parity NAKs
   upon loss detection.  For the purposes of soliciting on-demand
   parity, loss detection occurs at transmission group boundaries, i.e.
   upon receipt of the last data packet in a transmission group, upon
   receipt of any data packet in any subsequent transmission group, or
   upon receipt of any parity packet in the current or a subsequent
   transmission group.

   A parity NAK is simply a NAK with OPT_PARITY and NAK_PKT_CNT set to
   the count of the number of packets detected to be missing from the
   transmission group specified by NAK_TG_SQN.  Note that this
   constrains the receiver to request no more parity packets than there
   are data packets in the transmission group.

   A receiver SHOULD bias the value of NAK_BO_IVL for parity NAKs
   inversely proportional to NAK_PKT_CNT so that NAKs for larger losses
   are likely to be scheduled ahead of NAKs for smaller losses in the
   same receiver population.

   A confirming NCF for a parity NAK is a parity NCF with NCF_PKT_CNT
   equal to or greater than that specified by the parity NAK.

   A receiver's NAK_RDATA_IVL timer is not cancelled until all requested
   parity packets have been received.

   In the absence of data (detected from SPMs bearing SPM_LEAD equal to
   RXW_LEAD) on non-transmission-group boundaries, receivers MAY resort
   to selective NAKs for any missing packets in that partial
   transmission group.

Top      Up      ToC       Page 68 
   When a receiver handles parity packets belonging to a transmission
   group with variable sized packets, (detected from the presence of the
   OPT_VAR_PKTLEN option in the parity packets), it MUST decode them as
   specified in the overview description and use the decoded TSDU length
   to get rid of the padding in the decoded packet.

   If the source was using a variable sized transmission group via the
   OPT_CURR_TGSIZE, the receiver might learn this before having
   requested (and received) any retransmission.  The above happens if it
   sees OPT_CURR_TGSIZE in the last data packet of the TG, in any
   proactive parity packet or in a SPM.  If the receivers learns this
   and determines that it has missed one or more packets in the
   shortened transmission group, it MAY then NAK for them without
   waiting for the start of the next transmission group.  Otherwise it
   will start NAKing at the start of the next transmission group.

   In both cases, the receiver MUST NAK for the number of packets
   missing assuming that the size of the transmission group is the
   maximum effective transmission group.  In other words, the receivers
   cannot exploit the fact that it might already know that the
   transmission group was smaller but MUST always NAK for the number of
   packets it believes are missing, plus the number of packets required
   to bring the total packets up to the maximum effective transmission
   group size.

   After the first parity packet has been delivered to the receiver, the
   actual TG size is known to him, either because already known or
   because discovered via OPT_CURR_TGSIZE contained in the parity
   packet.  Hence the receiver can decode the whole group as soon as the
   minimum number of parity packets needed is received.

11.6.  Procedures - Network Elements

   Pro-active parity packets (ODATA with OPT_PARITY) are switched by
   network elements without transport-layer intervention.

   On-demand parity packets (RDATA with OPT_PARITY) necessitate modified
   request, confirmation and repair constraint procedures for network
   elements.  In the context of these procedures, repair state is
   maintained per NAK_TSI and NAK_TG_SQN, and in addition to recording
   the interfaces on which corresponding NAKs have been received,
   records the largest value of NAK_PKT_CNT seen in corresponding NAKs
   on each interface.  This value is referred to as the known packet
   count.  The largest of the known packet counts recorded for any
   interface in the repair state for the transmit group or carried by an
   NCF is referred to as the largest known packet count.

Top      Up      ToC       Page 69 
   Upon receipt of a parity NAK, a network element responds with the
   corresponding parity NCF.  The corresponding parity NCF is just an
   NCF formed in the usual way (i.e., a multicast copy of the NAK with
   the packet type changed), but with the addition of OPT_PARITY and
   with NCF_PKT_CNT set to the larger of NAK_PKT_CNT and the known
   packet count for the receiving interface.  The network element then
   creates repair state in the usual way with the following
   modifications.

   If repair state for the receiving interface does not exist, the
   network element MUST create it and additionally record NAK_PKT_CNT
   from the parity NAK as the known packet count for the receiving
   interface.

   If repair state for the receiving interface already exists, the
   network element MUST eliminate the NAK only if NAK_ELIM_IVL has not
   expired and NAK_PKT_CNT is equal to or less than the largest known
   packet count.  If NAK_PKT_CNT is greater than the known packet count
   for the receiving interface, the network element MUST update the
   latter with the larger NAK_PKT_CNT.

   Upon either adding a new interface or updating the known packet count
   for an existing interface, the network element MUST determine if
   NAK_PKT_CNT is greater than the largest known packet count.  If so or
   if NAK_ELIM_IVL has expired, the network element MUST forward the
   parity NAK in the usual way with a value of NAK_PKT_CNT equal to the
   largest known packet count.

   Upon receipt of an on-demand parity packet, a network element MUST
   locate existing repair state for the corresponding RDATA_TSI and
   RDATA_TG_SQN.  If no such repair state exists, the network element
   MUST discard the RDATA as usual.

   If corresponding repair state exists, the largest known packet count
   MUST be decremented by one, then the network element MUST forward the
   RDATA on all interfaces in the existing repair state, and decrement
   the known packet count by one for each.  Any interfaces whose known
   packet count is thereby reduced to zero MUST be deleted from the
   repair state.  If the number of interfaces is thereby reduced to
   zero, the repair state itself MUST be deleted.

   Upon reception of a parity NCF, network elements MUST cancel pending
   NAK retransmission only if NCF_PKT_CNT is greater or equal to the
   largest known packet count.  Network elements MUST use parity NCFs to
   anticipate NAKs in the usual way with the addition of recording
   NCF_PKT_CNT from the parity NCF as the largest known packet count
   with the anticipated state so that any subsequent NAKs received with
   NAK_PKT_CNT equal to or less than NCF_PKT_CNT will be eliminated, and

Top      Up      ToC       Page 70 
   any with NAK_PKT_CNT greater than NCF_PKT_CNT will be forwarded.
   Network elements which receive  a parity NCF with NCF_PKT_CNT larger
   than the largest known packet count MUST also use it to anticipate
   NAKs, increasing the largest known packet count to reflect
   NCF_PKT_CNT (partial anticipation).

   Parity NNAKs follow the usual elimination procedures with the
   exception that NNAKs are eliminated only if existing NAK state has a
   NAK_PKT_CNT greater than NNAK_PKT_CNT.

   Network elements must take extra precaution when the source is using
   a variable sized transmission group.  Network elements learn that the
   source is using a TG size smaller than the maximum from
   OPT_CURR_TGSIZE in parity RDATAs or in SPMs.  When this happens, they
   compute a TG size offset as the difference between the maximum TG
   size and the actual TG size advertised by OPT_CURR_TGSIZE.  Upon
   reception of parity RDATA, the TG size offset is used to update the
   repair state as follows:

      Any interface whose known packet count is reduced to the TG size
      offset is deleted from the repair state.

   This replaces the normal rule for deleting interfaces that applies
   when the TG size is equal to the maximum TG size.

11.7.  Procedures - DLRs

   A DLR with the ability to provide FEC repairs MUST indicate this by
   setting the OPT_PARITY bit in the redirecting POLR.  It MUST then
   process any redirected FEC NAKs in the usual way.

11.8.  Packet Formats

11.8.1.  OPT_PARITY_PRM - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|         |P O|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Transmission Group Size                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x08

   Option Length = 8 octets

   P-bit (PARITY_PRM_PRO)

Top      Up      ToC       Page 71 
      Indicates when set that the source is providing pro-active parity
      packets.

   O-bit (PARITY_PRM_OND)

      Indicates when set that the source is providing on-demand parity
      packets.

   At least one of PARITY_PRM_PRO and PARITY_PRM_OND MUST be set.

   Transmission Group Size (PARITY_PRM_TGS)

      The number of data packets in the transmission group over which
      the parity packets are calculated.  If a variable transmission
      group size is being used, then this becomes the maximum effective
      transmission group size across the session.

   OPT_PARITY_PRM MAY be appended only to SPMs.

   OPT_PARITY_PRM is network-significant.

11.8.2.  OPT_PARITY_GRP - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Parity Group Number                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x09

   Option Length = 8 octets

   Parity Group Number (PRM_GROUP)

      The number of the group of k parity packets amongst the h parity
      packets within the transmission group to which the parity packet
      belongs, where the first k parity packets are in group zero.
      PRM_GROUP MUST NOT be zero.

   OPT_PARITY_GRP MAY be appended only to parity packets.

   OPT_PARITY_GRP is NOT network-significant.

Top      Up      ToC       Page 72 
11.8.3.  OPT_CURR_TGSIZE - Packet Extension 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |E| Option Type | Option Length |Reserved |F|OPX|U|             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Actual Transmission Group Size                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type = 0x0A

   Option Length = 8 octets

   Actual Transmission Group Size (PRM_ATGSIZE)

      The actual number of data packets in this transmission group.
      This MUST be less than or equal to the maximum transmission group
      size PARITY_PRM_TGS in OPT_PARITY_PRM.

   OPT_CURR_TGSIZE MAY be appended to data and parity packets (ODATA or
   RDATA) and to SPMs.

   OPT_CURR_TGSIZE is network-significant except when appended to ODATA.



(page 72 continued on part 4)

Next RFC Part