Locating resources in a programmable networking environment

Computer Networks 50 (2006) 2519–2531 www.elsevier.com/locate/comnet

Locating resources in a programmable networking environment Paul Smith *, Steven Simpson, David Hutchison Computing Department, InfoLab21, Lancaster University, Lancaster LA14WA, United Kingdom Available online 5 June 2006

Abstract Programmable networking is a technology that has been demonstrated to enable the rapid deployment of novel network services. This is achieved through the use of open interfaces that can be used to extend the functionality of a device by third-party service components. Some forms of programmable network allow such components to be deployed out-ofband on a suitable configuration of elements, but do not define mechanisms to determine the configuration. We present a mechanism to resolve arbitrary service-specific deployment constraints into a suitable node configuration. To focus constraint resolution, we arrange programmable elements into an overlay, and use this to interpolate/extrapolate more favourable locations. Programmable service components are used to evaluate the suitability of individual nodes. Ó 2006 Elsevier B.V. All rights reserved. Keywords: Programmable networks; Peer-to-peer systems; Resource discovery

1. Introduction Critical to the successful operation of a network service is the deployment of service components on appropriate network elements. The services supported by a conventional network element are intrinsic to that element and are static. However, services on a programmable element are dynamic and transient. The challenge in a programmable networking environment is to select from a set of general purpose programmable elements a subset that is suitable for deploying a set of service components. When considering programmable service component deployment, two main approaches have been adopted to date: the in-band (or capsule) approach, where computational components are included with *

Corresponding author. E-mail address: [email protected] (P. Smith).

or referenced from within data traffic that is to be augmented [23,22]; or the out-of-band approach, where computational elements are loaded prior to the traffic’s arrival by a third-party process [4,15]. The latter approach requires a process to select the appropriate set of programmable elements to deploy components on, unlike the former, where component deployment is integral to the manner in which the service is executed. In this paper, we are concerned with the out-of-band approach to service deployment. Recently in particular, the peer-to-peer networking paradigm has proved to be a compelling means of implementing large-scale distributed systems. In a peer-to-peer system all entities should be capable of carrying out the same role as each of their peers, essentially conducting both client and server operations. This enables a system to be highly robust to failure and attack, as compromising a single entity only has local effect. Another benefit of such

1389-1286/$ - see front matter Ó 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.comnet.2006.04.023

2520

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

systems, and perhaps the catalyst for their prolific deployment, is the low organisational and financial burdens associated with introducing services. However, these properties typically come at the cost of a more challenging lookup problem in distributed resource sharing scenarios (than in client–server based systems, for example), and quite often inefficient network resource usage. We present a critical part of a service-deployment architecture that enables the identification of programmable entities based upon a set of servicespecific deployment constraints. We propose an architecture that is realised using the peer-to-peer networking paradigm in order to inherit the benefits associated with such systems. We present an algorithm, called GROUPNET, that can be used to construct a mesh between programmable elements that enables us to infer locations to search for superior elements. Programmable service components that encapsulate appropriate search algorithms and service-specific deployment constraints are used to determine suitable node configurations. To enable such components to determine element suitability, programmable elements expose open interfaces that enable the interrogation of local state. In Section 2, we continue with a discussion of issues related to service-deployment constraints. Following that, in Section 3 an overview of the framework we advocate for programmable resource discovery is presented. An introduction to GROUPNET is given in Section 4, demonstrating our group membership algorithm and how to perform searches over it. Entities necessary for determining element suitability are presented in Section 5. In Section 6, we present an example service-deployment scenario and show how our approach can be used. An evaluation showing properties of searching over GROUPNET meshes is shown in Section 7. In Section 8, related work is discussed. Finally, in Section 9 we present the conclusions of our work. 2. Service-deployment constraints Service-specific deployment constraints define suitable configurations of programmable devices on which to deploy service components. Deployment constraints can be described in terms of a number of dimensions plus acceptable values within those dimensions. For example, the network latency between a set of network end-points can be considered a constraint dimension. Acceptable values within such a dimension will prescribe a set of ele-

