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
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セルラー無線伝送技術を導入するアクセスネットワークで、イーサネット上でイーサネット、などのIPv6上でのIPv4の送信を説明します。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さ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
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（GPCS）とインターフェースするためのパケットCS（収束サブレイヤ）を定義します。この文書では、IEEE 802.16に基づいて、アクセスネットワーク内のGPCSのパケットCS同様のイーサネット固有部分を介してイーサネット上の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（基地局）とその関連のSS（加入者局）を接続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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terminology in this document is based on the definitions in "IP over 802.16 Problem Statement and Goals" [RFC5154].
この文書に記載されている用語は、「IP 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およびその関連のSSの間の接続を確立します。これらの接続のそれぞれは、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及び全てのSSは、一意の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アドレスに基づいて添付SSのリストを確立し、維持します。
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アドレスは全てのBSと同様のSSに割り当てられているが、無線でパケットの転送のみ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.
図1に示すように、それが提供するようによる個々のSSへのサービスフローと関連付けられたCID値の管理割り当てに、BSは、ネットワーク側の単一のリンクに特定の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パケットのための双方向のネイティブブロードキャストおよびマルチキャストをサポートしていません。ダウンリンク接続がSSのグループにマルチキャスト送信、ならびに単一SSのBSからユニキャスト送信のために使用することができるが、BSへのSSからのアップリンク接続は、ユニキャスト送信能力を提供します。また、ダウンリンクマルチキャスト伝送を実現するためのマルチキャスト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.
MBSは、IP層に見えないので、MBS（マルチキャストおよびブロードキャスト・サービス）は、IEEE 802.16で指定され、また、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.
今日の有線イーサネットネットワークのように、ブリッジングは、二つ以上のデバイス間の接続を実現するために必要とされます。イーサネットは、IEEE 802.16アクセスネットワークを介して実現されるように、IEEE 802.16において、スライドシートとBSとの間のポイントツーポイント接続をブリッジすることができます。
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は、ネットワーク側のブリッジング機能の1つのポートに1つのSSに属するすべてのサービスフローを転送する必要があります。いいえ複数のSSは、ネットワーク側のブリッジ機能の1つのポートに接続されてはなりません。 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]、別名subscriber-すべての加入者側ポートと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
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は、ネットワークの基地局のいずれかに取り付けられるたびに、ネットワーク側ブリッジ機能は、新たな無線側ポートを作成する必要があり、または関連するSSが基地局から離れたときには、無線側ポートを削除する必要があります。ネットワーク側ブリッジ機能のポートを管理するための方法は、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].
ネットワーク側ブリッジ機能は、添付のSSを相互接続し、添付のSSに関連付けられたポイントツーポイント接続との間のイーサネットフレームを渡す[802.1D]及びその改正[802.16k]に基づいていなければなりません。しかしながら、ブロードキャストまたはマルチキャストパケットのフラッディングを回避することにより、IEEE 802.16、イーサネット・リンク・モデルを強化するために、追加のIP特有の機能は、[802.1D]のセクション5.1によれば、必須の機能に加えて、ネットワーク側ブリッジ機能によって提供されてもよいです。
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.
これでは、VLANにIEEE 802.16上のイーサネットをセグメント化し、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パケットの伝送を規定します。これは、イーサネットMACアドレスにマッピングするIPアドレスのイーサネットフレームにIPv4パケットのカプセル化の仕様と同様のルールを含んでいます。 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パケットの伝送を規定します。その文書は、イーサネット・アドレス（すなわち、MACアドレス）にマッピングIPv6アドレスのための規則を含みます。 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に休止モードでのSSを乱すことができます。したがって、AdvDefaultLifetimeとMaxRtrAdvIntervalは[RFC5121]セクション8.3で指定された高い値で上書きされるべきです。
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]は、リンク層のための最小の最大伝送単位（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プレフィックスの同じセットは、イーサネット行動の最良の使用を作るために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イーサネットリンクモデルでは、ネットワーク側のブリッジ機能がIPマルチキャストメンバシップ状態を維持し、適しポートだけにIPマルチキャストデータを転送するために、[RFC4541]に記載のすべてのマルチキャストデータとマルチキャスト制御メッセージを処理することができますマルチキャストグループ。
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.
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]に従って転送することができます。セクション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.
放送がそのDHCPOFFERとDHCPACKメッセージをブロードキャストするDHCPv4サーバを要求するビットセットとのIPv4オーバーイーサネット（登録商標）の場合に、DHCPv4のクライアントは、DHCPDISCOVERとDHCPREQUESTメッセージを送信することができます。ネットワーク側のブリッジ機能は、これらの放送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の放送回答を避けるために使用することができます。サーキットIDとリモートID：オプション82は、サブオプションの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のオーバー・イーサネットの場合には、DHCPv6クライアントは、発見し、そのリンク上のDHCPv6サーバまたはリレーエージェントと通信するために彼らのリンクローカルアドレスとAll_DHCP_Relay_Agents_and_Serversマルチキャストアドレスを使用します。したがって、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のオーバー・イーサネットの場合、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].
ネットワーク側のブリッジ機能は、すべてのサービス提供のSSのためのARPエントリを収容するのに十分な大きさのARPキャッシュを維持する必要があります。 ARPキャッシュは、通常のレイヤ2ブリッジ装置は、[802.1D]に従ってそのフィルタリングデータベースを更新しているのと同じ方法でのSSからの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への返信ユニキャストSHOULD、ターゲットアドレスが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.
NASとしてAR機能場合、加入者端末からのすべてのトラフィックは、ARに転送されるべき、ネットワーク側ブリッジ機能に架橋しない - さえSS間のトラフィックの場合には同一のARによってサーブ。ブリッジは、ARに向かってホストからアップストリームトラフィックを転送するべきであるが、ARの下流側トラフィックのため、通常のブリッジ動作を行わなければならなくて、セキュリティ方式の適用を可能にするために、セキュア近隣探索（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のオーバーイーサネット場合、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
そうすることの間にレイヤ3の分離にAR、したがって結果を転送するのSSからのすべてのIPv6パケットを強制するためのIPv6オーバーイーサネットの場合、SSごとに一意のIPv6プレフィックスを割り当てることができ
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.
SS。また、一般的なIPv6プレフィックスがsssは、ネットワーク側のイーサネットリンクの効率的なマルチキャストサポートを利用するために、同じARが提供するすべてに割り当てることができます。この場合、共通のIPv6プレフィックスを搬送するプレフィックス情報オプション（PIO）[RFC4861]はオンリンクフラグ（L-フラグ）は、それがプレフィクスと一致するアドレスがオン利用可能であることが想定されていないようにリセットしてアドバタイズされるべきですリンク。
The AR should relay packets between SSs within the same AR.
ARは同じAR内SS間のパケットを中継する必要があります。
+-+--+
|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の仕様や操作に新しい脆弱性を導入しません。 SSと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およびそのブリッジポートとの間のポイントツーポイントリンクを持つブリッジ（スイッチ）イーサネットアーキテクチャを表します。ブリッジイーサネットモデルはブリッジを通過することなく、同じリンク上のSSの間のメッセージングを防止したとしても、それは学習過程におけるブリッジのアドレステーブルの悪質な再構成により、例えば、まだ脆弱です。この勧告は、すでにブリッジイーサネットアーキテクチャのために知られているものを超えて、新たなセキュリティ上の問題を引き起こすことはありません。例えば、[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.
イーサネットネットワーク上の一般的なIPとしてIEEE 802.16を使用してイーサネット上の標準のイーサネットリンク、既存の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.
作者はこの仕事にデビッド・ジョンストン、デーブターラー、ヤリ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標準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 802.1D STD-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 802.1Q STD-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]プラマー、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]デアリング、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パケットのトランスミッション"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、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]パティル、B.、夏、F.、Sarikaya、B.、チェ、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]パトリック、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.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[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.ブレイク、 "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]ジヨン、J.、Madanapalli、S.、およびJ. Mandin、RFC 5154、2008年4月 "IP IEEE 802.16問題文と目標を超えます"。
Appendix A. Multicast CID Deployment Considerations
付録A.マルチキャストCID展開の考慮事項
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の下で複数のSSに同時に同じ情報を配布するための非常に効率的な手段です。しかし、マルチキャストまたはブロードキャストデータサービスのためのマルチキャスト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の一方向性の性質です。それが並列に下流のSSの数に情報をマルチキャストすることは可能であるが、いかなる上流マルチキャスト接続は存在しません。アップストリーム方向では、ユニキャストのCIDは、BSに無線でマルチキャストメッセージを送信するマルチキャストCIDに戻って、他のSSへの情報を送信するための特別なマルチキャスト転送機能を要求するために使用されなければなりません。ブリッジ機能と本質的に類似しているが、利用可能な適切な転送モデルは存在しません。それは、ユニキャスト接続または双方向放送の接続に依存しているので、[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を展開のさらなる欠点は、それらを目的としていないメッセージによって休眠モードSSの目覚めを防ぐことができないことです。メッセージは、マルチキャストCIDを介して送信されるたびに、すべての関連するステーションがパワーアップし受信したメッセージを処理する必要があります。この動作は、マルチキャストおよびブロードキャストトラフィックのために望ましいが、それはARP要求のように、単一SSを目的としたリンク層ブロードキャスト制御メッセージのために有害です。他のすべてのSSは、受信復号、メッセージを廃棄するための乏しいバッテリ電力を浪費しています。低消費電力無線通信で非常に重要な側面です。
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は、細胞内で、サブスクライブのSSの数が多いためにのみ効率的であることを心に留めておくべきです。受信側からのフィードバック情報に基づいて、高度な無線レイヤアルゴリズムと互換性がないため、マルチキャスト接続をユニキャスト接続と同じ情報を転送するためのはるかに無線リソースを必要とします。
Appendix B. Centralized vs. Distributed Bridging
分散型ブリッジ対付録B.一元化
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.
AR（ARが最終的にSSに結合していてもよい）の位置に関する仮定を行わないIEEE 802.16リンクモデル上のイーサネットオーバーIPの一般的な場合として、集中ブリッジシステムは、一般的なケースのために推奨されています。集中型システムでは、リンクの空気上すべての接続は、単一の集中ブリッジに取り付けられなければなりません。
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チョン・電子通信研究院161 Gajeong洞、儒城区大田、305から350 KOREA
Phone: +82-42-860-3892 EMail: hongseok.jeon@gmail.com
電話：+ 82-42-860-3892 Eメール：hongseok.jeon@gmail.com
Sangjin Jeong Electronics Telecommunications Research Institute 161 Gajeong-dong, Yuseong-gu Daejeon, 305-350 KOREA
Sangjinチョン電子通信研究院161 Gajeong洞、儒城区大田、305から350 KOREA
Phone: +82-42-860-1877 EMail: sjjeong@etri.re.kr
電話：+ 82-42-860-1877 Eメール：sjjeong@etri.re.kr
Max Riegel Nokia Siemens Networks St-Martin-Str 76 Munich, 81541 Germany
マックスリーゲルノキアシーメンスネットワークスサンマルタンのStr 76ミュンヘン、ドイツ81541
Phone: +49-89-5159-32728 EMail: maximilian.riegel@nsn.com
電話：+ 49-89-5159-32728 Eメール：maximilian.riegel@nsn.com