<?xml version="1.0" encoding="UTF-8" ?> 
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- external references -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2544 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2544.xml">
<!ENTITY RFC1242 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1242.xml">
<!ENTITY RFC2285 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2285.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC1983 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1983.xml">
]>
<!--
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
-->
<?rfc toc="yes"?> 
<?rfc tocompact="no"?> 
<?rfc symrefs="yes"?> 
<?rfc sortrefs="yes"?> 
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!--
<?rfc strict="yes" ?>
-->

<rfc category="info" docName="draft-alexander-bmwg-wlan-switch-term-01" submissionType="IETF" xml:lang="en" ipr="full3978">

<front>
<title abbrev="WLAN Switch Benchmarking Terminology">Benchmarking Terminology for Wireless LAN Switching Systems</title> 
<author fullname="Tarunesh Ahuja" initials="T.A." surname="Ahuja">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region> 
<country>USA</country> 
</postal>
<phone>+1 408 853 9252</phone>
<email>tahuja@cisco.com</email>
</address>
</author>
<author fullname="Tom Alexander" initials="T.A." surname="Alexander">
<organization>VeriWave, Inc.</organization>
<address>
<postal>
<street>8770 SW Nimbus Ave,</street>
<city>Beaverton</city>
<code>97008</code>
<region>Oregon</region> 
<country>USA</country> 
</postal>
<phone>+1 971 327 7490</phone>
<email>tom@veriwave.com</email>
</address>
</author>
<author fullname="Scott Bradner" initials="S.B." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>29 Oxford St.</street>
<city>Cambridge</city>
<code>02138</code>
<region>Massachusetts</region> 
<country>USA</country> 
</postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<author fullname="Sanjay Hooda" initials="S.H." surname="Hooda">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region> 
<country>USA</country> 
</postal>
<phone>+1 408 527 6403</phone>
<email>shooda@cisco.com</email>
</address>
</author>
<author fullname="Jerry Perser" initials="J.P." surname="Perser">
<organization>VeriWave, Inc.</organization>
<address>
<postal>
<street>5743 Corsa Avenue, Suite 224</street>
<city>Westlake Village</city>
<code>91362</code>
<region>California</region> 
<country>USA</country> 
</postal>
<phone>+1 818 889 2071</phone>
<email>jperser@veriwave.com</email>
</address>
</author>
<author fullname="Muninder Sambi" initials="M.S." surname="Sambi">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Dr.</street>
<city>San Jose</city>
<code>95134</code>
<region>California</region> 
<country>USA</country> 
</postal>
<phone>+1 408 525 7298</phone>
<email>msambi@cisco.com</email>
</address>
</author>
<date month="January" year="2008" /> 
<area>Operations and Management Area</area> 
<workgroup>Internet Engineering Task Force</workgroup> 
<abstract>
<t> 
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.
</t>
</abstract>
</front>

<middle>
<section title="Introduction" toc="include">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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
   defined in RFC 2544 <xref target="RFC2544"></xref> and subsequently extended in RFC 2285
   <xref target="RFC2285"></xref>.  Terms generally applicable to WLAN switching systems are
   defined first, followed by specific terminology relating to data
   plane and control plane metrics.</t>
</section>

<section title="Existing definitions and requirements">
<t>RFC 1242, "Benchmarking Terminology for Network Interconnect Devices"
   <xref target="RFC1242"></xref> and RFC 2285, "Benchmarking Terminology for LAN Switching
   Devices" <xref target="RFC2285"></xref> 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 <xref target="802.11"></xref>. Commonly used
   terms may also be found in RFC 1983 <xref target="RFC1983"></xref>.</t>
<t>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.</t>
<t>The following terms are assumed to be taken as defined in RFC 1242
   <xref target="RFC1242"></xref>: Throughput, Latency, Constant Load, Frame Loss Rate, and
   Overhead Behavior. In addition, the following terms are taken as
   defined in RFC 2285 <xref target="RFC2285"></xref>: Forwarding Rates, Maximum Forwarding
   Rate, Loads, Device Under Test (DUT), and System Under Test (SUT).</t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>

<section title="Definitions of terms">

<t>The terminology defined in this document is divided into three main
   categories: general WLAN definitions, WLAN data plane definitions,
   and WLAN control plane definitions.</t>
   
<t>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.</t>

<t>WLAN data plane definitions relate to data frame forwarding
   functions within the WLAN architecture. </t>
   
<t>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
   usually unrelated to traffic forwarding, and handled by software on
   the AC and WTP.</t>

