Internet DRAFT - draft-alexander-bmwg-wlan-switch-term
draft-alexander-bmwg-wlan-switch-term
Internet Engineering Task Force T. Ahuja
Internet-Draft Cisco Systems, Inc.
Intended status: Informational T. Alexander
Expires: July 5, 2008 VeriWave, Inc.
S. Bradner
Harvard University
S. Hooda
Cisco Systems, Inc.
J. Perser
VeriWave, Inc.
M. Sambi
Cisco Systems, Inc.
January 2, 2008
Benchmarking Terminology for Wireless LAN Switching Systems
draft-alexander-bmwg-wlan-switch-term-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 5, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Ahuja, et al. Expires July 5, 2008 [Page 1]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Abstract
This document provides a terminology to be used when performing
performance test and benchmarking of wireless LAN (WLAN) switches and
controllers, including systems comprising groups of controllers and
Access Points. The various wireless-specific device nomenclature, as
well as the definitions of configuration parameters and test
conditions that may be used to characterize the performance of these
devices, are provided. The document also defines some of the metrics
used during WLAN switch benchmarking. This terminology is to be used
in conjunction with the companion methodology document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Existing definitions and requirements . . . . . . . . . . . . 5
3. Definitions of terms . . . . . . . . . . . . . . . . . . . . . 5
3.1. General terms . . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Wireless LAN (WLAN) . . . . . . . . . . . . . . . . . 6
3.1.2. Access controller (AC) . . . . . . . . . . . . . . . . 6
3.1.3. Endstation (STA) . . . . . . . . . . . . . . . . . . . 7
3.1.4. Wireless termination point (WTP) . . . . . . . . . . . 8
3.1.5. Service set identifier (SSID) . . . . . . . . . . . . 9
3.1.6. Rogue device . . . . . . . . . . . . . . . . . . . . . 9
3.1.7. Provisioned WTP . . . . . . . . . . . . . . . . . . . 10
3.1.8. Unprovisioned WTP . . . . . . . . . . . . . . . . . . 11
3.1.9. Unicast traffic flow . . . . . . . . . . . . . . . . . 12
3.1.10. Multicast traffic flow . . . . . . . . . . . . . . . . 12
3.1.11. Best-effort traffic . . . . . . . . . . . . . . . . . 13
3.1.12. High-priority traffic . . . . . . . . . . . . . . . . 14
3.1.13. Roaming . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.14. Inter-AC roaming . . . . . . . . . . . . . . . . . . . 16
3.1.15. Intra-AC roaming . . . . . . . . . . . . . . . . . . . 17
3.1.16. Roaming decision . . . . . . . . . . . . . . . . . . . 18
3.1.17. Roam failure . . . . . . . . . . . . . . . . . . . . . 19
3.1.18. Beacon period . . . . . . . . . . . . . . . . . . . . 19
3.1.19. Listen interval . . . . . . . . . . . . . . . . . . . 20
3.1.20. Preauthentication . . . . . . . . . . . . . . . . . . 21
3.1.21. PMKID caching . . . . . . . . . . . . . . . . . . . . 22
3.1.22. QoS differentiation . . . . . . . . . . . . . . . . . 23
3.2. Data plane terminology . . . . . . . . . . . . . . . . . . 24
3.2.1. Aggregate Multicast Throughput . . . . . . . . . . . . 24
3.2.2. Aggregate Maximum Multicast Forwarding Rate . . . . . 25
3.2.3. QoS threshold . . . . . . . . . . . . . . . . . . . . 25
3.3. Control plane terminology . . . . . . . . . . . . . . . . 26
Ahuja, et al. Expires July 5, 2008 [Page 2]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
3.3.1. Endstation capacity . . . . . . . . . . . . . . . . . 26
3.3.2. Endstation association rate . . . . . . . . . . . . . 27
3.3.3. WTP capacity . . . . . . . . . . . . . . . . . . . . . 28
3.3.4. Roaming rate . . . . . . . . . . . . . . . . . . . . . 29
3.3.5. Roaming delay . . . . . . . . . . . . . . . . . . . . 30
3.3.6. Reset duration . . . . . . . . . . . . . . . . . . . . 31
3.3.7. Reset recovery time . . . . . . . . . . . . . . . . . 32
3.3.8. WTP association rate . . . . . . . . . . . . . . . . . 33
3.3.9. AC reset recovery time . . . . . . . . . . . . . . . . 34
3.3.10. Failover recovery time . . . . . . . . . . . . . . . . 35
4. Security Considerations . . . . . . . . . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.1. Normative References . . . . . . . . . . . . . . . . . . . 36
6.2. Informative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 39
Ahuja, et al. Expires July 5, 2008 [Page 3]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
1. Introduction
Wireless LANs (WLANs) are deployed on a large scale in traditional
enterprises, in commercial service offerings such as coffee shops, as
well as vertical applications such as inventory management. These
deployments initially used a distributed network of Access Points
(APs). Large WLAN deployments using distributed APs, however,
introduce several issues. These include: an increased administrative
burden, as the APs are individually IP-addressable; the need to
ensure consistency of configuration across all APs; the difficulty of
dealing with the dynamic nature of the WLAN medium and combating RF
interference and noise; assuring seamless mobility for end users
across the WLAN; and the more complex task of securing the WLAN
against intrusion or unauthorized access.
To address the above problems, vendors offer solutions that combine
aspects of LAN switching, centralized control, and distributed
wireless access in an architecture comprising a set of relatively
simple Wireless termination points (WTPs) coupled to one or more
Access controllers (ACs). The use of centralized control and
monitoring simplifies many of the management and security issues
noted above, as the WTPs can be configured and controlled as a group
by the ACs, security policies can be administered on a WLAN-wide
basis, and the RF domain can be monitored and controlled from a
central location.
Each vendor offering such a system needs a protocol between ACs and
WTPs to support both centralized management and data transport
functions. The general practice has been for vendors to use a
proprietary protocol; however, the CAPWAP (Control and Provisioning
of Wireless Access Points) protocol is being standardized by the IETF
to provide a multi-vendor interoperable interface between WTPs and
ACs. The CAPWAP protocol also defines a standardized WLAN
architecture and mandatory functions (such as discovery) to enable a
common functional model to be adopted across the vendor base.
The ACs may perform both control plane and data plane functions
within a WLAN. It is therefore of significant interest to benchmark
their performance, as they have a material impact on the performance
and perceived end-user experience of WLANs built around them. ACs
may be benchmarked either as stand-alone entities, or in conjunction
with the WTPs to which they connect. When ACs are benchmarked in
conjunction with WTPs, the CAPWAP architectural model is used as a
reference.
This document defines the terminology to be used by vendors and users
of switched WLAN devices when measuring and reporting performance
characteristics of such devices. It extends existing terminology
Ahuja, et al. Expires July 5, 2008 [Page 4]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
defined in RFC 2544 [RFC2544] and subsequently extended in RFC 2285
[RFC2285]. Terms generally applicable to WLAN switching systems are
defined first, followed by specific terminology relating to data
plane and control plane metrics.
2. Existing definitions and requirements
RFC 1242, "Benchmarking Terminology for Network Interconnect Devices"
[RFC1242] and RFC 2285, "Benchmarking Terminology for LAN Switching
Devices" [RFC2285] SHOULD be reviewed in conjunction with this
document. WLAN-specific terms and definitions are also provided in
Clauses 3 and 4 of the IEEE 802.11 standard [802.11]. Commonly used
terms may also be found in RFC 1983 [RFC1983].
For the sake of clarity and continuity, this document adopts the
general template for benchmarking terminology set out in Section 2 of
RFC 1242. Definitions are organized in alphabetical order, and
grouped into sections for ease of reference.
The following terms are assumed to be taken as defined in RFC 1242
[RFC1242]: Throughput, Latency, Constant Load, Frame Loss Rate, and
Overhead Behavior. In addition, the following terms are taken as
defined in RFC 2285 [RFC2285]: Forwarding Rates, Maximum Forwarding
Rate, Loads, Device Under Test (DUT), and System Under Test (SUT).
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 [RFC2119].
3. Definitions of terms
The terminology defined in this document is divided into three main
categories: general WLAN definitions, WLAN data plane definitions,
and WLAN control plane definitions.
General WLAN definitions relate to the main physical and logical
components of the WLAN architecture as defined by CAPWAP. These
definitions are not specific to any particular metric or test
procedure.
WLAN data plane definitions relate to data frame forwarding functions
within the WLAN architecture.
WLAN control plane definitions are associated with functions, metrics
and test procedures that are connected with the management and
control of system components. These control plane functions are
Ahuja, et al. Expires July 5, 2008 [Page 5]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
usually unrelated to traffic forwarding, and handled by software on
the AC and WTP.
3.1. General terms
3.1.1. Wireless LAN (WLAN)
Definition:
A radio-based local area network architecture.
Discussion:
A WLAN performs the same functions as a typical (Ethernet) LAN,
but utilizes digital radio links rather than copper or optical
fiber connections. The principal benefits of a WLAN are mobility
and reduced physical plant (i.e., cabling).
The most common WLAN protocol today is IEEE 802.11 [802.11],
which comprises: various radio PHY technologies; a Carrier Sense
Multiple Access / Collision Avoidance (CSMA/CA) shared-medium
access method; encryption and authentication for security;
prioritized medium access for QoS; and functions for discovery,
connection establishment and mobility (roaming).
Measurement Units:
N/A
Issues:
None
See Also:
Access controller (AC)
Wireless termination point (WTP)
Endstation (STA)
Service set identifier (SSID)
3.1.2. Access controller (AC)
Definition:
Ahuja, et al. Expires July 5, 2008 [Page 6]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
A network infrastructure device that provides centralized
control, management and frame switching functions for a WLAN.
Discussion:
An AC is a component of a centralized WLAN architecture as
defined by CAPWAP. The AC provides connectivity and control for
Wireless Termination Points (WTPs), switches frames between the
wireless and wired portions of the LAN infrastructure, and
supports discovery, initialization, configuration, management and
data transfer functions.
Measurement Units:
N/A
See Also:
Wireless termination point (WTP)
Endstation (STA)
Wireless LAN (WLAN)
3.1.3. Endstation (STA)
Definition:
A user or subscriber device within a WLAN, that connects to a WTP
and sources or sinks data traffic.
Discussion:
Endstations in a WLAN are equivalent to hosts in a traditional
(wired) LAN, but are more diverse and functional entities. They
are also frequently referred to as clients. Endstations comprise
normal host devices such as laptops; peripherals such as
printers; mobile devices such as phones; consumer electronics
devices such as TVs; and even industrial or medical devices such
as RFID tags and heart monitors.
Endstations in a WLAN are connection-oriented, and must connect
to the WLAN and authenticate with it before exchanging data
traffic.
Measurement Units:
Ahuja, et al. Expires July 5, 2008 [Page 7]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
N/A
See Also:
Access controller (AC)
Wireless termination point (WTP)
3.1.4. Wireless termination point (WTP)
Definition:
A bridge between the wireless (RF) and wired domains, that acts
in conjunction with an AC to provide services to endstations.
Discussion:
WTPs (also referred to as Access Points, or APs) are a component
of the CAPWAP architecture. They implement all of the PHY layer
functions as well as some subset of the link layer functions of
the IEEE 802.11 protocol. In a CAPWAP system, the WTPs serve as
an encapsulating bridge between the RF domain in which the
endstations exist and the wired Ethernet LAN where the ACs
reside. Depending on the specific implementation, WTPs may also
provide some of the discovery, security and mobility functions
required by endstations.
Each WTP typically serves several endstations. The WTP and its
associated endstations contend for and share the RF medium among
themselves. WTPs may contain multiple radios (and MAC
functionality) to provide service on more than one WLAN frequency
band at the same time. WTPs may also advertise several Service
set identifiers (SSIDs) on the same frequency band in order to
support multiple logical WLANs that provide different types of
service (e.g., voice and data) simultaneously.
Measurement Units:
N/A
See Also:
Access controller (AC)
Endstation (STA)
Ahuja, et al. Expires July 5, 2008 [Page 8]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
3.1.5. Service set identifier (SSID)
Definition:
Tag assigned to a specific logical WLAN.
Discussion:
WLAN administrators may elect to overlay multiple logical WLANs
on a single physical topology, in the same manner as virtual LANs
(VLANs) are used in Ethernet LANs. Each logical WLAN is given an
identifying tag, referred to as an SSID, and is a sequence of up
to 32 ASCII characters. SSIDs supported by a WLAN are frequently
advertised in protocol frames such as beacons and probe
responses, so that endstations may discover the available list of
logical WLANs and attempt to associate with one of them.
The logical WLAN identified by an SSID has a distinct set of
properties shared among all its entities, such as security type
(encryption as well as authentication), QoS mechanisms, access
rights (e.g., guest or intranet user), and even services offered
(e.g., voice or data).
Measurement Units:
N/A
Issues:
None
See Also:
Wireless LAN (WLAN)
Access controller (AC)
Wireless termination point (WTP)
Endstation (STA)
3.1.6. Rogue device
Definition:
An unauthorized device, either an endstation or a WTP, that is
introduced into a WLAN.
Ahuja, et al. Expires July 5, 2008 [Page 9]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Discussion:
As WLANs require no physical cabling between WTPs and
endstations, it is relatively simple for users or intruders to
introduce a new endstation - or, less commonly, a new WTP -
without the consent or knowledge of the network administrator(s).
Such rogue devices are high security risks. When introduced by
legitimate users, they fall outside security policies set up by
the network administrators; when set up by intruders, they
represent security breaches or denial of service attacks.
Detection and isolation or containment of rogue devices is a
usual function in most enterprise WLANs.
Measurement Units:
N/A
See Also:
Wireless LAN (WLAN)
Access controller (AC)
Wireless termination point (WTP)
Provisioned WTP
Unprovisioned WTP
3.1.7. Provisioned WTP
Definition:
WTPs that have been successfully registered with an AC.
Discussion:
As part of rogue WTP detection and containment procedures, a WTP
is usually required to be authenticated and registered by an AC
before it is allowed to associate endstations or transfer data
traffic. In many cases, encrypted tunnels between the WTP and AC
must be configured and firmware versions verified (or downloaded)
as well. A provisioned WTP is therefore one that has
successfully completed all these steps and appears in the AC
database as a legitimate WTP.
Ahuja, et al. Expires July 5, 2008 [Page 10]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Note that in some cases a WTP that has been previously
authenticated and registered by an AC will take less time to be
provisioned on subsequent registration attempts, because of
caching of WTP information by the AC.
Measurement Units:
N/A
See Also:
Access controller (AC)
Wireless termination point (WTP)
Rogue device
Unprovisioned WTP
3.1.8. Unprovisioned WTP
Definition:
A WTP that has not (yet) been successfully registered with an AC.
Discussion:
Unprovisioned WTPs are devices in the process of registering with
an AC, but have not yet completed the registration process and
are not yet treated as rogue WTPs. If an unprovisioned WTP
completes the registration process successfully, it becomes a
provisioned WTP; if it fails, it becomes a rogue WTP. An
unprovisioned WTP is not normally capable of transferring data or
associating endstations.
Measurement Units:
N/A
See Also:
Access controller (AC)
Wireless termination point (WTP)
Rogue device
Ahuja, et al. Expires July 5, 2008 [Page 11]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Provisioned WTP
3.1.9. Unicast traffic flow
Definition:
A stream of one or more data frames from a single source to a
single intended destination.
Discussion:
For the purposes of this document, a unicast traffic flow has two
attributes: it carries user or application data, and it has
unicast destination addresses at both the link layer and the IP
layer. (If the traffic frames are encapsulated, then these
attributes pertain to the encapsulated traffic frames and not the
outer headers.) A well-formed unicast traffic flow also
possesses unicast source addresses at both the link and IP
layers.
"User or application data" in this context refers to traffic that
is not connected with control or management functions specific to
the WLAN itself.
A unicast traffic flow is also expected to carry traffic for a
single data stream, with reference to the protocol layer of
interest. For example, if the internetwork layer is of interest,
then a unicast traffic flow SHOULD carry packets from a single IP
address to a single IP address. If the application layer is
being considered, then the unicast traffic flow SHOULD be
generated by a single application entity, and SHOULD NOT contain
packets multiplexed from several application entities or
protocols.
Measurement Units:
N/A
See Also:
Multicast traffic flow
3.1.10. Multicast traffic flow
Definition:
Ahuja, et al. Expires July 5, 2008 [Page 12]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
A stream of one or more data frames from a single source to more
than one intended destination.
Discussion:
For the purposes of this document, a multicast traffic flow has
two attributes: it carries user or application data, and it has
multicast destination addresses at both the link layer and the IP
layer. (If the traffic frames are encapsulated, then these
attributes pertain to the encapsulated traffic frames and not the
outer headers.) A well-formed multicast traffic flow also
possesses unicast source addresses at both the link and IP
layers.
"User or application data" in this context refers to traffic that
is not connected with control or management functions specific to
the WLAN itself.
While it is possible for multicast traffic flows to be originated
from different source entities, a given multicast traffic flow
SHOULD be associated with a single application.
Measurement Units:
N/A
See Also:
Unicast traffic flow
3.1.11. Best-effort traffic
Definition:
A unicast or multicast traffic flow that is not associated with
any service guarantees, such as maximum loss, maximum latency, or
maximum jitter.
Discussion:
This type of traffic is assigned the lowest priority in the QoS
hierarchy. It is often used as the "default" traffic priority,
and is typically used by applications that are not adversely
affected by loss or delay. For example, a file transfer carried
out over TCP can recover from network losses, and retains high
transfer rates even over high-delay links.
Measurement Units:
Ahuja, et al. Expires July 5, 2008 [Page 13]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
N/A
See Also:
Unicast traffic flow
Multicast traffic flow
High-priority traffic
3.1.12. High-priority traffic
Definition:
A unicast or multicast traffic flow that is required to adhere to
one or more service guarantees, such as maximum loss, maximum
latency, or maximum jitter.
Discussion:
High-priority traffic is generated and consumed by applications
that cannot tolerate loss, delay (or delay variation), or both.
An example is a voice connection (Voice over IP, or VoIP); voice
data streams must be delivered by the infrastructure with low
delay and jitter, and with low packet loss, to avoid significant
degradation of voice quality.
High-priority traffic is usually marked by a QoS tag (e.g., a
DSCP codepoint, an 802.11e Access Category value [802.11e], or an
802.1D user_priority field) that indicates the desired level of
service guarantees required. In some connection-oriented
networks, the marking may be implicit (i.e., assigned to the
connection at setup time).
To enable the service guarantees of different types of traffic to
be met, a hierarchy of QoS tags or markings is usually
established within the network infrastructure. Concurrently
received traffic bearing different QoS tags are provided
different levels of service.
Measurement Units:
N/A
See Also:
Ahuja, et al. Expires July 5, 2008 [Page 14]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Unicast traffic flow
Multicast traffic flow
Best-effort traffic
3.1.13. Roaming
Definition:
The process whereby a WLAN endstation moves from the coverage
area of one WTP to the coverage area of another.
Discussion:
IEEE 802.11 is a connection-oriented protocol where the
endstations (clients) associate, or connect, to a single WTP at a
time; typically, the closest WTP to the endstation. When an
endstation moves from the neighborhood of one WTP to the
neighborhood of another, it attempts to maintain the best
possible wireless link parameters (signal strength and bit error
ratio) by disassociating from the former and associating with the
latter. At this point, the endstation is said to have roamed
from one WTP to another, and a roaming event is said to have
taken place.
The exact sequence of events during roaming varies considerably,
based on security mode and other factors. However, the general
process is as follows:
* the endstation makes a roaming decision based on some
internal criteria, such as link quality or traffic load
* the endstation determines the new WTP with which it should
associate or reassociate
* the endstation passively or actively disassociates with the
current WTP, thereby interrupting data transfer
* the endstation performs a (re)association process with the
new WTP
* data transfer resumes (i.e., the new WTP begins transferring
data to the endstation)
Ahuja, et al. Expires July 5, 2008 [Page 15]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Roaming MUST be applied only to movements of endstations within
the same logical or physical wireless network; for example, the
SSID MUST remain constant, and the security parameters MUST NOT
change. The endstation IP address SHOULD NOT change, which
usually confines roaming to a single subnet; however, if the WTPs
or AC can proxy for the endstation on different subnet, then
roaming can occur across subnets. Endstations that use DHCP MAY
elect to renew the DHCP lease after each roaming event.
Note that "roaming" in the WLAN context corresponds to "handover"
or "handoff" in the cellular wireless context.
Measurement Units:
N/A
Issues:
None
See Also:
Roaming decision
Roaming delay
Roaming rate
3.1.14. Inter-AC roaming
Definition:
A roaming situation wherein a WLAN endstation moves between WTPs
connected to different ACs.
Discussion:
An enterprise WLAN may comprise multiple ACs, each associated
with a separate subset of WTPs, but acting in concert to present
the appearance of a single integrated network to the endstations.
In this case, it is possible for endstations to roam between WTPs
belonging to different ACs, requiring the ACs to perform a
handoff between themselves to maintain connectivity to the
endstation.
This type of handoff is usually more complex than the simple case
where the endstation roams only between WTPs associated with a
single AC. It involves rapidly transferring security and
Ahuja, et al. Expires July 5, 2008 [Page 16]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
connection state information from one AC to another, in addition
to the usual requirements of reprovisioning WTPs and
reassociating the endstation. Inter-AC roaming can therefore
incur higher roaming delays.
Measurement Units:
N/A
Issues:
None
See Also:
Roaming
Roaming delay
Intra-AC roaming
3.1.15. Intra-AC roaming
Definition:
A roaming situation wherein a WLAN endstation moves between WTPs
connected to the same AC.
Discussion:
This is the simplest case of roaming in a WLAN employing WTPs and
ACs: the endstations roam between different WTPs, but each
endstation only roams within the subset of WTPs that are
associated with a single AC. In this situation there is no need
for ACs to transfer state information between themselves, and as
a consequence roaming delays may be lower.
Measurement Units:
N/A
Issues:
None
See Also:
Ahuja, et al. Expires July 5, 2008 [Page 17]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Roaming
Roaming delay
Inter-AC roaming
3.1.16. Roaming decision
Definition:
The point in time at which a WLAN endstation decides to initiate
a roaming process.
Discussion:
An endstation typically monitors the quality of the link between
itself and the WTP to which it is currently associated, and will
also monitor the neighboring WTPs whose signals it can receive.
(Some endstations may also monitor the traffic load of their
partner WTP as well.) When these factors cross predefined
thresholds, and a "better" neighboring WTP is available, the
endstation will make a decision to roam to the "better" WTP.
This is referred to as the roaming decision, and is a basic part
of the mobility process.
Once the roaming decision has been made, data traffic is usually
interrupted, because the endstation will disassociate (passively
or actively) from the current WTP and initiate the process of
roaming to a new WTP. Data traffic in either upstream or
downstream directions will not resume until the endstation has
successfully roamed.
Measurement Units:
Not applicable.
Issues:
None
See Also:
Roaming
Roaming delay
Roaming rate
Ahuja, et al. Expires July 5, 2008 [Page 18]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
3.1.17. Roam failure
Definition:
Failure to successfully complete the roaming process and restore
data service.
Discussion:
The roaming (mobility) process is complex and can involve several
layers of handshakes, especially when security protocols are
involved. If one or more of these handshakes fails completely
(i.e., the retries thereof all fail), then roaming will not
complete and data service to the roaming endstation will not be
restored by the WLAN infrastructure. Further, it is also
possible for the association handshakes during roaming to
complete successfully but for data service to not be restored
(i.e., downstream data transfer does not resume). The occurrence
of either of these events is classified as a roaming failure.
The consequences of a roaming failure are usually catastrophic
for user applications that are engaged in transferring data while
roaming is taking place.
Measurement Units:
Not applicable.
Issues:
None
See Also:
Roaming
Roaming delay
Roaming rate
3.1.18. Beacon period
Definition:
The nominal time interval between successive beacon frames
emitted by a single WTP.
Discussion:
Ahuja, et al. Expires July 5, 2008 [Page 19]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
To permit efficient discovery and self-configuration by
endstations, WTPs periodically broadcast IEEE 802.11 control
frames referred to as beacons. Beacons contain information
relating to a logical WLAN, such as acceptable PHY data rates,
security information, QoS information, and so on. The configured
time interval from the start of one beacon to the start of the
next beacon is referred to as the beacon period.
Note that beacons must obey the rules of the CSMA/CA access
protocol as well. Hence the actual time interval between beacons
may not equal the configured time interval. However, the error
is not accumulative, and so over a statistically significant
period of time the average interval between beacons will be very
close to the nominal beacon period.
The default beacon period of IEEE 802.11 WTPs is 102.4 msec.
Measurement Units:
Time Units (one Time Unit, or TU, equals 1024 microseconds)
Issues:
None
See Also:
Listen interval
3.1.19. Listen interval
Definition:
The time interval at which an endstation in sleep mode wakes to
check for buffered traffic.
Discussion:
WLAN endstations are frequently battery-powered, mobile devices
that need to conserve power consumption (and increase battery
life) by sleeping when they have no data to send, after first
notifying the WTP/AC. WTPs and/or ACs are expected to buffer
downstream data traffic for sleeping endstations until the
endstation wakes up and polls for buffered data, which is done
periodically.
The interval between polls for buffered data is known as the
listen interval. The size of the listen interval is usually
Ahuja, et al. Expires July 5, 2008 [Page 20]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
configurable, in order to strike a balance between battery life
and traffic delays. A larger listen interval results in reduced
power consumption, as the endstation has to wake up less often,
but also increases the delays in downstream traffic.
As the polling operation is linked to trigger fields in the
beacons emitted by the WTP, the listen interval is defined to be
an integral number of beacon periods. The default listen
interval for normal IEEE 802.11 endstations is usually 3 beacon
periods.
Measurement Units:
Beacon periods.
Issues:
None
See Also:
Beacon period
3.1.20. Preauthentication
Definition:
The process of authenticating with a target WTP prior to
performing a roam to that WTP.
Discussion:
Endstations normally need to perform a complete security
handshake (e.g., IEEE 802.11 authentication and association, EAP/
TLS authentication, and key exchange) when they re-associate with
a new WTP during a roaming event. This is because WLAN security
mechanisms produce different keys on different WTPs, as the WTP
MAC address and other information forms part of the key
derivation mechanism. This can greatly extend the time required
to complete a roaming event, because EAP handshakes are usually
long and complex.
To reduce the roaming time, the IEEE 802.11 standard permits a
shortcut to be implemented by endstations: prior to the actual
roam, the endstation may complete an authentication with the
target WTP via the WTP with which the endstation is currently
associated. Essentially the authentication frames are received
over the wireless medium by the current WTP and then tunneled
Ahuja, et al. Expires July 5, 2008 [Page 21]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
over the wired infrastructure to the target WTP.
When the roam event actually occurs, the endstation can bypass
the entire EAP authentication process and skip directly to IEEE
802.1X key derivation, using the parameters (such as keying
material) that have already been negotiated. This is known as
preauthentication.
Measurement Units:
N/A
Issues:
None
See Also:
Roaming delay
PMKID caching
3.1.21. PMKID caching
Definition:
The process of retaining (caching) security contexts when roaming
between WTPs, and using the cached contexts to reduce roaming
delay.
Discussion:
As described in section 3.1.14 (Preauthentication), endstations
must normally perform a complete security handshake during a
roaming event, which can significantly drive up roaming delay.
PMKID caching is a means of reducing roaming delay in the event
that an endstation returns to a WTP after roaming away from it.
Normally the endstation discards the security context when
disassociating from a WTP. When PMKID caching is in effect,
however, the endstation retains the security context and, if it
attempts to re-associate with the same WTP, signals the WTP that
the security context from the previous association is still
available. The WTP may then bypass the entire EAP authentication
process and skip directly to IEEE 802.1X key derivation.
Measurement Units:
Ahuja, et al. Expires July 5, 2008 [Page 22]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
N/A
Issues:
None
See Also:
Roaming delay
Preauthentication
3.1.22. QoS differentiation
Definition:
Differential handling of traffic flows based on QoS parameters
assigned to them.
Discussion:
WLANs are particularly subject to congestion issues, as not only
is the capacity of a radio link comparatively low, but it is also
shared by multiple endstations and WTPs. It is therefore
essential to support differential handling of traffic based on
their individual QoS requirements. For example, voice traffic
(which is highly delay sensitive but does not occupy much
bandwidth) should be permitted to take precedence over data
traffic, whenever both types of traffic are contending for use of
the wireless medium. This process is referred to as QoS
differentiation.
QoS differentiation may be realized in many different ways. A
common method is to use simple prioritization of traffic, with
delay-sensitive traffic having higher priority for medium access
versus best-effort traffic. The IEEE 802.11e standard [802.11e]
specifies a traffic prioritization and differential medium access
scheme suitable for IEEE 802.11 WLANs.
Measurement Units:
N/A
Issues:
None
See Also:
Ahuja, et al. Expires July 5, 2008 [Page 23]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
QoS Threshold
3.2. Data plane terminology
The terminology in the following subsections relate directly to
metrics and measurement procedures for data plane functions.
3.2.1. Aggregate Multicast Throughput
Definition:
The maximum aggregate offered load of a set of one or more
multicast traffic flows that can be presented to a DUT/SUT and
forwarded without frame loss.
Discussion:
As per RFC 1242 [RFC1242], a throughput figure allows vendors to
report a single value that has proven to be useful in the
marketplace, and also correlates to the quality of the end-user
experience. In some multicast protocols (e.g., push-to-talk
voice), the loss of even a single multicast frame at even one
destination may cause noticeable voice quality impairments. It
is therefore useful to know the maximum rate at which traffic
from several different multicast traffic flows can be forwarded
by the DUT/SUT without frame loss.
The aggregate multicast throughput is usually obtained from an
iterative set of forwarding rate measurements. It is calculated
by summing, over all the multicast traffic flows in the set, the
product of the offered load for each flow and the number of
destinations to which that flow is to be delivered.
Measurement Units:
N-octet input frames per second
Issues:
None
See Also:
Aggregate Multicast Forwarding Rate
Ahuja, et al. Expires July 5, 2008 [Page 24]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
3.2.2. Aggregate Maximum Multicast Forwarding Rate
Definition:
The maximum aggregate forwarding rate of a set of one or more
multicast traffic flows by a DUT/SUT, irrespective of frame loss.
Discussion:
The highest forwarding rate of a DUT/SUT may not coincide with
the throughput, or with the forwarding rate at maximum offered
load (FRMOL - see RFC 2285 [RFC2285]). The maximum aggregate
multicast forwarding rate figure enables the intrinsic multicast
handling capacity of the DUT/SUT datapath to be assessed, and is
useful in situations where some degree of loss can be tolerated
(e.g., multicast video).
The aggregate maximum multicast forwarding rate is usually
obtained from an iterative set of forwarding rate measurements.
It is calculated by summing, over all the multicast traffic flows
in the set, the number of frames per second delivered to each
destination of each traffic flow.
Measurement Units:
N-octet frames per second
Issues:
None
See Also:
Aggregate Multicast Throughput
3.2.3. QoS threshold
Definition:
A predefined set of minimum acceptable values for specific
properties of a forwarded unicast or multicast traffic flow.
Discussion:
Traffic flows such as voice and video need to adhere to a certain
level of service quality in order for the application layer to
provide an adequate level of service to the end user. For
example a voice traffic flow must keep packet losses and delays
Ahuja, et al. Expires July 5, 2008 [Page 25]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
below specific levels; otherwise, the audio quality at the
receiving end will be poor. A test of the QoS-related
performance of a DUT/SUT must therefore also specify the minimum
acceptable values for measurable parameters of the forwarded
traffic flow(s), in order to determine the performance of the
DUT/SUT.
For most RTP-based traffic, four parameters are of interest in
this regard: the average latency, the smoothed interarrival
jitter (see RFC 3550 [RFC3550]), the average packet loss, and the
loss burst distribution. The QoS threshold for a test specifies
the maximum acceptable levels of these parameters.
QoS thresholds vary depending on the needs of the application;
for G.711 VoIP flows, for instance, a generally accepted QoS
threshold is an average latency of 60 msec, a maximum jitter of
30 msec, a maximum packet loss of 1%, and a maximum burst loss of
1 packet. The specific QoS threshold used for a test MUST be
reported.
Once a QoS threshold is defined, the test may be conducted by
varying one or more test conditions - e.g., the offered load -
while ensuring that the measured values of the above four
parameters do not exceed the QoS threshold.
Measurement Units:
N/A
Issues:
None
See Also:
QoS differentiation
3.3. Control plane terminology
The terminology in the following subsections relate directly to
metrics and measurement procedures for control plane functions.
3.3.1. Endstation capacity
Definition:
Ahuja, et al. Expires July 5, 2008 [Page 26]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
The maximum number of wireless endstations that can be
simultaneously associated with a DUT/SUT.
Discussion:
The number of wireless endstations that can be concurrently
supported by a WLAN is an important metric, as it affects the
scalability of the WLAN. Further, the supported endstations
cannot merely achieve the state of being associated; they must be
able to transfer data as well. If data cannot be forwarded to
(or from) an associated endstation by the DUT/SUT, then the
endstation should not be counted towards the maximum number of
concurrently supported endstations.
Measurement Units:
endstations
Issues:
None
See Also:
Endstation (STA)
Access controller
Endstation association rate
3.3.2. Endstation association rate
Definition:
The sustained rate at which wireless endstations can successfully
associate with wireless controller.
Discussion:
The rate at which wireless endstations associate with a WLAN is
an important metric, as it affects both the scalability and the
responsiveness of the WLAN. Further, the associated endstations
cannot merely achieve the state of being associated; they must
all be able to transfer data as well. If data cannot be
forwarded to (or from) an associated endstation by the DUT/SUT,
then the endstation should not be counted towards the association
rate measurement.
Ahuja, et al. Expires July 5, 2008 [Page 27]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Measurement Units:
endstations associated per second
Issues:
None
See Also:
Endstation (STA)
Access controller
Endstation capacity
3.3.3. WTP capacity
Definition:
The maximum number of WTPs that can be simultaneously provisioned
by an AC.
Discussion:
The number of WTPs that can be discovered and concurrently
maintained by an AC (i.e., the DUT/SUT) affects the scalability
of the WLAN and is therefore an essential metric. Further, the
supported WTPs cannot merely achieve the state of being
provisioned; they must be able to associate endstations and
transfer data to/from them as well. If endstations cannot be
associated, or data cannot be forwarded to (or from) associated
endstations via a WTP, then it should not be counted towards the
maximum number of concurrently supported WTPs.
Measurement Units:
WTPs
Issues:
None
See Also:
Access controller
Ahuja, et al. Expires July 5, 2008 [Page 28]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Provisioned WTP
Endstation capacity
3.3.4. Roaming rate
Definition:
The rate at which endstations can roam from the coverage area of
one WTP to another (i.e., between WTPs) without failure.
Discussion:
A busy enterprise network, particularly one containing a number
of VoIP handsets (i.e., mobile phones) may see a large number of
roaming events per second as devices move between WTP coverage
areas. In such situations it is essential to ensure that roaming
takes place without failures (e.g., failed reassociations, or
excessively delayed reassociations). This is particularly true
in the case of VoIP handsets, where a roaming failure can cause
dropped calls or degraded voice quality. The maximum roaming
rate that can be sustained by the WLAN infrastructure is
therefore of significant interest.
The roaming rate measurement is invalidated by the presence of
roaming failures. The failure of the association handshakes with
the new WTP is relatively straightforward to determine (as the
handshakes themselves convey status messages and have predefined
timeouts and retry limits), but the length of time to wait for
resumption of data service is not well defined. A delay
threshold is therefore defined as part of the measurement
process, and a roam is considered to have failed if this
threshold is exceeded.
The distribution of endstations among WTPs within the DUT/SUT
usually has material impact on the roaming rate and therefore
SHOULD be specified by the measurement procedure.
Measurement Units:
roams per second
Issues:
None
See Also:
Ahuja, et al. Expires July 5, 2008 [Page 29]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Endstation (STA)
Wireless termination point (WTP)
Roaming
Roaming failure
Roaming delay
Endstation distribution
3.3.5. Roaming delay
Definition:
The time interval between the initiation and successful
completion of a roaming event.
Discussion:
Movement of an endstation between WTP coverage areas, which
causes roaming events to occur, requires some finite time to
complete, during which data traffic may be interrupted. The
duration of such data traffic interruption has a material impact
on the perceived capability of the WLAN to support mobile
endstations. For instance, an excessive period of traffic
interruption may cause voice calls to be dropped or TCP
connections to close their windows. A measurement of roaming
delay is thus a useful component of WLAN infrastructure
performance.
The roaming delay is ideally measured from the point at which the
roaming decision is made to the point at which data service is
completely restored (the roam completes without a roaming
failure). With reference to the WLAN infrastructure, therefore,
the roaming delay is the time from the roaming decision to the
first valid downstream data frame delivered to the endstation by
the new WTP.
In some situations the exact point at which the roaming decision
is made cannot be accurately ascertained, such as when using
actual endstations rather than dedicated test equipment during
the measurement process. In this case, the roaming delay is
measured as the time between the last valid data frame delivered
to the endstation by the old WTP to the first valid data frame
delivered to the endstation by the new WTP. The use of this
alternative measurement process MUST be noted along with the
Ahuja, et al. Expires July 5, 2008 [Page 30]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
measurement results.
In both cases, delivery of a data frame implies that the
endstation has received the data frame without error and has
issued, or has been observed to issue, an IEEE 802.11
acknowledgement packet for that data frame.
A roaming event MUST NOT be counted towards roaming delay
measurements if a roaming failure occurs.
The distribution of endstations among WTPs within the DUT/SUT
usually has material impact on the roaming delay and therefore
SHOULD be specified by the measurement procedure.
Measurement Units:
milliseconds
Issues:
None
See Also:
Endstation (STA)
Wireless termination point (WTP)
Roaming
Roaming decision
Roaming failure
Roaming rate
Endstation distribution
3.3.6. Reset duration
Definition:
The time period for which a reset is applied to the DUT/SUT, or
the time period for which the DUT/SUT is physically powered down.
Discussion:
Ahuja, et al. Expires July 5, 2008 [Page 31]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
In reset recovery and failover recovery measurements, the
duration for which a reset or power-off is applied can frequently
affect the test results. If the reset or power-off is applied
for too short a period, anomalous behavior can occur (such as the
DUT/SUT failing to reset at all). If the reset is applied for
too long a period, then unwanted effects such as TCP connections
being closed or association context being cleared can interfere
with the test. Reset or power-off should therefore be applied to
the DUT/SUT for a period sufficient to ensure a full reset of the
DUT/SUT, but not long enough to cause higher-layer connections to
time out.
Measurement Units:
seconds
Issues:
None
See Also:
Reset recovery time
Failover recovery time
3.3.7. Reset recovery time
Definition:
The time period from the removal of reset from the DUT/SUT (or
the power-up of the DUT/SUT) to the resumption of normal
operation.
Discussion:
The reset recovery time quantifies the duration of service outage
after a catastrophic event such as a power interruption. It
consists of two parts: the AC reset recovery time, and the
product of the rate of WTP association multiplied by the number
of WTPs present. The AC recovery time forms the fixed component
of the reset recovery time, while the latter product forms the
variable component. As the SUT increases in scale (i.e.,
comprises a larger number of WTPs) the reset recovery time
usually increases proportionally.
Ahuja, et al. Expires July 5, 2008 [Page 32]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Reset recovery time = AC reset recovery time + (Rate of WTP
association * Number of WTPs)
The measurement of the reset recovery time MUST include the time
required for all of the WTPs to reassociate the endstations and
begin transferring data. Until the last WTP has successfully
restored service to the last endstation, the reset recovery
process cannot be considered complete.
Measurement Units:
seconds
Issues:
None
See Also:
WTP association rate
AC reset recovery time
Failover recovery time
3.3.8. WTP association rate
Definition:
The rate at which WTPs can be discovered and provisioned by an
AC.
Discussion:
The number of WTPs present in a large enterprise WLAN may range
into the thousands, with each AC being called upon to provision
and manage hundreds of WTPs at a time. The rate at which the ACs
can discover and provision (i.e., associate) WTPs therefore
limits the speed with which the WLAN can recover from
catastrophic events such as power interruptions or connectivity
changes, and thus constitutes an important metric.
This metric is associated with the reset recovery test, and forms
the variable portion of the reset recovery time. A WTP is not
considered to be successfully provisioned by an AC until it has
reassociated all the endstations formerly associated to it and
begins transferring data to/from them.
Ahuja, et al. Expires July 5, 2008 [Page 33]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Note that caching of WTP information by an AC can increase the
WTP association rate for all subsequent associations after the
first one. See section 3.1.7.
Measurement Units:
WTPs per second.
Issues:
None
See Also:
Provisioned WTP
Reset recovery time
AC reset recovery time
Failover recovery time
3.3.9. AC reset recovery time
Definition:
The time period from the removal of reset from the DUT/SUT (or
the power-up of the DUT/SUT) to the successful provisioning of
the first WTP.
Discussion:
The AC reset recovery time is the fixed portion of the reset
recovery time, and indicates the minimum time required for an AC
with at least one connected WTP to recover from a catastrophic
event such as a power interruption. This time is mainly required
for the AC to restart and reinitialize itself, discover the first
WTP, provision it, reassociate the first endstation on the WTP,
and finally begin transferring data to the endstation. (If the
DUT/SUT contains or connects to more than one WTP, then the
actual reset recovery time is extended by the time required to
provision the additional WTPs and resume normal operation.)
The measurement of the AC reset recovery time MUST include the
time required for one WTP to reassociate one endstation and begin
transferring data to it.
Measurement Units:
Ahuja, et al. Expires July 5, 2008 [Page 34]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
seconds
Issues:
None
See Also:
Provisioned WTP
Reset recovery time
WTP association rate
Failover recovery time
3.3.10. Failover recovery time
Definition:
The time required to restore service after a catastrophic
hardware or software event in the DUT/SUT.
Discussion:
The availability of the WLAN infrastructure is of interest when
assessing the uptime and service quality of an enterprise
network. In fact, to ensure uninterrupted availability, vendors
often provide redundant elements in their systems (e.g., a backup
AC to take over when the primary AC fails). Further, if an AC is
manually reset, it should recover from the reset condition,
reconnect all the attached WTPs, and restore service to
endstations as rapidly as possible; this avoids issues such as
dropped voice calls and failed TCP sessions.
The recovery time in the case of either a reset recovery">
measurement, or a failover recovery measurement, is measured from
the onset of the reset or failure event (e.g., a forced failover
signal) to the restoration of data service. Restoration of data
service is deemed to have occurred when data packets are once
again received by the endstations associated with the DUT/SUT.
Note that in the case of failover measurements on DUTs/SUTs
incorporating hot-standby redundancy, it is possible for the
recovery time to be zero, i.e., no data loss or interruption of
service is noted.
Measurement Units:
Ahuja, et al. Expires July 5, 2008 [Page 35]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
seconds
Issues:
None
See Also:
Reset duration
4. Security Considerations
Documents of this type do not directly affect the security of the
Internet or of corporate networks as long as benchmarking is not
performed on devices or systems connected to operating networks.
Note that performance tests SHOULD be done on with adequate isolation
between the DUT and the remainder of the network, or with security
systems enabled, to avoid the possibility of compromising the
performance of operating networks in some manner.
5. IANA Considerations
There are no IANA actions requested in this memo. (Note to RFC
Editor: This section may be removed upon publication as a RFC.)
6. References
6.1. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Ahuja, et al. Expires July 5, 2008 [Page 36]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
6.2. Informative References
[802.11] IEEE, "ANSI/IEEE Std 802.11 "Part 11: Wireless LAN Medium
Access Control (MAC) and Physical Layer (PHY)
Specifications," ISO/IEC 8802-11:1999(E), ISBN 0-7381-
1658-0", 1999.
[802.11e] IEEE, "IEEE Std 802.11e-2005, "Part 11: Wireless LAN
Medium Access Control (MAC) and Physical Layer (PHY)
Specifications Amendment 8: Medium Access Control (MAC)
Quality of Service Enhancements", ISBN 0-7381-4772-9",
2005.
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983,
August 1996.
Authors' Addresses
Tarunesh Ahuja
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, California 95134
USA
Phone: +1 408 853 9252
Email: tahuja@cisco.com
Tom Alexander
VeriWave, Inc.
8770 SW Nimbus Ave,
Beaverton, Oregon 97008
USA
Phone: +1 971 327 7490
Email: tom@veriwave.com
Scott Bradner
Harvard University
29 Oxford St.
Cambridge, Massachusetts 02138
USA
Phone: +1 617 495 3864
Email: sob@harvard.edu
Ahuja, et al. Expires July 5, 2008 [Page 37]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Sanjay Hooda
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, California 95134
USA
Phone: +1 408 527 6403
Email: shooda@cisco.com
Jerry Perser
VeriWave, Inc.
5743 Corsa Avenue, Suite 224
Westlake Village, California 91362
USA
Phone: +1 818 889 2071
Email: jperser@veriwave.com
Muninder Sambi
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, California 95134
USA
Phone: +1 408 525 7298
Email: msambi@cisco.com
Ahuja, et al. Expires July 5, 2008 [Page 38]
Internet-Draft WLAN Switch Benchmarking Terminology January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Ahuja, et al. Expires July 5, 2008 [Page 39]
