Control and Provisioning of H. Cheng Wireless Access Points PSL Internet-Draft S. Iino Expires: January 16, 2005 PMC S. Govindan PSL July 18, 2004 Functionality Classifications for Control and Provisioning of Wireless Access Points (CAPWAP) draft-cheng-capwap-classifications-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes classifications for wireless local area network (WLAN) functionality. The main benefit of a consistent system of classification is accommodating the diversity of WLAN designs as seen in the Control and Provisioning of Wireless Access Points framework. This draft describes policies with which classifications may be used. The document analyzes various WLAN architectures and recent standardization efforts to derive key Cheng, et al. Expires January 16, 2005 [Page 1] Internet-Draft Functional Classifications July 2004 requirements for a CAPWAP WLAN protocol. It is envisioned that protocol development based on these requirements will enable interoperability among the various WLAN designs. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. WLAN Functionality Classifications . . . . . . . . . . . . . . 4 2.1 Policies for Adaptive CAPWAP Interfaces . . . . . . . . . 5 3. Scenarios for CAPWAP . . . . . . . . . . . . . . . . . . . . . 9 3.1 WLAN with Heterogeneous Elements . . . . . . . . . . . . . 9 3.2 Sharing of WLAN Infrastructure . . . . . . . . . . . . . . 9 3.3 Multiple Authentication Mechanisms . . . . . . . . . . . . 9 3.4 Data and Control Separation . . . . . . . . . . . . . . . 9 3.5 Dynamic Topologies . . . . . . . . . . . . . . . . . . . . 10 3.6 Failover Support . . . . . . . . . . . . . . . . . . . . . 10 4. CAPWAP Requirements . . . . . . . . . . . . . . . . . . . . . 11 4.1 Adaptive CAPWAP Interfaces . . . . . . . . . . . . . . . . 11 4.2 Secure Aggregations in Shared WLAN Infrastructures . . . . 11 4.3 Multiple Authentications Support . . . . . . . . . . . . . 11 4.4 Data and Control Channel Separation . . . . . . . . . . . 11 4.5 Dynamic WLAN Topologies . . . . . . . . . . . . . . . . . 11 4.6 Failover Support . . . . . . . . . . . . . . . . . . . . . 12 4.7 CAPWAP Design Aspects . . . . . . . . . . . . . . . . . . 12 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Shared WLAN Infrastrucuture . . . . . . . . . . . . . . . . . 15 B. Channel Separation . . . . . . . . . . . . . . . . . . . . . . 16 C. Dynamic Topologies . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Cheng, et al. Expires January 16, 2005 [Page 2] Internet-Draft Functional Classifications July 2004 1. Introduction The wide-spread adoption of wireless local area networks (WLANs) has resulted in tremendous benefits for both consumers and the industry at large. Productivity gains from inexpensive, easy-to-deploy WLANs have fueled growth and development of WLAN equipment and services which in turn have attracted more consumers and large enterprises. Naturally, such upbeat conditions have encouraged the participation of a large number of designers and manufacturers in furthering WLAN developments. Although these advancements are based on the standard IEEE 802.11 specifications [IEEE802-11] and individually beneficial, when put together however they present a host of incompatibilities that ultimately affect the end market. In particular, the Architecture Taxonomy [I-D.ietf-capwap-arch] illustrates the diversity of WLAN designs currently available in the market. In addition to the three broad WLAN architectures ‚Ητ autonomous, centralized and distributed ‚Ητ there are also local MAC, split MAC and remote MAC variations of the centralized architecture. The architectures and their variations are unique in their characteristics and operational advantages. For example, the autonomous architecture enables highly secure operations due to its tight integration of control and WLAN functions. On the other hand, the centralization of key functions in the split MAC model allows for cost-effective WLAN deployments. It is evident that each of the WLAN designs offers distinct capabilities and advantages. In order to deliver these benefits to consumers and enterprises, there is a pressing need to accommodate such diversity in an integrated Control and Provisioning of Wireless Access Points (CAPWAP) framework. Fundamental to this is the establishment of consistent classifications for the functions that comprise WLAN operations and management. Furthermore, it is important to establish a common yardstick with which CAPWAP efforts, and particularly draft protocols, may be measured. This document is intended to address these issues by way of detailing specific requirements for a CAPWAP standard. Specifically, Section 2 presents the requirement for enabling different split architectures within a single WLAN. As a precursor, the case for consistent classifications of WLAN functions is made. Next, in Section 3, relevant usage scenarios are described. Then based on the scenarios, requirements for CAPWAP are derived in Section 4. Cheng, et al. Expires January 16, 2005 [Page 3] Internet-Draft Functional Classifications July 2004 2. WLAN Functionality Classifications The IEEE 802.11 WLAN specifications [IEEE802-11] have been interpreted in numerous ways. This flexibility has allowed for varied interpretations that are compliant with the standards. However, these interpretations are presently incompatible with each other. As a result, the flexibility of the specifications has complicated interoperability. This is particularly seen in the current market space with the wide variety of split architectures. The Architecture Taxonomy [I-D.ietf-capwap-arch] clearly shows that manufacturers have taken up distinct ways distributing WLAN services among network entities. In order to address the compatibility issue, the first step is to remove ambiguity pertaining to WLAN functionality. This necessitates in establishing a consistent classification for the functions. Figure 1 illustrates a particular means of classifications based on various WLAN contributions [I-D.ietf-capwap-arch]. These function groups are distributed among access controllers (AC) and wireless termination points (WTP). Cheng, et al. Expires January 16, 2005 [Page 4] Internet-Draft Functional Classifications July 2004 --------------------------------------------------------------------- | Type | Type | Constituent | Justifications | | | Description | Functions | | --------------------------------------------------------------------- | 1 | RF Functions | Transmission/ | Functionality common| | | | Reception; | for physical | | | | Coding; Modulation; | transmission are | | | | Wireless interface | grouped. | | | | monitoring | | | | | | | | 2 | Data | Encryption/ | Functionality for | | | Functions | Decryption; | handling data frames| | | | Fragmentation; | are classified | | | | Buffering | together. | | | | | | | 3 | Management | Authentication; | Functionality common| | | Functions | Association; Probe | to the management of| | | | and beacon | the wireless MAC are| | | | generation | grouped together. | | | | | | | 4 | Control | Frame ACKs; Error | Functionality common| | | Functions | control | to the control of | | | | | wireless transport | | | | | are united. | | | | | | | 5 | WTP Supervisory| WTP Configuration; | Functionality for | | | Functions | Parameter settings; | overall WTP and | | | | Policy management; | WLAN supervision | | | | QoS management; | are aggregated. | | | | Access control | | --------------------------------------------------------------------- Figure 1 The classification in Figure 1 represents aggregations of functions that manufacturers realize in their WLAN systems. For example, the Type 1 classification relates to the radio-over-fibre WTP of Architecture 5 whereas Type 5 refers to the AC of Architecture 8 [I-D.ietf-capwap-arch]. 2.1 Policies for Adaptive CAPWAP Interfaces Classifications are an initial step for managing the diversity of split architectures. Next, they must be used to configure dissimilar WTPs to operate together within a single WLAN. This section describes adaptive CAPWAP interfaces for the purpose of managing diversity among WTPs. Cheng, et al. Expires January 16, 2005 [Page 5] Internet-Draft Functional Classifications July 2004 Figure 2 is used to illustrate different policies for adaptive CAPWAP interfaces. It shows a WLAN with a central controller, AC1, capable of all five functional classifications. Each classification is denoted by a numbered block. Associated with AC1 are two dissimilar WTPs, capable of different degrees of functionalities. The remaining complementary functionalities required for the two WTPs are left to AC1. AC1 _________ |1|2|3|4|5| |_|_|_|_|_| / \ / \ / \ _/___ _\_ |1|2|3| |1|2| |_|_|_| |_|_| WTP1 WTP2 Figure 2 The first policy is one in which each WTP executes all of its functions. In this case, the set of complementary functions required for complete WLAN operations are distinct for each of the WTPs in a WLAN. So with respect to Figure 2, WTP1 would execute all of its Types 1, 2 and 3 functions while leaving those of Types 4 and 5 to AC1. WTP2, on the other hand, can only execute Types 1 and 2 functions and refers to AC1 for all remaining. Figure 3 illustrates this policy where "+" represents functions that a WTP or AC executes and "-" represents those that are not executed. WTP1 and WTP2 both execute the entirety of their capable functions. The remaining set of complementary functions is distinct and left to AC1. AC1 in turn executes different sets of complementary functions for each of the WTPs. The result of the first policy is an adaptive CAPWAP interface between AC1 and the WTPs. AC1 (as seen AC1 (as seen _________ by WTP1) _________ by WTP2) |1|2|3|4|5| |1|2|3|4|5| |_|_|_|_|_| |_|_|_|_|_| (- - - + +) (- - + + +) / \ / \ _/___ _\_ |1|2|3| WTP1 |1|2| WTP2 |_|_|_| |_|_| (+ + +) (+ +) Cheng, et al. Expires January 16, 2005 [Page 6] Internet-Draft Functional Classifications July 2004 Figure 3 Such a policy requires AC1 to perform different types of processing for frames received from the different WTPs. There may also be variations in context requirements and sequences of processing for the different WTPs. Under this policy, CAPWAP accommodates dissimilar WTPs while fully leveraging their individual capabilities. It is noted here that an AC operating under the first policy is to be capable of performing substantial portions of the complete WLAN functions. Given the prevailing context of ACs being powerful switches or routers, the operations required for this policy are marginal. Furthermore, many existing ACs already realize considerable components of WLAN functions. A second policy for adaptive CAPWAP interfaces involves simplification for the AC. Here, an AC first determines a subset of the functions that is common across all the associated WTPs. This is then intimated to the WTPs so that they execute only those functions. Then, the remaining set of complementary functions - which is common for the WTPs - are taken up by the AC. Applying this policy to the network in Figure 2, WTP1 and WTP2 are required to execute their common Types 1 and 2 functions. The remaining functions are identically required for both and are executed by AC1. Figure 4 highlights this policy where WTP1 and WTP2 only execute Types 1 and 2 functions that are common to both. The remaining set of complementary functions is also common and is left to AC1. The notations "+" and "-" are similar to those in Figure 3. This policy simplifies the processing at the AC with the possibility of some WTPs operating below their full capabilities. AC1 (as seen AC1 (as seen _________ by WTP1) _________ by WTP2) |1|2|3|4|5| |1|2|3|4|5| |_|_|_|_|_| |_|_|_|_|_| (- - + + +) (- - + + +) / \ / \ _/___ _\_ |1|2|3| WTP1 |1|2| WTP2 |_|_|_| |_|_| (+ + -) (+ +) Figure 4 In order to accommodate the diversity among existing WLAN equipment, these policies are to be incorporated in CAPWAP. In particular, they Cheng, et al. Expires January 16, 2005 [Page 7] Internet-Draft Functional Classifications July 2004 may form the basis for initializing WTPs. The choice of policy may be left to the AC. Cheng, et al. Expires January 16, 2005 [Page 8] Internet-Draft Functional Classifications July 2004 3. Scenarios for CAPWAP It is envisaged that CAPWAP will play a leading role in WLAN deployments. The following are usage scenarios that are to be considered for devising a standard protocol. 3.1 WLAN with Heterogeneous Elements From Section 2,it is evident that the current market space comprises distinct WLAN architectures each delivering unique benefits. Consumers and enterprises however, need the combined benefits of all architectures. For instance, it is residential WLAN deployments will require both low-cost WTPs in some coverage areas and WTPs with enhanced capabilities at others. The former type is to allow service provisions to large common areas while the latter is for services within individual residences. As such, the controller of the residential WLAN needs to integrally manage both types of WTPs. 3.2 Sharing of WLAN Infrastructure Business realities are now compelling service providers to share physical WLAN infrastructure. This is with the aim of reducing capital expenditure and focusing on core competencies. In particular, a number of service providers will cover any given hotspot using the same equipment. This situation entails subscribers of the various service providers be separated and managed distinctly. Furthermore, given the sensitivity of competing businesses, subscribers must be secured from cross-service provider threats. An example to illustrate this scenario is given in Appendix A 3.3 Multiple Authentication Mechanisms Following from Section 3.2, each service provider generally has their own authentication mechanisms with which their subscribers are satisfied with. Some are content to use web based "User" and "Password" queries while others use time-limited certificates and complex challenge-response sequences. A grocery shop would use the former since wireless access is a side business while a business center next door, where wireless is a core service, would employ the latter. These represent different markets. It is highly likely that such distinct authentication mechanisms will have to be offered within a common set of WLAN infrastructure. 3.4 Data and Control Separation Current WLAN architectures enable switched or routed topologies Cheng, et al. Expires January 16, 2005 [Page 9] Internet-Draft Functional Classifications July 2004 between the AC and WTPs. As a result of allowing such topologies, WTPs may be deployed without being constrained by the limitations of physical medium, in particular length of wires. In addition to the benefit of flexibility, these topologies also introduce the drawback of latency within AC-WTP communications. Given the time sensitivity of split WLAN operations, especially control aspects, network latencies need to be addressed. A first step in this regard is to logically separate different aspects of WLAN operations and control. Appendix B provides an example for this scenario. 3.5 Dynamic Topologies With interests in mesh networks, the prevalence of dynamic WLAN topologies will increase. WTPs will be capable of being physically re-arranged during their operations. This could be for extending coverage or capacity. For instance, WLAN coverage is needed at a seaport during loading and unloading. So during such times, a WTP can be brought out from the WLAN inside a nearby warehouse and positioned on the docks. In this case, the topology of the warehouse WLAN changes in that the WTP which was previously wired to the warehouse WLAN is now using a wireless link. This complicates the timing aspects of CAPWAP split operations. Appendix C highlights this scenario. 3.6 Failover Support Large-scale WLANs involve higher risk of equipment failure or malfunction due to the sheer number of network elements. At the same time, wireless networks are playing critical roles in enterprises. It is therefore imperative for network services and the underlying infrastructure to be continuously available. Any failures need to be discovered and rectified at the earliest. Cheng, et al. Expires January 16, 2005 [Page 10] Internet-Draft Functional Classifications July 2004 4. CAPWAP Requirements Based on the scenarios of Section 3, requirements for a CAPWAP standard are presented here. 4.1 Adaptive CAPWAP Interfaces Given the scenario of Section 3.1, heterogeneous WTPs are to be accommodated within a single WLAN controller. The CAPWAP interface between AC and WTP MUST be adaptive based on the policies of Section 2.1. The policies MAY be employed statically during WLAN initialization or dynamically during active operation. 4.2 Secure Aggregations in Shared WLAN Infrastructures CAPWAP needs to address the shared infrastructure scenario of Section 3.2. In particular, subscribers from different service providers need to be aggregated and kept distinct from each other. It is also important that aggregations be secured in a manner as to avoid intermixing of traffic from different service providers. As a requirement, CAPWAP MUST support secure, non-interfering aggregations of communications traffic. 4.3 Multiple Authentications Support In light of scenario in Section 3.3, large scale WLAN deployments increasingly require different forms of authentication for the multitude of subscriber groups. Additionally, there have to be adequate means to distinguish between the groups and provide appropriate means of verification. As such, CAPWAP MUST support multiple authentication mechanisms and enable them selectively. 4.4 Data and Control Channel Separation Section 3.4 illustrates the need for CAPWAP to distinguish between different aspects of communications, specifically between data and control aspects. This is to ensure that appropriate priorities may be assigned so as to overcome topology latencies and other network conditions. So, as a first step, there MUST be separation of data and control channels in CAPWAP. The separation MAY be logical. Additionally, in order to provide relative quality of service, CAPWAP MUST support separation of subscriber data traffic into a number of sub-data channels. 4.5 Dynamic WLAN Topologies From Section 3.5, CAPWAP MUST be operational over dynamically changing WLAN topologies. In particular, some CAPWAP operations MAY Cheng, et al. Expires January 16, 2005 [Page 11] Internet-Draft Functional Classifications July 2004 be bypassed so as to compensate for topology related latencies. 4.6 Failover Support The critical nature of WLANs needs to be addressed in CAPWAP. It MUST involve mechanisms to handle failure of WTPs and ACs. 4.7 CAPWAP Design Aspects As a general requirement, it is important for CAPWAP to be rationalized in terms of number of messages it comprises. Messages and control sequences should be reused where appropriate so as to simplify operation. CAPWAP efforts should be based on these requirements to ensure that the benefits of diverse WLAN designs are integrated in a single framework. The usage scenarios provide an abstraction for CAPWAP operations. Requirements presented here also form a basis for measuring standardization efforts. Cheng, et al. Expires January 16, 2005 [Page 12] Internet-Draft Functional Classifications July 2004 5. Conclusion This document presents classifications of WLAN functions for the purpose of accommodating the diversity of designs within CAPWAP. A set of policies based on the classifications is then described as means for achieving this. The document also illustrates various scenarios in which CAPWAP would function. These follow from various contributions made to the Architecture Taxonomy. Then, based on the scenarios, specific CAPWAP requirements are derived. Cheng, et al. Expires January 16, 2005 [Page 13] Internet-Draft Functional Classifications July 2004 6. Security Considerations Security is an integral aspect of CAPWAP. As such, the requirements put forth in this document will base their security needs on that of the broader CAPWAP goals. 7 References [I-D.ietf-capwap-arch] Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", draft-ietf-capwap-arch-03 (work in progress), June 2004. [IEEE802-11] IEEE MAC and PHY Specifications, August 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Hong Cheng Panasonic Singapore Laboratories EMail: hcheng@psl.com.sg Satoshi Iino Panasonic Mobile Communications EMail: iino.satoshi@jp.panasonic.com Saravanan Govindan Panasonic Singapore Laboratories EMail: sgovindan@psl.com.sg Cheng, et al. Expires January 16, 2005 [Page 14] Internet-Draft Functional Classifications July 2004 Appendix A. Shared WLAN Infrastrucuture This is an illustration of a the shared WLAN infrastructure from Section 3.2 where three service providers, ISP-I, ISP-II and ISP-III, share the WLAN infrastructure comprising AC, WTP-1 and WTP-2. The MTs, MT1 through MT5, subscribe to one of the service providers where "I", "II" and "III" signify the subscriptions. A number of technologies are used to separate and distinguish subscriber traffic within the shared infrastructure. These include virtual APs and VLANs. For example, on the wireless front, multiple SSIDs, SSID#1 through SSID#3, are used to distinguish traffic belonging to the three ISPs. Also, on the network front, between AC and the WTPs, different VLAns, V1 and V2, are used for each of the WTPs. As a result, different ISPs share WLAN infrastructure and yet offer unique services. Section 3.2 is an increasingly common situation that CAPWAP needs to address. ___ | | MT1-I |___| / (SSID#1) / / / ISP-I ___/ (SSID#1) ___ /\ | |_____------| | MT2-II \ |___| |___| \ (V1)/ WTP1 ___ _\_ / | | ISP-II <----| |/ /|___| MT3-III |___|\ / / \ / (SSID#3) / (V2)\ / / \___/ ___ \/ | |______------| |MT4-I ISP-III |___| (SSID#1) |___| WTP-2\ \ \ (SSID#2) \ \___ | | MT5-II |___| Figure 5 Cheng, et al. Expires January 16, 2005 [Page 15] Internet-Draft Functional Classifications July 2004 Appendix B. Channel Separation An example for the scenario in Section 3.4 is given here. Figure 6 is used as an illustration. It shows the AC-WTP interface as comprising a number of channels for control and data. The control channel, C1, is used to transport configuration, control and status information between AC and WTP. There are multiple data channels, D1 through Dn, each representing subscriber traffic from a particular SSID. This follows from the current shared infrastructure trend. Such separation allows for provisioning each channel based on its appropriate sensitivities. ________________________ ()_______WTP Control______) C1 ___ ________________________ ___ | | ()_______Data (SSID#1)____) D1 | | |___| : |___| AC ________________________ WTP ()_______Data (SSID#n)____) Dn Figure 6 Cheng, et al. Expires January 16, 2005 [Page 16] Internet-Draft Functional Classifications July 2004 Appendix C. Dynamic Topologies One of the advantages of wireless mesh networks is the ease of physical deployment. This feature will be extended to allow dynamic changes in topology during the active operation of a WLAN. Figure 7 is an example of such a feature. Initially, the WLAN is configured as in topology (1). Here, WTP1 and WTP2 maintain wireline connections to the AC over which they provide service to MT1 and MT2, respectively. Then WTP1 is displaced to an alternate location where its wireline connection to AC is disconnected. This is shown in topology (2). There are a number of cases for WTP1 displacing. For example, in a manufacturing facility, network connectivity may be required at the loading bay only during dispatch periods. During such times, a WTP from the main area is moved to the loading area. In topology (2), the WTP1-AC CAPWAP interface traverses the WTP2-AC interface. So MT1 remains associated with WTP1, and at the same time there is a latent association with WTP2. This introduces timing and overhead complications that CAPWAP needs to consider. ___ ___ (1) | | AC (2) | | AC |___| |___| / \ / \ WTP1 / \ WTP2 / \ ___/ \___ \/ \___ | | | | /\ | | WTP2 |___| |___| |___| / \ || / \ / \ || / \ / \ \/ / \ _/_ _\_ ___ / _\_ |___| MT1 |___| MT2 | | |___| MT2 |___| / / / _/_ |___| MT1 Figure 7 Cheng, et al. Expires January 16, 2005 [Page 17] Internet-Draft Functional Classifications July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). 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 assignees. 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 Cheng, et al. Expires January 16, 2005 [Page 18] Internet-Draft Functional Classifications July 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Cheng, et al. Expires January 16, 2005 [Page 19]