CLOUD-ASSISTED DISTRIBUTED SERVICE DISCOVERY IN A WIRELESS NETWORK

A system for facilitating service discovery at an access point is provided. During operation, the system can receive, from a cloud-based service management system, an enhanced record indicating a set of services provided by a service-providing device (SPD). The enhanced record can be associated with one or more policies that indicate which device is eligible for receiving a service provided by the SPD. The system can cache the enhanced record in a service cache in a local storage device of the access point. The system can then receive a request for discovering a service from a client device wirelessly coupled to the access point. Subsequently, the system can determine whether to respond to or filter out the request based on the enhanced record and the one or more policies. Upon determining not to filter out the request, the system can respond to the request based on the enhanced record.

BACKGROUND

Field

The present disclosure relates to communication networks. More specifically, the present disclosure relates to a method and system for facilitating efficient service discovery at the access points (APs) in a wireless network based on a cloud-based service management system.

DETAILED DESCRIPTION

A distributed wireless network (DWN) can include one or more groups of APs operating in conjunction with each other. A respective group of APs can facilitate wireless coverage for a geographic location, such as a floor of a multi-floor establishment. The APs of the group can provide the same Service Set Identifier (SSID) for the client devices (e.g., a host or an end device). A client device can wirelessly couple to any of the APs and can join a virtual local area network (VLAN) configured on the AP. Hence, client devices belonging to the VLAN can be distributed among multiple APs. The DWN can be managed with a cloud-based management platform, which can provision and control a respective AP of the network. Consequently, an AP may synchronize the control information received from locally coupled client devices with the management platform.

In some configurations, the AP may forward service control traffic, such as service advertisements and queries, from the locally coupled devices to the cloud (e.g., to the management platform). The advertisements and queries can be network packets generated based on a service discovery protocol (e.g., the Bonjour service). Based on the control information, the management platform may determine how a client device may obtain a service from a service-providing device (SPD). The management platform can store the service records advertised by the SPD. The client device can then forward a query via a wireless interface of the AP to the SPD, thereby ensuring distributed forwarding of service traffic. However, since the management platform may receive service-related control traffic from a large number of APs of a plurality of client deployments (e.g., belonging to different tenants), managing such traffic can be challenging.

The aspects described herein address the problem of managing service control traffic in a wireless network in a distributed way by (i) enhancing a service record obtained from a service advertisement at a cloud-based service management system (CSMS) based on corresponding policies, such as role-based segmentation policies; (ii) providing enhanced service records and relevant AP-level policies to a set of target APs for caching; and (iii) responding service queries from the enhanced service records cached at the APs. The CSMS may be deployed with the management platform. The CSMS can receive service advertisements from the SPDs and determine which target APs should cache the enhanced service record based on a selection mechanism. The service queries from the client devices can then be responded to by the APs in accordance with the AP-level policies. Since the traffic volume of service queries can be significantly larger than the traffic volume of service advertisements, offloading the responses to APs while enhancing the service records at the SPDs can allow the CSMS to efficiently manage service traffic.

With existing technologies, a group of APs in the DWN may provide the same SSID. A large DWN may include a plurality of such groups. Each group can be deployed in a geographic location, which may correspond to a site, a department or division, a floor of a multi-floor establishment, etc. A client device or an SPD can couple to an AP in its vicinity via the corresponding SSID to be connected to a local network. The local network can be a VLAN associated with a role associated with the user of the device. The roles can indicate a level of access and a set of privileges available to the user in the network and can be used to segment traffic accordingly. For example, an engineer of the enterprise can be associated with an “engineer” role while a visitor can be associated with a “guest” role.

When an SPD connects to an AP, the SPD can send a service advertisement that can include respective service records indicating one or more services provided by the SPD. For example, if the SPD is a multi-purpose printer, the advertisement can include respective service records of printing, scanning, and photocopying. On the other hand, if the SPD is a shared screen, the advertisement can include a service record of screen sharing. The SPD may use a discovery protocol (e.g., the Bonjour service) to advertise the services. A record-keeping mechanism, such as a multicast domain name service (mDNS) or simple service discovery protocol (SSDP), can be used to record the services advertised by the SPDs. Client devices in the network can use the discovery protocol to query for services offered by the SPDs.

Typically, the cloud management platform can maintain the service records for the network in a database (e.g., in one or more mDNS instances). When the client device sends a query to search for a service, the AP can receive the query and forward it to the cloud management platform. The cloud management platform can then look up the requested service in the database, determine the location of the service, and provide a response indicating the location of the service. However, the cloud management platform can be used for multiple tenants, each of which may support a client network with a large number of SPDs and client devices. The cloud management platform can then store a significant number of service records and serve a large number of queries, many of which can be simultaneous. Consequently, the cloud management platform may become a bottleneck and adversely affect service discovery in the network.

To address this problem, when an SPD in communication with an AP advertises its services, the advertising AP can forward the service records gleaned from advertisements to the CSMS. The CSMS can then identify respective service records indicating one or more services provided by the SPD. The CSMS can determine a set of policies associated with the SPD, the advertising AP, and the service records. Examples of the policies can include, but are not limited to, role-based segmentation rules, broadcast-domain-based traffic separation, security-level-based access rules, location-based access rules, and user-defined access rules. Some of these rules can be defined based on respective access control lists (ACLs). Subsequently, the CSMS can apply the set of policies to the service records to produce enhanced service records. Enhancement of a respective service record can include determining whether an AP should cache the service record and associating the service record with AP-level policies (e.g., the policies that can be applied by the APs). To do so, the CSMS may add the policy identifiers of the AP-level policies to the service record.

The CSMS can then determine a set of target APs for caching the service records at the eligible APs based on a selection mechanism. The selection mechanism can be based on one or more of: the vicinity of the advertising AP, a predetermined number of target APs, and eligibility of receiving the service records. For example, an AP may not be eligible to cache the service record if a VLAN of the SPD is not configured on the AP. The CSMS may also apply license filtering to determine the APs eligible for receiving the services provided by the SPD. The license filtering ensures that if the SPD is licensed for one department of an enterprise, the APs serving another department may not cache the service records even if there is no role-based traffic segmentation between the two departments.

The CSMS can then provide the enhanced service records and the AP-level policies to the target APs, which can then locally cache them. A respective AP may deploy an mDNS or SSDP instance to cache the enhanced service records. When a client device requests, via one of the target APs, a service provided by the SPD, the AP can apply the AP-level policies associated with the enhanced record, such as role-based traffic segmentation based on the respective roles of the client device and the SPD. Accordingly, the AP can determine whether the client device is eligible for receiving the service from the SPD. If eligible, the AP can respond with the service record from the local cache, thereby allowing the client device to discover the service. In this way, the CSMS and the APs can operate in conjunction with each other to facilitate cloud-assisted distributed service discovery with improved scalability.

In this disclosure, the term “switch” is used in a generic sense, and it can refer to any standalone or fabric switch operating in any network layer. “Switch” should not be interpreted as limiting examples of the present invention to layer-2 networks. Any device that can forward traffic to an external device or another switch can be referred to as a “switch.” Any physical or virtual device (e.g., a virtual machine or switch operating on a computing device) that can forward traffic to an end device can be referred to as a “switch.” Examples of a “switch” include, but are not limited to, a layer-2 switch, a layer-3 router, a routing switch, a component of a Gen-Z network, or a fabric switch comprising a plurality of similar or heterogeneous smaller physical and/or virtual switches.

The term “packet” refers to a group of bits that can be transported together across a network. “Packet” should not be interpreted as limiting examples of the present invention to a particular layer of a network protocol stack. “Packet” can be replaced by other terminologies referring to a group of bits, such as “message,” “frame,” “cell,” “datagram,” or “transaction.” Furthermore, the term “port” can refer to the port that can receive or transmit data. “Port” can also refer to the hardware, software, and/or firmware logic that can facilitate the operations of that port.

FIG.1Aillustrates an example of a wireless network supporting cloud-assisted service discovery at the APs, in accordance with an aspect of the present application. A DWN100can include a plurality of AP groups110,120, and140. AP groups110,120, and140can be deployed in different geographic locations, which may correspond to different segments of an enterprise. A respective AP can be reachable from a network150(e.g., a wide-area network (WAN), such as an enterprise network or the Internet) via a corresponding backhaul link. A backhaul link can be a wired link (e.g., an optical cable) or a wireless link (e.g., a point-to-point wireless link). DWN100can be managed, controlled, and provisioned by a cloud management platform170, which can operate on a set of servers102(e.g., in a datacenter) accessible via network150.

AP group110can include a number of APs112,114, and116; and AP group120can include a number of APs122,124, and126. AP group110can provide the same SSID across APs112,114, and116. Similarly, AP group120can provide the same SSID across APs122,124, and126. A VLAN104can be configured at AP112,114,122,124, and126; and another VLAN106can be configured at AP112,114,116,122,124, and126. An AP can be any device capable of establishing a wireless connection using wireless technology (e.g., Wi-Fi, cellular, Bluetooth, line-of-sight optical, infrared, etc.). When a client device is within the wireless signal range of an AP, the client device can wirelessly couple to the AP. Establishing such a wireless connection may include the user of the client device authenticating with corresponding credentials. Based on the authentication, the client device can be allocated a role that can indicate a level of access and a set of privileges available to the user in DWN100.

Client devices142and144can wirelessly couple to cluster110, and client devices146and148can wirelessly couple to cluster120via the corresponding SSIDs. A respective client can obtain an IP address from a subnet associated with its VLAN. In this example, client devices142,144,146, and148can wirelessly couple to APs114,116,126, and122, respectively. A respective VLAN can be associated with a corresponding role. Hence, client devices belonging to a VLAN can be allocated the access and privileges of the role and can be used to segment traffic accordingly. Client devices142and146can be associated with role172, and client devices144and148can be associated with role174. For example, role172can indicate the role of “employee,” while role174can indicate the role of “guest.”

In DWN100, the APs in an AP group can be coupled to each other via a management VLAN. A respective AP can share its information with other APs of the AP group via the management VLAN. In this way, AP112can learn the respective IP addresses of APs114and116via the management VLAN. An SPD118can couple to AP112via the corresponding SSID to be connected to DWN100. SPD118may be associated with role172. When SPD118connects to AP112, SPD118can send a service advertisement128that can include the service records of the services provided by SPD118. For example, if SPD118is a multi-purpose printer, advertisement128can include respective service records of printing, scanning, and photocopying. Advertisement128can be based on a discovery protocol, such as the Bonjour service. Client devices in DWN100can also use the discovery protocol to query for services offered by SPD118.

Typically, the cloud management platform170can maintain the service records in a service database160, which may include one or more mDNS instances. When client device142sends a query to search for the service offered by SPD118, AP114can receive the query and forward it to cloud management platform170. Cloud management platform170can then look up the requested service in database160, determine the location of SPD118that provides that service, and provide a response indicating the location of SPD118. However, cloud management platform170can be used for multiple tenants, each of which may support a client network with a large number of SPDs and client devices. Cloud management platform170can then store a significant number of service records in database160and serve a large number of queries, many of which can be simultaneous. Consequently, cloud management platform170may become a bottleneck and adversely affect service discovery in DWN100.

To address this problem, DWN100can deploy a CSMS130capable of enhancing service records and caching them in a set of target APs. CSMS130can be incorporated into cloud management platform170and hence, can operate on servers102. CSMS130can include a packet handler132, a cache manager134, and a cache publisher136. CSMS130can also support a configuration interface138via which a user may define one or more policies to be implemented in DWN100. Configuration interface138can be remotely accessible via the Internet, and may include a user interface (e.g., a graphical, textual, touch-sensitive, and/or gesture-based interface) provided by CSMS130or a browser-based interface.

When SPD118advertises its services using advertisement128, AP112can forward the service records gleaned from advertisement128to CSMS130. AP112can send a notification packet162, which can be advertisement128from SPD118or a different packet. Packet handler132can then parse packet162to identify respective service records indicating one or more services provided by SPD118. Cache manager134can determine a set of policies associated with SPD118, AP112, and the service records in packet162. Examples of the policies can include, but are not limited to, role-based segmentation rules, broadcast-domain-based traffic separation, security-level-based access rules, location-based access rules, and user-defined access rules. Subsequently, cache manager134can apply the set of policies to the service records to produce enhanced service records. Cache manager134can store the enhanced service records in database160. Enhancement of a respective service record can include determining whether an AP should cache the service record and associating the service record with AP-level policies. To do so, cache manager134may add the policy identifiers of the AP-level policies to the service record.

Cache manager134can then determine a set of target APs for caching the service records at the eligible APs based on a selection mechanism. The selection mechanism can be based on one or more of: the vicinity of AP112, a predetermined number of target APs, and eligibility of receiving the service records. AP116may still be eligible to cache the service record even if VLAN104of SPD118is not configured on AP116. Therefore, the service records can be associated with the respective broadcast domains of VLANs104and106. In some configurations, SPD118can be associated with a license108that restricts access to SPD118. Cache manager134may also apply license filtering based on license108to determine APs eligible for receiving the services provided by SPD118. The license filtering ensures that if SPD118is licensed for one department of an enterprise, APs serving another department, such as AP group140, may not cache the service records even if there is no role-based traffic segmentation between the two departments.

Cache publisher136can then send a distribution packet168that can include the enhanced service records and the AP-level policies to each of the target APs, such as APs112,114,116,122,124, and126. Upon receiving packet168, a respective AP, such as AP114, can locally cache the enhanced service records and the AP-level policies. For example, AP114may maintain a service cache152(e.g., an mDNS instance) to cache the enhanced service records. AP114can also maintain a policy data structure154in the local memory for storing the AP-level policies. Similarly, AP126may maintain a service cache156to cache the enhanced service records and a policy data structure158for storing the AP-level policies. A respective entry in service cache152can be associated with one or more entries of policy data structure154comprising policies applicable to the entry.

When client device142requests a service provided by SPD118, AP114can apply the AP-level policies associated with the enhanced record. For example, if an AP-level policy is role-based traffic segmentation, AP114can determine that client device142and SPD118are associated with the same role172. Accordingly, AP114can determine that client device142is eligible for receiving the service from SPD118and respond with the service record from the local cache. Hence, AP114can facilitate the discovery of the service without forwarding the service request from client device142to cloud management platform170. On the other hand, if AP112receives a subsequent advertisement from service record164SPD118, AP112can determine whether the advertisement includes any update. If the advertisement does not include an update (i.e., a duplicate advertisement) or includes an unsupported format, AP112can suppress the subsequent advertisement by discarding it. In this way, CSMS130and the APs can operate in conjunction with each other to facilitate cloud-assisted distributed service discovery in DWN100.

FIG.1Billustrates an example of incorporating policies with service records for facilitating cloud-assisted service discovery at the APs in a wireless network, in accordance with an aspect of the present application. AP112may maintain a service cache182to cache the enhanced service records and a policy data structure184for storing the AP-level policies. During operation, CSMS130can receive one or more policies166via configuration interface138. CSMS130can then store policies166in a policy data structure, which can be a policy table. When AP112receives service advertisement128with a service record164, AP112can determine whether service record164already exists in service cache182. If service cache182does not include an entry corresponding to service record164, AP112can forward packet162comprising service record164to CSMS130.

Packet handler132can receive packet162and provide it to cache manager134. Cache manager134can apply policies166to enhance service record164. Such enhancement can include determining AP-level policies176from policies166and associating service record164with policies176. Policies176may include a subset of policies166or encompass policies166. Cache manager134may also apply license filtering based on license108to determine APs eligible for receiving service record164. Suppose that AP140does not have the license for the services offered by SPD118. The license filtering ensures that AP group140does not receive an advertisement from SPD118. Cache manager134can then determine a set of target APs in accordance with policies166.

In this example, cache manager134may select AP116as a target AP, thereby allowing devices on VLAN106to receive service from SPD118even though SPD118can be on a different VLAN104. Hence, the enhanced service record is associated with a set of broadcast domains that are allowed to receive the set of services from SPD118. Similarly, cache manager134can also select APs122and126as target APs based on a selection mechanism. Cache publisher136can then send a distribution packet168(e.g., based on the Bonjour service) comprising service record164and relevant policies176and forward it to the set of target APs. AP126can apply policies176to determine whether service records164can be cacheable. For example, if AP126does not serve a client device allowed to receive a service from role172, service records164may not be cacheable. If cacheable, AP126can store service record164in service cache156and polices176in policy data structure158. In the same way, AP122can store service record164in service cache186and polices176in policy data structure188.

When client device146requests a service provided by SPD118, AP126can identify service record164in service cache156. AP126can also determine associated policies176and apply policies176to determine client device146's eligibility. If policies176include role-based segmentation, AP126may determine whether the association with role172allows client device146to receive service from SPD118. If allowed, AP126can provide a response from service cache156. Client device146can then send a service request for the requested service based on service record164. AP126can then send the service request to SPD118.

On the other hand, when client device148requests the service, AP122can identify service record164in service cache186. AP122can also determine associated policies176in policy data structure188and apply policies176. AP126may determine whether the association with role174allows client device148to receive service from SPD118. Since role-based segmentation may prevent inter-role traffic between roles172and174, AP122may not provide a response from service cache156and discard the request.

FIG.2illustrates an example of a CSMS assisting with efficient service discovery at the APs in a wireless network, in accordance with an aspect of the present application. CSMS130can be deployed across a plurality of servers in servers102. CSMS130may support multiple instances of cache manager and cache publisher running on different servers, thereby distributing the computational load. In this example, CSMS130can include a number of cache manager instances (or cache managers)134,202, and204running on the same or different servers. Similarly, CSMS130can include a number of cache publisher instances (or cache publishers)136,212, and214running on the same or different servers. Configuration interface138allows a user or administrator to provide one or more policies166for the service advertisements received by CSMS130. The user may also provide configuration220that can be applicable to an SPD, a VLAN, one or more APs, and a type of service.

Packet handler132of CSMS130can use a distribution mechanism to distribute (or spray) service advertisements among the cache managers. Examples of the distribution mechanism can include, but are not limited to, round-robin distribution, load-based distribution, random distribution, and policy-based distribution where some policies are managed by specific cache managers. If a cache manager instance is added or removed, packet handler132can readjust the distribution mechanism accordingly. Upon receiving packet162from AP112, packet handler132can apply the distribution mechanism and select cache manager134for processing packet162.

