WO2007005131A2

WO2007005131A2 - System and method for multiprotocol service discovery in a computer network

Info

Publication number: WO2007005131A2
Application number: PCT/US2006/019608
Authority: WO
Inventors: John Buford
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2005-05-19
Filing date: 2006-05-19
Publication date: 2007-01-11
Also published as: WO2007005131A3; WO2007005131B1

Abstract

A multiprotocol service discovery system (104A) includes computer applications (100) and a middleware layer (102A) connected to a computer network having one or more protocol implementations. The middleware layer (102A) receives requests from the computer applications (100), forwards the requests to the protocol implementations, receives response to the requests from the protocol implementations, and returns the responses to the computer applications (100). In some embodiments, the middleware layer (102A) automatically routes service discovery requests to appropriate ones of the protocol implementations using a routing element. In still other embodiments, the middleware layer (102A) additionally or alternatively performs protocol conversion and translation which converts between common formats used by the computer applications (100) and protocol specific formats used by the protocol implementations.

Description

SYSTEM AND METHOD FOR MULTIPROTOCOL SERVICE DISCOVERY IN A

COMPUTER NETWORK

FIELD [0001] The present disclosure generally relates to service discovery protocols, and relates in particular to multiprotocol service discovery in a computer network.

BACKGROUND [0002] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0003] Service discovery is a basic mechanism in networked applications. However there are many service discovery protocols to use. It is not likely that a single protocol will be the dominant one. Hence it is important to support multiple ones and there may not be server or gateway mechanisms in every environment.

[0004] The most widely used service discovery systems, peer-to-peer file sharing systems, have used proprietary mechanisms which have not been exposed for such combination. Other systems such as Salutation have not been adopted or, like SLP, have been deployed only for network services.

[0005] Multiprotocol approach is complicated because of many differences in individual service discovery mechanisms, including: (1) varying formats, categories, attributes, and identifiers for service description; (2) different notions of what a "service" is; (3) push vs. pull; (4) multicast vs. unicast; (5) incompatible protocols; and (6) different security, authentication, and authorization methods.

[0006] Therefore, the need remains for a solution to the problems associated with providing a system and method for multiprotocol service discovery in a computer network. The present invention fulfills this need.

SUMMARY

[0007] The multiprotocol service discovery system according to the present teachings includes computer applications and a middleware layer connected to a computer network having one or more protocol implementations.

The middleware layer receives requests from the computer applications, forwards the requests to the protocol implementations, receives responses to the requests from the protocol implementations, and returns the responses to the computer applications. In some embodiments, the middleware layer automatically routes service discovery requests to appropriate ones of the protocol implementations using a routing element. In still other embodiments, the middleware layer additionally or alternatively performs protocol conversion and translation which converts between common formats used by the computer applications and protocol specific formats used by the protocol implementations.

[0008] Further areas of applicability will become apparent from the description provided herein. It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure.

DRAWINGS

[0009] The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way.

[0010] Figure 1 is a set of block diagrams, including: Figure 1(a), which shows one or more applications using multiple service discovery protocols; Figure 1 (b), which illustrates a middleware layer; and Figure 1(c), which illustrates addition of a protocol conversion and translation step.

[0011] Figure 2 is a block diagram illustrating a multiprotocol service discovery configuration involving SLP and UPnP SSDP. [0012] Figure 3 is a block diagram illustrating a multiprotocol service discovery configuration involving SLP and Bluetooth.

[0013] Figure 4 is a block diagram illustrating layering of a peer-to-peer service-oriented middleware.

[0014] Figure 5A is a block diagram illustrating an example in which a peer discovers and invokes a content-based retrieval service, which is in turn implemented using services from other peers, combined using service composition. [0015] Figure 5B is a block diagram illustrating an example in which a peer publishes protected content to the index using a local DRM service, another peer obtains the movie from the index and renders it using a media player service and separately acquired license, and the rendering service is in turn implemented using services from other peers, combined using service composition.

DETAILED DESCRIPTION [0016] The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses.

