RFC 5163
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE) 🦋
Okay bestie, this is RFC 5163 💖, a Standards Track doc from the Network Working Group ✨. It was written by G. Fairhurst (University of Aberdeen) and B. Collini-Nocker (University of Salzburg), and it's dated April 2008 🌸. The whole thing is about extension headers for ULE and GSE, so let's get into it 💅.
Status of This Memo 📜
This document is an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements 🫶. For the 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 🌈.
Abstract 🌈
So this doc describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), which is defined in RFC 4326 💜.
The Extension Header formats in here are built to work for both ULE and the Generic Stream Encapsulation (GSE), and they're made for the second-generation framing structure from the Digital Video Broadcasting (DVB) family of specifications 🔥.
Table of Contents 🗂️
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Description of the Method .......................................4
3.1. MPEG-2 TS-Concat Extension .................................5
3.2. PDU-Concat Extension .......................................8
3.3. TimeStamp Extension .......................................12
4. IANA Considerations ............................................13
5. Acknowledgments ................................................13
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. The Second-Generation DVB Transmission
Specifications .................................................161. Introduction ✨
Okay so this section is about three Extension Headers that can be used with both ULE [RFC4326] and GSE [GSE] 🎀. ULE is made for links that use the MPEG-2 Transport Stream, and it's giving versatility because it supports a wide variety of physical-layer bearers [RFC4259] 🧚.
GSE is designed for the Generic Mode (also called the Generic Stream (GS)), which is offered by second-generation DVB physical layers, and at first it's aimed at DVB-S2 [ETSI-S2] 🛰️. The requirements for the Generic Stream are in [S2-REQ], and the important characteristics of this encapsulation are covered in the appendix of this document 📖. GSE keeps a design philosophy where its network interface is common to the one ULE presents, and it uses a similar construction for SubNetwork Data Units (SNDUs) 💅.
The first Extension Header is a method that lets one or more TS Packets [ISO-MPEG2] be sent within a ULE SNDU 🎬. This method may be used to provide control plane information, including the transmission of MPEG-2 Program Specific Information (PSI) for the Multiplex 🧠. GSE has no native support for Transport Stream packets, so this method is a good fit for providing an MPEG-2 control plane 🌸.
A second Extension Header lets one or more PDUs be sent within the same ULE SNDU 🍓. It's made for cases where a large number of small PDUs are headed to the same Network Point of Attachment (NPA) address 💜. The method may improve transmission efficiency by removing duplicated MAC layer overhead ✨. It can also cut down on processing overhead for a receiver that isn't configured to receive the NPA address linked to an SNDU, so that receiver can skip several PDUs in one operation 🙈. This method is defined as a generic Extension Header, so it may be used for IPv4 or IPv6 packets 🦋. If, and when, a compression format is defined for ULE or Ethernet, the method may also be used in combination with this method 👑.
A third Extension Header gives an optional TimeStamp value for an SNDU ⏱️. Examples of using this TimeStamp option include monitoring and benchmarking of ULE and GSE links 📊. Receivers that don't want to decode the TimeStamp extension (or don't support it) may discard the extension and process the remaining PDU or Extension Headers 🫧.
The appendix has a summary of key design issues and considerations for the GSE Specification defined by the DVB Technical Module [GSE] 🎀.
2. Conventions Used in This Document 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔑.
Here's the glossary, so we're all on the same page 📚:
- b: bit. For example, one byte consists of 8b.
- B: byte. Groups of bytes are represented in Internet byte order.
- BBFrame payload: The data field part of a Baseband frame [ETSI-S2] that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits, depending on the choice of modulation format and Forward Error Correction (FEC) in use.
- DVB: Digital Video Broadcasting. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data 📺.
- E: A one-bit flag field defined in GSE [GSE].
- Encapsulator: A network device [RFC4259] that receives PDUs and formats these into Payload Units (known here as SNDUs) for output in DVB-S or the Generic Mode of DVB-S2.
- GS: Generic Stream. A stream of BBFrames identified by a common Input Stream Identifier, which does not use the MPEG-2 TS format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model.
- GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating PDUs to form a Generic Stream, which is sent using a sequence of BBFrames. This encapsulation format shares the same extension format and basic processing rules as ULE, and it uses a common IANA Registry 🧁.
- LT: A two-bit flag field defined in GSE [GSE].
- MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard.
- MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Organization for Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
- Next-Header: A Type value indicating an Extension Header [RFC4326].
- NPA: Network Point of Attachment [RFC4326]. In this document, it refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network, used to identify individual Receivers or groups of Receivers 📍.
- PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of each TS Packet. It identifies the TS Logical Channel that a TS Packet belongs to [ISO-MPEG2]. The TS Packets that form the parts of a Table Section or other Payload Unit must all carry the same PID value. The all-ones PID value indicates a Null TS Packet, which is introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes 🔢.
- PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets 📦.
- PSI: Program Specific Information [ISO-MPEG2].
- S: A one-bit flag field defined in [GSE].
- SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that has been defined by another standards body to convey information about the services carried on a DVB Multiplex 📡.
- SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an encapsulated PDU sent using ULE or GSE 🎁.
- Stream: A logical flow from an Encapsulator to a set of Receivers 🌊.
- TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets. It represents layer 2 of the ISO/OSI reference model.
- ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs, which are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry 💖.
3. Description of the Method 🎀
In ULE, a Type field value less than 1536 in decimal indicates an Extension Header ⚠️.
This section describes a set of three extension formats for the ULE encapsulation 🧚. [GSE] uses a Type field that has the same semantics as specified by RFC 4326. The encapsulation format is different in that GSE doesn't include a Cyclic Redundancy Check (CRC) for each SNDU, it has different header flags, and it uses a different SNDU length calculation [GSE] 🔍.
There's a natural ordering of Extension Headers, decided by the fields that each Extension Header operates on ✨. A suitable ordering for many applications is shown in the table below (from first to last header within an SNDU). This doesn't mean that all types of Extensions should be present in a single SNDU 🙅♀️. The ordering shown may serve as a guideline for optimizing Receiver processing 🏆.
+----------------------------------+-------------------------------+
|Fields related to Extension Header| Example Extension Headers |
+----------------------------------+-------------------------------+
| Link framing and transmission | TimeStamp Extension |
+----------------------------------+-------------------------------+
| Entire remaining SNDU Payload | Encryption Extension |
+----------------------------------+-------------------------------+
| Group of encapsulated PDUs | PDU-Concat or TS-Concat |
+----------------------------------+-------------------------------+
| Specific encapsulated PDU | IEEE-defined type |
| | Test or MAC bridging Extension|
+----------------------------------+-------------------------------+
Table 1: Recommended ordering of Extension Headers3.1. MPEG-2 TS-Concat Extension ✨
Okay bestie, the MPEG-2 TS-Concat Extension Header is the one with the IANA-assigned H-Type value of 0x0002 in hex 💖. It's a Mandatory Extension Header, so no skipping it 🫶.
This extension carries one or more MPEG-2 TS Packets inside a ULE SNDU 📦. How many TS Packets are in a given SNDU comes from the size of whatever's left of the payload after the MPEG-2 TS Extension Header. So the count is (Length-N-10+D*6) / 188, where N is the number of bytes used by any Extension Headers sitting in front of the MPEG-2 TS-Concat Extension (zero if there aren't any), and D is the value of the D-bit 🧚.
A Receiver MUST check the validity of the Length value before it processes the payload 👀. A valid Length is an integral number of TS Packets. If the Length is invalid (meaning there's a remainder from dividing by 188), the Receiver MUST discard all the encapsulated TS Packets, and it SHOULD record that as a TS-Concat size mismatch error 🙈.
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 = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)Figure 1 shows this Extension Header for ULE with D=0, which means an NPA address is present [RFC4326] 🌸. In that case, the valid payload Length for a ULE SNDU with no other extensions is (Length-10) / 188 ✨.
GSE defines Length differently from ULE 🎀. The equivalent GSE case would give a payload Length of (Length-6) / 188 (Figure 2) 💅.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)Fragmented GSE SNDUs are protected by a CRC-32 that rides in the final fragment 🛡️. Once they're reassembled, that CRC-32 gets removed and the resulting SNDU carries a Total Length field 🧩. The S and E fields are defined by [GSE], and they hold control flags for the GSE link layer 🚦. The Label Type (LT) field tells you whether the GSE label is there and what format it's in 🏷️. The LT field is only specified for the first fragment (or a non-fragmented GSE SNDU), meaning when S=1 🥹.
In ULE, D=1 is also allowed, and it means there's no NPA address (Figure 3) 💜. GSE supports a similar format too 🦋.
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 = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)The TS-Concat extension can carry one or more MPEG-2 TS Packets with arbitrary content, interpreted according to [ISO-MPEG2] 🎬. One expected use is sending MPEG-2 SI/PSI signalling [RFC4259] 📡.
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this encapsulation 🚫. To cut down on transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time it can wait before sending all queued TS Packets. This is called the TS Packing Threshold ⏱️. This value MUST be bounded and SHOULD be configurable in the Encapsulator 🔧. A larger value can improve efficiency, but it brings higher jitter and could increase the probability of corruption 😬. If additional TS Packets are not received within the TS Packing Threshold, the Encapsulator MUST immediately send any queued TS Packets 🏃♀️💨.
Timing is a whole thing, bestie. Using this format to transfer MPEG-2 clock references (for example, a Network Clock Reference, NCR) over ULE/GSE framing raises timing considerations at the encapsulation gateway. That includes the need to update or modify the timing information before the physical layer transmits it. The document doesn't cover these issues. It does note that this operation may be simplified in GSE by making sure all SNDUs that carry this Extension Header are placed before other data within the BBFrame DataField [GSE] ⏳✨.
This document does not specify how TS Packets are handled at the Receiver 🤷♀️. However, it does note the following 📝:
- A Receiver needs to consistently associate all TS Packets in a Stream with one TS Logical Channel (Stream). If an Encapsulator transmits more than one Stream of TS Packets, each encapsulated at a different level or with a different NPA address, a Receiver needs to ensure each one is independently demultiplexed as a separate Stream (Section 3.2 [RFC4259]) 🗂️.
- If an Encapsulator transmits service information encapsulated at different levels or with different NPA addresses, Receivers need to ensure each Stream is related to the corresponding SI table information (if any). A RECOMMENDED way to reduce signaling interactions is to make sure each PID value uniquely identifies a Stream within a TS Multiplex carrying ULE, and also any TS Packets encapsulated by a ULE/GSE Stream 🆔💖.
The need for consistency in the use of PIDs and the related service information is described in section 4.2 of [RFC4947] 🌈.
3.2. PDU-Concat Extension ✨
okay bestie, this one is the PDU-Concat Extension 💖 It has an IANA-assigned H-Type value of 0x0003 in hex 🦋, and it's a Mandatory Next-Header Extension, so no skipping it. Its whole job is letting you send a bunch of short PDUs inside one SNDU Payload. Iconic 💅
The base header has the Length of the entire SNDU 📦. That's the combined length of all the PDUs you're packing, including each set of encapsulation headers. The base header MAY be followed by one or more extra Extension Headers that come before the PDU-Concat Extension Header (a TimeStamp Extension would be a good example 🕰️). Those apply to the whole composite concatenated PDU, so they're basically the main character of the bundle 👑
The Extension Header also has a 16-bit ULE Type field called PDU-Concat-Type, which describes the encapsulated PDU 🎀. You can put any Type value from the ULE Next-Header Registry on it (extension header Types included!) except the recursive use of a PDU-Concat type. No concat-inside-concat, bestie 🙈 But all concatenated PDUs MUST have a common ULE Type, so every PDU the network layer passes over has to share the same Type value. This keeps the receiver design simple and cuts down on overhead for common use cases 🧚
Each PDU gets prefixed with its length in bytes (the diagrams call these PDU-x-Length for the xth PDU) 🔢. Encapsulated PDUs can be any length, and they're not necessarily aligned to 16-bit or 32-bit boundaries inside the SNDU (see Figures 4, 5, and 6). No alignment vibes here 🙃 The most significant bit of the first byte is reserved, which is the R bit, and this specification says it MUST be set to zero. Receivers MUST ignore the value of the R bit. Also, the length of each PDU MUST be less than 32758 bytes, though they'll usually be way smaller 🌸
When the SNDU header has an SNDU Destination Address field (that's D=0 in ULE), 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 hex, that identify the Receiver(s) on a transmission network who should process the SNDU. When it's present, the Receiver MUST associate the same specified MAC/NPA address with all PDUs in the SNDU Payload. That MAC/NPA address MUST also get forwarded with each PDU, if the forwarding interface needs it 💌
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 = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)
When the SNDU header has no SNDU Destination Address field (that's D=1 in ULE), all the encapsulated PDUs MUST be processed as if they'd arrived without an NPA address 🙅
The D value in the ULE header tells you whether an NPA/MAC address is in use [RFC4326]. GSE has a similar format too, using the LT field 🧩
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 = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU-Concat-Type |R| PDU-1-Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
To cut down on transmission overhead and processing, an Encapsulator SHOULD set a maximum period of time it'll wait before sending a Concatenated PDU ⏱️. This is known as the PDU Packing Threshold. That value MUST be bounded and SHOULD be configurable in the Encapsulator. A bigger value can boost efficiency, but it brings higher jitter and could increase the chance of corruption 😬 If additional PDUs are not received within the PDU Packing Threshold, the Encapsulator MUST immediately send all the queued PDUs 🚀
The receiver handles this Extension Header by checking that it supports the specified PDU-Concat Type. Unsupported Types MUST be discarded, but the receiver SHOULD record a PDU-Type error [RFC4326] 🕵️ Then it pulls out each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also make sure that the sum of the Lengths of all processed PDUs equals the Length in the SNDU base header 🧮 A Receiver SHOULD discard the whole SNDU if the total and PDU sizes don't match, and this event SHOULD be recorded as a PDU-Concat size mismatch error 🗑️ A receiver MUST NOT forward a partial PDU whose indicated PDU-Length is greater than the number of unprocessed bytes left in the SNDU payload field 🚫
3.3. TimeStamp Extension ⏰
The TimeStamp Extension Header is an Optional Extension Header that lets an Encapsulator add a TimeStamp field to an SNDU ⏰ It's specified by the IANA-assigned H-Type value of 257 decimal. This extension is an Optional Extension Header ([RFC4326], Section 5).
This extension is built for monitoring and measuring how a link performs, so you can tell how healthy an operational ULE link is 📊 It may be super useful for GSE links, where the scheduling from the lower layers can get really complicated 🌀 Possible uses include:
- Validation of in-sequence ordering per Logical Channel
- Measurement of one-way delay (when synchronized with the sender)
- Measurement of PDU Jitter introduced by the link
- Measurement of PDU loss (with additional information from sender)
Figure 7 shows the format of this extension. A HLEN value of 3 means a TimeStamp of length 4B with a Type field (and there's no implied byte-alignment) 🎯
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | TimeStamp HI |
+---------------+---------------+---------------+---------------+
| TimeStamp LO | Type |
+---------------+---------------+---------------+---------------+Figure 7: Format of the 32-bit TimeStamp Extension Header
The extension carries a 32-bit value (TimeStamp HI plus TimeStamp LO). The specified resolution is 1 microsecond, so the value is the number of 1-microsecond ticks past the hour in Universal Time when the PDU was encapsulated ⏳ This value may be earlier than the time of transmission, due to things like Packing, queuing, and other Encapsulator processing 📦 The value is right-justified to the 32-bit field. Systems that can't insert TimeStamps at the specified resolution MUST pad the unused least-significant bits with a value of zero 🧸
The last two bytes carry a 16-bit Type field. It says what type of payload the SNDU carries, or whether there's a further Next-Header ([RFC4326], Section 4.4) 🎁
Receivers MAY process the TimeStamp when the PDU encapsulation is removed. Receivers that do not implement the TimeStamp Extension, or do not wish to process it, MAY skip this Extension Header. Receivers MUST continue to process the remainder of the SNDU and forward the encapsulated PDU 💜
4. IANA Considerations ✨
okay so IANA handed out three brand new Next-Header Type values from the IANA ULE Next-Header Registry 🎀 these were made for the specific jobs GSE needed, but they still play nicely with ULE 🫶
the assignments made in this doc and registered by IANA are:
Type Name Reference
2: TS-Concat Section 3.1
3: PDU-Concat Section 3.2
Type Name H-LEN Reference
257: TimeStamp 3 Section 3.3the TS-Concat Extension is a Mandatory next-type Extension Header 💅 it's defined in Section 3.1 of this doc, and its next-header value is the IANA assigned H-Type value 0x0002 🦋
the PDU-Concat Extension is also a Mandatory next-type Extension Header, specified in Section 3.2 of this doc 🌸 its next-header value is the IANA assigned H-Type value 0x0003 ✨
the TimeStamp Extension is an Optional next-type Extension Header, specified in Section 3.3 🧚 its next-header value is the IANA assigned H-Type value 257 decimal. this doc defines the format for an HLEN value of 0x3. ⭐
5. Acknowledgments 🫶
the authors are so grateful to the DVB-GBS ad hoc group on DVB-S2 encapsulation for all their inputs, comments and help 💖 a special shoutout to Rita Rinaldo, Axel Jahn, and Ulrik De Bie for their contributions on DVB-S2 transmission aspects 🌈
Juan Cantillo gave a huge contribution to the informative appendix 👑 and the authors thank Christian Praehauser for his insight and contribution on Extension Header processing issues 🙌
6. Security Considerations 🔥
okay bestie, this part is serious, so pay attention 💀
the security considerations for ULE live in [RFC4326] 📖 and more info on security aspects of using ULE is in the security considerations of [RFC4259] and [Sec-Req] 🔐
an attacker who can inject arbitrary TS Packets into a ULE or GSE Stream can modify the layer 2 signalling information sent by the MPEG-2 TS-Concat extension 🚨
since this attack needs access to the link and/or layer 2 equipment, it could also directly attack signalling info sent as native TS Packets (the ones not encapsulated by ULE/GSE) 😭 security issues around sending and interpreting layer 2 signalling info (including Address Resolution) inside a TS Multiplex are described in [RFC4947] 🦋 and the use of security mechanisms to protect the MPEG-2 signalling info is discussed by [Sec-Req] 🔒
7. References 📚
7.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC4326]Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.[GSE]TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards, Institute (ETSI), 2007.
7.2. Informative References
[ETSI-S2]EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI).[S2-REQ]Cantillo, J. and J. Lacan, "A Design Rationale for Providing IP Services over DVB-S2 Links", Work in Progress, December 2006.[Sec-Req]Cruickshank, H., Iyengar, S., and P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, November 2007.[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 802.3, IEEE Computer Society, (also ISO/IEC 8802-3), 2002.[ISO-MPEG2]ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Organization for Standardization (ISO), 2000.[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.[RFC4947]Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
Appendix A. The Second-Generation DVB Transmission Specifications 🛰️
this bit is informative background on the network-layer stuff for the second-gen DVB Transmission Specs 🧠 the second-gen waveforms have two big upgrades. first, the physical layer got more efficient, using higher-order modulation with stronger FEC, and it can do adaptive coding and modulation that responds to changes in traffic and propagation conditions 📡 second, at the link layer there's way more flexibility in framing 🎀
support covers a bunch of stream formats, including the classic Transport Stream (TS) [RFC4259] ✨ there's also a newer method called Generic Stream (GS) (or the Generic Mode), and a GS can be packetized or continuous. it's meant to give native transport for other network-layer services, and one of those is the Generic Stream Encapsulation (GSE) [GSE] 🦋
for example, the DVB-S2 [ETSI-S2] transmission link sequentially multiplexes a series of baseband frames (BBFrames) 🧩 each BBFrame has a fixed-size 10B header plus a payload. the payload carries a DataField and uses padding to fill any unused space. a stream is a sequence of BBFrames tied to an Input Stream Identifier (ISI), which lives in the header of each BBFrame. the simplest setup uses one stream (with just one ISI value), but multiple streams are allowed 💅 the BBFrames in a stream can be variable size (picked from a set of allowed sizes), and they have to use the same stream format (TS or GSE, so i.e. the same one). each stream is its own independent link with independent address resolution [RFC4947] 🔗
GSE gives you the same functions as Unidirectional Lightweight Encapsulation (ULE) [RFC4326] ✨ it supports sending IP packets and other network-layer protocols. the network-layer interface looks a lot like ULE's: it uses common mechanisms for a Length field, a 16-bit Type field, and support for Extension Headers 💖 just like ULE, GSE allows multiple address formats, indicated by the LT field (which is functionally the same as the D field in ULE). the default addressing mode uses a 6-byte NPA and a suppressed NPA address (functionally equivalent to D=1 in ULE) 🌸
GSE also has more flexible fragmentation at the interface to the physical layer, using the S and E flags 🧚 this adapts the SNDUs to a variable-sized link-layer frame, and it deals with the more complex fragmentation and assembly needs that show up when you use point-to-multipoint adaptive physical layers 🌈 the integrity of a reassembled SNDU is checked with a CRC-32 in the last fragment for the matching PDU 🔍
Authors' Addresses 💌
Godred Fairhurst
- School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE, UK
- EMail:
gorry@erg.abdn.ac.uk - URI:
http://www.erg.abdn.ac.uk/users/gorry
Bernhard Collini-Nocker
- Department of Computer Sciences, University of Salzburg, Jakob Haringer Str. 2, 5020 Salzburg, Austria
- EMail:
bnocker@cosy.sbg.ac.at - URI:
http://www.cosy.sbg.ac.at
Full Copyright Statement ©
Copyright (C) The IETF Trust (2008).
this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🫶
this document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💀
Intellectual Property 📜
the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology in this doc, or on whether any license under those rights might or might not be available. it also doesn't say it has made any independent effort to find such rights 🙈 info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖
copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this spec to use those proprietary rights, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🔗
the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 💜
📦 where this page comes from
- ietf: rfc5163 2008-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms