[要約] 要約： RFC 5692は、IEEE 802.16ネットワーク上のEthernet経由でIPを転送するためのプロトコル仕様を提供しています。目的： このRFCの目的は、IEEE 802.16ネットワーク上でのIP over Ethernetの効率的な転送を実現するためのガイドラインを提供することです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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（Convergence Sublayer）および一般的なパケットCS（GPCS）を定義して、上層のプロトコルに依存しないインターフェイスを提供します。このドキュメントでは、Packet CSのイーサネット固有の部分とIEEE 802.16に基づくAccessネットワークのGPCを介したイーサネットを介した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の特殊性の下で、イーサネットの動作を介した標準IPとの完全な互換性を維持しながら、IEEE 802.16を超えるイーサネット層にIP固有のサポート関数を追加することは理にかなっています。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [RFC5154].
このドキュメントの用語は、「802.16を超える問題声明と目標を超えるIP」[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 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.
BSとSSの間に複数の接続を確立でき、それぞれに特定のQoSクラスと方向を備えています。BSとすべてのSSSは一意の48ビットMACアドレスに関連付けられていますが、空中を介して進むパケットは、特定の接続のCID数によってIEEE 802.16 Macヘッダーでのみ識別されます。接続は、ネットワークエントリ中に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
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の管理目的で、Macアドレスに基づいて、付属のSSSのリストを確立および維持します。
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は、図1に示すように、特定のSSに属するすべてのユニキャスト接続をネットワーク側の単一のリンクにバンドルすることができます。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（マルチキャストおよびブロードキャストサービス）は、MBSがIPレイヤーに見えないため、IPブロードキャストまたはマルチキャストデータもカバーしていません。
IEEE 802.16 provides two solutions to transfer Ethernet frames over IEEE 802.16 MAC connections.
IEEE 802.16は、IEEE 802.16 Mac接続を介してイーサネットフレームを転送する2つのソリューションを提供します。
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.
今日の有線イーサネットネットワークのように、3つ以上のデバイス間の接続を実装するにはブリッジングが必要です。IEEE 802.16では、SSSとBSの間のポイントツーポイント接続を橋渡しすることができ、IEEE 802.16 Access Networkでイーサネットが実現されるようになります。
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の上にあるイーサネットを実現するには、図2に示すように、SSに属するすべてのポイントツーポイント接続をネットワーク側のブリッジング関数に接続する必要があります。ホストをブリッジに接続する繊維（「スイッチ」）。
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は、1つのSSに属するすべてのサービスフローを、ネットワーク側のブリッジング機能の1つのポートに転送する必要があります。ネットワーク側のブリッジング機能の1つのポートに1つ以下の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 --------------------------
[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
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, 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]とその修正[802.16K]に基づいて、接続されたSSSを相互接続し、接続されたSSSに関連付けられたポイントツーポイント接続間のイーサネットフレームを通過する必要があります。ただし、[802.1D]のセクション5.1に従って、ブロードキャストまたはマルチキャストパケットフラッディングを回避することにより、IEEE 802.16イーサネットリンクモデルを強化するために、[必須関数に加えて、ネットワーク側のブリッジング関数によって追加の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をIPリンクを表す各VLANで特定のVLANにグループ化することにより、ブロードキャストドメインのサイズとカバレッジを制限することができます。したがって、仮想ブリッジポートで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シナリオは、すべてのホストが同じリンクに存在していることを前提としています。これにより、ホストは迂回せずに互いに直接通信できます。リンクには複数のアクセスルーター（ARS）があり、図3に示すように、サブスクライバー側とネットワーク側の両方に存在する場合があります。
+--+--+
---|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-Over-Ethernetパケットを送信するホストは、[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.
Stateful Address Autoconfigurationが必要な場合、[RFC3315]によるステートフルアドレス構成を実行する必要があります。この場合、ARはIPv6（DHCPV6）サーバーまたはリレー機能の動的ホスト構成プロトコルをサポートします。
When stateless address autoconfiguration is required, the stateless address configuration according to [RFC4862] and [RFC4861] MUST be performed.
Stateless Address Autoconfigurationが必要な場合、[RFC4862]および[RFC4861]に応じたステートレスアドレス構成を実行する必要があります。
The Neighbor Discovery Protocol (NDP) [RFC4861] MUST be used for determining the destination Ethernet MAC address.
Neighbor Discovery Protocol（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]は、リンクレイヤーの最小最大透過ユニット（MTU）サイズとして1280バイトを義務付け、イーサネット伝送よりもIPv6に少なくとも1500バイトを推奨します。[RFC0894]は、イーサネット上のIPv4の最大長として1500バイトを指定しています。したがって、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 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.
IEEE 802.16を超えるイーサネットは、任意の構造のより大きなイーサネットの一部のみを構築する可能性があるため、イーサネットで実行可能なあらゆる種類のプレフィックス割り当ては、IEEE 802.16よりもイーサネットにも適用できます。イーサネットの動作を最適に使用するために、同じIPv4プレフィックスと同じIPv6プレフィックスのセットがイーサネットに接続されているすべてのホストに割り当てられる場合があります。プレフィックスを共有すると、同じサブネットワークですべてのホストを見つけることができます。
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マルチキャストデータを維持し、適切なポートのみに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ブロードキャストパケットをflood濫させます。この動作は、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.
IEEE 802.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.
IGMP関連のブロードキャストパケットは、[RFC4541]に従って転送できます。ARP関連の放送は、セクション7.3で指定されているように処理する必要があります。
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-Over-Ethernetの場合、DHCPV4クライアントは、DHCPV4サーバーを要求してDHCPV4サーバーを要求するDHCPDISCOVERおよびDHCPREQUESTメッセージを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.
あるいは、DHCP44ブロードキャスト返信を回避するために、DHCPリレーエージェント情報オプション（オプション82）[RFC3046]を使用できます。オプション82は、回路IDとリモートIDの2種類のサブオプションで構成されています。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-Over-Ethernetの場合、DHCPV6クライアントはLink-LocalアドレスとALL_DHCP_RELAY_AGENTS_SERVERS MULTICASTアドレスを使用して、リンク上のDHCPV6サーバーまたはリレーエージェントと通信します。したがって、DHCPV6関連のパケットはユニカストまたはマルチキャストです。ネットワーク側のブリッジング関数は、[802.1d]に基づいてDHCPV6関連のユニキャストパケットを処理し、セクション7.1.1で指定されているDHCP6関連のマルチキャストパケットを送信する必要があります。
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要求は通常、同じリンクのすべてのホストを解決するために、同じリンクのすべてのホストにブロードキャストされます。これにより、同じリンクのすべてのホストが乱されます。プロキシ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].
ネットワーク側のブリッジング関数は、すべてのサービングSSSのARPエントリを収容するのに十分な大きさのARPキャッシュを維持する必要があります。ARPキャッシュは、[802.1d]に従って、通常のLayer-2ブリッジングデバイスがフィルタリングデータベースを更新しているのと同じように、SSSからのARP要求を含む任意のパケットによって更新する必要があります。
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リクエストが浸水する可能性があります。ネットワーク側のブリッジング関数は、受信した自己アンプリクエストを静かに破棄する必要があります。
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-over-ethernetの場合、隣接する勧誘メッセージは、複製アドレスの検出を含むアドレス解決のために、勧誘されたノードマルチキャストアドレスにマルチキャストされます。勧誘されたノードマルチキャストアドレスは、同じリンク上のすべてのホストを邪魔することなく、ホストの効率的なクエリを容易にします。ネットワーク側のブリッジング関数は、セクション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からの下流トラフィックのために通常のブリッジング操作を実行する必要があり、セキュリティスキームの適用性を可能にするために、Bridge Secure Neighbord Discovery（send）[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 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.
IPv6-over-ethernetの場合、SSSからすべてのIPv6パケットをARに転送させ、したがってSSS間のレイヤー3分離をもたらすため、SSあたりの一意のIPv6プレフィックスを割り当てることができます。あるいは、ネットワーク側のイーサネットリンクの効率的なマルチキャストサポートを活用するために、同じARが提供するすべてのSSSに一般的なIPv6プレフィックスを割り当てることができます。この場合、一般的なIPv6プレフィックスを運ぶプレフィックス情報オプション（PIO）[RFC4861]は、オンリンクフラグ（L-FLAG）リセットで宣伝する必要があります。リンク。
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 |
+-+--+ +- - - - - - - - - - +
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]の主題であり、エアインターフェイスに及ぼすトラフィックの入場制御と暗号化の機能を提供します。トラフィック暗号化キー（TEK）は、成功した相互認証の完了時にSSおよびBSによって生成され、エアインターフェイスの保護に使用されます。
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 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.
セクション5.1で説明されているIEEE 802.16イーサネットリンクモデルは、SSとそのブリッジポートの間にポイントツーポイントリンクを持つブリッジ（スイッチ付き）イーサネットアーキテクチャを表しています。ブリッジ付きイーサネットモデルは、ブリッジを通過せずに同じリンク上のSSS間のメッセージングを防ぎますが、例えば、学習プロセスにおけるブリッジのアドレステーブルの悪意のある再構成により、依然として脆弱です。この推奨事項は、ブリッジ付きイーサネットアーキテクチャですでに知られているものを超えた新しいセキュリティ問題を引き起こしません。たとえば、[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が標準のイーサネットリンクをエミュレートするため、イーサネットを介した既存のIPv4およびIPv6セキュリティメカニズムを使用することができます。IEEE 802.16を使用したパブリックアクセスネットワークは、近隣発見プロセスを確保するために安全な近隣発見（送信）[RFC3971]を採用することにより、ホストとARの間の各上流リンクの分離を確保できます。
The authors would like to thank David Johnston, Dave Thaler, Jari Arkko, and others for their inputs to this work.
著者は、デビッド・ジョンストン、デイブ・タラー、ジャリ・アークコなどに感謝したいと思います。
[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 STD 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 STD 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。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、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 4861、2007年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 Stateless Address Autoconfiguration」、RFC 4862、2007年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 5121、2008年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 STD 802.1AE-2006、「ローカルおよびメトロポリタンエリアネットワークのメディアアクセス制御（MAC）セキュリティのIEEE標準」、2006年8月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、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、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年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 4562、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.
ARPリクエストのように、放送制御メッセージを配布するためのマルチキャストCIDを展開することのさらなる欠点は、それらを目的としていないメッセージによる休眠モードSSSの目覚めを防ぐことができないことです。マルチキャストCIDを介してメッセージが送信されるたびに、関連するすべてのステーションはメッセージを電源を入れて受信し、処理する必要があります。この動作はマルチキャストとブロードキャストトラフィックに望ましいが、ARPリクエストのような単一のSSを対象としたLink-Layer Broadcast Controlメッセージには有害です。他のすべての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.
この仕様では、ネットワーク側のブリッジング機能が導入されます。これは、集中型デバイスまたは複数の相互接続されたブリッジによって分散された方法で実現できます。分散モデルの一般的な実装の1つは、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.
IEEE 802.16リンクモデルを介したイーサネットを介したIPの一般的なケースは、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
Hongseok Jeon Electronics Telecommunications Research Institute 161 Gajeong-Dong、Yousong-Gu Daejeon、305-350 Korea
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 Electronics Telecommunications Research Institute 161 Gajeong-Dong、Yusong-Gu Daejeon、305-350 Korea
Phone: +82-42-860-1877
EMail: sjjeong@etri.re.kr
Max Riegel Nokia Siemens Networks St-Martin-Str 76 Munich, 81541 Germany
Max Riegel Nokia Siemens Networks St-Martin-Str76 Munich、81541ドイツ
Phone: +49-89-5159-32728
EMail: maximilian.riegel@nsn.com