1. Aligning 11aq with Higher Layer Service Discovery Protocol
March 2014
doc.: IEEE /0216r0
Aligning 11aq with Higher Layer Service Discovery Protocol
Date:
Authors:
SK Yong, Apple
Stephen McCann, Blackberry

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

3. March 2014
doc.: IEEE /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 PHY/MAC layer (in this case aq)
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

4. Review of 802.11aq Service Discovery
March 2014
doc.: IEEE /0325r0
Review of aq 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

5. Review of 802.11aq Service Discovery (2)
March 2014
doc.: IEEE /0325r0
Review of aq 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

6. 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

7. 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

8. 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 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 E C0 27

9. 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 E F 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): D 31 1A C 3D C F 6E 2F 70 6F

10. 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

11. 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

12. 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

13. March 2014
doc.: IEEE /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

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