Overview of Spontaneous Networking - Evolving Concepts and Technologies

Transcription

1 Overview of Spontaneous Networking - Evolving Concepts and Technologies Stephan Preuß, Clemens. H. Cap University of Rostock, Department of Computer Science Chair for Information and Communication Services {spr,cap}@informatik.uni-rostock.de Abstract The permanently growing networked IT-infrastructure, the need for more mobility as well as the expansion of computer-aided applications to new areas demand new methods to simplify the handling of ITsystems. Spontaneous networking is a means for simple integration of devices and services into networks. It seems to be one way to achieve more flexibility, more mobility, a better usability and less administration effort. This paper provides a definition of spontaneous networking and lists mandatory and optional features. It takes a closer look at the evolving technologies Jini (Java intelligent network infrastructure), JetSend, Inferno/Limbo, HAVi (Home Audio Video interoperability), and UPnP (Universal Plug and Play). Their basic concepts and functionalities are explained and their conformance to the principles of spontaneous networking is outlined. Keywords: spontaneous networking, network service, hot pluggable, plug and play Classification (CR 1998): C.2.2, C.2.3, C Introduction Personal digital assistants (PDAs) and cell phones become universal data terminals; sensors and actuators in home and industry automation are controlled via digital networks; the TV set evolves to a control terminal for air conditioning and lighting. The amount of networked devices currently runs towards infinity. In the same way grows the administration effort for handling this amount. Common techniques of manual parameter configuration and software installation do not satisfy the needs for more mobility, dynamic and user friendliness. The currently evolving methods for spontaneous networking of devices and services could be one way out of this situation. In a plug and play manner they can minimize the effort to integrate devices and services into network environments. 1

2 Section 2 gives a definition of spontaneous networking and deduces features of spontaneously networking systems. It lines out that spontaneous networking is not only associated with a service aspect but also with a device aspect, and classifies these aspects. Section 3 describes and examines currently available technologies according to the features of spontaneous networking. 2 Spontaneous Networking Nowadays spontaneous networking is a buzzword. But what are its characteristics? In this context spontaneous is not used in the meaning of not constrained or voluntary but in the meaning of automatic or self-regulated. Therefore, spontaneous networking is referenced here as the integration of services and devices into network environments with the objective of an instantaneous service availability without any manual intervention. 2.1 Requirements Based on the above definition a feature list can be set up. These features can be split into two groups, a mandatory one and an optional one. They are shown in table 1. There are two areas of spontaneous networking, a device concerned one and a service concerned one. The first area includes all tasks required for integrating a node into the communication infrastructure like negotiation of transmissions protocols and speeds, configuration of addresses, routing information, and other resources. The second area handles everything concerning the automatic integration and usage of services like the registration with brokers. 2.2 Device Integration Automatic device integration into network environments handles all tasks making the device able to communicate with others. That includes the configuration of physical and logical parameters. In general, physical parameters like media transmission protocols, speeds, and handshaking methods are related to the layers 1 and 2 of the OSI reference model (physical and link layer). These parameters are usually controlled automatically by media access controllers (MAC), firmware, or device drivers of the operating system, or they are predefined. For this reason, they will not be considered any further in this paper. The layers 3 and 4 (network and transport layer) have an amount of parameters like node addresses, security features and basic resources that are not transparent to the user and require manual configuration. 2

3 Service Integration Device Integration Adaptability Fault- Tolerance Platform Independence Interoperability Network Independence Uniform Service Interfaces Security Concept Mandatory Features New services are made available without user intervention. Device parameters needed for a proper function are provided by specialized services. The device is able to reach these services in the network with basic configuration. Devices or services can be added to or removed from the network community without interfering the global functionality. That means that the community adapts itself to the new conditions. Failure or breakdown of any attached device or service does not compromise the functionality of the community. Resources that have been in use by the failed entity are freed automatically, offered services are deregistered. Optional Features Service providers and clients can run on different platforms without any change. Services and clients from different vendors that run on various platforms can interact. Provision and usage of services does not require a specific transport protocol or medium. There is exactly one well defined and possibly abstract interface per service. Abstract means here it is implementation independent. Methods for authentication and authorization of all involved entities and for encrypted data transport are provided. Table 1: Features of spontaneous networking The following three sections describe specific facilities of some network systems that support automatic device integration Ethernet & IP In Ethernet and IP based networks there exists a variety of protocols that provide mechanisms for automatic parameter configuration [Ste96]. Table 2 gives a short description of some of them. The main objective of these protocols is to provide device configuration parameters during the boot process. Except for DHCP they do not meet the requirements for dynamic network integration and removal of edge devices. 3

4 RARP BOOTP DHCP DHCP Autoconfiguration The Reverse Address Resolution Protocol [FMMT84] returns the IP-Address that is assigned to a specific MACaddress. For acquiring its IP-address a client makes a layer-2-broadcast (Ethernet) containing the request, and the server answers with the appropriate IP-address. Prerequisite is that the server knows the MAC-address of all possible clients, therefore it is not applicable for dynamic environments. The Bootstrap Protocol has been designed for booting diskless clients [CG85]. It is able to provide the client s IPaddress, the address of a boot server and the name of the boot image to load. There are a lot of vendor-specific extensions to configure a wide range of other parameters. Without the knowledge of initial parameters requests and responses are transferred via UDP-broadcasts. Like RARP BOOTP assigns client parameters according to its MACaddress. The Dynamic Host Configuration Protocol [Dro97] extends BOOTP with the ability of automatic assignment of reusable IP-addresses not associated with specific MACaddresses and with further configuration options. IPaddresses may be temporarily acquired (leased). Such a lease has to be renewed before it expires otherwise the address can be assigned to another client. As the name implies, this is an extension to DHCP. In the case that the client s configuration requests are not answered by a DHCP-server it is allowed to choose an address from a pool of freely available addresses [Tro99]. The real availability of this address has to be determined by ARP-requests (Address Resolution Protocol). In this way local network communities can be built without the presence of a DHCPserver. Table 2: Configuration protocols for network parameters FireWire & USB Other network systems contain methods for automatic device integration. The IEEE1394-bus (FireWire) is a self-configuring bus system. When devices are connected via FireWire they negotiate a root node. This root node is then responsible for the further configuration management. It organizes address assignment and transmission control. FireWire is electrically and logically hot pluggable, that means devices may be inserted or removed during normal operation. A similar concept provides the Universal Serial Bus (USB). The main difference is that the USB requires a host system that acts as the root node. This is normally a PC or workstation [MSS + 99]. 4

5 2.2.3 Bluetooth The objective of Bluetooth is the creation of small ad hoc networks, so called piconets. Bluetooth is a short distance radio network that embraces features for voice and data transmission. It is designed for the use in small mobile devices like PDAs cell phones or wearable computers. Communication is done in a master-slave-principle. The master may initiate point-to-point or pointto-multipoint connections. A piconet is built of at most eight and at least two members. Initially the devices are in a standby state and listen for incoming messages. An arbitrary device initiates the connection establishment. This device will be the master for this connection. The slaves synchronize their transmission parameters with the master. Subsequent MAC-address assignment, control of several slave states and transmission related parameters is done by the master. Contrary to other network technologies Bluetooth has an integrated security system. It allows device authentication with a challenge-response algorithm and stream ciphering with keys up to a length of 64 bit [EII + 99]. 2.3 Service Integration Automatic service integration does not only include methods for service provision but also for locating and possibly usage of services. This process involves the entities service provider, client (consumer), and service broker (optional). The service provider sets up all prerequisites for an instantaneous usage of the service. That embraces service initialization, resource allocation, service announcement or registration with service brokers, and handling of locating (lookup) requests. Service Provider Service Interface Interaction Registration Service Agent Service Provider Service Interface Lookup Client Lookup Interaction Client Figure 1: Service setup If a service broker is available it is responsible for managing service requests of clients. Its functionality is not fixed. Current implementations reach from pure service management (see section 3.1) to acting as a proxy for service providers (see section 3.5). In figure 1 the difference between environments with and without a service broker is shown. Environments without a service broker are typically char- 5

6 acterized by a small number of nodes or services. The service usage is limited to the local network segment because in this case services are commonly located via broadcast- or multicast-protocols. Using service brokers makes it easier to manage large service amounts, because services may be requested from a central instance. Hierarchical structuring of service brokers makes it possible to enlarge the covered area and therefore to increase the amount of offered services. Considering service usage it can be distinguished between two major service types. The first type provides a vendor specific interface and it is up to the client to implement the specific access methods. This leads to proprietary service interfaces and increased implementation effort on the client side. The second type provides a service specific interface that hides the vendor specific features. That ensures interoperability between clients and services of different vendors. 3 Technologies 3.1 Java Intelligent Network Infrastructure (Jini) Based on the homogeneous programming and runtime environment of Java Sun Microsystems has developed the Jini specification [AWO + 99, Edw99, Sun99]. This embraces protocols and methods for the provision and the locating of network services. Jini is a distributed computing model that is built around so called lookup services. The design of the Jini reference implementation is not suited for an implementation on devices with little resources. The Jini code itself amounts to only a few kilobytes but it requires an almost complete Java2 runtime environment of several megabytes. A way out of this situation could be the Java2 MicroEdition that is currently under construction and needs much less resources. Device Integration Jini does not have any methods for integrating devices. This is due to the fact that it is based on the Java Virtual Machine (JVM) that is not designed for having access to device specific features. Device integration and configuration has to be done by the underlying operating system. Network Independence The Jini specification does not require any specific transport layer. But there is the need for a unicast and a broadcast (multicast) protocol. The broadcast facility is only necessary to find lookup services, so it can be omitted for the case that a lookup service is known at the outset. The current implementation of the Java Runtime Environment (JRE) only supports TCP/IP and UDP/IP as transport layers. This implies their usage for Jini. But based on Java SocketFactories other transport layers can be implemented. 6

7 Service Broker Locating (Discovery) Service providers as well as clients have the need for locating a lookup service. A reference to the lookup service can be received in two ways, via the Multicast Request Protocol (MCRP) or via the Multicast Announcement Protocol (MCAP). Services or clients entering a community use the MCRP to get references to all available lookup services. The lookup service itself uses the MCAP to propagate its presence. This ensures that all community members get informed about newly integrated lookup services. Having a reference to a lookup service the Unicast Discovery Protocol (UCDP) is used to download the service proxy. This proxy is the interface for registering or looking up services. Service Provision (Join) Service providers that enter a community register the proxy of their services together with a set of service attributes with the lookup service. From this moment they are offering their services that can be referenced exactly by the Java class type of the proxy and the optional attribute set. Registration with a lookup service is leased for a certain amount of time. The lease has to be renewed before it expires to ensure a continuous service provision. This is a contribution to the systems adaptability and dynamic because services that are no longer available will not remain registered. Service Locating (Lookup) Clients that are looking for a service send a request to a lookup service. This request contains a template characterizing the service by its class type and/or its attributes. As response the client receives all proxies of service entries matching the template. In a community without a lookup service clients can use a technique called peer lookup. The client acts similar to a lookup service and sends out MCAPpackets. This is the request for service providers to register with the client and to transmit their service proxy. The disadvantage is that the client has to implement an MCA-client and a UCD-server. Service Usage The Jini specification does not define service access methods. The usual way of accessing services are method calls on remote objects as provided by Java RMI (Remote Method Invocation). The client accesses the service functions by an abstract interface definition that it knows and that the service proxy implements. That means the service provider is not constrained to use RMI for the service interface. Furthermore, this gives the possibility to use non-java-services with a Java-proxy. Adaptability and Fault-Tolerance As outlined above, service registration is done with a lease concept, so there will be no services offered without a service provider available. Furthermore, Jini supplies remote events. They ensure that all entities interested in these events will be notified of any state change of a service and can react appropriately. The identifiers associated to services by a lookup service are consistent across the network and unique even after lookup service crashes. 7