ments suitable for executing a service (for example, suitable hosts have an application-level round-trip delay below a given threshold). In some cases, values within constraint dimensions can be traded against others in different dimensions. For example, a customer may be willing to pay a particular price in proportion to the Quality of Service (QoS) obtained. Values within some dimensions can change in relation to network topology. For example, a telephone call may cost less when the end-points are geographically nearer. Programmable services that demonstrate these properties are described in [5,17]. Entities that define constraint dimensions and acceptable values include the service user (an organisation or individual user), the programmable network (administrators), and the service itself. We believe that constraints can largely be organised into one of three categories based upon the entities they relate to. These categories can be used to suggest the manner in which acceptable values within dimensions can be resolved. A description of these categories follows: 1. Policy-related constraints: These constraints relate to organisational requirements defined by both the service user and the programmable network administrator. Service users may define policies that focus the set of suitable programmable devices, for example their choice of service provider. Likewise, network administrators may also define policies that relate to, for example, the sets of users that can execute services on their devices. 2. Network-related constraints: For network services to operate correctly, certain networkrelated characteristics must prevail. For example, for a real-time video conferencing application to function correctly, there must be appropriate network bandwidth available between participants. A discussion regarding these and other forms of network-related application requirements is presented in [9]. 3. Device-related constraints: It is probable that a deployed programmable network infrastructure will be heterogeneous. This heterogeneity will relate to both the software and hardware systems in use. An element may intrinsically support a range of software and hardware services, such as available execution environments or network processors, for example. The availability of some resources will be highly transient, for example those of memory and processing.

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

In summary, service-specific deployment constraints have the potential to be complex and arbitrary in nature, covering potentially numerous dimensions and acceptable values within dimensions. They can be defined by multiple entities (or stakeholders) in the programmable service-deployment landscape, that in some cases have potentially conflicting requirements. Therefore, we propose the use of an open resource discovery framework, that enables stakeholders to manage and interrogate resources in a decentralised fashion. 3. A framework for programmable resource discovery As mentioned earlier, perhaps one of the significant catalysts for the large-scale deployment of systems that employ the peer-to-peer networking paradigm is the low financial and organisational burden associated with participation. Furthermore, inclusion in ‘‘community-based’’ programmable networking test-bed initiatives such as PlanetLab [12] places similarly low initiation and maintenance burdens on the contributor. Correspondingly, we propose a framework for programmable resource discovery that employs peer-to-peer network principles and requires the existence of little or no specialised infrastructure support, therefore placing no substantial burden on any single organisation. The framework we propose organises programmable elements into a set of meshed overlay networks. These overlay networks are constructed using the GROUPNET algorithm presented in Section 4. A property of these overlays enables interpolation/extrapolation of improved locations to search. Such overlay networks may span the set of programmable elements controlled by a single organisation, and could potentially peer or combine with others from related organisations. Programmable elements cannot natively understand the nature of potentially arbitrary servicedeployment constraints. As such, they expose interfaces that enable the interrogation of local state information (such as policies and device characteristics) by service-specific discovery components. We envisage constraints that relate to a service will be captured during service development, and be realised in such discovery components. At the point of deployment, user-oriented constraints can be gathered and, along with the discovery components, can be used to determine a suitable configuration of network elements. A more detailed description of this framework follows.

2521

