Network Working Group M.-J. Montpetit
Request for Comments: 4259 Motorola Connected Home Solutions
Category: Informational G. Fairhurst
University of Aberdeen
H. Clausen
TIC Systems
B. Collini-Nocker
H. Linder
University of Salzburg
November 2005
Network Working Group M.-J. Montpetit
Request for Comments: 4259 Motorola Connected Home Solutions
Category: Informational G. Fairhurst
University of Aberdeen
H. Clausen
TIC Systems
B. Collini-Nocker
H. Linder
University of Salzburg
November 2005
A Framework for Transmission of IP Datagrams over MPEG-2 Networks
一种在MPEG-2网络上传输IP数据报的框架
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.
本文档描述了通过ISO MPEG-2传输流（TS）传输IP数据报的体系结构。MPEG-2 TS不仅在提供数字电视服务方面，而且作为构建IP网络的子网技术，已被广泛接受。使用MPEG-2的系统示例包括数字视频广播（DVB）和用于数字电视的高级电视系统委员会（ATSC）标准。
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.
该文件确定了一套定义MPEG-2传输流和IP子网之间接口的互联网标准的需求。它提出了一种新的IP数据报封装方法，并提出了执行IPv6/IPv4地址解析的协议，以将IP数据包与MPEG-2 TS提供的逻辑信道的属性相关联。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................39
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................39
This document identifies requirements and an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams [ISO-MPEG]. The prime focus is the efficient and flexible delivery of IP services over those subnetworks that use the MPEG-2 Transport Stream (TS).
本文件确定了通过ISO MPEG-2传输流[ISO-MPEG]传输IP数据报的要求和体系结构。主要重点是通过使用MPEG-2传输流（TS）的子网高效灵活地提供IP服务。
The architecture is designed to be compatible with 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 typically provide unidirectional (simplex) physical and link layer standards, and have been defined for a wide range of physical media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ETSI-DVBS2, ATSC-S], Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC, OPEN-CABLE], and data transmission over MPEG-2 [ETSI-MHP].
该体系结构被设计为与基于MPEG-2的服务兼容，例如数字视频广播（DVB）体系结构、高级电视系统委员会（ATSC）系统[ATSC，ATSC-G]和其他类似的基于MPEG-2的传输系统。此类系统通常提供单向（单工）物理和链路层标准，并已针对各种物理媒体（例如，地面电视[ETSI-DVBT、ATSC-PSIP-TC]、卫星电视[ETSI-DVBS、ETSI-DVBS2、ATSC-S]、电缆传输[ETSI-DVBC、ATSC-PSIP-TC、开放式电缆]和MPEG-2[ETSI-MHP]上的数据传输进行了定义。
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+
Figure 1: Overview of the MPEG-2 protocol stack
图1:MPEG-2协议栈概述
Although many MPEG-2 systems carry a mixture of data types, MPEG-2 components may be, and are, also used to build IP-only networks. Standard system components offer advantages of improved interoperability and larger deployment. However, some MPEG-2 networks do not implement all parts of a DVB / ATSC system, and may, for instance, support minimal, or no, signalling of Service Information (SI) tables.
尽管许多MPEG-2系统混合了多种数据类型，但MPEG-2组件也可用于构建纯IP网络。标准系统组件具有改进的互操作性和更大规模部署的优点。然而，一些MPEG-2网络并不实现DVB/ATSC系统的所有部分，并且可能例如支持最小的或不支持服务信息（SI）表的信令。
The architecture defined in this document describes a set of protocols that support transmission of IP packets over the MPEG-2 TS. Key characteristics of these networks are that they may provide link-level broadcast capability, and that many supported applications require access to a very large number of subnetwork nodes.
本文档中定义的体系结构描述了一组支持通过MPEG-2 TS传输IP数据包的协议。这些网络的关键特征是，它们可以提供链路级广播能力，并且许多受支持的应用程序需要访问大量子网节点。
Some, or all, of these protocols may also be applicable to other subnetworks, e.g., other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM], and some types of broadcast wireless links. The key goals of the architecture are to reduce complexity when using the system, while improving performance, increasing flexibility for IP services, and providing opportunities for better integration with IP services.
这些协议中的一些或全部也可适用于其他子网，例如，其他MPEG-2传输网络、再生卫星链路[ETSI-BSM]和一些类型的广播无线链路。该体系结构的主要目标是在使用系统时降低复杂性，同时提高性能，增加IP服务的灵活性，并提供与IP服务更好集成的机会。
Since a majority of MPEG-2 transmission networks are bandwidth-limited, encapsulation protocols must therefore add minimal overhead to ensure good link efficiency while providing adequate network services. They also need to be simple to minimize processing, robust to errors and security threats, and extensible to a wide range of services.
由于大多数MPEG-2传输网络是带宽受限的，因此封装协议必须增加最小的开销，以确保良好的链路效率，同时提供足够的网络服务。它们还需要简单到最小化处理，对错误和安全威胁具有鲁棒性，并可扩展到广泛的服务。
In MPEG-2 systems, TS Logical Channels, are identified by their PID and provide multiplexing, addressing, and error reporting. The TS Logical Channel may also be used to provide Quality of Service (QoS). Mapping functions are required to relate TS Logical Channels to IP addresses, to map TS Logical Channels to IP-level QoS, and to associate IP flows with specific subnetwork capabilities. An important feature of the architecture is that these functions may be provided in a dynamic way, allowing transparent integration with other IP-layer protocols. Collectively, these will form an MPEG-2 TS Address Resolution (AR) protocol suite [IPDVB-AR].
在MPEG-2系统中，TS逻辑信道由其PID标识，并提供多路复用、寻址和错误报告。TS逻辑信道还可用于提供服务质量（QoS）。映射功能需要将TS逻辑通道与IP地址关联，将TS逻辑通道映射到IP级别的QoS，并将IP流与特定子网功能关联。该体系结构的一个重要特征是，这些功能可以动态提供，允许与其他IP层协议进行透明集成。总的来说，它们将形成一个MPEG-2 TS地址解析（AR）协议套件[IPDVB-AR]。
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-MPEG].
自适应字段：固定长度TS数据包报头的可选可变长度扩展字段，用于通过MPEG-2多路复用[ISO-MPEG]传输时钟参考、定时和同步信息以及填充。
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 [ISO-MPEG].
先进电视系统委员会（ATSC）。使用ISO MPEG-2标准[ISO-MPEG]传输视频、音频和数据的框架和一组相关标准。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information defined by the ISO MPEG-2 standard that is carried in an MPEG-2 Private Section.
DSM-CC：数字存储媒体命令和控制[ISO-DSMCC]。一种用于传输由ISO MPEG-2标准定义的数据和控制信息的格式，在MPEG-2专用部分中传输。
DVB: Digital Video Broadcast [ETSI-DVBC, ETSI-DVBRCS, ETSI-DVBS]. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data, using the ISO MPEG-2 Standard [ISO-MPEG].
DVB：数字视频广播[ETSI-DVBC，ETSI-DVBRCS，ETSI-DVBS]。欧洲电信标准协会（ETSI）发布的一个框架和一组相关标准，用于使用ISO MPEG-2标准[ISO-MPEG]传输视频、音频和数据。
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数据包流输出的网络设备。
Forward Direction: The dominant direction of data transfer over a network path. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network.
正向：通过网络路径进行数据传输的主要方向。正向数据传输称为“正向传输”。沿前向移动的数据包沿着IP网络的前向路径移动。
MAC: Medium Access and Control. The link layer header of the Ethernet IEEE 802 standard of protocols, consisting of a 6B destination address, 6B source address, and 2B type field (see also NPA).
MAC：介质访问和控制。以太网IEEE 802协议标准的链路层报头，由6B目标地址、6B源地址和2B类型字段组成（另见NPA）。
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) [ISO-MPEG].
MPEG-2：由电影专家组（MPEG）指定并由国际标准组织（ISO）[ISO-MPEG]标准化的一组标准。
NPA: Network Point of Attachment. Addresses primarily used for station (Receiver) identification within a local network (e.g., IEEE MAC address). An address may identify individual Receivers or groups of Receivers.
NPA：网络连接点。主要用于本地网络内站点（接收器）标识的地址（例如，IEEE MAC地址）。地址可以标识单个接收者或接收者组。
PAT: Program Association Table [ISO-MPEG]. An MPEG-2 PSI control table that associates program numbers with the PID value used to send the corresponding PMT. The PAT is sent using the well-known PID value of zero.
PAT：程序关联表[ISO-MPEG]。一种MPEG-2 PSI控制表，将程序编号与用于发送相应PMT的PID值相关联。PAT使用众所周知的PID值零发送。
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 Stream [ISO-MPEG]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES：分组化基本流[ISO-MPEG]。一种MPEG-2 TS数据包有效载荷格式，通常用于视频或音频信息。
PID: Packet Identifier [ISO-MPEG]. 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-MPEG]. The TS Packets forming the parts of a Table Section, PES, or other Payload Unit must
PID：数据包标识符[ISO-MPEG]。TS数据包报头中携带的13位字段。这用于标识TS数据包所属的TS逻辑信道[ISO-MPEG]。构成表格部分、PES或其他有效负载单元的TS数据包必须
all carry the same PID value. The all 1s PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
它们都具有相同的PID值。all 1s PID值表示为保持TS多路复用的恒定比特率而引入的空TS数据包。使用不同的TS多路复用器传输的TS逻辑信道所用的PID值之间没有必要的关系。
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/Streams that comprise a program [ISO-MPEG]. The PID value which is used to send the PMT for a specific program is defined by an entry in the PAT.
PMT：程序映射表。一种MPEG-2 PSI控制表，用于关联组成节目[ISO-MPEG]的TS逻辑信道/流集合使用的PID值。用于发送特定程序的PMT的PID值由PAT中的条目定义。
PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that directly follows the TS Packet header. It contains the number of bytes between the end of the TS Packet header and the start of a Payload Unit. 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 and Table Sections; it is not present in TS Logical Channels that use the PES-format.
PP：有效负载指针[ISO-MPEG]。直接跟随TS数据包头的可选单字节指针。它包含TS数据包报头的结束和有效负载单元的开始之间的字节数。有效负载指针的存在由TS分组报头中的PUSI位的值指示。有效载荷指针出现在DSM-CC和表格部分中；它不存在于使用PES格式的TS逻辑通道中。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire TS. 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-MPEG]表2-30构造的句法结构。该结构可用于识别与一个或多个基本流、特定MPEG-2程序或整个TS相关的私有信息（即，未由[ISO-MPEG]定义）。其他标准机构（例如，ETSI、ATSC）已使用私有部分结构定义了表结构集。专用部分使用TS逻辑信道作为TS分组序列传输。TS逻辑信道可以承载来自多组表的部分。
PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs [ISO-MPEG], see also SI Table.
PSI：程序特定信息[ISO-MPEG]。PSI用于传送关于TS多路复用中承载的服务的信息。它包含在四个特定标识的表节构造[ISO-MPEG]中，另请参见SI表。
PU: Payload Unit. A sequence of bytes sent using a TS. Examples of Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
有效载荷单位。使用TS发送的字节序列。有效负载单元的示例包括：MPEG-2表段或SNDU。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. 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-MPEG]。TS数据包报头中携带的一个位标志。PUSI值为零表示TS分组不携带新有效负载单元的开始。PUSI值为1表示TS分组确实携带新有效负载单元的开始。在ULE中，设置为1的PUSI位也表示存在单字节有效负载指针（PP）。
Receiver: A piece of 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-MPEG]. In this document, this term describes a table that is used to convey information about the services carried in a TS Multiplex, that has been defined by another standards body. 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-MPEG].
SI表：服务信息表[ISO-MPEG]。在本文件中，该术语描述了一个表，该表用于传达关于TS多路复用中承载的服务的信息，该信息已由另一个标准机构定义。一个表可以由一个或多个表部分组成，但是特定SI表的所有部分必须通过单个TS逻辑信道[ISO-MPEG]传输。
SNDU: Sub-Network Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：子网数据单元。作为MPEG-2有效负载单元发送的封装PDU。
STB: Set-Top Box. A consumer equipment (Receiver) for reception of digital TV services.
机顶盒：机顶盒。用于接收数字电视服务的消费设备（接收器）。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG].
表段：承载全部或部分SI或PSI表[ISO-MPEG]的有效载荷单元。
TS: Transport Stream [ISO-MPEG], a method of transmission at the MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS：传输流[ISO-MPEG]，一种使用TS分组在MPEG-2级进行传输的方法；它代表ISO/OSI参考模型的2级。另请参见TS逻辑通道和TS多路复用。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG].
TS报头：TS数据包[ISO-MPEG]的4字节报头。
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG]. 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). According to MPEG-2, some TS Logical Channels are reserved for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific TS Logical Channels.
TS逻辑通道：传输流逻辑通道。在本文档中，该术语标识MPEG-2级[ISO-MPEG]的信道。它存在于ISO/OSI参考模型的2级。通过TS逻辑通道发送的所有数据包都具有相同的PID值（该值在特定TS多路复用中是唯一的）。根据MPEG-2，一些TS逻辑信道被保留用于特定信令。其他标准（如ATSC、DVB）也保留特定的TS逻辑信道。
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), 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值相关联），例如将相同的多播内容重新分发到两个地面TV传输小区。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details and time stamp information to synchronize a set of related TS Logical Channels. It is also referred to as a TS_cell. Each TS Packet carries a PID value to associate it with a single TS Logical Channel.
TS数据包：通过TS多路复用[ISO-MPEG]发送的固定长度188B的数据单位。每个TS数据包携带4B报头，加上可选开销，包括自适应字段、加密细节和时间戳信息，以同步一组相关TS逻辑信道。它也被称为TS_单元。每个TS数据包携带一个PID值，以将其与单个TS逻辑通道相关联。
ULE: Unidirectional Lightweight Encapsulation (ULE) [IPDVB-ULE]. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel.
ULE：单向轻量封装（ULE）[IPDVB-ULE]。将PDU封装到SNDU中的一种方案，SNDU使用单个TS逻辑通道以一系列TS数据包的形式发送。
The following sections introduce the components of the MPEG-2 Transmission Network and relate these to a networking framework.
以下各节介绍MPEG-2传输网络的组件，并将其与网络框架相关联。
There are many possible topologies for MPEG-2 Transmission Networks. A number of example scenarios are briefly described below, and the following text relates specific functions to this set of scenarios.
MPEG-2传输网络有许多可能的拓扑结构。下面简要描述了一些示例场景，以下文本将特定功能与这组场景相关联。
A) Broadcast TV and Radio Delivery The principal service in the Broadcast TV and Radio Delivery scenario is Digital TV and/or Radio and their associated data [MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two components: the contribution feed and the broadcast part. Contribution feeds provide communication from a typically small number of individual sites (usually at high quality) to the Hub of a broadcast network. The traffic carried on contribution feeds is typically encrypted, and is usually processed prior to being resent on the Broadcast part of the network. The Broadcast part uses a star topology centered on the Hub to reach a typically large number of down-stream Receivers. Although such networks may provide IP transmission, they do not necessarily provide access to the public Internet.
A） 广播电视和无线电传输广播电视和无线电传输场景中的主要服务是数字电视和/或无线电及其相关数据[MMUSIC-IMG，ETSI-IPDC]。此类网络通常包含两个组件：贡献馈送和广播部分。贡献源提供了从通常为数不多的单个站点（通常是高质量站点）到广播网络中心的通信。贡献源上的流量通常是加密的，并且通常在网络的广播部分重新发送之前进行处理。广播部分使用以集线器为中心的星形拓扑，以到达通常大量的下游接收器。尽管此类网络可提供IP传输，但它们不一定提供对公共互联网的访问。
B) Broadcast Networks used as an ISP Another scenario resembles that above, but includes the provision of IP services providing access to the public Internet. The IP traffic in this scenario is typically not related to the digital TV/Radio content, and the service may be operated by an independent operator such as unidirectional file delivery or bidirectional ISP access. The IP service must adhere to the full system specification used for the broadcast transmission, including allocation of PIDs and generation of appropriate MPEG-2 control information (e.g., DVB and ATSC SI tables).
B） 作为ISP使用的广播网络另一个场景类似于上述场景，但包括提供IP服务以访问公共互联网。该场景中的IP通信量通常与数字电视/无线电内容无关，并且该服务可以由独立的运营商操作，例如单向文件传送或双向ISP访问。IP服务必须遵守用于广播传输的完整系统规范，包括分配PID和生成适当的MPEG-2控制信息（例如DVB和ATSC SI表）。
C) Unidirectional Star IP Scenario The Unidirectional Star IP Scenario utilizes a Hub station to provide a data network delivering a common bit stream to typically medium-sized groups of Receivers. MPEG-2 transmission technology provides the forward direction physical and link layers for this transmission; the return link (if required) is provided by other means. IP
C） 单向星形IP方案单向星形IP方案利用一个集线器站提供一个数据网络，向典型的中型接收机组提供一个公共比特流。MPEG-2传输技术为该传输提供前向物理层和链路层；返回链接（如果需要）通过其他方式提供。知识产权
services typically form the main proportion of the transmission traffic. Such networks do not necessarily implement the MPEG-2 control plane, i.e., PSI/SI tables.
服务通常构成传输业务的主要部分。这种网络不一定实现MPEG-2控制平面，即PSI/SI表。
D) Datacast Overlay The Datacast Overlay scenario employs MPEG-2 physical and link layers to provide additional connectivity such as unidirectional multicast to supplement an existing IP-based Internet service. Examples of such a network includes IP Datacast to mobile wireless receivers [MMUSIC-IMG].
D） 数据广播覆盖数据广播覆盖方案采用MPEG-2物理层和链路层提供额外的连接，如单向多播，以补充现有的基于IP的互联网服务。这种网络的示例包括到移动无线接收器的IP数据广播[MMUSIC-IMG]。
E) Point-to-Point Links Point-to-Point connectivity may be provided using a pair of transmit and receive interfaces supporting the MPEG-2 physical and link layers. Typically, the transmission from a sender is received by only one or a small number of Receivers. Examples include the use of transmit/receive DVB-S terminals to provide satellite links between ISPs utilising BGP routing.
E） 可以使用一对支持MPEG-2物理层和链路层的发送和接收接口来提供点到点链路点到点连接。通常，来自发送方的传输仅由一个或少量接收机接收。示例包括使用发送/接收DVB-S终端，利用BGP路由在ISP之间提供卫星链路。
F) Two-Way IP Networks Two-Way IP networks are typically satellite-based and star-based utilising a Hub station to deliver a common bit stream to medium-sized groups of receivers. A bidirectional service is provided over a common air-interface. The transmission technology in the forward direction at the physical and link layers is MPEG-2, which may also be used in the return direction. Such systems also usually include a control plane element to manage the (shared) return link capacity. A concrete example is the DVB-RCS system [ETSI-DVBRCS]. IP services typically form the main proportion of the transmission traffic.
F） 双向IP网络双向IP网络通常是基于卫星和基于星的网络，利用集线器站将公共比特流传送到中型接收机组。通过公共空中接口提供双向服务。物理层和链路层的前向传输技术是MPEG-2，其也可用于返回方向。此类系统通常还包括一个控制平面元件，用于管理（共享）返回链路容量。一个具体的例子是DVB-RCS系统[ETSI-DVBRCS]。IP服务通常构成传输流量的主要部分。
Scenarios A-D employ unidirectional MPEG-2 Transmission Networks. For satellite-based networks, these typically have a star topology, with a central Hub providing service to large numbers of down-stream Receivers. Terrestrial networks may employ several transmission Hubs, each serving a particular coverage cell with a community of Receivers.
场景A-D采用单向MPEG-2传输网络。对于基于卫星的网络，这些网络通常具有星形拓扑结构，中央集线器向大量下游接收器提供服务。地面网络可以采用多个传输集线器，每个集线器为具有接收器社区的特定覆盖小区服务。
From an IP viewpoint, the service is typically either unidirectional multicast, or a bidirectional service in which some complementary link technology (e.g., modem, Local Multipoint Distribution Service (LMDS), General Packet Radio Service (GPRS)) is used to provide the return path from Receivers to the Internet. In this case, routing could be provided using UniDirectional Link Routing (UDLR) [RFC3077].
从IP的观点来看，该服务通常是单向多播或双向服务，其中一些补充链路技术（例如，调制解调器、本地多点分发服务（LMDS）、通用分组无线电服务（GPRS））用于提供从接收机到因特网的返回路径。在这种情况下，可以使用单向链路路由（UDLR）[RFC3077]提供路由。
Note that only Scenarios A-B actually carry MPEG-2 video and audio (intended for reception by digital Set Top Boxes (STBs)) as the primary traffic. The other scenarios are IP-based data networks and need not necessarily implement the MPEG-2 control plane.
请注意，只有场景A-B实际将MPEG-2视频和音频（用于数字机顶盒（STB）接收）作为主要通信量。其他场景是基于IP的数据网络，不必实现MPEG-2控制平面。
Scenarios E-F provide two-way connectivity using the MPEG-2 Transmission Network. Such networks provide direct support for bidirectional protocols above and below the IP layer.
场景E-F使用MPEG-2传输网络提供双向连接。这种网络直接支持IP层上下的双向协议。
The complete MPEG-2 transmission network may be managed by a transmission service operator. In such cases, the assignment of addresses and TS Logical Channels at Receivers are usually under the control of the service operator. Examples include a TV operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission networks are also used for private networks. These typically involve a smaller number of Receivers and do not require the same level of centralized control. Examples include companies wishing to connect DVB-capable routers to form links within the Internet (Scenario B).
完整的MPEG-2传输网络可由传输服务运营商管理。在这种情况下，地址和TS逻辑信道在接收器的分配通常由服务运营商控制。示例包括电视运营商（场景a）或ISP（场景B-F）。MPEG-2传输网络也用于专用网络。这些通常涉及较少数量的接收器，并且不需要相同级别的集中控制。示例包括希望连接支持DVB的路由器以在互联网内形成链接的公司（场景B）。
An MPEG-2 Transport Multiplex offers a number of parallel channels, which are known here as TS Logical Channels. Each TS Logical Channel is uniquely identified by the Packet ID (PID) value that is carried in the header of each MPEG-2 TS Packet. The PID value is a 13 bit field; thus, the number of available channels ranges from 0 to 8191 decimal or 0x1FFF in hexadecimal, some of which are reserved for transmission of SI tables. Non-reserved TS Logical Channels may be used to carry audio [ISO-AUD], video [ISO-VID], IP packets [ISO-DSMCC, ETSI-DAT, ATSC-DAT], or other data [ISO-DSMCC, ETSI-DAT, ATSC-DAT]. The value 8191 decimal (0x1FFF) indicates a null packet that is used to maintain the physical bearer bit rate when there are no other MPEG-2 TS packets to be sent.
MPEG-2传输多路复用提供许多并行信道，这里称为TS逻辑信道。每个TS逻辑信道由每个MPEG-2ts分组的报头中携带的分组ID（PID）值唯一地标识。PID值是一个13位字段；因此，可用通道的数量范围为0到8191十进制或十六进制0x1FFF，其中一些保留用于传输SI表。非保留TS逻辑信道可用于承载音频[ISO-AUD]、视频[ISO-VID]、IP分组[ISO-DSMCC、ETSI-DAT、ATSC-DAT]或其他数据[ISO-DSMCC、ETSI-DAT、ATSC-DAT]。值8191 decimal（0x1FF）表示在没有其他MPEG-2 TS数据包要发送时用于保持物理承载比特率的空数据包。
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried Over 2 MPEG-2 TS Multiplexes.
图2：示例显示通过2个MPEG-2 TS多路复用传输的MPEG-2 TS逻辑信道。
TS Logical Channels are independently numbered on each MPEG-2 TS Multiplex (MUX). In most cases, the data sent over the TS Logical Channels will differ for different multiplexes. Figure 2 shows a set of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and B).
TS逻辑信道在每个MPEG-2 TS多路复用（MUX）上独立编号。在大多数情况下，通过TS逻辑通道发送的数据对于不同的多路复用将不同。图2显示了使用两个MPEG-2 TS多路复用器（a和B）发送的一组TS逻辑信道。
There are cases where the same data may be distributed over two or more multiplexes (e.g., some SI tables; multicast content that needs to be received by Receivers tuned to either MPEG-2 TS; unicast data where the Receiver may be in either/both of two potentially overlapping MPEG-2 transmission cells). In figure 2, each multiplex carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be common to both MPEG-2 TS Multiplexes (i.e., TS-LC-A-3 and TS-LC-B-3 carry identical content).
有些情况下，相同的数据可能分布在两个或多个多路复用器上（例如，一些SI表；需要由调谐到任一MPEG-2 TS的接收器接收的多播内容；其中接收器可能位于两个潜在重叠的MPEG-2传输小区中的任一个/两个中的单播数据）。在图2中，每个多路复用携带3个MPEG-2 TS逻辑信道。这些TS逻辑信道可能不同（TS-LC-A-1、TS-LC-A-2、TS-LC-B-2、TS-LC-B-1），或者可能对两个MPEG-2 TS多路复用共用（即，TS-LC-A-3和TS-LC-B-3承载相同的内容）。
As can been seen, there are similarities between the way PIDs are used and the operation of virtual channels in ATM. However, unlike ATM, a PID defines a unidirectional broadcast channel and not a point-to-point link. Contrary to ATM, there is, as yet, no specified
可以看出，PIDs的使用方式与ATM中虚拟通道的操作有相似之处。然而，与ATM不同，PID定义了单向广播信道，而不是点对点链路。与自动取款机相反，到目前为止，还没有规定
standard interface for MPEG-2 connection setup, or for signaling mappings of IP flows to PIDs, or to set the Quality of Service, QoS, assigned to a TS Logical Channel.
用于MPEG-2连接设置的标准接口，或用于IP流到PID的信令映射，或用于设置分配给TS逻辑信道的服务质量（QoS）的标准接口。
In a simple example, one or more TS Logical Channels are processed by an MPEG-2 multiplexor, resulting in a TS Multiplex. The TS Multiplex is forwarded over a physical bearer towards one or more Receivers (Figure 3).
在一个简单的示例中，一个或多个TS逻辑信道由MPEG-2多路复用器处理，从而产生TS多路复用。TS多路复用通过物理承载转发到一个或多个接收机（图3）。
In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenarios A and B of Section 3.1). One example is a satellite that provides on-board processing of the TS packets, multiplexing the TS Logical Channels received from one or more uplink physical bearers (TS Multiplex) to one (or more in the case of broadcast/multicast) down-link physical bearer (TS Multiplex). As part of the remultiplexing process, a remultiplexor may renumber the PID values associated with one or more TS Logical Channels to prevent clashes between input TS Logical Channels with the same PID carried on different input multiplexes. It may also modify and/or insert new SI data into the control plane.
在更复杂的示例中，相同的TS可以馈送到多个MPEG-2多路复用器，并且这些TS可以反过来馈送其他MPEG-2多路复用器（重多路复用）。再多路复用可能发生在多个地方（在第3.1节的场景A和B中很常见）。一个示例是卫星，其提供TS分组的车载处理，将从一个或多个上行链路物理承载（TS复用）接收的TS逻辑信道复用到一个（或多个，在广播/组播的情况下）下行链路物理承载（TS复用）。作为重多路复用过程的一部分，重多路复用器可以对与一个或多个TS逻辑信道相关联的PID值重新编号，以防止在不同输入多路复用器上携带相同PID的输入TS逻辑信道之间发生冲突。它还可以修改和/或将新的SI数据插入控制平面。
In all cases, the final result is a "TS Multiplex" that is transmitted over the physical bearer towards the Receiver.
在所有情况下，最终结果是通过物理承载向接收机发送的“TS多路复用”。
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 3: An example configuration for a unidirectional Service for IP transport over MPEG-2
图3:MPEG-2上IP传输的单向服务配置示例
Packet data for transmission over an MPEG-2 Transport Multiplex is passed to an Encapsulator, sometimes known as a Gateway. This receives Protocol Data Units, PDUs, such as Ethernet frames or IP packets, and formats each into a Sub-Network Data Unit, SNDU, by adding an encapsulation header and trailer (see Section 4). The SNDUs are subsequently fragmented into a series of TS Packets.
用于通过MPEG-2传输多路复用传输的分组数据被传递到封装器，有时称为网关。它接收协议数据单元PDU，如以太网帧或IP数据包，并通过添加封装头和尾部（参见第4节）将每个协议数据单元格式化为子网数据单元SNDU。sndu随后被分割成一系列TS分组。
To receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs to identify the specific TS Multiplex (physical link) and also the TS Logical Channel (the PID value of a logical link). It is common for a number of MPEG-2 TS Logical Channels to carry SNDUs; therefore, a Receiver must filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU.
要通过MPEG-2 TS多路复用接收IP数据包，接收器需要识别特定的TS多路复用（物理链路）和TS逻辑信道（逻辑链路的PID值）。许多MPEG-2ts逻辑信道携带sndu是常见的；因此，接收器必须过滤（接受）使用多个PID值发送的IP数据包，并且必须独立地重新组装每个SNDU。
A Receiver that simultaneously receives from several TS Logical Channels must filter other unwanted TS Logical Channels by employing, for example, specific hardware support. Packets for one IP flow (i.e., a specific combination of IP source and destination addresses) must be sent using the same PID. It should not be assumed that all IP packets are carried on a single PID, as in some cable modem implementations, and multiple PIDs must be allowed in the architecture. Many current hardware filters limit the maximum number of active PIDs (e.g., 32), although if needed, future systems may reasonably be expected to support more.
同时从多个TS逻辑信道接收的接收机必须通过采用例如特定硬件支持来过滤其他不需要的TS逻辑信道。一个IP流（即IP源地址和目标地址的特定组合）的数据包必须使用相同的PID发送。不应假设所有IP数据包都在一个PID上传输，就像在某些电缆调制解调器实现中一样，体系结构中必须允许多个PID。许多当前的硬件过滤器限制了活动PID的最大数量（例如32个），但如果需要，未来的系统可能会支持更多。
In some cases, Receivers may need to select TS Logical Channels from a number of simultaneously active TS Multiplexes. To do this, they need multiple physical receive interfaces (e.g., radio frequency (RF) front-ends and demodulators). Some applications also envisage the concurrent reception of IP Packets over other media that may not necessarily use MPEG-2 transmission.
在某些情况下，接收机可能需要从多个同时活动的TS多路复用器中选择TS逻辑信道。为此，他们需要多个物理接收接口（例如，射频（RF）前端和解调器）。一些应用还设想通过不一定使用MPEG-2传输的其他媒体同时接收IP分组。
Bidirectional (duplex) transmission can be provided using an MPEG-2 Transmission Network by using one of a number of alternate return channel schemes [ETSI-RC]. Duplex IP paths may also be supported using non-MPEG-2 return links (e.g., in Scenarios B-D of section 3.1). One example of such an application is that of UniDirectional Link Routing, UDLR [RFC3077].
通过使用多个备用返回信道方案[ETSI-RC]中的一个，可以使用MPEG-2传输网络来提供双向（双工）传输。还可以使用非MPEG-2返回链路支持双工IP路径（例如，在第3.1节的场景B-D中）。这种应用的一个例子是单向链路路由UDLR[RFC3077]。
The network layer protocols to be supported by this architecture include:
此体系结构支持的网络层协议包括：
(i) IPv4 Unicast packets, destined for a single end host
(i) IPv4单播数据包，目的地为单端主机
(ii) IPv4 Broadcast packets, sent to all end systems in an IP network
（ii）发送到IP网络中所有终端系统的IPv4广播数据包
(iii) IPv4 Multicast packets
（iii）IPv4多播数据包
(iv) IPv6 Unicast packets, destined for a single end host
（iv）目的地为单端主机的IPv6单播数据包
(v) IPv6 Multicast packets
(v) IPv6多播数据包
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g., [RFC2507, RFC3095])
（vi）具有压缩IPv4/IPv6数据包头的数据包（例如，[RFC2507，RFC3095]）
(vii) Bridged Ethernet frames
（vii）桥接以太网帧
(viii) Other network protocol packets (MPLS, potential new protocols)
（viii）其他网络协议包（MPLS，潜在的新协议）
The architecture will provide:
该体系结构将提供：
(i) Guidance on which MPEG-2 features are pre-requisites for the IP service, and identification of any optional fields that impact performance/correct operation.
(i) 指导哪些MPEG-2功能是IP服务的先决条件，以及识别影响性能/正确操作的任何可选字段。
(ii) Standards to provide an efficient and flexible encapsulation scheme that may be easily implemented in an Encapsulator or Receiver. The payload encapsulation requires a type field for the SNDU to indicate the type of packet and a mechanism to signal which encapsulation is used on a certain PID.
（ii）提供可在封装器或接收器中轻松实施的高效灵活封装方案的标准。有效负载封装需要SNDU的类型字段来指示数据包的类型，并需要一种机制来通知在特定PID上使用了哪种封装。
(iii) Standards to associate a particular IP address with a Network Point of Attachment (NPA) that could or may not be a MAC Address. This process resembles the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol [IPDVB-AR]. In addition, the standard will be compatible with IPv6 autoconfiguration.
（iii）将特定IP地址与可能是或可能不是MAC地址的网络连接点（NPA）关联的标准。此过程类似于IPv4地址解析协议ARP或IPv6邻居发现协议ND[IPDVB-AR]。此外，该标准将与IPv6自动配置兼容。
(iv) Standards to associate an MPEG-2 TS interface with one or more specific TS Logical Channels (PID, TS Multiplex). Bindings are required for both unicast transmission, and multicast reception. In the case of IPv4, this must also support network broadcast. To make the schemes robust to loss and state changes within the MPEG-2 transmission network, a soft-state approach may prove desirable.
（iv）将MPEG-2 TS接口与一个或多个特定TS逻辑信道（PID、TS多路复用）关联的标准。单播传输和多播接收都需要绑定。在IPv4的情况下，它还必须支持网络广播。为了使方案对MPEG-2传输网络内的丢失和状态变化具有鲁棒性，可以证明需要软状态方法。
(v) Standards to associate the capabilities of an MPEG-2 TS Logical Channel with IP flows. This includes mapping of QoS functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS, multi-homing and mobility. This capability could be associated by the AR standard proposed above.
(v) 将MPEG-2 TS逻辑通道的功能与IP流相关联的标准。这包括将QoS功能（如IP QoS/DSCP和RSVP）映射到底层MPEG-2 TS QoS、多归属和移动性。上述AR标准可将该能力关联起来。
(vi) Guidance on Security for IP transmission over MPEG-2. The framework must permit use of IPsec and clearly identify any security issues concerning the specified protocols. The security issues need to consider two cases: unidirectional transfer (in which communication is only from the sending IP end host to the receiving IP end host) and bidirectional transfer. Consideration should also be given to security of the TS Multiplex: the need for closed user groups and the use of MPEG-2 TS encryption.
（vi）MPEG-2上IP传输的安全指南。框架必须允许使用IPsec，并明确识别与指定协议有关的任何安全问题。安全问题需要考虑两种情况：单向传输（其中通信只从发送IP端主机到接收IP端主机）和双向传输。还应考虑TS多路复用的安全性：需要封闭的用户组和使用MPEG-2 TS加密。
(vii) Management of the IP transmission, including standardized SNMP MIBs and error reporting procedures. The need for and scope of this is to be determined.
（vii）管理IP传输，包括标准化SNMP MIB和错误报告程序。这方面的需要和范围有待确定。
The specified architecture and techniques should be suited to a range of systems employing the MPEG-2 TS, and may also suit other (sub)networks offering similar transfer capabilities.
指定的架构和技术应当适合于采用MPEG-2ts的一系列系统，并且还可以适合于提供类似传输能力的其他（子）网络。
The following section, 4, describes encapsulation issues. Sections 5 and 6 describe address resolution issues for unicast and multicast, respectively.
下面的第4节描述了封装问题。第5节和第6节分别描述了单播和多播的地址解析问题。
This section identifies requirements and provides examples of mechanisms that may be used to perform the encapsulation of IPv4/v6 unicast and multicast packets over MPEG-2 Transmission Networks.
本节确定了需求，并提供了可用于在MPEG-2传输网络上封装IPv4/v6单播和多播数据包的机制示例。
A network device, known as an Encapsulator receives PDUs (e.g., IP Packets or Ethernet frames) and formats these into Subnetwork Data Units, SNDUs. An encapsulation (or convergence) protocol transports each SNDU over the MPEG-2 TS service and provides the appropriate mechanisms to deliver the encapsulated PDU to the Receiver IP interface.
称为封装器的网络设备接收PDU（例如，IP数据包或以太网帧），并将其格式化为子网数据单元SNDU。封装（或聚合）协议通过MPEG-2 TS服务传输每个SNDU，并提供适当的机制将封装的PDU传送到接收器IP接口。
In forming an SNDU, the encapsulation protocol typically adds header fields that carry protocol control information, such as the length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers, etc. The SNDU payload is typically followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols also add additional control information and/or padding to or after the trailer (figure 4).
在形成SNDU时，封装协议通常添加承载协议控制信息的报头字段，例如SNDU的长度、接收器地址、多路复用信息、有效载荷类型、序列号等。SNDU有效载荷后面通常是承载完整性检查（例如，循环冗余检查、CRC）的尾部. 一些协议还向拖车添加额外的控制信息和/或填充（图4）。
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6 packet) to form an MPEG-2 Payload Unit.
图4：封装子网PDU（例如IPv4或IPv6数据包）以形成MPEG-2有效负载单元。
Examples of existing encapsulation/convergence protocols include ATM AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT].
现有封装/汇聚协议的示例包括ATM AAL5[ITU-AAL5]和MPEG-2 MPE[ETSI-DAT]。
When required, an SNDU may be fragmented across a number of TS Packets (figure 5).
当需要时，SNDU可以跨多个TS数据包分段（图5）。
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a Series of MPEG-2 TS Packets. Each TS Packet carries a header with a common Packet ID (PID) value denoting the MPEG-2 TS Logical Channel.
图5：将PDU（例如IP数据包）封装到一系列MPEG-2 TS数据包中。每个TS包携带一个具有公共分组ID（PID）值的报头，该值表示MPEG-2ts逻辑信道。
The DVB family of standards currently defines a mechanism for transporting an IP packet, or Ethernet frame using the Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of IP packets or (by using LLC) Ethernet frames by encapsulation within a Table Section (with the format used by the control plane associated with the MPEG-2 transmission). The MPE specification includes a set of optional header components and requires decoding of the control headers. This processing is suboptimal for Internet traffic, since it incurs significant receiver processing overhead and some extra link overhead [CLC99].
DVB系列标准目前定义了使用多协议封装（MPE）[ETSI-DAT]传输IP数据包或以太网帧的机制。ATSC[ATSC-DAT，ATSC-DATG]中也支持等效方案。它允许通过封装在一个表段内（使用与MPEG-2传输相关联的控制平面所使用的格式）来传输IP数据包或（通过使用LLC）以太网帧。MPE规范包括一组可选的报头组件，需要对控制报头进行解码。这种处理对于互联网流量来说是次优的，因为它会产生大量的接收器处理开销和一些额外的链路开销[CLC99]。
The existing standards carry heritage from legacy implementations. These have reflected the limitations of technology at the time of their deployment (e.g., design decisions driven by audio/video considerations rather than IP networking requirements). IPv6, MPLS, and other network-layer protocols are not natively supported. Together, these justify the development of a new encapsulation that will be truly IP-centric. Carrying IP packets over a TS Logical Channel involves several convergence protocol functions. This section briefly describes these functions and highlights the requirements for a new encapsulation.
现有标准继承了遗留实现的传统。这些都反映了其部署时技术的局限性（例如，由音频/视频考虑因素而非IP网络需求驱动的设计决策）。IPv6、MPLS和其他网络层协议本机不受支持。总之，这些都证明了开发一种真正以IP为中心的新封装是合理的。通过TS逻辑信道承载IP数据包涉及多个汇聚协议功能。本节简要介绍这些功能，并重点介绍新封装的要求。
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in the 4B TS Packet header. The PUSI is a 1 bit flag that has normative meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI data.
MPEG-2表示新TS数据包中有效负载单元（PU）的开始，其中4B TS数据包报头中带有“有效负载单元开始指示符”（PUSI）[ISO-MPEG]。PUSI是一个1位标志，对于携带PES数据包或PSI/SI数据的TS数据包具有规范意义[ISO-MPEG]。
When the payload of a TS Packet contains PES data, a PUSI value of '1' indicates the TS Packet payload starts with the first byte of a PES Packet. A value of '0' indicates that no PES Packet starts in the TS Packet. If the PUSI is set to '1', then one, and only one, PES Packet starts in the TS Packet.
当TS数据包的有效载荷包含PES数据时，PUSI值“1”表示TS数据包有效载荷从PES数据包的第一个字节开始。值“0”表示TS数据包中没有PES数据包开始。如果PUSI设置为“1”，则TS数据包中开始一个且仅一个PES数据包。
When the payload of the TS Packet contains PSI data, a PUSI value of '1' indicates the first byte of the TS Packet payload carries a Payload Pointer (PP) that indicates the position of the first byte of the Payload Unit (Table Section) being carried; if the TS Packet does not carry the first byte of a Table Section, the PUSI is set to '0', indicating that no Payload Pointer is present.
当TS数据包的有效载荷包含PSI数据时，PUSI值“1”表示TS数据包有效载荷的第一字节携带有效载荷指针（PP），该有效载荷指针指示所携带的有效载荷单元（表部分）的第一字节的位置；如果TS数据包不携带表段的第一个字节，则PUSI设置为“0”，表示不存在有效负载指针。
Using this PUSI bit, the start of the first Payload Unit in a TS Packet is exactly known by the Receiver, unless that TS Packet has been corrupted or lost in the transmission. In which case, the payload is discarded until the next TS Packet is received with a PUSI value of '1'.
使用该PUSI比特，接收机确切地知道TS分组中第一有效载荷单元的开始，除非该TS分组在传输中已损坏或丢失。在这种情况下，有效载荷被丢弃，直到接收到下一个具有PUSI值“1”的TS分组。
The encapsulation should allow packing of more than one SNDU into the same TS Packet and should not limit the number of SNDUs that can be sent in a TS Packet. In addition, it should allow an IP Encapsulator to insert padding when there is an incomplete TS Packet payload. A mechanism needs to be identified to differentiate this padding from the case where another encapsulated SNDU follows.
封装应允许将多个SNDU打包到同一TS数据包中，且不应限制TS数据包中可发送的SNDU数量。此外，当TS数据包负载不完整时，它应该允许IP封装器插入填充。需要确定一种机制来区分这种填充和另一种封装SNDU的情况。
A combination of the PUSI and a Length Indicator (see below) allows an efficient MPEG-2 convergence protocol to receive accurate delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not specify how private data should use the PUSI bit.
PUSI和长度指示符（见下文）的组合允许高效的MPEG-2收敛协议接收压缩SNDU的准确描述。MPEG-2标准[ISO-MPEG]没有规定私有数据应如何使用PUSI位。
Most services using MPEG-2 include a length field in the Payload Unit header to allow the Receiver to identify the end of a Payload Unit (e.g., PES Packet, Section, or an SNDU).
使用MPEG-2的大多数服务在有效载荷单元报头中包括长度字段，以允许接收器识别有效载荷单元的末端（例如，PES分组、部分或SNDU）。
When parts of more than two Payload Units are carried in the same TS Packet, only the start of the first is indicated by the Payload Pointer. Placement of a Length Indicator in the encapsulation header allows a Receiver to determine the number of bytes until the start of the next encapsulated SNDU. This placement also provides the opportunity for the Receiver to pre-allocate an appropriate-sized memory buffer to receive the reassembled SNDU.
当两个以上有效负载单元的一部分被携带在同一TS数据包中时，有效负载指针仅指示第一个有效负载单元的开始。在封装头中放置长度指示符允许接收器确定字节数，直到下一个封装SNDU开始。这种放置还为接收器提供了预分配适当大小的内存缓冲区以接收重新组装的SNDU的机会。
A Length Indicator is required, and should be carried in the encapsulation header. This should support SNDUs of at least the MTU size offered by Ethernet (currently 1500 bytes). Although the IPv4
需要一个长度指示器，并应在封装头中携带。这应至少支持以太网提供的MTU大小的SNDU（目前为1500字节）。虽然IPv4
and IPv6 packet format permits an IP packet of size up to 64 KB, such packets are seldom seen on the current Internet. Since high speed links are often limited by the packet forwarding rate of routers, there has been a tendency for Internet core routers to support MTU values larger than 1500 bytes. A value of 16 KB is not uncommon in the core of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network.
IPv6数据包格式允许一个最大为64KB的IP数据包，这种数据包在当前的互联网上很少见到。由于高速链路通常受到路由器的数据包转发速率的限制，因此互联网核心路由器倾向于支持大于1500字节的MTU值。16 KB的值在当前互联网的核心中并不少见。对于MPEG-2传输网络来说，这似乎是一个合适的最大大小。
Any IETF-defined encapsulation protocol should identify the payload type being transported (e.g., to differentiate IPv4, IPv6, etc). Most protocols use a type field to identify a specific process at the next higher layer that is the originator or the recipient of the payload (SNDU). This method is used by IPv4, IPv6, and also by the original Ethernet protocol (DIX). OSI uses the concept of a 'Selector' for this, (e.g., in the IEEE 802/ISO 8802 standards for CSMA/CD [LLC]; although in this case, a SNAP (subnetwork access protocol) header is also required for IP packets.
任何IETF定义的封装协议都应标识正在传输的有效负载类型（例如，区分IPv4、IPv6等）。大多数协议使用类型字段来标识下一个更高层的特定进程，即有效负载（SNDU）的发起方或接收方。IPv4、IPv6和原始以太网协议（DIX）都使用这种方法。OSI为此使用了“选择器”的概念（例如，在针对CSMA/CD[LLC]的IEEE 802/ISO 8802标准中）；尽管在这种情况下，IP数据包也需要SNAP（子网访问协议）报头。
A Next Level Protocol Type field is also required if compression (e.g., Robust Header Compression [RFC3095]) is supported. No compression method has currently been defined that is directly applicable to this architecture, however the ROHC framework defines a number of header compression techniques that may yield considerable improvement in throughput on links that have a limited capacity. Since many MPEG-2 Transmission Networks are wireless, the ROHC framework will be directly applicable for many applications. The benefit of ROHC is greatest for smaller SNDUs but does imply the need for additional processing at the Receiver to expand the received compressed packets. The selected type field should contain sufficient code points to support this technique.
如果支持压缩（例如，鲁棒头压缩[RFC3095]），则还需要下一级协议类型字段。目前还没有定义直接适用于该体系结构的压缩方法，但是ROHC框架定义了许多头压缩技术，这些技术可以在容量有限的链路上显著提高吞吐量。由于许多MPEG-2传输网络是无线的，ROHC框架将直接适用于许多应用。ROHC的好处对于较小的SNDU来说是最大的，但确实意味着需要在接收器处进行额外的处理以扩展接收到的压缩数据包。所选类型字段应包含足够的代码点以支持此技术。
It is thus a requirement to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4, IPv6, and must allow for other values (e.g., MAC-level bridging).
因此，要求在封装头中包含下一级协议类型字段。此类字段应至少指定IPv4、IPv6的值，并且必须允许其他值（例如MAC级桥接）。
In MPEG-2, the PID carried in the TS Packet header is used to identify individual services with the help of SI tables. This was primarily intended as a unidirectional (simplex) broadcast system. A TS Packet stream carries either tables or one PES Packet stream (i.e., compressed video or audio). Individual Receivers are not addressable at this level.
在MPEG-2中，TS数据包报头中携带的PID用于借助SI表识别单个服务。这主要用于单向（单工）广播系统。TS分组流携带表或一个PES分组流（即，压缩视频或音频）。单个接收器在此级别不可寻址。
IPv4 and IPv6 allocate addresses to end hosts and intermediate systems (routers). Each system (or interface) is identified by a globally assigned address. ISO uses the concept of a hierarchically structured Network Service Access Point (NSAP) address to identify an end host user process in an Internet environment.
IPv4和IPv6将地址分配给终端主机和中间系统（路由器）。每个系统（或接口）由全局分配的地址标识。ISO使用分层结构网络服务接入点（NSAP）地址的概念来标识Internet环境中的最终主机用户进程。
Within a local network, a completely different set of addresses for the Network Point of Attachment (NPA) is used; frequently these NPA addresses are referred to as Medium Access Control, MAC-level addresses. In the Internet they are also called hardware addresses. Whereas network layer addresses are used for routing, NPA addresses are primarily used for Receiver identification.
在本地网络中，使用一组完全不同的网络连接点（NPA）地址；这些NPA地址通常称为介质访问控制MAC级地址。在互联网上，它们也被称为硬件地址。网络层地址用于路由，而NPA地址主要用于识别接收器。
Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the (software) interface driver at the Receiver, but must also perform forwarding checks based on the IP address. IP multicast and broadcast may also filter using the NPA, but Receivers must also filter unwanted packets at the network layer based on source and destination IP addresses. This does not imply that each IP address must map to a unique NPA (more than one IP address may map to the same NPA). If a separate NPA address is not required, the IP address is sufficient for both functions.
接收机可以使用接收到的SNDU的NPA来拒绝接收机处（软件）接口驱动程序内不需要的单播分组，但是还必须基于IP地址执行转发检查。IP多播和广播也可以使用NPA进行过滤，但是接收器还必须基于源和目标IP地址在网络层过滤不需要的数据包。这并不意味着每个IP地址必须映射到唯一的NPA（多个IP地址可能映射到同一NPA）。如果不需要单独的NPA地址，则IP地址足以满足这两种功能。
If it is required to address an individual Receiver in an MPEG-2 transport system, this can be achieved either at the network level (IP address) or via a hardware-level NPA address (MAC-address). If both addresses are used, they must be mapped in either a static or a dynamic way (e.g., by an address resolution process). A similar requirement may also exist to identify the PID and TS multiplex on which services are carried.
如果需要在MPEG-2传输系统中寻址单个接收器，则可以在网络级别（IP地址）或通过硬件级别的NPA地址（MAC地址）来实现。如果使用两个地址，则必须以静态或动态方式（例如，通过地址解析过程）映射它们。还可能存在类似的要求，以识别承载服务的PID和TS多路复用。
Using an NPA address in an MPEG-2 TS may enhance security, in that a particular PDU may be targeted for a particular Receiver by specifying the corresponding Receiver NPA address. However, this is only a weak form of security, since the NPA filtering is often reconfigurable (frequently performed in software), and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. If security is required, it should be applied at another place (e.g., link encryption, authentication of address resolution, IPsec, transport level security and/or application level security).
在MPEG-2ts中使用NPA地址可以增强安全性，因为通过指定相应的接收机NPA地址，特定PDU可以针对特定接收机。然而，这只是一种弱的安全形式，因为NPA过滤通常是可重新配置的（通常在软件中执行），并且可以由用户修改以允许接收指定（或全部）分组，类似于以太网中的混杂模式操作。如果需要安全性，则应在其他位置应用安全性（例如，链路加密、地址解析验证、IPsec、传输级安全性和/或应用程序级安全性）。
There are also cases where the use of an NPA is required (e.g., where a system operates as a router) and, if present, this should be carried in an encapsulation header where it may be used by Receivers as a pre-filter to discard unwanted SNDUs. The addresses allocated do not need to conform to the IEEE MAC address format. There are many cases where an NPA is not required, and network layer filtering
还存在需要使用NPA的情况（例如，当系统作为路由器运行时），并且如果存在，则应将其携带在封装报头中，其中接收机可将其用作预过滤器以丢弃不需要的SNDU。分配的地址不需要符合IEEE MAC地址格式。在许多情况下，不需要NPA和网络层过滤
may be used. Therefore, a new encapsulation protocol should support an optional NPA.
可以使用。因此，新的封装协议应该支持可选的NPA。
For the IP service, the probability of undetected packet error should be small (or negligible) [RFC3819]. Therefore, there is a need for a strong integrity check (e.g., Cyclic Redundancy Check or CRC) to verify correctness of a received PDU [RFC3819]. Such checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss/corruption of TS Packets), in addition to protecting from loss and/or corruption by the transmission network (e.g., multiplexors and links).
对于IP服务，未检测到的数据包错误的概率应该很小（或可以忽略不计）[RFC3819]。因此，需要进行强完整性检查（例如，循环冗余检查或CRC），以验证接收到的PDU的正确性[RFC3819]。除了防止传输网络（例如多路复用器和链路）的丢失和/或损坏外，此类检查应足以检测封装器和接收器的错误操作（包括TS数据包丢失/损坏后的重新组装错误）。
Mechanisms exist in MPEG-2 Transmission Networks that may assist in detecting loss (e.g., the 4-bit continuity counter included in the MPEG-2 TS Packet header).
在MPEG-2传输网络中存在可协助检测丢失的机制（例如，包括在MPEG-2ts分组报头中的4位连续性计数器）。
An encapsulation must provide a strong integrity check for each IP packet. The requirements for usage of a link CRC are provided in [RFC3819]. To ease hardware implementation, this check should be carried in a trailer following the SNDU. A CRC-32 is sufficient for operation with up to a 12 KB payload, and may still provide adequate protection for larger payloads.
封装必须为每个IP数据包提供强大的完整性检查。[RFC3819]中提供了链路CRC的使用要求。为了简化硬件实现，该检查应在SNDU之后的拖车中进行。CRC-32足以在高达12KB的有效负载下运行，并且仍然可以为较大的有效负载提供足够的保护。
4.6. Identification of Scope.
4.6. 确定范围。
The MPE section header contains information that could be used by the Receiver to identify the scope of the (MAC) address carried as an NPA, and to prevent TS Packets intended for one scope from being received by another. Similar functionality may be achieved by ensuring that only IP packets that do not have overlapping scope are sent on the same TS Logical Channel. In some cases, this may imply the use of multiple TS Logical Channels.
MPE部分报头包含可由接收器用于识别作为NPA携带的（MAC）地址的范围以及防止用于一个范围的TS分组被另一个范围接收的信息。通过确保在同一TS逻辑信道上仅发送不具有重叠作用域的IP分组，可以实现类似的功能。在某些情况下，这可能意味着使用多个TS逻辑信道。
The evolution of the Internet service may require additional functions in the future. A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration.
未来，互联网服务的发展可能需要额外的功能。因此，灵活的协议应提供一种在需要时引入新功能的方法，而不必提供额外的带外配置。
IPv6 introduced the concept of extension headers that carry extra information necessary/desirable for certain subnetworks. The DOCSIS cable specification also allows a MAC header to carry extension headers to build operator-specific services. Thus, it is a requirement for the new encapsulation to allow extension headers.
IPv6引入了扩展头的概念，扩展头携带了某些子网所需的额外信息。DOCSIS电缆规范还允许MAC报头携带扩展报头，以构建特定于运营商的服务。因此，新封装需要允许扩展头。
The main requirements for an IP-centric encapsulation include:
以IP为中心的封装的主要要求包括：
- support of IPv4 and IPv6 packets - support for Ethernet encapsulated packets - flexibility to support other IP formats and protocols (e.g., ROHC, MPLS) - easy implementation using either hardware or software processing - low overhead/managed overhead - a fully specified algorithm that allows a sender to pack multiple packets per SNDU and to easily locate packet fragments - extensibility - compatibility with legacy deployments - ability to allow link encryption, when required - capability to support a full network architecture including data, control, and management planes
- 支持IPv4和IPv6数据包-支持以太网封装数据包-支持其他IP格式和协议（如ROHC、MPLS）的灵活性-使用硬件或软件处理的简单实现-低开销/管理开销-一种完全指定的算法，允许发送方为每个SNDU打包多个数据包并轻松定位数据包片段-可扩展性-与传统部署的兼容性-允许链路加密的能力，必要时—支持完整网络体系结构（包括数据、控制和管理平面）的能力
Address Resolution (AR) provides a mechanism that associates layer 2 (L2) information with the IP address of a system [IPDVB-AR]. Many L2 technologies employ unicast AR at the sender: an IP system wishing to send an IP packet encapsulates it and places it into an L2 frame. It then identifies the appropriate L3 adjacency (e.g., next hop router, end host) and determines the appropriate L2 adjacency (e.g., MAC address in Ethernet) to which the frame should be sent so that the packet gets across the L2 link.
地址解析（AR）提供了将第2层（L2）信息与系统IP地址关联的机制[IPDVB-AR]。许多L2技术在发送方使用单播AR：希望发送IP数据包的IP系统将其封装并将其放入L2帧中。然后，它确定适当的L3邻接（例如，下一跳路由器、终端主机），并确定帧应发送到的适当L2邻接（例如，以太网中的MAC地址），以便数据包通过L2链路。
The L2 addresses discovered using AR are normally recorded in a data structure known as the arp/neighbor cache. The results of previous AR requests are usually cached. Further AR protocol exchanges may be required as communication proceeds to update or re-initialize the client cache state contents (i.e., purge/refresh the contents). For stability, and to allow network topology changes and client faults, the cache contents are normally "soft state"; that is, they are aged with respect to time and old entries are removed.
使用AR发现的二级地址通常记录在称为arp/邻居缓存的数据结构中。以前AR请求的结果通常被缓存。当通信继续更新或重新初始化客户端缓存状态内容（即清除/刷新内容）时，可能需要进一步的AR协议交换。为了稳定性，并允许网络拓扑变化和客户端故障，缓存内容通常为“软状态”；也就是说，它们根据时间老化，旧条目将被删除。
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves finding other information than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS).
在某些情况下（例如，ATM、X.25、MPEG-2等），AR涉及查找MAC地址以外的其他信息。这包括识别L2传输所需的其他参数，例如信道ID（X.25中的VCs、ATM中的VCI或MPEG-2 TS中的PID）。
Address resolution has different purposes for unicast and multicast. Multicast address resolution is not required for many L2 networks, but is required where MPEG-2 transmission networks carry IP multicast packets using more than one TS Logical Channel.
地址解析对于单播和多播有不同的用途。许多L2网络不需要多播地址解析，但当MPEG-2传输网络使用多个TS逻辑信道承载IP多播数据包时，需要多播地址解析。
There are three elements to the L2 information required to perform AR before an IP packet is sent over an MPEG-2 TS. These are:
在通过MPEG-2 TS发送IP数据包之前，执行AR所需的L2信息有三个要素。它们是：
(i) A Receiver ID (e.g., a 6B MAC/NPA address). (ii) A PID or index to find a PID. (iii) Tuner information (e.g., Transmit Frequency of the physical layer of a satellite/broadcast link
(i) 接收器ID（例如，6B MAC/NPA地址）。（ii）查找PID的PID或索引。（iii）调谐器信息（例如，卫星/广播链路物理层的发射频率）
Elements (ii) and (iii) need to be de-referenced when the MPEG-2 Transmission Network includes (re)multiplexors that renumber the PID values of the TS Logical Channels that they process. In MPEG-2 [ISO-MPEG], this dereferencing is via indexes to the information (i.e., the Program Map Table, PMT, which is itself indexed via the Program Association Table, PAT). (Note that PIDs are not intended to be end-to-end identifiers.) However, although remultiplexing is common in broadcast TV networks (scenarios A and B), many private networks do not need to employ multiplexors that renumber PIDs (see Section 3.3).
当MPEG-2传输网络包括（重新）多路复用器时，元素（ii）和（iii）需要取消引用，这些多路复用器对它们处理的TS逻辑信道的PID值重新编号。在MPEG-2[ISO-MPEG]中，这种解引用是通过对信息的索引（即，节目映射表PMT，其本身通过节目关联表PAT进行索引）。（请注意，PID并非旨在作为端到端标识符。）然而，尽管在广播电视网络（场景A和场景B）中重新多路复用很常见，但许多专用网络不需要使用对PID重新编号的多路复用器（见第3.3节）。
The third element (iii) allows an AR client to resolve to a different MPEG TS Multiplex. This is used when there are several channels that may be used for communication (i.e., multiple outbound/inbound links). In a mesh system, this could be used to determine connectivity. This AR information is used in two ways at a Receiver:
第三元素（iii）允许AR客户端解析为不同的MPEG-TS复用。当存在多个可用于通信的信道（即多个出站/入站链路）时，使用该方法。在网格系统中，这可用于确定连接性。该AR信息在接收器处以两种方式使用：
(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set L2 filters to let traffic pass to the IP layer. This is used for unicast, and IPv4 subnet broadcast.
(i) AR将IP单播或IPv4广播地址解析为（MPEG TS多路复用、PID、MAC/NPA地址）。这允许接收器设置L2过滤器，让流量通过IP层。这用于单播和IPv4子网广播。
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the Receiver to set L2 filters enabling traffic to pass to the IP layer. A Receiver in an MPEG-2 TS Transmission Network needs to resolve the PID value and the tuning (if present) associated with a TS Logical Channel and (at least for unicast) the destination Receiver NPA address.
（ii）AR将IP多播地址解析为（MPEG TS多路复用、PID、MAC/NPA地址），并允许接收器设置L2过滤器，使流量能够传递到IP层。MPEG-2 TS传输网络中的接收器需要解析与TS逻辑信道和（至少对于单播）目标接收器NPA地址相关联的PID值和调谐（如果存在）。
A star topology MPEG-2 TS transmission network is illustrated below, with two Receivers receiving a forward broadcast channel sent by a Hub. (A mesh system has some additional cases.) The forward broadcast channel consists of a "TS Multiplex" (a single physical
星形拓扑MPEG-2 TS传输网络如下所示，其中两个接收机接收由集线器发送的前向广播信道。（网状系统有一些附加情况。）前向广播信道由“TS多路复用”（单个物理信道）组成
bearer) allowing communication with the terminals. These communicate using a set of return channels.
承载）允许与终端通信。它们使用一组返回通道进行通信。
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
图6：带有2个接收器的MPEG-2传输网络
There are three possibilities for unicast AR:
单播AR有三种可能：
(1) A system at a Receiver, A, needs to resolve an address of a system that is at the Hub;
(1) 接收器A处的系统需要解析集线器处系统的地址；
(2) A system at a Receiver, A, needs to resolve an address that is at another Receiver, B;
(2) 接收器A处的系统需要解析另一接收器B处的地址；
(3) A host at the Hub needs to resolve an address that is at a Receiver. The sender (encapsulation gateway), uses AR to provide the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, IPv4 subnet broadcast and multicast packets.
(3) 集线器上的主机需要解析接收器上的地址。发送方（封装网关）使用AR提供MPEG TS多路复用、PID、MAC/NPA地址，用于发送单播、IPv4子网广播和多播数据包。
If the Hub is an IP router, then case (1) and (2) are the same: The host at the Receiver does not know the difference. In these cases, the address to be determined is the L2 address of the device at the Hub to which the IP packet should be forwarded, which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3).
如果集线器是IP路由器，那么情况（1）和（2）是相同的：接收器处的主机不知道差异。在这些情况下，要确定的地址是IP分组应转发到的集线器处的设备的L2地址，该集线器随后在AR之后将IP分组中继回转发（广播）MPEG-2信道（情况3）。
If the Hub is an L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. The AR protocol needs to resolve the specific Receiver L2 MAC address of B, but needs to send this on an L2 channel to the Hub. This requires Receivers to be informed of the L2 address of other Receivers.
如果集线器是L2网桥，那么情况2仍然必须将IP数据包中继回出站MPEG-2通道。AR协议需要解析B的特定接收器L2 MAC地址，但需要通过L2通道将其发送到集线器。这要求接收者被告知其他接收者的L2地址。
An end host connected to the Hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. This requires the AR server at the Hub to be informed of the L2 addresses of other Receivers.
连接到集线器的终端主机需要使用AR协议来解析接收器终端MAC/NPA地址。这需要将其他接收器的L2地址通知集线器上的AR服务器。
An AR protocol may transmit AR information in three distinct ways:
AR协议可以以三种不同的方式传输AR信息：
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level (e.g., within the control plane using a Table);
(i) 在MPEG-2级别传输的MPEG-2信令表（例如，在控制平面内使用表）；
(ii) An MPEG-2 signalling table transmitted at the IP level (no implementations of this are known);
（ii）在IP级别传输的MPEG-2信令表（不知道这方面的实现）；
(iii) An address resolution protocol transported over IP (as in ND for IPv6)
（iii）通过IP传输的地址解析协议（如IPv6的ND）
There are three distinct cases in which AR may be used:
可使用AR的情况有三种：
(i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital Terrestrial, Satellite TV broadcast multiplexes. Many such systems employ remultiplexors that modify the PID values associated with TS Logical Channels as they pass through the MPEG-2 transmission network (as in Scenario A of Section 3.1).
(i) 多个TS多路复用器和re多路复用器的使用，例如，数字地面、卫星电视广播多路复用器。许多这样的系统采用重多路复用器，在TS逻辑信道通过MPEG-2传输网络时修改与之相关联的PID值（如第3.1节中的场景A）。
(ii) Tuner configuration(s) that are fixed or controlled by some other process. In these systems, the PID value associated with a TS Logical Channel may be known by the Sender.
（ii）由其他过程固定或控制的调谐器配置。在这些系统中，发送方可以知道与TS逻辑信道相关联的PID值。
(iii) A service run over one TS Mux (i.e., uses only one PID, for example DOCSIS and some current DVB-RCS multicast systems). In these systems, the PID value of a TS Logical Channel may be known by the Sender.
（iii）在一个TS Mux上运行的服务（即，仅使用一个PID，例如DOCSIS和一些当前DVB-RCS多播系统）。在这些系统中，TS逻辑信道的PID值可能由发送方知道。
In current deployments of MPEG-2 networks, information about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually distributed via tables (service information, SI) sent using channels assigned a specific (well-known) set of PIDs. This was originally designed for audio/video distribution to STBs. This design requires access to the control plane by processing the SI table information (carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects the complexity of delivering and coordinating the various TS Logical Channels associated with a multimedia TV program.
在当前的MPEG-2网络部署中，关于通过TS多路复用携带的MPEG-2 TS逻辑信道集的信息通常通过使用分配给特定（已知）pid集的信道发送的表（服务信息，SI）来分发。这最初是为向机顶盒分发音频/视频而设计的。该设计要求通过处理SI表信息（以MPEG-2节格式[ISO-DSMCC]携带）来访问控制平面。该方案反映了传送和协调与多媒体电视节目相关的各种TS逻辑频道的复杂性。
One possible requirement to provide TS multiplex and PID information for IP services is to integrate additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of the realization of such a solution.
为IP服务提供TS多路复用和PID信息的一个可能需求是将附加信息集成到现有MPEG-2表中，或者定义特定于IP服务的附加表。来自ATSC[ATSC-A92]的DVB INT和A/92规范是实现这种解决方案的示例。
AR information could be carried over a TS data channel (e.g., using an IP protocol similar to the Service Announcement Protocol, SAP). Implementing this independently of the SI tables would ease implementation, by allowing it to operate on systems where IP processing is performed in a software driver. It may also allow the technique to be more easily adapted to other similar delivery networks. It also is advantageous for networks that use the MPEG-2 TS, but do not necessarily support audio/video services and therefore do not need to provide interoperability with TV equipment (e.g., links used solely for connecting IP (sub)networks).
AR信息可以通过TS数据通道传输（例如，使用类似于服务公告协议SAP的IP协议）。独立于SI表实现此功能将简化实现，因为它允许在软件驱动程序中执行IP处理的系统上运行。它还允许该技术更容易地适应于其他类似的递送网络。这对于使用MPEG-2 TS的网络也是有利的，但不一定支持音频/视频服务，因此不需要提供与电视设备的互操作性（例如，仅用于连接IP（子）网络的链路）。
A query/response protocol may be used at the IP level (similar to, or based on IPv6 Neighbor Advertisements of the ND protocol). The AR protocol may operate over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g., configured, or communicated using a SI table). In this case, the AR could be performed by the target system itself (as in ARP and ND). This has good soft-state properties, and is very tolerant to failures. To find an address, a system sends a "query" to the network, and the "target" (or its proxy) replies.
查询/响应协议可在IP级别使用（类似于ND协议的IPv6邻居公告，或基于ND协议的IPv6邻居公告）。AR协议可以使用先前约定的PID（例如，使用SI表配置或通信）在MPEG-2ts逻辑信道上操作。在这种情况下，AR可以由目标系统本身执行（如ARP和ND）。这具有良好的软状态属性，并且对故障非常宽容。为了找到地址，系统向网络发送一个“查询”，然后“目标”（或其代理）回复。
In some cases, an MPEG-2 Transmission Network may support multiple IP networks. When this is the case, it is important to recognize the context (scope) within which an address is resolved, to prevent packets from one addressed scope from leaking into other scopes.
在某些情况下，MPEG-2传输网络可以支持多个IP网络。在这种情况下，必须识别解析地址的上下文（作用域），以防止来自一个寻址作用域的数据包泄漏到其他作用域。
An example of overlapping IP address assignments is the use of private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix). These should be confined to the area to which they are addressed.
重叠IP地址分配的一个示例是使用专用单播地址（例如，在IPv4中，10/8前缀；172.16/12前缀；192.168/16前缀）。这些问题应局限于解决这些问题的领域。
There is also a requirement for multicast address scoping (Section 6.2).
还需要多播地址范围（第6.2节）。
IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise when using level 2 NPA addresses:
不得允许具有这些地址的IP数据包超出其预期范围，如果允许，可能会导致意外行为。此外，使用2级NPA地址时，可能会出现地址分配重叠：
(i) The NPA address must be unique within the TS Logical Channel. Universal IEEE MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique, the same NPA address may be re-used by Receivers in different addressed areas.
(i) NPA地址在TS逻辑通道中必须是唯一的。以太网LAN中使用的通用IEEE MAC地址是全局唯一的。如果NPA地址不是全局唯一的，则相同的NPA地址可由不同寻址区域中的接收器重复使用。
(ii) The NPA broadcast address (all 1s MAC address). Traffic with this address should be confined to one addressed area.
（ii）NPA广播地址（所有1s MAC地址）。使用此地址的交通应限制在一个地址区域内。
Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems connected via the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. Reception of the additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. However, it does introduce a potential Denial of Service (DoS) opportunity.
接收目的地为另一寻址区域的单播分组可导致经由网络连接的系统接收分组的速率增加。IP端主机通常根据分配的IP地址过滤接收到的单播IP数据包。额外网络流量的接收可能会增加处理负载，但不应导致意外的协议行为。但是，它确实带来了潜在的拒绝服务（DoS）机会。
When the Receiver acts as an IP router, the receipt of such an IP packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer.
当接收器充当IP路由器时，接收这样的IP分组可能导致意外的协议行为。这还提供了一个安全漏洞，因为任意数据包可能会传递到IP层。
In many AR designs, authentication has been overlooked because of the wired nature of most existing IP networks, which makes it easy to control hosts that are physically connected [RFC3819]. With wireless connections, this is changing: unauthorized hosts actually can claim L2 resources. The address resolution client (i.e., Receiver) may also need to verify the integrity and authenticity of the AR information that it receives. There are trust relationships both ways: clients need to know they have a valid server and that the resolution is valid. Servers should perform authorisation before they allow an L2 address to be used.
在许多AR设计中，由于大多数现有IP网络的有线性质，身份验证被忽略，这使得控制物理连接的主机变得容易[RFC3819]。通过无线连接，情况正在发生变化：未经授权的主机实际上可以申请L2资源。地址解析客户端（即，接收器）可能还需要验证其接收的AR信息的完整性和真实性。信任关系有两种方式：客户机需要知道他们有一个有效的服务器，并且解析是有效的。服务器应在允许使用L2地址之前执行授权。
The MPEG-2 Transmission Network may also require access control to prevent unauthorized use of the TS Multiplex; however, this is an orthogonal issue to address resolution.
MPEG-2传输网络还可能需要访问控制，以防止未经授权使用TS多路复用；然而，这是解决解决解决方案的一个正交问题。
The requirement for AR over MPEG-2 networks include:
MPEG-2网络上AR的要求包括：
(i) Use of a table-based approach to promote AR scaling. This requires definition of the frequency of update and volume of AR traffic generated.
(i) 使用基于表格的方法促进AR缩放。这需要定义更新频率和生成的AR通信量。
(ii) Mechanisms to install AR information at the server (unsolicited registration).
（ii）在服务器上安装AR信息的机制（未经请求的注册）。
(iii) Mechanisms to verify AR information held at the server (solicited responses). Appropriate timer values need to be defined.
（iii）验证服务器上持有的AR信息的机制（请求的响应）。需要定义适当的计时器值。
(iv) An ability to purge client AR information (after IP network renumbering, etc.).
（iv）清除客户端AR信息的能力（在IP网络重新编号等之后）。
(v) Support of IP subnetwork scoping.
(v) 支持IP子网范围界定。
(vi) Appropriate security associations to authenticate the sender.
（vi）验证发送方身份的适当安全关联。
This section addresses specific issues concerning IPv4 and IPv6 multicast [RFC1112] over MPEG-2 Transmission Networks. The primary goal of multicast support will be efficient filtering of IP multicast packets by the Receiver, and the mapping of IPv4 and IPv6 multicast addresses [RFC3171] to the associated PID value and TS Multiplex.
本节讨论有关MPEG-2传输网络上IPv4和IPv6多播[RFC1112]的具体问题。多播支持的主要目标是由接收器有效过滤IP多播数据包，并将IPv4和IPv6多播地址[RFC3171]映射到相关的PID值和TS多路复用。
The design should permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets. For example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve drivers and operating systems from discarding unwanted multicast traffic [RFC3819].
该设计应允许大量的活动多播组，并应在过滤和转发IP多播数据包时最小化接收器处的处理负载。例如，易于在硬件中实现的方案将是有益的，因为这些方案可以使驱动程序和操作系统免于丢弃不需要的多播通信[RFC3819]。
Multicast mechanisms are used at more than one protocol level. The upstream router feeding the MPEG-2 Encapsulator may forward multicast traffic on the MPEG-2 TS Multiplex using a static or dynamic set of groups. When static forwarding is used, the set of IP multicast groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either an IP group management protocol (IGMP [RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast routing protocol to establish tables that it uses to dynamically enable local forwarding of received groups. In a dynamic case, this
多播机制用于多个协议级别。馈送MPEG-2封装器的上游路由器可以使用一组静态或动态组在MPEG-2ts多路复用上转发多播业务。当使用静态转发时，还可以使用SNMP、Telnet等配置或设置IP多播组集。接收器通常使用IP组管理协议（IPv4为IGMP[RFC3376]，IPv6为MLD[RFC2710][RFC3810]）或多播路由协议，以建立表，用于动态启用接收组的本地转发。在动态情况下，这个
group membership information is fed back to the sender to enable it to start sending new groups and (if required) to update the tables that it produces for multicast AR.
组成员信息反馈给发送方，使其能够开始发送新组，并（如果需要）更新为多播AR生成的表。
Appropriate procedures need to identify the correct action when the same multicast group is available on more than one TS Logical Channel. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. The correct behaviour for SSM [RFC3569] addresses must also be considered. It may also arise when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes), and in this case a Receiver may potentially receive more than one copy of the same packet. At the IP level, the host/router may be unaware of this duplication.
当同一多播组在多个TS逻辑信道上可用时，适当的过程需要确定正确的操作。当不同的终端主机充当发送方以提供具有相同IP组目标地址的IP数据包时，可能会出现这种情况。还必须考虑SSM[RFC3569]地址的正确行为。当发送方在多个TS逻辑信道（或甚至不同的TS多路复用）上复制相同IP组时，也可能出现这种情况，并且在这种情况下，接收方可能接收相同分组的多个副本。在IP级别，主机/路由器可能不知道这种重复。
The functions required for multicast AR may be summarized as:
多播AR所需的功能可概括为：
(i) The Sender needs to know the L2 mapping of a multicast group. (ii) The Receiver needs to know the L2 mapping of a multicast group.
(i) 发送方需要知道多播组的L2映射。（ii）接收器需要知道多播组的L2映射。
In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to an L2 MAC address, and the Receiver uses the same mapping to determine the L2 address to set an L2 hardware/software filter entry.
在互联网中，多播AR通常是一种映射功能，而不是使用协议的一对一关联。在以太网中，发送方将IP地址映射到L2 MAC地址，接收方使用相同的映射来确定L2地址以设置L2硬件/软件筛选器条目。
A typical sequence of actions for the dynamic case is:
动态情况下的典型动作顺序为：
L3) Populate the IP L3 membership tables at the Receiver.
L3）在接收器处填充IP L3成员资格表。
L3) Receivers send/forward IP L3 membership tables to the Hub
L3）接收器向集线器发送/转发IP L3成员资格表
L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
L3）IP L3组的集线器/上游路由器上的动态/静态转发
L2) Populate the IP AR tables at the encapsulator gateway (i.e., Map IP L3 mcast groups to L2 PIDs)
L2）在封装器网关处填充IP AR表（即，将IP L3 mcast组映射到L2 PID）
L2) Distribute the AR information to Receivers
L2）将AR信息分发给接收机
L2) Set Receiver L2 multicast filters for IP groups in the membership table.
L2）在成员资格表中为IP组设置接收器L2多播筛选器。
To be flexible, AR must associate a TS Logical Channel (PID) not only with a group address, but possibly also a QoS class and other appropriate MPEG-2 TS attributes. Explicit per group AR to individual L2 addresses is to be avoided.
为了灵活，AR必须将TS逻辑信道（PID）不仅与组地址相关联，还可能与QoS类和其他适当的MPEG-2 TS属性相关联。应避免对单个L2地址显式分组AR。
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
图7：接收机处理架构
As in unicast, it is important to recognize the context (scope) within which a multicast IP address is resolved, to prevent packets from one addressed scope leaking into other scopes.
与单播一样，重要的是要识别解析多播IP地址的上下文（作用域），以防止来自一个寻址作用域的数据包泄漏到其他作用域。
Examples of overlapping IP multicast address assignments include:
重叠IP多播地址分配的示例包括：
(i) Local scope multicast addresses. These are only valid within the local area (examples for IPv4 include: 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses [RFC2375].
(i) 本地作用域多播地址。这些仅在本地区域内有效（IPv4的示例包括：224.0.0/24；224.0.1/24）。某些IPv6多播地址[RFC2375]也存在类似情况。
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid with an addressed area (e.g. the 239/8 [RFC2365]).
（ii）作用域多播地址[RFC2365][RFC 2375]。这些地址的转发由与地址关联的作用域控制。地址仅对寻址区域有效（例如239/8[RFC2365]）。
(iii) Other non-IP protocols may also view sets of MAC multicast addresses as link-local, and may produce unexpected results if distributed across several private networks.
（iii）其他非IP协议也可以将MAC多播地址集视为本地链路，并且如果分布在多个专用网络上，则可能产生意外的结果。
IP packets with these addresses must not be allowed to travel outside their intended scope (see Section 5.3). Performing multicast AR at the IP level can enable providers to offer independently scoped addresses and would need to use multiple Multicast AR servers, one per multicast domain.
具有这些地址的IP数据包不得超出其预期范围（见第5.3节）。在IP级别执行多播AR可以使提供商提供独立作用域的地址，并且需要使用多个多播AR服务器，每个多播域一个。
The requirements for supporting multicast include, but are not restricted to:
支持多播的要求包括但不限于：
(i) Encapsulating multicast packets for transmission using an MPEG-2 TS.
(i) 使用MPEG-2 TS封装用于传输的多播数据包。
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex.
（ii）将IP多播组映射到底层MPEG-2 TS逻辑信道（PID）和MPEG-2 TS多路复用。
(iii) Providing AR information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
（iii）提供AR信息以允许接收器在MPEG-2ts多路复用内定位IP多播流。
(iv) Error Reporting.
（iv）错误报告。
This document describes the architecture for a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS). It also describes existing approaches. The focus is on IP networking, the mechanisms that are used, and their applicability to supporting IP unicast and multicast services.
本文档描述了一组协议的体系结构，这些协议在基于MPEG-2传输流（TS）的网络上对IP网络服务执行高效灵活的支持。它还描述了现有的方法。重点是IP网络、使用的机制以及它们对支持IP单播和多播服务的适用性。
The requirements for a new encapsulation of IPv4 and IPv6 packets is described, outlining the limitations of current methods and the need for a streamlined IP-centric approach.
描述了IPv4和IPv6数据包的新封装要求，概述了当前方法的局限性以及简化以IP为中心的方法的必要性。
The architecture also describes MPEG-2 Address Resolution (AR) procedures to allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network. These support IPv4 and IPv6 services in both the unicast and multicast modes. Resolution protocols will support IP packet transmission using both the Multiprotocol Encapsulation (MPE), which is currently widely deployed, and also any IETF-defined encapsulation (e.g., ULE [IPDVB-ULE]).
该体系结构还描述了MPEG-2地址解析（AR）过程，以允许使用MPEG-2传输链路/网络动态配置发送方和接收方。它们支持单播和多播模式下的IPv4和IPv6服务。解析协议将支持使用当前广泛部署的多协议封装（MPE）和任何IETF定义的封装（如ULE[IPDVB-ULE]）的IP数据包传输。
When the MPEG-2 transmission network is not using a wireline network, the normal security issues relating to the use of wireless links for transport of Internet traffic should be considered [RFC3819].
当MPEG-2传输网络不使用有线网络时，应考虑与使用无线链路传输互联网流量有关的正常安全问题[RFC3819]。
End-to-end security (including confidentiality, authentication, integrity and access control) is closely associated with the end user assets that are protected. This close association cannot be ensured when providing security mechanisms only within a subnetwork (e.g., an MPEG-2 Transmission Network). Several security mechanisms that can be used end-to-end have already been deployed in the general Internet and are enjoying increasing use. Important examples include:
端到端安全性（包括机密性、身份验证、完整性和访问控制）与受保护的最终用户资产密切相关。当仅在子网（例如，MPEG-2传输网络）内提供安全机制时，无法确保这种紧密关联。一些可以端到端使用的安全机制已经部署在通用Internet中，并且正在得到越来越多的使用。重要的例子包括：
- Transport Layer Security (TLS), which is primarily used to protect web commerce;
- 传输层安全（TLS），主要用于保护web商务；
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and authenticate email and software distributions;
- 相当好的隐私（PGP）和S/MIME，主要用于保护和验证电子邮件和软件发行版；
- Secure Shell (SSH), used to secure remote access and file transfer;
- Secure Shell（SSH），用于保护远程访问和文件传输的安全；
- IPsec, a general purpose encryption and authentication mechanism above IP that can be used by any IP application.
- IPsec，一种IP之上的通用加密和身份验证机制，可供任何IP应用程序使用。
However, subnetwork security is also important [RFC3819] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and/or shared media Internet access) often have control over, at most, one endpoint - usually a client - and therefore cannot enforce the use of end-to-end mechanisms.
然而，子网安全也很重要[RFC3819]，并且应该受到鼓励，其原则是它比默认情况要好，默认情况往往根本不安全。特别脆弱的子网（如无线电/广播网络和/或共享媒体互联网接入）的用户通常最多可以控制一个端点（通常是客户端），因此无法强制使用端到端机制。
A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties (by IP or MAC address) and determining their communication patterns, even when their actual contents are protected by strong end-to-end security mechanisms. (This is important for networks such as broadcast/radio, where eavesdropping is easy.)
子网安全的一个相关角色是保护用户免受流量分析的影响，即识别通信方（通过IP或MAC地址）并确定其通信模式，即使其实际内容受到强大的端到端安全机制的保护。（这对于广播/无线电等容易窃听的网络非常重要。）
Encryption performed at the Transport Stream (encrypting the payload of all TS-Packets with the same PID) encrypts/scrambles all parts of the SNDU, including the layer 2 MAC/NPA address. Encryption at the section level in MPE may also optionally encrypt the layer 2 MAC/NPA address in addition to the PDU data [ETSI-DAT]. In both cases, encryption of the MAC/NPA address requires a Receiver to decrypt all encrypted data, before it can then filter the PDUs with the set of
在传输流上执行的加密（使用相同的PID加密所有TS数据包的有效负载）对SNDU的所有部分进行加密/加扰，包括第2层MAC/NPA地址。除了PDU数据[ETSI-DAT]之外，MPE中的段级加密还可以选择性地加密第2层MAC/NPA地址。在这两种情况下，MAC/NPA地址的加密都需要接收方对所有加密数据进行解密，然后才能使用一组数据对PDU进行过滤
MAC/NPA addresses that it wishes to receive. This method also has the drawback that all Receivers must share a common encryption key. Encryption of the MPE MAC address is therefore not permitted in some systems (e.g., [ETSI-DVBRCS]).
它希望接收的MAC/NPA地址。此方法还有一个缺点，即所有接收器必须共享一个公共加密密钥。因此，某些系统（例如[ETSI-DVBRCS]）中不允许对MPE MAC地址进行加密。
Where it is possible for an attacker to inject traffic into the subnetwork control plane, subnetwork security can additionally protect the subnetwork assets. This threat must specifically be considered for the protocols used for subnetwork control functions (e.g., address resolution, management, configuration). Possible threats include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks [RFC3819].
如果攻击者有可能将流量注入子网控制平面，子网安全性可以额外保护子网资产。对于用于子网控制功能（例如，地址解析、管理、配置）的协议，必须特别考虑这种威胁。可能的威胁包括窃取服务和拒绝服务；共享媒体子网往往特别容易受到此类攻击[RFC3819]。
Appropriate security functions must therefore be provided for IPDVB control protocols [RFC3819], particularly when the control functions are provided above the IP-layer using IP-based protocols. Internet level security mechanisms (e.g., IPsec) can mitigate such threats.
因此，必须为IPDVB控制协议[RFC3819]提供适当的安全功能，特别是在使用基于IP的协议在IP层上提供控制功能时。Internet级别的安全机制（如IPsec）可以缓解此类威胁。
In general, End-to-End security is recommended for users of any communication path, especially when it includes a wireless/radio or broadcast link, where a range of security techniques already exist. Specification of security mechanisms at the application layer, or within the MPEG-2 transmission network, are the concerns of organisations beyond the IETF. The complexity of any such security mechanisms should be considered carefully so that it will not unduly impact IP operations.
通常，建议任何通信路径的用户使用端到端安全性，特别是当其包括无线/无线电或广播链路时，其中已经存在一系列安全技术。应用层或MPEG-2传输网络内的安全机制规范是IETF以外组织关注的问题。应仔细考虑任何此类安全机制的复杂性，以免对IP操作造成不适当的影响。
Link level encryption of IP traffic is commonly used in broadcast/radio links to supplement End-to-End security (e.g., provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption and key exchange methods vary significantly, depending on the intended application. For example, DVB-S/DVB-RCS operated by Access Network Operators may wish to provide their customers (Internet Service Providers, ISP) with security services. Common security services are: terminal authentication and data confidentiality (for unicast and multicast) between an encapsulation gateway and Receivers. A common objective is to provide the same level of privacy as terrestrial links. An ISP may also wish to provide end-to-end security services to the end-users (based on well-known mechanisms such as IPsec).
IP通信的链路级加密通常用于广播/无线电链路，以补充端到端安全性（例如，由TLS、SSH、Open PGP、S/MIME、IPsec提供）。根据预期的应用，加密和密钥交换方法有很大不同。例如，接入网运营商运营的DVB-S/DVB-RCS可能希望为其客户（互联网服务提供商、ISP）提供安全服务。常见的安全服务包括：封装网关和接收器之间的终端身份验证和数据机密性（对于单播和多播）。一个共同的目标是提供与地面链接相同级别的隐私。ISP还可能希望向最终用户提供端到端安全服务（基于众所周知的机制，如IPsec）。
Therefore, it is important to understand that both security solutions (Access Network Operators to ISP and ISP to end-users) may coexist.
因此，必须了解两种安全解决方案（ISP接入网络运营商和最终用户ISP接入网络运营商）可能共存。
MPE supports optional link encryption [ETSI-DAT]. A pair of bits within the MPE protocol header indicate whether encryption (scrambling) is used. For encrypted PDUs, the header bits indicate which of a pair of previously selected encryption keys is to be used.
MPE支持可选链路加密[ETSI-DAT]。MPE协议头中的一对位指示是否使用加密（加扰）。对于加密的PDU，标头位指示将使用一对先前选择的加密密钥中的哪一个。
It is recommended that any new encapsulation defined by the IETF allows Transport Stream encryption and also supports optional link level encryption/authentication of the SNDU payload. In ULE [IPDVB-ULE], this may be provided in a flexible way using Extension Headers. This requires definition of a mandatory header extension, but has the advantage that it decouples specification of the security functions from the encapsulation functions. This method also supports encryption of the NPA/MAC addresses.
建议IETF定义的任何新封装都允许传输流加密，并且还支持SNDU有效负载的可选链路级加密/认证。在ULE[IPDVB-ULE]中，这可以使用扩展头以灵活的方式提供。这需要定义一个强制的头扩展，但其优点是它将安全函数的规范与封装函数分离。此方法还支持对NPA/MAC地址进行加密。
A set of protocols that meet these requirements will require the IANA to make assignments. This document in itself, however, does not require any IANA involvement.
满足这些要求的一组协议将要求IANA进行分配。然而，本文件本身不需要IANA的参与。
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. We also wish to acknowledge the input provided by the members of the IETF ipdvb WG.
作者要感谢伊莎贝尔·阿莫努、托尔斯滕·杰克尔、皮埃尔·罗耶、罗玛·朱哈·佩卡和罗德·沃尔什的详细投入。我们还希望感谢IETF ipdvb工作组成员提供的意见。
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Standards Organisation (ISO).
[ISO-MPEG]ISO/IEC DIS 13818-1:2000，“信息技术；运动图像和相关音频信息系统的通用编码”，国际标准组织（ISO）。
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI).
[ETSI-DAT]EN 301 192，“数字视频广播（DVB）；数据广播用DVB规范”，欧洲电信标准协会（ETSI）。
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC]A/53C，“ATSC数字电视标准”，高级电视系统委员会（ATSC），文件。A/53C，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-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 2002.
[ATSC-A92]A/92，“通过ATSC数据广播提供IP多播会话”，高级电视系统委员会（ATSC），文件。A/922002。
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003.
[ATSC-G]A/54A，“ATSC数字电视标准使用指南”，高级电视系统委员会（ATSC），文件。A/54A，2003年。
[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-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年。
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
[CLC99]Clausen，H.，Linder，H.，和Collini Nocker，B.，“广播卫星上的互联网”，IEEE Common。《1999年杂志》，第146-151页。
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia Services and Architectures; Functional Architecture for IP Interworking with BSM networks", European Telecommunications Standards Institute (ETSI).
[ETSI-BSM]TS 102 292，“卫星地面站和系统（SES）；宽带卫星多媒体服务和体系结构；与BSM网络进行IP互通的功能体系结构”，欧洲电信标准协会（ETSI）。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBC]EN 300 800，“数字视频广播（DVB）；有线电视分配系统（CATV）的DVB交互频道”，欧洲电信标准协会（ETSI）。
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBRCS]EN 301 790，“数字视频广播（DVB）；卫星分配系统的交互通道”，欧洲电信标准协会（ETSI）。
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS]EN 301 421，“数字视频广播（DVB）；11/12 GHz下DBS卫星系统的调制和编码”，欧洲电信标准协会（ETSI）。
[ETSI-DVBS2] EN 302 207, "Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services,News Gathering and Other Broadband Satellite Applications", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS2]EN 302 207，“用于广播、交互服务、新闻采集和其他宽带卫星应用的第二代帧结构、信道编码和调制系统”，欧洲电信标准协会（ETSI）。
[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).
[ETSI-DVBT]EN 300 744，“数字视频广播（DVB）；数字地面电视（DVB-T）的帧结构、信道编码和调制”，欧洲电信标准协会（ETSI）。
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ETSI-IPDC]“IP数据广播规范”，DVB临时规范CNMS 1026 v1.0.0，（正在进行的工作），2004年4月。
[ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification", v1.2.1, European Telecommunications Standards Institute (ETSI), June 2002.
[ETSI-MHP]TS 101 812，“数字视频广播（DVB）；多媒体家庭平台（MHP）规范”，v1.2.1，欧洲电信标准协会（ETSI），2002年6月。
[ETSI-RC] ETS 300 802, "Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services", European Telecommunications Standards Institute (ETSI).
[ETSI-RC]ETS 300 802，“数字视频广播（DVB）；DVB交互服务的网络独立协议”，欧洲电信标准协会（ETSI）。
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", European Telecommunications Standards Institute (ETSI).
[ETSI-SI]EN 300 468，“数字视频广播（DVB）；DVB系统中服务信息（SI）规范”，欧洲电信标准协会（ETSI）。
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", Work in Progress, June 2005.
[IPDVB-ULE]Fairhurst，G.和B.Collini Nocker，“通过MPEG-2传输流传输IP数据报的单向轻量封装（ULE）”，正在进行的工作，2005年6月。
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 networks", Work in Progress, 2005.
[IPDVB-AR]Fairhurst，G.和M-J.Montpetit，“MPEG-2网络上IP数据报的地址解析”，正在进行的工作，2005年。
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic coding of moving pictures and associated audio information; Part 3: Audio", International Standards Organisation (ISO).
[ISO-AUD]ISO/IEC 13818-3:1995，“信息技术；运动图像和相关音频信息的通用编码；第3部分：音频”，国际标准组织（ISO）。
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic coding of moving pictures and associated audio information; Part 6: Extensions for DSM-CC", International Standards Organisation (ISO).
[ISO-DSMCC]ISO/IEC IS 13818-6，“信息技术；运动图像和相关音频信息的通用编码；第6部分：DSM-CC的扩展”，国际标准组织（ISO）。
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology; Generic coding of moving pictures and associated audio information; Video", International Standards Organisation (ISO).
[ISO-VID]ISO/IEC DIS 13818-2:1998，“信息技术；运动图像和相关音频信息的通用编码；视频”，国际标准组织（ISO）。
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer Specification Type AAL5", International Standards Organisation (ISO), 1996.
[ITU-AAL5]ITU-T I.363.5，“AAL5型B-ISDN ATM适配层规范”，国际标准组织（ISO），1996年。
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[LLC] ISO/IEC 8802.2, "Information technology;
Telecommunications and information exchange between
systems; Local and metropolitan area networks;
Specific requirements; Part 2: Logical Link Control",
International Standards Organisation (ISO), 1998.
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, June 2004.
[MMUSIC-IMG]野村，Y.，沃尔什，R.，骆马，J-P.，Ott，J.，和H.Schulzrinne，“互联网媒体指南的要求”，正在进行的工作，2004年6月。
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP 2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs, April 2002.
[开放式电缆]“开放式电缆应用平台规范；OCAP 2.0简介”，OC-SP-OCAP2.0-I01-020419，电缆实验室，2002年4月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]Meyer，D.，“管理范围的IP多播”，BCP 23，RFC 2365，1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375]Hinden，R.和S.Deering，“IPv6多播地址分配”，RFC 23751998年7月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[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月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，L-E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.，和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP，ESP，和未压缩”，RFC 3095，2001年7月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171]Albanna，Z.，Almeroth，K.，Meyer，D.，和M.Schipper，“IPv4多播地址分配的IANA指南”，BCP 51，RFC 3171，2001年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004 .
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
Appendix A: MPEG-2 Encapsulation Mechanisms
附录A:MPEG-2封装机制
Transmitting packet data over an MPEG-2 transmission network requires that individual PDUs (e.g., IPv4, IPv6 packets, or bridged Ethernet Frames) are encapsulated using a convergence protocol. The following encapsulations are currently standardized for MPEG-2 transmission networks:
通过MPEG-2传输网络传输分组数据需要使用汇聚协议封装单个PDU（例如IPv4、IPv6分组或桥接以太网帧）。以下封装目前已为MPEG-2传输网络标准化：
(i) Multi-Protocol Encapsulation (MPE).
(i) 多协议封装（MPE）。
The MPE specification of DVB [ETSI-DAT] uses private Sections for the transport of IP packets and uses encapsulation that is similar to the IEEE LAN/MAN standards [LLC]. Data packets are encapsulated in datagram sections that are compliant with the DSMCC section format for private data. Some Receivers may exploit section processing hardware to perform a first-level filtering of the packets that arrive at the Receiver.
DVB[ETSI-DAT]的MPE规范使用专用部分传输IP数据包，并使用类似于IEEE LAN/MAN标准[LLC]的封装。数据包封装在符合专用数据DSMCC节格式的数据报节中。一些接收机可以利用部分处理硬件来对到达接收机的分组执行第一级过滤。
This encapsulation makes use of a MAC-level Network Point of Attachment address. The address format conforms to the ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC address field contains the MAC address of the destination; it is distributed over six 8-bit fields, labelled MAC_address_1 to MAC_address_6. The MAC_address_1 field contains the most significant byte of the MAC address, while MAC_address_6 contains the least significant byte. How many of these bytes are significant is optional and defined by the value of the broadcast descriptor table [ETSI-DAT] sent separately over another MPEG-2 TS within the TS multiplex.
这种封装利用MAC级网络连接点地址。地址格式符合LAN/MAN[LLC]的ISO/IEEE标准。48位MAC地址字段包含目的地的MAC地址；它分布在六个8位字段上，标记为MAC_address_1到MAC_address_6。MAC_地址_1字段包含MAC地址的最高有效字节，而MAC_地址_6包含最低有效字节。这些字节中有多少是有效的是可选的，并由通过TS多路复用内的另一个MPEG-2 TS单独发送的广播描述符表[ETSI-DAT]的值定义。
MPE is currently a widely deployed scheme. Due to Investments in existing systems, usage is likely to continue in current and future MPEG-2 Transmission Networks. ATSC provides a scheme similar to MPE [ATSC-DAT] with some small differences.
MPE目前是一种广泛部署的方案。由于对现有系统的投资，在当前和未来的MPEG-2传输网络中可能会继续使用。ATSC提供了一种类似于MPE[ATSC-DAT]的方案，但有一些小的区别。
(ii) Data Piping.
（ii）数据管道。
The Data Piping profile [ETSI-DAT] is a minimum overhead, simple and flexible profile that makes no assumptions concerning the format of the data being sent. In this profile, the Receiver is intended to provide PID filtering, packet reassembly according to [ETSI-SI], error detection, and optional Conditional Access (link encryption).
数据管道配置文件[ETSI-DAT]是一个最小开销、简单且灵活的配置文件，它对发送的数据格式不作任何假设。在该配置文件中，接收器旨在提供PID过滤、根据[ETSI-SI]重新组装数据包、错误检测和可选条件接收（链路加密）。
The specification allows the user data stream to be unstructured or organized into packets. The specific structure is transparent to the Receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.
该规范允许将用户数据流非结构化或组织成数据包。特定结构对接收器是透明的。它可以符合任何协议，例如IP、以太网、NFS、FDDI、MPEG-2 PES等。
(iii) Data Streaming.
（iii）数据流。
The data broadcast specification profile [ETSI-DAT] for PES tunnels (Data Streaming) supports unicast and multicast data services that require a stream-oriented delivery of data packets. This encapsulation maps an IP packet into a single PES Packet payload.
PES隧道（数据流）的数据广播规范配置文件[ETSI-DAT]支持单播和多播数据服务，这些服务需要面向流的数据包交付。这种封装将IP数据包映射为单个PES数据包有效负载。
Two different types of PES headers can be selected via the stream_id values [ISO-MPEG]. The private_stream_2 value permits the use of the short PES header with limited overhead, while the private_stream_1 value makes available the scrambling control and the timing and clock reference features of the PES layer.
可以通过流id值[ISO-MPEG]选择两种不同类型的PES头。private_stream_2值允许使用开销有限的短PES报头，而private_stream_1值提供了PES层的加扰控制以及定时和时钟参考特性。
Authors' Addresses
作者地址
Marie J. Montpetit Motorola Connected Home Solutions 45 Hayden Avenue 4th Floor Lexington MA 02130 USA
美国马萨诸塞州莱克星顿市海登大道45号4楼玛丽蒙佩蒂摩托罗拉互联家庭解决方案公司02130
EMail: mmontpetit@motorola.com
EMail: mmontpetit@motorola.com
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
Horst D. Clausen TIC Systems Lawrence, Kansas
堪萨斯州劳伦斯霍斯特D.克劳森TIC系统公司
EMail: h.d.clausen@ieee.org
EMail: h.d.clausen@ieee.org
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.network-research.org
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.network-research.org
Hilmar Linder Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
萨尔茨堡科学计算大学HiMAar LIDER系JAJOB HARIGER STR 2 5020萨尔茨堡奥地利
EMail: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.org
EMail: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.org
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编辑功能的资金目前由互联网协会提供。