Network Working Group H. Jeon
Request for Comments: 5692 S. Jeong
Category: Standards Track ETRI
M. Riegel
NSN
October 2009
Network Working Group H. Jeon
Request for Comments: 5692 S. Jeong
Category: Standards Track ETRI
M. Riegel
NSN
October 2009
Transmission of IP over Ethernet over IEEE 802.16 Networks
在IEEE 802.16网络上通过以太网传输IP
Abstract
摘要
This document describes the transmission of IPv4 over Ethernet, as well as IPv6 over Ethernet, in an access network deploying the IEEE 802.16 cellular radio transmission technology. The Ethernet on top of IEEE 802.16 is realized by bridging connections that IEEE 802.16 provides between a base station and its associated subscriber stations. Due to the resource constraints of radio transmission systems and the limitations of the IEEE 802.16 Media Access Control (MAC) functionality for the realization of an Ethernet, the transmission of IP over Ethernet over IEEE 802.16 may considerably benefit by adding IP-specific support functions in the Ethernet over IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior.
本文档描述了在部署IEEE 802.16蜂窝无线传输技术的接入网络中通过以太网传输IPv4以及通过以太网传输IPv6。IEEE 802.16之上的以太网是通过在基站及其相关用户站之间桥接IEEE 802.16提供的连接来实现的。由于无线传输系统的资源限制以及用于实现以太网的IEEE 802.16媒体访问控制（MAC）功能的限制，通过在基于IEEE 802.16的以太网中添加特定于IP的支持功能，同时保持与基于以太网的标准IP行为的完全兼容性，通过IEEE 802.16通过以太网的IP传输可能会大大受益。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
2. Requirements ....................................................4
3. Terminology .....................................................4
4. The IEEE 802.16 Link Model ......................................4
4.1. Connection-Oriented Air Interface ..........................4
4.2. MAC Addressing in IEEE 802.16 ..............................5
4.3. Unidirectional Broadcast and Multicast Support .............6
4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet ......6
5. Ethernet Network Model for IEEE 802.16 ..........................6
5.1. IEEE 802.16 Ethernet Link Model ............................7
5.2. Ethernet without Native Broadcast and Multicast Support ....8
5.3. Network-Side Bridging Function .............................8
5.4. Segmenting the Ethernet into VLANs .........................9
6. Transmission of IP over Ethernet over IEEE 802.16 Link ..........9
6.1. Generic IP over Ethernet Network Scenario ..................9
6.2. Transmission of IP over Ethernet ..........................10
6.2.1. IPv4-over-Ethernet Packet Transmission .............10
6.2.2. IPv6-over-Ethernet Packet Transmission .............11
6.2.3. Maximum Transmission Unit ..........................11
6.2.4. Prefix Assignment ..................................11
7. Operational Enhancements for IP over Ethernet over IEEE
802.16 .........................................................12
7.1. IP Multicast and Broadcast Packet Processing ..............12
7.1.1. Multicast Transmission Considerations ..............12
7.1.2. Broadcast Transmission Considerations ..............12
7.2. DHCP Considerations .......................................13
7.3. Address Resolution Considerations .........................13
8. Public Access Recommendations ..................................14
9. Security Considerations ........................................15
10. Acknowledgments ...............................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Appendix A. Multicast CID Deployment Considerations ..............19
Appendix B. Centralized vs. Distributed Bridging ................19
1. Introduction ....................................................4
2. Requirements ....................................................4
3. Terminology .....................................................4
4. The IEEE 802.16 Link Model ......................................4
4.1. Connection-Oriented Air Interface ..........................4
4.2. MAC Addressing in IEEE 802.16 ..............................5
4.3. Unidirectional Broadcast and Multicast Support .............6
4.4. IEEE 802.16 Convergence Sublayer for IP over Ethernet ......6
5. Ethernet Network Model for IEEE 802.16 ..........................6
5.1. IEEE 802.16 Ethernet Link Model ............................7
5.2. Ethernet without Native Broadcast and Multicast Support ....8
5.3. Network-Side Bridging Function .............................8
5.4. Segmenting the Ethernet into VLANs .........................9
6. Transmission of IP over Ethernet over IEEE 802.16 Link ..........9
6.1. Generic IP over Ethernet Network Scenario ..................9
6.2. Transmission of IP over Ethernet ..........................10
6.2.1. IPv4-over-Ethernet Packet Transmission .............10
6.2.2. IPv6-over-Ethernet Packet Transmission .............11
6.2.3. Maximum Transmission Unit ..........................11
6.2.4. Prefix Assignment ..................................11
7. Operational Enhancements for IP over Ethernet over IEEE
802.16 .........................................................12
7.1. IP Multicast and Broadcast Packet Processing ..............12
7.1.1. Multicast Transmission Considerations ..............12
7.1.2. Broadcast Transmission Considerations ..............12
7.2. DHCP Considerations .......................................13
7.3. Address Resolution Considerations .........................13
8. Public Access Recommendations ..................................14
9. Security Considerations ........................................15
10. Acknowledgments ...............................................16
11. References ....................................................16
11.1. Normative References .....................................16
11.2. Informative References ...................................17
Appendix A. Multicast CID Deployment Considerations ..............19
Appendix B. Centralized vs. Distributed Bridging ................19
IEEE 802.16 [802.16] specifies a fixed-to-mobile, broadband wireless access system.
IEEE 802.16[802.16]规定了一种固定到移动的宽带无线接入系统。
The IEEE 802.16 standard defines a packet CS (Convergence Sublayer) for interfacing with specific packet-based protocols as well as a generic packet CS (GPCS) to provide an upper-layer, protocol-independent interface. This document describes transmission of IPv4 and IPv6 over Ethernet via the Ethernet-specific part of the packet CS as well as of the GPCS in the access network based on IEEE 802.16.
IEEE 802.16标准定义了用于与特定基于分组的协议接口的分组CS（聚合子层）以及通用分组CS（GPCS），以提供上层独立于协议的接口。本文档描述了通过数据包CS的以太网特定部分以及基于IEEE 802.16的接入网络中的GPCS通过以太网传输IPv4和IPv6。
Ethernet has been originally architected and designed for a shared medium while the IEEE 802.16 uses a point-to-multipoint architecture like other cellular radio transmission systems. Hence, Ethernet on top of IEEE 802.16 is realized by bridging between IEEE 802.16 radio connections that connect a BS (Base Station) and its associated SSs (Subscriber Stations).
以太网最初是为共享介质而设计的，而IEEE 802.16与其他蜂窝无线电传输系统一样，使用点对多点体系结构。因此，IEEE 802.16之上的以太网是通过连接BS（基站）及其相关SSs（用户站）的IEEE 802.16无线电连接之间的桥接来实现的。
Under the resource constraints of radio transmission systems and the particularities of the IEEE 802.16 for the realization of Ethernet, it makes sense to add IP-specific support functions in the Ethernet layer above IEEE 802.16 while maintaining full compatibility with standard IP over Ethernet behavior.
在无线传输系统的资源限制和IEEE 802.16实现以太网的特殊性下，在IEEE 802.16之上的以太网层中添加特定于IP的支持功能是有意义的，同时保持与标准IP over Ethernet行为的完全兼容性。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [RFC5154].
本文档中的术语基于“IP over 802.16问题声明和目标”[RFC5154]中的定义。
The IEEE 802.16 MAC establishes connections between a BS and its associated SSs for the transfer of user data over the air. Each of these connections realizes an individual service flow, which is identified by a 16-bit Connection Identifier (CID) number and has a defined Quality of Service (QoS) profile.
IEEE 802.16 MAC在BS及其相关SSs之间建立连接，以便通过空中传输用户数据。这些连接中的每一个都实现一个单独的服务流，该服务流由16位连接标识符（CID）号标识，并具有定义的服务质量（QoS）配置文件。
Multiple connections can be established between a BS and an SS, each with its particular QoS class and direction. Although the BS and all
可以在BS和SS之间建立多个连接，每个连接具有其特定的QoS等级和方向。尽管英国人和所有人
the SSs are associated with unique 48-bit MAC addresses, packets going over the air are only identified in the IEEE 802.16 MAC header by the CID number of the particular connection. The connections are established by MAC management messages between the BS and the SS during network entry or also later on demand.
SSs与唯一的48位MAC地址相关联，通过无线传输的数据包仅在IEEE 802.16 MAC报头中通过特定连接的CID编号识别。在网络进入期间或稍后根据需要在BS和SS之间通过MAC管理消息建立连接。
[Subscriber Side] [Network Side]
[用户端][网络端]
| | | +
| | | +
+--+--+ +--+--+ +--+-+-+--+
| MAC | | MAC | | MAC |
+-----+ +-----+ +---------+
| PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+-+
+ + | | | | + +
+ + | +-----CID#w------+ | + +
+ + +-------CID#x--------+ + +
+ +++++++++++++++++CID#y+++++++++++++++++ +
+++++++++++++++++++CID#z+++++++++++++++++++
SS#1 SS#2 BS
| | | +
| | | +
+--+--+ +--+--+ +--+-+-+--+
| MAC | | MAC | | MAC |
+-----+ +-----+ +---------+
| PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+-+
+ + | | | | + +
+ + | +-----CID#w------+ | + +
+ + +-------CID#x--------+ + +
+ +++++++++++++++++CID#y+++++++++++++++++ +
+++++++++++++++++++CID#z+++++++++++++++++++
SS#1 SS#2 BS
Figure 1: Basic IEEE 802.16 Link Model
图1：基本IEEE 802.16链路模型
Each SS has a unique 48-bit MAC address; the 48-bit MAC address is used during the initial ranging process for the identification of the SS and may be verified by the succeeding PKM (Privacy Key Management) authentication phase. Out of the successful authentication, the BS establishes and maintains the list of attached SSs based on their MAC addresses, purely for MAC management purposes.
每个SS都有一个唯一的48位MAC地址；48位MAC地址在初始测距过程中用于识别SS，并且可以通过随后的PKM（隐私密钥管理）认证阶段进行验证。在成功的身份验证之外，BS基于其MAC地址建立并维护附加SSs的列表，纯粹用于MAC管理目的。
While MAC addresses are assigned to all the BSs as well as the SSs, the forwarding of packets over the air is only based on the CID value of the particular connection in the IEEE 802.16 MAC header. Not relying on the MAC addresses in the payload for reception of a radio frame allows for the transport of arbitrary source and destination MAC addresses in Ethernet frames between an SS and its BS. This is required for bridging Ethernet frames toward an SS that is attached to a bridge connected to another network.
虽然MAC地址被分配给所有BSs以及SSs，但通过空中转发数据包仅基于IEEE 802.16 MAC报头中特定连接的CID值。不依赖有效载荷中的MAC地址来接收无线电帧允许在SS与其BS之间的以太网帧中传输任意源和目的MAC地址。这是将以太网帧桥接到连接到另一个网络的网桥上的SS所必需的。
Due to the managed assignment of the service flows and associated CID values to individual SSs, the BS is able to bundle all unicast connections belonging to a particular SS into a single link on the network side, as shown in Figure 1, so that it provides a single layer-2 link between the SS and its associated wired link on the network side.
由于服务流和相关联的CID值被管理地分配给各个SSs，BS能够将属于特定SS的所有单播连接捆绑到网络侧的单个链路中，如图1所示，从而在SS和网络侧的其相关联的有线链路之间提供单个第2层链路。
Current IEEE 802.16 [802.16] does not support bidirectional native broadcast and multicast for IP packets. While downlink connections can be used for multicast transmission to a group of SSs as well as unicast transmission from the BS to a single SS, uplink connections from the SSs to the BS provide only unicast transmission capabilities. Furthermore, the use of multicast CIDs for realizing downlink multicast transmissions is not necessarily preferable due to the reduced transmission efficiency of multicast CIDs for small multicast groups. Appendix A provides more background information about the issues arising with multicast CIDs in IEEE 802.16 systems.
当前的IEEE 802.16[802.16]不支持IP数据包的双向本机广播和多播。虽然下行链路连接可用于到一组SSs的多播传输以及从BS到单个SS的单播传输，但是从SSs到BS的上行链路连接仅提供单播传输能力。此外，由于多播cid对于小多播组的传输效率降低，因此使用多播cid来实现下行链路多播传输不一定是优选的。附录A提供了有关IEEE 802.16系统中多播CID问题的更多背景信息。
MBS (Multicast and Broadcast Service), as specified in IEEE 802.16, also does not cover IP broadcast or multicast data because MBS is invisible to the IP layer.
IEEE 802.16中规定的MBS（多播和广播服务）也不包括IP广播或多播数据，因为MBS对IP层不可见。
IEEE 802.16 provides two solutions to transfer Ethernet frames over IEEE 802.16 MAC connections.
IEEE 802.16提供了两种通过IEEE 802.16 MAC连接传输以太网帧的解决方案。
The packet CS is defined for handling packet-based protocols by classifying higher-layer packets depending on the values in the packet header fields and assigning the packets to the related service flow. The packet CS comprises multiple protocol-specific parts to enable the transmission of different kinds of packets over IEEE 802.16. The Ethernet-specific part of the packet CS supports the transmission of Ethernet by defining classification rules based on Ethernet header information.
分组CS被定义为通过根据分组报头字段中的值对高层分组进行分类并将分组分配给相关服务流来处理基于分组的协议。分组CS包括多个特定于协议的部分，以便能够通过IEEE 802.16传输不同种类的分组。数据包CS的以太网特定部分通过基于以太网报头信息定义分类规则来支持以太网传输。
The GPCS (Generic Packet Convergence Sublayer) may be used as an alternative to transfer Ethernet frames over IEEE 802.16. The GPCS does not define classification rules for each kind of payload but relies on higher-layer functionality outside of the scope of IEEE 802.16 to provide the assignment of packets to particular service flows.
GPCS（通用分组汇聚子层）可用作通过IEEE 802.16传输以太网帧的替代方案。GPCS不为每种有效载荷定义分类规则，而是依赖IEEE 802.16范围之外的更高层功能来为特定服务流提供分组分配。
Like in today's wired Ethernet networks, bridging is required to implement connectivity between more than two devices. In IEEE 802.16, the point-to-point connections between SSs and the BS can be bridged so that Ethernet is realized over the IEEE 802.16 access network.
与当今的有线以太网一样，需要桥接来实现两个以上设备之间的连接。在IEEE 802.16中，SSs和BS之间的点对点连接可以桥接，以便通过IEEE 802.16接入网络实现以太网。
To realize Ethernet on top of IEEE 802.16, all the point-to-point connections belonging to an SS MUST be connected to a network-side bridging function, as shown in Figure 2. This is equivalent to today's switched Ethernet with twisted pair wires or fibres connecting the hosts to a bridge ("Switch").
要在IEEE 802.16之上实现以太网，属于SS的所有点对点连接必须连接到网络端桥接功能，如图2所示。这相当于今天的交换式以太网，使用双绞线或光纤将主机连接到网桥（“交换机”）。
The network-side bridging function can be realized either by a single centralized network-side bridge or by multiple interconnected bridges, preferably arranged in hierarchical order. The single centralized network-side bridge allows best control of the broadcasting and forwarding behavior of the Ethernet over IEEE 802.16. Appendix B explains the issues of a distributed bridging architecture when no assumptions about the location of the access router can be made.
网络侧桥接功能可以通过单个集中式网络侧桥接器或多个互连桥接器来实现，优选地以分层顺序排列。单一集中式网络侧网桥允许通过IEEE 802.16对以太网的广播和转发行为进行最佳控制。附录B解释了当无法对接入路由器的位置进行假设时，分布式桥接体系结构的问题。
The BS MUST forward all the service flows belonging to one SS to one port of the network-side bridging function. No more than one SS MUST be connected to one port of the network-side bridging function. The separation method for multiple links on the connection between the BS and the network-side bridging function is out of scope for this document. Either layer-2 transport or layer-3 tunneling may be used.
BS必须将属于一个SS的所有服务流转发到网络侧桥接功能的一个端口。网络侧桥接功能的一个端口必须连接一个以上的SS。BS和网络侧桥接功能之间连接的多个链路的分离方法不在本文档的范围内。可以使用第2层传输或第3层隧道。
If the Ethernet over IEEE 802.16 is extended to multiple end stations behind the SS (i.e., SS#4 in the figure below), then the SS SHOULD support bridging according to [802.1D] and its amendment [802.16k], a.k.a. subscriber-side bridge, between all its subscriber-side ports and the IEEE 802.16 air link.
如果IEEE 802.16上的以太网扩展到SS后面的多个终端站（即下图中的SS#4），则SS应支持根据[802.1D]及其修正案[802.16k]在其所有用户端端口和IEEE 802.16空中链路之间建立桥接，即用户端桥接。
------------------------ IP Link --------------------------
------------------------ IP Link --------------------------
[Subscriber Side] [Network Side] [Subscriber Side]
| | | | | |
ETH ETH ETH ETH ETH ETH
| | | | | |
| | +---------+---------+ | +-+---+-+
| | | Bridging Function | | |Bridge |
| | +--+-+---------+-+--+ | +---+---+
| | | + + | | |
+--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+
| MAC | | MAC | | MAC | | MAC | | MAC | | MAC |
+-----+ +-----+ +-------+ +-------+ +-----+ +-----+
| PHY | | PHY | | PHY | | PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+
+ | | | | + + | | | | +
+ | +--CID#u-+ | + + | +-CID#x--+ | +
+ +----CID#v---+ + + +---CID#y----+ +
+++++++++++++++CID#w++++++ ++++++CID#z+++++++++++++++
[Subscriber Side] [Network Side] [Subscriber Side]
| | | | | |
ETH ETH ETH ETH ETH ETH
| | | | | |
| | +---------+---------+ | +-+---+-+
| | | Bridging Function | | |Bridge |
| | +--+-+---------+-+--+ | +---+---+
| | | + + | | |
+--+--+ +--+--+ +--+-+--+ +--+-+--+ +--+--+ +--+--+
| MAC | | MAC | | MAC | | MAC | | MAC | | MAC |
+-----+ +-----+ +-------+ +-------+ +-----+ +-----+
| PHY | | PHY | | PHY | | PHY | | PHY | | PHY |
+-+-+-+ +-+-+-+ +-+-+-+-+ +-+-+-+-+ +-+-+-+ +-+-+-+
+ | | | | + + | | | | +
+ | +--CID#u-+ | + + | +-CID#x--+ | +
+ +----CID#v---+ + + +---CID#y----+ +
+++++++++++++++CID#w++++++ ++++++CID#z+++++++++++++++
SS#1 SS#2 BS#1 BS#2 SS#3 SS#4
SS#1 SS#2 BS#1 BS#2 SS#3 SS#4
Figure 2: IEEE 802.16 Ethernet Link Model
图2:IEEE 802.16以太网链路模型
Current IEEE 802.16 does not define broadcast and multicast of Ethernet frames. Hence, Ethernet frames that are broadcast or multicast SHOULD be replicated and then carried via unicast transport connections on the IEEE 802.16 access link. The network-side bridging function performs the replication and forwarding for Ethernet broadcast and multicast over the IEEE 802.16 radio links.
当前的IEEE 802.16没有定义以太网帧的广播和多播。因此，应复制广播或多播的以太网帧，然后通过IEEE 802.16访问链路上的单播传输连接进行传输。网络侧桥接功能通过IEEE 802.16无线链路执行以太网广播和多播的复制和转发。
The network-side bridging function MUST create a new radio-side port whenever a new SS attaches to any of the BSs of the network, or it MUST remove a radio-side port when an associated SS detaches from the BSs. The method for managing the port on the network-side bridging function may depend on the protocol used for establishing multiple links on the connection between the BS and the network-side bridge. The port-managing method is out of scope for this document.
每当新SS连接到网络的任何BSs时，网络侧桥接功能必须创建新的无线电侧端口，或者当相关SS从BSs分离时，它必须删除无线电侧端口。用于管理网络侧桥接功能上的端口的方法可以取决于用于在BS和网络侧桥接之间的连接上建立多个链路的协议。端口管理方法超出了本文档的范围。
The network-side bridging function MUST be based on [802.1D] and its amendment [802.16k] to interconnect the attached SSs and pass Ethernet frames between the point-to-point connections associated with the attached SSs. However, to enhance the IEEE 802.16 Ethernet link model by avoiding broadcast or multicast packet flooding,
网络侧桥接功能必须基于[802.1D]及其修正案[802.16k]，以互连连接的SSs，并在与连接的SSs相关的点到点连接之间传递以太网帧。但是，为了通过避免广播或多播数据包泛滥来增强IEEE 802.16以太网链路模型，
additional IP-specific functionalities MAY be provided by the network-side bridging function in addition to the mandatory functions, according to Section 5.1 of [802.1D].
根据[802.1D]第5.1节，除了强制功能外，网络侧桥接功能还可以提供其他特定于IP的功能。
It is possible to restrict the size and coverage of the broadcast domain by segmenting the Ethernet over IEEE 802.16 into VLANs and grouping subsets of hosts into particular VLANs with each VLAN representing an IP link. Therefore, the network-side bridging function MAY be enabled to support VLANs according to [802.1Q] by assigning and handling the VLAN-IDs on the virtual bridge ports.
通过将IEEE 802.16上的以太网划分为VLAN，并将主机子集分组为特定VLAN（每个VLAN代表一个IP链路），可以限制广播域的大小和覆盖范围。因此，可以通过分配和处理虚拟网桥端口上的VLAN ID来启用网络侧桥接功能，以支持符合[802.1Q]的VLAN。
If an SS is directly connected to a subscriber-side bridge supporting VLANs, the port associated with such an SS MAY be enabled as trunk port. On trunk ports, Ethernet frames are forwarded in the [802.1Q] frame format.
如果SS直接连接到支持VLAN的用户端网桥，则与此类SS关联的端口可以启用为中继端口。在中继端口上，以太网帧以[802.1Q]帧格式转发。
The generic IP over Ethernet network scenario assumes that all hosts are residing on the same link. It enables the hosts to directly communicate with each other without detouring. There can be multiple Access Routers (ARs) on the link, and these may reside both on the subscriber side as well as on the network side, as shown in Figure 3.
一般的以太网IP网络场景假定所有主机都位于同一链路上。它使主机无需绕道即可直接相互通信。链路上可能有多址路由器（AR），这些路由器可能位于用户端和网络端，如图3所示。
+--+--+
---|AR|SS|
+--+--+* +----+
* +----+ +Host|
+----+--+ * | +-------+ /+----+
|Host|SS|* * * * **| BS +------+ \ / +----+
+----+--+ * | +-----+ \ \ / ++Host|
+----+--+ * +----+ \ \ +-+--------+ / +----+
|Host|SS|* \ +--+ ++
+----+ +----+--+ +---+Bridging| +----+
--+ AR ++ |Function+---+ AR +---
+----+ \ +--+ | +----+
\ +----+ / +-+--------+
+----+ +------+--+ | +---+ /
|Host+-+Bridge|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +----+--+ *
+----+ |Host|SS|*
+----+--+
+--+--+
---|AR|SS|
+--+--+* +----+
* +----+ +Host|
+----+--+ * | +-------+ /+----+
|Host|SS|* * * * **| BS +------+ \ / +----+
+----+--+ * | +-----+ \ \ / ++Host|
+----+--+ * +----+ \ \ +-+--------+ / +----+
|Host|SS|* \ +--+ ++
+----+ +----+--+ +---+Bridging| +----+
--+ AR ++ |Function+---+ AR +---
+----+ \ +--+ | +----+
\ +----+ / +-+--------+
+----+ +------+--+ | +---+ /
|Host+-+Bridge|SS|* * * *| BS | /
+----+ +------+--+ * | +---+
+----+/ * +----+
|Host+ +----+--+ *
+----+ |Host|SS|*
+----+--+
Figure 3: Generic IP over Ethernet Network Scenario Using IEEE 802.16
图3：使用IEEE 802.16的以太网通用IP网络场景
[RFC0894] defines the transmission of IPv4 packets over Ethernet networks. It contains the specification of the encapsulation of the IPv4 packets into Ethernet frames as well as rules for mapping IP addresses onto Ethernet MAC addresses. Hosts transmitting IPv4 over Ethernet packets over the IEEE 802.16 MUST follow the operations specified in [RFC0894].
[RFC0894]定义通过以太网传输IPv4数据包。它包含将IPv4数据包封装到以太网帧的规范，以及将IP地址映射到以太网MAC地址的规则。通过IEEE 802.16通过以太网传输IPv4数据包的主机必须遵循[RFC0894]中指定的操作。
IPv4 addresses can be configured manually or assigned dynamically from Dynamic Host Configuration Protocol for IPv4 (DHCPv4) servers [RFC2131].
IPv4地址可以手动配置或通过IPv4（DHCPv4）服务器的动态主机配置协议动态分配[RFC2131]。
The Address Resolution Protocol (ARP) [RFC0826] MUST be used for finding the destination Ethernet MAC address.
地址解析协议（ARP）[RFC0826]必须用于查找目标以太网MAC地址。
[RFC2464] defines transmission of IPv6 packets over Ethernet networks, which includes an encapsulation of IPv6 packets into Ethernet frames; that document includes rules for mapping IPv6 addresses to Ethernet addresses (i.e., MAC addresses). Hosts transmitting IPv6-over-Ethernet packets over IEEE 802.16 MUST follow the operations specified in [RFC2464].
[RFC2464]定义了通过以太网传输IPv6数据包，包括将IPv6数据包封装到以太网帧中；该文档包括将IPv6地址映射到以太网地址（即MAC地址）的规则。通过IEEE 802.16通过以太网传输IPv6数据包的主机必须遵循[RFC2464]中指定的操作。
Router Discovery, Prefix Discovery, and Parameter Discovery procedures are achieved by receiving Router Advertisement messages. However, periodic Router Advertisement messages can waste radio resource and disturb SSs in dormant mode in IEEE 802.16. Therefore, the AdvDefaultLifetime and MaxRtrAdvInterval SHOULD be overridden with high values specified in Section 8.3 in [RFC5121].
路由器发现、前缀发现和参数发现过程是通过接收路由器广告消息来实现的。然而，在IEEE 802.16中，周期性的路由器广告消息可能会浪费无线资源并在休眠模式下干扰SSs。因此，应使用[RFC5121]第8.3节中规定的高值覆盖AdvDefaultLifetime和MaxRtrAdvInterval。
When stateful address autoconfiguration is required, the stateful address configuration according to [RFC3315] MUST be performed. In this case, an AR supports a Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server or relay function.
当需要有状态地址自动配置时，必须根据[RFC3315]执行有状态地址配置。在这种情况下，AR支持IPv6（DHCPv6）服务器或中继功能的动态主机配置协议。
When stateless address autoconfiguration is required, the stateless address configuration according to [RFC4862] and [RFC4861] MUST be performed.
当需要无状态地址自动配置时，必须根据[RFC4862]和[RFC4861]执行无状态地址配置。
The Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for determining the destination Ethernet MAC address.
邻居发现协议（NDP）[RFC4861]必须用于确定目标以太网MAC地址。
[RFC2460] mandates 1280 bytes as a minimum Maximum Transmission Unit (MTU) size for the link layer and recommends at least 1500 bytes for IPv6 over Ethernet transmission. [RFC0894] also specifies 1500 bytes as a maximum length of IPv4 over Ethernet. Therefore, the default MTU of IPv6 packets and IPv4 packets on an Ethernet over IEEE 802.16 link MUST be 1500 bytes.
[RFC2460]要求1280字节作为链路层的最小最大传输单元（MTU）大小，并建议至少1500字节用于以太网上的IPv6传输。[RFC0894]还指定1500字节作为以太网上IPv4的最大长度。因此，通过IEEE 802.16的以太网链路上IPv6数据包和IPv4数据包的默认MTU必须为1500字节。
As Ethernet over IEEE 802.16 may only build a part of a larger Ethernet of arbitrary structure, any kind of prefix assignment that is feasible for Ethernet is applicable for Ethernet over IEEE 802.16
由于IEEE802.16上的以太网可能只构建任意结构的大型以太网的一部分，因此对以太网可行的任何类型的前缀分配都适用于IEEE802.16上的以太网
as well. The same IPv4 prefix and the same set of IPv6 prefixes MAY be assigned to all hosts attached to the Ethernet over IEEE 802.16 to make best usage of Ethernet behavior. Sharing the prefix means locating all hosts on the same subnetwork.
也可以将相同的IPv4前缀和相同的IPv6前缀集分配给通过IEEE 802.16连接到以太网的所有主机，以充分利用以太网行为。共享前缀意味着将所有主机定位在同一子网上。
This section presents operational enhancements in order to improve network performance and radio resource efficiency for transmission of IP packets over Ethernet over IEEE 802.16 networks.
本节介绍了操作增强功能，以提高通过IEEE 802.16网络通过以太网传输IP数据包的网络性能和无线电资源效率。
All multicast and multicast control messages can be processed in the network-side bridging function, according to [RFC4541]. Broadcasting messages to all radio-side side ports SHOULD be prevented.
根据[RFC4541]，可以在网络端桥接功能中处理所有多播和多播控制消息。应防止向所有无线电侧端口广播消息。
Further information on the prevention of multicasting or broadcasting messages to all radio-side ports is given in the following sections.
关于防止向所有无线电侧端口发送多播或广播消息的更多信息，请参见以下章节。
Usually, bridges replicate the IP multicast packets and forward them into all of its available ports except the incoming port. As a result, the IP multicast packets would be transmitted over the air -- even to hosts that have not joined the corresponding multicast group. To allow bridges to handle IP multicast more efficiently, the IP multicast membership information should be propagated between bridges.
通常，网桥复制IP多播数据包，并将其转发到除传入端口之外的所有可用端口。因此，IP多播数据包将通过空中传输——甚至传输到尚未加入相应多播组的主机。为了使网桥能够更有效地处理IP多播，应该在网桥之间传播IP多播成员信息。
In the IEEE 802.16 Ethernet link model in Section 5.1, the network-side bridging function can process all multicast data and multicast control messages according to [RFC4541] in order to maintain IP multicast membership states and forward IP multicast data to only ports suitable for the multicast group.
在第5.1节中的IEEE 802.16以太网链路模型中，网络侧桥接功能可根据[RFC4541]处理所有多播数据和多播控制消息，以维持IP多播成员状态，并将IP多播数据转发至仅适合多播组的端口。
The ordinary bridge floods the IP broadcast packets out of all connected ports except the port on which the packet was received. This behavior is not appropriate with scarce resources and dormant-mode hosts in a wireless network such as an access network based on IEEE 802.16.
普通网桥将IP广播数据包从除接收数据包的端口之外的所有连接端口中溢出。这种行为不适用于无线网络（如基于IEEE 802.16的接入网络）中的稀缺资源和休眠模式主机。
The network-side bridging function in the IEEE 802.16 Ethernet link model SHOULD flood all IP broadcast packets except ARP-, DHCPv4-, and Internet Group Management Protocol (IGMP)-related traffic.
IEEE802.16以太网链路模型中的网络侧桥接功能应淹没除ARP-、DHCPv4-和互联网组管理协议（IGMP）相关流量外的所有IP广播数据包。
IGMP-related broadcast packets can be forwarded according to the [RFC4541]. ARP-related broadcast SHOULD be processed as specified in Section 7.3.
可以根据[RFC4541]转发与IGMP相关的广播分组。应按照第7.3节的规定处理ARP相关广播。
In the IPv4-over-Ethernet case, DHCPv4 clients may send DHCPDISCOVER and DHCPREQUEST messages with the BROADCAST bit set to request the DHCPv4 server to broadcast its DHCPOFFER and DHCPACK messages. The network-side bridging function SHOULD filter these broadcast DHCPOFFER and DHCPACK messages and forward the broadcast messages only to the host defined by the client hardware address in the chaddr information element.
在以太网IPv4情况下，DHCPv4客户端可以发送设置了广播位的DHCPDISCOVER和DHCPREQUEST消息，以请求DHCPv4服务器广播其DHCPOFFER和DHCPACK消息。网络端桥接功能应过滤这些广播DHCPOFFER和DHCPACK消息，并仅将广播消息转发给chaddr信息元素中客户端硬件地址定义的主机。
Alternatively, the DHCP Relay Agent Information option (option 82) [RFC3046] MAY be used to avoid DHCPv4 broadcast replies. Option 82 consists of two types of sub-options: Circuit ID and Remote ID. The DHCPv4 Relay Agent is usually located on the network-side bridging function as the Layer 2 DHCPv4 Relay Agent. The port number of the network-side bridging function can be used as Circuit ID, and Remote ID may be left unspecified. Note that using option 82 requires DHCPv4 servers that are aware of option 82.
或者，DHCP中继代理信息选项（选项82）[RFC3046]可用于避免DHCPv4广播应答。选项82包括两种类型的子选项：电路ID和远程ID。DHCPv4中继代理通常位于网络侧桥接功能上，作为第2层DHCPv4中继代理。网络侧桥接功能的端口号可用作电路ID，远程ID可能未指定。注意，使用选项82需要知道选项82的DHCPv4服务器。
In the IPv6-over-Ethernet case, DHCPv6 clients use their link-local addresses and the All_DHCP_Relay_Agents_and_Servers multicast address to discover and communicate with DHCPv6 servers or Relay Agents on their link. Hence, DHCPv6-related packets are unicasted or multicasted. The network-side bridging function SHOULD handle the DHCPv6-related unicast packets based on [802.1D] and SHOULD transmit the DHCPv6-related multicast packets as specified in Section 7.1.1.
在以太网上的IPv6情况下，DHCPv6客户端使用其链路本地地址和所有_DHCP_中继_代理_和_服务器多播地址来发现DHCPv6服务器或其链路上的中继代理并与之通信。因此，与DHCPv6相关的数据包是单播或多播的。网络侧桥接功能应根据[802.1D]处理与DHCPv6相关的单播数据包，并应按照第7.1.1节的规定发送与DHCPv6相关的多播数据包。
In the IPv4-over-Ethernet case, ARP Requests are usually broadcasted to all hosts on the same link in order to resolve an Ethernet MAC address, which would disturb all hosts on the same link. Proxy ARP provides the function in which a device on the same link as the hosts answers ARP Requests instead of the remote host. When transmitting IPv4 packets over the IEEE 802.16 Ethernet link, the Proxy ARP mechanism is used by the network-side bridging function to avoid broadcasting ARP Requests over the air.
在IPv4 over Ethernet的情况下，ARP请求通常广播到同一链路上的所有主机，以解析以太网MAC地址，这将干扰同一链路上的所有主机。代理ARP提供了一种功能，在该功能中，与主机位于同一链路上的设备响应ARP请求，而不是远程主机。当通过IEEE 802.16以太网链路传输IPv4数据包时，网络端桥接功能使用代理ARP机制来避免通过空中广播ARP请求。
The network-side bridging function SHOULD maintain an ARP cache large enough to accommodate ARP entries for all its serving SSs. The ARP cache SHOULD be updated by any packets including ARP Requests from SSs in the same way the normal layer-2 bridging device is updating its Filtering Database according to [802.1D].
网络端桥接功能应保持足够大的ARP缓存，以容纳其所有服务SSs的ARP条目。ARP缓存应通过任何数据包（包括来自SSs的ARP请求）进行更新，更新方式与普通第2层桥接设备根据[802.1D]更新其过滤数据库的方式相同。
Upon receiving an ARP Request from an SS, the network-side bridging function SHOULD unicast an ARP Reply back to the SS with the Ethernet address of the target host, provided that the target address matches an entry in the ARP cache. However, in case of receiving an ARP Request from a host behind a subscriber-side bridge, the network-side bridging function SHOULD discard the request if the target host is also behind the same subscriber-side bridge, i.e., on the same port of the network-side bridge. Otherwise, the ARP Request MAY be flooded. The network-side bridging function SHOULD silently discard any received self-ARP Request.
在接收到来自SS的ARP请求后，网络侧桥接功能应使用目标主机的以太网地址将ARP回复单播回SS，前提是目标地址与ARP缓存中的条目匹配。然而，在从用户侧网桥后面的主机接收ARP请求的情况下，如果目标主机也在同一用户侧网桥后面，即在网络侧网桥的同一端口上，则网络侧网桥功能应丢弃该请求。否则，ARP请求可能会被淹没。网络端桥接功能应自动放弃任何接收到的自ARP请求。
In the IPv6-over-Ethernet case, Neighbor Solicitation messages are multicasted to the solicited-node multicast address for the address resolution, including a duplicate address detection. The solicited-node multicast address facilitates the efficient querying of hosts without disturbing all hosts on the same link. The network-side bridging function SHOULD transmit the Neighbor Solicitation messages specified in Section 7.1.1.
在以太网上的IPv6情况下，邻居请求消息被多播到请求的节点多播地址以进行地址解析，包括重复地址检测。请求的节点多播地址有助于高效查询主机，而不会干扰同一链路上的所有主机。网络侧桥接功能应传输第7.1.1节中规定的邻居请求消息。
In the public access scenario, direct communication between nodes is restricted because of security and accounting issues. Figure 4 depicts the public access scenario.
在公共访问场景中，由于安全和记帐问题，节点之间的直接通信受到限制。图4描述了公共访问场景。
In this scenario, the AR is connected to a network-side bridge. The AR MAY perform security filtering, policing, and accounting of all traffic from hosts, e.g., like an NAS (Network Access Server).
在此场景中，AR连接到网络侧网桥。AR可以对来自主机（例如，如NAS（网络访问服务器））的所有流量执行安全过滤、监管和记帐。
If the AR functions as the NAS, all the traffic from SSs SHOULD be forwarded to the AR, not bridged at the network-side bridging function -- even in the case of traffic between SSs served by the same AR. The bridge SHOULD forward upstream traffic from hosts toward the AR but MUST perform normal bridging operation for downstream traffic from the AR and MUST bridge SEcure Neighbor Discovery (SEND) [RFC3971] messages to allow applicability of security schemes.
如果AR用作NAS，则来自SSs的所有流量都应转发到AR，在网络端桥接功能处未桥接——即使是在由同一AR服务的SSs之间的流量情况下也是如此。桥接器应将来自主机的上游流量转发到AR，但必须对来自AR的下游流量执行正常桥接操作，并且必须桥接安全邻居发现（发送）[RFC3971]允许应用安全方案的消息。
In the IPv4-over-Ethernet case, MAC-Forced Forwarding (MAC-FF) [RFC4562] can be used for the public access network to ensure that traffic from all hosts is always directed to the AR. The MAC-FF is performed in the network-side bridging function; thus, the bridge filters broadcast ARP Requests from all the hosts and responds to the ARP Requests with an Ethernet MAC address of the AR.
在IPv4 over Ethernet的情况下，MAC强制转发（MAC-FF）[RFC4562]可用于公共接入网络，以确保来自所有主机的流量始终指向AR。MAC-FF在网络侧桥接功能中执行；因此，网桥过滤来自所有主机的广播ARP请求，并使用AR的以太网MAC地址响应ARP请求。
In the IPv6-over-Ethernet case, unique IPv6 prefixes per SS can be assigned because doing so forces all IPv6 packets from SSs to be transferred to the AR and thus results in layer-3 separation between
在以太网上的IPv6情况下，可以为每个SS分配唯一的IPv6前缀，因为这样做会强制将来自SSs的所有IPv6数据包传输到AR，从而导致各个SSs之间的第3层分离
SSs. Alternatively, common IPv6 prefixes can be assigned to all SSs served by the same AR in order to exploit the efficient multicast support of Ethernet link in the network side. In this case, a Prefix Information Option (PIO) [RFC4861] carrying the common IPv6 prefixes SHOULD be advertised with the On-link flag (L-Flag) reset so that it is not assumed that the addresses matching the prefixes are available on-link.
SSs。或者，可以将公共IPv6前缀分配给由同一AR服务的所有SSs，以便利用网络侧以太网链路的高效多播支持。在这种情况下，承载公共IPv6前缀的前缀信息选项（PIO）[RFC4861]应通过链路上标志（L标志）重置进行通告，以便不假设与前缀匹配的地址在链路上可用。
The AR should relay packets between SSs within the same AR.
AR应在同一AR内的SSs之间中继数据包。
+-+--+
|H|SS| +- - - - - - - - - - +
+-+--+* +----+ | +------+
+-+--+ * | +-----+ | |
|H|SS|* * * * * *| BS +-----+Bridge+-+
+-+--+ * | +-----+ | | +-----+ |
* +----+ | +------+ | | B |
+-+--+ * | +-+ r | | +-------+
|H|SS|* | i +---+AR(NAS)+--
+---+ +-+--+ | | d | | +-------+
| H ++ +-+ g |
+---+ \ +----+ | +------+ | | e | |
+---+ +--+--+ | +----+ | | +-----+
| H +--+Br|SS|* * * * | BS | | |Bridge+-+ |
+---+ +--+--+ * | +----+ |
+---+ / * +----+ | +------+ |
| H ++ +-+--+ *
+---+ |H|SS|* | Bridging Function |
+-+--+ +- - - - - - - - - - +
+-+--+
|H|SS| +- - - - - - - - - - +
+-+--+* +----+ | +------+
+-+--+ * | +-----+ | |
|H|SS|* * * * * *| BS +-----+Bridge+-+
+-+--+ * | +-----+ | | +-----+ |
* +----+ | +------+ | | B |
+-+--+ * | +-+ r | | +-------+
|H|SS|* | i +---+AR(NAS)+--
+---+ +-+--+ | | d | | +-------+
| H ++ +-+ g |
+---+ \ +----+ | +------+ | | e | |
+---+ +--+--+ | +----+ | | +-----+
| H +--+Br|SS|* * * * | BS | | |Bridge+-+ |
+---+ +--+--+ * | +----+ |
+---+ / * +----+ | +------+ |
| H ++ +-+--+ *
+---+ |H|SS|* | Bridging Function |
+-+--+ +- - - - - - - - - - +
Figure 4: Public Access Network Using IEEE 802.16
图4：使用IEEE 802.16的公共接入网络
This recommendation does not introduce new vulnerabilities to IPv4 and IPv6 specifications or operations. The security of the IEEE 802.16 air interface between SSs and BS is the subject of [802.16], which provides the capabilities of admission control and ciphering of the traffic carried over the air interface. A Traffic Encryption Key (TEK) is generated by the SS and BS on completion of successful mutual authentication and is used to secure the air interface.
本建议不会给IPv4和IPv6规范或操作引入新的漏洞。SSs和BS之间的IEEE 802.16空中接口的安全性是[802.16]的主题，它提供了通过空中接口传输的流量的准入控制和加密能力。SS和BS在成功完成相互认证后生成流量加密密钥（TEK），用于保护空中接口。
The IEEE 802.16 Ethernet link model described in Section 5.1 represents a bridged (switched) Ethernet architecture with point-to-point links between the SS and its bridge port. Even though the bridged Ethernet model prevents messaging between SSs on the same link without passing through the bridge, it is still vulnerable, e.g., by malicious reconfiguration of the address table of the bridge
第5.1节中描述的IEEE 802.16以太网链路模型表示一种桥接（交换）以太网体系结构，在SS及其网桥端口之间具有点到点链路。即使桥接以太网模型防止同一链路上的SSs之间的消息传递不通过网桥，它仍然容易受到攻击，例如，通过恶意重新配置网桥的地址表
in the learning process. This recommendation does not cause new security issues beyond those that are already known for the bridged Ethernet architecture. For example, link security mechanisms according to [802.1AE] can be used on top of this recommendation to resolve the security issues of the bridged Ethernet.
在学习过程中。除了桥接以太网体系结构已知的安全问题外，本建议不会导致新的安全问题。例如，根据[802.1AE]的链路安全机制可用于解决桥接以太网的安全问题。
As the generic IP over Ethernet network using IEEE 802.16 emulates a standard Ethernet link, existing IPv4 and IPv6 security mechanisms over Ethernet can still be used. The public access network using IEEE 802.16 can secure isolation of each of the upstream links between hosts and AR by adopting SEcure Neighbor Discovery (SEND) [RFC3971] for securing neighbor discovery processes.
由于使用IEEE 802.16的通用IP over Ethernet网络模拟标准以太网链路，因此仍可使用现有的IPv4和IPv6以太网安全机制。使用IEEE 802.16的公共接入网络可以通过采用安全邻居发现（SEND）[RFC3971]来保护邻居发现过程，从而确保主机和AR之间的每个上游链路的隔离。
The authors would like to thank David Johnston, Dave Thaler, Jari Arkko, and others for their inputs to this work.
作者要感谢David Johnston、Dave Thaler、Jari Arkko和其他人对这项工作的投入。
[802.16] IEEE Std 802.16-2009, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", May 2009.
[802.16]IEEE Std 802.16-2009，“局域网和城域网的IEEE标准，第16部分：固定宽带无线接入系统的空中接口”，2009年5月。
[802.16k] IEEE Std 802.16k-2007, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges, Amendment 5: Bridging of IEEE 802.16", March 2007.
[802.16k]IEEE标准802.16k-2007，“局域网和城域网的IEEE标准，媒体访问控制（MAC）网桥，修改件5：IEEE 802.16的网桥”，2007年3月。
[802.1D] IEEE Std 802.1D-2004, "IEEE Standard for Local and metropolitan area networks, Media Access Control (MAC) Bridges", June 2004.
[802.1D]IEEE标准802.1D-2004，“局域网和城域网的IEEE标准，媒体访问控制（MAC）网桥”，2004年6月。
[802.1Q] IEEE Std 802.1Q-2005, "IEEE Standard for Local and metropolitan area networks, Virtual Bridged Local Area Networks", May 2005.
[802.1Q]IEEE Std 802.1Q-2005，“局域网和城域网的IEEE标准，虚拟桥接局域网”，2005年5月。
[RFC0826] 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.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC0894]Hornig，C.，“通过以太网传输IP数据报的标准”，STD 41，RFC 894，1984年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[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月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]Thomson，S.，Narten，T.，和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月。
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. Madanapalli, "Transmission of IPv6 via the IPv6 Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
[RFC5121]Patil，B.，Xia，F.，Sarikaya，B.，Choi，JH.，和S.Madanapalli，“通过IEEE 802.16网络上的IPv6聚合子层传输IPv6”，RFC 51212008年2月。
[802.1AE] IEEE Std 802.1AE-2006, "IEEE Standard for Local and metropolitan area networks Media Access Control (MAC) Security", August 2006.
[802.1AE]IEEE标准802.1AE-2006，“局域网和城域网媒体访问控制（MAC）安全的IEEE标准”，2006年8月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[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月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[RFC4562] Melsen, T. and S. Blake, "MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network", RFC 4562, June 2006.
[RFC4562]Melsen，T.和S.Blake，“MAC强制转发：以太网接入网络上用户分离的方法”，RFC 45622，2006年6月。
[RFC5154] Jee, J., Madanapalli, S., and J. Mandin, "IP over IEEE 802.16 Problem Statement and Goals", RFC 5154, April 2008.
[RFC5154]Jee，J.，Madanapalli，S.，和J.Mandin，“IP over IEEE 802.16问题陈述和目标”，RFC 5154，2008年4月。
Multicast CIDs are a highly efficient means to distribute the same information concurrently to multiple SSs under the same BS. However, the deployment of multicast CIDs for multicast or broadcast data services suffers from the following drawbacks.
多播cid是一种高效的方法，可以将相同的信息并发地分发到同一BS下的多个SSs。然而，为多播或广播数据服务部署多播cid存在以下缺点。
A drawback of multicast CIDs for Ethernet over IEEE 802.16 is the unidirectional nature of multicast CIDs. While it is possible to multicast information downstream to a number of SSs in parallel, there are no upstream multicast connections. In the upstream direction, unicast CIDs have to be used for sending multicast messages over the air to the BS, requiring a special multicast forwarding function for sending the information back to the other SSs on a multicast CID. While similar in nature to a bridging function, there is no appropriate forwarding model available. [802.1D] cannot take advantage of the multicast CIDs because it relies on unicast connections or bidirectional broadcast connections.
IEEE 802.16上以太网的多播CID的一个缺点是多播CID的单向性。虽然可以并行地向多个SSs的下游多播信息，但没有上游多播连接。在上行方向上，必须使用单播CID通过空中向BS发送多播消息，这需要特殊的多播转发功能以将信息发送回多播CID上的其他SSs。虽然本质上类似于桥接功能，但没有合适的转发模型可用。[802.1D]无法利用多播CID，因为它依赖于单播连接或双向广播连接。
A further drawback of deploying multicast CIDs for distributing broadcast control messages, like ARP Requests, is the inability to prevent the waking up of dormant-mode SSs by messages not aimed for them. Whenever a message is sent over a multicast CID, all associated stations have to power up and receive and process the message. While this behavior is desirable for multicast and broadcast traffic, it is harmful for link-layer broadcast control messages aimed for a single SS, like an ARP Request. All other SSs are wasting scarce battery power for receiving, decoding, and discarding the message. Low power consumption is an extremely important aspect in a wireless communication.
部署多播CID以分发广播控制消息（如ARP请求）的另一个缺点是无法防止非针对休眠模式SSs的消息唤醒它们。每当通过多播CID发送消息时，所有相关站点都必须通电并接收和处理该消息。虽然这种行为对于多播和广播流量是可取的，但对于针对单个SS的链路层广播控制消息（如ARP请求）是有害的。所有其他SSs都在浪费稀缺的电池电量来接收、解码和丢弃消息。低功耗是无线通信中一个极其重要的方面。
Furthermore, it should be kept in mind that multicast CIDs are only efficient for a large number of subscribed SSs in a cell. Due to incompatibility with advanced radio-layer algorithms based on feedback information from the receiver side, multicast connections require much more radio resources for transferring the same information as unicast connections.
此外，应该记住，多播cid仅对小区中大量订阅的SSs有效。由于与基于接收方反馈信息的高级无线层算法不兼容，多播连接需要更多的无线资源来传输与单播连接相同的信息。
This specification introduces a network-side bridging function, which can be realized either by a centralized device or by multiple interconnected bridges in a distributed manner. One common implementation of the distributed model is the scenario where a bridge is directly attached to the BS, such that the interface between BS and bridging function becomes a software interface within the operation system of the BS/bridge device.
本规范介绍了一种网络侧桥接功能，该功能可以由一个集中设备或多个互连网桥以分布式方式实现。分布式模型的一个常见实现是桥接器直接连接到BS的场景，使得BS和桥接功能之间的接口成为BS/桥接器设备的操作系统内的软件接口。
The operational enhancements described in Section 7 of this document are based on the availability of additional information about all the hosts attached to the Ethernet. Flooding all ports of the bridge can be avoided when a priori information is available to determine the port to which an Ethernet frame has to be delivered.
本文档第7节中描述的操作增强功能是基于所有连接到以太网的主机的附加信息的可用性。当有先验信息可用于确定以太网帧必须传送到的端口时，可以避免桥的所有端口泛洪。
Best performance can be reached by a centralized database containing all information about the hosts attached to the Ethernet. A centralized database can be established by either a centralized bridge device or a hierarchical bridging structure with dedicated uplink and downlink ports like in the public access case, where the uppermost bridge is able to retrieve and maintain all the information.
通过一个包含连接到以太网的主机的所有信息的集中式数据库，可以达到最佳性能。集中式数据库可以由集中式网桥设备或具有专用上行链路和下行链路端口的分层网桥结构建立，如在公共接入情况下，其中最上面的网桥能够检索和维护所有信息。
As the generic case of the IP over Ethernet over IEEE 802.16 link model does not make any assumptions about the location of the AR (an AR may eventually be attached to an SS), a centralized bridging system is recommended for the generic case. In the centralized system, every connection over the air of a link should be attached to a single centralized bridge.
由于IEEE802.16链路模型上的以太网IP的一般情况没有对AR的位置做出任何假设（AR可能最终连接到SS），因此建议针对一般情况使用集中式桥接系统。在集中式系统中，链路空中的每个连接都应连接到单个集中式网桥。
A distributed bridging model is appropriate, in particular, for the public access mode, where Ethernet frames, which do not have entries in the bridge behind the BS, are sent upstream until finally reaching a bridge that has an entry for the destination MAC address.
分布式桥接模型尤其适用于公共接入模式，其中，在BS后面的网桥中没有条目的以太网帧被向上游发送，直到最终到达具有目的地MAC地址条目的网桥。
Authors' Addresses
作者地址
Hongseok Jeon Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA
韩国大田裕胜县Gajeong dong 161号洪世全电子电信研究所，邮编305-350
Phone: +82-42-860-3892
EMail: hongseok.jeon@gmail.com
Phone: +82-42-860-3892
EMail: hongseok.jeon@gmail.com
Sangjin Jeong Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA
Sangjin Jeong电子电信研究所161 Gajeong dong，Yuseong gu Daejeon，305-350韩国
Phone: +82-42-860-1877
EMail: sjjeong@etri.re.kr
Phone: +82-42-860-1877
EMail: sjjeong@etri.re.kr
Max Riegel Nokia Siemens Networks St-Martin-Str 76 Munich, 81541 Germany
德国慕尼黑市圣马丁街76号诺基亚西门子网络有限公司，邮编81541
Phone: +49-89-5159-32728
EMail: maximilian.riegel@nsn.com
Phone: +49-89-5159-32728
EMail: maximilian.riegel@nsn.com