Network Layer Resource Monitoring and Discovery for Information Service on Wireless Grids
1Shu-Hung Kuo, Kuochen Wang, Yi-Ling Hsieh Department of Computer Science
National Chiao Tung University
1This work was supported by the National Science Council, under Grant NSC 96-2628-E-009 -140 -MY3.
Abstract—In grid computing, the grid information service (GIS) plays an important role in grid resource discovery, registry, and indexing. The resource monitoring and discovery service (MDS) in GIS provides a set of messages to get the status information of resource providers and keeps monitoring on them. Traditional resource monitoring and discovery schemes for wired grids are not directly applicable to wireless grids due to the characteristics of them, such as frequent information update, short-lasting power source, and limited computing capacity. In this paper, we propose a network layer resource monitoring and discovery service (NL-MDS) scheme. It is an ad-hoc routing protocol embedded method for wireless grids. The resource types and status information of resource providers are piggybacked on the message extensions of the ad-hoc on-demand distance vector (AODV) routing protocol. Each client, which needs resources, can perform a fast look-up for resource providers in the proposed resource table. We have compared NL- MDS with WGMDS (Wireless Grid Monitoring and Discovery Service), an extension of MDS in the Globus Toolkit, to evaluate the number of control packets and the discovery completion time.
Simulation results show for nodes from 10 to 50, NL- MDS can reduce the number of control packets from 23% to 2%, and decrease the discovery completion time on average by 50% compared to WGMDS.
Therefore, the proposed lightweight resource monitoring and discovery scheme can support a fast resource monitoring and discovery service with low overhead on wireless grids, and is suitable for wireless grids in temporary or urgent needs.
Index Terms—grid information service, monitoring and discovery service, network layer, wireless grids.
1. INTRODUCTION
Grid computing [1] is a kind of distributed systems that aggregates and shares computational resources over a network. The service-oriented architecture of grid computing is defined in OGSA
(Open Grid Service Architecture) [2]. In OGSA, the grid information service (GIS) [3], which is an infrastructure component responsible for collecting and distributing information about grids. GIS contains the mechanism of resource discovery, registry, and indexing. The resource monitoring and discovery service (MDS) in GIS provides a set of messages to get the status information of resource providers and keeps monitoring on them. Most resource monitoring and discovery approaches in GIS followed the WSRF (Web Service Resource Framework), which defines the concept of stateful resources. Just like many implementations of grid computing, a wed-based method was adopted to perform discovery, registration, monitoring, and notification of GIS. With the widespread of web applications since the middle of 1990s, the web- based resource monitoring and discovery service has offered the most convenient way to perform the periodic communications of nodes in grid computing.
Due to the enormous growth of wireless networks of different types since late 1990s, personal electronic devices with wireless network capacity are common to find in our life. Owing to different requirements from wired grids, the resource information on wireless grids needs to be updated more frequently. On wireless grids, which are constructed within MANETs (mobile ad-hoc networks), we have to take account of node mobility, short-lasting power source, limited computing capacity, and so on. Many existing protocols which provide service discovery in peer-to-peer environments were proposed, like SLP (Service Location Protocol) [4], Jini [5], and UPnP (Universal Plug and Play) [6], etc. But most of these existing approaches were not designed originally for grid computing due to lacking a complete monitoring mechanism. Moreover, in some approaches proposed recently [8][9], they addressed the specific requirements of MANETs, and design methods coupling the service advertisement and discovery with the ad-hoc routing protocol, to save some overheads from the periodical operations of MANETs. In this paper, we propose a network layer resource monitoring and discovery service (NL-MDS) scheme, which is an ad-hoc routing protocol
embedded method, to deal with the resource monitoring and discovery on wireless grids. We have compared the proposed NL-MDS with the WGMDS (Wireless Grid Monitoring and Discovery Service) [10]. WGMDS is an extension of MDS in the Globus Toolkit [7], one of the most widespread and well- known software toolkits used to build grid computing systems.
This paper is organized as follows. In Section 2, some existing approaches of resource or service monitoring and discovery are reviewed. In Section 3, we introduce the basic idea and describe the design approach. Simulation results for the design approach have been obtained and discussed in Section 4.
Finally, in Section 5, we give concluding remarks and future work.
2. RELATED WORK
In this section, we review some existing approaches in peer-to-peer service discovery first, and then we introduce the MDS [7] of the Globus Toolkit and WGMDS [10] in wireless grids. Finally, we make a comparison among the mentioned approaches.
2.1. Peer-to-Peer Service Discovery
In peer-to-peer environments, the service information is an important component for communication and collaboration, just as the resource information in grid computing. Several approaches were already proposed, like the SLP from IETF (Internet Engineering Task Force) [4], Jini from Sun Microsystems [5], and UPnP from Microsoft [6]. According to design methods of these service discovery approaches, most of them were implemented without a complete monitoring service.
A. SLP [4]
SLP is a standards-track protocol developed by the IETF SrvLoc group to simplify the discovery and use of network resources, such as printers, fax machines, video cameras, web servers, mail servers, calendars, databases, and so on. Focusing on the vendor and platform independent, SLP establishes a framework using three types of agents: Service Agents (SAs), which advertise service handles (service providers), Directory Agents (DAs), which collect service handles in intranets, and User Agents (UAs) which acquire service handles for user applications [4]. When a UA needs to acquire a service handle, it sends the service type, a string- based query and the desired attributes in a service request. When the service reply is returned, it contains a URL (Uniform Resource Locator) pointing to the service. The discovery process
requires TCP/IP and the knowledge of a SLP server where the clients can initiate service requests.
B. Jini [5]
A Jini system is a distributed system, based on a Java application environment, federating groups of users and the resources required by users. Jini turns the network into a flexible system on which resources, implemented as either hardware devices or software programs, even a combination of the two categories, can be found by human and computational clients.
The kernel function of Jini is performed by a trio of protocols: discovery, join, and look-up [5]. The discovery/join protocols occur when a device is plugged in. The discovery protocol supports services to find a look-up server and when the services find a look-up server, the join protocol supports them to join the server with the registration procedure. In other words, the discovery/join is the process of adding a service to a Jini system. When a client needs a service from service providers, it sends a look-up request to the look-up server and gets the information provided by service providers.
C. UPnP [6]
Developed by Microsoft, UPnP defines an architecture for pervasive peer-to-peer network connectivity of devices. UPnP is implemented in Windows XP, an extension of Windows Plug and Play. It leverages TCP/IP and web technologies to provide a distributed, open networking architecture.
Discovery is the first step in UPnP. Based on SSDP (Simple Service Discovery Protocol), when a device is added to the network, the UPnP discovery protocol allows the device to advertise its services to control points (look-up servers) on the network. Similarly, when a control point is added to the network, the UPnP discovery protocol allows the control point to search for devices on the network. The UPnP description for a device is expressed in XML (Extensible Markup Language) and includes a list of devices or services. The control message is also implemented in XML using the SOAP (Simple Object Access Protocol) to deliver then return results or errors back to control points.
2.2. Resource Monitoring and Discovery in Wireless Grids
A. MDS in the Globus Toolkit [7]
The GIS (grid information service) within the most widespread and well-known grid middleware, Globus Toolkit, is called MDS. It was built on the top of LDAP (Lightweight Directory Access Protocol) that provides information about available resources on wireless grids and the status of resource providers.
The resource providers that make up a grid
environment can be discovered, accessed, allocated, monitored, accounted for, billed for, and so forth [2].
MDS is a WSRF implementation and a suite of web services to monitor and discover resources on wired grids. MDS was specially designed to address the needs of a grid monitoring system. Corresponding to two services of resource monitoring and resource discovery, MDS provides two WSRF-based services in the Globus Toolkit:
z GRIS (Grid Resource Information Service): It includes a standard configurable information provider framework, and uses the GRIP (Grid Information Protocol) to provide access to information about individual entities.
z GIIS (Grid Index Information Service): It provides a framework for constructing an aggregate directory. A GRIS registers itself to a GIIS using the Grid Resource Registration Protocol (GRRP).
Resource A Resource B
GIIS
GRIS GRIS
IP IP IP IP IP
Cache information from A and B GRIS registers with GIIS
GIIS requests information from GRIS
Client 1
Client 2
Client 1 searches the GRIS directly
Client 2 uses GIIS for searching collective
information
Figure 1: The MDS architecture in the Globus Toolkit.
In Figure 1, it shows that Information Providers (IPs) interfaces from any data collection service and talk to the GRIS. The GRIS runs in a resource and acts as a content gateway for the resource, and then registers with a GIIS. The GIIS provides an aggregate directory of lower-level data. And clients can search either GRIS or GIIS for the resource information [7].
B. WGMDS [10]
WGMDS, an extension from the Globus Toolkit MDS, is a lightweight and WSRF complaint information service that is used for wireless grids.
Due to the specific needs of wireless environments, no Virtual Organization (VO) information service is required in WGMDS. WGMDS distributes information services to manage parts of resource providers. Then via a peer-to-peer mechanism, WGMDS integrates all site information services with full grid information. For service providers, it queries and registers to the nearest information service dynamically. For resource request clients, the site information service sends a merged search result
back. WGMDS implements the ISPDA (Information Service Peers Discovery Algorithm) to broadcast an information service peer-list, and after running the algorithm, all information services can establish their complete peer-lists. WGMDS also implements the ISPA (Information Service Probing Algorithm) to find the nearest information service. And in order to provide the aggregated result from every information service peers, WGMDS implements the P2PISPA (P2P Information Service Provision Algorithm) [10].
Note that WGMDS uses AODV as its routing protocol.
Table 1: Comparisons of different approaches.
Approach Category Resource
registry Network transport
Ad-hoc network compatibl
e
Feature SLP [4] P2P centralized http medium authentication
feature Jini [5] P2P/grid centralized independent medium Java-centric architecture UPnP [6] P2P distributed http low automatic
configuration MDS [7] Grid centralized http low WSRF compliant WGMDS
[10] Grid distributed http high
decentralized information
service NL-MDS
(proposed) Grid distributed ad-hoc routing
protocol high
routing protocol embedded
method
Table 1 shows the comparisons of the mentioned approaches. In terms of category, resource registry, network transport, and ad-hoc network compatible, we make comparisons among the P2P service discoveries we have mentioned, and the grid computing resource monitoring and discoveries:
WGMDS and the proposed NL-MDS.
2.3. Overview of the Service Discovery Internet Draft
The “Service discovery in on-demand ad hoc networks” Internet draft [11] was proposed by Koodli and Perkins from the Nokia research center.
Since our design approach is based on this draft, we first review its basic concept. It uses an on-demand routing protocol such as the ad-hoc on-demand distance vector (AODV) routing protocol or the dynamic source routing (DSR) protocol. It defines two new routing messages, SREQ (service discovery request, as shown in Figure 2), and SREP (service discovery reply, as shown in Figure 3), with the purpose to initiate a service discovery process, which is similar to route discovery. The extensions introduced in this document use the Type-Length- Value (TLV) format, with 8-bit types. It embeds the service discovery into the ad-hoc routing protocol, and binds the service selector (service names and port numbers) to the IP address. Consequently, it can
decrease the latency between the service request and service reply.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length <Srv-type>
length Reserved
<Service-type> string
Service request predicate
Figure 2: Service discovery request (SREQ) extension format.
The definition of each field in the SREQ message extension is shown in Table 2, and in the SREP message extension is shown in Table 3 [11].
Table 2: The definition of each field in the SREQ message extension.
Field Definition Type The value of the message type
Length Length of the extension
<srv-type> length Length of the <service-type> string
<service-type> string The <service-type> string Service request predicate The <predicate> string
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length Lifetime
URL length URL (variable length)
Figure 3: Service discovery reply (SREP) extension format.
Table 3: The definition of each field in the SREP message extension.
Field Definition Type The value of the message type
Length Length of the extension
Lifetime The lifetime of the association between the service and the IP address of the node hosting the service URL length Length of the URL
URL The service: URL strings as defined by the Service Location Protocol
3. DESIGN APPROACH
In this section, we propose a network layer resource monitoring and discovery approach, named NL-MDS, for wireless grids. In contrast to WGMDS, it targeted at the trade-off between functional completeness and operating overhead, NL-MDS uses
simple resource information and a fully distributed method for resource discovery and monitoring.
3.1. Network Layer-MDS
We propose a network layer resource monitoring and discovery service (NL-MDS) scheme that includes the following characteristics of wireless grids [10]:
z Resource providers arrive and depart frequently.
z Mobile wireless devices are generally less powerful than wired devices.
z The information services on wireless grids should be able to probe the status of resource providers dynamically.
In addition, we add a new control message extension to each of three AODV routing packets: RREQ, RREP, and Hello [12][13] for resource monitoring and discovery and a resource table for the look-up of resource providers.
A. Control Message Extension for Resource Monitoring and Discovery
In order to support the resource table establishment, we design a new control message extension for NL-MDS, which was modified from the message extension of SREP and was described in Section 2.3. In Figure 4, the format of the proposed control message extension is shown and the definition of each filed is given in Table 4.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Type Length Lifetime
Resource type Resource property URL
Length URL (variable length)
Figure 4: The proposed control message extension format.
Table 4: The definition of each field in the proposed control message extension.
Field Definition Type The value of the message type
Length Length of the extension
Lifetime The lifetime of the association between the service and the IP address of the node hosting the service
Resource Type The type of the sharing resource: the CPU free time, free memory space, or network bandwidth on wireless grids
Resource Property Property descriptions for the resource URL Length Length of the URL
URL The service: URL strings as defined by the Service Location Protocol
By piggybacking the resource types and their status information to the message extensions of AODV control packets, whenever the route path discovery is initiated, the resource discovery is also in progress. While the RREP acts as a backward path discovery to establish a route path, the route table will be built, so will the resource table. The resource table contains the resource information of the current node and any other nodes along the same route path.
It offers the resource type and resource properties for look-up when a node needs some information about a required resource. In Figure 5, the resource discovery algorithm in NL-MDS is shown. A node will receive RREQ packets or RREP packets in the resource discovery procedure. When the received packet is a RREQ, it will update the route to the originator. If the current node is a destination or has a fresh route, it will attach resource information to the RREP message extension and send the RREP back to the originator, or it will attach resource information to the RREQ message extension and forward the RREQ to neighbors. On the other hand, when the received packet is a RREP, it will update the route table. If the current node is the originator, it will update the resource table; otherwise it will update the resource table and forward the RREP to neighbors.
Figure 5: Flowchart of resource discovery.
B. The Resource Table for Look-up
Resource
type Resource
property URL Lifetime
Figure 6: The proposed resource table.
We design a resource table for resource providers to exchange their sharing resources as shown in Figure 6. The definition of each field is shown in Table 5. With only four fields are included in the resource table, our approach can provide a
lightweight information service. When a route path is established, the route table and resource table will be established in each node as well. If a node initiates a request for sharing resources on wireless grids, it will first perform a fast look-up in its resource table.
Because the node simply performs a look-up in its own resource table, it can get the information very quickly without any network transmission delay, mass look-up request and reply packets. The resource table not only supports the resource type and properties, but also offers the URL information to map to the IP addresses of the resource providers.
Considering the update frequency in wireless grids, the lifetime field is needed to keep the entry in the resource table fresh enough for look-up.
Table 5: The definition of each field in the resource table.
Field Definition Resource type The type of the sharing resource: the CPU free
time, free memory space, or network bandwidth on wireless grids
Resource property Property descriptions for the resource
URL The service: URL strings as defined by the Service Location Protocol
Lifetime
The lifetime of the association between the service and the IP address of the node hosting the service
C. The Resource Monitoring
Upon the completion of resource discovery, the resource monitoring starts. Similar to the route table maintenance, the resource table uses AODV Hello messages with the proposed message extension to detect the possible status change of resources. Hello messages, which are RREP messages with the hop count of 1, are used to detect the linkage broken and keep the connectivity with neighboring nodes. We also use Hello messages to exchange the resource information status between neighboring nodes. And when the resource information status changed, the associated node records the status in the message extension. Then if any neighboring node receiving the message extension will update its own resource table to keep the table fresh after checking the sequence number of the Hello message to make sure no duplication. The resource monitoring algorithm is shown in the Figure 7. When in a resource monitoring cycle, the current node will check the Hello message. If there is no change of resource information status, the current node will simply use the Hello packet without message extension, and the neighbors will receive the Hello packet. If there is any change of resource information status, the current node will attach updated information to the Hello message extension. And when the neighbors receive the Hello packet with message extension, it will check the sequence number. If the sequence
number is new, the neighboring node will update the resource information, or skip this packet.
Figure 7: The flowchart of resource monitoring.
3.2. The Features of Our Design Approach The main difference between our approach and Koodli and Perkins’ approach [11] reviewed in Section 2.3, are described as follows. Koodli and Perkins’ approach uses two different control message extensions for SREQ and SREP to perform the service request and reply. However, in NL-MDS, we use the same control message extension for RREQ and RREP to establish a resource table. The resource table is used for the look-up of a resource, and each node has its own resource table. Moreover, we also use the same message extension for the Hello packet.
The Hello packet can not only be used for keeping connectivity within neighboring nodes, but also for the maintenance of the resource table. Using the same message extension for the three control packets, RREQ, RREP, and Hello, in NL-MDS, substantially simplifies our design.
4. EVALUATION AND DISCUSSION
In this section, we evaluate the proposed NL- MDS approach, by measuring its estimated discovery completion time and the number of control packets generated, and compare NL-MDS with WGMDS in wireless grids.
4.1. Simulation Model
We used the ns-2 [14] network simulator to simulate NL-MDS and WGMDS. The simulation scenarios consist of 10-50 mobile nodes moving in a rectangular area of 500 m × 500 m. The speed of mobile nodes is randomly chosen from 1 to 10 meters/second. The IEEE 802.11b medium access protocol is employed at the link layer level. Each
node has a transmission range of 250 meters. All nodes are equipped with identical wireless radios, which have a bandwidth of 11 Mbps. The simulations run for a period of 200 seconds. The AODV routing protocol is used for routing. Node movement and traffic connection pattern are automatically generated by ns-2 in the simulation. The mobility model is the random waypoint mobility model. The parameters used in the simulation are summarized in Table 6.
Table 6: Simulation parameters [10]
Parameter Value Area size
(Rectangular area) 500 m × 500 m Scenarios 10, 20, 30, 40, and 50
mobile nodes Node speed Randomly choose from 1
to 10 meters/second Node transmission
range 250 m
Bandwidth 11 Mbps
Simulation period 200 seconds
4.2. Simulation Results and Discussion
To evaluate simulation results, we use two metrics: the number of control packets and discovery completion time:
z Number of control packets: The numbers of control packets that are generated by NL-MDS and WGMDS for resource monitoring and discovery.
z Discovery completion time: The time period for resource discovery.
Table 7: Numbers of control packets generated in NL-MDS and WGMDS.
Number of nodes
Number of control packets for NL-MDS (A)
Number of control packets for WGMDS (B)
10 2192 2860 23.4 %
20 18666 20069 7.0 %
30 46831 48685 3.8 %
40 95376 97736 2.4 %
50 153964 157068 2.0 %
B - A B %
To evaluate the number of control packets generated by the two approaches, we conducted simulations in five scenarios: 10, 20, 30, 40, and 50 nodes. In all the scenarios, the nodes moved with the maximum speed of 10 meters/second and minimum speed of 1 meter/second. Table 7 shows the numbers of control packets generated with different number of nodes by NL-MDS and WGMDS. The simulation results show that the number of control packets increases with the increasing number of nodes. As the number of nodes grows, the number of control packets for resource monitoring and discovery increases rapidly. In summary, NL-MDS reduces the number of control packets from 23% to 2% compared
to WGMDS when the number of nodes increases from 10 to 50.
To evaluate the discovery completion time, we also conducted our simulation under the same five scenarios. The simulation results are shown in Figure 8. The discovery completion time increases with the node number for both NL-MDS and WGMDS.
However, the discovery completion time of NL-MDS is on average 50 % lower that of WGMDS.
0 0.5 1 1.5 2 2.5
10 20 30 40 50
Number of nodes
Discovery completion time (sec.) WGMDS
NL-MDS
Figure 8: Discovery completion time of NL-MDS and WGMDS with different number of
nodes.
5. CONCLUSIONS
To adapt to the characteristics of wireless grids, such as frequent update, short-lasting power source, and limited computing capacity, a lightweight distributed model has been proposed for resource monitoring and discovery. The basic idea of NL- MDS is that it embeds resource information in the AODV ad-hoc routing protocol and the data consistency is maintained by using Hello messages.
The merits of the proposed NL-MDS are summarized as follows. First, NL-MDS can decrease the number of control packets generated during the resource monitoring and discovery period. Simulation results have shown that NL-MDS reduces the number of control packets from 23% to 2% compared to WGMDS for nodes from 10 to 50. Second, NL-MDS can reduce the discovery completion time. Simulation results have shown that the discovery completion time of NL-MDS is less than that of WGMDS by about 50%.
6. REFERENCES
[1] Mark Baker, Rajkumar Buyya, and Domenico Laforenza, “Grids and Grid Technologies for Wide-area Distributed Computing,” Software- Practice and Experience, pp. 1437-1466, December 2002.
[2] I. Foster, H. Kishimoto, and A. Savva, “The Open Grid Services Architecture, Version 1.0,”
Global Grid Forum GFD-I.030, January 2005.
[3] K. Czajkowski, S. Fitzgerald, I. Foster, and C.
Kesselman, “Grid Information Services for Distributed Resource Sharing,” in Proceedings of the Tenth IEEE International Symposium on High-Performance Distributed Computing (HPDC-10), pp. 181-194, August 2001.
[4] E. Guttman and C. Perkins, “Service Location Protocol, Version 2,” IETF Request for Comments: 2608, 1999.
[5] Jini Specifications Archive v2.0, Sun Microsystems, 2004, [Online] Available:
http://java.sun.com/products/jini/2_0index.html.
[6] UPnP Device Architecture v 1.0.1, UPnP Forum, 2003, [Online] Available:
http://www.upnp.org/resources/documents/Clea nUPnPDA101-20031202s. pdf.
[7] GT Information Services: Monitoring &
Discovery System (MDS), [Online] Available:
http://www.globus.org/toolkit/mds/.
[8] Liang Cheng, “Service Advertisement and Discovery in Mobile Ad hoc Networks,” ACM 2002 Conference on Computer Supported Cooperative Work (CSCW 2002), pp. 20-23, November 2002.
[9] Wenbin Ma, Baoning Wu, Wei Zhang, and Liang Cheng, “Implementation of a Lightweight Service Advertisement and Discovery Protocol for Mobile Ad hoc Networks,” IEEE Globecom, pp. 1023-1027, December 2003.
[10] Jianghu Yang, Ming Li, Changlai Huang, and Chuanshan Gao, “WGMDS: A WSRF- Compliant Information Service on Wireless Grids,” in Proceeding of the Sixth International Conference on Parallel and Distributed Computing Applications and Technologies (PDCAT'05), pp. 103-105, 2005.
[11] Rajeev Koodli, and Charles E. Perkins,
“Service Discovery in On-Demand Ad Hoc
Networks,” draft-koodli-manet- servicediscovery-00, Internet draft, October
2002.
[12] Charles E. Perkins, and Elizabeth M. Royer,
“Ad-hoc On-Demand Distance Vector Routing,” in Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, pp. 90-100, New Orleans, LA, February 1999.
[13] C. Perkins and E. Belding-Royer, “Ad-hoc On- Demand Distance Vector (AODV) Routing,”
IETF Request for Comments: 3561, October 2003.
[14] USC/ISI, “Network Simulator 2 (NS2),”
[Online] Available:
http://www.isi.edu/nsnam/ns/.
