+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SNDU Format for a Bridged Payload (D=0)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Destination Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Source Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType/LLC-Length (2B) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a Bridged Payload (D=1)
The EtherType/LLC-Length field of a frame is defined according to
IEEE 802.3 [IEEE-802.2] (see section 5).
In this special case, the Mandatory Extension Header format may be
interpreted as either an EtherType [DIX] or an LLC Length field,
specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in
the ULE Next-Header Registry maintained by the IANA.
The MAC addresses in the frame being bridged SHOULD be assigned
according to the rules specified by the IEEE and denote unknown,
unicast, broadcast, and multicast link addresses. These MAC
addresses denote the intended recipient in the destination LAN, and
therefore have a different function from the NPA addresses carried in
the SNDU header.
A frame Type < 1536 for a bridged frame introduces a LLC Length
field. The Receiver MUST check this length and discard any frame
with a length greater than permitted by the SNDU payload size.
In normal operation, it is expected that any padding appended to the
Ethernet frame SHOULD be removed prior to forwarding. This requires
the sender to be aware of such Ethernet padding (e.g., [DIX,
IEEE-802.3]).
Ethernet frames received at the Encapsulator for onward transmission
over ULE carry a Local Area Network Frame Check sequence (LAN FCS)
field (e.g., CRC-32 for Ethernet [DIX, IEEE-802.3]). The
Encapsulator MUST check the LAN-FCS value of all frames received,
prior to further processing. Frames received with an invalid LAN FCS
MUST be discarded. After checking, the LAN FCS is then removed
(i.e., it is NOT forwarded in the bridged SNDU). As in other ULE
frames, the Encapsulator appends a CRC-32 to the transmitted SNDU.
At the Receiver, an appropriate LAN-FCS field will be appended to the
bridged frame prior to onward transmission on the Ethernet interface.
This design is readily implemented using existing network interface
cards and does not introduce an efficiency cost by
calculating/verifying two integrity check fields for bridged frames.
However, it also introduces the possibility that a frame corrupted
within the processing performed at an Encapsulator and/or Receiver
may not be detected by the final recipient(s) (i.e., such corruption
would not normally result in an invalid LAN FCS).
5.3. Extension-Padding Optional Extension Header
The Extension-Padding Optional Extension Header is specified by an
IANA-assigned H-Type value of 0x100. As in other Optional
Extensions, the total length of the extension is indicated by the
H-LEN field (specified in 16-bit words). The extension field is
formed of a group of one to five 16-bit fields.
For this specific option, only the last 16-bit word has an assigned
value; the sender SHOULD set the remaining values to 0x0000. The
last 16-bit field forms the Next-Header Type field. A Receiver MUST
interpret the Type field, but MUST ignore any other fields of this
Extension Header.
6. Processing at the Encapsulator
The Encapsulator forms the PDUs queued for transmission into SNDUs by
adding a header and trailer to each PDU (section 4). It then
segments the SNDU into a series of TS Packet payloads (Figure 13).
These are transmitted using a single TS Logical Channel over a TS
Multiplex. The TS Multiplex may be processed by a number of MPEG-2
(re)multiplexors before it is finally delivered to a Receiver
[RFC4259].
+------+--------------------------------+------+
| ULE | Protocol Data Unit | ULE |
|Header| |CRC-32|
+------+--------------------------------+------+
/ / \ \
/ / \ \
/ / \ \
+--------+---------+ +--------+---------+ +--------+---------+
|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |
| Header | Payload | | Header | Payload | | Header | Payload |
+--------+---------+ +--------+---------+ +--------+---------+
Figure 13: Encapsulation of an SNDU into a series of TS Packets
6.1. SNDU Encapsulation
When an Encapsulator has not previously sent a TS Packet for a
specific TS Logical Channel, or after an Idle period, it starts to
send an SNDU in the first available TS Packet. This first TS Packet
generated MUST carry a PUSI value of 1. It MUST also carry a Payload
Pointer value of zero, indicating that the SNDU starts immediately
after the Payload Pointer in the TS Packet payload.
The Encapsulation MUST ensure that all TS Packets set the MPEG-2
Continuity Counter carried in the TS Packet header, according to
[ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for
each successive TS Packet containing a fragment/complete SNDU sent
using the same TS Logical Channel.
An Encapsulator MAY decide not to send another SNDU immediately, even
if space is available in a partially filled TS Packet. This
procedure is known as Padding (Figure 14). The End Indicator informs
the Receiver that there are no more SNDUs in this TS Packet payload.
The End Indicator is followed by zero or more unused bytes until the
end of the TS Packet payload. All unused bytes MUST be set to the
value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The
Padding procedure trades decreased efficiency against improved
latency.
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
Indicator
Figure 14: A TS Packet carrying the end of SNDU 1, followed by an
End Indicator
Alternatively, when more packets are waiting at an Encapsulator, and
a TS Packet has sufficient space remaining in the payload, the
Encapsulator can follow a previously encapsulated SNDU with another
SNDU using the next available byte of the TS Packet payload (see
6.2). This is called Packing (Figure 15).
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 2 | | DU 3 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+
PUSI=1 | ^
| |
+--------------+
Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3
6.2. Procedure for Padding and Packing
Five possible actions may occur when an Encapsulator has completed
encapsulation of an SNDU:
(i) If the TS Packet has no remaining space, the Encapsulator
transmits this TS Packet. It starts transmission of the next SNDU in
a new TS Packet. (The standard rules [ISO-MPEG2] require that the
header of this new TS Packet carry a PUSI value of 1 followed by a
Payload Pointer value of 0x00.)
(ii) If the TS Packet carrying the final part of an SNDU has one byte
of unused payload, the Encapsulator MUST place the value 0xFF in this
final byte and transmit the TS Packet. This rule provides a simple
mechanism to resolve the complex behaviour that may arise when the TS
Packet has no PUSI set. To send another SNDU in the current TS
Packet would otherwise require the addition of a Payload Pointer that
would consume the last remaining byte of TS Packet payload. The
behaviour follows similar practice for other MPEG-2 payload types
[ISO-DSMCC]. The Encapsulator MUST start transmission of the next
SNDU in a new TS Packet. (The standard rules require the header of
this new TS Packet to carry a PUSI value of 1 followed by a Payload
Pointer value of 0x00.)
(iii) If the TS Packet carrying the final part of an SNDU has exactly
two bytes of unused payload, and the PUSI was NOT already set, the
Encapsulator MUST place the value 0xFFFF in these final two bytes,
providing an End Indicator (section 4.3), and transmit the TS Packet.
This rule prevents fragmentation of the SNDU Length field over two TS
Packets. The Encapsulator MUST start transmission of the next SNDU
in a new TS Packet. (The standard rules require the header of this
new TS Packet to carry a PUSI value of 1 followed by a Payload
Pointer value of 0x00.)
(iv) If the TS Packet has more than two bytes of unused payload, the
Encapsulator MAY transmit this partially full TS Packet but MUST
first place the value 0xFF in all remaining unused bytes (i.e.,
setting an End Indicator followed by Padding). The Encapsulator MUST
then start transmission of the next SNDU in a new TS Packet. (The
standard rules [ISO-MPEG2] require that the header of this new TS
Packet carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
(v) If at least two bytes are available for SNDU data in the TS
Packet payload (i.e., three bytes if the PUSI was NOT previously set,
and two bytes if it was previously set), the Encapsulator MAY
encapsulate further queued PDUs, by starting the next SNDU in the
next available byte of the current TS Packet payload. When the
Encapsulator packs further SNDUs into a TS Packet where the PUSI has
NOT already been set, the PUSI MUST be updated (set to 1), and an
8-bit Payload Pointer MUST be inserted in the first byte directly
following the TS Packet header. (This reduces the size of the TS
Packet payload field that is available for data by one byte.) The
value of the Payload Pointer MUST be set to the position of the byte
following the end of the first SNDU in the TS Packet payload. If no
further PDUs are available, an Encapsulator MAY wait for additional
PDUs to fill the incomplete TS Packet. The maximum period of time an
Encapsulator can wait, known as the Packing Threshold, MUST be
bounded and SHOULD be configurable in the Encapsulator. If
sufficient additional PDUs are NOT received to complete the TS Packet
within the Packing Threshold, the Encapsulator MUST insert an End
Indicator (using rule iv).
Use of the Packing method (v) by an Encapsulator is optional and may
be determined on a per-session, per-packet, or per-SNDU basis.
When an SNDU is less than the size of a TS Packet payload, a TS
Packet may be formed that carries a PUSI value of one and also an End
Indicator (using rule iv).
7. Receiver Processing
A Receiver tunes to a specific TS Multiplex carrying a ULE Stream and
sets a receive filter to accept all TS Packets with a specific PID.
These TS Packets are associated with a specific TS Logical Channel
and are reassembled to form a stream of SNDUs. A single Receiver may
be able to receive multiple TS Logical Channels, possibly using a
range of TS Multiplexes. In each case, reassembly MUST be performed
independently for each TS Logical Channel. To perform this
reassembly, the Receiver may use a buffer to hold the partially
assembled SNDU, referred to here as the Current SNDU buffer. Other
implementations may choose to use other data structures, but MUST
provide equivalent operations.
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS
Packet contains the start of a new SNDU. It also indicates the
presence of the Payload Pointer (indicating the number of bytes to
the start of the first SNDU in the TS-Packet currently being
reassembled). It is illegal to receive a Payload Pointer value
greater than 181, and this MUST cause the SNDU reassembly to be
aborted and the Receiver to enter the Idle State. This event SHOULD
be recorded as a payload pointer error.
A Receiver MUST support the use of both the Packing and Padding
method for any received SNDU and MUST support reception of SNDUs with
or without a Destination Address Field (i.e., D=0 and D=1).
7.1. Idle State
After initialisation or errors, or on receipt of an End Indicator,
the Receiver enters the Idle State. In this state, the Receiver
discards all TS Packets until it discovers the start of a new SNDU,
upon which it then enters the Reassembly State. Figure 16 outlines
these state transitions:
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
Figure 16: Receiver state transitions
7.1.1. Idle State Payload Pointer Checking
A Receiver in the Idle State MUST check the PUSI value in the header
of all received TS Packets. A PUSI value of 1 indicates the presence
of a Payload Pointer. Following a loss of synchronisation, values
between 0 and 181 are permitted, in which case the Receiver MUST
discard the number of bytes indicated by the Payload Pointer (counted
from the first byte of the TS Packet payload field, and excluding the
PP field itself), before leaving the Idle State. It then enters the
Reassembly State, and starts reassembly of a new SNDU at this point.
7.2. Processing of a Received SNDU
When in the Reassembly State, the Receiver reads a 2-byte SNDU Length
field from the TS Packet payload. If the value is less than or equal
to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and
the remaining TS Packet payload and returns to the Idle State.
Receipt of an invalid Length field is an error event and SHOULD be
recorded as an SNDU length error.
If the Length of the Current SNDU is greater than 4, the Receiver
accepts bytes from the TS Packet payload to the Current SNDU buffer
until either Length bytes in total are received, or the end of the TS
Packet is reached (see also 7.2.1). When the Current SNDU length
equals the value of the Length field, the Receiver MUST calculate and
verify the CRC value (see 4.6). SNDUs that contain an invalid CRC
value MUST be discarded. Mismatch of the CRC is an error event and
SHOULD be recorded as a CRC error. The underlying physical-layer
processing (e.g., forward error correction coding) often results in
patterns of errors, rather than single bit errors, so the Receiver
needs to be robust to arbitrary patterns of corruption to the TS
Packet and payload, including potential corruption of the PUSI, PP,
and SNDU Length fields. Therefore, a Receiver SHOULD discard the
remaining TS Packet payload (if any) following a CRC mismatch and
return to the Idle State.
When the Destination Address is present (D=0), the Receiver accepts
SNDUs that match one of a set of addresses specified by the Receiver
(this includes the NPA address of the Receiver, the NPA broadcast
address, and any required multicast NPA addresses). The Receiver
MUST silently discard an SNDU with an unmatched address.
After receiving a valid SNDU, the Receiver MUST check the Type field
(and process any Type 1 Extension Headers). The SNDU payload is then
passed to the next protocol layer specified. An SNDU with an unknown
Type value < 1536 MUST be discarded. This error event SHOULD be
recorded as an SNDU type error.
The Receiver then starts reassembly of the next SNDU. This MAY
directly follow the previously reassembled SNDU within the TS Packet
payload.
(i) If the Current SNDU finishes at the end of a TS Packet payload,
the Receiver MUST enter the Idle State.
(ii) If only one byte remains unprocessed in the TS Packet payload
after completion of the Current SNDU, the Receiver MUST discard this
final byte of TS Packet payload. It then enters the Idle State. It
MUST NOT record an error when the value of the remaining byte is
identical to 0xFF.
(iii) If two or more bytes of TS Packet payload data remain after
completion of the Current SNDU, the Receiver accepts the next 2 bytes
and examines whether this is an End Indicator. When an End Indicator
is received, a Receiver MUST silently discard the remainder of the TS
Packet payload and transition to the Idle State. Otherwise, this is
the start of the next Packed SNDU, and the Receiver continues by
processing this SNDU. (This is provided that the TS Packet has a
PUSI value of 1, see 7.2.1; otherwise, the Receiver has detected a
delimiting error and MUST discard all remaining bytes in the TS
Packet payload and transitions to the Idle State.)
7.2.1. Reassembly Payload Pointer Checking
A Receiver that has partially received an SNDU (in the Current SNDU
buffer) MUST check the PUSI value in the header of all subsequent TS
Packets with the same PID (i.e., same TS Logical Channel). If it
receives a TS Packet with a PUSI value of 1, it MUST then verify the
Payload Pointer. If the Payload Pointer does NOT equal the number of
bytes remaining to complete the Current SNDU (i.e., the difference
between the SNDU Length field and the number of reassembled bytes),
the Receiver has detected a delimiting error.
Following a delimiting error, the Receiver MUST discard the partially
assembled SNDU (in the Current SNDU buffer) and SHOULD record a
reassembly error. It MUST then re-enter the Idle State.