[0017] The present teachings are directed to a middleware between a multiprotocol client and service discovery protocols of a network. It should be readily understood that a multiprotocol client is distinguishable from a single protocol clients that uses other hosts as gateways to other protocols. [0018] The present teachings are part of results of ongoing efforts by the assignee of the present invention to address the problems associated with competing and incompatible service discovery, advertisement, and/or invocation protocols that typically differ from one network or network domain to another. For example, a "federated peer-to-peer" concept, which includes federated service discovery, is under development by the assignee of the present invention. The goal of federated searching is to enable a user to search multiple, independent, discretely mounted, data sources or databases through one search query. The multiprotocol service discovery method described here directly provides "federated service discovery." This approach is further detailed in: (a) U.S. Pat. App. No. 60/715,388, filed September 8, 2005 by the assignee of the present invention, entitled System and Method for Meta-Discovery in Federated Peer-to-Peer Service Discovery Systems; (b) Application No. 60/674,875, filed on April 26 2005 by the assignee of the present invention, entitled Mechanism to Support Transparent Roaming in Heterogeneous Service Discovery Systems; (c) U.S. Pat. App. No. 60/710,660, filed August 23, 2005 by the assignee of the present invention, entitled Method and System for Peer-to-Peer Services Architecture and Framework; (d) U.S. Pat. App. No. 60/716,384, filed September 12, 2005 by the assignee of the present invention, entitled System and Method for Service Discovery in a Computer Network Using Data Dissemination; and (e) U.S. Pat. App. No. 60/718,968, filed September 20, 2005 by the assignee of the present invention, entitled System and Method for Component Trust Model in Peer-to-Peer Service Composition. The aforementioned patent applications are incorporated herein by reference in their entirety for any purpose.

[0019] Referring generally to Figure 1, and starting with Figure 1(a), one or more applications 100 are able to use multiple service discovery protocols 104A and 104B using a middleware layer 102A that forwards application requests to the appropriate protocol implementation, and returns responses for those requests to the application 100. In addition, any service advertisements that are received can be forward to the applications 100. Further, applications 100 which request notifications about registered services can receive those. In this case the applications 100 use the service description content for each protocol. The middleware forwards to the designated protocol. The protocols may operate on the same or different network interfaces 106, network transports, and network media.

[0020] Referring now to Figure 1(b) the middleware layer 102B can alternatively or additionally automatically route the service discovery requests to the appropriate protocol(s) 104A and 104B using a routing element.

[0021] Referring now to Figure 1(c), the middleware 102C can implement a protocol conversion and translation step which converts from a common format used by the application 100 to/from the protocol specific formats.

[0022] Turning now to Figure 2, a multiprotocol service discovery configuration can involve, for example, SLP and UPnP. An application 100 searching for a printer can issue a request to the SD Request/Router layer of middleware 102. The request is forward to each of the SD stacks after translation into the appropriate format for each protocol by middleware layer. In the SLP case, the SLP user agent (UA) 104A issues a request to the SLP directory agent (DA) 200, which returns one or more printers 202 and 204. Then the service information is returned to the application 100 after possible translation into a common application format. In the UPnP case, the request can be issued using SSDP which is a multicast protocol on top of HTTPMU. The request is received by all listening UPnP devices, and those that provide the service respond with an SSDP reply. Alternately, one or more UPnP printers 204 might have advertised their availability via network interface 106 using SSDP, and that advertisement could be cached in the local control point 104B. Further, the control point (CP) 104B can request a detailed service description document (an XML document) from the device. The service information is returned to the application 100 after possible translation into a common application format. The application 100 can then select a device and issue the service request.

[0023] Turning now to Figure 3, a multiprotocol service discovery configuration can involve, for example, SLP and Bluetooth (BT). An application 100 searching for a printer can issue a request to the SD Request/Router layer of middleware 102. The request is forwarded to each of the SD stacks after translation into the appropriate format for each protocol. In the SLP case, the SLP user agent (UA) 104A issues a request to the SLP directory agent (DA) 200 via 802,11 network interface 106A, which returns one or more printers. Then the service information is returned to the application 100 after possible translation into a common application format. In the BT case, the local SDP of protocol 104B1 records are searched for matching entries. And the SDP layer of protocol 104B1 can send requests to neighboring SDP layers of protocol 104B2 via Bluetooth interface 106B1 to request matching service records. Then the service information is returned to the application 100 after possible translation into a common application format. [0024] Other variations are possible, including and not limited to: multiple network interfaces; multiple network media; multiple network transport; more than two service discovery protocols; multiple service advertisement protocols; and/or multiple service invocation protocols.