8 3.2 JetSend Hewlett Packard has designed JetSend as a data-type-based protocol for information exchange between devices like printers, scanners, and cameras. It does not exactly fit in the model shown in section 2.3, but it includes concepts and technologies that are covered by spontaneous networking. Functionality JetSend is based on type-oriented data streams, called e-material. It introduces the surface interaction model for information exchange. A surface is a layer representing data of a specific type (e-material). They can be hierarchically structured so that they can represent any useful combination of data types (e. g. video and audio). Data transport is performed in producer-consumer-principle. The consumer surface is synchronized with the producer surface. Surfaces transform between device specific and device independent data formats (e-material). User interfaces, control and security functions (PIN-surface) can be realized in this way by special surfaces. JetSend defines some basic data types that build the smallest common denominator between JetSend-compatible devices. The specification is open for the introduction of new data types that meet the requirements for data to be transmitted. During connection establishment JetSend-devices negotiate the optimal data format supported by both sides [Hew99]. Network Independence JetSend can be implemented on any bi-directional transport layer so it is network independent. It uses an addressing scheme called JetSend Multi-Network (JMN) that is comparable to a URLnotation with a transport layer tag. Device Integration The specification does not define methods for integrating devices into network environments. They are made dispensable by the preferred operation of JetSend on point-to-point connections like infrared or serial lines, or self-configuring networks like Bluetooth. On transport layers like IP manual configuration or support protocols like DHCP are required. 3.3 Inferno/Limbo With Inferno Lucent Technologies has designed a small and portable network operating system. It allows transparent network wide access to resources, services, and information. Inferno is able to run as a native or hosted operating system on a variety of hard- and software platforms [Tec99]. So it provides a homogeneous programming and runtime environment. A functioning system can be set up in environments with less than one megabyte of working memory. That makes it suitable for lightweight devices like network computers (NCs), personal digital assistants (PDAs), or cell phones. Platform and Network Independence As shown in figure 2, the Inferno kernel is implemented on top of a communication layer called styx. Styx hides platform and network specific features. The Inferno kernel provides a 8

9 common API with network, graphic (Limbo/Tk), security, and other functions. Inferno applications run on a virtual machine called Dis that supports automatic garbage collection and just-in-time compilation (JIT), making Inferno applications platform independent. Applications are programmed in a language called Limbo which is similar to C. Besides the Dis there is a Personal Java implementation that opens the Java world to Inferno. Limbo Application Java Application Dis JVM Inferno Kernel Styx Host-OS Device Driver Hardware Figure 2: Inferno structure Service Provision and Locating All resources and services are provided via a network transparent namespace. This is realized as a hierarchy of file handles similar to UNIX special files. For applications it is not important whether a resource is locally or remotely available. The transparent access is organized by the styx communication layer. Service Usage Due to the file concept, service or resource access is handled via file operations. For instance, a video stream could be rendered by redirecting it to the appropriate special file or a database service could be realized by writing the request to and reading the response from another special file. Any service can be mapped to this scheme. The disadvantage is that the client has to implement a service specific communication protocol for interaction on the special file. Security The Inferno API includes methods for authentication, authorization, and encryption. Therefore, Inferno provides symmetric and hash algorithms (DES, RC4, SHA, MD5). 3.4 Home Audio Video interoperability (HAVi) HAVi has been designed by eight leading vendors (Sony, Grundig,... ) of consumer electronics (CEs) like TV sets, VCRs, and DVDs with the objective of easily networking them. The major design goals are [GHM + 99]: exchange of control and audio/video contents, self-configuration, self-management, hot plug and play, sharing of computing and storage capacities. 9