Cache manager134can then apply configuration220and policies166on service record164in packet162. Cache manager134can also determine the location where the service indicated in service record164can be available. The location can be referred to as the visibility domain of SPD118and can be represented by the set of target APs. The target APs can be selected based on adjacency to AP112or a configured static policy. For service record164, cache manager134may determine a replication number that can determine the number of target APs. The replication number can be a predetermined number or determined based on the number of APs available within a threshold distance from AP112. Cache manager134can then store service record164in database160. Cache manager134can also restrict access to the service based on license108by applying license-based filtering. Cache manager134can use a distribution mechanism to distribute (or spray) the service records among the cache publishers. The respective distribution mechanisms of packet handler132and cache manager134can be the same or different.

Cache manager134can also maintain the coherency for service record164, which ensures that the up-to-date version of service record is maintained in database160and cached at the target APs. To ensure coherency, cache manager134can maintain a hash value for AP112for records learned from AP112. Cache manager134can also identify the current version of service record164based on a sequence number. The sequence number can indicate the version of service record164and operate as a unique record identifier for service record164. If a new version of service record164is received, the sequence number can be updated when the new version is propagated to the target APs. Based on the updated sequence number, the target APs can determine that service record164has been updated and update their local cache accordingly. Hence, cache manager134can update service records based on updates received from APs and propagate the updated cache records to the corresponding target APs.

Cache manager134can store the identifiers (e.g., network addresses) of the set of target APs in association with the service record164in database160. The identifiers of a respective AP can include one or more of: an Internet Protocol (IP) address, a media access control (MAC) address, and an internal identifier that can uniquely identify the AP within DWN100. If an AP, such as AP114, needs to re-populate service cache152and policy data structure154(e.g., due to a reboot or error), AP114can send a request to CSMS130. Cache manager134can then determine the service records propagated to AP114from database160and provide the service records to AP114. For example, cache manager134can determine that AP114has previously stored service record164and provide service record164to AP114via a corresponding cache publisher.

To determine the cache publisher for distributing service record164, cache manager134can apply the distribution mechanism on service record164and select cache publisher136. Cache publisher136can determine the identifiers of the target APs. Cache publisher136can then send a distribution packet168comprising service record164and AP-level policies176to a respective AP of the target APs. Cache publisher136can facilitate the bookkeeping of counter value. While distributing service record164, cache publisher136can generate or update the counter value for the current version, which can be the initial version, of service record164. In the same way, if service record164is updated, cache publisher136can update the counter value while distributing the updated service record164. The counter value allows cache publisher136to determine whether the cache at an AP is out of synchronization and provide the updated version of the impacted service records.

FIG.3illustrates an example of an AP caching service records and associated policies, in accordance with an aspect of the present application. When AP112receives advertisement128, AP112can obtain service record164and check whether cache182includes an entry matching service record164. If no match is detected, AP112can send packet162comprising service record164to CSMS130. Packet162can be advertisement128or a separate notification packet generated at AP112. Finding a match can include determining the presence of an entry that does not have a difference with service record164obtained from advertisement128. In other words, a match may not be detected if no such entry is present in service cache182or if service record164includes updated information with respect to an existing entry in service cache182. Upon receiving packet162, CSMS130can obtain service record164and enhance service record164by applying policies166and configuration220.

CSMS130can also incorporate a service identifier302, which can be a hash value, and a sequence number304into service record164. Service identifier302can uniquely identify service record164within DWN100; and sequence number304can uniquely identify a version of service record164. CSMS130can determine AP-level policies176from policies166, allocate policy identifier332to policies176, and associate policy identifier332with service record164. Subsequently, CSMS130can include enhanced service record164, service identifier302, and sequence number304in a distribution packet168. CSMS130may also include policies176and policy identifier332into packet168and send the packet to a respective target AP, such as APs112and126. Alternatively, CSMS130may provide the policies separately to a respective AP of DWN100. Under such circumstances, distribution packet168may include the policy identifiers associated with policies176without including individual policies.

AP126can apply policies176to determine whether service records164can be cacheable. For example, if AP126does not serve a client device allowed to receive a service from role172, service records164may not be cacheable. If cacheable, AP126can store service record164in an entry in service cache156and policies176in policy data structure158. Columns of service cache156can include, but are not limited to, a service identifier312, sequence number314, and service record316. On the other hand, columns for policy data structure158can include, but are not limited to, a policy identifier322and policies324. A respective entry or row of service cache156can be associated with one or more entries of policy data structure158. The association can be established by adding the policy identifiers318column to service cache156(denoted with dotted lines). For a respective entry in service cache156, policy identifiers318may include the policy identifiers of the policies applicable to the entry. The association may also be established by maintaining a separate table that can map service identifier312to policy identifiers318.

