1. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 1 IEEE 802.11-IETF Liaison Report Date: 2012-01-19 Authors:

2. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 2 Abstract This presentation contains the IEEE 802.11 – IETF liaison report for January 2012.

3. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 3 Protocol to Access White Space database (paws) WG paws Working Group was formed June 2011, see http://datatracker.ietf.org/wg/paws/http://datatracker.ietf.org/wg/paws/ Charter and problem statement documents: –Charter, see https://datatracker.ietf.org/wg/paws/charter/https://datatracker.ietf.org/wg/paws/charter/ –Problem Statement, see https://datatracker.ietf.org/doc/draft-patil-paws-problem-stmt/https://datatracker.ietf.org/doc/draft-patil-paws-problem-stmt/ –Use Case Scenarios, see https://datatracker.ietf.org/doc/draft-probasco-paws-overview-usecases/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/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/http://datatracker.ietf.org/doc/draft-das-paws-protocol/ currently an individual submission First Working Group draft anticipated November 2012

4. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 4 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.

5. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 5 Charter defines Background, Problem Statement, Objectives and Deliverables 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.

6. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 6 Charter defines Background, Problem Statement, Objectives and Deliverables 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.

7. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 7 Charter defines Background, Problem Statement, Objectives and Deliverables 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.

8. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 8 Charter defines Background, Problem Statement, Objectives and Deliverables 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.

9. doc.: IEEE 802.11-12/0122r1 Submission Some Defined elements January 2012 Slide 9 Others define the Authorized database protocols that APs and Fixed devices shall use, and each AP is certified 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)https://mentor.ieee.org/802.11/dcn/11/11-11-0175-01-00af-fcc-tvws-terminology.ppt PAWS

10. 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 is certified 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.ppthttps://mentor.ieee.org/802.11/dcn/11/11-11-0175-02-00af-fcc-tvws-terminology.ppt PAWS

11. 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 for 1.Registration for Fixed Devices 2.Channel query for its location (Fixed and Mode II) 3.FCC ID validation of Mode I device Qn: 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 sufficient 2.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 signal 3. 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 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 STAhttps://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after-new-fcc-rules.ppt PAWS January 2012

12. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 12 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/ 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/

13. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 13 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/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)

14. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 14 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/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.

15. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 15 Protocol to Access White Space database (paws) Data Model Requirements See https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ - DRAFThttps://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ 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.

16. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 16 Protocol to Access White Space database (paws) Protocol Requirements See https://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ - DRAFThttps://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ 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.

17. doc.: IEEE 802.11-12/0122r1 Submission Likely Protocol Layering +-+-+-+-+-+-+-+-+-+-+-+-+ | WS Appl. Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+ | HTTPS | +-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable Transport | +-+-+-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+-+-+ January 2012 Dorothy Stanley, Aruba NetworksSlide 17 Source: http://www.ietf.org/proceedings/82/slides/paws-3.pdfhttp://www.ietf.org/proceedings/82/slides/paws-3.pdf

18. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 18 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.ppthttps://mentor.ieee.org/802.11/dcn/11/11-11-0448-00-00af- update-on-european-uk-regulatory-in-the-tvws.ppt

19. 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.pptxhttps://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

20. doc.: IEEE 802.11-12/0122r1 Submission Database architecture (FCC) 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.pptxhttps://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

21. doc.: IEEE 802.11-12/0122r1 Submission Database architecture (FCC) ‘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, ETRI Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptxhttps://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx

22. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 22 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 http://transition.fcc.gov/oet/ whitespace/tvwpdda.html [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.pptxhttps://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.ppthttps://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.pdfhttp://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.ppthttps://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.pptxhttps://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.ppthttps://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.ppthttps://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after- new-fcc-rules.ppt

23. doc.: IEEE 802.11-12/0122r1 Submission Questions? January 2012 Dorothy Stanley, Aruba NetworksSlide 23

24. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 24 Handover Keying (HOKEY) Hokey Charter available at http://www.ietf.org/html.charters/hokey-charter.htmlhttp://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 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.txthttp://www.ietf.org/rfc/rfc5295.txt –EAP Extensions for EAP Re-authentication Protocol (ERP), see http://www.ietf.org/rfc/rfc5296.txt 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] http://www.ietf.org/rfc/rfc5749.txt –Extensible Authentication Protocol (EAP) Early Authentication Problem Statement, see http://tools.ietf.org/html/rfc5836 [published April 2010] http://tools.ietf.org/html/rfc5836 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/ http://datatracker.ietf.org/doc/draft-ietf-hokey-erp-aak/ –Updated: EAP Architecture Design, http://datatracker.ietf.org/doc/draft-ietf-hokey-arch-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

25. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 25 EAP Method Update (EMU) Working Group website: http://www.ietf.org/html.charters/emu-charter.htmlhttp://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/ 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/ 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/ http://datatracker.ietf.org/doc/draft-ietf-emu-eaptunnel-req/

26. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 26 6LOWPAN Working Group Working Group website: http://datatracker.ietf.org/wg/6lowpan/charter/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/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/http://datatracker.ietf.org/doc/rfc6282/ –Design and Application Spaces (Use Cases), see http://datatracker.ietf.org/doc/draft-ietf- 6lowpan-usecases/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/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 / http://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle /

27. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 27 ROLL Working Group Working Group website: http://datatracker.ietf.org/wg/roll/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/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/ 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.pdfhttps://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/ 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/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/http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/

28. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 28 CORE Working Group CORE ( Constrained RESTful Environments) Working Group website: http://datatracker.ietf.org/wg/core/http://datatracker.ietf.org/wg/core/ Focus: framework for resource-oriented applications intended to run on constrained IP networks –Constrained Application Protocol, see http://datatracker.ietf.org/doc/draft-ietf-core- coap/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/http://datatracker.ietf.org/doc/draft-dijk-core-groupcomm- misc/http://datatracker.ietf.org/doc/draft-shelby-core-interfaces/ –Constrained Application Protocol, see http://datatracker.ietf.org/doc/draft-ietf-core-coap/http://datatracker.ietf.org/doc/draft-ietf-core-coap/ –Core link format, see http://datatracker.ietf.org/doc/draft-ietf-core-link-format/http://datatracker.ietf.org/doc/draft-ietf-core-link-format/ –Observing Resources in CoAP, see http://datatracker.ietf.org/doc/draft-ietf-core-observe/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-02http://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/http://datatracker.ietf.org/doc/draft- garcia-core-security/

29. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 29 Emergency Context Resolution with Internet Technologies (ECRIT) Working Group website: http://www.ietf.org/dyn/wg/charter/ecrit- charter.htmlhttp://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/ 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.txthttp://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.txthttp://tools.ietf.org/id/draft- thomson-ecrit-civic-boundary-02.txt Updates [Jan 2012] –http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/http://datatracker.ietf.org/doc/draft-ietf-ecrit-lost-sync/

30. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 30 IETF Geographic Location and Privacy (Geopriv) WG See http://www.ietf.org/html.charters/geopriv-charter.htmlhttp://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.txthttp://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.txthttp://www.ietf.org/rfc/rfc3693.txt –Civic Address definitions, see http://www.ietf.org/rfc/rfc4776.txthttp://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.dochttps://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/ http://datatracker.ietf.org/doc/draft-ietf-geopriv-policy-uri/ –Relative Location, see http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/http://datatracker.ietf.org/doc/draft-ietf-geopriv-relative-location/

31. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 31 Home Networking (homenet) WG See https://datatracker.ietf.org/wg/homenet/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/https://datatracker.ietf.org/doc/draft-ietf-homenet- arch/

32. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 32 Home Networking Trends Home Networking Trends, Source: http://www.ietf.org/proceedings/81/slides/homenet-1.pdf 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.pdfhttp://www.ietf.org/proceedings/81/slides/homenet-1.pdf

33. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 33 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

34. doc.: IEEE 802.11-12/0122r1 Submission January 2012 Dorothy Stanley, Aruba NetworksSlide 34 References RFC 4017 - IEEE 802.11 Requirements on EAP Methods