| 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.
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
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.
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.
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.
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
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
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).
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.
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 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
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 ...
+-+-+- ...
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.
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.
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
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
9. Options
PGM specifies several end-to-end options to address specific
application requirements. PGM specifies options to support
fragmentation, late joining, and redirection.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+