4. GROUPNET: A grouping meshed overlay network To expedite searching, programmable elements are organised into an overlay network that enables us to discover more suitable locations to search. A description of the algorithm we use to achieve this, called GROUPNET, follows. A peer s locally decides its desired degree d, which will influence the number of immediate peers it has. The choice of degree will be influenced by the capabilities of the peer, for example it may relate to the available bandwidth on its network connections. It will maintain N(s), its set of immediate neighbours. Initially, using a bootstrap mechanism, s is assigned a set of peers N(s). The network addresses of the initial N(s) could be published on-line in a similar fashion to [3] or discovered using the Domain Name System (e.g., the domain name bootstrap.groupnet.org could resolve to an appropriate bootstrap node), for example. Peer s now undergoes a sequence of optimisations – in each optimisation, for each peer p in N(s), s obtains measurements to p and N(p), and orders them to produce a list L(p) (which includes p) of those peers in order. The new set of neighbours of s, N 0 (s) will at least consist of the best of each L(p) – if this falls short of d, the best of the union of the remaining members of all the L(p) lists can make up the shortfall. The result is that for each p 2 N(s), (N 0 (p) [ p) \ N 0 (s) is not empty, i.e., there is a path of no more than two hops between s and each of its original neighbours, ensuring that the mesh does not become disconnected. 4.1. Peer membership example Fig. 1 shows an example of a peer wishing to join a mesh and some of the steps toward achieving this. The node s wishes to join the mesh and has selected a degree d of 3. Using a bootstrap mechanism s is assigned {K} as its initial N(s) as shown in step 1 of Fig. 1. The neighbours of K are evaluated along with K itself and the ordered list L(K) is produced. In this example, peers closer to s score higher than those more distant and therefore appear toward the start of the list. From L(K), the best d are taken to produce N 0 (s) as shown in step 2. This completes a single iteration of the GROUPNET membership algorithm. We anticipate a number of iterations would be performed until N 0 (s) does not improve on N(s).

2522

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

Fig. 1. An example peer membership scenario with some of the stages of evaluation shown.

In step 2 of Fig. 1, N 0 (s) = {O, L, K} which improves upon the initial N(s). Another iteration of the membership algorithm involves determining N(p) where p is a peer in N 0 (s) and N(p) are all the neighbours of p (for example N(O) = {K, P}), evaluating them to create L(p) (L(O) = hP, O, Ki), and then selecting the best from each L(p) to generate N00 (s). If we find that we have already selected the best from a list, we simply take the next best as demonstrated in the example. It can be seen that the immediate peers of s draw gradually closer to it. Ultimately, the algorithm should terminate with N(s) = {U, T, Y}. 4.2. Peer evaluation metrics A decision must be made regarding the metrics used to evaluate peers when constructing a GROUPNET mesh. For the purpose of programmable resource discovery, it is probable that the overlay network will have two main roles. These are to enable efficient dissemination of control traffic between programmable elements, and to assist resource discovery (searching) operations. For the purpose of the latter, we envisage that programmable elements will exist in potentially numerous overlays. Based upon application-specific requirements, different overlays could be used to locate programmable elements with properties that relate to the overlay being searched. When considering control traffic distribution, the round-trip delay between hosts is often considered a suitable metric to constrain a structured overlay network [8]. Typically, such traffic has relatively low bandwidth requirements, but requires timely and reliable delivery to its intended recipients.

Suitable metrics that assist programmable resource discovery could include the following. Observed network delay to a set of remote network locations can be critical to the successful operation of a large class of service. For example, consider the problem of selecting a suitable multi-player game server, where deviation in network delay between participating clients and a prospective server must be kept to a minimum to avoid bias. For services such as these, round-trip delay is a suitable metric that can be used to infer the location of suitable elements. There are a number of services, such as those emerging from the Grid community [11], that have significant bandwidth requirements. For services such as these, available network bandwidth between peers could prove a sensible evaluation metric. If the over-provisioning of core networks that exists today prevails, other non-network-centric metrics could prove more valuable. For example, the number of executing services or available resources at an element can be used as a metric. Clustering elements in this manner could be the basis for a form of load balancing. In a market-driven environment, programmable element providers could advertise the use of their devices at competing rates. Grouping elements based upon the cost of a service unit enables configurations to be discovered that meet user requirements regarding this metric. 4.3. Evaluation of the GROUPNET algorithm In [18] we present some of the properties of building overlays in this manner. We conducted simulations where peers were randomly distributed in a two-dimensional coordinate space and the group

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

2523

Random

a

b

c

Fig. 2. Meshes created both randomly and using the GROUPNET algorithm with different node degrees.

membership algorithm was run at each peer. Distance between peers was used as the configuration metric. Peers with a smaller distance score better than those with larger distances. Fig. 2 presents a graphical representation of the meshes produced. Node degrees of 3, 4 and 5 were assigned, shown in Fig. 2a–c respectively. The top line of Fig. 2 (random) shows meshes produced after peers are assigned random neighbours. The bottom line of Fig. 2 (groupnet) show the meshes produced after running the GROUPNET overlay membership algorithm. To optimise the mesh produced, we ran the algorithm 30 times at each node. In Fig. 2 some of the peers in the GROUPNET meshes have node degrees that are not equal to d (the desired degree). This is because as peers attempt to acquire the best d peers at each iteration of the algorithm they will remove less optimal connections in favour of new more optimal ones. Measures to ensure that a peer cannot become disconnected from the mesh are described in [16]. The aim of these simulations was to demonstrate that the membership algorithm produces overlays with desirable properties, in a scalable manner. In [18] we show that for node degrees of 3 and 4, the algorithm selects approximately 90% of the most optimal peers available as its neighbours (its final N(s)). We also demonstrate that there is a correlation between the number of hops travelled on the overlay and the distance covered in the underlying space. This correlation is necessary to conduct the form of searching described in Section 4.4. In terms of scalability of the algorithm, we show that as the total mesh size increases, a peer evaluates an increasingly smaller percentage of the total mesh to discover its position in the overlay. For example,

for a mesh with 6400 members, the algorithm evaluates on average less than 5% of the total mesh for node degrees of 4. We conclude that although the algorithm scales well, intelligent selection of a node’s initial N(s) would be necessary to make the approach workable in practise. 4.4. Searching over GROUPNET To demonstrate how locations to search for programmable resources can be interpolated/ extrapolated using GROUPNET, an example search problem will be presented. Consider a scenario, depicted in Fig. 3, where an overlay exists in a two-dimensional Cartesian coordinate space where the Euclidean distance between peers is used as the evaluation metric, such that closer peers improve upon those further way. Consider how one might find a set of target peers that fall within a threshold in the coordinate space from a given point. In this

node point threshold overlay link Fig. 3. Example searching scenario.

2524

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

scenario, a target set of peers is defined with three parameters: a point p in the coordinate space, a threshold T from p, that peers should fall within, and a timeout. One might imagine in the Internet that p is a known network location (for example, a media server) and T is a measure of round-trip delay. The objective of the search would be to locate all the programmable devices that fall within a certain delay from the server. When carrying out a search, two operations can be performed on another peer: evaluate or spawn. The evaluate operation simulates remotely determining the suitability of another peer, for example by loading evaluation components. Here, evaluation takes the form of a peer calculating its distance from p and returning that value. The spawn operation simulates migrating the search toward a more suitable peer in the overlay. The evaluate and spawn operations are envisaged as being necessary to conduct searches. To conduct the search at a peer, initially, the timeout is checked and if it has expired the search algorithm terminates on that peer. The search then randomly selects a number of other peers n hops away and evaluates them. If the peers just evaluated have larger distances s to p than measured at the current node, a subsequent set of peers are evaluated n/2 hops away. This process is iterated until n = 0, when the search is terminated at that peer. However, if a set of evaluated peers have smaller values of s than measured at the current location, the search algorithm is spawned on those peers. Peers with s < = T are immediately reported after evaluation. The search should migrate (spawn) toward peers with improved values of s and terminate when better values of s cannot be found. 5. Determining element suitability Programmable elements cannot natively understand the deployment constraints of a potentially arbitrary set of transient services. For this reason, we suggest a framework where service-specific discovery components, that encapsulate the functionality to locate suitable element configurations, can interrogate programmable elements using wellknown interfaces. 5.1. Programmable element entities Fig. 4 shows the functional components that must be resident on a programmable element to

User Agent

Constraints Description

Resolution Components

Programmable Element Constraint Processor

Resolution Components

Neighbour State

Element Characteristics Transient Services Software Resources Hardware Resources Policy Database

Fig. 4. Functional suitability.

components

for

determining

element

enable resource discovery. Essentially, the role of these components is to safely represent a device’s characteristics (including administrative policies that define the behaviour of the element), so that third-party components can determine an element’s suitability. Clearly, these components must interact with other sub-systems that are responsible for managing the local resources. The significant components shown in Fig. 4 will now be briefly described. Element characteristics: There must be a means of representing and managing the local characteristics of an element. These characteristics include the intrinsic software services and hardware resources associated with an element. Furthermore, they may also include transient services such as deployed code, either executing or cached on the device. Finally, perhaps most importantly, the local policy information must be made available for interrogation. Constraint processor: The constraint processor takes a constraints description document (a user agent entity), and determines whether the requirements expressed within it can be met by the node. It should be possible for the constraint processor to give a boolean value in response to a constraint description presented to it, indicating success or failure for the element to meet the constraints. Furthermore, for the purposes of con-

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

straint adaptation it should be possible, in the event of failure, for the constraint processor to suggest which clauses in the constraint description the element failed to meet. Neighbour state information: A programmable element will potentially reside in a number of GROUPNET-based overlay networks. It should be possible for resolution components to interrogate an element’s overlay neighbour information. Such information can be used to determine the addresses of potentially more optimal programmable elements on which to execute a service. The availability of some element resources such as memory and processor cycles will be highly transient. The components that represent the element characteristics must interact with sub-systems that control such resources. Approaches to enable finegrained resource management and control are presented in [10,1,21]. 5.2. User agent entities It is envisaged that, associated with a service, a set of components will be made available that enable the discovery of a suitable configuration of elements on which the service can be deployed. These components will encapsulate the logic to resolve the service-deployment constraints of the form presented in Section 2, as imposed by both the service characteristics and the service user. For example, these discovery components would implement the search algorithm presented in Section 4.4. Furthermore, resolution components could be used to discover non-element related values such as the round-trip delay between network points. 5.3. Constraints description This is a format that enables the description of characteristics that are associated with the programmable element. It is used to express the conditions under which the service can execute on a programmable element. It should be possible to describe policy-based and device-related constraints and define a number of distinct options that are acceptable for the execution of the service. A format that can be used to described such constraints is the Component Compatibility Markup Language (CCML) [15]. CCML is an XML (eXtensible Markup Language) derived language for agentdriven content negotiation. In essence, a CCML

2525

document is generated that potentially represents a number of distinct conditions under which a service will execute at an element. These conditions can be selected using local knowledge by a target environment. 6. Service-deployment scenario To demonstrate the applicability of our approach, we will present an example servicedeployment scenario. The service we present in this example aims to reduce the cost of making long distance calls by using the Internet and Voice over IP (VoIP) to make the long distance connection [6]. At the remote end of a connection, a network element with a modem attached to the Public Switched Telephone Network (PSTN) can be used to complete a call to a local receiver, therefore making the total cost of a long distance call at most two local connections: one to connect to the Internet and the other to a local receiver. In our example scenario, the network element with modem functionality is programmable and the aim is to discover from the set of elements available a subset most suited to serve our application demands. By using the Internet to form the long distance part of a connection, one exacerbates the problem of round-trip call delay. However, the greater part the Internet constitutes the connection, the cheaper the cost of the call is likely to be. A balance must be struck between the total cost of the call and the delay experienced. Both parts of a connection contribute to a monetary cost and the total round-trip delay. We can use the function c = cn + cp to calculate the total cost of making the call, where cn is the fixed cost of connecting to the Internet and cp is cost of the call on the PSTN. We use t = tn + tp to determine the total round-trip delay, where tn is the delay across the Internet and tp is the delay across the PSTN. The values of t and c have acceptable upper bounds represented by tmax and cmax respectively. Elements with values greater than tmax and cmax can be immediately dismissed as unacceptable. The product of t and c can be used to select the most appropriate element from the available set. Table 1 shows example values of five candidate elements. If tmax = 100 ms and cmax = 10 p/min we can immediately consider elements 1, 2 and 5 from Table 1 as unsuitable. Elements 3 and 4 meet our constraints and we consider the value of tc to select the most appropriate element; in this case element 4 best meets the service constraints.

2526

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

Table 1 Example costs for a set of candidate elements for deploying a voice over IP service Element

tn

tp

cp

cn

t

c

tc

1 2 3 4 5

20 40 60 80 100

17 14 11 8 5

17 12 6 3 3

3 3 3 3 3

37 54 71 88 105

19 15 9 6 6

703 810 639 528 630

By employing a GROUPNET overlay formed using round-trip delay between elements, a loose correlation between relative location in the overlay and network topology should exist. One would anticipate the cost of the call cp to change in relation to network topology. Therefore, traversing an overlay network formed in this manner should result in a consistent variation in the cost cp. We can use this fact to interpolate/extrapolate better locations for searching. For example, if a direction along the overlay yields elements with a better cp than those already known, searching can continue in that direction in the hope that cp will continue to improve. Other inferences such as these can be made in order to find the set of programmable elements that have acceptable values of c. If such elements are found, tn can be determined, and ultimately tc. 7. Evaluation To evaluate aspects of the effectiveness and scalability of our approach, we have simulated searching over a GROUPNET mesh. To do this we construct meshes in a two-dimensional Cartesian coordinate space using Euclidean distance as the evaluation

metric. We have implemented the algorithm presented in Section 4.4 for searching over a GROUPNET mesh. Recall how a target set of peers is defined using three parameters: a point p in the coordinate space, a threshold T from p, that peers should fall within, and a timeout. 7.1. Scalability of searching To assess the scalability of our search algorithm, we observed the average number of evaluations and spawns. We ran the search algorithm with the following parameters. We exponentially increased the number of peers in the mesh and adjusted the size of the coordinate space to maintain a constant density of peers. The value of T was maintained to yield a statistically constant number of target peers. The initial hop count n was kept at 20% of the mesh size. The algorithm was performed 50 times using each mesh size, with a new p and initial peer to start the search on being selected at each iteration. Spawns and evaluations are relatively expensive operations to perform. For example, programmable service component deployment using funnelWeb [4] involves invoking a load command on a programmable element, fetching the component(s) over HTTP to the element and then instantiating the components. Figs. 5 and 6 present the average number of spawns and the percentage of the total mesh spawned upon. The average number of spawns remains fairly constant in relation to increased topology size. The ability of the search algorithm to scale is best demonstrated in Fig. 6, where the total percent of the mesh spawned upon falls dramatically with the increase in size of the mesh.

21 20 19

Spawns

18 17 16 15 14 13 12 11 100

400

1600

6400

25600

Nodes

Fig. 5. Average number of spawns conducted on different size meshes.

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

2527

12

% Spawned

10 8 6 4 2 0 100

400

1600

6400

25600

Nodes

Fig. 6. Percentage of total mesh size spawned on when searching.

130 120

Evaluations

110 100 90 80 70 60 50 40 30 100

400

1600

6400

25600

Nodes

Fig. 7. Average number of evaluations conducted on different size meshes.

35

% Evaluated

30 25 20 15 10 5 0 100

400

1600

6400

25600

Nodes

Fig. 8. Percentage of total mesh size spawned on when searching.

Fig. 7 presents the average number of evaluations conducted when executing the search algorithm. Again, as with the average number of spawns the number of evaluations remains relatively constant

in relation to increased mesh size. The percentage of the mesh evaluated is presented in Fig. 8. The percentage of the total mesh evaluated falls significantly with increased mesh size.

2528

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

It can be seen from the results presented that the target peers can be converged upon in a manner that scales with large mesh sizes. This is achieved by using a search algorithm that uses the properties of the GROUPNET overlay to infer improved locations to search. 7.2. Searching effectiveness In some cases, there may be a number of programmable elements that can adequately satisfy the deployment constraints associated with a service. One would expect that a service intended to discover suitable element configurations, as proposed here, should be able to discover a large percentage of the total configurations available. That said, it may not be necessary to discover the complete set of configurations, merely those that are discovered within a given time-frame. This may be the case due to a desire to deploy a service rapidly, for example a service that re-routes traffic in light of network failures fits this criterion: the deployment location does not have to be optimal, the objective is rapid service availability. Intuitively however, it can be seen that the longer a search executes, more superior configurations can be potentially discovered. We carried out simulations to demonstrate how this trade-off can be made using the resource discovery framework. To achieve the results presented in Fig. 9, searches were conducted over a simulated mesh over a number of cycles with varying search origins and targets. The threshold was manipulated in order to statistically yield a constant number of target nodes. For each cycle the percentage of the total set of tar-

get nodes found was recorded for each of the timeouts. Finally, the percentage of nodes found for each timeout was calculated. Fig. 9 shows how, by increasing the timeout associated with a search, the accuracy associated with a search can be manipulated. To demonstrate the effectiveness of the algorithm, we note that of the total number of peers to be found, the algorithm located on average 89% of them. It is probable in a real deployment scenario that a search will be alloted a time long enough to discover numerous hosts, and as suitable elements are found they will be immediately reported. The decision can then be taken to deploy components upon the most appropriate elements discovered, based upon service-specific criteria. 8. Related work There are peer-to-peer networking-based solutions that are able to take resource constraints and resolve/route them to the nearest set of peers that meet the constraints. Noteworthy approaches include CANs [13] and Pastry [14]. The design of Content-Addressable Networks (CANs) is focused on the use of a virtual d-dimensional Cartesian coordinate space, which is partitioned into zones that are controlled by peers in the CAN. A peer wishing to join the CAN selects a point in the coordinate space at which it wishes to reside. Each sends a join message to an arbitrary point in the CAN with the desired coordinates. This message is routed over the coordinate space until it reaches a peer that controls the zone occupying that point. The peer that owns the zone partitions it with

90

Percent Found

80 70 60 50 40 30 20 10 0 50

75

100

125

150

175

200

Time(ms)

Fig. 9. Percentage of the total number of nodes discovered for varying timeouts.

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

the new peer, and shares neighbour information. The new peer is now reachable across the CAN and is adjacent to peers with similar coordinates. The multi-dimensional nature of a CAN enables it to be used to locate resources based upon multidimensional constraints. Peers in a Pastry network possess a unique node identifier that is obtained by using a secure hash of its public key. As with CANs, a peer’s identifier dictates its position within the Pastry network. The group membership algorithm used by Pastry enables peers to be located with others that have similar identifiers. Peers in Pastry maintain routing tables containing node identifiers of adjacent peers in the network. These distributed hash table-based systems can be used to identify peers that satisfy resource constraints. Potentially, such approaches could be used to aid searching in conjunction with (or instead of) a GROUPNET-based overlay. However, further research is required to ascertain how suitable such approaches are when used to construct overlays that reflect the characteristics of the underlying network. Also, it is not clear how effective these techniques are in an environment where resource availability is dynamic [2]. The problem of resource discovery and allocation in open service-deployment platforms has been recognised for some time [20]. The XenoServer Open Platform [7] is representative of a new generation of service-deployment platforms. Within the XenoServer framework, the role of representing and querying information regarding programmable elements (called XenoServers) is handled by a XenoServer Information Service (XIS). XenoServers advertise and update their capabilities and available resources in the XIS. Clients can then query this information using an XML format to discover suitable servers on which to execute their services. The notion of Resource Discovery (RD) Systems are introduced that, in conjunction with the XIS, can be used to discover suitable XenoServers. RD Systems are intended to be implemented on a task-specific basis. The joint role of the XIS and RD systems is conceptually similar in nature to the framework presented here. However, here the framework is entirely distributed, in fact XIS functionality is bound to individual elements, and RD systems are realised as components associated with services. In addition, we propose a substrate overlay service to aid searching for suitable elements. It is envisaged

2529

that such a service within the XenoServer framework would be formed on a per-application basis, as part of an RD system. 9. Conclusions We have presented an entirely distributed approach to discovering a set of appropriate programmable elements based upon service-specific deployment constraints. The distributed nature of the approach, we believe, is a key contribution and would enable its deployment without any singularly significant organisational or financial commitment. By using an architecture similar to the one described here, programmable elements locally manage their available resources and policies, allowing them to be interrogated by third-party processes. A major component of the approach to programmable resource discovery described here is a novel overlay construction algorithm (called GROUPNET) that enables inferences to be made regarding superior locations to search for more suitable programmable elements. Early results suggest that this algorithm, with intelligent bootstrapping procedures, should scale well in practice. Here we present an evaluation of searching over GROUPNET meshes. In particular, we investigate how scalable and accurate is a searching algorithm that takes advantage of the properties of a GROUPNET mesh. Our results suggest that a target set of devices can be located in a scalable manner, as only a relatively small region of a large mesh has to be searched. We also show that on average 89% of a total set of target nodes can be discovered using such an algorithm. While this form of searching is potentially not as efficient (both in terms of accuracy and resource utilisation) as, for example, a distributed hash table approach [13,14,19], it should provide a greater degree of flexibility and robustness in light of the dynamically available resources that are likely to be found in a programmable networking environment. As further work, to demonstrate the effectiveness of our approach on a large-scale deployment platform, we propose conducting searches on PlanetLab [12]. We also intend to consider combining metrics for mesh construction and searching on a subset of the available metrics. We believe that in some cases maintaining a mesh that embodies a combination of metrics could have a lower

2530

P. Smith et al. / Computer Networks 50 (2006) 2519–2531

overhead that maintaining a number of single-metric meshes. Acknowledgements This work was carried out under the Alpine project funded by BT Exact Technologies. Paul Smith was supported by a CASE studentship funded by the EPSRC and BTexact Technologies.

[16]

[17]

[18]

References [1] K.G. Anagnostakis, M.W. Hicks, S. Ioannidis, A.D. Keromytis, J.M. Smith, Scalable resource control in active networks, in: Active Networks, Second International Conference, IWAN 2000, Lecture Notes in Computer Science, 1942, Springer, Tokyo, Japan, 2000. [2] H. Balakrishnan, M.F. Kaashoek, D. Karger, R. Morris, I. Stoica, Looking up data in P2P systems, Communications of the ACM 46 (2) (2003) 43–48. [3] P. Francis, Yoid: Extending the Internet Multicast Architecture, Unpublished paper. Available from: April 2000. [4] M. Fry, A. Ghosh, Application level active networking, in: Computer Networks and ISDN Systems, 1998. [5] A. Ghosh, M. Fry, Javaradio: an application level active network, in: Third International Workshop on High Performance Protocols (HIPPARCH ’97), London, June 1997. [6] A. Ghosh, M. Fry, J. Crowcroft, An architecture for application layer routing, in: IWAN 2000, Tokyo, Japan, October 2000. [7] S. Hand, T. Harris, E. Kotsovinos, I. Pratt, Controlling the XenoServer open platform, in: Sixth IEEE Conference on Open Architectures and Network Programming (OPENARCH 2003), San Francisco, CA, April 2003. [8] L. Mathy, R. Canonico, D. Hutchison, An overlay tree building control protocol, in: J. Crowcroft, M. Hoffman (Eds.), 3rd International COST264 Workshop on Networked Group Communication (NGC 2001), Lecture Notes in Computer Science, 2233, Springer, 2001, pp. 78–87. [9] A. Mauthe, D. Hutchison, G. Coulson, S. Namuye, Multimedia group communications: towards new services, Distributed Systems Engineering Journal 3 (3) (1996) 197–210. [10] P. Menage, RCANE: a resource controlled framework for active network services, in: Stefan Covaci (Ed.), Active Networks, First International Working Conference, IWAN’99, Lecture Notes in Computer Science, vol. 1653, Springer, Berlin, Germany, 1999, pp. 25–36. [11] The Particle Physics Data Grid. Available from: . [12] PlanetLab. Available from: . [13] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S Shenker, A scalable content-addressable network, in ACM Sigcomm 2001, August 2001. [14] A. Rowstron, P. Drushcel, Pastry: scalable, distributed object location and routing for large-scale peer-to-peer systems, in: IFIP/ACM Middleware 2001, Heidelberg, Germany, 2001. [15] S. Simpson, M. Banfield, P. Smith, D. Hutchison, Component selection for heterogeneous active networking, in: I.W.

[19]

[20]

[21]

[22]

[23]

Marshall, S. Nettles, N. Wakamiya (Eds.), International Working Conference on Active Networking (IWAN’01), Lecture Notes in Computer Science, vol. 2207, Springer, 2001, pp. 84–100, September/October. P. Smith, Programmable Service Deployment with Peer-toPeer Networks, Ph.D. Thesis, Computing Department, Lancaster University, September 2003. P. Smith, L. Mathy, R. Canonico, D. Hutchison, ALM and ProgNets for v4-to-v6 Multicast Transition, in: IEEE OpenArch 2001 – Short Paper Session ‘‘Ghosts of the Net!’’, Anchorage, Alaska, 2001. P. Smith, S. Simpson, D. Hutchison, Peer-to-peer networking for discovering programmable resources, in: Fourth International Workshop on Networked Group Communication (NGC 2002), Boston, USA, 2002. I. Stocia, R. Morris, D. Karger, M.F. Kaashoek, H. Balakrishnan, Chord: a scalable peer-to-peer lookup service for internet applications, in: ACM SIGCOMM, San Diego, USA, August 2001, pp. 149–160. J.J. Sydir, S. Chatterjee, B. Sabata, Providing end-to-end QoS assurances in CORBA-based system, in: First IEEE International Symposium on Object-Oriented Real-Time Distributed Computing, Kyoto, Japan, April 1998, pp. 53–64. D. Waddington, D. Hutchison, Resource partitioning in general purpose operating systems, experimental results in WindowsNT, Operating Systems Review 33 (4) (1999) 52–74. D. Wetherall, Active network vision and reality: lessons from a capsule-based system, Operating Systems Review 34 (5) (1999) 64–79. D. Wetherall, J. Guttag, D. Tennenhouse, ANTS: network services without the red tape, IEEE Computer 32 (4) (1999) 42–49.

Paul Smith is a research associate within the Computing Department at Lancaster University. He submitted his Ph.D. thesis in the area of programmable networking resource discovery in September 2003, and graduated in 1999 with an honours degree in Computer Science from Lancaster. His research interests include programmable and active networks, peer-to-peer networking, multiparty communication technologies, the application of overlay networks for deploying advanced network services, resilient networking, and cross-layer issues.

Steven Simpson is a research associate in the Computing Department at Lancaster University, where he graduated with an honours degree in 1993 and submitted his Ph.D. thesis in 1998. His networking research interests include programmability, overlays, peer-to-peer, resilience, group communication and management, content delivery and URN resolution.

P. Smith et al. / Computer Networks 50 (2006) 2519–2531 David Hutchison is Director of InfoLab21 and Professor of Computing at Lancaster University and has worked in the areas of computer communications, networking and multimedia systems for more than 20 years. He has completed many UK, European and industry-funded research contracts and published many papers as well as writing and editing books in these and related subject areas. His research interests cover advances in architecture, services and communication protocols for networked multimedia systems, including Quality of Service (QoS) mechanisms, programmable networking and also multimedia content distribution networks.

2531