Network Working Group G. Fairhurst
Request for Comments: 5163 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
April 2008
Network Working Group G. Fairhurst
Request for Comments: 5163 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
April 2008
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
单向轻量级封装（ULE）和通用流封装（GSE）的扩展格式
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.
本文档描述了单向轻量级封装（ULE）RFC 4326的一组扩展头。
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications.
本文件中规定的扩展头格式定义了适用于ULE和通用流封装（GSE）的扩展，用于数字视频广播（DVB）规范系列定义的第二代帧结构。
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 .................................................16
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 .................................................16
This document describes three Extension Headers that may be used with both the Unidirectional Lightweight Encapsulation (ULE) [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links that employ the MPEG-2 Transport Stream, and supports a wide variety of physical-layer bearers [RFC4259].
本文档描述了三个扩展头，它们可以与单向轻量级封装（ULE）[RFC4326]和通用流封装（GSE）[GSE]一起使用。ULE是为采用MPEG-2传输流的链路定义的，并支持多种物理层承载[RFC4259]。
GSE has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers, and in the first instance for DVB-S2 [ETSI-S2]. The requirements for the Generic Stream are described in [S2-REQ]. The important characteristics of this encapsulation are described in the appendix of this document. GSE maintains a design philosophy that presents a network interface that is common to that presented by ULE and uses a similar construction for SubNetwork Data Units (SNDUs).
GSE设计用于第二代DVB物理层提供的通用模式（也称为通用流（GS）），第一种情况下用于DVB-S2[ETSI-S2]。[S2-REQ]中描述了通用流的要求。本文件附录中描述了该封装的重要特征。GSE坚持一种设计理念，即提供与ULE所提供的网络接口相同的网络接口，并使用类似的子网络数据单元（SNDU）结构。
The first Extension Header defines a method that allows one or more TS Packets [ISO-MPEG2] to 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. In GSE, there is no native support for Transport Stream packets and this method is therefore suitable for providing an MPEG-2 control plane.
第一扩展报头定义了一种方法，该方法允许在一个SNDU内发送一个或多个TS分组[ISO-MPEG2]。该方法可用于提供控制平面信息，包括用于多路复用的MPEG-2节目特定信息（PSI）的传输。在GSE中，不存在对传输流分组的本机支持，因此该方法适合于提供MPEG-2控制平面。
A second Extension Header allows one or more PDUs to be sent within the same ULE SNDU. This method is designed for cases where a large number of small PDUs are directed to the same Network Point of Attachment (NPA) address. The method may improve transmission efficiency (by removing duplicated MAC layer overhead). It can also reduce processing overhead for a receiver that is not configured to receive the NPA address associated with an SNDU, allowing this receiver to then skip several PDUs in one operation. The method is defined as a generic Extension Header and 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.
第二扩展报头允许在同一SNDU内发送一个或多个pdu。此方法设计用于大量小型PDU指向同一网络连接点（NPA）地址的情况。该方法可以提高传输效率（通过移除重复的MAC层开销）。它还可以减少未配置为接收与SNDU相关联的NPA地址的接收器的处理开销，从而允许该接收器在一次操作中跳过多个pdu。该方法定义为通用扩展标头，可用于IPv4或IPv6数据包。如果为ULE或以太网定义了压缩格式，则该方法也可与该方法结合使用。
A third Extension Header provides an optional TimeStamp value for an SNDU. Examples of the use of this TimeStamp option include monitoring and benchmarking of ULE and GSE links. Receivers that do not wish to decode (or do not support) the TimeStamp extension may discard the extension and process the remaining PDU or Extension Headers.
第三个扩展头为SNDU提供可选的时间戳值。使用此时间戳选项的示例包括ULE和GSE链路的监控和基准测试。不希望解码（或不支持）时间戳扩展的接收机可以丢弃扩展并处理剩余的PDU或扩展报头。
The appendix includes a summary of key design issues and considerations relating to the GSE Specification defined by the DVB Technical Module [GSE].
附录包括与DVB技术模块[GSE]定义的GSE规范相关的关键设计问题和注意事项的摘要。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
b: bit. For example, one byte consists of 8b.
b:一点点。例如，一个字节由8b组成。
B: byte. Groups of bytes are represented in Internet byte order.
B:字节。字节组以Internet字节顺序表示。
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 according to the choice of modulation format and Forward Error Correction (FEC) in use.
BBFrame payload：基带帧[ETSI-S2]的数据字段部分，可用于数据通信。根据所使用的调制格式和前向纠错（FEC）的选择，典型BBFrames的大小范围为3072到58192位。
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.
DVB：数字视频广播。欧洲电信标准协会（ETSI）发布的视频、音频和数据传输框架和相关标准集。
E: A one-bit flag field defined in GSE [GSE].
E: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.
封装器：一种网络设备[RFC4259]，用于接收PDU并将其格式化为有效负载单元（此处称为SNDU），以便以DVB-S或DVB-S2的通用模式输出。
GS: Generic Stream. A stream of BBFrames identified by a common Input Stream Identifier, and which does not use the MPEG-2 TS format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model.
通用流。由公共输入流标识符标识的BB帧流，不使用MPEG-2 TS格式[ETSI-S2]。它代表ISO/OSI参考模型的第2层。
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 of ULE and uses a common IANA Registry.
GSE：通用流封装[GSE]。一种封装PDU以形成通用流的方法，该通用流使用BBU帧序列发送。此封装格式共享相同的扩展格式和ULE的基本处理规则，并使用通用IANA注册表。
LT: A two-bit flag field defined in GSE [GSE].
LT：在GSE[GSE]中定义的两位标志字段。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard.
MAC：媒体访问控制[IEEE-802.3]。由IEEE 802.3标准定义的链路层协议。
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).
MPEG-2：由电影专家组（MPEG）规定并由国际标准化组织（ISO/IEC 113818-1）[ISO-MPEG2]和ITU-T（H.220）标准化的一组标准。
Next-Header: A Type value indicating an Extension Header [RFC4326].
下一个标头：表示扩展标头的类型值[RFC4326]。
NPA: Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA：网络连接点[RFC4326]。在本文档中，指DVB-S/S2传输网络内的目的地地址（类似于IEEE MAC地址），用于识别单个接收机或接收机组。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [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 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.
PID：数据包标识符[ISO-MPEG2]。每个TS数据包的报头中携带的13位字段。这标识TS数据包所属的TS逻辑信道[ISO-MPEG2]。构成表格部分或其他有效负载单元的TS数据包必须全部携带相同的PID值。all ones PID值表示为保持TS多路复用的恒定比特率而引入的空TS数据包。使用不同的TS多路复用器传输的TS逻辑信道所用的PID值之间没有必要的关系。
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PDU：协议数据单元[RFC4259]。PDU的示例包括以太网帧、IPv4或IPv6数据报以及其他网络数据包。
PSI: Program Specific Information [ISO-MPEG2].
PSI：程序特定信息[ISO-MPEG2]。
S: A one-bit flag field defined in [GSE].
S:GSE中定义的一位标志字段。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried on a DVB Multiplex.
SI表：服务信息表[ISO-MPEG2]。在本文件中，该术语描述了由另一标准机构定义的表，以传达有关DVB多路复用所承载服务的信息。
SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an encapsulated PDU sent using ULE or GSE.
SNDU：子网数据单元[RFC4259]。在本文档中，这是使用ULE或GSE发送的封装PDU。
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.
TS：传输流[ISO-MPEG2]，一种使用TS分组在MPEG-2级进行传输的方法；它代表ISO/OSI参考模型的第2层。
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs that 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.
ULE：单向轻量封装（ULE）[RFC4326]。一种将PDU封装到SNDU中的方法，SNDU使用单个TS逻辑信道以一系列TS数据包的形式发送。封装定义了扩展格式和关联的IANA注册表。
In ULE, a Type field value that is 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 adopts the same semantics as specified by RFC 4326. The
在ULE中，十进制数小于1536的类型字段值表示扩展标题。本节介绍ULE封装的一组三种扩展格式。[GSE]使用的类型字段采用RFC 4326指定的相同语义。这个
encapsulation format differs in that GSE does not include a Cyclic Redundancy Check (CRC) for each SNDU, has different header flags, and utilizes a different SNDU length calculation [GSE].
封装格式的不同之处在于，GSE不包括每个SNDU的循环冗余校验（CRC），具有不同的报头标志，并利用不同的SNDU长度计算[GSE]。
There is a natural ordering of Extension Headers, which is determined by the fields upon which the Extension Header operates. A suitable ordering for many applications is presented in the list below (from first to last header within an SNDU). This does not imply that all types of Extensions should be present in a single SNDU. The presented ordering may serve as a guideline for optimization of Receiver processing.
扩展头的顺序是自然的，由扩展头操作的字段决定。下表列出了许多应用程序的合适顺序（SNDU中从第一个到最后一个标题）。这并不意味着所有类型的扩展都应该出现在单个SNDU中。所提出的排序可作为接收机处理优化的指南。
+----------------------------------+-------------------------------+
|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|
+----------------------------------+-------------------------------+
+----------------------------------+-------------------------------+
|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 Headers
表1：扩展标题的建议顺序
The MPEG-2 TS-Concat Extension Header is specified by an IANA-assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory Extension Header.
MPEG-2 TS Concat扩展头由IANA分配的十六进制H-Type值0x0002指定。这是一个必需的扩展标题。
The extension is used to transport one or more MPEG-2 TS Packets within a ULE SNDU. The number of TS Packets carried in a specific SNDU is determined from the size of the remainder of the payload following the MPEG-2 TS Extension Header. The number of TS Packets contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N is the number of bytes associated with Extension Headers that precede the MPEG-2 TS-Concat Extension (zero if there are none) and D is the value of the D-bit.
该扩展用于在一个SNDU内传输一个或多个MPEG-2ts分组。在特定SNDU中承载的TS分组的数目由MPEG-2ts扩展报头之后的剩余有效载荷的大小确定。因此，SNDU中包含的TS分组的数量是（长度-N-10+D*6）/188，其中N是与MPEG-2 TS Concat扩展之前的扩展头相关联的字节数（如果没有扩展，则为零），D是D位的值。
A Receiver MUST check the validity of the Length value prior to processing the payload. A valid Length corresponds to an integral number of TS Packets. An invalid Length (a remainder from the division by 188) MUST result in the discard of all encapsulated TS Packets and SHOULD be recorded as TS-Concat size mismatch error.
在处理有效载荷之前，接收器必须检查长度值的有效性。有效长度对应于整数个TS数据包。无效长度（除以188的余数）必须导致丢弃所有封装的TS数据包，并应记录为TS Concat大小不匹配错误。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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: ULE/SNDU Format for a TS-Packet Payload (D=0)
Figure 1 illustrates the format of this Extension Header for ULE with a value D=0, which indicates the presence of an NPA address [RFC4326]. In this case, the valid payload Length for a ULE SNDU with no other extensions is (Length-10) / 188.
图1显示了值为D=0的ULE扩展头的格式，这表示存在NPA地址[RFC4326]。在这种情况下，没有其他扩展的ULE SNDU的有效有效负载长度为（长度-10）/188。
The method used to define the Length in GSE differs to that of ULE. The equivalent case for GSE would result in a payload Length value of (Length-6) / 188 (Figure 2).
GSE中用于定义长度的方法与ULE不同。GSE的等效情况将导致有效负载长度值（长度-6）/188（图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. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final fragment. After reassembly, this CRC-32 is removed and the resulting SNDU carries a Total Length field. The fields labeled S and E are defined by [GSE] and contain control flags used by the GSE link layer. The Label Type (LT) field specifies the presence and format of the GSE label. The LT field is only specified for the first fragment (or a non-fragmented) GSE SNDU (i.e., when S=1).
片段化的GSE SNDU由最终片段中携带的CRC-32保护。重新组装后，该CRC-32被移除，产生的SNDU携带一个总长度字段。标记为S和E的字段由[GSE]定义，并包含GSE链路层使用的控制标志。标签类型（LT）字段指定GSE标签的存在和格式。LT字段仅为第一个片段（或非片段）GSE SNDU指定（即，当S=1时）。
In ULE, a value of D=1 is also permitted and indicates the absence of an NPA address (Figure 3). A similar format is supported in GSE.
在ULE中，D=1的值也是允许的，表示没有NPA地址（图3）。GSE中支持类似的格式。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
The TS-Concat extension may be used to transport one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO-MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI signalling [RFC4259].
TS Concat扩展可用于传输根据[ISO-MPEG2]解释的任意内容的一个或多个MPEG-2 TS分组。一种预期用途是用于传输MPEG-2 SI/PSI信令[RFC4259]。
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this encapsulation. To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time that it can wait before sending all queued TS Packets. This is known as the TS Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs 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.
不应使用此封装发送空TS数据包[ISO-MPEG2]。为了减少传输开销和处理，封装器应该指定在发送所有排队的TS数据包之前可以等待的最长时间。这被称为TS打包阈值。该值必须是有界的，并且应该在封装器中进行配置。较大的值可以提高效率，但会导致更高的抖动，并可能增加损坏的概率。如果在TS打包阈值内未收到其他TS数据包，则封装器必须立即发送任何排队的TS数据包。
The use of this format to transfer MPEG-2 clock references (e.g., a Network Clock Reference, NCR) over ULE/GSE framing raises timing considerations at the encapsulation gateway, including the need to
使用此格式通过ULE/GSE帧传输MPEG-2时钟参考（例如，网络时钟参考，NCR）会在封装网关引起定时考虑，包括需要
update/modify the timing information prior to transmission by the physical layer. These issues are not considered here, but this operation may be simplified in GSE by ensuring that all SNDUs that carry this Extension Header are placed before other data within the BBFrame DataField [GSE].
在物理层传输之前更新/修改定时信息。这里不考虑这些问题，但在GSE中可以通过确保所有携带此扩展头的SNDU放在BBFrame数据字段[GSE]中的其他数据之前来简化此操作。
This document does not specify how TS Packets are to be handled at the Receiver. However, it notes:
本文档未指定如何在接收方处理TS数据包。然而，它注意到：
* 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 that each is independently demultiplexed as a separate Stream (Section 3.2 [RFC4259]).
* 接收器需要一致地将流中的所有TS数据包与一个TS逻辑信道（流）相关联。如果封装器发送多个TS数据包流，每个TS数据包以不同的级别封装或使用不同的NPA地址封装，则接收器需要确保每个TS数据包作为单独的数据流独立地解复用（第3.2节[RFC4259]）。
* If an Encapsulator transmits service information encapsulated at different levels or with different NPA addresses, the 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 ensure each PID value uniquely identifies a Stream within a TS Multiplex carrying ULE and also any TS Packets encapsulated by a ULE/GSE Stream.
* 如果封装器发送以不同级别或不同NPA地址封装的服务信息，则接收器需要确保每个流与相应的SI表信息（如果有）相关。减少信令交互的推荐方法是确保每个PID值唯一地标识TS多路复用传输ULE内的流以及由ULE/GSE流封装的任何TS分组。
The need for consistency in the use of PIDs and the related service information is described in section 4.2 of [RFC4947].
[RFC4947]第4.2节描述了PIDs和相关服务信息使用一致性的需要。
The PDU-Concat Extension Header is specified by an IANA-assigned H-Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header Extension. It enables a sequence of (usually short) PDUs to be sent within a single SNDU Payload.
PDU Concat扩展标头由IANA分配的十六进制H-Type值0x0003指定。这是强制性的下一个标题扩展。它允许在单个SNDU有效负载内发送一系列（通常较短）PDU。
The base header contains the Length of the entire SNDU. This carries the value of the combined length of all PDUs to be encapsulated, including each set of encapsulation headers. The base header MAY be followed by one or more additional Extension Headers that precede the PDU-Concat Extension Header. These Extension Headers (e.g., a TimeStamp Extension) apply to the composite concatenated PDU.
基本标头包含整个SNDU的长度。它携带要封装的所有PDU的组合长度值，包括每组封装头。基本标头之后可能会有一个或多个附加的扩展标头，位于PDU Concat扩展标头之前。这些扩展头（例如，时间戳扩展）应用于复合连接PDU。
The Extension Header also contains a 16-bit ULE Type field describing the encapsulated PDU, PDU-Concat-Type. Although any Type value specified in the ULE Next-Header Registry (including Extension Header Types) may be assigned to the encapsulated PDU (except the recursive use of a PDU-Concat type), all concatenated PDUs MUST have a common ULE Type (i.e., all concatenated PDUs passed by the network layer
扩展标头还包含一个16位ULE类型字段，描述封装的PDU、PDU Concat类型。尽管ULE Next Header注册表中指定的任何类型值（包括扩展标头类型）都可以分配给封装的PDU（PDU Concat类型的递归使用除外），但所有连接的PDU必须具有公共ULE类型（即，网络层传递的所有连接的PDU）
must be associated with the same Type value). This simplifies the receiver design, and reduces the transmission overhead for common use cases.
必须与相同的类型值关联）。这简化了接收机设计，并减少了常见用例的传输开销。
Each PDU is prefixed by its length in bytes (shown in the following diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of arbitrary length (in bytes) and are not necessarily aligned to 16-bit or 32-bit boundaries within the SNDU (as shown in the figures 4, 5, and 6). The most significant bit of the first byte is reserved, R, and this specification requires that this MUST be set to zero. Receivers MUST ignore the value of the R bit. The length of each PDU MUST be less than 32758 bytes, but will generally be much smaller.
每个PDU的前缀是其长度（以字节为单位）（在下图中显示为第x个PDU的PDU-x-length）。封装的PDU具有任意长度（以字节为单位），并且不一定与SNDU内的16位或32位边界对齐（如图4、5和6所示）。第一个字节的最高有效位为保留位R，本规范要求必须将其设置为零。接收器必须忽略R位的值。每个PDU的长度必须小于32758字节，但通常要小得多。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0 in ULE), a Network Point of Attachment, NPA, field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a transmission network that should process a received SNDU. When present, the Receiver MUST associate the same specified MAC/NPA address with all PDUs within the SNDU Payload. This MAC/NPA address MUST also be forwarded with each PDU, if required by the forwarding interface.
当SNDU报头指示存在SNDU目的地址字段（即，ULE中的D＝0）时，网络连接点NPA字段直接位于SNDU报头的第四字节之后。NPA目标地址是6字节的数字，通常用十六进制表示，用于识别传输网络中应处理接收到的SNDU的接收器。当存在时，接收器必须将相同的指定MAC/NPA地址与SNDU有效负载内的所有PDU相关联。如果转发接口要求，此MAC/NPA地址还必须与每个PDU一起转发。
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
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
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
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)
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)
When the SNDU header indicates the absence of an SNDU Destination Address field (i.e., D=1 in ULE), all encapsulated PDUs MUST be processed as if they had been received without an NPA address.
当SNDU报头指示不存在SNDU目的地址字段（即，ULE中的D＝1）时，必须处理所有封装的pdu，就像它们在没有NPA地址的情况下被接收一样。
The value of D in the ULE header indicates whether an NPA/MAC address is in use [RFC4326]. A similar format is supported in GSE (using the LT field).
ULE头中的D值指示NPA/MAC地址是否正在使用[RFC4326]。GSE中支持类似的格式（使用LT字段）。
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
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time it will wait before sending a Concatenated PDU. This is known as the PDU Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional PDUs are NOT received within the PDU Packing Threshold, the Encapsulator MUST immediately send all queued PDUs.
为了减少传输开销和处理，封装器应该指定在发送连接的PDU之前等待的最长时间。这称为PDU打包阈值。该值必须是有界的，并且应该在封装器中进行配置。较大的值可以提高效率，但会导致更高的抖动，并可能增加损坏的概率。如果在PDU打包阈值内未收到其他PDU，则封装器必须立即发送所有排队的PDU。
The Receiver processes this Extension Header by verifying that it supports the specified PDU-Concat Type (unsupported Types MUST be discarded, but the receiver SHOULD record a PDU-Type error [RFC4326]). It then extracts each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also ensure that the sum of the Lengths of all processed PDUs equals the Length specified in the SNDU base header. A Receiver SHOULD discard the whole SNDU if the total and PDU sizes are not consistent and this
接收方通过验证其是否支持指定的PDU Concat类型来处理此扩展标头（必须放弃不支持的类型，但接收方应记录PDU类型错误[RFC4326]）。然后依次提取每个封装的PDU。接收器必须验证每个PDU的长度。它还必须确保所有已处理PDU的长度之和等于SNDU基本标头中指定的长度。如果总大小和PDU大小不一致，则接收器应丢弃整个SNDU，并且
event SHOULD be recorded as a PDU-Concat size mismatch error. A receiver MUST NOT forward a partial PDU with an indicated PDU-Length greater than the number of unprocessed bytes remaining in the SNDU payload field.
事件应记录为PDU Concat大小不匹配错误。接收器不得转发指示PDU长度大于SNDU有效负载字段中剩余未处理字节数的部分PDU。
The TimeStamp Extension Header is an Optional Extension Header that permits an Encapsulator to add a TimeStamp field to an SNDU. The TimeStamp Extension Header is specified by the IANA-assigned H-Type value of 257 decimal. This extension is an Optional Extension Header ([RFC4326], Section 5).
时间戳扩展头是一个可选的扩展头，它允许封装器向SNDU添加时间戳字段。时间戳扩展标头由IANA分配的257十进制H类型值指定。此扩展是可选的扩展标头（[RFC4326]，第5节）。
This extension is designed to support monitoring and measurement of the performance of a link to indicate the quality of an operational ULE link. This may be useful for GSE links (e.g., where significant complexity exists in the scheduling provided by the lower layers). Possible uses of this extension include:
此扩展旨在支持链路性能的监视和测量，以指示运行链路的质量。这可能对GSE链路有用（例如，在较低层提供的调度中存在显著复杂性的情况下）。此扩展的可能用途包括：
* 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)
* 验证每个逻辑通道的顺序顺序*测量单向延迟（与发送方同步时）*测量链路引入的PDU抖动*测量PDU损耗（来自发送方的附加信息）
Figure 7 shows the format of this extension with a HLEN value of 3 indicating a TimeStamp of length 4B with a Type field (there is no implied byte-alignment).
图7显示了此扩展的格式，其中HLEN值为3，表示带有类型字段的长度为4B的时间戳（没有隐含的字节对齐）。
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | TimeStamp HI |
+---------------+---------------+---------------+---------------+
| TimeStamp LO | Type |
+---------------+---------------+---------------+---------------+
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | TimeStamp HI |
+---------------+---------------+---------------+---------------+
| TimeStamp LO | Type |
+---------------+---------------+---------------+---------------+
Figure 7: Format of the 32-bit TimeStamp Extension Header
图7:32位时间戳扩展头的格式
The extension carries a 32-bit value (TimeStamp HI plus TimeStamp LO). The specified resolution is 1 microsecond. The value therefore indicates 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 for example to Packing, queuing, and other Encapsulator processing. The value is right-justified to the 32-bit field. Systems unable to insert TimeStamps at the specified resolution MUST pad the unused least-significant bits with a value of zero.
扩展携带32位值（时间戳HI加上时间戳LO）。指定的分辨率为1微秒。因此，该值表示封装PDU时，世界时小时过去1微秒的滴答数。该值可能早于传输时间，例如由于打包、排队和其他封装器处理。该值与32位字段右对齐。无法以指定分辨率插入时间戳的系统必须将未使用的最低有效位的值填充为零。
The last two bytes carry a 16-bit Type field that indicates the type of payload carried in the SNDU or the presence of a further Next-Header ([RFC4326], Section 4.4).
最后两个字节包含一个16位类型字段，该字段指示SNDU中承载的有效负载类型或下一个报头的存在（[RFC4326]，第4.4节）。
Receivers MAY process the TimeStamp when the PDU encapsulation is removed. Receivers that do not implement, or do not wish to process, the TimeStamp Extension MAY skip this Extension Header. Receivers MUST continue to process the remainder of the SNDU, forwarding the encapsulated PDU.
当PDU封装被移除时，接收机可以处理时间戳。不实现或不希望处理时间戳扩展的接收器可以跳过此扩展头。接收器必须继续处理剩余的SNDU，转发封装的PDU。
IANA has assigned three new Next-Header Type values from the IANA ULE Next-Header Registry. These options are defined for specific use cases envisaged by GSE, but are compatible with ULE.
IANA已从IANA ULE Next Header注册表中分配了三个新的Next Header类型值。这些选项是针对GSE设想的特定用例定义的，但与ULE兼容。
The following assignments have been made in this document and registered by IANA:
以下任务已在本文件中完成并由IANA注册：
Type Name Reference
类型名称引用
2: TS-Concat Section 3.1 3: PDU-Concat Section 3.2
2:TS混凝土第3.1节3:PDU混凝土第3.2节
Type Name H-LEN Reference
类型名称H-LEN引用
257: TimeStamp 3 Section 3.3
257：时间戳3第3.3节
The TS-Concat Extension is a Mandatory next-type Extension Header, specified in Section 3.1 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 0x0002.
TS Concat扩展是本文件第3.1节规定的强制性下一类型扩展标题。下一个标头的值由IANA分配的H-Type值0x0002定义。
The PDU-Concat Extension is a Mandatory next-type Extension Header specified in Section 3.2 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 0x0003.
PDU Concat扩展是本文件第3.2节规定的强制性下一类型扩展标题。下一个标头的值由IANA分配的H-Type值0x0003定义。
The TimeStamp Extension is an Optional next-type Extension Header specified in Section 3.3 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 257 decimal. This documents defines the format for an HLEN value of 0x3.
时间戳扩展是本文档第3.3节中指定的可选下一类型扩展头。下一个标题的值由IANA分配的257十进制H型值定义。本文档定义了HLEN值0x3的格式。
The authors gratefully acknowledge the inputs, comments, and assistance offered by the members of the DVB-GBS ad hoc group on DVB-S2 encapsulation, in particular contributions on DVB-S2 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
作者衷心感谢DVB-GBS DVB-S2封装特设小组成员提供的投入、意见和协助，特别是Rita Rinaldo、Axel Jahn和Ulrik De Bie在DVB-S2传输方面的贡献。
Juan Cantillo provided a significant contribution to the informative appendix. The authors thank Christian Praehauser for his insight and contribution on Extension Header processing issues.
胡安·坎蒂略对资料性附录做出了重大贡献。作者感谢Christian Praehauser对扩展头处理问题的见解和贡献。
Security considerations for ULE are described in [RFC4326], and further information on security aspects of using ULE are described in the security considerations of [RFC4259] and [Sec-Req].
ULE的安全注意事项在[RFC4326]中描述，关于使用ULE的安全方面的更多信息在[RFC4259]和[Sec Req]的安全注意事项中描述。
An attacker that is able to inject arbitrary TS Packets in a ULE or GSE Stream may modify layer 2 signalling information transmitted by the MPEG-2 TS-Concat extension. Since this attack requires access to the link and/or layer 2 equipment, such an attack could also directly attack signalling information sent as native TS Packets (not encapsulated by ULE/GSE). Security issues relating to the transmission and interpretation of layer 2 signalling information (including Address Resolution) within a TS Multiplex are described in [RFC4947]. The use of security mechanisms to protect the MPEG-2 signalling information is discussed by [Sec-Req].
能够在ULE或GSE流中注入任意TS包的攻击者可以修改由MPEG-2 TS Concat扩展传输的第2层信令信息。由于这种攻击需要访问链路和/或第2层设备，因此这种攻击还可以直接攻击作为本机TS数据包（未由ULE/GSE封装）发送的信令信息。[RFC4947]中描述了与TS多路复用内第2层信令信息（包括地址分辨率）的传输和解释相关的安全问题。[Sec Req]讨论了使用安全机制来保护MPEG-2信令信息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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.
[RFC4326]Fairhurst，G.和B.Collini Nocker，“通过MPEG-2传输流（TS）传输IP数据报的单向轻量封装（ULE）”，RFC 4326，2005年12月。
[GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards, Institute (ETSI), 2007.
[GSE]TS 102 606“数字视频广播（DVB）；通用流封装（GSE）协议”，欧洲电信标准协会（ETSI），2007年。
[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).
[ETSI-S2]EN 302 307，“数字视频广播（DVB）；用于广播、交互服务、新闻采集和其他宽带卫星应用的第二代帧结构、信道编码和调制系统”，欧洲电信标准协会（ETSI）。
[S2-REQ] Cantillo, J. and J. Lacan, "A Design Rationale for Providing IP Services over DVB-S2 Links", Work in Progress, December 2006.
[S2-REQ]Cantillo，J.和J.Lacan，“通过DVB-S2链路提供IP服务的设计原理”，正在进行的工作，2006年12月。
[Sec-Req] Cruickshank, H., Iyengar, S., and P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, November 2007.
[Sec Req]Cruickshank，H.，Iyengar，S.，和P.Pillai，“单向轻量级封装（ULE）协议的安全要求”，正在进行的工作，2007年11月。
[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.
[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.translate error, please retry
[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.
[ISO-MPEG2]ISO/IEC DIS 13818-1:2000，“信息技术；运动图像和相关音频信息系统的通用编码”，国际标准化组织（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.
[RFC4259]Montpetit，M.-J.，Fairhurst，G.，Clausen，H.，Collini Nocker，B.，和H.Linder，“通过MPEG-2网络传输IP数据报的框架”，RFC 4259，2005年11月。
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
[RFC4947]Fairhurst，G.和M.Montpetit，“MPEG-2网络上IP数据报的地址解析机制”，RFC 4947，2007年7月。
This section provides informative background to the network-layer requirements of the second-generation DVB Transmission Specifications. The second-generation waveforms specified by the Digital Video Broadcasting project offer two main enhancements. First, more efficient physical-layer methods that employ higher-order modulation with stronger FEC and permit adaptive coding and modulation response to changes in traffic and propagation conditions. Second, at the link layer, they offer greater flexibility in framing. Support is provided for a range of stream formats including the classical Transport Stream (TS) [RFC4259]. In addition, a new method called Generic Stream (GS) (or the Generic Mode) is supported. A GS can be packetized or continuous and is intended to provide native transport of other network-layer services. One such method is that provided by the Generic Stream Encapsulation (GSE) [GSE].
本节提供了第二代DVB传输规范的网络层要求的信息背景。数字视频广播项目指定的第二代波形提供了两个主要增强功能。首先，更有效的物理层方法采用具有更强FEC的高阶调制，并允许对流量和传播条件的变化进行自适应编码和调制响应。其次，在链接层，它们提供了更大的框架灵活性。支持一系列流格式，包括经典传输流（TS）[RFC4259]。此外，还支持名为通用流（GS）（或通用模式）的新方法。GS可以打包或连续，用于提供其他网络层服务的本机传输。一种这样的方法是由通用流封装（GSE）[GSE]提供的方法。
For example, the DVB-S2 [ETSI-S2] transmission link sequentially multiplexes a series of baseband frames (BBFrames). Each BBFrame comprises a fixed-size 10B header and a payload. The payload carries a DataField and uses padding to fill any unused space. A stream comprises a sequence of BBFrames associated with an Input Stream Identifier (ISI) that is carried in the header of each BBFrame. The simplest scheme uses a single stream (with just one ISI value), but multiple streams are permitted. The BBFrames forming a stream may be of variable size (selected from a set of allowed sizes), and must use the same stream format (i.e., TS or GSE). Each stream represents an independent link with independent address resolution [RFC4947].
例如，DVB-S2[ETSI-S2]传输链路顺序复用一系列基带帧（bb帧）。每个BBFrame包括一个固定大小的10B报头和一个有效负载。有效负载携带一个数据字段，并使用填充来填充任何未使用的空间。流包括与在每个BBFrame的报头中携带的输入流标识符（ISI）相关联的BBFrame序列。最简单的方案使用单个流（只有一个ISI值），但允许多个流。形成流的bb帧可以具有可变大小（从一组允许的大小中选择），并且必须使用相同的流格式（即TS或GSE）。每个流表示具有独立地址解析的独立链路[RFC4947]。
GSE provides functions that are equivalent to those of the Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It supports the transmission of IP packets and other network-layer protocols. The network-layer interface resembles that of ULE, where it adopts common mechanisms for a Length field, a 16-bit Type field, and support for Extension Headers. As in ULE, GSE permits multiple address formats, indicated by the LT field (functionally equivalent to 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提供的功能等同于单向轻量级封装（ULE）[RFC4326]的功能。它支持IP数据包和其他网络层协议的传输。网络层接口类似于ULE，它对长度字段、16位类型字段采用通用机制，并支持扩展头。与ULE中一样，GSE允许多种地址格式，由LT字段表示（功能等同于ULE中的D字段）。默认寻址模式使用6字节NPA和抑制的NPA地址（功能等同于ULE中的D=1）。
GSE also provides 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 reflects the more complex requirements in terms of fragmentation and assembly that arise when using point-to-multipoint adaptive physical layers. The integrity of a reassembled SNDU is validated using a CRC-32 in the last fragment for the corresponding PDU.
GSE还在与物理层的接口处提供更灵活的分段（使用S和E标志）。这使SNDU适应可变大小的链路层帧，并反映了在使用点对多点自适应物理层时出现的碎片和组装方面更复杂的要求。在对应PDU的最后一个片段中使用CRC-32验证重新组装的SNDU的完整性。
Authors' Addresses
作者地址
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE UK
阿伯丁大学GoRead FelHurt工程学院，阿伯丁大学
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
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
伯恩哈德，科林尼诺克计算机科学系，萨尔茨堡大学，Jakob Haringer Str. 2, 5020萨尔茨堡，奥地利
EMail: bnocker@cosy.sbg.ac.at
URI: http://www.cosy.sbg.ac.at
EMail: bnocker@cosy.sbg.ac.at
URI: http://www.cosy.sbg.ac.at
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.