[要約] 要約：RFC 5154は、IP over IEEE 802.16の問題と目標について説明しています。 目的：IEEE 802.16ネットワーク上でのIP通信の問題を特定し、解決策を提案することを目指しています。
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
IEEE 802.16の問題の声明と目標を超えるIP
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
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].
ブロードバンドワイヤレスアクセスネットワークは、高品質のデータ/音声サービス、高速モビリティ、幅広いカバレッジなどのユーザー要件のための低帯域幅のワイヤレス通信の不備に対処します。ブロードバンドワイヤレスメトロポリタンエリアネットワークの開発と展開[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スペクトルバンドに焦点を当てた韓国の努力であるWibro（ワイヤレスブロードバンド）も、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]は、MACでポイントツーポイントで接続指向であり、各接続の一方の端と個々のサブスクライバーステーションを終了するベースステーション（BS）とともに、ポイントツーマルチポイント構造に物理的に配置されています（BS）SS）各接続のもう一方の端を終了します。IEEE 802.16 Convergence Sublayer（CS）は、送信方向サービスデータユニット（BSまたはSSのIPまたはイーサネットなど）を特定のアウトバウンドに割り当てることを担当するMACの最上部にあります。輸送接続。IEEE 802.16は、ATM収束サブレイヤー（CS）とパケットCSの2つの収束サブレイヤータイプを定義しています。パケットCSのIP固有のサブパート（IP 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.
IEEE 802.16ネットワークを介してIPサブネットを構成することには複雑さがあります。これは、ポイントツーポイント接続指向の機能とIP CSとイーサネットCSの存在により、異なる高層機能性を想定しています。IPサブネットは、[RFC4903]で指定されている個々のアドレスに除き、そのプレフィックスがさらに細分化されていない同じIPアドレスプレフィックスを使用するトポロジ領域です。IPサブネット構成は、基礎となるリンク層の特性に依存しており、ネットワーク上の全体的なIP操作を決定します。IEEE 802.16のIP CSおよびイーサネットCSは、IP CSの場合のIPルーティング機能とイーサネット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は[IEEE802.16E]で導入されたモバイルサブスクライバーステーション（MS）を表します。
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）：IPルーティング関数を実行してサブスクライバーステーション（SSまたはMS）に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）：これは、Macの下端からPhyに渡されたデータ形式を指します。
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.
トランスポート接続：SS（MS）とBSの間のIEEE 802.16のMACレイヤー接続は、特定のサービス品質（QOS）属性を備えています。いくつかのタイプの接続が定義されており、これらにはブロードキャスト、ユニキャスト、マルチキャストが含まれます。各輸送接続は、16ビット接続識別子（CID）によって一意に識別されます。トランスポート接続は、ユーザートラフィックを対象とした一意の接続です。輸送接続の範囲は、SS（MS）とBSの間です。
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）：SS（MS）およびBSのIEEE 802.16 Macの同等のピアへの接続を識別する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：[IEEE802.16]で定義されているパケットCSの802.1Q（VLAN）特定の部分。
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レイヤー内の3メッセージシグナル伝達シーケンス（通常はBSによって開始される）によって確立されます。
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.
ダウンリンク方向の輸送接続は、（MACシグナリングを介して）複数のSSに利用可能になった場合、「マルチキャスト」と見なされます。アップリンク方向接続は常にユニキャストです。
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（つまり、Airlinkを介して送信される形式）は、一般的な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 Generic Macヘッダーには、PDUが関連付けられている接続の接続識別子（CID）が搭載されています。RAW 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 Convergence Sublayer（CS）は、MACサービスとMac CPSの内部接続指向サービス（共通部品サブレイヤー）との間のマッピングを分類とカプセル化を通じてマッピングする責任があるMacのコンポーネントです。分類プロセスは、送信方向サービスデータユニット（BSまたはSSのIPスタックなど）を特定のアウトバウンド輸送接続に割り当てます。Convergence Sublayerは、順序付けられた「分類器テーブル」を維持します。分類器テーブルの各エントリには、分類器とターゲットCIDが含まれています。分類器は、1つ以上のサブ分類器の接続詞で構成されています。各サブ分類器がパケットフィールドを指定します（たとえば、イーサネットフレームの宛先MACアドレス、またはIPデータグラムのタイプ（TOS）フィールドが含まれています。フィールドの特定の値または値の範囲とともに、イーサネットフレーム）。アウトバウンドサービスデータユニットで分類を実行するために、Convergence Sublayerは分類器テーブルの最初のエントリから最後まで進み、テーブルエントリの分類子との一致についてサービスデータユニットのフィールドを評価します。一致が見つかると、Convergence Sublayerはサービスデータユニットをターゲット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は、ATM CSとPacket CSの2つの収束サブレイヤータイプを定義しています。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のパケット、802.3/イーサネットCSを超えるIPv4、802.3/イーサネットCS、802.3/イーサネットCSを搭載したパケットが含まれます。強化された圧縮リアルタイムプロトコル（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を超えるIPv4および802.1Q/VLANを超えるIPv6が含まれます。
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/Ethernet CSを超えてパケット）を制限しないパケット分類がありますが、IP CSおよび802.1Q/VLAN CS DO。これらの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.
分類器により、MACはヘッダーにフィールドが存在することを確認し、IEEE 802.16のペイロードヘッダー抑制（PHS）機能をそれらのヘッダーに適用できるようにします。
For the sake of brevity in this document, the following naming conventions will be used for particular classifications of particular subparts of particular CSs.
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を展開する際の重要な問題は、そのリンクでIPサブネットを構成する方法です。これは、MACレベルで接続指向でポイントツーポイントです。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:
上記のIPサブネットモデルをIEEE 802.16ネットワークに採用する際の特定の問題と問題は次のとおりです。
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フレームをカプセル化して脱カプセル化できる収束サブレイヤーを定義しないため、IEEE 802.16ネットワークではPPPの直接使用は不可能です。したがって、IP CSの場合にSSとARの間にポイントツーポイントリンクを提供するメカニズムが必要です。もう1つの選択肢は、イーサネット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の下のすべてのSSSが同じIPサブネットに存在します。これは、SSSが異なるBSSに接続されている場合にも適用されます。このイーサネットのようなリンクモデルは、基礎となるリンク層がイーサネットなど、ネイティブブロードキャストやマルチキャストなどの同等の機能を提供することを前提としています。IEEE 802.16のイーサネットCSを適用して、このリンクモデルを構成することは可能です。ただし、IEEE 802.16のMac機能はまだ接続指向であり、IPパケット転送にマルチキャストとブロードキャスト接続を提供していません。したがって、マルチキャストとブロードキャストを実現するには、IEEE 802.1Dのようなメカニズムが必要です。さらに、睡眠/アイドルモード[IEEE802.16e]にあるSSSを目覚めさせないように、頻繁に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はSSSのIEEE 802.16接続を個別に割り当てます。したがって、SSSは異なるリンクに配置されます。この状況では、さまざまなリンクに配置されたSSSの共有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サブネットモデルです。
1. Point-to-Point Link model for IP CS.
1. IP CSのポイントツーポイントリンクモデル。
2. Ethernet-like Link Model for Ethernet CS.
2. イーサネットCSのイーサネット様リンクモデル。
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アドレスはIEEE 802.16フレームの一部として使用されていないため、アドレス解像度プロトコル（ARP）または近隣キャッシュの典型的な使用法は適用されません。したがって、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に対して、各SSに対して独立したIPプレフィックスを使用してルーター広告（RA）を独立したIPプレフィックスで送信する必要があります。
- 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.
SSごとに個別のIPプレフィックスを配布して、異なるIPサブネットに配置する必要があります。SSが同じARでBSS間を移動する場合、ARは以前のBSで使用した同じIPサブネットプレフィックスを再分配する必要があります。
- Next-Hop:
- 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:
- 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サブネットは1つの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フレームを送信するためにそのアドレスが使用されていない場合でも、宛先イーサネットアドレスフィールドを埋めるためにアドレス解像度を実行する必要があります。そのイーサネット宛先アドレスは、BSまたはブリッジに使用され、IEEE 802.16フレームを脱カプセル化した後、そのイーサネットフレームをどこに転送するかを決定します。宛先のIPアドレスに独自のアドレスのプレフィックスが同じ場合、送信者は宛先自体と同じようにイーサネットフレームの宛先アドレスを設定する必要があります。そのアドレスを取得するには、アドレス解決を従来のブロードキャストおよびマルチキャストベースのARPまたは近隣発見プロトコル（NDP）全体で実行する必要があります。ただし、フィルタリングされていない場合（[RFC4541]など）、これらのマルチキャストとブロードキャストパケットは、睡眠/アイドルモード[IEEE802.16E]にあるSSSを目覚めさせる問題をもたらします。
- 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].
ARの下のすべてのSSSは、イーサネット様リンクモデルの同じブロードキャストドメインにあります。この環境では、全ノードのマルチキャストアドレスの宛先で定期的なルーター広告を送信すると、睡眠/アイドルモード[IEEE802.16E]にあるSSSを目覚めさせる問題が発生します。
- 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プレフィックスは複数のSSSと共有されるため、IPサブネットは複数のSSSとARで構成されています。SSは、オンリンク隣人が存在することを想定し、オンリンクプレフィックスのL2アドレスを解決しようとします。ただし、2つのSSS間のリンク層アドレスを使用した直接通信は、イーサネットCSだけでは不可能です。ブリッジング機能は、BSの上またはBSとARの間に追加する必要があります。
- Next-Hop:
- 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の下のすべてのSSSはすべて隣人です。したがって、NUDはすべてのSSSおよびARに必要です。
- Address Autoconfiguration:
- 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].
複数のSSSと同じIPプレフィックスを使用するAR間で、複製アドレス検出（DAD）を実行する必要があります。以前のマルチキャストベースの父親は、睡眠/アイドルモード[IEEE802.16E]にあるSSSを目覚めさせる問題を引き起こします。
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。Secure Neighbor Discovery（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.16] [IEEE802.16E]で指定されているように暗号化セキュリティメカニズムを採用しています。
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 Jee、Syam Madanapalli、Jeff Mandin、Gabriel Montenegro、Soohong Daniel Park、Maximilian Riegelが含まれます。
The problem statement team members can be reached at:
問題の声明チームメンバーには、次のように連絡できます。
Junghoon Jee, jhjee@etri.re.kr
Junghoon Jee、jhjee@etri.re.kr
Syam Madanapalli, smadanapalli@gmail.com
Syam Madanapalli、smadanapalli@gmail.com
Jeff Mandin, j_mandin@yahoo.com
ジェフ・マンディン、j_mandin@yahoo.com
Gabriel Montenegro, g_e_montenegro@yahoo.com
Gabriel Montenegro、g_e_montenegro@yahoo.com
Soohong Daniel Park, soohong.park@samsung.com
Soohong Daniel Park、Soohong.park@samsung.com
Maximilian Riegel, maximilian.riegel@nsn.com
Maximilian Riegel、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.
著者はまた、コメントと貢献について、Jari Arkko、Heeyoung Jung、Myung-ki Shin、Eun-Kyoung Paik、Jaesun Cha、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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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 STD 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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007.
[RFC4903] Thaler、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 Jee（編集者）Etri 161 Gajeong-Dong Yusong-gu daejeon 305-700 Korea
Phone: +82 42 860 5126
EMail: jhjee@etri.re.kr
Syam Madanapalli Ordyn Technologies 1st Floor, Creator Building, ITPL Bangalore - 560066 India
Syam Madanapalli Ordyn Technologies 1st Floor、Creator Building、ITPL Bangalore -560066 India
EMail: smadanapalli@gmail.com
Jeff Mandin Runcom
ジェフ・マンディン・ランコム
EMail: j_mandin@yahoo.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。