1 / 34

IEEE 802.11-IETF Liaison Report

IEEE 802.11-IETF Liaison Report. Authors:. Date: 2012-01-19. Abstract. This presentation contains the IEEE 802.11 – IETF liaison report for January 2012. Protocol to Access White Space database (paws) WG. paws Working Group was formed June 2011, see http://datatracker.ietf.org/wg/paws /

jun
Download Presentation

IEEE 802.11-IETF Liaison Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IEEE 802.11-IETF Liaison Report Authors: Date: 2012-01-19 Dorothy Stanley, Aruba Networks

  2. Abstract This presentation contains the IEEE 802.11 – IETF liaison report for January 2012. Dorothy Stanley, Aruba Networks

  3. 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 Dorothy Stanley, Aruba Networks

  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. Dorothy Stanley, Aruba Networks

  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. Dorothy Stanley, Aruba Networks

  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. Dorothy Stanley, Aruba Networks

  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. Dorothy Stanley, Aruba Networks

  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. Dorothy Stanley, Aruba Networks

  9. Some Defined elements PAWS PAWS 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. 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) Peter Ecclesine, Cisco

  10. Some Defined elements PAWS PAWS 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. Source: https://mentor.ieee.org/802.11/dcn/11/11-11-0175-02-00af-fcc-tvws-terminology.ppt Peter Ecclesine, Cisco

  11. Network Architectures and Interfaces • Signaling Interfaces and Open Issues: • DB Access: could be for • Registration for Fixed Devices • Channel query for its location (Fixed and Mode II) • 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: • Simple beacon frame reception can be sufficient • Any need to define signal seeking contact (FCC term) ? • 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): • Must hear contact verification signal at least once every 60 s (from same Enabling STA providing channel list) • Shall we still call it Enabling Signal? PAWS Scenario 1: AP has direct connection to Internet for DB access Source: https://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after-new-fcc-rules.pptNote: Enabling AP =Geolocation Data Base Controlled (GDC) AP; Dependent STA=GDC STA

  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/ • 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/ Dorothy Stanley, Aruba Networks

  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/ • 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) Dorothy Stanley, Aruba Networks

  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/ • 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. Dorothy Stanley, Aruba Networks

  15. 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. Dorothy Stanley, Aruba Networks

  16. 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. Dorothy Stanley, Aruba Networks

  17. Likely Protocol Layering +-+-+-+-+-+-+-+-+-+-+-+-+ | WS Appl. Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+ | HTTPS | +-+-+-+-+-+-+-+-+-+-+-+-+ | Reliable Transport | +-+-+-+-+-+-+-+-+-+-+-+-+ | IP | +-+-+-+-+-+-+-+-+-+-+-+-+ Source: http://www.ietf.org/proceedings/82/slides/paws-3.pdf Dorothy Stanley, Aruba Networks

  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.ppt Dorothy Stanley, Aruba Networks

  19. 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 Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx Donghun Lee, et al, ETRI

  20. Database architecture(FCC) • Google’s clearinghouse model architecture[3]: Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx Donghun Lee, et al, ETRI

  21. 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. Source: https://mentor.ieee.org/802.19/dcn/11/19-11-0128-01-0001-geo-location-database-issues-of-fcc.pptx Donghun Lee, et al, ETRI

  22. References • [1] TV Band (White Spaces) Database Administrators Guide, http://transition.fcc.gov/oet/ whitespace/tvwpdda.htmlFCC 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 Dorothy Stanley, Aruba Networks

  23. Questions? Dorothy Stanley, Aruba Networks

  24. 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 Dorothy Stanley, Aruba Networks

  25. 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/ Dorothy Stanley, Aruba Networks

  26. 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/ Dorothy Stanley, Aruba Networks

  27. 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/ Dorothy Stanley, Aruba Networks

  28. 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/ Dorothy Stanley, Aruba Networks

  29. 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/ Dorothy Stanley, Aruba Networks

  30. 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/ Dorothy Stanley, Aruba Networks

  31. 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/ Dorothy Stanley, Aruba Networks

  32. 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 Dorothy Stanley, Aruba Networks

  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 Dorothy Stanley, Aruba Networks

  34. References • RFC 4017 - IEEE 802.11 Requirements on EAP Methods Dorothy Stanley, Aruba Networks

More Related