Aligning 11aq with Higher Layer Service Discovery Protocol March 2014 doc.: IEEE 802.11-14/0216r0 Aligning 11aq with Higher Layer Service Discovery Protocol Date: 2017-04-07 Authors: SK Yong, Apple Stephen McCann, Blackberry

March 2014 doc.: IEEE 802.11-14/0216r0 Abstract This contribution proposes to align 11aq unsolicited PAD to higher layer service discovery framework SK Yong, Apple Stephen McCann, Blackberry

March 2014 doc.: IEEE 802.11-14/0325r0 Background 11aq is an amendment to enable delivery of pre-association Service Discovery information The service information is dictated by an application/service and should be transparent to the lower layer i.e. 802.11 PHY/MAC layer (in this case 802.11aq) 802.11aq protocol serves to facilitate the higher layer service discovery mechanism during pre-association It should not impose additional implementation complexity on the existing higher layer service discovery (e.g. translation and/or extraction of service information) SK Yong, Apple Stephen McCann, Blackberry

Review of 802.11aq Service Discovery March 2014 doc.: IEEE 802.11-14/0325r0 Review of 802.11aq Service Discovery Service Hash Request/Response ANQP-element This enables a STA to query APs about a specific service, based on multiple Service Hashes (with potentially different permutations) The AP responds with the Instance Name associated with the Service Hash In higher layer SD (when STA and AP are associated) The STA queries a network device about a service using encoded Service Name + DNS Record Type (i.e. PTR record type), which are treated as a key in the request The network device responds with same key (encoded Service Name + DNS Record Type) and its value as an Instance Name (i.e. PTR record), which are treated as key-value pair SK Yong, Apple Stephen McCann, Blackberry

Review of 802.11aq Service Discovery (2) March 2014 doc.: IEEE 802.11-14/0325r0 Review of 802.11aq Service Discovery (2) Service Information Request/Response ANQP-element This enables a STA to further query AP for further service information associated with the Instance Name The AP responds with more service information associated with the Instance Name In higher layer SD (when STA and AP are associated), The STA further queries network device (after obtaining the Instance Name) for further service information using encoded Instance Name + DNS Record Type (i.e. TXT record type), which are treated as a key in the request The network device responds with the same key (encoded Instance Name + DNS Record Type) and its value as an TXT record, which are treated as key-value pair SK Yong, Apple Stephen McCann, Blackberry

Review of High Layer Service Discovery (mDNS and DNS-SD) Higher Layer Service Discovery relies on generic Key/Key-Value pair for Service Discovery The Key (i.e. the Question) queries the service name (encoded and compressed based on RFC 1035), and type of record (PTR, SRV, or TXT record) The Key-Value (i.e.the Answer) responds with the same key + the value associated with the key The Key and Value are defined by the service (e.g. service name, PTR record (Instance Name), TXT record) Answer Key Value Question Key SK Yong, Apple

Example: mDNS Service Internet Printing Protocol (IPP) IPP Subscriber DNS Name: _ipp._tcp.local. Publisher Service Instance Name: MyPrinter._ipp._tcp.local. Available TXT Record associated to MyPrinter_ipp._tcp.local.: txtvers=1, pdl=application/postscript SK Yong, Apple

Example: mDNS Service – cont’d Initial Service Discovery (corresponds to Service Hash Req/Resp ANQP-element) DNS Name field Encoded and compressed format of _ipp._tcp.local. (based on RFC1035): 04 5F 69 70 70 C0 0C DNS Record Type field value is 0x000C corresponding to PTR Record Type The RDATA field The RDATA field is the encoded and compressed format of MyPrinter._ipp._tcp.local. (i.e. Instance Name): 09 4D 79 50 72 69 6E 74 65 72 C0 27

Example: mDNS Service – cont’d Initial Service Discovery (corresponds to Service Info Req/Resp ANQP-element) DNS Name field Encoded and compressed format of MyPrinter._ipp._tcp.local. (i.e. Instance Name): 09 6D 79 70 72 69 6E 74 65 72 04 5F 69 70 70 C0 0C DNS Record Type field value is 0x0010 corresponding to TXT Record Type The RDATA field The RDATA field is the encoded and compressed format of txtvers=1, pdl=application/postscript. (i.e. TXT recod): 09 74 78 74 76 65 72 73 3D 31 1A 70 64 6C 3D 61 70 70 6C 69 63 61 74 69 6F 6E 2F 70 6F 73 74 73 63 72 69 70 74

Aligning 11aq to Higher Layer SD Protocol Maintaining the attributes/fields used by higher layer SD protocol is important: Compatible with existing implementation/ecosystem; best bet for adoption of 11aq Reduce unnecessary implementation complexity at STA and AP E.g. Extracting higher layer information for lower layer usage and then translating back for higher layer usage Such translations incur more processing time SK Yong, Apple

Proposed Changes (1) Replace Figure 9-625f and 9-625g, Figure 9-625h and 9-625i as follows Info ID Length Service Information Request Tuple 2 Variable Service Hash Service Info Request Keys 6 Variable Service Hash Service Info Request Keys 6 Variable … Note: Service Info Request Key is service specific. We can specify the format as in Slide 8/9 or left in unspecified

Proposed Changes (2) Info ID Length Service Information Response Tuple Replace Figure 9-625l, 9-625m, 9-625j and 9-625k as follows Info ID Length Service Information Response Tuple 2 Variable Service Hash Service Info Response Key-Value 6 Variable Service Hash Service Info Response Key-Value 6 Variable … Note: Service Info Response Key-Value is service specific. We can specify the format as in Slide 8/9 or left in unspecified

March 2014 doc.: IEEE 802.11-14/0325r0 Summary Aligning 11aq to higher layer SD protocols is critical to adoption of 11aq We recommend that D8.0 spec to be updated accordingly based on slide 11-12 SK Yong, Apple Stephen McCann, Blackberry

Strawpoll Do you agree in principle the proposed changes as shown in slide 11-12 to better align PAD protocol with higher layer service discovery framework?