Internet DRAFT - draft-calhoun-capwap-taxonomy-recommendation
draft-calhoun-capwap-taxonomy-recommendation
Network Working Group P. Calhoun
Internet-Draft B. O'Hara
Expires: January 16, 2006 Cisco Systems, Inc.
I. Singh
Chantry Networks Inc.
July 15, 2005
CAPWAP Taxonomy Recommendations
draft-calhoun-capwap-taxonomy-recommendation-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The IETF's CAPWAP working group has documented various product
architectures and has categorized the Centralized WLAN Architectures
into two main buckets: Split and Local MAC. While the document
contains very relevant and useful information, what it does is list
the architectural variants of these two buckets, but does not
unambiguously define either the Split MAC or Local MAC architectures.
Calhoun, et al. Expires January 16, 2006 [Page 1]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
In order for CAPWAP to be successful, it is crucial for the protocol
evaluation team, and the working group, to agree on unambiguous
terminology to describe these architectures.
This document proposes terminology to unambiguously describe the
relevant architectures found in the taxonomy document, for the
purpose of initiating a discussion within the working group and to
allow the protocol evaluation work to come to a fruitful conclusion.
We conclude in this document that the architectures are very similar
and could be supported via a single protocol.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 5
2. CAPWAP Functions . . . . . . . . . . . . . . . . . . . . . . . 6
3. Split AP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Local AP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. CAPWAP Signalling . . . . . . . . . . . . . . . . . . . . . . 12
6. Capabilities Negotiation . . . . . . . . . . . . . . . . . . . 14
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 18
11. Normative References . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . 20
Calhoun, et al. Expires January 16, 2006 [Page 2]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
1. Introduction
The CAPWAP's taxonomy specification [3] documents various
architectures, 6 of which are labeled by their proponents to be Split
MAC and 5 being Local MAC. In observing the various architectures
listed, it is clear that there is significant differentiation from
one vendor to another in the location of various functions among both
the WTP and the AC.
Figure 1 (below) comes from the taxonomy draft and shows the location
of various AP functions across different architectures. Note that
the Remote MAC architecture was determined by the Working Group to be
out of scope for CAPWAP. In this specification, this table will be
referred to as the "architecture table".
+--------------+--- +---------------+--- +--------------+---
| CAPWAP | | CAPWAP | | CAPWAP |
| functions |AC | functions |AC | functions |
|==============|=== |---------------| |--------------|
| | | non RT MAC | | |AC
| 802.11 MAC | |===============|=== | 802.11 MAC |
| |WTP | Real Time MAC | | |
|--------------| |---------------|WTP |==============|===
| 802.11 PHY | | 802.11 PHY | | 802.11 PHY |WTP
+--------------+--- +---------------+--- +--------------+---
(a) "Local MAC" (b) "Split MAC" (c) "Remote MAC"
Figure 1: Three Architectural Variants within Centralized WLAN
Architecture Family
In reading the above, one can easily understand the primary
difference between the Local and Split MAC. The Local MAC
architecture means that all of the 802.11 functions reside in the
WTP, while the CAPWAP functions reside in the AC. Conversely, the
Split MAC architecture requires that only the real-time functions of
the 802.11 MAC reside in the WTP, while the AC takes on an additional
role of participating in the 802.11 MAC management protocol in
addition to providing the CAPWAP functions.
The taxonomy draft defines the CAPWAP functions as follows:
o RF monitoring, such as Radar detection, noise and interference
detection and measurement.
Calhoun, et al. Expires January 16, 2006 [Page 3]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
o RF configuration, e.g., for retransmission, channel selection,
transmission power adjustment, etc.
o WTP configuration, e.g., for SSID, etc.
o WTP firmware loading, e.g., automatic loading and upgrading of WTP
firmware for network wide consistency.
o Network-wide STA state information database, including the
information needed to support value-added services, such as
mobility, load balancing etc.
o Mutual authentication between network entities, e.g., for AC and
WTP authentication in a Centralized WLAN Architecture.
Given the above conclusions, where a Local MAC architecture's AC only
provides the above functions, the following paragraph, found in the
taxonomy document, comes to a different conclusion:
The commonalities and differences between Local MAC and Split MAC
are most clearly seen by comparing Figure 7 and Figure 10. The
commonality between the two is that 802.11 control frames are
terminated at WTPs in both cases. The main difference between
Local MAC and Split MAC is that in the latter the WTP terminates
only the 802.11 control frames, while in the former the WTP may
terminate all 802.11 frames. An interesting consequence of this
difference is that the Integration Service, which essentially
refers to bridging between 802.11 and 802.3 frames, is implemented
by the AC in the Split MAC, but can be part of either the AC or
WTP in the Local MAC.
The above paragraph clearly creates a contradiction between the
"architecture table" and the local MAC architectures surveyed. Most
importantly is the fact that in certain local MAC architectures, the
Integration and Distribution Functions reside in the WTP while in
others they exist in the AC. As per the "architecture table", a
protocol whose Integration and Distribution Functions reside in the
AC is by definition a Split MAC architecture.
Some of the confusion stems from the actual definition of a Split MAC
architecture, which is copied here from the taxonomy specification:
Split MAC Architecture: A sub-group of the Centralized WLAN
Architecture, with the characteristic that WTPs in such WLAN
access networks only implement the delay sensitive MAC services
(including all control frames and some management frames) for IEEE
802.11, while tunneling all the remaining management and data
frames to AC for centralized processing. The IEEE 802.11 MAC, as
Calhoun, et al. Expires January 16, 2006 [Page 4]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
defined by IEEE 802.11 Standards in [1], is effectively split
between the WTP and AC.
If one were to use the strict definition above, an architecture that
terminates the MAC in the WTP, but tunnels traffic to the AC would be
considered Local MAC. It is important to note that in order for the
AC to properly terminate these "data tunnels", it must somehow
communicate STA information to the AC. Therefore, an architecture
that takes an 802.11 MAC management message and reformats it into a
different packet, containing much of the same information, which is
then sent to the AC for processing and tunnels data traffic could be
considered a Local MAC. However, the functionality provided by such
an architecture is nearly identical to a Split MAC architecture, and
the only difference is where the authors of the architecture sliced
the AP function.
It is believed that the crux of the issue is in terminology. If the
CAPWAP working group had used the terminology Split AP and Local AP
instead of MAC, this confusion could have been avoided. The term MAC
implies that the 802.11 MAC has been split as opposed to AP
functions.
In this document we will attempt to provide a clearer definition of
both architectures by focusing on functions rather than terminology,
and will therefore use the terms Split and Local AP. The proposals
in this document are intended to initiate discussions and gain some
level of consensus on the architectures.
1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Calhoun, et al. Expires January 16, 2006 [Page 5]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
2. CAPWAP Functions
The CAPWAP taxonomy specification defines the CAPWAP functions, which
are also described in Section 1 of this document. In order to ensure
compatibility among CAPWAP devices, it is necessary to come to
agreement on the location of the various CAPWAP Functions.
There was a surprising amount of similarity in the placement of the
CAPWAP functions across all architectures within a given category in
the taxonomy specification. From that document, Figure 2 attempts to
use the most consistent location for each function and proposes a
model for both the Local and Split architecture.
Local Split
Functions MAC MAC
----- -----
RF Monitoring WTP WTP
RF Configuration AC AC
WTP Configuration AC AC
WTP Firmware AC AC
STA State Info Database WTP/AC AC
AC/WTP Mutual Authentication WTP/AC WTP/AC
Figure 2: Mapping of CAPWAP Functions
Note when a function appears to reside in both network elements
(e.g., WTP/AC), it implies that this is a split function among both
the WTP and the AC.
Calhoun, et al. Expires January 16, 2006 [Page 6]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
3. Split AP
It is clear that there are significant similarities among most of the
Split MAC architectures, and as a consequence providing a proposed
architecture here should be simpler. In this section we attempt to
provide a proposal for a Split AP architecture for the CAPWAP working
group. The following paragraphs are found in the taxonomy
specification and provide a high level view of the "CAPWAP 802.11 MAC
Split"
Since there is no clear definition in the 802.11 specification as
to which 802.11 MAC functions are considered "real time", each
vendor has taken the liberty to interpret that in his own way.
Most vendors agree that the following services of the 802.11 MAC
are examples of real time services and so are chosen to be
implemented on the WTPs.
o Beacon Generation
o Probe Response/Transmission
o Processing of Control Frames: RTS/CTS/ACK/PS-Poll/CF-End/CF-ACK
o Synchronization
o Retransmissions
o Transmission Rate Adaptation
The following list includes examples of non-real-time MAC
functions as interpreted by most vendors:
o Authentication/Deauthentication
o Association/Disassociation/Reassociation/Distribution
o Integration Services: bridging between 802.11 and 802.3
o Privacy: 802.11 Encryption/Decryption
o Fragmentation/Defragmentation
The above list is a good starting place for evaluating a Split AP
protocol. However, there are two issues with functions listed as
residing in the AC:
Calhoun, et al. Expires January 16, 2006 [Page 7]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
o Fragmentation/Defragmentation. Requiring this function to exist
in the AC will cause issues with support for 802.11e. In the
802.11e specification, and more importantly the HCCA mechanism
defined, an AP may need to fragment frames in order to fill a
scheduled service period; thus 802.11e defines this function to be
realtime for some instance. Moving this function to the AC is not
possible since access to the air is required in order to be able
to react to instantaneous changes in bandwidth, either as a result
of noise or co-channel interference from adjacent APs or STAs.
Placing this function in the AC would preclude an implementer from
using the feature of 802.11e. In addition, this function is often
used as part of the retransmission strategy, the control of which
is in the WTP.
o Privacy. There are two components to Privacy; 802.11 data privacy
and secure session establishment (802.1X/EAP). It is agreed that
the 802.1X/EAP function should reside in the AC. However, while
encryption/decryption services could be performed in the WTP in
most of today's circumstances, this becomes very problematic when
used in conjunction with HCCA. As previously noted, HCCA will
cause frames to be fragmented in order to fill a service period,
and fragmentation occurs prior to encryption in 802.11. Requiring
encryption services in the AC is not possible, again, else it
preclude an implementer from utilizing these 802.11e features.
Taking the above information, and assuming that the CAPWAP functions
are handled in the AC, Figure 3 proposes a functional definition for
all functions in a Split MAC architecture.
Function Location
Distribution Service AC
Integration Service AC
Beacon Generation WTP
Probe Response WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc AC (1)
802.11e
Classifying AC
Scheduling WTP/AC (2)
Queuing WTP
802.11i
802.1X/EAP AC
Key Management AC
802.11 Encryption/Decryption WTP
Calhoun, et al. Expires January 16, 2006 [Page 8]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
Figure 3: Mapping of 802.11 Functions for Split AP Architecture
(1) The messages exchanged between the AC and the WTP do not
necessarily mean these are 802.11 MAC management packets, but an
equivalent message would have to be exchanged to allow the AC to
maintain proper state. However, note that the introduction of
802.11r will necessitate the co-location of both 802.11i key
management and 802.11 MAC Management messages.
(2) Packet scheduling may occur on the AC, but MUST occur on the WTP.
Calhoun, et al. Expires January 16, 2006 [Page 9]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
4. Local AP
The local MAC architecture is one that is not very well defined in
the taxonomy specification, primarily due to the variations in the
architectures listed. The following paragraph can be found in the
taxonomy document and is central to the architecture being proposed
in this section (please note all references are against the taxonomy
specification, not this document):
The main motivation of Local MAC architecture model, as shown in
Figure 6.(a), is to offload network access policies and management
functions (CAPWAP functions described in Section 2.2) to the AC,
without splitting the 802.11 MAC functionality between WTPs and
AC. The whole 802.11 MAC resides on the WTPs locally, including
all the 802.11 management and control frame processing for the
STAs; on the other hand, information related to management and
configuration of the WTP devices is communicated with a
centralized AC, to facilitate management of the network, and
maintain a consistent network-wide configuration for the WTP
devices.
There appears to be some confusion as to what a local MAC
architecture means in the various implementations listed in the
taxonomy document. For instance, an implementation that takes an
802.11 MAC management packet and creates a separate request, which is
forwarded for processing at the AC, is sometimes considered a Local
MAC. This is primarily due to the fact that the actual 802.11 MAC
protocol never leaves the WTP. While this is correct in principle,
the reality is that the functionality provided by such a solution
would be identical in nature to a Split MAC approach. As a
consequence, this document assumes that even though these
architectures were classified as being Local MAC in the taxonomy
document, they are really Split MAC (but implemented in a slightly
different way).
This section will attempt to provide a proposal for a local AP
architecture that the CAPWAP WG could consider.
Using the above assumptions, all of the 802.11 MAC resides on the
Local AP WTP and only the CAPWAP functions are found on the AC.
However, it is important to note that the 802.11i components in
Figure 4 overlap directly with the "STA State Info Database" CAPWAP
function described in Figure 2. As a consequence, it is only natural
to locate the 802.1X and Key Management 802.11i functions centrally
in the AC.
The resulting function distribution for a Local AP architecture can
be found in Figure 4
Calhoun, et al. Expires January 16, 2006 [Page 10]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
Function Location
Distribution Service WTP
Integration Service WTP
Beacon Generation WTP
Probe Response WTP
Power Mgmt/Packet Buffering WTP
Fragmentation/Defragmentation WTP
Assoc/Disassoc/Reassoc WTP
802.11e
Classifying WTP
Scheduling WTP
Queuing WTP
802.11i
802.1X/EAP AC
Key Management AC
802.11 Encryption/Decryption WTP
Figure 4: Mapping of 802.11 Functions for Local AP Architecture
To summarize, a Local AP architecture is one where all of the normal
802.11 AP functions, with the exception of 802.1X and the 802.11i key
management functions, reside in the WTP, but centralized control and
provisioning, defined as CAPWAP functions, reside in the AC.
Calhoun, et al. Expires January 16, 2006 [Page 11]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
5. CAPWAP Signalling
The issue that remains at this point is whether a single protocol is
capable of supporting both Split and Local AP modes. The primary
differences between both is that a Local AP implementation is
generally used in network deployments where a long latency link
exists between the WTP and the AC. Therefore, it is not realistic to
expect that the MAC management response times assumptions in 802.11
stations can be supported if the MAC management packets had to
traverse a high latency network towards the AC.
As a result, certain Local MAC implementations have created an agent
that sits at the 802.11 SME layer on the WTP. This agent simply
creates a protocol PDU based on the information received at the SME,
and forwards it to the AC (see Figure 5.
+----------------------------+
| CAPWAP AC Function |
|- - - - - - - - - - - - - - | AC
| CAPWAP Protocol |
+----------------------------+
IP Network
+----------------------------+
| CAPWAP Protocol |
|- - - - - - - - - - - - - - |
| SME Layer | WTP
|- - - - - - - - - - - - - - |
| 802.11 MAC Management |
+----------------------------+
Figure 5: Local AP Diagram
While creating an SME agent at the WTP is one method of implementing
a Local AP architecture, there is an alternative that allows for a
single CAPWAP protocol to be used by both Split and Local AP
architectures. This method is known as Proxy MAC, whereby the WTP
actually processes the MAC management frames received, and then
forwards these frames to the AC. This allows the AC to be notified
of SME events at the WTP, while allowing this to be provided by
simply encapsulating the 802.11 MAC management frames.
This Proxy MAC mechanism is agnostic to wireless MAC technology. A
Proxy MAC function can be applied to other wireless MAC technologies
to allow a WTP to transmit MAC-specific events to the AC.
Calhoun, et al. Expires January 16, 2006 [Page 12]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
+----------------------------+
| CAPWAP AC Function |
|----^---------- - - - - - - |
| | Split AP | AC
|----|---------- - - - - ^ - |
| | CAPWAP Protocol | |
+----|-------------------|---+
| |
| IP Network |
| |
+----|-------------------|---+
| | CAPWAP Protocol | |
|- - v - - - - ----------|---|
| Proxy MAC | | WTP
|- - - - - - - ----------v---|
| 802.11 MAC Management |
+----------------------------+
Figure 6: Proxy AP Diagram
Calhoun, et al. Expires January 16, 2006 [Page 13]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
6. Capabilities Negotiation
Many of the discussions in the CAPWAP mailing list have revolved
around the need for flexibility, and as such, the need to provide
multiple optional features that would be negotiated between the WTP
and the AC. The introduction of optional features is a means to
introduce interoperability issues. This is clearly seen in some
CAPWAP proposals that lay out a complex options matrix, allowing for
a large number of combinations.
While it is not possible to eliminate all of the options in a
protocol or architecture, it is clear that the presence of such
options must not create interoperability issues, must be limited in
number, and have clear mandatory to implement modes. In the end, the
CAPWAP WG serves the Internet Community, and not resolving this issue
simply places the burden on the end customer, causing them to try to
figure out how to get multiple CAPWAP compliant devices to
interoperate.
This document suggests out of the box interoperability by proposing
the following CAPWAP protocol options, with specific default values:
o Data Path Tunneling: While some proposals encapsulate the user
frames in their natural 802.11 form, other proposals prefer the
use of 802.3, a clear indication of an interoperability issue.
However, if one were to make Local AP, meaning local bridging of
user frames, be the default (mandatory to implement) mode, then
interoperability would be guaranteed, and Split AP mode could be
enabled only if both the AC and the WTP supported the same
encapsulation format.
o Split vs. Local AP: The WG needs to pick a mandatory to implement
mode for handling MAC Management frames. A recommendation is
local AP.
o Split AP Encryption Mode: Given the issues discussed in this
document regarding support for HCCA, the only reasonable mandatory
to implement encryption mode is in the WTP. Further, this is only
natural as all 802.11 MACs today support the 802.11i encryption
mechanisms in hardware. The CAPWAP protocol MUST allow for
negotiation of encryption in the AC.
Calhoun, et al. Expires January 16, 2006 [Page 14]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
7. Conclusion
We have defined both the Local and Split AP architectures in the
previous sections. The observations described in this document
clearly outline their differences. To summarize, these are:
o Data Path Tunneling: In a Split AP approach, all of the 802.11
data frames are tunneled to the AC, while a Local AP design would
require the WTP to locally bridge the traffic.
o 802.11 Functions: In a Split AP approach, the 802.11 MAC
management functions reside in the AC. In the Local AP
architecture all of the access control decisions reside in the
WTP, while the 802.1X authenticator resides in the AC.
This document has also observed that a single protocol could provide
both Local and Split AP modes, through the introduction of Proxy MAC.
This method allows the AC to be notified of SME events, without
requiring a new protocol, significantly simplifying the task of the
Working Group.
Lastly, this document has listed a small number of CAPWAP
architectures, with specific default (mandatory to implement) values,
guaranteeing interoperability among any CAPWAP compliant devices.
The CAPWAP working group should seriously consider the Split and
Local AP architectures defined in this document, allowing the working
group to put aside the bagagge associated with the concept of
splitting the MAC and focus instead on splitting the AP functions.
Calhoun, et al. Expires January 16, 2006 [Page 15]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
8. Security Considerations
This document is an observation of the two main architectures being
discussed within the CAPWAP working group. As a consequence, there
is nothing specific about this document that introduces new security
considerations.
Calhoun, et al. Expires January 16, 2006 [Page 16]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
9. IANA Considerations
This document requires no action by IANA.
Calhoun, et al. Expires January 16, 2006 [Page 17]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
10. IPR Statement
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Please refer to http://www.ietf.org/ietf/IPR for more information.
11. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Govindan, S., "Objectives for Control and Provisioning of
Wireless Access Points (CAPWAP)",
draft-ietf-capwap-objectives-03 (work in progress), June 2005.
[3] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for
Control and Provisioning of Wireless Access Points(CAPWAP)",
draft-ietf-capwap-arch-06 (work in progress), November 2004.
Authors' Addresses
Pat R. Calhoun
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408-853-5269
Email: pcalhoun@cisco.com
Bob O'Hara
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
Phone: +1 408-853-5513
Email: bob.ohara@cisco.com
Calhoun, et al. Expires January 16, 2006 [Page 18]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
Inderpreet Singh
Chantry Networks Inc.
1900 Minnesota Court
Mississauga, ON L5N 3C9
Canada
Phone: +1 905-363-6412
Email: inderpreet.singh@siemens.com
Calhoun, et al. Expires January 16, 2006 [Page 19]
Internet-Draft CAPWAP Taxonomy Recommendations July 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Calhoun, et al. Expires January 16, 2006 [Page 20]