10 Device Integration In section the IEEE1394-bus has been shortly characterized. It is the only network system supported by HAVi. Doing so, HAVi adapts the hot-plug-and-play and self-configuration facilities from the IEEE1394-bus. HAVi distinguishes four device categories by their functionality. With a short description they are shown in table 3. FAV IAV BAV LAV Full Audio/Video device; contains an own runtime environment, a Java Virtual Machine, and implements HAVi services. Intermediate Audio/Video device; is like the FAV but does not contain a Java Virtual Machine. Base Audio/Video device; it does not have an own runtime environment, but provides a HAVi-compliant interface. Can supply its interface in form of downloadable Java bytecode. Legacy Audio/Video device; it is not a HAVi-compliant device and has to be integrated via gateways. Table 3: HAVi device categories Service Provision and Locating Services are encapsulated by objects called software elements. Software elements have to be registered with a unique Software Element Identifier (SEID) with a system wide Registry and can be requested there. Every FAV and IAV implements an instance of the Registry. Interoperability HAVi specifies communication protocols interoperability APIs with and access methods for software elements. Software elements use platform specific APIs to provide platform independent APIs to HAViapplications. Service Usage HAVi is not designed as a universal service platform so two major service types can be distinguished, device control and transmission of audio/video data. The interface to the services is supplied by Device Control Modules (DCMs). DCMs give HAVi compliant access to device specific functions. FAVs and IAVs normally embed their DCMs and have them running in their own execution environment. BAVs have to have their DCMs run in other device s execution environments. They can provide them as loadable Java bytecode or have them embedded in other FAVs/IAVs of e. g. the same vendor. In the Java execution environment of FAVs can run arbitrary applications that use functions of software elements. User interfaces can be supplied with Java applets that use a specially designed AWT (Abstract Windowing Toolkit). 3.5 Universal Plug and Play (UPnP) Microsoft has initiated the UPnP Forum which in turn created the UPnP specification. UPnP does not invent new techniques, it uses common ones 10

11 and puts them together in a framework. The design goal is to extend the known Plug-and-Play concept ( zero-configuration peripheral connectivity ) to a heterogeneous network environment [UPn99]. UPnP-services are mainly WWW-based offers, and common browsers act as user interfaces. Interoperability, Platform and Network Independence There is a kind of interoperability, the interaction protocols and service descriptors are fixed in the specification. Implementation and generation of APIs is up to the vendors which means there is no platform independence. IP is defined as the default UPnP network layer. Service Locating A central question within UPnP is how a client can locate service providers. The Simple Service Discovery Protocol (SSDP) is supplied to solve this task. SSDP uses TCP- and UDP-based HTTP. A client sends out UDP-multicast-packets that contain an identification for the required service. The service providers listen for such requests and respond to the client if they are matched by the identifier. Service Broker Locating The UPnP-concept contains a directory service called directory that can be hierarchically structured. Clients do not need to take care about the directory, it is transparent to them. Service providers have to distinguish between networks with and without a directory and adapt their behavior. Without a directory a service provider answers appropriate SSDP-requests itself. If a directory is available the provider has to register with it and does not respond to SSDP-requests anymore. In this case the directory acts as a proxy for the service. Service Usage Once a client has located a service it can request a more detailed service description. This is called schema and is based on XML (Extensible Markup Language). Further interaction between client and service is not specified by UPnP. Device Integration UPnP makes use of DHCP and its extension DHCP Autoconfiguration (see table 2) for automatic device integration. Another technology used by UPnP is Multicast-DNS [WM98]. It is used for resolving node names and IP-addresses in absence of a DNS-server. DHCP- Autoconfiguration and Multicast-DNS are not ready standards but they have been proposed for standardization to the IETF (Internet Engineering Task Force). Devices that are unable to communicate via IP can be integrated in UPnP-communities via proxies or gateways. In the same way devices and services that are not UPnP-compliant (legacy devices/services) may be integrated. 4 Conclusion Spontaneous networking is more than pure automated service provision, it covers aspects related to devices, networks, security, and others. As shown in 11

12 table 4, all presented technologies ensure interoperability between different systems but this is not spontaneous. The major objectives are covered in a quite different manner. Jini JetSend Inferno HAVi UPnP Service Integration Device Integration Adaptability Fault-Tolerance Platform Independence Interoperability Network Independence Uniform Service Interfaces Security Concept good, ++ partial, + possible, - not, not relevant Table 4: Feature overview Products like JetSend and HAVi are designed for special purposes. In their domains they realize many of the ideas of spontaneous networking, but they are not suited as universal service platforms. UPnP is mainly made for WWW-based services. Such services do not meet the requirements e. g. in industrial environments. The binding to IP-networks shows the target. The abstract styx communication layer of Inferno with its network transparency would be a good choice for network and platform independence. But service usage via special files requires the clients to implement interaction protocols and makes them dependent on the specific service implementation. According to the fact that Inferno is a real operating system it provides security mechanisms for authorization and encryption. This is one of Jini s disadvantages. It lacks of any authorization or authentication. But due to the open service concept this functions may be implemented with specialized services. Adaptability and fault-tolerance are given by the lease concept, the remote events, and the unique and consistent service identifiers. Platform independence and interoperability is given by the use of Java. Network independence has to be improved since Java is too closely bound to TCP/IP. Uniform service Interfaces are under development. And the service access via abstract interfaces makes the client lightweight. The here outlined advantages and disadvantages are visualized in figure 3. WWW-page-counts are not absolutely representative but they can show the global acceptance of these technologies. 12

13 Matches 9994 Relevant WWW pages found with Altavista ( ) UPnP HAVi Inferno Limbo 1299 JetSend Jini Products Figure 3: WWW-reference-counts References [AWO + 99] Ken Arnold, Ann Wollrath, Brian O Sullivan, Robert Scheifler, and Jim Waldo. The Jini Specification. Addison-Wesley, [CG85] Bill Croft and John Gilmore. Bootstrap Protocol (BOOTP). IETF Internet Draft, RFC 951, [Dro97] Ralph Droms. Dynamic Host Configuration Protocol (DHCP). IETF Internet Draft, RFC 2131, [Edw99] W. Keith Edwards. Core Jini. Prentice Hall, [EII + 99] Ericsson, IBM, Intel, Nokia, and Toshiba. Bluetooth Technical Overview [FMMT84] Ross Finlayson, Timothy Mann, Jeffrey Mogul, and Marvin Theimer. A Reverse Adderss Resolution Protocol (RARP). IETF Internet Draft, RFC 903, [GHM + 99] Grundig, Hitachi, Matsushita, Philips, Sharp, Sony, Thomson, and Toshiba. HAVi Specification [Hew99] Hewlett Packard. HP JetSend Communications Technology

14 [MSS + 99] Christian Müller-Schloer, Burghardt Schallenberger, et al. Vom Arbeitsplatzrechner zum ubiquitären Computer. VDE, [Ste96] W. Richard Stevens. The Protocols. In TCP/IP Illustrated, volume 1. Addison-Wesley, [Sun99] Sun Microsystems, Inc. Jini Connection Technology. sun.com/products/jini/, [Tec99] Lucent Technologies. Inferno Introduction [Tro99] Ryan Troll. DHCP Auto-Configuration Option [UPn99] UPnP Forum. Universal Plug and Play Connects Smart Devices [WM98] B. Woodcock and B. Manning. Multicast discovery of DNS Services Product related URLs Jini JetSend Inferno HAVi UPnP