<section title="General terms">
         
<section title="Wireless LAN (WLAN)">
<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t>A radio-based local area network architecture.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t>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).</t>
<t> The most common WLAN protocol today is IEEE 802.11 <xref target="802.11"></xref>,
    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).</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
<t> Endstation (STA)</t>
<t> Service set identifier (SSID)</t>
</list></t>
</section>
<section title="Access controller (AC)">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A network infrastructure device that provides centralized control,
    management and frame switching functions for a WLAN.</t>
</list></t> 
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Wireless termination point (WTP)</t>
<t> Endstation (STA)</t>
<t> Wireless LAN (WLAN)</t>
</list></t>
</section>
<section title="Endstation (STA)">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A user or subscriber device within a WLAN, that connects to a WTP
    and sources or sinks data traffic.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> Endstations in a WLAN are connection-oriented, and must connect to
    the WLAN and authenticate with it before exchanging data traffic.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
</list></t>
</section>
<section title="Wireless termination point (WTP)">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A bridge between the wireless (RF) and wired domains, that acts in
    conjunction with an AC to provide services to endstations.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Access controller (AC)</t>
<t> Endstation (STA)</t>
</list></t>
</section>
<section title="Service set identifier (SSID)">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> Tag assigned to a specific logical WLAN.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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).</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty"><t> Wireless LAN (WLAN)</t>
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
<t> Endstation (STA)</t>
</list></t>
</section>
<section title="Rogue device">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> An unauthorized device, either an endstation or a WTP, that is
    introduced into a WLAN.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> Detection and isolation or containment of rogue devices is a
    usual function in most enterprise WLANs.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty"><t> Wireless LAN (WLAN)</t>
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
<t> Provisioned WTP</t>
<t> Unprovisioned WTP</t>
</list></t>
</section>
<section title="Provisioned WTP">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> WTPs that have been successfully registered with an AC.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>
</list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
<t> Rogue device</t>
<t> Unprovisioned WTP</t>
</list></t>
</section>    
<section title="Unprovisioned WTP">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A WTP that has not (yet) been successfully registered with an AC.</t>
   </list></t> 
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
 </list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Access controller (AC)</t>
<t> Wireless termination point (WTP)</t>
<t> Rogue device</t>
<t> Provisioned WTP</t>
</list></t>
</section>
<section title="Unicast traffic flow">
 
<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A stream of one or more data frames from a single source to a
    single intended destination.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> "User or application data" in this context refers to traffic that is
    not connected with control or management functions specific to the
    WLAN itself.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Multicast traffic flow</t>
</list></t>
</section>
<section title="Multicast traffic flow">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A stream of one or more data frames from a single source to more
    than one intended destination.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> "User or application data" in this context refers to traffic that is
    not connected with control or management functions specific to the
    WLAN itself.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Unicast traffic flow</t>
</list></t>
</section>
<section title="Best-effort traffic">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A unicast or multicast traffic flow that is not associated with any
    service guarantees, such as maximum loss, maximum latency, or
    maximum jitter.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Unicast traffic flow</t>
<t> Multicast traffic flow</t>
<t> High-priority traffic</t>
</list></t>
</section>
<section title="High-priority traffic">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
    
<t> High-priority traffic is usually marked by a QoS tag (e.g., a DSCP
    codepoint, an 802.11e Access Category value <xref target="802.11e"></xref>, 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).</t>
    
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Unicast traffic flow</t>
<t> Multicast traffic flow</t>
<t> Best-effort traffic</t>
</list></t>
</section>
<section title="Roaming">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The process whereby a WLAN endstation moves from the coverage area
    of one WTP to the coverage area of another.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> The exact sequence of events during roaming varies considerably,
    based on security mode and other factors. However, the general
    process is as follows:</t>

<t><list style="symbols">
        <t>the endstation makes a roaming decision based on some
            internal criteria, such as link quality or traffic load</t>

        <t>the endstation determines the new WTP with which it should
            associate or reassociate</t>
            
        <t>the endstation passively or actively disassociates with the
            current WTP, thereby interrupting data transfer</t>

        <t>the endstation performs a (re)association process with the
            new WTP</t>

        <t>data transfer resumes (i.e., the new WTP begins transferring
            data to the endstation)</t>
</list></t>

<t> 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.</t>

<t> Note that "roaming" in the WLAN context corresponds to "handover"
    or "handoff" in the cellular wireless context.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Roaming decision</t>
