RFC5154 日本語訳

Network Working Group                                        J. Jee, Ed.
Request for Comments: 5154                                          ETRI
Category: Informational                                   S. Madanapalli
                                                      Ordyn Technologies
                                                               J. Mandin
                                                                  Runcom
                                                              April 2008

ワーキンググループJ.Jee、エドをネットワークでつないでください。コメントのために以下を要求してください。 5154年のETRIカテゴリ: 情報のS.Madanapalli Ordyn技術J.Mandin Runcom2008年4月

            IP over IEEE 802.16 Problem Statement and Goals

IEEE802.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のためにIEEE802.16メディアAccess Control(MAC)の特定のギャップを特定するのによるネットワークがサポートするIEEE802.16にIPを経営している際に問題を指定します。 また、このドキュメントは、IEEE802.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

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 IEEE802.16MAC層. . . . . . . . . . . . 4 3.1の概要。 コネクションズ. . . . . . . . . . . . . . . . . . 4 3.2を輸送してください。 IEEE802.16PDUは.53.3をフォーマットします。 IEEE802.16集合副層. . . . . . . . . . . . . 5 4。 IEEE802.16問題声明と目標. . . . . . . 6 4.1の上のIP。 問題. . . . . . . . . . . . . . . . . . . . . . . 6 4.2を根づかせてください。 IP Csのためのポイントツーポイント接続モデル: 問題. . . . . . 8 4.3。 イーサネットCsのためのイーサネットのようなリンクモデル: 問題. . . . 9 4.4。 IEEE802.16目標.105の上のIP セキュリティ問題. . . . . . . . . . . . . . . . . . . 11 6。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 11 7。 承認. . . . . . . . . . . . . . . . . . . . . . . 11 8。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 引用規格. . . . . . . . . . . . . . . . . . . 12 8.2。 有益な参照. . . . . . . . . . . . . . . . . . 12

Jee, et al.                  Informational                      [Page 1]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[1ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

1.  Introduction

1. 序論

   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].

広帯域のWireless Accessネットワークは高品質のデータ/ボイスサービス、速い移動性、広い適用範囲などのユーザ要件のために低い帯域幅無線通信の不適当を扱います。 Broadband Wireless Access Standardsの上のIEEE802.16作業部会は、ブロードバンドWireless Metropolitan Area Networks[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 Forumで、コネ特定です、NWG(ネットワーク作業部会)はIEEE802.16ネットワークアーキテクチャ(例えば、IPv4、IPv6、Mobility、異なったネットワークがあるInterworking、AAAなど)を定義しています。 その結果、NWGはIEEE802規格(物理的とリンクレイヤだけに通常制限される)によって定義されたものの上で層に仕事を引き受けています。 また、同様に、WiBro(ワイヤレスのBroadband)(韓国の取り組み)はIEEE802.16仕様[IEEE802.16]に基づいています。(取り組みは2.3ギガヘルツスペクトル帯に焦点を合わせます)。

   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.

IEEE802.16[IEEE802.16]はMACで二地点間であって接続指向です、基地の駅(BS)がそれぞれの接続のもう一方の端を終えながら各接続と個々のSubscriber駅(SS)の片端を終えていて、ポイントツーマルチポイント構造で物理的に整います。 IEEE802.16集合副層(CS)が割り当てが方向Service Data Unitsを伝えるので(例えば、より高い層のアプリケーション、IPまたはイーサネットから、BSかSSに発します)特定の外国行きの輸送接続において、責任があるMACの最上部にあります。 IEEE802.16は2つの集合副層タイプ、ATM Convergence Sublayer(CS)、およびPacket CSを定義します。 IETF取り組みの現在の範囲の中にIP Specific Subpart(IP CS)とPacket CSの802.3イーサネットSpecific Subpart(イーサネットCS)があります。

   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.

二地点間接続指向の特徴のためにIEEE802.16ネットワークの上でIP Subnetを構成することにおける複雑さとIP CSとイーサネットCSの存在があります。(CSは異なったより高い層の機能性を仮定します)。 IP Subnetは[RFC4903]の指定されるとしての個々のアドレス以外に、その接頭語がさらに細分されないのと同じIPアドレス接頭語を使用する位相的な領域です。 IP Subnet構成は、基本的なリンクレイヤの特性に依存していて、ネットワークで総合的なIP操作について決めます。 IEEE802.16のIP CSとイーサネットCSは異なったより高い層の能力を仮定します: IP CSに関するケースの中のIPルーティングの機能性とイーサネットCSの場合で機能性をブリッジすること。 これは、採用された集合副層に応じてIPの下のリンクレイヤの特性が変化できることを意味します。

Jee, et al.                  Informational                      [Page 2]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[2ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   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 Subnetモデルを各IP CSとイーサネットCSに供給して、IPを経営している際に各ケースに問題を指定します。 また、このドキュメントは、ベースガイドラインにソリューションフレームワークを定義している間、使用されるために明確に集合副層に焦点を合わせるネットワークの特性と一般的な用語をIEEE802.16の概要に提示します。

2.  Terminology

2. 用語

   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): IEEE802.16ネットワークに接続性を提供するエンドユーザ設備。 それは修理されるか遊牧民的であるかモバイルの設備であるかもしれません。 モバイル環境で、SSは[IEEE802.16e]で導入されたモバイルSubscriber駅(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)にアクセスしてください: 加入者設備(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)について議定書の中で述べてください: これはMACの下側の縁からPHYまで通過されたデータの形式を示します。PHYは断片化/パッキング、暗号化などの後にSDUデータを通常含みます。

   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 Hop Limitを減少させます)。

   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.

