Liaison Report by jennyyingdi

VIEWS: 2 PAGES: 34

									January 2012                                           doc.: IEEE 802.11-12/0122r1


             IEEE 802.11-IETF Liaison Report
                                   Date: 2012-01-19
Authors:
Name              Company          Address             Phone           email
Dorothy Stanley   Aruba Networks   1322 Crossman Ave   630-363-1389    dstanley@arubanetworks.
                                   Sunnyvale, CA                       com




Submission                                Slide 1                Dorothy Stanley, Aruba Networks
January 2012                            doc.: IEEE 802.11-12/0122r1


                         Abstract

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




Submission                    Slide 2          Dorothy Stanley, Aruba Networks
January 2012                                                           doc.: IEEE 802.11-12/0122r1

     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




Submission                                           Slide 3                       Dorothy Stanley, Aruba Networks
January 2012                                          doc.: IEEE 802.11-12/0122r1

      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.


Submission                              Slide 4                Dorothy Stanley, Aruba Networks
January 2012                                            doc.: IEEE 802.11-12/0122r1

      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.



Submission                                Slide 5                Dorothy Stanley, Aruba Networks
January 2012                                                 doc.: IEEE 802.11-12/0122r1

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

      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.




Submission                               Slide 7               Dorothy Stanley, Aruba Networks
January 2012                                         doc.: IEEE 802.11-12/0122r1

      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.




Submission                              Slide 8               Dorothy Stanley, Aruba Networks
       January 2012                                                                  doc.: IEEE 802.11-12/0122r1


                                    Some Defined elements




          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)
       Submission                                                 Slide 9                                    Peter Ecclesine, Cisco
       January 2012                                                                    doc.: IEEE 802.11-12/0122r1


                                    Some Defined elements




          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

      Submission                                                  Slide 10                                      Peter Ecclesine, Cisco
       January 2012                                                               doc.: IEEE 802.11-12/0122r1
                              Network Architectures and Interfaces
                                                       Signaling Interfaces and Open Issues:
         C
       FC DB                                           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
  PAWS                  DB                             Qn: Is it beyond scope of 802.11 ? OR, need to specify
                      Access
                                                          message content/format at least?
                                                       Initial wireless signal before Mode I can attempt contact:
                                                       1. Simple beacon frame reception can be sufficient
               Enabling AP                             2. Any need to define signal seeking contact (FCC term) ?
            (fixed or personal/
            portable beaconing                         3. Shall we call it Enabling signal?
                    STA)
                                                       Enablement (contact establishment for channel query):
                                                       1. Is enablement term fine (contact establishment in FCC) ?
                      2. WLAN operations
                                                       2. Request contains FCC ID, Response: channel list + Info to
              1. Enablement
  0. Hear signal                                            decode contact verification signal
                                                       3. Enabler is a functional unit to serve its Mode I contacts
            Dependent STA
           (Non-beaconing STA)                         WLAN Operational control (contact verification):
                                                       1. Must hear contact verification signal at least once every 60
                                                          s (from same Enabling STA providing channel list)
Scenario 1: AP has direct connection to
                                                       2. Shall we still call it Enabling Signal?
Internet for DB access Source: https://mentor.ieee.org/802.11/dcn/10/11-10-1226-00-00af-tvws-enablement-after-new-fcc-rules.ppt
       Submission                  Note: Enabling AP =Geolocation Data Base Controlled (GDC) AP; Dependent STA=GDC STA
January 2012                                                  doc.: IEEE 802.11-12/0122r1

    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/




Submission                                    Slide 12                  Dorothy Stanley, Aruba Networks
January 2012                                         doc.: IEEE 802.11-12/0122r1

     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)


Submission                             Slide 13               Dorothy Stanley, Aruba Networks
January 2012                                            doc.: IEEE 802.11-12/0122r1

     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.




Submission                                Slide 14               Dorothy Stanley, Aruba Networks
January 2012                                                   doc.: IEEE 802.11-12/0122r1

     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.


Submission                                     Slide 15                   Dorothy Stanley, Aruba Networks
January 2012                                                   doc.: IEEE 802.11-12/0122r1

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


                           Likely Protocol Layering

+-+-+-+-+-+-+-+-+-+-+-+-+
| WS Appl. Protocol     |
+-+-+-+-+-+-+-+-+-+-+-+-+
|      HTTPS            |
+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliable Transport     |
+-+-+-+-+-+-+-+-+-+-+-+-+
|        IP             |
+-+-+-+-+-+-+-+-+-+-+-+-+
Source: http://www.ietf.org/proceedings/82/slides/paws-3.pdf

Submission                                                Slide 17          Dorothy Stanley, Aruba Networks
January 2012                                 doc.: IEEE 802.11-12/0122r1

    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




Submission                       Slide 18           Dorothy Stanley, Aruba Networks
January 2012                                                                  doc.: IEEE 802.11-12/0122r1

                              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
Submission                                               Slide 19                               Donghun Lee, et al, ETRI
January 2012                                                                  doc.: IEEE 802.11-12/0122r1

                              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
Submission                                               Slide 20                               Donghun Lee, et al, ETRI
January 2012                                                                 doc.: IEEE 802.11-12/0122r1

                              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
Submission                                                Slide 21                              Donghun Lee, et al, ETRI
January 2012                                                  doc.: IEEE 802.11-12/0122r1


                                    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-
Submission
       new-fcc-rules.ppt                     Slide 22               Dorothy Stanley, Aruba Networks
January 2012                 doc.: IEEE 802.11-12/0122r1


               Questions?




Submission        Slide 23          Dorothy Stanley, Aruba Networks
January 2012                                                          doc.: IEEE 802.11-12/0122r1


                    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


Submission                                          Slide 24                      Dorothy Stanley, Aruba Networks
January 2012                                                        doc.: IEEE 802.11-12/0122r1



                    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/




Submission                                         Slide 25                    Dorothy Stanley, Aruba Networks
January 2012                                                        doc.: IEEE 802.11-12/0122r1



                    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/




Submission                                         Slide 26                    Dorothy Stanley, Aruba Networks
January 2012                                                           doc.: IEEE 802.11-12/0122r1



                           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/


Submission                                          Slide 27                      Dorothy Stanley, Aruba Networks
January 2012                                                            doc.: IEEE 802.11-12/0122r1



                           CORE Working Group
 •    CORE (Constrained RESTful Environments) Working Group
      website: 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/
 •    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/

Submission                                            Slide 28                      Dorothy Stanley, Aruba Networks
January 2012                                                   doc.: IEEE 802.11-12/0122r1


             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/




Submission                                     Slide 29                Dorothy Stanley, Aruba Networks
January 2012                                                             doc.: IEEE 802.11-12/0122r1

      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/




Submission                                            Slide 30                       Dorothy Stanley, Aruba Networks
January 2012                                                           doc.: IEEE 802.11-12/0122r1


              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/




Submission                                          Slide 31                      Dorothy Stanley, Aruba Networks
January 2012                                                          doc.: IEEE 802.11-12/0122r1


                       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

Submission                                          Slide 32                     Dorothy Stanley, Aruba Networks
January 2012                                        doc.: IEEE 802.11-12/0122r1


                            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




Submission                            Slide 33             Dorothy Stanley, Aruba Networks
January 2012                        doc.: IEEE 802.11-12/0122r1


                    References

 • RFC 4017 - IEEE 802.11 Requirements on EAP
   Methods




Submission               Slide 34          Dorothy Stanley, Aruba Networks

								
To top