Network Working Group G. Fairhurst
Request for Comments: 4947 University of Aberdeen
Category: Informational M.-J. Montpetit
Motorola Connected Home Solutions
July 2007
Network Working Group G. Fairhurst
Request for Comments: 4947 University of Aberdeen
Category: Informational M.-J. Montpetit
Motorola Connected Home Solutions
July 2007
Address Resolution Mechanisms for 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 IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.
本文档描述了将IPv4/IPv6地址与MPEG-2传输流（TS）绑定/关联的过程。此过程称为地址解析（AR）或邻居发现（ND）。这种地址解析补充了用于公布IP会话的更高层资源发现工具。
In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.
在MPEG-2网络中，IP地址必须与数据包ID（PID）值和特定的传输多路复用相关联。本文件回顾了适用于一系列技术（如DVB（数字视频广播）、ATSC（高级电视系统委员会）、DOCSIS（有线数据服务接口规范）和变体）的当前方法。它还描述了与众所周知的地址管理协议（包括DHCP、ARP和ND协议）的交互。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Bridging and Routing .......................................4
2. Conventions Used in This Document ...............................7
3. Address Resolution Requirements ................................10
3.1. Unicast Support ...........................................12
3.2. Multicast Support .........................................12
4. MPEG-2 Address Resolution ......................................14
4.1. Static Configuration ......................................15
4.1.1. MPEG-2 Cable Networks ..............................15
4.2. MPEG-2 Table-Based Address Resolution .....................16
4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17
4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18
4.2.3. Application Information Table (AIT) and Its Usage ..18
4.2.4. Address Resolution in ATSC .........................19
4.2.5. Comparison of SI/PSI Table Approaches ..............19
4.3. IP-Based Address Resolution for TS Logical Channels .......19
5. Mapping IP Addresses to MAC/NPA Addresses ......................21
5.1. Unidirectional Links Supporting Unidirectional
Connectivity ..............................................22
5.2. Unidirectional Links with Bidirectional Connectivity ......23
5.3. Bidirectional Links .......................................25
5.4. AR Server .................................................26
5.5. DHCP Tuning ...............................................27
5.6. IP Multicast AR ...........................................27
5.6.1. Multicast/Broadcast Addressing for UDLR ............28
6. Link Layer Support .............................................29
6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30
6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31
6.3. MPE without LLC/SNAP Encapsulation ........................31
6.4. MPE with LLC/SNAP Encapsulation ...........................31
6.5. ULE with Bridging Header Extension (D=1) ..................32
6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32
6.7. MPE with LLC/SNAP & Bridging ..............................33
7. Conclusions ....................................................33
8. Security Considerations ........................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................36
1. Introduction ....................................................3
1.1. Bridging and Routing .......................................4
2. Conventions Used in This Document ...............................7
3. Address Resolution Requirements ................................10
3.1. Unicast Support ...........................................12
3.2. Multicast Support .........................................12
4. MPEG-2 Address Resolution ......................................14
4.1. Static Configuration ......................................15
4.1.1. MPEG-2 Cable Networks ..............................15
4.2. MPEG-2 Table-Based Address Resolution .....................16
4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17
4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18
4.2.3. Application Information Table (AIT) and Its Usage ..18
4.2.4. Address Resolution in ATSC .........................19
4.2.5. Comparison of SI/PSI Table Approaches ..............19
4.3. IP-Based Address Resolution for TS Logical Channels .......19
5. Mapping IP Addresses to MAC/NPA Addresses ......................21
5.1. Unidirectional Links Supporting Unidirectional
Connectivity ..............................................22
5.2. Unidirectional Links with Bidirectional Connectivity ......23
5.3. Bidirectional Links .......................................25
5.4. AR Server .................................................26
5.5. DHCP Tuning ...............................................27
5.6. IP Multicast AR ...........................................27
5.6.1. Multicast/Broadcast Addressing for UDLR ............28
6. Link Layer Support .............................................29
6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30
6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31
6.3. MPE without LLC/SNAP Encapsulation ........................31
6.4. MPE with LLC/SNAP Encapsulation ...........................31
6.5. ULE with Bridging Header Extension (D=1) ..................32
6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32
6.7. MPE with LLC/SNAP & Bridging ..............................33
7. Conclusions ....................................................33
8. Security Considerations ........................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................36
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbor Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. The document reviews current methods appropriate to a range of technologies (DVB, ATSC, DOCSIS, and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.
本文档描述了将IPv4/IPv6地址与MPEG-2传输流（TS）绑定/关联的过程。此过程称为地址解析（AR）或邻居发现（ND）。这种地址解析补充了用于公布IP会话的更高层资源发现工具。本文件回顾了适用于一系列技术（DVB、ATSC、DOCSIS和变体）的当前方法。它还描述了与众所周知的地址管理协议（包括DHCP、ARP和ND协议）的交互。
The MPEG-2 TS provides a time-division multiplexed (TDM) stream that may contain audio, video, and data information, including encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer 2 (L2) frame, known as a TS Packet, contains a 4 byte header and a 184 byte payload. Each TS Packet is associated with a single TS Logical Channel, identified by a 13-bit Packet ID (PID) value that is carried in the MPEG-2 TS Packet header.
MPEG-2 TS提供可包含音频、视频和数据信息的时分复用（TDM）流，包括规范ISO/IEC 13818[ISO-MPEG2]中定义的封装IP数据报[RFC4259]。每个第2层（L2）帧称为TS数据包，包含一个4字节的报头和一个184字节的有效负载。每个TS分组与单个TS逻辑信道相关联，由MPEG-2ts分组报头中携带的13位分组ID（PID）值标识。
The MPEG-2 standard also defines a control plane that may be used to transmit control information to Receivers in the form of System Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific Information (PSI) Tables.
MPEG-2标准还定义了一个控制平面，该控制平面可用于以系统信息（SI）表[ETSI-SI]、[ETSI-SI1]或程序特定信息（PSI）表的形式向接收机发送控制信息。
To utilize the MPEG-2 TS as a L2 link supporting IP, a sender must associate an IP address with a particular Transmission Multiplex, and within the multiplex, identify the specific PID to be used. This document calls this mapping an AR function. In some AR schemes, the MPEG-2 TS address space is subdivided into logical contexts known as Platforms [ETSI-DAT]. Each Platform associates an IP service provider with a separate context that shares a common MPEG-2 TS (i.e., uses the same PID value).
为了将MPEG-2 TS用作支持IP的L2链路，发送方必须将IP地址与特定的传输多路复用相关联，并且在多路复用内标识要使用的特定PID。本文档将此映射称为AR函数。在一些AR方案中，MPEG-2 TS地址空间被细分为称为平台[ETSI-DAT]的逻辑上下文。每个平台将IP服务提供商与共享公共MPEG-2 TS的单独上下文相关联（即，使用相同的PID值）。
MPEG-2 Receivers may use a Network Point of Attachment (NPA) [RFC4259] to uniquely identify a L2 node within an MPEG-2 transmission network. An example of an NPA is the IEEE Medium Access Control (MAC) address. Where such addresses are used, these must also be signalled by the AR procedure. Finally, address resolution could signal the format of the data being transmitted, for example, the encapsulation, with any L2 encryption method and any compression scheme [RFC4259].
MPEG-2接收机可以使用网络连接点（NPA）[RFC4259]来唯一地标识MPEG-2传输网络内的L2节点。NPA的一个示例是IEEE介质访问控制（MAC）地址。在使用这些地址的情况下，这些地址也必须由AR程序发出信号。最后，地址解析可以用任何L2加密方法和任何压缩方案来表示正在传输的数据的格式，例如封装[RFC4259]。
The numbers of Receivers connected via a single MPEG-2 link may be much larger than found in other common LAN technologies (e.g., Ethernet). This has implications on design/configuration of the address resolution mechanisms. Current routing protocols and some multicast application protocols also do not scale to arbitrarily
通过单个MPEG-2链路连接的接收器数量可能比其他常见LAN技术（例如以太网）中的接收器数量大得多。这对地址解析机制的设计/配置有影响。目前的路由协议和一些多播应用协议也不能任意扩展
large numbers of participants. Such networks do not by themselves introduce an appreciable subnetwork round trip delay, however many practical MPEG-2 transmission networks are built using links that may introduce a significant path delay (satellite links, use of dial-up modem return, cellular return, etc.). This higher delay may need to be accommodated by address resolution protocols that use this service.
大量的参与者。此类网络本身不会引入可观的子网络往返延迟，但是许多实际的MPEG-2传输网络是使用可能引入显著路径延迟的链路（卫星链路、使用拨号调制解调器返回、蜂窝返回等）构建的。使用此服务的地址解析协议可能需要适应更高的延迟。
The following two figures illustrate the use of AR for a routed and a bridged subnetwork. Various other combinations of L2 and L3 forwarding may also be used over MPEG-2 links (including Receivers that are IP end hosts and end hosts directly connected to bridged LAN segments).
以下两幅图说明了AR在路由和桥接子网中的使用。还可以通过MPEG-2链路（包括作为IP终端主机和直接连接到桥接LAN段的终端主机的接收器）使用L2和L3转发的各种其他组合。
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|
Figure 1: A routed MPEG-2 link
图1：路由MPEG-2链路
Figure 1 shows a routed MPEG-2 link feeding three downstream routers (R2-R4). AR takes place at the Encapsulator (R1) to identify each Receiver at Layer 2 within the IP subnetwork (R2, etc.).
图1显示了一个路由MPEG-2链路，该链路馈送三个下游路由器（R2-R4）。AR发生在封装器（R1）处，以识别IP子网（R2等）内第2层的每个接收器。
When considering unicast communication from R1 to R2, several L2 addresses are involved:
考虑从R1到R2的单播通信时，涉及几个L2地址：
1a is the L2 (sending) interface address of R1 on the MPEG-2 link. 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link. 2a is the L2 (sending) interface address of R2 on the next hop link.
1a是MPEG-2链路上R1的L2（发送）接口地址。2b是MPEG-2链路上R2的L2（接收）接口地址。2a是下一跳链路上R2的L2（发送）接口地址。
AR for the MPEG-2 link allows R1 to determine the L2 address (2b) corresponding to the next hop Receiver, router R2.
MPEG-2链路的AR允许R1确定对应于下一跳接收机路由器R2的L2地址（2b）。
Figure 2 shows a bridged MPEG-2 link feeding three downstream bridges (B2-B4). AR takes place at the Encapsulator (B1) to identify each Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork allowing the Feed router (R1) to identify the downstream Routers at Layer 2 (R2, etc.). The Encapsulator associates a destination MAC/NPA address with each bridged PDU sent on an MPEG-2 link. Two methods are defined by ULE (Unidirectional Lightweight Encapsulation) [RFC4326]:
图2显示了为三个下游网桥（B2-B4）馈电的桥接MPEG-2链路。AR发生在封装器（B1）处，以识别L2（B2-B4）处的每个接收器。AR也发生在IP子网上，允许馈送路由器（R1）识别第2层（R2等）的下游路由器。封装器将目标MAC/NPA地址与在MPEG-2链路上发送的每个桥接PDU相关联。ULE（单向轻量封装）[RFC4326]定义了两种方法：
The simplest method uses the L2 address of the transmitted frame. This is the MAC address corresponding to the destination within the L2 subnetwork (the next hop router, 2b of R2). This requires each Receiver (B2-B4) to associate the receiving MPEG-2 interface with the set of MAC addresses that exist on the L2 subnetworks that it feeds. Similar considerations apply when IP-based tunnels support L2 services (including the use of UDLR (Unidirectional Links) [RFC3077]).
最简单的方法是使用传输帧的L2地址。这是与L2子网（R2的下一跳路由器2b）内的目的地相对应的MAC地址。这要求每个接收器（B2-B4）将接收MPEG-2接口与其馈送的L2子网上存在的MAC地址集相关联。当基于IP的隧道支持L2服务（包括使用UDLR（单向链路）[RFC3077]）时，类似的考虑也适用。
It is also possible for a bridging Encapsulator (B1) to encapsulate a PDU with a link-specific header that also contains the MAC/NPA address associated with a Receiver L2 interface on the MPEG-2 link (Figure 2). In this case, the destination MAC/NPA address of the encapsulated frame is set to the Receiver MAC/NPA address (y), rather than the address of the final L2 destination. At a different level, an AR binding is also required for R1 to associate the destination L2 address 2b with R2. In a subnetwork using bridging, the systems R1 and R2 will normally use standard IETF-defined AR mechanisms (e.g., IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP subnetwork.
桥接封装器（B1）也可以用链路特定报头封装PDU，该报头还包含与MPEG-2链路上的接收器L2接口相关联的MAC/NPA地址（图2）。在这种情况下，封装帧的目的地MAC/NPA地址被设置为接收机MAC/NPA地址（y），而不是最终L2目的地的地址。在不同的级别上，R1还需要AR绑定来将目标L2地址2b与R2关联。在使用桥接的子网中，系统R1和R2通常将使用标准IETF定义的AR机制（例如，IPv4地址解析协议（ARP）[RFC826]和IPv6邻居发现协议（ND）[RFC2461]）跨IP子网的边到边。
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|
Figure 2: A bridged MPEG-2 link
图2：桥接MPEG-2链路
Methods also exist to assign IP addresses to Receivers within a network (e.g., stateless autoconfiguration [RFC2461], DHCP [RFC2131], DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]). Receivers may also participate in the remote configuration of the L3 IP addresses used in connected equipment (e.g., using DHCP-Relay [RFC3046]).
还存在将IP地址分配给网络内接收器的方法（例如，无状态自动配置[RFC2461]、DHCP[RFC2131]、DHCPv6[RFC3315]和无状态DHCPv6[RFC3736]）。接收器还可以参与连接设备中使用的L3 IP地址的远程配置（例如，使用DHCP中继[RFC3046]）。
The remainder of this document describes current mechanisms and their use to associate an IP address with the corresponding TS Multiplex, PID value, the MAC/NPA address and/or Platform ID. A range of approaches is described, including Layer 2 mechanisms (using MPEG-2 SI tables), and protocols at the IP level (including ARP [RFC826] and ND [RFC2461]). Interactions and dependencies between these mechanisms and the encapsulation methods are described. The document does not propose or define a new protocol, but does provide guidance on issues that would need to be considered to supply IP-based address resolution.
本文档的其余部分描述了将IP地址与相应的TS多路复用、PID值、MAC/NPA地址和/或平台ID关联的当前机制及其使用。描述了一系列方法，包括第2层机制（使用MPEG-2 SI表）和IP级协议（包括ARP[RFC826]和ND[RFC2461]).描述了这些机制和封装方法之间的交互和依赖关系。该文件没有提出或定义新的协议，但就提供基于IP的地址解析所需考虑的问题提供了指导。
AIT: Application Information Table specified by the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. This table may carry IPv4/IPv6 to MPEG-2 TS address resolution information.
AIT：多媒体家庭平台（MHP）规范[ETSI-MHP]规定的应用信息表。此表可能包含IPv4/IPv6到MPEG-2 TS地址解析信息。
ATSC: Advanced Television Systems Committee [ATSC]. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard [ISO-MPEG2].
先进电视系统委员会（ATSC）。使用ISO MPEG-2标准[ISO-MPEG2]传输视频、音频和数据的框架和一组相关标准。
b: bit. For example, one byte consists of 8-bits.
b:一点点。例如，一个字节由8位组成。
B: Byte. Groups of bytes are represented in Internet byte order.
B:字节。字节组以Internet字节顺序表示。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for the transmission of data and control information carried in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSM-CC：数字存储媒体命令和控制[ISO-DSMCC]。一种用于传输MPEG-2专用部分中所载数据和控制信息的格式，由ISO MPEG-2标准定义。
DVB: Digital Video Broadcasting [DVB]. 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.
DVB：数字视频广播[DVB]。欧洲电信标准协会（ETSI）发布的一个框架和一组相关标准，用于使用ISO MPEG-2标准传输视频、音频和数据。
DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bidirectional IPv4/IPv6 service employing low-cost Receivers [ETSI-RCS].
DVB-RCS：通过卫星的数字视频广播返回通道。采用低成本接收器的双向IPv4/IPv6服务[ETSI-RCS]。
DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS].
DVB-S：卫星数字视频广播[ETSI-DVBS]。
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数据包流输出的网络设备。
Feed Router: The router delivering the IP service over a Unidirectional Link.
馈送路由器：通过单向链路提供IP服务的路由器。
INT: Internet/MAC Notification Table. A unidirectional address resolution mechanism using SI and/or PSI Tables.
INT：Internet/MAC通知表。使用SI和/或PSI表的单向地址解析机制。
L2: Layer 2, the link layer.
L2：第2层，链接层。
L3: Layer 3, the IP network layer.
L3：第三层，IP网络层。
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2).
MAC：媒体访问控制[IEEE-802.3]。由IEEE 802.3标准（或以太网v2）定义的链路层协议。
MAC Address: A 6-byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA).
MAC地址：以太网IEEE 802标准所述格式的6字节链路层地址（另见NPA）。
MAC Header: The link layer header of the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2. It consists of a 6-byte destination address, 6-byte source address, and 2 byte type field (see also NPA, LLC (Logical Link Control)).
MAC头：IEEE 802.3标准[IEEE-802.3]或Ethernet v2的链路层头。它由6字节的目标地址、6字节的源地址和2字节类型的字段组成（另请参见NPA，LLC（逻辑链路控制））。
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia Receiver, that may (in some cases) support IPv4/IPv6 services [ETSI-MHP].
多媒体家庭平台。一种集成的MPEG-2多媒体接收器，在某些情况下可能支持IPv4/IPv6服务[ETSI-MHP]。
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to PID values).
MMT：多播映射表（DVB-RCS[ETSI-RCS]的专有扩展，定义了将IPv4多播地址映射到PID值的AR表）。
MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90]. A method that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single Stream (TS Logical Channel).
MPE：多协议封装[ETSI-DAT]，[ATSC-A90]。一种封装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 Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG-2：由电影专家组（MPEG）规定并由国际标准组织（ISO/IEC 113818-1）[ISO-MPEG2]和ITU-T（H.220）标准化的一组标准。
NPA: Network Point of Attachment. A 6-byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers [RFC4259].
NPA：网络连接点。MPEG-2传输网络内的6字节目的地址（类似于IEEE MAC地址），用于识别单个接收机或接收机组[RFC4259]。
PAT: Program Association Table. An MPEG-2 PSI control table. It associates each program with the PID value that is used to send the associated PMT (Program Map Table). The table is sent using the well-known PID value of 0x000, and is required for an MPEG-2 compliant Transport Stream.
PAT：程序关联表。MPEG-2psi控制表。它将每个程序与用于发送相关PMT（程序映射表）的PID值相关联。该表是使用众所周知的PID值0x000发送的，并且是符合MPEG-2的传输流所必需的。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets.
协议数据单元。PDU的示例包括以太网帧、IPv4或IPv6数据报以及其他网络数据包。
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section, or other Payload Unit must all carry the same PID value. A PID value of all ones indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID：数据包标识符[ISO-MPEG2]。每个TS数据包的报头中携带的13位字段。这标识TS数据包所属的TS逻辑信道[ISO-MPEG2]。构成表格部分或其他有效负载单元的TS数据包都必须携带相同的PID值。PID值全部为1表示引入空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-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT.
PMT：程序映射表。一种MPEG-2 PSI控制表，用于关联组成程序[ISO-MPEG2]的TS逻辑通道/流集合使用的PID值。用于发送特定程序的PMT的PID值由PAT中的条目定义。
Private Section: A syntactic structure constructed according to Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g., ETSI and ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
专用部分：根据[ISO-MPEG2]表2-30构造的句法结构。该结构可用于识别与一个或多个基本流、特定MPEG-2节目或整个传输流相关的私有信息（即，未由[ISO-MPEG2]定义）。其他标准机构，如ETSI和ATSC，已使用private_section结构定义了一组表结构。专用部分使用TS逻辑信道作为TS分组序列传输。TS逻辑信道可以承载来自多组表的部分。
PSI: Program Specific Information [ISO-MPEG2]. 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-MPEG2], see also SI Table.
PSI：程序特定信息[ISO-MPEG2]。PSI用于传送关于TS多路复用中承载的服务的信息。它包含在四个专门标识的表节构造[ISO-MPEG2]中，另见SI表。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
接收器：处理来自TS多路复用的信号并对封装的PDU进行过滤和转发到网络层服务（或在链路层操作时桥接模块）的设备。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections, however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SI表：服务信息表[ISO-MPEG2]。在本文件中，该术语描述了由另一个标准机构定义的表，以传达关于TS多路复用中承载的服务的信息。一个表可以由一个或多个表部分组成，但是，特定SI表的所有部分必须通过单个TS逻辑通道[ISO-MPEG2]传输。
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：子网数据单元。作为MPEG-2有效负载单元发送的封装PDU。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG2].
表段：承载全部或部分SI或PSI表的有效载荷装置[ISO-MPEG2]。
TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents Layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS：传输流[ISO-MPEG2]，一种使用TS分组在MPEG-2级进行传输的方法；它代表ISO/OSI参考模型的第2层。另请参见TS逻辑通道和TS多路复用。
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the
TS逻辑通道：传输流逻辑通道。在本文档中，该术语标识MPEG-2级别[ISO-MPEG2]的信道。这存在于ISO/OSI参考模型的第2级。通过TS逻辑通道发送的所有数据包都具有相同的PID值（该值在特定TS多路复用中是唯一的）。术语“流”在MPEG-2[ISO-MPEG2]中定义。这描述了
content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved (by MPEG-2) for specific signaling. Other standards (e.g., ATSC and DVB) also reserve specific PID values.
由特定TS逻辑通道承载的内容（请参阅ULE流）。某些PID值（由MPEG-2）保留用于特定信令。其他标准（如ATSC和DVB）也保留特定的PID值。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259], for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
TS多路复用：在本文档中，该术语定义了通过单个较低层连接发送的一组MPEG-2 TS逻辑通道。这可以是公共物理链路（即，以指定符号速率、FEC设置和传输频率的传输）或由另一协议层（例如，以太网或RTP over IP）提供的封装。相同的TS逻辑信道可以在多个TS多路复用上重复（可能与不同的PID值相关联）[RFC4259]，例如，将相同的多播内容重新分发到两个地面TV传输小区。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header.
TS数据包：通过TS多路复用发送的固定长度188B的数据单位[ISO-MPEG2]。每个TS数据包携带一个4B报头。
UDL: Unidirectional link: A one-way transmission link. For example, and IP over DVB link using a broadcast satellite link.
单向链路：单向传输链路。例如，使用广播卫星链路的IP over DVB链路。
ULE: Unidirectional Lightweight Encapsulation. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel [RFC4326].
ULE: Unidirectional Lightweight Encapsulation. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel [RFC4326].translate error, please retry
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [RFC4326, ISO-MPEG2].
ULE流：仅承载ULE封装PDU的MPEG-2 TS逻辑通道。ULE流可通过SI/PSI[RFC4326，ISO-MPEG2]中的流类型定义来识别。
The MPEG IP address resolution process is independent of the choice of encapsulation and needs to support a set of IP over MPEG-2 encapsulation formats, including Multi-Protocol Encapsulation (MPE) ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional Lightweight Encapsulation (ULE) [RFC4326].
MPEG IP地址解析过程独立于封装的选择，需要支持一组IP over MPEG-2封装格式，包括多协议封装（MPE）（[ETSI-DAT]，[ATSC-A90]）和IETF定义的单向轻量封装（ULE）[RFC4326]。
The general IP over MPEG-2 AR requirements are summarized below:
MPEG-2 AR的一般IP要求总结如下：
- A scalable architecture that may support large numbers of systems within the MPEG-2 Network [RFC4259].
- 可扩展架构，可支持MPEG-2网络内的大量系统[RFC4259]。
- A protocol version, to indicate the specific AR protocol in use and which may include the supported encapsulation method.
- 协议版本，用于指示正在使用的特定AR协议，可能包括支持的封装方法。
- A method (e.g., well-known L2/L3 address/addresses) to identify the AR Server sourcing the AR information.
- 一种方法（例如，众所周知的L2/L3地址），用于识别获取AR信息的AR服务器。
- A method to represent IPv4/IPv6 AR information (including security mechanisms to authenticate the AR information to protect against address masquerading [RFC3756]).
- 表示IPv4/IPv6 AR信息的方法（包括验证AR信息以防止地址伪装的安全机制[RFC3756]）。
- A method to install AR information associated with clients at the AR Server (registration).
- 在AR服务器上安装与客户端关联的AR信息的方法（注册）。
- A method for transmission of AR information from an AR Server to clients that minimize the transmission cost (link-local multicast is preferable to subnet broadcast).
- 一种用于将AR信息从AR服务器传输到客户端的方法，该方法使传输成本最小化（链路本地多播比子网广播更可取）。
- Incremental update of the AR information held by clients.
- 客户持有的AR信息的增量更新。
- Procedures for purging clients of stale AR information.
- 清除客户端过时应收账款信息的过程。
An MPEG-2 transmission network may support multiple IP networks. If this is the case, it is important to recognize the scope within which an address is resolved to prevent packets from one addressed scope leaking into other scopes [RFC4259]. Examples of overlapping IP address assignments include:
MPEG-2传输网络可以支持多个IP网络。如果是这种情况，识别解析地址的作用域非常重要，以防止来自一个寻址作用域的数据包泄漏到其他作用域[RFC4259]。重叠IP地址分配的示例包括：
(i) Private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; and 192.168/16 prefix). Packets with these addresses should be confined to one addressed area. IPv6 also defines link-local addresses that must not be forwarded beyond the link on which they were first sent.
(i) 专用单播地址（例如，在IPv4中，10/8前缀；172.16/12前缀；和192.168/16前缀）。具有这些地址的数据包应限制在一个寻址区域内。IPv6还定义了链路本地地址，这些地址不得转发到第一次发送它们的链路之外。
(ii) 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].
（ii）本地范围多播地址。这些仅在本地区域内有效（IPv4的示例包括：224.0.0/24；224.0.1/24）。某些IPv6多播地址[RFC2375]也存在类似情况。
(iii) Scoped multicast addresses [RFC2365] and [RFC2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid within an addressed area (e.g., the 239/8 [RFC2365]).
（iii）作用域多播地址[RFC2365]和[RFC2375]。这些地址的转发由与地址关联的作用域控制。地址仅在寻址区域内有效（例如，239/8[RFC2365]）。
Overlapping address assignments may also occur at L2, where the same MAC/NPA address is used to identify multiple Receivers [RFC4259]:
重叠的地址分配也可能发生在L2，其中相同的MAC/NPA地址用于标识多个接收器[RFC4259]：
(i) An MAC/NPA unicast address must be unique within the addressed area. The IEEE-assigned MAC addresses used in Ethernet LANs are globally unique. If the addresses are not globally unique, an address must only be re-used by Receivers in different addressed (scoped) areas.
(i) MAC/NPA单播地址在寻址区域内必须是唯一的。以太网LAN中使用的IEEE分配的MAC地址是全局唯一的。如果地址不是全局唯一的，则地址只能由不同寻址（作用域）区域中的接收者重新使用。
(ii) The MAC/NPA address broadcast address (a L2 address of all ones). Traffic with this address should be confined to one addressed area.
（ii）MAC/NPA地址广播地址（所有地址的L2地址）。使用此地址的交通应限制在一个地址区域内。
(iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (Sections 3.2 and 5.6).
（iii）IP和其他协议可将L3多播地址集视为本地链路。若将具有相应多播L2地址的帧分发到不同L3网络或多播作用域中的系统，则可能会产生意外结果（第3.2和5.6节）。
Reception of unicast packets destined for another addressed area will lead to an increase in the rate of received packets by systems connected via the network. Reception of the additional network traffic may contribute to processing load, but should not lead to unexpected protocol behaviour, providing that systems can be uniquely addressed at L2. It does however introduce a potential Denial of Service (DoS) opportunity. When the Receiver operates as an IP router, the receipt of such a packet can lead to unexpected protocol behaviour.
接收目的地为另一个寻址区域的单播分组将导致通过网络连接的系统接收分组的速率增加。接收额外的网络流量可能会增加处理负载，但不应导致意外的协议行为，前提是系统可以在L2处唯一寻址。但是，它确实会带来潜在的拒绝服务（DoS）机会。当接收器作为IP路由器运行时，接收到这样的数据包可能导致意外的协议行为。
Unicast address resolution is required at two levels.
单播地址解析需要两个级别。
At the lower level, the IP (or MAC) address needs to be associated with a specific TS Logical Channel (PID value) and the corresponding TS Multiplex (Section 4). Each Encapsulator within an MPEG-2 Network is associated with a set of unique TS Logical Channels (PID values) that it sources [ETSI-DAT, RFC4259]. Within a specific scope, the same unicast IP address may therefore be associated with more than one Stream, and each Stream contributes different content (e.g., when several different IP Encapsulators contribute IP flows destined to the same Receiver). MPEG-2 Networks may also replicate IP packets to send the same content (Simulcast) to different Receivers or via different TS Multiplexes. The configuration of the MPEG-2 Network must prevent a Receiver accepting duplicated copies of the same IP packet.
在较低级别，IP（或MAC）地址需要与特定的TS逻辑信道（PID值）和相应的TS多路复用（第4节）相关联。MPEG-2网络中的每个封装器都与一组唯一的TS逻辑通道（PID值）相关联，这些通道是由其源[ETSI-DAT，RFC4259]提供的。在特定范围内，相同的单播IP地址因此可以与多个流相关联，并且每个流提供不同的内容（例如，当多个不同的IP封装器提供目的地为同一接收器的IP流时）。MPEG-2网络还可以复制IP分组，以向不同的接收器或通过不同的TS多路复用发送相同的内容（同步广播）。MPEG-2网络的配置必须防止接收器接受相同IP数据包的重复副本。
At the upper level, the AR procedure needs to associate an IP address with a specific MAC/NPA address (Section 5).
在上层，AR程序需要将IP地址与特定MAC/NPA地址相关联（第5节）。
Multicast is an important application for MPEG-2 transmission networks, since it exploits the advantages of native support for link broadcast. Multicast address resolution occurs at the network-level in associating a specific L2 address with an IP Group Destination Address (Section 5.6). In IPv4 and IPv6 over Ethernet, this
组播是MPEG-2传输网络的一个重要应用，因为它利用了本地支持链路广播的优势。多播地址解析发生在网络级别，将特定L2地址与IP组目标地址关联（第5.6节）。在以太网上的IPv4和IPv6中
association is normally a direct mapping, and this is the default method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].
关联通常是直接映射，这是ULE[RFC4326]和MPE[ETSI-DAT]中也指定的默认方法。
Address resolution must also occur at the MPEG-2 level (Section 4). The goal of this multicast address resolution is to allow a Receiver to associate an IPv4 or IPv6 multicast address with a specific TS Logical Channel and the corresponding TS Multiplex [RFC4259]. This association needs to permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets (e.g., by distributing the multicast traffic over a number of TS Logical Channels). Schemes that allow hardware filtering can be beneficial, since these may relieve the drivers and operating systems from discarding unwanted multicast traffic.
地址解析也必须发生在MPEG-2级别（第4节）。此多播地址解析的目标是允许接收器将IPv4或IPv6多播地址与特定TS逻辑通道和相应的TS多路复用相关联[RFC4259]。该关联需要允许大量的活动多播组，并且在过滤和转发IP多播分组时（例如，通过在多个TS逻辑信道上分配多播通信量），应该最小化接收器处的处理负载。允许硬件过滤的方案可能是有益的，因为这些方案可以使驱动程序和操作系统免于丢弃不需要的多播流量。
There are two specific functions required for address resolution in IP multicast over MPEG-2 Networks:
在MPEG-2网络上的IP多播中，地址解析需要两个特定功能：
(i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
(i) 将IP多播组映射到封装器处的底层MPEG-2 TS逻辑通道（PID）和MPEG-2 TS多路复用。
(ii) Provide signalling information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
（ii）提供信令信息以允许接收器在MPEG-2 TS多路复用内定位IP多播流。
Methods are required to identify the scope of an address when an MPEG-2 Network supports several logical IP networks and carries groups within different multicast scopes [RFC4259].
当MPEG-2网络支持多个逻辑IP网络并在不同的多播作用域内承载组时，需要使用方法来识别地址的作用域[RFC4259]。
Appropriate procedures need to specify the correct action when the same multicast group is available on separate TS Logical Channels. This could arise when different Encapsulators contribute IP packets with the same IP Group Destination Address in the ASM (Any-Source Multicast) address range. Another case arises when a Receiver could receive more than one copy of the same packet (e.g., when packets are replicated across different TS Logical Channels or even different TS Multiplexes, a method known as Simulcasting [ETSI-DAT]). At the IP level, the host/router may be unaware of this duplication and this needs to be detected by other means.
当相同的多播组在单独的TS逻辑信道上可用时，适当的过程需要指定正确的操作。当不同的封装器在ASM（任意源多播）地址范围内提供具有相同IP组目标地址的IP数据包时，可能会出现这种情况。另一种情况是，当接收机可以接收同一分组的多个副本时（例如，当分组在不同的TS逻辑信道或甚至不同的TS多路复用中被复制时，称为同时广播[ETSI-DAT]的方法）。在IP级别，主机/路由器可能不知道这种重复，这需要通过其他方式进行检测。
When the MPEG-2 Network is peered to the multicast-enabled Internet, an arbitrarily large number of IP multicast group destination addresses may be in use, and the set forwarded on the transmission network may be expected to vary significantly with time. Some uses of IP multicast employ a range of addresses to support a single application (e.g., ND [RFC2461], Layered Coding Transport (LCT) [RFC3451], and Wave and Equation Based Rate Control (WEBRC) [RFC3738]). The current set of active addresses may be determined dynamically via a multicast group membership protocol (e.g., Internet
当MPEG-2网络窥视到启用多播的因特网时，可以使用任意多个IP多播组目的地地址，并且可以期望在传输网络上转发的集合随着时间显著变化。IP多播的某些用途使用一系列地址来支持单个应用程序（例如，ND[RFC2461]、分层编码传输（LCT）[RFC3451]和基于波形和方程的速率控制（WEBRC）[RFC3738]）。可通过多播组成员协议（例如，因特网）动态地确定当前的一组活动地址
Group Management Protocol (IGMP) [RFC3376] and Multicast Listener Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol Independent Multicast (PIM) [RFC4601]) and/or other means (e.g., [RFC3819] and [RFC4605]), however each active address requires a binding by the AR method. Therefore, there are advantages in using a method that does not need to explicitly advertise an AR binding for each IP traffic flow, but is able to distribute traffic across a number of L2 TS Logical Channels (e.g., using a hash/mapping that resembles the mapping from IP addresses to MAC addresses [RFC1112, RFC2464]). Such methods can reduce the volume of AR information that needs to be distributed, and reduce the AR processing.
组管理协议（IGMP）[RFC3376]和多播侦听器发现（MLD）[RFC3810]），通过多播路由（例如，协议独立多播（PIM）[RFC4601]）和/或其他方式（例如，[RFC3819]和[RFC4605]），但是每个活动地址都需要AR方法的绑定。因此，使用不需要为每个IP业务流显式地通告AR绑定，但能够跨多个L2-TS逻辑信道分配业务的方法（例如，使用类似于从IP地址到MAC地址的映射的散列/映射[rfc112rfc2464]）具有优势。这种方法可以减少需要分发的AR信息量，并减少AR处理。
Section 5.6 describes the binding of IP multicast addresses to MAC/NPA addresses.
第5.6节描述了IP多播地址与MAC/NPA地址的绑定。
The first part of this section describes the role of MPEG-2 signalling to identify streams (TS Logical Channels [RFC4259]) within the L2 infrastructure.
本节的第一部分描述了MPEG-2信令在二级基础设施内识别流（TS逻辑信道[RFC4259]）的作用。
At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the existence and format of a Stream, using a combination of two PSI tables: the Program Association Table (PAT) and entries in the program element loop of a Program Map Table (PMT). PMT Tables are sent infrequently and are typically small in size. The PAT is sent using the well-known PID value of 0X000. This table provides the correspondence between a program_number and a PID value. (The program_number is the numeric label associated with a program). Each program in the Table is associated with a specific PID value, used to identify a TS Logical Channel (i.e., a TS). The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the program. This approach de-references the PID values when the MPEG-2 Network includes multiplexors or re-multiplexors that renumber the PID values of the TS Logical Channels that they process.
在L2，MPEG-2传输流[ISO-MPEG2]使用两个PSI表的组合来识别流的存在和格式：节目关联表（PAT）和节目映射表（PMT）的节目元素循环中的条目。PMT表不经常发送，通常较小。PAT使用众所周知的PID值0X000发送。此表提供了程序编号和PID值之间的对应关系。（程序编号是与程序关联的数字标签）。表中的每个程序都与特定的PID值相关联，用于标识TS逻辑通道（即TS）。识别的TS用于发送PMT，PMT将一组PID值与程序的各个组件相关联。当MPEG-2网络包括对其处理的TS逻辑信道的PID值重新编号的多路复用器或重多路复用器时，该方法取消引用PID值。
In addition to signalling the Receiver with the PID value assigned to a Stream, PMT entries indicate the presence of Streams using ULE and MPE to the variety of devices that may operate in the MPEG-2 transmission network (multiplexors, remultiplexors, rate shapers, advertisement insertion equipment, etc.).
除了用分配给流的PID值向接收机发送信号外，PMT条目还指示使用ULE和MPE向可在MPEG-2传输网络中操作的各种设备（多路复用器、再多路复用器、速率整形器、广告插入设备等）的流的存在。
A multiplexor or remultiplexor may change the PID values associated with a Stream during the multiplexing process, the new value being reflected in an updated PMT. TS Packets that carry a PID value that is not associated with a PMT entry (an orphan PID), may, and usually will be dropped by ISO 13818-1 compliant L2 equipment, resulting in
多路复用器或再多路复用器可以在多路复用过程中改变与流相关联的PID值，新值反映在更新的PMT中。带有与PMT条目（孤立PID）不相关的PID值的TS数据包可能，并且通常会被符合ISO 13818-1的L2设备丢弃，从而导致
the Stream not being forwarded across the transmission network. In networks that do not employ any intermediate devices (e.g., scenarios C,E,F of [RFC4259]), or where devices have other means to determine the set of PID values in use, the PMT table may still be sent (but is not required for this purpose).
未通过传输网络转发的流。在不使用任何中间设备的网络中（例如，[RFC4259]的场景C、e、F），或者在设备有其他方法来确定正在使用的PID值集的情况下，仍然可以发送PMT表（但不需要用于此目的）。
Although the basic PMT information may be used to identify the existence of IP traffic, it does not associate a Stream with an IP prefix/address. The remainder of the section describes IP addresses resolution mechanisms relating to MPEG-2.
尽管基本PMT信息可用于识别IP通信量的存在，但它不将流与IP前缀/地址相关联。本节其余部分介绍与MPEG-2相关的IP地址解析机制。
The static mapping option, where IP addresses or flows are statically mapped to specific PIDs is the equivalent to signalling "out-of-band". The application programmer, installing engineer, or user receives the mapping via some outside means, not in the MPEG-2 TS. This is useful for testing, experimental networks, small subnetworks and closed domains.
静态映射选项（其中IP地址或流静态映射到特定PID）相当于发送“带外”信号。应用程序程序员、安装工程师或用户通过某种外部方式（而不是MPEG-2 TS）接收映射。这对于测试、实验网络、小型子网和封闭域非常有用。
A pre-defined set of IP addresses may be used within an MPEG-2 transmission network. Prior knowledge of the active set of addresses allows appropriate AR records to be constructed for each address, and to pre-assign the corresponding PID value (e.g., selected to optimize Receiver processing; to group related addresses to the same PID value; and/or to reflect a policy for usage of specific ranges of PID values). This presumes that the PID mappings are not modified during transmission (Section 4).
可以在MPEG-2传输网络内使用预定义的IP地址集。对活动地址集的先验知识允许为每个地址构造适当的AR记录，并预先分配相应的PID值（例如，选择以优化接收器处理；将相关地址分组到相同的PID值；和/或反映使用特定PID值范围的策略）。这假定PID映射在传输过程中未被修改（第4节）。
A single "well-known" PID is a specialization of this. This scheme is used by current DOCSIS cable modems [DOCSIS], where all IP traffic is placed into the specified TS stream. MAC filtering (and/or Section filtering in MPE) may be used to differentiate subnetworks.
一个“众所周知的”PID就是其中的一个特例。此方案由当前的DOCSIS电缆调制解调器[DOCSIS]使用，其中所有IP流量都放入指定的TS流中。MAC过滤（和/或MPE中的部分过滤）可用于区分子网。
Cable networks use a different transmission scheme for downstream (head-end to cable modem) and upstream (cable modem to head-end) transmissions.
电缆网络对下行（头端到电缆调制解调器）和上行（电缆调制解调器到头端）传输使用不同的传输方案。
IP/Ethernet packets are sent (on the downstream) to the cable modem(s) encapsulated in MPEG-2 TS Packets sent on a single well-known TS Logical Channel (PID). There is no use of in-band signalling tables. On the upstream, the common approach is to use Ethernet framing, rather than IP/Ethernet over MPEG-2, although other proprietary schemes also continue to be used.
IP/以太网数据包被发送（在下游）到封装在MPEG-2 TS数据包中的电缆调制解调器，该数据包在单个已知TS逻辑通道（PID）上发送。不使用带内信令表。在上游，常用的方法是使用以太网帧，而不是MPEG-2上的IP/以太网，尽管也继续使用其他专有方案。
Until the deployment of DOCSIS and EuroDOCSIS, most address resolution schemes for IP traffic in cable networks were proprietary, and did not usually employ a table-based address resolution method. Proprietary methods continue to be used in some cases where cable modems require interaction. In this case, equipment at the head-end may act as gateways between the cable modem and the Internet. These gateways receive L2 information and allocate an IP address.
在部署DOCSIS和EuroDOCSIS之前，有线网络中IP流量的大多数地址解析方案都是专有的，通常不采用基于表的地址解析方法。在电缆调制解调器需要交互的某些情况下，继续使用专有方法。在这种情况下，前端设备可以充当电缆调制解调器和Internet之间的网关。这些网关接收L2信息并分配IP地址。
DOCSIS uses DHCP for IP client configuration. The Cable Modem Terminal System (CMTS) provides a DHCP Server that allocates IP addresses to DOCSIS cable modems. The MPEG-2 transmission network provides a L2 bridged network to the cable modem (Section 1). This usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and [RFC3256]. Issues in deployment of IPv6 are described in [RFC4779].
DOCSIS使用DHCP进行IP客户端配置。电缆调制解调器终端系统（CMTS）提供一个DHCP服务器，为DOCSIS电缆调制解调器分配IP地址。MPEG-2传输网络为电缆调制解调器提供L2桥接网络（第1节）。这通常充当IP设备[RFC2131]、[RFC3046]和[RFC3256]的DHCP中继。[RFC4779]中描述了IPv6部署中的问题。
The information about the set of MPEG-2 Transport Streams carried over a TS Multiplex can be distributed via SI/PSI Tables. These tables are usually sent periodically (Section 4). This design requires access to and processing of the SI Table information by each Receiver [ETSI-SI], [ETSI-SI1]. This scheme reflects the complexity of delivering and coordinating the various Transport Streams associated with multimedia TV. A TS Multiplex may provide AR information for IP services by integrating additional information into the existing control tables or by transmitting additional SI Tables that are specific to the IP service.
关于通过TS多路复用携带的MPEG-2传输流的集合的信息可以通过SI/PSI表来分发。这些表格通常定期发送（第4节）。此设计要求每个接收器[ETSI-SI]、[ETSI-SI1]访问和处理SI表信息。该方案反映了传送和协调与多媒体电视相关的各种传输流的复杂性。TS多路复用可以通过将附加信息集成到现有控制表中或通过发送特定于IP服务的附加SI表来为IP服务提供AR信息。
Examples of MPEG-2 Table usage that allows an MPEG-2 Receiver to identify the appropriate PID and the multiplex associated with a specific IP address include:
允许MPEG-2接收器识别与特定IP地址相关联的适当PID和多路复用的MPEG-2表使用的示例包括：
(i) IP/MAC Notification Table (INT) in the DVB Data standard [ETSI-DAT]. This provides unidirectional address resolution of IPv4/IPv6 multicast addresses to an MPEG-2 TS.
(i) DVB数据标准[ETSI-DAT]中的IP/MAC通知表（INT）。这为MPEG-2 TS提供IPv4/IPv6多播地址的单向地址解析。
(ii) Application Information Table (AIT) in the Multimedia Home Platform (MHP) specifications [ETSI-MHP].
（ii）多媒体家庭平台（MHP）规范[ETSI-MHP]中的应用信息表（AIT）。
(iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by some DVB-RCS systems to provide unidirectional address resolution of IPv4 multicast addresses to an MPEG-2 TS.
（iii）多播映射表（MMT）是一些DVB-RCS系统使用的MPEG-2表，用于向MPEG-2 TS提供IPv4多播地址的单向地址解析。
The MMT and AIT are used for specific applications, whereas the INT [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and IPv6 AR when used in combination with the other MPEG-2 tables (Section 4).
MMT和AIT用于特定应用，而INT[ETSI-DAT]是一种更通用的DVB方法，当与其他MPEG-2表结合使用时，它支持MAC、IPv4和IPv6 AR（第4节）。
The INT provides a set of descriptors to specify addressing in a DVB network. The use of this method is specified for Multiprotocol Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying information about the location of IP/L2 flows within a DVB network. A Platform_ID identifies the addressing scope for a set of IP/L2 streams and/or Receivers. A Platform may span several Transport Streams carried by one or multiple TS Multiplexes and represents a single IP network with a harmonized address space (scope). This allows for the coexistence of several independent IP/MAC address scopes within an MPEG-2 Network.
INT提供了一组描述符来指定DVB网络中的寻址。此方法的使用指定用于多协议封装（MPE）[ETSI-DAT]。它提供了一种在DVB网络中承载IP/L2流位置信息的方法。平台ID标识一组IP/L2流和/或接收器的寻址范围。平台可以跨越由一个或多个TS多路复用器承载的多个传输流，并表示具有协调地址空间（作用域）的单个IP网络。这允许在MPEG-2网络中共存多个独立的IP/MAC地址范围。
The INT allows both fully-specified IP addresses and prefix matching to reduce the size of the table (and hence enhance signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified in full form or by using a slash notation (e.g., /127). IP multicast addresses can be specified with or without a source (address or range), although if a source address is specified, then only the slash notation may be used for prefixes.
INT允许完全指定的IP地址和前缀匹配，以减少表的大小（从而提高信令效率）。IPv4/IPv6“子网掩码”可以完整形式指定，也可以使用斜杠符号指定（例如，/127）。IP多播地址可以指定源（地址或范围），也可以不指定源（地址或范围），但如果指定了源地址，则前缀只能使用斜杠符号。
In addition, for identification and security descriptors, the following descriptors are defined for address binding in INT tables:
此外，对于标识和安全描述符，为INT表中的地址绑定定义了以下描述符：
(i) target_MAC_address_descriptor: A descriptor to describe a single or set of MAC addresses (and their mask).
(i) 目标MAC地址描述符：描述单个或一组MAC地址（及其掩码）的描述符。
(ii) target_MAC_address_range_descriptor: A descriptor that may be used to set filters.
（ii）目标\ MAC\地址\范围\描述符：可用于设置过滤器的描述符。
(iii) target_IP_address_descriptor: A descriptor describing a single or set of IPv4 unicast or multicast addresses (and their mask).
（iii）目标IP地址描述符：描述单个或一组IPv4单播或多播地址（及其掩码）的描述符。
(iv) target_IP_slash_descriptor: Allows definition and announcement of an IPv4 prefix.
（iv）目标IP斜杠描述符：允许定义和宣布IPv4前缀。
(v) target_IP_source_slash_descriptor: Uses source and destination addresses to target a single or set of systems.
(v) 目标\ IP \源\斜杠\描述符：使用源地址和目标地址以单个或一组系统为目标。
(vi) IP/MAC stream_location_descriptor: A descriptor that locates an IP/MAC stream in a DVB network.
（vi）IP/MAC流\位置\描述符：在DVB网络中定位IP/MAC流的描述符。
The following descriptors provide corresponding functions for IPv6 addresses:
以下描述符为IPv6地址提供了相应的函数：
target_IPv6_address_descriptor target_IPv6_slash_descriptor and target_IPv6_source_slash_descriptor
目标\u IPv6\u地址\u描述符目标\u IPv6\u斜杠\u描述符和目标\u IPv6\u源\u斜杠\u描述符
The ISP_access_mode_descriptor allows specification of a second address descriptor to access an ISP via an alternative non-DVB (possibly non-IP) network.
ISP_访问_模式_描述符允许指定第二地址描述符，以通过替代的非DVB（可能是非IP）网络访问ISP。
One key benefit is that the approach employs MPEG-2 signalling (Section 4) and is integrated with other signalling information. This allows the INT to operate in the presence of (re)multiplexors [RFC4259] and to refer to PID values that are carried in different TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario [RFC4259].
一个主要优点是，该方法采用MPEG-2信令（第4节），并与其他信令信息集成。这允许INT在存在（re）多路复用器[RFC4259]的情况下工作，并参考不同TS多路复用器中携带的PID值。这使得它非常适合广播电视场景[RFC4259]。
The principal drawback is a need for an Encapsulator to introduce associated PSI/SI MPEG-2 control information. This control information needs to be processed at a Receiver. This requires access to information below the IP layer. The position of this processing within the protocol stack makes it hard to associate the results with IP Policy, management, and security functions. The use of centralized management prevents the implementation of a more dynamic scheme.
主要缺点是需要封装器引入相关的PSI/SI MPEG-2控制信息。此控制信息需要在接收器处处理。这需要访问IP层下的信息。此处理在协议栈中的位置使得很难将结果与IP策略、管理和安全功能相关联。集中管理的使用阻止了更动态方案的实施。
In DVB-RCS, unicast AR is seen as a part of a wider configuration and control function and does not employ a specific protocol.
在DVB-RCS中，单播AR被视为更广泛配置和控制功能的一部分，不采用特定协议。
A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control table that associates a set of multicast addresses with the corresponding PID values [MMT]. This table allows a DVB-RCS Forward Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 multicast addresses to PID values within a specific TS Multiplex. Receivers (DVB-RCS Return Channel Satellite Terminals (RCSTs)) may use this table to determine the PID values associated with an IP multicast flow that it requires to receive. The MMT is specified by the SatLabs Forum [MMT] and is not currently a part of the DVB-RCS specification.
可以在MPEG-2控制表中携带多播映射表（MMT），该控制表将一组多播地址与相应的PID值[MMT]相关联。此表允许DVB-RCS前向链路子系统（FLSS）指定IPv4和IPv6多播地址到特定TS多路复用内PID值的映射。接收机（DVB-RCS返回信道卫星终端（RCST））可使用此表来确定与需要接收的IP多播流相关联的PID值。MMT由卫星实验室论坛[MMT]指定，目前不是DVB-RCS规范的一部分。
The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does not define a specific AR function. However, an Application Information Table (AIT) is defined that allows MHP Receivers to receive a variety of control information. The AIT uses an MPEG-2 signalling table, providing information about data broadcasts, the required activation state of applications carried by a broadcast stream, etc. This information allows a broadcaster to request that a Receiver change the activation state of an application, and to direct
DVB多媒体家庭平台（MHP）规范[ETSI-MHP]未定义特定的AR功能。然而，定义了应用信息表（AIT），允许MHP接收器接收各种控制信息。AIT使用MPEG-2信令表，提供关于数据广播、广播流承载的应用程序的所需激活状态等的信息。该信息允许广播公司请求接收器更改应用程序的激活状态，并指导
applications to receive specific multicast packet flows (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a specific function, but as a part of a wider configuration and control function.
用于接收特定多播数据包流的应用程序（使用IPv4或IPv6描述符）。在MHP中，AR不被视为特定功能，而是更广泛配置和控制功能的一部分。
ATSC [ATSC-A54A] defines a system that allows transmission of IP packets within an MPEG-2 Network. An MPEG-2 Program (defined by the PMT) may contain one or more applications [ATSC-A90] that include IP multicast streams [ATSC-A92]. IP multicast data are signalled in the PMT using a stream_type indicator of value 0x0D. A MAC address list descriptor [SCTE-1] may also be included in the PMT.
ATSC[ATSC-A54A]定义了一种允许在MPEG-2网络内传输IP数据包的系统。MPEG-2程序（由PMT定义）可以包含一个或多个应用程序[ATSC-A90]，其中包括IP多播流[ATSC-A92]。IP多播数据在PMT中使用值0x0D的流类型指示符发送信号。MAC地址列表描述符[SCTE-1]也可以包括在PMT中。
The approach focuses on applications that serve the transmission network. A method is defined that uses MPEG-2 SI Tables to bind the IP multicast media streams and the corresponding Session Description Protocol (SDP) announcement streams to particular MPEG-2 Program Elements. Each application constitutes an independent network. The MPEG-2 Network boundaries establish the IP addressing scope.
该方法侧重于服务于传输网络的应用程序。定义了一种使用MPEG-2 SI表将IP多播媒体流和相应的会话描述协议（SDP）公告流绑定到特定MPEG-2节目元素的方法。每个应用程序构成一个独立的网络。MPEG-2网络边界确定了IP寻址范围。
The MPEG-2 methods based on SI/PSI meet the specified requirements of the groups that created them and each has their strength: the INT in terms of flexibility and extensibility, the MMT in its simplicity, and the AIT in its extensibility. However, they exhibit scalability constraints, represent technology specific solutions, and do not fully adopt IP-centric approaches that would enable easier use of the MPEG-2 bearer as a link technology within the wider Internet.
基于SI/PSI的MPEG-2方法满足创建它们的组的特定要求，并且每个方法都有自己的优势：灵活性和可扩展性方面的INT，简单性方面的MMT，以及可扩展性方面的AIT。然而，它们表现出可伸缩性限制，代表了特定于技术的解决方案，并且没有完全采用以IP为中心的方法，从而更容易地将MPEG-2承载作为更广泛的互联网中的链路技术使用。
As MPEG-2 Networks evolve to become multi-service networks, the use of IP protocols is becoming more prevalent. Most MPEG-2 Networks now use some IP protocols for operations and control and data delivery. Address resolution information could also be sent using IP transport. At the time of writing there is no standards-based IP-level AR protocol that supports the MPEG-2 TS.
随着MPEG-2网络向多业务网络的发展，IP协议的使用变得越来越普遍。大多数MPEG-2网络现在使用一些IP协议进行操作、控制和数据传输。地址解析信息也可以使用IP传输发送。在撰写本文时，还没有支持MPEG-2 TS的基于标准的IP级AR协议。
There is an opportunity to define an IP-level method that could use an IP multicast protocol over a well-known IP multicast address to resolve an IP address to a TS Logical Channel (i.e., a Transport Stream). The advantages of using an IP-based address resolution include:
有机会定义一种IP级方法，该方法可以使用已知IP多播地址上的IP多播协议将IP地址解析为TS逻辑信道（即，传输流）。使用基于IP的地址解析的优点包括：
(i) Simplicity: The AR mechanism does not require interpretation of L2 tables; this is an advantage especially in the growing market share for home network and audio/video networked entities.
(i) 简单性：AR机制不需要解释L2表；这是一个优势，尤其是在家庭网络和音频/视频网络实体的市场份额不断增长的情况下。
(ii) Uniformity: An IP-based protocol can provide a common method across different network scenarios for both IP to MAC address mappings and mapping to TS Logical Channels (PID value associated with a Stream).
（ii）一致性：基于IP的协议可以为IP到MAC地址映射和映射到TS逻辑通道（与流相关联的PID值）提供跨不同网络场景的通用方法。
(iii) Extensibility: IP-based AR mechanisms allow an independent evolution of the AR protocol. This includes dynamic methods to request address resolution and the ability to include other L2 information (e.g., encryption keys).
（iii）可扩展性：基于IP的AR机制允许AR协议的独立演化。这包括请求地址解析的动态方法以及包含其他L2信息（例如，加密密钥）的能力。
(iv) Integration: The information exchanged by IP-based AR protocols can easily be integrated as a part of the IP network layer, simplifying support for AAA, policy, Operations and Management (OAM), mobility, configuration control, etc., that combine AR with security.
（iv）集成：通过基于IP的AR协议交换的信息可以很容易地集成为IP网络层的一部分，简化了对AAA、策略、操作和管理（OAM）、移动性、配置控制等的支持，将AR与安全性结合起来。
The drawbacks of an IP-based method include:
基于IP的方法的缺点包括：
(i) It can not operate over an MPEG-2 Network that uses MPEG-2 remultiplexors [RFC4259] that modify the PID values associated with the TS Logical Channels during the multiplexing operation (Section 4). This makes the method unsuitable for use in deployed broadcast TV networks [RFC4259].
(i) 它不能在使用MPEG-2复用器[RFC4259]的MPEG-2网络上运行，该复用器在复用操作期间修改与TS逻辑信道相关联的PID值（第4节）。这使得该方法不适用于已部署的广播电视网络[RFC4259]。
(ii) IP-based methods can introduce concerns about the integrity of the information and authentication of the sender [RFC4259]. (These concerns are also applicable to MPEG-2 Table methods, but in this case the information is confined to the L2 network, or parts of the network where gateway devices isolate the MPEG-2 devices from the larger Internet creating virtual MPEG-2 private networks.) IP-based solutions should therefore implement security mechanisms that may be used to authenticate the sender and verify the integrity of the AR information as a part of a larger security framework.
（ii）基于IP的方法可能会引起对信息完整性和发送方身份验证的担忧[RFC4259]。（这些关注点也适用于MPEG-2表格方法，但在这种情况下，信息仅限于L2网络，或网关设备将MPEG-2设备与创建虚拟MPEG-2专用网络的较大互联网隔离的网络部分。）因此，基于IP的解决方案应实施安全机制，这些机制可用于验证发送方，并作为更大安全框架的一部分验证AR信息的完整性。
An IP-level method could use an IP multicast protocol running an AR Server (see also Section 5.4) over a well-known (or discovered) IP multicast address. To satisfy the requirement for scalability to networks with a large number of systems (Section 1), a single packet needs to transport multiple AR records and define the intended scope
IP级方法可以使用IP多播协议，在已知（或发现的）IP多播地址上运行AR服务器（另请参见第5.4节）。为了满足具有大量系统的网络的可扩展性要求（第1节），单个数据包需要传输多个AR记录并定义预期范围
for each address. Methods that employ prefix matching are desirable (e.g., where a range of source/destination addresses are matched to a single entry). It can also be beneficial to use methods that permit a range of IP addresses to be mapped to a set of TS Logical Channels (e.g., a hashing technique similar to the mapping of IP Group Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464]).
对于每个地址。采用前缀匹配的方法是可取的（例如，将一系列源/目标地址匹配到单个条目）。使用允许将一系列IP地址映射到一组TS逻辑信道的方法（例如，类似于将IP组目的地地址映射到以太网MAC地址[RFC1112][RFC2464]的散列技术）也是有益的。
This section reviews IETF protocols that may be used to assign and manage the mapping of IP addresses to/from MAC/NPA addresses over MPEG-2 Networks.
本节回顾了IETF协议，这些协议可用于通过MPEG-2网络分配和管理IP地址到MAC/NPA地址的映射。
An IP Encapsulator requires AR information to select an appropriate MAC/NPA address in the SNDU header [RFC4259] (Section 6). The information to complete this header may be taken directly from a neighbor/ARP cache, or may require the Encapsulator to retrieve the information using an AR protocol. The way in which this information is collected will depend upon whether the Encapsulator functions as a Router (at L3) or a Bridge (at L2) (Section 1.1).
IP封装器需要AR信息在SNDU头[RFC4259]（第6节）中选择适当的MAC/NPA地址。完成此报头的信息可以直接从邻居/ARP缓存获取，或者可能需要封装器使用AR协议检索信息。收集这些信息的方式将取决于封装器是作为路由器（在L3）还是桥接器（在L2）（第1.1节）。
Two IETF-defined protocols for mapping IP addresses to MAC/NPA addresses are the Address Resolution Protocol, ARP [RFC826], and the Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and IPv6. Both protocols are normally used in a bidirectional mode, although both also permit unsolicited transmission of mappings. The IPv6 mapping defined in [RFC2464] can result in a large number of active MAC multicast addresses (e.g., one for each end host).
用于将IP地址映射到MAC/NPA地址的两个IETF定义的协议是地址解析协议ARP[RFC826]和邻居发现协议ND[RFC2461]，分别用于IPv4和IPv6。这两个协议通常以双向模式使用，尽管它们也允许映射的非请求传输。[RFC2464]中定义的IPv6映射可能导致大量活动MAC多播地址（例如，每个终端主机一个）。
ARP requires support for L2 broadcast packets. A large number of Receivers can lead to a proportional increase in ARP traffic, a concern for bandwidth-limited networks. Transmission delay can also impact protocol performance.
ARP要求支持L2广播数据包。大量接收器可能导致ARP流量成比例增加，这是带宽有限网络的一个问题。传输延迟也会影响协议性能。
ARP also has a number of security vulnerabilities. ARP spoofing is where a system can be fooled by a rogue device that sends a fictitious ARP RESPONSE that includes the IP address of a legitimate network system and the MAC of a rogue system. This causes legitimate systems on the network to update their ARP tables with the false mapping and then send future packets to the rogue system instead of the legitimate system. Using this method, a rogue system can see (and modify) packets sent through the network.
ARP还存在许多安全漏洞。ARP欺骗是指一个系统可能被一个恶意设备欺骗，该设备发送一个虚构的ARP响应，其中包括合法网络系统的IP地址和恶意系统的MAC地址。这会导致网络上的合法系统使用错误映射更新其ARP表，然后将未来的数据包发送到恶意系统，而不是合法系统。使用这种方法，恶意系统可以看到（并修改）通过网络发送的数据包。
Secure ARP (SARP) uses a secure tunnel (e.g., between each client and a server at a wireless access point or router) [RFC4346]. The router ignores any ARP RESPONSEs not associated with clients using the secure tunnels. Therefore, only legitimate ARP RESPONSEs are used
安全ARP（SARP）使用安全隧道（例如，在无线接入点或路由器的每个客户端和服务器之间）[RFC4346]。路由器忽略与使用安全隧道的客户端无关的任何ARP响应。因此，只使用合法的ARP响应
for updating ARP tables. SARP requires the installation of software at each client. It suffers from the same scalability issues as the standard ARP.
用于更新ARP表。SARP要求在每个客户端安装软件。它与标准ARP一样存在可伸缩性问题。
The ND protocol uses a set of IP multicast addresses. In large networks, many multicast addresses are used, but each client typically only listens to a restricted set of group destination addresses and little traffic is usually sent in each group. Therefore, Layer 2 AR for MPEG-2 Networks must support this in a scalable manner.
ND协议使用一组IP多播地址。在大型网络中，使用了许多多播地址，但每个客户端通常只侦听一组受限的组目标地址，并且通常在每个组中发送很少的通信量。因此，MPEG-2网络的第2层AR必须以可伸缩的方式支持这一点。
A large number of ND messages may cause a large demand for performing asymmetric operations. The base ND protocol limits the rate at which multicast responses to solicitations can be sent. Configurations may need to be tuned when operating with large numbers of Receivers.
大量ND消息可能会导致对执行非对称操作的大量需求。基本ND协议限制对请求的多播响应可以发送的速率。在使用大量接收器时，可能需要调整配置。
The default parameters specified in the ND protocol [RFC2461] can introduce interoperability problems (e.g., a failure to resolve when the link RTT (round-trip time) exceed 3 seconds) and performance degradation (duplicate ND messages with a link RTT > 1 second) when used in networks where the link RTT is significantly larger than experienced by Ethernet LANs. Tuning of the protocol parameters (e.g., RTR_SOLICITATION_INTERVAL) is therefore recommended when using network links with appreciable delay (Section 6.3.2 of [RFC2461]).
ND协议[RFC2461]中指定的默认参数可能会导致互操作性问题（例如，当链路RTT（往返时间）超过3秒时无法解决）和性能下降（链路RTT>1秒的重复ND消息）当用于链路RTT明显大于以太网LAN的网络时。因此，当使用具有明显延迟的网络链路时，建议调整协议参数（例如，RTR_请求_间隔）（[RFC2461]第6.3.2节）。
ND has similar security vulnerabilities to ARP. The Secure Neighbor Discovery (SEND) [RFC3971] was developed to address known security vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic compared to ND. In addition, SEND does not require the configuration of per-host keys and can coexist with the use of both SEND and insecure ND on the same link.
ND具有与ARP类似的安全漏洞。安全邻居发现（SEND）[RFC3971]是为了解决ND[RFC3756]中已知的安全漏洞而开发的。与ND相比，它还可以减少AR流量。此外，SEND不需要配置每主机密钥，并且可以在同一链路上同时使用SEND和不安全的ND。
The ND Protocol is also used by IPv6 systems to perform other functions beyond address resolution, including Router Solicitation / Advertisement, Duplicate Address Detection (DAD), Neighbor Unreachability Detection (NUD), and Redirect. These functions are useful for hosts, even when address resolution is not required.
IPv6系统还使用ND协议执行地址解析以外的其他功能，包括路由器请求/公布、重复地址检测（DAD）、邻居不可达性检测（NUD）和重定向。这些函数对于主机很有用，即使不需要地址解析。
MPEG-2 Networks may provide a Unidirectional Broadcast Link (UDL), with no return path. Such links may be used for unicast applications that do not require a return path (e.g., based on UDP), but commonly are used for IP multicast content distribution.
MPEG-2网络可提供无返回路径的单向广播链路（UDL）。此类链路可用于不需要返回路径（例如，基于UDP）但通常用于IP多播内容分发的单播应用程序。
/-----\
MPEG-2 Uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider + v MPEG-2 Downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
/-----\
MPEG-2 Uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider + v MPEG-2 Downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
Figure 3: Unidirectional connectivity
图3：单向连接
The ARP and ND protocols require bidirectional L2/L3 connectivity. They do not provide an appropriate method to resolve the remote (destination) address in a unidirectional environment.
ARP和ND协议需要双向L2/L3连接。它们没有提供在单向环境中解析远程（目标）地址的适当方法。
Unidirectional links therefore require a separate out-of-band configuration method to establish the appropriate AR information at the Encapsulator and Receivers. ULE [RFC4326] defines a mode in which the MAC/NPA address is omitted from the SNDU. In some scenarios, this may relieve an Encapsulator of the need for L2 AR.
因此，单向链路需要单独的带外配置方法，以在封装器和接收器处建立适当的AR信息。ULE[RFC4326]定义了一种模式，在该模式下，从SNDU中省略MAC/NPA地址。在某些情况下，这可能会减轻封装器对L2 AR的需求。
Bidirectional connectivity may be realized using a unidirectional link in combination with another network path. Common combinations are a Feed link using MPEG-2 satellite transmission and a return link using terrestrial network infrastructure. This topology is often known as a Hybrid network and has asymmetric network routing.
可使用单向链路结合另一网络路径来实现双向连接。常见的组合是使用MPEG-2卫星传输的馈送链路和使用地面网络基础设施的返回链路。这种拓扑结构通常被称为混合网络，具有不对称的网络路由。
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
Figure 4: Bidirectional connectivity
图4：双向连接
The Unidirectional Link Routing (UDLR) [RFC3077] protocol may be used to overcome issues associated with asymmetric routing. The Dynamic Tunnel Configuration Protocol (DTCP) enables automatic configuration of the return path. UDLR hides the unidirectional routing from the IP and upper layer protocols by providing a L2 tunnelling mechanism that emulates a bidirectional broadcast link at L2. A network using UDLR has a topology where a Feed Router and all Receivers form a logical Local Area Network. Encapsulating L2 frames allows them to be sent through an Internet Path (i.e., bridging).
单向链路路由（UDLR）[RFC3077]协议可用于克服与非对称路由相关的问题。动态隧道配置协议（DTCP）允许自动配置返回路径。UDLR通过提供模拟L2上双向广播链路的L2隧道机制，对IP和上层协议隐藏单向路由。使用UDLR的网络具有一个拓扑结构，其中一个馈送路由器和所有接收器构成一个逻辑局域网。封装L2帧允许通过Internet路径（即桥接）发送它们。
Since many unidirectional links employ wireless technology for the forward (Feed) link, there may be an appreciable cost associated with forwarding traffic on the Feed link. Therefore, it is often desirable to prevent forwarding unnecessary traffic (e.g., for multicast this implies control of which groups are forwarded). The implications of forwarding in the return direction must also be considered (e.g., asymmetric capacity and loss [RFC3449]). This suggests a need to minimize the volume and frequency of control messages.
由于许多单向链路对前向（馈送）链路采用无线技术，因此可能存在与在馈送链路上转发业务相关联的可观成本。因此，通常需要防止转发不必要的流量（例如，对于多播，这意味着控制转发哪些组）。还必须考虑返回方向转发的影响（例如，不对称容量和损失[RFC3449]）。这表明需要最小化控制消息的数量和频率。
Three different AR cases may be identified (each considers sending an IP packet to a next-hop IP address that is not currently cached by the sender):
可以识别三种不同的AR情况（每种情况都考虑将IP数据包发送到发送方当前未缓存的下一跳IP地址）：
(i) A Feed Router needs a Receiver MAC/NPA address.
(i) 馈送路由器需要一个接收器MAC/NPA地址。
This occurs when a Feed Router sends an IP packet using the Feed UDL to a Receiver whose MAC/NPA address is unknown. In IPv4, the Feed Router sends an ARP REQUEST with the IP address of the Receiver. The Receiver that recognizes its IP address replies with an ARP RESPONSE to the MAC/NPA address of the Feed Router (e.g., using a UDLR tunnel). The Feed Router may then address IP packets to the unicast MAC/NPA address associated with the Receiver. The ULE encapsulation format also permits packets to be sent without specifying a MAC/NPA address, where this is desirable (Section 6.1 and 6.5).
当Feed路由器使用Feed UDL向MAC/NPA地址未知的接收器发送IP包时，就会发生这种情况。在IPv4中，馈送路由器发送带有接收器IP地址的ARP请求。识别其IP地址的接收器用ARP响应回复馈送路由器的MAC/NPA地址（例如，使用UDLR隧道）。然后，馈送路由器可将IP分组寻址到与接收器相关联的单播MAC/NPA地址。ULE封装格式还允许在不指定MAC/NPA地址的情况下发送数据包，这是需要的（第6.1和6.5节）。
(ii) A Receiver needs the Feed Router MAC/NPA address.
（ii）接收器需要馈送路由器MAC/NPA地址。
This occurs when a Receiver sends an IP packet to a Feed Router whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the Feed Router (e.g., using a UDLR tunnel). The Feed Router replies with an ARP RESPONSE using the Feed UDL. The Receiver may then address IP packets to the MAC/NPA address of the recipient.
当接收器向MAC/NPA地址未知的馈送路由器发送IP数据包时，就会发生这种情况。在IPv4中，接收方发送一个带有馈送路由器IP地址的ARP请求（例如，使用UDLR隧道）。Feed路由器使用Feed UDL以ARP响应进行响应。然后，接收机可以将IP分组寻址到接收机的MAC/NPA地址。
(iii) A Receiver needs another Receiver MAC/NPA address.
（iii）接收器需要另一个接收器MAC/NPA地址。
This occurs when a Receiver sends an IP packet to another Receiver whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the remote Receiver (e.g., using a UDLR tunnel to the Feed Router). The request is forwarded over the Feed UDL. The target Receiver replies with an ARP RESPONSE (e.g., using a UDLR tunnel). The Feed Router forwards the response on the UDL. The Receiver may then address IP packets to the MAC/NPA address of the recipient.
当一个接收器向另一个MAC/NPA地址未知的接收器发送IP数据包时，就会发生这种情况。在IPv4中，接收器发送带有远程接收器IP地址的ARP请求（例如，使用UDLR隧道到馈送路由器）。请求通过提要UDL转发。目标接收器以ARP响应进行响应（例如，使用UDLR隧道）。馈送路由器在UDL上转发响应。然后，接收机可以将IP分组寻址到接收机的MAC/NPA地址。
These 3 cases allow any system connected to the UDL to obtain the MAC/NPA address of any other system. Similar exchanges may be performed using the ND protocol for IPv6.
这3种情况允许连接到UDL的任何系统获得任何其他系统的MAC/NPA地址。可以使用IPv6的ND协议执行类似的交换。
A long round trip delay (via the UDL and UDLR tunnel) impacts the performance of the reactive address resolution procedures provided by ARP, ND, and SEND. In contrast to Ethernet, during the interval when resolution is taking place, many IP packets may be received that are addressed to the AR Target address. The ARP specification allows an interface to discard these packets while awaiting the response to the resolution request. An appropriately sized buffer would however prevent this loss.
长的往返延迟（通过UDL和UDLR隧道）会影响ARP、ND和SEND提供的反应式地址解析过程的性能。与以太网相反，在解析发生的间隔期间，可能会接收到许多IP数据包，这些数据包被寻址到AR目标地址。ARP规范允许接口在等待对解析请求的响应时丢弃这些数据包。但是，适当大小的缓冲区可以防止这种丢失。
In case (iii), the time to complete address resolution may be reduced by the use of an AR Server at the Feed (Section 5.4).
在第（iii）种情况下，通过在提要上使用AR服务器，可以缩短完成地址解析的时间（第5.4节）。
Using DHCP requires prior establishment of the L2 connectivity to a DHCP Server. The delay in establishing return connectivity in UDLR networks that use DHCP, may make it beneficial to increase the frequency of the DTCP HELLO message. Further information about tuning DHCP is provided in Section 5.5.
使用DHCP需要事先建立到DHCP服务器的L2连接。在使用DHCP的UDLR网络中建立返回连接的延迟可能有助于增加DTCP HELLO消息的频率。第5.5节提供了有关调整DHCP的更多信息。
Bidirectional IP networks can be and are constructed by a combination of two MPEG-2 transmission links. One link is usually a broadcast link that feeds a set of remote Receivers. Links are also provided from Receivers so that the combined link functions as a full duplex interface. Examples of this use include two-way DVB-S satellite links and the DVB-RCS system.
双向IP网络可以并且由两个MPEG-2传输链路的组合构成。一个链路通常是为一组远程接收器提供信息的广播链路。还提供来自接收器的链路，以便组合链路用作全双工接口。这种使用的示例包括双向DVB-S卫星链路和DVB-RCS系统。
An AR Server can be used to distribute AR information to Receivers in an MPEG-2 Network. In some topologies, this may significantly reduce the time taken for Receivers to discover AR information.
AR服务器可用于向MPEG-2网络中的接收器分发AR信息。在某些拓扑中，这可以显著减少接收器发现AR信息所花费的时间。
The AR Server can operate as a proxy responding on behalf of Receivers to received AR requests. When an IPv4 AR request is received (e.g., Receiver ARP REQUEST), an AR Server responds by (proxy) sending an AR response, providing the appropriate IP to MAC/NPA binding (mapping the IP address to the L2 address).
AR服务器可以作为代理，代表接收者响应接收到的AR请求。当接收到IPv4 AR请求（例如，接收器ARP请求）时，AR服务器通过（代理）发送AR响应进行响应，提供适当的IP到MAC/NPA绑定（将IP地址映射到L2地址）。
Information may also be sent unsolicited by the AR Server using multicast/broadcast to update the ARP/neighbor cache at the Receivers without the need for explicit requests. The unsolicited method can improve scaling in large networks. Scaling could be further improved by distributing a single broadcast/multicast AR message that binds multiple IP and MAC/NPA addresses. This reduces the network capacity consumed and simplifies client/server processing in networks with large numbers of clients.
AR服务器还可以使用多播/广播来主动发送信息，以更新接收机处的ARP/邻居缓存，而无需显式请求。非请求方法可以提高大型网络中的可伸缩性。通过分发绑定多个IP和MAC/NPA地址的单个广播/多播AR消息，可以进一步改进扩展。这降低了所消耗的网络容量，并简化了具有大量客户端的网络中的客户端/服务器处理。
An AR Server can be implemented using IETF-defined Protocols by configuring the subnetwork so that AR Requests from Receivers are intercepted rather than forwarded to the Feed/broadcast link. The intercepted messages are sent to an AR Server. The AR Server maintains a set of MAC/NPA address bindings. These may be configured or may learned by monitoring ARP messages sent by Receivers. Currently defined IETF protocols only allow one binding per message (i.e., there is no optimization to conserve L2 bandwidth).
AR服务器可以通过配置子网，使用IETF定义的协议来实现，从而拦截来自接收器的AR请求，而不是转发到提要/广播链路。截获的消息被发送到AR服务器。AR服务器维护一组MAC/NPA地址绑定。这些可以通过监视接收器发送的ARP消息来配置或学习。当前定义的IETF协议只允许每条消息有一个绑定（即，没有优化以节省L2带宽）。
Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [RFC4389]. To perform an AR Server function, the AR information must also be cached. A caching AR proxy stores the system state within a middle-box device. This resembles a classic man-in-the-middle security attack; interactions with SEND are described in [SP-ND].
等效方法可以提供IPv6 AR。拦截ND消息的过程在[RFC4389]中定义。要执行AR服务器功能，还必须缓存AR信息。缓存AR代理将系统状态存储在中间盒设备中。这类似于典型的中间人安全攻击；[SP-ND]中描述了与SEND的交互。
Methods are needed to purge stale AR data from the cache. The consistency of the cache must also be considered when the Receiver bindings can change (e.g., IP mobility, network topology changes, or intermittent Receiver connectivity). In these cases, the use of old (stale) information can result in IP packets being directed to an inappropriate L2 address, with consequent packet loss.
需要使用方法从缓存中清除过时的AR数据。当接收器绑定可能发生变化时（例如，IP移动性、网络拓扑变化或间歇性接收器连接），还必须考虑缓存的一致性。在这些情况下，使用旧（过时）信息可能导致IP数据包被定向到不适当的L2地址，从而导致数据包丢失。
Current IETF-defined methods provide bindings of IP addresses to MAC/NPA, but do not allow the bindings to other L2 information pertinent to MPEG-2 Networks, requiring the use of other methods for
当前IETF定义的方法提供了到MAC/NPA的IP地址绑定，但不允许绑定到与MPEG-2网络相关的其他L2信息，这需要使用其他方法来实现
this function (Section 4). AR Servers can also be implemented using non-IETF AR protocols to provide the AR information required by Receivers.
此功能（第4节）。AR服务器也可以使用非IETF AR协议来实现，以提供接收机所需的AR信息。
DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 Networks with bidirectional connectivity. DHCP consists of two components: a protocol for delivering system-specific configuration parameters from a DHCP Server to a DHCP Client (e.g., default router, DNS server) and a mechanism for the allocation of network addresses to systems.
DHCP[RFC2131]和DHCPv6[RFC3315]可在具有双向连接的MPEG-2网络上使用。DHCP由两个组件组成：用于将特定于系统的配置参数从DHCP服务器传送到DHCP客户端（例如，默认路由器、DNS服务器）的协议和用于向系统分配网络地址的机制。
The configuration of DHCP Servers and DHCP Clients should take into account the local link round trip delay (possibly including the additional delay from bridging, e.g., using UDLR). A large number of clients can make it desirable to tune the DHCP lease duration and the size of the address pool. Appropriate timer values should also be selected: the DHCP messages retransmission timeout, and the maximum delay that a DHCP Server waits before deciding that the absence of an ICMP echo response indicates that the relevant address is free.
DHCP服务器和DHCP客户端的配置应考虑本地链路往返延迟（可能包括桥接的额外延迟，例如使用UDLR）。大量的客户机可能需要调整DHCP租约持续时间和地址池的大小。还应选择适当的计时器值：DHCP消息重新传输超时，以及DHCP服务器在确定没有ICMP回显响应表示相关地址空闲之前等待的最大延迟。
DHCP Clients may retransmit DHCP messages if they do not receive a response. Some client implementations specify a timeout for the DHCPDISCOVER message that is small (e.g., suited to Ethernet delay, rather than appropriate to an MPEG-2 Network) providing insufficient time for a DHCP Server to respond to a DHCPDISCOVER retransmission before expiry of the check on the lease availability (by an ICMP Echo Request), resulting in potential address conflict. This value may need to be tuned for MPEG-2 Networks.
DHCP客户端如果没有收到响应，可能会重新传输DHCP消息。一些客户端实现为DHCPDISCOVER消息指定了一个很小的超时（例如，适合以太网延迟，而不适合MPEG-2网络），使得DHCP服务器在租约可用性检查（通过ICMP回送请求）到期之前没有足够的时间响应DHCPDISCOVER重传，导致潜在的地址冲突。对于MPEG-2网络，可能需要调整此值。
Section 3.2 describes the multicast address resolution requirements. This section describes L3 address bindings when the destination network-layer address is an IP multicast Group Destination Address.
第3.2节描述了多播地址解析要求。本节介绍目标网络层地址为IP多播组目标地址时的L3地址绑定。
In MPE [ETSI-DAT], a mapping is specified for the MAC Address based on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464]. (A variant of DVB (DVB-H) uses a modified MAC header [ETSI-DAT]).
在MPE[ETSI-DAT]中，根据IPv4[RFC1112]和IPv6[RFC2464]的IP多播地址为MAC地址指定映射。（DVB（DVB-H）的变体使用修改的MAC报头[ETSI-DAT]）。
In ULE [RFC4326], the L2 NPA address is optional, and is not necessarily required when the Receiver is able to perform efficient L3 multicast address filtering. When present, a mapping is defined based on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464].
在ULE[RFC4326]中，L2 NPA地址是可选的，并且在接收器能够执行有效的L3多播地址过滤时不一定需要。存在时，将根据IPv4[RFC1112]和IPv6[RFC2464]的IP多播地址定义映射。
The L2 group addressing method specified in [RFC1112] and [RFC2464] can result in more than one IP destination address being mapped to the same L2 address. In Source-Specific Multicast, SSM [RFC3569], multicast groups are identified by the combination of the IP source and IP destination addresses. Therefore, senders may independently select an IP group destination address that could map to the same L2 address if forwarded onto the same L2 link. The resulting addressing overlap at L2 can increase the volume of traffic forwarded to L3, where it then needs to be filtered.
[RFC1112]和[RFC2464]中指定的二级组寻址方法可能导致多个IP目标地址映射到同一二级地址。在源特定多播SSM[RFC3569]中，多播组由IP源地址和IP目标地址的组合来标识。因此，发送方可以独立地选择IP组目标地址，如果转发到相同的L2链路上，该地址可以映射到相同的L2地址。在L2产生的寻址重叠会增加转发到L3的流量，然后需要在L3进行过滤。
These considerations are the same as for Ethernet LANs, and may not be of concern to Receivers that can perform efficient L3 filtering. Section 3 noted that an MPEG-2 Network may need to support multiple addressing scopes at the network and link layers. Separation of the different groups into different Transport Streams is one remedy (with signalling of IP to PID value mappings). Another approach is to employ alternate MAC/NPA mappings to those defined in [RFC1112] and [RFC2464], but such mappings need to be consistently bound at the Encapsulator and Receiver, using AR procedures in a scalable manner.
这些注意事项与以太网LAN的注意事项相同，对于能够执行有效的L3过滤的接收器来说可能不太重要。第3节指出，MPEG-2网络可能需要在网络层和链路层支持多个寻址范围。将不同的组分离为不同的传输流是一种补救方法（通过IP到PID值映射的信令）。另一种方法是采用替代MAC/NPA映射到[RFC1112]和[RFC2464]中定义的MAC/NPA映射，但此类映射需要以可扩展的方式使用AR过程在封装器和接收器处一致绑定。
UDLR is a Layer 2 solution, in which a Receiver may send multicast/broadcast frames that are subsequently forwarded natively by a Feed Router (using the topology in Figure 2), and are finally received at the Feed interface of the originating Receiver. This multicast forwarding does not include the normal L3 Reverse Path Forwarding (RPF) check or L2 spanning tree checks, the processing of the IP Time To Live (TTL) field or the filtering of administratively scoped multicast addresses. This raises a need to carefully consider multicast support. To avoid forwarding loops, RFC 3077 notes that a Receiver needs to be configured with appropriate filter rules to ensure that it discards packets that originate from an attached network and are later received over the Feed link.
UDLR是一种第2层解决方案，在该解决方案中，接收器可以发送多播/广播帧，这些帧随后由馈送路由器（使用图2中的拓扑）本地转发，并最终在发起接收器的馈送接口处接收。此多播转发不包括正常的L3反向路径转发（RPF）检查或L2生成树检查、IP生存时间（TTL）字段的处理或管理范围多播地址的过滤。这就需要仔细考虑多播支持。为了避免转发循环，RFC 3077注意到接收机需要配置适当的过滤规则，以确保其丢弃源自连接网络且随后通过馈送链路接收的数据包。
When the encapsulation includes an MAC/NPA source address, re-broadcast packets may be filtered at the link layer using a filter that discards L2 addresses that are local to the Receiver. In some circumstances, systems can send packets with an unknown (all-zero) MAC source address (e.g., IGMP Proxy Queriers [RFC4605]), where the source at L2 can not be determined at the Receiver. These packets need to be silently discarded, which may prevent running the associated services on the Receiver.
当封装包括MAC/NPA源地址时，可以使用丢弃接收机本地的L2地址的过滤器在链路层过滤重新广播分组。在某些情况下，系统可以发送具有未知（全零）MAC源地址（例如，IGMP代理查询器[RFC4605]）的数据包，其中L2处的源在接收器处无法确定。需要悄悄地丢弃这些数据包，这可能会阻止在接收器上运行相关服务。
Some encapsulation formats also do not include an MAC/NPA source address (Table 1). Multicast packets may therefore alternatively be discarded at the IP layer if their IP source address matches a local IP address (or address range). Systems can send packets with an
一些封装格式也不包括MAC/NPA源地址（表1）。因此，如果多播数据包的IP源地址与本地IP地址（或地址范围）匹配，则可以在IP层丢弃多播数据包。系统可以使用
all-zero IP source address (e.g., BOOTP (bootstrap protocol) [RFC951], DHCP [RFC2131] and ND [RFC2461]), where the source at L3 can not be determined at the Receiver these packets need to be silently discarded. This may prevent running the associated services at a Receiver, e.g., participation in IPv6 Duplicate Address Detection or running a DHCP server.
所有零IP源地址（例如BOOTP（引导协议）[RFC951]、DHCP[RFC2131]和ND[RFC2461]），其中L3处的源无法在接收器处确定。这些数据包需要被静默丢弃。这可能会阻止在接收器上运行相关服务，例如，参与IPv6重复地址检测或运行DHCP服务器。
This section considers link layer (L2) support for address resolution in MPEG-2 Networks. It considers two issues: The code-point used at L2 and the efficiency of encapsulation for transmission required to support the AR method. The table below summarizes the options for both MPE ([ETSI-DAT], [ATSC-A90]) and ULE [RFC4326] encapsulations.
本节讨论MPEG-2网络中对地址解析的链路层（L2）支持。它考虑了两个问题：L2使用的代码点和支持AR方法所需的传输封装效率。下表总结了MPE（[ETSI-DAT]、[ATSC-A90]）和ULE[RFC4326]封装的选项。
[RFC4840] describes issues and concerns that may arise when a link can support multiple encapsulations. In particular, it identifies problems that arise when end hosts that belong to the same IP network employ different incompatible encapsulation methods. An Encapsulator must therefore use only one method (e.g., ULE or MPE) to support a single IP network (i.e., set of IPv4 systems sharing the same subnet broadcast address or same IPv6 prefix). All Receivers in an IP network must receive all IP packets that use a broadcast (directed to all systems in the IP network) or a local-scope multicast address (Section 3). Packets with these addresses are used by many IP-based protocols including service discovery, IP AR, and routing protocols. Systems that fail to receive these packets can suffer connectivity failure or incorrect behaviour (e.g., they may be unable to participate in IP-based discovery, configuration, routing, and announcement protocols). Consistent delivery can be ensured by transmitting link-local multicast or broadcast packets using the same Stream that is used for unicast packets directed to this network. A Receiver could simultaneously use more than one L2 AR mechanism. This presents a potential conflict when the Receiver receives two different bindings for the same identifier. When multiple systems advertise AR bindings for the same identifiers (e.g., Encapsulators), they must ensure that the advertised information is consistent. Conflicts may also arise when L2 protocols duplicate the functions of IP-based AR mechanisms.
[RFC4840]描述了当链路支持多个封装时可能出现的问题和担忧。特别是，它确定了当属于同一IP网络的终端主机采用不同的不兼容封装方法时出现的问题。因此，封装器必须仅使用一种方法（例如，ULE或MPE）来支持单个IP网络（即，共享相同子网广播地址或相同IPv6前缀的一组IPv4系统）。IP网络中的所有接收器必须接收使用广播（指向IP网络中的所有系统）或本地范围多播地址（第3节）的所有IP数据包。具有这些地址的数据包被许多基于IP的协议使用，包括服务发现、IP AR和路由协议。无法接收这些数据包的系统可能会出现连接故障或错误行为（例如，它们可能无法参与基于IP的发现、配置、路由和公告协议）。通过使用用于定向到此网络的单播数据包的相同流传输链路本地多播或广播数据包，可以确保一致的传输。接收机可以同时使用多个L2 AR机制。当接收者接收到同一标识符的两个不同绑定时，这就产生了潜在的冲突。当多个系统为相同的标识符（例如，封装器）发布AR绑定时，它们必须确保发布的信息是一致的。当L2协议重复基于IP的AR机制的功能时，也可能出现冲突。
In ULE, the bridging format may be used in combination with the normal mode to address packets to a Receiver (all ULE Receivers are required to implement both methods). Frames carrying IP packets using the ULE Bridging mode, that have a destination address corresponding to the MAC address of the Receiver and have an IP address corresponding to a Receiver interface, will be delivered to the IP stack of the Receiver. All bridged IP multicast and broadcast frames will also be copied to the IP stack of the Receiver.
在ULE中，桥接格式可与正常模式结合使用，以向接收机寻址分组（所有ULE接收机都需要实现这两种方法）。使用ULE桥接模式承载IP分组的帧，其具有对应于接收机的MAC地址的目的地地址并且具有对应于接收机接口的IP地址，将被传送到接收机的IP堆栈。所有桥接IP多播和广播帧也将复制到接收器的IP堆栈。
Receivers must filter (discard) frames that are received with a source address that matches an address of the Receiver itself [802.1D]. It must also prevent forwarding frames already sent on a connected network. For each network interface, it must therefore filter received frames where the frame source address matches a unicast destination address associated with a different network interface [802.1D].
接收器必须过滤（丢弃）使用与接收器自身地址匹配的源地址接收的帧[802.1D]。它还必须防止转发已连接网络上发送的帧。因此，对于每个网络接口，它必须过滤接收到的帧，其中帧源地址匹配与不同网络接口相关联的单播目标地址[802.1D]。
+-------------------------------+--------+----------------------+
| | PDU |L2 Frame Header Fields|
| L2 Encapsulation |overhead+----------------------+
| |[bytes] |src mac|dst mac| type |
+-------------------------------+--------+-------+-------+------+
|6.1 ULE without dst MAC address| 8 | - | - | x |
|6.2 ULE with dst MAC address | 14 | - | x | x |
|6.3 MPE without LLC/SNAP | 16 | - | x | - |
|6.4 MPE with LLC/SNAP | 24 | - | x | x |
|6.5 ULE with Bridging extension| 22 | x | x | x |
|6.6 ULE with Bridging & NPA | 28 | x | x | x |
|6.7 MPE with LLC/SNAP&Bridging | 38 | x | x | x |
+-------------------------------+--------+-------+-------+------+
+-------------------------------+--------+----------------------+
| | PDU |L2 Frame Header Fields|
| L2 Encapsulation |overhead+----------------------+
| |[bytes] |src mac|dst mac| type |
+-------------------------------+--------+-------+-------+------+
|6.1 ULE without dst MAC address| 8 | - | - | x |
|6.2 ULE with dst MAC address | 14 | - | x | x |
|6.3 MPE without LLC/SNAP | 16 | - | x | - |
|6.4 MPE with LLC/SNAP | 24 | - | x | x |
|6.5 ULE with Bridging extension| 22 | x | x | x |
|6.6 ULE with Bridging & NPA | 28 | x | x | x |
|6.7 MPE with LLC/SNAP&Bridging | 38 | x | x | x |
+-------------------------------+--------+-------+-------+------+
Table 1: L2 Support and Overhead (x =supported, - =not supported)
Table 1: L2 Support and Overhead (x =supported, - =not supported)
The remainder of the section describes IETF-specified AR methods for use with these encapsulation formats. Most of these methods rely on bidirectional communications (see Sections 5.1, 5.2, and 5.3 for a discussion of this).
本节的其余部分描述了IETF指定的AR方法，用于这些封装格式。这些方法大多依赖于双向通信（关于这一点的讨论，见第5.1、5.2和5.3节）。
The ULE encapsulation supports a mode (D=1) where the MAC/NPA address is not present in the encapsulated frame. This mode may be used with both IPv4 and IPv6. When used, the Receiver is expected to perform L3 filtering of packets based on their IP destination address [RFC4326]. This requires careful consideration of the network topology when a Receiver is an IP router, or delivers data to an IP router (a simple case where this is permitted arises in the connection of stub networks at a Receiver that have no connectivity to other networks). Since there is no MAC/NPA address in the SNDU, ARP and the ND protocol are not required for AR.
ULE封装支持一种模式（D=1），其中MAC/NPA地址不存在于封装的帧中。此模式可用于IPv4和IPv6。当使用时，预期接收器根据其IP目的地地址[RFC4326]对数据包执行L3过滤。当接收器是IP路由器或向IP路由器传送数据时，这需要仔细考虑网络拓扑（在一个简单的情况下，允许在接收器处连接与其他网络没有连接的存根网络时出现这种情况）。由于SNDU中没有MAC/NPA地址，AR不需要ARP和ND协议。
IPv6 systems can automatically configure their IPv6 network address based upon a local MAC address [RFC2462]. To use auto-configuration, the IP driver at the Receiver may need to access the MAC/NPA address of the receiving interface, even though this value is not being used to filter received SNDUs.
IPv6系统可以基于本地MAC地址自动配置其IPv6网络地址[RFC2462]。要使用自动配置，接收器处的IP驱动程序可能需要访问接收接口的MAC/NPA地址，即使该值未用于过滤接收到的SNDU。
Even when not used for AR, the ND protocol may still be required to support DAD, and other IPv6 network-layer functions. This protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
即使不用于AR，也可能需要ND协议来支持DAD和其他IPv6网络层功能。该协议使用一组IPv6多播地址，这些地址需要由L2网络承载。然而，由于这种封装格式不提供MAC源地址，因此存在这样的拓扑（例如，第5.6.1节），系统无法区分最初由自身发送并重新广播的DAD数据包与可能由具有相同L3地址的另一系统发送的DAD数据包。因此，在可能发生L2转发的拓扑中，DAD不能与此封装格式一起使用。
The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by an IEEE EtherType and may be used over ULE [RFC4326]. Although no MAC source address is present in the ULE SNDU, the ARP protocol still communicates the source MAC (hardware) address in the ARP record payload of any query messages that it generates.
IPv4地址解析协议（ARP）[RFC826]由IEEE EtherType标识，可通过ULE[RFC4326]使用。尽管ULE SNDU中不存在MAC源地址，但ARP协议仍在其生成的任何查询消息的ARP记录有效负载中通信源MAC（硬件）地址。
The IPv6 ND protocol is supported. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
支持IPv6 ND协议。该协议使用一组IPv6多播地址，这些地址需要由L2网络承载。该协议使用一组IPv6多播地址，这些地址需要由L2网络承载。然而，由于这种封装格式不提供MAC源地址，因此存在这样的拓扑（例如，第5.6.1节），系统无法区分最初由自身发送并重新广播的DAD数据包与可能由具有相同L3地址的另一系统发送的DAD数据包。因此，在可能发生L2转发的拓扑中，DAD不能与此封装格式一起使用。
This is the default (and sometimes only) mode specified by most MPE Encapsulators. MPE does not provide an EtherType field and therefore can not support the Address Resolution Protocol (ARP) [RFC826].
这是大多数MPE封装器指定的默认（有时是唯一）模式。MPE不提供EtherType字段，因此无法支持地址解析协议（ARP）[RFC826]。
IPv6 is not supported in this encapsulation format, and therefore it is not appropriate to consider the ND protocol.
在这种封装格式中不支持IPv6，因此考虑ND协议是不合适的。
The LLC/SNAP (Sub-Network Access Protocol) format of MPE provides an EtherType field and therefore may support ARP [RFC826]. There is no specification to define how this is performed. No MAC source address is present in the SNDU, although the protocol communicates the source MAC address in the ARP record payload of any query messages that it generates.
MPE的LLC/SNAP（子网访问协议）格式提供了一个EtherType字段，因此可以支持ARP[RFC826]。没有规定如何执行此操作。SNDU中不存在MAC源地址，尽管协议在其生成的任何查询消息的ARP记录有效负载中传递源MAC地址。
The IPv6 ND protocol is supported using The LLC/SNAP format of MPE. This requires specific multicast addresses to be carried by the L2 network. The IPv6 ND protocol is supported. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
使用MPE的LLC/SNAP格式支持IPv6 ND协议。这需要L2网络承载特定的多播地址。支持IPv6 ND协议。该协议使用一组IPv6多播地址，这些地址需要由L2网络承载。然而，由于这种封装格式不提供MAC源地址，因此存在这样的拓扑（例如，第5.6.1节），系统无法区分最初由自身发送并重新广播的DAD数据包与可能由具有相同L3地址的另一系统发送的DAD数据包。因此，在可能发生L2转发的拓扑中，DAD不能与此封装格式一起使用。
The ULE encapsulation supports a bridging extension header that supplies both a source and destination MAC address. This can be used without an NPA address (D=1). When no other Extension Headers precede this Extension, the MAC destination address has the same position in the ULE SNDU as that used for an NPA destination address. The Receiver may optionally be configured so that the MAC destination address value is identical to a Receiver NPA address.
ULE封装支持同时提供源和目标MAC地址的桥接扩展头。这可以在没有NPA地址（D=1）的情况下使用。当此扩展之前没有其他扩展头时，MAC目标地址在ULE SNDU中的位置与用于NPA目标地址的位置相同。接收机可以可选地被配置为使得MAC目的地地址值与接收机NPA地址相同。
At the Encapsulator, the ULE MAC/NPA destination address is determined by a L2 forwarding decision. Received frames may be forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. Where the topology may result in subsequent reception of re-broadcast copies of multicast frames that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
在封装器处，ULE MAC/NPA目的地地址由L2转发决定确定。接收到的帧可以被转发或者可以被寻址到接收机本身。与在其他L2 LAN中一样，接收器可以选择基于配置的MAC目的地地址过滤器过滤接收到的帧。ARP和ND消息可以在通过这种封装格式桥接的PDU中传输。如果拓扑可能导致随后接收最初由接收器发送的多播帧的重新广播副本（例如，第5.6.1节），则系统必须丢弃其在从同一接口发送的帧中使用的源地址接收的帧[802.1D]。这可防止桥接网络上的重复（例如，否则将调用DAD）。
The combination of an NPA address (D=0) and a bridging extension header are allowed in ULE. This SNDU format supplies both a source and destination MAC address and a NPA destination address (i.e., Receiver MAC/NPA address).
ULE中允许NPA地址（D=0）和桥接扩展标头的组合。此SNDU格式提供源和目标MAC地址以及NPA目标地址（即，接收器MAC/NPA地址）。
At the Encapsulator, the value of the ULE MAC/NPA destination address is determined by a L2 forwarding decision. At the Receiver, frames may be forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this
在封装器处，ULE MAC/NPA目的地地址的值由L2转发决定确定。在接收机处，帧可以被转发或被寻址到接收机本身。与在其他L2 LAN中一样，接收器可以选择基于配置的MAC目的地地址过滤器过滤接收到的帧。ARP和ND消息可以在通过该协议桥接的PDU内传送
encapsulation format. Where the topology may result in the subsequent reception of re-broadcast copies of multicast frames, that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
封装格式。如果拓扑可能导致随后接收最初由接收器发送的多播帧的重新广播副本（例如，第5.6.1节），则系统必须丢弃其在从同一接口发送的帧中使用的源地址接收的帧[802.1D]。这可防止桥接网络上的重复（例如，否则将调用DAD）。
The LLC/SNAP format MPE frames may optionally support an IEEE bridging header [LLC]. This header supplies both a source and destination MAC address, at the expense of larger encapsulation overhead. The format defines two MAC destination addresses, one associated with the MPE SNDU (i.e., Receiver MAC address) and one with the bridged MAC frame (i.e., the MAC address of the intended recipient in the remote LAN).
LLC/SNAP格式MPE帧可以可选地支持IEEE桥接报头[LLC]。该报头同时提供源MAC地址和目标MAC地址，但以更大的封装开销为代价。该格式定义了两个MAC目的地地址，一个与MPE SNDU（即，接收器MAC地址）关联，另一个与桥接MAC帧（即，远程LAN中预期接收器的MAC地址）关联。
At the Encapsulator, the MPE MAC destination address is determined by a L2 forwarding decision. There is currently no formal description of the Receiver processing for this encapsulation format. A Receiver may forward frames or they may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. The MPE MAC destination address is determined by a L2 forwarding decision. Where the topology may result in a subsequent reception of re-broadcast copies of multicast frames, that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
在封装器处，MPE MAC目的地地址由L2转发决定确定。目前没有关于这种封装格式的接收器处理的正式描述。接收机可以转发帧，也可以将帧寻址到接收机本身。与在其他L2 LAN中一样，接收器可以选择基于配置的MAC目的地地址过滤器过滤接收到的帧。ARP和ND消息可以在通过这种封装格式桥接的PDU中传输。MPE MAC目的地地址由L2转发决定确定。如果拓扑可能导致随后接收最初由接收器发送的多播帧的重新广播副本（例如，第5.6.1节），则系统必须丢弃其在从同一接口发送的帧中使用的源地址接收的帧[802.1D]。这可防止桥接网络上的重复（例如，否则将调用DAD）。
This document describes addressing and address resolution issues for IP protocols over MPEG-2 transmission networks using both wired and wireless technologies. A number of specific IETF protocols are discussed along with their expected behaviour over MPEG-2 transmission networks. Recommendations for their usage are provided.
本文档描述了使用有线和无线技术通过MPEG-2传输网络的IP协议的寻址和地址解析问题。讨论了一些特定的IETF协议及其在MPEG-2传输网络上的预期行为。提供了使用它们的建议。
There is no single common approach used in all MPEG-2 Networks. A static binding may be configured for IP addresses and PIDs (as in some cable networks). In broadcast networks, this information is normally provided by the Encapsulator/Multiplexor and carried in signalling tables (e.g., AIT in MHP, the IP Notification Table, INT,
在所有的MPEG-2网络中没有使用单一的通用方法。可以为IP地址和PID配置静态绑定（如在某些有线网络中）。在广播网络中，该信息通常由封装器/多路复用器提供，并在信令表（例如，MHP中的AIT、IP通知表、INT、，
of DVB and the DVB-RCS Multicast Mapping Table, and MMT). This document has reviewed the status of these current address resolution mechanisms in MPEG-2 transmission networks and defined their usage.
DVB和DVB-RCS多播映射表以及MMT）。本文档回顾了MPEG-2传输网络中这些当前地址解析机制的现状，并定义了它们的用法。
The document also considers a unified IP-based method for AR that could be independent of the physical layer, but does not define a new protocol. It examines the design criteria for a method, with recommendations to ensure scalability and improve support for the IP protocol stack.
该文件还考虑了一种基于IP的AR统一方法，该方法可以独立于物理层，但没有定义新的协议。它检查了方法的设计标准，并提出了确保可伸缩性和改进对IP协议栈的支持的建议。
The normal security issues relating to the use of wireless links for transmission of Internet traffic should be considered.
应考虑与使用无线链路传输互联网流量有关的正常安全问题。
L2 signalling in MPEG-2 transmission networks is currently provided by (periodic) broadcasting of information in the control plane using PSI/SI tables (Section 4). A loss or modification of the SI information may result in an inability to identify the TS Logical Channel (PID) that is used for a service. This will prevent reception of the intended IP packet stream.
MPEG-2传输网络中的L2信令目前通过使用PSI/SI表在控制平面中（定期）广播信息来提供（第4节）。SI信息的丢失或修改可能导致无法识别用于服务的TS逻辑信道（PID）。这将阻止接收预期的IP分组流。
There are known security issues relating to the use of unsecured address resolution [RFC3756]. Readers are also referred to the known security issues when mapping IP addresses to MAC/NPA addresses using ARP [RFC826] and ND [RFC2461]. It is recommended that AR protocols support authentication of the source of AR messages and the integrity of the AR information, this avoids known security vulnerabilities resulting from insertion of unauthorized AR messages within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] may be used in place of ND. This defines security mechanisms that can protect AR.
存在与使用不安全地址解析[RFC3756]相关的已知安全问题。当使用ARP[RFC826]和ND[RFC2461]将IP地址映射到MAC/NPA地址时，读者还可以参考已知的安全问题。建议AR协议支持AR消息源的身份验证和AR信息的完整性，这样可以避免在L2基础设施中插入未经授权的AR消息而导致的已知安全漏洞。对于IPv6，可以使用发送协议[RFC3971]代替ND。这定义了可以保护AR的安全机制。
AR protocols can also be protected by the use of L2 security methods (e.g., Encryption of the ULE SNDU [IPDVB-SEC]). When these methods are used, the security of ARP and ND can be comparable to that of a private LAN: A Receiver will only accept ARP or ND transmissions from the set of peer senders that share a common group encryption and common group authentication key provided by the L2 key management.
AR协议也可以通过使用L2安全方法（例如，加密ULE SNDU[IPDVB-SEC]）进行保护。当使用这些方法时，ARP和ND的安全性可以与专用LAN的安全性相媲美：接收器将只接受来自对等发送者的ARP或ND传输，这些发送者共享L2密钥管理提供的公共组加密和公共组认证密钥。
AR Servers (Section 5.4) are susceptible to the same kind of security issues as end hosts using unsecured AR. These issues include hijacking traffic and denial-of-service within the subnet. Malicious nodes within the subnet can take advantage of this property, and hijack traffic. In addition, an AR Server is essentially a legitimate man-in-the-middle, which implies that there is a need to distinguish such proxies from unwanted man-in-the-middle attackers. This document does not introduce any new mechanisms for the
AR服务器（第5.4节）容易受到与使用不安全AR的终端主机相同的安全问题的影响。这些问题包括子网内的劫持流量和拒绝服务。子网内的恶意节点可以利用此属性劫持流量。此外，AR服务器本质上是一个合法的中间人，这意味着需要将此类代理与不需要的中间人攻击者区分开来。本文件没有介绍任何新的机制
protection of these AR functions (e.g., authenticating servers, or defining AR Servers that interoperate with the SEND protocol [SP-ND]).
保护这些AR功能（例如，验证服务器，或定义与发送协议[SP-ND]互操作的AR服务器）。
The authors wish to thank the IPDVB WG members for their inputs and in particular, Rod Walsh, Jun Takei, and Michael Mercurio. The authors also acknowledge the support of the European Space Agency. Martin Stiemerling contributed descriptions of scenarios, configuration, and provided extensive proof reading. Hidetaka Izumiyama contributed on UDLR and IPv6 issues. A number of issues discussed in the UDLR working group have also provided valuable inputs to this document (summarized in "Experiments with RFC 3077", July 2003).
作者希望感谢IPDVB工作组成员的投入，特别是Rod Walsh、Jun Takei和Michael Mercurio。作者还感谢欧洲航天局的支持。Martin Stiemerling对场景、配置进行了描述，并提供了广泛的校对。Hidetaka Izumiyama对UDLR和IPv6问题做出了贡献。UDLR工作组讨论的一些问题也为本文件提供了宝贵的投入（总结于2003年7月的“RFC 3077实验”）。
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", v1.3.1, European Telecommunications Standards Institute (ETSI), May 2003.
[ETSI-DAT]EN 301 192，“数据广播规范”，v1.3.1，欧洲电信标准协会（ETSI），2003年5月。
[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-SI] EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", v1.7.1, European Telecommunications Standards Institute (ETSI), December 2005.
[ETSI-SI]EN 300 468，“数字视频广播（DVB）；DVB系统中服务信息（SI）规范”，v1.7.1，欧洲电信标准协会（ETSI），2005年12月。
[ISO-MPEG2] ISO/IEC IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organization (ISO), 2000.
[ISO-MPEG2]ISO/IEC IS 13818-1，“信息技术——运动图像和相关音频信息的通用编码——第1部分：系统”，国际标准化组织（ISO），2000年。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]Deering，S.，“IP多播的主机扩展”，STD 5，RFC11121989年8月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[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月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736]Droms，R.，“IPv6的无状态动态主机配置协议（DHCP）服务”，RFC 3736，2004年4月。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[RFC4326]Fairhurst，G.和B.Collini Nocker，“通过MPEG-2传输流（TS）传输IP数据报的单向轻量封装（ULE）”，RFC 4326，2005年12月。
[802.1D] IEEE 802.1D, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", IEEE, 2004.
[802.1D]IEEE 802.1D，“局域网和城域网的IEEE标准：媒体访问控制（MAC）网桥”，IEEE，2004年。
[802.3] IEEE 802.3, "Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Computer Society, (also ISO/IEC 8802-3), 2002.
[802.3]IEEE 802.3，“局域网和城域网特定要求第3部分：带冲突检测的载波侦听多址接入（CSMA/CD）接入方法和物理层规范”，IEEE计算机协会（也称ISO/IEC 8802-3），2002年。
[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-A54A] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003.
[ATSC-A54A]A/54A，“ATSC数字电视标准使用指南”，高级电视系统委员会（ATSC），文件。A/54A，2003年。
[ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/90, 2000.
[ATSC-A90]A/90，“ATSC数据广播标准”，高级电视系统委员会（ATSC），文件。A/902000。
[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。
[DOCSIS] "Data-Over-Cable Service Interface Specifications, DOCSIS 2.0, Radio Frequency Interface Specification", CableLabs, document CM-SP-RFIv2.0-I10-051209, 2005.
[DOCSIS]“电缆数据服务接口规范，DOCSIS 2.0，射频接口规范”，电缆实验室，文件CM-SP-RFIv2.0-I10-0512092005。
[DVB] Digital Video Broadcasting (DVB) Project. http://www.dvb.org.
[DVB]数字视频广播（DVB）项目。http://www.dvb.org.
[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-RCS] EN 301 790, "Digital Video Broadcasting (DVB); Interaction channel for satellite distribution Systems", European Telecommunications Standards Institute (ETSI).
[ETSI-RCS]EN 301 790，“数字视频广播（DVB）；卫星分配系统的交互信道”，欧洲电信标准协会（ETSI）。
[ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems", European Telecommunications Standards Institute (ETSI).
[ETSI-SI1]TR 101 162，“数字视频广播（DVB）；DVB系统服务信息（SI）代码的分配”，欧洲电信标准协会（ETSI）。
[IPDVB-SEC] H. Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, May 2007.
[IPDVB-SEC]H.Cruickshank，S.Iyengar，L.Duquerroy，P.Pillai，“单向轻量级封装（ULE）协议的安全要求”，正在进行的工作，2007年5月。
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC is a full software implementation", International Standards Organization (ISO), 2002.
[ISO-DSMCC]ISO/IEC IS 13818-6，“信息技术——运动图像和相关音频信息的通用编码——第6部分：DSM-CC的扩展是一个完整的软件实现”，国际标准化组织（ISO），2002年。
[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 Organization (ISO), 1998.
[LLC]ISO/IEC 8802.2，“信息技术；系统间的电信和信息交换；局域网和城域网；特殊要求；第2部分：逻辑链路控制”，国际标准组织（ISO），1998年。
[MMT] "SatLabs System Recommendations, Part 1, General Specifications", Version 2.0, SatLabs Forum, 2006. http://satlabs.org/pdf/ SatLabs_System_Recommendations_v2.0_general.pdf.
[MMT]“卫星实验室系统建议，第1部分，通用规范”，2.0版，卫星实验室论坛，2006年。http://satlabs.org/pdf/ SatLabs_系统_建议_v2.0_general.pdf。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951]Croft，W.和J.Gilmore，“引导协议”，RFC9511985年9月。
[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月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option", RFC 3256, April 2002.
[RFC3256]Jones，D.和R.Woundy，“DOCSIS（有线数据服务接口规范）设备级DHCP（动态主机配置协议）中继代理信息子选项”，RFC 3256，2002年4月。
[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月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449]Balakrishnan，H.，Padmanabhan，V.，Fairhurst，G.，和M.Sooriyabandara，“网络路径不对称的TCP性能影响”，BCP 69，RFC 3449，2002年12月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Handley，M.，和J.Crowcroft，“分层编码传输（LCT）构建块”，RFC 34512002年12月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya，S.，“源特定多播（SSM）概述”，RFC 3569，2003年7月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756]Nikander，P.，Kempf，J.，和E.Nordmark，“IPv6邻居发现（ND）信任模型和威胁”，RFC 37562004年5月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]Luby，M.和V.Goyal，“基于波动和方程的速率控制（WEBRC）构造块”，RFC 3738，2004年4月。
[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月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4259] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4259]Weis，B.“在封装安全有效载荷（ESP）和身份验证头（AH）中使用RSA/SHA-1签名”，RFC 4359，2006年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，2006年4月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]Fenner，B.，He，H.，Haberman，B.，和H.Sandick，“基于Internet组管理协议（IGMP）/多播侦听器发现（MLD）的多播转发（“IGMP/MLD代理”）”，RFC 4605，2006年8月。
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", RFC 4779, January 2007.
[RFC4779]Asadullah，S.，Ahmed，A.，Popoviciu，C.，Savola，P.，和J.Palet，“宽带接入网络中的ISP IPv6部署场景”，RFC 4779，2007年1月。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation Methods Considered Harmful", RFC 4840, April 2007.
[RFC4840]Aboba，B.，Davies，E.，和D.Thaler，“认为有害的多种封装方法”，RFC 4840，2007年4月。
[SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6, March 2002.
[SCTE-1]“数字MPEG网络的IP多播”，SCTE DVS 311r6，2002年3月。
[SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Work in Progress, February 2005.
[SP-ND]Daley，G.，“保护代理邻居发现问题声明”，正在进行的工作，2005年2月。
Authors' Addresses
作者地址
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
英国阿伯丁大学阿德里德-费尔赫斯特工程系
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Marie-Jose Montpetit Motorola Connected Home Solutions Advanced Technology 55 Hayden Avenue, 3rd Floor Lexington, Massachusetts 02421 USA
美国马萨诸塞州列克星敦市海登大道55号三楼玛丽何塞·蒙佩蒂特摩托罗拉互联家庭解决方案先进技术公司02421
EMail: mmontpetit@motorola.com
EMail: mmontpetit@motorola.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。