doc.: ieee 802.11-12/0122r1 submission january 2012 dorothy stanley, aruba networksslide 1 ieee...

doc.: IEEE 802.11-12/0122r1

Submission

January 2012

Dorothy Stanley, Aruba NetworksSlide 1

IEEE 802.11-IETF Liaison ReportDate: 2012-01-19

Name Company Address Phone email Dorothy Stanley Aruba Networks 1322 Crossman Ave

Sunnyvale, CA 630-363-1389 dstanley@arubanetworks.

com

Authors:

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Abstract

This presentation contains the IEEE 802.11 – IETF liaison report for January 2012.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) WG

•paws Working Group was formed June 2011, see http://datatracker.ietf.org/wg/paws/ •Charter and problem statement documents:

– Charter, see https://datatracker.ietf.org/wg/paws/charter/ – Problem Statement, see https://datatracker.ietf.org/doc/draft-patil-paws-problem-stmt/ – Use Case Scenarios, see https://datatracker.ietf.org/doc/draft-probasco-paws-overview-usecases/ – New: Use Case Requirements, see http

://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ • Goals and Milestones

– Oct 2011 - Submit 'Use Cases and Requirements for Accessing a Radio White Space Database' to the IESG for publication as Informational

– April 2012 - Submit 'Accessing a Radio White Space Database' to the IESG for publication as Proposed Standard

•[January 2012 Update]– Device to Database protocol, http://datatracker.ietf.org/doc/draft-das-paws-protocol/

• currently an individual submission• First Working Group draft anticipated November 2012

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Charter defines Background, Problem Statement, Objectives and Deliverables

•Background– Radio spectrum is a limited resource.– National and international bodies assign different frequencies for specific

uses, and in most cases license the rights to use these frequencies.– Locally unused spectrum is commonly called "white space" and may be

made available to other services on a basis of non-interference with the primary user of the frequencies concerned (if any).

– This technique can help "unlock" existing spectrum, for example to enable the wireless communications industry to provide more services over frequencies associated with unused television channels.

– An obvious requirement is that white space uses must not interfere with the primary use of the spectrum.

– This is achieved through spatial and/or temporal separation of the primary user and whitespace user with due consideration made to the radio characteristics of the two uses.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012



• Problem Statement - 1–The fundamental problem is enabling a radio device to determine, in a specific location and at specific time, if any white space is available for secondary use. –There are two parties to such an interaction…A database containing records about the protected contours (in space and time) of primary spectrum users…and a radio device that wishes to query such a database.–The contents of white space databases, and the needs of radio devices, are being defined elsewhere. However, these parties need a protocol for communication that will enable radio devices to find out what white space is available at a given time in a given location. –It is expected that white space databases will be reachable via the Internet, and that radio devices too will have some form of Internet connectivity, directly or indirectly. Therefore, it is appropriate to define an Internet-based protocol for querying white space databases and receiving responses from such databases.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012



• Problem Statement - 2–… such a protocol would enable a radio device that knows its location and the current time to …:

• Determine the relevant white space database to query. • Connect to the database using a well-defined access method. • Provide its geolocation and perhaps other data to the database

using a well-defined format for querying the database. • Receive in return a list of currently available white space

using a well-defined format for returning information. –Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. –If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012



• Objectives: –Standardize a mechanism for discovering a white space database. –Standardize a method for accessing a white space database. –Standardize query and response formats to be carried over the database access method. –Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012



• Deliverables–A description of the relevant use cases and requirements. This document shall be Informational. –A specification of the mechanism for discovering a white space database, the method for accessing a white space database, and the query/response formats for interacting with a white space database. This document shall be Standards Track.

doc.: IEEE 802.11-12/0122r1

Submission

Some Defined elements

January 2012

Slide 9

Others define the Authorized database protocolsthat APs and Fixed devices shall use, and each AP iscertified to operate with a specific Authorized TV bands database.

Peter Ecclesine, Cisco

Source: https://mentor.ieee.org/802.11/dcn/11/11-11-0175-01-00af-fcc-tvws-terminology.ppt Note, Registered Location (Secure) Server applicable to Europe only (not US)

PAW

S

PAWS

doc.: IEEE 802.11-12/0122r1

Submission

