Network Working Group S. Iino
Internet-Draft S. Govindan
Expires: September 30, 2005 M. Sugiura
H. Cheng
Panasonic
March 29, 2005
Wireless LAN Control Protocol (WiCoP)
draft-iino-capwap-wicop-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 September 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The popularity of wireless local area networks (WLANs) has led to
wide spread deployments across different establishments. It has also
translated in to increasing scale of the WLANs. Large-scale
deployments made of large numbers of wireless termination points
Iino, et al. Expires September 30, 2005 [Page 1]
Internet-Draft WiCoP March 2005
(WTPs) and covering substantial areas are increasingly common.
The Wireless LAN Control Protocol (WiCoP) described in this document
allows for the control and provisioning of large-scale WLANs. It
enables central management of these networks and realizes the
objectives set forth for the control and provisioning of wireless
access points (CAPWAP).
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
5. WiCoP Format . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 WiCoP Header . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 WiCoP Control Packet . . . . . . . . . . . . . . . . . . . 11
5.2.1 WiCoP Control Messages . . . . . . . . . . . . . . . . 12
5.2.2 WiCoP Control Message Elements . . . . . . . . . . . . 13
5.2.3 WiCoP Control Message Description . . . . . . . . . . 25
5.3 WiCoP Data Packet . . . . . . . . . . . . . . . . . . . . 34
5.4 WiCoP Timers . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.1 Active Presence Timer . . . . . . . . . . . . . . . . 35
5.4.2 Feedback Interval . . . . . . . . . . . . . . . . . . 35
5.4.3 Response Timer . . . . . . . . . . . . . . . . . . . . 35
5.4.4 Wireless Connectivity Timer . . . . . . . . . . . . . 36
6. WiCoP Processes . . . . . . . . . . . . . . . . . . . . . . . 37
6.1 Initialization . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Capabilities Exchange . . . . . . . . . . . . . . . . . . 37
6.3 Connection . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 Configuration . . . . . . . . . . . . . . . . . . . . . . 38
6.4.1 Logical Groups . . . . . . . . . . . . . . . . . . . . 38
6.4.2 Resource Control . . . . . . . . . . . . . . . . . . . 38
6.5 Operation . . . . . . . . . . . . . . . . . . . . . . . . 39
6.5.1 Updates . . . . . . . . . . . . . . . . . . . . . . . 39
6.5.2 Feedback and Statistics . . . . . . . . . . . . . . . 39
6.5.3 Non-periodic Events . . . . . . . . . . . . . . . . . 40
6.5.4 Firmware Trigger . . . . . . . . . . . . . . . . . . . 40
6.5.5 Wireless Terminal Management . . . . . . . . . . . . . 40
6.5.6 Key Configuration . . . . . . . . . . . . . . . . . . 41
7. Summary and Conclusion . . . . . . . . . . . . . . . . . . . . 43
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . 47
Iino, et al. Expires September 30, 2005 [Page 2]
Internet-Draft WiCoP March 2005
1. Requirements notation
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 [RFC2119].
Iino, et al. Expires September 30, 2005 [Page 3]
Internet-Draft WiCoP March 2005
2. Terminology
This document follows the terminologies of [I-D.ietf-capwap-arch] and
[I-D.ietf-capwap-objectives].
Iino, et al. Expires September 30, 2005 [Page 4]
Internet-Draft WiCoP March 2005
3. Introduction
The popularity of wireless local area networks (WLANs) has led to
numerous but incompatible designs and solutions. The CAPWAP
Architecture Taxonomy [I-D.ietf-capwap-arch] describes major
variations of these designs. Among them, the local-MAC and split-MAC
architecture designs are notable categories.
Wireless LAN Control Protocol (WiCoP) recognizes the major
architecture designs and presents a common platform on which WLAN
entities of different designs can be accommodated. This enables
interoperability among wireless termination points (WTPs) and WLAN
access controllers (ACs) of distinct architecture designs. WiCoP
therefore allows for cost-effective WLAN expansions. It can also
accommodate future developments in WLAN technologies. Figure 1
illustrates the WiCoP opertional structure in which distinct control
elements are utilized for local-MAC and split-MAC WTPs.
WiCoP also addresses the increasing trend in shared infrastructure
WLANs. Here, WLAN management needs to distinguish and isolate
control for the different logical groups sharing a single physical
WLAN. WiCoP manages WLANs through a series of tunnels that separate
traffic based on logical groups.
The WiCoP operational structure in Figure 1 shows that each WTP uses
a number of tunnels to distinguish and separate traffic for control
and for each logical group. The protocol allows for managing WLANs
in a manner consistent with the logical groups that share the
physical infrastructure.
Iino, et al. Expires September 30, 2005 [Page 5]
Internet-Draft WiCoP March 2005
Local-MAC WTP
+-------+ +-------+
| | | | Logical Groups
| (=====Control Tunnel======) |
| | | | ~~~~~~~
| | | | / /
| <=====Logical Group A=====> | / A /~~~~
| | | | / / /
| <=====Logical Group B=====> | ~~~~~~~ /~~~~
| | | | / B / /
| <=====Logical Group C=====> | ~~~~~~~ /
| | | | / C /
| | +-------+ ~~~~~~~
| |
| |
| AC |
| |
| | Split-MAC WTP
| |
| | +-------+ Logical Groups
| | | |
| [=====Control Tunnel======] | ~~~~~~~
| | | | / /
| | | | / 1 /~~~~
| <=====Logical Group 1=====> | / / /
| | | | ~~~~~~~ /
| <=====Logical Group 2=====> | / 2 /
| | | | ~~~~~~~
+-------+ +-------+
Figure 1
WiCoP enables collective management of WTPs and its operations
include;
i. WTP configuration
ii. Firmware distribution
iii. WLAN monitoring and statistics
iv. Terminal data management
v. Traffic tunneling
Iino, et al. Expires September 30, 2005 [Page 6]
Internet-Draft WiCoP March 2005
4. Protocol Overview
The Wireless LAN Control Protocol (WiCoP) focuses on enabling
interoperability in shared infrastructure WLANs. It is designed for
use with different wireless technologies. This document provides
both the general operations of WiCoP and also specific use-cases with
respect to IEEE 802.11 based systems.
The state machine for WiCoP is illustrated in Figure 2. Each state
represents a major process in WiCoP operation.
+-------------------------------------------+
| \
| \
V \
+-------------+ +-------------+ +-------------+
| |<--------| | | |
| Initial- | | Capabilities| | Connection |<----+
| ization | | Exchange | | | |
| |-------->| |-------->| | |
+-------------+ +-------------+ +-------------+ |
| |
| |
| |
| |
V |
+-------------+ |
| | |
+---->| Configur- | |
| | ation | |
| | | |
| +-------------+ |
| | |
| | |
| | |
| | /
| V /
| +--------------+ /
| | | /
+-----| |/
| Operation |
| |
+--------------+
Figure 2
Iino, et al. Expires September 30, 2005 [Page 7]
Internet-Draft WiCoP March 2005
The Capabilities Exchange state combines discovery of WTPs together
with inspection of their respective capabilities. This enables the
AC to determine if a communicating WTP is of local-MAC or split-MAC
design variant.
Security associations between WTPs and the AC are established within
the Connection state of WiCoP. The specific security mechanism is
not covered by WiCoP.
WiCoP configures WTPs within the Configuration state. This state
involves operations whose effects are primarily long-term.
The active operation of WTPs occurs in the Operation state. The
Operation state involves active control of WTPs and the WLAN.
Iino, et al. Expires September 30, 2005 [Page 8]
Internet-Draft WiCoP March 2005
5. WiCoP Format
WiCoP uses separate packets for control and data transfer between the
AC and WTPs. A common header is used for both types of packets in
which a single-bit flag distinguishes between them.
5.1 WiCoP Header
Figure 3 illustrates the WiCoP common header for control and data
packets.
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+
Figure 3
Version Field
This field indicates the protocol version.
'M' Field
The MAC-type field, 'M', distinguishes between local-MAC WTPs and
split-MAC WTPs. This field is used for interoperability between WTPs
of the two different designs. A '0' value indicates WiCoP exchanges
with a split-MAC WTP while a '1' value indicates WiCoP exchanges with
a local-MAC WTP.
'D' Field
The differentiator field, 'D', is used to distinguish between WTP
variants within a type of WTP design. The CAPWAP Architecture
Taxonomy [I-D.ietf-capwap-arch] illustrates that the split-MAC design
allows encryption/decryption to be performed at either the WTP or the
AC. The Architecture Taxonomy also indicates that the local-MAC
design allows authentication to take place at either the WTP or the
Iino, et al. Expires September 30, 2005 [Page 9]
Internet-Draft WiCoP March 2005
AC.
WiCoP acknowledges these major variants and accommodates them using
the 'D' field in conjunction with the 'M' field. So for a split-MAC
WTP, the 'D' field is used to indicate location of
encryption/decryption while for a local-MAC WTP, the 'D' field is
used to indicate location of authentication. The following table
highlights their usage.
'M' 'D' Description
0 0 Split-MAC WTP - Encryption/decryption is
performed at WTP
0 1 Split-MAC WTP - Encryption/decryption is
performed at AC
1 0 Local-MAC WTP - Authentication is
performed by WTP
1 1 Local-MAC WTP - Authentication is
performed by AC
'C' Field
This field distinguishes between a WiCoP control and WiCoP data
packet. Each type of information is tunneled separately across the
WiCoP interface between WTPs and the AC. A '0' value for the 'C'
field indicates a data packet while a '1' value indicates a control
packet.
'R' Field
The retransmission field, 'R', is used to differentiate between first
and subsequent transmission of WiCoP packets. The 'R' field is used
for critical WiCoP packets such as those relating to security key
exchanges. A '0' value for the 'R' field indicates the first
transmission of a WiCoP packet while a '1' value indicates a
retransmission.
'E' Field
The encryption field, 'E', is used to indicate if the WiCoP packet is
encrypted between the AC and WTPs. The 'E' field is used for those
WiCoP packets that are exchanged during initialization. A '0' value
indicates the WiCoP packet is unencrypted while a '1' value indicates
the packet is encrypted.
Iino, et al. Expires September 30, 2005 [Page 10]
'F' Field
The fragmentation field indicates if the packet is a fragment of a
larger packet. A '0' value indicates a non-fragmented packet while a
'1' value indicates a fragmented packet. The 'F', 'L', 'Fragment ID'
and 'Fragment No.' fields are used together.
'L' Field
This field is used to indicate the last fragment of a larger packet.
It is only valid when the 'F' field has a '1' value. A '0' value for
the 'L' field indicates the last fragment of a larger packet while a
'1' value indicates an intermediate fragment of a larger packet. The
'F', 'L', 'Fragment ID' and 'Fragment No.' fields are used together.
Fragment ID Field
The Fragment ID identifies the larger packet which has been
fragmented. It is used to distinguish between fragments of different
large packets. This field is valid only when the 'F' field has a '1'
value. The 'F', 'L', 'Fragment ID' and 'Fragment No.' fields are
used together.
Fragment No. Field
The fragment number field identifies the sequence of fragments of a
larger packet. The value of the Fragment No. field is incremented
for each fragment of a larger packet so as to show the order of
fragments. This field is valid only when the 'F' field has a '1'
value. The 'F', 'L', 'Fragment ID' and 'Fragment No.' fields are
used together.
Length Field
This field specifies the length of the WiCoP payload following the
header.
5.2 WiCoP Control Packet
The WiCoP control header follows the WiCoP common header. It is
highlighted in Figure 5.
Iino, et al. Expires September 30, 2005 [Page 11]
Internet-Draft WiCoP March 2005
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+---------------+-------------------------------+
| Msg Type | Reserve | Seq Num |
+---------------+---------------+-------------------------------+
| Msg Element Length |
+-------------------------------+
Figure 5
The control packet adds four additional fields to the common header.
These are described below;
Msg Type Field
The message type field specifies the type of control message
transported in the packet. The list of control messages is presented
below.
Seq Num Field
The sequence number field is used to map WiCoP request and response
sequences. The initiator of a WiCoP request message increments the
Seq Num field for each new request message. The responder then uses
these values of the Seq Num fields in its corresponding response
messages.
Msg Element Length Field
This field specifies the length in bytes of the subsequent WiCoP
control message element.
5.2.1 WiCoP Control Messages
The list of WiCoP control messages is shown below;
Iino, et al. Expires September 30, 2005 [Page 12]
Internet-Draft WiCoP March 2005
Message Msg Type
------------------------------------------------------------
Capabilities 1
Capabilities Response 2
Connection 3
Connection Response 4
Configuration Request 5
Configuration Response 6
Configuration Data 7
Configuration Data Response 8
Configuration Trigger 9
Configuration Trigger Response 10
Feedback 11
Feedback Response 12
Reset 13
Reset Response 14
Firmware Trigger 15
Firmware Trigger Response 16
Terminal Addition 17
Terminal Additiona Response 18
Terminal Deletion 19
Terminal Deletion Response 20
Key Configuration 21
Key Configuration Response 22
Notification 23
Notification Response 24
5.2.2 WiCoP Control Message Elements
WiCoP control messages each include a control message header followed
by one or more message elements. The message elements are shown in
the following table.
Iino, et al. Expires September 30, 2005 [Page 13]
Internet-Draft WiCoP March 2005
+-----------------+-----------+-------------------------------------+
| Message Element | Type | Description |
+-----------------+-----------+-------------------------------------+
| WTP Info | 1 | Information regarding WTPs, such as |
| | | manufacturer ID, MAC address, etc. |
| | | |
| Cap from WTP | 2 | QoS abilities (WME) and security |
| | | abilities (IEEE 802.11i) are |
| | | included |
| | | |
| Conf If Data | 3 | PHY information for each wireless |
| | | interface |
| | | |
| Conf WTP Data | 4 | Information regarding logical |
| | | groups on a per-logical group basis |
| | | (e.g. per-virtual AP) |
| | | |
| Cap to WTP | 5 | Setup data sent to WTPs by AC on a |
| | | per-logical group basis |
| | | |
| QoS Value | 6 | QoS setup (access categories) |
| | | |
| Timer Init | 7 | Initial values of timers such as |
| Value | | aging, echo interval etc. |
| | | |
| Terminal Data | 8 | Information relevant to wireless |
| | | terminals - BSSID, association ID, |
| | | etc. |
| | | |
| BSSID | 9 | BSSID, and terminal MAC address |
| | | |
| Encryption Data | 10 | Details of the security framework - |
| | | cipher suit, operation mode etc. |
| | | |
| EAP Frame | 11 | EAP frame |
| | | |
| Statistics | 12 | Various statistics information - |
| | | transmission attempts, FCS errors |
| | | etc. |
| | | |
| Interface Error | 13 | Type of wireless interface failure |
| | | |
| FROM Error | 14 | Flash ROM Error information |
| | | |
| QoS Capability | 15 | Network congestion information |
| | | |
| TFTP Data | 16 | Firmware related details |
| | | |
Iino, et al. Expires September 30, 2005 [Page 14]
Internet-Draft WiCoP March 2005
| Result | 17 | Result of protocol operations - |
| | | success or failure |
| | | |
| OID | 18 | SNMP OIDs |
| | | |
| MIC Flag | 19 | Location of KeyMIC calculation |
+-----------------+-----------+-------------------------------------+
Each message element comprises a number of information items that are
detailed below. The length of each information item is specified in
bytes.
WTP Info:
Information included in the WTP Info message element is provided on a
per-WTP basis. So each WTP exchanges one WTP Info message element.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Manufacturer | 8 | DisplayString | Manufacturer ID |
| ID | | | |
| | | | |
| MAC Address | 6 | PhyAddress | WTP MAC Address |
| | | | |
| Firmware | 8 | DisplayString | Firmware version of |
| Version | | | WTP |
| | | | |
| Start Time | 4 | TimeTicks | Starting time of WTP |
| | | | (UNIX Time) |
+--------------+----------+----------------+------------------------+
Cap from WTP:
Information included in the Cap from WTP message element is provided
on a per-WTP basis. So each WTP exchanges one Cap from WTP message
element.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| 802.11e Cap | 2 | Integer | Length of 802.11e |
| Length | | | Capabilities |
| | | | |
| 802.11e | Variable | OCTETString | 802.11e capabilities |
| Capabilities | | | of WTP. If WTP does |
Iino, et al. Expires September 30, 2005 [Page 15]
Internet-Draft WiCoP March 2005
| | | | not have such |
| | | | capabilities, this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| 802.11i Cap | 2 | Integer | Length of 802.11i |
| Length | | | Capabilities |
| | | | |
| 802.11i | Variable | OCTETString | 802.11i capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities,this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| AuthType | 2 | OCTETString | Type of authentication |
| | | | mechanism used between |
| | | | WTP and AC |
+--------------+----------+----------------+------------------------+
Conf If Data
The Conf If Data message element relates to the wireless interface.
So a WTP with many interfaces will include corresponding numbers of
Conf If Data message elements within the WiCoP control messages.
Conf If Data message elements are indexed by the If ID information
item.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| If ID | 1 | Integer | Denotes identification |
| | | | of a wireless |
| | | | interface |
| | | | |
| Current | 1 | Integer | Current Power Level |
| Power | | | ('1' = Max; '2' = 1/2; |
| | | | '3' = 1/4; '4' = 1/8 |
| | | | |
| Radio | 1 | Integer | Radio channel of |
| Channel | | | operation |
| | | | |
| 2Dot4Mode | 1 | Integer | Interface mode in |
| | | | 2.4GHz. ('1' = IEEE |
| | | | 802.11b; '2' = IEEE |
| | | | 802.11g; '3' = Both) |
+--------------+----------+----------------+------------------------+
Iino, et al. Expires September 30, 2005 [Page 16]
Internet-Draft WiCoP March 2005
Conf WTP Data
Configuration information is provided on the basis of logical groups
or BSSIDs. So there are multiple Conf WTP Data message elements to
address the many logical groups within a WLAN managed by WiCoP. Conf
WTP Data message elements are indexed by the BSSID information item.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| ESSID | 32 | OCTETString | ESSID |
| | | | |
| BSSID - | 32 | OCTETString | Mapping for logical |
| TunnelID | | | groups across BSSID |
| | | | and WiCoP tunnels |
| | | | |
| Beacon | 1 | Integer | Time interval between |
| Period | | | Beacon transmissions |
| | | | |
| DTIM Period | 1 | Integer | DTIM period of Beacon |
| | | | transmissions |
| | | | |
| AnyRejectFla | 1 | Integer | Flag indicating WTP |
| g | | | rejection of any Probe |
| | | | Request within any |
| | | | SSID - ('1' = |
| | | | Rejected; '2' = Not |
| | | | Rejected) |
| | | | |
| SSID Stealth | 1 | Integer | Flag indicating |
| Flag | | | inclusion of ESSID |
| | | | within Beacon Frames |
| | | | ('1' = ESSID included; |
| | | | '2' = ESSID not |
| | | | included) |
| | | | |
| Operation | 2 | Integer | Data rates supported |
| Rate Set | | | by WTP for terminal |
| | | | being added using 12 |
| | | | bit format for 1.1, |
| | | | 2.2, 3.55, 4.6, 5.9, |
| | | | 6.11, 7.12, 8.18, |
| | | | 9.24, 10.36, 11.48 and |
| | | | 12.54 Mbps |
| | | | |
Iino, et al. Expires September 30, 2005 [Page 17]
Internet-Draft WiCoP March 2005
| Encryption | 1 | Integer | Encryption Type - |
| Type | | | ê'1' = OFF; '2' = |
| | | | WEP40; '3' = WEP104; |
| | | | '4' = WEP128) |
| | | | |
| Encryption | 16 | OCTETString | Static Encryption Key |
| Key | | | |
+--------------+----------+----------------+------------------------+
Cap to WTP:
Capabilities information is provided on the basis of logical groups
or virtual APs. So there are multiple Cap to WTP message elements to
address the many logical groups within a WLAN managed by WiCoP. Conf
to WTP message elements are indexed by the BSSID information item.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| 802.11e Cap | 2 | Integer | Length of 802.11e |
| Length | | | Capabilities |
| | | | |
| 802.11e | Variable | OCTETString | 802.11e capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities, this |
| | | | field is filled with |
| | | | '0' |
| | | | |
| 802.11i Cap | 2 | Integer | Length of 802.11i |
| Length | | | Capabilities |
| | | | |
| 802.11i | Variable | OCTETString | 802.11i capabilities |
| Capabilities | | | of WTP. If WTP does |
| | | | not have such |
| | | | capabilities,this |
| | | | field is filled with |
| | | | '0' |
+--------------+----------+----------------+------------------------+
QoS Value:
QoS parameters are assigned for each logical groups to address their
respective individual conditions and requirements. QoS Value message
Iino, et al. Expires September 30, 2005 [Page 18]
Internet-Draft WiCoP March 2005
elements are provided on a per-logical group basis. QoS Value
message elements are indexed by the BSSID information item.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| WTP AC_BE | 2 | Integer | AC Parameters Record |
| | | | AC_BE in WTP |
| | | | |
| WTP AC_BK | 2 | Integer | AC Parameters Record |
| | | | AC_BK in WTP |
| | | | |
| WTP AC_VI | 2 | Integer | AC Parameters Record |
| | | | AC_VI in WTP |
| | | | |
| WTP AC_VO | 2 | Integer | AC Parameters Record |
| | | | AC_VO in WTP |
| | | | |
| TE AC_BE | 2 | Integer | AC Parameters Record |
| | | | AC_BE in terminals |
| | | | |
| TE AC_BK | 2 | Integer | AC Parameters Record |
| | | | AC_BK in terminals |
| | | | |
| TE AC_VI | 2 | Integer | AC Parameters Record |
| | | | AC_VI in terminals |
| | | | |
| TE AC_VO | 2 | Integer | AC Parameters Record |
| | | | AC_VO in terminals |
+--------------+----------+----------------+------------------------+
Timer Init Value:
WiCoP timers are used for the WTP as a whole. So the Timer Init
Value message element is provided on a per-WTP basis.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | OCTETString | BSSID |
| | | | |
| Response | 4 | Integer | Initial value of |
| Timer | | | Response Timer |
| | | | |
| Active | 4 | Integer | Initial value of |
Iino, et al. Expires September 30, 2005 [Page 19]
Internet-Draft WiCoP March 2005
| Presence | | | Active Presence Timer |
| Timer | | | |
| | | | |
| Feedback | 4 | Integer | Initial value of |
| Interval | | | Feedback Interval |
| Timer | | | Timer |
+--------------+----------+----------------+------------------------+
Terminal Data:
The Terminal Data message element is applicable for both local-MAC
and split-MAC WTP designs. In the case of local-MAC, Terminal Data
is sent from WTPs to the AC. In the case of split-MAC, Terminal Data
is sent from the AC to WTPs. So the direction of usage depends on
the type of WTP at which wireless terminal operations are performed.
Some information items may be optional for use with specific WTP
designs.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | PhyAddress | BSSID in which |
| | | | terminal is being |
| | | | added |
| | | | |
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal being added |
| | | | |
| Association | 2 | Integer | Association ID of |
| ID | | | terminal being added |
| | | | |
| Operation | 2 | Integer | Data rates supported |
| Rate Set | | | by WTP for terminal |
| | | | being added using 12 |
| | | | bit format for 1.1, |
| | | | 2.2, 3.55, 4.6, 5.9, |
| | | | 6.11, 7.12, 8.18, |
| | | | 9.24, 10.36, 11.48 and |
| | | | 12.54 Mbps |
| | | | |
| Listen | 2 | Integer | Listen period |
| Period | | | |
+--------------+----------+----------------+------------------------+
BSSID:
Iino, et al. Expires September 30, 2005 [Page 20]
Internet-Draft WiCoP March 2005
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| BSSID | 6 | PhyAddress | BSSID in which |
| | | | terminal is being |
| | | | added |
| | | | |
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal being added |
+--------------+----------+----------------+------------------------+
Encryption Data:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal |
| | | | |
| Operation | 1 | Integer | Operational Mode ('1' |
| | | | = Set Key; '2' = |
| | | | Delete Key) |
| | | | |
| Key Index | 1 | Integer | Key Index - valid when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Key Flag | 1 | Integer | Key Flag ('1' = |
| | | | Unicast Key or PTK; |
| | | | '2' = Broadcast Key or |
| | | | GTK) - valid only when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Cipher Suit | 1 | Integer | Encryption Type ('1' = |
| | | | WEP40; '2' = WEP104; |
| | | | '3' = WEP128; '4' = |
| | | | TKIP; '5' = AES) - |
| | | | valid only when |
| | | | Operational Mode = Set |
| | | | Key |
| | | | |
| Key | 32 | OCTESTString | Key body - valid only |
| | | | when Operational Mode |
| | | | = Set Key |
+--------------+----------+----------------+------------------------+
Iino, et al. Expires September 30, 2005 [Page 21]
Internet-Draft WiCoP March 2005
EAP Frame:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| MAC Address | 6 | PhyAddress | MAC address of |
| | | | terminal |
| | | | |
| EAP | Variable | OCTETString | EAP Frames |
+--------------+----------+----------------+------------------------+
Statistics:
Statistics information covers all aspects of WTPs. As such, this
message element is provided on a per-WTP basis.
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| OutOctet | 4 | Counter 32 | Octet number of frame |
| | | | WTP transmits |
| | | | |
| Transmit | 4 | Counter 32 | Total number of frames |
| Count | | | transmitted by WTP |
| | | | |
| Successful | 4 | Counter 32 | Total number of ACKs |
| Transmit | | | received |
| Count | | | |
| | | | |
| ACK Failure | 4 | Counter 32 | Total number of failed |
| Count | | | ACKs |
| | | | |
| InOctets | 4 | Counter 32 | Octet number of frame |
| | | | WTP receives |
| | | | |
| Receive | 4 | Counter 32 | Total number of frames |
| Count | | | received by WTP |
| | | | |
| Receive | 4 | Counter 32 | Total number of |
| Discard | | | received frames that |
| | | | are discarded |
| | | | |
| Retransmissi | 4 | Counter 32 | Number of WTP |
| on Count | | | retransmission |
| | | | attempts" |
| | | | |
Iino, et al. Expires September 30, 2005 [Page 22]
Internet-Draft WiCoP March 2005
| Duplicate | 4 | Counter 32 | Number of duplicate |
| Recieve | | | frames received by WTP |
| Count | | | |
| | | | |
| FCS Error | 4 | Counter32 | Number to frames |
| Receive | | | received with FCS |
| Count | | | errors |
| | | | |
| Unknown | 4 | Counter 32 | Number of unknown |
| Frame | | | protocol frames |
| Receive | | | received |
| Count | | | |
| | | | |
| Beacon | 4 | Counter 32 | Number of transmitted |
| Transmit | | | Beacon frames |
| Count | | | |
| | | | |
| Probe | 4 | Counter 32 | Number of transmitted |
| Transmit | | | Probe Response frames |
| Count | | | |
| | | | |
| Probe | 4 | Counter 32 | Number of received |
| Receive | | | Probe Response frames |
| Count | | | |
| | | | |
| Decrypt CRC | 4 | Counter 32 | Number of received |
| Error Count | | | frames that cannot |
| | | | decrypt |
+--------------+----------+----------------+------------------------+
Interface Error:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Interface | 1 | Integer | Interface ID |
| Index | | | |
| | | | |
| Error Type | 1 | Integer | Type of error ('1' = |
| | | | Unrecoverable; '2' = |
| | | | Recoverable) |
+--------------+----------+----------------+------------------------+
FROM Error:
Iino, et al. Expires September 30, 2005 [Page 23]
Internet-Draft WiCoP March 2005
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| FROM Index | 1 | Integer | FROM ID |
| | | | |
| Error Type | 1 | Integer | Type of error ('1' = |
| | | | Unrecoverable; '2' = |
| | | | Recoverable) |
+--------------+----------+----------------+------------------------+
QoS Capability:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| EDCA | 1 | Integer | EDcA Capability ('1' = |
| | | | Capable; '2' = Not |
| | | | capable) |
| | | | |
| HCCA | 1 | Integer | HCcA Capability ('1' = |
| | | | Capable; '2' = Not |
| | | | capable) |
+--------------+----------+----------------+------------------------+
TFTP Data:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| TFTP Data | Variable | OCTETString | Details of TFTP |
+--------------+----------+----------------+------------------------+
Result:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Result Code | 1 | Integer | '1' = OK; '2' = NG |
+--------------+----------+----------------+------------------------+
OID:
Iino, et al. Expires September 30, 2005 [Page 24]
Internet-Draft WiCoP March 2005
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| Length | 1 | Integer | Length of OID String |
| | | | and OID Value |
| | | | |
| OID String | Variable | OCTETString | Object Indentifier |
| | | | that is assigned |
| | | | according to Basic |
| | | | Encoding Rules (BER) |
| | | | |
| Value | Variable | OCTETString | Value |
+--------------+----------+----------------+------------------------+
MIC Flag:
+--------------+----------+----------------+------------------------+
| Item | Length | Syntax | Description |
+--------------+----------+----------------+------------------------+
| MIC Flag | 1 | Integer | Determines the entity |
| | | | calculating MIC ('1' = |
| | | | AC; '2' = WTP) |
+--------------+----------+----------------+------------------------+
5.2.3 WiCoP Control Message Description
Message: Capabilities
Type: Request
Description: WTPs broadcast Capabilities message when they are
powered on. The message serves to discover and identify the
controlling AC and to provide it with information regarding the
capabilities of the WTP. This includes specifying whether the WTP is
of local-MAC or split-MAC design and radio capabilities. In the IEEE
802.11 use-case, Capabilities also specifies whether the WTP can
perform encryption and authentication.
TLV: The Capabilities message includes message elements of types 1
and 2.
+----------------+
| Capabilities |
+----------------+
| WTP Info |
Iino, et al. Expires September 30, 2005 [Page 25]
Internet-Draft WiCoP March 2005
| |
| Cap from WTP |
+----------------+
Message: Capabilities Response
Type: Response
Description: This message is sent by an AC after examining the
compatibility of the WTP and its capabilities. The compatibility is
with respect to the MAC architecture that can be supported. If the
WTP is determined to be compatible, the Capabilities Response message
also contains information on the capabilities of the AC.
TLV: The Capabilities Response message includes message elements of
types 5 and 17.
+-----------------------+
| Capabilities Response |
+-----------------------+
| Cap to WTP 1 |
| |
| Cap to WTP ... |
| |
| Cap to WTP n |
| |
| Result |
+-----------------------+
Message: Connection
Type: Request
Description: The Connection message initiates the mutual security
association between AC and WTPs. The specific security mechanism for
the authentication is out of scope of the WiCoP specifications.
TLV: The Connection message includes message elements of type 2.
+----------------+
| Connection |
+----------------+
| Cap from WTP |
+----------------+
Iino, et al. Expires September 30, 2005 [Page 26]
Internet-Draft WiCoP March 2005
Message: Connection Response
Type: Response
Description: This message indicates the result of the WTP-AC security
association. If successful, it also represents the admission of the
WTP into the WLAN.
TLV: Type 17 message element is included.
+---------------------+
| Connection Response |
+---------------------+
| Result |
+---------------------+
Message: Configuration Request
Type: Request
Description: This message starts the Configuration state of WiCoP.
It is a request for configuration information from the WTPs to the
AC.
Message: Configuration Response
Type: Response
Description: This is an acknowledgement for the Configuration Request
message.
TLV: Type 17 message element is included.
+------------------------+
| Configuration Response |
+------------------------+
| Result |
+------------------------+
Message: Configuration Data
Type: Request
Description: Configuration information including operational
parameters is sent using the Configuration Data message. This
Iino, et al. Expires September 30, 2005 [Page 27]
Internet-Draft WiCoP March 2005
message is also used for configuration updates in the Operation state
of WiCoP.
TLV: This message includes message elements of type 3, 4, 5, 6 and 7.
+---------------------+
| Configuration Data |
+---------------------+
| Conf If Data 1 |
| |
| Conf If Data ... |
| |
| Conf If Data n |
| |
| Conf WTP DATA 1 |
| |
| Conf WTP DATA ... |
| |
| Conf WTP DATA n |
| |
| Cap to WTP 1 |
| |
| Cap to WTP ... |
| |
| Cap to WTP n |
| |
| QoS Value 1 |
| |
| QoS Value ... |
| |
| QoS Value n |
| |
| Timer Init Value |
+---------------------+
Message: Configuration Data Response
Type: Response
Description: This is an acknowledgement for the Configuration Data
message.
TLV: Type 17 message element is included.
+-----------------------------+
| Configuration Data Response |
+-----------------------------+
Iino, et al. Expires September 30, 2005 [Page 28]
Internet-Draft WiCoP March 2005
| Result |
+-----------------------------+
Message: Configuration Trigger
Type: Request
Description: This message is used to trigger the activation of the
configuration information sent in earlier Configuration messages.
Message: Configuration Trigger Response
Type: Response
Description: This is an acknowledgement of the Configuration Trigger.
This response message is sent before activation of the configuration
information.
TLV: Message elements of type 17 are included.
+--------------------------------+
| Configuration Trigger Response |
+--------------------------------+
| Result |
+--------------------------------+
Message: Reset
Type: Request
Description: This message from the AC instructs the WTP to clear
registers and revert to initial conditions.
Message: Reset Response
Type: Response
Description: This is an acknowledgement for the Reset message to the
AC.
TLV: Message elements of type 17 are included.
+----------------+
| Reset Response |
Iino, et al. Expires September 30, 2005 [Page 29]
Internet-Draft WiCoP March 2005
+----------------+
| Result |
+----------------+
Message: Feedback
Type: Request
Description: This message is used to send regular statistics
information from WTPs to the AC. Additionally, it acts as a
keepalive indicator for WTPs that is used to update the Active
Presence Timer. Feedback is also used by the AC to determine the
active state of WTPs.
TLV: This message includes message elements of type 12.
+--------------+
| Feedback |
+--------------+
| Statistics |
+--------------+
Message: Feedback Response
Type: Response
Description: This is an acknowledgement for Feedback messages.
TLV: Message elements of type 17 are included.
+-------------------+
| Feedback Response |
+-------------------+
| Result |
+-------------------+
Message: Firmware Download
Type: Request
Description: This message is used to instruct WTPs to update their
firmware. The message element contains information regarding the new
firmware.
TLV: Message elements of type 16 are included.
Iino, et al. Expires September 30, 2005 [Page 30]
Internet-Draft WiCoP March 2005
+-------------------+
| Firmware Download |
+-------------------+
| TFTP Data |
+-------------------+
Message: Firmware Download Response
Type: Request Response
Description: This is an acknowledgement for the Firmware Download
message.
TLV: Message elements of type 17 are included.
+----------------------------+
| Firmware Download Response |
+----------------------------+
| Result |
+----------------------------+
Message: Notification
Type: Request
Description: This message is used to indicate non-periodic events.
It may be sent by either WTPs or the AC. Notification messages
indicate failures, non-periodic changes etc.
TLV: Message elements of types 13 and 14 are included.
+-------------------+
| Notification |
+-------------------+
| Interface Error |
| |
| FROM Error |
+-------------------+
Message: Notification Response
Type: Response
Description: This is an acknowledgement for the Notification message.
It may be followed by Configuration messages to rectify errors.
Iino, et al. Expires September 30, 2005 [Page 31]
Internet-Draft WiCoP March 2005
TLV: Message elements of type 17 are included.
+-----------------------+
| Notification Response |
+-----------------------+
| Result |
+-----------------------+
Message: Terminal Addition
Type: Request
Description: This message can be sent from WTPs or the AC. In both
cases it is sent in response to an IEEE 802.11 association frame.
For split-MAC WTPs, Terminal Addition is sent from the AC to the WTPs
and includes information on the wireless terminal relevant to the
WTP.
For local-MAC WTPs, Terminal Addition is sent from a WTP to the AC
and contains information on the wireless terminal relevant to the AC.
TLV: Message elements of type 8 are included.
+-------------------+
| Terminal Addition |
+-------------------+
| Terminal Data |
+-------------------+
Message: Terminal Addition Response
Type: Response
Description: This is an acknowledgement sent from either WTPs or the
AC depending on the WiCoP interface.
TLV: Message elements of type 17 are included.
+----------------------------+
| Terminal Addition Response |
+----------------------------+
| Result |
+----------------------------+
Iino, et al. Expires September 30, 2005 [Page 32]
Internet-Draft WiCoP March 2005
Message: Terminal Deletion
Type: Request
Description: This message is sent in response to a disconnection of a
wireless terminal. It can be sent from WTPs of the AC. In both
cases, Terminal Deletion instructs the recipient to remove any state
information relating to the specific wireless terminal. The message
is sent in response to an IEEE 802.11 disassociation frame, IEEE
802.11 deauthentication frame or due to the expiration of the Active
Presence Timer.
For split-MAC WTPs, Terminal Deletion is sent from the AC to the
WTPs.
For local-MAC WTPs, Terminal Deletion is sent from the WTPs to the
AC.
TLV: Message elements of type 9 are included.
+-------------------+
| Terminal Deletion |
+-------------------+
| BSSID |
+-------------------+
Message: Terminal Deletion Response
Type: Response
Description: This is an acknowledgement sent from either WTPs or the
AC depending on the WiCoP interface.
TLV: Message elements of type 17 are included.
+----------------------------+
| Terminal Addition Response |
+----------------------------+
| Result |
+----------------------------+
Message: Key Configuration
Type: Request
Description: This message is used when 'M' = 0 and 'D' = 1. It is
Iino, et al. Expires September 30, 2005 [Page 33]
Internet-Draft WiCoP March 2005
used to configure security key information from the AC to the WTPs.
TLV: The following message elements are included for Key
Configuration.
+-------------------+
| Key Configuration |
+-------------------+
| MIC Flag |
| |
| Encryption Data |
| |
| EAP Frame |
+-------------------+
Message: Key Configuration Response
Type: Response
Description: This is an acknowledgement for the Key Configuration
message.
TLV: Message elements of type 17 are included.
+----------------------------+
| Key Configuration Response |
+----------------------------+
| Result |
+----------------------------+
5.3 WiCoP Data Packet
WiCoP data packets include the WiCoP common header followed by a
payload. Data packets are used to distinguish traffic from control
when both control and data paths are identical. Such a scenario
would involve data traffic of the WTPs traversing the AC. However,
given the diversity of large-scale WLAN deployments, there are
scenarios in which data and control paths are distinct. WiCoP can be
used in both cases.
The WiCoP data packet format is illustrated below in Figure 7
together with the WiCoP common header.
Iino, et al. Expires September 30, 2005 [Page 34]
Internet-Draft WiCoP March 2005
0 31
| 7 15 23 |
|-------|-------|-------|-------|-------|-------|-------|-------|
| |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Version |M|D|C|R|E|F|L| | Reserve |
+---------------+-+-+-+-+-+-+-+-+-------------------------------+
| Fragment ID | Fragment No. | Length |
+---------------+---------------+-------------------------------+
| Paylaod |
+---------------------------------------------------------------+
Figure 7
5.4 WiCoP Timers
WiCoP uses a number of timers to determine WLAN status and maintain
system performance. Timers are maintained by all WiCoP entities.
The timers are described in this section.
5.4.1 Active Presence Timer
The Active Presence Timer is used by each WiCoP entity Çô AC and
WTPs - to verify the presence of each other. The absence of a reply
to the Feedback message within the expiration of the Active Presence
Timer indicates the corresponding entity is inactive. Contingency
operations such as reset are used in this case. The value of the
Active Presence Timer ranges from 10 to 300 seconds with a default
value of 30 seconds.
5.4.2 Feedback Interval
Feedback messages are periodic with the frequency defined by the
Feedback Interval. The interval is set during WTP configuration. It
has a value ranging from 1 to 100 seconds and a default value of 10
seconds.
5.4.3 Response Timer
This is a general purpose timer used to limit the elapsed time
between transmission of a request message and receipt of a
corresponding response message. The value of this timer ranges from
1 to 3 seconds with a default value of 1 second.
Iino, et al. Expires September 30, 2005 [Page 35]
Internet-Draft WiCoP March 2005
5.4.4 Wireless Connectivity Timer
This timer triggers any changes in wireless connectivity. WiCoP uses
this timer to send Notification and other messages relating to
wireless conditions. It is also used to trigger the disconnection of
mobile terminals without disassociation. The value of the Wireless
Connectivity Timer ranges from 1 minute to 86,400 minutes with a
default value of 10 minutes.
Iino, et al. Expires September 30, 2005 [Page 36]
Internet-Draft WiCoP March 2005
6. WiCoP Processes
The processes of the Wireless LAN Control Protocol are described in
this section with respect to the operational state in which they
occur.
6.1 Initialization
The initialization state represents the initial state of WiCoP
entities. Hardware is initialized and the WiCoP entities remain in
their respective base system conditions.
6.2 Capabilities Exchange
WiCoP is designed to control WLANs with both local-MAC and split-MAC
WTPs. Since there are differences in the functional characteristics
these two types of WTPs, WiCoP first determines their specific
capabilities.
So in the Capabilities Exchange state, a WTP first broadcasts a
Capabilities message to find its AC. The AC receiving the message
examines the compatibility of the WTPÇÖs capabilities and responds
with an appropriate Capabilities Response message.
A WTP continues to send Capabilities messages at an interval
specified by the Response Timer until it receives a Capabilities
Response message.
In the Capabilities Exchange state, there is a limit of connection
attempts after which the AC ignores the WTP. This is to ensure that
rogue WTPs which are not compatible with the AC do not repeatedly
attempt connections. The limit of connection attempts is 3 within 60
seconds.
6.3 Connection
A Connection message from WTP to the AC indicates a transition to the
Connection state and triggers the mutual security association. At
this point, the AC and WTPs first authenticate each other. Here,
authentication information such as EAP messages are transported in
WiCoP Connection messages.
At the end of successful mutual authentication, subsequent WiCoP
exchanges are secured based on the type of underlying transport.
Given the predominance of IP, WiCoP exchanges are secured by IPSEC.
Successful establishment of the security association results in the
AC admitting the WTP in the WLAN with a successful Connection
Iino, et al. Expires September 30, 2005 [Page 37]
Internet-Draft WiCoP March 2005
Response message. Failure of the security association results in a
transition back to the Initialization state. During the security
association setup, the AC monitors the receipt of WiCoP control
messages to prevent replay attacks.
The security association between AC and WTPs covers mutual
authentication and also protection for integrity, confidentiality and
modification protection for subsequent traffic exchanges.
6.4 Configuration
The Configuration state is triggered by the Configuration Request
message from a WTP. In this state, the WiCoP interface with respect
to the WTP architecture is established. So the differences between
local-MAC and split-MAC designs are accommodated by means of the
interface setup.
The AC acknowledges the Configuration Request with a Configuration
Response message, after which it sends configuration information in
Configuration messages. Where appropriate, WiCoP includes MIB
objects as the message element of Configuration messages. The use of
MIB objects simplifies WTP configuration. A number of Configuration
messages are sent for which each is acknowledged with a Configuration
Response message.
6.4.1 Logical Groups
Configuration messages are used to establish logical groups in the
WLAN and also to separate traffic among them. In the IEEE 802.11
use-case, logical groups are established on the basis of BSSIDs and
are separated over the WiCoP interface using tunnels. The
BSSID-TunnelID parameter in the Configuration message maps logical
groups across the wireless and WiCoP interfaces. Tunnels may be
based on VLANs, IP tunnels or other technologies. WiCoP enables
traffic separation by establishing links between the tunnels and
logical groups.
6.4.2 Resource Control
The Configuration messages are also used to establish operational QoS
information at WTPs. In particular, the EDCA related message
elements are used to specify QoS information to be configured at the
wireless terminals in each logical group. WiCoP enables the central
AC to supervise QoS settings in the entire WLAN. The EDCA message
elements also include QoS information necessary at the WTPs.
Iino, et al. Expires September 30, 2005 [Page 38]
Internet-Draft WiCoP March 2005
6.5 Operation
The Operation state of WiCoP commences after the exchange of all
relevant Configuration information and when the AC sends a
Configuration Trigger message to the WTP. This message informs the
WTP to begin operations based on the configuration information sent
earlier. After activating the configuration information, the WTP
replies with a Configuration Trigger Response message.
6.5.1 Updates
The dynamic nature of WLAN systems requires regular updates to
network operations. So in the Operation state, WiCoP allows the AC
to exchange additional configuration information with the
Configuration message. The WTP activates configuration update
information upon receiving the Configuration Trigger message from the
AC.
Configuration updates can be used to clear statistics information by
reflecting initial values.
An extreme case of configuration update involves use of the Reset
message from the AC, which instructs the WTP to revert to initial
conditions. The WTP replies with a Reset Response message before
reverting to its initial state.
6.5.2 Feedback and Statistics
The Operation state also sees regular feedback being sent by WTPs to
the AC. The WTPs use Feedback messages to send statistics
information that have been gathered. Feedback messages are sent with
a frequency defined by the Feedback Interval. In addition to
statistics, the Feedback message also serves as a WTP keepalive
indicator to the AC. So Feedback messages combine statistics
information together with WTP status information.
Feedback messages also contain information on the state of congestion
at mobile terminals and WTPs. So it includes parameters specifying
the channel interference and queue levels. This information enables
the AC to adapt its downstream transmissions so as to relieve
congestion. One example is for the AC to schedule transmissions away
from the congested WTPs.
The AC additionally uses the Feedback message to randomly determine
the active state of WTPs. An active WTP replies with a corresponding
Feedback Response message.
Iino, et al. Expires September 30, 2005 [Page 39]
Internet-Draft WiCoP March 2005
6.5.3 Non-periodic Events
The Notification message is used for non-periodic events. It is used
to indicate error conditions or drastic changes in congestion state.
It can be sent from either WTPs or the AC. A Notification Response
message is sent in reply to this. The response may contain
information on rectifying the error or may simply be an
acknowledgement of the Notification.
6.5.4 Firmware Trigger
The Firmware Download message is used to trigger WTPs to to update
their firmware to the most recent version available. This message
contains TFTP information which the WTP uses to receive firmware.
WTPs reply with the Firmware Download Response message before
activating the new firmware.
6.5.5 Wireless Terminal Management
The Operation state of WiCoP also involves configuration of WTPs and
the AC with wireless terminal specific information.
Here the Terminal Addition message is used in response to a new
wireless terminal entering the WLAN. This message may be sent by
either the WTPs or the AC depending on the WiCoP interface being
used. The recipient of this message replies with the Terminal
Addition Response message.
The Terminal Deletion message is used when a wireless terminal leaves
the WLAN. This is used to delete state information that was
maintained by either the WTPs or the AC. It is acknowledged with the
Terminal Deletion Response message.
Figure 8 below illustrates the exchange of Terminal Addition and
Terminal Deletion messages for both local-MAC and split-MAC based
WiCoP interfaces.
Here the WiCoP Terminal Addition message is triggered as a response
to IEEE 802.11 Association message. In the case of local-MAC
architecture, the WTP sends the message to the AC. However, in the
split-MAC architecture, Terminal Addition is sent from AC to the WTP.
+----------+ +---------------+ +------+
| Terminal | | Local-MAC WTP | | AC |
+----------+ +---------------+ +------+
| | |
| | |
Iino, et al. Expires September 30, 2005 [Page 40]
Internet-Draft WiCoP March 2005
| IEEE 802.11 Association | WiCoP |
|-------------------------)| Terminal Addition |
| |===========================)|
| | |
| | WiCoP Terminal |
| |(===========================|
| IEEE 802.11 Association | Addition Response |
|(-------------------------| |
| Response | |
| | |
| | |
| |
| |
| |
| +---------------+ |
| | Split-MAC WTP | |
| +---------------+ |
| | |
| | |
| IEEE 802.11 Association | |
|-------------------------)| |
| | IEEE 802.11 Association |
| |===========================)|
| | (Over WiCoP) |
| | |
| | |
| | WiCoP |
| | Terminal Addition |
| |(===========================|
| | |
| | |
| | WiCoP Terminal |
| |===========================)|
| IEEE 802.11 Association | Addition Response |
|(-------------------------| |
| Response | |
| | |
Figure 8
6.5.6 Key Configuration
One of the differences between split-MAC and local-MAC WTPs is the
location of the over-the-air encryption. Some split-MAC and
local-MAC WTPs perform encryption locally while others leave it to
the AC. WiCoP accommodates these differences by enabling security
Iino, et al. Expires September 30, 2005 [Page 41]
Internet-Draft WiCoP March 2005
key configuration in those cases where encryption is performed at the
WTP. The encryption setup process is therefore contingent on the
WiCoP protocol interface.
When dynamic WEP is used, the WiCoP Key Configuration message is used
to notify WTPs of encryption keys for each associated wireless
terminal. Here, the EAPoL Key frame is encapsulated in the Key
Configuration message and sent to a WTP. Upon receiving the Key
Configuration message, the WTP sets the encryption key in its local
security table, decapsulates the EAPOL Key frame and forwards it to
the wireless terminal.
When WPA or IEEE 802.11i is used in WLAN architectures in which the
authenticator is located at the AC and encryption points at WTPs, the
exchanges of the 4-way handshake are managed distinctly. This is
because the AC is no longer in a position to calculate the KeyMIC as
it is not aware of the KeyRSC sequence counter. So here, WiCoP Key
Configuration message is used to transport the 3rd message of the
4-way handshake - containing the EAPoL-Key - with unassigned KeyRSC
and KeyMIC fields. When the WTP receives the WiCoP Key Configuration
message, it first assigns the sequnce number value to the KeyRSC
field. Then, the WTP calculates the KeyMIC value using the PTK and
3rd message of 4-way handshake with assigned sequence counter value.
So the WiCoP Key Configuration message allows the KeyMIC to be
calculated at the WTPs instead of the AC.
The 1st, 2nd and 4th messages of the 4-way handshake are transported
in WiCoP data packets that are assigned priorities similar to that of
WiCoP control packets.
Similarly, for the group key handshake in WPA and IEEE 802.11i, the
1st message of the handshake is transported using the WiCoP Key
Configuration message with unassigned KeyRSC. The WTP again assigns
the sequence number value to the KeyRSC and then calculates the
KeyMIC. The 2nd message of the handshake however is transported in
WiCoP data packets with priorities similar to that of WiCoP control
packets.
The Key Configuration Response message is used by the WTP to notify
the AC of the encryption setup process.
Iino, et al. Expires September 30, 2005 [Page 42]
Internet-Draft WiCoP March 2005
7. Summary and Conclusion
The Wireless LAN Control Protocol presents a solution for managing
large-scale WLANs with diverse elements. It addresses the challenges
presented in the CAPWAP Problem Statement
[I-D.ietf-capwap-problem-statement] and realizes the requirements of
the CAPWAP Objectives [I-D.ietf-capwap-objectives].
WiCoP enables integral control of split-MAC and local-MAC WTPs by
defining appropriate differentiators within the protocol message
exchanges and processes. It addresses architecture designs in which
the authenticator and encryption points are located on distinct
entities. And in doing so, WiCoP realizes the interoperability
objective and its benefits.
WiCoP also addresses shared WLAN deployments by configuring and
managing WTPs on a logical group basis. It is futher provisioned to
separate control and data traffic within WLANs. So the protocol
addresses the objectives of logical groups and traffic separation.
Overall, the specifications presented in this document allows for an
effective WLAN control and provisioning protocol.
Iino, et al. Expires September 30, 2005 [Page 43]
Internet-Draft WiCoP March 2005
8. Security Considerations
Illegitimate WTPs and ACs pose a significant threat to WLAN security.
This can be mitigated by requiring all WiCoP entities to be mutually
authenticated before initiating critical protocol exchanges. WiCoP
includes a trigger for a suitable authentication mechanism. This is
to accommodate different security mechanism that may be used between
WTPs and AC depending on the nature of the deployment.
In extension to mutual authentication, the subsequent exchange of
protocol information between WTPs and AC need to be protected. The
exchanges have to be protected against alterations of any sort and
DoS attacks. Also, the information should not be accessible to any
third party. Encryption of protocol exchanges is therefore
necessary. WiCoP includes appropriate procedures to select and
establish a security association between WTPs and AC in the Connection
state.
Architecture designs in which authentication is performed at the AC
and encryption at the WTPs can be exposed to the threat of replay
attacks. Since the AC will not be aware of the exact value of the
sequence counter, it will not make the corresponding assignment
within the 4-way handshake. This leaves the wireless terminal to
accept all incoming frames including illegitimate frames as it cannot
verify the sequence counter value. Such a threat needs to protected
against by allowing the WTP to assign the correct value of the
sequence counter. WiCoP accomplishes this by sending the 3rd message
of the 4-way handshake within a control message to the WTP, which
then updates the sequence counter field before forwarding to the
wireless terminals.
9. References
[I-D.ietf-capwap-arch]
Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy
for Control and Provisioning of Wireless Access
Points(CAPWAP)", Internet-Draft draft-ietf-capwap-arch-06,
November 2004.
[I-D.ietf-capwap-objectives]
Govindan, S., "Objectives for Control and Provisioning of
Wireless Access Points (CAPWAP)",
Internet-Draft draft-ietf-capwap-objectives-01, March
2005.
[I-D.ietf-capwap-problem-statement]
Calhoun, P., "CAPWAP Problem Statement",
Internet-Draft draft-ietf-capwap-problem-statement-02,
Iino, et al. Expires September 30, 2005 [Page 44]
Internet-Draft WiCoP March 2005
September 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Satoshi Iino
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
Email: iino.satoshi@jp.panasonic.com
Saravanan Govindan
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5441
Email: sgovindan@psl.com.sg
Mikihito Sugiura
Panasonic Mobile Communications
600, Saedo-cho
Tsuzuki-ku
Yokohama 224 8539
Japan
Phone: +81 45 938 3789
Email: sugiura.mikihito@jp.panasonic.com
Iino, et al. Expires September 30, 2005 [Page 45]
Internet-Draft WiCoP March 2005
Hong Cheng
Panasonic Singapore Laboratories
Block 1022, Tai Seng Industrial Estate
#06-3530, Tai Seng Avenue
Singapore 534 415
Singapore
Phone: +65 6550 5447
Email: hcheng@psl.com.sg
Iino, et al. Expires September 30, 2005 [Page 46]
Internet-Draft WiCoP March 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.
Iino, et al. Expires September 30, 2005 [Page 47]