Network Working Group J. Jee, Ed.
Request for Comments: 5154 ETRI
Category: Informational S. Madanapalli
Ordyn Technologies
J. Mandin
Runcom
April 2008
IP over IEEE 802.16 Problem Statement and Goals
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document specifies problems in running IP over IEEE 802.16 networks by identifying specific gaps in the IEEE 802.16 Media Access Control (MAC) for IPv4 and IPv6 support. This document also provides an overview of IEEE 802.16 network characteristics and convergence sublayers. Common terminology used for the base guideline while defining the solution framework is also presented.
この文書では、IPv4とIPv6をサポートするためのIEEE 802.16メディアアクセス制御（MAC）で特定のギャップを識別することにより、IEEE 802.16の上に網をIPを実行中に問題を指定します。また、このドキュメントでは、IEEE 802.16ネットワークの特性と収束副層の概要を説明します。ソリューションフレームワークを定義しながら、ベースガイドラインに使用される一般的な用語もまた提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the IEEE 802.16 MAC Layer . . . . . . . . . . . . 4
3.1. Transport Connections . . . . . . . . . . . . . . . . . . 4
3.2. IEEE 802.16 PDU Format . . . . . . . . . . . . . . . . . . 5
3.3. IEEE 802.16 Convergence Sublayer . . . . . . . . . . . . . 5
4. IP over IEEE 802.16 Problem Statement and Goals . . . . . . . 6
4.1. Root Problem . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Point-to-Point Link Model for IP CS: Problems . . . . . . 8
4.3. Ethernet-Like Link Model for Ethernet CS: Problems . . . . 9
4.4. IP over IEEE 802.16 Goals . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 12
Broadband Wireless Access networks address the inadequacies of low bandwidth wireless communication for user requirements such as high quality data/voice service, fast mobility, wide coverage, etc. The IEEE 802.16 Working Group on Broadband Wireless Access Standards develops standards and recommended practices to support the development and deployment of broadband Wireless Metropolitan Area Networks [IEEE802.16].
ブロードバンド無線アクセスネットワークは、このような高品質なデータ/音声サービス、高速で移動性、広いカバレッジなどのブロードバンド無線アクセス規格のIEEE 802.16ワーキンググループは、標準を開発するなど、ユーザーの要件については、低帯域幅の無線通信の不備に対処し、サポートするためのプラクティスを推奨しました開発やブロードバンドワイヤレスメトロポリタンエリアネットワーク[IEEE802.16]の展開。
Recently the WiMAX Forum, and in particular, its NWG (Network Working Group) is defining the IEEE 802.16 network architecture (e.g., IPv4, IPv6, Mobility, Interworking with different networks, AAA, etc.). The NWG is thus taking on work at layers above those defined by the IEEE 802 standards (typically limited to the physical and link-layers only). Similarly, WiBro (Wireless Broadband), a Korean effort, which focuses on the 2.3 GHz spectrum band, is also based on the IEEE 802.16 specification [IEEE802.16].
最近、WiMAXフォーラムは、特に、そのNWG（ネットワークワーキンググループ）は、IEEE 802.16ネットワークアーキテクチャ（例えば、IPv4の、IPv6の移動度、等の異なるネットワーク、AAA、と連動）を定義します。 NWGは、このようにIEEE 802規格で定義されたもの以上の層で仕事に取っている（典型的には、物理およびリンク層のみに限定されるもの）。同様に、2.3 GHzのスペクトル帯域に焦点を当ててワイブロ（ワイヤレスブロードバンド）、韓国の努力は、また、IEEE 802.16仕様[IEEE802.16]に基づいています。
IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at the MAC, physically arranged in a point-to-multipoint structure with the Base Station (BS) terminating one end of each connection and an individual Subscriber Station (SS) terminating the other end of each connection. The IEEE 802.16 convergence sublayer (CS) is at the uppermost part of the MAC that is responsible for assigning transmit-direction Service Data Units (originating from a higher layer application, e.g., IP or Ethernet at the BS or SS) to a specific outbound transport connection. IEEE 802.16 defines two convergence sublayer types, the ATM Convergence Sublayer (CS) and the Packet CS. The IP Specific Subpart (IP CS) and the 802.3 Ethernet Specific Subpart (Ethernet CS) of Packet CS are within the current scope of IETF efforts.
IEEE 802.16は、[IEEE802.16]物理的接続の一端を終端する基地局（BS）とポイントツーマルチポイント構造および個々の加入者局（に配置され、ポイントツーポイントおよび接続指向MACであります各接続のもう一方の端を終端SS）。 IEEE 802.16収束サブレイヤ（CS）は、送信方向サービスデータユニット（上位層アプリケーションからの発信、BSまたはSSで、例えば、IPまたはイーサネット（登録商標））は、特定の送信に割り当てる責任があるMACの最上部にありますトランスポート接続。 IEEE 802.16は、二つの収束サブレイヤタイプ、ATM収束サブレイヤ（CS）およびパケットCSを定義します。 IP特定サブパート（IP CS）およびパケットCSの802.3イーサネット具体サブパート（イーサネットCS）は、IETFの努力の電流範囲内です。
There is complexity in configuring the IP Subnet over IEEE 802.16 network because of its point-to-point connection-oriented feature and the existence of IP CS and Ethernet CS, which assume different higher-layer functionality. An IP Subnet is a topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses as specified in [RFC4903]. The IP Subnet configuration is dependent on the underlying link-layer's characteristic and decides the overall IP operation on the network. The IP CS and Ethernet CS of IEEE 802.16 assume different higher layer capabilities: IP routing functionality in the case of IP CS and bridging functionality in the case of Ethernet CS. This means that the link-layer's characteristics beneath IP can change according to the adopted convergence sublayers.
異なる上位層の機能を想定し、そのポイントツーポイント接続指向の機能およびIP CSとイーサネットCSの存在をIEEE 802.16ネットワーク上でIPサブネットを構成する際の複雑さは、あります。 IPサブネットは、[RFC4903]で指定されている接頭辞がさらに個々のアドレスに除いて細分化されていない、同じIPアドレスのプレフィックスを使用していますトポロジカル領域です。 IPサブネットの構成は、基礎となるリンク層の特性に依存しており、ネットワーク上の全体的なIP処理を決定します。 IP CSの場合にはIPルーティング機能とイーサネットCSの場合に機能をブリッジング：IP CS及びIEEE 802.16のイーサネット（登録商標）CSは、異なる上位層機能を引き受けます。これはIPの下にリンク層の特性を採用収束サブレイヤに応じて変更できることを意味します。
This document provides the feasible IP Subnet model for each IP CS and Ethernet CS and specifies the problems in running IP for each case. This document also presents an overview of IEEE 802.16 network characteristics specifically focusing on the convergence sublayers and the common terminology to be used for the base guideline while defining solution frameworks.
この文書では、各IP CSとイーサネットCSのための実現可能なIPサブネットモデルを提供し、それぞれのケースのためにIPを実行する際に問題を指定します。この文書はまた、具体的に収束副層と溶液フレームワークを定義しながら、基地指針のために使用される一般的な用語に焦点を当てたIEEE 802.16ネットワーク特性の概要を提示します。
Subscriber Station (SS): An end-user equipment that provides connectivity to the IEEE 802.16 networks. It can be either fixed/ nomadic or mobile equipment. In mobile environment, SS represents the Mobile Subscriber Station (MS) introduced in [IEEE802.16e].
加入者局（SS）：IEEE 802.16ネットワークへの接続を提供エンドユーザ機器。これは、固定/遊牧民やモバイル機器のいずれかになります。モバイル環境では、SSは、移動加入者局（MS）は[IEEE802.16e規格]に導入表します。
Base Station (BS): A generalized equipment set that provides connectivity, management, and control between the subscriber station and the IEEE 802.16 networks.
基地局（BS）、加入者局、およびIEEE 802.16ネットワークの間の接続、管理、および制御を提供する一般機器セット。
Access Router (AR): An entity that performs an IP routing function to provide IP connectivity for the subscriber station (SS or MS).
アクセスルータ（AR）：加入者局（SS又はMS）のためのIP接続性を提供するためにIPルーティング機能を実行するエンティティ。
Protocol Data Unit (PDU): This refers to the data format passed from the lower edge of the MAC to the PHY, which typically contains SDU data after fragmentation/packing, encryption, etc.
プロトコルデータユニット（PDU）：これは、典型的には、フラグメンテーション/パッキング、暗号化などの後にSDUデータを含むPHY、MACへの下縁部から渡されたデータ形式を指し
Service Data Unit (SDU): This refers to the data format passed to the upper edge of the MAC
サービスデータユニット（SDU）：これは、MACの上縁に渡されるデータ形式を指し
IP Subnet: Topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses as specified from [RFC4903].
IPサブネット：[RFC4903]から指定されたように、その接頭辞は、さらに個々のアドレスに除いて細分化されていない、同じIPアドレスのプレフィックスを使用していますトポロジカルエリア。
Link: Topological area bounded by routers, which decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet as specified from [RFC4903].
リンク：[RFC4903]から指定されるようにパケットを転送する際のIPv4 TTLまたはIPv6ホップ限界を減少ルータによって区切らトポロジカル領域、。
Transport Connection: The MAC layer connection in IEEE 802.16 between an SS (MS) and BS with a specific Quality of Service (QoS) attributes. Several types of connections are defined and these include broadcast, unicast, and multicast. Each transport connection is uniquely identified by a 16-bit connection identifier (CID). A transport connection is a unique connection intended for user traffic. The scope of the transport connection is between the SS (MS) and the BS.
トランスポート接続：サービス（QoS）の特定の品質とSS（MS）とBS間のIEEE 802.16におけるMAC層の接続属性。接続のいくつかのタイプが定義されており、これらは、ブロードキャスト、ユニキャスト、およびマルチキャストが含まれます。各トランスポート接続は、一意の16ビットの接続識別子（CID）によって識別されます。トランスポート接続は、ユーザトラフィックのために意図したユニークな接続です。トランスポート接続の範囲は、SS（MS）と基地局との間です。
Connection Identifier (CID): A 16-bit value that identifies a connection to equivalent peers in the IEEE 802.16 MAC of the SS (MS) and BS.
接続識別子（CID）：IEEE 802.16 SSのMAC（MS）及びBSにおける同等のピアへの接続を特定する16ビット値。
Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS defined in [IEEE802.16].
イーサネット（登録商標）CS：[IEEE802.16]で定義されたパケットCSの802.3 /イーサネットCS特定部分。
802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined in [IEEE802.16].
802.1Q CS：802.1Q（VLAN）[IEEE802.16]で定義されたパケットCSの特定の部分。
IP CS: The IP specific subpart of the Packet CS defined in [IEEE802.16].
IP CS：[IEEE802.16]で定義されたパケットCSのIP特定サブパート。
IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1 (Packet, IPv4)
IPv4のCS：CSパケットのIP特定のサブパート、分類1（パケット、IPv4）の
IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2 (Packet, IPv6).
IPv6のCS：パケットCS、分類2（パケットはIPv6）のIP特定サブパート。
IEEE 802.16 [IEEE802.16] is point-to-point and connection-oriented at the MAC, physically arranged in a point-to-multipoint structure with the BS terminating one end of each connection and an individual SS terminating the other end of each connection. Each SS in the network possesses a 48-bit MAC address. The BS possesses a 48-bit unique identifier called "BSId". The BS and SS learn each others' MAC Address/BSId during the SS's entry into the network. Additionally, the BS may possess a 48-bit MAC address, but this is only known to the SS if using the Ethernet CS.
IEEE 802.16 [IEEE802.16]は、ポイントツーポイントおよび物理的に、MACに接続指向の各接続の一端を終端BSとそれぞれのもう一方の端を終端個々SSとポイントツーマルチポイント構造に配置されています接続。ネットワーク内の各SSは48ビットのMACアドレスを持っています。 BSは「BSID」と呼ばれる48ビットの一意の識別子を有しています。 BSとSSは、ネットワークへのSSのエントリ中に互いのMACアドレス/ BSIDを学びます。また、BSは、48ビットのMACアドレスを有してもよいが、イーサネット（登録商標）CSを使用している場合、これは唯一のSSにはよく知られています。
User data traffic in both the BS-bound (uplink) and SS-bound (downlink) directions is carried on unidirectional "transport connections". Each transport connection has a particular set of associated parameters indicating characteristics such as cryptographic suite and quality of service.
BS-結合（アップリンク）とSS結合（下り）方向の両方におけるユーザデータトラフィックが一方向「トランスポート接続」に担持されています。各トランスポート接続は、暗号化スイートとサービスの品質などの特性を示す関連するパラメータの特定のセットを有します。
After successful entry of an SS to the IEEE 802.16 network, no data traffic is possible as there are no transport connections between the BS and the SS yet. Transport connections are established by a 3-message signaling sequence within the MAC layer (usually initiated by the BS).
IEEE 802.16ネットワークにSSの成功したエントリの後に、データトラフィックはBSとSSとの間には、トランスポート接続がまだ存在しないように可能ではありません。トランスポート接続は、MAC層（通常BSによって開始される）内の3メッセージシグナル配列によって確立されます。
A downlink-direction transport connection is regarded as "multicast" if it has been made available (via MAC signaling) to more than one SS. Uplink-direction connections are always unicast.
それは複数のSSに（MACシグナリングを介して）利用可能とされている場合、下り方向の転送接続は、「マルチキャスト」とみなされます。アップリンク方向の接続は、常にユニキャストです。
An IEEE 802.16 PDU (i.e., the format that is transmitted over the airlink) consists of a Generic MAC header, various optional subheaders, and a data payload.
IEEE 802.16 PDU（すなわち、エアリンクを介して送信されるフォーマット）がジェネリックMACヘッダ、様々な任意のサブヘッダ、及びデータのペイロードから成ります。
The IEEE 802.16 Generic MAC header carries the Connection Identifier (CID) of the connection with which the PDU is associated. We should observe that there is no source or destination address present in the raw IEEE 802.16 MAC header.
IEEE 802.16ジェネリックMACヘッダにはPDUが関連付けられているコネクションのコネクション識別子（CID）を運びます。我々は、生のIEEE 802.16 MACヘッダには送信元または宛先アドレスが存在しないことを確認すべきです。
The IEEE 802.16 convergence sublayer (CS) is the component of the MAC that is responsible for mapping between the MAC service and the internal connection oriented service of the MAC CPS (Common Part Sublayer), through classification and encapsulation. The classification process assigns transmit-direction Service Data Units (originating from a higher layer application, e.g., an IP stack at the BS or SS) to a specific outbound transport connection. The convergence sublayer maintains an ordered "classifier table". Each entry in the classifier table includes a classifier and a target CID. A classifier, in turn, consists of a conjunction of one or more subclassifiers -- where each subclassifier specifies a packet field (e.g., the destination MAC address in an Ethernet frame, or the Type of Service (TOS) field of an IP datagram contained in an Ethernet frame) together with a particular value or range of values for the field. To perform classification on an outbound Service Data Unit, the convergence sublayer proceeds from the first entry of the classifier table to the last, and evaluates the fields of the Service Data Unit for a match with the table entry's classifier. When a match is found, the convergence sublayer associates the Service Data Unit with the target CID (for eventual transmission), and the remainder of the IEEE 802.16 MAC and PHY processing can take place.
IEEE 802.16収束サブレイヤ（CS）は、MACサービスおよび分類およびカプセル化を介して、MAC CPS（共通部サブレイヤ）の内部接続指向サービスとの間のマッピングを担当してMACの成分です。分類プロセスは、特定の発信トランスポート接続に送信方向をサービスデータユニット（上位層アプリケーションからの発信、例えば、BSまたはSSでIPスタック）を割り当てます。コンバージェンスサブレイヤは、注文した「クラシファイアテーブル」を保持しています。分類子テーブル内の各エントリは、分類およびターゲットCIDを含みます。分類器は、順番に、一つ以上のsubclassifiersの組み合わせで構成されています - 各subclassifierは、パケットのフィールドを指定します（例えば、イーサネットフレームの宛先MACアドレス、またはIPデータグラムのサービス（TOS）フィールドのタイプが含まれています）イーサネットフレームで一緒にフィールドの値の特定の値または範囲を有します。アウトバウンドサービスデータユニットに分類を実行するには、コンバージェンスサブレイヤは、最後に分類子テーブルの最初のエントリから進み、テーブルエントリの分類器との試合のためにサービスデータユニットのフィールドを評価します。一致が見つかった場合、収束サブレイヤは、ターゲット（最終的な伝送のための）CIDとサービスデータユニットを関連付け、およびIEEE 802.16 MACおよびPHY処理の残りを行うことができます。
IEEE 802.16 defines two convergence sublayer types, the ATM CS and the Packet CS. The ATM CS supports ATM directly. The Packet CS is subdivided into three specific subparts.
IEEE 802.16は、2コンバージェンスサブレイヤの種類、ATM CSおよびパケットCSを定義します。 ATM CSは直接ATMをサポートしています。パケットCSは、3つの特定のサブパートに分割されています。
o "The IP Specific Subpart" carries IP packets over a point-to-point connection.
O「IP具体サブパートは、」ポイント・ツー・ポイント接続を介してIPパケットを運びます。
o "The 802.3 Ethernet Specific Subpart" carries packets encoded in the 802.3/Ethernet packet format with 802.3 style headers.
O「802.3イーサネット具体サブパートは、」802.3スタイルヘッダを持つ802.3 /イーサネットパケット形式で符号化されたパケットを運びます。
o "The 802.1Q VLAN Specific Subpart" carries 802 style packets that contain 802.1Q VLAN Tags.
O「802.1Q VLAN固有のサブパートは、」802.1Q VLANタグが含まれている802個のスタイルパケットを運びます。
Classifiers applied to connections at the time of connection establishment further classify and subdivide the nature of the traffic over a connection.
クラシファイアは、さらに接続を介してトラフィックの性質を分類し、細分化し、接続確立時に接続に適用されます。
The classifications that apply to the Ethernet CS include packet over the 802.3/Ethernet CS, IPv4 over the 802.3/Ethernet CS, IPv6 over the 802.3/Ethernet CS, 802.3/Ethernet CS with RObust Header Compression (ROHC) header compression and 802.3/Ethernet with Enhanced Compressed Real-Time Protocol (ECRTP) header compression.
イーサネット（登録商標）CSに適用される分類は802.3 /イーサネット（登録商標）CS、ロバストヘッダ圧縮（ROHC）ヘッダ圧縮と802.3 /イーサネット（登録商標）CS及び802.3 /イーサネット802.3 /イーサネット（登録商標）CS、IPv6を介し802.3 /イーサネット（登録商標）CS、IPv4の上のパケットを含みます強化された圧縮リアルタイムプロトコル（ECRTP）ヘッダ圧縮を持ちます。
The classifications that apply to the 802.1Q/VLAN CS include IPv4 over 802.1Q/VLAN and IPv6 over 802.1Q/VLAN.
802.1Q / VLAN CSに適用される分類は、802.1Q / VLAN上802.1Q / VLANおよびIPv6上のIPv4を含みます。
It should be noted that while the 802.3/Ethernet CS has a packet classification that does not restrict the IP version (packet over the 802.3/Ethernet CS), the IP CS and 802.1Q/VLAN CS do. All the IP classifiers for those CSs are either IPv4 or IPv6.
802.3 /イーサネットCSは、IPバージョン（802.3 /イーサネットCSを超えるパケット）を制限するものではありませんパケット分類、IP CSおよび802.1Q / VLAN CSが何を有していることに留意すべきです。これらのCSSのすべてのIPの分類は、IPv4またはIPv6のいずれかです。
The classifiers enable the MAC to be sure of the presence of fields in the headers and so to be able to apply the payload header suppression (PHS) feature of IEEE 802.16 to those headers.
分類器は、ヘッダー内のフィールドの存在を確認するので、これらのヘッダに、IEEE802.16のペイロードヘッダ抑制（PHS）機能を適用することができるようにMACを可能にします。
For the sake of brevity in this document, the following naming conventions will be used for particular classifications of particular subparts of particular CSs.
この文書に記載されている簡潔にするために、次の命名規則は、特定のCSの特定のサブパーツの特定の分類のために使用されます。
o IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet, IPv4)
O IPv4のCS：CSパケット、IP特定サブパート、分類1（パケット、IPv4）の
o IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet, IPv6)
O IPv6のCS：CSパケット、IP特定サブパート、分類2（パケット、IPv6）の
o Ethernet CS: Packet CS, 802.3/Ethernet Subpart, Classifier 3 (Packet, 802.3/Ethernet)
OイーサネットCS：パケットCS、802.3 /イーサネットサブパート、分類3（パケット、802.3 /イーサネット）
An implementation of IEEE 802.16 can support multiple CS types.
IEEE 802.16の実装では、複数のCSタイプをサポートすることができます。
We can observe that the CS type, subpart, and classification actually defines the type of data interface (e.g., IPv4/IPv6 or 802.3) that is presented by IEEE 802.16 to the higher layer application.
我々は、CS型、サブパートを観察することができ、および分類は、実際には、上位層アプリケーションにIEEE 802.16によって提示されたデータインターフェースの種類（例えば、IPv4の/ IPv6の又は802.3）を定義します。
The key issue when deploying IP over IEEE 802.16 networks is how to configure an IP Subnet over that link, which is connection-oriented and point-to-point in the MAC level. IP Subnet is a topological area that uses the same IP address prefix where that prefix is not further subdivided except into individual addresses. [RFC4903] There are three different IP Subnet models [RFC4968] that are possible for IEEE 802.16 network:
IEEE 802.16ネットワーク上でIPを導入する重要な問題は、MACレベルでの接続指向およびポイント・ツー・ポイントでそのリンク上でIPサブネットを設定する方法です。 IPサブネットは、その接頭辞は、さらに個々のアドレスに除いて細分化されていない、同じIPアドレスのプレフィックスを使用していますトポロジカル領域です。 [RFC4903] IEEE 802.16ネットワークのための可能な3つの異なるIPサブネットモデル[RFC4968]があります。
1) Point-to-point Link Model
1）ポイントツーポイントリンクモデル
2) Ethernet-like Link Model
2）イーサネットのようなリンクモデル
3) Shared IPv6 Prefix Link Model
3）共有のIPv6プレフィックスリンクモデル
The specific problems and issues when adopting the above IP Subnet models to the IEEE 802.16 network are as below:
具体的な問題や課題IEEE 802.16ネットワークに上記のIPサブネットモデルを採用し、以下の通りであります：
In the point-to-point link model, each SS under a BS resides on a different IP Subnet. Therefore, only a certain SS and an AR exist under an IP Subnet, and IP packets with destination address of link local scope are delivered only within the point-to-point link between a SS and an AR. PPP [RFC1661] has been widely used for this kind of point-to-point link. However, the direct use of PPP is not possible on the IEEE 802.16 network because IEEE 802.16 does not define a convergence sublayer, which can encapsulate and decapsulate PPP frames. Therefore, there needs to be a mechanism to provide a point-to-point link between an SS and an AR in case of IP CS. The other alternative is to utilize PPP over Ethernet by using the Ethernet CS. However, Ethernet CS assumes the upper layer's bridging functionality to realize the Ethernet-like link model.
ポイントツーポイントリンクモデルでは、BSの下の各SSは、異なるIPサブネット上に存在します。したがって、唯一の特定のSSとARは、IPサブネットの下に存在し、リンクローカルスコープの宛先アドレスを持つIPパケットのみSSとARとの間のポイントツーポイントリンク内に送達されます。 PPP [RFC1661]は広くポイントツーポイントリンクのこの種のために使用されてきました。 IEEE 802.16は、PPPフレームをカプセル化し、デカプセル化することができ、収束サブレイヤを定義していないためしかし、PPPの直接使用は、IEEE 802.16ネットワークでは不可能です。したがって、IP CSの場合にSSとARとの間のポイントツーポイントリンクを提供するためのメカニズムが必要です。他の代替は、イーサネットCSを使用してイーサネット上でPPPを利用することです。しかし、イーサネットCSは、イーサネットのようなリンクモデルを実現するために、上層のブリッジ機能を前提としています。
In the Ethernet-like link model, all SSs under an AR reside on the same IP Subnet. This also applies when SSs are connected with different BSs. This Ethernet-like link model assumes that underlying link-layer provides the equivalent functionality like Ethernet, for example, native broadcast and multicast. It seems feasible to apply IEEE 802.16's Ethernet CS to configure this link model. However, IEEE 802.16's MAC feature is still connection-oriented, and does not provide multicast and broadcast connection for IP packet transfer. Therefore, we need a mechanism like IEEE 802.1D to realize multicast and broadcast. Moreover, frequent IP multicast and broadcast signaling should be avoided so as not to wake up the SSs that are in sleep/idle mode [IEEE802.16e].
イーサネットのようなリンクモデルでは、ARの下のすべてのSSが同じIPサブネット上に存在します。 SSが異なるBSに接続されている場合にも適用されます。このイーサネットのようなリンクモデルは、基礎となるリンク層は、イーサネット、例えば、ネイティブブロードキャストおよびマルチキャストなどの同等の機能を提供することを前提としています。このリンクモデルを設定するには、IEEE 802.16のイーサネットCSを適用することが可能と思われます。しかし、IEEE 802.16のMAC機能はまだ接続指向であり、IPパケット転送のためのマルチキャストおよびブロードキャスト接続を提供していません。したがって、我々は、マルチキャストおよびブロードキャストを実現するIEEE 802.1Dのようなメカニズムが必要です。スリープ/アイドル・モード[IEEE802.16e規格]であるのSSを起動しないようにまた、頻繁にIPマルチキャストおよびブロードキャスト・シグナリングが回避されるべきです。
The shared IPv6 prefix link model eventually results in multi-link subnet problems [RFC4903]. In IEEE 802.16, the BS assigns separate IEEE 802.16 connections for SSs. Therefore, SSs are placed on different links. In this situation, distributing shared IPv6 prefix for SSs, which are placed on different links causes multi-link subnet problems. This applies to IP CS and even to Ethernet CS if no bridging functionality is implemented on top of the BS or between the BS and the AR.
共有のIPv6プレフィックスリンクモデルは、最終的にマルチリンクサブネット問題[RFC4903]になります。 IEEE 802.16では、BSはSSのための別個のIEEE 802.16接続を割り当てます。したがって、SSSが異なるリンクの上に配置されます。このような状況では、異なるリンク上に置かれているのSS用の共有IPv6プレフィックスを配布することはマルチリンクサブネット上の問題が発生します。何のブリッジ機能はBSの上またはBSとARの間に実装されていない場合、これはIP CSにしても、イーサネットCSに適用されます。
We identified the feasible IP Subnet models for IEEE 802.16 networks depending on the convergence sublayers. At the current stage, only the IP CS and Ethernet CS of IEEE 802.16 are within the scope of ongoing IETF work. Following are the feasible IP Subnet models for each convergence sublayer used.
私たちは、収束サブレイヤに応じて、IEEE 802.16ネットワークのための実現可能なIPサブネットモデルを同定しました。現在の段階では、IEEE 802.16の唯一のIP CSとイーサネットCSは、現在進行中のIETF仕事の範囲内です。使用される各コンバージェンス・サブレイヤのための実現可能なIPサブネットモデルは次のとおり。
According to the point-to-point feature of the IEEE 802.16 MAC, the Point-to-Point link model is the feasible IP Subnet model in the case of IP CS. For the Ethernet CS, the Ethernet-like link model is the feasible IP Subnet model. However, in this model unnecessary multicast and broadcast packets within an IP Subnet should be minimized.
IEEE 802.16 MACのポイント・ツー・ポイントの特徴によれば、ポイントツーポイントリンクモデルは、IP CSの場合、実現可能なIPサブネットモデルです。イーサネットCSの場合は、イーサネットのようなリンクモデルは、実現可能なIPサブネットモデルです。しかし、このモデルではIPサブネット内の不要なマルチキャストおよびブロードキャストパケットが最小化されなければなりません。
- Address Resolution:
- アドレス解決：
Address Resolution is the process by which IP nodes determine the link-layer address of a destination node on the same IP Subnet given only the destination's IP address. In the case of IP CS, the IEEE 802.16 MAC address is not used as part of the IEEE 802.16 frame so typical usage of the Address Resolution Protocol (ARP) or Neighbor cache does not apply. Thus, performing the address resolution may be redundant in the case of IP CS. For IPv4, ARP cannot be carried by the IP CS, so is not used either by the SS or by the BS. For IPv6, address resolution is the function of IP layer, and IP reachability state is maintained through neighbor discovery packets. Therefore, blocking neighbor discovery packets would break the neighbor unreachability detection model.
アドレス解決は、IPノードのみが送信先のIPアドレスを与えられた同じIPサブネット上の宛先ノードのリンク層アドレスを決定するプロセスです。 IP CSの場合は、IEEE 802.16 MACアドレスはそれほどアドレス解決プロトコル（ARP）またはネイバーキャッシュの一般的な使用法は適用されませんIEEE 802.16フレームの一部として使用されていません。これにより、アドレス解決を実行することIP CSの場合に冗長であってもよいです。 IPv4の場合、ARPはIP CSによって実行することができないので、SSまたはBSのいずれかによって使用されていません。 IPv6の場合、アドレス解決は、IP層の機能であり、IP到達可能性状態は近隣探索パケットを介して維持されます。そのため、近隣探索パケットを遮断することは、近隣到達不能検出モデルを破ります。
- Router Discovery:
- ルーター検出：
The BS needs to send the Router Advertisement (RA) with separate IP prefix in unicast manner for each SS explicitly to send periodic router advertisements in IEEE 802.16 Networks.
BSは、IEEE 802.16ネットワークにおける定期的なルータアドバタイズメントを送信するために、明示的に各SSのためにユニキャストで別々のIPプレフィックスをルータ広告（RA）を送信する必要があります。
- Prefix Assignment:
- プレフィックスの割り当て：
Separate IP prefix should be distributed for each SS to locate them on different IP Subnets. When an SS moves between BSs under the same AR, the AR needs to redistribute the same IP Subnet prefix, which the SS used at the previous BS.
個別のIPプレフィックスは、異なるIPサブネット上でそれらを見つけるために、各SSのために分散されなければなりません。 SSは、同一のAR下で基地局間を移動するとき、ARは、SSは、前のBSで使用したのと同じIPサブネットプレフィックスを再配布する必要があります。
- Next-Hop:
- ネクストホップ：
SS's next-hop always needs to be the AR that provides the IP connectivity at that access network.
SSのネクストホップは常にそのアクセスネットワークでIP接続を提供するARにする必要があります。
- Neighbor Unreachability Detection (NUD):
- 近隣到達不能検出（NUD）：
Because the SS always sees an AR as the next hop, the NUD is required only for that AR. Also the requirement of NUD may depend on the existence of a connection to the BS for that particular destination.
SSは、常にネクストホップとしてARを見ているので、NUDは、それだけでARのために必要です。また、NUDの要件は、特定の宛先のBSへの接続の有無に依存してもよいです。
- Address Autoconfiguration:
- アドレス自動：
Because a unique prefix is assigned to each SS, the IP Subnet consists of only one SS and an AR. Therefore, duplicate address detection (DAD) is trivial.
ユニークなプレフィックスは、各SSに割り当てられているため、IPサブネットは、唯一のSSとARで構成されています。したがって、重複アドレス検出（DAD）が自明です。
- Address Resolution:
- アドレス解決：
For Ethernet CS, the sender needs to perform an address resolution to fill the destination Ethernet address field even though that address is not used for transmitting an IEEE 802.16 frame on the air. That Ethernet destination address is used for a BS or bridge to decide where to forward that Ethernet frame after decapsulating the IEEE 802.16 frame. When the destination's IP address has the same address prefix with its own, the sender should set the Ethernet frame's destination address as the destination itself. To acquire that address, the address resolution should be performed throughout conventional broadcast- and multicast-based ARP or Neighbor Discovery Protocol (NDP). However, if not filtered (e.g., [RFC4541]), these multicast and broadcast packets result in the problem of waking up the SSs that are in sleep/idle mode [IEEE802.16e].
イーサネット（登録商標）CSのために、送信者は、そのアドレスが空気にIEEE 802.16フレームを送信するために使用されていなくても、宛先イーサネットアドレスフィールドを埋めるためのアドレス解決を実行する必要があります。そのイーサネット宛先アドレスは、IEEE 802.16フレームをデカプセル化した後、そのイーサネットフレームの転送先を決定するBSまたはブリッジのために使用されます。送信先のIPアドレスが、自身と同じアドレスプレフィックスを持っている場合、送信者は送信先自体として、イーサネットフレームの送信先アドレスを設定する必要があります。そのアドレスを取得し、アドレス解決は、従来の放送・マルチキャストベースARPまたは近隣探索プロトコル（NDP）を通じて行われるべきです。しかしながら、濾過されていない場合（例えば、[RFC4541]）、これらのマルチキャストおよびブロードキャストパケットがスリープ/アイドル・モード[IEEE802.16e規格]であるのSSをウェイクアップするという問題を生じます。
- Router Discovery:
- ルーター検出：
All SSs under the AR are located in the same broadcast domain in the Ethernet-like link model. In this environment, sending periodic Router Advertisements with the destination of all-nodes multicast address results in the problem of waking up the SSs that are in sleep/idle mode [IEEE802.16e].
すべてのSSは、ARの下で、イーサネットのようなリンクモデルで同じブロードキャストドメイン内に位置しています。この環境で、[IEEE802.16e規格]スリープ/アイドルモードにあるのSSをウェイクアップの問題で全ノードマルチキャストアドレス結果の宛先で周期的ルータ広告を送信します。
- Prefix Assignment:
- プレフィックスの割り当て：
Because the same IP prefix is shared with multiple SSs, an IP Subnet consists of multiple SSs and an AR. The SS assumes that there exist on-link neighbors and tries to resolve the L2 address for the on-link prefixes. However, direct communication using link-layer address between two SSs is not possible with Ethernet CS alone; bridging functionality must be added on top of the BS or between the BS and AR.
同じIPプレフィックスは複数のSSで共有されているため、IPサブネットは複数のSSとARで構成されています。 SSは、オンリンクネイバーが存在することを前提とオンリンクプレフィックスのL2アドレスを解決しようとします。しかし、2つのSSの間のリンク層アドレスを使用して直接通信は、単独で、イーサネットCSでは不可能です。ブリッジング機能は、BSの上またはBSとARの間に追加されなければなりません。
- Next-Hop:
- ネクストホップ：
When Ethernet CS is used and the accompanying Ethernet capability emulation is implemented, the next-hop for the destination IP with the same global prefix with the sender or link local address type should be the destination itself not an AR.
イーサネットCSを使用して目的地については、付属のイーサネット機能のエミュレーションが実装され、ネクストホップIP同じグローバル接頭辞で、送信者またはローカルアドレスタイプをリンクされている場合、宛先そのものではないARでなければなりません。
- Neighbor Unreachability Detection (NUD):
- 近隣到達不能検出（NUD）：
All SSs under the same AR are all the neighbors. Therefore, the NUD is required for all the SSs and AR.
同じARの下のすべてのSSは、すべての隣接しています。したがって、NUDは全てのSSとARのために必要とされます。
- Address Autoconfiguration:
- アドレス自動：
Duplicate Address Detection (DAD) should be performed among multiple SSs and an AR, which use the same IP prefix. The previous multicast-based DAD causes the problem of waking up the SSs that are in sleep/ idle mode [IEEE802.16e].
アドレス検出（DAD）は、複数のSSと同じIPプレフィックスを使用AR、間に行わなければならない重複。以前のマルチキャストベースのDADは[IEEE802.16e規格】スリープ/アイドルモードにあるのSSをウェイクアップの問題が生じます。
The following are the goals in no particular order that point at relevant work to be done in IETF.
以下は関連する仕事でのポイントは、IETFで行われることを順不同目標です。
Goal #1. Define the way to provide the point-to-point link model for IP CS.
目標＃1。 IP CSのためのポイントツーポイントリンクモデルを提供する方法を定義します。
Goal #2. Reduce the power consumption caused by waking up sleep/idle [IEEE802.16e] terminals for Ethernet-like link model.
目標＃2。イーサネットのようなリンクモデルのためのスリープ/アイドル[IEEE802.16e規格]端子を目覚めによる電力消費を削減します。
Goal #3. Avoid multi-link subnet problems.
目標＃3。マルチリンクサブネット上の問題を回避します。
Goal #4. Allow applicability of security schemes such as SEcure Neighbor Discovery (SEND) [RFC3971].
目標＃4。安全な近隣探索（SEND）[RFC3971]などのセキュリティスキームの適用を可能にします。
Goal #5. Do not introduce any new security threats.
目標＃5。新たなセキュリティの脅威を導入しないでください。
Goal #6. Review management requirements and specifically the interfaces and specific management model (objects) for IP over IEEE 802.16 in collaboration with IEEE 802.16 working group.
目標＃6。 IEEE 802.16ワーキンググループと共同でIEEE 802.16オーバーIPのレビュー管理要件、具体的インターフェースと特定の管理モデル（オブジェクト）。
This documents describes the problem statement and goals for IP over IEEE 802.16 networks and does not introduce any new security threats. The IEEE 802.16 link-layer employs cryptographic security mechanisms as specified in [IEEE802.16][IEEE802.16e].
この文書は、IEEE 802.16ネットワーク上でIPのための問題声明と目標を説明し、新たなセキュリティの脅威を導入していません。 IEEE 802.16リンク層は、[IEEE802.16e規格] [IEEE802.16]で指定されるように暗号化セキュリティ・メカニズムを採用しています。
This document is a joint effort of the problem statement team of the IETF 16ng Working Group. The team members include Junghoon Jee, Syam Madanapalli, Jeff Mandin, Gabriel Montenegro, Soohong Daniel Park, and Maximilian Riegel.
この文書は、IETF 16ngワーキンググループの問題文チームの共同の努力です。チームのメンバーはJunghoonジヨン、Syam Madanapalli、ジェフMandin、ガブリエルモンテネグロ、Soohongダニエル・パーク、マクシミリアンリーゲルが含まれます。
The problem statement team members can be reached at:
問題文のチームのメンバーがで到達することができます。
Junghoon Jee, jhjee@etri.re.kr
Junghoonジヨン、jhjee@etri.re.kr
Syam Madanapalli, smadanapalli@gmail.com
シャムのmadanapalli、సమాధానపల్లి@జిమెయిల్.కం
Jeff Mandin, j_mandin@yahoo.com
ジェフMandin、j_mandin@yahoo.com
Gabriel Montenegro, g_e_montenegro@yahoo.com
ガブリエルモンテネグロ、g_e_montenegro@yahoo.com
Soohong Daniel Park, soohong.park@samsung.com
Soohongダニエル・パーク、soohong.park@samsung.com
Maximilian Riegel, maximilian.riegel@nsn.com
マクシミリアンリーゲル、maximilian.riegel@nsn.com
The authors would like to express special thank to David Johnston for his help with Section 3, "Overview of the IEEE 802.16 MAC Layer", and for carefully reviewing the entire document, and also to Phil Roberts for suggesting the reorganization of the document depending on the baseline IP subnet models.
著者は、に応じて、文書の再編成を示唆するために、第3節で彼の助けのためにデビッド・ジョンストンに特別な感謝を表現するために、「IEEE 802.16 MACレイヤの概要」を希望し、慎重に文書全体を再検討するために、また、フィル・ロバーツにベースラインのIPサブネットモデル。
The authors also would like to thank Jari Arkko, HeeYoung Jung, Myung-Ki Shin, Eun-Kyoung Paik, Jaesun Cha, and the KWISF (Korea Wireless Internet Standardization Forum) for their comments and contributions.
著者はまた、彼らのコメントと貢献のためにヤリArkko、HeeYoungユング、ミョン-KI新、ウン・ヘギョンパイク、Jaesunちゃ、とKWISF（韓国無線インターネット標準化フォーラム）を感謝したいと思います。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[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月。
[IEEE802.16] IEEE Std 802.16-2004, "IEEE Standard for Local and metropolitan area networks, Part 16: Air Interface for Fixed Broadband Wireless Access Systems", October 2004.
[IEEE802.16] IEEE標準802.16-2004、「ローカルおよびメトロポリタンエリアネットワークのためのIEEE規格、パート16：固定ブロードバンド無線アクセスシステムのためのエアインタフェース」、2004年10月。
[IEEE802.16e] IEEE Std 802.16e, "IEEE standard for Local and metropolitan area networks, Part 16:Air Interface for fixed and Mobile broadband wireless access systems", October 2005.
[IEEE802.16e規格] IEEE STDの802.16eの、「ローカルおよびメトロポリタンエリアネットワークのためのIEEE標準、パート16：固定およびモバイルブロードバンドワイヤレスアクセスシステムのためのエアインタフェース」、2005年10月。
[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）スヌーピングスイッチの考慮事項"。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903]ターラー、D.、 "マルチリンクサブネットの問題"、RFC 4903、2007年6月。
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 Based Networks", RFC 4968, August 2007.
[RFC4968] Madanapalli、S.、 "802.16ベースのネットワークのIPv6リンクモデルの分析"、RFC 4968、2007年8月。
Authors' Addresses
著者のアドレス
Junghoon Jee (editor) ETRI 161 Gajeong-dong Yuseong-gu Daejeon 305-700 Korea
Junghoonジヨン（エディタ）ETRI 161 Gajeong洞儒城区大田305から700韓国
Phone: +82 42 860 5126 EMail: jhjee@etri.re.kr
電話：+82 42 860 5126 Eメール：jhjee@etri.re.kr
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
1つのサム服フロアmadanapalli ordhyam技術、創造主の建物、バンガロールaitipil - 560066、インド
EMail: smadanapalli@gmail.com
メールアドレス：smadanapalli@gmail.com
Jeff Mandin Runcom
ジェフMandin Runcom社
EMail: j_mandin@yahoo.com
メールアドレス：j_mandin@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。