[0025] A method for supporting two or more service discovery protocols in one client which can run over the same or different network interfaces and same or different transport layers. The method encompasses service discovery, service advertisement, and service description in a multiprotocol client. The method includes issuing service discovery requests and receiving service discovery responses across multiple SD protocols; issuing service advertisements and receiving service advertisements across multiple SD/SA protocols; issuing service descriptions and receiving service descriptions across multiple SD protocols and in multiple service description formats.

[0026] In some embodiments, the method employs a common service classification, naming or type scheme, in which case service requests and service responses are converted to native service requests and responses at lower layers. [0027] In other embodiments, the method additionally or alternatively employs a common service classification, naming or type scheme, in which case service advertisements are converted from native service advertisements received at lower layers.

[0028] In still other embodiments, the method additionally or alternatively employs a common set of service attributes and service invocation rules, in which case service descriptions are converted to the native service attributes and service invocation rules.

[0029] The common service classification, naming, or type scheme can use an existing model or format, or define a new model or format. The common set of service attributes and service invocation rules may use an existing model or format, or define a new model or format.

[0030] In the case that the common service classification, service attributes, and service invocation rules are not used, the application issues service requests using native classification, and interprets service descriptions and advertisements using native service description and advertisement according to the formats of the SD protocols in the multiprotocol client.

[0031] In the case that the common service description is not used, the application will receive service descriptions using native service descriptions according to the formats associated with the SD protocols in the multiprotocol client.

[0032] A service offered by another device can be advertised. The local SD implementation for that SD protocol can store or cache service advertisements according to the SD protocol rules. Thus, when a local request is made, matching service records in the cache may be returned to the application.

[0033] In some embodiments, a multiprotocol client advertises its own services by sending the advertisements to each of the SD protocol stacks.

[0034] In some embodiments, a multiprotocol client composes new services that combine one or more local services with one or more services offered by another node through one of the SD protocols supported at the multiprotocol client. [0035] This method can also be described in terms of a system of multiprotocol service discovery and a medium of service discovery.

[0036] The method can also be described in terms of specific combinations of SD protocol configurations including: UPnP SSDP and Bluetooth SDP; SLP and UPnP SSDP; UPnP SSDP and Web Services; UPnP SSDP and DHT-based (JXTA, Chord, Pastry, etc.); JXTA and Chord; JXTA and NEMO; and/or two or more peer-to-peer file sharing protocols, including Kazaa, Gnutella, Napster, WinMX, Audiogalaxy, BearShare, LimeWire.

[0037] The method can also be described in terms of specific types of combinations of SD protocols including: local domain and multiple (widearea) domain (e.g., SLP and Chord); client-server and peer-to-peer (e.g., SLP and Chord); home network and PAN (e.g., UPnP, 802.15.3); network services and application services (e.g., SLP and Web Services). The method can also be described in terms of combinations of more than two SD protocols in one client. Moreover, besides conventional client-server discovery protocols and broadcast protocols like UPnP, services overlay can be included. Services overlay are overlay networks used to advertise and discover services between peers, typically in a wide-area context.

[0038] A service overlay can connect peers end-to-end in a highly scalable way. The coupling of service advertisement and discovery with a peer- to-peer overlay network creates the service overlay. The design of a service overlay involves mapping of service descriptions, which are typically complex structured documents, to the overlay's index mechanism to permit efficient indexing and lookup. The use of a peer-to-peer overlay, offering scalability in the millions of nodes, brings new issues such as node churn and decentralized security.

[0039] The method can also be described in terms of specific types of combinations of SD protocols including two or more separate service overlays.

[0040] Turning now to Figure 4, according to some embodiments, the present invention is a peer-to-peer service oriented middleware (P2PSOM) 354. Because P2PSOM 354 is service oriented, the middleware architecture focuses on functions for enabling and discovery of services in peer-to-peer environments. Other functions are also needed in mobile devices, such as mobility management, security, session control, and QoS transport.

[0041] The P2PSOM 354 can, for example, be implemented on a peer device 350 having applications and application services 352, operating system 356, and network interface(s) 358. Multiple SDA protocols 368A-C of operating system 356 can communicate with network layers 370A-C of operating system 356, which in turn can communicate with network interface(s) 358. P2PSOM 354 can have basic services 360A and other P2PSO services 360B. Basic services 360A can include, for example, search service 362A, group service 362B, publish and subscribe service 362C, application services 362D, and DRM service 362E.