When AP126receives distribution packet168, AP126can insert service identifier302, sequence number304, service record164, and policy identifier332into an entry of service cache156. AP126can also insert policy identifier332and policies166into policy data structure158. Policy data structure158can include entries for other policies, such as policies346with policy identifier336, that are not applicable to service record164. AP112can also generate similar entries in service cache182and policy data structure184. If client device146sends a request for the service, AP126can look up the service in service cache156and determine corresponding policies176from policy data structure158based on policy identifier332. AP126can then determine whether client device146is eligible for receiving the service from SPD118. Since the bulk of the service traffic include client requests, offloading the client requests to the APs can relieve CSMS130from significant computational and resource overhead.

If SPD118sends a subsequent service advertisement362with service record164, AP112can determine whether advertisement362indicates an update. To do so, AP112can determine whether service record164in advertisement362matches service record164in service cache156. If a match is detected, AP112can suppress advertisement362by discarding it. On the other hand, if service record164in advertisement362is different (or updated) than service record164in service cache156, AP112can forward advertisement362to CSMS130. Therefore, AP112can forward new or updated advertisements while suppressing duplicate advertisements, thereby facilitating efficient use of network bandwidth in DWN100.

Suppose that the user provides one or more new policies342applicable to service record164. CSMS130can determine AP-level policies344from policies342, allocate policy identifier334to policies344, and associate policy identifier3344with service record164. CSMS130can then further enhance service record164by applying policies342. Because service164has been updated, CSMS130can generate a new sequence number306, which can be generated by incrementing sequence number304. CSMS130can include enhanced service record164, service identifier302, and sequence number306in a distribution packet364. CSMS130may also include policies176and344, and their respective policy identifiers332334into packet168. Subsequently, CSMS130can send the packet to a respective target AP, such as APs112and126.

When AP126receives packet364, AP126determines that the sequence number has been updated. Accordingly, AP126can update the entry in service cache156by replacing the existing sequence number and service record with the instances in packet364. Alternatively, AP126can generate a new entry in service cache156with the new sequence number and service record in packet364. AP126can also include policy identifier334in the updated or new entry. As a result, the entry can become associated with both polices176and344. In this way, an entry for a service record can be updated based on updates from both SPD118and CSMS130.

FIG.4Apresents a flowchart illustrating an example of a process of an AP processing a service advertisement, in accordance with an aspect of the present application. During operation, the AP can receive a service advertisement from a locally coupled SPD (operation402) and obtain service records from the service advertisement (operation404). The AP can then determine whether the advertisement is supported (operation406). For example, the version of the discovery protocol instances at the AP and the SPD can be different. If the advertisement is supported, the AP can determine whether the advertisement is new or updated (operation408). If the advertisement is new or updated, the AP can forward the advertisement to the CSMS (operation410). On the other hand, if the advertisement is not supported or is new or updated (operation406or408), the AP can local suppress the advertisement (e.g., by discarding it at the AP) (operation412).

FIG.4Bpresents a flowchart illustrating an example of a process of a CSMS distributing service records and associated policies to the APs in a wireless network, in accordance with an aspect of the present application. During operation, the CSMS receive a service notification for an SPD from an AP (operation432) and obtain service records from the service notification (operation434). The CSMS can determine whether the service records correspond to a new service (operation436). The CSMS can look up the service record in a local database (e.g., an mDNS instance) to determine whether the service records correspond to a new service. If the service records correspond to a new service, the CSMS can generate a service identifier and sequence number (operation438).

On the other hand, if the service records don't correspond to a new service, the CSMS can determine whether a difference is detected (operation440). The CSMS can compare respective instances of the service record in the advertisement and the local database to determine the difference. If a difference is detected, the service record in the advertisement includes an update. The CSMS can then update the sequence number for the service record (operation442). Upon generating the service and sequence numbers or updating the sequence number (operation438or442), the CSMS can store the service record in the database based on the service identifier and the sequence number (operation444).

The CSMS can then determine policies and license associated with the service and the SPD (operation446). The CSMS can also obtain a set of target APs associated with the SPD based on a selection mechanism (operation448). The CSMS can apply the policies and license filtering on the service records to generate enhanced service records (operation450). Subsequently, the CSMS can determine the relevant policies applicable at the APs, which are the AP-level policies, and generate the policy identifier (operation452). The CSMS can then generate a distribution packet comprising the enhanced service records and the relevant policies (operation454) and send the distribution packet to a respective target AP (operation456).

FIG.4Cpresents a flowchart illustrating an example of a process of an AP caching service records and associated policies, in accordance with an aspect of the present application. During operation, the AP can receive a service packet, which can be packet issued based on the discovery protocol, comprising enhanced service records and relevant policies (operation462). The AP can then determine whether the service discovery feature is enabled (operation464). If the service discovery feature is not enabled, the AP can perform layer-2 forwarding for the service packet. On the other hand, if the service discovery feature is enabled, the AP can parse the header of the service packet (operation466) and determine whether the service packet is for distribution (operation468).

If the service packet is for distribution, the packet can be a distribution packet. The AP can then determine the service records from the service packet (operation474) and apply policies to determine cacheable service records (operation476). Subsequently, the AP can store the cacheable service records in the local service cache (e.g., an mDNS instance) (operation478). The AP can also store the policies in the local policy data structure (operation480). However, if the packet is not for distribution, the AP can process the content of the service packet (operation470).

FIG.5presents a flowchart illustrating an example of a process of an AP responding to a service query service records and associated policies, in accordance with an aspect of the present application. During operation, the AP can receive a service request from a client device (operation502) and determine whether the service is locally cached (operation504). If the service is not locally cached, the AP can, optionally, forward the service request to the CSMS (operation516) (denoted with dashed lines). If the service is locally cached, the AP can identify a service record associated with the request in the local service cache (operation506) and determine policies associated with the service record (operation508).

The AP can apply the policies to the request (operation510). Applying the policies can include comparing the parameters of the policies (e.g., roles, restrictions, etc.) with the corresponding parameters associated with the request and the client device. The AP can then determine whether the client device is allowed to receive the service (operation512). If the client device is allowed to receive the service, the AP can response to the service request based on the service record from the local service cache (operation514). On the other hand, if the client device is not allowed to receive the service, the AP can discard the service request (operation518).

FIG.6illustrates an example of a switch that operates as an AP and supports cloud-assisted service discovery, in accordance with an aspect of the present application. In this example, a switch600can include a number of communication ports602, a packet processor610, and a storage device650. Switch600can include a wireless logic block640that allows switch600to operate as an AP (e.g., AP112inFIG.1). Switch600can also include switch hardware660(e.g., processing hardware of switch600, such as its application-specific integrated circuit (ASIC) chips), which includes information based on which switch600processes packets (e.g., determines output ports for packets).

Switch hardware660can include circuitry for a wireless interface that allows switch600to communicate wirelessly based on a wireless technology. Examples of the wireless technology can include but are not limited to, the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards, a cellular technology (e.g., nth generation or nG cellular technology), Bluetooth, line-of-sight optical, and infrared. Packet processor610can extract and processes header information from the received packets.

Packet processor610can identify a switch identifier (e.g., a MAC address and/or an IP address) associated with switch600in the header of a packet. Switch600can maintain a database652(e.g., in storage device650). Database652can be a relational database and may run on one or more Database Management System (DBMS) instances. Database652can store information associated with routing, configuration, and interface of switch600. Database652may store the local service cache and policy data structure of switch600.

Communication ports602can include inter-switch communication channels for communication with other switches and/or user devices. The communication channels can be implemented via a regular communication port and based on any open or proprietary format. Communication ports602can include one or more Ethernet ports capable of receiving frames encapsulated in an Ethernet header over a wired or wireless connection. Communication ports602can also include one or more IP ports capable of receiving IP packets. An IP port is capable of receiving an IP packet and can be configured with an IP address. Packet processor610can process Ethernet frames and/or IP packets. A respective port of communication ports602may operate as an ingress port and/or an egress port.

Switch600can include a service logic block630that can facilitate efficient service discovery at switch600. Service logic block630can include a caching logic block632, a policy logic block634, and a response logic block636. Caching logic block632can determine whether to suppress or forward a service advertisement. Caching logic block632can cache an enhanced service record received from a CSMS in the local service cache. Furthermore, caching logic block632may store a policy received from a CSMS in the local policy data structure. Policy logic block634can determine whether the enhanced service record is cacheable based on one or more policies. Moreover, policy logic block634can apply the policies to determine whether to serve a service request from a client device based on the enhanced service record. Response logic block636can allow switch600to respond to the client request based on the enhanced service record.

FIG.7illustrates an example of a computing system facilitating cloud-assisted service discovery in a wireless network, in accordance with an aspect of the present application. A computing system700includes a set of processors702, a memory device704, and a storage device708. Memory device704can include a set of volatile memory devices (e.g., dual in-line memory module (DIMM)). Furthermore, computing system700may be coupled to a display device712, a keyboard714, and a pointing device716, if needed. Storage device708can store an operating system718, a service management system720, and data736associated with service management system720. Service management system720can be a cloud service facilitating efficient service discovery in conjunction with one or more APs. Service management system720can operate based on a discovery protocol.