<t> Roaming delay</t>
<t> Roaming rate</t>
</list></t>
</section>
<section title="Inter-AC roaming">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A roaming situation wherein a WLAN endstation moves between WTPs
    connected to different ACs.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Roaming</t>
<t> Roaming delay</t>
<t> Intra-AC roaming</t>
</list></t>
</section>
<section title="Intra-AC roaming">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> A roaming situation wherein a WLAN endstation moves between WTPs
    connected to the same AC.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Roaming</t>
<t> Roaming delay</t>
<t> Inter-AC roaming</t>
</list></t>
</section>
<section title="Roaming decision">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The point in time at which a WLAN endstation decides to initiate a
    roaming process.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> Not applicable.</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Roaming</t>
<t> Roaming delay</t>
<t> Roaming rate</t>
</list></t>
</section>
<section title="Roam failure">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> Failure to successfully complete the roaming process and restore
    data service.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> The consequences of a roaming failure are usually catastrophic for
    user applications that are engaged in transferring data while
    roaming is taking place.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> Not applicable.</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Roaming</t>
<t> Roaming delay</t>
<t> Roaming rate</t>
</list></t>
</section>
<section title="Beacon period">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The nominal time interval between successive beacon frames emitted
    by a single WTP.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>

<t> The default beacon period of IEEE 802.11 WTPs is 102.4 msec.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> Time Units (one Time Unit, or TU, equals 1024 microseconds)</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Listen interval</t>
</list></t>
</section>
<section title="Listen interval">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t>  The time interval at which an endstation in sleep mode wakes to
     check for buffered traffic.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t>  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.</t>

<t>  The interval between polls for buffered data is known as the listen
     interval. The size of the listen interval is usually 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.</t>

<t>  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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  Beacon periods.</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  Beacon period</t>
</list></t>
</section>
<section title="Preauthentication">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The process of authenticating with a target WTP prior to performing
    a roam to that WTP.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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 over the wired
    infrastructure to the target WTP.</t>
    
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  Roaming delay</t>
<t>  PMKID caching</t>
</list></t>
</section>
<section title="PMKID caching">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The process of retaining (caching) security contexts when roaming
    between WTPs, and using the cached contexts to reduce roaming delay.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  Roaming delay</t>
<t>  Preauthentication</t>
</list></t>
</section>
<section title="QoS differentiation">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t>  Differential handling of traffic flows based on QoS parameters
     assigned to them.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t>  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.</t>

<t>  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 <xref target="802.11e"></xref>
     specifies a traffic prioritization and differential medium access
     scheme suitable for IEEE 802.11 WLANs.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  QoS Threshold</t>
</list></t>
</section>
</section>
<section title="Data plane terminology">

<t>The terminology in the following subsections relate directly to
   metrics and measurement procedures for data plane functions.</t>

<section title="Aggregate Multicast Throughput">

<t> Definition:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> As per RFC 1242 <xref target="RFC1242"></xref>, 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.</t>

<t> 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.</t>
</list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N-octet input frames per second</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t> 
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Aggregate Multicast Forwarding Rate</t>
</list></t>
</section>
<section title="Aggregate Maximum Multicast Forwarding Rate">

<t> Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The maximum aggregate forwarding rate of a set of one or more
    multicast traffic flows by a DUT/SUT, irrespective of frame loss.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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 <xref target="RFC2285"></xref>). 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).</t>

<t> 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.</t>
</list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> N-octet frames per second</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
  </list></t> 
<t>See Also:   </t>
<t><list hangIndent="4" style="empty">
<t> Aggregate Multicast Throughput</t>
</list></t>
</section>
<section title="QoS threshold">

<t>Definition:</t>
   <t><list hangIndent="4" style="empty"> 
<t> A predefined set of minimum acceptable values for specific
    properties of a forwarded unicast or multicast traffic flow.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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 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.</t>

<t> For most RTP-based traffic, four parameters are of interest in this
    regard: the average latency, the smoothed interarrival jitter (see
    RFC 3550 <xref target="RFC3550"></xref>), the average packet loss, and the loss burst
    distribution. The QoS threshold for a test specifies the maximum
    acceptable levels of these parameters.</t>
    
<t> 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.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  N/A</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  QoS differentiation</t>
</list></t>
</section>
</section>
<section title="Control plane terminology">

<t>The terminology in the following subsections relate directly to
   metrics and measurement procedures for control plane functions.</t>