[0042] P2PSOM 354 can also have a service discovery and advertisement (SDA) Layer 364 that provides a unified API for applications to use the various SDA protocols in a protocol neutral way. Within the SDA Layer are the functions 366A-F: (1) meta-discovery of service discovery mechanisms organized by domain, location, or other attributes federation of multiple SDA protocols into a unified protocol-independent model supporting the unified API; (2) identity management of service and resource identities used in each SDA protocol to provide unified and consistent identities to applications; (3) filters which allow applications to control the flow of actions, events, and states between SDA protocols and the unified SDA layer; (4) group federation to manage group membership and identities across the SDA protocols and networks in a protocol-independent manner; and (5) service composition of services inter- and intra-SDA protocols.

[0043] Each underlying SDA protocol, whether a peer-to-peer service overlay or a client-server protocol, is responsible for the management of peer ids and other resource ids that are used in that protocol or overlay. In addition, a device might participate in more than one SDA protocol, and could have distinct identifiers in each. The functions of group federation and service composition in the SLA layer may span more than one protocol.

[0044] The purpose of identity management is to coordinate the mapping of ids at each protocol to a locally unique id at the application layer. In addition, operations that span separate multiple name spaces (such as groups and service composition) need to avoid confusion from duplicate instances of the same peer (due to membership in more than overlay) and different identifier spaces. [0045] With devices enabled with P2PSOM and connected via one or more service overlays, each peer can offer services for use by other peers. Above the SDA Layer are basic services which are the minimum set of operations for a peer to participate in P2PSOM. These include: (1) Group — associate peers into groups for content sharing and service access within the group; (2) Publish/Subscribe — subscribe to and receive events related to index changes in the overlay; (3) Search — providing content search methods beyond hash indexing, such as content-based retrieval, meta-data search, and text retrieval; (4) Association — creating and using hyperlink associations between objects in the peer to peer network; and (5) DRM (Digital Rights Management) — protection and license management of content produced at the peer.

[0046] The requirements driving the design of P2PSOM are summarized in Table 1.

Table 1 Key requirements driving the design of P2PSOM

[0047] Before elaborating on the details of the SDA layer, it is useful to first describe example peer interactions. In these examples, the peer-to-peer overlays are generalized as multiple ones of "P2P Index".

[0048] Turning now to Figure 5A, a media-storing peer 400 advertises a search service 402 which provides content-based retrieval (CBR). Another peer 404 discovers this service using the service discovery method in the SDA Layer 406, for example, by accessing P2P index 405A. The SDA Layer 406 connects to several service discovery and advertisement protocols 408 (e.g., SDA1, SDA2, ...). After peer 404 has discovered peer 400 offering the service of interest as at 410, it then uses the service invocation protocol 412 required by the service description for service 402 "search-cbr-intf-v3" as at 414. To implement this service, two sub-interfaces have been defined, pre-process 416 and query process 418, which may be provided either locally or by other peers 420A-D. Peer 400 discovers peers 420A-D implementing these sub-interfaces 418A-B, 418A-B₁ for example, by accessing P2P index 405A and P2P index 405B. Peer 400 then uses these peer's services when it receives the incoming search request from Peer 404. Such service composition 422 is mediated by the SDA Layer. Thus, a peer 404 discovers and invokes a content-based retrieval service 402, which is in turn implemented using services 416A-B, 418A-B from other peers 420-D, combined using service composition 422 across multiple service overlays. [0049] Turning now to Figure 5B, a camcorder 450 used to capture media at 452 immediately encrypts the media using a DRM service 454, applies the owner's rights management policy, and prepares it for publication to a wide- area peer-to-peer index 458A. Once the content is published in the peer-to-peer (P2P) index 458A, any peer may retrieve it. For example, peer 460 can retrieve the media file 456 "tom-movie-20050630-081003" from the P2P index 458. Peer-460 uses a local service 462 (media-player-intf-v3) which plays the content, assuming the peer also has the appropriate license. In addition, this media player service 462 uses two components which may be either local or provided by other peers. In this simplified example, the components provide two key functions of the media player: media decryption 464 and media rendering 466. Peer 470 and Peer 472 have previously registered services in the P2P index 458B which correspond to these interfaces. Peer 460 can discover these services and use them to perform the necessary function. Thus, a peer, camcorder 450, publishes protected content to the index 458A using a local DRM service 454, another peer obtains the movie, media file 456, from the index 458A and renders it from local storage 465 using a media player service 462 and separately acquired license 463, and the rendering service, decryption 464 and rendering 466, is in turn implemented using services 474A-B from other peers, combined using service composition 476 across another index 458B. [0050] As previously observed it is likely that many networked CE devices will be enabled with multiple network interfaces, each of which may have its own service discovery protocol(s). Further, as indicated by the proliferation of peer-to-peer filing sharing applications, the low barrier of entry to creating network overlays suggests that many different service overlays could emerge, tailored to different applications, quality of service, richness of semantics, administrative requirements, security policies, or other needs. [0051] One of the three forces behind fifth wave and pervasive computing is application interoperability across the devices and network fabric. The deployment of peer-to-peer middleware on devices and networks can enable interoperability, but may also lead to balkanization and fragmentation if multiple incompatible peer-to-peer SDA protocols and middleware are widely deployed.