Some Defined elements

January 2012

Slide 10

Others define the Authorized database protocols that APs and Fixed devices shall use, and each AP iscertified to operate with a specific Authorized TV bands database. A Registered Location Secure Server accesses the Authorized databases with protocols that others define, and may provide a persistent internet address to the databases. APs and 802.11 stations access a Registered Location Secure Server with radio protocols that IEEE 802.11 defines.

Peter Ecclesine, Cisco

Source: https://mentor.ieee.org/802.11/dcn/11/11-11-0175-02-00af-fcc-tvws-terminology.ppt

PAW

S

PAW

S

doc.: IEEE 802.11-12/0122r1

Submission

Scenario 1: AP has direct connection to Internet for DB access

Signaling Interfaces and Open Issues:

DB Access: could be for1. Registration for Fixed Devices2. Channel query for its location (Fixed and Mode II)3. FCC ID validation of Mode I deviceQn: Is it beyond scope of 802.11 ? OR, need to specify message

content/format at least?

Initial wireless signal before Mode I can attempt contact:1. Simple beacon frame reception can be sufficient2. Any need to define signal seeking contact (FCC term) ?3. Shall we call it Enabling signal?

Enablement (contact establishment for channel query): 1. Is enablement term fine (contact establishment in FCC) ?2. Request contains FCC ID, Response: channel list + Info to

decode contact verification signal3. Enabler is a functional unit to serve its Mode I contacts

WLAN Operational control (contact verification):1. Must hear contact verification signal at least once every 60

s (from same Enabling STA providing channel list)2. Shall we still call it Enabling Signal?

Network Architectures and Interfaces

FCC DB

1. Enablement

2. WLAN operations

DB Access

Dependent STA(Non-beaconing STA)

Enabling AP (fixed or personal/ portable beaconing

STA)

0. Hear signal

FCC DB

1. Enablement

2. WLAN operations

DB Access

Dependent STA(Non-beaconing STA)

Enabling AP (fixed or personal/ portable beaconing

STA)

0. Hear signal

Source: https://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after-new-fcc-rules.ppt Note: Enabling AP =Geolocation Data Base Controlled (GDC) AP; Dependent STA=GDC STA

PAWS

January 2012

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) WG Goals and Milestones

•Published Goals and Milestones– Oct 2011 - Submit 'Use Cases and Requirements for Accessing a Radio

White Space Database' to the IESG for publication as Informational – April 2012 - Submit 'Accessing a Radio White Space Database' to the IESG

for publication as Proposed Standard

•Status:– Use case and Requirements draft available, see

https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ – Working Group Protocol specification Draft anticipated to be adopted

2H2012, individual submissions available, see• https://datatracker.ietf.org/doc/draft-caufield-paws-protocol-for-tvws/ • https://datatracker.ietf.org/doc/draft-das-paws-protocol/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) Use Cases

•Use Case Scenarios, see https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/

– TVWS database discovery

– Device registration with trusted Database

– Hotspot: urban internet connectivity service

– Wide-Area or Rural internet broadband access

– Offloading: moving traffic to a white space network

– TVWS for backhaul

– Rapid deployed network for emergency scenario

– Mobility

– Indoor Networking

– Machine to Machine (M2M)

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) Use Cases

•Use Case Scenarios, see https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ •In Scope:

– 1. Determine the relevant white space database to query.

– 2. Connect to the database using a well-defined access method.

– 3. Register with the database using a well-defined protocol.

– 4. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database.

– 5. Receive in return a list of currently available white space using a well-defined format for returning information.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) Data Model Requirements

•See https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ - DRAFT•The Data Model MUST support specifying the antenna height parameter of the subject. •The Data Model MUST support specifying an ID of the subject. This ID would be the ID of the device used to be certified by a regulatory body for a regulatory domain. •The Data Model MUST support specifying the location of the subject and the uncertainty by which the location was determined, when confidence level is considered 95%. •The Data Model MUST support specifying the location of the subject and accuracy of location determination. •The Data Model MUST support specifying a list of available channel list and time constrains for the channel list availability. •The Data Model MUST support specifying the maximum output power of the subject. •The Data Model MUST support specifying channel availability information for multiple locations. •The Data Model MUST support specifying channel availability information for an area around a specified location. •The Data Model MUST support specifying multiple spectrum masks, each containing (1) the lowest applicable frequency in MHz, (2) the highest possible frequency in MHz, (3) the maximum total EIRP over the frequency range defined by the spectrum mask, (4) the general spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask expressed as in [80211P] or [FCC47CFR90.210], and (5) measurement resolution bandwidth for EIRP measurements.

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) Protocol Requirements

•See https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ - DRAFT•The protocol MUST provide a mechanism for the subject to discover the WS Database it has to use at a given location. •The protocol MUST support regulatory domain discovery. •The protocol between the master device and the WS Database MUST support pushing updates in channel availability changes to subjects. •The protocol between the master device and the WS Database MUST support mutual authentication and authorization. •The protocol between the master device and the WS Database MUST support integrity and confidentiality protection. •The protocol MUST support both username/password and digital certificates based authentication. •A master device MAY register with a trusted white space database. •A master device MUST place its location into the query it makes to the whitespace database. •A master device MUST be able to query the whitespace database for channel availability information for a specific expected coverage area around its current location. •A master device MUST send Device ID, serial number and device location in the query it makes to the database. •A master device MAY send additional information in the query it makes to the database such as antenna height above ground level or antenna characteristics. •A master device MUST be capable of validating the digital certificate of the WS Database. •A master device MUST be capable of checking the validity of the WS Database certificate and whether it has been revoked or not.

doc.: IEEE 802.11-12/0122r1

Submission

Likely Protocol Layering

+-+-+-+-+-+-+-+-+-+-+-+-+

| WS Appl. Protocol |

+-+-+-+-+-+-+-+-+-+-+-+-+

| HTTPS |

+-+-+-+-+-+-+-+-+-+-+-+-+

| Reliable Transport |

+-+-+-+-+-+-+-+-+-+-+-+-+

| IP |

+-+-+-+-+-+-+-+-+-+-+-+-+

January 2012


Source: http://www.ietf.org/proceedings/82/slides/paws-3.pdf

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Protocol to Access White Space database (paws) WG

•Data Base Status – Not part of paws•Also see https://mentor.ieee.org/802.11/dcn/11/11-11-0448-00-00af-update-on-european-uk-regulatory-in-the-tvws.ppt

doc.: IEEE 802.11-12/0122r1

Submission

Database architecture(FCC)

• Multiple database administrators that could offer services on a competitive basis

• 10 designated TV white space database administrators are [1][3]:– Airity, – Comsearch – Frequency Finder– Google– KB Enterprises LLC and LS Telecom– Key Bridge Global LLC– NeuStar– Spectrum Bridge– Telcordia Technologies– Microsoft

Slide 19

January 2012

Donghun Lee, et al, ETRI

Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

doc.: IEEE 802.11-12/0122r1

Submission


• Google’s clearinghouse model architecture[3]:

Slide 20

January 2012

Donghun Lee, et al, ETRI

Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

doc.: IEEE 802.11-12/0122r1

Submission


• ‘Clearinghouse’ model proposed by Google [3]– Partitions the process of providing information on available channels to

WSDs

– The key element is the clearinghouse, which aggregates and hosts the raw data needed to perform database calculations.

– The TVWS database service providers would use the raw data together with other required regulatory inputs in the process of calculating the contents of their own databases

• The clearinghouse model would provide substantial benefits, including, facilitating greater choice in service providers, and minimizing the burden of syncing with multiple parties.

• It would leave open the possibility of approving quickly other clearinghouse and TVWS Database Service proposals, leading to more robust market forces and promoting innovation and competition in basic and enhanced database services.

Slide 21

January 2012

Donghun Lee, et al, ETRISource: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


References• [1] TV Band (White Spaces) Database Administrators Guide, http://transition.fcc.gov/oet/

whitespace/tvwpdda.html FCC 08-260 : Second report and order and memorandum opinion and order, Nov, 2008

• [2] FCC 10-174 : Second memorandum opinion and order, Sep, 2010• [3] Proposal by Google Inc. to provide a TV band device database management solution, Google

Inc., Jan. 2010• Gabor Bajko 11af submission,

