diff options
Diffstat (limited to 'doc/rfc/rfc3002.txt')
| -rw-r--r-- | doc/rfc/rfc3002.txt | 2355 |
1 files changed, 2355 insertions, 0 deletions
diff --git a/doc/rfc/rfc3002.txt b/doc/rfc/rfc3002.txt new file mode 100644 index 0000000..023f75c --- /dev/null +++ b/doc/rfc/rfc3002.txt @@ -0,0 +1,2355 @@ + + + + + + +Network Working Group D. Mitzel +Request for Comments: 3002 Nokia +Category: Informational December 2000 + + + Overview of 2000 IAB Wireless Internetworking Workshop + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +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. + + Comments should be submitted to the IAB-Wireless-Workshop@ietf.org + mailing list. + +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 + + + +Mitzel Informational [Page 1] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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 + + + + + + + + +Mitzel Informational [Page 2] + +RFC 3002 IAB Wireless Workshop December 2000 + + +1 Introduction + + 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. + + 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. + + 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. + + The following topics were defined for discussion: + + + Local area wireless technologies + + + Cellular wireless technologies + + + Wireless Application Protocol (WAP) + + + Near-space and aviation wireless applications + + + Voice over IP (VoIP) over wireless networks + + + Security over wireless networks + + + Transport and QoS over wireless networks + + + Use of WWW protocols over wireless and small screen devices + + + +Mitzel Informational [Page 3] + +RFC 3002 IAB Wireless Workshop December 2000 + + + + 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. + + 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 Presentation Overview + + Title: Overview of Wireless IP Devices (Network Implications...) + + Presenter: 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 + + Overview: + + Title: Overview of IEEE 802.11 Wireless LAN's & Issues Running IP + over IEEE 802.11? + + Presenter: Juha Ala-Laurila + + Reference: + http://www.iab.org/IAB-wireless-work- + shop/talks/IEEE80211_IP.ppt + + Overview: + + + + + +Mitzel Informational [Page 4] + +RFC 3002 IAB Wireless Workshop December 2000 + + + Title: Overview of Bluetooth Wireless & Issues Running IP over + Bluetooth? + + Presenter: 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 + + Overview: + + Title: Overview of Cellular Data Systems & Approaches to more IP + centric Cellular Data System + + Presenter: 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 + + Overview: + + Title: IP Packet Data Service over IS-95 CDMA + + Presenter: Phil Karn + + Reference: + http://www.iab.org/IAB-wireless-workshop/talks/karn/index.htm + + Overview: + + Title: Wireless Internet Networking + + Presenter: Chih-Lin I + + Reference: + 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 + + Presenter: Charlie Perkins + + + +Mitzel Informational [Page 5] + +RFC 3002 IAB Wireless Workshop December 2000 + + + Reference: + 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 + + Presenter: Alastair Angwin + + Reference: + http://www.iab.org/IAB-wireless-workshop/talks/iab-wap-1.pdf + + Overview: + + Title: Mobile Wireless Internet Forum (MWIF) + + Presenter: Alastair Angwin + + Reference: + http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC + _Presentation.PDF, + http://www.iab.org/IAB-wireless-workshop/talks/MWIF_TC + _Presentation.ppt + + Overview: + + Title: Some WAP History + + Presenter: Jerry Lahti + + Reference: + 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 + + Overview: + + + +Mitzel Informational [Page 6] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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 + + Overview: + + Title: 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 + + Overview: + + Title: Security Issues in Wireless Networks and Mobile Computing + + Presenter: 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 + + Overview: + + Title: Security for Mobile IP in 3G Networks + + 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 + + Overview: + + Title: On Inter-layer Assumptions (A View from the Transport Area) + + Presenter: Mark Handley + + + + +Mitzel Informational [Page 7] + +RFC 3002 IAB Wireless Workshop December 2000 + + + Reference: + 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 + + Overview: + + Title: 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 + + Overview: + + Title: Do current WWW Protocols work over Wireless and Small + Screen Devices? + + Presenter: Gabriel Montenegro + + Reference: + http://www.iab.org/IAB-wireless-workshop/talks/wireless- + www.PDF, + http://www.iab.org/IAB-wireless-workshop/talks/wireless- + www.ppt + + Overview: + + Title: Compression & Bit Error Requirements for Wireless + + Presenter: Mikael Degermark + + + +Mitzel Informational [Page 8] + +RFC 3002 IAB Wireless Workshop December 2000 + + + Reference: + 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 + + 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 + + Overview: + +3 Discussion and Observations + + 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 Discussion on "Walled Garden" Service Model + + 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". + + + + +Mitzel Informational [Page 9] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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"). + +3.2 Discussion on Mobility and Roaming + + 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. + + + + + + + +Mitzel Informational [Page 10] + +RFC 3002 IAB Wireless Workshop December 2000 + + +3.2.1 Discussion on Mobility and Roaming Model + + 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. + + 3G.IP uses the term "macro mobility" to describe this mode. + + The discussion attempted to discern whether the current mode of usage + is a perceived limitation introduced by current protocols. A clear + consensus could not be achieved. There was agreement that + introduction of this "macro mobility" roaming is a worthwhile first + step. However, that was immediately followed by questions on whether + it is a sufficient first step, and warning not to stop at this level. + There seems significant issues for continued investigation related to + enabling continual usage of a device during roaming ("micro + mobility") and the ability to retrieve previous connections after a + roaming event. + +3.2.2 Discussion on Mobility and Roaming Protocols + + 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. + + 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. + + 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. + + + + +Mitzel Informational [Page 11] + +RFC 3002 IAB Wireless Workshop December 2000 + + +3.2.3 Discussion on Mobility and Roaming Services + + 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. + + 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. + + This exchange illustrated the disconnect between interpreting + Internet standards and telephony service profiles. First, in the + Internet many protocols are defined but many are optional. Protocol + support is typically driven by market demand, which can lead to + "chicken and egg" problem. Secondly, individual protocols and + applications are developed rather than complete profile to compose a + commercial service. For this service, evaluating the usage and + scalability of service discovery protocols appears to be an area open + for further investigation. + +3.3 Discussion on Security Model + + 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. + +3.3.1 Discussion on User Identity + + 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. + + + +Mitzel Informational [Page 12] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + +3.3.2 Discussion on WAP Security + + 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. + + 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. + +3.3.3 Discussion on 3G Network Security + + 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. + + + + + + +Mitzel Informational [Page 13] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + +3.4 Discussion on Transports + + 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. + +3.4.1 Discussion on Link Characteristics and Mobility Effect on + Transport + + 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 + + + +Mitzel Informational [Page 14] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + + 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). + + 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 + + + +Mitzel Informational [Page 15] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + +3.4.2. Discussion on WAP Transport + + 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. + + 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. + + 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.). + +3.4.3 Discussion on IETF Transport Activities + + 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 + + + +Mitzel Informational [Page 16] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + +3.5 Discussion on Aeronautical Telecommunication Network (ATN) Routing + Policy + + 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. + + 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 + + + +Mitzel Informational [Page 17] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + +3.6 Discussion on QoS Services + + 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. + + 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. + +3.6.1 Discussion on "Last Leg" 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 + + + +Mitzel Informational [Page 18] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + + 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. + +3.6.2 Discussion on Path QoS Discovery + + 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. + + 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. + + 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 + + + +Mitzel Informational [Page 19] + +RFC 3002 IAB Wireless Workshop December 2000 + + + alternative is to push capability exchange and negotiation to the + application layer. Discussion on this topic was brief, as + application issues were deemed outside the workshop charter, however + this also seems an area open for future investigation. + +3.7 Discussion on Header Compression + + 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. + + 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). + + 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. + + 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. + + 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 + + + +Mitzel Informational [Page 20] + +RFC 3002 IAB Wireless Workshop December 2000 + + + Bellovin's TCP filters. Observation was made that it could be + beneficial to investigate more compact alternative encoding of the + WWW protocols. + +3.8 Discussion on Applications Protocols + + 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. + + 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. + + 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. + + Finally, work within the near-space satellite environment has pointed + out other physical limitations that can affect performance. In this + case the long propagation delays can make "chatty" protocols highly + inefficient and unbearable for interactive use. This environment + could benefit from protocols that support some form of "pipelining" + operation. + + There seemed broad agreement that many of these observations + represent valid reasons to pursue optimization of protocol + operations. Investigation of compact protocol encoding, capability + negotiation, and minimizing or overlapping round trips to complete a + transaction could all lead to improved application performance across + a wide range of environments. + + + + + + + +Mitzel Informational [Page 21] + +RFC 3002 IAB Wireless Workshop December 2000 + + +3.9 Discussion on Proxy Agents + + 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). + + The discussion on proxy agents primarily recognized that there are a + range of proxy agent types. Proxies may operate by intercepting and + interpreting protocol packets, or by hijacking or redirecting + connections. Some types of proxy break the Internet end-to-end + communication and security models. Other proxy architectures may + limit system scalability due to state or performance constraints. + There was some desire to conduct further study of proxy agent models + to evaluate their effect on system operation. + +3.10 Discussion on Adoption of IPv6 + + 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. + + 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 + + + + +Mitzel Informational [Page 22] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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). + + 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". + + 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. + +3.11 Discussion on Signaling + + 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 + + + +Mitzel Informational [Page 23] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + + 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. + +3.12 Discussion on Interactions Between IETF and Other Standards + Organizations + + 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. + + 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]. + + 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. + + 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. + + + + +Mitzel Informational [Page 24] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + +4 Recommendations + + 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. + +4.1 Recommendations on Fostering Interaction with Non-Internet Standards + Organizations + + 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. + +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. + +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. + + + +Mitzel Informational [Page 25] + +RFC 3002 IAB Wireless Workshop December 2000 + + + 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. + +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. + + It was recommended that mutual document reviews should be encouraged. + This helps to disseminate information on current standards activities + and provides an opportunity for external expert feedback. A critical + hurdle that could severely limit the effectiveness of this type of + activity is the intellectual property and distribution restrictions + some groups place on their standards and working documents. + +4.2 Recommendations for Dealing with "Walled Garden" Model + + 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 + + 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. + + + + + +Mitzel Informational [Page 26] + +RFC 3002 IAB Wireless Workshop December 2000 + + +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. + + 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! + +4.3 Recommendations on IPv4 and IPv6 Scaling + + 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. + +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. + +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. + + + +Mitzel Informational [Page 27] + +RFC 3002 IAB Wireless Workshop December 2000 + + +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. + +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. + +4.4 Recommendations on IPv4 and IPv6 Mobility + + 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. + +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. + + + + + + + +Mitzel Informational [Page 28] + +RFC 3002 IAB Wireless Workshop December 2000 + + +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. + + 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. + +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. + +4.5 Recommendations on TCP and Transport Protocols + + 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 + + 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 + + + + + +Mitzel Informational [Page 29] + +RFC 3002 IAB Wireless Workshop December 2000 + + + establishment, congestion control, loss recovery strategies, etc.), + and document some of the history behind transport research in the + Internet. + + This "entry point" document into transport design is in direct + support of the recommendations in section 4.1 to foster communication + and mutual education. In addition it was deemed critical that the + Internet community make it very clear that congestion control is not + optional. Internet researchers have learned that optimizing for a + single link or homogeneous environment does not scale. Early work by + Jacobson [34,35], standardization of TCP congestion control [5], and + continuing work within the IETF Endpoint Congestion Management (ecm) + working group could provide excellent basis for education of wireless + transport designers. + +4.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]. + +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. + +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 + + + + +Mitzel Informational [Page 30] + +RFC 3002 IAB Wireless Workshop December 2000 + + + (SE) message [39]. This likely falls to the auspice of the IETF + Performance Implications of Link Characteristics (pilc) working + group. + +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. + +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. + +4.6 Recommendations on Routing + + Unique routing requirements may be introduced in support of wireless + systems, especially when viewing the mobile component as an + autonomous system (AS). + +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 + + + + + +Mitzel Informational [Page 31] + +RFC 3002 IAB Wireless Workshop December 2000 + + + peer policy. These features could be used for instance in support of + requirements established in the Aeronautical Telecommunication + Network (ATN). + +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. + +4.7 Recommendations on Mobile Host QoS Support + + 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. + +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. + +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. + + + + + +Mitzel Informational [Page 32] + +RFC 3002 IAB Wireless Workshop December 2000 + + +4.8 Recommendations on Application Mobility + + 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. + +4.9 Recommendations on TCP/IP Performance Characterization in WAP-like + Environment + + 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. + +4.10 Recommendations on Protocol Encoding + + 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. + + + + + + + + +Mitzel Informational [Page 33] + +RFC 3002 IAB Wireless Workshop December 2000 + + +4.11 Recommendations on Inter-Domain AAA Services + + 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. + +4.12 Recommendations on Bluetooth + + 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. + +4.13 Recommendations on Proxy Architecture + + 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. + + + + + + + + +Mitzel Informational [Page 34] + +RFC 3002 IAB Wireless Workshop December 2000 + + +4.14 Recommendations on Justifying IPv6-based Solutions for Mobile / + Wireless Internet + + 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. + +5 Security Considerations + + 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. + +6 Acknowledgments + + 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. + + + + +Mitzel Informational [Page 35] + +RFC 3002 IAB Wireless Workshop December 2000 + + +7 Bibliography + + [1] ACIRI. TCP-Friendly Rate Control. 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. + + [3] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's + Initial Window", RFC 2414, September 1998. + + [4] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over + Satellite Channels using Standard Mechanisms", RFC 2488, + January 1999. + + [5] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", + RFC 2581, April 1999. + + [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. + + [7] Arkko, J., "Requirements for Internet-Scale Accounting + Management", Work in Progress. + + [8] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol + Extensions for BGP-4", RFC 2283, February 1998. + + [9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. + Weiss, "An Architecture for Differentiated Services" RFC 2475, + December 1998. + + [10] Borella, M., et al., "Realm Specific IP: Framework", Work in + Progress. + + [11] Borella, M., et al., "Realm Specific IP: Protocol + Specification", Work in Progress. + + [12] Braden, R., "T/TCP -- TCP Extensions for Transactions Functional + Specification", RFC 1644, July 1994. + + [13] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, + "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional + Specification", RFC 2205, September 1997. + + [14] Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior + Identification Codes", RFC 2836, May 2000. + + + +Mitzel Informational [Page 36] + +RFC 3002 IAB Wireless Workshop December 2000 + + + [15] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address + Behaviour Today", RFC 2101, February 1997. + + [16] Carpenter, B., "Internet Transparency", RFC 2775, February 2000. + + [17] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August + 2000. + + [18] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, + September 1985. + + [19] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [20] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [21] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + March 1997. + + [22] Everhart, C., Mamakos, L., Ullman, R. and P. Mockapetris, "New + DNS RR Definitions", RFC 1183, October 1990. + + [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. + + [24] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's + Fast Recovery Algorithm", RFC 2582, April 1999. + + [25] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An + Extension to the Selective Acknowledgment (SACK) Option for + TCP", RFC 2883, July 2000. + + [26] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IP + Authentication, Authorization, and Accounting Requirements", RFC + 2977, October 2000. + + [27] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the + location of services (DNS SRV)", RFC 2052, October 1996. + + [28] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service + Location Protocol, Version 2", RFC 2608, June 1999. + + [29] Hain, T., "Architectural Implications of NAT", RFC 2993, + November 2000. + + + + + +Mitzel Informational [Page 37] + +RFC 3002 IAB Wireless Workshop December 2000 + + + [30] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [31] Holdrege, M. and P. Srisuresh, "Protocol Complications with the + IP Network Address Translator (NAT)", Work in Progress. + + [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. + + [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. + + [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. + + [35] V. Jacobson. Modified TCP Congestion Avoidance Algorithm. + end2end-interest mailing list, April 30, 1990. + ftp://ftp.isi.edu/end2end/end2end-interest-1990.mail. + + [36] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High + Performance", RFC 1323, May 1992. + + [37] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in + Progress. + + [38] Jonsson, L., et al., "RObust Checksum-based header COmpression + (ROCCO)", Work in Progress. + + [39] Karn, P., et al., "Advice for Internet Subnetwork Designers", + Work in Progress. + + [40] King, S., et al., "The Case for IPv6", Work in Progress. + + [41] J. Kulik, R. Coulter, D. Rockwell, and C. Partridge. Paced TCP + for High Delay-Bandwidth Networks. Proceedings of IEEE Globecom + '99, December 1999. + + [42] Le, K., et al., "Adaptive Header ComprEssion (ACE) for Real-Time + Multimedia", Work in Progress. + + [43] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, October 1996. + + + + + + +Mitzel Informational [Page 38] + +RFC 3002 IAB Wireless Workshop December 2000 + + + [44] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD + 13, RFC 1034, November 1987. + + [45] Mockapetris, P., "Domain Names -- Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [46] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of + the Differentiated Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. + + [47] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting + Service", RFC 1546, November 1993. + + [48] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. + + [49] Perkins, C. and P. Calhoun, "AAA Registration Keys for Mobile + IP", Work in Progress. + + [50] Perkins, C. and D. Johnson, "Route Optimization in Mobile IP", + Work in Progress. + + [51] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August + 1980. + + [52] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. + + [53] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit + Congestion Notification (ECN) to IP", RFC 2481, January 1999. + + [54] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", + RFC 1771, March 1995. + + [55] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. + Lear, "Address Allocation for Private Internets", BCP 5, RFC + 1918, February 1996. + + [56] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2138, April + 1997. + + [57] Schulzrinne, H., Casner, S., Fredrick, R. and V. Jacobson, "RTP: + A Transport Protocol for Real-Time Applications", RFC 1889, + January 1996. + + [58] J. Semke, J. Mahdavi, and M. Mathis. Automatic TCP Buffer + Tuning. Proceedings of ACM SIGCOMM '98, September 1998. + + + + + +Mitzel Informational [Page 39] + +RFC 3002 IAB Wireless Workshop December 2000 + + + [59] Srisuresh, P. and M. Holdrege, "IP Network Address Translator + (NAT) Terminology and Considerations", RFC 2663, August 1999. + + [60] Srisuresh, P. and K. Egevang, "Traditional IP Network Address + Translator (Traditional NAT)", Work in Progress. + + [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. + + [62] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [63] Touch, J., "TCP Control Block Interdependence", RFC 2140, April + 1997. + + [64] Vollbrecht, J., et al., "AAA Authorization Framework", Work in + Progress. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mitzel Informational [Page 40] + +RFC 3002 IAB Wireless Workshop December 2000 + + +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 + + Danny J. Mitzel + Nokia + 313 Fairchild Drive + Mountain View, CA 94043 + USA + + Phone: +1 650 625 2037 + EMail: mitzel@iprg.nokia.com + + + + + + +Mitzel Informational [Page 41] + +RFC 3002 IAB Wireless Workshop December 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + 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. + + + + + + + + + + + + + + + + + + + +Mitzel Informational [Page 42] + |