接続を輸送してください: MACはService(QoS)属性の特定のQualityと共にSS(MS)とBSの間のIEEE802.16で接続を層にします。 いくつかのタイプの接続は定義されます、そして、これらは放送、ユニキャスト、およびマルチキャストを含んでいます。 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): 同等物に接続を特定する16ビットの値はSS(MS)とBSのIEEE802.16MACをじっと見ます。

Jee, et al.                  Informational                      [Page 3]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[3ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   Ethernet CS: The 802.3/Ethernet CS specific part of the Packet CS
   defined in [IEEE802.16].

イーサネットCs: Packet CSの特定の部分が[IEEE802.16]で定義した802.3/イーサネットCS。

   802.1Q CS: The 802.1Q (VLAN) specific part of the Packet CS defined
   in [IEEE802.16].

802.1 Q Cs: [IEEE802.16]で定義されたPacket CSの802.1Q(VLAN)の特定の部分。

   IP CS: The IP specific subpart of the Packet CS defined in
   [IEEE802.16].

IP Cs: [IEEE802.16]で定義されたPacket CSのIPの特定の下位区分。

   IPv4 CS: The IP specific subpart of the Packet CS, Classifier 1
   (Packet, IPv4)

IPv4Cs: Packet CS、Classifier1のIPの特定の下位区分(パケット、IPv4)

   IPv6 CS: The IP specific subpart of the Packet CS, Classifier 2
   (Packet, IPv6).

IPv6Cs: Packet CS、Classifier2(パケット、IPv6)のIPの特定の下位区分。

3.  Overview of the IEEE 802.16 MAC Layer

3. IEEE802.16MAC層の概要

   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.

IEEE802.16[IEEE802.16]はMACで二地点間であって接続指向です、BSがそれぞれの接続の片端を終えていて、個々のSSがそれぞれの接続のもう一方の端を終えていて、ポイントツーマルチポイント構造で物理的に整います。 ネットワークにおける各SSには、48ビットのMACアドレスがあります。 BSには、"BSId"と呼ばれる48ビットのユニークな識別子があります。 BSとSSはSSのエントリーの間、それぞれ他のもののマックーアドレス/BSIdをネットワークに学びます。 さらに、BSには、48ビットのMACアドレスがあるかもしれませんが、イーサネットCSを使用する場合にだけ、これはSSにおいて知られています。

3.1.  Transport Connections

3.1. 輸送の接続

   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).

IEEE802.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.

それを1SSに利用可能に(MACシグナリングを通した)したなら、ダウンリンク方向輸送接続を「マルチキャスト」と見なします。 いつもアップリンク方向接続はユニキャストです。