https://mentor.ieee.org/802.11/dcn/11/11-11-0438-00-00af-ietf-paws.pptx• July 2010 Plenary Tutorial presentation, https://

mentor.ieee.org/802.19/dcn/10/19-10-0096-01-0000-coexistence-in-the-tv-white-space.ppt • March 2009 plenary tutorial: http://

ieee802.org/802_tutorials/2009-03/2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf • https://

mentor.ieee.org/802.11/dcn/11/11-11-0448-00-00af-update-on-european-uk-regulatory-in-the-tvws.ppt

• https://mentor.ieee.org/802.11/dcn/11/11-11-0175-02-00af-fcc-tvws-terminology.ppt • https://

mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx • https://

mentor.ieee.org/802.11/dcn/11/11-11-0448-00-00af-update-on-european-uk-regulatory-in-the-tvws.ppt

• https://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after-new-fcc-rules.ppt

doc.: IEEE 802.11-12/0122r1

Submission

Questions?

January 2012


doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Handover Keying (HOKEY)• Hokey Charter available at http://www.ietf.org/html.charters/hokey-charter.html

– Extensions to current EAP key framework to facilitate inter-authenticator handover and roaming.

• Published RFCs: – Handover Key Management and Re-authentication Problem Statement, see

http://www.ietf.org/rfc/rfc5169.txt – Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),

see http://www.ietf.org/rfc/rfc5295.txt – EAP Extensions for EAP Re-authentication Protocol (ERP), see

http://www.ietf.org/rfc/rfc5296.txt – Distribution of EAP based keys for handover and re-authentication , see

http://www.ietf.org/rfc/rfc5749.txt [published March 2010]– Extensible Authentication Protocol (EAP) Early Authentication Problem Statement, see

http://tools.ietf.org/html/rfc5836 [published April 2010]• Updates [Jan 2012]

– Updated: EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) http://datatracker.ietf.org/doc/draft-ietf-hokey-erp-aak/

– Updated: EAP Architecture Design, http://datatracker.ietf.org/doc/draft-ietf-hokey-arch-design/

– Remaining milestones:• Nov 2011: Submit the revision of RFC 5296 to IESG• March 2012: Re-charter or shut down WG

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


EAP Method Update (EMU)

• Working Group website: http://www.ietf.org/html.charters/emu-charter.html • Updates [Jan 2012]:

– Publication requested for Channel Binding Support for EAP Methods draft, http://datatracker.ietf.org/doc/draft-ietf-emu-chbind/

– Updates to draft of Standard Tunnel based EAP method, see http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/

– Requirements for a Tunnel based EAP method in editor queue, see http://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


6LOWPAN Working Group

• Working Group website: http://datatracker.ietf.org/wg/6lowpan/charter/• Focus: IPv6 over Low Power PAN: Adaption of IPv6 protocol to operate

on constrained nodes and link layers– RFC 4944: adaption of IPv6 to 802.15.4 link layer– Improved header compression scheme, see

http://datatracker.ietf.org/doc/draft-ietf-6lowpan-hc/ – RFC 6282, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”

published, see http://datatracker.ietf.org/doc/rfc6282/ – Design and Application Spaces (Use Cases), see

http://datatracker.ietf.org/doc/draft-ietf-6lowpan-usecases/ – Problem Statement and Requirements for 6LOWPAN, see

http://datatracker.ietf.org/doc/draft-ietf-6lowpan-routing-requirements/

• Updates [Jan 2012]– Revision available: Transmission of IPv6 packets over Bluetooth Low Energy, see

http://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


ROLL Working Group

• Working Group website: http://datatracker.ietf.org/wg/roll/

• Focus: Routing over Low Power and Lossy Networks– Routing Objectives, see http://datatracker.ietf.org/doc/draft-ietf-roll-of0/

– Routing protocol for efficient operation in low-power, lossy networks, see http://datatracker.ietf.org/doc/draft-ietf-roll-rpl/

• Reference: Smart Grid Tutorial Presentations, slides 58-60– https://mentor.ieee.org/802-ec/dcn/10/ec-10-0013-00-00EC-smart-grid-information

-update-july-2010.pdf

• Updates [Jan 2012]– Updated: A Security Framework for Routing over Low Power and Lossy Networks, see

http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ – Of interest: Applicability of ROLL in AMI Networks, see

