RFC3002 日本語訳
3002 Overview of 2000 IAB Wireless Internetworking Workshop. D.Mitzel. December 2000. (Format: TXT=101466 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Mitzel Request for Comments: 3002 Nokia Category: Informational December 2000
Mitzelがコメントのために要求するワーキンググループD.をネットワークでつないでください: 3002年のノキアカテゴリ: 情報の2000年12月
Overview of 2000 IAB Wireless Internetworking Workshop
2000のIABのワイヤレスのインターネットワーキングワークショップの概要
Status of this Memo
この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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document provides an overview of a workshop held by the Internet Architecture Board (IAB) on wireless internetworking. The workshop was hosted by Nokia in Mountain View, CA, USA on February 29 thru March 2, 2000. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors. This report summarizes the conclusions and recommendations of the IAB on behalf of the IETF community.
このドキュメントはワイヤレスのインターネットワーキングでインターネット・アーキテクチャ委員会(IAB)によって開かれたワークショップの概要を提供します。 そのワークショップは2月29日から2000年3月2日を通したマウンテンビュー(カリフォルニア)(米国)でノキアによって主催されました。 ワークショップの目標は、ワイヤレスの環境におけるインターネット網とトランスポート・プロトコルの承認を改良するために研究と標準化の推薦状をタスクにするワイヤレスの環境におけるインターネット技術の現在の、そして、将来の用途を評価して、電話のインターネット標準ワーキンググループとものの中でコミュニケーションと共同を改良するメソッドとワイヤレスのセクターを評価することでした。 このレポートはIETF共同体を代表してIABの結論と推薦をまとめます。
Comments should be submitted to the IAB-Wireless-Workshop@ietf.org mailing list.
IAB-Wireless-Workshop@ietf.org メーリングリストにコメントを提出するべきです。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . 3 2 Presentation Overview . . . . . . . . . . . . . . . . 4 3 Discussion and Observations . . . . . . . . . . . . . 9 3.1 Discussion on "Walled Garden" Service Model . . . . . 9 3.2 Discussion on Mobility and Roaming . . . . . . . . . 10 3.2.1 Discussion on Mobility and Roaming Model . . . . . . 11 3.2.2 Discussion on Mobility and Roaming Protocols . . . . 11 3.2.3 Discussion on Mobility and Roaming Services . . . . . 12 3.3 Discussion on Security Model . . . . . . . . . . . . 12 3.3.1 Discussion on User Identity . . . . . . . . . . . . . 12 3.3.2 Discussion on WAP Security . . . . . . . . . . . . . 13
1 序論. . . . . . . . . . . . . . . . . . . . 3 2プレゼンテーション概要. . . . . . . . . . . . . . . . 4 3議論と移動性についての「塀で囲まれた庭」サービスモデル.93.2議論についての.93.1議論と移動性とローミングについてのローミング.103.2.1議論がモデル化されるという観測; . . . . . 11 3.2.2 議論、移動性とローミングプロトコルでは、移動性とローミングについての.113.2.3議論はWAPセキュリティ. . . . . . . . . . . . . 13についてのユーザアイデンティティ.123.3.2議論についての機密保護モデル.123.3.1議論についての.123.3議論を修理します。
Mitzel Informational [Page 1] RFC 3002 IAB Wireless Workshop December 2000
[1ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
3.3.3 Discussion on 3G Network Security . . . . . . . . . . 13
3.4 Discussion on Transports . . . . . . . . . . . . . . 14
3.4.1 Discussion on Link Characteristics and Mobility
Effect on Transport . . . . . . . . . . . . . . . . . 14
3.4.2 Discussion on WAP Transport . . . . . . . . . . . . . 16
3.4.3 Discussion on IETF Transport Activities . . . . . . . 16
3.5 Discussion on Aeronautical Telecommunication Network
(ATN) Routing Policy. . . . . . . . . . . . . . . . . 17
3.6 Discussion on QoS Services . . . . . . . . . . . . . 18
3.6.1 Discussion on "Last Leg" QoS . . . . . . . . . . . . 18
3.6.2 Discussion on Path QoS Discovery . . . . . . . . . . 19
3.7 Discussion on Header Compression . . . . . . . . . . 20
3.8 Discussion on Applications Protocols . . . . . . . . 21
3.9 Discussion on Proxy Agents . . . . . . . . . . . . . 22
3.10 Discussion on Adoption of IPv6 . . . . . . . . . . . 22
3.11 Discussion on Signaling . . . . . . . . . . . . . . . 23
3.12 Discussion on Interactions Between IETF and Other
Standards Organizations . . . . . . . . . . . . . . . 24
4 Recommendations . . . . . . . . . . . . . . . . . . . 25
4.1 Recommendations on Fostering Interaction with Non-
Internet Standards Organizations . . . . . . . . . . 25
4.2 Recommendations for Dealing with "Walled Garden"
Model . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Recommendations on IPv4 and IPv6 Scaling . . . . . . 27
4.4 Recommendations on IPv4 and IPv6 Mobility . . . . . . 28
4.5 Recommendations on TCP and Transport Protocols . . . 29
4.6 Recommendations on Routing . . . . . . . . . . . . . 31
4.7 Recommendations on Mobile Host QoS Support . . . . . 32
4.8 Recommendations on Application Mobility . . . . . . . 33
4.9 Recommendations on TCP/IP Performance Characterization
in WAP-like Environment . . . . . . . . . . . . . . . 33
4.10 Recommendations on Protocol Encoding . . . . . . . . 33
4.11 Recommendations on Inter-Domain AAA Services . . . . 34
4.12 Recommendations on Bluetooth . . . . . . . . . . . . 34
4.13 Recommendations on Proxy Architecture . . . . . . . . 34
4.14 Recommendations on Justifying IPv6-based Solutions for
Mobile / Wireless Internet . . . . . . . . . . . . . 35
5 Security Considerations . . . . . . . . . . . . . . . 35
6 Acknowledgments . . . . . . . . . . . . . . . . . . . 35
7 Bibliography . . . . . . . . . . . . . . . . . . . . 36
A Participants . . . . . . . . . . . . . . . . . . . . 41
B Author's Address . . . . . . . . . . . . . . . . . . 41
Full Copyright Statement . . . . . . . . . . . . . . 42
3.3.3 3Gネットワークセキュリティ.133.4議論の進行中の議論は方針を発送する飛行電気通信についての.163.5議論がネットワークでつなぐIETF輸送活動(ATN)についてのWAP輸送.163.4.3議論でのリンクの特性についての.143.4.1議論と輸送.143.4.2議論への移動性効果を輸送します。 . . . . . . . . . . . . . . . . QoSについての3.6議論はアプリケーションプロトコルについてのヘッダー圧縮.203.8議論についての経路QoS発見.193.7議論についてのQoS.183.6.2議論が「最後に急いで歩かれる」というプロキシエージェントについての.213.9議論についての.183.6.1議論を修理します。17、シグナリング. . . . . . . . . . . . . . . 23 3におけるIPv6.22 3.11議論の採用についての.22 3.10議論; IETFともう一方規格組織. . . . . . . . . . . . . . . 24 4推薦の間の相互作用についての12議論、非インターネットの規格組織との相互作用を伸ばすときの.254.1の推薦…; 「塀で囲まれた庭」ModelとDealingのための.254.2の推薦、IPv4の上のIPv4とIPv6 Scaling.274.4RecommendationsとIPv6 Mobility. . . . . . 28 4.5Recommendations oの.264.3RecommendationsモバイルHost QoS Supportの上のルート設定.314.7Recommendationsの上のn TCPとTransportプロトコル.294.6Recommendations、Application Mobilityの上の.324.8Recommendations、WAPのようなEnvironmentのTCP/IPパフォーマンスCharacterizationの上の.334.9Recommendations、プロトコルEncodingの上の.33 4.10Recommendations、Inter-ドメインAAA Servicesの上の.33 4.11Recommendations、ブルートゥースの上の.34 4.12Recommendations…; .357図書目録. . . . . . . . . . . . . . . . . . . . 36A関係者. . . . . . . . . . . . . . . . . . . . 41B作者のアドレス. . . . . . . . . . . . . . . . . . 41が洗い張りする.355のモバイルの、または、ワイヤレスのインターネットセキュリティ問題. . . . . . . . . . . . . . . 35 6承認のためにIPv6ベースのソリューションを正当化するときのアーキテクチャ.34 4.14のプロキシ推薦の.34 4.13の推薦が声明に版権を取らせます…. . . . . . . . . 42
Mitzel Informational [Page 2] RFC 3002 IAB Wireless Workshop December 2000
[2ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
1 Introduction
1つの序論
Wireless technology, including wireless LANs, data transfer over cellular radio (GSM, 3GPP, etc), and mobile operations from aircraft and near earth spacecraft are becoming increasingly important. Some market projections suggest that a mobile Internet in parallel with or augmenting the wired Internet may be comparable in size to the wired Internet as early as 2003.
無線技術、無線LAN、セルラーのラジオ(GSM、3GPPなど)の上のデータ転送、および航空機と地球宇宙船の近くのモバイル操作を含んでいるのはますます重要になっています。 と平行していくつかの市場予測がそのaモバイルインターネットを示す、ワイヤードなインターネットを増大させるのは早ければ2003年にサイズでワイヤードなインターネットに匹敵しているかもしれません。
The wireless operators have not, however, chosen to use IPv4, TCP, full HTTP/HTML, and other applications for a variety of reasons. These relate to edge device cost, bandwidth limitations, perceived protocol imperfections, unnecessary complexities, the chattiness of the application protocols, and network layer addressing issues. Unfortunately, this creates some serious issues at the wired/wireless demarcation: end to end operation is sacrificed, security is compromised, and automated content modification in some form becomes necessary. The IAB considers these to be serious fundamental issues, which will in time be a serious impediment to the usability of the combined Internet if not addressed.
しかしながら、無線通信士は、さまざまな理由にIPv4、TCP、完全なHTTP/HTML、および他のアプリケーションを使用するのを選んでいません。 これらはエッジデバイス費用、プロトコル欠点、不要な複雑さ、アプリケーション・プロトコルのchattinessであると知覚された帯域幅制限、およびネットワーク層問題提示に関連します。 残念ながら、これはワイヤードであるかワイヤレスの画定でいくつかの重大な問題を作成します: 操作を終わらせる終わりは犠牲にされます、そして、セキュリティは感染されます、そして、何らかのフォームにおける自動化された満足している変更は必要になります。 IABは、これらが重大な基本的な問題であると考えます。(扱われないなら、基本的な問題は時間内に、結合したインターネットのユーザビリティの重大な障害になるでしょう)。
The Internet Architecture Board (IAB), on February 29 thru March 2, 2000, held an invitational workshop on wireless internetworking. The goal of the workshop was to assess current and future uses of Internet technology in wireless environments, to make recommendations on research and standardization tasks to improve acceptance of Internet network and transport protocols in wireless environments, and to evaluate methods to improve communication and collaboration among Internet standards working groups and those of the telephony and wireless sectors.
2月29日から2000年3月2日を通して、インターネット・アーキテクチャ委員会(IAB)はワイヤレスのインターネットワーキングに関する招待者に限る催しワークショップを開きました。 ワークショップの目標は、ワイヤレスの環境におけるインターネット網とトランスポート・プロトコルの承認を改良するために研究と標準化の推薦状をタスクにするワイヤレスの環境におけるインターネット技術の現在の、そして、将来の用途を評価して、電話のインターネット標準ワーキンググループとものの中でコミュニケーションと共同を改良するメソッドとワイヤレスのセクターを評価することでした。
The following topics were defined for discussion:
以下の話題は議論のために定義されました:
+ Local area wireless technologies
+ 局部無線技術
+ Cellular wireless technologies
+ セル無線技術
+ Wireless Application Protocol (WAP)
+ ワイヤレス・アプリケーション・プロトコル(ワップ)
+ Near-space and aviation wireless applications
+ 近いスペースと航空無線機器
+ Voice over IP (VoIP) over wireless networks
+ ワイヤレス・ネットワークの上のボイス・オーバー IP(VoIP)
+ Security over wireless networks
+ ワイヤレス・ネットワークの上のセキュリティ
+ Transport and QoS over wireless networks
+ ワイヤレス・ネットワークの上の輸送とQoS
+ Use of WWW protocols over wireless and small screen devices
+ ワイヤレスの、そして、小さいスクリーンデバイスの上のWWWプロトコルの使用
Mitzel Informational [Page 3] RFC 3002 IAB Wireless Workshop December 2000
[3ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
+ Addressing requirements for wireless devices
+ ワイヤレス機器のための要件を扱うこと。
+ Compression and bit error requirements for wireless networks
+ ワイヤレス・ネットワークのための圧縮と噛み付いている誤り要件
The fundamental question addressed in these discussion is "what are the issues, and what really needs to be done to unify the Internet below the application layer." Applications will also need to be addressed, but were perceived to be more than could be usefully discussed in a three-day workshop, and probably require different expertise.
これらの議論で扱われた基本的な質問はことです「何が問題であるか、そして、ことは、本当に応用層の下のインターネットを統一するためにする必要がある」という。 また、アプリケーションは、扱われる必要があるでしょう、3日間のワークショップで有効に議論できたより多くであると知覚されて、たぶん異なった専門的技術を必要とするのを除いて。
Section 2 presents a concise overview of the individual presentations made during the workshop. References to more extensive materials are provided. Details on major discussion topics are provided in section 3. Section 4 presents the recommendations made to wireless operators, IRTF, and IETF on the architectural roadmap for the next few years. It should be noted that not all participants agreed with all of the statements, and it was not clear whether anyone agreed with all of them. However, the recommendations made are based on strong consensus among the participants. Finally, section 5 highlights references to security considerations discussed, appendix A lists contact information of workshop participants, and appendix B lists the author contact information.
セクション2はワークショップの間に作られた個々のプレゼンテーションの簡潔な概要を提示します。 より大規模な材料の参照を提供します。 主要な議論話題に関する詳細はセクション3に明らかにされます。 セクション4はこの数年間建築道路地図で無線通信士(IRTF)とIETFにされた推薦状を提示します。 すべての関係者が声明のすべてに同意したというわけではなくて、だれかそれらに皆、同意したかどうかは、明確でなかったことに注意されるべきです。 しかしながら、された推薦状は関係者の中で強いコンセンサスに基づいています。 最終的に、セクション5は議論したセキュリティ問題の参照を強調します、そして、付録Aは講習会参加者の問い合わせ先をリストアップします、そして、付録Bは作者問い合わせ先をリストアップします。
2 Presentation Overview
2プレゼンテーション概要
Title: Overview of Wireless IP Devices (Network Implications...)
タイトル: ワイヤレスのIPデバイスの概要(含意をネットワークでつないでください…)
Presenter: Heikki Hammainen
プレゼンター: Heikki Hammainen
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt
Overview:
概要:
Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running IP
over IEEE 802.11?
タイトル: IEEE802.11にIPを経営しているIEEE802.11ワイヤレスLANのものと問題の概要?
Presenter: Juha Ala-Laurila
プレゼンター: ユハアラー-Laurila
Reference:
http://www.iab.org/IAB-wireless-work-
shop/talks/IEEE80211_IP.ppt
参照: http://www.iab.org/IAB-wireless-work- 店/会談/IEEE80211_IP.ppt
Overview:
概要:
Mitzel Informational [Page 4] RFC 3002 IAB Wireless Workshop December 2000
[4ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Title: Overview of Bluetooth Wireless & Issues Running IP over
Bluetooth?
タイトル: ブルートゥースにIPを経営しているブルートゥースワイヤレスと問題の概要?
Presenter: Pravin Bhagwat
プレゼンター: Pravin Bhagwat
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/BT-
overview.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/BT-
overview.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/BT- overview.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/BT- overview.ppt
Overview:
概要:
Title: Overview of Cellular Data Systems & Approaches to more IP
centric Cellular Data System
タイトル: より多くのIPの中心のCellular Data SystemへのCellularデータシステムズとApproachesの概要
Presenter: Jonne Soinien
プレゼンター: Jonne Soinien
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/
Cellular_JSo.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/
Cellular_JSo.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/ のセル_JSo.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/ のセル_JSo.ppt
Overview:
概要:
Title: IP Packet Data Service over IS-95 CDMA
タイトル: IPパケットデータサービスオーバー、-95である、CDMA
Presenter: Phil Karn
プレゼンター: フィルKarn
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm
参照: http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm
Overview:
概要:
Title: Wireless Internet Networking
タイトル: ワイヤレスのインターネットネットワーク
Presenter: Chih-Lin I
プレゼンター: Chih-リンI
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/IAB000229.ppt
Overview:
概要:
Title: Mobile IP in Cellular Data Systems
タイトル: セルデータシステムズにおけるモバイルIP
Presenter: Charlie Perkins
プレゼンター: チャーリー・パーキンス
Mitzel Informational [Page 5] RFC 3002 IAB Wireless Workshop December 2000
[5ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/WLIP99.ppt
Overview:
概要:
Title: Overview of WAP
タイトル: WAPの概要
Presenter: Alastair Angwin
プレゼンター: アラステアAngwin
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf
参照: http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf
Overview:
概要:
Title: Mobile Wireless Internet Forum (MWIF)
タイトル: モバイルワイヤレスのインターネットフォーラム(MWIF)
Presenter: Alastair Angwin
プレゼンター: アラステアAngwin
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC
_Presentation.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC
_Presentation.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC _Presentation.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC _Presentation.ppt
Overview:
概要:
Title: Some WAP History
タイトル: 何らかのWAP歴史
Presenter: Jerry Lahti
プレゼンター: ジェリー・ラーティ
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/waphist.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/waphist.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/waphist.ppt
Overview:
概要:
Title: Near-space Wireless Applications
タイトル: スペースの近くの無線機器
Presenter: Mark Allman
プレゼンター: マーク・オールマン
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab-
wireless.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/allman-iab-
wireless.ps
参照: http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- wireless.pdf、 http://www.iab.org/IAB-wireless-workshop/talks/allman-iab- wireless.ps
Overview:
概要:
Mitzel Informational [Page 6] RFC 3002 IAB Wireless Workshop December 2000
[6ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Title: Air Traffic / Aviation Wireless
タイトル: 航空交通/航空ワイヤレス
Presenter: Chris Wargo
プレゼンター: クリスWargo
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/wargo-talk.ppt
Overview:
概要:
Title: VoIP over Wireless
タイトル: ワイヤレスの上のVoIP
Presenter: Christian Huitema
プレゼンター: クリスチャンのHuitema
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless-
voip.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/iab-wless-
voip.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- voip.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/iab-wless- voip.ppt
Overview:
概要:
Title: Security Issues in Wireless Networks and Mobile Computing
タイトル: ワイヤレス・ネットワークとモバイル・コンピューティングにおける安全保障問題
Presenter: N. Asokan
プレゼンター: N。 Asokan
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu-
rity.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu-
rity.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- rity.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/mobile-secu- rity.ppt
Overview:
概要:
Title: Security for Mobile IP in 3G Networks
タイトル: 3GネットワークにおけるモバイルIPのためのセキュリティ
Presenter: Pat Calhoun
プレゼンター: パットCalhoun
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/mip-sec-3g.ppt
Overview:
概要:
Title: On Inter-layer Assumptions (A View from the Transport Area)
タイトル: 相互層の前提で(輸送領域からの視点)
Presenter: Mark Handley
プレゼンター: マーク・ハンドレー
Mitzel Informational [Page 7] RFC 3002 IAB Wireless Workshop December 2000
[7ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/handley-
wireless.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/handley-wire-
less.ps
参照: http://www.iab.org/IAB-wireless-workshop/talks/handley- wireless.pdf、 http://www.iab.org/IAB-wireless-workshop/talks/handley-wire- less.ps
Overview:
概要:
Title: Does current Internet Transport work over Wireless?
タイトル: 現在のインターネットTransportはWirelessの上で働いていますか?
Presenter: Sally Floyd
プレゼンター: サリー・フロイド
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless-
Mar00.pdf,
http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless-
Mar00.ps
参照: http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- Mar00.pdf、 http://www.iab.org/IAB-wireless-workshop/talks/IAB-wireless- Mar00.ps
Overview:
概要:
Title: QOS for Wireless (DiffServ, IntServ, other?)
タイトル: ワイヤレスのためのQOS(IntServの、そして、他のDiffServ)?
Presenter: Lixia Zhang
プレゼンター: Lixiaチャン
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb-
IAB.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb-
IAB.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- IAB.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/zhang-feb- IAB.ppt
Overview:
概要:
Title: Do current WWW Protocols work over Wireless and Small
Screen Devices?
タイトル: 現在のWWWプロトコルはWirelessとSmall Screen Devicesの上で働いていますか?
Presenter: Gabriel Montenegro
プレゼンター: ガブリエル・モンテネグロ
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/wireless-
www.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/wireless-
www.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/wireless- www.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/wireless- www.ppt
Overview:
概要:
Title: Compression & Bit Error Requirements for Wireless
タイトル: ワイヤレスのための圧縮とビット誤り要件
Presenter: Mikael Degermark
プレゼンター: マイケル・デーゲルマルク
Mitzel Informational [Page 8] RFC 3002 IAB Wireless Workshop December 2000
[8ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF 、 http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt
Overview:
概要:
Title: Addressing Requirements for Wireless Devices & IPv6
タイトル: ワイヤレス機器とIPv6のための要件を扱います。
Presenter: Bob Hinden
プレゼンター: ボブHinden
Reference:
http://www.iab.org/IAB-wireless-workshop/talks/Addressing-
IPv6.PDF,
http://www.iab.org/IAB-wireless-workshop/talks/Addressing-
IPv6.ppt
参照: http://www.iab.org/IAB-wireless-workshop/talks/Addressing- IPv6.PDF、 http://www.iab.org/IAB-wireless-workshop/talks/Addressing- IPv6.ppt
Overview:
概要:
3 Discussion and Observations
3 議論と観測
During the workshop presentations a number of issues were discussed and observations made. The following sections 3.1 -- 3.12 summarize these discussion and observations. Rather than organizing the material linearly by presentation, it is grouped according to common "themes" and issues.
ワークショッププレゼンテーションの間の多くの問題について議論しました。そして、された観測。 以下のセクション3.1 -- 3.12はこれらの議論と観測をまとめます。 プレゼンテーションで直線的に材料を有機化するよりむしろ、一般的な「テーマ」と問題によると、それは分類されます。
3.1 Discussion on "Walled Garden" Service Model
3.1 「塀で囲まれた庭」サービスモデルについての議論
Presentations from members involved in the cellular wireless (3GPP, 3G.IP, MWIF) and WAP environments quickly illustrated a significant difference in protocol specification and service models from that typically assumed by the Internet community. These communities focus on defining a profile (set of protocols and operational parameters) that combine to provide a well defined user service. In addition, the carriers typically prefer to have complete (or as much as possible) control over the entire service, including user access device, transmission facilities, and service "content". This style of service model appears to have been inherited from the classic telephony provider model. The term "walled garden" was coined to describe the resulting captive customer economic and service model. That is, the user is constrained within the limits of the service provided by the carrier with limited ability to extend features or access services outside the provider. The "walled garden" service model is in stark contrast to the "open" service assumed in the Internet. The application, access device, and service content may each be controlled by a different entity, and the service provider is typically viewed as little more than a "bit pipe".
すぐにセルワイヤレス(3GPP、3G.IP、MWIF)とWAP環境にかかわるメンバーからのプレゼンテーションはインターネットコミュニティによって通常想定されたそれからプロトコル仕様とサービスモデルの著しい違いを例証しました。 これらの共同体は、よく定義されたユーザサービスを提供するためにプロフィール(プロトコルと操作上のパラメタのセット)を定義するのにそのコンバインの焦点を合わせます。 さらに、キャリヤーは、全体のサービスの完全な(できるだけ)コントロールを持っているのを通常好みます、ユーザアクセスデバイス、通信施設、およびサービス「内容」を含んでいて。 このスタイルのサービスモデルは、古典的な電話プロバイダーモデルから引き継がれたように見えます。 「塀で囲まれた庭」という用語は、経済で結果として起こる専属顧客について説明して、モデルにサービスを提供するために鋳造されました。 すなわち、ユーザはキャリヤーによってプロバイダーの外で特徴かアクセス・サービスを広げる限られた能力に提供されたサービスの限界の中で抑制されます。 「塀で囲まれた庭」サービスモデルはインターネットで想定された「開いている」サービスへのあからさまな対比中です。 アプリケーション、アクセスデバイス、およびサービス内容は異なった実体によってそれぞれ制御されるかもしれません、そして、サービスプロバイダーはただ「噛み付いているパイプ」として通常見なされます。
Mitzel Informational [Page 9] RFC 3002 IAB Wireless Workshop December 2000
[9ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Additionally, specification typically define a standalone protocol or application rather than the set of features and interoperation with other components required to deploy a commercial service.
さらに、他のコンポーネントが商業サービスを配布するのに必要である状態で仕様は特徴とinteroperationのセットよりむしろスタンドアロンプロトコルかアプリケーションを通常定義します。
Some discussion focused on whether cellular carriers could be persuaded to transition toward the Internet "open" service model. Responses indicated that there was little hope of this as carriers will always fight being reduced to a "bit pipe", fearing they cannot sustain sufficient revenues without the value added services. An additional point raised was that the closed model of the "walled garden" simplifies a number of issues, such as security, authorization, and billing when the entire network is considered secured and controlled under a single administration. These simplification can eliminate roadblocks to service deployment before scalable, interdomain solutions are available.
何らかの議論がインターネットの「開いている」サービスモデルに向かった変遷をセルラー電話会社を説得できたかどうかに集中しました。 応答は、キャリヤーが「噛み付いているパイプ」に減少しながらいつも戦うときこの望みがほとんどなかったのを示しました、彼らが付加価値が付いたサービスなしで十分な収入を維持できないと恐れて。 上げられた追加ポイントは「塀で囲まれた庭」の閉鎖モデルが多くの問題を簡素化するということでした、セキュリティなどのように、承認、そして、全体のネットワークが考えられるとき、支払いは、ただ一つの管理の下で保証して、制御されました。 スケーラブルなinterdomainソリューションが利用可能になる前にこれらの簡素化はサービス展開にバリケードを排除できます。
Even though there seems little hope of evolving carriers away from the "walled garden" service in the short term, there was significant value in recognizing its presence. This led to observations that "walled garden" Internet-based services will operate somewhat like current intranet services. Also, mechanisms should be investigated to simplify interoperation and controlled access to the Internet. Finally, the difference between Internet protocol specification contrasted to service profiles highlights some of the confusion those in the telephony environment encounter when attempting to incorporate Internet capabilities.
「塀で囲まれた庭」サービスから遠くで短期でキャリヤーを発展するという望みはほとんど見えませんでしたが、存在を認識するのにおいて重要な値がありました。 これは「塀で囲まれた庭」インターネット・サービスがいくらか現在のイントラネットサービスのように作動するという観測に通じました。 また、メカニズムは、interoperationとインターネットへの制御アクセスを簡素化するために調査されるべきです。 最終的に、サービスプロフィールに対して対照されたインターネットプロトコル仕様の違いはインターネット能力を取り入れるのを試みるとき電話環境におけるものが遭遇する何らかの混乱を強調します。
Much of the current work in extending Internet-based services to cellular customers has focused on data services such as email or web access. One observation on the reluctance of carriers to release any control over services was that this may be an impediment to adoption of Internet-based voice services. Current work on voice over IP (VoIP) and call signaling (SIP [30]) loosens control over these services, much of the functionality is moved into the SIP agent with the carrier being reduced to an access provider (i.e., "bit pipe").
セル顧客へのインターネット・サービスを広げることにおける、執筆中の作品の多くがメールかウェブアクセサリーなどのデータサービスに焦点を合わせました。 キャリヤーがサービスのどんなコントロールもリリースするという不本意における1つの観測はこれがインターネットを利用するボイスサービスの採用の障害であるかもしれないということでした。 IPの上で(VoIP)を声に出してください、そして、合図するのに電話をしてください。執筆中の作品、オンである、(SIP[30])はこれらのサービスのコントロールを緩めて、機能性の多くがアクセスプロバイダに減少するキャリヤーのSIPエージェントに動かされます(すなわち、「ビットは運びます」)。
3.2 Discussion on Mobility and Roaming
3.2 移動性とローミングについての議論
An inherent characteristic of wireless systems is their potential for accommodating device roaming and mobility. Some discussion focused on the model of mobility presented to the user. There was also considerable interest and discussion on protocols employed, using cellular telephony and/or IP-based solutions. Finally, there was some interest in exploring new services enabled by mobility.
ワイヤレスシステムの固有の特性はそれらのデバイスローミングと移動性を収容する可能性です。 何らかの議論がユーザに提示された移動性にならって集中しました。 また、セル電話を使用して、使われたプロトコル、そして/または、IPベースのソリューションについての相当な興味と議論がありました。 最終的に、移動性によって可能にされた新種業務について調査することへの何らかの関心がありました。
Mitzel Informational [Page 10] RFC 3002 IAB Wireless Workshop December 2000
[10ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
3.2.1 Discussion on Mobility and Roaming Model
3.2.1 移動性についての議論とローミングはモデル化されます。
There was considerable discussion and concern over what style of mobility and roaming needs to be supported. Current usage in the Internet is dominated by the mode where a user performs some actions at one location, then shuts down and moves, followed by restart at a new location.
どんなスタイルの移動性とローミングが、サポートされる必要があるかに関するかなりの議論と心配がありました。 インターネットの現在の用法はユーザが1つの位置でのいくつかの動作を実行して、次に停止するモードと再開が新しい位置であとに続いた移動で支配されます。
3G.IP uses the term "macro mobility" to describe this mode.
3G.IPは、このモードを説明するのに「マクロの移動性」という用語を使用します。
The discussion attempted to discern whether the current mode of usage
is a perceived limitation introduced by current protocols. A clear
consensus could not be achieved. There was agreement that
introduction of this "macro mobility" roaming is a worthwhile first
step. However, that was immediately followed by questions on whether
it is a sufficient first step, and warning not to stop at this level.
There seems significant issues for continued investigation related to
enabling continual usage of a device during roaming ("micro
mobility") and the ability to retrieve previous connections after a
roaming event.
議論は、用法の現在のモードが現在のプロトコルによって導入された知覚された制限であるかどうか明察するのを試みました。 明確なコンセンサスを達成できませんでした。 この「マクロの移動性」ローミングの導入が価値がある第一歩であるという協定がありました。 しかしながら、それが十分な第一歩と、このレベルで止まらないという警告であるかどうかに関する質問はすぐに、それのあとに続きました。 ローミング(「マイクロ移動性」)の間、デバイスの絶え間ない使用法を可能にすると関連する継続的な調査とローミングイベントの後に前の接続を救済する能力のための重要な問題は見えます。
3.2.2 Discussion on Mobility and Roaming Protocols
3.2.2 移動性についての議論とローミングプロトコル
Selection between cellular and IP protocols in support of roaming provided another topic for significant discussion. Cellular operators have already deployed protocols providing significant support for roaming. This has led several efforts, such as 3GPP and 3G.IP, toward architecture relying on telephone system for all mobility support, hiding roaming from the IP layer.
ローミングを支持したセルとIPプロトコルの間の選択は別の話題を重要な議論に提供しました。 セルオペレータは既にローミングの重要なサポートを提供するプロトコルを配布しました。 これはいくつかの取り組みを導きました、3GPPや3G.IPのように、すべての移動性サポートの電話を当てにするアーキテクチャに向かって、IP層からローミングを隠して。
Arguments for cellular-based roaming centered on concerns about the mobile IP model. There was concern that home agent and foreign agent involvement in delivery might introduce bottleneck, and the perception that mobile IP handoff is too slow. A rebuttal offered was that IETF mobileip working group is introducing hierarchy and route optimization to improve performance and robustness [50], and there was disagreement on the point regarding slow handoff under mobile IP.
セルベースのローミングのための議論はモバイルIPモデルに関する心配に集中しました。 配送におけるホームのエージェントと外国エージェントかかわり合いが遅い状態でボトルネック、およびまた、モバイルIP移管がそうである知覚を導入するかもしれないという関心がありました。 提供された反論はIETF mobileipワーキンググループが性能と丈夫さ[50]を向上させるために階層構造と経路最適化を紹介しているということでした、そして、モバイルIPの下に遅い移管に関するポイントの上に不一致がありました。
Detriments to the cellular-based roaming include the lack of IP support out to the mobile device and the added tunneling protocols and overhead required. Additionally, roaming is less well defined when traversing service provider boundaries and may involve highly non-optimal forwarding path. There appears significant work remaining to reach convergence on opinions, and additional investigation to support roaming across cellular, WLAN, and IP boundaries.
セルベースのローミングへの損傷はモバイル機器と加えられたトンネリングプロトコルにIPサポートの不足を除外します、そして、オーバーヘッドが必要です。 さらに、ローミングは、サービスプロバイダー限界を横断するとき、それほどよくない定義されないで、非常に非最適の推進経路にかかわるかもしれません。 集合は意見、サポートするセルの向こう側に移動する追加調査、WLAN、およびIP境界で重要な仕事の残りように達するように見えます。
Mitzel Informational [Page 11] RFC 3002 IAB Wireless Workshop December 2000
[11ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
3.2.3 Discussion on Mobility and Roaming Services
3.2.3 移動性についての議論とローミング・サービス
3G.IP mobility model is primarily focused on providing ubiquitous service across a range of access media. However, the presentation also highlighted a desire to develop new "location based" services. Examples presented include locating nearby services or receiving advertisement and solicitations from nearby business.
3G.IP移動性モデルは主としてさまざまなアクセスメディアの向こう側に遍在しているサービスを提供するのに焦点を合わせられます。 しかしながら、また、プレゼンテーションは「基づく位置」新しいサービスを開発する願望を強調しました。 提示された例は、近いビジネスから近いサービスの場所を見つけるか、または広告と懇願を受け取るのを含んでいます。
There are several Internet protocols defined, such as anycast service [47] and SLP [28], that may aid in developing location based services. However, there was considerable frustration on the part of 3G.IP in that there appears little commercial support of these protocols, and even less direction on how to assemble and coordinate the required protocols to deploy the desired services.
展開している位置でベースのサービスを支援するかもしれないanycastサービス[47]とSLP[28]などのように定義されたいくつかのインターネットプロトコルがあります。 しかしながら、これらのプロトコルの少ない商業サポート、および必要なサービスを配布するために必要なプロトコルを組み立てて、どう調整するかに関するさらに少ない方向が現れるので、かなりのフラストレーションが3G.IP側のありました。
This exchange illustrated the disconnect between interpreting Internet standards and telephony service profiles. First, in the Internet many protocols are defined but many are optional. Protocol support is typically driven by market demand, which can lead to "chicken and egg" problem. Secondly, individual protocols and applications are developed rather than complete profile to compose a commercial service. For this service, evaluating the usage and scalability of service discovery protocols appears to be an area open for further investigation.
この交換はインターネット標準と電話サービスプロフィールを解釈することの間の分離を例証しました。 まず最初に、インターネットでは、多くのプロトコルが定義されますが、多くが任意です。 プロトコルサポートは市場の需要で通常追い立てられます。(それは、「鶏肉と卵」問題を引き起こすことができます)。 第二に、個々のプロトコルとアプリケーションは、商業サービスを構成するために完全なプロフィールよりむしろ開発されます。 このサービスに関しては、サービス発見プロトコルの用法とスケーラビリティを評価するのはさらなる調査において、開いている領域であるように見えます。
3.3 Discussion on Security Model
3.3 機密保護モデルについての議論
Mobility and wireless environments introduce many complexities and potential attacks to user authentication and privacy. In addition to the discussion presented below, there was an overriding statement made regarding the methodology that must be followed for all security protocol development. It was felt quite strongly that the only chance for success is that the definition be done in a public forum, allowing full disclosure of all algorithms and thorough review by security experts. Stated an alternate way, defining protocols in a closed forum relying on cellphone manufacturers, or other non-experts on IP security, is very likely to create security exposures.
移動性とワイヤレスの環境は多くの複雑さと起こり得るかもしれない攻撃をユーザー認証とプライバシーに紹介します。 以下に提示された議論に加えて、すべてのセキュリティプロトコル開発のために従わなければならない方法論に関して出された最優先の声明がありました。 成功のための唯一の機会が公共のフォーラムで定義するということであると全く強く感じられました、安全保障専門家によるすべてのアルゴリズムと徹底的なレビューの完全な開示を許容して。 携帯電話メーカー、またはIPセキュリティの他の非の専門家に頼りながら閉じているフォーラムでプロトコルを定義して、代替の道がセキュリティ暴露を非常に作成しそうであると述べました。
3.3.1 Discussion on User Identity
3.3.1 ユーザのアイデンティティについての議論
Storage of user identity can have significant effect on device usage and device portability. Discussion focused on whether identity should be tied to the mobile device or a transferable SIM card. Fixing identification with the device may simplify manufacture and provide some tamper resistance, however it makes it very difficult to deploy a public device taking on the identity of the user. These alternative also affect transfer of identity and configuration state on device replacement or upgrade.
ユーザのアイデンティティのストレージはデバイス用法とデバイスの移植性に重要な影響を与えることができます。 議論はアイデンティティがモバイル機器か移転可能なSIMカードに結ばれるべきであるかどうかに集中しました。 デバイスで識別を修理すると、製造が簡素化されて、何らかのタンパー抵抗が提供されるかもしれなくて、それでしかしながら、ユーザのアイデンティティを呈する公共のデバイスを配布するのは非常に難しくなります。 また、これらの代替手段はデバイス交換かアップグレードのアイデンティティと構成状態の転送に影響します。
Mitzel Informational [Page 12] RFC 3002 IAB Wireless Workshop December 2000
[12ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
A related topic revolves around the user desire to employ a single device but to take on a different identity and privilege based on the usage at hand (e.g., to gain corporate access, home access, or Internet access). The ability and ease of assuming these multiple identities may be highly dependent on the model of identity integration, as discussed above. Discussion highlighted potential pitfalls based on tieing of device and user identities. IPsec use of device IP address inhibits roaming capabilities as the address may change based on location, and precludes distinguishing identity and capabilities for current usage. IPsec requires additional work to accommodate this added flexibility.
関連した話題は単一のデバイスを使うユーザ願望の周りで回転しましたが、異なったアイデンティティと特権を呈するのは手元の用法を基礎づけました(例えば法人のアクセス、ホームアクセス、またはインターネット・アクセスを得る)。 これらが複数のアイデンティティであると仮定する能力と容易さはアイデンティティ統合にならって非常に依存しているかもしれません、上で議論するように。 デバイスとユーザアイデンティティをtieingすることに基づいて議論は潜在的落とし穴を強調しました。 アドレスが、位置に基づいて変化するかもしれなくて、現在の用法のためにアイデンティティと能力を区別するのを排除するとき、デバイスIPアドレスのIPsec使用はローミング能力を禁止します。 IPsecは、この加えられた柔軟性を収容するために追加仕事を必要とします。
A final topic of discussion on user identity establishment was whether possession of the device is sufficient, or whether the user should be required to authenticate to the device. In the real world the first alternative is exemplified by the credit card model, while the second is more analogous to the ATM card where the user must also provide a PIN code. Both models seem useful in the real world, and it's likely both will have uses in wireless networking.
ユーザアイデンティティ設立についての議論の最終的な話題はデバイスの所持が十分であるかどうか、またはユーザがデバイスに認証するのに必要であるべきであるかどうかということでした。 本当の世界では、最初の代替手段がクレジットカードモデルによって例示されます、2番目がまたユーザが暗証番号コードを提供しなければならない銀行のキャッシュカードにより類似していますが。 両方のモデルは本当の世界で役に立つように見えます、そして、両方にはワイヤレスのネットワークにおける用途があるのは、ありそうです。
3.3.2 Discussion on WAP Security
3.3.2 WAPセキュリティについての議論
WAP wireless transport security (WTLS) is based on TLS [20], with optimized handshake to allow frequent key exchange. The security service employs a "vertical" integration model, with protocol components throughout the network stack. Some argued that this is the wrong model. A better approach may have been a security layer with well defined interfaces. This could allow for later tradeoffs among different protocols, driven by market, applications, and device capabilities.
WAPのワイヤレスの輸送セキュリティ(WTLS)は最適化された握手でTLS[20]に基づいていて、頻繁な主要な交換を許容します。 セキュリティー・サービスはネットワークスタック中のプロトコルコンポーネントと共に「垂直な」統合モデルを雇います。 或るものは、これが間違ったモデルであると主張しました。 より良いアプローチはよく定義されたインタフェースがあるセキュリティ層であったかもしれません。 これは市場、アプリケーション、およびデバイス能力によって動かされた異なったプロトコルの中で後の見返りを考慮するかもしれません。
Additional statements argued that the WAP security model illustrates
dangers from optimizing for a limited usage domain ("walled garden").
Content provider systems requiring security (e.g., banks) must deploy
a special WAP proxy, which breaks the model of a single WAP "domain".
Similar issues are inherent in gatewaying to the Internet.
追加声明は、WAP機密保護モデルが限られた用法ドメイン(「塀で囲まれた庭」)に最適化するので危険を例証すると主張しました。 セキュリティ(例えば、銀行)を必要とするコンテンツプロバイダーシステムは特別なWAPプロキシを配布しなければなりません。(プロキシは単一のWAP「ドメイン」のモデルを壊します)。 同様の問題はインターネットにgatewayingするのが固有です。
3.3.3 Discussion on 3G Network Security
3.3.3 3Gネットワークセキュリティについての議論
The existing GSM/GPRS model uses long term shared secrets (embedded in SIM card) with one-way authentication to the network, and with privacy only provided on the access link. This is an example where the "walled garden" service model has an advantage. Complete control over the service access devices and network greatly reduces the range of security concerns and potential attacks.
既存のGSM/GPRSモデルはネットワークへの一方向認証、およびアクセスリンクの上に提供するだけであるプライバシーと共に長期共有秘密キー(SIMカードに埋め込まれている)を使用します。 これは「塀で囲まれた庭」サービスモデルが利点を持っている例です。 サービスアクセスデバイスとネットワークの完全なコントロールは安全上の配慮と起こり得るかもしれない攻撃の範囲を大いに減少させます。
Mitzel Informational [Page 13] RFC 3002 IAB Wireless Workshop December 2000
[13ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Future 3GPP and 3GPP2 plan to push IP all the way out to the wireless device. An observation is that this results in more potential for exposure of signaling and control plane to attacks. Desire is to perform mutual authentication and securing of the network. This is a difficult problem with additional issues remaining to be solved; however the statement was made that relying on IP and open standards is more likely to produce a provably secure network than former reliance on SS7 protocols and obscurity.
将来の3GPPと3GPP2は、ワイヤレス機器にIPをはるばる押し出すのを計画しています。 観測はこれがシグナリングの暴露の、より多くの可能性と攻撃への制御飛行機をもたらすということです。 願望はネットワークを互いの認証と機密保護することを実行することです。 これは解決されるために残っている追加設定の難問です。 しかしながら、IPとオープンスタンダードを当てにするのが、SS7プロトコルへの前の信用と不鮮明よりaを証明可能に生産しそうな安全なネットワークであるという声明は出されました。
Completing support for the security requirements of the 3GPP/3GPP2 network seems to require resolving issues in two primary areas, AAA services and mobile IP. AAA is required for authentication, authorization, and billing. Remaining issues center around cross domain AAA, authentication using PKI, and there was considerable aversion to use of IPsec and IKE protocols due to perceived overhead and delay. Mobile IP issues revolve around solutions to reduce the security associations required between mobile node and home agent, mobile node and foreign agent, and the home and foreign agent. An interim solution being investigated involves use of a RADIUS server [56]; however, there are concerns with repeated dynamic key generation on each handoff or hiding some details of handoffs, which may violate assumptions in mobile IP protocol [48]. Evaluating requirements and addressing all of these open issues appears to be an excellent opportunity for mutual cooperation on open standardization and review.
3GPP/3GPP2ネットワークのセキュリティ要件のサポートを終了するのは2つの一次領域、AAAサービス、およびモバイルIPの問題を解決するのが必要であるように思えます。 AAAが認証、承認、および支払いに必要です。 IPsecの使用へのかなりの反感とオーバーヘッドを知覚して、延着するのにおいて当然のIKEプロトコルは、残された問題が交差しているドメインAAA、PKIを使用する認証を中心に置いて、ありました。 モバイルIP問題はモバイルノードとホームのエージェントの間で必要であるセキュリティ協会、モバイルノード、および外国人のエージェントを減らす解決、ホーム、および外国人のエージェントを中心題目とします。 調査される当座のソリューションはRADIUSサーバ[56]の使用にかかわります。 しかしながら、各移管かいくつかの詳細を隠すときのモバイルIPプロトコル[48]で仮定に違反するかもしれないhandoffsの繰り返されたダイナミックなキー生成に従った関心があります。 要件を評価して、これらの未解決の問題のすべてを扱うのは開いている標準化とレビューの相互扶助の素晴らしい機会であるように見えます。
3.4 Discussion on Transports
3.4 輸送についての議論
Discussion on transport protocols touched on a broad range of issues. Concerns ranged from the effects of wireless link characteristics and mobility effect on TCP, to development of new transport protocols such as WAP Wireless Transaction Protocol (WTP). In addition, a significant amount of time was spent reviewing ongoing efforts within the IETF on TCP transport enhancements and investigation of new transports.
トランスポート・プロトコルについての議論は広範囲な問題に触れました。 関心はTCPへのワイヤレスのリンクの特性と移動性効果の効果から変化しました、WAP Wireless Transactionプロトコル(WTP)などの新しいトランスポート・プロトコルの開発に。 さらに、重要な時間は新しい輸送のTCP輸送増進と調査のときにIETFの中で進行中の取り組みを見直すのに費やされました。
3.4.1 Discussion on Link Characteristics and Mobility Effect on
Transport
3.4.1 輸送へのリンクの特性と移動性効果についての議論
TCP makes assumptions on loss as congestion indication. The statement was made that TCP was designed for links with about 1% corruption loss, and provided that constraint is met then TCP should function properly. Presentation on IS-95 CDMA-based data service showed that it conditions line to provide 1--2% error rate with little correlation between loss. Similar conditioning and Forward Error Correction (FEC) mechanisms may be appropriate for other wireless and satellite systems [4]. This may not be true for all wireless media, but it was interesting in the fact that it indicates
TCPは混雑としての損失の仮定を指示にします。 TCPがおよそ1%の不正損失とのリンクに設計されたという声明は出されました、そして、規制が迎えられれば、TCPは適切に機能するはずです。 プレゼンテーション、オンである、-95である、CDMAベースのデータサービスは、それが、損失の間でほとんど1--2%の誤り率に相関関係を提供しないように系列を条件とさせるのを示しました。 他のワイヤレスとサテライト・システム[4]に、同様の調節とForward Error Correction(FEC)メカニズムは適切であるかもしれません。 すべてのワイヤレスのメディアには、これは本当でないかもしれませんが、それは示す事実でおもしろかったです。
Mitzel Informational [Page 14] RFC 3002 IAB Wireless Workshop December 2000
[14ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
TCP should work properly on many wireless media. However, the amount of discussion and suggestions on TCP performance optimizations showed that there can be a considerable gap between merely working and working well.
TCPは適切に多くのワイヤレスのメディアに取り組むはずです。 しかしながら、TCPパフォーマンスの最適化の議論と提案の量は、かなりのギャップが単に働いて、うまくいくときあることができるのを示しました。
One issue raised several times was related to the effects of non- congestive loss on TCP performance. In the wireless environment non-congestive loss may be more prevalent due to corruption loss (especially if the wireless link cannot be conditioned to properly control error rate) or an effect of mobility (e.g., temporary outage while roaming through an area of poor coverage). These losses can have great detrimental effect on TCP performance, reducing the transmission window and halving the congestion window size. Much of the discussion focused on proposing mechanisms to explicitly indicate a non-congestive loss to the TCP source. Suggestions included a Non-Congestive Loss Indication (NCLI) sent for instance when packet corruption loss is detected, or sending a Source Encourage (SE) to stimulate source transmission at the end of an outage. In addition to data corruption, wireless links can also experience dropouts. In this situation any active TCP sessions will commence periodic retransmissions, using an exponentially increasing back-off timer between each attempt. When the link becomes available it may be many seconds before the TCP sessions resume transmission. Mechanisms to alleviate this problem, including packet caching and triggered retransmission were discussed. The more generic form of all of these mechanisms is one that allows the state of the layer two (datalink) system to signal to the TCP session its current operating mode. Developing a robust form of such a signaling mechanism, and integrating these signals into the end-to-end TCP control loop may present opportunities to improve TCP transport efficiency for wireless environments.
何度か提起された1冊は非充血性の損失のTCP性能への影響に関連しました。 ワイヤレスでは、環境の非充血性の損失は不正損失(特にワイヤレスのリンクが適切に誤り率を制御するように条件とできないなら)か移動性の効果(例えば、貧しい適用範囲の領域を通って移動している間の一時的な供給停止)のために、より一般的であるかもしれません。 トランスミッションウィンドウを減少させて、混雑ウィンドウサイズを半分にして、これらの損失はTCP性能にすばらしい有害な影響を持つことができます。 議論の多くが、明らかに非充血性の損失を示すためにメカニズムを提案するのはTCPソースに焦点を合わせました。 提案は、例えば、パケット不正損失を検出するとき送るか、または供給停止の終わりにソーストランスミッションを刺激するために、Source Encourage(SE)を送りながら、Non充血性のLoss Indication(NCLI)を含んでいました。 また、データの汚染に加えて、ワイヤレスのリンクは落第生を経験できます。 この状況で、各試みの間の指数関数的に増加する下に後部タイマを使用して、どんな活発なTCPセッションも周期的な「再-トランスミッション」を始めるでしょう。 リンクが利用可能になるとき、TCPセッションがトランスミッションを再開する前にまた何秒であるかもしれないのも。 パケットキャッシュを含むこの問題を軽減するメカニズムと引き起こされた「再-トランスミッション」について議論しました。 より多くのジェネリックフォームのこれらのメカニズムのすべてが層twoの(データリンク)系の事情がTCPセッションまで現在のオペレーティング・モードに合図できるものです。 そのようなシグナル伝達機構の強健なフォームを発生して、TCPコントロールループがワイヤレスの環境のためにTCP輸送効率を改良する機会を提示するかもしれない終わりから終わりまでこれらの信号を統合します。
TCP improvements have been incorporated to support "long" links (i.e., those with large delay and bandwidth characteristics) [36], however considerable expertise may still be required to tune socket buffers for maximum performance. Some work has been done on auto- tuning buffers, which shows promise [58]. An additional problem with large windows and auto-tuning is the added header overheads. This may exasperate the problems of running TCP over low bandwidth links. Suggestions included to explore dynamic negotiation of large window extensions in the middle of a connection to alleviate these issues. A final issue raised with regardport (see discussion below in section 3.4.3).
TCP改良が「長い」リンク(すなわち、大きい遅れと帯域幅の特性があるそれら)が[36]であるとサポートするために法人組織であった、しかしながら、かなりの専門的技術が、最大性能のためのソケットバッファを調整するのにまだ必要であるかもしれません。 自動チューニングバッファでいくらかの仕事をしました。(ショーは[58]をバッファに約束します)。 大きい窓と自動チューニングに関する追加問題は加えられたヘッダーオーバーヘッドです。 これは低い帯域幅リンクの上にTCPを実行するという問題を激怒させるかもしれません。 これらの問題を軽減するために接続の途中での大きい窓の拡大のダイナミックな交渉について調査するために提案を含んでいます。 regardport(以下でのセクション3.4.3における議論を見る)で提起された最終的な問題。
There was also concern regarding mobility effects on TCP performance. TCP has implicit assumptions on bounding propagation delay. If delay exceeds the smoothed round trip time plus four times the round trip variance then the segment is considered lost, triggering the normal
TCP性能への移動性効果に関する心配もありました。 TCPはバウンドしている伝播遅延に暗黙の仮定を持っています。 セグメントは無くなると考えられます、標準の引き金となって遅れが平坦な周遊旅行時間と周遊旅行変化の4倍を超えているなら
Mitzel Informational [Page 15] RFC 3002 IAB Wireless Workshop December 2000
[15ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
backoff procedures. Could these assumptions be violated by segment loss or duplication during handoff? Work on D-SACK [25] may alleviate these worries, detecting reordering and allowing for adaptive DUP-ACK threshold. Finally, there was suggestion it might be appropriate to adapt (i.e., trigger slow start) immediately after mobile handoff on the assumption that path characteristics may differ.
backoff手順。 セグメントの損失か複製で移管の間、これらの仮定に違反できるでしょうか? 適応型のDUP-ACK敷居のための再命令と許容を検出して、D-SACK[25]への作業はこれらの心配を軽減するかもしれません。 最終的に、経路特性が異なるかもしれないという前提のモバイル移管直後適合させるのが(すなわち、遅れた出発の引き金となります)適切であるかもしれない提案がありました。
3.4.2. Discussion on WAP Transport
3.4.2. WAP輸送についての議論
WAPF considered TCP connection setup and teardown too expensive in terms of bit overhead and latency when required for every transaction. WAPF developed the Wireless Transaction Protocol (WTP), with some inspiration from T/TCP [12]. WTP offers several classes of service ranging from unconfirmed request to single request with single reply transaction. Data is carried in the first packet and 3-way handshake eliminated to reduce latencies. In addition acknowledgments, retransmission, and flow control are provided.
あらゆるトランザクションに必要であると、WAPFは、TCPが接続設定と、頭上のビットで高価過ぎる分解と潜在であると考えました。 WAPFはT/TCP[12]からのいくらかのインスピレーションを伴うWireless Transactionプロトコル(WTP)を開発しました。 WTPはただ一つの回答トランザクションで未確認の要求からただ一つの要求まで及ぶ数人のクラスのサービスを提供します。 データは潜在を減少させるために排除された最初のパケットと3ウェイ握手で運ばれます。 さらに、承認、「再-トランスミッション」、およびフロー制御を提供します。
Discussion on WTP centered on assessing details on its operation. Although it incorporates mechanisms for reliability and flow control there was concern that it may miss critical or subtle transport issues learned through years of Internet research and deployment experience. One potential area for disaster appeared to be the use of fixed retransmission timers and lack of congestion control. This gave rise to suggestions that the IETF write up more details on the history and tradeoffs in transport design to aid others doing transport design work, and secondly that the IETF advocate that the congestion control is not optional when using rate adaptive transport protocols.
操作に関する詳細を評価しながら集中されるWTPについての議論。 信頼性とフロー制御のためにメカニズムを組み込みますが、重要であるか微妙な輸送問題が何年ものインターネット研究と展開経験で学んだのが消えるかもしれないという関心がありました。 災害のための1つの潜在的領域が固定再送信タイマーの使用と輻輳制御の不足であるように見えました。 これはIETFが歴史に関するその他の詳細を詳しく書くという提案をもたらしました、そして、使用するとき、任意の状態で輸送にデザインワークをして、輻輳制御がそうでないIETF支持者を第二にそれにしている他のものを支援する輸送デザインにおける見返りは適応型の輸送がプロトコルであると評定します。
The remaining discussion on WAP transport primarily focused on ways to share information. It was suggested that any result from WAPF study of TCP shortcomings that led to its rejection might be useful for IETF review as inputs for TCP modifications. Similar comments were raised on study of T/TCP shortcomings and its potential exposure to Denial of Service (DoS) attacks. It was also encouraged that the WAPF members participate in the IETF directly contribute requirements and remain abreast of current efforts on evolving TCP operation and introduction of new transport (see discussion below in section 3.4.3.).
WAP輸送についての残っている議論は主として情報を共有する方法に焦点を合わせました。 拒絶につながったTCP短所のWAPF研究からのどんな結果もTCP変更のための入力としてIETFレビューの役に立つかもしれないと示唆されました。 同様のコメントはT/TCP短所の研究とサービス妨害(DoS)攻撃へのその潜在被曝のときに上げられました。 それがそうであり、また、奨励されて、新しい輸送のTCP操作と導入を発展するとき、WAPFメンバーがIETFに参加するのは、直接要件を寄付して、現在の取り組みと並行して残っています(.3にセクション3.4の以下での議論を見てください)。
3.4.3 Discussion on IETF Transport Activities
3.4.3 IETF輸送活動についての議論
Discussion on transport work in the IETF presented a large array of activities. Recent work on transport improvement includes path MTU, Forward Error Correction (FEC), large windows, SACK, NewReno Fast Recovery, ACK congestion control, segment byte counting, Explicit Congestion Notification (ECN), larger initial transmit windows, and
IETFでの輸送仕事についての議論は活動の大きい勢ぞろいを提示しました。 そして輸送改良インクルード経路MTU、Forward Error Correction(FEC)の近作、大きい窓、SACK、NewReno Fast Recovery、ACK輻輳制御、セグメントバイトが重要であることで、Explicit Congestion Notification(電子証券取引ネットワーク)、より大きいイニシャルが窓を伝える。
Mitzel Informational [Page 16] RFC 3002 IAB Wireless Workshop December 2000
[16ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
sharing of related TCP connection state [3,4,5,6,24,25,43,53,63]. Work on new transports includes SCTP [61] in the IETF Signaling Transport (sigtran) working group and TCP-Friendly Rate Control (TFRC) [1] by researchers at ACIRI. SCTP provides a reliable UDP- like protocol supporting persistent associations and in-order delivery with congestion control. TFRC is targeted at unreliable, unicast streaming media. Finally, work in the IETF End-point Congestion Management (ecm) working group is looking at standardizing congestion control algorithms, and work in the Performance Implications of Link Characteristics (pilc) working group is characterizing performance impacts of various link technologies and investigating performance improvements.
関連するTCP接続状態[3、4、5、6、24、25、43、53、63]を共有します。 新しい輸送に対する仕事はACIRIにIETF Signaling Transport(sigtran)ワーキンググループとTCP好意的なRate Control(TFRC)[1]に研究者でSCTP[61]を含んでいます。 SCTPは永続的な協会をサポートするプロトコルとオーダーにおける配送のような信頼できるUDPを輻輳制御に提供します。 TFRCは頼り無いユニキャストストリーミング・メディアをターゲットにします。 最終的に、IETF End-ポイントCongestion Management(ecm)ワーキンググループにおける仕事が輻輳制御アルゴリズムを標準化するのを検討することであって、Link Characteristics(pilc)ワーキンググループのパフォーマンスImplicationsにおける仕事は、様々なリンク技術の性能影響を特徴付けて、性能改良を調査することです。
This vast array of ongoing research and standards development seemed a bit overwhelming, and there was considerable disagreement on the performance and applicability of several TCP extensions. However, this discussion did raise a couple of key points. First, transport work within the Internet community is not stagnant, there is a significant amount of interest and activity in improvement to existing protocols and exploration of new protocols. Secondly, the work with researchers in satellite networking has demonstrated the tremendous success possible in close collaboration. The satellite networking community was dissatisfied with initial TCP performance on long delay links. Through submission of requirements and collaborative investigation a broad range of improvements have been proposed and standardized to address unique characteristics of this environment. This should hopefully set a very positive precedent to encourage those in the wireless sector to pursue similar collaboration in adoption of Internet protocols to their environment.
継続中の研究と規格開発のこの広大な勢ぞろいは少し圧倒的に見えました、そして、かなりの不一致がいくつかのTCP拡張子の性能と適用性にありました。 しかしながら、この議論は2、3の要所を提起しました。 まず最初にインターネットコミュニティの中の輸送仕事が淀まない、新しいプロトコルの既存のプロトコルと探検への改善における興味があるかなりの量と活動があります。 第二に、衛星ネットワークにおける研究者との仕事は厳密な共同で可能な大成功を示しました。 衛星ネットワーク共同体は長時間の遅延リンクに関する初期のTCP性能に不満でした。 要件と協力的な調査の提案で、広範囲な改良が、この環境のユニークな特性を扱うために提案されて、標準化されました。 これは、希望をいだいて非常に積極的な先例にワイヤレスのセクターのものがインターネットプロトコルの採用における同様の共同を彼らの環境まで追求するよう奨励するように設定するべきです。
3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing
Policy
3.5 航空通信網(ATN)ルート設定方針についての議論
The Aeronautical Telecommunication Network (ATN) has goals to improve and standardize communications in the aviation industry. This ranges across air traffic management and control, navigation and surveillance, all the way up to passenger telephone service and entertainment. This also involves integration of both fixed ground segments and mobile aircraft. Supporting the ATN architecture using Internet protocols may introduce additional requirements on the routing infrastructure.
Aeronautical Telecommunication Network(ATN)には、航空機産業でコミュニケーションを改良して、標準化する目標があります。 これは空気輸送管理、コントロール、ナビゲーション、および監視の向こう側に及びます、いっぱいに乗客電話サービスとエンターテインメントまで。 また、これは固定地面セグメントとモバイル航空機の両方の統合にかかわります。 ATNがアーキテクチャであるとインターネットプロトコルを使用することでサポートするのがルーティングインフラストラクチャに関する追加要件を導入するかもしれません。
Current ATN views each aircraft as an autonomous network (AS) with changing point of attachment as it "roams" through different airspace. Addressing information associated with the aircraft is fixed, which makes route aggregation difficult since they're not related to topology, and also increases the frequency of updates. Additionally, the aircraft may be multiply attached (within coverage
異なった領空を通って「移動する」とき、現在のATNは変化接着点がある自治のネットワーク(AS)であると各航空機をみなします。 航空機に関連しているアドレス指定情報は固定されています(トポロジーに関連しないのでルート集合を難しくして、また、アップデートの頻度を増強します)。 さらに、航空機が付属していた状態で増えることであるかもしれない、(適用範囲
Mitzel Informational [Page 17] RFC 3002 IAB Wireless Workshop December 2000
[17ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
of multiple ground and space-based access networks), requiring routing policy support for path selection. Finally, QoS path selection capabilities may be beneficial to arbitrate shared access or partition real-time control traffic from other data traffic.
複数の地面とスペースを拠点とするアクセスネットワーク)、経路選択の方針サポートを発送するのが必要です。 最終的に、QoS経路選択能力は、他のデータ通信量から共用アクセスかパーティション実時間制御トラフィックを仲裁するために有利であるかもしれません。
Initial prototype of ATN capabilities have been based on ISO IDRP [33] path selection and QoS routing policy. There was some discussion whether IDRP could be adopted for use in an IP environment. There was quick agreement that the preferred solution within the IETF would be to advance BGP4++ [8,54] as an IDRP-like replacement. This transitioned discussion to evaluation of ATN use of IDRP features and their equivalent to support in BGP. Several issues with BGP were raised for further investigation. For example, whether BGP AS space is sufficient to accommodate each aircraft as an AS? Also issues with mobility support; can BGP provide for dynamically changing peering as point of attachment changes, and alternative path selection policies based on current peerings? A significant amount of additional investigation is required to fully assess ATN usage of IDRP features, especially in the QoS area. These could lead to additional BGP requirements, for instance to effect different prioritization or path selection for aircraft control vs. passenger entertainment traffic.
ATN能力の初期のプロトタイプはISO IDRP[33]経路選択とQoSルーティング方針に基づきました。 IP環境における使用のためにIDRPを採用できたか否かに関係なく、何らかの議論がありました。 IETFの中の都合のよいソリューションがIDRPのような交換としてBGP4++[8、54]を進めるだろうことであるという迅速な協定がありました。 IDRPの特徴のATN使用の評価とのこの移行した議論とBGPでサポートするそれらの同等物。 BGPのいくつかの問題がさらなる調査のために提起されました。 BGP ASスペースがASとして各航空機を収容するために例えば十分であるか否かに関係なく? 移動性サポートの問題も。 BGPはダイナミックに接着点が変化しながらじっと見ながら変化して、現在のpeeringsに基づく迂回経路選択方針に備えることができますか? かなりの量の追加調査がIDRPの特徴のATN用法を完全に評価するのに必要です、特にQoS領域で。 例えば、これらは、航空機コントロールのために乗客エンターテインメントトラフィックに対して異なった優先順位づけか経路選択に作用するように追加BGP要件に通じるかもしれません。
3.6 Discussion on QoS Services
3.6 QoSサービスについての議論
Enabling support for voice and other realtime services along with data capabilities requires Quality of Service (QoS) features to arbitrate access to the limited transmission resources in wireless environment. The wireless and mobile environment requires QoS support for the last leg between the mobile device and network access point, accommodating roaming and unique characteristics of the wireless link.
声のサポートとデータ能力に伴う他のリアルタイムでサービスを可能にすると、ワイヤレスの環境における限られたトランスミッションリソースへのアクセスを仲裁するService(QoS)の特徴はQualityに要求されます。 ワイヤレスの、そして、モバイルの環境はモバイル機器とネットワークアクセスポイントの間の最後の航程のQoSサポートを必要とします、ワイヤレスのリンクのローミングとユニークな特性を収容して。
In addition to the discussion presented below, it was felt quite strongly that it is critical any QoS facility be provided as an underlying service independent of payload type. That is, there should be no built in knowledge of voice or other application semantics. This results in a feature that can be leveraged and easily extended to support new applications.
以下に提示された議論に加えてそれが重要ないずれもQoSであると全く強く感じられた、施設、基本的なサービスとして、ペイロードタイプの如何にかかわらず、提供してください。 すなわち、声か他のアプリケーションに関する知識で意味論を築き上げるべきではありません。 これは利用して、新しいアプリケーションをサポートするために容易に広げることができる特徴をもたらします。
3.6.1 Discussion on "Last Leg" QoS
3.6.1 「最後の航程」QoSについての議論
Discussion on voice over IP (VoIP) emphasized that (wireless) access link is typically the most constrained resource, and while contention access (CSMA) provides good utilization for data it is not ideal for voice. Two models were identified as potential solution in VoIP architecture. The first is to have the wireless device directly signal the local access router. A second alternative is to have the
IP(VoIP)の上の声についての議論は、(ワイヤレス)のアクセスリンクが通常最も制約つきなリソースであると強調しました、そして、主張アクセス(CSMA)はデータのための良い利用を提供しますが、声には、それは理想的ではありません。 2つのモデルがVoIPアーキテクチャの潜在的ソリューションとして特定されました。 1番目はワイヤレス機器に地方のアクセスルータを直接合図させることです。 2番目の代替手段は持つことになっています。
Mitzel Informational [Page 18] RFC 3002 IAB Wireless Workshop December 2000
[18ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
call control element (SIP agent [30]) "program" the edge router. This tradeoff seemed to be an area open for additional investigation, especially given the complications that may be introduced in the face of mobility and roaming handoffs. This appears a key component to solve for success in VoIP adoption.
コントロールを要素と呼んでください。(SIPエージェント[30])は縁のルータを「プログラムします」。 この見返りは追加調査において、開いている領域であるように思えました、移動性とhandoffsに移動することに直面して導入されるかもしれない複雑さを特に考えて。 これはVoIP採用の成功のために解決する主要なコンポーネントに現れます。
Work within the IEEE 802.11 WLAN group identified similar requirements for QoS support. That group is investigating a model employing two transmission queues, one for realtime and one for best-effort traffic. Additional plans include mapping between IP DiffServ markings [14,46] and IEEE 802 priorities.
IEEE802.11WLANグループの中の仕事はQoSサポートのための同様の要件を特定しました。 そのグループは2つのトランスミッション待ち行列、1つのリアルタイム用、およびベストエフォート型トラフィックのための1つを使うモデルを調査しています。 追加プランは、IP DiffServ印[14、46]とIEEE802プライオリティの間で写像するのを含んでいます。
The statement was also made that QoS over the wireless link is not the fundamental problem, rather it is handling mobility aspects and seamless adaptation across handoffs without service disruption. There were concerns about mechanisms establishing per-flow state (RSVP [13]). Issues include scaling of state, and signaling overhead and setup delays on roaming events. DiffServ [9] approach allows allocating QoS for aggregate traffic class, which simplifies roaming. However, DiffServ requires measurement and allocation adjustment over time, and policing to limit amount of QoS traffic injected.
また、むしろそれがサービスの崩壊のないhandoffsの向こう側のワイヤレスのリンクの上のQoSが基本的な問題でなく、取り扱い移動性局面とシームレスの適合であるという声明は、出されました。 1流れあたりの状態を設置するメカニズムに関する心配がありました。(RSVP[13])。 問題は、状態のスケーリングと、ローミングイベントでオーバーヘッドとセットアップ遅れに合図するのを含んでいます。 DiffServ[9]アプローチは集合トラフィックのクラスのためにQoSを割り当てます。(それは、ローミングを簡素化します)。 しかしながら、DiffServは時間がたつにつれて測定と割当調整を必要とします、そして、QoSの限界量までトラフィックを取り締まるのは注入されました。
3.6.2 Discussion on Path QoS Discovery
3.6.2 経路QoS発見についての議論
The HDR high speed wireless packet data system under development at Qualcomm highlights unique characteristics of some wireless media. This system provides users a channel rate between 38.4Kb/s and 2.4Mb/s, with throughput dependent on channel loading and distance from network access point. This gave rise to considerable discussion on whether it might be possible to discover and provide feedback to the application regarding current link or path QoS being received. This might enable some form of application adaptation.
クアルコムの開発中の高速HDRワイヤレスパケットデータ・システムはいくつかのワイヤレスのメディアのユニークな特性を目立たせます。 このシステムはスループットと共に38.4KB/sと2.4Mb/sの間のチャンネルレートをネットワークアクセスポイントからユーザにチャンネルローディングと距離に依存していた状態で提供します。 これはかなりの議論を現在のリンクか受け取られる経路QoSに関するアプリケーションにフィードバックを発見して、提供するのが可能であるかもしれないかどうか起こしました。 これは何らかの形式のアプリケーション適合を可能にするかもしれません。
In the case of the HDR system it was indicated that no such feedback is currently available. Additionally, it was argued that this is in accord with the current Internet stack model, which does not provide any mechanisms to expose this type of information. Counter arguments stated that there are growing demands in Internet QoS working groups requesting exposure of this type of information via standardized APIs. Members working on GPRS protocols also indicated frustration in deploying QoS capabilities without exposure of this information. This clearly seemed a topic for further investigations.
HDRシステムの場合では、そのようなどんなフィードバックも現在利用可能でないことが示されました。 さらに、これが現在のインターネットスタック・モデルに合っていると主張されました。(そのスタック・モデルは、この情報の種類をさらすためにどんなメカニズムも提供しません)。 カウンタ議論は、標準化されたAPIを通してこの情報の種類の暴露を要求するインターネットQoSワーキンググループには高まる需要があると述べました。 また、この情報の暴露なしでQoSが能力であると配布する際にGPRSプロトコルに取り組んでいるメンバーがフラストレーションを示しました。 これはさらなる調査に関して明確に話題に見えました。
A final area of discussion on QoS discovery focused on the question of how a server application might find out the capabilities of a receiver. This could allow for application adaptation to client device and path characteristics. One suggestion proposed use of RSVP payload, which is able to transport QoS information. A second
QoS発見についての議論の最終的な領域はサーバ・アプリケーションがどう受信機の能力を見つけるかもしれないかに関する質問に焦点を合わせました。これはクライアントデバイスと経路特性へのアプリケーション適合を考慮するかもしれません。 1つの提案がRSVPペイロードの使用を提案しました。(ペイロードはQoS情報を輸送できます)。 1秒
Mitzel Informational [Page 19] RFC 3002 IAB Wireless Workshop December 2000
[19ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
alternative is to push capability exchange and negotiation to the application layer. Discussion on this topic was brief, as application issues were deemed outside the workshop charter, however this also seems an area open for future investigation.
代替手段は能力交換と交渉を応用層に押し進めることです。 この話題についての議論が簡潔であった、しかしながら、アプリケーション問題がワークショップ特許の外で考えられたとき、また、これは今後の調査において、開いている領域に見えます。
3.7 Discussion on Header Compression
3.7 ヘッダー圧縮についての議論
A critical deterrent to Internet protocol adoption in the highly band-width constrained wireless cellular environment is the bit overhead of the protocol encoding. Examples presented highlighted how a voice application (layered over IP [52,19], UDP [51], and RTP [57]) requires a minimum of 40 bytes of headers for IPv4 or 60 bytes for IPv6 before any application payload (e.g., 24 byte voice sample). This overhead was also presented as a contributing factor for the creation of WAP Wireless Datagram Protocol (WDP) rather than IP for very low datarate bearers.
帯域幅非常に強制的なワイヤレスのセル環境におけるインターネットプロトコル採用への重要な抑止力はプロトコルコード化の噛み付いているオーバーヘッドです。 提示された例はaがどうアプリケーションを声に出すかを強調しました。(IP[52、19]の上で層にされます、UDP[51]、およびRTP[57])は以前、IPv6のためにどんなアプリケーションペイロード(例えば、24バイトの声のサンプル)にもヘッダーの最低40バイトをIPv4か60バイト必要とします。 また、このオーバーヘッドは非常に低いdatarate運搬人のためにIPよりむしろWAP Wirelessデータグラムプロトコル(WDP)の作成のための要因として提示されました。
Discussion on header compression techniques to alleviate these concerns focused on work being performed within the IETF Robust Header Compression (rohc) working group. This working group has established goals for wireless environment, to conserve radio spectrum, to accommodate mobility, and to be robust to packet loss both before the point where compression is applied and between compressor and decompressor. Additional requirements established were that the technique be transparent, does not introduce additional errors, and that it is compatible with common protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP).
これらの関心を軽減するヘッダー圧縮のテクニックについての議論はIETF Robust Header Compression(rohc)ワーキンググループの中で行われる仕事に焦点を合わせました。 このワーキンググループは、電波スペクトルを保存して、移動性を収容して、ポイント圧縮が適用されている前とコンプレッサーと減圧装置の間のパケット損失に強健になるようにワイヤレスの環境の目標を確立しました。 確立された追加要件はテクニックが透明であり、追加誤りを導入しないで、それは一般的なプロトコルレイヤリング(例えば、IPv4、IPv6、RTP/UDP/IP、TCP/IP)と互換性があるということでした。
The primary observation was that this problem is now largely solved! The working group is currently evaluating the ROCCO [38] and ACE [42] protocols, and expects to finalize its recommendations in the near future. It was reported that these encodings have a minimum header of 1 byte and result in average overhead of less than 2 bytes for an RTP/UDP/IP packet. There is some extra overhead required if transport checksum is required and some issues still to be analyzed related to interoperation with encryption and tunneling.
プライマリ観測はこの問題が現在主に解決されているということでした! ワーキンググループは、現在ロッコ[38]とACE[42]プロトコルを評価していて、近い将来推薦を成立させると予想します。 これらのencodingsにはRTP/UDP/IPパケットのための2バイト未満の平均したオーバーヘッドにおける1つのバイトと結果の最小のヘッダーがあると報告されました。 輸送チェックサムが必要であり、いくつかのまだ分析されるべき問題が暗号化とトンネリングがあるinteroperationに関連したなら必要である何らかの付加的なオーバーヘッドがあります。
A detriment to IPv6 adoption often cited is its additional header overhead, primarily attributed to its larger address size. A secondary observation made was that it's believed that IPv6 accommodates greater header compression than IPv4. This was attributed to the elimination of the checksum and identification fields from the header.
しばしば引用されたIPv6採用への損傷は頭上の、そして、主としてより大きいアドレスサイズまで結果と考えられた追加ヘッダーです。 されたセカンダリ観測はIPv6がIPv4より大きいヘッダー圧縮を収容するのが信じていたということでした。 これはヘッダーからチェックサムと識別分野の除去の結果と考えられました。
Discussion on use of WWW protocols over wireless highlighted protocol encodings as another potential detriment to their adoption. A number of alternatives were mentioned for investigation, including use of a "deflate" Content-Encoding, using compression with TLS [20], or
ワイヤレスの上のWWWプロトコルの使用についての議論は別の潜在的損傷として彼らの採用にプロトコルencodingsを目立たせました。 または多くの選択肢がTLS[20]との圧縮を使用して、Contentコード化される「空気を抜いてください」の使用を含む調査のために言及された。
Mitzel Informational [Page 20] RFC 3002 IAB Wireless Workshop December 2000
[20ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
Bellovin's TCP filters. Observation was made that it could be beneficial to investigate more compact alternative encoding of the WWW protocols.
BellovinのTCPフィルタ。 WWWプロトコルの、よりコンパクトな代替のコード化を調査するのが有益であるかもしれないという観測をしました。
3.8 Discussion on Applications Protocols
3.8 アプリケーションプロトコルについての議論
IETF protocol developments have traditionally taken the approach of preferring simple encode/decode and word alignment at the cost of some extra bit transmissions. It was stated that optimizing protocol encoding for bit savings often leads to shortcomings or limitations on protocol evolution. However, it was also argued that environments where physical limitations have an effect on transmission capacity and system performance may present exceptions where optimized encodings are beneficial. Cellular wireless and near-space satellite may fall into this category.
開発が簡単な状態で好みながらアプローチを伝統的に取ったIETFプロトコルは、いくつかの付加的なビット伝送の費用で整列をコード化するか、解読して、または言い表します。 ビットのために貯蓄をコード化するプロトコルを最適化するのがしばしばプロトコル発展における短所か制限に通じると述べられました。 しかしながら、また、物理的な制限が送信能力とシステム性能に影響を与える環境が最適化されたencodingsが有益である例外を提示するかもしれないと主張されました。 セルワイヤレスと近い人工衛星はこのカテゴリになるかもしれません。
The WAP protocols exhibit several examples where existing Internet protocols were felt to be too inefficient for adoption with very low datarate bearer services and limited capability devices. The WAP Wireless Session Protocol (WSP) is based on HTTPv1.1 [23], however WSP incorporates several changes to address perceived inefficiencies. WSP uses a more compact binary header encoding and optimizations for efficient connection and capability negotiation. Similarly, the WAP Wireless Application Environment (WAE) uses tokenized WML and a tag- based browser environment for more efficient operation.
WAPプロトコルは非常に低いdatarate運搬人サービスと限られた能力デバイスで既存のインターネットプロトコルが採用には効率が悪過ぎると感じられたいくつかの例を示します。 WAP Wireless Sessionプロトコル(WSP)はHTTPv1.1[23]に基づいていて、しかしながら、WSPは、知覚された非能率を扱うために数回の変化を取り入れます。 WSPは有能な接続と能力交渉によりコンパクトな2進のヘッダーコード化と最適化を使用します。 同様に、WAP Wireless Application Environment(WAE)用途tokenized WMLとタグは、より効率的な操作のためのブラウザ環境を基礎づけました。
Additional requests for more efficient and compact protocol encodings, and especially improved capability negotiation were raised during discussion on usage of WWW protocols with wireless handheld devices.
より効率的でコンパクトなプロトコルencodings、および特に改良された能力を求める交渉がWWWプロトコルの用法についての議論の間、ワイヤレスのハンドヘルドデバイスで上げられたという追加要求。
Finally, work within the near-space satellite environment has pointed out other physical limitations that can affect performance. In this case the long propagation delays can make "chatty" protocols highly inefficient and unbearable for interactive use. This environment could benefit from protocols that support some form of "pipelining" operation.
最終的に、人工衛星の近くの環境の中の仕事は性能に影響できる他の物理的な制限を指摘しました。 この場合、長い伝播遅延で、「話好きな」プロトコルは対話的な使用に非常に効率が悪く耐え難くなる場合があります。 この環境は何らかの形式の「パイプライン処理」操作をサポートするプロトコルの利益を得るかもしれません。
There seemed broad agreement that many of these observations represent valid reasons to pursue optimization of protocol operations. Investigation of compact protocol encoding, capability negotiation, and minimizing or overlapping round trips to complete a transaction could all lead to improved application performance across a wide range of environments.
これらの観測の多くがプロトコル操作の最適化を追求する正当な理由を表すという広い協定は見えました。 取引を完了するために周遊旅行をコンパクトなプロトコルコード化、能力交渉と、最小にするか、または重ね合わせる調査はさまざまな環境の向こう側に向上したアプリケーション性能にすべてつながるかもしれません。
Mitzel Informational [Page 21] RFC 3002 IAB Wireless Workshop December 2000
[21ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
3.9 Discussion on Proxy Agents
3.9 プロキシエージェントについての議論
Proxy agents are present in a number of the wireless and mobile architectures. They're often required to gateway between communication domains; terminate tunnel and translate between telephony system and Internet protocols (GPRS), or to escape the "walled garden" (WAP). In conjunction with limited capability handheld devices a proxy might be deployed to offload expensive processing such as public key operations, perform content filtering, or provide access to "backend" applications (e.g., email, calendar, database). In other cases the proxy may be required to work around protocol deployment limitations (e.g., NAT with limited IPv4 addresses).
プロキシエージェントは多くのワイヤレスの、そして、モバイルのアーキテクチャで出席しています。 それらがコミュニケーションドメインの間でしばしばゲートウェイに必要です。 トンネルを終えてください、そして、電話技術システムとインターネットプロトコル(GPRS)の間、または、エスケープに「塀で囲まれた庭」(WAP)を翻訳してください。 プロキシが公開鍵操作として高価な処理そのようなものを積み下ろすために配布されるかもしれない限られた能力ハンドヘルドデバイスに関連して、コンテントのフィルタリングを実行するか、または「バックエンド」アプリケーション(例えば、メール、カレンダー、データベース)へのアクセスを提供してください。 他の場合では、プロキシはプロトコル展開制限(例えば、限られたIPv4アドレスがあるNAT)の周りで働かなければならないかもしれません。
The discussion on proxy agents primarily recognized that there are a range of proxy agent types. Proxies may operate by intercepting and interpreting protocol packets, or by hijacking or redirecting connections. Some types of proxy break the Internet end-to-end communication and security models. Other proxy architectures may limit system scalability due to state or performance constraints. There was some desire to conduct further study of proxy agent models to evaluate their effect on system operation.
プロキシエージェントについての議論は、さまざまなプロキシエージェントタイプがあると主として認めました。 プロキシは、接続をプロトコルパケットを妨害して、解釈するか、ハイジャックするか、または向け直すことによって、働くかもしれません。 プロキシのタイプの中にはインターネットエンド・ツー・エンド通信と機密保護モデルを壊す人もいます。 他のプロキシアーキテクチャはシステムスケーラビリティ支払われるべきものを状態か性能規制に制限するかもしれません。 システム・オペレーションへの彼らの効果を評価するためにプロキシエージェントモデルのさらなる研究を行う何らかの願望がありました。
3.10 Discussion on Adoption of IPv6
3.10 IPv6の採用についての議論
Projections were presented claiming 1200 million cellular (voice)
subscribers, 600 million wired stations on the Internet, and over 600
million wireless data ("web handset") users by the year 2004. Right
up front there was caution about these projections, especially the
wireless data since it is highly speculative with little history.
Secondly, there was some doubt regarding potential for significant
revenues from user base over 1 billion subscribers; this may be
pushing the limits of world population with sufficient disposable
income to afford these devices. However, there was broad consensus
that cellular and Internet services are going to continue rapid
growth and that wireless data terminals have potential to form a
significant component of the total Internet. These conclusions
seemed to form the basis for many additional recommendations to push
for adoption of IPv6 protocols in emerging (3G) markets.
映像は、12億人のセル(声)加入者、インターネットの6億のワイヤードなステーション、および2004年までに6億人以上のワイヤレスのデータ(「ウェブ受話器」)ユーザを要求しながら、提示されました。 まさしく前払いで、これらの映像に関して警告があって、特にそれ以来のワイヤレスのデータは少ない歴史で非常に投機的です。 第二に、ユーザベースより多くの1 billion加入者からの重要な収入の可能性に関する何らかの疑問がありました。 これはこれらのデバイスを都合することができるくらいの可処分所得がある世界人口について限界を押し広げることであるかもしれません。 しかしながら、そんなにセルの一般的なコンセンサスがありました、そして、インターネットのサービスは急速な成長と、ワイヤレスのデータ端末には総インターネットの重要なコンポーネントを形成する可能性があり続けているでしょう。 これらの結論は(3G)市場として現れることにおける、IPv6プロトコルの採用を要求するという多くの追加推薦の基礎を形成するように思えました。
In nearly all the presentations on 3G cellular network technologies discussion on scaling to support the projected large number of wireless data users resulted in strong advocacy by the Internet representatives for adoption of IPv6 protocols. There were some positive signs that groups have begun investigation into IPv6. For example, 3GPP has already defined IPv6 as an option in their 1998 and 1999 specifications (release R98 and R99), and are considering
多くの映し出されたワイヤレスのデータについてサポートに合わせて調整するのと3Gセルラー・ネットワーク技術議論のほとんどすべてのプレゼンテーションでは、ユーザはIPv6プロトコルの採用のためのInternet代表による強い支持をもたらしました。 グループがIPv6に調査を始めたといういくつかの明るいサインがありました。 例えば、3GPPは1998と1999年のそれらの仕様(リリースR98とR99)に基づきIPv6を既にオプションと定義して、考えています。
Mitzel Informational [Page 22] RFC 3002 IAB Wireless Workshop December 2000
[22ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
specifying IPv6 as mandatory in the release 2000. The MWIF effort is also cognizant of IPv4 and IPv6 issues and is currently wrestling with their recommendations in this area.
リリース2000で義務的であるとしてIPv6を指定します。 MWIF取り組みは、また、IPv4とIPv6問題において認識力があって、現在、この領域で彼らの推薦と取っ組み合いをしています。
Although there was limited positive signs on IPv6 awareness, indication is that there are long fights ahead to gain consensus for IPv6 adoption in any of the 3G standards efforts. There was considerable feedback that the telephony carriers perceive IPv6 as more difficult to deploy, results in higher infrastructure equipment expenses, and adds difficulty in interoperation and gatewaying to the current (IPv4) Internet. Arguments for sticking with IPv4 primarily came down to the abundance and lower pricing of IPv4-based products, and secondary argument of risk aversion; there is currently minimal IPv6 deployment or operational experience and expertise, and the carriers do not want to drive development of this expertise. Finally, some groups argue IPv4 is sufficient for "walled garden" use, using IPv4 private address space (i.e., the "net 10" solution).
限られた明るいサインがIPv6認識にありましたが、指示はIPv6採用に関するコンセンサスを獲得するために3G規格取り組みのどれかには長い戦いが先にあるということです。 電話キャリヤーが、より難しいとしてのIPv6が配布すると知覚するかなりのフィードバックと、より高いインフラストラクチャ設備費における結果と、interoperationで困難を加えて、現在の(IPv4)インターネットにgatewayingするのがありました。 IPv4に主として忠実である議論はIPv4ベースの製品の豊富と低い価格設定、および危険回避のセカンダリ議論に落ちました。 現在、最小量のIPv6展開か運用経験と専門的技術があります、そして、キャリヤーはこの専門的技術の開発を追い立てたがっていません。 すなわち、最終的に、いくつかのグループが、IPv4が「塀で囲まれた庭」使用に十分であると主張します、IPv4プライベート・アドレススペースを使用して(「10インチのネットのソリューション)」
One other area of concern regarding IPv6 usage is perceived memory and processing overhead and its effect on small, limited capability devices. This was primarily directed at IPv6 requirement for IPsec implementation to claim conformance. Arguments that continued increase in device capacity will obviate these concerns were rejected. It was stated that power constraints on these low-end devices will continue to force concerns on memory and processing overhead, and impact introduction of other features. There was no conclusion on whether IPsec could be made optional for these devices, or the effect if these devices were "non-compliant".
IPv6用法に関して重要な他の1つの領域が小さくて、限られた能力デバイスへのメモリと、処理オーバヘッドとその効果であると知覚されます。 IPsec実装が順応を要求するというIPv6要件は主としてこれに向けられました。 デバイス容量の継続的な増加がこれらの関心を取り除くという主張は拒絶されました。 これらのローエンドデバイスにおけるパワー規制が、メモリと処理オーバヘッドに関する心配、および他の特徴の影響導入を強制し続けると述べられました。 これらのデバイスが「不従順である」ならIPsecをこれらのデバイス、または効果に任意にすることができるかどうかに関する結論が全くありませんでした。
Emerging 3G cellular networks appear ideal environment for IPv6 introduction. IPv6 addresses scaling requirements of wireless data user projections and eliminates continued cobbling of systems employing (IPv4) private address space and NAT. This appears an area for IAB and Internet community to take a strong stance advocating adoption of IPv6 as the various 3G forums wrestle with their recommendations.
現れている3Gセルラー・ネットワークはIPv6序論に関して理想的な環境に現れます。 IPv6は、ワイヤレスのデータユーザ映像のスケーリング要件を扱って、修繕しながら、続けられていた状態でシステムがプライベート・アドレススペースとNATを使うのを(IPv4)排泄します。 IABとインターネットコミュニティが様々な3Gフォーラムが彼らの推薦と取っ組み合いをしながらIPv6の採用を支持する強い姿勢を取るように、これは領域に現れます。
3.11 Discussion on Signaling
3.11 シグナリングについての議論
Discussion on signaling focused on call setup and control functions, and the effects of mobility. The 3G.IP group has investigated standardizing on either H.323 [32] or SIP [30]. Currently support seems to be split between the protocols, and neither seemed ideal without support for mobility. During discussion on VoIP it was presented that SIP does support mobility, with graceful handling of mobile handoff, updating location information with remote peer, and even simultaneous handoff of both endpoints. The problem with SIP adoption seems to be its slow standardization brought about by
シグナリングについての議論は呼び出しセットアップとコントロールに機能、および移動性の効果の焦点を合わせました。 3G.IPグループは、H.323で[32]かSIP[30]を標準化しながら、調査されました。 現在の、サポートはプロトコルの間で分けられるように思えました、そして、どちらもは移動性のサポートなしで理想的に思えませんでした。 それが提示されたVoIPについての議論の間、そのSIPは移動性をサポートします、モバイル移管の優雅な取り扱いで、リモート同輩がいる位置情報、および両方の終点の同時の移管さえアップデートして。 SIP採用に関する問題は引き起こされた遅い標準化であるように思えます。
Mitzel Informational [Page 23] RFC 3002 IAB Wireless Workshop December 2000
[23ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
focusing on the harder multicast model rather than expediting definition of a unicast "profile". There seems great need for IETF to expedite finalization of SIP, however some argued at this point it's likely many products will need to develop support for both SIP and H.323, and for their interoperation.
むしろユニキャスト「プロフィール」の定義を速めるより困難なマルチキャストモデルに焦点を合わせます。 IETFがSIPの決定を速めるすばらしい必要性は思えて、しかしながら、或るものは、ここに多くの製品が、SIPとH.323の両方、およびそれらのinteroperationのサポートを開発する必要があるのが、ありそうであると主張しました。
A short discussion was also raised on whether it is the correct model to incorporate the additional protocol mechanisms to accommodate mobility into the SIP signaling. An alternative model might be to build on top of the existing mobile IP handoff facilities. There was no conclusion reached, however it seemed an area for further investigation.
また、短い議論はSIPシグナリングに移動性を収容するために追加議定書メカニズムを組み込むのが、正しいモデルであるかどうかに関して上げられました。 代替のモデルは既存のモバイルIP移管施設の上に建てることになっているかもしれません。 さらなる調査に関してどのように領域に見えたとしても達した結論が全くありませんでした。
3.12 Discussion on Interactions Between IETF and Other Standards
Organizations
3.12 IETFと他の規格組織との相互作用についての議論
There were many examples where non-IETF standards organizations would like to directly adopt IETF standards to enable Internet (or similar) services. For example IEEE 802.11 WLAN relies on adoption of IETF standards for mobile IP, end-to-end security, and AAA services. 3GPP is looking into the IETF work on header compression. WAPF derived its transport, security, and application environment from Internet protocols. At first glance these would seem successes for adoption of Internet technologies, however the decision to rely on IETF standards often introduced frustrations too.
多くの例が非IETF規格組織がインターネットの、そして、(同様)のサービスを可能にするために直接IETF規格を採用したがっているところにありました。 例えば、IEEE802.11WLANはモバイルIPのIETF規格の採用、終わりから終わりへのセキュリティ、およびAAAサービスに依存します。 3GPPはヘッダー圧縮に対するIETF仕事を調べています。 WAPFはインターネットプロトコルから輸送、セキュリティ、およびアプリケーション環境を引き出しました。 一見したところではこれらはインターネット技術の採用に関して成功に見えて、しかしながら、IETF規格を当てにするという決定はしばしばフラストレーションも導入しました。
One common theme for frustration is differences in standardization procedures. For instance, 3GPP follows a strict model of publishing recommendations yearly; any feature that cannot be finalized must be dropped. On the other hand the IETF working groups have much less formalized schedules, and in fact often seem to ignore published milestone dates. This has led to a common perception within other standards organizations that the IETF cannot deliver [on time].
フラストレーションのための1つの一般的なテーマが標準化手順の違いです。 例えば、3GPPは毎年出版推薦の厳しいモデルに従います。 成立させることができないどんな特徴も下げなければなりません。 他方では、IETFワーキンググループは、まして、スケジュールを正式にして、事実上、発行された重大事件期日を無視するようにしばしば思えます。 これはIETFが[定刻に]提供できない他の規格組織の中で一般的な知覚に通じました。
A second area identified where IETF differs from other organizations is in publication of "system profile". For example defining interoperation of IPsec, QoS for VoIP and video conferencing, and billing as a "service". Wading through all the protocol specifications, deciding on optional features and piecing together the components to deliver a commercial quality service takes considerable expertise.
IETFが他の組織と異なっているところで特定された2番目の領域が「システムプロフィール」の公表にあります。 例えば、IPsecのinteroperation、VoIPのためのQoS、ビデオ会議、および支払いを「サービス」と定義します。 すべてのプロトコル仕様をなんとかしてやり通して、商業質の高いサービスを提供するためにオプション機能を決めて、コンポーネントに継ぎを当てると、かなりの専門的技術が取ります。
Thirdly, there was often confusion about how to get involved in IETF standards effort, submit requirements, and get delivery commitments. Many people seem unaware and surprised at how open and simple it is to join in IETF standardization via working group meetings and mailing list.
三番目に、IETF規格取り組みにかかわって、要件を提出して、どう配送委任を得るかに関して混乱がしばしばありました。 多くの人々がワーキンググループミーティングとメーリングリストでIETF標準化に参加するのがどれくらい開いて簡単かに気づかなく驚いているように見えます。
Mitzel Informational [Page 24] RFC 3002 IAB Wireless Workshop December 2000
[24ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
There wasn't really a large amount of discussions on ways to address these differences in standards practices. However, it did seem beneficial to understand these concerns and frustrations. It seemed clear there can be some benefits in improving communication with other standards organizations and encouraging their participation in IETF activities.
本当に、規格習慣のこれらの違いを扱う方法についての多量の議論がありませんでした。 しかしながら、これらの関心とフラストレーションを理解しているのは有益に思えました。 それは他の規格組織と共にコミュニケーションを改良して、IETF活動で彼らの参加を奨励するのにおいていくつかの利益があることができるのが明確に見えました。
4 Recommendations
4つの推薦
The IAB wireless workshop provided a forum for those in the Internet research community and in the wireless and telephony community to meet, exchange information, and discuss current activities on using Internet technology in wireless environments. However the primary goal from the perspective of the IAB was to reach some understanding on any problems, both technical or perceived deficiencies, deterring the adoption of Internet protocols in this arena. This section documents recommendations of the workshop on actions by the IAB and IESG, IRTF research efforts, and protocol development actions for the IETF to address these current deficiencies and foster wider acceptance of Internet technologies.
ワイヤレスの環境でインターネット技術を使用するときインターネット研究団体とワイヤレスと電話共同体のものが会って、情報交換して、現在の活動について議論するように、IABのワイヤレスのワークショップはフォーラムを提供しました。 しかしながら、IABの見解からのプライマリ目標はどんな問題における何らかの理解に達することでした、ともに技術的であるか知覚された欠乏、このアリーナでのインターネットプロトコルの採用を思いとどまらせて。 このセクションはIABとIESGによる動作、IRTF研究取り組み、およびプロトコル開発動作のIETFがこれらが現在の欠乏であると扱って、インターネット技術の、より広い承認を伸ばすというワークショップの推薦を記録します。
4.1 Recommendations on Fostering Interaction with Non-Internet Standards
Organizations
4.1 非インターネット規格組織との相互作用を伸ばすときの推薦
A clear consensus of the workshop is that dialog needs to be improved. The Internet community should attempt to foster communication with other standards bodies, including WAPF, MWIF, 3GPP, 3G.IP, etc. The goal is to "understand each others problems", provide for requirements input, and greater visibility into the standardization process.
ワークショップの明確なコンセンサスは対話が、改良される必要があるということです。 WAPF、MWIF、3GPP、3G.IPなどを含んでいて、インターネットコミュニティは、他の標準化団体とのコミュニケーションを伸ばすのを試みるべきです。 「他のもののためにそれぞれ問題を理解してください」には目標があって、要件入力、および、より大きい目に見えることに標準化過程に備えてください。
4.1.1
4.1.1
It was recommended to take a pragmatic approach rather than formalizing liaison agreements. The formalized liaison model is counter to the established Internet standards process, is difficult to manage, and has met with very limited success in previous trials. Instead, any relevant IETF working group should be strongly encouraged to consider and recommend potential liaison requirements within their charter.
連絡協定を正式にするよりむしろ実際的なアプローチを取るのはお勧めでした。 正式にされた連絡モデルは、確立したインターネット標準化過程へのカウンタであり、管理するのが難しく、前のトライアルの非常に限られた成功を得ました。 代わりに、どんな関連IETFワーキンググループも、彼らの特許の中で潜在的連絡要件を考えて、推薦するよう強く奨励されるべきです。
4.1.2
4.1.2
It was recommended to avoid formation of jointly sponsored working groups and standards. Once again this has shown limited success in the past. The preferred mode of operation is to maintain separate standards organizations but to encourage attendance and participation of external experts within IETF proceedings and to avoid overlap.
共同で後援されたワーキンググループと規格の構成を避けるのはお勧めでした。 もう一度、これは過去に限られた成功を示しました。 しかし、操作の最もよく使われる方法は、IETF議事の中で外部の専門家の出席と参加を奨励して、オーバラップを避けるために別々の規格組織であることを支持することになっています。
Mitzel Informational [Page 25] RFC 3002 IAB Wireless Workshop December 2000
[25ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
An exception to this style of partitioning meeting sponsorship is less formal activities, such as BOFs. It was recommended that sponsoring joint BOF could be beneficial. These could enable assembly of experts from multiple domains early in the process of exploring new topics for future standards activities.
このスタイルの仕切りのミーティングスポンサーシップへの例外はBOFsなどの、より少ないホルマール活性です。 共同BOFを後援するのが有益であるかもしれないことは、お勧めでした。 今後の規格活動のために新しい話題を探ることの途中にこれらは早く複数のドメインから専門家のアセンブリを可能にするかもしれません。
4.1.3
4.1.3
A principle goal of fostering communication with other standards organizations is mutual education. To help in achieving this goal recommendations were made related to documenting more of the history behind Internet standards and also in coordinating document reviews.
他の規格組織とのコミュニケーションを伸ばすという原則目標は互いの教育です。 この目標を達成するのを手伝うために、インターネット標準の後ろに一層の歴史を記録して、また、ドキュメントレビューを調整する際に推薦状を関連するようにしました。
It was recommended that IETF standards groups be encouraged to create or more formally document the reasons behind algorithm selection and design choices. Currently much of the protocol design history is difficult to extract, in the form of working group mail archives or presentations. Creation of these documents could form the basis to educate newcomers into the "history" and wisdom behind the protocols.
IETF規格グループがアルゴリズム選択とデザイン選択の後ろに理由を作成するか、または、より正式に記録するよう奨励されるのは、お勧めでした。 現在の、プロトコルデザイン歴史の多くは抽出するのが難しいです、ワーキンググループメールアーカイブかプレゼンテーションの形で。 これらのドキュメントの作成はプロトコルの後ろで新来者を教育する基礎で「歴史」と知恵を作るかもしれません。
It was recommended that mutual document reviews should be encouraged. This helps to disseminate information on current standards activities and provides an opportunity for external expert feedback. A critical hurdle that could severely limit the effectiveness of this type of activity is the intellectual property and distribution restrictions some groups place on their standards and working documents.
互いのドキュメントレビューが奨励されるのは、お勧めでした。 これは、現在の規格活動の情報を広めるのを助けて、外部の専門のフィードバックに機会を与えます。 厳しくこのタイプの活動の有効性を制限できた重要なハードルは、いくつかのグループがそれらの規格と働くドキュメントに関して課す知的所有権と分配制限です。
4.2 Recommendations for Dealing with "Walled Garden" Model
「塀で囲まれた庭」に対処するための4.2の推薦がモデル化されます。
There are several perceived benefits to the "walled garden" (captive customer) model, similar to current deployment of "intranets". These range from simplified user security to "captive customer" economic models. There was disagreement on the extent this deployment model might be perpetuated in the future. However it is important to recognize this model exists and to make a conscious decision on how to accommodate it and how it will affect protocol design.
「イントラネット」の現在の展開と同様の「塀で囲まれた庭」(専属顧客)モデルへのいくつかの知覚された利益があります。 これらは簡易型のユーザセキュリティから「専属顧客」経済モデルまで及びます。 不一致がこの展開モデルが将来永続させられるかもしれないという範囲にありました。 しかしながら、このモデルが存在すると認めて、どのようにそれを収容するか、そして、それがどのようにプロトコルデザインに影響するかに関する意識的な決断をするのは重要です。
4.2.1
4.2.1
It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an "open model". IETF protocol design must address seamless, secure, and scalable access.
それは「塀で囲まれた庭」展開シナリオの偏在の如何にかかわらずプロトコルと建築決定がこのモデルを狙うべきでないことが強く勧められました。 aの向こう側に非常に多様な作動と異機種混在環境でインターネットプロトコルの成功を続けるために、IETFは、「開放モデル」の採用を伸ばし続けなければなりません。 IETFプロトコルデザインはシームレスの、そして、安全で、スケーラブルなアクセサリーを扱わなければなりません。
Mitzel Informational [Page 26] RFC 3002 IAB Wireless Workshop December 2000
[26ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.2.2
4.2.2
Recognition that the "walled garden" model has some perceived benefits led to recommendations to better integrate it into the Internet architecture. These focused on service location and escape from the "walled garden".
「塀で囲まれた庭」モデルが利益であるといくつかを知覚させるという認識はインターネットアーキテクチャとそれをよりよく統合するという推薦につながりました。 これらは、サービス位置に焦点を合わせて、「塀で囲まれた庭」から逃れます。
It was recommended to investigate standard protocols for service and proxy discovery within the "walled garden" domain. There are already a number of candidate mechanisms, including static preconfiguration, DNS [22,27,44,45], BOOTP [18], DHCP [21], SLP [28], and others. Specific recommendations on use of these protocols in this environment can help foster common discovery methods across a range of access devices and ease configuration complexity.
サービスとプロキシ発見のために「塀で囲まれた庭」ドメインの中で標準プロトコルを調査するのはお勧めでした。 多くの候補メカニズムが既にあります、静的な前構成、DNS[22、27、44、45]、BOOTP[18]、DHCP[21]、SLP[28]、および他のものを含んでいて。 この環境におけるこれらのプロトコルの使用の特定の推薦は、さまざまなアクセスデバイスと容易さ構成の複雑さの向こう側に一般的な発見メソッドを伸ばすのを助けることができます。
It was recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet). It seemed clear that a better model is required than trying to map all access over a HTTP [23] transport connection gateway. One suggestion was to propose use of IP!
庭の壁を通して輸送する標準方法を調査するのはお勧めでした(例えば、インターネットに逃げてください)。 より良いモデルが必要であるのはHTTP[23]輸送接続ゲートウェイの上のすべてのアクセスを写像しようとするより明確に見えました。 1つの提案はIPの使用を提案することでした!
4.3 Recommendations on IPv4 and IPv6 Scaling
IPv4における4.3の推薦とIPv6スケーリング
Wireless operators are projecting supporting on the order of 10's to 100's million users on their Internet-based services. Supporting this magnitude of users could have severe scaling implications on use of the dwindling IPv4 address space.
無線通信士は、100への10年代の注文ときに彼らのインターネット・サービスでの100万人のユーザをサポートしながら、突出しています。 ユーザのこの大きさをサポートすると、厳しいスケーリング意味はやせ細っているIPv4アドレス空間の使用に持たれているかもしれません。
4.3.1
4.3.1
There was clear consensus that any IPv4-based model relying on traditional stateless NAT technology [60] is to be strongly discouraged. NAT has several inherent faults, including breaking the Internet peer-to-peer communication model, breaking end-to-end security, and stifling deployment of new services [16,29,31]. In addition, the state and performance implications of supporting 10's to 100's million users is cost and technologically prohibitive.
どんなIPv4ベースのモデル信用も伝統的な状態がないNAT技術[60]で強くがっかりすることであるという明確なコンセンサスがありました。 NATには、いくつかの固有の欠点があります、新種業務[16、29、31]のインターネットピアツーピアコミュニケーションモデル、終わりから終わりへの壊れているセキュリティ、および息苦しい展開を壊すのを含んでいて。 さらに、100の100万人のユーザに10年代をサポートする状態と性能含意は、費用であって技術的に禁止です。
4.3.2
4.3.2
Realm specific IP (RSIP) [10,11] has potential to restore the end- to-end communication model in the IPv4 Internet, broken by traditional NAT. However there was considerable reluctance to formally recommend this as the long term solution. Detriments to its adoption include that the protocol is still being researched and defined, and potential interactions with applications, QoS features, and security remain. In addition, added signaling, state, and tunneling has cost and may be technologically prohibitive scaling.
分野の特定のIP(RSIP)[10、11]には、伝統的なNATによって壊されたIPv4インターネットで終わりまでの終わりのコミュニケーションモデルを返す可能性があります。 しかしながら、長期ソリューションとして正式にこれを推薦するというかなりの不本意がありました。 プロトコルがまだそうである研究されて、定義されるインクルード、およびアプリケーションとの潜在的相互作用、QoSが特徴とする採用、およびセキュリティの残りへの損傷。 さらに、シグナリング、状態、およびトンネリングがかかったと言い足して、技術的に禁止のスケーリングであるかもしれません。
Mitzel Informational [Page 27] RFC 3002 IAB Wireless Workshop December 2000
[27ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.3.3
4.3.3
The clear consensus of the workshop was to recommend adoption of an IPv6-based solution to support these services requiring large scaling. Adoption of IPv6 will aid in restoring the Internet end- to-end communication model and eliminates some roaming issues. Adoption of IPv6 in this marketspace could also help spur development of IPv6 products and applications, and hasten transition of the Internet. It was recognized that some application gateways are required during transition of the IPv4 Internet, however it was felt that the scaling and roaming benefits outweighed these issues.
ワークショップの明確なコンセンサスはIPv6ベースのソリューションの採用が大きいスケーリングを必要とするこれらのサービスをサポートすることを勧めることでした。 IPv6の採用は、インターネットの終わりから終わりへのコミュニケーションモデルを返す際に支援して、いくつかのローミング問題を排除します。 このmarketspaceでのIPv6の採用は、また、IPv6製品とアプリケーションの拍車開発を助けて、インターネットの変遷を急がせるかもしれません。 いくつかのアプリケーションゲートウェイがIPv4インターネットの変遷の間必要であると認められて、しかしながら、スケーリングとローミング利益がこれらの問題より重かったと感じられました。
4.3.4
4.3.4
It was recommended that an effort be made to eliminate any requirement for NAT in an IPv6 Internet. The IAB believes that the IPv6 address space is large enough to preclude any requirement for private address allocation [55] or address translation due to address space shortage [15]. Therefore, accomplishing this should primarily require installing and enforcing proper address allocation policy on registry and service providers. It was recommended to establish policies requiring service providers to allocate a sufficient quantity of global addresses for a sites use. The feeling was that NAT should be easily eliminated provided efficient strategies are defined to address renumbering [17,62] and mobility [37] issues.
取り組みはIPv6インターネットのNATのためのどんな要件も排除させられるのが、お勧めでした。 IABは、IPv6アドレス空間がアドレス空間不足[15]のためプライベート・アドレス配分[55]かアドレス変換のためのどんな要件も排除できるくらい大きいと信じています。 したがって、これを達成するのは、インストールして、適切なアドレス配分方針に登録とサービスプロバイダーに押しつけるのを主として必要とするべきです。 サービスプロバイダーがサイト使用のための十分な数量のグローバルなアドレスを割り当てるのを必要とする方針を確立するのはお勧めでした。 感じは効率的な戦略が[17、62]に番号を付け替えさせて、移動性[37]が問題であると扱うために定義されるならNATが容易に排除されるべきであるということでした。
4.4 Recommendations on IPv4 and IPv6 Mobility
4.4 IPv4における推薦とIPv6の移動性
An inherent characteristic of wireless systems is their potential for accommodating device roaming and mobility. Scalable and efficient support of this mobility within Internet protocols can aid in pushing native IP services out to the mobile devices.
ワイヤレスシステムの固有の特性はそれらのデバイスローミングと移動性を収容する可能性です。 インターネットプロトコルの中のこの移動性のスケーラブルで効率的なサポートはネイティブのIPサービスをモバイル機器に押し出す際に支援されることができます。
4.4.1
4.4.1
Several limitations were identified relating to current specification of mobile IPv4 [48]. Primary among these limitations is that mechanisms to support redundant home agents and failover are not currently defined. Redundant home agents are required to avoid single point of failure, which would require (proprietary) extensions. Additional deficiencies related to lack of route optimization, and tunneling and path MTU issues were also identified. Due to these limitations there was reluctance to recommend this as a solution.
いくつかの制限が、モバイルIPv4[48]の現在の仕様に関連しながら、特定されました。 これらの制限の中の予備選挙は余分なホームがエージェントとフェイルオーバーであるとサポートするメカニズムが現在定義されないということです。 余分なホームのエージェントは失敗の単一のポイントを避けなければなりません。(失敗は(独占)の拡大を必要とするでしょう)。 追加欠乏は経路最適化の不足に関連しました、そして、また、トンネリングと経路MTU問題は特定されました。 これらの制限のために、ソリューションとしてこれを推薦するという不本意がありました。
Mitzel Informational [Page 28] RFC 3002 IAB Wireless Workshop December 2000
[28ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.4.2
4.4.2
It was recommended to encourage adoption of IPv6 mobility extensions [37] to support roaming capabilities in the wireless environment. IP mobility over IPv6 incorporates improvements to address several limitations of the IPv4-based mobility. The ability to use autoconfiguration for "care of" address improves robustness and efficiency. Additionally, path MTU is more easily adapted when a router forwards to a new "care of" address.
IPv6移動性拡張子[37]の採用が、ローミングがワイヤレスの環境で能力であるとサポートするよう奨励するのはお勧めでした。 IPv6の上のIPの移動性は、IPv4ベースの移動性のいくつかの制限を扱うために改良を取り入れます。 アドレスは自動構成を使用する能力について「気にかけられます」。丈夫さと効率を高めます。 さらに、経路MTUはaに新しいフォワードが「気にかける」ルータであるときに、容易により適合させられたアドレスです。
Building wireless roaming atop IPv6-based mobility may introduce IPv4/IPv6 transition issues unique to the mobile environment. It was recommended to add investigation of these issues to the charter of the existing IETF Next Generation Transition (ngtrans) working group, provided any mobile IP interoperation issues be identified.
IPv6ベースの移動性の上でワイヤレスのローミングを築き上げると、モバイル環境にユニークなIPv4/IPv6変遷問題は紹介されるかもしれません。 既存のIETF Next Generation Transition(ngtrans)ワーキンググループの特許へのこれらの問題の調査、モバイルIP interoperationが発行する提供されたいずれも特定されると言い足すのはお勧めでした。
4.4.3
4.4.3
Scalable and widespread authentication, authorization, and accounting (AAA) services are critical to the deployment of commercial services based on (wireless) mobile IP. Some work is progressing on definition of these standards for IP mobility [26,49]. However, due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of these AAA standards and investigation of AAA scalability as high priorities.
スケーラブルで広範囲の認証、承認、および会計(AAA)サービスは(ワイヤレス)のモバイルIPに基づく商業サービスの展開に重要です。 いくらかの仕事がIPの移動性[26、49]のこれらの規格の定義のときに進歩をします。 しかしながら、商業サービスを配布する能力に関するこれらのプロトコルの極めて重要な役割のために、高いプライオリティとしてAAAスケーラビリティのこれらのAAA規格と調査の決定をするのはお勧めでした。
4.5 Recommendations on TCP and Transport Protocols
4.5 TCPにおける推薦とトランスポート・プロトコル
The wireless environment and applications place additional requirements on transport protocol. Unique link error and performance characteristics, and application sensitivity to connection setup and transaction semantics has led to "optimized" transports specific to each environment. These new transports often lack robustness found in Internet transport and place barriers to seamless gatewaying to the Internet. It was felt that better education on transport design and cooperation on Internet transport evolution could lead to significant improvements.
ワイヤレスの環境とアプリケーションは追加要件をトランスポート・プロトコルに置きます。 ユニークなリンク誤りと特性、および接続へのアプリケーション感度がセットアップして、トランザクション意味論がつながった性能は各環境に特定の輸送を「最適化しました」。 これらの新しい輸送はしばしばインターネット輸送と場所バリアでインターネットへのシームレスのgatewayingに見つけられた丈夫さを欠いています。 輸送デザインにおけるより良い教育とインターネット輸送発展における協力がかなりの改善につながることができると感じられました。
4.5.1
4.5.1
It was recommended that the IETF Transport Area (tsv) working group document why Internet transport protocols are the way they are. The focus should be on generic transport issues and mechanisms, rather than TCP specifics. This should capture usage and tradeoffs in design of specific transport mechanisms (e.g., connection
IETF Transport Area(tsv)ワーキンググループが、インターネットトランスポート・プロトコルがなぜ道であるかを記録するのは、お勧めでした。 ジェネリック輸送問題とTCP詳細よりむしろメカニズムの上に焦点があるべきです。 これが特定の移送機構のデザインにおける用法と見返りを得るべきである、(例えば、接続
Mitzel Informational [Page 29] RFC 3002 IAB Wireless Workshop December 2000
[29ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
establishment, congestion control, loss recovery strategies, etc.), and document some of the history behind transport research in the Internet.
設立、輻輳制御、損失回復戦略など)、そして、歴史背中輸送のいくつかがインターネットで研究するドキュメント。
This "entry point" document into transport design is in direct support of the recommendations in section 4.1 to foster communication and mutual education. In addition it was deemed critical that the Internet community make it very clear that congestion control is not optional. Internet researchers have learned that optimizing for a single link or homogeneous environment does not scale. Early work by Jacobson [34,35], standardization of TCP congestion control [5], and continuing work within the IETF Endpoint Congestion Management (ecm) working group could provide excellent basis for education of wireless transport designers.
輸送デザインへのこの「エントリー・ポイント」ドキュメントはコミュニケーションと互いの教育を伸ばすというセクション4.1の推薦のダイレクトサポート中です。 さらに、インターネット共同体が輻輳制御が任意でないことを非常に明確にするのは重要であると考えられました。 インターネット情報検索専門家は、単一のリンクか均質の環境のために最適化するのが比例しないことを学びました。 ジェーコブソン[34、35]による早めの仕事、TCP輻輳制御[5]の規格化、およびIETF Endpoint Congestion Management(ecm)ワーキンググループの中の継続する仕事はワイヤレスの輸送デザイナーの教育の素晴らしい基礎を提供するかもしれません。
4.5.2
4.5.2
It was recommended that the IETF actively solicit input from external standards bodies on identifying explicit requirements and in assessing inefficiencies in existing transports in support of cellular and wireless environments. This has proven highly effective in identifying research topics and in guiding protocol evolution to address new operational environments, for instance in cooperation with groups doing satellite-based internetworking [4,6].
セルの、そして、ワイヤレスの環境を支持してIETFが明白な要件を特定して、既存の輸送における非能率を評価する際に活発に外部の標準化団体からの入力に請求するのは、お勧めでした。 これは、例えば、衛星ベースのインターネットワーキング[4、6]をするグループと提携して新しい運用環境を扱うために研究話題を特定して、誘導しているプロトコル発展で高効率であると判明しました。
4.5.3
4.5.3
It was recommended that the IAB make wireless standards bodies aware of the existence, and get them active in, the IETF Transport Area (tsv) working group. This transport "catch all" could provide an excellent forum for workers outside the Internet community to propose ideas and requirements, and engage in dialog with IESG members prior to contributing any formal proposal into the IETF or incurring overhead of working group formation.
IABがワイヤレスの標準化団体を存在を知るようにして、それらをアクティブにするのは、お勧めでした、IETF Transport Area(tsv)ワーキンググループ。 インターネットコミュニティの外の労働者が考えと要件を提案するように素晴らしいフォーラムを提供して、どんな正式な提案もIETFに寄付する前のIESGメンバーと共に対話に従事できたか、またはワーキンググループ構成のオーバーヘッドを被って、この輸送は「すべてを捕らえます」。
4.5.4
4.5.4
Mobile radio environments may often be subject to frequent temporary outages. For example, roaming through an area that is out of range of any base station, or disruptions due to base station handoffs. This violation of the congestive loss assumption of TCP can have severe detrimental effect on transport performance. It was recommended to investigate mechanisms for improving transport performance when these non-congestive loss can be detected. Areas for potential research identified include incorporation of "hints" to the sender providing Non-Congestive Loss Indication (NCLI) or stimulating transmission after link recovery via Source Encourage
移動無線環境は、一時的な供給停止によく行くためにしばしばなることがあるかもしれません。 例えば、領域を通って移動して、それはどんな基地局の範囲、または基地局handoffsによる分裂からも脱しています。 TCPの充血性の損失仮定のこの違反は輸送性能に厳しい有害な影響を持つことができます。 これらであるときに、輸送性能を向上させるためにメカニズムを調査することが勧められる場合非充血性の損失を検出できるということでした。 特定された潜在的調査のための領域はリンク回復の後にSource Encourageを通してNon充血性のLoss Indication(NCLI)か刺激的なトランスミッションを提供する送付者に「ヒント」の編入を含んでいます。
Mitzel Informational [Page 30] RFC 3002 IAB Wireless Workshop December 2000
[30ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
(SE) message [39]. This likely falls to the auspice of the IETF Performance Implications of Link Characteristics (pilc) working group.
(SE)メッセージ[39]。 これはおそらくLink Characteristics(pilc)ワーキンググループのIETFパフォーマンスImplicationsの前兆に落下します。
4.5.5
4.5.5
Many wireless applications require transaction semantics and are highly sensitive to connection establishment delays (e.g., WAP). However, it is still desirable to efficiently support streaming of large bulk transfers too. It was recommended to investigate tradeoffs in supporting these transaction and streaming connections. Potential areas for investigation include tradeoffs between minimal transaction transport and potential security and denial of service (DoS) attacks, mechanisms to piggyback data during connection establishment to eliminate round trip delays, or ways for endpoints to cooperate in eliminating setup handshake for simple transactions while providing switch-over to reliable streaming for bulk transfers.
多くの無線機器が、トランザクション意味論を必要として、コネクション確立遅れ(例えば、WAP)に非常に敏感です。 しかしながら、効率的に大きいバルク転送についてもストリーミングをサポートするのはまだ望ましいです。 これらのトランザクションとストリーミングの接続をサポートする際に見返りを調査するのはお勧めでした。 調査のための潜在的領域は、大量において、スイッチ信頼できるストリーミングに終わっている転送を供給している間、単純取引のためのセットアップ握手を排除するのに協力するために最小量のトランザクション輸送と潜在的セキュリティの間の見返りとサービス(DoS)攻撃、周遊旅行遅れを排除するためにコネクション確立の間にデータを背負うメカニズム、または終点への方法の否定を含んでいます。
4.5.6
4.5.6
It was recommended to look at (TCP) transport improvements specific to the wireless and mobile environment. An example is to investigate reattachable transport endpoints. This could allow for graceful recovery of a transport connection after a roaming or mobility event results in changes to one or both endpoint identifiers. Another area for potential investigation is to develop targeted uses of D-SACK [25]. D-SACK provides additional robustness to reordered packets, which may prove beneficial in wireless environment where packets are occasionally corrupted. Higher performance may be attainable by eliminating requirements on link-level retransmission maintaining in-order delivery within a flow.
(TCP)輸送改良をワイヤレスの、そして、モバイルの環境に特定であるとして見るのはお勧めでした。 例は再付着可能輸送終点を調査することです。 ローミングか移動性イベントが1つへの変化か終点識別子の両方をもたらした後にこれは輸送接続の優雅な回復を考慮するかもしれません。 別の領域は、潜在的調査が展開することであるので、D-SACK[25]の用途を狙いました。 D-SACKは追加丈夫さを再命令されたパケットに提供します。(パケットはパケットが時折崩壊するところでワイヤレスの環境で有益であると判明するかもしれません)。 より高い性能は流れの中でオーダーにおける配送を維持するリンク・レベル「再-トランスミッション」に関する要件を排除することによって、達成できるかもしれません。
4.6 Recommendations on Routing
4.6 ルート設定の推薦
Unique routing requirements may be introduced in support of wireless systems, especially when viewing the mobile component as an autonomous system (AS).
特に自律システム(AS)であるとモバイルコンポーネントをみなすとき、ワイヤレスシステムを支持してユニークなルーティング要件を導入するかもしれません。
4.6.1
4.6.1
It was recommended that the IETF Routing Area commence investigation of extensions to the BGP protocol [54] to support additional policy features available within the ISO IDRP protocol [33]. The range of policy control desired includes adopting different identity or policies based on current point of attachment, and providing flexibility in path selection based on local policy and/or current
IETFルート設定AreaがISO IDRPプロトコル[33]の中で利用可能な追加方針機能をサポートするためにBGPプロトコル[54]に拡大の調査を始めるのは、お勧めでした。 コントロールが望んでいた方針の範囲は、現在の接着点に基づく異なったアイデンティティか方針を採って、ローカルの方針、そして/または、電流に基づく経路選択に柔軟性を提供するのを含んでいます。
Mitzel Informational [Page 31] RFC 3002 IAB Wireless Workshop December 2000
[31ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
peer policy. These features could be used for instance in support of requirements established in the Aeronautical Telecommunication Network (ATN).
同輩方針。 例えば、これらの特徴はAeronautical Telecommunication Network(ATN)に確立された要件を支持して使用されるかもしれません。
4.6.2
4.6.2
It was recommended that the IETF Routing Area commence investigation of extensions to the BGP protocol [54] to support additional QoS/TOS path selection features available within the ISO IDRP protocol [33]. The range of policies include differentiating service level or path selection based on traffic classes. An example, based on Aeronautical Telecommunication Network (ATN) requirements, might be differentiating path selection and service between airline control and passenger entertainment traffic.
IETFルート設定Areaが追加QoS/TOSがISO IDRPプロトコル[33]の中で利用可能な経路選択機能であるとサポートするためにBGPプロトコル[54]に拡大の調査を始めるのは、お勧めでした。 方針の範囲は、トラフィックのクラスに基づくサービスレベルか経路選択を差別化するのを含んでいます。 Aeronautical Telecommunication Network(ATN)要件に基づく例はエアラインコントロールと乗客エンターテインメントトラフィックの間の経路選択とサービスを差別化しているかもしれません。
4.7 Recommendations on Mobile Host QoS Support
モバイルにおける4.7の推薦がQoSサポートを主催します。
Wireless link bandwidth is often scarce (e.g., cellular) and/or shared (e.g., IEEE 802.11 WLAN). Meeting application QoS needs requires accommodating these link characteristic, in addition to the roaming nature of mobile host. Specialized support may be required from the network layer to meet both link and end-to-end performance constraints.
ワイヤレスのリンク帯域幅は、しばしば不十分(例えば、携帯電話)である、そして/または、共有されています(例えば、IEEE802.11WLAN)。 QoSが必要とするミーティングアプリケーションは、これらを収容するのをリンクモバイルホストのローミング自然に加えて独特の状態で必要とします。 専門化しているサポートが、リンクと終わりから終わりへの性能両方の規制を満たすのにネットワーク層から必要であるかもしれません。
4.7.1
4.7.1
It was recommended that the IETF Transport Area undertake investigation into providing QoS in the last leg of mobile systems. That is, between the mobile device and the network access point. This type of QoS support might be appropriate where the wireless link is the most constrained resource. A potential solution to investigate is to employ an explicit reservation mechanism between the mobile host and the access point (e.g., RSVP [13]), while relying on resource provisioning or more scalable DiffServ [9] technologies within the core.
IETF Transport Areaがモバイルシステムの最後の航程にQoSを提供するのに調査を引き受けるのは、お勧めでした。Thatはそうです、モバイル機器とネットワークアクセスポイントの間で。 このタイプのQoSサポートはワイヤレスのリンクが最も制約つきなリソースであるところで適切であるかもしれません。 調査する潜在的ソリューションはモバイルホストとアクセスポイントの間の明白な予約メカニズムを使うことです。(例えば、コアの中でリソースの食糧を供給しているか、よりスケーラブルなDiffServ[9]技術を当てにしている間のRSVP[13])。
4.7.2
4.7.2
It was recommended that the IETF Transport Area undertake investigation into end-to-end QoS when the path includes a mixture of wireless and wired technologies. This investigation could focus on mechanism to communicate QoS characteristics in cellular network to the core network to establish end-to-end QoS guarantees. An alternative investigation is to look into discovery problem of assessing current end-to-end performance characteristics, enabling for dynamic adaptation by mobile host.
経路がワイヤレスの、そして、ワイヤードな技術の混合物を含んでいるとIETF Transport Areaが終わりから終わりへのQoSに調査を引き受けるのは、お勧めでした。 この調査は、終わりから終わりへのQoS保証を証明するためにセルラー・ネットワークでQoSの特性をコアネットワークに伝えるためにメカニズムに焦点を合わせるかもしれません。 代替の調査は終わりから終わりへの性能現在の特性を評価するという発見問題、モバイルホストによるダイナミックな適合のために可能にすることを調べることです。
Mitzel Informational [Page 32] RFC 3002 IAB Wireless Workshop December 2000
[32ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.8 Recommendations on Application Mobility
4.8 アプリケーションの移動性における推薦
In a mobile environment with roaming, and mobile host disconnect and reconnect at different attachment point it may be desirable to recover an incomplete application session. It was recommended that the IRTF investigate application mobility at this level. The goal is to achieve a smooth recovery after a disconnect period; something more graceful than a "redial". Currently there does not appear to be sufficient information available within the network stack, this may require instantiation of some form of "session" layer.
モバイル環境で、不完全な出願セッションは、移動していて、モバイルのホストと共に切断して、回復するのが望ましいかもしれない異なった付着点で再接続されます。 IRTFがこのレベルでアプリケーションの移動性を調査するのは、お勧めでした。 目標は分離の期間の後に滑らかな回復を達成することです。 「リダイヤル」より何か優雅なもの。 現在、ネットワークスタックの中で利用可能な十分な情報はあるように見えないで、これは何らかの形式の「セッション」層の具体化を必要とするかもしれません。
4.9 Recommendations on TCP/IP Performance Characterization in WAP-like
Environment
4.9 WAPのような環境におけるTCP/IPパフォーマンス特殊化の推薦
WAPF has gone to considerable effort to develop unique transport protocol and optimizations due to perception that TCP/IP protocol stack is too expensive. Much of this was predicated on WAP requirements to support very low datarate bearer services. It was recommended that members of the IRTF evaluate TCP/IP stack performance in WAP-like environment to quantify its behavior and applicability. The focus should include investigation of code and memory space requirements, as well as link usage to complete a single transaction for current WAP protocols and for both IPv4 and IPv6. This work should result in better characterization of TCP/IP performance in highly constrained devices and network, recommendations to the IETF on protocol enhancements to optimize performance in this environment, and recommendations to WAPF on suitability of deploying native IP protocols.
WAPFは高価な状態で知覚によるまた、TCP/IPプロトコル・スタックがそうであるユニークなトランスポート・プロトコルと最適化を開発しにかなりの取り組みに行きました。 この多くが非常に低いdatarate運搬人サービスをサポートするというWAP要件で叙述されました。 IRTFのメンバーがその振舞いと適用性を定量化するWAPのような環境におけるTCP/IPスタック性能を評価するのは、お勧めでした。 焦点は、コードとメモリスペース要件の調査を含んで、現在のWAPプロトコルとIPv4とIPv6の両方のための単一取引を終了するために用法をリンクするべきです。 この仕事は固有のIPプロトコルを配布する適合でこの環境における性能、およびWAPFへの推薦を最適化するプロトコル増進でのIETFへの非常に強制的なデバイスとネットワーク、推薦におけるTCP/IP性能の、より良い特殊化をもたらすべきです。
4.10 Recommendations on Protocol Encoding
4.10 プロトコルコード化の推薦
IETF protocol developments have traditionally taken the approach of preferring simple encode/decode and word alignment at the cost of some extra bit transmissions. This overhead may prove too burdensome in some bandwidth constrained environments, such as cellular wireless and WAP. Work within the IETF Robust Header Compression (rohc) working group may go a long way to reducing some of these detriments to Internet protocols deployment. However, there may be potential for additional savings from investigation of alternative encoding of common Internet protocols. It was recommended that members of the IRTF evaluate general techniques that can be used to reduce protocol "verbiage". Examples might include payload compression techniques or tokenized protocol encoding.
開発が簡単な状態で好みながらアプローチを伝統的に取ったIETFプロトコルは、いくつかの付加的なビット伝送の費用で整列をコード化するか、解読して、または言い表します。 このオーバーヘッドはセルワイヤレスやWAPなどのいくつかの帯域幅強制的な環境で重荷になり過ぎると判明するかもしれません。 IETF Robust Header Compression(rohc)ワーキンググループの中の仕事はこれらの損傷のいくつかをインターネットプロトコル展開に下げるのにはるばる行くかもしれません。 しかしながら、一般的なインターネットプロトコルの代替のコード化の調査からの追加貯蓄の可能性があるかもしれません。 IRTFのメンバーがプロトコル「多言」を減少させるのに使用できる一般的なテクニックを評価するのは、お勧めでした。 例はペイロード圧縮のテクニックかtokenizedプロトコルコード化を含むかもしれません。
Mitzel Informational [Page 33] RFC 3002 IAB Wireless Workshop December 2000
[33ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.11 Recommendations on Inter-Domain AAA Services
4.11 相互ドメインAAAサービスの推薦
Commercial roaming and mobility services are likely to require exchange of authentication, authorization, and billing services spanning multiple domains (service providers). This introduces requirements related to establishing a web or hierarchy of trust across multiple autonomous domains. Standard protocols to specify and exchange usage policies and billing information must also be established. Some work is progressing on scoping out the issues and a framework [7,64]. However, there are significant issues to be solved to enable a scalable, Internet-wide solution. Due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of scalable inter- domain AAA as high priority within the IETF.
商業..ローミング..移動性..サービス..ありそう..必要..交換..認証..承認..支払い..サービス..かかる..複数..ドメイン..サービスプロバイダー これは複数の自治のドメインの向こう側に信頼のウェブか階層構造を確立すると関連する要件を導入します。 また、指定する標準プロトコル、交換用法方針、および支払い情報を確立しなければなりません。 問題とフレームワーク[7、64]を見るとき、いくらかの仕事が進歩をします。 しかしながら、スケーラブルで、インターネット全体のソリューションを可能にするために解決されるために、重要な問題があります。 商業サービスを配布する能力に関するこれらのプロトコルの極めて重要な役割のために、高い優先度としてIETFの中でスケーラブルな相互ドメインAAAの決定をするのはお勧めでした。
4.12 Recommendations on Bluetooth
4.12 ブルートゥースにおける推薦
Bluetooth protocols and devices were originally optimized for a narrow application space. However, there is interest in exploring the breadth to which protocol and device access can be extended. One particular area of interest is exploring integration into, or gatewaying access to, the Internet. It was recommended that the IETF pursue formation of a joint BOF to assemble experts from the IETF and Bluetooth communities to begin exploration of this problem. This is in direct support of the recommendations in section 4.1 to foster communication and mutual education.
ブルートゥースプロトコルとデバイスは元々、狭いアプリケーションスペースに最適化されました。 しかしながら、どのプロトコルに幅について調査するかへの関心があります、そして、デバイスアクセスは広げることができます。 1つの特定の関心領域が、インターネットに統合について調査するか、またはアクセスをgatewayingしています。 IETFがこの問題の探検を始めるためにIETFとブルートゥース共同体から専門家を集まらせるように関節形成BOFを追求するのは、お勧めでした。 これはコミュニケーションと互いの教育を伸ばすというセクション4.1の推薦のダイレクトサポート中です。
4.13 Recommendations on Proxy Architecture
4.13 プロキシアーキテクチャにおける推薦
Proxy agents are often deployed to intercept and evaluate protocol requests (e.g., web cache, HTTP redirector, filtering firewall) or to gateway access between communication domains (e.g., traversing bastion host between private network and Internet or gatewaying between a cellular service and the Internet). There are a number of potential architectures when contemplating development and deployment of one of these proxy agent. It was recommended that members of the IRTF investigate taxonomy of proxy architectures and evaluate their characteristics and applicability. Each type of proxy should be characterized, for example, by its effect on Internet end-to-end model, and security, scaling, and performance implications. The results of this study can help educate developers and network operators on the range of proxy available and recommend solutions that are least disruptive to Internet protocols.
プロキシエージェントは、プロトコル要求(例えば、ウェブキャッシュ、ファイアウォールをフィルターにかけるHTTPリダイレクタ)を妨害して、評価するためにしばしば配布されるか、またはコミュニケーションドメイン(例えば、私設のネットワークとインターネットの間で要塞ホストを横断するか、またはセルサービスとインターネットの間でgatewayingする)の間のゲートウェイアクセスにそうします。 これらのプロキシエージェントのひとりの開発と展開を熟考するとき、多くの潜在的アーキテクチャがあります。 IRTFのメンバーがプロキシアーキテクチャの分類学を調査して、彼らの特性と適用性を評価するのは、お勧めでした。 例えば、それぞれのタイプのプロキシはインターネット終わりから終わりへのモデルへの効果、セキュリティ、スケーリング、および性能含意によって描写されるべきです。 この研究の結果は、プロキシの利用可能な範囲で開発者とネットワーク・オペレータを教育して、インターネットプロトコルに最も破壊的でないソリューションを推薦するのを助けることができます。
Mitzel Informational [Page 34] RFC 3002 IAB Wireless Workshop December 2000
[34ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
4.14 Recommendations on Justifying IPv6-based Solutions for Mobile /
Wireless Internet
4.14 モバイルの、または、ワイヤレスのインターネットにIPv6ベースのソリューションを正当化するときの推薦
IPv6 was strongly recommended to address scaling (see section 4.3) and mobility (see section 4.4) issues in the future Internet dominated by large numbers of wireless and mobile devices. It was recommended that the IAB draft a formalized justification for these recommendations for adoption of IPv6-based solution. It was believed that the "The Case for IPv6" [40] document should form an excellent basis for this justification. In addition, documents highlighting architectural and operational pitfalls of continued reliance on IPv4 and NAT also provide excellent justification [29,31,59]. It was deemed urgent to submit these informational documents as inputs to other standards bodies (MWIF, 3GPP, 3G.IP), as many decisions are being made on Internet protocol adoption and this data could be highly influential.
IPv6が多くのワイヤレスの、そして、モバイルのデバイスによって支配された将来のインターネットでスケーリング(セクション4.3を見る)と移動性(セクション4.4を見る)問題を扱うことが強く勧められました。 IABがIPv6ベースのソリューションの採用のためのこれらの推薦のための正式にされた正当化を作成するのは、お勧めでした。 それが信じられていた、それ、「IPv6"[40]ドキュメントのためのこの件はこの正当化の素晴らしい基礎を形成するべきです」。 また、さらに、IPv4とNATへの継続的な信用の建築していて操作上の落とし穴を強調するドキュメントが素晴らしい正当化[29、31、59]を提供します。 それは入力として他の標準化団体(MWIF、3GPP、3G.IP)にこれらの情報のドキュメントを提出するために緊急であると考えられました、インターネットプロトコル採用のときに多くの決定をして、このデータが非常に有力であるかもしれないように。
5 Security Considerations
5 セキュリティ問題
This workshop did not focus on security. However, mobility and wireless environment introduces additional complexities for security and potential attacks to user authentication and privacy. The presentations by Asokan and by Calhoun referenced in section 2 focused on security mechanisms in currently deployed cellular networks and evolution toward 3G cellular and IP networks. Discussion on the "walled garden" service model (see section 3.1) briefly mentions effects on simplifying security requirements. Section 3.3 raises a number of security issues related to wireless devices and mobility. These include alternatives for establishing user identity and capabilities, securing network infrastructure from attacks, and security associations required for mobile IP and AAA operation. Section 3.7 mentions interoperation issues between compression and encryption or tunneling, and finally section 3.9 highlight potential for proxy agent to be used to offload expensive crypto operations.
このワークショップはセキュリティに焦点を合わせませんでした。 しかしながら、移動性とワイヤレスの環境はセキュリティと起こり得るかもしれない攻撃のためにユーザー認証とプライバシーに追加複雑さを取り入れます。 Asokanとカルフーンによるプレゼンテーションはセルラー・ネットワークと3Gに向かってセルの発展であると配布された現在のセキュリティー対策に集中しているセクション2とIPでネットワークに参照をつけました。 「塀で囲まれた庭」サービスモデル(セクション3.1を見る)についての議論は簡潔にセキュリティ要件を簡素化することへの効果について言及します。 セクション3.3はワイヤレス機器と移動性に関連する多くの安全保障問題を提起します。 これらはユーザのアイデンティティと能力を確立するための代替手段を含んでいます、協会がモバイルIPとAAA操作のために必要とした攻撃、およびセキュリティからネットワークインフラを保証して。 セクション3.7は圧縮と暗号化かトンネリングの間のinteroperation問題を参照します、そして、最終的にセクション3.9はプロキシエージェントが高価な暗号操作を積み下ろすのに使用される可能性を目立たせます。
6 Acknowledgments
6つの承認
The author would like to thank all of the workshop participants for their feedback, encouragement, and patience during the writeup of this document. I would especially like to thank Brian Carpenter for prompt responses to questions on the document organization and content. Similarly, Charlie Perkins provided extensive feedback that dramatically improved and corrected statements throughout the report. Finally, Mikael Degermark, Sally Floyd, Heikki Hammainen, Geoff Huston, and Gabriel Montenegro contributed comments and responses to questions.
作者はこのドキュメントに関する記事の間、彼らのフィードバック、奨励、および忍耐について講習会参加者のすべてに感謝したがっています。 ドキュメント組織と内容の質問への迅速な応答についてブライアンCarpenterに特に感謝申し上げます。 同様に、チャーリー・パーキンスは、劇的に向上した大規模なフィードバックを提供して、レポート中で声明を修正しました。 最終的に、マイケル・デーゲルマルク、サリー・フロイド、Heikki Hammainen、ジェフ・ヒューストン、およびガブリエル・モンテネグロは質問に見解書を寄付しました。
Mitzel Informational [Page 35] RFC 3002 IAB Wireless Workshop December 2000
[35ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
7 Bibliography
7 図書目録
[1] ACIRI. TCP-Friendly Rate Control. http://www.aciri.org/tfrc.
[1] ACIRI。 TCPに優しい速度制御 http://www.aciri.org/tfrc 。
[2] A. Aggarwal, S. Savage, and T. Anderson. Understanding the
Performance of TCP Pacing. Proceedings of IEEE Infocom 2000,
March 2000.
[2] A.Aggarwal、S.サヴェージ、およびT.アンダーソン。 TCPペースのパフォーマンスを理解しています。 2000年3月のIEEE Infocom2000の議事。
[3] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's
Initial Window", RFC 2414, September 1998.
[3] オールマンとM.とフロイドとS.とC.ヤマウズラ、「増加するTCPの初期の窓」、RFC2414、1998年9月。
[4] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over
Satellite Channels using Standard Mechanisms", RFC 2488,
January 1999.
[4] オールマンとM.と手袋製造業者とD.とL.サンチェス、「衛星チャンネルの上に標準のメカニズムを使用することでTCPを高めます」、RFC2488、1999年1月。
[5] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control",
RFC 2581, April 1999.
[5] オールマンとM.とパクソンとV.とW.スティーブンス、「TCP輻輳制御」、RFC2581、1999年4月。
[6] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann,
S., Scott, K. and J. Semke, "Ongoing TCP Research Related to
Satellites", RFC 2760, February 2000.
[6]オールマン、M.、ダウキンズ、S.、手袋製造業者、D.、Griner、J.、チャン、D.、ヘンダーソン、T.、Heidemann、J.、接触、J.、クルーゼ、H.、オステルマン、S.、スコット、K.、およびJ.Semke、「進行中のTCP研究は衛星に関連しました」、RFC2760、2000年2月。
[7] Arkko, J., "Requirements for Internet-Scale Accounting
Management", Work in Progress.
[7] J.、「インターネットスケール会計管理のための要件」というArkkoは進行中で働いています。
[8] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 2283, February 1998.
[8] ベイツとT.とチャンドラとR.とキャッツとD.とY.Rekhter、「BGP-4インチのためのMultiprotocol拡張子、RFC2283、1998年2月。」
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services" RFC 2475,
December 1998.
[9] ブレーク、S.は黒くされます、D.、カールソン、M.、デイヴィース、E.、Z.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」RFC2475、ワング、1998年12月。
[10] Borella, M., et al., "Realm Specific IP: Framework", Work in
Progress.
[10]Borella、M.、他、「分野の特定のIP:」 「フレームワーク」、処理中の作業。
[11] Borella, M., et al., "Realm Specific IP: Protocol
Specification", Work in Progress.
[11]Borella、M.、他、「分野の特定のIP:」 「プロトコル仕様」、処理中の作業。
[12] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional
Specification", RFC 1644, July 1994.
[12] ブレーデン、R.、「T/TCP--、トランザクションに、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
[13] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[13] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[14] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior
Identification Codes", RFC 2836, May 2000.
「ホップ振舞い識別コード」あたりの[14]縁、S.、大工、B.、およびF.Le Faucheur(RFC2836)は2000がそうするかもしれません。
Mitzel Informational [Page 36] RFC 3002 IAB Wireless Workshop December 2000
[36ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
[15] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
Behaviour Today", RFC 2101, February 1997.
[15]大工、B.、クロウクロフト、J.、およびY.Rekhter、「IPv4は今日ふるまいを扱う」RFC2101、1997年2月。
[16] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[16] 大工、B.、「インターネット透明」、RFC2775、2000年2月。
[17] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August
2000.
[17] クロフォード、M.、「IPv6"、RFC2894、2000年8月のためのルータの番号を付け替えること」。
[18] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
September 1985.
[18] 耕地とB.とJ.ギルモア、「プロトコル(BOOTP)を独力で進んでください」、RFC951、1985年9月。
[19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[19] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[20] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[20] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[21] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[21]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[22] Everhart, C., Mamakos, L., Ullman, R. and P. Mockapetris, "New
DNS RR Definitions", RFC 1183, October 1990.
[22] エバーハートとC.とMamakosとL.とウルマンとR.とP.Mockapetris、「新しいDNS RR定義」、RFC1183、1990年10月。
[23] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[23] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月」。
[24] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's
Fast Recovery Algorithm", RFC 2582, April 1999.
[24] フロイドとS.とT.ヘンダーソン、「TCPの速い回復アルゴリズムへのNewReno変更」、RFC2582、1999年4月。
[25] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An
Extension to the Selective Acknowledgment (SACK) Option for
TCP", RFC 2883, July 2000.
[25] フロイドとS.とMahdaviとJ.とマシスとM.とM.ポドルスキー、「TCPのための選択している承認(袋)オプションへの拡大」、RFC2883、2000年7月。
[26] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP
Authentication, Authorization, and Accounting Requirements", RFC
2977, October 2000.
[26] S.、ヒラー、T.、ジェイコブズ、S.、C.パーキンス、および「モバイルIP認証、承認、および会計要件」とガラスで覆ってください、RFC2977、2000年10月。
[27] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[27]GulbrandsenとA.とP.Vixie、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2052、1996年10月。
[28] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2", RFC 2608, June 1999.
[28] Guttman(E.、パーキンス、C.、Veizades、J.、およびM.日)は「1999年6月にRFC2608を位置のプロトコル、バージョン2インチ調整します」。
[29] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[29] ハイン、T.、「NATの建築含意」、RFC2993、2000年11月。
Mitzel Informational [Page 37] RFC 3002 IAB Wireless Workshop December 2000
[37ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
[30] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[30] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[31] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator (NAT)", Work in Progress.
[31] 「IPネットワークアドレス変換機構(NAT)とのプロトコル複雑さ」というHoldrege、M.、およびP.Srisureshは進行中で働いています。
[32] International Telecommunication Union. Visual Telephone Systems
and Equipment for Local Area Networks which provide a Non-
guaranteed Quality of Service. Recommendation H.323, May 1996.
[32] 国際電気通信連合。 Nonを提供するローカル・エリア・ネットワークのための視覚Telephone SystemsとEquipmentはServiceのQualityを保証しました。 1996年5月の推薦H.323。
[33] ISO/IEC. Protocol for Exchange of Inter-Domain Routeing
Information among Intermediate Systems to support Forwarding of
ISO 8473 PDUs. ISO/IEC IS10747, 1993.
[33] ISO/IEC。 議定書を作って、Intermediate Systemsの中のInter-ドメインRouteing情報のExchangeはISO8473PDUsのForwardingをサポートしてください。 ISO/IEC IS10747、1993。
[34] V. Jacobson. Congestion Avoidance and Control. Computer
Communication Review, vol. 18, no. 4 August 1988.
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
[34] V.ジェーコブソン。 輻輳回避とコントロール。 1988年8月4日コンピュータCommunication Review、vol.18、No. ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z 。
[35] V. Jacobson. Modified TCP Congestion Avoidance Algorithm.
end2end-interest mailing list, April 30, 1990.
ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail.
[35] V.ジェーコブソン。 変更されたTCP Congestion Avoidance Algorithm. end2end-関心メーリングリスト、1990年4月30日 ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail 。
[36] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High
Performance", RFC 1323, May 1992.
[36] ジェーコブソン(V.、ブレーデン、R. and D.ボーマン、「高性能のためのTCP拡張子」、RFC1323)は1992がそうするかもしれません。
[37] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in
Progress.
[37] ジョンソンとD.とC.パーキンス、「IPv6"での移動性サポート、進行中の仕事。」
[38] Jonsson, L., et al., "RObust Checksum-based header COmpression
(ROCCO)", Work in Progress.
[38] イェンソン、L.、他、「RObust ChecksumベースのヘッダーCOmpression(ロッコ)」、ProgressのWork。
[39] Karn, P., et al., "Advice for Internet Subnetwork Designers",
Work in Progress.
[39]Karn、P.、他、「インターネットサブネットワークデザイナーのためのアドバイス」、ProgressのWork。
[40] King, S., et al., "The Case for IPv6", Work in Progress.
[40] キング、S.、他、「IPv6"のためのケース、処理中の作業。」
[41] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP
for High Delay-Bandwidth Networks. Proceedings of IEEE Globecom
'99, December 1999.
[41] J.クリク、R.コールター、D.ロックウェル、およびC.ヤマウズラ。 高い遅れ帯域幅ネットワークのためにTCPに歩調を合わせました。 IEEE Globecom'99、1999'年12月の議事。
[42] Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time
Multimedia", Work in Progress.
[42]Le、K.、他、「リアルタイムのマルチメディアのための適応型のヘッダー圧縮(ACE)」、ProgressのWork。
[43] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996.
[43] マシスとM.とMahdaviとJ.とフロイドとS.とA.Romanow、「TCPの選択している承認オプション」、RFC2018、1996年10月。
Mitzel Informational [Page 38] RFC 3002 IAB Wireless Workshop December 2000
[38ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
[44] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
13, RFC 1034, November 1987.
[44]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[45] Mockapetris, P., "Domain Names -- Implementation and
Specification", STD 13, RFC 1035, November 1987.
[45]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[46] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[46] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの差別化されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[47] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[47] ヤマウズラとC.とメンデスとT.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[48] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[48] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[49] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile
IP", Work in Progress.
[49] 「モバイルIPのためのAAA登録キー」というパーキンス、C.、およびP.カルフーンは進行中で働いています。
[50] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP",
Work in Progress.
[50] 「モバイルIPにおける経路最適化」というパーキンス、C.、およびD.ジョンソンは進行中で働いています。
[51] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[51] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[52] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[52] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[53] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[53]Ramakrishnan、K.とS.フロイド、「Explicit Congestion Notification(電子証券取引ネットワーク)をIPに追加するProposal」RFC2481、1999年1月。
[54] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
RFC 1771, March 1995.
[54]RekhterとY.と1995年のT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1771行進。
[55] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E.
Lear, "Address Allocation for Private Internets", BCP 5, RFC
1918, February 1996.
[55] Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[56] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[56]RigneyとC.とルーベンとA.とシンプソン、W.とS.ウィレンス、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2138(1997年4月)。
[57] Schulzrinne, H., Casner, S., Fredrick, R. and V. Jacobson, "RTP:
A Transport Protocol for Real-Time Applications", RFC 1889,
January 1996.
[57]Schulzrinne、H.、Casner、S.、フレドリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[58] J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer
Tuning. Proceedings of ACM SIGCOMM '98, September 1998.
[58] J.Semke、J.Mahdavi、およびM.マシス。 自動TCPはチューニングをバッファリングします。 ACM SIGCOMM98年、1998年9月の議事。
Mitzel Informational [Page 39] RFC 3002 IAB Wireless Workshop December 2000
[39ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
[59] Srisuresh, P. and M. Holdrege, "IP Network Address Translator
(NAT) Terminology and Considerations", RFC 2663, August 1999.
[59]SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[60] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", Work in Progress.
[60] 「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」というSrisuresh、P.、およびK.Egevangは進行中で働いています。
[61] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[61] スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[62] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[62] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[63] Touch, J., "TCP Control Block Interdependence", RFC 2140, April
1997.
[63] 接触、J.、「TCP制御ブロック相互依存」、RFC2140、1997年4月。
[64] Vollbrecht, J., et al., "AAA Authorization Framework", Work in
Progress.
[64]Vollbrecht、J.、他、「AAA承認フレームワーク」、ProgressのWork。
Mitzel Informational [Page 40] RFC 3002 IAB Wireless Workshop December 2000
[40ページ]RFC3002IABワイヤレスワークショップ2000年12月の情報のMitzel
A Participants
関係者
Juha Ala-Laurila JUHA.ALA-LAURILA@nokia.com
Mark Allman mallman@grc.nasa.gov
Alastair Angwin angwin@uk.ibm.com
N. Asokan n.asokan@nokia.com
Victor Bahl bahl@microsoft.com
Fred Baker fred@cisco.com
Pravin Bhagwat pravinb@us.ibm.com
Scott Bradner sob@harvard.edu
Randy Bush randy@psg.com
Pat Calhoun Pcalhoun@eng.sun.com
Brian Carpenter brian@icair.org
Mikael Degermark micke@cs.arizona.edu
Sally Floyd floyd@aciri.org
Heikki Hammainen HEIKKI.HAMMAINEN@NOKIA.COM
Mark Handley mjh@aciri.org
Bob Hinden hinden@iprg.nokia.com
Christian Huitema huitema@microsoft.com
Chih-Lin I ci@att.com
Van Jacobson van@packetdesign.com
Phil Karn Karn@qualcomm.com
John Klensin Klensin@JCK.com
Jerry Lahti jerry.lahti@nokia.com
Allison Mankin mankin@isi.edu
Danny J. Mitzel mitzel@iprg.nokia.com
Gabriel Montenegro gab@sun.com
Keith Moore moore@cs.utk.edu
Eric Nordmark nordmark@sun.com
Charles E. Perkins charliep@iprg.nokia.com
Jonne Soininen jonna.Soininen@nokia.com
Chris A. Wargo cwargo@cnsw.com
Lars Westberg Lars.Westberg@era.ericsson.se
Lixia Zhang lixia@cs.ucla.edu
ユハアラー-Laurila JUHA.ALA-LAURILA@nokia.com マークオールマンmallman@grc.nasa.govアラステアAngwin angwin@uk.ibm.com N.Asokan n.asokan@nokia.com ビクタBahl bahl@microsoft.com フレッドベイカー fred@cisco.com Pravin Bhagwat pravinb@us.ibm.com スコットブラドナー sob@harvard.edu ランディブッシュ randy@psg.com パットカルフーン Pcalhoun@eng.sun.com ブライアンCarpenter brian@icair.org マイケルデーゲルマルク micke@cs.arizona.edu サリーフロイド floyd@aciri.org Heikki Hammainen HEIKKI.HAMMAINEN@NOKIA.COM マークハンドレーmjh@aciri.orgボブHinden hinden@iprg クリスチャンのnokia.comのA.Wargo cwargo@cnsw.com ラースウェストバーグHuitema huitema@microsoft.com Chih-リンI ci@att.com ヴァンジェーコブソン van@packetdesign.com フィルKarn Karn@qualcomm.com ジョンKlensin Klensin@JCK.com ジェリーラーティ jerry.lahti@nokia.com アリソンマンキン mankin@isi.edu ダニーJ.Mitzel mitzel@iprg.nokia.com ガブリエルモンテネグロ gab@sun.com キースムーア moore@cs.utk.edu エリックNordmark nordmark@sun.com チャールズE.パーキンス charliep@iprg.nokia.com Jonne Soininen jonna.Soininen@nokia.com クリス Lars.Westberg@era.eric sson.se Lixiaチャン lixia@cs.ucla.edu
B Author's Address
B作者のアドレス
Danny J. Mitzel Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ダニーJ.Mitzelノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625 2037 EMail: mitzel@iprg.nokia.com
以下に電話をしてください。 +1 2037年の650 625メール: mitzel@iprg.nokia.com
Mitzel Informational [Page 41] RFC 3002 IAB Wireless Workshop December 2000
[41ページ]RFC3002IAB無線電信ワークショップ2000年12月の情報のMitzel
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mitzel Informational [Page 42]
Mitzel情報です。[42ページ]
一覧
スポンサーリンク