[0052] Since multiple legacy and future methods for finding services are likely to co-exist, and because many devices are mobile and will be enabled with wireless network interfaces, peers will frequently encounter different protocols for locating and using other peers' services. The SDA Layer in P2PSOM provides SDA protocol federation so that each peer can use the specific SDA protocol as required by a given context while insulating the application.

[0053] In general, a mobile device may select one or more SDA protocols for each network interface, and may change the selected set based on the context, for example when roaming. P2PSOM federates the selected SDA protocols for use by applications on the device by a providing unified protocol- neutral interface to each SDA protocol.

[0054] Federation of multiple SDA protocols means the following: (1) A universal or generic SDA protocol may be exposed to applications via an API; (2) An outgoing request to advertise, discover, create, invoke, or authenticate a service or service method may be automatically converted to one or more SDA protocol specific operations by the middleware; (3) An incoming event, advertisement, query, or request from one or more SDA protocols will be converted by the middleware to the generic format of the federated SDA Layer; (4) Service descriptions for services discoverable via specific SDA protocols are translated to/from a generic service description or programming representation at the federated API; (5) Filters can be specified by applications on each peer governing the mapping of outgoing requests to specific SDA protocols and specific facilities of SDA protocols; similarly, filters can be specified by applications on each peer governing the mapping and visibility of incoming events, advertisements, queries, or requests from one or more SDA protocols to the API. Example filters are:

(a) Filter 1 : Use SDA1 , Block SDA2;

(b) Filter 2: If service-type = ecommerce, use SDA1 , else use SDA2;

(c) Filter 3: When at home { Grant * incoming advertisements; Block SDA2 incoming discovery from non-group member peers; Issue discovery in sequence SDA1, SDA2} When roaming { issue discovery parallel * }; and (6) The federated API can expose protocol-specific features of given SDA protocols to the application.

[0055] SDA federation at a device is complementary to using gateways between different SDA domains. Experience has shown, for example in the use of instant messaging and presence applications, that interoperability between different services domains by use of gateways is not a guaranteed deployment path. Further, using a Meta Service Discovery facility, a peer can discover which SDA protocols are used in a given domain, location, or application and can dynamically install the appropriate protocol library to use the given protocol.

Claims

CLAIMS What is claimed is:

1. A multiprotocol service discovery system, comprising: one or more computer applications operably connected to a computer network; a middleware layer operably connected to the computer network, wherein said middleware layer receives requests from said one or more computer applications, forwards the requests to one or more protocol implementations of the computer network, receives responses to the requests from the one or more protocol implementations, and returns the responses to said one or more computer applications.

2. The system of claim 1, wherein said middleware layer receives service advertisements from the one or more protocol implementations of the computer network, and forwards the service advertisements to said one or more computer applications.

3. The system of claim 1, wherein said middleware layer receives notifications about registered services from the one or more protocol implementations of the computer network, and sends notifications requested by said one or more computer applications to said one or more computer applications.

4. The system of claim 3, wherein said one or more computer applications generating the notifications use service description content for each of the one or more protocol implementations, and said middleware layer forwards designated portions of service description content to designated protocol implementations.

5. The system of claim 1 , wherein at least two of the one or more protocol implementations operate on same network interfaces.

6. The system of claim 1, wherein at least two of the one or more protocol implementations operate on different network interfaces.