http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/

– Of Interest: A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network, see http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


CORE Working Group

• CORE (Constrained RESTful Environments) Working Group website: http://datatracker.ietf.org/wg/core/

• Focus: framework for resource-oriented applicationsintended to run on constrained IP networks

– Constrained Application Protocol, see http://datatracker.ietf.org/doc/draft-ietf-core-coap/

• Updates [Jan 2012] – New: Communication topics, see http://datatracker.ietf.org/doc/draft-dijk-core-groupcomm-misc/

and interfaces, see http://datatracker.ietf.org/doc/draft-shelby-core-interfaces/

– Constrained Application Protocol, see http://datatracker.ietf.org/doc/draft-ietf-core-coap/

– Core link format, see http://datatracker.ietf.org/doc/draft-ietf-core-link-format/

– Observing Resources in CoAP, see http://datatracker.ietf.org/doc/draft-ietf-core-observe/

– Security Bootstrapping of Resource-Constrained Devices, see http://tools.ietf.org/html/draft-sarikaya-core-sbootstrapping-02

– Security Considerations in IP based Internet of Things, see http://datatracker.ietf.org/doc/draft-garcia-core-security/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Emergency Context Resolution with Internet Technologies (ECRIT)

• Working Group website: http://www.ietf.org/dyn/wg/charter/ecrit-charter.html

• Emergency Services – Framework for Emergency Calling using Internet Multimedia, see

http://datatracker.ietf.org/doc/draft-ietf-ecrit-framework/ – Unauthenticated access being discussed, see

http://tools.ietf.org/id/draft-schulzrinne-ecrit-unauthenticated-access-08.txt – Describing boundaries for Civic Addresses, see

http://tools.ietf.org/id/draft-thomson-ecrit-civic-boundary-02.txt • Updates [Jan 2012]

– http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


IETF Geographic Location and Privacy (Geopriv) WG

• See http://www.ietf.org/html.charters/geopriv-charter.html • Specific reference to WLANs:

– Carrying Location Objects in RADIUS, see http://www.ietf.org/proceedings/66/IDs/draft-ietf-geopriv-radius-lo-08.txt

• Documents referenced in 802.11 (TGv)– Geopriv Requirements, see http://www.ietf.org/rfc/rfc3693.txt – Civic Address definitions, see http://www.ietf.org/rfc/rfc4776.txt

• July 2009 Liaison to IETF GEOPRIV– See https://mentor.ieee.org/802.11/dcn/09/11-09-0718-01-000v-liaison-request-to-ietf-

geopriv.doc • Updates [Jan 2012]

– Location Configuration Extensions for Policy Management, see http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/

– Relative Location, see http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Home Networking (homenet) WG

• See https://datatracker.ietf.org/wg/homenet/ • This working group focuses on the evolving networking technology

within and among relatively small "residential home" networks – The task of the group is to produce an architecture document that outlines how to construct

home networks involving multiple routers and subnets. – This document is expected to apply the IPv6 addressing architecture, prefix delegation, global

and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate.

• Updates [Jan 2012]– Home networking Architecture for IPv6, see https://datatracker.ietf.org/doc/draft-ietf-homenet-

arch/

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


Home Networking Trends

• Home Networking Trends, Source: http://www.ietf.org/proceedings/81/slides/homenet-1.pdf

– IPv6 – moving to towards this– Separate networks (guest vs. private vs. utility)– Explosion in the number of devices– Different technologies (Ethernet-like vs. sensor networks)– Borders and the elimination of NAT– Naming and manual configuration of addresses

• Homenet Work is NOT wireless related, but– 802.11 Wireless devices are an integral part of home networks– Potential for additional functionality in residential APs to meet needs of more complex home networks

Source: http://www.ietf.org/proceedings/81/slides/homenet-1.pdf

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


IETF Meetings• Meetings:

– March 25-30, 2012 - Paris

– July 29 – August 3, 2012 - Vancouver

– November 4-9, 2012 - Atlanta

– March 10-15, 2013 – Orlando

• http://www.ietf.org

doc.: IEEE 802.11-12/0122r1

Submission

January 2012


References

• RFC 4017 - IEEE 802.11 Requirements on EAP Methods