[要約] RFC 3002は、2000年のIABワイヤレスインターネットワーキングワークショップの概要を提供しています。このRFCの目的は、ワイヤレスネットワーキングの現状と将来の展望を議論し、関連する技術と課題についての洞察を提供することです。
Network Working Group D. Mitzel
Request for Comments: 3002 Nokia
Category: Informational December 2000
Overview of 2000 IAB Wireless Internetworking Workshop
2000年のIABワイヤレスインターネットワークワークショップの概要
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.
Copyright（c）The Internet Society（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）が開催したワークショップの概要を提供します。ワークショップは、2000年3月29日から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.
ワイヤレスLANS、セルラー無線経由のデータ転送（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、およびその他のアプリケーションを使用することを選択していません。これらは、エッジデバイスのコスト、帯域幅の制限、知覚されたプロトコルの欠陥、不必要な複雑さ、アプリケーションプロトコルのおしゃべり、および問題に対処するネットワーク層に関連しています。残念ながら、これは有線/無線の境界にいくつかの深刻な問題を引き起こします。終了操作が犠牲になり、セキュリティが侵害され、何らかの形で自動化されたコンテンツの変更が必要になります。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
+ ワイヤレスネットワークを介してVoice over 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
プレゼンター：Heikki Hammainen
Reference: http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.PDF, http://www.iab.org/IAB-wireless-workshop/talks/hh-IABpub.ppt
参照：http：//www.iab.org/iab-wireless-workshop/talks/hh-iabpub.pdf、http：//www.iab.org/iab-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を超えて実行される問題の概要？
Presenter: Juha Ala-Laurila
プレゼンター：Juha Ala-Laurila
Reference: http://www.iab.org/IAB-wireless-work-shop/talks/IEEE80211_IP.ppt
参照：http：//www.iab.org/iab-wireless-work-shop/talks/iee80211_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
プレゼンター：フィルカーン
Reference: http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm
参照：http：//www.iab.org/iab-wireless-workshop/talks/karn/index.htm
Overview:
概要：
Title: Wireless Internet Networking
タイトル：ワイヤレスインターネットネットワーキング
Presenter: Chih-Lin I
プレゼンター：Chih-lin 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
プレゼンター：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
プレゼンター：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
プレゼンター：クリス・ウォーゴ
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 over wireless
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-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?)
タイトル：Qos for Wireless（diffserv、intserv、other？）
Presenter: Lixia Zhang
プレゼンター：リキシア・チャン
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-workshop/talks/wireless-www.ppt
Overview:
概要：
Title: Compression & Bit Error Requirements for Wireless
タイトル：ワイヤレスの圧縮およびビットエラー要件
Presenter: Mikael Degermark Reference: http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.PDF, http://www.iab.org/IAB-wireless-workshop/talks/iab-hc.ppt
プレゼンター：Mikael Degermarkリファレンス：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
プレゼンター：ボブ・ヒンデン
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.ptt
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アクセスなどのデータサービスに焦点を当てています。サービスに対する制御を解放するためにキャリアの不本意に関する1つの観察結果は、これがインターネットベースの音声サービスの採用の障害である可能性があるということでした。Voice over IP（VoIP）およびCall Signaling（SIP [30]）に関する現在の作業は、これらのサービスの制御を緩め、機能の多くがSIPエージェントに移動し、キャリアがアクセスプロバイダーに削減されます（つまり、「Bit Pipe」」）。
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プロトコルの選択は、重要な議論のための別のトピックを提供しました。セルラーオペレーターはすでにプロトコルを展開しており、ローミングを大幅にサポートしています。これにより、3GPPや3G.IPなどのいくつかの取り組みが、すべてのモビリティサポートのために電話システムに依存して、IPレイヤーからローミングを隠しています。
Arguments for cellular-based roaming centered on concerns about the mobile IP model. There was concern that home agent and foreign agent involvement in delivery might introduce bottleneck, and the perception that mobile IP handoff is too slow. A rebuttal offered was that IETF mobileip working group is introducing hierarchy and route optimization to improve performance and robustness [50], and there was disagreement on the point regarding slow handoff under mobile IP.
モバイルIPモデルに関する懸念を中心としたセルラーベースのローミングの引数。ホームエージェントと配送への外国人エージェントの関与がボトルネックを導入する可能性があり、モバイルIPハンドオフが遅すぎるという認識が導入される可能性があるという懸念がありました。提供された反論は、IETF MobileIPワーキンググループが階層とルートの最適化を導入してパフォーマンスと堅牢性を改善しており[50]、モバイルIPの下での遅いハンドオフに関するポイントについて意見の相違があったことです。
Detriments to the cellular-based roaming include the lack of IP support out to the mobile device and the added tunneling protocols and overhead required. Additionally, roaming is less well defined when traversing service provider boundaries and may involve highly non-optimal forwarding path. There appears significant work remaining to reach convergence on opinions, and additional investigation to support roaming across cellular, WLAN, and IP boundaries.
セルラーベースのローミングの欠陥には、モバイルデバイスへのIPサポートの不足と、追加のトンネルプロトコルと必要なオーバーヘッドが含まれます。さらに、ローミングは、サービスプロバイダーの境界を通過する場合、あまり明確に定義されておらず、非常に非最適な転送パスが含まれる場合があります。意見に収束に達するためにはかなりの作業が残っているように見え、携帯電話、WLAN、およびIPの境界を越えてローミングをサポートするための追加調査があります。
3G.IP mobility model is primarily focused on providing ubiquitous service across a range of access media. However, the presentation also highlighted a desire to develop new "location based" services. Examples presented include locating nearby services or receiving advertisement and solicitations from nearby business.
3G.IPモビリティモデルは、主に、さまざまなアクセスメディア全体でユビキタスなサービスを提供することに焦点を当てています。ただし、プレゼンテーションでは、新しい「ロケーションベースの」サービスを開発したいという願望も強調されています。提示された例には、近くのサービスを見つけたり、近くのビジネスから広告と勧誘を受け取ったりすることが含まれます。
There are several Internet protocols defined, such as anycast service [47] and SLP [28], that may aid in developing location based services. However, there was considerable frustration on the part of 3G.IP in that there appears little commercial support of these protocols, and even less direction on how to assemble and coordinate the required protocols to deploy the desired services.
Anycast Service [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.
ユーザーIDの保存は、デバイスの使用とデバイスの移植性に大きな影響を与える可能性があります。ディスカッションでは、IDをモバイルデバイスまたは転送可能なSIMカードに結び付けるべきかどうかに焦点を当てました。デバイスとの識別を修正すると、製造を簡素化し、抵抗を改ざんすることができますが、ユーザーのIDを取得してパブリックデバイスを展開することは非常に困難になります。これらの代替案は、デバイスの交換またはアップグレードでの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.
関連するトピックは、単一のデバイスを採用したいが、目前の使用に基づいて異なるアイデンティティと特権をとるというユーザーの欲求を中心に展開します（たとえば、コーポレートアクセス、ホームアクセス、またはインターネットアクセスを獲得するため）。これらの複数のアイデンティティを仮定する能力と容易さは、上記のように、アイデンティティ統合のモデルに大きく依存している可能性があります。ディスカッションは、デバイスとユーザーのアイデンティティの結びつきに基づいて、潜在的な落とし穴を強調しました。IPSECデバイスIPアドレスの使用は、アドレスが位置に基づいて変更される可能性があるため、ローミング機能を阻害し、現在の使用のための識別と機能を際立たせます。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.
ユーザーIDの確立に関する議論の最終的なトピックは、デバイスの所有で十分であるかどうか、またはデバイスに認証するためにユーザーが必要なのかでした。現実の世界では、最初の代替品はクレジットカードモデルによって例示されますが、2番目の代替品はユーザーがピンコードも提供する必要がある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.
将来の3GPPと3GPP2は、IPをワイヤレスデバイスにずっと押し出すことを計画しています。観察は、これにより、シグナル伝達と攻撃への制御プレーンの暴露の可能性が高まるということです。欲求は、相互認証とネットワークの保護を実行することです。これは、解決するために追加の問題が残っているため、難しい問題です。ただし、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ネットワークのセキュリティ要件のサポートを完了すると、AAAサービスとモバイルIPの2つの主要な領域で問題を解決する必要があるようです。AAAは、認証、承認、請求に必要です。残りの問題は、クロスドメインAAA、PKIを使用した認証を中心に中心であり、頭上と遅延の知覚により、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.
輸送プロトコルに関する議論は、幅広い問題に触れました。懸念は、ワイヤレスリンク特性とTCPに対するモビリティ効果の影響から、WAPワイヤレストランザクションプロトコル（WTP）などの新しい輸送プロトコルの開発に及びました。さらに、TCP輸送の強化と新しい輸送の調査に関するIETF内での継続的な努力のレビューにかなりの時間が費やされました。
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 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は、約1％の腐敗損失を伴うリンクのために設計されており、制約が満たされている場合、TCPが適切に機能することを条件に、TCPが設計されたという声明が作成されました。IS-95 CDMAベースのデータサービスに関するプレゼンテーションにより、IT条件は、損失間の相関がほとんどなく、1〜2％のエラー率を提供することが示されました。同様のコンディショニングとフォワードエラー補正（FEC）メカニズムは、他のワイヤレスおよび衛星システムに適している場合があります[4]。これはすべてのワイヤレスメディアに当てはまるわけではないかもしれませんが、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）が含まれます。データの破損に加えて、ワイヤレスリンクもドロップアウトを経験する可能性があります。この状況では、アクティブなTCPセッションは、各試行の間に指数関数的に増加するバックオフタイマーを使用して、定期的な再送信を開始します。リンクが利用可能になると、TCPセッションが送信を再開するまでに何秒もかかる場合があります。パケットキャッシュやトリガーされた再送信など、この問題を軽減するメカニズムについて説明しました。これらすべてのメカニズムのより一般的な形式は、レイヤー2（Datalink）システムの状態が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を実行する問題が激化する可能性があります。これらの問題を軽減するために、接続の途中で大きなウィンドウエクステンションの動的な交渉を調査するための提案が含まれています。点に関する最終的な問題（以下のセクション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からインスピレーションを得て、ワイヤレストランザクションプロトコル（WTP）を開発しました[12]。WTPは、未確認のリクエストから単一の返信トランザクションによる単一の要求まで、いくつかのクラスのサービスを提供します。データは最初のパケットに搭載され、レイテンシを減らすために3方向の握手が排除されます。さらに、謝辞、再送信、およびフロー制御が提供されます。
Discussion on WTP centered on assessing details on its operation. Although it incorporates mechanisms for reliability and flow control there was concern that it may miss critical or subtle transport issues learned through years of Internet research and deployment experience. One potential area for disaster appeared to be the use of fixed retransmission timers and lack of congestion control. This gave rise to suggestions that the IETF write up more details on the history and tradeoffs in transport design to aid others doing transport design work, and secondly that the IETF advocate that the congestion control is not optional when using rate adaptive transport protocols.
WTPに関する議論は、その操作に関する詳細の評価に焦点を当てています。信頼性とフロー制御のメカニズムが組み込まれていますが、長年のインターネット調査と展開の経験を通じて学んだ重大または微妙な輸送の問題を見逃す可能性があるという懸念がありました。災害の潜在的な領域の1つは、固定再送信タイマーの使用と輻輳制御の欠如であると思われました。これにより、IETFが輸送設計の歴史とトレードオフの詳細を作成して、輸送設計作業を行う他の人を支援するために、輸送設計のトレードオフの詳細を作成し、第二に、IETFは、レート適応輸送プロトコルを使用する場合に輻輳制御がオプションではないことを提唱することを引き起こしました。
The remaining discussion on WAP transport primarily focused on ways to share information. It was suggested that any result from WAPF study of TCP shortcomings that led to its rejection might be useful for IETF review as inputs for TCP modifications. Similar comments were raised on study of T/TCP shortcomings and its potential exposure to Denial of Service (DoS) attacks. It was also encouraged that the WAPF members participate in the IETF directly contribute requirements and remain abreast of current efforts on evolving TCP operation and introduction of new transport (see discussion below in section 3.4.3.).
WAP輸送に関する残りの議論は、主に情報を共有する方法に焦点を当てていました。TCP修正の入力としてのIETFレビューには、その拒否につながったTCP欠点のWAPF研究の結果があらゆる結果が役立つ可能性があることが示唆されました。T/TCPの欠点と、サービス拒否（DOS）攻撃への潜在的な暴露の研究に関する同様のコメントが提起されました。また、WAPFメンバーがIETFに参加することを直接貢献し、進化するTCP操作と新しい輸送の導入に関する現在の努力に遅れをとっていることも奨励されました（以下のセクション3.4.3の説明を参照）。
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での輸送作業に関する議論は、多数のアクティビティを提示しました。輸送改善に関する最近の作業には、PATH MTU、フォワードエラー補正（FEC）、大きなウィンドウ、サック、NewReno Fast Recovery、ACK輻輳制御、セグメントバイトカウント、明示的な混雑通知（ECN）、より大きな初期送信ウィンドウ、および関連するTCPの共有が含まれます。接続状態[3,4,5,6,24,25,43,53,63]。新しい輸送の作業には、ACIRIの研究者によるIETFシグナル伝達輸送（Sigtran）ワーキンググループ（TFRC）[1]のIETFシグナル伝達輸送（Sigtran）の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パフォーマンスに不満でした。要件の提出と共同調査を通じて、この環境のユニークな特性に対処するために、幅広い改善が提案され、標準化されています。これは、ワイヤレスセクターの人々が環境へのインターネットプロトコルの採用において同様のコラボレーションを追求することを奨励するために、非常に前向きな先例を設定することを願っています。
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は、各航空機を、異なる空域を「ローミング」する際に、アタッチメントのポイントが変化する自律的なネットワークと見なしています。航空機に関連する情報のアドレス指定は固定されているため、トポロジーとは関係がなく、更新の頻度も増加するため、ルート集約が困難になります。さらに、航空機は（複数の地面とスペースベースのアクセスネットワークのカバー内で）増殖している場合があり、パス選択のためのルーティングポリシーサポートが必要です。最後に、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内の優先ソリューションは、BGP4 [8,54]をIDRPのような置換として進めることであるという迅速な合意がありました。これにより、IDRP機能のATN使用とBGPでのサポートに相当するATNの評価に関する議論が移行しました。さらなる調査のために、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.
Voiceやその他のリアルタイムサービスとデータ機能のサポートを有効にするには、ワイヤレス環境で限られた伝送リソースへのアクセスを仲裁するために、品質のサービス（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.
Voice over IP（VoIP）に関する議論は、（ワイヤレス）アクセスリンクが通常最も制約されたリソースであり、競合アクセス（CSMA）がデータに適した利用を提供する一方で、音声には理想的ではないことを強調しました。VoIPアーキテクチャの潜在的なソリューションとして2つのモデルが特定されました。1つ目は、ワイヤレスデバイスにローカルアクセスルーターを直接通知することです。2番目の選択肢は、コールコントロール要素（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つはリアルタイム用、もう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.
Qualcommで開発中の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つ。2番目の選択肢は、能力交換と交渉をアプリケーションレイヤーにプッシュすることです。アプリケーションの問題はワークショップチャーターの外で見られると見なされていたため、このトピックに関する議論は短いものでしたが、これは将来の調査のために開かれた領域でもあるようです。
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]を介して階層化されている）が、アプリケーションペイロードの前にIPv4の最低40バイトまたはIPv6に60バイトのヘッダーを必要とする方法を強調した（例えば（例：24バイト音声サンプル）。このオーバーヘッドは、非常に低いデータレートベアラーのIPではなく、WAPワイヤレスデータグラムプロトコル（WDP）の作成の要因としても提示されました。
Discussion on header compression techniques to alleviate these concerns focused on work being performed within the IETF Robust Header Compression (rohc) working group. This working group has established goals for wireless environment, to conserve radio spectrum, to accommodate mobility, and to be robust to packet loss both before the point where compression is applied and between compressor and decompressor. Additional requirements established were that the technique be transparent, does not introduce additional errors, and that it is compatible with common protocol layerings (e.g., IPv4, IPv6, RTP/UDP/IP, TCP/IP).
これらの懸念を軽減するためのヘッダー圧縮技術に関する議論は、IETFロバストヘッダー圧縮（ROHC）ワーキンググループ内で実行される作業に焦点を当てています。このワーキンググループは、ワイヤレス環境の目標を確立し、無線スペクトルを節約し、モビリティに対応し、圧縮が適用されるポイントとコンプレッサーと減圧装置の間でパケット損失に堅牢になりました。追加の要件は、この手法が透明であり、追加のエラーを導入せず、一般的なプロトコル層（例：IPv4、IPv6、RTP/UDP/IP、TCP/IP）と互換性があることでした。
The primary observation was that this problem is now largely solved! The working group is currently evaluating the ROCCO [38] and ACE [42] protocols, and expects to finalize its recommendations in the near future. It was reported that these encodings have a minimum header of 1 byte and result in average overhead of less than 2 bytes for an RTP/UDP/IP packet. There is some extra overhead required if transport checksum is required and some issues still to be analyzed related to interoperation with encryption and tunneling.
主な観察は、この問題が今では大部分解決されていることでした！ワーキンググループは現在、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 Bellovin's TCP filters. Observation was made that it could be beneficial to investigate more compact alternative encoding of the WWW protocols.
ワイヤレスハイライトされたプロトコルエンコーディングを介したWWWプロトコルの使用に関する議論は、採用に対する別の潜在的な不利益として。TLS [20]または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プロトコルの開発は、いくつかの追加のビット送信を犠牲にして、単純なエンコード/デコードと単語のアライメントを好むというアプローチを伝統的に採用してきました。少し節約のためにプロトコルエンコードを最適化することは、しばしばプロトコルの進化の欠点または制限につながると述べられました。ただし、物理的な制限が伝送容量とシステムのパフォーマンスに影響を与える環境が、最適化されたエンコーディングが有益である場合の例外を提示する可能性があると主張されました。Cellular WirelessおよびNearスペースの衛星は、このカテゴリに分類される場合があります。
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）から逃れるために翻訳します。限られた機能ハンドヘルドデバイスと組み合わせて、プロキシは、公開キー操作、コンテンツフィルタリングの実行、または「バックエンド」アプリケーション（電子メール、カレンダー、データベースなど）へのアクセスを提供するなど、高価な処理をオフロードするように展開される場合があります。それ以外の場合は、プロトコルの展開制限（例えば、IPv4アドレスが限られているNATなど）を回避するためにプロキシが必要になる場合があります。
The discussion on proxy agents primarily recognized that there are a range of proxy agent types. Proxies may operate by intercepting and interpreting protocol packets, or by hijacking or redirecting connections. Some types of proxy break the Internet end-to-end communication and security models. Other proxy architectures may limit system scalability due to state or performance constraints. There was some desire to conduct further study of proxy agent models to evaluate their effect on system operation.
プロキシエージェントに関する議論は、主にプロキシエージェントタイプの範囲があることを認識しました。プロキシは、プロトコルパケットを傍受および解釈するか、接続のハイジャックまたはリダイレクトによって動作する場合があります。一部のタイプのプロキシは、インターネットのエンドツーエンドのコミュニケーションモデルとセキュリティモデルを破壊します。他のプロキシアーキテクチャは、状態またはパフォーマンスの制約により、システムのスケーラビリティを制限する場合があります。システム操作への影響を評価するために、プロキシエージェントモデルのさらなる研究を実施したいという欲求がいくつかありました。
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年までに1億12億人のセルラー（音声）加入者、インターネット上の6億人の有線ステーション、および6億人以上のワイヤレスデータ（「Webハンドセット」）ユーザーを主張する予測が提示されました。ワイヤレスデータは、歴史がほとんどなく、非常に投機的であるためです。第二に、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 Cellular Network Technologiesの議論に関するほぼすべてのプレゼンテーションで、IPv6プロトコルの採用のためにインターネット担当者による強力な擁護をもたらしました。グループがIPv6の調査を始めたという肯定的な兆候がいくつかありました。たとえば、3GPPは1998年と1999年の仕様（リリースR98およびR99）のオプションとして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プライベートアドレススペース（つまり、「Net 10」ソリューション）を使用するのに十分であると主張しています。
One other area of concern regarding IPv6 usage is perceived memory and processing overhead and its effect on small, limited capability devices. This was primarily directed at IPv6 requirement for IPsec implementation to claim conformance. Arguments that continued increase in device capacity will obviate these concerns were rejected. It was stated that power constraints on these low-end devices will continue to force concerns on memory and processing overhead, and impact introduction of other features. There was no conclusion on whether IPsec could be made optional for these devices, or the effect if these devices were "non-compliant".
IPv6の使用に関するもう1つの懸念事項は、メモリとオーバーヘッドの処理と、小規模で限定された機能デバイスへの影響です。これは主に、IPSECの実装が適合性を請求するためのIPv6要件に向けられていました。デバイス容量の継続的な増加がこれらの懸念を取り除くという議論は拒否されました。これらのローエンドデバイスに対する電力の制約は、メモリとメモリのオーバーヘッドの処理、および他の機能の導入に懸念を強制し続けると述べられました。これらのデバイスでIPSECをオプションにすることができるかどうか、またはこれらのデバイスが「非準拠」である場合の効果について結論はありませんでした。
Emerging 3G cellular networks appear ideal environment for IPv6 introduction. IPv6 addresses scaling requirements of wireless data user projections and eliminates continued cobbling of systems employing (IPv4) private address space and NAT. This appears an area for IAB and Internet community to take a strong stance advocating adoption of IPv6 as the various 3G forums wrestle with their recommendations.
新しい3Gセルラーネットワークは、IPv6の紹介に理想的な環境に見えます。IPv6は、ワイヤレスデータユーザーの投影のスケーリング要件に対処し、（IPv4）プライベートアドレススペースとNATを使用しているシステムの継続的な凝集を排除します。これは、IABとインターネットコミュニティが、さまざまな3Gフォーラムが推奨に取り組んでいるため、IPv6の採用を提唱する強力な姿勢をとる領域のようです。
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ハンドオフ機能の上に構築することです。結論に達したことはありませんでしたが、さらなる調査のための領域のように思われました。
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.
非ITF標準団体が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].
フラストレーションの一般的なテーマの1つは、標準化手順の違いです。たとえば、3GPPは毎年推奨事項を公開する厳格なモデルに従います。確定できない機能はすべて削除する必要があります。一方、IETFワーキンググループのスケジュールははるかに少ないスケジュールであり、実際、公開されたマイルストーンの日付を無視することが多いようです。これは、IETFが[時間通り]を提供できないという他の標準組織内で共通の認識をもたらしました。
A second area identified where IETF differs from other organizations is in publication of "system profile". For example defining interoperation of IPsec, QoS for VoIP and video conferencing, and billing as a "service". Wading through all the protocol specifications, deciding on optional features and piecing together the components to deliver a commercial quality service takes considerable expertise.
IETFが他の組織とは異なる場合、「システムプロファイル」の公開中の2番目の領域が特定されています。たとえば、IPSECの相互操作、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の観点からの主な目標は、技術的または知覚された欠陥の両方の問題についてある程度の理解を深めることであり、この分野でのインターネットプロトコルの採用を阻止することでした。このセクションでは、これらの現在の欠陥に対処し、インターネットテクノロジーの幅広い受け入れを促進するためのIETFのIABおよびIESGによるアクション、IRTFの研究努力、およびプロトコル開発アクションに関するワークショップの勧告を文書化します。
A clear consensus of the workshop is that dialog needs to be improved. The Internet community should attempt to foster communication with other standards bodies, including WAPF, MWIF, 3GPP, 3G.IP, etc. The goal is to "understand each others problems", provide for requirements input, and greater visibility into the standardization process.
ワークショップの明確なコンセンサスは、ダイアログを改善する必要があることです。インターネットコミュニティは、WAPF、MWIF、3GPP、3G.IPなど、他の標準団体とのコミュニケーションを促進しようとする必要があります。目標は、「お互いの問題を理解する」こと、要件の入力を提供し、標準化プロセスへのより大きな可視性を提供することです。
4.1.1
4.1.1
It was recommended to take a pragmatic approach rather than formalizing liaison agreements. The formalized liaison model is counter to the established Internet standards process, is difficult to manage, and has met with very limited success in previous trials. Instead, any relevant IETF working group should be strongly encouraged to consider and recommend potential liaison requirements within their charter.
リエゾン契約を正式にするのではなく、実用的なアプローチをとることをお勧めします。正式なリエゾンモデルは、確立されたインターネット標準プロセスに対抗し、管理が困難であり、以前の試験で非常に限られた成功を収めています。代わりに、関連するIETFワーキンググループは、チャーター内で潜在的なリエゾン要件を検討および推奨することを強く奨励する必要があります。
4.1.2
4.1.2
It was recommended to avoid formation of jointly sponsored working groups and standards. Once again this has shown limited success in the past. The preferred mode of operation is to maintain separate standards organizations but to encourage attendance and participation of external experts within IETF proceedings and to avoid overlap.
共同スポンサーのワーキンググループと標準の形成を避けることをお勧めします。繰り返しになりますが、これは過去に限られた成功を示しています。希望する運用モードは、個別の標準組織を維持することですが、IETFの手続き内の外部専門家の出席と参加を奨励し、重複を避けることです。
An exception to this style of partitioning meeting sponsorship is less formal activities, such as BOFs. It was recommended that sponsoring joint BOF could be beneficial. These could enable assembly of experts from multiple domains early in the process of exploring new topics for future standards activities.
このスタイルの分割会議スポンサーシップの例外は、BOFSなどのより正式な活動ではありません。共同BOFのスポンサーが有益であることが推奨されました。これらは、将来の標準活動のための新しいトピックを調査するプロセスの初期に、複数のドメインからの専門家の集会を可能にする可能性があります。
4.1.3
4.1.3
A principle goal of fostering communication with other standards organizations is mutual education. To help in achieving this goal recommendations were made related to documenting more of the history behind Internet standards and also in coordinating document reviews.
他の標準組織とのコミュニケーションを促進するという主要な目標は、相互教育です。この目標の達成を支援するために、推奨事項は、インターネット標準の背後にある履歴のより多くの文書化と、ドキュメントレビューの調整に関連して行われました。
It was recommended that IETF standards groups be encouraged to create or more formally document the reasons behind algorithm selection and design choices. Currently much of the protocol design history is difficult to extract, in the form of working group mail archives or presentations. Creation of these documents could form the basis to educate newcomers into the "history" and wisdom behind the protocols.
IETF標準グループは、アルゴリズムの選択と設計の選択の背後にある理由を作成するか、より正式に文書化することを奨励することをお勧めしました。現在、プロトコルの設計履歴の多くは、ワーキンググループのメールアーカイブまたはプレゼンテーションの形で抽出することが困難です。これらの文書の作成は、プロトコルの背後にある「歴史」と知恵に新人を教育するための基礎を形成する可能性があります。
It was recommended that mutual document reviews should be encouraged. This helps to disseminate information on current standards activities and provides an opportunity for external expert feedback. A critical hurdle that could severely limit the effectiveness of this type of activity is the intellectual property and distribution restrictions some groups place on their standards and working documents.
相互の文書のレビューを奨励することをお勧めしました。これは、現在の標準活動に関する情報を広めるのに役立ち、外部の専門家フィードバックの機会を提供します。このタイプの活動の有効性を厳しく制限できる重要なハードルは、一部のグループが基準と作業文書に掲載する知的財産と流通の制限です。
There are several perceived benefits to the "walled garden" (captive customer) model, similar to current deployment of "intranets". These range from simplified user security to "captive customer" economic models. There was disagreement on the extent this deployment model might be perpetuated in the future. However it is important to recognize this model exists and to make a conscious decision on how to accommodate it and how it will affect protocol design.
「イントラネット」の現在の展開と同様に、「壁に囲まれた庭」（捕虜の顧客）モデルにはいくつかの利点があります。これらは、単純化されたユーザーセキュリティから、「捕虜の顧客」の経済モデルにまで及びます。この展開モデルが将来永続化される可能性がある範囲について意見の相違はありませんでした。ただし、このモデルが存在することを認識し、それに対応する方法とプロトコルの設計にどのように影響するかについて意識的な決定を下すことが重要です。
4.2.1
4.2.1
It was strongly recommended that independent of the ubiquity of the "walled garden" deployment scenario that protocols and architectural decisions should not target this model. To continue the success of Internet protocols at operating across a highly diverse and heterogeneous environment the IETF must continue to foster the adoption of an "open model". IETF protocol design must address seamless, secure, and scalable access.
プロトコルとアーキテクチャの決定がこのモデルをターゲットにしないでください。IETFは、非常に多様で不均一な環境で動作するインターネットプロトコルの成功を継続するために、「オープンモデル」の採用を促進し続けなければなりません。IETFプロトコル設計は、シームレスで安全な、スケーラブルなアクセスに対処する必要があります。
4.2.2
4.2.2
Recognition that the "walled garden" model has some perceived benefits led to recommendations to better integrate it into the Internet architecture. These focused on service location and escape from the "walled garden".
「壁に囲まれた庭」モデルには、ある程度の利点があるという認識は、インターネットアーキテクチャに適切に統合するための推奨事項につながりました。これらは、サービスの場所に焦点を当て、「壁に囲まれた庭」から逃げました。
It was recommended to investigate standard protocols for service and proxy discovery within the "walled garden" domain. There are already a number of candidate mechanisms, including static preconfiguration, DNS [22,27,44,45], BOOTP [18], DHCP [21], SLP [28], and others. Specific recommendations on use of these protocols in this environment can help foster common discovery methods across a range of access devices and ease configuration complexity.
「壁に囲まれた庭」ドメイン内のサービスおよびプロキシ発見のための標準プロトコルを調査することをお勧めします。静的前構成、DNS [22,27,44,45]、BOOTP [18]、DHCP [21]、SLP [28]などを含む、すでに多くの候補メカニズムがあります。この環境でのこれらのプロトコルの使用に関する特定の推奨事項は、さまざまなアクセスデバイスにわたって一般的な発見方法を促進し、構成の複雑さを容易にするのに役立ちます。
It was recommended to investigate standard methods to transport through the garden wall (e.g., escape to the Internet). It seemed clear that a better model is required than trying to map all access over a HTTP [23] transport connection gateway. One suggestion was to propose use of IP!
庭の壁を通って輸送する標準的な方法を調査することをお勧めします（たとえば、インターネットへの脱出）。HTTP [23] Transport Connection Gatewayを介してすべてのアクセスをマッピングしようとするよりも、より良いモデルが必要であることは明らかでした。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.
ワイヤレスオペレーターは、インターネットベースのサービスで10代から1億人のユーザーのオーダーでサポートを投影しています。この大きさのユーザーをサポートすることは、減少するIPv4アドレス空間の使用に深刻なスケーリングの影響を与える可能性があります。
4.3.1
4.3.1
There was clear consensus that any IPv4-based model relying on traditional stateless NAT technology [60] is to be strongly discouraged. NAT has several inherent faults, including breaking the Internet peer-to-peer communication model, breaking end-to-end security, and stifling deployment of new services [16,29,31]. In addition, the state and performance implications of supporting 10's to 100's million users is cost and technologically prohibitive.
従来のステートレスNATテクノロジー[60]に依存しているIPv4ベースのモデルは、強く落胆するという明確なコンセンサスがありました。NATには、インターネットのピアツーピア通信モデルの破損、エンドツーエンドのセキュリティの壊し、新しいサービスの展開を抑制するなど、いくつかの固有の障害があります[16,29,31]。さらに、10から1億人のユーザーをサポートすることの州とパフォーマンスの意味は、コストと技術的には禁止されています。
4.3.2
4.3.2
Realm specific IP (RSIP) [10,11] has potential to restore the end-to-end communication model in the IPv4 Internet, broken by traditional NAT. However there was considerable reluctance to formally recommend this as the long term solution. Detriments to its adoption include that the protocol is still being researched and defined, and potential interactions with applications, QoS features, and security remain. In addition, added signaling, state, and tunneling has cost and may be technologically prohibitive scaling.
レルム固有のIP（RSIP）[10,11]は、従来のNATによって壊れたIPv4インターネットのエンドツーエンド通信モデルを復元する可能性があります。しかし、これを長期的な解決策として正式に推奨することはかなりの抵抗がありました。採用の欠陥には、プロトコルがまだ研究および定義されていること、およびアプリケーション、QoS機能、およびセキュリティとの潜在的な相互作用が残っていることが含まれます。さらに、追加のシグナル、状態、およびトンネリングにはコストがかかり、技術的には禁止されているスケーリングである可能性があります。
4.3.3
4.3.3
The clear consensus of the workshop was to recommend adoption of an IPv6-based solution to support these services requiring large scaling. Adoption of IPv6 will aid in restoring the Internet end-to-end communication model and eliminates some roaming issues. Adoption of IPv6 in this marketspace could also help spur development of IPv6 products and applications, and hasten transition of the Internet. It was recognized that some application gateways are required during transition of the IPv4 Internet, however it was felt that the scaling and roaming benefits outweighed these issues.
ワークショップの明確なコンセンサスは、IPv6ベースのソリューションの採用を推奨して、大規模なスケーリングを必要とするこれらのサービスをサポートすることでした。IPv6の採用は、インターネットのエンドツーエンド通信モデルの復元に役立ち、いくつかのローミングの問題を排除します。このマーケットスペースでのIPv6の採用は、IPv6製品とアプリケーションの開発を促進し、インターネットの移行を早めるのにも役立ちます。IPv4インターネットの移行中にいくつかのアプリケーションゲートウェイが必要であることが認識されていましたが、スケーリングとローミングの利点がこれらの問題を上回っていると感じられました。
4.3.4
4.3.4
It was recommended that an effort be made to eliminate any requirement for NAT in an IPv6 Internet. The IAB believes that the IPv6 address space is large enough to preclude any requirement for private address allocation [55] or address translation due to address space shortage [15]. Therefore, accomplishing this should primarily require installing and enforcing proper address allocation policy on registry and service providers. It was recommended to establish policies requiring service providers to allocate a sufficient quantity of global addresses for a sites use. The feeling was that NAT should be easily eliminated provided efficient strategies are defined to address renumbering [17,62] and mobility [37] issues.
IPv6インターネットのNATの要件を排除する努力をすることをお勧めしました。IABは、IPv6アドレススペースが、住所スペースの不足[15]によるプライベートアドレスの割り当て[55]または住所変換の要件を排除するのに十分な大きさであると考えています。したがって、これを達成するには、主にレジストリおよびサービスプロバイダーに適切なアドレス割り当てポリシーをインストールおよび実施する必要があります。サービスプロバイダーがサイトの使用に十分な量のグローバルアドレスを割り当てることを要求するポリシーを確立することをお勧めします。NATは、非変更[17,62]およびモビリティ[37]の問題に対処するために、効率的な戦略が定義されている場合、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サービスをモバイルデバイスに押し出すのに役立ちます。
4.4.1
4.4.1
Several limitations were identified relating to current specification of mobile IPv4 [48]. Primary among these limitations is that mechanisms to support redundant home agents and failover are not currently defined. Redundant home agents are required to avoid single point of failure, which would require (proprietary) extensions. Additional deficiencies related to lack of route optimization, and tunneling and path MTU issues were also identified. Due to these limitations there was reluctance to recommend this as a solution.
モバイルIPv4の現在の仕様に関連するいくつかの制限が特定されました[48]。これらの制限の一次は、冗長な在宅エージェントとフェールオーバーをサポートするメカニズムが現在定義されていないことです。冗長なホームエージェントは、単一の障害点を避けるために必要です。これには（独自の）拡張が必要です。ルートの最適化の欠如に関連する追加の欠陥、およびトンネルとパスMTUの問題も特定されました。これらの制限により、これを解決策として推奨することは抵抗がありました。
4.4.2
4.4.2
It was recommended to encourage adoption of IPv6 mobility extensions [37] to support roaming capabilities in the wireless environment. IP mobility over IPv6 incorporates improvements to address several limitations of the IPv4-based mobility. The ability to use autoconfiguration for "care of" address improves robustness and efficiency. Additionally, path MTU is more easily adapted when a router forwards to a new "care of" address.
ワイヤレス環境でのローミング機能をサポートするために、IPv6モビリティエクステンション[37]の採用を奨励することをお勧めします。IPv6を介したIPモビリティには、IPv4ベースのモビリティのいくつかの制限に対処するための改善が組み込まれています。Autoconfigurationを「ケア」アドレスに使用する機能は、堅牢性と効率を向上させます。さらに、パス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 Next Generation Transition（NGTRANS）ワーキンググループの憲章に追加することをお勧めします。
4.4.3
4.4.3
Scalable and widespread authentication, authorization, and accounting (AAA) services are critical to the deployment of commercial services based on (wireless) mobile IP. Some work is progressing on definition of these standards for IP mobility [26,49]. However, due to the pivotal role of these protocols on the ability to deploy commercial services, it was recommended to make finalization of these AAA standards and investigation of AAA scalability as high priorities.
スケーラブルで広範な認証、承認、および会計（AAA）サービスは、（ワイヤレス）モバイルIPに基づく商業サービスの展開に不可欠です。一部の作業は、IPモビリティに関するこれらの標準の定義について進行しています[26,49]。ただし、これらのプロトコルが商業サービスを展開する能力に関する極めて重要な役割により、これらのAAA標準の最終化とAAAスケーラビリティの調査を優先事項として調査することが推奨されました。
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.
ワイヤレス環境とアプリケーションは、輸送プロトコルに追加の要件を掲載しています。一意のリンクエラーとパフォーマンス特性、および接続のセットアップおよびトランザクションセマンティクスに対するアプリケーションの感度により、各環境に固有の「最適化」トランスポートが発生しました。これらの新しい輸送は、インターネット輸送に見られる堅牢性を欠いていることが多く、インターネットへのシームレスなゲートウェイに障壁を置きます。インターネット輸送の進化に関する輸送設計と協力に関するより良い教育は、大幅な改善につながる可能性があると感じられました。
4.5.1
4.5.1
It was recommended that the IETF Transport Area (tsv) working group document why Internet transport protocols are the way they are. The focus should be on generic transport issues and mechanisms, rather than TCP specifics. This should capture usage and tradeoffs in design of specific transport mechanisms (e.g., connection 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の推奨事項を直接サポートしています。さらに、インターネットコミュニティが混雑制御がオプションではないことを非常に明確にすることが重要であると考えられていました。インターネットの研究者は、単一のリンクまたは均質環境の最適化は拡大しないことを学びました。Jacobson [34,35]による初期の研究、TCP輻輳制御の標準化[5]、およびIETFエンドポイント混雑管理（ECM）ワーキンググループ内の継続的な作業は、無線輸送デザイナーの教育に優れた基盤を提供することができます。
4.5.2
4.5.2
It was recommended that the IETF actively solicit input from external standards bodies on identifying explicit requirements and in assessing inefficiencies in existing transports in support of cellular and wireless environments. This has proven highly effective in identifying research topics and in guiding protocol evolution to address new operational environments, for instance in cooperation with groups doing satellite-based internetworking [4,6].
IETFは、明示的な要件を特定し、細胞および無線環境をサポートする既存の輸送の非効率性を評価する際に、外部標準団体からの入力を積極的に求めることをお勧めしました。これは、研究トピックを特定し、たとえば衛星ベースのインターネットワークを行うグループと協力して、新しい運用環境に対処するためのプロトコルの進化を導くのに非常に効果的であることが証明されています[4,6]。
4.5.3
4.5.3
It was recommended that the IAB make wireless standards bodies aware of the existence, and get them active in, the IETF Transport Area (tsv) working group. This transport "catch all" could provide an excellent forum for workers outside the Internet community to propose ideas and requirements, and engage in dialog with IESG members prior to contributing any formal proposal into the IETF or incurring overhead of working group formation.
IABは、ワイヤレス標準団体を存在を認識させ、IETF輸送エリア（TSV）ワーキンググループにアクティブにすることをお勧めしました。このトランスポート「Catch All」は、インターネットコミュニティ以外の労働者がアイデアと要件を提案するための優れたフォーラムを提供し、IETFに正式な提案を提供したり、ワーキンググループ形成のオーバーヘッドを発生させる前にIESGメンバーと対話することができます。
4.5.4
4.5.4
Mobile radio environments may often be subject to frequent temporary outages. For example, roaming through an area that is out of range of any base station, or disruptions due to base station handoffs. This violation of the congestive loss assumption of TCP can have severe detrimental effect on transport performance. It was recommended to investigate mechanisms for improving transport performance when these non-congestive loss can be detected. Areas for potential research identified include incorporation of "hints" to the sender providing Non-Congestive Loss Indication (NCLI) or stimulating transmission after link recovery via Source Encourage (SE) message [39]. This likely falls to the auspice of the IETF Performance Implications of Link Characteristics (pilc) working group.
モバイル無線環境は、多くの場合、頻繁に一時的な停止の対象となる場合があります。たとえば、基地局の範囲外のエリアや、基地局のハンドオフによる混乱をローミングします。TCPのうっ血損失の仮定のこの違反は、輸送パフォーマンスに深刻な有害な影響を与える可能性があります。これらの非同義の損失を検出できる場合、輸送パフォーマンスを改善するためのメカニズムを調査することをお勧めします。特定された潜在的な研究のための領域には、Source Ingisage（SE）メッセージ[39]を介したリンク回復後の非同義損失適応症（NCLI）または刺激伝送を提供する送信者への「ヒント」の組み込みが含まれます[39]。これは、リンク特性（PILC）ワーキンググループのIETFパフォーマンスへの影響の後援に該当する可能性があります。
4.5.5
4.5.5
Many wireless applications require transaction semantics and are highly sensitive to connection establishment delays (e.g., WAP). However, it is still desirable to efficiently support streaming of large bulk transfers too. It was recommended to investigate tradeoffs in supporting these transaction and streaming connections. Potential areas for investigation include tradeoffs between minimal transaction transport and potential security and denial of service (DoS) attacks, mechanisms to piggyback data during connection establishment to eliminate round trip delays, or ways for endpoints to cooperate in eliminating setup handshake for simple transactions while providing switch-over to reliable streaming for bulk transfers.
多くのワイヤレスアプリケーションには、トランザクションセマンティクスが必要であり、接続の確立の遅延（たとえば、WAP）に非常に敏感です。ただし、大きなバルク転送のストリーミングを効率的にサポートすることも依然として望ましいです。これらのトランザクションとストリーミングの接続をサポートするトレードオフを調査することをお勧めします。調査のための潜在的な領域には、最小限のトランザクション輸送と潜在的なセキュリティとサービス拒否（DOS）攻撃のトレードオフ、接続確立中のピギーバックデータのメカニズム、往復の遅延を排除するためのメカニズム、または単純なトランザクションのセットアップハンドシェイクを排除するためのエンドポイントが協力する方法が含まれます。バルク転送用の信頼できるストリーミングへのスイッチ。
4.5.6
4.5.6
It was recommended to look at (TCP) transport improvements specific to the wireless and mobile environment. An example is to investigate reattachable transport endpoints. This could allow for graceful recovery of a transport connection after a roaming or mobility event results in changes to one or both endpoint identifiers. Another area for potential investigation is to develop targeted uses of D-SACK [25]. D-SACK provides additional robustness to reordered packets, which may prove beneficial in wireless environment where packets are occasionally corrupted. Higher performance may be attainable by eliminating requirements on link-level retransmission maintaining in-order delivery within a flow.
ワイヤレスおよびモバイル環境に固有の（TCP）輸送の改善を検討することをお勧めします。例としては、再張り返し可能な輸送エンドポイントを調査することです。これにより、ローミングまたはモビリティイベントが1つまたは両方のエンドポイント識別子に変更されると、輸送接続の優雅な回復が可能になります。潜在的な調査のためのもう1つの領域は、Dサックの標的使用を開発することです[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）と見なす場合、ワイヤレスシステムをサポートするために、一意のルーティング要件が導入される場合があります。
4.6.1
4.6.1
It was recommended that the IETF Routing Area commence investigation of extensions to the BGP protocol [54] to support additional policy features available within the ISO IDRP protocol [33]. The range of policy control desired includes adopting different identity or policies based on current point of attachment, and providing flexibility in path selection based on local policy and/or current peer policy. These features could be used for instance in support of requirements established in the Aeronautical Telecommunication Network (ATN).
IETFルーティング領域は、ISO IDRPプロトコル[33]内で利用可能な追加のポリシー機能をサポートするために、BGPプロトコルへの拡張の調査を開始することをお勧めしました[54]。希望するポリシー管理の範囲には、現在の添付ファイルのポイントに基づいてさまざまな身元またはポリシーを採用し、ローカルポリシーおよび/または現在のピアポリシーに基づくパス選択の柔軟性を提供することが含まれます。これらの機能は、たとえば、航空通信ネットワーク（ATN）で確立された要件をサポートするために使用できます。
4.6.2
4.6.2
It was recommended that the IETF Routing Area commence investigation of extensions to the BGP protocol [54] to support additional QoS/TOS path selection features available within the ISO IDRP protocol [33]. The range of policies include differentiating service level or path selection based on traffic classes. An example, based on Aeronautical Telecommunication Network (ATN) requirements, might be differentiating path selection and service between airline control and passenger entertainment traffic.
IETFルーティング領域は、ISO IDRPプロトコル[33]内で利用可能な追加のQOS/TOSパス選択機能をサポートするために、BGPプロトコルへの拡張の調査を開始することをお勧めしました[54]。ポリシーの範囲には、トラフィッククラスに基づいたサービスレベルまたはパス選択の差別化が含まれます。航空通信ネットワーク（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ニーズを満たすには、モバイルホストのローミングの性質に加えて、これらのリンク特性に対応する必要があります。リンクとエンドツーエンドのパフォーマンスの制約の両方を満たすために、ネットワークレイヤーから専門的なサポートが必要になる場合があります。
4.7.1
4.7.1
It was recommended that the IETF Transport Area undertake investigation into providing QoS in the last leg of mobile systems. That is, between the mobile device and the network access point. This type of QoS support might be appropriate where the wireless link is the most constrained resource. A potential solution to investigate is to employ an explicit reservation mechanism between the mobile host and the access point (e.g., RSVP [13]), while relying on resource provisioning or more scalable DiffServ [9] technologies within the core.
IETF輸送エリアは、モバイルシステムの最後のレッグでQoSを提供することを調査することをお勧めしました。つまり、モバイルデバイスとネットワークアクセスポイントの間です。このタイプのQoSサポートは、ワイヤレスリンクが最も制約されたリソースである場合に適切かもしれません。調査する潜在的な解決策は、モバイルホストとアクセスポイント（例：RSVP [13]）の間に明示的な予約メカニズムを採用することですが、コア内のリソースプロビジョニングまたはよりスケーラブルなDiffserv [9]テクノロジーに依存しています。
4.7.2
4.7.2
It was recommended that the IETF Transport Area undertake investigation into end-to-end QoS when the path includes a mixture of wireless and wired technologies. This investigation could focus on mechanism to communicate QoS characteristics in cellular network to the core network to establish end-to-end QoS guarantees. An alternative investigation is to look into discovery problem of assessing current end-to-end performance characteristics, enabling for dynamic adaptation by mobile host.
パスにワイヤレス技術と有線技術の混合物が含まれている場合、IETF輸送エリアはエンドツーエンド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がこのレベルでアプリケーションのモビリティを調査することをお勧めしました。目標は、切断期間後にスムーズな回復を達成することです。「リダイアル」よりも優雅なもの。現在、ネットワークスタック内で十分な情報が利用可能ではないようです。これには、何らかの形の「セッション」レイヤーのインスタンス化が必要になる場合があります。
WAPF has gone to considerable effort to develop unique transport protocol and optimizations due to perception that TCP/IP protocol stack is too expensive. Much of this was predicated on WAP requirements to support very low datarate bearer services. It was recommended that members of the IRTF evaluate TCP/IP stack performance in WAP-like environment to quantify its behavior and applicability. The focus should include investigation of code and memory space requirements, as well as link usage to complete a single transaction for current WAP protocols and for both IPv4 and IPv6. This work should result in better characterization of TCP/IP performance in highly constrained devices and network, recommendations to the IETF on protocol enhancements to optimize performance in this environment, and recommendations to WAPF on suitability of deploying native IP protocols.
WAPFは、TCP/IPプロトコルスタックが高すぎるという認識のため、ユニークな輸送プロトコルと最適化を開発するためにかなりの努力を払ってきました。これの多くは、非常に低いDatarate BearerサービスをサポートするためのWAP要件に基づいていました。IRTFのメンバーは、WAPのような環境でTCP/IPスタックのパフォーマンスを評価して、その動作と適用性を定量化することをお勧めしました。焦点には、コードとメモリスペースの要件の調査、およびリンクの使用状況と、現在のWAPプロトコルとIPv4とIPv6の両方の単一のトランザクションを完了する必要があります。この作業により、高度に制約されたデバイスとネットワークでのTCP/IPパフォーマンスのより良い特性評価、この環境でのパフォーマンスを最適化するためのプロトコル拡張に関するIETFへの推奨、およびネイティブIPプロトコルの展開の適合性に関するWAPFへの推奨事項が得られるはずです。
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プロトコルとデバイスは、もともと狭いアプリケーションスペース用に最適化されていました。ただし、プロトコルとデバイスのアクセスを拡張できる幅を探ることに関心があります。関心のある特定の領域の1つは、インターネットへのアクセスへの統合またはゲートウェイの統合を調査することです。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.
プロキシエージェントは、プロトコル要求（例：Webキャッシュ、HTTPリダイレクター、フィルタリングファイアウォール）を傍受および評価するために、または通信ドメイン間のゲートウェイアクセス（たとえば、プライベートネットワークとインターネットまたはインターネット間のインターネットまたはインターネット間のゲートウェイを移動するために展開されることがよくあります。）。これらのプロキシエージェントの1つの開発と展開を検討する際に、多くの潜在的なアーキテクチャがあります。IRTFのメンバーがプロキシアーキテクチャの分類法を調査し、その特性と適用性を評価することをお勧めしました。プロキシの各タイプは、たとえば、インターネットエンドツーエンドモデル、セキュリティ、スケーリング、パフォーマンスへの影響に対する影響によって特徴付けられる必要があります。この調査の結果は、利用可能なプロキシの範囲について開発者とネットワークオペレーターを教育するのに役立ち、インターネットプロトコルを最も破壊しないソリューションを推奨します。
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およびCalhounによるプレゼンテーションは、現在展開されているセルラーネットワークのセキュリティメカニズムと3GセルラーおよびIPネットワークへの進化に焦点を当てています。「壁に囲まれた庭」サービスモデルに関する議論（セクション3.1を参照）は、セキュリティ要件の簡素化に関する効果について簡単に言及しています。セクション3.3では、ワイヤレスデバイスとモビリティに関連する多くのセキュリティ問題を提起します。これらには、ユーザーのアイデンティティと機能を確立するための代替案、攻撃からのネットワークインフラストラクチャの保護、およびモバイルIPおよびAAA操作に必要なセキュリティ関連が含まれます。セクション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.
著者は、このドキュメントの書き込み中のフィードバック、励まし、忍耐について、すべてのワークショップ参加者に感謝したいと思います。特に、ドキュメントの組織とコンテンツに関する質問に対する迅速な回答について、ブライアンカーペンターに感謝したいと思います。同様に、チャーリーパーキンスは、レポート全体で声明を劇的に改善および修正した広範なフィードバックを提供しました。最後に、Mikael Degermark、Sally Floyd、Heikki Hammainen、Geoff Huston、およびGabriel Montenegroが質問へのコメントと回答を提供しました。
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ペーシングのパフォーマンスを理解する。IEEE INFOCOM 2000、2000年3月の議事録。
[3] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[3] Allman、M.、Floyd、S。、およびC. Partridge、「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] Allman、M.、Glover、D。、およびL. Sanchez、「標準メカニズムを使用した衛星チャネル上のTCPの強化」、RFC 2488、1999年1月。
[5] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[5] Allman、M.、Paxson、V。and W. Stevens、「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] Allman、M.、Dawkins、S.、Glover、D.、Griner、J.、Tran、D.、Henderson、T.、Heidemann、J.、Touch、J.、Kruse、H.、Ostermann、S.、Scott、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] Bates、T.、Chandra、R.、Katz、D。およびY. Rekhter、「BGP-4のマルチプロトコル拡張」、RFC 2283、1998年2月。
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services" RFC 2475, December 1998.
[9] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」RFC 2475、1998年12月。
[10] Borella, M., et al., "Realm Specific IP: Framework", Work in Progress.
[10] Borella、M.、et al。、「Realm固有のIP：フレームワーク」、進行中の作業。
[11] Borella, M., et al., "Realm Specific IP: Protocol Specification", Work in Progress.
[11] Borella、M.、et al。、「Realm固有のIP：プロトコル仕様」、作業進行中。
[12] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[12] Braden、R。、「T/TCP -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] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（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] Brim、S.、Carpenter、B。and F. Le Faucheur、「Per Hopの動作識別コード」、RFC 2836、2000年5月。
[15] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[15] Carpenter、B.、Crowcroft、J。and Y. Rekhter、「IPv4アドレスToday」、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] Crawford、M。、「IPv6の名変更」、RFC 2894、2000年8月。
[18] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985.
[18] Croft、B。およびJ. Gilmore、「Bootstrap Protocol（BOOTP）」、RFC 951、1985年9月。
[19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[19] Deering、S。and 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] Dierks、T。およびC. Allen、「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] Everhart、C.、Mamakos、L.、Ullman、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-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] Floyd、S。およびT. Henderson、「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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「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] Glass、S.、Hiller、T.、Jacobs、S.およびC. Perkins、「モバイル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 RR（DNS SRV）」、RFC 2052、1996年10月。
[28] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[28] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「Service Location Protocol、Version 2」、RFC 2608、1999年6月。
[29] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[29] Hain、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] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
[31] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", Work in Progress.
[31] Holdrege、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の転送をサポートするために、中間システム間のドメイン間ルーティング情報の交換のためのプロトコル。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.ジェイコブソン。混雑の回避と制御。コンピューター通信レビュー、Vol。18、いいえ。1988年8月4日。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-Interestメーリングリスト、1990年4月30日。ftp：//ftp.isi.edu/end2end/end2end-interest-1990.mail。
[36] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[36] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のためのTCP拡張」、RFC 1323、1992年5月。
[37] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[37] Johnson、D。およびC. Perkins、「IPv6のモビリティサポート」、進行中の作業。
[38] Jonsson, L., et al., "RObust Checksum-based header COmpression (ROCCO)", Work in Progress.
[38] Jonsson、L.、et al。、「堅牢なチェックサムベースのヘッダー圧縮（Rocco）」、Work in Progress。
[39] Karn, P., et al., "Advice for Internet Subnetwork Designers", Work in Progress.
[39] Karn、P.、et al。、「インターネットサブネットワークデザイナーへのアドバイス」、進行中の作業。
[40] King, S., et al., "The Case for IPv6", Work in Progress.
[40] King、S.、et al。、「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. Kulik、R。Coulter、D。Rockwell、およびC. Partridge。高遅延帯域幅ネットワーク用のペースTCP。IEEE Globecom '99の議事録、1999年12月。
[42] Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time Multimedia", Work in Progress.
[42] Le、K.、et al。、「リアルタイムマルチメディア用の適応ヘッダー圧縮（ACE）」、作業進行中。
[43] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[43] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Auncoundage Options」、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] Nichols、K.、Blake、S.、Baker、F。and D. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[47] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[47] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycciding Service」、RFC 1546、1993年11月。
[48] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[48] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[49] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile IP", Work in Progress.
[49] Perkins、C。およびP. Calhoun、「モバイルIPのAAA登録キー」、進行中の作業。
[50] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", Work in Progress.
[50] Perkins、C。およびD. Johnson、「モバイルIPのルート最適化」は、進行中の作業です。
[51] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[51] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[52] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[52] Postel、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] Ramakrishnan、K。およびS. Floyd、「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. Li、「ボーダーゲートウェイプロトコル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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス割り当て」、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.、Rubens、A.、Simpson、W。and S. Willens、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2138、1997年4月。
[57] Schulzrinne, H., Casner, S., Fredrick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[57] Schulzrinne、H.、Casner、S.、Fredrick、R。and 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. Mathis。自動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. Holdrege、「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] 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、2000年10月。
[62] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[62] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[63] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[63] Touch、J。、「TCP制御ブロック相互依存」、RFC 2140、1997年4月。
[64] Vollbrecht, J., et al., "AAA Authorization Framework", Work in Progress.
[64] Vollbrecht、J.、et al。、「AAA Authorization Framework」、作業進行中。
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
Danny J. Mitzel Nokia 313 Fairchild Drive Mountain View、CA 94043 USA
Phone: +1 650 625 2037
EMail: mitzel@iprg.nokia.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。