7. The system of claim 1 , wherein at least two of the one or more protocol implementations operate on same network transports.

8. The system of claim 1 , wherein at least two of the one or more protocol implementations operate on different network transports.

9. The system of claim 1, wherein at least two of the one or more protocol implementations operate on same network media.

10. The system of claim 1 , wherein at least two of the one or more protocol implementations operate on different network media.

11. The system of claim 1 , wherein said middleware layer automatically routes service discovery requests to appropriate ones of the one or more protocol implementations of the computer network using a routing element.

12. The system of claim 1 , wherein said middleware layer performs protocol conversion and translation which converts from one or more common formats used by said one or more computer applications to protocol specific formats used by the one or more protocol implementations.

13. The system of claim 1 , wherein said middleware layer performs protocol conversion and translation which converts from one or more protocol specific formats used by the one or more protocol implementations to a common format used by said one or more computer applications.

14. The system of claim 1, wherein one of said applications searching for a device issues a request to said middleware layer, and said middleware layer forwards the request to each SD stack after translation into an appropriate format for each protocol.

15. The system of claim 1 , wherein a multiprotocol service discovery configuration involves SLP and at least one other protocol.

16. The system of claim 15, wherein a SLP user agent issues a request to a SLP directory agent, which returns one or more devices, and then service information is returned to the application.

17. The system of claim 16, wherein the service information is returned to the application after translation into a common application format.

18. The system of claim 15, wherein the other protocol is UPnP.

19. The system of claim 18, wherein the request, which specifies a service, is issued using SSDP, which is a multicast protocol on top of HTTPMU, the request is received by all listening UPnP devices, and those that provide the service respond with an SSDP reply.

20. The system of claim 19, wherein one or more UPnP devices advertise their availability using SSDP, and advertisements are cached in a local control point.

21. The system of claim 20, wherein the control point requests detailed service description documents from the devices, and service information is returned to the application.

22. The system of claim 21, wherein the application then selects at least one of the devices and issues a service request.

22. The system of claim 15, wherein the other protocol is Bluetooth.

23. The system of claim 22, wherein local SDP records are searched for matching entries, an SDP layer sends requests to neighboring SDP layers to request matching service records, and then the service information is returned to the application.

24. The system of claim 1 , wherein the protocols include at least one of multiple service discovery protocols, multiple service advertisement protocols, or multiple service invocation protocols.

25. The system of claim 1 , wherein said middleware layer performs identity management by operably mapping service discovery and advertisement function to and from a native service discovery and advertisement protocol format to a universal format.

26. The system of claim 1 , wherein said middleware layer performs identity management by mapping service discovery and advertisement function to and from a native service discovery and advertisement protocol format to a universal format.

27. The system of claim 1 , wherein said middleware layer performs filtering by filtering service discovery and advertisement requests and notifications.

28. The system of claim 1 , wherein said middleware layer performs grouping by associating service discovery and advertisement requests and notifications with groups that span multiple, separate service discovery and advertisement domains.

29. The system of claim 1 , wherein said middleware layer handles service discovery and advertisement requests and notifications for composite services in one or more service discovery and advertisement domains.

30. a multiprotocol service discovery method, comprising: receiving requests from computer applications operably connected to a computer network; forwarding the requests to protocol implementations of the computer network; receiving responses to the requests from the protocol implementations; and returning the responses to the computer applications.

31. The method of claim 30, further comprising automatically routing service discovery requests to appropriate ones of the protocol implementations using a routing element.

32. The method of claim 30, further comprising performing protocol conversion and translation to convert between common formats used by the computer applications and protocol specific formats used by the protocol implementations.

33. A multiprotocol service discovery method, comprising: discovering a first service discovery and advertisement protocol; and discovering a second service discovery and advertisement protocol, wherein the first service discovery and advertisement protocol is in a first service overlay.

34. The method of claim 33, wherein the second service discovery and advertisement protocol is in a second service overlay.

35. The method of claim 34, wherein the second service discovery and advertisement protocol is identical to the first service discovery and advertisement protocol except for its location in the second service overlay instead of the first service overlay.

36. The method of claim 33, wherein the second service discovery and advertisement protocol is in the first service overlay, and is a different service discovery and advertisement protocol than the first service discovery and advertisement protocol.

37. The method of claim 33, further comprising employing federated service discovery to discover the first and second service discovery and advertisement protocols.