Jee, et al.                  Informational                      [Page 4]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[4ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

3.2.  IEEE 802.16 PDU Format

3.2. IEEE802.16PDU形式

   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.

IEEE802.16PDU(すなわち、空路連結の上に伝えられる書式)はGeneric 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.

IEEE802.16Generic MACヘッダーはPDUが関連している接続のConnection Identifier(CID)を運びます。 私たちは、生のIEEE802.16MACヘッダーに出席しているどんなソースも送付先アドレスもないのを観測するべきです。

3.3.  IEEE 802.16 Convergence Sublayer

3.3. IEEE802.16集合副層

   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.

IEEE802.16集合副層(CS)はMAC CPSのMACサービスと内部のコネクション型サービスの間で(一般的なPart Sublayer)を写像するのに責任があるMACの部品です、分類とカプセル化を通して。 分類プロセスは方向を伝えているService Data Units(より高い層のアプリケーション、例えば、IPスタックから、BSかSSに発する)を特定の外国行きの輸送接続に割り当てます。 集合副層は命令された「クラシファイアテーブル」を維持します。 クラシファイアテーブルの各エントリーはクラシファイアと目標CIDを含んでいます。 クラシファイアは各「副-クラシファイア」が特定の値か1つの範囲の値と共にパケット分野(例えばMACがイーサネットフレームで扱うか、またはService(TOS)のTypeがさばくイーサネットフレームに含まれたIPデータグラムの目的地)を分野に指定するところで1つ以上の「副-クラシファイア」の結びつきから順番に成ります。 集合副層は、外国行きのService Data Unitに分類を実行するために、クラシファイアテーブルの初記入から最終になりまで続いて、テーブル項目のクラシファイアとのマッチのためにService Data Unitの分野を評価します。 マッチが見つけられるとき、集合副層は目標CID(最後のトランスミッションのための)にService Data Unitを関連づけます、そして、IEEE802.16MACと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.

IEEE802.16は2つの集合副層タイプ、ATM CS、およびPacket CSを定義します。 ATM CSは直接ATMをサポートします。 Packet CSは3つの特定の下位区分に細分されます。

   o  "The IP Specific Subpart" carries IP packets over a point-to-point
      connection.

o 「IP Specific Subpart」は二地点間接続の上まで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イーサネットSpecific Subpart」は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 Specific Subpart」は802.1Q VLAN Tagsを含む802のスタイルパケットを運びます。

Jee, et al.                  Informational                      [Page 5]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[5ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   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の上のIPv6、RObust Header Compression(ROHC)ヘッダー圧縮がある802.3/イーサネットCS、およびEnhanced Compressedレアル-時間プロトコル(ECRTP)ヘッダー圧縮がある802.3/イーサネットを含んでいます。

   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はIP 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.

クラシファイアは、MACがヘッダーでの分野の存在が確かであるのでIEEE802.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.

簡潔にするためにこのドキュメントでは、以下の命名規則は特定のCSsの特定の下位区分の特定の分類に使用されるでしょう。

   o  IPv4 CS: Packet CS, IP Specific Subpart, Classifier 1 (Packet,
      IPv4)

o IPv4Cs: パケットCs、IPの特定の下位区分、クラシファイア1(パケット、IPv4)

   o  IPv6 CS: Packet CS, IP Specific Subpart, Classifier 2 (Packet,
      IPv6)

o IPv6Cs: パケット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.

IEEE802.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タイプ、下位区分、および分類が実際にIEEE802.16によって、より高い層のアプリケーションに提示されるデータインタフェース(例えば、IPv4/IPv6か802.3)のタイプを定義するのを観測できます。

4.  IP over IEEE 802.16 Problem Statement and Goals

4. IEEE802.16問題声明と目標の上のIP

4.1.  Root Problem

4.1. 根本問題

   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

IEEE802.16の上のIPにネットワークを配布するとき、主要な問題はそのリンクの上にどうIP Subnetを構成するかということです。リンクは、MACレベルで接続指向であって二地点間です。 IP Subnetは位相的な領域です。

Jee, et al.                  Informational                      [Page 6]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[6ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   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:

それは個々のアドレス以外に、その接頭語がさらに細分されないのと同じIPアドレス接頭語を使用します。 [RFC4903] 3つのIEEE802.16ネットワークに、可能な異なったIP Subnetモデル[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 SubnetがIEEE802.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 Subnetに住んでいます。 あるSSとARだけがIP Subnetの下に存在しています、そして、リンクの地方の範囲の送付先アドレスがあるIPパケットはSSとARとのポイントツーポイント接続だけの中で提供されます。 PPP[RFC1661]はこの種類のポイントツーポイント接続に広く使用されました。 しかしながら、IEEE802.16が集合副層、どれが要約されることができるか、そして、およびdecapsulate PPPフレームを定義しないので、PPPのダイレクト使用はIEEE802.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の下のすべてのSSsが同じIP Subnetに住んでいます。 また、SSsが異なったBSsに接続されるとき、これは適用されます。 このイーサネットのようなリンクモデルは、基本的なリンクレイヤがイーサネットの例えば、ネイティブの放送とマルチキャストのように同等な機能性を提供すると仮定します。 このリンクモデルを構成するためにIEEE802.16のイーサネットCSを適用するのは可能に思えます。 しかしながら、IEEE802.16のMACの特徴は、まだ接続指向であり、マルチキャストと放送接続をIPパケット転送に提供しません。 したがって、私たちは、マルチキャストがわかって、放送するためにIEEE 802.1Dのようなメカニズムを必要とします。 そのうえ、頻繁なIPマルチキャストと放送シグナリングは、睡眠/無駄なモード[IEEE802.16e]であるSSsを起こさないように避けられるべきです。

   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

共有されたIPv6接頭語リンクモデルは結局、マルチリンクサブネット問題[RFC4903]をもたらします。 IEEE802.16では、BSはSSsのために別々のIEEE802.16接続を選任します。 したがって、SSsは異なったリンクに置かれます。 この状況で、SSsのために共有されたIPv6接頭語を分配して、どれが異なったリンクに置かれるかがマルチリンクサブネットを引き起こします。

Jee, et al.                  Informational                      [Page 7]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[7ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   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.

問題機能性をブリッジしないのが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.

私たちはIEEE802.16の可能なIP Subnetモデルのために集合副層によるネットワークを特定しました。 現在の段階には、進行中のIETF仕事の範囲の中にIEEE802.16のIP CSとイーサネットCSしかありません。 以下に、それぞれの集合副層のためのモデルが使用した可能なIP Subnetがあります。

   1.  Point-to-Point Link model for IP CS.

1. 指すポイントLinkは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.

IEEE802.16MACの二地点間特徴によると、PointからポイントへのリンクモデルはIP CSの場合で可能なIP Subnetモデルです。 イーサネットCSのために、イーサネットのようなリンクモデルは可能なIP Subnetモデルです。 しかしながら、これでは、不要なマルチキャストをモデル化してください。そうすれば、IP Subnetの中の放送パケットは最小にされるべきです。

4.2.  Point-to-Point Link Model for IP CS: Problems

4.2. IP Csのためのポイントツーポイント接続モデル: 問題

   - 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.

アドレスResolutionは目的地のIPアドレスだけを考えて、IPノードが同じIP Subnetの上の目的地ノードのリンクレイヤアドレスを決定するプロセスです。 IP CSの場合では、IEEE802.16MACアドレスはAddress Resolutionプロトコル(ARP)かNeighborキャッシュの用法が適用されないようにとても典型的なIEEE802.16フレームの一部として使用されません。 したがって、アドレス解決を実行するのはIP CSの場合で余分であるかもしれません。 IPv4のために、IP CSが運ぶことができないので、ARPは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.16Networksを送るのに各SSのために、ユニキャスト方法で明らかに、別々のIP接頭語があるRouter Advertisement(RA)を送る必要があります。

Jee, et al.                  Informational                      [Page 8]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[8ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   - 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 Subnetsに彼らの居場所を見つけるように、別々のIP接頭語は分配されるべきです。 SSが同じARの下のBSsの間で移行すると、ARは、SSが前のBSで使用したのと同じIP Subnet接頭語を再配付する必要があります。

   - 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):

- 隣人Unreachability検出(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 Subnetは1SSとARだけから成ります。 したがって、写しアドレス検出(DAD)は些細です。

4.3.  Ethernet-Like Link Model for Ethernet CS: Problems

4.3. イーサネットCsのためのイーサネットのようなリンクモデル: 問題

   - 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のために、送付者は、そのアドレスがIEEE802.16フレームを伝えるのにおいて放送されていた状態で使用されていませんが、目的地イーサネットアドレス・フィールドをいっぱいにするアドレス解決を実行する必要があります。 そのイーサネット送付先アドレスはBSかIEEE802.16フレームをdecapsulatingした後にそのイーサネットフレームをどこに送るかを決めるブリッジに使用されます。 目的地のIPアドレスにそれ自身のものがある同じアドレス接頭語があるとき、送付者は目的地自体としてイーサネットフレームの送付先アドレスを設定するべきです。 そのアドレスを習得するために、アドレス解決は従来の放送とマルチキャストベースのARPかNeighborディスカバリープロトコル(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

ARの下のすべてのSSsがイーサネットのようなリンクモデルの同じ放送ドメインに位置しています。 この環境、オールノードマルチキャストの目的地がある送付の周期的なRouter Advertisementsで

Jee, et al.                  Informational                      [Page 9]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[9ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   address results in the problem of waking up the SSs that are in
   sleep/idle mode [IEEE802.16e].

アドレスは睡眠/無駄なモード[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 Subnetは複数のSSsとARから成ります。 SSはリンクの上の隣人が存在すると仮定して、リンクの上の接頭語のためのL2アドレスを決議しようとします。 しかしながら、イーサネットCSが単独の状態で2SSsの間のリンクレイヤアドレスを使用するダイレクトコミュニケーションは可能ではありません。 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):

- 隣人Unreachability検出(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:

- 自動構成を扱ってください:

   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].

写しAddress Detection(DAD)は複数のSSsとARの中で実行されるべきです。ARは同じIP接頭語を使用します。 ベースの前のマルチキャストDADは睡眠/無駄なモード[IEEE802.16e]であるSSsを起こすという問題を引き起こします。

4.4.  IP over IEEE 802.16 Goals

4.4. IEEE802.16目標の上のIP

   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ディスカバリー(SEND)[RFC3971]などのセキュリティ体系の適用性を許容してください。

Jee, et al.                  Informational                     [Page 10]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[10ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

   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。 IEEE802.16の上でIEEE802.16ワーキンググループとの共同で明確にIPの管理要件、インタフェース、および特定のマネジメント・モデル(オブジェクト)を再検討してください。

5.  Security Considerations

5. セキュリティ問題

   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].

IEEE802.16ネットワークの上でIPの問題声明と目標について説明して、少しの新しい軍事的脅威も導入しませんこれが、ドキュメントである。 IEEE802.16リンクレイヤは指定されるとしての暗号のセキュリティー対策を雇用します[IEEE802.16][IEEE802.16e]。

6.  Contributors

6. 貢献者

   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、ジェフMandin、ガブリエル・モンテネグロ、SoohongダニエルPark、およびマクシミリアン・リーゲルを入れます。

   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

ジェフ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ダニエルPark、 soohong.park@samsung.com

      Maximilian Riegel, maximilian.riegel@nsn.com

マクシミリアン・リーゲル、 maximilian.riegel@nsn.com

7.  Acknowledgments

7. 承認

   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との彼の助け、「IEEE802.16MAC層の概観」についてデヴィッド・ジョンストンに感謝します、そして、慎重に全体のドキュメントを再検討して、ドキュメントの再編成を示すためのフィル・ロバーツにも基線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ユング、ミュング-気Shin、Eun-Kyoungパク、Jaesun Cha、およびKWISF(韓国WirelessインターネットStandardization Forum)に感謝したがっています。

Jee, et al.                  Informational                     [Page 11]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[11ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [RFC1661]      Simpson, W., "The Point-to-Point Protocol (PPP)",
                  STD 51, RFC 1661, July 1994.

[RFC1661] シンプソン、W.、「二地点間プロトコル(ppp)」、STD51、RFC1661、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、「安全な隣人発見(発信する)」、RFC3971、2005年3月。

8.2.  Informative References

8.2. 有益な参照

   [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 Std802.16-2004、「LocalとメトロポリタンエリアネットワークのためのIEEE Standard、Part16:」 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、「LocalとメトロポリタンエリアネットワークのIEEE規格、Part16: 修理されてモバイルの広帯域の無線電信のための空気Interfaceはシステムにアクセスします」、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、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、2006年5月。

   [RFC4903]      Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
                  June 2007.

[RFC4903] ターレル、D.、「マルチリンクサブネット問題」、RFC4903、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リンクモデルの分析はネットワークを基礎づけた」RFC4968、2007年8月。

Jee, et al.                  Informational                     [Page 12]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[12ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

Authors' Addresses

作者のアドレス

   Junghoon Jee (editor)
   ETRI
   161 Gajeong-dong Yuseong-gu
   Daejeon  305-700
   Korea

Junghoon Jee(エディタ)ETRI161Gajeong-ドングYuseong-gu韓国大田305-700

   Phone: +82 42 860 5126
   EMail: jhjee@etri.re.kr

以下に電話をしてください。 +82 42 860 5126はメールされます: jhjee@etri.re.kr

   Syam Madanapalli
   Ordyn Technologies
   1st Floor, Creator Building, ITPL
   Bangalore - 560066
   India

1階、創造者ビル、Syam Madanapalli Ordyn技術ITPLバンガロール--560066インド

   EMail: smadanapalli@gmail.com

メール: smadanapalli@gmail.com

   Jeff Mandin
   Runcom

ジェフMandin Runcom

   EMail: j_mandin@yahoo.com

メール: j_mandin@yahoo.com

Jee, et al.                  Informational                     [Page 13]

RFC 5154              IP over 802.16 PS and Goals             April 2008

Jee、他 情報[13ページ]のRFC5154IPより多くの802.16PSと目標2008年4月

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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に情報を記述してください。

Jee, et al.                  Informational                     [Page 14]

Jee、他 情報[14ページ]