0x0001: Bridged Frame (see section 5.2)
0x0100: Extension-Padding (see section 5.3)
The remaining values within the first part of the Type space are
reserved for Next-Header values allocated by the IANA.
4.4.2. Type 2: EtherType Compatible Type Fields
The second part of the Type space corresponds to the values between
0x600 (1536 decimal) and 0xFFFF. This set of type assignments
follows DIX/IEEE assignments (but excludes use of this field as a
frame length indicator). All assignments in this space MUST use the
values defined for IANA EtherType. The following two Type values are
used as examples (taken from the IANA EtherTypes registry):
0x0800: IPv4 Payload (see section 4.7.2)
0x86DD: IPv6 Payload (see section 4.7.3)
4.5. SNDU Destination Address Field
The SNDU Destination Address Field is optional (see section 4.1).
This field MUST be carried (i.e., D=0) for IP unicast packets
destined to routers that are sent using shared links (i.e., where the
same link connects multiple Receivers). A sender MAY omit this field
(D=1) for an IP unicast packet and/or multicast packets delivered to
Receivers that are able to utilise a discriminator field (e.g., the
IPv4/IPv6 destination address, or a bridged MAC destination address),
which, in combination with the PID value, could be interpreted as a
Link-Level address.
When the SNDU header indicates the presence of an SNDU Destination
Address field (i.e., D=0), a Network Point of Attachment (NPA) field
directly follows the fourth byte of the SNDU header. NPA destination
addresses are 6 Byte numbers, normally expressed in hexadecimal, used
to identify the Receiver(s) in a MPEG-2 transmission network that
should process a received SNDU. The value 0x00:00:00:00:00:00 MUST
NOT be used as a destination address in an SNDU. The least
significant bit of the first byte of the address is set to 1 for
multicast frames, and the remaining bytes specify the link-layer
multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the
link broadcast address, indicating that this SNDU is to be delivered
to all Receivers.
IPv4 packets carrying an IPv4 subnetwork broadcast address need to be
delivered to all systems with the same network prefix. When a SNDU
Destination Address is present (D=0), the value MUST be set to the
NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
When the PDU is an IP multicast packet and an SNDU Destination
Address is present (D=0), the IP group destination address of the
multicast packet MUST be mapped to the multicast SNDU Destination
Address (following the method used to generate a destination MAC
address in Ethernet). The method for mapping IPv4 multicast
addresses is specified in [RFC1112]. The method for mapping IPv6
multicast addresses is specified in [RFC2464].
4.6. SNDU Trailer CRC
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of the
SNDU. This position eases CRC computation by hardware. The CRC-32
polynomial is to be used. Examples where this polynomial is also
employed include Ethernet, DSM-CC section syntax [ISO-DSMCC], and
AAL5 [ITU-3563]. This is a 32-bit value calculated according to the
generator polynomial represented 0x104C11DB7 in hexadecimal:
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
The Encapsulator initialises the CRC-32 accumulator register to the
value 0xFFFF FFFF. It then accumulates a transmit value for the
CRC32 that includes all bytes from the start of the SNDU header to
the end of the SNDU (excluding the 32-bit trailer holding the
CRC-32), and places this in the CRC Field. In ULE, the bytes are
processed in order of increasing position within the SNDU; the order
of processing bits is NOT reversed. This use resembles, but is
different from that in SCTP [RFC3309].
The Receiver performs an integrity check by independently calculating
the same CRC value and comparing this with the transmitted value in
the SNDU trailer. SNDUs that do not have a valid CRC are discarded,
causing the Receiver to enter the Idle State.
This description may be suited for hardware implementation, but this
document does not imply any specific implementation. Software-based
table-lookup or hardware-assisted software-based implementations are
also possible. Appendix B provides an example of an Encapsulated PDU
that includes the computed CRC-32 value.
The primary purpose of this CRC is to protect the SNDU (header and
payload) from undetected reassembly errors and errors introduced by
unexpected software/hardware operation while the SNDU is in transit
across the MPEG-2 subnetwork and during processing at the
Encapsulator and/or the Receiver. It may also detect the presence of
uncorrected errors from the physical link (however, these may also be
detected by other means, e.g., section 7.3).
4.7. Description of SNDU Formats
The format of an SNDU is determined by the combination of the
Destination Address Absent bit (D) and the SNDU Type field. The
simplest encapsulation places a PDU directly into an SNDU payload.
Some Type 1 encapsulations may require additional header fields.
These are inserted in the SNDU following the NPA destination address
and directly preceding the PDU.
The following SNDU Formats are defined here:
End Indicator: The Receiver should enter the Idle State (4.7.1).
IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2).
IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3).
Test SNDU: The payload will be discarded by the Receiver (5.1).
Bridged SNDU: The payload carries a bridged MAC frame (5.2).
Other formats may be defined through relevant assignments in the IEEE
and IANA registries.
4.7.1. End Indicator
The format of the End Indicator is shown in figure 2. This format
MUST carry a D-bit value of 1.
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| 0x7FFF | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= A sequence of zero or more bytes with a value 0xFF filling =
| the remainder of the TS Packet Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for a ULE End Indicator
4.7.2. IPv4 SNDU Encapsulation
IPv4 datagrams are directly transported using one of the two standard
SNDU structures, in which the PDU is placed directly in the SNDU
payload. The two encapsulations are shown in Figures 3 and 4. (Note
that in this, and the following figures, the IP datagram payload is
of variable size and is directly followed by the CRC-32).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (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 = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1)
4.7.3. IPv6 SNDU Encapsulation
IPv6 datagrams are directly transported using one of the two standard
SNDU structures, in which the PDU is placed directly in the SNDU
payload. The two encapsulations are shown in Figures 5 and 6.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (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 = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
5. Extension Headers
This section describes an extension format for the ULE encapsulation.
In ULE, a Type field value less than 1536 decimal indicates an
Extension Header. These values are assigned from a separate IANA
registry defined for ULE.
The use of a single Type/Next-Header field simplifies processing and
eliminates the need to maintain multiple IANA registries. The cost
is that each Extension Header requires at least 2 bytes. This is
justified, on the basis of simplified processing and maintaining a
simple lightweight header for the common case when no extensions are
present.
A ULE Extension Header is identified by a 16-bit value in the Type
field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN
field, and an 8-bit H-Type field, as follows:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of ULE Next-Header Field
The H-LEN Assignment is described below:
0 Indicates a Mandatory Extension Header
1 Indicates an Optional Extension Header of length 2B (Type only)
2 Indicates an Optional Extension Header of length 4B (Type + 2B)
3 Indicates an Optional Extension Header of length 6B (Type + 4B)
4 Indicates an Optional Extension Header of length 8B (Type + 6B)
5 Indicates an Optional Extension Header of length 10B (Type + 8B)
>=6 The combined H-LEN and H-TYPE values indicate the EtherType
of a PDU that directly follows this Type field.
The H-LEN value indicates the total number of bytes in an Optional
Extension Header (including the 2B Type field).
An H-LEN value of zero indicates a Mandatory Extension Header. Each
Mandatory Extension Header has a pre-defined length that is not
communicated in the H-LEN field. No additional limit is placed on
the maximum length of a Mandatory Extension Header. A Mandatory
Extension Header MAY modify the format or encoding of the enclosed
PDU (e.g., to perform encryption and/or compression).
The H-Type is a one-byte field that is either one of 256 Mandatory
Header Extensions or one of 256 Optional Header Extensions. The set
of currently permitted values for both types of Extension Headers are
defined by an IANA Registry (section 15). Registry values for
Optional Extensions are specified in the form H=1 (i.e., a decimal
number in the range 256-511), but may be used with an H-Length value
in the range 1-5 (see example in section 5.3).
Two examples of Extension Headers are the Test SNDU and the use of
Extension-Padding. The Test SNDU Mandatory Extension Header results
in the entire PDU’s being discarded. The Extension-Padding Optional
Extension Header results in the following (if any) option header
being ignored (i.e., a total of H-LEN 16-bit words).
The general format for an SNDU with Extension Headers is:
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header > < ext 1 >
Figure 8: SNDU Encapsulation with one Extension Header (for D=0)
Where:
D is the ULE D_bit (in this example D=0; however, NPA addresses may
also be omitted when using Extension Headers).
T1 is the base header Type field. In this case, specifying a
Next-Header value.
H1 is a set of fields defined for header type T1. There may be 0
or more bytes of information for a specific ULE Extension Header.
T2 is the Type field of the next header, or an EtherType > 1535 B
indicating the type of the PDU being carried.
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
Figure 9: SNDU Encapsulation with two Extension Headers (D=1)
Using this method, several Extension Headers MAY be chained in
series. Figure 12 shows an SNDU including two Extension Headers. In
the example, the values of T1 and T2 are both less than 1536 decimal.
Each indicates the presence of an Extension Header, rather than a
directly following PDU. T3 has a value > 1535 indicating the
EtherType of the PDU being carried. Although an SNDU may contain an
arbitrary number of consecutive Extension Headers, it is not expected
that SNDUs will generally carry a large number of extensions.
5.1. Test SNDU
A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1.
This header must be the final (or only) extension header specified in
the header chain of an SNDU. The structure of the Data portion of
this SNDU is not defined by this document. Receivers MAY record
reception in a log file, but MUST then discard any Test SNDUs. The
D-bit MAY be set in a TEST SNDU.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Length (15b) | Type = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Data (not forwarded by a Receiver) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a Test SNDU
5.2. Bridged Frame SNDU Encapsulation
A bridged SNDU is a Mandatory Extension Header of Type 1. It MUST be
the final (or only) extension header specified in the header chain of
an SNDU. The payload includes MAC address and EtherType [DIX] or LLC
Length [ISO-8802-2] fields together with the contents of a bridged
MAC frame. The SNDU has the format shown in Figures 11 and 12.
When an NPA address is specified (D=0), Receivers MUST discard all
SNDUs that carry an NPA destination address that does NOT match their
own NPA address (or a broadcast/multicast address); the payload of
the remaining SNDUs are processed by the bridging rules that follow.
An SNDU without an NPA address (D=1) results in a Receiver performing
bridging processing on the payload of all received SNDUs.
An Encapsulator MAY also use this encapsulation format to directly
communicate network protocol packets that require the LLC
encapsulation [IEEE-802.2, ISO-8802-2]. To do this, it constructs an
SNDU with a Bridge Extension Header containing the intended
destination MAC address, the MAC source address of the Encapsulator,
and the LLC-Length. The PDU comprises an LLC header followed by the
required payload. The Encapsulator MAY choose to suppress the NPA
address (see 4.5).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Destination Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Source Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EtherType/LLC-Length (2B) |