<section title="Endstation capacity">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The maximum number of wireless endstations that can be
    simultaneously associated with a DUT/SUT.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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. </t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> endstations</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Endstation (STA)</t>
<t> Access controller</t>
<t> Endstation association rate</t>
</list></t>
</section>
<section title="Endstation association rate">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The sustained rate at which wireless endstations can successfully
    associate with wireless controller. </t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
   </list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> endstations associated per second</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Endstation (STA)</t>
<t> Access controller</t>
<t> Endstation capacity</t>
</list></t>
</section>    
<section title="WTP capacity">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The maximum number of WTPs that can be simultaneously provisioned
    by an AC.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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. </t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> WTPs</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty"><t> Access controller</t>
<t> Provisioned WTP</t>
<t> Endstation capacity</t>
</list></t>
</section>    
<section title="Roaming rate">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The rate at which endstations can roam from the coverage area of one
    WTP to another (i.e., between WTPs) without failure.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>

<t> 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.</t>
   </list></t> 
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> roams per second</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Endstation (STA)</t>
<t> Wireless termination point (WTP)</t>
<t> Roaming</t>
<t> Roaming failure</t>
<t> Roaming delay</t>
<t> Endstation distribution</t>
</list></t>
</section>
<section title="Roaming delay">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The time interval between the initiation and successful completion
    of a roaming event.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>

<t> 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 measurement
    results.</t>

<t> 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.</t>

<t> A roaming event MUST NOT be counted towards roaming delay
    measurements if a roaming failure occurs.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> milliseconds</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Endstation (STA)</t>
<t> Wireless termination point (WTP)</t>
<t> Roaming</t>
<t> Roaming decision</t>
<t> Roaming failure</t>
<t> Roaming rate</t>
<t> Endstation distribution</t>
</list></t>
</section>
<section title="Reset duration">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  seconds</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  Reset recovery time</t>
<t>  Failover recovery time</t>
</list></t>
</section>
<section title="Reset recovery time">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t><list style="hanging">
<t>     Reset recovery time = AC reset recovery time +
                            (Rate of WTP association * Number of WTPs)</t>
</list></t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> seconds</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> WTP association rate</t>
<t> AC reset recovery time</t>
<t> Failover recovery time</t>
</list></t>
</section>
<section title="WTP association rate">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The rate at which WTPs can be discovered and provisioned by an AC.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>

<t> 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.</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> WTPs per second.</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Provisioned WTP</t>
<t> Reset recovery time</t>
<t> AC reset recovery time</t>
<t> Failover recovery time</t>
</list></t>
</section>
<section title="AC reset recovery time">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> 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.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t> 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.)</t>

<t> 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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t> seconds</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t> None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t> Provisioned WTP</t>
<t> Reset recovery time</t>
<t> WTP association rate</t>
<t> Failover recovery time</t>
</list></t>
</section>
<section title="Failover recovery time">

<t>Definition:</t>
<t><list hangIndent="4" style="empty">
<t> The time required to restore service after a catastrophic hardware
    or software event in the DUT/SUT.</t>
</list></t>
<t>Discussion:</t>
<t><list hangIndent="4" style="empty">
<t>  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.</t>

<t>  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.</t>

<t>  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.</t>
</list></t>
<t>Measurement Units:</t>
<t><list hangIndent="4" style="empty">
<t>  seconds</t>
</list></t>
<t>Issues:</t>
<t><list hangIndent="4" style="empty">
<t>  None</t>
</list></t>
<t>See Also:</t>
<t><list hangIndent="4" style="empty">
<t>  Reset duration</t>
</list></t>
</section>
</section>
</section>

<section anchor="Security" title="Security Considerations">
<t>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.</t>

<t>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.</t>
</section>

<section anchor="IANA" title="IANA Considerations">
<t>There are no IANA actions requested in this memo. (Note to RFC
   Editor: This section may be removed upon publication as a RFC.)</t>
</section>

</middle>

<back>
<references title="Normative References">
&RFC2119;
&RFC2544;
&RFC1242;
&RFC2285;
&RFC3550;
</references>

<references title="Informative References"> 
<reference anchor="802.11">
    <front>
        <title>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</title>
        <author initials="" surname="">
            <organization>IEEE</organization>
        </author>
        <date year="1999" />
    </front>
</reference>
<reference anchor="802.11e">
    <front>
        <title>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</title>
        <author initials="" surname="">
            <organization>IEEE</organization>
        </author>
        <date year="2005" />
    </front>
</reference>
&RFC1983;
</references>

</back>

</rfc>
