Network Working Group D. Mitzel
Request for Comments: 3002 Nokia
Category: Informational December 2000
Overview of 2000 IAB Wireless Internetworking Workshop
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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）で開催されたワークショップの概要を説明します。ワークショップは、ワークショップの目的は、研究と標準化の作業上の勧告ができるようにするため、無線環境でのインターネット技術の現在と将来の使用を評価することであった3月2日、2000年を通して2月29日にカリフォルニア州マウンテンビューにあるノキア、米国が主催しました。インターネット網と無線環境におけるトランスポートプロトコルの受け入れを改善し、インターネットワーキンググループの標準とテレフォニー、ワイヤレス部門のそれら間のコミュニケーションとコラボレーションを改善するための方法を評価します。このレポートは、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
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
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、など）、および移動操作を含む無線技術が、ますます重要になってきています。いくつかの市場予測はと並行または有線インターネットを増強におけるモバイルインターネットは、早ければ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.
インターネットアーキテクチャ委員会（IAB）は、2000年3月2日スルー2月29日に、無線インターネットワーキングに招待ワークショップを開催しました。ワークショップの目的は、無線環境でのインターネット技術の現在と将来の使用を評価するために、ワイヤレス環境でのインターネット網の受け入れや輸送プロトコルを改善するための研究と標準化作業に勧告を行うために、との間のコミュニケーションとコラボレーションを改善するための方法を評価することでしたインターネット標準ワーキンググループやテレフォニー、ワイヤレス分野のものを。
The following topics were defined for discussion:
次のトピックでは、議論のために定義されました：
+ Local area wireless technologies
+ローカルエリア無線技術
+ Cellular wireless technologies
+セルラー無線技術
+ Wireless Application Protocol (WAP)
+ワイヤレスアプリケーションプロトコル（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プロトコルの使用
+ 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
プレゼンター：ヘイッキHämmäinen
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?
タイトル：IEEE 802.11無線LANのIEEE 802.11＆上でIPを実行している問題の概要？
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-shop/talks/IEEE80211_IP.ppt
Overview:
概要：
Title: Overview of Bluetooth Wireless & Issues Running IP over Bluetooth?
タイトル：Bluetoothワイヤレス＆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中心のセルラーデータシステムへのアプローチの概要
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/ Cellular_JSo.PDF、http://www.iab.org/IAB-wireless-workshop/talks/ Cellular_JSo.ppt
Overview:
概要：
Title: IP Packet Data Service over IS-95 CDMA
タイトル：IS-95 CDMAオーバーIPパケットデータサービス
Presenter: Phil Karn
Presentr：フィル理由
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
プレゼンター：志林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
プレゼンター：チャーリー・パーキンス
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
プレゼンター：アラステア・アングウィン
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
プレゼンター：アラステア・アングウィン
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:
概要：
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
プレゼンター：クリスチャン・ハイテマ
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
プレゼンター：パットカルフーン
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
プレゼンター：マーク・ハンドリー
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?
タイトル：無線上で現在のインターネットトランスポートの仕事をしていますか？
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?)
タイトル：WirelessのQOS（他のDiffServ、IntServの、？）
Presenter: Lixia Zhang
プレゼンター：L I張
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プロトコルの仕事をしますか？
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
タイトル：Wirelessの圧縮＆ビット・エラーの要件
Presenter: Mikael Degermark
ギフト：マイケルDegermark
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は、これらの議論との観測をまとめます。むしろ提示によって直線的に資料を整理するよりも、それは一般的な「テーマ」や課題に応じてグループ化されます。
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環境に関わるメンバーからのプレゼンテーションがすぐに一般的にインターネットコミュニティが想定していることから、プロトコル仕様とサービスモデルで有意差を示します。これらのコミュニティは、明確に定義されたユーザサービスを提供するために組み合わせるプロファイル（プロトコルおよび動作パラメータのセット）を定義することに焦点を当てます。加えて、キャリアは、典型的には、ユーザアクセス装置、伝送設備、サービスの「コンテンツ」を含むサービス全体を完全に（または可能な限り）制御を有することを好みます。サービスモデルのこのスタイルは、古典的なテレフォニープロバイダモデルから継承されているように見えます。用語「壁に囲まれた庭には、」結果のキャプティブ顧客の経済やサービスモデルを記述するために鋳造されました。すなわち、ユーザは、プロバイダ外機能やアクセスサービスを拡張する限られた能力を有するキャリアが提供するサービスの限界内に拘束されています。 「壁に囲まれた庭」サービスモデルは、インターネットで想定している「オープン」サービスとは全く対照的です。アプリケーション、アクセスデバイス、及びサービスのコンテンツは、それぞれ異なるエンティティによって制御することができる、サービスプロバイダは、典型的には、「ビットパイプ」より少しとして見られます。
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.
また、仕様は、典型的には、スタンドアロンプロトコルまたはアプリケーションではなく、特徴および商用サービスを展開するために必要な他の成分との相互運用のセットを定義します。
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.
いくつかの議論は、携帯キャリアがインターネット「オープン」サービスモデルへの移行するように説得することができるかどうかに焦点を当てました。応答は、キャリアが常に彼らは付加価値サービスずに十分な収入を維持することはできません恐れて、「ビットパイプ」に縮小されて戦うことになるとして、これの少しの希望があったことが示されました。上げ、追加点は、「壁に囲まれた庭」のクローズドモデルは、ネットワーク全体をセキュリティで保護されたとみなされ、単回投与の下で制御され、セキュリティ、認証、および請求などの問題の数を簡素化するということでした。これらの簡素化は、スケーラブル、ドメイン間のソリューションが利用可能になる前にサービス展開に障害物を排除することができます。
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.
離れて短期的には「壁に囲まれた庭」サービスからキャリアを進化の少し希望が見えても、その存在を認識することに大きな価値がありました。これは、「壁に囲まれた庭」のインターネットベースのサービスは、現在のイントラネットサービスのように、やや動作することを観測につながりました。また、メカニズムは相互運用やインターネットへのアクセス制御を簡素化するために調査する必要があります。最後に、サービスプロファイルに対比インターネットプロトコル仕様の違いは、インターネット機能を組み込むしようとすると、テレフォニー環境のものが発生した混乱のいくつかを強調しています。
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").
携帯のお客様にインターネットベースのサービスを拡張する際に、現在の仕事の多くは、このような電子メールやWebアクセスなどのデータサービスに焦点を当てています。サービスの上に任意のコントロールを解放するために、キャリアの抵抗の一つの観測は、これがインターネットベースの音声サービスの採用の障害であってもよいことでした。現在のボイスオーバーIP（VoIP）の作業と（SIP [30]）コールシグナリングがこれらのサービスに対する制御を緩め、機能の多くは、キャリアは、アクセス・プロバイダ（すなわち、「ビットパイプ」に還元された状態でSIPエージェントに移動します）。
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ベースのソリューションを使用して、かなりの関心や採用のプロトコルに関する議論もありました。最後に、モビリティでは有効になって新しいサービスを模索に関心がありました。
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.
議論は、使用の現在のモードが現在のプロトコルによって導入される知覚される制限であるかどうかを識別することを試みました。明確なコンセンサスを達成することができませんでした。この「マクロモビリティ」ローミングの導入は価値が最初のステップである合意がありました。しかし、それはすぐにそれが十分で最初のステップであり、このレベルで停止しないように警告するかどうかについての質問が続きました。ローミング中にデバイスの継続的な使用を可能に関連する継続的な調査（「マイクロモビリティ」）とローミングイベントの後、以前の接続を取得する機能のための重要な問題があるようです。
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プロトコル間の選択は重要な議論のために別の話題を提供しました。携帯電話事業者は、すでにローミングのための重要なサポートを提供するプロトコルを展開しています。これは、アーキテクチャに向かって、すべてのモビリティサポートのための電話システムに依存するIP層からのローミングを隠し、そのよう3GPPや3G.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モバイルIPワーキンググループは、[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の境界があります表示されます。
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.
位置情報サービスを開発するのを助けることができるようにエニーキャストサービス[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.
この交換は、解釈のインターネット標準および電話サービスプロファイル間の切断を示します。まず、インターネットで多くのプロトコルが定義されているが、多くはオプションです。プロトコルのサポートは、典型的には、「鶏と卵」の問題につながることができ、市場の需要によって駆動されます。第二に、個々のプロトコルおよびアプリケーションは、商用サービスを構成するためにではなく、完全なプロファイルよりも開発されています。このサービスでは、サービス発見プロトコルの使用とスケーラビリティを評価することは、さらなる調査のためのオープンエリアであるように思われます。
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セキュリティ上の他の非専門家に頼る閉じフォーラムでのプロトコルを定義し、別の言い方をすれば、セキュリティ・エクスポージャーを作成する可能性が非常に高いです。
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カードに接続する必要があるかどうかに焦点を当てました。しかし、それは非常に難しいユーザのIDに取ってパブリックデバイスを展開することができ、製造を簡素化し、一部の耐タンパ性を提供することができるデバイスと識別を固定します。これらの代替は、デバイスの交換やアップグレードのアイデンティティと設定状態の転送に影響を与えます。
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.
関連のトピックは、単一のデバイスを使用することなく、手（例えば、企業のアクセス、ホームアクセス、またはインターネットへのアクセスを得るために）で、使用状況に基づいて異なるIDと特権を取るために、ユーザーの欲求を中心に展開します。上述したように、これらの複数のアイデンティティを想定する能力と容易さは、ID統合のモデルに大きく依存してもよいです。ディスカッションには、デバイスとユーザアイデンティティの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.
ユーザのアイデンティティの確立に関する議論の最終的なトピックは、デバイスの所有が十分であるかどうか、またはユーザがデバイスに認証するために要求される必要があるかどうかでした。第二は、ユーザはまた、PINコードを提供しなければならないATMカードに、より類似していながら、現実の世界では最初の選択肢は、クレジットカードのモデルが挙げられます。両モデルは、現実の世界で有用ようで、それは両方がワイヤレスネットワークでの用途を持つことになりそうです。
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プロキシを、展開する必要があります。同様の問題は、インターネットへのゲートウエイに内在しています。
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カードに埋め込まれた）長期共有秘密を使用し、プライバシーにのみアクセスリンク上で提供します。これは、「囲い込み」サービスモデルは利点が例です。サービス・アクセス・デバイスとネットワークを完全に制御を大幅にセキュリティ上の問題や潜在的な攻撃の範囲を減らします。
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.
無線デバイスへ出IPのすべての方法をプッシュする、将来の3GPPおよび3GPP2計画。観察は、この攻撃に対してシグナリングの露光および制御プレーンのためのより多くの可能性をもたらすことです。欲望は、相互認証とネットワークの確保を実行することです。これは、追加の問題を解決するために残って難しい問題です。しかし声明は、IPおよびオープンな標準に頼ることはかつてのSS7プロトコルへの依存とあいまいよりも証明可能安全なネットワークを生成する可能性が高いと判断されました。
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は、認証、許可、および課金のために必要です。 PKIを使用したクロスドメインAAA、認証周りの問題の中心部に残り、そしてによる認知オーバーヘッドと遅延にIPsecとIKEプロトコルの使用にかなりの嫌悪感がありました。モバイルIPの問題は、モバイルノードとホームエージェント、モバイルノードと外国人のエージェント、およびホームと外国人のエージェントとの間に必要なセキュリティアソシエーションを削減するためのソリューションを中心に展開します。調査されて暫定的な解決策は、RADIUSサーバ[56]の使用を含みます。しかし、各ハンドオフまたはモバイルIPプロトコル[48]における仮定に違反する可能性がハンドオフのいくつかの詳細を隠蔽で繰り返さダイナミックキー生成との懸念があります。要件を評価し、これらの未解決の問題のすべてに対処することは、オープン標準化と見直しに関する相互協力のための絶好の機会であるように思われます。
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.
トランスポートプロトコルに関する議論は、幅広い問題に触れました。懸念は、このようなWAPワイヤレストランザクションプロトコル（WTP）などの新しいトランスポートプロトコルの開発に、TCP上の無線リンクの特性とモビリティ効果の影響の範囲でした。また、かなりの時間は、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が適切に機能する必要があり、その後満たされている制約を提供しました。 IS-95 CDMAベースのデータサービスのプレゼンテーションは、条件ラインは損失の間にはほとんど相関して1--2％のエラーレートを提供することを示しました。同様のコンディショニングおよび前方誤り訂正（FEC）メカニズムは、他の無線及び衛星システムのために適切であるかもしれない[4]。これは、すべてのワイヤレスメディアの真実ではないかもしれないが、それは、それが示すという事実に面白かったです
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ソースに非うっ血性損失を示すためのメカニズムを提案に焦点を当てました。提案は、パケット破損の損失が検出されたとき、例えば、送信された非うっ血損失表示（NCLI）を含んで、ソースは停止の終了時に送信元送信を刺激する（SE）を奨励送ります。データの破損に加えて、無線リンクもドロップアウトを体験することができます。このような状況では、アクティブなTCPセッションは各試行の間に指数関数的に増加するバックオフタイマーを使用して、定期的な再送信を開始します。リンクが利用可能になるとTCPセッションが送信を再開する前にそれが何秒かもしれません。パケットのキャッシングと、トリガーの再送を含め、この問題を軽減するためのメカニズムは、議論されました。これらの機構の全てのより一般的な形態は、レイヤ2（データリンク）システムの状態は、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 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.
TCPのパフォーマンス上のモビリティの影響に関する懸念もありました。 TCPは、伝搬遅延の境界上の暗黙の仮定があります。遅延が平滑化往復時間を加えた4回のラウンドトリップ差異を超えた場合、セグメントは、通常のバックオフ手続きをトリガ、失われたと考えられています。これらの仮定は、ハンドオフ中セグメント損失または重複によって侵害されていませんか？ D-SACK [25]の作業は、並べ替えを検出し、適応DUP-ACK閾値を考慮して、これらの心配を軽減することができます。最後に、直ちに路特性が異なることを前提に移動ハンドオフの後（すなわち、スロースタートをトリガ）が適応するのが適切であるかもしれない提案がありました。
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]からいくつかのインスピレーションと、ワイヤレストランザクションプロトコル（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についての議論は、その動作の詳細を評価する上で中心。それは信頼性のためのメカニズムを内蔵しており、フロー制御が、それはインターネットの研究と展開長年の経験を通じて学んだ重要か微妙な輸送の問題を見逃す可能性が懸念されました。災害のための一つの可能性の領域は、固定された再送信タイマーと輻輳制御の欠如の使用であるように思われました。これは、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）攻撃に対する潜在的なエクスポージャーに提起されました。また、WAPFメンバーが直接（セクション3.4.3で以下の議論を参照。）の要件に貢献し、TCPの動作や新しいトランスポートの導入を進化上の現在の取り組みに遅れないまま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 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.
IETFでの輸送の仕事上の議論は、活動の大規模な配列を提示しました。輸送改善に関する最近の研究では、パスMTU、前方誤り訂正（FEC）、大きな窓、SACK、NewRenoの高速リカバリ、ACK輻輳制御、セグメントバイトカウント、明示的輻輳通知（ECN）、大きな初期送信ウィンドウ、および関連TCPの共有を含み接続状態[3,4,5,6,24,25,43,53,63]。新しいトランスポートの作業はACIRIの研究者によって[1] IETFシグナリング輸送（SIGTRAN）ワーキンググループとTCPフレンドリーレート制御（TFRC）にSCTP [61]を含んでいます。 SCTPは、永続的な関連付けと輻輳制御とで順序どおりの配信をサポートする信頼性の高いUDPのようなプロトコルを提供します。 TFRCは信頼できない、ユニキャストストリーミングメディアを対象としています。最後に、IETFエンドポイントの輻輳管理における作業（ECM）ワーキンググループは、輻輳制御アルゴリズムの標準化を見ていると、リンク特性（PILC）ワーキンググループの業績への影響で仕事がさまざまなリンク・テクノロジーのパフォーマンスへの影響を特徴付けるし、パフォーマンスの向上を調査しています。
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の拡張機能の性能と適用性にかなりの意見の相違がありました。しかし、この議論は重要なポイントのカップルを上げました。まず、インターネットコミュニティ内の輸送作業は、既存のプロトコルと新しいプロトコルの探査への改善への関心と活動にかなりの量があり、停滞していません。第二に、衛星ネットワークの研究者との仕事は、緊密な連携で可能な驚異的な成功を実証してきました。衛星ネットワーキングコミュニティは、長時間の遅延リンク上の最初のTCPのパフォーマンスに不満を持っていました。要件の提出との共同研究を通じて、改善の幅広い範囲が提案され、このような環境のユニークな特性に対処するために標準化されています。これがうまくいけば、その環境にインターネットプロトコルの採用で同様のコラボレーションを追求するために、ワイヤレス分野のものを奨励するために非常に肯定的な先例を設定する必要があります。
3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing Policy
航空通信ネットワーク（ATN）ルーティングポリシーに3.5ディスカッション
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.
航空通信ネットワーク（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 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.
現在のATNは、異なる空域を通じて「ローミング」として結合点を変えて自律系ネットワーク（AS）として各航空機を見ます。それらが、トポロジに関連し、また、更新の頻度が増加していないので、ルート集約を困難に固定されている航空機に関連する情報をアドレッシング。また、航空機は、多重経路選択のためのルーティングポリシーのサポートを必要とする、（複数のグランドと空間ベースのアクセスネットワークのカバレッジ内に）取り付けられてもよいです。最後に、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ルーティングポリシーに基づいています。 IDRPはIP環境で使用するために採用することができるかどうか、いくつかの議論がありました。 IETF内の好ましい解決策は、IDRPのような代替としてBGP4 ++ [8,54]を進めることになると迅速な合意がありました。これは、ATNのIDRPの機能を使用し、BGPに支持するそれらと同等の評価に議論を移行しました。 BGPを持ついくつかの問題は、さらなる調査のために提起されました。例えば、BGP AS空間が十分であるかどうかなど、各航空機を収容するために？また、モビリティサポートを発行。 BGPは、動的に添付ファイルの変更、および現在のピアリングに基づいて代替パス選択ポリシーのポイントとしてピアリングを変更するために提供することができますか？追加の調査にかなりの量は、特にQoSの領域に、完全にIDRP機能のATNの使用状況を評価するために必要とされます。これらは、乗客娯楽トラフィック対航空機制御のために異なる優先順位付けやパスの選択を行うために、インスタンスのための追加的なBGPの要件、につながる可能性があります。
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.
データ機能とともに音声およびその他のリアルタイムサービスのサポートを有効にすると、サービスの品質（QoS）を必要と無線環境での限られた伝送リソースへのアクセスを調停しています。無線およびモバイル環境は、無線リンクのローミングと独自の特性を収容し、モバイルデバイスとネットワークアクセスポイントとの最後のレッグの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の機能はペイロードタイプの基本的なサービスの独立として提供することが重要であることは非常に強く感じました。これには、音声または他のアプリケーションのセマンティクスの知識であっ構築する必要があり、ではありません。これは、活用して簡単に新しいアプリケーションをサポートするように拡張することができる機能になります。
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 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.
ボイスオーバーIP（VoIP）上の議論は、（無線）アクセスリンクは、典型的には、ほとんどの制約資源であり、競合アクセスが（CSMA）は、データのための良好な利用を提供しながら、それは音声のために理想的ではないことを強調しました。二つのモデルは、VoIPのアーキテクチャにおける潜在的な解決策として同定されました。最初は直接ローカルアクセスルータを知らせる無線デバイスを持つことです。第二の代替は、呼制御エレメント（SIPエージェント[30]）「プログラム」エッジルータを有することです。このトレードオフは、特にモビリティとローミングハンドオフの顔で導入することができる合併症与えられた追加調査のためのオープンエリア、ように見えました。これは、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.
IEEE 802.11 WLANグループ内の仕事は、QoSをサポートするための同様の要件を特定しました。そのグループは、2つの送信キュー、リアルタイム用とベストエフォートトラフィックのための1つを採用したモデルを調査しています。追加の計画はIP DiffServのマーキング[14,46]とIEEE 802の優先順位間のマッピングが含まれます。
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.
声明はまた、無線リンク上のQoSは、むしろそれは、サービスを中断することなく、ハンドオフを越えモビリティ側面とのシームレスな適応を処理している、根本的な問題ではないこと。作られましたフロー毎の状態（RSVP [13]）を確立するメカニズムについての懸念がありました。問題は、国家のスケーリング、およびローミングイベントで、シグナリングオーバーヘッドとセットアップ遅延を含んでいます。 DiffServは[9]の手法は、ローミング簡素化、集約トラフィッククラスのQoSを割り当てることができます。しかし、DiffServは経時測定及び割り当て調整を必要とし、注入された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のワーキンググループでの高まる需要があると述べました。 GPRSプロトコルに取り組んでメンバーにもこの情報を暴露することなく、QoS機能の展開に不満を示しました。これは明らかにさらなる調査のためのトピックを見えました。
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 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.
QoSの発見に関する議論の最後の領域は、サーバアプリケーションが受信機の能力を見つけるかもしれない方法の問題に焦点を当てました。これは、クライアントデバイスとパス特性へのアプリケーションの適応を可能にすることができます。 QoS情報を転送することが可能であるRSVPペイロードの1つの提案提案された使用。第二の代替は、アプリケーション層への能力交換と交渉をプッシュすることです。アプリケーションの問題は、ワークショップのチャーター外とみなされたように、このトピックに関する議論は、しかし、これはまた、今後の調査のための開口面積を思わ、簡単でした。
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.
高い帯域幅制約無線セルラー環境におけるインターネットプロトコルの採用にとって重要抑止は、プロトコルエンコードのビットのオーバーヘッドです。提示の実施例は、（例えば、音声アプリケーション（IP [52,19]、UDP [51]の上に重ね、およびRTPは、[57]）は、任意のアプリケーションペイロードの前にIPv6のIPv4のヘッダの40バイトまたは60バイトの最小値を必要とするどのように強調表示されました24バイトの音声サンプル）。このオーバーヘッドは、非常に低いデータレートベアラのためのWAPワイヤレスデータグラムプロトコル（WDP）ではなくIPを作成するための要因として発表されました。
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のロバストヘッダ圧縮（ROHC）ワーキンググループ内で実行される作業に焦点を当ててこれらの問題を軽減します。このワーキンググループでは、無線スペクトルを節約するために、モビリティに対応するために、両方の圧縮が適用され、コンプレッサとデコンプレッサとの間にある点の前にパケット損失に対してロバストであることが、無線環境の目標を確立しました。設立追加要件は、追加のエラーを導入しない、技術が透明であることがあったが、それは一般的なプロトコルlayeringsと互換性があること（例えば、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.
主な観測は、この問題は今、大部分は解決されていることでした！ワーキンググループは現在、ROCCO [38]およびACE [42]プロトコルを評価し、そして近い将来に勧告を確定することを期待されています。これは、これらのエンコーディングは、1バイトの最小ヘッダを有し、RTP / UDP / IPパケットの2未満の平均バイトオーバーヘッドをもたらすことが報告されました。輸送チェックサムが必要で、まだいくつかの問題は、暗号化とトンネリングとの相互運用に関連して、分析する場合に必要ないくつかの余分なオーバーヘッドがあります。
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プロトコルの使用上の議論は、その採用の別の潜在的な損害などのプロトコルのエンコーディングを強調しました。選択肢の数は、TLS [20]を用いて圧縮を使用して、コンテンツの符号化を「収縮」の使用を含む、調査のために言及した、またはし
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プロトコルのよりコンパクトな代替エンコーディングを調査するのに有益であり得ることが行われました。
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プロトコルの開発は、伝統的にいくつかの余分なビット送信のコストで単純なエンコード/デコードおよびワードアラインメントを好むのアプローチをとっています。それは少しの節約のためのプロトコルエンコーディングを最適化することが多いプロトコルの進化上の欠点や制限につながると述べました。しかし、それはまた、物理的な限界が伝送容量とシステムパフォーマンスに影響を与える環境が最適化された符号化が有益である例外を提示することができると主張しました。セルラー無線近宇宙衛星はこのカテゴリーに入ることがあります。
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プロトコルは、既存のインターネットプロトコルは非常に低いデータレートベアラサービスと限られた機能デバイスとの養子縁組のためにあまりにも非効率的であることが感じられたいくつかの例を示します。 WAPワイヤレスセッションプロトコル（WSP）はHTTPv1.1に基づいている[23]、しかしWSPは、知覚される非効率性に対処するためにいくつかの変更が組み込まれています。 WSPは、効率的な接続と能力ネゴシエーションのためのよりコンパクトなバイナリヘッダ符号化および最適化を使用します。同様に、WAPワイヤレスアプリケーション環境（WAE）は、より効率的な動作のためにトークン化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.
より効率的でコンパクトなプロトコルエンコーディング、および特に改善能力交渉のための追加の要求は、ワイヤレスハンドヘルドデバイスと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.
これらの観察の多くは、プロトコル動作の最適化を追求する正当な理由を表すという幅広い合意があるように見えました。トランザクションを完了するために、コンパクトなプロトコルのエンコーディング、機能ネゴシエーション、および最小化または重複のラウンドトリップの調査ができ環境の幅広い改善、アプリケーションのパフォーマンスへのすべてのリード。
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）をエスケープします。限られた機能をハンドヘルドデバイスに関連してプロキシは、そのような公開鍵操作のような高価な処理をオフロードするコンテンツフィルタリングを実行し、または「バックエンド」アプリケーション（例えば、電子メール、カレンダー、データベース）へのアクセスを提供するために展開されるかもしれません。他の場合には、プロキシは、プロトコルの展開の制限を回避するために必要とされ得る（例えば、NAT限られたIPv4アドレスを持ちます）。
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.
プロキシエージェント上の議論は、主に、プロキシエージェント・タイプの範囲があることを認識しました。プロキシはプロトコルパケットをインターセプトし、解釈し、または接続をハイジャックまたはリダイレクトすることによって動作することができます。プロキシの種類によっては、インターネットのエンド・ツー・エンドの通信およびセキュリティモデルを破ります。他のプロキシアーキテクチャは、状態やパフォーマンスの制約により、システムの拡張性を制限する可能性があります。システム動作への影響を評価するために、プロキシエージェントモデルのさらなる研究を行うためにいくつかの願望がありました。
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.
予測は、特に、右フロントまでこれらの予測についての注意があった2004年12億携帯（音声）の加入者、インターネット上の600万の有線ステーション、百万600以上のワイヤレスデータ（「ウェブ携帯電話」）のユーザーを主張発表されましたワイヤレスデータ、それは少し歴史を持つ非常に投機的であるため。第二に、10億の加入以上のユーザーベースからの重要な収入のための潜在的なに関するいくつかの疑問がありました。これは、これらのデバイスを得て、十分な可処分所得で世界人口の限界に挑戦することができます。しかし、携帯電話やインターネットのサービスが急速な成長を続けるしようとしていると、その無線データ端末は、全インターネットの重要な構成要素を形成する可能性を持っていることを幅広い合意がありました。これらの結論は、新興（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 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.
ワイヤレスデータユーザーの投影多数をサポートするために、スケーリング上の3G携帯電話ネットワーク技術の議論上のほぼすべてのプレゼンテーションでのIPv6プロトコルの採用のためのインターネットの代表者による強い擁護しました。グループはIPv6の調査を始めているいくつかの肯定的な兆候がありました。例えば、3GPPはすでに1998年と1999年仕様（リリースR98とR99）のオプションとしてIPv6を定義している、とMWIF努力はまた、IPv4とIPv6の問題を認識しており、現在でリリース2000年に義務として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の意識に明るい兆しが制限されていたが、表示は3G標準の努力のいずれかでのIPv6の普及のためのコンセンサスを得るために前方に長い戦いがあるということです。そこ電話キャリアは高いインフラ設備費用の結果、展開することがより困難として、IPv6を感じることはかなりのフィードバックがあって、相互運用の難しさと現在（IPv4）のインターネットへのゲートウエイを追加します。 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の使用状況に関する懸念のもう一つの領域は、知覚メモリと処理オーバーヘッドと小さな、限られた機能デバイスに対するその影響です。これは主に、適合性を主張するために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は、無線データユーザ投影のスケーリング要件に対応し、使用するシステムの継続的cobbling（IPv4）のプライベートアドレス空間とNATを排除します。これは、様々な3Gフォーラムが提言と格闘としてのIPv6の採用を提唱強い姿勢を取るためにIABのためのエリアとインターネットコミュニティを表示されます。
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 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.
コールセットアップおよび制御機能、およびモビリティの影響に焦点を当てたシグナル伝達に対する議論。 3G.IP基は上のいずれかのH.323 [32]またはSIP [30]の標準化検討しています。現在サポートは、プロトコル間で分割されているようだ、とどちらがモビリティのサポートのない理想的なように見えました。 VoIPの上の議論の中で、それは優雅な携帯ハンドオフの取り扱い、リモートピアと位置情報を更新して、両方のエンドポイントであっても、同時にハンドオフで、SIPは、モビリティをサポートすることを発表されました。 SIPの採用に伴う問題は、その遅い標準化が難しく、マルチキャストモデルに焦点を当てるのではなく、ユニキャスト「プロファイル」の定義を促進することによってもたらされているようです。 IETFはSIPのファイナライズを促進するための大きな必要性があるようだ、しかし、いくつかは、それが多くの製品は、SIPとH.323の両方のサポートを開発する必要があり、そして彼らの相互運用のためになる可能性があります。この時点で主張しました。
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
IETFやその他の標準化組織間の相互作用の3.12ディスカッション
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標準規格を採用したいと考え、多くの例がありました。例えば、IEEE 802.11 WLANは、モバイルIP、エンドツーエンドのセキュリティ、およびAAAサービスのためのIETF標準規格の採用に依存しています。 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].
フラストレーションのための一つの共通テーマは、標準化手順の違いです。例えば、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の、「サービス」として、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標準化に参加することでどのようにオープンでシンプルに気づいていないと驚いているようです。
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、目標は「お互いの問題を理解する」ことであるなど、他の標準化団体とのコミュニケーションを促進しようとすると標準化プロセスへの要求事項の入力、およびより高い可視性を提供すべきです。
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ワーキンググループが強く、その憲章の中に潜在的なリエゾンの要件を考慮してお勧めするよう奨励されるべきです。
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議事内外部の専門家の出席と参加を奨励するとの重複を避けるためです。
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を後援することは有益であり得ることを推奨しました。これらは、早期将来の標準化活動のための新しいトピックを探求する過程で複数のドメインからの専門家の組み立てを可能にすることができます。
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.
これは、相互の文書のレビューは奨励されるべきであると勧告されました。これは、現在の標準化活動に関する情報を発信するのに役立ちますし、外部の専門家のフィードバックのための機会を提供します。深刻な活動のこのタイプの有効性を制限する可能性がある重大なハードルはいくつかのグループが自分の基準や作業文書に置き、知的財産および配布制限があります。
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.
「イントラネット」の現在の展開に似た「壁に囲まれた庭」（キャプティブ顧客）のモデルにいくつかの知覚の利点があります。 「キャプティブ顧客」経済モデルに簡略化されたユーザのセキュリティからこれらの範囲。この展開モデルは、将来的に永続されるかもしれない程度に意見の相違がありました。しかし、存在するこのモデルを認識し、それに対応するために、それは、プロトコルの設計にどのように影響するかをどのように意識的な決定を下すことが重要です。
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.
それは強くプロトコルとアーキテクチャの決定は、このモデルを対象とはならない「壁に囲まれた庭」の展開シナリオのユビキタスとは独立していることを推奨されていました。非常に多様な異種環境間で動作し、インターネット・プロトコルの成功を継続するために、IETFは、「オープンモデル」の採用を促進し続けなければなりません。 IETFプロトコルの設計は、シームレスで安全かつスケーラブルなアクセスに対処しなければなりません。
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の使用を提案しました！
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個のオーダーの支援に突出しています。ユーザーのこの大きさをサポートすることが先細りするIPv4アドレス空間の使用に厳しいスケーリングの影響を持つことができます。
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人の万人のユーザーに10年代を支持した状態とパフォーマンスへの影響は、コストや技術的法外です。
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機能、およびセキュリティが残ります。加えて、状態シグナリングを加え、そしてトンネリングはコストがあり、技術的に法外なスケーリングであってもよいです。
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インターネットの移行の際に必要とされていることが認められました。
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アドレス空間は、アドレス空間の不足によるプライベートアドレスの割り当て[55]やアドレス変換[15]のためにどのような要件を排除するのに十分な大きさであると考えています。したがって、これを達成することは、主にインストールし、レジストリおよびサービスプロバイダの適切なアドレス割り当てポリシーを強制する必要がなければなりません。これは、使用するサイトのグローバルアドレスの十分な量を割り当てるために、サービスプロバイダが必要な政策を確立することを推奨されていました。感が[37]の問題[17,62] NATが容易に除去されなければならない提供、効率的な戦略はリナンバリングに対処するために定義されていることだったとモビリティ。
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サービスをプッシュするのを助けることができます。
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の問題に関連する追加の不備も同定されました。これらの制限に起因するソリューションとしてこれをお勧めするために抵抗がありました。
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がより容易に適合されている場合、アドレスの新しい「のケア」へのルータに転送。
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移行の問題を導入することができます。これは、任意のモバイルIPの相互運用上の問題が識別されて、ワーキンググループの既存のIETF次世代移行（NGTRANS）のチャーターに、これらの問題の調査を追加するために推奨されていました。
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に基づいた商用サービスの展開に不可欠です。いくつかの作品は[26,49] IPモビリティのためのこれらの基準の定義に進んでいます。ただし、商用サービスを展開する能力にこれらのプロトコルの中心的役割のために、それはこれらのAAA基準とAAAのスケーラビリティと高い優先順位の調査の最終決定を行うことが推奨されていました。
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.
無線環境とアプリケーションは、トランスポートプロトコルの追加要件を置きます。接続設定およびトランザクションセマンティクスへのユニークなリンクエラーとパフォーマンス特性、およびアプリケーションの感度は、「最適化」につながっている各環境に固有の輸送。これらの新しいトランスポートは、多くの場合、インターネットトランスポートで見つかった堅牢性を欠き、インターネットへのシームレスなゲートウェイへの障壁を置きます。これは、インターネットトランスポート進化上の輸送の設計と協力に関するより良い教育が重要な改善につながる可能性があることを感じました。
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 establishment, congestion control, loss recovery strategies, etc.), and document some of the history behind transport research in the Internet.
これは、インターネットのトランスポートプロトコルは、彼らがされている方法である理由IETF交通エリア（TSV）ワーキンググループ文書ことを推奨されていました。焦点は、一般的な輸送問題やメカニズムではなく、TCPの仕様にする必要があります。これは、特定のトランスポート・メカニズム（例えば、接続確立、輻輳制御、損失回復戦略など）、および文書インターネットでの輸送研究の背後にある歴史の一部の設計での使用とのトレードオフをキャプチャする必要があります。
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]、IETFエンドポイントの輻輳管理（ECM）ワーキンググループ内のTCPの輻輳制御[5]、および継続的な作業の標準化は、ワイヤレストランスポートデザイナーの教育のための優れた基盤を提供することができます。
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]の研究テーマを特定するのにして、新しい運用環境に対処するために、プロトコルの進化を導くのに非常に有効であることが証明されました。
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交通エリア（TSV）ワーキンググループでそれらをアクティブに取得することを推奨されていました。 「全てを捕まえる」この輸送は、インターネットコミュニティ外の労働者がアイデアや要件を提案し、前IETFに正式な提案を貢献するか、ワーキンググループ形成のオーバーヘッドを発生するIESGメンバーとの対話に従事するための優れたフォーラムを提供することができます。
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 (SE) message [39]. This likely falls to the auspice of the IETF Performance Implications of Link Characteristics (pilc) working group.
モバイル無線環境は、多くの場合、頻繁に一時的な停電を受ける可能性があります。例えば、任意の基地局、または基地局ハンドオフに起因する混乱の範囲外である領域を通ってローミング。 TCPのうっ血性損失の仮定のこの違反は、トランスポートのパフォーマンスに深刻な悪影響を与える可能性があります。それは、これらの非うっ血性の損失を検出することができたときに輸送性能を向上させるためのメカニズムを調査するために推奨されていました。識別された潜在的な研究のための領域がソース奨励（SE）メッセージ[39]を経由してリンク回復後の非うっ血性損失の表示（NCLI）または刺激伝達を提供する送信者に「ヒント」の取り込みが含まれます。これはおそらくリンク特性（PILC）ワーキンググループのIETFパフォーマンスへの影響の後援に落ちます。
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）攻撃、往復遅延を解消するために、接続の確立中にデータを便乗するメカニズム、またはエンドポイントは、単純なトランザクションのためのセットアップ握手を排除に協力するための方法が含まれますスイッチ・オーバー信頼性の高いストリーミングにバルク転送のために。
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パケットが時々破損している無線環境における有益性を実証することができる並べ替え、パケット、に追加の堅牢性を提供します。より高い性能は、フロー内で順序どおりの配信を維持するリンクレベルの再送信に対する要求を排除することによって達成することができます。
Unique routing requirements may be introduced in support of wireless systems, especially when viewing the mobile component as an autonomous system (AS).
自律システム（AS）などのモバイルコンポーネントを表示する場合は特にユニークなルーティング要件は、無線システムをサポートするために導入されてもよいです。
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 peer policy. These features could be used for instance in support of requirements established in the Aeronautical Telecommunication Network (ATN).
これは、[33] ISO IDRPプロトコル内で利用可能な追加のポリシー機能をサポートするために、[54] IETFルーティングエリアは、BGPプロトコルの拡張の調査を開始することを推奨されていました。所望のポリシー制御の範囲は、添付の現在位置に基づいて異なる同一またはポリシーを採用し、ローカルポリシーおよび/または現在のピアポリシーに基づいて、経路選択の自由度を提供することを含みます。これらの機能は、航空通信ネットワーク（ATN）に設立された資格要件を満たしていることのインスタンスを使用することができます。
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.
これは、ISO IDRPプロトコル[33]内で利用可能な追加的なQoS / TOSパス選択機能をサポートするために、[54] IETFルーティングエリアは、BGPプロトコルの拡張の調査を開始することを推奨されていました。政策の範囲は、トラフィッククラスに基づいてサービスレベルやパスの選択を区別含まれています。例では、航空通信ネットワーク（ATN）の要件に基づいて、航空会社のコントロールと乗客の娯楽トラフィック間のパスの選択やサービスを差別化される可能性があります。
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.
無線リンク帯域幅（例えば、細胞）および/または共有（例えば、IEEE 802.11 WLAN）しばしば不足しています。アプリケーションのQoSニーズを満たすことが、モバイルホストのローミング自然に加えて、これらのリンクの特性を収容必要です。専門のサポートは、リンクとエンドツーエンドのパフォーマンスの制約の両方を満たすために、ネットワーク層から要求することができます。
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交通エリアは、モバイルシステムの最後の脚にQoSを提供するに捜査に着手することを推奨されていました。つまり、モバイルデバイスとネットワーク・アクセス・ポイントとの間です。無線リンクは、最も制約の資源ですQoSサポートのこのタイプが適している場合があります。調査する潜在的な解決策は、モバイルホストとアクセスポイントとの間の明示的な予約機構を使用することである（例えば、RSVP [13]）、コア内のリソースプロビジョニング以上のスケーラブルのDiffServ [9]技術に頼っています。
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交通エリアは、エンドツーエンドのQoSの調査に着手することを推奨されていました。この調査は、エンドツーエンドのQoS保証を確立するために、コアネットワークにセルラーネットワークにおけるQoS特性を通信するメカニズムに焦点を当てることができました。代替調査は、モバイルホストによって動的に適応するために有効に、現在のエンド・ツー・エンドのパフォーマンス特性を評価する発見の問題を検討することです。
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
WAPのような環境でのTCP / IPのパフォーマンス特性評価の4.9勧告
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プロトコルスタックは、あまりにも高価であるという認識に独自のトランスポートプロトコルと最適化を開発するために多大な努力を行ってきました。これの多くは、非常に低いデータレートベアラサービスをサポートするために、WAPの要件を前提ました。それはIRTFのメンバーは、その動作と適用性を定量化するために、WAPのような環境でのTCP / IPスタックの性能を評価することを推奨されていました。焦点は、現在のWAPプロトコル用とIPv4とIPv6の両方のための単一のトランザクションを完了するためのコードとメモリ容量の要件の調査と同様に、リンクの使用状況を含める必要があります。この作品は非常に制約のあるデバイスやネットワーク、プロトコルの拡張にIETFに勧告この環境でパフォーマンスを最適化するため、およびネイティブIPプロトコルを展開する適合性についてWAPFに勧告におけるTCP / IP性能の優れた特性を生じるはずです。
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ロバストヘッダ圧縮（ROHC）ワーキンググループ内での作業は、インターネット・プロトコルの展開にこれらの不利益のいくつかを軽減するのに長い道を行くことがあります。しかし、一般的なインターネット・プロトコルの代替エンコーディングの調査から、さらなるコスト削減のための潜在的な可能性があります。それはIRTFのメンバーは、プロトコル「言い回し」を低減するために用いることができる一般的な技術を評価することを推奨されていました。例としては、ペイロード圧縮技法またはトークン化プロトコル符号化を含むかもしれません。
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のファイナライズを行うことが推奨されていました。
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.
Bluetoothのプロトコルおよび装置は、もともと狭いアプリケーション領域用に最適化しました。しかし、プロトコル及びデバイスアクセスが拡張可能な幅を探索に関心があります。関心のある特定の領域はへの統合を模索し、またはインターネットへのアクセスをゲートウェイされます。これは、IETFは、この問題の探査を開始するためにIETFとBluetoothコミュニティからの専門家を組み立てるための共同BOFの形成を追求することを推奨されていました。これは、コミュニケーションと相互教育を促進するためにセクション4.1の勧告の直接サポートです。
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リダイレクタを例えば、Webキャッシュ）プロトコル要求をインターセプトし、評価するために配備されているか、通信ドメイン（例えば、携帯電話サービスとインターネットの間のプライベートネットワークとインターネットまたはゲートウェイ間の横断要塞ホスト間のアクセスゲートウェイします）。これらのプロキシエージェントの1の開発と展開を考え潜在的なアーキテクチャの数があります。それはIRTFのメンバーは、プロキシアーキテクチャの分類を調査し、その特性と適用性を評価することを推奨されていました。プロキシの各タイプは、例えば、インターネットのエンドツーエンドモデル、およびセキュリティ、スケーリング、およびパフォーマンスへの影響に対するその効果によって、特徴付けられるべきです。この研究の結果は、利用可能なプロキシの範囲で、開発者とネットワークオペレータの教育を支援し、インターネット・プロトコルに少なくとも破壊的なソリューションをお勧めすることができます。
4.14 Recommendations on Justifying IPv6-based Solutions for Mobile / Wireless Internet
モバイル/ワイヤレスインターネットのための正当化IPv6ベースのソリューションで4.14勧告
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携帯電話とIPネットワークへの進化のセキュリティ・メカニズムに焦点を当てたセクション2で参照しました。 「壁に囲まれた庭」サービスモデルについての議論は、簡単にセキュリティ要件を簡素化への影響に言及している（3.1節を参照してください）。 3.3節では、ワイヤレスデバイスとモビリティに関連したセキュリティ上の問題の数を発生させます。これらは、モバイルIPおよびAAAの動作に必要なユーザーIDと能力を確立するための代替手段、攻撃からネットワークインフラストラクチャを保護し、セキュリティアソシエーションが含まれます。 3.7節は、圧縮と暗号化やトンネリング、高価な暗号操作をオフロードするために使用するプロキシエージェントの最後にセクション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.
著者は、この文書の過去記事の間に彼らのフィードバック、励まし、そして忍耐のためのワークショップの参加者のすべてに感謝したいと思います。私は特に、文書の構成と内容に関する質問への迅速な対応のためのブライアン・カーペンターに感謝したいと思います。同様に、チャーリーパーキンスは劇的に改善し、レポート全体の文を修正豊富なフィードバックを提供します。最後に、ミカエルDegermark、サリー・フロイド、ヘイッキHammainen、ジェフ・ヒューストン、とガブリエルモンテネグロが質問にコメントやレスポンスに貢献しました。
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.アガルワル、S.サベージ、およびT.アンダーソン。 TCP Pacingのパフォーマンスを理解します。 IEEEインフォコム2000年、2000年3月の議事。
[3] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[3]オールマン、M.、フロイド、S.とC.ヤマウズラ、 "増加するTCPの初期ウィンドウ"、RFC 2414、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.サンチェスを、RFC 2488、1999年1月、 "標準的なメカニズムを使用してTCP上の衛星テレビの強化"。
[5] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[5]オールマン、M.、パクソン、V.とW.スティーブンス、 "TCP輻輳制御"、RFC 2581、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.、Ostermann、 S.、スコット、K.とJ. Semke、 "継続的なTCPの研究衛星に関連する"、RFC 2760、2000年2月。
[7] Arkko, J., "Requirements for Internet-Scale Accounting Management", Work in Progress.
[7] Arkko、J.、「インターネット規模の会計管理のための要件」は進行中で働いてい。
[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、RFC 2283、1998年2月 "BGP-4のためのマルチプロトコル拡張機能"。
[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.ワイス、RFC 2475、1998年12月 "微分されたサービスのためのアーキテクチャ"。
[10] Borella, M., et al., "Realm Specific IP: Framework", Work in Progress.
[10]ボレッラ、M.、ら、 "レルム特定IP：フレームワーク"、ProgressのWork。
[11] Borella, M., et al., "Realm Specific IP: Protocol Specification", Work in Progress.
[11]ボレッラ、M.、ら、 "レルム特定IP：プロトコル仕様"、ProgressのWork。
[12] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[12]ブレーデン、R.、 "T / TCP - 取引機能仕様のためのTCP拡張機能"、RFC 1644、1994年7月。
[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機能仕様"、RFC 2205、1997年9月。
[14] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 2836, May 2000.
[14]つば、S.、大工、B.およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 2836、2000年5月。
[15] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[15]カーペンター、B.、クロウクロフト、J.およびY. Rekhter、 "IPv4アドレス動作今日"、RFC 2101、1997年2月。
[16] Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
[16]大工、B.、 "インターネット透明性"、RFC 2775、2000年2月。
[17] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[17]クロフォード、M.、 "IPv6のルータリナンバリング"、RFC 2894、2000年8月。
[18] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985.
[18]クロフト、B.及びJ.ギルモア、 "ブートストラッププロトコル（BOOTP）"、RFC 951、1985年9月。
[19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[19]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[20] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[20]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。
[21] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[21] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、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の定義"、RFC 1183、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.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1"、 RFC 2616、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の変更"、RFC 2582、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のための選択的確認応答（SACK）オプションの拡張"、RFC 2883、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認証、認可、およびアカウンティング要件"、RFC 2977、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"、RFC 2052、1996年10月。
[28] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[28]ガットマン、E.、パーキンス、C.、Veizades、J.とM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[29] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[29]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[30] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[30]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
[31] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
[31]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症（NAT）"、進行中の作業。
[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]国際電気通信連合。サービスの非保証品質を提供するローカルエリアネットワークのためのビジュアル電話システムおよび機器。勧告H.323、1996年5月。
[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。 ISO 8473台のPDUの転送をサポートするための中間システム間でドメイン間のRouteing情報を交換するためのプロトコル。 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.ヤコブソン。輻輳回避とコントロール。コンピュータコミュニケーションレビュー、巻。 18、ありません。 8月4日1988年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の輻輳回避アルゴリズム。 end2end金利メーリングリスト、4月30日、1990年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.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[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.、ら。、 "体力チェックサムベースヘッダ圧縮（ROCCO）"、進行中の作業。
[39] Karn, P., et al., "Advice for Internet Subnetwork Designers", Work in Progress.
[39]カーン、P.、ら。、「インターネットサブネットワークデザイナーのためのアドバイス」、進行中の作業。
[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。 '99、1999年12月GLOBECOM IEEEの議事録。
[42] Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time Multimedia", Work in Progress.
、進行中の作業「リアルタイムマルチメディアのための適応型ヘッダ圧縮（ACE）」[42]ル、K.、ら。、。
[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の選択確認応答オプション"、RFC 2018、1996年10月。
[44] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD 13, RFC 1034, November 1987.
[44] Mockapetris、P.、 "ドメイン名 - 概念および機能"、STD 13、RFC 1034、1987年11月。
[45] Mockapetris, P., "Domain Names -- Implementation and Specification", STD 13, RFC 1035, November 1987.
[45] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[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フィールド）の定義"、RFC 2474、1998年12月。
[47] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[47]ウズラ、C.、メンデス、T.およびW.ミリケン、 "ホストエニーキャストサービス"、RFC 1546、1993年11月。
[48] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[48]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[49] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
[49]パーキンス、C.およびP.カルフーン、 "モバイルIPのためのAAAの登録キー" が進行中で働いています。
[50] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[50]パーキンス、C.およびD.ジョンソン、「モバイルIPにおける経路最適化」が進行中で働いています。
[51] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[51]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
[52] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[52]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[53] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[53]ラマクリシュナン、K.およびS.フロイド、 "IPに明示的輻輳通知（ECN）を追加する提案"、RFC 2481、1999年1月。
[54] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[54] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[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.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、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. Willens、RFC 2138、1997年4月 "ユーザーサービス（RADIUS）においてリモート認証ダイヤル"。
[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. Jacobson氏、 "RTP：リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、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のSIGCOMM '98の予稿集、1998年9月。
[59] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[59] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[60] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", Work in Progress.
[60] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）" が進行中で働いています。
[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.パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[62] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[62]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[63] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[63]タッチ、J.、 "TCP制御ブロック相互依存"、RFC 2140、1997年4月。
[64] Vollbrecht, J., et al., "AAA Authorization Framework", Work in Progress.
[64] Vollbrecht、J.、ら、 "AAA認可フレームワーク"、ProgressのWork。
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
B Author's Address
Bの著者のアドレス
Danny J. Mitzel Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ダニー・J. Mitzelノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625 2037 EMail: mitzel@iprg.nokia.com
電話：+1 650 625 2037 Eメール：mitzel@iprg.nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。