RFC 4326
Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
RFC 4326: Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) 💖
Okay, so here's the title block, all the tea in one spot ✨
- Number: RFC 4326 🎀
- Working group: Network Working Group 🌸
- Authors: G. Fairhurst (University of Aberdeen) and B. Collini-Nocker (University of Salzburg) 🎓
- Category: Standards Track, so this is a real, official standard 👑
- Date: December 2005 📅
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🦋
Status of This Memo ✨
Okay, the status bit! This is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 💅.
Copyright Notice 💜
Copyright (C) The Internet Society (2005).
Abstract 🌈
The MPEG-2 Transport Stream (TS) is hugely popular, and not just for digital TV. It's also a subnetwork technology people use to build IP networks, which is so iconic 🔥.
This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for carrying IPv4 and IPv6 Datagrams, plus other network protocol packets, directly over the ISO MPEG-2 Transport Stream as TS Private Data 🧚. ULE defines a base encapsulation format, and it also supports an extension format. That extension lets it carry extra header information to help with network and Receiver processing ✨.
Table of Contents 💅
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Description of the Method .......................................8
4. SNDU Format .....................................................9
4.1. Destination Address Absent (D) Field ......................10
4.2. Length Field ..............................................10
4.3. End Indicator .............................................10
4.4. Type Field ................................................10
4.4.1. Type 1: Next-Header Type Fields ....................11
4.4.2. Type 2: EtherType Compatible Type Fields ...........11
4.5. SNDU Destination Address Field ............................12
4.6. SNDU Trailer CRC ..........................................12
4.7. Description of SNDU Formats ...............................13
4.7.1. End Indicator ......................................14
4.7.2. IPv4 SNDU Encapsulation ............................14
4.7.3. IPv6 SNDU Encapsulation ............................15
5. Extension Headers ..............................................16
5.1. Test SNDU .................................................18
5.2. Bridged Frame SNDU Encapsulation ..........................18
5.3. Extension-Padding Optional Extension Header ...............21
6. Processing at the Encapsulator .................................22
6.1. SNDU Encapsulation ........................................22
6.2. Procedure for Padding and Packing .........................24
7. Receiver Processing ............................................25
7.1. Idle State ................................................26
7.1.1. Idle State Payload Pointer Checking ................26
7.2. Processing of a Received SNDU .............................26
7.2.1. Reassembly Payload Pointer Checking ................28
7.3. Other Error Conditions ....................................28
8. Summary ........................................................29
9. Acknowledgements ...............................................29
10. Security Considerations .......................................29
11. IANA Considerations ...........................................30
11.1. IANA Guidelines ..........................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Appendix A. SNDU Packing Examples .................................35
Appendix B. SNDU Encapsulation ....................................401. Introduction ✨
Okay, so this document describes an encapsulation for carrying IP datagrams, or other network-layer packets, over ISO MPEG-2 Transport Streams [ISO-MPEG2, RFC4259] 🦋. It meets the requirement for a lightweight encapsulation that's defined in section 4 of [RFC4259]. The basic header gives you the required set of protocol fields, and extension headers can also be defined 💖. The header structure is way simpler to parse and process [SOOR05] than the current alternatives, like MPE [ETSI-DAT], which is built on the DSM-CC Table Section syntax [ISO-DSMCC] 🙈.
This encapsulation is made for MPEG-2-based services, like the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other similar MPEG-2-based transmission systems 📺. These systems offer unidirectional (simplex) physical and link-layer standards. They've been defined for a wide range of physical media, including Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ATSC-S], and Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC] 🛰️. Bi-directional (duplex) links can be set up with these standards too. For example, DVB defines a bunch of return channel technologies, including two-way satellite links [ETSI-RCS], and dial-up modem links [RFC3077] 🌈.
Protocol Data Units (PDUs) are things like Ethernet Frames, IP datagrams, or other network-layer packets sent over an MPEG-2 Transport Multiplex. They get passed to an Encapsulator 🧚. The Encapsulator formats each PDU into a SubNetwork Data Unit (SNDU) by adding an encapsulation header and an integrity check trailer. Then the SNDU gets fragmented into one or more MPEG-2 Transport Stream (TS) Packets, which are sent over a single TS Logical Channel 💅.
The MPEG-2 specification [ISO-MPEG2] requires that conformant TS Multiplexes provide Program Specific Information (PSI) for each stream in the TS Multiplex 📚. Other MPEG-2-based transmission standards may also define Service Information (SI) ✨.
A format_identifier value has been registered for ULE [ULE1]. It's a 32 bit number with the hexadecimal value 0x554C4531 🔥. Transport Streams that use the Programme Map Table (PMT) defined in ISO 13818-1 [ISO-MPEG2], and that use the ULE format defined in this document, SHOULD insert a descriptor with this value in the PMT ES_info descriptor loop 👑. ULE Streams can also be identified by the stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2] 🎀.
This information can help Receivers and Re-multiplexors [RFC4259] find a specific ULE Stream, meaning the PID value of the TS Logical Channel that carries it 🔍. The conditions under which this information is required, and the format it has to be provided in, are beyond the scope of this document. Addressing and mapping issues for ULE over MPEG-2 are also covered in [IPDVB-AR] 🫶.
Part 1 of 10 down, bestie! 💖 More coming.
2. Conventions Used in This Document ✨
okay bestie, the capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this doc are to be read as described in [RFC2119]. 💅
Here's the glossary of the other terms we use, so everyone's on the same page 🎀
b: bit. So one byte is 8b, obviously 🤓
B: Byte. Groups of bytes are shown in Internet byte order 🌸
Adaptation Field: an optional, variable-length extension field hanging off the fixed-length TS Packet header 🦋 It's meant to carry clock references, timing and synchronization info, plus stuffing, over an MPEG-2 Multiplex [ISO-MPEG2].
AFC: Adaptation Field Control [ISO-MPEG2]. It's a pair of bits in the TS Packet header that signal whether there's an Adaptation Field, a TS Packet payload, or both 💜
ATSC: Advanced Television Systems Committee [ATSC]. It's a framework plus a set of standards for sending video, audio, and data using the ISO MPEG-2 standard 📺
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. It's a format for sending data and control info in an MPEG-2 Private Section, as defined by the ISO MPEG-2 standard 🧚
DVB: Digital Video Broadcast. This is a framework and set of standards published by the European Telecommunications Standards Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for sending video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2]. Very iconic, very European 🇪🇺✨
Encapsulator: a network device that takes in PDUs and formats them into Payload Units (known here as SNDUs) that go out as a stream of TS Packets 🎁
End Indicator: a value that tells the Receiver that there are no more SNDUs in the current TS Packet. Bye bye, nothing else here 👋
LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. It's a link-layer protocol defined by the IEEE 802 standard, and it follows the Ethernet MAC Header 🫶
MAC: Medium Access Control [IEEE-802.3]. It's a link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]) 🌈
MAC Header: the link-layer header from the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2 [DIX]. It's made up of a 6B destination address, a 6B source address, and a 2B Type field (see also NPA, LLC) 💖
MPE: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. It's a scheme that encapsulates PDUs and forms a DSM-CC Table Section. Each Section gets sent in a series of TS Packets using a single TS Logical Channel 🍓
MPEG-2: a set of standards from the Motion Picture Experts Group (MPEG), standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and by ITU-T (in H.222 [ITU-H222]). The OG of this whole vibe 👑
Next-Header: a Type value that means "there's an Extension Header next" 🔥
NPA: Network Point of Attachment. In this doc, it's a 6-byte destination address (kinda looks like an IEEE MAC address) inside the MPEG-2 transmission network. It's used to identify individual Receivers or groups of Receivers 🎀
Packing Threshold: a period of time an Encapsulator is willing to wait before sending a partially filled TS-Packet, so it can squeeze in more SNDUs instead of using Padding. Once the Packet Threshold period is up, the Encapsulator uses Padding to send the partially filled TS-Packet. Patience is a whole mood 🫠
Padding: a method that fills the leftover unused bytes in a TS Packet payload with the specific pattern 0xFF 🌸
Payload Unit, PU: a sequence of bytes sent using a TS. Examples include an MPEG-2 Table Section or a ULE SNDU 📦
PDU: Protocol Data Unit. Examples are Ethernet frames, IPv4 or IPv6 datagrams, and other network packets 💜
PES: Packetized Elementary Steam [ISO-MPEG2]. It's a format for the TS packet payload that's usually used for video or audio info 🎬
PID: Packet Identifier [ISO-MPEG2]. It's a 13-bit field in the header of TS Packets, and it's used to identify the TS Logical Channel a TS Packet belongs to [ISO-MPEG2]. The TS Packets that form parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000, along with other PID values, is reserved for specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF means a Null TS Packet, which is introduced to keep a TS Multiplex at a constant bit rate. There's no required relationship between the PID values used for TS Logical Channels sent over different TS Multiplexes 🦋
PP: Payload Pointer [ISO-MPEG2]. It's an optional one-byte pointer that comes right after the 4-byte TS Packet header. It holds the number of bytes that follow the Payload Pointer, up to the start of the first Payload Unit. That count starts from the first byte of the TS Packet payload field and leaves out the PP field itself. You know the Payload Pointer is there because of the value of the PUSI bit in the TS Packet header. It's present in DSM-CC, Table Sections, and ULE, but not in TS Logical Channels that use the PES format 🧚
Private Section: a syntactic structure built according to Table 2-30 of [ISO-MPEG2]. It can be used to identify private info (i.e., not defined by [ISO-MPEG2]) about one or more elementary streams, a specific MPEG-2 program, or the entire Transport Stream. Other standards bodies, like ETSI and ATSC, have defined sets of table structures using the private_section structure. A Private Section is sent as a sequence of TS Packets over a TS Logical Channel, and a TS Logical Channel may carry sections from more than one set of tables 🎀
PSI: Program Specific Information [ISO-MPEG2]. These are tables that convey info about the service carried in a TS Multiplex. The info lives in one of four specifically identified Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table 💅
PU: Payload Unit 🫶
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. It's a single-bit flag in the TS Packet header. A PUSI value of zero means the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one means it does. In ULE, a PUSI bit set to 1 also means there's a one-byte Payload Pointer (PP) 🍓
Receiver: equipment that processes the signal from a TS Multiplex and filters and forwards encapsulated PDUs to the network-layer service (or to the bridging module when it's operating at the link layer) 📡
SI Table: Service Information Table [ISO-MPEG2]. In this doc, this term describes a table defined by another standards body to convey info about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections, but all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2] 🌈
SNDU: SubNetwork Data Unit. It's an encapsulated PDU sent as an MPEG-2 Payload Unit 📦
Table Section: a Payload Unit that carries all or part of an SI or PSI Table [ISO-MPEG2] 💖
TS: Transport Stream [ISO-MPEG2]. It's a method of transmission at the MPEG-2 level that uses TS Packets. It represents layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex 👑
TS Header: the 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B TS Packet has a 4B header with the following fields (the ones referenced in this doc are marked with *) 🦋
Field Length Name/Purpose
(in bits)
8b Synchronisation pattern equal to 0x47
*1b Transport Error Indicator
*1b Payload Unit Start Indicator (PUSI)
1b Transport Priority
*13b Packet IDentifier (PID)
2b Transport Scrambling Control
*2b Adaptation Field Control (AFC)
*4b Continuity Counter (CC)If the PUSI bit is set to a value of 1, there is one additional field following the TS packet header 🌸
*8b Payload Pointer (PP)TS Logical Channel: Transport Stream Logical Channel. In this doc, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. It lives at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (and that value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved (by MPEG-2) for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific PID values 🧚
TS Multiplex: In this doc, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. That could be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency), or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly with a different PID value) [RFC4259]. For example, it could redistribute the same multicast content to two terrestrial TV transmission cells 📺✨
TS Packet: a fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional overhead such as an Adaptation Field, encryption details, and time stamp info to synchronise a set of related TS Logical Channels 🎀
ULE Stream: an MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by defining a stream_type in SI/PSI [ISO-MPEG2] 💜
3. Description of the Method 🎀
okay bestie, so the big idea is that PDUs (IP packets, Ethernet frames, or packets from other network protocols) get wrapped up into a Subnetwork Data Unit (SNDU) 🎁 Then that SNDU rides across an MPEG-2 transmission network, either tucked inside the payload of a single TS Packet or, if it's too big, chopped up into a series of TS Packets ✂️ When there's enough room, one TS Packet can hold more than one SNDU (or part of one). People sometimes call this Packing ✨ Every TS Packet that makes up an SNDU MUST be given the same PID, so they all belong to the same TS Logical Channel 💅
The ULE encapsulation is only for TS private streams 🔒 Each TS Packet header has a one-bit Payload Unit Start Indicator (PUSI) field. A PUSI value of 1 means that at least one Payload Unit (SNDU) starts inside that TS Packet payload 🦋 PUSI's meaning is defined for PES and PSI packets [ISO-MPEG2]. For private data, the MPEG-2 Standard doesn't define how it's used. ULE uses private data, but it acts like PSI packets, so these are the PUSI values:
0: The TS Packet does NOT contain the start of an SNDU, but contains the continuation, or end, of an SNDU;1: The TS Packet contains the start of an SNDU, and a one byte Payload Pointer follows the last byte of the TS Packet header.
If a Payload Unit (SNDU) ends before the TS Packet payload does, but no new Payload Unit is meant to start, the leftover space gets filled with stuffing (called Padding) 🧸 That Padding is made of bytes with the value 0xFF [ISO-MPEG2].
A Receiver processing MPEG-2 Table Sections that sees 0xFF in the first byte of a Table Section (table_Id) reads it as Padding/Stuffing and quietly drops the rest of the TS Packet payload 🙈 The next TS Packet for the same TS Logical Channel starts its payload with a Payload Pointer of value 0x00, which means the next Payload Unit begins right after the TS Packet header. ULE is kind of similar to this, but the exact steps are different (see the following sections) ✨
The TS Packet Header also has a two-bit Adaptation Field Control (AFC) value 🌈 The adaptation field can stretch the header to carry timing and synchronisation info, and it can also hold stuffing bytes before the payload. Adaptation Field stuffing is NOT used in this encapsulation method. TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'. For TS Logical Channels that support ULE, Receivers MUST discard TS Packets that carry any other AFC values 🚫
4. SNDU Format 💜
PDUs get encapsulated with ULE to form an SNDU, and every SNDU is an MPEG-2 Payload Unit 🫶 Here's the layout for the encapsulation format:
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+Figure 1: SNDU Encapsulation (* optional Destination Address)
Every multi-byte value in ULE is sent in network byte order (most significant byte first). That's the Length/End Indicator (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension Headers (5) 🍓 The most significant bit of each byte goes in the left-most spot of the 8-bit field. Appendix A has informative examples of how it's used 🧚
4.1. Destination Address Absent (D) Field 💖
The most significant bit of the Length field is the Destination Address Absent Field, which we call the D-bit 🎀 A D-bit value of 0 means the Destination Address Field is there (see section 4.5). A value of 1 means there's no Destination Address Field.
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other SNDUs MAY be sent with a D-bit value of 0 or 1. The default method SHOULD use a D-bit value of 0 (see section 4.5) 🌸
4.2. Length Field 📏
This is a 15-bit value that tells you how many bytes the SNDU is, counted from the byte right after the Type field of the SNDU base header (figure 9), all the way up to and including the CRC 💅 That Length also includes any extension headers that might be there (section 5). There's a special case described in section 4.3, so don't skip it 👀
4.3. End Indicator 🛑
When the first two bytes after an SNDU are 0xFFFF, that's an End Indicator (all ones length plus a D-bit value of 1) 😭 It tells the Receiver there are no more SNDUs in the current TS Packet (see section 6), and that no Destination Address Field is present. The value 0xFF has its own job in MPEG-2 framing, where it means Padding. This use is similar to [ISO-DSMCC] 🧠
4.4. Type Field 🧩
The 16-bit Type field says what kind of payload is inside an SNDU, or whether there's a Next-Header. The values that can go here are split into two parts, kinda like Ethernet does 💕
EtherTypes were first specified by Xerox under the Ethernet v2 Specification [DIX]. After IEEE 802.3 [IEEE-802.3, ISO-8802-2] came along, the EtherTypes under 1536 (0x0600) took on the job of a length indicator. Ethernet receivers use this to tell LLC format frames apart. So any IEEE EtherType < 1536 means it's an LLC frame, and the actual value tells you the length of that LLC frame 🤓
Here's the tricky part: if a Receiver gets a PDU with two Length fields, it has to check that the actual length and the Length field agree, and make sure the network doesn't pass along inconsistent values 😬 Having two independent Length fields is therefore not something anyone wants. ULE avoids this by including only one length value in the SNDU header, but bridging LLC frames brings this issue back (section 5.2) 🙃
Ethernet's LLC mode of identification isn't required in ULE, since the SNDU format always carries an explicit Length field. So the ULE procedure is modified like this:
The first set of ULE Type field values is every value under 1536 in decimal. These Type field values are IANA assigned (see section 4.4.1) and they indicate the Next-Header 🪄
The second set is every value greater than or equal to 1536 in decimal. In ULE, these values match the type codes from the IEEE/DIX type assignments for Ethernet, which are recorded in the IANA EtherType registry 💜
4.4.1. Type 1: Next-Header Type Fields 🌟
The first part of the Type space covers the values 0 to 1535 in decimal. These can identify link-specific protocols, and/or show that Extension Headers are present to carry extra optional protocol fields (e.g., a bridging encapsulation). These values are coordinated through an IANA registry. This document defines the following types:
0x0000: Test SNDU (see section 5.1)
0x0001: Bridged Frame (see section 5.2)
0x0100: Extension-Padding (see section 5.3)The rest of the values in this first part are reserved for Next-Header values that IANA allocates 🎀
4.4.2. Type 2: EtherType Compatible Type Fields 🦋
The second part of the Type space covers the values between 0x600 (1536 decimal) and 0xFFFF. This set follows the DIX/IEEE assignments, except that the field isn't used as a frame length indicator 🙅♀️ All assignments in this space MUST use the values defined for IANA EtherType. These two Type values are 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 going to routers over shared links (meaning the same link connects multiple Receivers). A sender MAY omit this field (D=1) for an IP unicast packet, and/or for multicast packets delivered to Receivers that can use a discriminator field (e.g., the IPv4/IPv6 destination address, or a bridged MAC destination address). Together with the PID value, that discriminator could be read as a Link-Level address 🔍
When the SNDU header shows an SNDU Destination Address field is there (i.e., D=0), a Network Point of Attachment (NPA) field comes right after the fourth byte of the SNDU header 📍 NPA destination addresses are 6 Byte numbers, usually written in hexadecimal. They identify the Receiver(s) in an 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 is set to 1 for multicast frames, and the remaining bytes give the link-layer multicast address. The value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, which means this SNDU goes to all Receivers 📢
IPv4 packets that carry an IPv4 subnetwork broadcast address need to reach every system with the same network prefix 🌐 When an 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 same 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 💖
Okay bestie, every SNDU MUST carry a 32-bit CRC field in its last four bytes 🫶 The end is the move because it makes the CRC math way easier for hardware to do, and that's so smart ✨ The CRC-32 polynomial is the one we use, and it's giving everywhere. Ethernet uses it, DSM-CC section syntax [ISO-DSMCC] uses it, and AAL5 [ITU-3563] uses it too 🌈 The 32-bit value comes from the generator polynomial 0x104C11DB7 in hexadecimal, which works out to this:
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 starts its CRC-32 accumulator register at 0xFFFF FFFF 🧚 Then it runs through every byte from the start of the SNDU header to the end of the SNDU, skipping the 32-bit trailer that holds the CRC-32 itself, and drops the result into the CRC Field. In ULE, the bytes get processed in order of increasing position within the SNDU, and the order of processing bits is NOT reversed. This is lowkey similar to what SCTP does [RFC3309], but it's not the same, so don't mix them up 🙈
The Receiver does an integrity check by calculating the same CRC value on its own and comparing it with the value sitting in the SNDU trailer. Any SNDU without a valid CRC gets thrown out, and that makes the Receiver enter the Idle State 💅
This description is probably a good fit for hardware, but this document doesn't require any specific implementation. Software table-lookup is also a vibe, and so is a hardware-assisted software approach 🦋 Appendix B has an example of an Encapsulated PDU with the computed CRC-32 value, so you can check your work 🎀
Now, why do we even care about this CRC? Its main job is to protect the SNDU, meaning both the header and the payload, from reassembly errors that go undetected. It also guards against errors caused by unexpected software or hardware behaviour while the SNDU is in transit across the MPEG-2 subnetwork, and while it's being processed at the Encapsulator and/or the Receiver 😭 It may also catch uncorrected errors from the physical link, although other methods can catch those too, like section 7.3 🔥
4.7. Description of SNDU Formats 🌸
Which format an SNDU takes depends on the combination of the Destination Address Absent bit (D) and the SNDU Type field. The simplest encapsulation just pops a PDU straight into the SNDU payload 🍓 Some Type 1 encapsulations need extra header fields too. Those get tucked into the SNDU right after the NPA destination address and directly before the PDU, so they're easy to spot ✨
These are the SNDU Formats 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 can be defined later 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 get transported directly using one of the two standard SNDU structures, where the PDU sits right in the SNDU payload 💖 The two encapsulations are shown in Figures 3 and 4. (Quick note: in this figure and the ones that follow, the IP datagram payload is variable in size and is followed right away 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 get transported directly using one of the two standard SNDU structures too, again with the PDU placed right 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 ✨
okay so this section is all about the extension format for ULE encapsulation 🎀 in ULE, a Type field value less than 1536 decimal means "hey, there's an Extension Header here, not a PDU yet" 💅 those values come from a separate IANA registry that's made just for ULE 📋
the single Type/Next-Header field is honestly so clean 🧚 it keeps processing simple and means nobody has to juggle multiple IANA registries 🙌 the tradeoff is that every Extension Header costs at least 2 bytes 🥺 but that's totally justified, bestie, because the common case (no extensions at all) stays a super lightweight header 🦋
a ULE Extension Header is identified by a 16-bit value in the Type field 💖 that field is split up like this: a 5-bit zero prefix, then a 3-bit H-LEN field, then an 8-bit H-Type field 🌸
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 🦋
here's how the H-LEN values work 👑
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 tells you the total number of bytes in an Optional Extension Header, and that count includes the 2B Type field itself 🫶
an H-LEN value of zero means it's a Mandatory Extension Header 💀 each one has a pre-defined length that is NOT communicated in the H-LEN field 🙈 and there's no extra limit on how long a Mandatory Extension Header can be ✨ a Mandatory Extension Header MAY modify the format or encoding of the enclosed PDU (for example, to do encryption and/or compression) 🔐
the H-Type is a one-byte field, and it's either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions 🌈 the currently permitted values for both kinds are defined by an IANA Registry (section 15) 📋 Registry values for Optional Extensions are written in the form H=1 (so a decimal number in the range 256-511), but they can be used with an H-Length value in the range 1-5 (see the example in section 5.3) 💜
two examples of Extension Headers are the Test SNDU and Extension-Padding 🎀 the Test SNDU Mandatory Extension Header makes the entire PDU get discarded 😭 and the Extension-Padding Optional Extension Header makes the following option header (if there is one) get ignored, which is a total of H-LEN 16-bit words 🌸
the general format for an SNDU with Extension Headers looks like this 🧚
< -------------------------- 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, but NPA addresses may also be omitted when using Extension Headers) 🦋
- T1 is the base header Type field, which in this case specifies a Next-Header value 💖
- H1 is a set of fields defined for header type T1, and 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 with two Extension Headers 🙈 (heads up, that's the figure number the original text uses for this example.) in that example, T1 and T2 are both less than 1536 decimal, so each one signals another Extension Header instead of a directly following PDU 🫶 T3 has a value > 1535, which is the EtherType of the PDU being carried 💜 an SNDU can hold an arbitrary number of consecutive Extension Headers, but it's not expected that SNDUs will usually carry a lot 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 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 they 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 🌸
okay bestie, so a bridged SNDU is a Mandatory Extension Header of Type 1 🎀 It MUST be the final (or only) extension header in the header chain of an SNDU, no exceptions 💅 The payload carries MAC address and EtherType [DIX] or LLC Length [ISO-8802-2] fields, plus the contents of a bridged MAC frame. Check out Figures 11 and 12 for the layout ✨
When an NPA address is specified (D=0), Receivers MUST discard every SNDU that carries an NPA destination address that does NOT match their own NPA address (or a broadcast/multicast address) 🙅♀️ The payload of the SNDUs that survive gets handled by the bridging rules that follow. If there's no NPA address (D=1), the Receiver does bridging processing on the payload of every SNDU it receives 🧚
An Encapsulator MAY also use this encapsulation format to directly send network protocol packets that need the LLC encapsulation [IEEE-802.2, ISO-8802-2] 🦋 To do that, it builds an SNDU with a Bridge Extension Header that holds the intended destination MAC address, the MAC source address of the Encapsulator, and the LLC-Length. The PDU is an LLC header followed by the payload it needs. 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= (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 read as either an EtherType [DIX] or an LLC Length field, as specified by IEEE 802 [IEEE-802.3]. It is not 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 they denote unknown, unicast, broadcast, and multicast link addresses 🫶 These MAC addresses point to the intended recipient in the destination LAN, so they have a different job from the NPA addresses in the SNDU header.
A frame Type < 1536 for a bridged frame introduces an LLC Length field. The Receiver MUST check this length and discard any frame with a length greater than the SNDU payload size allows 🚫
In normal operation, any padding added to the Ethernet frame SHOULD be removed before forwarding 🧹 This means the sender has to be aware of that Ethernet padding (e.g., [DIX, IEEE-802.3]).
Ethernet frames that the Encapsulator receives 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 every frame it receives, before any further processing 🔍 Frames with an invalid LAN FCS MUST be discarded 🗑️ After checking, the LAN FCS is removed, so it is NOT forwarded in the bridged SNDU. Like every other ULE frame, the Encapsulator appends a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate LAN-FCS field gets appended to the bridged frame before it's sent onward on the Ethernet interface ✨
This design is easy to implement with existing network interface cards, and it doesn't add an efficiency cost by calculating and verifying two integrity check fields for bridged frames 🙌 However, it also means a frame that gets corrupted during processing at an Encapsulator and/or Receiver might not be caught by the final recipient(s). That 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 💅 Like every Optional Extension, the total length of the extension is shown in the H-LEN field (specified in 16-bit words). The extension field is made up of a group of one to five 16-bit fields.
For this one, only the last 16-bit word has an assigned value. The sender SHOULD set the remaining values to 0x0000 🌸 That last 16-bit field is the Next-Header Type field. A Receiver MUST interpret the Type field, but it MUST ignore any other fields of this Extension Header 🙈
6. Processing at the Encapsulator 👑
The Encapsulator takes the PDUs waiting for transmission and turns them into SNDUs by adding a header and trailer to each PDU (section 4) 💖 Then it segments the SNDU into a series of TS Packet payloads (Figure 13). These get sent over a single TS Logical Channel on a TS Multiplex. The TS Multiplex might go through a bunch of MPEG-2 (re)multiplexors before it's 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 hasn't previously sent a TS Packet for a specific TS Logical Channel, or after an Idle period, it starts sending an SNDU in the first available TS Packet ✨ That first TS Packet MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero, which means the SNDU starts right after the Payload Pointer in the TS Packet payload 🫶
The Encapsulation MUST make sure that every TS Packet sets the MPEG-2 Continuity Counter carried in the TS Packet header, following [ISO-MPEG2]. That value MUST be incremented by one (modulo 16) for each successive TS Packet containing a fragment or complete SNDU sent using the same TS Logical Channel 🔢
An Encapsulator MAY decide not to send another SNDU right away, even if there's space in a partly filled TS Packet. This is called Padding (Figure 14) 🫧 The End Indicator tells the Receiver there are no more SNDUs in this TS Packet payload. After the End Indicator come zero or more unused bytes, running until the end of the TS Packet payload. All unused bytes MUST be set to 0xFF, following current practice in MPEG-2 [ISO-DSMCC] 💜 So basically, Padding trades efficiency for better latency ⏱️
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
IndicatorFigure 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 enough space left in its payload, the Encapsulator can follow a previously encapsulated SNDU with another SNDU, starting at 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
Okay so once an Encapsulator finishes encapsulating an SNDU, there are five things that can happen next 💅 Let's go through them, bestie!
(i) If the TS Packet has no remaining space, the Encapsulator sends this TS Packet off ✈️ and starts the next SNDU in a brand new TS Packet. (The standard rules [ISO-MPEG2] say that new header has to 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 exactly one byte of unused payload, the Encapsulator MUST put 0xFF in that last byte and then send the TS Packet 🫶 This is a super simple fix for the messy situations that can pop up when there's no PUSI set. Squeezing another SNDU in would need a Payload Pointer, and that pointer would eat the very last byte, which is just not it 🙈 MPEG-2 payload types [ISO-DSMCC] do something similar, so this isn't a weird one-off. The Encapsulator MUST start the next SNDU in a new TS Packet. (The standard rules say that header has 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 put 0xFFFF in those final two bytes 🎀 That gives you an End Indicator (section 4.3), and then the TS Packet gets sent. This stops the SNDU Length field from getting split across two TS Packets, which would be chaos 😭 The Encapsulator MUST start the next SNDU in a new TS Packet. (Same deal as before: the standard rules want that header 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 send this partially full TS Packet, but it MUST first fill every remaining unused byte with 0xFF. That means an End Indicator followed by Padding 🧚 Then the Encapsulator MUST start the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] want that header to 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 (that's three bytes if the PUSI was NOT previously set, and two bytes if it was), the Encapsulator MAY pack in more queued PDUs 🌈 It does this by starting the next SNDU in the next available byte of the current TS Packet payload. When the Encapsulator packs more 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 right after the TS Packet header. (Yes, this shaves one byte off the room left for data 😤) The value of the Payload Pointer MUST be set to the position of the byte right after the end of the first SNDU in the TS Packet payload. If no more PDUs are waiting, an Encapsulator MAY hang on for more PDUs to fill up the incomplete TS Packet. The longest an Encapsulator can wait is called the Packing Threshold ⏳ That time MUST be bounded, and it SHOULD be configurable in the Encapsulator. If enough additional PDUs don't show up to complete the TS Packet within the Packing Threshold, the Encapsulator MUST insert an End Indicator (using rule iv) 💔
Using the Packing method (v) is optional for an Encapsulator. It can be decided per-session, per-packet, or per-SNDU, so you get to pick your vibe 💜
Heads up: when an SNDU is smaller than 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). Not required, just allowed!
7. Receiver Processing 🎀
Okay, receiver time! A Receiver tunes into a specific TS Multiplex that's carrying a ULE Stream, then sets a receive filter so it only accepts TS Packets with a specific PID 📡 Those TS Packets belong to one TS Logical Channel, and the Receiver puts them back together into a stream of SNDUs. One Receiver might catch multiple TS Logical Channels, possibly across a bunch of TS Multiplexes, and that's giving multitasking queen 👑 In every case, reassembly MUST be done independently for each TS Logical Channel. To pull that off, the Receiver can use a buffer to hold the partly assembled SNDU, which this document calls the Current SNDU buffer. Other implementations can use different data structures if they want, but they MUST provide equivalent operations ✨
Getting a TS Packet with a PUSI value of 1 means that packet has the start of a new SNDU in it 🦋 It also tells the Receiver that a Payload Pointer is present, and that pointer says how many bytes are until the start of the first SNDU in the TS Packet currently being reassembled. A Payload Pointer value greater than 181 is illegal, and that MUST cause the SNDU reassembly to be aborted and the Receiver to enter the Idle State 🙅♀️ That event SHOULD be recorded as a payload pointer error.
A Receiver MUST support both the Packing and Padding methods for any SNDU it receives, and it MUST support receiving SNDUs with or without a Destination Address Field (so D=0 and D=1 both need to work) 🌸
7.1. Idle State
After initialisation or errors, or when it gets an End Indicator, the Receiver enters the Idle State 😴 While it's in this state, the Receiver throws away all TS Packets until it finds the start of a new SNDU, and then it moves into the Reassembly State. Figure 16 shows these transitions, and yes, it's giving flowchart 💅
+-------+
| 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 every TS Packet it receives 🔍 A PUSI value of 1 means a Payload Pointer is there. After losing synchronisation, Payload Pointer values between 0 and 181 are allowed. In that case, the Receiver MUST discard the number of bytes the Payload Pointer indicates (counted from the first byte of the TS Packet payload field, and not counting the PP field itself) before it leaves the Idle State. Then it enters the Reassembly State and starts reassembling a new SNDU from that point 🧼
7.2. Processing of a Received SNDU
Once it's in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload 📏 If that value is less than or equal to 4, or equal to 0xFFFF, the Receiver throws out the Current SNDU and the rest of the TS Packet payload, then goes back to the Idle State. Getting an invalid Length field counts as an error event, and it SHOULD be recorded as an SNDU length error.
If the Length of the Current SNDU is greater than 4, the Receiver copies bytes from the TS Packet payload into the Current SNDU buffer until it has either Length bytes in total or it reaches the end of the TS Packet (see also 7.2.1) 🧺 When the Current SNDU length equals the Length field value, the Receiver MUST calculate and verify the CRC value (see 4.6). Any SNDU with an invalid CRC value MUST be discarded. A CRC mismatch is an error event and SHOULD be recorded as a CRC error. Real physical-layer processing (like forward error correction coding) often leads to patterns of errors instead of single bit flips, so the Receiver has to be tough enough to handle any pattern of corruption in the TS Packet and payload. That includes possibly corrupted PUSI, PP, and SNDU Length fields 🛡️ So after a CRC mismatch, a Receiver SHOULD discard the rest of the TS Packet payload (if there's any) 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 it has been given. That set includes the NPA address of the Receiver, the NPA broadcast address, and any required multicast NPA addresses 📬 The Receiver MUST silently discard any SNDU with an address that doesn't match.
After a valid SNDU comes in, the Receiver MUST check the Type field (and process any Type 1 Extension Headers) 🔎 Then the SNDU payload gets passed up to the next protocol layer that's specified. An SNDU with an unknown Type value less than 1536 MUST be discarded, and that error event SHOULD be recorded as an SNDU type error.
After that, the Receiver starts reassembling the next SNDU. That one MAY come right after the previous SNDU inside the same TS Packet payload 🔁
(i) If the Current SNDU finishes right at the end of a TS Packet payload, the Receiver MUST enter the Idle State.
(ii) If only one byte is left unprocessed in the TS Packet payload after the Current SNDU is done, the Receiver MUST discard that final byte and then enter the Idle State. It MUST NOT record an error when that remaining byte is 0xFF, because that's just normal padding behaviour 🙌
(iii) If two or more bytes of TS Packet payload data are left after the Current SNDU is done, the Receiver takes the next 2 bytes and checks whether they're an End Indicator 🛑 When it gets one, a Receiver MUST silently discard the rest of the TS Packet payload and transition to the Idle State. Otherwise, that's the start of the next Packed SNDU, so the Receiver keeps processing it. (That only works if the TS Packet has a PUSI value of 1, see 7.2.1. If it doesn't, the Receiver has detected a delimiting error and MUST discard all remaining bytes in the TS Packet payload and transition to the Idle State.)
7.2.1. Reassembly Payload Pointer Checking
A Receiver that has partly received an SNDU (sitting in the Current SNDU buffer) MUST check the PUSI value in the header of every later TS Packet with the same PID, which means the same TS Logical Channel 🕵️♀️ If it gets 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 still needed to finish the Current SNDU (that's the SNDU Length field minus the number of bytes already reassembled), the Receiver has detected a delimiting error 🚨
After a delimiting error, the Receiver MUST throw away the partly assembled SNDU (in the Current SNDU buffer), and it SHOULD record a reassembly error. Then it MUST re-enter the Idle State 💖
7.3. Other Error Conditions 🎀
Okay so bestie, the Receiver SHOULD check the MPEG-2 Transport Error Indicator in the TS Packet header [ISO-MPEG2] 👀 This flag is basically the TS Logical Channel saying "hey, something went wrong in transmission" 😭 If it's set to one, a transmission error event SHOULD be recorded. Any partially received SNDU MUST be discarded, and then the Receiver enters the Idle State 🧚
The Receiver MUST check the MPEG-2 Continuity Counter in the TS Packet header [ISO-MPEG2] 💖 If two (or more) successive TS Packets in the same TS Logical Channel carry the same Continuity Counter value, the duplicate TS Packets MUST be silently discarded 🙈 If the received value is not identical to the one in the previous TS Packet, and it does not go up by one for successive TS Packets (modulo 16), the Receiver has detected a continuity error 💀 Any partially received SNDU MUST be discarded, a continuity counter error event SHOULD be recorded, and then the Receiver enters the Idle State ✨
Note that an MPEG2-2 Transmission network is permitted to carry duplicate TS Packets [ISO-MPEG2], which are normally detected by the MPEG-2 Continuity Counter. A Receiver that does not perform the above Continuity Counter check would accept duplicate copies of TS Packets to the reassembly procedure. In most cases, the SNDU CRC-32 integrity check will result in discard of these SNDUs, leading to unexpected PDU loss; however, in some cases, duplicate PDUs (fitting into one TS Packet) could pass undetected to the next layer protocol. 😱
8. Summary 🌸
This document defines a Unidirectional Lightweight Encapsulation (ULE) that performs efficient and flexible support for IPv4 and IPv6 network services over networks built upon the MPEG-2 Transport Stream (TS). The encapsulation is also suited to transport of other protocol packets and bridged Ethernet frames. 🦋
ULE also provides an Extension Header format and defines an associated IANA registry for efficient and flexible support of both mandatory and optional SNDU headers. This allows for future extension of the protocol, while providing backwards compatibility with existing implementations. In particular, Optional Extension Headers may safely be ignored by Receivers that do not implement them, or choose not to process them. 🫶
9. Acknowledgements 🫶
This document is based on a previous document authored by: Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst. The authors wish to thank the members of the ip-dvb mailing list for their input; in particular, the many comments received from Art Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and William Stanislaus. Alain also provided the original examples of usage. 👑
10. Security Considerations 💀
Security is serious, bestie, so read this part carefully 🚨
The security considerations for ULE resemble those that arise when the existing Multi-Protocol Encapsulation (MPE) is used. ULE does not add specific new threats that will impact the security of the general Internet. 🛡️
There is a known security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2). 😬
There are known integrity issues with the removal of the LAN FCS in a bridged networking environment. The removal for bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver. 😭
There is a potential security issue when a Receiver receives a PDU with two Length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. In direct encapsulation of IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length Field. However, this issue still arises in bridged LLC frames, and frames with a LLC Length greater than the SNDU payload size MUST be discarded, and an SNDU payload length error SHOULD be recorded. 🚩
In the future, a ULE Mandatory Extension Header may be used to define a method to perform link encryption of the SNDU payload. This is as an additional security mechanism to IP-, transport-, or application-layer security, not a replacement [RFC4259]. The approach is generic and decouples the encapsulation from future security extensions. The operation provides functions that resemble those currently used with the MPE encapsulation. 🔐
Additional security control fields may be provided as part of this link encryption Extension Header, e.g., to associate an SNDU with one of a set of Security Association (SA) parameters. As a part of the encryption process, it may also be desirable to authenticate some or all of the SNDU headers. The method of encryption and the way in which keys are exchanged is beyond the scope of this specification, as are the definition of the SA format and that of the related encryption keys. 🗝️
11. IANA Considerations 🧚
The IANA has created the ULE Next-Header Type field registry as defined in this document.
ULE Next-Header registry
This registry allocates Next-Header values within the range 0-511 (decimal). For each allocated value, it also specifies the set of allowed H-LEN values (see section 5). In combination, these define a set of allowed values in the range 0-1535 for the first part of the ULE Type space (see section 4.4.1). ✨
11.1. IANA Guidelines 📋
The following contains the IANA guidelines for management of the ULE Next-Header registry. This registry allocates values 0-511 decimal (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than 0x01FF (decimal).
It subdivides the Next-Header registry in the following way:
- 0-255 (decimal) IANA-assigned values, indicating Mandatory Extension Headers (or link-dependent Type fields) for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification MUST define the value and the name associated with the Extension Header, together with the procedure for processing the Extension Header. It MUST also define the need for the Mandatory Extension and the intended use. The size of the Extension Header MUST be specified.
Assignments have been made in this document, and registered by IANA:
Type Name Reference
0: Test-SNDU Section 5.1
1: Bridged-SNDU Section 5.2- 256-511 (decimal) IANA-assigned values, indicating Optional Extension Headers for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification MUST define the value and the name associated with the Extension Header, together with the procedure for processing the Extension Header. The entry MUST specify the range of allowable H-LEN values that are permitted (in the range 1-5). It MUST also define the need for the Optional Extension and the intended use.
Assignments have been made in this document, and registered by IANA:
Type Name H-LEN Reference
256: Extension-Padding 1-5 Section 5.312. References 📚
12.1. Normative References 🔖
[ISO-MPEG2]IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000.[RFC2119]Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997.[RFC1112]Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.[RFC2464]Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.[ULE1]Registration for format_identifier ULE1, SMPTE Registration Authority, LLC, http://www.smpte-ra.org/ule1.html.
12.2. Informative References
okay so these are the background reads 🧚 they're informative, not normative, so they're here for context and not as required reading
- [IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 Networks", Work in Progress, September 2005.
- [ATSC] A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53 Rev.C, 2004
- [ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000.
- [ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001.
- [ATSC-G] A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995.
- [ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 2003.
- [ATSC-REG] ATSC "Code Point Registry" www.atsc.org/standards/Code_Point_Registry.pdf.
- [ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 1999.
- [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982.
- [ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI), 2004.
- [ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI), 1998.
- [ETSI-DVBS] EN 300 421, "Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI), 1997.
- [ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T)", European Telecommunications Standards Institute (ETSI), 2004.
- [ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI), 2005.
- [IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks- Specific requirements Part 2: Logical Link Control", IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
- [IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks- Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Computer Society, (also ISO/IEC 8802-3), 2002.
- [ISO-DSMCC] IS 13818-6, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC", International Standards Organisation (ISO), 1998.
- [ITU-H222] H.222.0, "Information technology - Generic coding of moving pictures and associated audio information: Systems", International Telecommunication Union, (ITU-T), 1995.
- [ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, (ITU-T), 1996.
- [ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International Standards Organisation (ISO), 1998.
- [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001.
- [RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
- [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
- [SOOR05] M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-Nocker, H. Linder, W. Stering "A Lightweight Encapsulation Protocol for IP over MPEG-2 Networks: Design, Implementation and Analysis", Computer Networks 48 p5-19, 2005.
Appendix A: SNDU Packing Examples 🎀
this appendix is full of examples, bestie 💖 it's informative, so it isn't a description of the protocol. it just walks through the complete TS Packet sequence for some sample encapsulated IP packets
the TS Packet header operation and field values are specified in [ISO-MPEG2], and the ULE spec lives in the body of this document ✨
here's the key we'll use for all the examples:
HDR 4B TS Packet Header
PUSI Payload Unit Start Indicator
PP Payload Pointer
*** TS Packet Payload Pointer (PP)Example A.1: Two 186B PDUs.
SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address)
the sequence comprises 3 TS Packets 🦋
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU
PP=17 CRC for A Length
+-----+------+------+- -+--- --+------+------+- -+------+
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
+-----+----*-+------+- -+------+-*----+------+- -+------+
PUSI=1 * *
*************************
End Stuffing
CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+
PUSI=0Example A.2: Usage of last byte in a TS-Packet
SNDU A is 183 bytes SNDU B is 182 bytes SNDU C is 181 bytes SNDU D is 185 bytes
the sequence comprises 4 TS Packets, and this one's a whole vibe 💅
SNDU
PP=0 Length CRC for A
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU Unused
PP=0 Length CRC for B byte
+-----+------+------+------+- -+------+------+
| HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+-----+---*--+-*----+------+- -+------+------+
PUSI=1 * *
******
SNDU SNDU
PP=0 Length CRC for C Length
+-----+------+------+------+- -+------+------+------+
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * *
****** Unused
byte
+-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+
PUSI=0Example A.3: Large SNDUs
SNDU A is 732 bytes SNDU B is 284 bytes
the sequence comprises 6 TS Packets 🌸
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0Example A.4: Illustration of SNDU Length field
SNDU A is 200 bytes SNDU B is 60 bytes SNDU C is 60 bytes
the sequence comprises two TS Packets, and the Length field is the star of the show 🧚
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * * + +
***** ++++++++
+
+++++++++++++++++
+ SNDU
PP=17 CRC for A + Length
+-----+------+------+- -+------+-+----+------+-
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
+-----+----*-+------+- -+------+*-----+------+-
PUSI=1 * * + +
************************ +++++++++
+
+++++++++++++++++++++++++++++++++++++++
+
+ SNDU End Stuffing
+ Length Indicator bytes
+ -+------+------+------+ -+------+------+------+- -+------+
+ ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++ ++++++++++++++++++++++
*** TS Packet Payload Pointer (PP)
+++ ULE Length IndicatorExample A.5: Three 44B PDUs.
SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52 bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE destination NPA address)
the sequence comprises 1 TS Packet, and it's a tight squeeze 💜
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-----+------+- -+-----+---------+- -+------+Appendix B: SNDU Encapsulation ✨
Okay bestie, this is the big payoff 💖 It's a real example of ULE encapsulation carrying an ICMPv6 packet that ping6 generated. You can check every byte against the spec, so grab a snack and let's walk through it 🍓
ULE SNDU Length : 63 decimal
D-bit value : 0 (NPA destination address present)
ULE Protocol Type : 0x86dd (IPv6)
Destination ULE NPA Address : 00:01:02:03:04:05
ULE CRC32 : 0x7c171763So the SNDU is 63 bytes long 🎀. The D-bit is 0, which means the NPA destination address is there 🦋. The protocol type is 0x86dd, which is IPv6 ✨, and the destination NPA address is 00:01:02:03:04:05 🌸. Last but not least, the CRC32 is 0x7c171763 💅.
Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6 : 2001:DB8:2509:1962::2These are the IPv6 addresses sitting inside the packet, a source of 2001:DB8:3008:1965::1 and a destination of 2001:DB8:2509:1962::2 🧚
Now the actual bytes. This is the SNDU contents, including the CRC-32 at the end 👑
SNDU contents (including CRC-32):
0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d
0016: 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00
0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00
0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c
0064: 17 17 63Look at that first row, it's giving length field plus protocol type plus NPA address all at once 🙈 Then the trailer ends with the CRC bytes 7c 17 17 63 😭 The whole thing is iconic, no cap 🔥
Authors' Addresses
Here's who wrote this 🫶 The first author is Godred Fairhurst:
Godred Fairhurst
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
UK
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/GorryAnd the second author is Bernhard Collini-Nocker:
Bernhard Collini-Nocker
Department of Scientific Computing
University of Salzburg
Jakob Haringer Str. 2
5020 Salzburg
Austria
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/Full Copyright Statement
The copyright belongs to The Internet Society (2005) 💜 The document is covered by the rights, licenses and restrictions in BCP 78. Apart from what that says, the authors keep all their own rights 🌈
This document and everything in it is given to you "AS IS" 💀 The contributor, the organization they represent or are sponsored by (if any), The Internet Society, and the IETF all say no to any warranties, whether they're spelled out or implied. That includes no promise that using the info won't infringe anyone's rights, and no promise of merchantability or fitness for a particular purpose 🙅♀️
Intellectual Property
The IETF stays neutral 🧘♀️ It doesn't say whether any intellectual property rights or other rights that might apply to this technology are valid or how wide they reach. It also doesn't say whether you could get a license for them. And it hasn't tried to track any of these rights down on its own 🕵️♀️ If you want the rules on rights for RFC documents, check out BCP 78 and BCP 79 ✨
Copies of IPR disclosures sent to the IETF Secretariat are available, and so are any promises of licenses. The same goes for the results of any attempt to get a general license or permission for implementers or users to use the proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬
Acknowledgement
Funding for the RFC Editor function is currently coming from The Internet Society 🌸 Thank you for keeping the lights on, bestie 🫶✨
📦 where this page comes from
- ietf: rfc4326 2005-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms