[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01

   Operations Group                                            I. Singh
   Internet Draft                                          P. Francisco
   Expires: December 2005                              Chantry Networks
                                                              June 2005




               Evaluation of CAPWAP Tunneling Protocol (CTP)
               draft-francisco-capwap-ctp-evaluation-00.txt


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 December 8, 2005.

Copyright Notice

      Copyright (C) The Internet Society (2005).


Abstract

   This document presents a self evaluation of the CAPWAP Tunneling
   Protocol (CTP) with respect to the requirements presented in the
   CAPWAP Objectives draft.  This work is to aid in the official working
   group evaluation of the candidate protocols for CAPWAP.




Francisco              Expires - December 2005               [Page 1]


 Internet-Draft             CTP Evaluation                   June 2005


Table of Contents

   1. Definitions....................................................3
      1.1 Conventions used in this document..........................3
   2. Introduction...................................................3
   3. Objectives Responses...........................................3
      3.1 Mandatory and Accepted Objectives..........................3
         3.1.1 Logical Groups........................................3
         3.1.2 Support for Traffic Separation........................3
         3.1.3 Wireless Terminal Transparency........................4
         3.1.4 Configuration Consistency.............................4
         3.1.5 Firmware Trigger......................................4
         3.1.6 Monitoring and Exchange of System-wide Resource State.5
         3.1.7 Resource Control Objective............................5
         3.1.8 CAPWAP Protocol Security..............................6
         3.1.9 System-wide Security..................................6
         3.1.10 IEEE 802.11i Considerations..........................7
         3.1.11 Interoperability Objective...........................7
         3.1.12 Vendor Independence..................................8
         3.1.13 Vendor Flexibility...................................8
      3.2 Desirable Objectives.......................................9
         3.2.1 Multiple Authentication Mechanisms....................9
         3.2.2 Support for Future Wireless Technologies..............9
         3.2.3 Support for New IEEE Requirements.....................9
         3.2.4 Interconnection Objective............................10
         3.2.5 Access Control.......................................10
      3.3 Non-objectives............................................10
         3.3.1 Support for Non-CAPWAP WTPs..........................10
         3.3.2 Technical Specifications.............................11
      3.4 Operator Requirements.....................................11
         3.4.1 AP Fast Handoff......................................11
   4. Compliance Table..............................................11
   5. Security considerations.......................................12
   6. References....................................................12
   7. Author's Addresses............................................12
      Intellectual Property and Copyright Statements ...............13















Francisco              Expires - December 2005               [Page 2]


 Internet-Draft             CTP Evaluation                   June 2005



1.   Definitions

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]

2.   Introduction

   The authors of the CAPWAP Tunneling Protocol(CTP) [2] believe that
   CTP provides a robust solution in the form of a protocol that
   addresses the issues raised in the CAPWAP Problem Statement draft
   [3].  CTP can be run over an L2 or an L3 network and it is extensible
   to support WTPs which terminate other radio technologies than IEEE
   802.11.

   Given below is a brief analysis of the protocol with respect to the
   objectives draft [4] that has been presented and discussed in the WG.

3.   Objectives Responses
3.1    Mandatory and Accepted Objectives

3.1.1      Logical Groups
   The ability to control and manage physical WTPs in terms of logical
   groups.

3.1.1.1        Protocol Evaluation
   CTP natively recognizes WTP devices as logical groups. The protocol
   provides capabilities discovery mechanisms (CTP_CAP_REQ/RESP) to
   allow a device to enumerate physical and logical associations. These
   associations are then carried forth into the protocol exchange and
   state machines to decouple the logical operations such as Virtual
   Radios from physical resources.

3.1.1.2        Compliance
   CTP is compliant with this objective.

3.1.2      Support for Traffic Separation
   This objective pertains to the need to maintain separation of control
   and data traffic in the operation of the protocol.

3.1.2.1        Protocol Evaluation
   CTP provides specific message types providing for support of easy
   separation of control and data paths. The CTP payload is explicitly
   enumerated with itÆs own type (CTP Draft Section 5.3.1, CTP_DATA). In
   addition the CTP implementation, by terminating the 802.1d conversion
   at the WTP, provides a configurable option per logical WTP device to


Francisco              Expires - December 2005               [Page 3]


 Internet-Draft             CTP Evaluation                   June 2005


   indicate whether data traffic should be returned to the controller,
   via tunneling, or natively be handled by the WTP by bridging locally
   onto the wired network.  This only applies to data packets, whereas
   the control channel within CTP is completely separate and terminates
   at the controller always.

3.1.2.2        Compliance
   CTP is compliant with this objective.

3.1.3      Wireless Terminal Transparency
   This objective specifies the need for the protocol to be client
   agnostic.  That is, the wireless terminals need not be aware of the
   existence of the CAPWAP protocol running underneath.

3.1.3.1        Protocol Evaluation
   CTP provides mainly a set of provisioning methods for the WTPs
   operations and data tunneling, but itÆs operation is transparent to
   the connecting client. The connecting client simply interacts with
   the WTPÆs wireless MAC implementation and itÆs traffic is bridge to
   the network point of presence which may selectively be the controller
   or the local wired infrastructure. In Controller mode the traffic is
   encapsulated for transport but the client remains un-aware that
   additional transport is taking place.  Shipping products with CTP
   implementations have shown that this protocol does not have any
   adverse effects, interoperability or otherwise, on the wireless
   terminals.

3.1.3.2        Compliance
   CTP is compliant with this objective.

3.1.4      Configuration Consistency
   This objectives pertains to the protocolÆs ability to provide
   consistent state information of the WTPs at the AC.

3.1.4.1        Protocol Evaluation
   CTP makes provisions for the periodic retrieval of WTP information
   (CTP_Stats_REQ/RESP, CTP_STATS_Notify) such as RF statistics and Load
   factors as per standard MIB specifications.

3.1.4.2        Compliance
   CTP is compliant with this objective.

3.1.5       Firmware Trigger
   This objective states that the protocol must have the ability to
   trigger WTP firmware updates.  It does not necessarily state the need
   for the protocol to integrate a software update mechanism within the
   protocol itself.



Francisco              Expires - December 2005               [Page 4]


 Internet-Draft             CTP Evaluation                   June 2005


3.1.5.1        Protocol Evaluation
   After the device capability exchange phase (CTP-CAP_REQ/RESP) which
   allows for the identification of the type of WTP connecting, CTP
   protocol specifies a phase of firmware image validation (CTP-
   Software-upgrade-req/resp, section 5.1.5) by which the WTP indicates
   to the Controller what version of image it is currently running and
   the response validates and requests an update if necessary.
   Conversely, the Controller may explicitly request (Under
   administratorÆs control) the firmware upgrade for a specified WTP.
   CTP does not specify the actual method for firmware upgrade, but
   rather assumes the application of standardized binary transport
   protocols (FTP/TFTP).

3.1.5.2        Compliance
   CTP is compliant with this objective.

3.1.6       Monitoring and Exchange of System-wide Resource State
   This objective states that the protocol must incorporate the ability
   for the WTP to send statistics, congestion indications and other
   pertinent wireless state information to the AC.

3.1.6.1         Protocol Evaluation
   CTP protocol provides for the periodic exchange of a WTPÆs
   operational statistics (CTP-Stats-req/resp, CTP-Stats-Notify, Section
   5.2.7-9). The statistics characteristics may be enhanced to convey
   necessary information set.

3.1.6.2         Compliance
   CTP is compliant with this objective.

3.1.7       Resource Control Objective
   This objective pertains to the ability of the protocol to provide a
   mapping mechanism of the IEEE 802.11e QOS priorities across the
   wireless and wired infrastructure.

3.1.7.1         Protocol Evaluation
   CTP, by virtue of being an IP based transport protocol, provides
   several mechanisms to ensure the preservation of QoS markers within
   the original data packet. The protocol header (CTP Section 4.1)
   natively defines an 8-bit field for relaying of QoS policy related
   information in a transport independent manner. This allows the WTP
   and Controller to classify and guarantee the preservation of any
   802.11e identifiers between the two entities. In addition, CTP
   implementation must copy the TOS fields of the original data packet
   onto the tunnel header.  The corresponding QoS markers are also
   mapped to the layer 2 if 802.1q implemented in the interconnecting
   network.




Francisco              Expires - December 2005               [Page 5]


 Internet-Draft             CTP Evaluation                   June 2005


3.1.7.2         Compliance
   CTP is compliant with this objective.

3.1.8       CAPWAP Protocol Security
   This objective concerns the security of the CAPWAP protocol.  The
   protocol must support mutual authentication of the WTP and the AC and
   the communication channel between the two entities must be secured.
   In addition, however, the protocol must not preclude the possibility
   of supporting asymmetric authentication mechanisms.

3.1.8.1         Protocol Evaluation
   First of all, as currently defined, CTP does not support a pre-shared
   key mechanism for mutual authentication.  It assumes the existence of
   digital certificates on the WTP and AC.  The mutual authentication
   mechanism between WTP and AC using digital certificates as described
   in the CTP draft is very similar to the method employed in the LWAPP
   draft [5].  As such, some of the recent comments on the WG email list
   regarding the security of LWAPPÆs mutual authentication also applies
   to CTP.  Specifically in the area of the generation of the encryption
   key.  Currently CTP specifies that the encryption key is generated by
   the AC and is securely transported to the WTP.  An obvious
   improvement would be for the WTP and the AC to mutually contribute to
   the generation of the encryption key by providing independently
   generated random material for the session keys.

   Also, based on discussion on the WG list it is not clear whether the
   use of pre-shared key for mutual authentication is required or simply
   that the authentication must be mutual.  Nevertheless, we believe
   that adding another method of mutual authentication, ie. with using
   pre-shared keys, will enhance the flexibility of the CTP protocol,
   but at the cost of increased protocol complexity.

3.1.8.2         Compliance
   CTP is partially compliant with this objective.

3.1.9       System-wide Security
   The protocol must not adversely affect the security of the wireless
   and wired networks on which it runs.

3.1.9.1         Protocol Evaluation
   CTP defines that any exchanges of control based material such as PMK
   is natively encrypted. All Control messages are mutually encrypted
   between the WTP and controller. In lieu of a thorough security and
   cryptographic analysis of the protocol by peers, the authors believe
   that the encryption/keying mechanism currently provides adequate
   protection against un-authorized compromise of the transported
   information which, in turn, would not adversely affect the security
   of the wireless or wired network.



Francisco              Expires - December 2005               [Page 6]


 Internet-Draft             CTP Evaluation                   June 2005




3.1.9.2         Compliance
   The protocol is partially compliant with this objective pending a
   thorough security and cryptographic review.

3.1.10        IEEE 802.11i Considerations
   The CAPWAP protocol must determine the exact structure of the
   centralized WLAN architecture in which authentication needs to be
   supported, i.e. the location of major authentication components.

   This may be achieved during WTP initialization where major
   capabilities are distinguished.

   The protocol must allow for the exchange of key information when
   authenticator and encryption roles are located in distinct entities.

3.1.10.1          Protocol Evaluation
   During the capabilities exchange phase of the CTP protocol it is
   determined whether the WTP implementation is a split-MAC or a local-
   MAC implementation.  This would in turn lead the AC to engage the
   appropriate authentication modules of 802.11i.  The CTP protocol
   defines that all control exchanges between WTP and Controller are
   encrypted with own key pairs.  Therefore , the keying information
   that is required is appropriately transported between WTP and AC in a
   secure fashion.  For local-MAC implementation any frames relating to
   authentication are relayed as control messages (CTP-Auth-Req/resp).
   For split-MAC, the transport of this sensitive information may also
   be carried as payload for the same message and therefore provide
   encryption for transport.

3.1.10.2          Compliance
   CTP is compliant with this objective.

3.1.11        Interoperability Objective
   The objective specifies that the protocol must include a capabilities
   exchange mechanism so that different types of WTPs can be managed by
   ACs.  That is, local-MAC and split-MAC WTPs may be recognized by the
   AC through protocol exchange and appropriate handling within the
   protocol would ensue as a result of this capability exchange.

3.1.11.1          Protocol Evaluation
   The CTP protocol as specified, provides a mechanism for capabilities
   exchange (CTP-caps-req/resp) that could be leveraged to allow the WTP
   and the Controller to negotiate the operational mode as to whether
   split-MAC or Local-MAC is implemented in the WTP.  In its current
   form the draft does not specify the differences in the transport and
   configuration that would occur if the WTP supports split-MAC.  The



Francisco              Expires - December 2005               [Page 7]


 Internet-Draft             CTP Evaluation                   June 2005


   authors are aware of this limitation in the draft and are working on
   the same.

3.1.11.2          Compliance
   In its current form CTP is partially compliant with this objective.

3.1.11.3         Protocol Specifications
   This objective states that any vendor of a WTP or AC or any person
   may implement the CAPWAP protocol and that all such implementations
   should interoperate.

3.1.11.4          Protocol Evaluation
   CTP specification fully specify the protocol and its operation within
   WTPs and ACs.  It also indicates the configuration and statistics
   capabilities come from MIB specifications that are published by IEEE
   that fully describe the managed objects within an WTP.  Although full
   MIB specifications from IEEE are considered work in progress the
   authors believe that the work done there will enable full
   interoperability as, presumably, the specifications coming from IEEE
   will be complete and not require any knowledge of any vendor specific
   wireless device information.

3.1.11.5          Compliance
   CTP is compliant with this objective.

3.1.12        Vendor Independence
   This objective states that the CAPWAP protocol must not be reliant on
   any underlying vendor implementation of hardware of either the WTP or
   the AC.

3.1.12.1          Protocol Evaluation
   CTP does not assume any underlying hardware architecture of the WTPs
   or the ACs.  In addition any dependency on MIB definitions in its
   current form also does not assume any reliance on hardware
   specifications.

3.1.12.2          Compliance
   CTP is compliant with this objective.

3.1.13        Vendor Flexibility
   The protocol must not be bound to any specific MAC.

3.1.13.1          Protocol Evaluation
   CTP has been completely implemented on hardware from at least two
   different vendors whose wireless MAC implementations are completely
   independent.  Given this fact as well as CTPÆs inherent agnosticity
   of wireless implementation, CTP can be implemented without knowledge
   of underlying vendor hardware.



Francisco              Expires - December 2005               [Page 8]


 Internet-Draft             CTP Evaluation                   June 2005


3.1.13.2          Compliance
   CTP is compliant with this objective.

3.2     Desirable Objectives

3.2.1        Multiple Authentication Mechanisms
   This objective specifies the requirement that the protocol should be
   able to support authentication mechanisms other than IEEE 802.11i.

3.2.1.1          Protocol Evaluation
   Since CTP is wireless terminal agnostic, and since the PMK key
   exchange is generic (for example, does not assume any authentication
   mechanism in the form of an EAP type), CTP does not prevent the
   operation of any other authentication mechanism.

3.2.1.2          Compliance
   CTP is compliant with this objective.

3.2.2        Support for Future Wireless Technologies
   This objective states that the protocol should be able to be extended
   to future layer 2 wireless technologies and should not be limited to
   only supporting IEEE 802.11.

3.2.2.1          Protocol Evaluation
   The current specification lists alternative layer 2 wireless
   technologies that and be indicated as part of the capabilities
   exchange phase.  The protocol is sufficiently modular in that the
   configuration, statistics and other management functions of these
   wireless devices can be supported.  If indeed there are layer 2
   wireless specific elements that need to be added, those are easily
   supported by extensions to the protocol.

3.2.2.2          Compliance
   CTP is compliant with this objective.

3.2.3        Support for New IEEE Requirements
   The protocol must be able to accommodate defined changes or
   extensions to the IEEE 802.11 specifications.

3.2.3.1         Protocol Evaluation
   Currently CTP maps 802.11 specific messages into generic messages
   within CTP.  In other words it provides an abstraction layer to layer
   2 wireless specific commands and functions.  As new 802.11
   specifications arise, whether the intelligence to interpret them is
   required in the AC or the WTP is irrelevant.  There will be work
   required to interpret these new extensions on both the AC as well as
   the WTP.  The CTP specification is constructed so that a new
   extension would result in a new message type.  So it can accommodate
   the changes as they arise.


Francisco              Expires - December 2005               [Page 9]


 Internet-Draft             CTP Evaluation                   June 2005



3.2.3.2         Compliance
   CTP is compliant with this objective.

3.2.4        Interconnection Objective
   The CAPWAP protocol must not be constrained by the underlying
   transport technologies of the wired medium.

3.2.4.1          Protocol Evaluation
   CTP is agnostic to the underlying transport technology as it is
   implemented as UDP.  This was done with the assumption that the
   transport technology can carry IP packets across its medium either L2
   or L3 network.  Currently CTP is IPv4 specific and needs to be
   updated to be IP version agnostic as well.

3.2.4.2          Compliance
   CTP is partially compliant with this objective in terms of not having
   specified IPv6 header types.

3.2.5        Access Control
   This objective pertains to the ability of the protocol to exchange
   information required for access control of WTPs and wireless
   terminals.

3.2.5.1          Protocol Evaluation
   CTP provides specific messages, e.g. CTP-MU-
   Connect/Disconnect/Authenticate messages, that control the access of
   wireless terminals.  In addition to the actual mutual authentication
   of WTPs and ACs, the registration phase contains a AP-ID field that
   needs to be verified by the AC.  This field needs to be checked by
   the AC and the mechanism for this check is not within the scope of
   any CAPWAP work.  However, the CTP protocol itself provides this
   identification token as a means of access control of the WTP.

3.2.5.2          Compliance
   CTP is compliant with this objective.

3.3     Non-objectives

   The current objectives draft states this section as ôRejected
   Objectivesö.  We have used the term ôNon-Objectivesö for this section
   based on the discussion on the WG email list.

3.3.1        Support for Non-CAPWAP WTPs
   This objective states that the CAPWAP protocol should be capable of
   recognizing legacy WTPs and existing network management systems.

3.3.1.1          Protocol Evaluation



Francisco              Expires - December 2005              [Page 10]


 Internet-Draft             CTP Evaluation                   June 2005


   This requirement is more of a feature for centralized WLAN network
   applications and thus does not apply to the CAPWAP problem statement.

3.3.1.2          Compliance
   CTP is compliant with this objective.

3.3.2        Technical Specifications
   This objective states that WTP vendors should not have to share
   technical specifications for hardware and software to AC vendors in
   order for interoperability to be achieved.

3.3.2.1          Protocol Evaluation
   As discussed earlier, CTP is hardware and vendor agnostic.

3.3.2.2          Compliance
   CTP is compliant with this objective.

3.4     Operator Requirements

3.4.1       AP Fast Handoff
   This objective states that the CAPWAP protocol operations must not
   impede or obstruct the efficiency of fast handoff procedures.

3.4.1.1          Protocol Evaluation
   In the CTP protocol, the signaling of roaming events are efficiently
   encoded in the CTP-MU messages.  Also, the 802.1x messaging is
   centralized allowing efficient use of CPU resources at the AC.  In
   effect, the mere existence of the centralized architecture ensures
   that the efficiency of fast handoffs is improved rather than impeded.

3.4.1.2          Compliance
   CTP complies with this objective.

4.   Compliance Table

   Given below is a table summarizing the compliance to the objectives.
   C = Compliant, P = Partially compliant, N = Non-compliant.

   +----------------------------------------------------+------------+
   | Objective Type                                     | Compliance |
   +----------------------------------------------------+------------+
   | Logical Groups                                     |     C      |
   | Support for Traffic Separation                     |     C      |
   | Wireless Terminal Transparency                     |     C      |
   | Configuration Consistency                          |     C      |
   | Firmware Trigger                                   |     C      |
   | Monitoring & Exchange of System-wide Resource State|     C      |
   | Resource Control Objective                         |     C      |
   | CAPWAP Protocol Security                           |     P      |


Francisco              Expires - December 2005              [Page 11]


 Internet-Draft             CTP Evaluation                   June 2005


   | System-wide Security                               |     P      |
   | IEEE 802.11i Considerations                        |     C      |
   | Interoperability Objective                         |     P      |
   | Protocol Specifications                            |     C      |
   | Vendor Independence                                |     C      |
   | Vendor Flexibility                                 |     C      |
   | Multiple Authentication Mechanisms                 |     C      |
   | Support for Future Wireless Technologies           |     C      |
   | Support for New IEEE Requirements                  |     C      |
   | Interconnection Objective                          |     P      |
   | Access Control                                     |     C      |
   | Support for Non-CAPWAP WTPs                        |     C      |
   | Technical Specifications                           |     C      |
   | AP Fast Handoff                                    |     C      |
   +----------------------------------------------------+------------+


5.   Security considerations

   This document provides a self evaluation of CTP in respect to the
   CAPWAP objectives.  The CTP draft itself has a section that
   catalogues all the pertinent security concerns.  Therefore, in this
   draft there are no new security considerations to be discussed.

6.   References



   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
      Levels", BCP 14, RFC 2119, March 1997

   [2] Singh, I., et. al., ôCAPWAP Tunneling Protocolö, draft-singh-
      capwap-ctp-01.txt (work in progress), April 2005.

   [3] Calhoun, P., "CAPWAP Problem Statement", draft-ietf-capwap-
      problem-statement-02.txt (work in progress), September 2004.

   [4] Govindan, S., et. al., ôObjectives for Control and Provisioning
      of Wireless Access Points (CAPWAP)ö, draft-ietf-capwap-objectives-
      02.txt (work in progress), April 2005

   [5] Calhoun, et. al., ôLight Weight Access Point Protocol (LWAPP)ö,
      draft-ohara-capwap-lwapp-02.txt (work in progress), April 2005


7.   Author's Addresses

   Paulo Francisco



Francisco              Expires - December 2005              [Page 12]


 Internet-Draft             CTP Evaluation                   June 2005


   Chantry Networks Inc.
   1900 Minnesota Court
   Mississauga, ON L5N 3C9
   Canada

   Phone: +1 905-363-6410
   Email: paulo.francisco@siemens.com

   Inderpreet Singh
   Chantry Networks Inc.
   1900 Minnesota Court
   Mississauga, ON L5N 3C9
   Canada

   Phone: +1 905-363-6412
   Email: inderpreet.singh@siemens.com


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 implementers 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.

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.


Francisco              Expires - December 2005              [Page 13]


 Internet-Draft             CTP Evaluation                   June 2005



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.







































Francisco              Expires - December 2005              [Page 14]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/