Network Working Group G. Fairhurst
Request for Comments: 4326 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
December 2005
Network Working Group G. Fairhurst
Request for Comments: 4326 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
December 2005
Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
用于通过MPEG-2传输流（TS）传输IP数据报的单向轻量级封装（ULE）
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.
MPEG-2传输流（TS）已被广泛接受，不仅用于提供数字电视服务，而且作为构建IP网络的子网技术。
This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.
本文档描述了一种单向轻量级封装（ULE）机制，用于直接通过ISO MPEG-2传输流将IPv4和IPv6数据报以及其他网络协议数据包作为TS专用数据传输。ULE指定一种基本封装格式，并支持一种扩展格式，允许它携带额外的头信息，以协助网络/接收器处理。
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 ....................................40
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 ....................................40
This document describes an encapsulation for the transport of IP datagrams, or other network-layer packets, over ISO MPEG-2 Transport Streams [ISO-MPEG2, RFC4259]. The encapsulation satisfies the requirement for a lightweight encapsulation defined in section 4 of [RFC4259]. The basic header provides the required set of protocol fields. Extension headers may also be defined. This header structure is significantly simpler to parse and process [SOOR05] than current alternative methods (e.g., MPE [ETSI-DAT], which builds upon the DSM-CC Table Section syntax [ISO-DSMCC]).
本文档描述了通过ISO MPEG-2传输流[ISO-MPEG2，RFC4259]传输IP数据报或其他网络层数据包的封装。封装满足[RFC4259]第4节中定义的轻量级封装要求。基本标头提供所需的一组协议字段。也可以定义扩展头。与当前的替代方法（例如，基于DSM-CC表节语法[ISO-DSMCC]的MPE[ETSI-DAT]）相比，这种头结构的解析和处理[SOOR05]要简单得多。
The encapsulation is suited to services based on MPEG-2; for example, the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other similar MPEG-2-based transmission systems. Such systems provide unidirectional (simplex) physical and link-layer standards. Support has been defined for a wide range of physical media (e.g., 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 may also be established using these standards (e.g., DVB defines a range of return channel technologies, including the use of two-way satellite links [ETSI-RCS]) and dial-up modem links [RFC3077].
封装适用于基于MPEG-2的业务；例如，数字视频广播（DVB）体系结构、高级电视系统委员会（ATSC）系统[ATSC，ATSC-G]和其他类似的基于MPEG-2的传输系统。此类系统提供单向（单工）物理和链路层标准。已定义了对各种物理媒体的支持（例如，地面电视[ETSI-DVBT、ATSC-PSIP-TC]、卫星电视[ETSI-DVBS、ATSC-S]和电缆传输[ETSI-DVBC、ATSC-PSIP-TC]）。还可以使用这些标准建立双向（双工）链路（例如，DVB定义了一系列返回信道技术，包括使用双向卫星链路[ETSI-RCS]）和拨号调制解调器链路[RFC3077]。
Protocol Data Units (PDUs), such as Ethernet Frames, IP datagrams, or other network-layer packets, used for transmission over an MPEG-2 Transport Multiplex are passed to an Encapsulator. This formats each PDU into a SubNetwork Data Unit (SNDU) by adding an encapsulation header and an integrity check trailer. The SNDU is fragmented into a series of one or more MPEG-2 Transport Stream (TS) Packets that are sent over a single TS Logical Channel.
用于通过MPEG-2传输多路复用传输的协议数据单元（PDU），例如以太网帧、IP数据报或其他网络层分组，被传递到封装器。通过添加封装头和完整性检查尾，将每个PDU格式化为子网数据单元（SNDU）。SNDU被分割成一系列通过单个TS逻辑信道发送的一个或多个MPEG-2传输流（TS）分组。
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).
MPEG-2规范[ISO-MPEG2]要求一致性TS多路复用器为TS多路复用中的每个流提供节目特定信息（PSI）。其他基于MPEG-2的传输标准也可以定义服务信息（SI）。
A format_identifier value has been registered for ULE [ULE1]. This 32 bit number has a hexadecimal value of 0x554C4531. Transport Streams that utilise 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 may also be identified by the stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
已为ULE[ULE1]注册了格式_标识符值。此32位数字的十六进制值为0x554C4531。使用ISO 13818-1[ISO-MPEG2]中定义的程序映射表（PMT）并使用本文件中定义的ULE格式的传输流，应在PMT ES_信息描述符循环中插入具有该值的描述符。ULE流也可以通过SI/PSI表[ISO\U MPEG2]中的流类型值0x91[ATSC-REG]来识别。
This information may allow Receivers and Re-multiplexors [RFC4259] to locate a specific ULE Stream (i.e., the PID value of the TS Logical
该信息可允许接收机和重多路复用器[RFC4259]定位特定的ULE流（即TS逻辑信号的PID值）
Channel that carries a ULE Stream). The conditions under which this information is required and the format in which it is to be provided are beyond the scope of this document. Addressing and mapping issues for ULE over MPEG-2 are also described in [IPDVB-AR].
传输数据流的通道）。要求提供此信息的条件和格式超出了本文件的范围。[IPDVB-AR]中还描述了基于MPEG-2的ULE的寻址和映射问题。
The capitalized 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 [RFC2119].
本文件中大写的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Other terms used in this document are defined below:
本文件中使用的其他术语定义如下：
Adaptation Field: An optional variable-length extension field of the fixed-length TS Packet header, intended to convey clock references and timing and synchronization information as well as stuffing over an MPEG-2 Multiplex [ISO-MPEG2].
自适应字段：固定长度TS数据包报头的可选可变长度扩展字段，用于通过MPEG-2多路复用[ISO-MPEG2]传输时钟参考、定时和同步信息以及填充。
AFC: Adaptation Field Control [ISO-MPEG2]. A pair of bits carried in the TS Packet header that signal the presence of the Adaptation Field and/or TS Packet payload.
AFC：自适应现场控制[ISO-MPEG2]。TS数据包报头中携带的一对比特，表示适配字段和/或TS数据包有效载荷的存在。
ATSC: Advanced Television Systems Committee [ATSC]. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard.
先进电视系统委员会（ATSC）。使用ISO MPEG-2标准传输视频、音频和数据的框架和一组相关标准。
b: bit. For example, one byte consists of 8b.
b:一点点。例如，一个字节由8b组成。
B: Byte. Groups of bytes are represented in Internet byte order.
B:字节。字节组以Internet字节顺序表示。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSM-CC：数字存储媒体命令和控制[ISO-DSMCC]。在MPEG-2专用部分中传输数据和控制信息的一种格式，由ISO MPEG-2标准定义。
DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2].
DVB：数字视频广播。欧洲电信标准协会（ETSI）发布的用于使用ISO MPEG-2标准[ISO-MPEG2]传输视频、音频和数据的框架和相关标准集（例如[ETSI-DVBC、ETSI-DVBS、ETSI-DVBT]）。
Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
封装器：接收PDU并将其格式化为有效负载单元（此处称为SNDU）以作为TS数据包流输出的网络设备。
End Indicator: A value that indicates to the Receiver that there are no further SNDUs present within the current TS Packet.
结束指示符：向接收器指示当前TS数据包中不存在其他SNDU的值。
LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer protocol defined by the IEEE 802 standard, which follows the Ethernet MAC Header.
LLC：逻辑链路控制[ISO-8802-2，IEEE-802.2]。由IEEE 802标准定义的链路层协议，遵循以太网MAC报头。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
MAC：媒体访问控制[IEEE-802.3]。由IEEE 802.3标准（或以太网v2[DIX]）定义的链路层协议。
MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2 [DIX]. It consists of a 6B destination address, 6B source address, and 2B Type field (see also NPA, LLC).
MAC头：IEEE 802.3标准[IEEE-802.3]或以太网v2[DIX]的链路层头。它由6B目标地址、6B源地址和2B类型字段组成（另见NPA，LLC）。
MPE: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel.
MPE：多协议封装[ETSI-DAT、ATSC-DAT、ATSC-DATG]。一种封装PDU的方案，形成DSM-CC表格部分。每个部分使用单个TS逻辑信道在一系列TS数据包中发送。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]).
MPEG-2：由电影专家组（MPEG）规定并由国际标准组织（ISO/IEC 13818-1）[ISO-MPEG2]和ITU-T（H.222[ITU-H222]）标准化的一组标准。
Next-Header: A Type value indicating an Extension Header.
下一个标题：表示扩展标题的类型值。
NPA: Network Point of Attachment. In this document, refers to a 6-byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA：网络连接点。在本文档中，指的是MPEG-2传输网络内的6字节目标地址（类似于IEEE MAC地址），用于识别单个接收机或接收机组。
Packing Threshold: A period of time an Encapsulator is willing to defer transmission of a partially filled TS-Packet to accumulate more SNDUs, rather than use Padding. After the Packet Threshold period, the Encapsulator uses Padding to send the partially filled TS-Packet.
打包阈值：封装者愿意延迟部分填充的TS数据包的传输以累积更多SNDU而不是使用填充的一段时间。在包阈值周期之后，封装器使用填充发送部分填充的TS包。
Padding: A method that fills the remaining unused bytes in a TS Packet payload using the specific pattern of 0xFF.
填充：使用0xFF的特定模式填充TS数据包有效负载中剩余未使用字节的方法。
Payload Unit, PU. A sequence of bytes sent using a TS. Examples of Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
有效载荷单位，PU。使用TS发送的字节序列。有效负载单元的示例包括：MPEG-2表段或SNDU。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
协议数据单元。PDU的示例包括以太网帧、IPv4或IPv6数据报以及其他网络数据包。
PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES：封装的基本蒸汽[ISO-MPEG2]。一种MPEG-2 TS数据包有效载荷格式，通常用于视频或音频信息。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of TS Packets. This is used to identify the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
PID：数据包标识符[ISO-MPEG2]。TS数据包报头中携带的13位字段。这用于标识TS数据包所属的TS逻辑信道[ISO-MPEG2]。TS数据包
forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000 as well as other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 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.
构成表格部分的PES或其他有效负载单元必须具有相同的PID值。全零PID 0x0000以及其他PID值保留用于特定PSI/SI表[ISO-MPEG2]。all ones PID值0x1FFF表示为保持TS多路复用的恒定比特率而引入的空TS数据包。使用不同的TS多路复用器传输的TS逻辑信道所用的PID值之间没有必要的关系。
PP: Payload Pointer [ISO-MPEG2]. An optional one-byte pointer that directly follows the 4-byte TS Packet header. It contains the number of bytes that follow the Payload Pointer, up to the start of the first Payload Unit (counted from the first byte of the TS Packet payload field, and excluding the PP field itself). The presence of the Payload Pointer is indicated by the value of the PUSI bit in the TS Packet header. The Payload Pointer is present in DSM-CC, Table Sections, and ULE. It is not present in TS Logical Channels that use the PES-format.
PP：有效负载指针[ISO-MPEG2]。直接跟随4字节TS数据包头的可选单字节指针。它包含有效负载指针之后直到第一个有效负载单元开始的字节数（从TS数据包有效负载字段的第一个字节开始计算，不包括PP字段本身）。有效负载指针的存在由TS分组报头中的PUSI位的值指示。有效负载指针出现在DSM-CC、表格部分和ULE中。它不存在于使用PES格式的TS逻辑通道中。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g., ETSI, ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
专用部分：根据[ISO-MPEG2]表2-30构造的句法结构。该结构可用于识别与一个或多个基本流、特定MPEG-2节目或整个传输流相关的私有信息（即，未由[ISO-MPEG2]定义）。其他标准机构，如ETSI、ATSC，已使用private_section结构定义了一组表结构。专用部分使用TS逻辑信道作为TS分组序列传输。TS逻辑信道可以承载来自多组表的部分。
PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey information about the service carried in a TS Multiplex. The information is carried in one of four specifically identified Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
PSI：程序特定信息[ISO-MPEG2]。用于传输TS多路复用中所承载服务信息的表格。该信息在MPEG-2[ISO-MPEG2]定义的四个专门标识的表格部分之一中携带。另见SI表。
PU: Payload Unit.
有效载荷单位。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single-bit flag carried in the TS Packet header. A PUSI value of zero indicates that the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one indicates that the TS Packet does carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the presence of a one-byte Payload Pointer (PP).
PUSI：有效载荷\单元\启动\指示器[ISO-MPEG2]。TS数据包报头中携带的一个位标志。PUSI值为零表示TS分组不携带新有效负载单元的开始。PUSI值为1表示TS分组确实携带新有效负载单元的开始。在ULE中，设置为1的PUSI位也表示存在单字节有效负载指针（PP）。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
接收器：处理来自TS多路复用的信号并对封装的PDU进行过滤和转发到网络层服务（或在链路层操作时桥接模块）的设备。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SI表：服务信息表[ISO-MPEG2]。在本文件中，该术语描述了由另一个标准机构定义的表，以传达关于TS多路复用中承载的服务的信息。一个表格可以由一个或多个表格部分组成；但是，特定SI表的所有部分必须通过单个TS逻辑通道[ISO-MPEG2]传输。
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：子网数据单元。作为MPEG-2有效负载单元发送的封装PDU。
Table Section: A Payload Unit carrying all or part of an SI or PSI Table [ISO-MPEG2].
表段：承载全部或部分SI或PSI表的有效载荷装置[ISO-MPEG2]。
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. See also TS Logical Channel and TS Multiplex.
TS：传输流[ISO-MPEG2]，一种使用TS分组在MPEG-2级进行传输的方法；它代表ISO/OSI参考模型的第2层。另请参见TS逻辑通道和TS多路复用。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B TS Packet incorporates a 4B header with the following fields (those referenced within this document are marked with *):
TS报头：TS数据包的4字节报头[ISO-MPEG2]。每个188B TS数据包包含一个4B报头和以下字段（本文件中引用的字段用*标记）：
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)
8b同步模式等于0x47*1b传输错误指示器*1b有效负载单元启动指示器（PUSI）1b传输优先级*13b数据包标识符（PID）2b传输加扰控制*2b自适应字段控制（AFC）*4b连续性计数器（CC）
If the PUSI bit is set to a value of 1, there is one additional field following the TS packet header:
如果PUSI位设置为值1，则TS数据包头后面还有一个附加字段：
*8b Payload Pointer (PP)
*8b有效负载指针（PP）
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this 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逻辑通道：传输流逻辑通道。在本文档中，该术语标识MPEG-2级别[ISO-MPEG2]的信道。它存在于ISO/OSI参考模型的2级。通过TS逻辑通道发送的所有数据包都具有相同的PID值（该值在特定TS多路复用中是唯一的）。术语“流”在MPEG-2[ISO-MPEG2]中定义，用于描述特定TS逻辑信道承载的内容（参见ULE流）。某些PID值（由MPEG-2）保留用于特定信令。其他标准（如ATSC、DVB）也保留特定的PID值。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. This may 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 associated with a different PID value) [RFC4259]; for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
TS多路复用：在本文档中，该术语定义了通过单个较低层连接发送的一组MPEG-2 TS逻辑通道。这可以是公共物理链路（即，以指定符号速率、FEC设置和传输频率的传输）或由另一协议层（例如，以太网或RTP over IP）提供的封装。同一TS逻辑信道可在多个TS多路复用上重复（可能与不同的PID值相关）[RFC4259]；例如，将相同的多播内容重新分发到两个地面电视传输小区。
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 including an Adaptation Field, encryption details, and time stamp information to synchronise a set of related TS Logical Channels.
TS数据包：通过TS多路复用发送的固定长度188B的数据单位[ISO-MPEG2]。每个TS包携带4B报头，加上可选开销，包括自适应字段、加密细节和时间戳信息，以同步一组相关TS逻辑信道。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2].
ULE流：仅承载ULE封装PDU的MPEG-2 TS逻辑通道。ULE流可通过SI/PSI[ISO-MPEG2]中的流类型定义来识别。
PDUs (IP packets, Ethernet frames or packets from other network protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). The SNDU is transmitted over an MPEG-2 transmission network either by being placed in the payload of a single TS Packet, or, if required, by being fragmented into a series of TS Packets. Where there is sufficient space, the method permits a single TS Packet to carry more than one SNDU (or part thereof), a practice sometimes known as Packing. All TS Packets comprising an SNDU MUST be assigned the same PID, and therefore form a part of the same TS Logical Channel.
PDU（IP数据包、以太网帧或来自其他网络协议的数据包）被封装以形成子网数据单元（SNDU）。SNDU通过MPEG-2传输网络被传输，或者通过被放置在单个TS分组的有效载荷中，或者，如果需要，通过被分段成一系列TS分组。在有足够空间的情况下，该方法允许单个TS分组携带多个SNDU（或其一部分），这种做法有时称为打包。包含SNDU的所有TS数据包必须分配相同的PID，因此构成相同TS逻辑信道的一部分。
The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one-bit Payload Unit Start Indicator (PUSI) field. A PUSI field with a value of 1 indicates the start of at least one Payload Unit (SNDU) within the TS Packet payload. The semantics of the PUSI bit are defined for PES and PSI packets [ISO-MPEG2]; for private data, its use is not defined in the MPEG-2 Standard. Although ULE uses private data, the operation follows that of PSI packets. Hence, the following PUSI values are defined:
ULE封装仅限于TS专用流。每个TS分组的报头携带一位有效负载单元开始指示符（PUSI）字段。值为1的PUSI字段指示TS分组有效载荷内至少一个有效载荷单元（SNDU）的开始。为PES和PSI数据包定义了PUSI位的语义[ISO-MPEG2]；对于私有数据，其使用未在MPEG-2标准中定义。虽然ULE使用私有数据，但操作遵循PSI数据包的操作。因此，定义了以下PUSI值：
0: The TS Packet does NOT contain the start of an SNDU, but contains the continuation, or end, of an SNDU;
0:TS分组不包含SNDU的开始，而是包含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.
1:TS数据包包含SNDU的开始，一个字节的有效负载指针位于TS数据包头的最后一个字节之后。
If a Payload Unit (SNDU) finishes before the end of a TS Packet payload, but it is not intended to start another Payload Unit, a stuffing procedure (known as Padding) fills the remainder of the TS Packet payload with bytes with a value 0xFF [ISO-MPEG2].
如果有效负载单元（SNDU）在TS数据包有效负载结束之前完成，但不打算启动另一个有效负载单元，则填充过程（称为填充）将使用值为0xFF[ISO-MPEG2]的字节填充TS数据包有效负载的其余部分。
A Receiver processing MPEG-2 Table Sections that receives a value of 0xFF in the first byte of a Table Section (table_Id) interprets this as Padding/Stuffing and silently discards the remainder of the TS Packet payload. The payload of the next TS Packet for the same TS Logical Channel will begin with a Payload Pointer of value 0x00, indicating that the next Payload Unit immediately follows the TS Packet header. The ULE protocol resembles this, but differs in the exact procedure (see the following sections).
处理MPEG-2表段的接收器在表段（表Id）的第一个字节中接收0xFF值，将其解释为填充/填充，并静默地丢弃TS数据包有效负载的其余部分。同一TS逻辑信道的下一个TS数据包的有效负载将以值0x00的有效负载指针开始，指示下一个有效负载单元紧跟在TS数据包头之后。ULE协议类似于此，但在具体程序上有所不同（见以下章节）。
The TS Packet Header also carries a two-bit Adaptation Field Control (AFC) value. This adaptation field may extend the TS Packet Header to carry timing and synchronisation information and may also be used to include stuffing bytes before a TS Packet payload. Adaptation Field stuffing is NOT used in this encapsulation method, and TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'. For TS Logical Channels supporting ULE, Receivers MUST discard TS Packets that carry other AFC values.
TS分组报头还携带两位自适应字段控制（AFC）值。该适配字段可以扩展TS分组报头以携带定时和同步信息，并且还可以用于在TS分组有效载荷之前包括填充字节。此封装方法中不使用自适应字段填充，来自ULE封装器的TS数据包必须以AFC值“01”发送。对于支持ULE的TS逻辑信道，接收机必须丢弃携带其他AFC值的TS数据包。
PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is illustrated below:
使用ULE封装PDU以形成SNDU。（每个SNDU是一个MPEG-2有效负载单元。）用于PDU的封装格式如下所示：
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation (* optional Destination Address)
图1:SNDU封装（*可选目标地址）
All multi-byte values in ULE (including the Length/End Indicator (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension Headers (5)) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field. Appendix A provides informative examples of usage.
ULE中的所有多字节值（包括长度/结束指示符（4.2,4.3）、类型（4.4）、目标地址（4.5）和扩展头（5））均以网络字节顺序传输（最高有效字节优先）。每个字节的最高有效位位于8位字段的最左侧位置。附录A提供了详细的用法示例。
The most significant bit of the Length field carries the value of the Destination Address Absent Field, the D-bit. A value of 0 indicates the presence of the Destination Address Field (see section 4.5). A value of 1 indicates that a Destination Address Field is not present.
长度字段的最高有效位携带目标地址缺失字段的值，即D位。值为0表示存在目标地址字段（见第4.5节）。值1表示目标地址字段不存在。
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).
必须发送D位值为1的结束指示器（4.3）。其他sndu可以用D位值0或1发送。默认方法应使用D位值0（参见第4.5节）。
A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field of the SNDU base header (figure 9) up to and including the CRC. This Length includes the size of any extension headers that may be present (section 5). Note the special case described in section 4.3.
一个15位的值，指示SNDU的长度，以字节为单位，从SNDU基本头（图9）的类型字段后面的字节开始计算，直到并包括CRC。该长度包括可能存在的任何扩展标头的大小（第5节）。注意第4.3节中描述的特殊情况。
When the first two bytes following an SNDU have the value 0xFFFF, this denotes an End Indicator (i.e., all ones length combined with a D-bit value of 1). This indicates to the Receiver that there are no further SNDUs present within the current TS Packet (see section 6), and that no Destination Address Field is present. The value 0xFF has specific semantics in MPEG-2 framing, where it is used to indicate the presence of Padding. This use resembles [ISO-DSMCC].
当SNDU后面的前两个字节的值为0xFFFF时，这表示结束指示符（即，所有字节的长度与D位值1的组合）。这向接收机指示在当前TS分组内不存在进一步的sndu（参见第6节），并且不存在目的地地址字段。值0xFF在MPEG-2帧中具有特定的语义，用于指示填充的存在。这种用法类似于[ISO-DSMCC]。
The 16-bit Type field indicates the type of payload carried in an SNDU, or the presence of a Next-Header. The set of values that may be assigned to this field is divided into two parts, similar to the allocations for Ethernet.
16位类型字段指示SNDU中承载的有效负载类型，或是否存在下一个报头。可分配给该字段的一组值分为两部分，类似于以太网的分配。
EtherTypes were originally specified by Xerox under the Ethernet v2 Specification [DIX]. After specification of IEEE 802.3 [IEEE-802.3, ISO-8802-2], the set of EtherTypes less than 1536 (0x0600) assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence, any IEEE EtherType < 1536 indicates an LLC frame, and the actual value indicates the length of the LLC frame.
EtherTypes最初由Xerox根据Ethernet v2规范[DIX]指定。在IEEE 802.3[IEEE-802.3，ISO-8802-2]规范之后，小于1536（0x0600）的以太类型集承担了长度指示器的角色。以太网接收器使用此功能区分LLC格式的帧。因此，任何IEEE EtherType<1536表示LLC帧，实际值表示LLC帧的长度。
There is a potential ambiguous case 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. Specification of two
当接收器接收到带有两个长度字段的PDU时，可能存在一种不明确的情况：接收器需要验证实际长度和长度字段，并确保不一致的值不会被网络传播。两种方法的说明
independent Length fields is therefore undesirable. In the ULE header, this is avoided in the SNDU header by including only one length value, but bridging of LLC frames re-introduces this consideration (section 5.2).
因此，不需要独立的长度字段。在ULE报头中，通过仅包含一个长度值，在SNDU报头中避免了这种情况，但LLC帧的桥接重新引入了这种考虑（第5.2节）。
The Ethernet LLC mode of identification is not required in ULE, since the SNDU format always carries an explicit Length field, and therefore the procedure in ULE is modified, as below:
ULE中不需要Ethernet LLC标识模式，因为SNDU格式始终带有明确的长度字段，因此ULE中的程序修改如下：
The first set of ULE Type field values comprise the set of values less than 1536 in decimal. These Type field values are IANA assigned (see section 4.4.1) and indicate the Next-Header.
第一组ULE类型字段值包括一组小于1536（十进制）的值。这些类型字段值由IANA分配（见第4.4.1节），并指示下一个标题。
The second set of ULE Type field values comprise the set of values greater than or equal to 1536 in decimal. In ULE, this value is identical to the corresponding type codes specified by the IEEE/DIX type assignments for Ethernet and recorded in the IANA EtherType registry.
第二组ULE类型字段值包括一组大于或等于1536（十进制）的值。在ULE中，该值与IEEE/DIX以太网类型分配指定并记录在IANA以太网类型注册表中的相应类型代码相同。
The first part of the Type space corresponds to the values 0 to 1535 decimal. These values may be used to identify link-specific protocols and/or to indicate the presence of Extension Headers that carry additional optional protocol fields (e.g., a bridging encapsulation). Use of these values is co-ordinated by an IANA registry. The following types are defined in this document:
类型空间的第一部分对应于0到1535十进制的值。这些值可用于标识特定于链路的协议和/或指示存在携带附加可选协议字段（例如桥接封装）的扩展头。这些值的使用由IANA注册中心协调。本文件中定义了以下类型：
0x0000: Test SNDU (see section 5.1) 0x0001: Bridged Frame (see section 5.2) 0x0100: Extension-Padding (see section 5.3)
0x0000：测试SNDU（见第5.1节）0x0001：桥接框架（见第5.2节）0x0100：扩展填充（见第5.3节）
The remaining values within the first part of the Type space are reserved for Next-Header values allocated by the IANA.
类型空间第一部分中的剩余值保留给IANA分配的下一个标头值。
The second part of the Type space corresponds to the values between 0x600 (1536 decimal) and 0xFFFF. This set of type assignments follows DIX/IEEE assignments (but excludes use of this field as a frame length indicator). All assignments in this space MUST use the values defined for IANA EtherType. The following two Type values are used as examples (taken from the IANA EtherTypes registry):
类型空间的第二部分对应于0x600（1536十进制）和0xFFFF之间的值。这组类型分配遵循DIX/IEEE分配（但不包括将此字段用作帧长度指示器）。此空间中的所有分配必须使用为IANA EtherType定义的值。以下两个类型值用作示例（取自IANA EtherTypes注册表）：
0x0800: IPv4 Payload (see section 4.7.2) 0x86DD: IPv6 Payload (see section 4.7.3)
0x0800:IPv4有效负载（参见第4.7.2节）0x86DD:IPv6有效负载（参见第4.7.3节）
The SNDU Destination Address Field is optional (see section 4.1). This field MUST be carried (i.e., D=0) for IP unicast packets destined to routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (D=1) for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilise a discriminator field (e.g., the IPv4/IPv6 destination address, or a bridged MAC destination address), which, in combination with the PID value, could be interpreted as a Link-Level address.
SNDU目标地址字段是可选的（见第4.1节）。对于使用共享链路（即，同一链路连接多个接收机）发送到路由器的IP单播数据包，必须携带此字段（即，D=0）。对于发送到能够使用鉴别器字段（例如，IPv4/IPv6目的地地址或桥接MAC目的地地址）的接收机的IP单播分组和/或多播分组，发送方可以省略该字段（D＝1），该字段与PID值结合，可以解释为链路级地址。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0), a Network Point of Attachment (NPA) field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 Byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a MPEG-2 transmission network that should process a received SNDU. The value 0x00:00:00:00:00:00 MUST NOT be used as a destination address in an SNDU. The least significant bit of the first byte of the address is set to 1 for multicast frames, and the remaining bytes specify the link-layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating that this SNDU is to be delivered to all Receivers.
当SNDU报头指示存在SNDU目的地址字段（即，D＝0）时，网络连接点（NPA）字段直接跟随在SNDU报头的第四字节之后。NPA目标地址是6字节的数字，通常以十六进制表示，用于识别MPEG-2传输网络中应处理接收到的SNDU的接收器。值0x00:00:00:00:00:00不能用作SNDU中的目标地址。对于多播帧，地址的第一个字节的最低有效位设置为1，其余字节指定链路层多播地址。特定值0xFF:FF:FF:FF:FF:FF是链路广播地址，表示该SNDU将被传送到所有接收机。
IPv4 packets carrying an IPv4 subnetwork broadcast address need to be delivered to all systems with the same network prefix. When a SNDU Destination Address is present (D=0), the value MUST be set to the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
携带IPv4子网广播地址的IPv4数据包需要发送到具有相同网络前缀的所有系统。当存在SNDU目标地址（D=0）时，该值必须设置为NPA链路广播地址（0xFF:FF:FF:FF:FF:FF）。
When the PDU is an IP multicast packet and an SNDU Destination Address is present (D=0), the IP group destination address of the multicast packet MUST be mapped to the multicast SNDU Destination Address (following the method used to generate a destination MAC address in Ethernet). The method for mapping IPv4 multicast addresses is specified in [RFC1112]. The method for mapping IPv6 multicast addresses is specified in [RFC2464].
当PDU是IP多播分组并且存在SNDU目的地地址（D＝0）时，多播分组的IP组目的地地址必须映射到多播SNDU目的地地址（遵循用于在以太网中生成目的地MAC地址的方法）。[RFC1112]中指定了映射IPv4多播地址的方法。[RFC2464]中规定了映射IPv6多播地址的方法。
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of the SNDU. This position eases CRC computation by hardware. The CRC-32 polynomial is to be used. Examples where this polynomial is also employed include Ethernet, DSM-CC section syntax [ISO-DSMCC], and AAL5 [ITU-3563]. This is a 32-bit value calculated according to the generator polynomial represented 0x104C11DB7 in hexadecimal:
每个SNDU必须在SNDU的最后四个字节中携带一个32位CRC字段。这个位置简化了硬件的CRC计算。将使用CRC-32多项式。还使用此多项式的示例包括以太网、DSM-CC段语法[ISO-DSMCC]和AAL5[ITU-3563]。这是根据十六进制表示的生成器多项式0x104C11DB7计算的32位值：
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.
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0。
The Encapsulator initialises the CRC-32 accumulator register to the value 0xFFFF FFFF. It then accumulates a transmit value for the CRC32 that includes all bytes from the start of the SNDU header to the end of the SNDU (excluding the 32-bit trailer holding the CRC-32), and places this in the CRC Field. In ULE, the bytes are processed in order of increasing position within the SNDU; the order of processing bits is NOT reversed. This use resembles, but is different from that in SCTP [RFC3309].
封装器将CRC-32累加器寄存器初始化为值0xFFFF FFFF。然后，它累积CRC32的传输值，该传输值包括从SNDU报头开始到SNDU结束的所有字节（不包括持有CRC-32的32位尾部），并将其放入CRC字段中。在ULE中，按照SNDU内位置的增加顺序处理字节；处理位的顺序不颠倒。这种用法类似于，但与SCTP[RFC3309]中的用法不同。
The Receiver performs an integrity check by independently calculating the same CRC value and comparing this with the transmitted value in the SNDU trailer. SNDUs that do not have a valid CRC are discarded, causing the Receiver to enter the Idle State.
接收器通过独立计算相同的CRC值并将其与SNDU拖车中的传输值进行比较来执行完整性检查。没有有效CRC的SNDU被丢弃，导致接收器进入空闲状态。
This description may be suited for hardware implementation, but this document does not imply any specific implementation. Software-based table-lookup or hardware-assisted software-based implementations are also possible. Appendix B provides an example of an Encapsulated PDU that includes the computed CRC-32 value.
本说明可能适用于硬件实现，但本文档并不暗示任何具体实现。基于软件的表查找或硬件辅助的基于软件的实现也是可能的。附录B提供了包含计算出的CRC-32值的封装PDU示例。
The primary purpose of this CRC is to protect the SNDU (header and payload) from undetected reassembly errors and errors introduced by unexpected software/hardware operation while the SNDU is in transit across the MPEG-2 subnetwork and during processing at the Encapsulator and/or the Receiver. It may also detect the presence of uncorrected errors from the physical link (however, these may also be detected by other means, e.g., section 7.3).
该CRC的主要目的是保护SNDU（报头和有效载荷）不受未检测到的重新组装错误以及SNDU在MPEG-2子网中传输以及在封装器和/或接收器处处理期间由意外软件/硬件操作引入的错误的影响。它还可以检测物理链路中是否存在未纠正的错误（但是，也可以通过其他方式检测这些错误，例如第7.3节）。
The format of an SNDU is determined by the combination of the Destination Address Absent bit (D) and the SNDU Type field. The simplest encapsulation places a PDU directly into an SNDU payload. Some Type 1 encapsulations may require additional header fields. These are inserted in the SNDU following the NPA destination address and directly preceding the PDU.
SNDU的格式由目标地址缺失位（D）和SNDU类型字段的组合确定。最简单的封装将PDU直接放入SNDU有效负载中。某些类型1封装可能需要额外的头字段。它们插入到SNDU中，位于NPA目标地址之后，直接位于PDU之前。
The following SNDU Formats are defined here:
此处定义了以下SNDU格式：
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).
结束指示器：接收器应进入空闲状态（4.7.1）。IPv4 SNDU：有效负载是完整的IPv4数据报（4.7.2）。IPv6 SNDU：有效负载是一个完整的IPv6数据报（4.7.3）。测试SNDU：有效载荷将被接收器丢弃（5.1）。桥接SNDU：有效负载承载桥接MAC帧（5.2）。
Other formats may be defined through relevant assignments in the IEEE and IANA registries.
其他格式可通过IEEE和IANA注册中心的相关分配进行定义。
The format of the End Indicator is shown in figure 2. This format MUST carry a D-bit value of 1.
结束指示器的格式如图2所示。此格式的D位值必须为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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图2：ULE结束指示器的格式
IPv4 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 3 and 4. (Note that in this, and the following figures, the IP datagram payload is of variable size and is directly followed by the CRC-32).
IPv4数据报使用两种标准SNDU结构之一直接传输，其中PDU直接放置在SNDU有效负载中。这两种封装如图3和图4所示。（请注意，在本图和下图中，IP数据报有效负载的大小是可变的，后面紧跟着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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图3：使用二级过滤（D=0）的IPv4数据报的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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 = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1)
图4：使用L3过滤的IPv4数据报的SNDU格式（D=1）
IPv6 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 5 and 6.
IPv6数据报使用两种标准SNDU结构之一直接传输，其中PDU直接放置在SNDU有效负载中。这两种封装如图5和图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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图5：使用二级过滤（D=0）的IPv6数据报的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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (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 = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
图6：使用L3过滤的IPv6数据报的SNDU格式（D=1）
This section describes an extension format for the ULE encapsulation. In ULE, a Type field value less than 1536 decimal indicates an Extension Header. These values are assigned from a separate IANA registry defined for ULE.
本节介绍ULE封装的扩展格式。在ULE中，小于1536十进制的类型字段值表示扩展标题。这些值是从为ULE定义的独立IANA注册表中分配的。
The use of a single Type/Next-Header field simplifies processing and eliminates the need to maintain multiple IANA registries. The cost is that each Extension Header requires at least 2 bytes. This is justified, on the basis of simplified processing and maintaining a simple lightweight header for the common case when no extensions are present.
使用单个Type/Next报头字段简化了处理，并且无需维护多个IANA注册表。成本是每个扩展头至少需要2个字节。这是合理的，因为在没有扩展的情况下，简化了处理并为常见情况维护了一个简单的轻量级头。
A ULE Extension Header is identified by a 16-bit value in the Type field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field, and an 8-bit H-Type field, as follows:
ULE扩展头由类型字段中的16位值标识。该字段组织为5位零前缀、3位H-LEN字段和8位H-Type字段，如下所示：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图7：ULE下一个标题字段的结构
The H-LEN Assignment is described below:
H-LEN分配如下所述：
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)
0表示强制扩展标头1表示长度为2B的可选扩展标头（仅限类型）2表示长度为4B的可选扩展标头（类型+2B）3表示长度为6B的可选扩展标头（类型+4B）4表示长度为8B的可选扩展标头（类型+6B）5表示长度为10B（类型+8B）的可选扩展标题
>=6 The combined H-LEN and H-TYPE values indicate the EtherType of a PDU that directly follows this Type field.
>=6 H-LEN和H-TYPE的组合值表示直接遵循此类型字段的PDU的EtherType。
The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field).
H-LEN值表示可选扩展标头（包括2B类型字段）中的总字节数。
An H-LEN value of zero indicates a Mandatory Extension Header. Each Mandatory Extension Header has a pre-defined length that is not communicated in the H-LEN field. No additional limit is placed on the maximum length of a Mandatory Extension Header. A Mandatory Extension Header MAY modify the format or encoding of the enclosed PDU (e.g., to perform encryption and/or compression).
H-LEN值为零表示强制扩展标头。每个强制扩展标头都有一个预定义的长度，该长度在H-LEN字段中不通信。强制扩展标题的最大长度没有附加限制。强制扩展标头可修改所附PDU的格式或编码（例如，执行加密和/或压缩）。
The H-Type is a one-byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions. The set of currently permitted values for both types of Extension Headers are defined by an IANA Registry (section 15). Registry values for Optional Extensions are specified in the form H=1 (i.e., a decimal number in the range 256-511), but may be used with an H-Length value in the range 1-5 (see example in section 5.3).
H-Type是一个单字节字段，它是256个强制标头扩展之一或256个可选标头扩展之一。两种类型的扩展头的当前允许值集由IANA注册表定义（第15节）。可选扩展的注册表值以H=1的形式指定（即，范围为256-511的十进制数），但可与范围为1-5的H长度值一起使用（参见第5.3节中的示例）。
Two examples of Extension Headers are the Test SNDU and the use of Extension-Padding. The Test SNDU Mandatory Extension Header results in the entire PDU's being discarded. The Extension-Padding Optional Extension Header results in the following (if any) option header being ignored (i.e., a total of H-LEN 16-bit words).
扩展头的两个例子是testsndu和扩展填充的使用。Test SNDU强制扩展头导致整个PDU被丢弃。扩展填充可选扩展标头会导致忽略以下（如果有）选项标头（即，总共H-LEN 16位字）。
The general format for an SNDU with Extension Headers is:
带有扩展标题的SNDU的一般格式为：
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header > < ext 1 >
< -------------------------- 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)
图8：带有一个扩展头的SNDU封装（对于D=0）
Where: D is the ULE D_bit (in this example D=0; however, NPA addresses may also be omitted when using Extension Headers). T1 is the base header Type field. In this case, specifying a Next-Header value. H1 is a set of fields defined for header type T1. There may be 0 or more bytes of information for a specific ULE Extension Header. T2 is the Type field of the next header, or an EtherType > 1535 B indicating the type of the PDU being carried.
其中：D是ULE D_位（在本例中，D=0；但是，在使用扩展头时，也可以省略NPA地址）。T1是基本标头类型字段。在本例中，指定下一个标头值。H1是为标题类型T1定义的一组字段。对于特定的ULE扩展头，可能有0个或更多字节的信息。T2是下一个标头的类型字段，或EtherType>1535b，表示所携带的PDU的类型。
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
< -------------------------- 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)
图9：带有两个扩展头（D=1）的SNDU封装
Using this method, several Extension Headers MAY be chained in series. Figure 12 shows an SNDU including two Extension Headers. In the example, the values of T1 and T2 are both less than 1536 decimal. Each indicates the presence of an Extension Header, rather than a directly following PDU. T3 has a value > 1535 indicating the EtherType of the PDU being carried. Although an SNDU may contain an arbitrary number of consecutive Extension Headers, it is not expected that SNDUs will generally carry a large number of extensions.
使用此方法，可以将多个扩展标头串联起来。图12显示了一个包含两个扩展头的SNDU。在本例中，T1和T2的值均小于1536十进制。每个都表示存在扩展标头，而不是直接跟随的PDU。T3的值大于1535，表示所携带PDU的以太网类型。尽管SNDU可能包含任意数量的连续扩展头，但预计SNDU通常不会携带大量扩展。
A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1. This header must be the final (or only) extension header specified in the header chain of an SNDU. The structure of the Data portion of this SNDU is not defined by this document. Receivers MAY record reception in a log file, but MUST then discard any Test SNDUs. The D-bit MAY be set in a TEST SNDU.
测试SNDU（图10）是类型1的强制扩展头。此标头必须是SNDU标头链中指定的最终（或唯一）扩展标头。本SNDU的数据部分的结构未在本文档中定义。接收机可以在日志文件中记录接收情况，但随后必须丢弃任何测试SNDU。可以在测试SNDU中设置D位。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图10：测试SNDU的SNDU格式
A bridged SNDU is a Mandatory Extension Header of Type 1. It MUST be the final (or only) extension header specified in the header chain of an SNDU. The payload includes MAC address and EtherType [DIX] or LLC Length [ISO-8802-2] fields together with the contents of a bridged MAC frame. The SNDU has the format shown in Figures 11 and 12.
桥接SNDU是类型1的强制扩展头。它必须是SNDU头链中指定的最终（或唯一）扩展头。有效载荷包括MAC地址和EtherType[DIX]或LLC长度[ISO-8802-2]字段以及桥接MAC帧的内容。SNDU的格式如图11和图12所示。
When an NPA address is specified (D=0), Receivers MUST discard all SNDUs that carry an NPA destination address that does NOT match their own NPA address (or a broadcast/multicast address); the payload of the remaining SNDUs are processed by the bridging rules that follow. An SNDU without an NPA address (D=1) results in a Receiver performing bridging processing on the payload of all received SNDUs.
当指定了NPA地址（D=0）时，接收机必须丢弃所有携带与其自己的NPA地址（或广播/多播地址）不匹配的NPA目标地址的SNDU；剩余sndu的有效负载由下面的桥接规则处理。没有NPA地址（D＝1）的SNDU导致接收机对所有接收到的SNDU的有效载荷执行桥接处理。
An Encapsulator MAY also use this encapsulation format to directly communicate network protocol packets that require the LLC encapsulation [IEEE-802.2, ISO-8802-2]. To do this, it constructs an SNDU with a Bridge Extension Header containing the intended destination MAC address, the MAC source address of the Encapsulator, and the LLC-Length. The PDU comprises an LLC header followed by the required payload. The Encapsulator MAY choose to suppress the NPA address (see 4.5).
封装器还可以使用该封装格式直接通信需要LLC封装的网络协议包[IEEE-802.2，ISO-8802-2]。为此，它构造了一个SNDU，其中包含一个网桥扩展头，其中包含预期的目标MAC地址、封装器的MAC源地址和LLC长度。PDU包括一个LLC标头，后跟所需的有效负载。封装器可选择抑制NPA地址（见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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图11：桥接有效负载的SNDU格式（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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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)
图12：桥接有效负载的SNDU格式（D=1）
The EtherType/LLC-Length field of a frame is defined according to IEEE 802.3 [IEEE-802.2] (see section 5).
帧的EtherType/LLC长度字段根据IEEE 802.3[IEEE-802.2]定义（参见第5节）。
In this special case, the Mandatory Extension Header format may be interpreted as either an EtherType [DIX] or an LLC Length field, specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in the ULE Next-Header Registry maintained by the IANA.
在这种特殊情况下，强制扩展报头格式可以解释为由IEEE 802[IEEE-802.3]指定的EtherType[DIX]或LLC长度字段，而不是在IANA维护的ULE下一报头注册表中分配的值。
The MAC addresses in the frame being bridged SHOULD be assigned according to the rules specified by the IEEE and denote unknown, unicast, broadcast, and multicast link addresses. These MAC addresses denote the intended recipient in the destination LAN, and therefore have a different function from the NPA addresses carried in the SNDU header.
桥接帧中的MAC地址应根据IEEE规定的规则分配，并表示未知、单播、广播和多播链路地址。这些MAC地址表示目标LAN中的预期收件人，因此具有与SNDU报头中携带的NPA地址不同的功能。
A frame Type < 1536 for a bridged frame introduces a LLC Length field. The Receiver MUST check this length and discard any frame with a length greater than permitted by the SNDU payload size.
桥接帧的帧类型<1536将引入LLC长度字段。接收器必须检查该长度，并丢弃长度大于SNDU有效负载大小允许的任何帧。
In normal operation, it is expected that any padding appended to the Ethernet frame SHOULD be removed prior to forwarding. This requires the sender to be aware of such Ethernet padding (e.g., [DIX, IEEE-802.3]).
在正常操作中，希望在转发之前删除附加到以太网帧的任何填充。这要求发送方知道此类以太网填充（例如，[DIX，IEEE-802.3]）。
Ethernet frames received at the Encapsulator for onward transmission over ULE carry a Local Area Network Frame Check sequence (LAN FCS)
在封装器处接收的以太网帧，用于通过ULE向前传输，带有局域网帧检查序列（LAN FCS）
field (e.g., CRC-32 for Ethernet [DIX, IEEE-802.3]). The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU). As in other ULE frames, the Encapsulator appends a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate LAN-FCS field will be appended to the bridged frame prior to onward transmission on the Ethernet interface.
字段（例如，用于以太网的CRC-32[DIX，IEEE-802.3]）。在进一步处理之前，封装者必须检查接收到的所有帧的LAN-FCS值。必须丢弃使用无效LAN FCS接收的帧。检查后，LAN FCS将被移除（即，它不会在桥接SNDU中转发）。与在其他ULE帧中一样，封装器将CRC-32附加到所发送的SNDU。在接收器处，在以太网接口上向前传输之前，将在桥接帧上附加一个适当的LAN-FCS字段。
This design is readily implemented using existing network interface cards and does not introduce an efficiency cost by calculating/verifying two integrity check fields for bridged frames. However, it also introduces the possibility that a frame corrupted within the processing performed at an Encapsulator and/or Receiver may not be detected by the final recipient(s) (i.e., such corruption would not normally result in an invalid LAN FCS).
该设计易于使用现有网络接口卡实现，并且不会通过计算/验证桥接帧的两个完整性检查字段来引入效率成本。然而，它也引入了在封装器和/或接收器处执行的处理中损坏的帧可能不会被最终接收者检测到的可能性（即，这种损坏通常不会导致无效的LAN FCS）。
The Extension-Padding Optional Extension Header is specified by an IANA-assigned H-Type value of 0x100. As in other Optional Extensions, the total length of the extension is indicated by the H-LEN field (specified in 16-bit words). The extension field is formed of a group of one to five 16-bit fields.
扩展填充可选扩展标头由IANA分配的H-Type值0x100指定。与其他可选扩展名一样，扩展名的总长度由H-LEN字段表示（用16位字指定）。扩展字段由一到五个16位字段组成。
For this specific option, only the last 16-bit word has an assigned value; the sender SHOULD set the remaining values to 0x0000. The last 16-bit field forms the Next-Header Type field. A Receiver MUST interpret the Type field, but MUST ignore any other fields of this Extension Header.
对于该特定选项，只有最后一个16位字具有赋值；发送方应将剩余值设置为0x0000。最后一个16位字段构成下一个标头类型字段。接收方必须解释类型字段，但必须忽略此扩展标头的任何其他字段。
The Encapsulator forms the PDUs queued for transmission into SNDUs by adding a header and trailer to each PDU (section 4). It then segments the SNDU into a series of TS Packet payloads (Figure 13). These are transmitted using a single TS Logical Channel over a TS Multiplex. The TS Multiplex may be processed by a number of MPEG-2 (re)multiplexors before it is finally delivered to a Receiver [RFC4259].
封装器通过向每个PDU添加一个标头和尾部，形成排队等待传输到SNDU的PDU（第4节）。然后，它将SNDU分割成一系列TS数据包有效负载（图13）。这些通过TS多路复用使用单个TS逻辑信道传输。TS多路复用可在其最终传送到接收机之前由多个MPEG-2（re）多路复用器处理[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 |
+--------+---------+ +--------+---------+ +--------+---------+
+------+--------------------------------+------+
| 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
图13：将SNDU封装到一系列TS数据包中
When an Encapsulator has not previously sent a TS Packet for a specific TS Logical Channel, or after an Idle period, it starts to send an SNDU in the first available TS Packet. This first TS Packet generated MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero, indicating that the SNDU starts immediately after the Payload Pointer in the TS Packet payload.
当封装器之前没有为特定TS逻辑信道发送TS分组时，或者在空闲时段之后，它开始在第一个可用TS分组中发送SNDU。生成的第一个TS数据包的PUSI值必须为1。它还必须携带有效负载指针值零，指示SNDU在TS数据包有效负载中的有效负载指针之后立即启动。
The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header, according to [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for each successive TS Packet containing a fragment/complete SNDU sent using the same TS Logical Channel.
根据[ISO-MPEG2]，封装必须确保所有TS数据包设置TS数据包头中携带的MPEG-2连续性计数器。对于包含使用相同TS逻辑信道发送的片段/完整SNDU的每个连续TS数据包，该值必须增加1（模16）。
An Encapsulator MAY decide not to send another SNDU immediately, even if space is available in a partially filled TS Packet. This procedure is known as Padding (Figure 14). The End Indicator informs the Receiver that there are no more SNDUs in this TS Packet payload. The End Indicator is followed by zero or more unused bytes until the end of the TS Packet payload. All unused bytes MUST be set to the value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The Padding procedure trades decreased efficiency against improved latency.
封装器可能决定不立即发送另一个SNDU，即使部分填充的TS分组中有可用空间。此过程称为填充（图14）。结束指示符通知接收器在该TS分组有效载荷中没有更多sndu。结束指示符后面是零个或多个未使用的字节，直到TS数据包有效负载结束。所有未使用的字节必须按照MPEG-2[ISO-DSMCC]中的当前做法设置为0xFF值。填充过程将降低的效率与改进的延迟进行权衡。
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
Indicator
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
Indicator
Figure 14: A TS Packet carrying the end of SNDU 1, followed by an End Indicator
图14：携带SNDU 1结尾的TS数据包，后跟一个结束指示符
Alternatively, when more packets are waiting at an Encapsulator, and a TS Packet has sufficient space remaining in the payload, the Encapsulator can follow a previously encapsulated SNDU with another SNDU using the next available byte of the TS Packet payload (see 6.2). This is called Packing (Figure 15).
或者，当更多的数据包在封装器处等待，并且TS数据包在有效载荷中有足够的剩余空间时，封装器可以使用TS数据包有效载荷的下一个可用字节跟随先前封装的SNDU和另一个SNDU（参见6.2）。这称为包装（图15）。
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 2 | | DU 3 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+
PUSI=1 | ^
| |
+--------------+
+-/----------------+ +----------------/-+
| 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
图15：以SNDU 2结尾，然后是SNDU 3的TS数据包
Five possible actions may occur when an Encapsulator has completed encapsulation of an SNDU:
当封装器完成SNDU的封装时，可能会发生五种可能的操作：
(i) If the TS Packet has no remaining space, the Encapsulator transmits this TS Packet. It starts transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
(i) 如果TS分组没有剩余空间，则封装器发送该TS分组。它开始在新的TS数据包中传输下一个SNDU。（标准规则[ISO-MPEG2]要求此新TS数据包的标头携带PUSI值1，后跟有效负载指针值0x00。）
(ii) If the TS Packet carrying the final part of an SNDU has one byte of unused payload, the Encapsulator MUST place the value 0xFF in this final byte and transmit the TS Packet. This rule provides a simple mechanism to resolve the complex behaviour that may arise when the TS Packet has no PUSI set. To send another SNDU in the current TS Packet would otherwise require the addition of a Payload Pointer that would consume the last remaining byte of TS Packet payload. The behaviour follows similar practice for other MPEG-2 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
（ii）如果承载SNDU最后部分的TS数据包具有一个未使用有效负载字节，则封装器必须在该最后字节中放置值0xFF并传输TS数据包。该规则提供了一种简单的机制来解决TS数据包没有PUSI集时可能出现的复杂行为。若要在当前TS数据包中发送另一个SNDU，则需要添加有效负载指针，该指针将消耗TS数据包有效负载的最后剩余字节。该行为遵循其他MPEG-2有效负载类型的类似实践[ISO-DSMCC]。封装器必须开始传输新TS数据包中的下一个SNDU。（标准规则要求此新TS数据包的标头携带PUSI值1，后跟有效负载指针值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 place the value 0xFFFF in these final two bytes, providing an End Indicator (section 4.3), and transmit the TS Packet. This rule prevents fragmentation of the SNDU Length field over two TS Packets. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
（iii）如果承载SNDU最后部分的TS数据包正好有两个字节的未使用有效负载，并且尚未设置PUSI，则封装器必须在这最后两个字节中放置值0xFFFF，提供结束指示符（第4.3节），并传输TS数据包。此规则防止SNDU长度字段在两个TS数据包上出现碎片。封装器必须开始传输新TS数据包中的下一个SNDU。（标准规则要求此新TS数据包的标头携带PUSI值1，后跟有效负载指针值0x00。）
(iv) If the TS Packet has more than two bytes of unused payload, the Encapsulator MAY transmit this partially full TS Packet but MUST first place the value 0xFF in all remaining unused bytes (i.e., setting an End Indicator followed by Padding). The Encapsulator MUST then start transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
（iv）如果TS数据包具有超过两个字节的未使用有效负载，则封装器可以传输该部分完整的TS数据包，但必须首先在所有剩余未使用字节中放置值0xFF（即，设置结束指示符，然后填充）。然后，封装器必须开始传输新TS数据包中的下一个SNDU。（标准规则[ISO-MPEG2]要求此新TS数据包的报头携带PUSI值1和有效负载指针值0x00。）
(v) If at least two bytes are available for SNDU data in the TS Packet payload (i.e., three bytes if the PUSI was NOT previously set, and two bytes if it was previously set), the Encapsulator MAY encapsulate further queued PDUs, by starting the next SNDU in the next available byte of the current TS Packet payload. When the Encapsulator packs further SNDUs into a TS Packet where the PUSI has
(v) 如果TS分组有效载荷中至少有两个字节可用于SNDU数据（即，如果先前未设置PUSI，则为三个字节，如果先前已设置，则为两个字节），则封装器可通过在当前TS分组有效载荷的下一个可用字节中启动下一个SNDU来封装进一步排队的pdu。当封装器将更多SNDU打包到一个TS包中时，PUSI
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 directly following the TS Packet header. (This reduces the size of the TS Packet payload field that is available for data by one byte.) The value of the Payload Pointer MUST be set to the position of the byte following the end of the first SNDU in the TS Packet payload. If no further PDUs are available, an Encapsulator MAY wait for additional PDUs to fill the incomplete TS Packet. The maximum period of time an Encapsulator can wait, known as the Packing Threshold, MUST be bounded and SHOULD be configurable in the Encapsulator. If sufficient additional PDUs are NOT received to complete the TS Packet within the Packing Threshold, the Encapsulator MUST insert an End Indicator (using rule iv).
尚未设置，必须更新PUSI（设置为1），并且必须在TS数据包头后面的第一个字节中插入一个8位有效负载指针。（这将可用于数据的TS数据包有效负载字段的大小减少了一个字节。）有效负载指针的值必须设置为TS数据包有效负载中第一个SNDU结束后的字节位置。如果没有其他可用的PDU，封装器可能会等待其他PDU来填充不完整的TS数据包。封装器可以等待的最长时间段（称为打包阈值）必须是有界的，并且应该在封装器中进行配置。如果没有收到足够的额外PDU以在打包阈值内完成TS数据包，则封装者必须插入结束指示器（使用规则iv）。
Use of the Packing method (v) by an Encapsulator is optional and may be determined on a per-session, per-packet, or per-SNDU basis.
封装器使用打包方法（v）是可选的，并且可以基于每个会话、每个分组或每个SNDU来确定。
When an SNDU is less than the size of 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).
当SNDU小于TS分组有效载荷的大小时，可以形成携带PUSI值1和结束指示符的TS分组（使用规则iv）。
A Receiver tunes to a specific TS Multiplex carrying a ULE Stream and sets a receive filter to accept all TS Packets with a specific PID. These TS Packets are associated with a specific TS Logical Channel and are reassembled to form a stream of SNDUs. A single Receiver may be able to receive multiple TS Logical Channels, possibly using a range of TS Multiplexes. In each case, reassembly MUST be performed independently for each TS Logical Channel. To perform this reassembly, the Receiver may use a buffer to hold the partially assembled SNDU, referred to here as the Current SNDU buffer. Other implementations may choose to use other data structures, but MUST provide equivalent operations.
接收机调谐到承载ULE流的特定TS多路复用，并设置接收滤波器以接受具有特定PID的所有TS分组。这些TS分组与特定TS逻辑信道相关联，并且被重新组合以形成sndu流。单个接收机可能能够接收多个TS逻辑信道，可能使用一系列TS多路复用。在每种情况下，必须为每个TS逻辑通道独立执行重新组装。为了执行该重新组装，接收器可以使用缓冲器来保持部分组装的SNDU，这里称为当前SNDU缓冲器。其他实现可以选择使用其他数据结构，但必须提供等效的操作。
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS Packet contains the start of a new SNDU. It also indicates the presence of the Payload Pointer (indicating the number of bytes to the start of the first SNDU in the TS-Packet currently being reassembled). It is illegal to receive a Payload Pointer value greater than 181, and this MUST cause the SNDU reassembly to be aborted and the Receiver to enter the Idle State. This event SHOULD be recorded as a payload pointer error.
接收到PUSI值为1的TS分组表示TS分组包含新SNDU的开始。它还指示有效负载指针的存在（指示当前正在重新组装的TS数据包中第一个SNDU开始的字节数）。接收大于181的有效负载指针值是非法的，这必须导致SNDU重新组装中止，并且接收器进入空闲状态。此事件应记录为有效负载指针错误。
A Receiver MUST support the use of both the Packing and Padding method for any received SNDU and MUST support reception of SNDUs with or without a Destination Address Field (i.e., D=0 and D=1).
接收器必须支持对任何接收到的SNDU使用打包和填充方法，并且必须支持接收带有或不带有目的地地址字段的SNDU（即，D=0和D=1）。
After initialisation or errors, or on receipt of an End Indicator, the Receiver enters the Idle State. In this state, the Receiver discards all TS Packets until it discovers the start of a new SNDU, upon which it then enters the Reassembly State. Figure 16 outlines these state transitions:
初始化或出错后，或接收到结束指示器后，接收器进入空闲状态。在此状态下，接收器丢弃所有TS数据包，直到发现新SNDU的开始，然后进入重新组装状态。图16概述了这些状态转换：
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
+-------+
| 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
图16：接收器状态转换
A Receiver in the Idle State MUST check the PUSI value in the header of all received TS Packets. A PUSI value of 1 indicates the presence of a Payload Pointer. Following a loss of synchronisation, values between 0 and 181 are permitted, in which case the Receiver MUST discard the number of bytes indicated by the Payload Pointer (counted from the first byte of the TS Packet payload field, and excluding the PP field itself), before leaving the Idle State. It then enters the Reassembly State, and starts reassembly of a new SNDU at this point.
处于空闲状态的接收器必须检查所有接收到的TS数据包的报头中的PUSI值。PUSI值为1表示存在有效负载指针。在同步丢失之后，允许0到181之间的值，在这种情况下，接收器必须在离开空闲状态之前丢弃有效负载指针指示的字节数（从TS数据包有效负载字段的第一个字节开始计算，并且不包括PP字段本身）。然后进入重新组装状态，并在此点开始重新组装新的SNDU。
When in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS Packet payload and returns to the Idle State. Receipt of an invalid Length field is an error event and SHOULD be recorded as an SNDU length error.
当处于重新组装状态时，接收器从TS数据包有效负载读取2字节SNDU长度字段。如果该值小于或等于4，或等于0xFFFF，则接收器丢弃当前SNDU和剩余TS数据包有效负载，并返回空闲状态。收到无效长度字段是一个错误事件，应记录为SNDU长度错误。
If the Length of the Current SNDU is greater than 4, the Receiver accepts bytes from the TS Packet payload to the Current SNDU buffer until either Length bytes in total are received, or the end of the TS Packet is reached (see also 7.2.1). When the Current SNDU length equals the value of the Length field, the Receiver MUST calculate and verify the CRC value (see 4.6). SNDUs that contain an invalid CRC value MUST be discarded. Mismatch of the CRC is an error event and SHOULD be recorded as a CRC error. The underlying physical-layer processing (e.g., forward error correction coding) often results in patterns of errors, rather than single bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the TS Packet and payload, including potential corruption of the PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard the remaining TS Packet payload (if any) following a CRC mismatch and return to the Idle State.
如果当前SNDU的长度大于4，则接收器接受从TS数据包有效负载到当前SNDU缓冲区的字节，直到接收到总长度字节或到达TS数据包的末尾（另见7.2.1）。当当前SNDU长度等于长度字段的值时，接收器必须计算并验证CRC值（见4.6）。必须丢弃包含无效CRC值的SNDU。CRC不匹配是一个错误事件，应记录为CRC错误。底层物理层处理（例如，前向纠错编码）通常导致错误模式，而不是单比特错误，因此接收机需要对TS分组和有效载荷的任意损坏模式具有鲁棒性，包括PUSI、PP和SNDU长度字段的潜在损坏。因此，接收机应丢弃CRC失配后剩余的TS数据包有效负载（如果有），并返回空闲状态。
When the Destination Address is present (D=0), the Receiver accepts SNDUs that match one of a set of addresses specified by the Receiver (this includes the NPA address of the Receiver, the NPA broadcast address, and any required multicast NPA addresses). The Receiver MUST silently discard an SNDU with an unmatched address.
当存在目标地址（D=0）时，接收器接受与接收器指定的一组地址之一匹配的SNDU（这包括接收器的NPA地址、NPA广播地址和任何所需的多播NPA地址）。接收方必须悄悄地丢弃地址不匹配的SNDU。
After receiving a valid SNDU, the Receiver MUST check the Type field (and process any Type 1 Extension Headers). The SNDU payload is then passed to the next protocol layer specified. An SNDU with an unknown Type value < 1536 MUST be discarded. This error event SHOULD be recorded as an SNDU type error.
在接收到有效的SNDU后，接收方必须检查类型字段（并处理任何类型1扩展头）。然后，SNDU有效负载被传递到下一个指定的协议层。必须丢弃未知类型值小于1536的SNDU。此错误事件应记录为SNDU类型的错误。
The Receiver then starts reassembly of the next SNDU. This MAY directly follow the previously reassembled SNDU within the TS Packet payload.
然后，接收器开始重新组装下一个SNDU。这可以直接跟随TS分组有效载荷内先前重新组装的SNDU。
(i) If the Current SNDU finishes at the end of a TS Packet payload, the Receiver MUST enter the Idle State.
(i) 如果当前SNDU在TS数据包有效负载结束时结束，则接收器必须进入空闲状态。
(ii) If only one byte remains unprocessed in the TS Packet payload after completion of the Current SNDU, the Receiver MUST discard this final byte of TS Packet payload. It then enters the Idle State. It MUST NOT record an error when the value of the remaining byte is identical to 0xFF.
（ii）如果在完成当前SNDU后TS数据包有效载荷中只有一个字节未处理，则接收器必须丢弃TS数据包有效载荷的最后一个字节。然后进入空闲状态。当剩余字节的值与0xFF相同时，它不得记录错误。
(iii) If two or more bytes of TS Packet payload data remain after completion of the Current SNDU, the Receiver accepts the next 2 bytes and examines whether this is an End Indicator. When an End Indicator is received, a Receiver MUST silently discard the remainder of the TS Packet payload and transition to the Idle State. Otherwise, this is the start of the next Packed SNDU, and the Receiver continues by processing this SNDU. (This is provided that the TS Packet has a
（iii）如果在完成当前SNDU之后仍然保留两个或更多字节的TS分组有效载荷数据，则接收器接受接下来的2个字节并检查这是否是结束指示符。当接收到结束指示符时，接收器必须静默地丢弃剩余的TS数据包有效负载并转换到空闲状态。否则，这是下一个压缩SNDU的开始，并且接收机继续处理该SNDU。（前提是TS分组具有
PUSI value of 1, see 7.2.1; otherwise, the Receiver has detected a delimiting error and MUST discard all remaining bytes in the TS Packet payload and transitions to the Idle State.)
PUSI值为1，见7.2.1；否则，接收器已检测到定界错误，必须丢弃TS数据包有效负载中的所有剩余字节，并转换到空闲状态。）
A Receiver that has partially received an SNDU (in the Current SNDU buffer) MUST check the PUSI value in the header of all subsequent TS Packets with the same PID (i.e., same TS Logical Channel). If it receives 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 remaining to complete the Current SNDU (i.e., the difference between the SNDU Length field and the number of reassembled bytes), the Receiver has detected a delimiting error.
部分接收到SNDU（在当前SNDU缓冲区中）的接收机必须检查具有相同PID（即，相同TS逻辑信道）的所有后续TS分组的报头中的PUSI值。如果接收到PUSI值为1的TS数据包，则必须验证有效负载指针。如果有效负载指针不等于完成当前SNDU剩余的字节数（即SNDU长度字段和重新组装的字节数之间的差值），则接收器已检测到定界错误。
Following a delimiting error, the Receiver MUST discard the partially assembled SNDU (in the Current SNDU buffer) and SHOULD record a reassembly error. It MUST then re-enter the Idle State.
在定界错误之后，接收器必须丢弃部分组装的SNDU（在当前SNDU缓冲区中），并应记录重新组装错误。然后必须重新进入空闲状态。
The Receiver SHOULD check the MPEG-2 Transport Error Indicator carried in the TS Packet header [ISO-MPEG2]. This flag indicates a transmission error for a TS Logical Channel. If the flag is set to a value of one, a transmission error event SHOULD be recorded. Any partially received SNDU MUST be discarded. The Receiver then enters the Idle State.
接收机应检查TS数据包头[ISO-MPEG2]中携带的MPEG-2传输错误指示器。此标志表示TS逻辑通道的传输错误。如果该标志设置为值1，则应记录传输错误事件。必须丢弃任何部分接收的SNDU。然后，接收器进入空闲状态。
The Receiver MUST check the MPEG-2 Continuity Counter carried in the TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets within 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 that in the previous TS Packet, and it does NOT increment 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. The Receiver then enters the Idle State.
接收机必须检查TS数据包头[ISO-MPEG2]中携带的MPEG-2连续性计数器。如果同一TS逻辑信道中的两个（或多个）连续TS数据包具有相同的连续性计数器值，则必须以静默方式丢弃重复的TS数据包。如果接收到的值与先前TS分组中的值不相同，并且对于连续TS分组（模16）它没有增加1，则接收器检测到连续性错误。必须丢弃任何部分接收的SNDU。应记录连续性计数器错误事件。然后，接收器进入空闲状态。
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.
注意，允许MPEG2-2传输网络携带通常由MPEG-2连续性计数器检测的重复TS包[ISO-MPEG2]。不执行上述连续性计数器检查的接收器将接受TS数据包的重复副本，以重新组装程序。在大多数情况下，SNDU CRC-32完整性检查将导致丢弃这些SNDU，从而导致意外的PDU丢失；然而，在某些情况下，重复的PDU（装配到一个TS数据包中）可能会在未被检测到的情况下传递到下一层协议。
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），它通过基于MPEG-2传输流（TS）构建的网络对IPv4和IPv6网络服务提供高效灵活的支持。这种封装也适用于传输其他协议包和桥接以太网帧。
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.
ULE还提供了一种扩展头格式，并定义了一个关联的IANA注册表，以高效灵活地支持强制和可选的SNDU头。这允许将来扩展协议，同时提供与现有实现的向后兼容性。特别是，不实现可选扩展头或选择不处理可选扩展头的接收方可以安全地忽略它们。
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.
本文件以霍斯特D.克劳森、伯恩哈德·科里尼·诺克、希尔玛·林德和戈里·费尔赫斯特之前的一份文件为基础。作者希望感谢ip dvb邮件列表的成员的投入；特别是从Art Allison、Carstsen Borman、Patrick Cipiere、Wolgang Fritsche、Hilmar Linder、Alain Ritoux和William Stanislaus收到的许多评论。Alain还提供了最初的用法示例。
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.
ULE的安全注意事项类似于使用现有多协议封装（MPE）时出现的安全注意事项。ULE没有添加会影响通用互联网安全的特定新威胁。
There is a known security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
存在未初始化的填充字节的已知安全问题。在ULE中，这些字节被设置为0xFF（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.
在桥接网络环境中移除LAN FCS存在已知的完整性问题。删除桥接帧会使通信量在由封装器和/或接收器处理时暴露于潜在的未检测到的损坏。
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
当接收器接收到带有两个长度字段的PDU时，存在一个潜在的安全问题：接收器需要验证实际长度和长度字段，并确保不一致的值不会被网络传播。在ULE中直接封装IPv4/IPv6时，通过只包含一个SNDU长度来避免这种情况
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.
领域然而，在桥接LLC帧中仍然会出现此问题，必须丢弃LLC长度大于SNDU有效负载大小的帧，并且应记录SNDU有效负载长度错误。
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.
将来，可以使用强制扩展报头来定义执行SNDU有效载荷的链路加密的方法。这是IP、传输或应用层安全的附加安全机制，而不是替代[RFC4259]。该方法是通用的，将封装与未来的安全扩展分离。该操作提供的功能类似于当前与MPE封装一起使用的功能。
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.
可以提供附加的安全控制字段作为该链路加密扩展报头的一部分，例如，将SNDU与一组安全关联（SA）参数中的一个相关联。作为加密过程的一部分，可能还希望验证部分或全部SNDU报头。加密方法和密钥交换方式超出了本规范的范围，SA格式和相关加密密钥的定义也超出了本规范的范围。
The IANA has created the ULE Next-Header Type field registry as defined in this document.
IANA已创建本文档中定义的ULE下一个标题类型字段注册表。
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).
此注册表在0-511（十进制）范围内分配下一个标头值。对于每个分配的值，它还指定了一组允许的H-LEN值（参见第5节）。这些组合定义了ULE类型空间第一部分0-1535范围内的一组允许值（见第4.4.1节）。
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).
以下包含IANA下一个标题注册表管理指南。此注册表分配0-511十进制值（0x0000-0x01FF，十六进制）。它不能分配大于0x01FF（十进制）的值。
It subdivides the Next-Header registry in the following way:
它按以下方式细分下一个标头注册表：
1) 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
1) 0-255（十进制）IANA分配值，表示ULE的强制扩展头（或链接相关类型字段），需要专家审查，从而提前发布IETF RFC。此规范必须定义与扩展标头关联的值和名称，以及
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:
已在本文件中进行了转让，并由IANA注册：
Type Name Reference
类型名称引用
0: Test-SNDU Section 5.1 1: Bridged-SNDU Section 5.2
0：测试SNDU第5.1节1：桥接SNDU第5.2节
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.
2) 256-511（十进制）IANA分配的值，表示ULE的可选扩展标题，需要专家审查，从而提前发布IETF RFC。此规范必须定义与扩展标头关联的值和名称，以及处理扩展标头的过程。该条目必须指定允许的H-LEN值的范围（范围1-5）。它还必须定义可选扩展的需求和预期用途。
Assignments have been made in this document, and registered by IANA:
已在本文件中进行了转让，并由IANA注册：
Type Name H-LEN Reference
类型名称H-LEN引用
256: Extension-Padding 1-5 Section 5.3
256：扩展填充1-5第5.3节
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000.
[ISO-MPEG2]IS 13818-1，“信息技术——运动图像和相关音频信息的通用编码——第1部分：系统”，国际标准化组织（ISO），2000年。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC2119]Bradner，S.，“在RFC中用于表示需求水平的关键词”，BCP 14，RFC 211997。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[ULE1] Registration for format_identifier ULE1, SMPTE Registration Authority, LLC, http://www.smpte-ra.org/ule1.html.
[ULE1]SMPTE注册管理局有限责任公司格式标识ULE1的注册，http://www.smpte-ra.org/ule1.html.
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 Networks", Work in Progress, September 2005.
[IPDVB-AR]Fairhurst，G.和M-J.Montpetit，“MPEG-2网络上IP数据报的地址解析”，正在进行的工作，2005年9月。
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53 Rev.C, 2004
[ATSC]A/53，“ATSC数字电视标准”，高级电视系统委员会（ATSC），文件。A/53 Rev.C，2004年
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DAT]A/90，“ATSC数据广播标准”，高级电视系统委员会（ATSC），文件。A/09020000。
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-DATG]A/91，“推荐做法：ATSC数据广播标准的实施指南”，高级电视系统委员会（ATSC），文件。A/912001。
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995.
[ATSC-G]A/54，“ATSC数字电视标准使用指南”，高级电视系统委员会（ATSC），Doc。A/541995年。
[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-PSIP-TC]A/65B，“地面广播和有线电视的节目和系统信息协议”，高级电视系统委员会（ATSC），文件。A/65B，2003年。
[ATSC-REG] ATSC "Code Point Registry" www.atsc.org/standards/Code_Point_Registry.pdf.
[ATSC-REG]ATSC“代码点注册表”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.
[ATSC-S]A/80，“卫星数字电视（DTV）应用的调制和编码要求”，高级电视系统委员会（ATSC），文件。A/801999年。
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982.
[DIX]数字设备公司、英特尔公司、施乐公司，“以太网局域网规范”2.0版，1982年11月。
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI), 2004.
[ETSI-DAT]EN 301 192，“数据广播规范”，欧洲电信标准协会（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-DVBC]EN 300 800，“数字视频广播（DVB）；有线电视分配系统（CATV）的DVB交互频道”，欧洲电信标准协会（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-DVBS]EN 300 421，“数字视频广播（DVB）；11/12 GHz下DBS卫星系统的调制和编码”，欧洲电信标准协会（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-DVBT]EN 300 744，“数字视频广播（DVB）；数字地面电视（DVB-T）的帧结构、信道编码和调制”，欧洲电信标准协会（ETSI），2004年。
[ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI), 2005.
[ETSI-RCS]ETSI 301 790，“数字视频广播（DVB）；卫星分配系统的交互通道”，欧洲电信标准协会（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.2]IEEE 802.2，“局域网和城域网特定要求第2部分：逻辑链路控制”，IEEE计算机协会（也称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.
[IEEE-802.3]IEEE 802.3，“局域网和城域网特定要求第3部分：带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范”，IEEE计算机协会（也是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.
[ISO-DSMCC]IS 13818-6，“信息技术——运动图像和相关音频信息的通用编码——第6部分：DSM-CC的扩展”，国际标准组织（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-H222]H.222.0，“信息技术——运动图像和相关音频信息的通用编码：系统”，国际电信联盟（ITU-T），1995年。
[ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, (ITU-T), 1996.
[ITU-3563]I.363.5，“B-ISDN ATM适配层规范：第5类AAL”，国际电信联盟（ITU-T），1996年。
[ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International Standards Organisation (ISO), 1998.
[ISO-8802-2]ISO/IEC 8802.2，“逻辑链路控制”，国际标准化组织（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.
[RFC3077]Duros，E.，Dabbous，W.，Izumiyama，H.，Fujii，N.，和Y.Zhang，“单向链路的链路层隧道机制”，RFC 3077，2001年3月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.，和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[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月。
[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.
[SOOR05]M.Sooriyabandara，G.Fairhurst，A.Ang，B.Collini Nocker，H.Linder，W.Stering“基于MPEG-2网络的IP轻量级封装协议：设计、实现和分析”，计算机网络48 p5-19，2005年。
Appendix A: SNDU Packing Examples
附录A：SNDU包装示例
This appendix provides some examples of use. The appendix is informative. It does not provide a description of the protocol. The examples provide the complete TS Packet sequence for some sample encapsulated IP packets.
本附录提供了一些使用示例。附录内容丰富。它没有提供协议的描述。这些示例为一些示例封装的IP数据包提供了完整的TS数据包序列。
The specification of the TS Packet header operation and field values is provided in [ISO-MPEG2]. The specification of ULE is provided in the body of this document.
[ISO-MPEG2]中提供了TS数据包报头操作和字段值的规范。本文件正文中提供了ULE规范。
The key below is provided for the following examples.
下面的键用于以下示例。
HDR 4B TS Packet Header
PUSI Payload Unit Start Indicator
PP Payload Pointer
*** TS Packet Payload Pointer (PP)
HDR 4B TS Packet Header
PUSI Payload Unit Start Indicator
PP Payload Pointer
*** TS Packet Payload Pointer (PP)
Example A.1: Two 186B PDUs.
示例A.1：两个186B PDU。
SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address)
SNDU A为200字节（包括ULE目标NPA地址）SNDU B为200字节（包括ULE目标NPA地址）
The sequence comprises 3 TS Packets:
该序列包括3个TS分组：
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 * *
*************************
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=0
End Stuffing
CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+
PUSI=0
Example A.2: Usage of last byte in a TS-Packet
示例A.2:TS数据包中最后一个字节的使用
SNDU A is 183 bytes SNDU B is 182 bytes SNDU C is 181 bytes SNDU D is 185 bytes
SNDU A是183字节SNDU B是182字节SNDU C是181字节SNDU D是185字节
The sequence comprises 4 TS Packets:
该序列包括4个TS分组：
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=0
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=0
Example A.3: Large SNDUs
示例A.3：大型SNDU
SNDU A is 732 bytes SNDU B is 284 bytes
SNDU A为732字节SNDU B为284字节
The sequence comprises 6 TS Packets:
该序列包括6个TS分组：
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0
Example A.4: Illustration of SNDU Length field
示例A.4：SNDU长度字段的图示
SNDU A is 200 bytes SNDU B is 60 bytes SNDU C is 60 bytes
SNDU A是200字节SNDU B是60字节SNDU C是60字节
The sequence comprises two TS Packets:
该序列包括两个TS分组：
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 |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++ ++++++++++++++++++++++
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 Indicator
*** TS Packet Payload Pointer (PP)
+++ ULE Length Indicator
Example A.5: Three 44B PDUs.
示例A.5：三个44B PDU。
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)
SNDU A为52字节（无ULE目标NPA地址）SNDU B为52字节（无ULE目标NPA地址）SNDU C为52字节（无ULE目标NPA地址）
The sequence comprises 1 TS Packet:
该序列包括1个TS分组：
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-----+------+- -+-----+---------+- -+------+
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-----+------+- -+-----+---------+- -+------+
Appendix B: SNDU Encapsulation
附录B：SNDU封装
An example of ULE encapsulation carrying an ICMPv6 packet generated by ping6.
ULE封装的一个示例，其中包含由ping6生成的ICMPv6数据包。
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 : 0x7c171763
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 : 0x7c171763
Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6 : 2001:DB8:2509:1962::2
Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6 : 2001:DB8:2509:1962::2
SNDU contents (including CRC-32):
SNDU内容（包括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 63
0000:00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 00 00 00 00 00 00 00 0016:3a 40 20 01 00 00 00 00 00 00 00 00 00 00 00 0032:00 01 20 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 48:00 02 80 00 00 00 00 00 00 00 00 00 00 9d 8c 06 38 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 7 C 0064:17 17 17 63
Authors' Addresses
作者地址
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/Gorry
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
伯恩哈德科林尼诺克萨尔茨堡科学计算大学系JAJOB HARGIN STR 2萨尔茨堡5020奥地利
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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 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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。