Service management system720can include instructions, which when executed by system700can cause system700to perform methods and/or processes described in this disclosure. Specifically, service management system720can include instructions for receiving and parsing a service advertisement (advertisement logic block722). Moreover, service management system720can include instructions for selecting a set of target APs (target logic block724). Furthermore, service management system720can include instructions for applying license filtering on the service records in the service advertisement (filtering logic block726).

Service management system720can include instructions for applying one or more policies on the service records (policy logic block728). Service management system720can also include instructions for receiving a policy configured by a user (policy logic block728). In addition, service management system720can include instructions for generating AP-level policies from the one or more policies (policy logic block728). Moreover, service management system720can include instructions for distributing the service records and the AP-level policies to the target APs (distribution logic block730). Service management system720can also include instructions for receiving an updated service record and propagate the update to the target APs (update logic block732).

Service management system720may further include instructions for sending and receiving packets (communication logic block734). Such packets can include service advertisements and distribution packets. Data736can include any data that can facilitate the operations of service management system720. Data736can include, but is not limited to, one or more policies, configurations, stored service records, location information of a respective AP, service identifiers, sequence numbers, and policy identifiers.

The description herein is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed examples will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other examples and applications without departing from the spirit and scope of the present invention. Thus, the present invention is not limited to the examples shown, but is to be accorded the widest scope consistent with the claims.

One aspect of the present technology can provide a system for facilitating service discovery at an access point. During operation, the system can receive, from a cloud-based service management system, an enhanced record indicating a set of services provided by a service-providing device (SPD). The enhanced record can be associated with one or more policies that indicate which device is eligible for receiving a service provided by the SPD. The system can cache the enhanced record in a service cache in a local storage device of the access point. The system can then receive a request for discovering a service from a client device wirelessly coupled to the access point. Subsequently, the system can determine whether to respond to or filter out the request based on the enhanced record and the one or more policies. Upon determining not to filter out the request, the system can respond to the request based on the enhanced record.

In a variation on this aspect, the system can receive an update to the enhanced record, wherein the update is indicated based on a sequence number. The system can then cache the updated enhanced record in the service cache based on the sequence number.

In a variation on this aspect, the system can receive the one or more policies and store them in a data structure. The enhanced record in the service cache can then correspond to the one or more policies in the data structure.

In a variation on this aspect, the access point can be in a set of target access points within a predetermined vicinity of the SPD. Here, a respective target access point can store the enhanced record.

In a variation on this aspect, the one or more policies can include a role-based segmentation rule that indicates whether a first role of the client device is permitted to exchange traffic with a second role of the SPD.

In a variation on this aspect, the system can receive a service advertisement comprising a service record. If a match is detected for the service record in the service cache, the system can suppress the service advertisement.

In a variation on this aspect, the enhanced record can be associated with a set of broadcast domains that are allowed to receive the set of services from the SPD.

In a variation on this aspect, the enhanced record can be an enhanced multicast domain name service (mDNS) record. The request can then be based on a Bonjour service.

In a variation on this aspect, upon determining to filter out the request, the system can refrain from responding to the request.

Another aspect of the present technology can provide a system for facilitating service discovery on a cloud-based service manager. During operation, the system can receive a service advertisement from an access point. Here, the service manager facilitates service discovery from the access point. The system can obtain, from the service advertisement, a service record indicating a set of services provided by a service-providing device (SPD). The system can then apply one or more policies to the service record to generate an enhanced record. Subsequently, the system can determine a set of target access points for locally caching the enhanced record based on a selection mechanism. Here, a respective target access point is capable of responding to a request for the set of services received based on the locally cached enhanced record. The system can send a distribution packet comprising the enhanced record to a respective target access point. The enhanced record can be associated with one or more access-point-level policies implementable at the target access point.

In a variation on this aspect, the system can detect an update to the service record based on a subsequent service advertisement. The system can then send a distribution packet with the updated service record, wherein the update is indicated by a sequence number.

In a variation on this aspect, the system can filter the service record based on a license to determine access points eligible to cache the service record.

The methods and processes described herein can be executed by and/or included in hardware logic blocks or apparatus. These logic blocks or apparatus may include, but are not limited to, an application-specific integrated circuit (ASIC) chip, a field-programmable gate array (FPGA), a dedicated or shared processor that executes a particular software logic block or a piece of code at a particular time, and/or other programmable-logic devices now known or later developed. When the hardware logic blocks or apparatus are activated, they perform the methods and processes included within them.

The foregoing descriptions of examples of the present invention have been presented only for purposes of illustration and description. They are not intended to be exhaustive or to limit this disclosure. Accordingly, many modifications and variations will be apparent to practitioners skilled in the art. The scope of the present invention is defined by the appended claims.