The State of Service Protocols Jay R. Moorman
[email protected]
University of Illinois
John W. Lockwood
[email protected]
Washington University, St. Louis April 28, 2000
Abstract
Sung-Mo Kang
[email protected]
University of Illinois
infrastructure. The goal from each perspective is to provide many computing devices that are transparent to the end user.[1] From the user perspective, a service sharing system will involve no setup, con guration, or administration. A user will bring into range the resource limited device so it can locate, discover, and use any resources in the area. This background service sharing might range from borrowed CPU cycles to complete system level tasks. From the device perspective, a system can either have a resource it is willing to share, or be lacking a resource it desires to utilize. For resource capable devices, a method must be provided to communicate its service to other devices through service advertisements, contact with a central service server, or responses to service queries. A means to discover the available services must be provided to resource limited devices through listening for advertisements, contacting a service server, or transmitting queries. The network perspective involves the necessary infrastructure and support to facilitate the resource sharing. This includes the physical communication capabilities in addition to well de ned protocols that enable devices to o er and use available resources. This communication infrastructure includes the capability to tell and learn of available services through a central capabilities server, or point-to-point communication.
This paper looks at the current state of service protocols. With the increasing network connectivity of devices, a new approach to con guring and sharing resources is needed. This paper provides an overview of the primary proposed solutions for providing these functions. After exploring the current state of network services, the relevant issues needed for the transition to this new model of computing device utilization is discussed.
Introduction Computational resource sharing among multiple users had its origins with large central processors scheduling CPU cycles for users at individual terminals. As low-cost microprocessors emerged and made standalone desktop machines and workstations commonplace, the ability to communicate was passed to the network. As networked systems emerged with higher bandwidths and lower latencies, the possibilities for additional resource sharing became available. This enabled large parallel programs to be executed on multiple machines. Future resource sharing will involve the dynamic discovery, migration, and use of many services to all network connected devices. This article rst discusses the resource sharing model. Particular features and desired goals are introduced, and current protocols are described. In order to better compare and contrast these approaches, they are evaluated in terms of desired features of a resource sharing network.
Service Protocols
Bluetooth Service Discovery Protocol
Bluetooth1 is a technical speci cation for short range radio links between portable devices. It is supported by a special interest group as a solution for the emIn the model of ubiquitous computing, devices pro- bedded wireless market. The goal is to provide device vide services that are used by other devices in the connectivity without any unique cabling, and autonetwork. This can be viewed from three di erent matic connections for quick setup in ad-hoc networks. perspectives: the user, the devices, and the network 1
Service Sharing Model
http://www.bluetooth.com
1
2 The speci cation is a low level MAC layer protocol. Compliant devices must use the same Bluetooth protocol stack for the link communication, but may use existing protocols and interfaces on top of the Bluetooth speci c stack. One of the core protocols is the Service Discovery Protocol (SDP).[2] This service provides the vital function of locating services for Bluetooth devices. Devices can query for other device information, for available services, and for the capabilities of those services. A typical SDP client/server model is shown in Figure 1. A separate connection, not provided by the SDP, is established before the actual service can be utilized. Client Application
lored for the ad-hoc mobile environment of wireless devices, and is particularly well suited for quick service discovery.
Salutation
The Salutation architecture2 was designed by a consortium as a solution to service discovery in an environment of devices with varying degrees of connectivity and mobility.[3] The architecture allows these devices to both search for or request certain types of capabilities, and to advertise available device capabilities. A diagram of the Salutation architecture is shown in Figure 2.
Server Application
Remote Service
Remote Client RPC
Local Client
RPC
Local Service
Local Client
SLM - API
SLM - API
Salutation Manager
SDP Request
SDP Client
SDP Server
Transport Manager
Service Records SDP Response
Local Service
Transport Manager
Salutation Manager Salutation Manager Protocol
To SLM
RPC
Transport Manager
Transport Manager
To SLM
Figure 1: Bluetooth Service Discovery Protocol
Figure 2: Salutation Architecture
An SDP server maintains a record for each available service consisting of a list of service attributes identi ed by a 32-bit number (unique to that SDP). If a service becomes invalid, the server holds the identi er until all connections are no longer using that service. A device is not explicitly noti ed of a service departure, but is returned an error when invalid service use is attempted. All services are associated with a particular class to help distinguish the services by common attributes. An SDP client rst learns of a service record handle with a service search transaction. The search capability is provided to match attributes with Universally Unique Identi ers (UUID). These are globally unique identi ers for all space and time. They are independently created in a distributed manner with no global registry.[2] A search can be performed to match all requested UUIDs with a subset of the UUIDs of a service record. Hierarchical browsing of the available services is also possible through the use of special UUIDs. The SDP protocol uses a request/response model for communication as shown in Figure 1. Only a single data unit is sent with each message. If additional data is needed, the response will tell the client more data is available upon request. This protocol was tai-
The heart of the salutation protocol is the salutation manager (SLM). This manager functions as the resource broker for services, applications, and network devices. A transport independent API is provided by the manager to both the servers and clients so that services can register capabilities, and clients can discover and request services. A speci c SLM Protocol based on RPCs is used for manager to manager communication. Each SLM has a globally unique ID for identi cation by clients, services, and other managers. A transport manager is used in conjunction with the salutation manager for nding other SLMs. If found, the transport manager registers the SLM ID with the local SLM and maintains the necessary association. This discovery can occur either by a request to an existing central server, or a broadcast query. The requirements of the service broker include registry, discovery, availability checks, and the session management.[3] Registry information must be kept for all locally connected devices, and may be stored for services available on other SLMs. One SLM can be designated a central server to keep track of registry information in the entire network. Service discovery is performed by RPCs that transmit a speci c type 2
http://www.salutation.org
3 of service. The exchange protocol contains both the contents of the service, and the necessary protocol format needed to access the service. The discovery query can be for all services, speci c services, or services with particular matching characteristics. An availability check is performed periodically to update the state of registered services. Once a service has been discovered and is ready to be used, some type of management is needed by the broker. Session management is performed when the SLM establishes a virtual data pipe between a client and service. This pipe can be managed by the client/service, or the SLM (without data inspection). All commands and data are sent through this pipe in messages. Salutation is an open standard protocol designed for service discovery and management. It is meant to operate among many di erent devices and with various protocols, and has already been mapped to the Bluetooth Service Discovery Layer, and is currently being bridged with the Service Location Protocol.
Jini
Jini3 is an implemented software package from Sun Microsystems based on a set of Java APIs for the Java platform. In Jini, the entire network is viewed as a collection of Java virtual machines that rely on each other to share and use services. Targeted at the embedded system market, Jini is designed to be a set of infrastructure components and functional services for a distributed system, as well as a reliable programming model.[4] A Jini system provides a federation of services to a distributed environment through three major parts: services, infrastructure, and the programming model. Services or shared resources, are the key component of the federation. The system dynamically adapts so new services can be added, or old services removed at any time. The infrastructure needed to support the Jini model includes the messages, lookup services, and discovery services fundamental to the protocol. The programming model itself includes the leasing, event noti cation, and transaction interfaces. The combination of these three areas makes the Jini system a functional model for sharing distributed services. Services are the fundamental block in the federation. They use the infrastructure and programming model to e ectively provide a resource across a distributed system. These services are Java objects with a de ned interface advertised to the network. A device searching for this speci c service will use the in3
http://www.sun.com/jini
frastructure lookup to ll out a service template description. If a close match is made, the requesting device is informed of the available service and the appropriate communication interface. When a device rst enters the system it uses the infrastructure abilities of discover and join. Discovery, by multicast messages, is used to nd a lookup service with which to register. Once found, the device will attempt to join the lookup service, register new services, or locating existing ones. This lookup service is a repository of code for available services in the federation. Service code is then moved to a requesting device with Java's Remote Method Invocation (RMI) distributed communications infrastructure.[5] Entries in the lookup service are leased. When a device registers interest, it receives a noti cation if a lease has expired or a new service (matching its template) joins. Leasing adds the notion of time to services and keeps an up to date view of the distributed system. These leases, either exclusive or non-exclusive, are negotiated between the service user and service provider. The programming model allows multiple operations to be grouped into a transaction. The interface then provides a two-phase commit that can force grouped changes to be performed either atomically or not at all. The rst phase involves voting to see if the actions are ready to be executed, and the second phase involves a commit command. Client Jini Client
Service Proxy Device Specific Communication
Lookup Host Jini Lookup
Non-Jini Device
RMI
Service
Service
Jini Service
Jini Service
Device Proxy
Device Specific Protocol
Figure 3: Jini Federation The Jini architecture assumes that each device is running on a Java platform and has processing power and memory of its own. If a device is lacking these areas, it has a proxy act on its behalf. This proxy presents an interface to the federation that looks like any other Jini device. The proxy then translates federation information as needed for its connected device(s). The proxy will also serve as a gateway to communicate with non-Jini devices.
4
UPnP Simple Service Discovery
nding responses as needed. Services register with a directory so it can manage requests. If a client successfully nds a proxy, it will send all service requests through the proxy. Proxies will also communicate with other directories so that services outside the local area can be used. The open standard nature of UPnP is meant to allow various vendors, operating systems, and programming languages to be used in the architecture implementation. This is designed for greater interoperability while providing compatibility with legacy devices. A speci c UPnP programming model is not de ned but left to the individual devices and implementations.
Universal Plug and Play (UPnP)4 is a proposed architecture by the UPnP Forum for peer-to-peer service sharing in a network. It is designed for an ad-hoc networking environment targeted at PC's, embedded systems, and wireless devices.[6] This architecture relies heavily on existing protocols to provide an open network architecture for distributed devices and services. The Plug and Play (PnP) model is based primarily on a host/peripheral relationship involving communication links that are persistent over time. UPnP uses IP trac, web browsers, HTML pages, and the eXtensible Markup Language (XML) to separate the communication into presentation and data. It additionally provides a service discovery protocol for use Service Location Protocol over the IP network. The architecture is shown in The Service Location Protocol5 (SLP) is an IETF Figure 4. RFC designed to provide a framework for the discovery and selection of network services. In addiClient Service tion, it is designed to minimized or eliminate static con guration.[8] Dynamic con guration is used for XML Schema Application applications seeking a particular service with a cerUPnP UPnP tain set of attributes. If the number of clients and HTTP HTTP Request Service services becomes large, a central repository is used as IP Discovery Announcement IP a directory for advertised services. A typical protocol architecture and the available transactions are shown Directory in Figure 5. Application
Service
User Agent
Service Agent
Additional Directories
Figure 4: Universal Plug and Play Architecture The Simple Service Discovery Protocol [7] allows the discovery of devices based on pro les that de ne the contract between the client and the service. Services are represented by a description URL and service discovery uses an OPTIONS method.[6] A service is identi ed by a service type, a globally unique instance of that type, location information, and expiration time. This allows all services to be uniquely identi ed in a mobile environment. Clients only cache this information until the expiration time. Additional service information is provided to the client with an XML schema containing structured values. Devices operate in a distributed manner by sending out requests for service to speci c multicast addresses. Available services listen on the speci ed address for incoming requests, and respond as needed. The notion of a directory allows the protocol to scale. Directories act like a proxy, accepting requests and 4
http://www.upnp.com
Directory Agent
Service Agent
...
Service Agent
Figure 5: Service Location Protocol Architecture Applications looking for particular services act as clients in the system trying to discover particular services. In small networks services are con gured to respond, while in larger networks a directory agent is used to satisfy a client's request. Directory agents are rst discovered by clients using a query to a Directory Agent Discovery multicast address. 5
http://www.ietf.org/rfc/rfc2165.txt
5 When a device is willing to o er a service it must advertise the particular service and its attributes. The service information is encoded as a URL with a simple notation of keywords, attributes, and logical connectives. This method allows the communication to be human readable, use existing technology, and be more exible and adaptable with legacy code. An additional feature includes the use of a service scheme to name service types in the URL. User agents are contacted by the application to nd a particular service on the network. This agent will acquire service information that matches the user application request. If a directory agent is known, the user agent will send a unicast message for a particular request, and wait for a unicast reply. If no directory agent is known, a multicast request is used to a service-speci c multicast address. Service agents are responsible for both listening for service-speci c multicast requests, and for registering with any available directory agents. If a service becomes unavailable, the service agent is responsible for deregistering with the directory agent. The service agent will also refresh registrations in order to avoid the directory expiration. Directory agents serve as a central device for facilitating the service announcements and discovery in the network. They respond to client queries from the user agents, and allow registrations/deregistrations from services. This agent is also responsible for acknowledging service agent transactions, and for maintaining the expiration of registered services. Logical groupings of services across multiple directory agents are called scopes. Scoped service registrations are registered with all directory agents, while unscoped registrations are only registered with unscoped directory agents. A scoped user agent will only try to contact a directory agent with its particular scope. These scopes allow the organization of a network by certain administrative domains. An addition to the SLP protocol (iSLP) allows the protocol to scale over the internet. Directory agents are allowed to accept requests from user agents on the internet, but not to accept registrations from service agents outside the local area. For wide area discovery the use of a reserved name that resolves to the directory agent is needed. For example, da.some.net would resolve to the directory agent just as ftp.some.net would resolve to the ftp server.
infrastructure for applications to use services in a manner that is scalable, fault-tolerant, and available. A key component of the architecture is the Secure Service Discovery Service (SDS).[9] This service allows the advertisement of available and running services. Clients perform descriptive queries to locate particular services. All advertisements and query information use XML, and all communication is kept secure through encryption and authentication. In Figure 6, a diagram of the system components are shown SDS Server Certificate Authority Capability Manager
SDS Server Secure One-Way Service Broadcasts
SDS Server Authenticated RMI
Client
Server Hierarchy
Authenticated RMI
Service Authenticated Server Broadcasts
Service
Figure 6: Service Discovery Service Components
An SDS server contains descriptions of available and running services, answers client service requests, and periodically uses multicast announcements of the domain and address for service announcements. Service descriptions are cached and must be periodically updated before they expire. If the service load exceeds a threshold, a child server is spawned and given a portion of the current load creating a hierarchy of servers. The services in the system continually listen for announcements in case the server topology changes. If a new server is found, the service description is encrypted and sent. The service then locates a capability manager to provide the user speci c capabilities. Both a push-based passive discovery of services and a pull-based query discovery are supported. Security in the SDS protocol is kept very tight. A certi cate authority is used to authenticate bindings and signs certi cates. All service announcements use the secure one-way service broadcast protocol[9] before being decrypted at the server. SDS servers implicitly trust each other. However, the returned services are not trusted but are guaranteed to be signed by the certi cate authority. Each client must decide if it trusts each particular service. The capability manager limits the users that are allowed to discover a particular service. Each serNinja Service Discovery Service vice is authenticated before providing any capabiliThe Ninja Project6 is a software architecture for in- ties. The manager then distributes this information ternet support of services. Its goal is to provide the to clients who have a private key for the service. Ex6 http://ninja.cs.berkeley.edu piration times are used for a revocation function.
6
Service Issues All of the protocols include architectural similarities. The general service architecture contains three main components: clients, directories, and services. Peerto-peer client/service communication is often available, however, a directory service is used if possible. The client sends queries to the directory for particular service types. Services must advertise or register with the directory which will match incoming requests. Most service information in the directory is based on leased expiration times. Additionally, a proxy is used to translate services to devices that are not protocol compliant.
Security
The security of a resource sharing network is a major concern for users, devices, and the network infrastructure. Issues include authentication of particular system components, encryption of data, and the levels of trust and access granted to devices. The Bluetooth protocol provides a level of device level authentication and private key encryption at the link layer. A security policy in a centralized security manager labels devices and services as trusted or untrusted. The manager is just a database with registered services and devices. User level authentication is left to the application layer. The Salutation protocol bases its security on credentials along with a veri er for user level authentication. The UPnP protocol has no de ned security model. The Jini protocol bases its security model on the Java Remote Method Invocation (RMI) security extension. A Java authentication and authorization service is used to authenticate user logins, execute code for clients, and grant permission to clients. The client and server must mutually authenticate each other. A server can use delegation to authenticate for the client, and ne grained access control is provided through an access control list. Within each federation, security policies are agreed upon in advance. These include levels of trust, administration functions, and identi cation. The Service Location Protocol (SLP) includes a well de ned security model. User authentication is not included, but authentication for URL's, peer directory agents, service registrations, and deregistrations are included. The authentication blocks also track timestamps to combat replay attacks. Con dentiality can be guaranteed through the use of the IP encapsulating security payload (ESP) The Secure Discovery Services (Ninja) is designed
to speci cally address security concerns. It requires user and client authentication as well as service authentication. Clients must separately decide to trust a service. A certi cate authority and capabilities manager are included for authentication, certi cate signing, and restricting client access. All communication is encrypted, and an additional protocol (secure one-way service broadcast) is used for encrypted service announcements. The servers and certi cate authority are assumed to be in physically secure locations and implicitly trust each other throughout the network.
Scalability
The ability of a protocol to eciently scale to larger networks is of great importance. Most protocols were originally targeted at local area support, but have extensions to include larger area networks. Bluetooth does not address the issue of wide area scaling. Communication is only local to the particular RF area. In UPnP directory to directory communication is mentioned for a hierarchy of directories. In Salutation, the use of a central registry server is proposed with SLM to SLM communication used for service lookups. A global search algorithm is still needed since current methods rely on pointto-point requests. All three protocols use globally unique names. Bluetooth contains UUIDs, UPnP has Unique Device Names (UDN) that are dependent on location, and Salutation has unique ID's for each SLM. The Jini protocol mentions the use of lookup services arranged in a hierarchical manner. One lookup service provides information to other lookup services creating a bridge. This hierarchical view can be imposed on any collection of services, but the details of this hierarchical arrangement, and the necessary communication between lookup services is not well de ned. Naming is generated by the lookup service using the Universal Unique ID (UUID) for each particular service. Originally, the SLP protocol was designed only for a local area network. However, a number of extensions have been proposed to help the protocol scale to larger areas. This wide area addition includes the use of a central directory. In [10] the peer relationship among scoped Directory Agents is de ned. However, they are not arranged in a hierarchical topology and service queries are only to a speci c domain. For greater scaling, a more general search is needed. There is also a scaling problem with the use of unscoped directory agents that must register all scoped and unscoped services. The use of a naming author-
7 ity to provide unique names is mentioned, but the actual naming scheme is not de ned. Ninja was designed with scaling ability from the beginning. It includes support for a hierarchy of servers by spawning child servers. Service requests are propagated up a hierarchical tree if no local service matches are found. This propagation, which is lossy, uses a hashing algorithm. Local requests specifically search for a service that matches the exact requirements. However, if no local service is found, the search will look for more general matches on a larger scale. The e ect of scaling on the capability manager and certi cate authority is not well known, and the method of wide area naming is not de ned.
Fault Tolerance
The issue of fault tolerance is very important for a robust, reliable, and dependable working system. However, this issue seems to be poorly addressed by most current protocols. For an administration free service protocol to become widely accepted, it will need features that continue operation despite network problems. The rst important issue for fault tolerance is the ability to deal with disappearing services and/or devices. This occurs because of network link failure, individual device failure, or simply a wireless device moving out of range. Most of the protocols address this by leasing. If a service time expires without renewing its lease, it is assumed to no longer be available. Bluetooth is the most capable of handling this fault as it is designed for a wireless mobile environment. The system can adjust to services, clients, or servers moving out of range (or failing) at any time. SDP servers are co-located with clients and services. Jini, Ninja, and SLP provide leasing for service registration timeouts. Similarly, UPnP provides a caching of the service expiration. Salutation uses an availability check to guarantee a service is still operational. The second important issue in fault tolerance involves the failure of a directory server. Since this situation can prevent the ability of clients and services to nd each other, its solution is vital to the robust operation of a system. Bluetooth is well prepared to handle this situation since servers may go out of range at any time. SLP is also somewhat reliable during a server failure. It provides a mechanism to notify clients if either a directory agent or a particular service disappear. There are also provisions for redundant directory agents to avoid a single point of failure. Jini provides peer lookup if a lookup server fails. UPnP includes peer-to-peer service sharing but does not discuss the failure of a known directory service.
Ninja includes server announcements for changes in the network topology. The Salutation protocol does not address failed SLM's, but can operate in a pointto-point manner without central directories.
Service Protocol Directions A fundamental change needed for service protocols is a design shift to a new paradigm of service based systems. Instead of viewing the network as a collection of stand-alone devices that are independent and self-sucient, the network should be viewed as a service providing infrastructure. Each device is only a small part of that system and should be able to rely on the network to provide access to services it cannot perform on its own. This involves broadening the scope of how the service model is viewed. Instead of limiting shared services to simply a printing service, a wireless network, or a web browser connection, the new service paradigm must encompass all service requesters and service providers. This might include printing, or web access, but also would refer to CPU cycles, gateways, video/audio access, doorbells, VCR's, refrigerators, and toasters. The reliance of service mechanisms on existing protocols promotes quick implementations. This does not exclude the use of new protocols where needed, but rather encourages a protocol to leverage o of existing technology for a smoother transition. Security is also an area of great importance in this new service model. This involves not just the protection of data and authentication of users/devices, but also the ability to restrict services to particular domains and particular users. Many of the current protocols address these issues of security through proprietary implementations. Though security will be a necessity in fully developed systems, it is not yet clear if too much security in the initial design might hinder the adoption of the service protocols. This is especially true for embedded applications where program size is important, and where minimal protocol overhead is vital to low bandwidth communication (such as wireless). The issue of scaling may determine the long term survival of any particular protocol. Service protocol models that do not scale to broader area networks may nd themselves a player in only small niche markets. Key issues include network topology, global naming, and global searching. A scalable solution will involve locally unique identi cation with additional global attributes, though not necessarily uniquely global. This can be accomplished by hierarchical names, domain dependent names, or
8 some breakdown in global service names, with locally unique tags (which might even be location dependent). Once a naming scheme has been de ned and a network topology chosen, there remains the issue of search algorithms for wide area discovery. The issue of implementation for embedded devices will also be a key area for protocol adoption. A protocol must provide a small footprint while supporting a full set of features. Overhead should be kept as minimal and ecient as possible as the bandwidth may be limited. Finally, the ability of systems to adjust to component failure is a key area in need of work. This issue is only brie y addressed in the various protocols. For a true paradigm shift to a service capable network, the network must be reliable, predictable, and available{in other words fault tolerant.
Conclusion The idea of relying on the network as a service providing infrastructure is a new way of viewing the network. With the development of service protocols and the continued growth of digital devices, we may soon see such a network become a reality. Though there still remains obstacles to overcome, the future of network enabled service sharing holds many exciting prospects.
References [1] M. Weiser, \Some computer science problems in ubiquitous computing," Communications of the ACM, vol. 36, pp. 75{84, July 1993. [2] Bluetooth Special Interest Group, \Bluetooth Speci cation v1.0, Service Discovery Protocol." Available at http://www.bluetooth.com/v2/document, 1999. [3] The Salutation Consortium, \Salutation Architecture Speci cation version 2.0c." Available at http://www.salutation.org/specordr.htm, 1999. [4] SUN Microsystems, \Jini technology architectural overview." Whitepaper available at http://www.sun.com/jini/whitepapers/architecture.html, 1999. [5] P. J. Perrone and V. Chaganti, \Jini in the Box," Embedded Systems Programming, vol. 12, Nov. 1999.
[6] UPnP Forum, \Universal Plug and Play Device Architecture Reference Speci cation, Version 0.90." Available at http://www.microsoft.com/hwdev/upnp/, 1999. [7] Y. Goland, T. Cai, P. Leach, Y. Gu, and S. Albright, \Simple Service Discovery Protocol 1.0." IETF Draft , 1999. [8] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan, \Service Location Protocol." RFC 2165, June 1997. [9] S. E. Czerwinski, B. Y. Zhao, T. D. Hodes, A. D. Joseph, and R. H. Katz, \An architecture for a secure service discovery service," in MOBICOM '99, (Seattle,Washington), pp. 24{35, Aug. 1999. [10] W. Zhao and H. Schulzrinne, \Interaction of SLP Directory Agents for Reliability and Scalability." IETF Draft , 1999.
