One document matched: draft-cheng-capwap-classifications-01.txt
Differences from draft-cheng-capwap-classifications-00.txt
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] | PAFTECH AB 2003-2026 | 2026-04-24 05:40:18 |