rfc-4326

Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)

G. Fairhurst, B. Collini-Nocker
date2005-12 streamIETF areaapp wgipdvb statusPROPOSED STANDARD pages42 canonicalhttps://www.rfc-editor.org/rfc/rfc4326 doi10.17487/RFC4326 errataview
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks. This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing. [STANDARDS-TRACK]

updated by

Extracted elements (31)

design-rationale §5

Each ULE Extension Header requires at least 2 bytes (the 16-bit Type field). The designers accepted this overhead cost because it simplifies processing and eliminates the need for multiple IANA registries, keeping the common case (no extensions) lightweight.

ip

design-rationale §4.4

The ULE Type field range < 1536 is reserved for IANA-assigned Next-Header values rather than using LLC-style length semantics. This avoids the Ethernet ambiguity where a value < 1536 could be interpreted as either a length or a protocol identifier, since ULE always carries an explicit Length field.

ip

design-rationale §4.6

ULE's CRC-32 bytes are placed at the end of the SNDU (rather than in the header) to ease hardware implementation of CRC computation. The bit processing order is NOT reversed — unlike SCTP — because ULE processes bytes in order of increasing position.

ip

design-rationale §6.2

When only one byte remains in a TS Packet payload after an SNDU, the Encapsulator MUST fill it with 0xFF and start the next SNDU in a new TS Packet. This avoids complex behavior that would arise if a Payload Pointer were required to consume the sole remaining byte.

ip

interoperability-note §1

A format_identifier value of 0x554C4531 has been registered for ULE with SMPTE. Transport Streams using the PMT SHOULD insert a descriptor with this value in the PMT ES_info descriptor loop; ULE Streams may also be identified by stream_type 0x91 in SI/PSI tables.

ip, registry

interoperability-note §3

ULE uses TS private data but follows PSI packet PUSI semantics: PUSI=1 indicates the start of a new SNDU and the presence of a 1-byte Payload Pointer immediately after the 4-byte TS Packet header. This differs from PES format, which does not use the Payload Pointer.

ip

normative-requirement §7 MUST

A Receiver MUST support both Packing and Padding reception methods and MUST support SNDUs with or without the Destination Address field (D=0 and D=1).

ip

normative-requirement §7.2 MUST

A Receiver reading a 2-byte SNDU Length value of ≤4 or 0xFFFF MUST discard the Current SNDU and remaining TS Packet payload and return to the Idle State. An SNDU with an unknown Type value < 1536 MUST also be discarded.

ip

normative-requirement §3 MUST

Adaptation Field stuffing MUST NOT be used; TS Packets from a ULE Encapsulator MUST be sent with an Adaptation Field Control (AFC) value of '01'. Receivers MUST discard TS Packets on ULE channels that carry other AFC values.

ip

normative-requirement §3 MUST

All TS Packets comprising a single SNDU MUST be assigned the same PID value, so they all belong to the same TS Logical Channel.

ip

normative-requirement §4.6 MUST

Each SNDU MUST carry a 32-bit CRC-32 field in its last four bytes. Receivers MUST calculate and verify the CRC; SNDUs with an invalid CRC MUST be discarded and the Receiver MUST enter the Idle State.

ip, security

normative-requirement §5.2 MUST

For bridged frame encapsulation, the Encapsulator MUST check the LAN FCS of all received Ethernet frames before processing; frames with an invalid LAN FCS MUST be discarded. The LAN FCS is then removed and is not forwarded in the SNDU.

ip, security

normative-requirement §4.5 MUST

For IP unicast packets sent over shared links (multiple Receivers), the SNDU Destination Address field MUST be carried (D=0). For multicast packets with D=0, the IP group address MUST be mapped to the multicast NPA address following RFC 1112 (IPv4) or RFC 2464 (IPv6).

ip, multicast

normative-requirement §7 MUST

Receipt of a Payload Pointer value greater than 181 is illegal and MUST cause reassembly to be aborted, with the Receiver entering the Idle State. This event SHOULD be recorded as a payload pointer error.

ip

normative-requirement §4.5 MUST NOT

The NPA Destination Address value 0x00:00:00:00:00:00 MUST NOT be used as a destination address in an SNDU.

ip

normative-requirement §7.3 MUST

The Receiver MUST check the MPEG-2 Continuity Counter; duplicate TS Packets (same counter value) MUST be silently discarded. A counter discontinuity MUST cause discard of any partially received SNDU and entry into Idle State.

ip

normative-requirement §6.2 MUST

When packing further SNDUs into a TS Packet where PUSI was not previously set, the Encapsulator MUST update the PUSI to 1 and insert a Payload Pointer immediately after the TS Packet header. The Packing Threshold MUST be bounded and SHOULD be configurable.

ip

protocol-element §4.6

Each SNDU carries a 32-bit CRC-32 trailer using the polynomial 0x104C11DB7 (same as Ethernet and AAL5), initialized to 0xFFFFFFFF and computed over all SNDU header and payload bytes in order of increasing position without bit reversal.

ip, security

protocol-element §4.5

The NPA Destination Address is a 6-byte field used to identify individual or group Receivers in the MPEG-2 network. The all-zeros value MUST NOT be used; the LSB of the first byte signals multicast; 0xFF:FF:FF:FF:FF:FF is the link broadcast address.

ip, multicast

protocol-element §4.4

The ULE Type field is 16 bits and is split into two ranges: values 0–1535 are IANA-assigned Next-Header/Extension Header indicators, while values 1536–65535 are EtherType-compatible and MUST use IEEE/DIX-registered EtherType values.

ip, registry

registry §11

IANA created the ULE Next-Header Type field registry allocating values 0–511 decimal: values 0–255 are for Mandatory Extension Headers (requiring IETF RFC), with Type 0 (Test-SNDU) and Type 1 (Bridged-SNDU) already assigned; values 256–511 are for Optional Extension Headers (requiring IETF RFC), with Type 256 (Extension-Padding, H-LEN 1–5) already assigned.

registry, ip

security-consideration §10

Bridged LLC frames reintroduce the dual-Length-field security issue avoided in direct IPv4/IPv6 encapsulation. Receivers MUST discard bridged frames where the LLC Length exceeds the SNDU payload size and SHOULD record an SNDU payload length error.

security, ip

security-consideration §10

Future ULE Mandatory Extension Headers may define SNDU payload link-layer encryption (with Security Association parameters) as an additional mechanism complementing IP-, transport-, or application-layer security. The encryption method and key exchange are outside the scope of RFC 4326.

security, ip, crypto

security-consideration §10

Removing the LAN FCS in a bridged networking environment introduces a known integrity risk: corruption occurring within Encapsulator or Receiver processing will not be detected by the final recipient(s), as such corruption would not produce an invalid LAN FCS on the reconstructed frame.

security, ip

state-machine §7.1

The Receiver operates in two states: Idle State (entered after initialization, errors, or End Indicator — discards all TS Packets until a new SNDU start is found) and Reassembly State (entered when a TS Packet with PUSI=1 is received in Idle State — accumulates SNDU bytes). MPEG-2 TS errors, CRC mismatches, invalid Length, delimiting errors, or invalid Payload Pointer trigger a transition back to Idle State.

ip

wire-format §5.2

A Bridged Frame SNDU uses a Mandatory Extension Header (Type=0x0001) and carries a 6-byte MAC destination address, 6-byte MAC source address, 2-byte EtherType/LLC-Length, bridged MAC frame contents, and CRC-32. The NPA address field may be present (D=0) or absent (D=1).

ip

wire-format §5

A ULE Extension Header occupies the 16-bit Type/Next-Header field and is structured as a 5-bit zero prefix, a 3-bit H-LEN field (0=Mandatory extension, 1–5=Optional extension with total length 2–10 bytes, ≥6=EtherType of directly following PDU), and an 8-bit H-Type field.

ip, registry

wire-format §4.7.2

An IPv4 SNDU with L2 filtering (D=0) carries a 16-bit Length (0|length), Type=0x0800, a 6-byte NPA destination address, the IPv4 datagram, and a 32-bit CRC-32. Without L2 filtering (D=1), the NPA address field is omitted.

ip

wire-format §4.7.3

An IPv6 SNDU with L2 filtering (D=0) carries a 16-bit Length, Type=0x86DD, a 6-byte NPA destination address, the IPv6 datagram, and CRC-32. The D=1 variant omits the NPA field.

ip

wire-format §4.3

The End Indicator is encoded as two bytes with value 0xFFFF (D-bit=1 combined with an all-ones 15-bit Length field). It signals that no further SNDUs are present in the current TS Packet payload; remaining bytes MUST be padded with 0xFF.

ip

wire-format §4

The SNDU base format consists of a 1-bit D-field (MSB of Length), a 15-bit Length field, a 16-bit Type field, an optional 6-byte NPA Destination Address (when D=0), the PDU payload, and a 32-bit CRC-32 trailer. All multi-byte values are in network byte order (most significant byte first).

ip, registry