Active and Programmable Networks: IFIP TC6 7th International Working Conference, IWAN 2005, Sophia Antipolis, France, November 21-23, 2005, Revised ... Networks and Telecommunications)

),

(1)

where ResourceList is a list of the available resources along P along with information about the hosting nodes of the resources. However, such an ill-defined interface is not very functional creating the following issues: • •

The amount of information in ResourceList is proportional to the dimension k of vector P, consuming the end device’s time and resources for filtering. The queried active nodes queried along P will have to generate larger amounts of data than what is actually needed, thus wasting useful network resources.

A better approach is to use a more expressive interface, which allows for more accurate and fine grained description of the information requested: ResourceList FindResources (

, ),

(2)

The FilterSpec parameter corresponds to a filter description that (a) imposes constraints with regard to the type of information requested and (b) permits a metricassisted ranking of the returned information. The objective here is that only a reduced subset of active nodes in ai needs to respond to a query and the amount of information returned is minimised and ranked by relevance to the query. On the other hand very

134

M. Sifalakis, A. Mauthe, and D. Hutchison

often the active resources will be situated close to a specific data path rather than along it, thus necessitating the re-routing of the data path through them in order to perform active processing. This manifests the ability to discover resources that are within an acceptable proximity from to the data path. Moreover, knowing “how far”, in network distance, from the actual data path the specific active resources lie, will allow us to assess the cost of a rerouting decision (number of hops, delay, congestion, etc). As a result it should be possible to support proximity metrics (hop count, path delay, etc) as heuristics to specify the range around a data path D where available active resources should be solicited. This can easily facilitated in the aforementioned interface as part of the FilterSpec parameter. E.g.: ResourceList FindResources (

, FilterSpec (ResDistanceHops() = 5)), Note also that it is possible to facilitate discovery in a “neighbourhood” instead of along a path if P consists of only one entry, the current locus. On another subject information exchange between diverse and potentially noncompatible network transports has to be possible. Although addressing nodes between custom networks might be possible (using some sort of universal naming scheme), direct communication between them will not be feasible without “speaking” a common network transport protocol, or (dynamically) employing a protocol translator or adaptation layer. This condition can easily lead to a deadlock situation if the discovery process has to take place atomically along the complete end-to-path before deploying services (as is the case with other approaches). The SAND architecture needs to be flexible enough to allow the interplay between discovery and deployment steps, so that the discovery process completes “gradually as a path is opened” towards a destination, by deploying appropriate service elements. Although the cost (delay, overhead) of such a process seems high there will often be cases where the feasibility defies the trade-off, thus justifying such a design. In summary: ƒ ƒ ƒ

If the discovery process cannot be completed atomically for P, it should not fail. The service nodes should support query chaining whereby they are able to (recursively) proxy queries across different network transports. The query protocol supported by our architecture must be transport independent.

3 The SAND Architecture SAND2 is an active service that enables an active node to participate in a scalable distributed and dynamic directory-lookup service, storing information about resources, services, policies and access control information (to govern the way the information is used and distributed). Being an active service itself it is generic and does not impose any special requirements on the platforms it is deployed on. The SAND front-end interface is based on LDAP [14], which provides a simple, flexible and lightweight information access mechanism. LDAP allows easy interoperability and cooperation between heavily customised instances of SAND. The standard interface conforms to the one described earlier using two interchangeable APIs. Filter descriptions can be used to optimise a search. From a client perspective SAND is an opaque and ubiquitous service that can be used to discover active resources in the environment. 2

Due to space limitation several details are omitted. A detailed description is available in [13].

SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service

135

Fig. 1. The main concepts in SAND and their organisation in the Network

From the viewpoint of an active node SAND is a peer-based system, which it may join and register its resources with. Each participating node undertakes an “equal” role in the maintenance of the directory and is responsible of responding to client queries on behalf of the whole directory. This makes the service fault-tolerant and more resilient in episodic environments. 3.1 The SAND Framework A SAND node n ∈ S (S the set of all SAND nodes), is any active node that runs the SAND service. Specifically such a node is one that has the following capabilities: ƒ ƒ ƒ ƒ ƒ

Support of join/leave/peering functions in the SAND system and advertise its resources and services through it. Provides the client SAND APIs for answering client requests. Maintains a directory for its active resources, services and management/access policies. Maintenance of (unique) identification information and a set of hash functions to can generate a set of keys. These keys can be used to address the node. Support of an API for integrating information indexing functions and ability to communicate the index information to other SAND nodes.

These capabilities provide a SAND node with 2 very important properties: (a) Identification within the SAND system (and potentially beyond) which makes it discoverable and (b) Accessibility to its directory store for browsing and listing its resource and service information. These properties essentially provide the knowledge of how to reach the SAND system in a network location is and see what resources are available. In SAND, the smallest functional entity is the SAND node. However, the smallest opaque service entity is an “area” A, which refers to a group of SAND nodes coupled in a peering relationship (figure 1): A =

{ ² ni | | i | ≥ 1, ni ∈ S }

(3)

136

M. Sifalakis, A. Mauthe, and D. Hutchison

A SAND node can simultaneously be a member of more than one area, participating in each one of them independently. For an area the following postulates hold: • • • • •

Each node can communicate with every other node in the same area. This implies a uniform network (overlay) transport across the area. The area members cooperate to provide a distributed, externally opaque, directory base that stores information collectively for the whole area. Externally the area is represented by (unique) identification information and there are functions used to generate area-wide IDs from that information. There are common procedures and methods among area members for summarizing the directory stored information and communicating it to other SAND nodes. Area members that are also members of other areas may (individually or collaboratively) volunteer to proxy requests and selectively advertise summary directory information from one area to another. Such nodes are area border nodes (BN). The area border representation can be uni or bi-directional.

It follows, from definition (3), that for i = 1 a single SAND node also constitutes an area. This also complies with the postulates for a SAND node and an area. Some very interesting developments derive from this observation. First of all every SAND node is member of at least one SAND area, the self-area, and therefore it is self sufficient. Seeing it in exactly the other way round, every area can be represented as a node within another area (by means of its BNs). This creates a mirage of locally concentrated resource information about a large number of networks (running in other areas), in a scalable way and therefore hiding complexity from the servicees. If in definition (3) we replace ni with Ai , we can produce the recursive definition of a SAND hyper-area (area of areas – figure 1) Ad, of dimension d. Ad =

{ ² Aid-1 | | i |, | d-1 | ≥ 1 }

(4)

The concept of a hyper-area is very important as it describes the construction of a global SAND service recursively, starting from the basic entity, the SAND node, and using the same primitives and functions, re-occurring at different scales. The concept of an area is of key importance for the SAND service as it promotes scalability by dividing the network into independently configurable clusters, enables network and/or host mobility without impacting the stability and opaqueness of the service, and finally confines the distribution of the directory content. Another abstraction used in SAND is the SAND domain (figure 1). This is used to signify the boundaries of a network administration authority. A domain is nothing more than a set of SAND areas under the same administrative management and in that sense it can serve as a unique common identification attribute for a group of areas. 3.2 SAND, under the Hood The functionality of the service discovery mechanism can be decoupled in two abstract notions: (a) Location of required service and (b) Type of required service. A client must have sufficient flexibility in describing what resources and services it needs and where within the network. On the other hand the server side must be able to locate service points at those network locations and browse the available resources.

SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service

137

DIT organisation in a SAND node

Fig. 2. The SAND Architecture and structure of the DIT in the Directory store

Internally in SAND these aspects are addressed independently by two different, yet complementary, mechanisms perceived as 2 distinct layers. Figure 2 is a block diagram of the SAND architecture in an active node, showing the most important components, their interactions and their relative positions within the architecture. The DHT Layer. DHTs refer to a technology [15] that has become popular because it can provide a sophisticated and scalable (key) lookup facility, based on extensive use of hashes. In SAND we deployed DHTs as a means of looking up SAND entities. The DHT layer accommodates a set of structures that map keys to network transportspecific node addresses; thus providing a generic, abstract and scalable way for identifying, addressing and locating SAND entities, irrespective of network transport. These keys, called s-keys are somewhat different from conventional hash keys (addressed here as h-keys). They derive from, and thus relate to, the identification information of a SAND entity. If an s-key corresponds to a SAND node, a transport address of the node is stored in the key map. If the s-key corresponds to a hyper-area the transport address of one or more DNs are kept in the key map. Different sets of key maps allow a SAND node to partake in more than one area. The concept of an s-key is the fundamental primitive of customisability at this layer. In contrast to h-keys, s-keys are produced from a so called S-function, which combines a hash function H(x) and a “normalisation” function N(x): S (x) = a ⋅ N(x) ⊕ (1 - a) ⋅ H(x),

where 0 ≤ a ≤ 1

(5)

x indicates the network ID of a SAND node or hyper-area (e.g. the network address). The algebraic operation ⊕ determines how the two terms are combined to form the s-key. The coefficient a is the main amortizing factor and expresses the relative weight of the two terms in the generation of the s-key. Essentially, a determines how random or relevant to the network ID the s-key is. This is better realised through the following example: Assume IPv4 based transport, ⊕ to equal arithmetic addition, H(x) a randomising hash function that returns a random number from an IP address, and N(x) a function that masks an IP address to return its /28 netmask. Assuming x represents a continuous subset of IP addresses then in figure 3 graph (a) shows the distribution of the H-term (a = 0), and graph (b) shows the distribution of the N-term (a = 1). If a regression line would be drawn the correlation coefficient r for the

138

M. Sifalakis, A. Mauthe, and D. Hutchison

(b) s-keys for a=1

(a) skeys for a=0

0

10

20

30

40

50

60

0

10

20

(c) s-keys for a=0.3

0

10

20

30

x

30

40

50

60

50

60

x

x

40

(d) s-keys for a=0.75

50

60

0

10

20

30

40

x

Fig. 3. Relationship between s-keys and network address for different values of a

H-term would be close to 0 showing the independence of the h-keys and the corresponding IPs, whereas for the N-term, r is close to 1, showing the dependence on the IP addresses. The graphs in (c, d) show the distribution of the s-keys (S(x)) for various values of a, to imply a stronger (d) or weaker (c) relationship to the IP addresses. Therefore it is possible to customise the representation of s-keys in the DHT layer, in order to include/exclude locality information, and control the number of address resolution steps. This, combined with the flexibility to select a search algorithm allows the customisation of the DHT layer for various environments. The Directory Access Layer. On top of the DHT layer in the SAND system is the directory layer providing access to information about the active resources and services in a SAND node or area, their exact locations and their access permissions. Although it may be possible to integrate this function in the DHT layer, the notalways structured nature of the s-keys constrains the ability to aggregate and perform effective indexing. This creates scalability problems due to the amount of information that needs to be accumulated at the BNs, increasing the memory requirements and the search cost. For this reason a more structured form of identifiers is adopted for this layer, i.e. the ASN.1 object identifiers (OIDs) [16], which lends itself well to directory-based solutions (fast searching, aggregating). As a data model for the resource information the LDAP system [14] has been selected. It builds upon the notion of OIDs, and provides a lightweight, flexible and extensible solution, optimised for fast read operations. In LDAP information is organised in objects and attributes describing those objects. Objects belong to classes defining their type. An extensible schema language describes how to interpret the information related to an object class and perform operations between attribute types. Objects follow a hierarchy (imposed by the OIDs) for efficient searching, called directory information tree (DIT). To improve search performance the scope of a search operation can be limited to specific parts of the DIT through search filters.

SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service

139

In SAND each node maintains its own complete, locally rooted DIT which is partitioned in a number of sectors equal to the number of areas that the SAND node is a member of (figure 2). Each sector represents a sub-tree dedicated to one area, holding specific information related to that area. All sectors converge at the RootDN of the SAND node3 DIT. The sub-tree structure of each sector needs to be shared by all area members and is determined on a per area basis. This sub-tree forms the area virtual DIT and enables the SAND nodes in the area to have a common reference structure for their intra-area communications. Since all members of an area need to have a synchronised view of the virtual DIT structure, we need an exchange mechanism for the area-wide graph along with s-key information depicting the nodes responsible for each part of the DIT. As of version 3 of LDAP, each entity maintains within the directory the so called subschema information that encodes among other things its DIT structure. This enables one to access it through the standard LDAP interface. In SAND the subschema is being extended to include s-key based attributes. The exchange/refresh of the virtual DIT across the whole area is facilitated by sequenced updates to a subset of s-keys in the key-tables. The interfacing of the directory layer with the DHT layer requires the representation of a node in the LDAP data model. Easily a SAND entity (node or area) is described as a SandIdObject in the schema, storing all the node specific information. The DIT structure as well as the information exchange model (push/pull, periodic/immediate) is customisable per area. SAND Information Aggregation and Indexing. Consider the two virtual DIT structures in sector 1 and 2 in figure 2, and a SAND node that has received a query for a Java EE. If not enough information to answer the query is available locally by consulting the virtual DIT map, in case (a) it will propagate the query to node K (or respond with a referral to K). In case (b) though the process would be significantly more expensive as it would have to send the query in parallel to all active nodes, and expect to receive their responses. If however, some index information was available about the actual contents of the area in the above case (b), it would enable the SAND node to know that only L has a Java EE and so answer the query itself or have hints that only node L might have a Java EE and so prune and propagate the query only to L. In either case the amount of consumed resources would be significantly less. SAND considers an optional indexing framework customisable to match different configurations trading-off memory for search efficiency. The Index datasets, which refer to record-sets of indexed data (“hints” depicting where more explicit information can be found) are stored within a node-local directory as directory objects. To a certain degree the effectiveness of the indexing mechanism relies entirely on the ability to produce small and fast searchable datasets. The Index aggregation mechanism, i.e. the process of combining index records in a dataset is a two step operation on a dataset D: (a) collecting index information and (b) reducing it: More important is the Reduce operation which has two types (and therefore two types of aggregation), namely the implicit and the explicit (algebraic) reduction. In implicit aggregation the Reduce operation is defined as the intersection of the indexes in a dataset D: 3

Note the differentiation between a “SAND node” which refers to the hosting device and the “DIT node” which refers to a location in the DIT.

140

M. Sifalakis, A. Mauthe, and D. Hutchison

If D = {I1, I2, … Id},

d

IReduce (D) = ³i Ii

(6)

Practically this means that the reduced index will have as an OID the common prefix of the OIDs of all the indexes in the dataset, and as attributes only the common attributes types among all the indexes in the dataset (an example is given in [13]). On the other hand in explicit aggregation (EReduce) one can define any custom algebraic operation to modify the indexes in a dataset. Practically this may involve combining indexes, replacing an index with another, changing OID type, etc. Occasionally an explicit aggregation operation will simply modify the information in an index so as to make it implicitly reducible. Functions that perform explicit aggregation can be loaded at run-time as dynamic library plugins. Information on how the index can be aggregated with other indexes in a dataset is provided through the eReduce and iReduce attributes of the IndexObject class and may need to be area wide or area specific. Finally for the index exchange one can use the standard LDAP interface as the datasets reside within the directory. However it is more efficient if this process occurs at a lower priority than actual query servicing, and so SAND uses the Common Index Protocol [17], which is a generic mechanism for establishing indexing topologies.

4 Deployment and Operation 4.1 Start Up and Initialisation Once an active node has the SAND framework installed and initialised it will typically try to do one or more of the following (depending on the policy configuration): a)

Generate s-keys from its identification information for every area it participates (defined in the bootstrap configuration). This will involve at least the self-area. b) Build the DHT structures in the bottom layer for every area it is a member of. c) Construct the DIT and populate the directory with local resource information. d) If indexing is enabled, initialise its local index structures, datasets, and plugins. e) Start “beaconing” for the areas it is a member of, so as to announce its existence and invite other nodes to join. f) Start listening for join invitations from other areas. The mechanisms for performing the last two steps are outside of the scope of this work since semantically they are aspects related to self-association mechanisms. 4.2 Join and Leave Operations When a SAND node in listen mode receives a “beacon” about the existence of an area it needs to do the following: (a) decide if it “wants” to join and (b) find out if it is allowed to join. Both are subject to bilateral policies. First there is need for a negotiation/authentication phase, during which a set of preconditions have to be checked. To comply with the overall philosophy, in the current prototype these preconditions are expressed a set of attributes in a JoinInfoObject object, at a fixed location in the DIT. The joining node can contact the beacon node using the standard LDAP interface to query and check the attributes of interest in this object and decide if it complies with its local policies for joining. The beaconing node can optionally do the same.

SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service

141

Once the joining node has decided to proceed it issues a join request at the DHT level, using the standard join method of whatever DHT system is used. At this point it is possible for the area node to reject the join request. If the newcomer completes the join successfully, this means that it has already initialised its DHT layer data structures and has a valid s-key. In order to participate in the SAND area at the directory level, it initially undergoes a quality assessment period during which it operates simply as a replicating node. During this process a supervisor node (typically the one that sent the “invite” beacons) is responsible to “keep an eye” and assess the new member by issuing occasionally requests as a client in order to verify the validity of its contents. After the assessment period is over (decided by the supervising area node), and depending on the area specific configuration, the new member may be assigned responsibility for a specific part of the DIT or remain a replicator. If a node wants to gracefully leave the area, it deregisters its resources from the directory, removes its s-key from the virtual DIT and triggers an update, and finally informs accordingly its peers at the DHT level. Finally, if a node is likely to become a BN or a DN the following actions are taken: ƒ ƒ ƒ

As a BN, it establishes an index topology for the area’s contents Generates and advertises an area s-key so as to respond on behalf of the area, to external requests. As a DN, it builds domain ID information so as to be able to respond to queries originating outside the domain.

4.3 Service Operation When an entity wants to find an active resource it issues a request to its nearest SAND point through the abstract interface described in (2) or otherwise using the standard LDAP interface. The request is then decoupled in three parts: (a) where service must be provided, (b) what service needs to be found, and (c) heuristics for making the request more or less specific. Each of the first two questions essentially produces a part of a unique request identifier: Request ID ≡ location-ID │ resource-ID Location- ID ≡ s-key = S ( location ) Resource- ID ≡ resource OID = ASN.1 (resource) The location-ID (s-key) is resolved in the DHT (bottom) layer of the SAND architecture by contacting the SAND node responsible for the hyper-area and domain that corresponds to that s-key. This node, being part of that location-ID namespace can now produce the correct resource-ID (OID) and perform an internal query for it at the directory level. The resource-ID is looked up in the directory (upper) layer. One can see that for scalability and flexibility the resource-ID has local scope only within the location-ID namespace and therefore is late-bound to an OID only after the locationID has been resolved. If there is not enough information available locally, there should be enough index information so as to know whom to contact next and so a recursion of s-key and OID lookup steps will follow within the hyper-area until the information can be obtained. The search will “halt” either when the information has been found, or if there is not enough information to continue the lookup process.

142

M. Sifalakis, A. Mauthe, and D. Hutchison

At every lookup step of the search process the server side might respond with a referral to a new location where the search should continue or act as a proxy in chain mode and perform the next search on behalf of the servicee.

5 Related Work and Outlook This paper presented the design of a service discovery architecture called SAND. It provides a distributed and dynamic architecture that lends itself well to non-uniform and multi-transport network environments. It enables the discovery of active resources along or alongside a network path or within a given network neighbourhood. The main strengths of SAND are its customisability, and its cluster-based architecture which promotes scalability for different network sizes. So far there has not been much work in the area of active resource discovery in heterogeneous networks. None of the approaches we are aware of considers a resource discovery infrastructure that is independent of, or customizable to diverse network environments. Moreover they have limited flexibility as they restrict the discovery process to be completed “atomically” before service deployment. SAND on the other hand is very flexible since: ƒ ƒ

The discovery process can precede and succeed partial deployment of services. It can facilitate location discovery by using abstract and fuzzy expressions of a network location which can be independent of a specific network transport.

Service discovery mechanisms such as those advocated in [19, 20, 21] are not suitable for the application environments we consider because they are either non-generic for any network, or non-scalable (assume deployment of multicast), or else fairly static (rely on the existence of centralised registries in fixed locations). In [22] the authors consider a more dynamic approach, which enables the discovery of active nodes that are not in the data path. However it relies on other external services such as DNS to map consistently in the domain namespace, the network domain topology, thus assuming that proximity in the network is reflected in the domain names. An approach which has inspired SAND in some aspects, is presented in [23]. The HIGS algorithm combines the discovery and deployment process in one, architecture. In HIGS, SAND could be providing the mechanism for performing the solicitation and summarisation steps. The authors in [24] provide a mechanism for discovering active nodes in close vicinity. Although not a resource discovery mechanism per se, this work can be used in conjunction with SAND as a self-association mechanism for discovering SAND areas and nodes in close range. In [25] the authors devised a sophisticated approach of optimally selecting service points in a network between two end nodes. Although the deployment of composite services in the network is the focus of this work, they do not address the discovery aspect, thus assuming an external mechanism like SAND to provide a number of available service nodes. SAND is currently being implemented and refined. On-going work based on simulation aims to compare the performance of SAND against a fully DHT based solution. Future work will study more extensively the various aspects of unattended creation of

SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service

143

index topologies in order to further improve its customisability. We envision the proposed architecture to provide a sustainable solution for autonomic infrastructures. Acknowledgements. Special thanks to Stefan Schmid (NEC labs, Europe), for the insightful discussions on the topic.

References [1] [2] [3] [4]

[5]

[6]

[7] [8]

[9] [10]

[11]

[12] [13]

[14] [15] [16] [17]

Wakeman, I., Jeffrey, A., Owen, T., Pepper, D.: SafetyNet: A Language-Based Approach to Programmable Networks. Computer Networks and ISDN Systems 36(1) (2001) The Caml Language. Online Reference, INRIA, http://caml.inria.fr/ Wetherall, D.J., Guttag, J., Tennenhouse, T.L.: ANTS: A toolkit for building and dynamically deploying network protocols. Proc. of IEEE Openarch (April 1998) Hicks, M.W., Kaddar, P., Moore, J.T., Gunter, C.A., Nettles, S.: PLAN: A Packet Language for Active Networks. In: Proceedings of the 3rd ACM SIGPLAN International Conference on Functional Programming, pp. 86–93 (1998) Paterson, L., Gottlieb, Y., Hibler, M., Tullmann, P., Lepreau, J., Schwab, S., Dandelkar, H., Purtell, A., Hartman, J.: An OS Interface for Active Routers. IEEE Journal on Selected Areas in Communications 19(3), 473–487 (2001) Merugu, S., Bhattacharjee, S., Zegura, E., Calvert, K.: Bowman: A Node OS for Active Networks. In: Proceedings of IEEE INFOCOMM 2000, Tel Aviv, Israel, March 26-30 (2000) Keller, R., et al.: An Active Router Architecture for Multicast Video Distribution. In: Proc. of IEEE INFOCOM, vol. (3), pp. 1137–1146 (2000) Keller, R., et al.: PromethOS: A dynamically extensible router architecture supporting explicit routing. In: Sterbenz, J.P.G., Takada, O., Tschudin, C.F., Plattner, B. (eds.) IWAN 2002. LNCS, vol. 2546, pp. 20–31. Springer, Heidelberg (2002) Schmid, S., Finney, J., Scott, A.C., Shepherd, W.D.: Component-based Active Network Architecture. In: IEEE Symposium on Computers and Communications (July 2001) Merugu, S., Bhattacharjee, S., Chae, Y., Sanders, M., Calvert, K., Zegura, E.: Bowman and CANEs: Implementation of an Active Network. In: Proc. of 37th Conference on Communication, Control and Computing (September 1999) Bossardt, M., Antik, R.H., Moser, A., Plattner, B.: Chameleon: Realising Automatic Service Composition for Extensible Active Routers. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982. Springer, Heidelberg (2004) Eugene Ng, T.S., Zhang, H.: A Network Positioning System for the Interne. In: USENIX Annual Technical Conference (2004) Sifalakis, M., Mauthe, A., Hutchison, D.: SAND: A Scalable, Distributed and Dynamic Active Networks Directory Service. Technical Report TR-COMP-008-2005, Lancaster University (July 2005) Wahl, M., Howes, T., Kille, S.: Lightweight Directory Access Protocol (v3). RFC 2251 (December 1997) Plaxton, C.G.: On the network complexity of selection. In: Proc. of Annual Symposium on Foundations of Computer Science (October 1989) Abstract Syntax Notation One (ASN.1) and ASN.1 Encoding Rules. ITU-T Rec. X.680–683 and X.690–693 (2002) Allen, J., Mealling, M.: The Architecture of the Common Indexing Protocol (CIP). RFC 2651 (August 1999)

144

M. Sifalakis, A. Mauthe, and D. Hutchison

[18]

Sifalakis, M., Schmid, S., Chart, T., Hutchison, D.: A Generic Active Service Deployment Protocol. In: Proc. of ANTA 2003 (May 2003) Veizades, J., Guttman, E., Perkins, C., Kaplan, S.: Service Location Protocol. RFC 2165 (June 1997) Microsoft corporation. Windows Server 2003 Active Directory (2003) Gulbrandsen, A., Vixie, P., Esibov, L.: A DNS RR for specifying the location of services (DNS SRV). RFC 2782 (February 2000) Karrer, R., Gross, T.: Location Selection for Active Services. Cluster Comp.: Journal of Networks, Software and Applications (March 2002) Haas, R., Droz, P., Stiller, B.: Autonomic service deployment in networks. IBM Systems Journal 42(1), 150–164 (2003) Martin, S., Leduc, G.: Dynamic Neighbourhood Discovery Protocol for Active Overlay Networks. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982. Springer, Heidelberg (2004) Keller, R., et al.: Active Pipes: Service Composition for Programmable Networks. In: Proc. of IEEE MILCOM 2001 (2001)

[19] [20] [21] [22] [23] [24]

[25]

A Programmable Structured Peer-to-Peer Overlay Marius Portmann1, Sébastien Ardon2, and Patrick Sénac2 1

School of Information Technology and Electrical Engineering, University of Queensland, Brisbane QLD 4064, Australia [email protected] 2 DMI / ENSICA 1 place Emile Blouin, 31000 Toulouse, France {sardon,senac}@ensica.fr

Abstract. Structured peer-to-peer (P2P) overlay are scalable, robust and selforganizing in nature, and provide a promising platform for a range of largescale distributed applications. Applications proposed to date utilize a similar key-based routing service but “re-invent the wheel” by deploying their own dedicated structured P2P overlay network. This is highly inefficient and results in a significant duplication of work in terms of development, deployment and maintenance of the overlays. To address this problem, we propose a PROgrammable STructured P2P infrastructure (PROST), which allows the dynamic and incremental deployment of multiple applications over a single structured P2P overlay. In this paper, we outline the PROST architecture and discuss the implementation of our prototype. Keywords: Programmable networks, peer-to-peer.

1 Introduction In recent times, structured peer-to-peer (P2P) overlay networks have attracted a lot of attention in the research community. These systems are also referred to as Distributed Hash Tables (DHT), since Hash Tables are a common service abstraction implemented by structured P2P overlays. All the proposed structured P2P systems (e.g. [1], [2], [3]) share the features of an efficient lookup mechanism, fault-tolerance, scalability and a self-organizing nature. These characteristics make structured P2P systems an ideal building block for a wide range of large-scale distributed applications. All currently proposed applications using structured P2P overlay are tightly integrated with their own implementation of a dedicated structured P2P overlay network. Obviously, this results in an undesirable duplication of effort, and more importantly, this result in a higher cost of operation, in particular in terms of network traffic as every application with its own P2P overlay separately incurs the cost involved in deploying and maintaining it. To address this problem, we present a PROgrammable STructured P2P infrastructure (PROST), an overlay architecture, which allows multiple applications to share a common overlay network. This is achieved by allowing the dynamic and incremental deployment of applications and services onto overlay nodes. Our proposed infrastructure allows P2P applications to be run much more efficiently since the cost for D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 145–155, 2009. © IFIP International Federation for Information Processing 2009

146

M. Portmann, S. Ardon, and P. Sénac

deployment and maintenance of the overlay network is amortized over multiple applications. Finally, the development of new applications is also greatly facilitated by providing developers with a simple API to access the basic services provided by structured P2P systems. The remaining of this paper is organized as follows: Section 2 gives a brief background on structured P2P systems. In Section 3 we introduce PROST, our programmable P2P platform and outline its architecture. Section 4 discusses the dynamic deployment of applications in PROST. In Section 5 we present our proof-of-concept implementation of PROST. Section 6 and 7 discuss remaining challenges and related work, and Section 8 concludes the paper.

2 Structured P2P Overlays – Background Structured P2P overlays have recently gained popularity due to their ability to locate objects in a network very efficiently, with a cost of typically O(log N) messages exchanged, where N is the number of nodes in the overlay. This is in contrast to unstructured P2P systems, where lookup operations are based on flooding messages in the network, resulting in a cost that scales linearly in the number of nodes [20]. At the heart of every structured P2P system is a key-based routing (KBR) mechanism [8]. Every node in the overlay is assigned an identifier or nodeID from a large identifier space, typically 128 or 160 bits. Application-specific objects (files, database records, etc.) are assigned unique identifiers called keys, chosen from the same identifier space. Keys are typically assigned to an object by hashing the name of the object. Based on its key, each object is mapped to a node that is responsible for it, called its root node. The details of how this mapping is done vary for different P2P systems. In Pastry [2] for example, keys are mapped to the node with the closest nodeID. This key-to-node mapping is implemented by the KBR mechanism, through routing of lookup messages to their destination nodes, i.e. the root nodes. To achieve this efficiently, the overlay topology is tightly controlled. Each node has a small routing table with a number of carefully chosen links to peer nodes. Lookup messages are routed to their destination along these overlay links, in typically O(Log N) hops. The key-to-node mapping of the KBR mechanism forms the basis of all structured P2P systems, upon which a range of higher layer services and applications can be implemented. Figure 1 shows a layered model of structured P2P overlays as it was proposed in [8]. The Key-based routing (KBR) layer represents the greatest common denominator for all structured P2P overlay systems. As explained previously, this layer is responsible for routing messages to key’s root nodes. Built on top of it are higher layer communication abstractions, such as Distributed Object Location and Routing (DOLR), Distributed Hash Tables (DHT), and group anycast/multicast (CAST) which essentially provide different communication primitives on which to build applications. Finally, applications reside on the third layer. The applications shown in Figure 1 are distributed storage systems (CFS [7], PAST [12], OceanStore [4]), group communication/multicast systems (Scribe [9], Bayeux [10]), content distribution (Split Stream) [5] and a generic Indirection Infrastructure (I3) [6].

A Programmable Structured Peer-to-Peer Overlay

Layer 3: Applications

Layer 2: Higher Layer Abstractions

CFS

PAST

I3

Scribe

DHT

Split Stream

Bayeux

CAST

Layer 1: KBR

147

Ocean Store

DOLR

Key -based Routing Layer (KBR )

Fig. 1. A Layered Model of Structured P2P Systems

The higher layer abstractions shown at layer 2 of Figure 1 are quite diverse. Future applications will require an even wider range of functionality and service abstractions. This makes the implementation of layer 2 as a static service layer in our view difficult, if not impossible. With PROST, we propose to implement the basic KBR layer as a shared static infrastructure. Layers 2 and 3 are implemented via a programmable layer that allows dynamic and on-demand deployment of applications and services. The following sections describe the PROST architecture of our programmable structured P2P system in more detail.

3 PROST – A Programmable Structured P2P Overlay Even though all current structured P2P systems provide the same basic service of keyto-node mapping via the Key-based routing mechanism, they all export different APIs with slightly different semantics. In order to implement a generic structured P2P infrastructure that is not tied to one particular system, we also need a generic API to access the basic services of structured P2P overlays. Such an API has been proposed by Dabek et al.in [8]. The authors show that the API can easily be implemented by all current structured P2P systems and that it is rich enough to allow the implementation of all current higher layer service abstractions and applications. This makes the API an ideal building block for our proposed infrastructure. User Interface Component Peerlet

User Interface Component Peerlet

Peerlet Manager

Programmable Peer Layer

Key-based Routing Layer (KBR )

Fig. 2. PROST Node Architecture

Peerlet

148

M. Portmann, S. Ardon, and P. Sénac

Figure 2 illustrates the two-tiered architecture of a node in PROST. The KBR layer forms the basis of the infrastructure and is used to map keys onto node. Its API is similar to that proposed in [8]. On top of this KBR layer resides the Programmable Peer Layer, which comprises the functionality of Layers 2 and 3 of Figure 1. Applications and services are deployed in this layer dynamically loaded peerlets. Each of the components is discussed in more detail in the following sections. 3.1 Key-Based Routing Layer The Key-based routing layer forms the base of the PROST infrastructure, and is used to map keys onto nodes. This is implemented via the API’s route() method, which delivers a message to the node responsible for a given key (root node). To enable multiple applications to share a common KBR layer, every message sent over the overlay network needs to include an application identifier (app id), allowing the demultiplexing of messages and their delivery to the appropriate application, i.e. peerlet, similarly to the port number in transport protocols. In addition, the route() API primitive can take a first node ID as a parameter. This mechanism allows the application to bypass the default KBR routing process and specify the first-hop to use when sending a message (useful for some application-level multicast applications). The application identifier and application type parameters are necessary for the correct handling of messages and are therefore included in the header of each message routed by the KBR layer, as shown in Figure 3. The message further contains the destination key of the message as well as a Peerlet Code Locator parameter. This parameter informs the nodes about the mechanism and location for downloading the peerlet code. Applications running over structured peer-to-peer systems can be broadly classified in two categories. The first type of application, which we call end-node applications, only requires the destination or end nodes of the routing path to perform applicationspecific operations. A typical example of end-node application is any application based on the DHT concept, i.e. the storage of {key, values} couples. On the other hand, the second type of application, which we call per-hop applications, involves intermediary nodes in the routing path to perform per-hop operations on “their” messages before they are forwarded. This may include changing the next hop ID (i.e. changing the routing of a message).

dst key

app id

app type

peerlet code locator

application data

Fig. 3. PROST message format

To this end, the API defines a forward() callback method that is invoked at each node that forwards a message. This upcall informs the application that the message M with a key k is about to be forwarded to the node with ID nextHopNode. Examples of applications requiring per-hop treatment are multicast routing [9], [10] application-level multicast infrastructure [9] or result aggregation [11]. For example, in the SCRIBE event notification service [9], nodes requires the underlying key-based routing layer to invoke

A Programmable Structured Peer-to-Peer Overlay

149

its forward upcall in order to build the multicast event dissemination tree on the way from the subscriber to the rendezvous point. PROST uses the binary message parameter application type to differentiate between these two classes of applications, as shown on Figure 3. Note that intercepted messages are only sent to applications with ID matching that of the message. The KBR layer also provides mechanisms that deal with the transient and unreliable nature of individual nodes. The deal with node failure, the KBR layer defines set of replication nodes, called a replica set, for each key. In case a root node is unavailable, the KBR layer is responsible to route a message to one of the available replica nodes. Furthermore, the API’s replicaSet() method gives the application access to the current set of replication nodes, in order to keep the replication nodes synchronized. Finally, the routing tables of peer nodes need to be maintained and updated appropriately in case of node failure, or in case of nodes joining and leaving the overlay. Applications can be informed of such events via the API’s update() callback method. We refer to [8] for a detailed discussion of the API. 3.2 Programmable Peer Layer Above the KBR layer, the programmable peer layer performs all the operations concerning peerlets deployment, execution and termination. As mentioned previously, peerlets are mobile code modules, which are dynamically loaded and installed, similarly to any plug-in architecture. Peerlets implement the actual P2P applications. The Peerlet Manager, shown on Figure 2, is responsible for the loading and instantiation of peerlets. It also enforces the node’s local security and access control policy by controlling and limiting the peerlets’ access to local resources such as CPU, storage and the network. It further provides security by isolating peerlets from the host system to limit the impact of malicious or faulty peerlets. Currently, resource management in PROST is kept to a basic sandbox model, as explained in section 5. We are looking at applying existing research results, e.g. from the active network community to further improve on this. Applications on peer nodes in PROST consist of two components: a peerlet and a user interface component. The peerlets implements the server-component of the application. Again, this functionality can be as simple as a DHT, but it can be arbitrarily complex, depending on the application. The user interface component of an application allows end-users to access the services provided by the peerlets. This is typically a Graphical User Interface, but this is determined by the application and not restricted by our infrastructure. While peerlets can be deployed without a user interface component on a node, user interface components require a peerlet to be deployed on the same node.

4 Dynamic Application Deployment In this section, we discuss how multiple applications can co-exist in PROST and how new applications can be dynamically deployed. 4.1 End-Node Applications As mentioned previously, end-node applications only need to invoke applicationspecific functionality at the destination node of a message in the KBR layer. This is

150

M. Portmann, S. Ardon, and P. Sénac Application (Peerlet)

KBR

Application (Peerlet)

KBR

. . .

KBR

(a) Application (Peerlet)

Application (Peerlet)

KBR

KBR

Application (Peerlet)

. . .

KBR

(b)

Fig. 4. Message flow in End-node (a) and Per-hop Applications (b)

illustrated in Figure 4a. A simple DHT is an example for such an application. The intermediary nodes in the routing path are not involved in the application and simply forward messages to their destination. In a typical scenario, a peer application initiates an operation on another node designated by a key, by invoking the route() method (c.f figure 3). For example a put(key,data) operation in a DHT. This results in the KBR layer to route a message to the root node in charge of the key. In this case, the application type field tells intermediary nodes in the routing path that no application-specific code needs to be invoked and the message is therefore simply forwarded according to the default routing rules of the KBR layer Upon receiving the message, the root node lookup the message application id, and checks if the corresponding peerlet is installed. If this is the case, the message is delivered to the peerlet; otherwise, the node automatically downloads the necessary code from the source specified by the Peerlet Code Locator field in the message. Once the peerlet is loaded and instantiated it is passed the message and it can perform the necessary tasks. 4.2 Per-Hop Applications As mentioned in section 3.1, the second category of applications considered in PROST is per-hop applications, which requires per-hop operations to be performed at the intermediary nodes along the routing path. This is illustrated in Figure 4b. Per-hop applications, in contrast to End-node applications, therefore require the corresponding peerlets to be installed at the intermediary nodes of a message’s routing path. The process of dynamic application deployment is therefore slightly different from the previous case: at every node in the path the application’s peerlet is invoked via the forward() upcall of the KBR layer’s standard interface (c.f. section 3.1). This call passes the message up to the application and allows it to override the standard routing behavior or to perform the application-specific tasks. As in the case of End-node applications, an operation begins with an application invoking the route() method to send a message to the node responsible for a key k. The message is forwarded to the first node in the path to its destination. In this case, the application type field specifies that application-specific functionality needs to be invoked at intermediary nodes. Therefore, the node calls the forward() method of the

A Programmable Structured Peer-to-Peer Overlay

151

peerlet with the specified application identifier. If the corresponding peerlet is not installed, the node’s peerlet manager automatically downloads the code and installs it, in the same way as described in the previous section. Then, the peerlet’s forward() method is called which gives the application the opportunity to perform any per-hop operations. After the forward() method returns, the message is sent to the next node on its path and the process is repeated until it reaches its final destination. 4.3 Application Deployment Policing In a general use case, most nodes will want to control the type and which particular peerlet they run. This can be due to security or legal reason. It is therefore possible that some nodes are not able or not willing to install and run certain peerlets. Note that this problem is irrelevant if we consider the use of PROST in a corporate context, or more generally when a trust relationship exists between nodes and peerlet providers. This problem of non-cooperating nodes is different for per-hop-applications than for end-node applications. PROST requires per-hop applications, to tolerate a certain amount of non-cooperating intermediary nodes and implement a graceful degradation of service. The impact of this limitation on the performance of several existing perhop applications is currently under investigation. On the other hand, the situation where a message’s destination node refuses to install a peerlet is more severe. This problem is treated in PROST in the same way as general node failures are treated in most P2P systems, by means of replication. As briefly discussed in Section 3.1, the KBR layer provides applications with the necessary mechanisms for implementing replication.

5 Implementation We have implemented a proof-of-concept prototype of PROST in Java. The KBR layer of our prototype is based on the implementation of the CHORD [1] protocol from the XML-Store project [21], with a few minor modifications. We replaced the UDP-based RPC mechanism with Java’s Remote Method Invocation (RMI). This increased the code stability and allowed us to easily detect node failures in the CHORD overlay, which was not implemented in the original XML-Store code. The downside of using RMI for inter-node communication in a peer-to-peer overlay is the relatively high overhead. However, the focus of our first proof-of-concept implementation was simplicity and ease of development rather than performance. We also implemented the standard API for structured P2P systems. In addition to the methods defined in [8], we implemented a lookupPeerlet() method. This recursive method takes a message (see Figure 3) and the corresponding parameters and delivers it to the root node responsible for the given key k, in the same way the API’s route() method does it, including the invocation of per-hop-operation if required. In contrast to route(), the lookupPeerlet() method is blocking returns a RMI reference of the peerlet the message was delivered to. With such a reference, peerlets can invoke any application-specific operations on each other, using Remote Method Invocation. For example, in the case of a DHT, the application would simply call the put() and get() methods of the remote peerlet.

152

M. Portmann, S. Ardon, and P. Sénac

Java’s support for mobile code greatly facilitated the implementation of the Programmable Peer Layer. Peerlets are implemented as Java classes implementing the Peerlet interface. The corresponding class files are dynamically loaded by the Peerlet Manager from remote sources via Java’s URLClassLoader. In our implementation, we used a standard web server as a peerlet code server, which can be authenticated and secured using standard methods. We are currently working on implementing the peerlet code server functionality in a distributed fashion as an integral part of PROST. We currently employ two basic methods to protect a node from malicious (or faulty) third party code. Firstly, peerlets executing on a PROST node are contained to a restricted environment, also referred to as a sandbox. The sandbox provides a separate name and address space for each peerlet and limits its access to functionality and resources on the host node. Secondly, PROST supports the concept of code signing, where each peerlet is digitally signed by its producer. When dynamically loading peerlet code, a node can verify its authenticity and the identity of its producer. This allows restricting the loading of peerlets from trusted sources only, depending on a node’s local security policy. To evaluate the design and usability of our infrastructure, we implemented two sample applications: an instant messaging (IM) application and a yellow pages-style service directory that maps service categories to a list of service providers. We successfully deployed and tested these applications simultaneously on a small overlay of 20 nodes on 5 physical machines. Deploying new P2P applications, even on small overlays, is typically a very tedious and costly operation. Application deployment in PROST is relatively easy and involves the following steps: first, a 128-bit application identifier is assigned pseudo-randomly, with a negligibly small probability of a collision. Then, the peerlet code needs to be made available on a code server. An initial peerlet and the corresponding user interface component must be installed manually on one of the overlay nodes. Further deployment of peerlets is done automatically, as described in Section 4. For example, the creation of new service categories in our service directory application results in the automatic deployment of peerlets on the nodes responsible for these categories i.e. the corresponding key. Reliability through replication has not been implemented yet for our two sample applications. This is one of the issues that we will address in our future work.

6 Future Work There are a large number of issues remaining to be addressed in PROST. The first challenge that comes to mind in PROST is the security aspect of the KBR layer, as identified in [16]. These security problems are shared by all structured P2P systems. Some ideas proposed in [17] can be applied in the context of PROST and they provide partial solutions to some of the problems. However, we believe the basis of any security mechanism in P2P overlays are strong and verifiable node identities. We are currently exploring the use of crypto-based IDs [19] for our infrastructure. We are also investigating the use of Threshold Cryptography [18] to implement a distributed admission control mechanism. Secondly, resource management and resource policing aspects in PROST also needs to be further developed. We believe some existing results from the active

A Programmable Structured Peer-to-Peer Overlay

153

network (AN) research can be re-used in this context. Thirdly, there are a number of performance aspects to be investigated, such as quantifying the impact of the larger overlay network on delays and on probability of failure/cache miss. Finally, we plan to develop a range of applications to further evaluate our infrastructure and perform performance measurements on a medium scale deployment of PROST.

7 Related Work The lack of a generic shared infrastructure for structured P2P system has also been identified as a being a problem in [13]. As a solution, the authors propose OpenHash (subsequently re-named OpenDHT), an open, publicly accessible DHT service that runs on a set of infrastructure hosts. It provides applications with the simple put/get interface of a hash table. Applications for which this interface is sufficient are called Lite Applications, and can be directly implemented on top of OpenHash. For the majority of applications for which a simple DHT interface is not adequate, OpenHash serves as a distributed rendezvous mechanism that allows discovery and coordination between nodes implementing the same applications. The actual P2P applications are deployed on arbitrary nodes outside the OpenHash infrastructure. This represents a departure from the pure P2P paradigm that stipulates symmetric roles of all nodes, and is one of the main points in which OpenHash differs from our approach. Finally, OpenHash does not provide a mechanism for the dynamic deployment of application and services. In [8], a standard API for the KBR layer, which is common to all structured P2P systems, is proposed. The authors go further and state their intention to define static APIs for a range of higher layer abstractions (Layer 2 in Figure 1) such as DHTs, DOLR, CAST etc. This is in contrast to our approach, which only defines a static API for the KBR layer, but provides maximum flexibility and ease of deployment for higher layer functionality via a programmable platform. In [3], the authors mention that their structured P2P system has an extensible API and it can be shared by multiple applications. However, the paper does not address the details of this and neither does it provide a mechanism to dynamically deploy new functionality and applications. JXTA [22] is a project that defines a set of protocols and concepts for P2P computing, such as peer and resource discovery, peer communication and peer group management. One of the main point in which JXTA implementations differ from our proposed infrastructure is the way in which messages routing is implemented. JXTA uses an adaptive source-based routing, where routes are initially computed by the sender. This is in contrast to our proposal that specifically focuses on the Key-based routing mechanism of structured P2P systems. Furthermore, JXTA does not provide a mechanism for the dynamic deployment of applications. Finally, the idea of programmable overlay architecture is not new and has been proposed previously by a number of authors [14], [15]. However, to the best of our knowledge, our proposed architecture is the first to apply the idea of programmability in the context of structured P2P overlays to alleviate the overlay applications from maintaining their own dedicated overlay network

154

M. Portmann, S. Ardon, and P. Sénac

8 Conclusions In this paper, we outlined the idea of PROST, a programmable structured P2P platform that allows dynamic deployment of new distributed applications and services. It is built on top of a key-based routing layer that provides a scalable and efficient lookup service. The programmability of our proposed infrastructure is a new concept in the context of structured P2P networks. It allows the basic P2P routing infrastructure to be shared by multiple applications, thereby also sharing the cost of deployment and maintenance, while providing a maximum degree of flexibility to accommodate the requirements of wide range of current and future applications. We believe that the availability of a shared and programmable infrastructure, as proposed in this paper, would greatly encourage and facilitate the innovation and development of new large-scale distributed applications using structured P2P functionality. Our work presented here is in its early stages, and with many unresolved issues. However, we believe our novel approach provides a promising solution that can serve as a versatile platform for a wide range of distributed applications.

References 1. Stoica, I., Morris, R., Lien-Nowell, D., Karger, D.R., Kaashoek, M., Dabek, F., Balakrishnan, H.: Chord: A Scalable P2P Lookup Protocol for Internet Applications. In: ACM SIGCOMM 2001, San Diego, CA (August 2001) 2. Rowstron, A., Druschel, P.: Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In: Guerraoui, R. (ed.) Middleware 2001. LNCS, vol. 2218, p. 329. Springer, Heidelberg (2001) 3. Zhao, B.Y., Huang, L., Stribling, J., Rhea, S.C., Joseph, A.D., Kubiatowicz, J.D.: Tapestry: A Resilient Global-scale Overlay for Service Deployment. IEEE Journal on Selected Areas in Communications (January 2004) 4. Kubiatowicz, J., Bindel, D., Chen, Y., Eaton, P., Geels, D., Gummadi, R., Rhea, S., Weatherspoon, H., Weimer, W., Wells, C., Zhao, B.: OCEANSTORE: An Architecture for Global-Scale Persistent Storage. In: Proceedings of the 9th International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS), Cambridge, MA. ACM, New York (2000) 5. Castro, M., Druschel, P., Kermarrec, A., Nandi, A., Rowstron, A., Singh, A.: Splitstream: High-bandwidth multicast in cooperative environments. In: 19th ACM Symposium on Operating Systems Principles (2003) 6. Stoica, I., Adkins, D., Zhuang, S., Shenker, S., Surana, S.: Internet indirection infrastructure. In: Proceedings of ACM SIGCOMM (August 2002) 7. Dabek, F., et al.: Wide-area cooperative storage with CFS. In: Proceedings of the 18th ACM Symposium on Operating Systems Principles (SOSP 2001), Banff, Canada (October 2001) 8. Dabek, F., et al.: Towards a common API for structured P2P overlays. In: Proceedings of IPTPS 2003, Berkeley, CA (February 2003) 9. Rowstron, A., Kermarrec, A.-M., Castro, M., Druschel, P.: SCRIBE: The design of a large-scale event notification infrastructure. In: Crowcroft, J., Hofmann, M. (eds.) NGC 2001. LNCS, vol. 2233, p. 30. Springer, Heidelberg (2001) 10. Zhuang, S.Q., Zhao, B.Y., Joseph, A.D.: Bayeux: An architecture for scalable and faulttolerant wide-area data dissemination. In: The Proceedings of the 11th ACM/IEEE NOSSDAV, New York (June 2001)

A Programmable Structured Peer-to-Peer Overlay

155

11. Huebsch, R., Hellerstein, J.M., Lanham, N., Thau Loo, B., Shenker, S., Stoica, I.: Querying the Internet with PIER. In: Proceedings of the 9th International Conference on Very Large Data Bases (VLDB 2003), Berlin, Germany, September 9-12 (2003) 12. Druschel, P., Rowstron, A.: PAST: Persistent and anonymous storage in a peer-to-peer networking environment. In: Proceedings of the 8th IEEE Workshop on Hot Topics in Operating Systems (HotOS-VIII) (2001) 13. Karp, B., Ratnasamy, S., Rhea, S., Shenker, S.: Spurring adoption of DHTs with openHash, a public DHT service. In: Voelker, G.M., Shenker, S. (eds.) IPTPS 2004. LNCS, vol. 3279, pp. 195–205. Springer, Heidelberg (2005) 14. Fry, M., Ghosh, A.: Application Level Active Networking. Computer Networks 31(7), 655–667 (1999) 15. Ardon, S., Gunningberg, P., Ismailov, Y., Landfeldt, B., Portmann, M., Seneviratne, A., Thai, B.: Mobile Aware Server Architecture: A distributed proxy architecture for content adaptation. In: Proceedings of The 11th annual Internet Society Conference (INET 2001), Stockholm, Sweden (June 2001) 16. Sit, E., Morris, R.: Security considerations for peer-to-peer distributed hash tables. In: Druschel, P., Kaashoek, M.F., Rowstron, A. (eds.) IPTPS 2002. LNCS, vol. 2429, p. 261. Springer, Heidelberg (2002) 17. Castro, M., Druschel, P., Ganesh, A.J., Rowstron, A., Wallach, D.S.: Secure Routing for Structured Peer-to-Peer Overlay Networks. In: Proceedings of the 5th Symposium on Operating System Design and Implementation (OSDI 2002), Boston, Massachusetts, USA, December 9-11, 2002, USENIX Association (2002) 18. Saxena, N., Tsudik, G., Hyun Yi, J.: Admission Control in Peer-to-peer: Design and Performance Evaluation. In: Proceedings of the 1st ACM Workshop on Security of Ad Hoc and Sensor Networks, Fairfax, Virginia (2003) 19. Montenegro, G., Castelluccia, C.: Crypto-based identifiers (CBIDs): Concepts and applications. ACM Transactions on Information and System Security (TISSEC) 7 (2004) 20. Lv, Q., Cao, P., Cohen, E., Li, K., Shenker, S.: Search and Replication in Unstructured Peer-to-Peer Networks. In: Proceedings of the 16th annual ACM International Conference on Supercomputing (ICS 2002), New York, USA (2002) 21. Thorn, T., Fennestad, M., Baumann, A.: A Distributed, Value-Oriented XML Store, Master’s Thesis IT, University of Copenhagen (2002) 22. Traversat, B., Abdelaziz, M., Duigou, M., Hugly, J., Pouyoul, E., Yeager, B.: Project JXTA Virtual Network Sun Microsystems Inc. (October 28, 2002), http://www.jxta.org

Interpreted Active Packets for Ephemeral State Processing Routers Sylvain Martin and Guy Leduc Research Unit in Networking, Université de Liège, Institut Montefiore B28, 4000 Liège 1, Belgium {martin,leduc}@run.montefiore.ulg.ac.be http://www.run.montefiore.ulg.ac.be/

Abstract. We propose WASP (lightweight and World-friendly Active packets for ephemeral State Processing), a new active platform based on Ephemeral State designed to allow bytecode interpretation on programmable datapath elements. We designed WASP to be a good compromise between flexibility (e.g. offering solutions in quality-adaptive multimedia flows, service discovery or mobility support) and safety (i.e. protection of router and network resource).

1 Introduction and Motivations With the emergence of network processors, the way we design active networks has evolved [14]. Older active platforms like ANTS [1] offer fully-featured environment supporting complex functions like transcoding video flows, redistributing a packet towards a collection of targets, etc. In constrast, SNAP (Safe and Nimble Active Packets from the SwitchWare project[5]) and more recently ESP (Ephemeral State Processing router designed at University of Kentucky [4]) stress that active processing should remain safe and efficient in addition of being flexible (in a word, practical [2]). WASP is an attempt to merge the benefits of these two platforms to offer a better compromise between users and network operators’ expectations about active networking. The WASP router keeps the focus on routing the packets, with the option of performing very simple tasks (e.g. that are “too cheap to measure” compared to packet forwarding) that can help applications in end-system to take better decisions or locally improve flow efficiency. In other words, we can express the constraint we put on WASP design as follows: User-Friendly: WASP should offer significant programmability while allowing the end-user to know to what extent he can trust what he gets from the active network. Network-Friendly: WASP should not become a nuisance to networks (and operators). It should require no configuration from the operator and the network load it produces should be predictable. Router-Friendly: Active packets should not be able to harm a router nor degrade its performance. 

Sylvain Martin is a Research Fellow of the Belgian National Fund for Scientific Research (FNRS). This work has been partially supported by the Belgian Science Policy in the framework of the IAP program (Motion PS/11 project) and by the E-Next European Network of Excellence.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 156–167, 2009. c IFIP International Federation for Information Processing 2009 

Interpreted Active Packets for Ephemeral State Processing Routers

157

1.1 The Need for Speed The speed at which our active platform will be able to process active packets will define the network locations where it can actually be deployed. With the appearance of network processor devices that offer datapath programmability at rates of up to 1Gbps, we may expect a network environment where programmable nodes are not simply endsystems in an overlay but even border routers in a transit domain. A simple active packet crossing an active node will incur different types of timeconsuming operations, among which delivery to the software component that will evaluate it and unmarshalling of high-level language abstractions can be a significant share (up to 42% and 32% of the smallest ANTS capsule respectively, according to [10]) of the total processing time. Considering these results, second-generation active platforms have migrated from the user-level space to kernel level and tend to operate directly on packet data rather than requiring serialization/deserialization between the representation active code uses and the one stored in the packet. Because it is extremely small, the WASP microbytes interpreter can be made safe enough to run with the same privileges as the “fast path” of the router. Moreover, it doesn’t require any marshalling cost as it directly operate on the packet as if it were flat memory rather than trying to assign strong types to data objects. 1.2 How Network Processors Differs from Generic-Purpose Processors We developed the WASP platform with two target platforms in mind: regular PC systems (where it could be for instance running as a Linux kernel module) and routers equipped with network processors, where it is possible to implement efficiently solutions that require custom operations on packets. Network processors typically include a general-purpose processor (for control plane purpose), specialized co-processors (for hashing or trie lookup) and dedicated RISC cores for programmable datapath on a single chip. These chips try to avoid SDRAM lookup latencies1 by providing closer, faster (and smaller) storage for both data and code and often access multiple words in a row. These hardware considerations have an impact on the design we can implement efficiently on such system. In addition, in the Intel IXP family ([9]), each execution unit (called a microengine) has very small instruction memory (2K-4K) whose content cannot be reprogrammed while the microengine is in use. It is thus quite unpractical to implement a platform that would cache native code at the microengine level. Moreover, if one wishes to implement a bytecode interpreter, it will have to be simple enough to fit a few microengines. 1.3 Third-Party Services: An Hybrid Networking Approach Literature on active applications have shown how end-users could benefit from highlevel operations such as hierarchical HTTP caches and multimedia flow transcoding depending on terminal/network abilities. A network operator who is willing to offer such “value-added services” to customers will however face the problem of client-side configuration and service advertisements. In our previous work [8], we have shown 1

According to [6], it will take up to 750 cycles of the IXP1200 microengine.

158

S. Martin and G. Leduc

how the WASP platform could be used to help deploy such services through a fully decentralized, configurationless discovery scheme. The key idea of that service location facility is that, if sufficient WASP nodes are deployed in a network domain, nodes that are willing to offer a given service S simply need to leave information in WASP routers so that, when customers establish a new connection, they can automatically detect whether a given service is available or not and which “proxy” node should be contacted to get the service. In terms of speed improvement, this hybrid approach allows the operator to draw the full power of nodes that hosts services with limited overhead on routers, taking benefits of both componentbased active networks for the services implementation and active packets for services discovery.

2 A Router-Friendly Platform Even if WASP is based on active packets, it is much more restricted than generalpurpose capsules, so that user’s bytecode cannot waste router’s resources. For instance, WASP bytecode language prohibits backward jumps and all instructions have predictable execution time, which makes packet processing time trivial to control (as shown in SNAP [5]). If such a restriction is impractical for general-purpose services, it perfectly fits the lightweight control tasks that WASP will have to perform. While alternative solutions exist, such as associating a counter to any backward jump in the code, we believe the benefit we could get in WASP is not worth the additional management required. 2.1 Memory and Storage Most active protocols will need information to be stored temporarily on intermediate nodes, so that it can be later retrieved by other active packets. For instance, we could drop B frames of an MPEG video stream if the I frame they refer to has been dropped by the node or if it is likely to be dropped, for instance due to a congested output link. This requires I frame to leave information on the router status for further frames. It is important for network availability and performance that this local storage remains easy to manage and can automatically discard information that is no longer pertinent. ANTS [1] and many other platforms use soft-state-based memory management to release memory that has not been used by packets for a given amount of time. Unfortunately, soft-state based managers make it hard for the access control to define if there will be sufficient memory to accept the flow. It has been shown in ESP [4] that memory will be much easier to manage in the ephemeral state approach, that is if the store only keeps data for a constant period (10 seconds), regardless of how frequent the data is referenced during that period. If we also ensure that all the data slots in the store have the same size, collecting freefor-reuse slots becomes simple enough to execute without disturbing packet forwarding tasks on the router, and checking if the router will have sufficient resources to process an additional flow simply requires that the router checks how many different slots are used by the flow. Those small, fixed-size data slots that the node associate with a key

Interpreted Active Packets for Ephemeral State Processing Routers load(@queue_state); test(heavy_loaded_bit); bnz(+1); FORWARD; insert $key; FORWARD;

lookup $key; bundef(+1); DROP; FORWARD; $key=0xdecafbad MPEG DATA (bframe)

B

P

B

159

$key=0xdecafbad MPEG DATA (iframe)

B

I MPEG

stream

frames dependencies

WASP router

Fig. 1. WASP code attached to MPEG I frames and B frames

for a fixed amount of time are called tags in the ESP terminology. Note that no access control is required for tags. It is simply assumed that each source picks up a random 64-bit value and uses it as a key. The chances that two sources randomly pick the same tag and send packets over routes that cross the same router in a 10 seconds timeslice (otherwise no collision occurs) are extremely small. 2.2 A First Example The above decisions may sound excessively restrictive, but the platform we build on it can still be sufficiently expressive. Figure 1 illustrate a WASP implementation of the selective frame filter [12]. The code for I frames checks a bit of the interface state to evaluate the load on the outgoing interface (set by a RED queue manager, for instance) and, depending on the result, leaves (insert) a tag demanding B frames to be dropped. All the B frames depending on a given I frame will carry the same unique identifier (e.g. 0xdecafbad) generated by the source and use it to check (lookup) the presence of the tag in the router’s store. Note that this scheme could easily be extended so that, for instance, a B frame that faces a ‘drop request’ propagates this information backwards to the source. We could also use an I frame code that would compare the local time with the reception time of the last I frame to see if the deadline is still achievable.

3 A Network-Friendly Framework Even if we take care of router resources, an ill-intentioned active packet could easily create an avalanche of clones to overload its destination. Among ‘first generation’ active platforms, PLAN [11] was the only project that addressed this issue by making sure all children’s resource counters receive a portion of the parent’s counter. Unfortunately, knowing what initial bound should be allowed remains a complex issue. In the case of the WASP platform, packets do not have the ability to create child packets unless they are targetted at a multicast address, but they can drop themselves or return to their source. If we focus on applications like service discovery or server load balancing, we have no real need for more: we can store the new destination in the active

160

S. Martin and G. Leduc

packet, return the packet towards its source and let the source issue a new connection attempt to the real destination. In the case of content distribution networks, however, being able to change the destination address could have a great impact on performance, especially if we are allowed to swap a multicast address to unicast addresses. Using this scheme, it becomes possible to take advantage of multicast routing where it is deployed rather than requiring a consistent deployment along the whole path. From the network operator point of view, such rerouting needs to be carefully handled so that it does not lead to packets looping endlessly within a domain or “pingponging” between two domains. For instance, by the action of rerouting, a WASP packet should never require an additional IP table lookup and it may never lead to sending a packet back on the interface it is coming from. The problem of rerouting is further discussed in section 6.

4 The WASP Platform WASP is derived from ESP router[4], which consists of the router logic and Ephemeral State Stores (ESS) containing tags that packets access based on 64-bit keys. As shown on Fig. 2, ESS are either bound to a network interface or to the “center” location, and active packets that cross the router can only request interpretation at 3 logical locations: incoming interface, center and/or outgoing interface. Each ESP packet requests the execution of one of the pre-defined operations on certain tags. Unfortunately, those operations remain tightly bound to a specific application domain (multicast) and non-trivial protocols require almost dedicated operations. The WASP platform thus keeps the overall design of ESP but replaces pre-defined operations by a virtual processor interpreting a bytecode language inspirated by SNAP [5]. We also extended the packet control operations, access control semantics on the tags and access to node-specific state. 4.1 WASP Packets WASP uses the active packets paradigm: each packet contains its own code and the data on which it can operate. The evaluation of packet code (up to 256 bytecoded

eth0 ESS

Ephemeral State Store

center outgoing

store

lookup insert

packet variables

load

VPU incoming

packet header

packet code

environment variables

Fig. 2. A WASP router and WASP execution environment. Gray items mean the VPU has readonly access to the resource.

Interpreted Active Packets for Ephemeral State Processing Routers

161

micro-instructions called microbytes) terminates when a packet control microbyte is encountered, which tells the router what to do with the packet. In addition to “forward” and “drop” semantics, WASP allows the packet to be sent back to the source at any router, which can be useful when a quick feedback of a discovered state is required (e.g. filtering more packets in the router ahead of a congestion point). During interpretation, the data part of the WASP packet is available as a 128 byte region of random-access memory and only the IP header is readable. Other parts (WASP bytecode, other IP options, transport payload) are unavailable to WASP code. 4.2 The WASP Node Each WASP node has a certain number of Ephemeral State Stores that will associate 64-bit keys with small, fixed-size data into tags. Each ESS is associated with a Virtual Processing Unit (VPU) that processes the WASP packets. Since all exchanges between packets occur in the ESS, there is no need to store VPU state between the evaluation of two packets. This greatly simplifies the synchronization problems, even on a multiprocessor system, since it means we can bind VPU data to one real CPU rather than to an ESS. Before a VPU starts evaluating a packet, it retrieves the node and interface environment variables and exports them as banks of read-only memory to WASP code. Those variable will typically contain the node IP address, netmask, local time, etc. plus statistics about the current interface (recent packet transmission statistics, queues status, etc.), which can be useful for applications sensible to network conditions. Considering the restricted resources of network processors, we tried to keep the design of WASP’s virtual processor as simple as possible, which makes it look more like an embedded microcontroller than a modern microprocessor, from an architectural point of view. – Work registers are organized following the ’accumulator and stack’ approach, leading to smaller encoding and better use of hardware registers. – Once the index register has been loaded, any memory reference can either stay on that index or advance to the next word. With an appropriate ordering of data according to code sequence, this may save up to 50% of code size for the ESP instructions involved in data aggregation service [15]. – Only simple ALU and shifting operations are allowed. The VPU has, for instance, no support for floating point values, multiplications/divisions, or signed arithmetic. 4.3 More Efficient Access to ESS Among all microbytes, interactions with the ephemeral state store will be the most important to tune, as they will likely be the most costly operations the VPU will have to handle. It is clear that we’d like to avoid repetitive hashing in a lookup-then-update cycle, for instance. In native implementations, once the hash table has been looked up, resulting memory references are kept for further updates. In WASP VPU, those “resolved pointers” are stored in a cache transparent to the bytecode programmer. We tested two cache policies, small caching, where only the last resolved pointer is kept, and full caching, which keeps every resolved pointers.

162

S. Martin and G. Leduc Table 1. Comparing caching policies. Timings in CPU cycles on 1GHz Pentium III.

count collect rchild rcollect

no caching full small mapping native 721 637 592 586 349 1245 1082 958 842 633 2058 1830 1845 1509 775 2980 2438 2394 2020 1091

Moreover, previous work with ESS-based programmable nodes has shown that nontrivial operations (including rchild and rcollect used for the robust aggregation service) may require 3 or 4 logical variables in the ESS, leading to increased processing cost due to repeated search in the ESS and repeated access to SDRAM. WASP solves these issue by allowing larger values (namely 32 bytes) to be stored in the ESS, and through a map microbytes that makes a whole ESS value appear as a memory bank for the VPU. The packet can then access individual bytes/words of that bank with no extra key resolution until another map forces the bank to be written back in the ESS. Even on the PC implementation, mapping larger memory banks has allowed us to reduce execution time by about 30%, and we expect even higher improvements on IXP architecture thanks to burst transfers with SDRAM. It is also interesting to note that, due to overhead in the ESS entries, allowing 8 times more storage leads to better memory consumption as soon as we have an average of at least 2 related values. 4.4 Preliminary Performance Results To validate our assumptions, we compared the execution time of ESP operations on a Pentium III processor, interpreted by WASP using different access policies, against ESP’s native implementation (see Table 1). Note that the small caching policy behaves better than full caching here. This can be explained by the fact most of ESP operations (as described in [15]) don’t look up for a given variable more than once and that updates can be done before another lookup is issued. The cost for setting up and maintaining a more complex policy such as full caching is thus greater than the benefit one can expect from the cache hit ratio. The mapping scheme is clearly giving even better results once the bytecode has been rewritten to use the map instruction, approaching an execution time of 200 to 150% of the native implementation provided by University of Kentucky. Note that even if interpretation with WASP is twice longer than execution of native code, this represents only a small fraction of the code that is actually executed to process a packet. For instance, on a Linux router running at 300MHz featuring the ESP/WASP module (with small caching policy), the ESP:count packet took an average 69.8µs2 while processing WASP:count took 77.6µs – only a penalty of 10%, compared to 69% suggested by Table 1. Comparatively, the same packets take respectively 23.6µs and 24.3µs to be just forwarded. Moreover, a more complex packet like WASP:collect took 80.0µs for processing and 25.0µs for plain forwarding. Finally, 2

Those timings are obtained using timestamps returned by libpcap on a machine running Linux kernel 2.4.18, which forwards a ping with an average latency of 48µs and takes 99.8µs to reply to a ping.

Interpreted Active Packets for Ephemeral State Processing Routers

163

a WASP packet of the same size as WASP:count that simply contains the forward microbyte took 66.6µs, which means most of the overhead is in packet checking, initializing and finalizing rather than in instructions processing.

5 Trustworthy Storage for the End-User As soon as WASP is used to locate services, packets need to use a well-known key to access information other participants might have left in routers. Such a well-known key can be for instance produced by hashing a service name, which makes them easier to guess from an external attacker than random keys of section 2.1. Therefore WASP introduces protected tags that can only be modified by super packets. If the domain operator ensures that no super packets can come from outside, the end user can be sure that the information bound to the tag has been set up by the domain operator. The node determines whether a tag is protected or not by checking its key against a specific pattern3 , and will allow writes to such tags only to packets that are marked ‘super’ in their WASP header. All a network manager will have to do in this case is (1) filter out WASP super packets at ingress nodes from the outside and (2) use super packets to advertise services within his own network. 5.1 Hash-Requesting Packets and Private Tags When participants and attackers can come from the same domain, protected tags are no longer helpful. For such cases, WASP offers private tags, which works like protocolprivate data in ANTS. Unlike other tags, the application programmer has no direct control on the key that will be used for private tags. Instead, the WASP node will hash the code contained in the packet and use the result as the private key for that packet, which is kept secret by the router. To make sure that regular packets do not attempt to use brute-force scan, private tags have an identifiable prefix and any attempt to use keys with that prefix explicitly will abort packet execution. If the hash method is carefully chosen (e.g. a one-way hash like MD5), it means that packets will have access to the same private space only if they have the same code, which means we are sure they play the same game with same rules. Under those circumstances, an attacker can only hope to break the protocol by sending more (or less) packets than expected by the protocol – which a properly designed protocol should handle anyway. Note that the implementer of a WASP node is free to use any hash method that best suits its hardware as the resulting hashes are used only on the computing node. The only rule is that packets with the same hashed part operate on the same private tag and that packets with different hashed parts operate on different private tags. Note that routers that cannot afford MD5 could be allowed to use cheaper algorithms (e.g. CRC) by mixing the bytecode with a locally-generated random number and still be able to safely assume that protocol’s privacy cannot be broken.

3

Highest 8 bits are all 1 in current implementation.

164

S. Martin and G. Leduc

5.2 World-Readable, Protocol-Writable Tags While private tags guarantee that a collection of participants will modify state in the router following a common set of rules (e.g. the protocol), their cost may not be acceptable for packets that just need to follow the decision without altering the state (e.g. a multimedia stream). Each packet would also have to carry the whole protocol so that it receives the same hash value, regardless of what part of the code is useful for itself. As a result, the expose opcode allows a hash-requesting packet to have its private state accessible read-only as a protected tag. The result is a new ESS tag that contains a link to the private tag, which is transparently resolved by the VPU when a packet tries to read it. Writing to an exposed tag via a link is of course not allowed. Note that the presence of a link only tells that it exposes private data, but not what protocol exposes them. It will thus be up to the protocol designer to ensure that the key used for exposing the data cannot be guessed by an attacker before the link is created. A simple way to achieve this is to generate the key from a random number on the router and inform participants of its value after data has been exposed.

6 Rerouting Packets While considerably augmenting the flexibility of the WASP platform, packet rerouting raises a number of issues for both network operator and end-users. The main concern for the end-user will be to ensure that packets still reach the expected destination, even when re-routing applies. When the sequence of destination addresses to the final target is given explicitly in the packet’s variables, the offered service has the same security semantic as loose source routing in IP. When that sequence is retrieved from ESS, however, we need to ensure that no one is trying to abuse the end-systems to gain an intermediate position on a specific data flow. We are confident that protected/private tags should however help the end-user build reliable rerouting-based applications. From the operator’s point of view, the main difficulty comes from the fact that generally speaking, we do not want to allow any packet to be received from any link. Business agreements with other peer domains, for instance, may only allow a domain A to use link to domain B to reach B’s clients, but not to reach other peer domains or providers of B (see Fig. 3a). Nowadays, most of these agreements are enforced by filtering routes customer to provider relationship

$ Provider to: any

=

$

Provider

peering relationship

regular A to U

$ $

A

Peer

B

=

$

to: X,Y

A fake A to X

$ $

X (a)

Peer

B

=

Y

U

X

v

rerouted A to U

(b)

Fig. 3. Typical interdomain policies for domain A (a), broken by blind rerouting (b)

U

Interpreted Active Packets for Ephemeral State Processing Routers

165

advertised by BGP rather than by filtering packets, but blindly enabling rerouting of WASP packets could lead to situations where a packet leaves A with a destination address falling in one of B’s clients and then reroute itself to another peer domain on B’s ingress router, thus cheating the business model (see Fig. 3b). We propose to solve those problems by means of invitations left in the ESS by former packets. When a WASP packet executes on an interface VPU, it can create a new tag carrying its source address by means of the invite opcode. The binary pattern of the key used with invite tells the VPU that the value can be safely used as a redirection target. Depending on how the interface is configured, the reroute opcode will accept either any target value (e.g. for customers-ingress links) or will be restricted to protected tags and invitations (e.g. for any other link). This way, “ping-ponging” between domains is no longer possible if all egress interfaces restrict rerouting to invited destinations. An invitation to address Y present on the interface means that the peer router for that interface has once sent a packet coming from Y , and thus it should be able to route another packet towards Y properly. We can also prevent cheating on the business model if non-client (guest) packets can leave invitations only on incoming VPU of ingress routers. More precisely, if we make sure that WASP packets from peers and providers are tagged as guest when they reach the center (see Fig. 2) of their ingress router and that invite opcode is not allowed for guest packets, then a packet p received on a non-client ingress interface that is targetted to a client domain can only be delivered to a client domain. By contradiction, suppose V is the first VPU where rerouting changes packet p’s destination towards a non-client destination U . This is only possible if an invitation to U is present in V , however: – if V is on a core router, it cannot have the invitation since guest packets can only leave invitations on their ingress VPU (unless source addresses are spoofed) – if V is on a border router, it implies V is bound to an outgoing interface, say itf, towards domain U . Note that p can only reach that hypothetical interface if itf connects to both clients and non-clients domains (likely to be a configuration error). In Fig. 3, note that B is not protected if A allows blind rerouting on its egress interface to B (we could easily disable blind rerouting on output interface, anyway). If both A and B configure rerouting properly, malicious clients from A cannot lead A to a situation where it unwillingly misroutes packets through B. Note that even if rerouting does not, by itself, allow source spoofing (which is the root of most DDoS attacks [13]), it might disturb tools based on header-hashing for traceback of packets used to react to those attacks. Allowing interoperations between rerouting and traceback might include storing previous destination in a field of the WASP packet or keeping traces of applied rerouting on routers and will be an interesting challenge for future work.

7 Conclusion and Future Work We proposed a new platform that combines safety of ephemeral state processing and flexibility of a bytecode language. While involving strong restrictions on programs one can write, WASP can still address a large range of problems and it can be used as a

166

S. Martin and G. Leduc

“helper” tool for more complex solutions that require a more “applicative layer” approach. Still, for the network operator, WASP is safe and offers strong guarantees on processing time, memory requirements and network link consumption. For the end-user, WASP gives enough programmability for most per-packet control operations. Moreover, WASP is clear concerning what may happen and what may not: the active network will never, for instance, alter source addresses or payloads, nor will it reroute packets if not explicitly requested. It would be interesting to investigate further how the receiver can be given more control on what WASP function can/must be supported by received flows, and whether it could help hosts protect themselves against DDoS, spam, etc. The preliminary benchmarks and the design choices of this platform give us good hope that an implementation on network processors will be able to sustain high throughput of active packets, even if a real implementation on IXP network processor is still required to measure under which proportion of active packets wire speed can be achieved.

Acknowledgment We would like to address special thanks to Jiangbo Li from Kenneth L. Calvert’s team for having so kindly replied to all our questions related to ESP.

References 1. Wetherall, D., Whitaker, A.: ANTS - an Active Node Transfer System. version 2.0, http://www.cs.washington.edu/research/networking/ants/ 2. Moore, J., Nettles, S.: Towards Practical Programmable Packets. In: Proc. of the 20th IEEE INFOCOM, Anchorage, Alaska (April 2001) 3. Nygren, E., Garland, S., Kaashoek, M.: PAN: A High-Performance Active Network Node Supporting Multiple Mobile Code Systems. In: Proc. of IEEE OPENARCH, New York, pp. 78–89 (March 1999) 4. Calvert, K., Griffioen, J., Wen, S.: Lightweight Network Support for Scalable End-to-End Services. In: Proc. of ACM SIGCOMM, Pittsburg, PA, August 2002, pp. 265–278 (2002) 5. Moore, J.T.: Safe and Efficient Active Packets, Technical Report MS-CIS-99-24, University of Pennsylvania (October 1999) 6. Calvert, K., Griffioen, J., Imam, N., Li, J.: Challenges in implementing an ESP service. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982, pp. 3–19. Springer, Heidelberg (2004) 7. Martin, S., Leduc, G.: A Dynamic Neighbourhood Discovery Protocol for Active Overlay Networks. In: Wakamiya, N., Solarski, M., Sterbenz, J.P.G. (eds.) IWAN 2003. LNCS, vol. 2982, pp. 151–162. Springer, Heidelberg (2004) 8. Martin, S., Leduc, G.: An Active Platform as Middleware for Services and Communities Discovery. In: Sunderam, V.S., van Albada, G.D., Sloot, P.M.A., Dongarra, J. (eds.) ICCS 2005. LNCS, vol. 3516, pp. 237–245. Springer, Heidelberg (2005) 9. Intel Corporation The IXP2400 Hardware Reference Manual (November 2003) 10. Wetherall, D.: Active network vision and reality: lessons from a capsule-based system. Operating Systems Review 33, 64–79 (1999) 11. Hicks, M., Kakkar, P., Moore, J.T., Gunter, C.A., Nettles, S.: PLAN: A programming language for active networks. In: Proc. of ACM ICFP 1998, pp. 86–93 (September 1998)

Interpreted Active Packets for Ephemeral State Processing Routers

167

12. Bhattacharjee, S., Calvert, K., Zegura, E.: Technical Report GIT-CC-96/02, On Active Networking and Congestion, Georgia Institute of Technology, ftp://ftp.cc. gatech.edu/pub/coc/tech_reports/1996/GIT-CC-96-02.ps.Z 13. Dübendorfer, T., Bossardt, M., Plattner, B.: Adaptive Distributed Traffic Control Service for DDoS Attack Mitigation. In: Proc. of SSN 2005, Denver, USA (April 2005) 14. Sterbenz, J.P.G.: Intelligence in Future Broadband Networks: Challenges and Opportunities in High-Speed Active Networking. In: Proc. of IEEE IZS 2002, Zürich, pp. 2-1 – 2-7 (Feburary 2002) 15. Calvert, K., et al.: ESP Packet & ESP Instruction Specification, Technical Report. University of Kentucky, http://protocols.netlab.uky.edu/~esp/documents/esp_spec.pdf

A Secure Code Deployment Scheme for Active Networks Le¨ıla Kloul and Amdjed Mokhtari PRiSM, Universit´e de Versailles, 45 av. des Etats-Unis, 78000 Versailles France {kle,amok}@prism.uvsq.fr

Abstract. Active Networking is an innovative technology which can open the network and make it more flexible. But introducing active codes within the network increases the network vulnerability from the security point of view. The security is always considered as a separated layer from the other layers of the active network architecture. In this paper, we develop a global security architecture for a safe code distribution. A three level mechanism is defined to provide a unique identification, authentication, and classification of a code, according to its developer and its users. Index Terms: Active networks, Code distribution and identification, Network security.

1

Introduction

Beside the advantages of opening the network such as introducing quickly a new protocols and applications within the network, injecting a smart program in the network nodes can affect their performance. Moreover, this new task for the routers can deteriorate functions of forwarding packets and increase dramatically the security failures. Usually the security enforcement is operated in active network architectures as an upper layer added at the end of the design process. This enforcement is typically an admission control interface or a simple authentication mechanism based on Public Key Infrastructure (PKI). However, the security layer is not integrated into the lower layers like the code distribution and execution. Our goal is to build a global architecture where the security system is included in the conception of code distribution and execution systems. In our architecture, the security mechanism interacts with all actors which are concerned by the injection of the active programs within the network and their execution. These actors or entities can be identified as the code provider or developer, the code user and the code itself. Because they are external to the network, these three entities push us to define a three level security mechanism which defines a strong and a unique identification, authentication, and classification of the entities. The development of a global security mechanism implies the definition at the same time of a global architecture of code distribution. Both aspects are strongly linked and must be led seriously to implement a secure active network. 

Corresponding author.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 168–181, 2009. c IFIP International Federation for Information Processing 2009 

A Secure Code Deployment Scheme for Active Networks

169

The code distribution is the main key to the introduction and the implantation of the active network in the current Intranet and Internet. Without an appropriate code deployment scheme, in terms of performance (time of downloading, loading and executing the code) and security, the active network stays in state of a project without an effective implementation. We divide the code distribution into two main phases, the code identification and its deployment. Code identification consists in an universal mechanism which gives to the code a unique and non-ambiguous identifier which is independent of its developer and its users and making it easy to share. The code identification has not found yet a normalisation in the active network. Each project defines its own identification method. The code deployment phase consists of the policy to follow which allows the active programs to reach the desired network nodes. The code distribution security enforcement allows the right developer to publish its code, the network to check the safe execution of the new code on the nodes and finally the right user to deploy the code through the network nodes and to execute it. The three poles relation between the code, the developer and the user leads us to define a three poles security architecture. The security function at the developer level must at least check if this developer is authorised to publish its code. The developers of active codes must be authenticated and classified into different groups. The distinction between the groups is based on their relation with the network, nodes resources and the user applications. Different classes can be defined in order to give several levels of grants. The differentiation between the developers creates a set of code categories. Each category of program corresponds to one class of users. The security function at the code level verifies if the active program adheres to the security rules defined by the network. The safety requirements must be related mainly to the resources consumption and data access. Finally, the security function at the user level must allow the nodes to formally verify if the user, through its data packets, has the authorisation to execute the referenced code with few computation and communications. In this article, we define a new approach of code deployment and identification in active networks. Our objective is to provide a secure mechanism which guarantees a unique identification of the code and allows its use by other users in addition to its owner. This approach combines different techniques and is mainly based on the notion of the code server. This server is able to achieve other tasks such as the attribution to each application of a unique identifier, the verification of the conformity of the code, the authentication of code developer and user, and the storage and publication of codes. We study also the security issues to establish the minimum requirements for a secure active network. We propose a new approach which places our code server in the heart of a global architecture interacting with the developer, the code, the user and the node to set up the previous security functions. In the following section, we give an overview of the code distribution in current active networks. Based on the minimal requirements that are fundamental to build a secure active network environment, in Section 3, we define a new

170

L. Kloul and A. Mokhtari

approach for code security and distribution. We investigate the performances of our approach, in terms of throughput and latency, in Section 4. The results obtained are compared with those of the hop by hop technique developed for ANTS platform [15]. The related works are presented in Section 5. Our conclusions and the possible extensions of this work are pointed out in Section 6.

2

Code Distribution Overview

The code distribution consists in injecting active programs in a semi-closed system constituted of the network routers. This operation must provide an homogeneous mechanism of identification of the active programs inside and outside this system. We distinguish between two independent steps in the distribution of the code. The first step is the effective deployment of the new application or the active service in the concerned active nodes. The second is the identification of the code. 2.1

Effective Deployment of Active Code

The main key of active networking is to load dynamically a new code into the network nodes. The way the code reaches the node determines the chosen policy of code deployment in the network. The recent active networks projects fall onto two mechanisms to deploy their code, the capsule based code distribution and the switch based code distribution. Capsule based code distribution: In this approach, the code is transmitted, in band, at the same time as the data; the capsules carry the active code and the data. When an active packet arrives at the active node, this one loads immediately the code part of the packet and executes it using the corresponding execution environment. As the code is loaded in the nodes along the packet path, only the concerned nodes are programmed. Thus this scheme adapts itself dynamically to packets path changes. The inconvenient of this approach is that the presence of the active code in the data packets increases the packet length [4]. Consequently the response time (treatment and propagation time) is sharply increased. And we know that the network protocols are limited in term of packet size. To improve this aspect, a hop by hop based approach has been proposed in [15]. In this technique, a node receiving a capsule which does not contain the active code, extracts the reference of this code and checks its presence in the cache. If the code is in the cache, the node downloads it and executes it on the data. Otherwise, the node requests it from the active node previously visited by the packet (a previous hop address field is updated at each node). This process is repeated hop by hop. Switch based code distribution: This approach is characterised by two distinct phases. The first phase consists of sending, out of band, the active code to all nodes, through the possible data packet paths, generally one potential path for each user session. The second phase is the sending of the data packets. Here, the nodes are pre-programmed, because a code is sent before the data. With this

A Secure Code Deployment Scheme for Active Networks

171

approach, we can expect that unknown and several paths can be taken by user data packets. Thus we cannot know exactly the nodes to pre-program. Both approaches have the following characteristics in common: - An active code cannot be stored indefinitely in the active node. - It is difficult to share the active code. The user must ask for the code from its developer or to develop it himself again and deploy it in the network. - An active node cannot check itself the integrity and the authentication of the received code and its owner. The program verification requires a lot of processor time and memory space and its execution may penalise the node performance. - With the switch based approach we must consider two delays. The time to pre-program the nodes and the session time, i.e. the time to receive the user active data and to execute the corresponding active code. The session time may be small but we may expect the total time to be considerable. Similarly, with the capsule approach (hop by hop), the code downloading time and the session time are mixed. The session time includes the downloading time which may be considerable. 2.2

The Code Identification Issue

Because of the multiple code sources and the multilevel node architecture, a unique and multilevel identification is essential. The code identification must allow the code to be shared and reused by other users. The code identification has not found a normalisation in the active networks yet. Each project defines its own identification method. Currently several projects such as ANTS [16] and Switchware [2] use a three layers based architecture developed in [5]. In this architecture, the identification of the application data is specific to each session user. A data packet must contain the identifier of the active application (AA) and also the identifier of the corresponding execution environment (EE) which is able to interpret the AA. The reference of the EE is given only once by the Active Networks Assigned Number Authority (ANANA). The encapsulation packet ANEP (Active Node Encapsulation Packet), a standard in terms of format of packets, includes a dedicated field of 16 bits length to the EE identifier. At the arrival of a data packet to an active node, this node loads the EE which its identifier is specified in the packet. Once loaded, the EE must then trigger the loading of the corresponding active application. Each EE is basically able to manage several active applications at the same time, to load them in memory and to eliminate them according to user’s needs. This implies that, like the EE, each application must have a unique identifier. However as the identifier of an application is currently defined by its developer and each application can be developed by an independent user, the problem of the multiple identifiers can be inevitable. Indeed, because of the multitude of code sources, their independence and the absence of central regulation authority, situations where two active applications have the same identifier are not impossible. Moreover, as the application identifier is known only by its developer, the code of this application can hardly be shared with the other users.

172

L. Kloul and A. Mokhtari

The identification depends also on deployment techniques. In the capsule based technique, all data packets are active and identifies the couple AA-EE treating it. On the other hand, in the switch based technique, a filter is installed at the NodeOS level which is responsible of recognising the potential passive flows on which to apply the active code. The filter uses packet header information (packet type, source address and/or destination address, . . . ) to orient the packets. In the following section, we present a new approach which integrates code deployment and security. This approach constitutes a response to the problems of identification, verification and sharing of the code. It allows the authentication and authorisation of the entities manipulating this code.

3

A New Security Approach for Code Distribution

The requirements to deploy the code must consider the security at the level of three entities: the code developer, the code user and the code itself. We can summarise the minimal requirements as follows: - A unique developer identification, its authentication, and hierarchical developer rights to publish a code according to the code effect on the network. Moreover, it requires a certificate. - A unique user identification, its authentication, and hierarchical user permissions to execute a code. It also requires a certificate. - A unique code identification, a safety control mechanism and a key as a hash code. To satisfy these security requirements, we define a Code Identification and Storage Server (CISS). To be able to manage our three poles structure, a central authority acting as a code server plays a crucial role in the verification of the code safety and the authentication of both the developer and the user. The CISS associates a unique identifier to an application and places at the disposal of all network users this identifier and its code. With this technique, sharing the code becomes easier, because the user who wants to use an existing code has only to reference it. In our approach we assume that the certificates are delivered by CAAN (Certificate Authority for Active Network). It is an autonomous authority which delivers a certificate based on the PKI (such as X.509). The certificates must contain the public key, information about the holder and its class. Moreover, we consider a publication web site where a user can have knowledge about the existing active applications. This web site allows the visitors to compose their applications by choosing different code modules. The access to this web site takes into account the user rights. Only applications of the same or lower class are showed to the users. We established another security requirement to authenticate all routers, CISS, CAAN and the publication web site server by giving them a certificate or at least a couple of keys.

A Secure Code Deployment Scheme for Active Networks

3.1

173

User and Developer Classification and Authentication

We can expect that most end users will not program network nodes. The code users and the code developers can be different entities. For this reason we differentiate between who publishes the codes and who uses them. We classify the developers and the users into hierarchical classes according to their permissions and the executed code effects on the network. To simplify this model, we consider only two classes. These classes are mainly the user application class and the network application class. A typical example of the first class developer is the Internet Service Provider (ISP) manager and its customers are considered as users in this class. The code of this class can be executed on the user data only. The second class gathers the developers and users who are allowed to operate on the network level and can change the node behaviour by introducing new protocols and routing algorithm codes. This is the case, for example, of the network administrator. Note that each class can be divided onto several subclasses. Thus, node resources access depends on this classification. This distinction is a first fire-wall against malicious codes as it allows a first control of the code execution. It is managed by the CISS during the code publication phase. 3.1.1 The Identification The identification of the developer or the user must allow us to determine exactly to which class he belongs. The CISS requests the certificate from the CAAN. This certificate contains information about the holder (name, address, . . . ), its class and also its public key. The attribution of the developer identifier can be performed by this trust authority. 3.1.2 The Authentication The authentication process is based on the PKI. At the beginning of this process the CISS sends a private information (a simple random text to strengthen the process) to the developer or to the users. When the developer receives this information, it crypts it with his own private key and sends the encrypted information to the CISS. Using the developer public key, the CISS decrypts the received information. If the decrypted information and the original one match then the developer is authenticated. Otherwise, it is another entity acting on behalf the real one. Therefore, the developer or the user is strongly identified and authenticated and cannot deny or repudiate the code sent or execution. Moreover, the untrusted entity which is not identified (does not hold a certificate) cannot send, publish or deploy any code. 3.2

Code Distribution Phases

Our approach consists of three phases as follows: 1. Code publication phase: The application developer sends to the CISS its active code, in order to publish it. This phase is noted by 1 in Fig 1. After verifying the code safety using the Proof-Carrying Code (PCC) technique and authenticating the user certificate with CAAN (exchanging Certificate Check-CC message), the CISS sends an Active Code Identifier (ACI) (2 in Fig 1) to the developer.

174

L. Kloul and A. Mokhtari

PCC technique [13] is used for a secure execution of untrusted code. In our context, the CISS establishes a set of safety rules that guarantee a safe behaviour of programs. According to the developer class, the CISS requires different rules. The rules for user data level code developers are more restrictive than the rules for network level code developers. In the other hand, the code developer creates a formal safety proof that proves the code adherence to the required safety rules. Then, the CISS is able to use a simple and fast proof validation system to check, with certainty, that the proof is valid and hence the code is safe to be executed [13] by the nodes. It is possible to use a heavy code analysis mechanism to check memory use and CPU performed by CISS. If one of those tasks fails, the CISS sends a negative message to the developer. Once the ACI is sent to the developer, the CISS generates a unique key for the code (Kc) to be used when checking if a certain user has the right to execute this code. Once all information about the application service are available, a notification is sent to the publication web site (3 in Fig 1) which generates a web page containing the application identifier and a description of all its modules. 2. Code referencing phase: When a user wants to customise the treatment of the network nodes on its data packets, it connects to the publication web site to choose the application service and notes its ACI (4 Fig 1). With the ACI and its own certificate, the user requests from the CISS (5 Fig 1) the generation of a symmetric key (K) to be able to deploy the code. Once the CISS is sure about the user rights to deploy and execute the code by checking the user certificate (CC message exchanged with CAAN), it generates a key K and sent it to the user. We adapt a distributed symmetric key generation based credential technique, used by [10], in which the key is generated as a combination of the code key, user key, address source, the authorisation time and a validity period. The key is hashed by the CISS and sent to the users. With this technique the active node can verify the user authentication and authorisation without connecting to any third authority, without additional computation, and without holding any further users list. In [10], the code key is generated and shared frequently by authorisation authority and different code servers. To secure this generation, the Kc is now generated by CISS itself as a hash-code signed with CISS private key. This hash-code allows the node to verify at the same time the code integrity and CISS authenticity. The symmetric-key offers good performances because the node does not perform heavy computations or further communications. 3. Code deployment phase: The user sends its packets (6 Fig 1) with the reference of the application service and the generated symmetric-key K through the network. The node receiving such packets and holding the code referenced and its corresponding key (code key), reconstitutes a symmetric-key K’ using the code key sent by CISS, the user key, the source address, the session time and the validity period sent by the user. In the case where the node does not hold the referenced code and its code key, it must send a demand of code (7 Fig 1) to the CISS. Consequently, the CISS provides the node with the desired code and key (8 Fig 1). If both code keys match, the node can execute the code on the user data.

A Secure Code Deployment Scheme for Active Networks

175

Fig. 1. Active code distribution phases

This approach can be considered as an intermediate between the integrated and discrete approaches. Indeed the active code is downloaded out of band (discrete approach) from a certain server. The data packets (at least the first ones) arrive at the nodes before the code and can reference an inexistent code in the node cache (integrated approach). This method solves the problem of multiple paths that may be taken by the packets of the same application, which is a characteristic of IP networks. It allows also the node to not keep a code indefinitely because the codes are always retrieved from the CISS. It is important to note that, using an event based system, it is easy to consider the arrival of standard packets as an event and to treat them as an active. 3.3

The Multi-CISS Approach

The solution with one code server can present a major drawback, the CISS can become the bottleneck of the network. Indeed, it can be congested if a lot of nodes send requests at the same time. One approach to avoid the congestion of the CISS is to add other CISS servers in appropriate places in the network. The first step performed when a passive node becomes active is to detect all CISS present in its neighbourhood. Based on the RTT (Round Trip Time) counted from the set of CISS responses, the new active node orders its CISS neighbours according to their distance. When the search of a code is needed (the active code is not available in the active node), the node requests it from the first CISS in the list of CISSs. This one responds with a negative message or the active node does not receive a message after a notified RTT from this server, the active node sends a new request to the second CISS. This process is repeated for the other CISSs until the active node receives the appropriate active modules. To avoid the saturation of the network by multiple code packets sent by the CISSs, the active node which wants an active module can begin a negotiation protocol by sending, at first, a request for code message or notification of code

176

L. Kloul and A. Mokhtari

existence to the set of CISS. Each CISS able to satisfy the code request sends to the active node an equivalent Ack packet, otherwise, it sends an equivalent Nack packet. When the current node receives an Ack packets, it can send to the chosen CISS, and only one, a downloading request. At this time a CISS receiving the downloading request message sends to the node the code. We assume that negotiation protocol messages are small packets and their transfer in the underlying network is as fast as ‘syn’ messages. The next section presents another approach which is a mixed solution between CISS and hop by hop approaches. 3.4

The Mixed Approach

We expect that the CISS will be placed in the edge of the global network, in the sub-domains. For the nodes close to CISS servers (belonging to the same domain), the number of the routers separating them is very small and the RTT is also small. However, for the node in the other domain the path to CISS is longer and downloading the code from a nearest node is suitable. The CISS approach evolve easily with other techniques and can be combined with hop by hop scheme for its connectless and flexibility. In this combination CISS plays its classic role of attributing and saving the active codes and also has the role of the first and permanent source of codes. In this case we can consider either one or several CISS. The hop by hop code migration intervenes to reduce the load on the CISS and also to improve the code transfer time by choosing the nearest source. Moreover, the combination may be an alternative in the case where an active node cannot receive a code or receives a negative response from CISS. This can be due to, for example, one of the following reasons: the CISS is congested, the link is temporary broken or bottlenecked, the server is off or does not have the right code in the case of several CISS managing a distributed code base. Using this approach requires two steps which must be followed and the distinction between the first active node and the other nodes. 1. Code injection: this is the first time the user sends its data packets with references to the code, to the first attached active node. At this moment, the “previous hop” field of the data packets is empty. This first node is the first visited node and must download the code and the corresponding key (Kc) from the CISS if the active code is missing. Before forwarding the data packets, this active node puts its address in previous hop field. 2. Code migration: the next active nodes visited by the data packets look for previous hop field which determines the new source of the code, and the code request must be sent to the previous node. However, the other nodes must use this same code migration technique to find the code and will have to ask the CISS for the code only in the error case. The previous hop field should be updated at each node. When receiving the code and its key from the previous node, the current node can also perform the symmetric key verification to authorise the code execution. With this technique, the CISS is requested only once for all the data session.

A Secure Code Deployment Scheme for Active Networks

4

177

Performance Analysis

In this section, we are interested in the performance evaluation of the code deployment techniques presented previously. We compare the two approaches single CISS and multi-CISS that we developed for our platform ARFANet (Active Rule Framework for Active Networks) [3] and the approach hop by hop. We are interested particularly in the throughput of the network for the active packets and end-to-end latency for this type of packets. The considered topology of the network is composed of one CISS, three active nodes and three passive nodes. In the case of the multi-CISS approach, a second CISS is added to this topology. We varied the arrival rate of the packets to this network from 250 packets/s to 4500 packets/s for a size of the packets of 200 bytes. According to our analysis of the impact of the active packets introduction into a network on the standard packets, several proportions of active packets were considered [9]. This work showed that the proportion K = 20% of active applications does not deteriorate the active nodes performances with respect to the standard packets. Also, in this study, we retained the same proportion of active packets. This proportion includes the packets of data, programs as well as the code requests packets sent to the CISS. The data packets sent in the network can reference four different types of applications. These applications are published on the server for the CISS approaches and are provided by the source node for the hop by hop approach. Our tests were performed on Linux machines with a processor ”AMD Athlon(tm) XP 1500+” of 1339 MHz, 256 KB of cache memory and a 256Mo read-write memory. 4.1

The Throughput

Figure 2(a) shows the throughput of the network for the active packets according to the total arrival rate of the packets (active and passive) for the three techniques. These results show that although the throughput of the single CISS technique is slightly higher than the throughput of the technique hop by hop, both throughputs remain very similar. We can note that both throughputs are stabilised at 8500 active packets/s from a high arrival rate (2000 packets/s). It is interesting to note these results because the proportion of active packets arriving at the network is only of 20% i.e. 400 active packets/s when the total arrival rate is 2000 packets/s. This high throughput compared to the real arrival rate of the active packets is due to the fact that the first data packets of an application arriving at a node will have to wait until the node receives the corresponding code from the CISS (single CISS ) or from the previous node (hop by hop). Once the code received, an immediate processing is carried out on the data packets accumulated in the queue causing a successive sending of the treated packets towards the following node. This phenomenon is repeated for all the active nodes forwarding the packets, leading to a throughput which is much higher than the arrival rate. Consequently, along way of the data, the rhythm of migration of the active packets does not respect necessarily the rhythm of the source.

178

L. Kloul and A. Mokhtari Packet Throughput

Packet Latency

9000

450 One CISS Hop by Hop Several CISS Mixed

8000

400

7000

350

6000 300 Latency (ms)

Packet Throughput (packets/s)

One CISS Hop by Hop Several CISS Mixed

5000 4000

250

200 3000 150

2000

100

1000 0

50 0

500

1000

1500

2000

2500

3000

3500

4000

4500

500

1000

Packet rate (packets/s)

1500

2000

2500

3000

3500

4000

4500

Packet rate (packets/s)

(a) Throughput

(b) The latency Fig. 2. Numerical results

In addition, we observe that the throughput obtained with the multi-CISS approach is significantly lower than those obtained with the two previous approaches, in particular the single CISS approach. This is due to the presence of an additional CISS in this approach. This additional server allows decreasing the load from the first CISS and absorbing the part of the requests for codes sent from the nodes in its immediate neighbourhood. However, the first data packets of an application arriving at a node will wait the arrival of the code to the node less longer than in the single CISS approach. The packets will tend to less accumulate in the queues of the nodes. Thus the throughput is less significant than in the other approaches, although it is still higher than the arrival rate. The difference between the throughput of the network for the active packets and the arrival rate of this type of packets remains less significant than for for the other approaches. For an arrival rate of 400 active packets/s, the throughput is of 800 packets/, i.e. ten times lower than in the single CISS approach. We can note, when the arrival rate increases, the throughput increases too until reaching 5000 packets/s for a total arrival rate of 4500 packets/s (900 active packets/s). As conclusion, the more the arrival rate increases, the more both CISS are requested and the more the data packets wait in the nodes. 4.2

The Latency

In this section, we investigate the end-to-end latency experienced by the active packets for the three approaches. In Figure 2(b), although the nodes must request the code from the CISS which can be some routers away, the latency of the active packets is better in the single CISS approach than in the hop by hop approach. That can be explained by the fact that the active nodes in the second technique have to manage also the code requests emanating from other nodes. This additional task has an impact on latency. This figure shows also that the introduction of an additional CISS (muti-CISS approach) allows us to improve the end-to-end latency of active packets. As explained previously for the throughput, the second CISS takes in charge a part of the code requests, those coming from the active nodes in its neighbourhood. Clearly the management of the codes by

A Secure Code Deployment Scheme for Active Networks

179

one or more dedicated entities allows us to have better performances than when this task is achieved by the nodes themselves.

5

Related Work

Beyond the two main techniques, integrated and discrete, there are few works in the code distribution area. We can divide the current contributions into two main categories according to the use or not of a code server. The first category gathers the works in which a code server is used for an out-band code deployment (discrete approach). The fist technique introducing the code server notion for the storage and the publication of active programs is DAN (Distributed Code Caching for Active Networks) [6], which has been proposed for high performance active routers. Nevertheless, this work is neither motivated by a universal active code identification nor by proposing safety and security verification mechanisms. Future Active IP Networks project (FAIN) [11] is a component based approach. The components are stored in a code server and compose a service. The service is identified as a concatenation of the service provider name and the service name. Note that with this identification method the service stays strongly linked to his provider which must guarantee the service name unicity. The user data are oriented to the corresponding service by a channel installed at the NodeOS level without the need of the service reference. This manner limits service users to whom belonging to the service provider customers. The main difference between our code distribution system and FAIN is that this approach is dedicated to component based architecture rather than packet based one. Code Distribution Scheme for active networks (CDS), proposed in [17], is a set of recommendations for the design of Code Distribution Protocol (CDP). The authors recommend out-band code transport rather than in-band transport arguing on the large capsule size. They suggest also the store of AA with its code using the code server. Considering naming and name resolution method of an AA as a basic function of a CDP, the authors suggest that the name of an AA should be universal. The projects of the second category consider mainly in-band code deployment. The basic idea is the use of a unique key [15] hold by the code developer and provided by a trust certificate authority to create a unique reference. With the key, the developer defines a one way MD5 hash code with 128 bits length on code content. This approach can be useful in order to limit the number of code developers authorised to deploy their codes in the network. However, this approach makes hard the share and the re-use of the code by other users because the code reference is strongly linked to the code and its owner. The security must rely on how the code is distributed and the elements which take part in the process of injecting the code into the network (the developer and the user). Several works, prompted by the security working group [7], are leaning towards secure execution rather than secure deployment. Projects like SANE [1] and SANTS [12] provide a secure framework for active nodes. Another technique

180

L. Kloul and A. Mokhtari

adopts a different method to secure the execution of the code by restrictive active languages like PLAN [8] and SafetyNet [14]. ROSA [10] defines a user authorisation scheme based on the symmetric-key generation. The generated key corresponds to a key related to the code itself, shared between the code server and the authentication authority, and the session time and duration. The task cannot be performed only if the user has the grant to deploy the code. However, ROSA does not define identification and publication mechanisms and does not secure the developer side. We have adapted and improved this technique to be a part of our global security scheme.

6

Conclusion

The processes of code identification and deployment define respectively how the code is identified by the different entities of the network (nodes and users) and how it reaches the nodes. In this paper, we developed a new approach based on the classification of the developers and the users according to their rights in the network. Two mains categories can be distinguished. The first one can be the application level related particularly to the user data. The second category concerns the network level which is more restrictive and reserved to the network manager. We developed also a new mechanism for active code distribution based on the use of a code server (CISS) which is the central point of a three poles security architecture. The CISS attributes a unique identifier and checks the developer grants and code safety before its publication. Moreover, this server allows the user authentication and authorisation by the generation of a symmetric-key which involves the code key, the user key and a valid session time. This technique avoids to the nodes to perform a hard task of verification which arises a lots of computations and communications. The CISS mixes the advantages of the two approaches of code distribution, the approach based on the pre-programming of certain active nodes and the hop by hop which uses capsules of code. We compared CISS performances to the hop by hop performances, in terms of latency and throughput. The results obtained showed that the use of the code server gives better performances. Although our approach was applied in the context of our framework ARFANet [3], it can be used for any kind of active applications and in other existing platforms. The use of a Publication web site allows an easy access to all published application and their composition. An extension to this work would consist in analysing the different management techniques for distributed databases for a possible application within the case of several and distributed CISS maintaining an harmonious and reliable security protocol. In particular, we are interested in the number of CISS, their location in the network and the distributed code base management.

A Secure Code Deployment Scheme for Active Networks

181

References [1] Alexander, D., Arbaugh, W., Keromytis, A., Smith, J.: Safety and security of programmable network infrastructures (1998) [2] Alexander, D.S., Arbaugh, W.A., Hicks, M., Kakkar, P., Keromytis, A.D., Moore, J.T., Gunter, C.A., Nettles, S., Smith, J.M.: The switchware active network architecture. Departement of Computer and Information Science University of Pennsylvania (Juillet 1998) [3] Bouzeghoub, M., Kloul, L., Mokhtari, A.: A new active network framework based on active rules. Technical Recherche 21, PRiSM (2002) [4] Braden, R., Lindell, B., Berson, S., Faber, T.: The asp ee: An active network execution environment. In: Proceedings of DARPA Active Networks Conference and Exposition (DANCE 2002). IEEE CS Press, Los Alamitos (2002) [5] Calvert, K.: Architectural framework for active networks. Technical repport, AN Architecture Working Group (Juillet 1998) [6] Decasper, D., Plattner, B.: Dan - distributed code caching for active networks. In: IEEE INFOCOM, San Francisco (April 1998) [7] AN Security Working Group. Security architecture for active nets (2001) [8] Hicks, M., Kakkar, P., Moore, J.T., Gunter, C.A., Nettles, S.: Plan: A packet language for active networks. Departement of Computer and Information Science University of Pennsylvania (Juillet 1998) [9] Hillston, J., Kloul, L., Mokhtari, A.: Towards a feasible active networking scenario. Telecommunication Systems 27(2-4), 413, 438 (2004) [10] Calderon, M., Bagnulo, M., Alarcos, B., Sedano, M.: Providing Authentication & Authorization Mechanisms for Active Service Charging. In: Stiller, B., Smirnow, M., Karsten, M., Reichl, P. (eds.) QofIS 2002 and ICQT 2002. LNCS, vol. 2511, pp. 337–346. Springer, Heidelberg (2002) [11] Otsuki, H., Bossardt, M., Egawa, T., Plattner, B.: Integrated service deployment for active networks. In: Sterbenz, J.P.G., Takada, O., Tschudin, C.F., Plattner, B. (eds.) IWAN 2002. LNCS, vol. 2546, pp. 74–86. Springer, Heidelberg (2002) [12] Murphy, S., Lewis, E., Puga, R., Watson, R., Yee, R.: Strong security for active networks (2001) [13] Necula, G.C., Lee, P.: Research on proof-carrying code for untrusted-code security. In: Proceedings of the IEEE Symposium on Security and Privacy, Oakland (1997) [14] Wakeman, I., Jeffrey, A., Owen, T., Pepper, D.: Safetynet: A language-based approach to programmable networks. Computer Networks 36(1), 101–114 (2001) [15] Wetherall, D., et al.: Ants: A toolkit for building and dynamically deploying network protocols. In: IEEE OPENARCH, San Francisco (April 1998) [16] Wetherall, D.J.: Active network vision and reality: lessons from a capsule-based system. In: Operating Systems Review, 17th ACM Symposium on Operating Systems Principles (SOPS 1999), December 1999, vol. (34), pp. 64–79 (1999) [17] Zhou, Y., Zhang, Y., Lu, J.: Cds: a code distribution scheme for active networks. Computer Communications 27(3), 315, 321(7) (2004)

Securing AODV Routing Protocol in Mobile Ad-Hoc Networks Phung Huu Phu, Myeongjae Yi , and Myung-Kyun Kim Network-based Automation Research Center and School of Computer Engineering and Information Technology University of Ulsan, Ulsan Metropolitan City, 680-749, Republic of Korea [email protected], {ymj,mkkim}@mail.ulsan.ac.kr

Abstract. In this paper, we have proposed a security schema for Ad-hoc On-Demand Distance Vector (AODV) routing protocol. In this schema, each node in a network has a list of its neighbor nodes including a shared secret key which is obtained by executing a key agreement when joining a network. One key principle in our schema is that before executing route discovery steps in AODV protocol, each node executes message authentication process with the sender to guarantee the integrity and non-repudiation of routing messages and therefore, could prevent attacks from malicious nodes. Comparing with other recently proposed security routing protocols, our security schema needs less computation power in routing transactions and does not need any centralized element in mobile ad-hoc networks.

1

Introduction

The AODV routing protocol [1] is being considered by the Internet Engineering Task Force (IETF) for Mobile Ad-hoc Network (MANET) routing protocol standardization. AODV is improved from DSR [2] routing protocol and both of them are reactive routing protocols. In general, the AODV routing protocol fulfills the requirements of routing protocol in MANETs and it is efficient in terms of network performance. However, security aspects have not been considered in the protocol; attackers, therefore, can use many kinds of attacks via route discovery or path maintenance process such as advertising falsified route information, redirecting routes, launching denial-of-service attacks, sending falsified error reports and so on. Recently, a number of researches have been investigated for secure routing protocols in MANETs. Some focus on AODV and others examine general solution for secure routing in MANETs. Most routing security solutions make unrealistic assumptions about the availability of key management infrastructures that are in contrast with the very nature of ad hoc networks. Integrity of transactions between neighbor nodes, which is required to protect against fabrication attacks, is not examined in most of these protocols. 

Corresponding author.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 182–187, 2009. c IFIP International Federation for Information Processing 2009 

Securing AODV Routing Protocol in Mobile Ad-Hoc Networks

183

In this paper, we examine and discuss recent secure routing protocols in order to identify the flaws of current security approaches. Based on the analysis, a security schema for AODV routing protocol has been proposed to eliminate the security flaws in the protocol and compensate identified security weaknesses in recent secure routing approaches. The remainder of this paper is organized as follows. Section 2 examines current approaches of security routing, then the scope of problems which needs to be solved in this research is stated. In section 3, we detail our proposed schema to secure AODV. We discuss and analyze our schema in section 4. Finally, we conclude our contribution and specify future work in section 5.

2

Problem Statement

Lately, there are a number of solutions for securing routing protocols in MANETs. In this section, however, we briefly describe only two schemas: ARAN [4] and SAODV [5] since they are closely related to our approach. In [4], the authors categorized three kinds of threats which are modification, impersonation and fabrication in AODV and DSR. On the basic of these analysis, the authors proposed a protocol called ARAN (Authenticated Routing for Ad hoc Networks) using cryptographic certificates to bring authentication, message-integrity and non-repudiation to the route discovery process based on the assumption of existing of a trusted certificate server. It is not appropriate with ad hoc networks because it forms a centralized element. Moreover, in this protocol, because the source node cannot authenticate intermediate nodes in the routing path, intermediate malicious nodes can use error message attacks to networks. In [5], the authors extend the AODV routing protocol to guarantee security based on the approach of key management scheme in which each node must have certificated public keys of all nodes in the network. This work uses two mechanisms to secure the AODV messages: digital signature to authenticate the fixed fields of the messages and hash chains to secure the hop count field. This protocol uses public key distribution approach in the ad hoc network; therefore, it is difficult to deploy and computationally heavy since it requires both asymmetric cryptography and hash chains in exchanging messages. The protocol also did not consider the authentication of intermediate nodes; hence it could not prevent the attack of falsifying error messages in ad hoc networks. In general, the existing schemas for secure routing are based on the assumptions of the availability of key management infrastructures which are unrealistic and contrast to the ad-hoc network concepts. Moreover, these schemas do not consider intermediate nodes during the routing steps; therefore, the nodes may perform fabrication attacks. From these weaknesses of current approaches, our goal is to design a schema which performs point-to-point message authentication without a deployed key management infrastructure.

3

The Proposed Security Schema for AODV

The principle of our schema is that messages in AODV must be authenticated to guarantee the integrity and non-repudiation so that the protocol can be prevented

184

P.H. Phu, M. Yi, and M.-K. Kim

against several kinds of attacks. Each node in a network has its own a pair of public key e and private key d following RSA Public-key Crypto-system [6] by selfgeneration, and each node contains a list of neighbor nodes with records containing the information of a neighbor node including neighbor address, neighbor public key, and a shared secret key. This information is formed after the key agreement between two neighbor nodes to negotiate a pair of keys and a shared secret key. The details of our security schema for AODV are described as the following sections. 3.1

Key Agreement Process between Neighbor Nodes

A node joining a network requires to send key agreement messages to its neighbors to negotiate a shared secret key. The concept of this process is based on HELLO message in ad-hoc routing protocols. The node broadcasts a message indicating the negotiation request with neighbor nodes: . On receiving this request, nodes reply a message: (where eS and eN are the public key of the sender node and replying node, respectively; request id is a sequence number generated by the sender node) to indicate the receiving of the request message and inform that it is ready for the key agreement process. For each received message, the request node creates a new record in its neighbor list. Each record contains filled neighbor address and filled neighbor public key; the other fields of the record are empty. For each new record in the list, the request node (A) negotiates a secret key with the neighbor node (B) by the following steps: 1. 2. 3. 4.

Generate a key Ks by using a secure random number generator, Encrypt Ks with eB (node B’s public key) = encrypteB (Ks ), Send an offer message to B, Wait ACK from B and check message integrity to finish the negotiation

When node B receives the offer message, it decrypts encrypteB (Ks ) by its private key (dB )to get the shared key Ks . Then, node B sends the ACK message to indicate successful shared secret key negotiation, where hKs (request id) is the hashed message of request id by the shared key Ks . Since RSA algorithm is used in the negotiation, the confidentiality of the shared key is guaranteed between the two nodes. The shared key is used for authenticating messages between two adjacent nodes later in AODV routing protocol. In the case a node does not have a shared key with its neighbor nodes, it can not participate in routing transactions. 3.2

Route Request

Route request (RREQ) is initiated by a source node (S) and then propagated by intermediate nodes until the message reaches its destination node (D). On receiving RREQ, an intermediate node I, according to AODV routing protocol, checks whether the message will be re-broadcasted or not. If the message needs to be re-broadcasted and the sender is in node I’s neighbor list,

Securing AODV Routing Protocol in Mobile Ad-Hoc Networks

185

it will send (unicast) a message to request the authentication process from the sender: . When receiving the authentication request, the sender creates an authentication reply message containing where hashKs (RREQ) is the hashed value of RREQ message by the shared key Ks between the two nodes. The authentication reply message is unicasted back to node I. Node I on receiving the message will check the integrity of the RREQ message by hashing the message with using the shared key Ks and then comparing with the received hashed digest. If the comparison is successful (the integrity of the RREQ message is guaranteed), node I continues steps following AODV such as set up reverse path, increase the hop count, rebroadcast the message and so on; otherwise, the RREQ will be discarded. The process continues until the message reaches the destination. The destination also authenticates the sender of RREQ (neighbor of the destination) by the same procedure.

Fig. 1. Illustration of the message authentication

3.3

Route Reply and Route Maintenance

Route replies (RREP) in AODV are also targets for attacks by malicious nodes. In our schema, when receiving a RREP, a node requests the sender to proof the integrity and non-repudiation of the message by sending an authentication message . The request for authentication is and the reply is where hashKs (RREP) is the hashed value of RREP message by the shared key Ks between the two nodes. After the authentication process is successful, a node continues to the steps in AODV, otherwise, the node drops RREP since it is invalid. In route maintenance process, only route error report message (RERR) is a target for attacks in AODV protocol. Our schema requires the authentication process in sending route error messages to prevent attacks from malicious nodes. The authentication request and response for RERR is , and , respectively.

186

4

P.H. Phu, M. Yi, and M.-K. Kim

Security Analysis

Our schema proposes a new fully distributed authentication process which does not require any third parties. The schema does not supply the confidentiality but it provides the integrity and non-repudiation of messages. Our schema has a similar approach with SAODV or ARAN in supplying the integrity and nonrepudiation of messages. However, it uses point-to-point authentication process, therefore, it can authenticate intermediate nodes in routing steps and it does not require a certificate server (like ARAN) or assumption of key distribution (SAODV). By supplying integrity of exchanging messages, our schema can prevent against attacks from malicious nodes. A malicious node can not forms loops by spoofing nodes thanks to authentication process between neighbor nodes. Based on the integrity of exchanging messages, the schema also can prevent falsified error messages or modification attacks during route discovery process. However, the end-to-end authentication process has not been considered yet in our current work, some kinds of attacks such as impersonating a source node, a destination node, or neighbor of destination could not been prevented if malicious nodes comply with the proposed procedure. It is assumed that after time of working, trust relationship between two neighbor nodes will be established; a node that continues to perform malicious activities will be detected and excluded from trust list and therefore, so it can not participate in future routing. This aspect is expected to be studied in future. In general, the proposed security schema needs heavy computation when a node joins a network, but during routing transactions, it needs less computation power compared to existing approaches since it only uses hash algorithm to authenticate between two nodes and it does not need a centralized element in the network which causes heavy computation in the existing secure routing protocols. In our opinion, the proposed schema is more appropriate to the MANETs since there is no centralized element. This approach differs from most routing security solutions which make unrealistic assumptions about the availability of key management infrastructures that are in contrast with the very nature of ad hoc networks.

5

Conclusions and Future Work

Our work focuses on AODV routing protocol, which is under consideration as a standard for routing in MANETs. A security schema for AODV has been proposed to prevent common kinds of attacks and compensate for the security flaws of recent related works. The approach of our work is that exchanging messages in AODV are required to be authenticated in point-to-point step by using hash chains during a transaction. When joining a network, a node must execute key agreement with neighbor nodes so that each two neighbor nodes have a shared secret key. Before executing steps in AODV, each node performs message authentication process with the sender by requesting hashed digest value

Securing AODV Routing Protocol in Mobile Ad-Hoc Networks

187

of the message and then checking the integrity and non-repudiation of routing messages from the hashed message in order to prevent attacks from malicious nodes. However, some kinds of attacks such as tunneling attacks or selfishness problems (so far, no security schema has been able to detect these [5]) have not been considered in this work. This work has proposed a point-to-point and fully distributed authentication approach for securing AODV. It can compensate for weaknesses in SAODV or ARAN as above-mentioned since it can authenticate intermediate nodes in transactions and it does not need any centralized element such as certificate server. Recently, this work just focuses on AODV routing protocol; however, future work will investigate on applying the schema to other routing protocols in MANETs. The implementation and simulation of the schema will be investigated to compare security features with similar approaches in particular kind of attacks. The end-to-end authentication procedure will be added to the current approach in order to improve our current schema.

Acknowledgments The authors would like to thank Ministry of Commerce, Industry and Energy, Ulsan Metropolitan City, University of Ulsan, and the Network-based Automation Research Center (NARC) which partly supported this research. The authors also thank Prof. Hoon Oh (University of Ulsan) and the anonymous reviewers for their carefully reading and commenting this paper.

References 1. Charles, E.P., Elizabeth, M.R.: Ad hoc On-Demand Distance Vector Routing. In: Proc. of the 2nd IEEE Workshop on Mobile Computing Systems and Applications, New Orleans, LA, pp. 90–100 (1999) 2. Johnson, D., Maltz, D.: Dynamic source routing in ad hoc wireless networks. In: Imielinski, T., Korth, H. (eds.) Mobile computing. Kluwer Academic Publ., Dordrecht (1996) 3. Refik, M., Pietro, M.: Security in ad hoc networks. In: Conti, M., Giordano, S., Gregori, E., Olariu, S. (eds.) PWC 2003. LNCS, vol. 2775, pp. 756–775. Springer, Heidelberg (2003) 4. Kimaya, S., et al.: Authenticated routing for ad hoc networks. Journal on Selected Areas in Communications 23(3), 598–610 (2005) 5. Zapata, M.G., Asokan, N.: Securing Ad hoc Routing Protocols. In: Proc. of the ACM workshop on Wireless security, Atlanta, USA, pp. 1–10 (2002) 6. Man, Y.R.: Interner Security-cryptographic: principles, algorithms and protocols. Wiley Publishing House, Chichester (2004) 7. Panagiotis, P., Zygmunt, J.H.: Secure Routing for Mobile Ad hoc Networks. In: SCS Communication Networks and Distributed Systems Modeling and Simulation Conference (CNDS 2002), San Antonio, TX (2002)

Extensible Network Configuration and Communication Framework Todd Sproull and John Lockwood Applied Research Laboratory Department of Computer Science and Engineering: Washington University in Saint Louis 1 Brookings Drive, Campus Box 1045 St. Louis, MO 63130 USA http://www.arl.wustl.edu/arl/projects/fpx/reconfig.htm

Abstract. The effort to manage network security systems has increased in complexity over the past years. Network security for a company, university, or government agency can no longer be provided using a single Internet firewall or Intrusion Prevention System (IPS). Today, network administrators must deploy multiple intrusion detection and prevention nodes, traffic shapers, and firewalls in order to effectively protect their network. As the number of devices increases, maintaining a secure environment becomes difficult. This paper presents an infrastructure for control, configuration, and communication between heterogeneous network devices. The approach presented uses a Publish/Subscribe model built on top of a peer-to-peer overlay network in order to distribute information between network intrusion detection and prevention devices.

1

Introduction

Network administrators have become overwhelmed by the task of securing their networks against attacks on hosts in their network. End hosts are difficult to protect because they can be subverted via attacks against flaws in their operating system, trojan programs, and misconfiguration by users. Firewalls, Network Intrusion Detection Systems (NIDS) and Intrusion Prevention Systems (IPS) integrated within the network help protect against exploitation of such flaws. Many organizations also deploy traffic shapers to help organize bandwidth more fairly. Today, network administrators spend much of their time patching or changing device configurations to prepare or recover from the latest computer worm or system exploit. The manual configuration and administration of each device contributes to down time of the network. It is difficult to manage a group of firewalls, NIDS, IPS, and traffic shapers because today’s different devices each user proprietary management infrastructure. Developing a common framework for these devices to communicate would greatly reduce the time associated with control and configuration of all systems in the network. In this work, we propose a unified management network that exchanges information using an eXtensible Markup Language (XML). D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 188–193, 2009. c IFIP International Federation for Information Processing 2009 

Extensible Network Configuration and Communication Framework

189

The proposed infrastructure allows heterogenous nodes to communicate via XML messages sent over an adhoc, Peer-to-Peer (P2P) overlay network. Experimental results demonstrate the performance of the overlay forwarding high level security alerts.

2 2.1

System Architecture Services

Nodes in the overlay network subscribes to services of interest. Nodes subscribe to the services by issuing discovery queries to the network. Nodes implementing services respond with a list of the services they offer as well as advertisements of other peers in the group. Services include, but are not limited to: rule updates for intrusion detection and prevention, signatures distribution for viruses and trojan horses, anomaly detection and SPAM filters. In general, these services run in hardware or software in the network infrastructure and communicate through an overlay network. 2.2

Overlay Network

The P2P overlay network is developed using JXTA [11]. JXTA provides an open infrastructure allowing developers to create P2P networks operating across a variety of platforms. The original implementation of JXTA was developed in JAVA. JXTA-C and JXTA for mobile devices also exist. The default message distribution broadcasts messages to communicate with nodes. JXTA also supports a two tiered hierarchy for the overlay network, Which could be used to reduce the amount of traffic forwarded between nodes when discovering services. 2.3

Connecting JXTA with Services

In order for JXTA to interface with existing software running on hosts that provide network services, a mechanism was needed to hook into applications that need to communicate. This was accomplished through a generic wrapper around the process implementing the security service. Updates to the peer sent from an administrator or authorized node are processed by the peer. The peer reformats the control and configuration commands for the specific application executing the service. Commands are redirected to a configuration file and the application level process is restarted.

3

Implementation

Table 1 identifies several types of security services and how each maps to a particular platform. Services were implemented for three types of network processing platforms: a Linksys Wireless Router, (model WRT54GS) [5], a workstation running Linux and a Global Velocity GVS1500 Extensible Network Switch [1]. The applications which run on these platforms include Intrusion Detection or Prevention, Quality of Service, and Anomaly Detection.

190

T. Sproull and J. Lockwood Table 1. Security Applications for each respective platform Wireless Router Workstation Extensible Switch Intrusion Detection Snort with Snort or Bro FPGA Snort or Prevention limited ruleset Lite Quality of Service Linksys QoS HTB FPGA Queue Support Manager Anomaly or None SPADE FPGA Worm Event Detection Detector

In this work we modified a Linksys wireless router to serve as a node in the network-wide managed infrastructure. The wireless router consists of a 54 MBit/sec WiFi connection, a 4 port 100Mbit/sec Ethernet switch and one external 100Mbit/sec uplink connection. The Linksys router uses a 200 MHz embedded processor with 32MBytes of RAM. An experiment has been discussed demonstrating the IDS software Snort [10] running on the Linksys router in [3]. This implementation of Snort on the Linksys router is limited in terms of the number of rules it supports and the rate at which it processes requests. The router provides native support for application and port based Quality of Service. Performing anomaly detection at the wireless router was not the intended purpose of the device and only works to a marginal degree because of limited CPU and memory resources. Anomaly services are better implemented using higher powered nodes. A workstation configured with the Linux operating system is another platform we support for distributed management. Linux workstations are commonly used by network administrators implementing IDS. Networks running IDS software operate at rates measured in the 100’s of Megabits/sec range. Two open source software tools perform IDS, Snort and Bro [9]. Linux systems can be used to provide some types of Quality of Service. The Hierarchical Token Bucket (HTB) packet scheduler [2] is found in standard Linux distributions from 2.4.20. Anomaly detection can be performed using Linux with the Statistical Packet Anomaly Detection Engine (SPADE) [4]. SPADE is a Snort preprocessor plugin which sends alerts through the standard Snort reporting mechanisms. The Global Velocity GVS1500 system uses the FPX hardware platform [7] to process packets in reconfigurable hardware at Gigabits/second rates. is a reconfigurable hardware device able to process traffic at gigabit link rates using FPGA’s. The device also contains a single board computer executing software applications. FPGA Circuits have been developed for FPX modules that process Snort rules operating in both Intrusion Detection and Prevention modes. This work was presented in [6], and demonstrated Gigabits/sec header and payload processing of TCP streams. An application to detect worm activity was presented in [8]. This approach demonstrated the use of Bloom filters to maintain statistics on commonly occurring content.

Extensible Network Configuration and Communication Framework

4 4.1

191

Experimental Results High Level

In order to test the capabilities of the overlay network, experiments were performed to measure the overhead of JXTA and the publish/subscribe model for nodes. Specifically, the time to process alerts and forward relevant information to nodes or groups of nodes interested in the alerts or aggregation of alerts. Figure 1 illustrates the network created to test the overlay network. The topology consists of an XML generator host, a host which advertises and publishes alerts, the server, and clients interested in subscribing to the server. The XML generator sends alerts to the server which are forwarded to subscribers. XML Generator

Server/Publisher Clients/Subscribers

100Mbit/sec

100Mbit/sec

Workgroup Switch

CiscoSystems

Catalyst

10.1.2.X

Workgroup Switch

CiscoSystems

Catalyst

10.1.1.X

Fig. 1. Network topology constructed in Emulab

4.2

Experiment Setup

The Emulab [12] environment is used to test the performance of the P2P overlay network. The nodes in the experiment consist of three 2Ghz Pentium 4 computers executing the Linux 2.4.20 kernel. The links between each node are set to 100Mbits/sec with 0ms delays between links. The XML generator injects 1000 144byte XML alert packets at various link rates. JXTA version 2.3.3 is used on all hosts. Communication between the nodes is through the JXTA API, using unreliable unicast pipes on top of TCP. JXTA pipes provide a mechanism to connect the input of one service (or node) to the output of another. 4.3

Results

Figure 2 represents the number of packets per second the generator is able to inject while avoiding packet loss at the client. The client is subscribed to one service, which consists of every alert from the XML generator. The number of dropped alerts increases with the increase of packets per seconds from the XML generator. At approximately 55 packets per second, JXTA is able to forward all 1000 alerts to a client. Figure 3 illustrates the percentage of alert traffic dropped as the number of subscriptions increase. For each subscription an additional copy of the alert is generated. For example, when seven clients are subscribed, JXTA attempts to send out 1000 alerts to each of the seven clients (7000 total alerts). In this example, the clients are individual nodes, however they are capable of acting as

192

T. Sproull and J. Lockwood

100 90 80

Packet Loss %

70 60 50 40 30 20 10 0 0

100

200

300

400

500

600

700

Packets per Second

Fig. 2. Percentage of dropped as the number of packets per second increases

100 90

Packet Loss %

80 70 60 50 40 30 20 10 0 1

2

3

4

5

6

7

8

9

10

Number of Subscribers

Fig. 3. Percentage of dropped packets as the number of subscribes increases

rendezvous peers connected to a large group of nodes, similar to the top tier of a two tier overlay network. From the graph, we observe that with two subscriptions the number of alerts the server processes and forwards is cut almost in half. As the number of subscriptions increase, the total amount of alerts generated increases, however the number received at each client continues to decline. During both of these experiments the CPU utilization of both the client and the server operated around 60-70%. The main reason for such low performance stems from the amount of overhead necessary for a single JXTA alert message. In order to send a message, the server first creates a JXTA unidirectional output pipe to connect to the client. A reason for this is to ensure that the client is alive, as JXTA makes no assumptions about reliable nodes. The overhead associated with this however, is around 40ms per alert. The overhead of transmitting the JXTA alert was observed with tcpdump. Nine packets were transmitted between the client and server to create the output pipe and deliver the message. Despite this drawback, optimizations exist to increase performance. The authors chose an implementation consist with examples provided by the JXTA tutorials. Maintaining individual state per client should increase overall performance.

Extensible Network Configuration and Communication Framework

5

193

Conclusion

The goal of this initial research is to investigate techniques for deploying services in the network for heterogeneous communications. Migrating to an open XML based solution imposes a fair amount of overhead as observed through the experiments. Characterizing the overhead and investigating appropriate uses of this technology is necessary. Moving forward, the goal is to developing more automated network management using open standards targeting network security.

References 1. Global Velocity, http://www.globalvelocity.info/ 2. Heirarchical token bucket, http://luxik.cdi.cz.devik/qpos/htb/ 3. IETF Simple public key infrastructure (spki) charter (September 2003), http://www.batbox.org/wrt54g.html 4. Spade - statistical packet anomaly detection engine (2004), http://www.computersecurityonline.com/spade 5. Linksys (2005), http://www.linksys.com 6. Attig, M., Dharmapurikar, S., Lockwood, J.: Implementation results of bloom filters for string matchings. In: FCCM, Napa, CA (April 2004) 7. Lockwood, J.W.: Evolvable Internet hardware platforms. In: The Third NASA/DoD Workshop on Evolvable Hardware (EH 2001), pp. 271–279 (July 2001) 8. Madhusudan, B., Lockwood, J.: Design of a system for real-time worm detection. In: Hot Interconnects, Stanford, CA, pp. 77–83 (August 2004) 9. Paxson, V.: Bro: a system for detecting network intruders in real-time. In: Computer Networks, Amsterdam, Netherlands, vol. 31(23–24), pp. 2435–2463 (1999) 10. Roesch, M.: SNORT - lightweight intrusion detection for networks. In: LISA 1999: USENIX 13th Systems Administration Conference, Seattle, Washington (November 1999) 11. Traversat, B.: Project jxta 2.0 super-peer virtual network 12. White, B., Lepreau, J., Stoller, L., Ricci, R., Guruprasad, S., Newbold, M., Hibler, M., Barb, C., Joglekar, A.: An integrated experimental environment for distributed systems and networks. In: Proc. of the Fifth Symposium on Operating Systems Design and Implementation, Boston, MA, pp. 255–270. USENIX Association (2002)

A Model for Scalable and Autonomic Network Management Amir Eyal and Robin Braun Institute of Information and Communication Technology, Faculty of Engineering, University of Technology, Sydney {Amir.Eyal,Robin.Braun}@uts.edu.au Tel.: +61 2 9514 2460; Fax: +61 2 9514 2435

Abstract. Current telecommunication network management systems rely extensively on human intervention. They are also prone to fundamental changes as the managed network evolves. These two attributes, combined with the growing complexity of networks and services, make the cost of network management very high. In recent years, we have witnessed the emergence of artificial intelligence applications. Some are aimed at the creation of autonomic network management systems. This paper offers a novel approach to the design of a network management system that incorporates intelligent agents. As a benchmark to this model, we use two approaches most widely in use in network management systems today. The focus of this paper is on synchronization issues, service discovery and policy enforcement. Keywords: Autonomous Network, Network Management, Scalability, Information Model.

1

Introduction

Telecommunication networks are by definition complex systems [5]. They consist of large numbers of components and the number of services and activities taking place is even larger. The behaviour of the network is according to a changing set of rules that is hard to accurately predict. Given the complexity, it is a difficult task to maintain and manage these systems. Moreover, the complexity has been growing and is expected to grow vastly with the introduction of new types of devices, new services and networks, and with the standardization of service differentiation [4, 6]. Substantial efforts are being put into automating management tasks. This includes the development of algorithms, protocols and management tools. By having some of the labour done automatically, the network operator can cut down on the resources spent on maintenance and management [1, 2]. It will still 

The authors are with the Institute for Information and Communications Technology, Faculty of Engineering, University of Technology, Sydney. They are members of the Teleholonic Systems Research Group. http://teleholonics.eng.uts.edu.au. Amir Eyal is a doctoral candidate. Robin Braun is Group Leader.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 194–199, 2009. c IFIP International Federation for Information Processing 2009 

A Model for Scalable and Autonomic Network Management

195

be required for network managers to perform some manual tasks, and to coordinate and supervise the automated tasks. By definition, the managed component has to behave in a certain pattern in order for the management algorithms to be effective. Any deviation from this pattern would mean efficiency degradation or a malfunction. To overcome that, the algorithm needs to be adaptive. This attribute in the management system would transform it from automatic to autonomic [5, 4]. A central part of the network management system (NMS) is the information layer (IL). The IL’s purpose is to represent the state of the network. Parameters in the information layer correspond to settable parameters in the network. The meta-tructure is an information model. It consists of two parts, informational, containing the network status, and operational, which has the ability to affect the status of the network. We use two opposite approaches in network management as benchmarks the distributed model and the centralized model. The distributed model with a distributed information base is epitomized by SNMP to control and monitor network devices like switches. The CIM [3] is a comprehensive example for the centralized model. This paper offers a novel model for the information layer that enables a strong binding by utilizing autonomic agents that perform the synchronization tasks. We show that it bridges over the differences between the standards in use to utilize the best suited standard for each component in a natural way. It also enables the use of intelligent agents that perform several duties. The paper proceeds as follows: section 2 is a survey on current management systems and models. Section 3 describes the autonomic network management system model. Section 5 describes our model, followed by a detailed description of the information layer (IL) and how it addresses the challenges presented above.

2

The Information Model

Information models divide to two groups or models. One model is the distributed information model. It can be seen in management systems like SNMP [7], where each network element contains its own parameters. A management system can perform a “SET” operations to change the state of the network, and a “GET” in order to check a certain parameter. Due to the differences between network elements, the structure, the hierarchy, of the information may differ from one element’s storage to another’s. Thus, it is also required of the system to know the structure of the informatio n model contained in each network element. Another constraint of this model is that information must be related to the physical element it exists on. This means that a parameter that cannot be associated with a specific network element does not get the appropriate representation. On the other hand, this approach is scalable, since the larger the network, the more distributed the MIB is. With centralized model, network management tools like CIM provide more versatile capabilities. CIM is a common definition of management information for

196

A. Eyal and R. Braun

systems, networks, applications and services [3]. Since its a centralized database (or distributed between a set of management stations) we can map logical entities properly. However, issues like synchronization and scalability rise, since all the weight of the network management falls on a small number of management stations and its corresponding databases.

3

The Hybrid Model

Our model’s contribution is twofold. Firstly, it remaps the network components into the TMF 4 layer structure [4], combining it with a 3 columns (vertical layers) of the management system. Secondly, it adds the concept of intelligent agents performing most of the duties in the management system. The usage of artificial intelligence concepts and tools, like JADE, which provides mobile agents, can alleviate accuracy and scalability issues, reduce delays and spare most of the effort done by the human network administra tor. It may also reduce the development cost of network management tools. The block representation of our two-dimensional autonomic network management model is presented in Figure 1. By dividing the network into 4 layers, the network can be fully represented in the information layer [4]: – – – –

Resource Layer - storage devices and available bandwidth. Services Layer - services offered by the system. The services rely on use resources in the layer below. The products and their components are mapped to the uppermost layers.

Fig. 1. Block Diagram of the Layered Model

In addition to the 4 horizontal layers, there are 3 vertical management layers. The first provides objectives to the system. An objective is an ambition that produces management actions. The middle layer translates those objectives into network activity. The rightmost layer is split in two parts. One stores the state of the network, corresponding to the 4 horizontal layers, while the other is in charge of maintaining integrity between the information storage and the network.

A Model for Scalable and Autonomic Network Management

4 4.1

197

Issues with the Information Binding Requirements

The flow of commands in the management systems is as follows. Any activity initiated by the objectives layer and translated by the management layer into changes in the information store, has to be reflected correctly in the network. It has to happen with as little delay and as much accuracy as possible. This is the IL ⇒ Network binding. On the other hand, any event that changes the state of the network needs to be visible to the management and objective layers. This means we need a binding in the other direction, IL ⇐ Network. The following discusses the inner structure of the synchronization block and the ways to achieve the IL ⇔ Network goal. In order for a network management system to become autonomous, it needs a number of prerequisite. – It has to be capable of incorporating specially tailored artificial intelligence algorithms. – It has to interface with intelligent agents. – It has to have a strong binding between the management systems information layer and the network parameters. 4.2

Structure

As shown in the logical representation in Figure 2(a), the management system has two parts, the management activity and the synchronization activity. The management activity is making and carrying out management decisions. This may be done by an autonomous decision making process or by a network administrator. Figure 2(b) shows the actual layout of the network management system with a physical network. The network consists of both physical elements (resources) and logical ones (services and products). Furthermore, the physical elements can be of any type. The synchronization activities taking place in the management system are separated from the actual management activity. The synchronization block is divided into three parts. The upper part is responsible for collecting data from the network. It is home to foraging agents that roam the network performing service-discover y activities. The lower part of this block is in charge of enforcing those management decisions taken in the management block, on the network, the IL ⇒ Network binding. It multiple types of agents and algorithms. The middle part interfaces between the two former parts and the management block. In events of an initiative from the management block, the interface part has to translate it to input for the algorithms that run in the lower part. Whenever the higher part comes up with new discovered data, the interface will perform the corresponding changes in the information layer. It is important to say that parts of this block are likely to be mobile agents, swarming the network devices themselves. The combination of an information layer and a synchronization layer would form a “terrain” or “environment” for the agents in the management layer, which take on the role of inhabitants of that terrain.

198

A. Eyal and R. Braun

Fig. 2. The hybrid system

4.3

A Hybrid System

A comparison of the two leads us to the conclusion that in the hybrid model, we would want to include as many high-level parameters as possible, while having the bulk of the lower-level ones distributed. That way we can enjoy the possibility of optimization in the centralized management layer and leave the IL scalable. The main performance issues we want to measure in the model for the autonomous management system is the bandwidth used for management. It is closely related to the number of messages passed between the IL and the network. In such case, the more centralized the model, the smaller the number of low-level commands and the total number of messages passed will be.

5

Possible Implementation

We need to implement two classes of intelligent agents. One class will contain agents capable of collecting the state of those parameters. The other class is of agents that affect the parameters within the domain. They synthesize changes in the information store and execute them on the network. Each class may consist of multiple agent types. In some cases, one type of agents may be responsible for more than one parameter or for both collecting a parameter’s state and setting it. Finally, after establishing a kind of sandbox that is able to perform network management duties autonomically; we can set to out explore ways to transform the management itself into an autonomic process. We might end up using a 3rd class of intelligent agents, a genetic algorithm, or any combination of those. At the this time, we have started with an email service. We mapped the email box into resources and services that it consists of, shown in Figure 2. We designed agents that perform the setting and the retrieving of parameters related to the service level of the email on multiple mail servers. For that particular service, we need to control on each server the list of users and passwords and be able to manage the quota allocated to each user. We are going to evaluate the management system using numerous measurements. The most obvious parameter would be the integrity of the system. Here,

A Model for Scalable and Autonomic Network Management

199

we want to see that the network stabilizes in the right state and that changes in the network’s state are reflected properly in the IL. Secondly, we will look at the delay, the period of time it takes the system to enter the state of stability. We will also notice the resources used in the process of performing a management act (i.e. number of messages, number of procedures, storage used, etc.). An important issue to check is the scalability of the management system. The measurement will be done by experimenting with different scales of networks, growing number of operations and user requirements and checking the rate of growth in used resources and of performance degradation experienced.

6

Conclusions

We have discussed the different model structure options in the design of an autonomic network management system with the emphasis on the Information Layer. We suggested that the appropriate model might be of a hybrid nature between the distributed and centralized models. We are going to test the effectiveness and efficiency of the model for supporting autonomic algorithms according to a set of parameters that include the efficiency and grade of results.

References [1] Bonabeau, E., Dorigo, M., Theraulaz, G.: Swarm Intelligence - From Natural to Artificial Systems, Santa Fe Institute (1999) [2] Holland, J.H.: Hidden Order - How Adaptation Builds Complexity (1996) [3] DMTF, Distributed Management Task Force [4] Braun, R.: Towards a Management Paradigm for Autonomic Communications (2005) [5] Ottino, L.A.N.A.,, J.M.: Complex Networks, Augmenting the Framework for the Study of Complex Systems. The European Physical Journal, B 38, 147–162 (2003) [6] Magrath, S., Braun, R., Cuervo, F.: Policy Interoperability and Network Autonomics. In: 7th International Symposium on Autonomous Decentralized Systems (2005) [7] Strauß, Klie, T., Frank: Integrating SNMP Agents with XML-based Management Systems. In: XML-based Management of Networks and Services in the IEEE Communications Magazine (2004) [8] Bellifemine, F., Caire, G., Poggi, A., Rimassa, G.: JADE - A White Paper (September 2003)

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver ´ Juan J. Ramos-Mu˜ noz, Angel M. G´ omez, and Juan M. Lopez-Soler Signal Theory, Telematics and Communications Department University of Granada, Spain [email protected], [email protected], [email protected]

Abstract. This work contributes to demonstrate what perceptual benefits can be expected by adding some processing capabilities to the network nodes for the class of interactive audio streaming applications. In particular, we propose a new voice stream multi-flow block interleaver and we show that it provides an intelligibility performance very close to the reference end-to-end interleaver, even under conditions where the end-to-end interleaving is unfeasible. Keywords: VoIP subjective evaluation, interleaving, speech recognition.

1

Introduction

It is well established that in streaming voice applications packet losses are more harmful as they are consecutive, since the subjective quality degradation increases as the burst length increases [1]. Based on this fact, to improve the VoIP perceived quality some procedures should be considered to combat the unwished bursty-error-prone nature of the Internet. To this end, by using active technology, we aim to scatter the pattern of losses without increasing both the bandwidth consumption and, ideally, the end-to-end delay as well. Traditionally, error control techniques operate end-to-end [2]. However, with the advent of the Active Networks technology [3] new promising router functionalities can be envisaged. In this work, we evaluate our active procedure in terms of intelligibility, and we experimentally show that the quality of the received audio stream increases by using active routers. More precisely, we take up again the packet interleaving problem but now we use the processing capabilities of the network elements. Since intermediate network nodes can use different multimedia flows [4], we propose an interleaver algorithm that take advantage of it [5]. For comparison purposes, we simulate a reference single flow end-to-end interleaver and, we experimentally demonstrate that, under some circumstances, our algorithm outperforms the reference system in terms of intelligibility with light impact in the end-to-end packet delay. 

This work has been partially financed by the Spanish Science and Technology Ministry under Research Project TIC2002-02978 (with 70% of FEDER funds).

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 200–205, 2009. c IFIP International Federation for Information Processing 2009 

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver

2

201

Basic and Multi-flow Block Interleavers Algorithms

Given a input packet sequence, denoted by {ai }, and the output sequence, denoted by {bi } the interleaver defines a permutation π : ZZ → ZZ such that ai = bπ(i) . An interleaver is said to be periodic if it verifies that π(i+e) = π(i)+e, being e its period. An interleaver has a spread s, if any two input symbols in an interval of length s are separated by distance of at least s at the output. In interactive VoIP applications, the end-to-end delay must be bounded. Thus, for getting the minimum delay packet reallocation, given a spread s, the basic block interleaver algorithm [6] (hereafter referred to as Type I (s)) is: 1. Arrange the symbols associated to the input packets in a (s × s) matrix in rows, from left to right and from top to bottom. 2. Read the matrix by columns from bottom to top and from left to right, and accordingly send the packets. In this case, Dmax , defined as the maximum number of symbols (in the worst case) that any packet will wait at the interleaver, will be equal to Dmax = s·(s− 1). Note that for a periodic VoIP flow, given the imposed end-to-end delay constraint, Type I (s) interleaver will be limited to s such as s·(s−1)·tf < dmax , where tf is the inter-packet period, and dmax is the maximum end-to-end delay that any packet can tolerate. For example, for typical values of dmax = 300 ms and tf = 20 ms, it can not be assured that bursts length longer than 4 packets will be scattered. However, if the router jointly interleaves nf > 1 different flows, a reduction in the interleaver packet delay can be potentially achieved. In this work, we will assume that all the flows have the same period tf . To fill the interleaver matrices, each flow will maintain the relative order with respect to the others. In addition, for a given flow each row will be written from left to right according to the packet sequence number. Let (f 1 , f 2 , . . . , f nf ) be the nf available audio flows, and let s be the maximum expected burst length. To simplify, let us additionally define Rji , with i = {1, . . . , nf } and {j = 1, . . . , nm }, as the number of consecutive rows that the flow f i will be assigned for filling the interleaver matrix j, being nm the number of matrices. Depending on nf and s, we will consider two different cases. 1. Whenever nf ≥ s, the interleaver will be based on just one (nf × 1) matrix (nm = 1), in which R1i = 1, ∀i = {1, . . . , nf }. For this case, the interleaver n nf 1 2 output will be given by . . ., fi1 , fj2 , . . ., fk f , fi+1 , fj+1 , . . ., fk+1 , . . ., where the subscripts i, j, . . ., k denote the sequence number for flows f 1 , f 2 , . . ., f nf . We refer to this interleaver as Type II (nf ). 2. If nf < s, we will refer to this interleaver as Type II (nf , s). Under this condition, two different cases will be considered. – If s = (nf · i), i ∈ IN ⇒ nm = 1. That is, only one interleaver (s × s) matrix will be used; – Otherwise, nm = nf square (s × s) matrices will be required. Going ahead, if we denote rem(x, y) as the remainder of the integer division x/y, the writing matrices algorithm will be as follows:

202

´ J.J. Ramos-Mu˜ noz, A.M. G´ omez, and J.M. Lopez-Soler

 , for i = {1, 2, . . . , (nf −   rem(s, nf ))}. Similarly, we will set R1j = nsf + 1, for j = {(nf − rem(s, nf ) + 1), . . . , (nf − 1), nf }. – If applicable, for the next j = {2, . . . , nf } additional matrices,  and  for – For the first matrix, we will set R1i =

i i = {2, . . . , nf } flows, if R(j−1) = ( nsf     (i−1) Rji = nsf and Rj = ( nsf + 1).



s nf

(i−1)

+ 1) and R(j−1) =

s nf

then

As it can be checked, any burst of length less or equal to s will be scattered at the de-interleaver output. In this case, if we define r = rem(s, nf ) and d = (s−r)/nf , Dmax , the maximum delay will obey the following expressions - If r ≤ (nf − r) ⇒ Dmax = s · (r · (d + 1) − 1 − (r − 1) · d). - If r > (nf − r) ⇒ Dmax = s · (r · (d + 1) − 1 − ((r − 1) · d + 2 · r − nf − 1)) For a given s, the lower maximum delay that we can obtain is achieved when nf = (s−1), and when s/nf = 2 and r = 0. This delay corresponds to Dmax = s. Therefore, the maximum tolerated s, given a flow with a maximum per packet time to live dmax and a period of tf must satisfy that s < dmax tf . For the provided numerical example, in which tf = 20 ms and dmax = 300 ms, it yields that s < 15, what is significantly less demanding compared to the upper bound of s < 5 for the Type I (s) end-to-end interleaver. The period of the proposed Type 2 II (nf , s) interleaver is equal to ns f , if s ≡ 0 (mod nf ), and s2 in the other case.

3

Quality and Intelligibility Evaluation

To evaluate our VoIP interleavers we plan to use a high level criterion. In noise free conditions, Automatic Speech Recognition (ASR) rate is highly correlated to human intelligibility [7]. Based on that, we propose to use this score as the performance measure. We feel that this methodology should be definitively considered to evaluate any VoIP service enhancement. Compared to MOS subjective tests, ASR has lower cost and is more reproducible. In addition, in terms of the intelligibility perceived by the user, ASR rate can be more suitable than other quality measures like PESQ (ITU-T recommendation P.862) or the E-model [8]. Speech recognizer’s performance is measured in terms of the Word Error-Rate (WER), defined by: ni + n s + n d W ER = × 100 (1) nt where ns is the number of substituted words, ni is the number of spurious words inserted, nd is the number of deleted words and, nt is the overall number of words. Prior to the count of substitution, deletion and insertion errors, dynamic programming is used to align the recognized sentence with its correct transcription.

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver

4

203

Experimental Results

Experimental results are provided by means of simulation. A simple scenario is set. nf periodic flows arrive into the active router with period equal to tf = 20 ms. For the Type I (s) case, just one flow (nf = 1) is considered. Ideally, we assume no switching or any other routing delay. 1

Cumulative probability

0.95

0.9

0.85

0.8

0.75

0.7

0.65

Generated losses Type I(10) (Dmax=1.80 s) Type II(5) (Dmax=0.00 s) Type II(5,10) (Dmax=0.20 s)

0.6

0.55 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

Burst length Fig. 1. Bursts length CDF

We adopt a single error model. It is based on a Markov chain trained with collected traces described in [9]. The bursts length CDF of the trace obtained from the trained model is shown in Fig. 1. The overall probability of loss is 8.2%. In the same figure, as an illustrative example (nf = 5 and s = 10), we plot the bursts length CDFs obtained by using the simulated interleavers. Note that T ypeI(10) is not practically applicable, T ypeII(5) although does not introduce extra delay, it has less scattering capabilities and, finally, T ypeII(5, 10) exhibits a balance between the introduced delay and the loss isolation capacity. To enhance the quality of the received flow, before ASR evaluation, whenever a loss packet is detected, the previous received packet will be artificially repeated. For ASR evaluation we use the connected digit Project Aurora 2 database [10]. After transmission, in order to reduce its inherent variability the speech signal is processed. A feature extractor segments the received speech signal in overlapped frames of 25 ms every 10 ms. Each speech frame is represented by a feature vector containing 13 Mel Frequency Cepstrum Coefficients and the log-Energy. Finally, the feature vectors are extended with their first and second derivatives. The speech recognizer is based on Hidden Markov Models (HMM). We use eleven 16-state continuous HMM word models, (plus silence and pause, that have 3 and 1 states, respectively), with 3 gaussians per state (except silence, with 6

204

´ J.J. Ramos-Mu˜ noz, A.M. G´ omez, and J.M. Lopez-Soler

gaussians per state). The HMM models are trained from a set of 8440 noise-free sentences, while the out-of-train-test set comprises 4004 noise-free sentences. In Table 1, WER and Dmax values are summarized for T ypeI(s), T ypeII(nf ) and T ypeII(nf , s) interleavers with different nf and s. For a given nf , the s value was chosen such as Dmax , expressed in seconds, would be lower than 0.300 for T ypeII(nf , s) interleaver. Note that for T ypeII(nf ), Dmax is not shown because its theoretic delay is equal to 0. It can be observed that WER performance for T ypeII(nf ) interleaver strongly depends on nf . For nf = 2, T ypeII(nf , s) can reduce the T ypeII(nf ) WER without breaking the end-to-end constraint. However, as more nf will be available, the WER difference is less noticeable. Note that although T ypeI(s) outperforms both T ypeII interleavers it can be only used for s < 5, given the VoIP end-to-end delay constraint. Table 1. WER (%) and Dmax in seconds for the three simulated interleavers II(nf ) nf WER s 3 2 5.401 5 6 3 4.333 7 4 3.419 8 5 2.875 10

II(nf , s) WER Dmax 4.610 0.060 2.892 0.200 2.255 0.240 1.831 0.280 1.848 0.160 1.567 0.200

s 3 5 6 7 8 10

I(s) WER Dmax 3.080 0.120 1.595 0.400 1.540 0.600 1.307 0.840 1.289 1.120 1.325 1.800

nf 6 7 8 9 10 12

II(nf ) WER 2.420 1.968 1.819 1.613 1.611 1.534

s 12 14 9 10 11 13

II(nf , s) WER Dmax 1.449 0.240 1.381 0.280 1.626 0.180 1.526 0.200 1.533 0.220 1.455 0.260

s 12 14 9 10 11 13

I(s) WER Dmax 1.263 2.640 1.340 3.640 1.304 1.440 1.285 1.800 1.282 2.200 1.322 3.120

Additionally, note that the T ypeII(4, 8) maximum delay (160 ms) is lower than the T ypeII(3, 7) delay (280 ms), although the s value is greater. This is due to the peculiarity of the interleaver, which results in non linear delay dependence with the number of flows and the burst length considered. Summing up, both the Type II interleavers diminish the packet interleaving delay. Although Type II (nf ) is designed to work properly when nf ≥ s, it can be suited when nf ≈ s, without introducing any additional delay. Compared to Type II (nf ), the Type II (nf , s) interleaver improves the VoIP intelligibility. It scatters a high percentage of losses patterns, and reduces the maximum length of the bursts at the de-interleaver output. Furthermore, although T ypeII(nf , s) introduces some additional delay, it can be used under conditions that T ypeII(nf ) does not tolerate (long burst length and low number of different flows). On a separate note, given the processing capabilities of the active router, it could be always possible to select which interleaver algorithm to use (T ypeII(nf ) or T ypeII(nf , s)). In this case, the network dynamics and the number of available flows should be taken into account. As a rule of thumb, we would suggest the consideration of the T ypeII(nf ) interleaver instead of T ypeII(nf , s) whenever nf ≈ s.

Intelligibility Evaluation of a VoIP Multi-flow Block Interleaver

5

205

Conclusion

In this paper the block interleaving problem for audio applications is revisited. To increase the final audio quality we aim to scatter long bursts of packet losses. We propose a new VoIP interleaver algorithm which not only diminish the per packet delay, but also allows its use under conditions where end-to-end approaches are unfeasible. Our algorithm interleaves packets from different flows. To work properly, the interleaver must be placed in a common node before the path where losses are expected to occur. We show that the resulting speech intelligibility is maximized, especially when the number of available flows is small. In this work, because of its reproducibility and low cost, we have considered automatic speech recognition in order to assess the intelligibility improvements of the proposed VoIP active service. This procedure can be extended to evaluate any other VoIP enhancement. As future work, to establish a mapping function for human to machine recognition rate remains. Similarly, the mapping functions between recognition rate and MOS score should be studied as well. By using these mapping functions, enhanced VoIP active services can be envisaged.

References [1] Liang, Y.J., Farber, N., Girod, B.: Adaptive playout scheduling and loss concealment for voice communication over IP networks. IEEE Transactions on Multimedia 5(4), 532–543 (2003) [2] Towsley, D., Kurose, J., Pingali, S.: A comparison of sender-initiated and receiverinitiated reliable multicast protocols. IEEE Journal on Selected Areas in Communications 15(3), 398–406 (1997) [3] Tennenhouse, D.L., Smith, J.M., Sincoskie, W.D., Wetherall, D.J., Minden, G.J.: A survey of active network research. IEEE Communications Magazine 35(1), 80– 86 (1997) [4] Ott, D.E., Sparks, T., Mayer-Patel, K.: Aggregate Congestion Control for Distributed Multimedia Applications. In: IEEE INFOCOM 2004, vol. 1, pp. 13–23 (March 2004) [5] Ramos-Mu˜ noz, J.J., Lopez-Soler, J.M.: Low delay multiflow block interleavers for real-time audio streaming. In: Lorenz, P., Dini, P. (eds.) ICN 2005. LNCS, vol. 3420, pp. 909–916. Springer, Heidelberg (2005) [6] Kenneth Andrews, C.H., Kozen, D.: A theory of interleavers. Technical Report 97-1634, Computer Science Department, Cornell University (1997) [7] Jiang, W., Schulzrinne, H.: Speech recognition performance as an effective perceived quality predictor. In: Tenth IEEE International Workshop on Quality of Service, pp. 269–275 (May 2002) [8] Cole, R.G., Rosenbluth, J.H.: Voice Over IP Performance Monitoring. SIGCOMM Comput. Commun. Rev. 31(2), 9–24 (2001) [9] Yajnik, M., Kurose, J., Towsley, D.: Packet loss correlation in the MBone multicast network experimental measurements and markov chain models. Tech. Rep. UMCS-1995-115 (1995) [10] Hirsch, H.G., Pearce, D.: The AURORA Experimental Framework for the Performance Evaluations of Speech Recognition Systems under Noisy Condition. In: ISCA ITRW ASR 2000, France (2000)

A Web-Services Based Architecture for Dynamic-Service Deployment Christos Chrysoulas1, Evangelos Haleplidis1, Robert Haas2, Spyros Denazis1,3, and Odysseas Koufopavlou1 1 University of Patras, ECE Department, Patras, Greece {cchrys,ehalep,odysseas}@ee.upatras.gr 2 IBM Research, Zurich Research Laboratory, Rüschlikon, Switzerland [email protected] 3 Hitachi Sophia Antipolis Lab, France [email protected]

Abstract. Due to the increase in both heterogeneity and complexity in today’s networking systems, there arises a demand for an architecture for networkbased services, that gives flexibility and efficiency in the definition, deployment and execution of the services and at the same time, takes care of the adaptability and evolution of such services. In this paper we present an approach that applies a component model to GT4, a Web-service based Grid environment, which enables the provision of parallel applications as QoS-aware (Grid) services, whose performance characteristics may be dynamically negotiated between a client application and service providers. Our component model allows context dependencies to be explicitly expressed and dynamically managed with respect to the hosting environment, computational resources, as well as dependencies on other components. Our work can be seen as a first step towards a component-based programming-model for service–oriented infrastructures utilizing standard Web services technologies.

1 Introduction In the recent years, Web service technology has gained more and more importance in the area of Grid Computing. The Open Grid Service Architecture [1] has motivated Grid architects to build environments based on a service-oriented architecture utilizing Web-service technology. The evolution of the Globus Toolkit 4 [2] towards the Web Service Resource Framework [3] was the outcome of that effort. Grids are mostly built following a service-oriented architecture using Web-services technology which has not been designed to fit the idea of a component-based plugand-play client programming framework. Services are typically discovered dynamically, using technologies like the Monitoring and Discovery System (MDS) [4] in Globus Toolkit 4, rather than created, they further do not provide means to describe D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 206–211, 2009. © IFIP International Federation for Information Processing 2009

A Web-Services Based Architecture for Dynamic-Service Deployment

207

dependencies for example in other services running outside the Grid. Web-service technology provides a versatile messaging facility but lacks an extensive component model applicable to service composition. In this paper we present a component-based architecture in order to address the above issues. Our architecture is based not only on the Globus Toolkit 4 environment, a Grid architecture for the provision of parallel applications as Grid services over standard Web-service technology, but it also makes heavy use of a component-based architecture trying to solve the problem of creating new services and the dependencies in other services and components outside the architecture we present. Our proposed Dynamic Service-Deployment Architecture is developing as part of the FlexiNET [5] IST research project and particularly as a sub-module of the FlexiNET Wireless Access Node (FWAN) module. The remainder of the paper is organized as follows: Section 2 describes what FlexiNET is. Section 3 describes the architecture regarding the Dynamic ServiceDeployment. A discussion on related work is given in section 4. Conclusions and future work are presented in section 5.

2 FlexiNET Architecture As stated in section I, the DSD module is developed for the FlexiNET Project. The primary aim of the project is to define and implement a scalable and modular network architecture incorporating adequate network elements (FlexiNET Node Instances) offering roaming connection control, switching/routing control, and advanced services management/access functions to the network access points that currently only support connectivity between user terminals and network core infrastructures [6], [7], [8]. The FlexiNET network architecture consists mainly of node instances, communication buses and data repositories. The DSD module is part of the FWAN. The FWAN architecture can be seen in Figure 1 and is based on Hitachi’s distributed router. Hitachi’s distributed router consists of two functional blocks, the basic and the extensible function block.

Fig. 1. FWAN architecture

208

C. Chrysoulas et al.

The FWAN has, as a basic functional block, a network processor, and as extended functional block, two PCs. A user will access the FWAN through an access point using either a laptop or a mobile phone. The FWAN is responsible for authenticating native and roaming users through the FLAS using an AAA proxy. The Dynamic Service Deployment Module (DSD) must be deployed on the FWAN before boot-up. The Bootstrap Process is responsible for booting up the FWAN with the AAA proxy module. In order to accomplish its task, it reads from a static configuration file which is stored in a local of the Bootstrap Process, followed by a series of commands which will be sent to the DSD Module in order to create the FWAN’s node fundamental functionalities. The Bootstrap Process mainly will trigger the install of the AAA proxy through the DSD module. The AAA Proxy Module is forwarding the Authentication packets to the FLAS Server, encapsulates the EAP Packets [9] into XML messages that are passed over Web Services, and the opposite, in order to authenticate and authorize the user. The AAA proxy service is deployed in the FWAN at boot-up time. It is stored in a local directory and deployed by the DSD module. The code will be requested from the DGWN through Web services. On boot-up the DSD module is requested by the Boot-up process to deploy the AAA proxy module. The DSD module retrieves through the DGWN the AAA proxy service code and deploys it on any of the two PCs based on specific algorithms. Also based upon the user profiles, the DSD module will deploy a Quality of Service Module (QoS), which is responsible for providing QoS to specific users. The required configuration of the network processor will be handled by the ForCEG module which receives Web Service requests from the AAA Proxy and the QoS Module and translates them into ForCES protocol messages [10].

3 DSD Architecture 3.1 DSD Definition By Dynamic Service Deployment we are referring to a sequence of steps that must be taken in order to deploy a service on demand. The necessary steps regarding the service deployment refer to service code retrieval, code installing destination according to matchmaking algorithms, and service deployment. The matchmaking algorithms provide the most efficient use of system resources by examining the available resources of the FWAN with the required resources of the service to be deployed. 3.2 Proposed DSD Architecture The following figure depicts the current proposed DSD architecture. As can be deduced from the figure the DSD is the sum of the following sub-components:

A Web-Services Based Architecture for Dynamic-Service Deployment

209

Fig. 2. DSD Architecture

Web Services Server The Web Services Server sub-component hosts the interfaces with the AAA Proxy and the Bootstrap Process. At this stage only these two processes will interact with the DSD Module. This server is responsible for exchanging messages between the DSD Module and the AAA Proxy Module and the Bootstrap Process. The Web Services Server sub-component has the necessary functionalities necessary to register a Web Service in a UDDI directory. This component also is capable of finding other Web Service Interfaces. DSD Manager The DSD Manager sub-component has two functions depending on whether the user’s profile is required: ƒ In the case of the AAA Proxy communicates with the DGWN, the DSD Manager must download the user profile, in order to find, which services must be deployed , and provides the request to the DSD Controller. ƒ In the case of Bootstrap Process, the DSD Manager passes the bootstrap services required for deployment to the DSD Controller The DSD Manager is responsible to check if a user has terminated the connection and undo the user’s personal configuration. DSD Controller The DSD Controller sub-component is assigned to receive the service request from the DSD Manager, to communicate with the DGWN in order to download the service code and the service requirements, to retrieve from the Node Model the available resources, to perform the Matchmaking Algorithm in order to find the most suitable resources, and finally to deploy the service. The DSD Controller is responsible for the Services, in 3 dimensions: Download, Deploy, and Configure.

210

C. Chrysoulas et al.

Resource Manager The Resource Manager sub-component is assigned to do the discovery and monitoring of the resources. It collects information, with the help of the Resource Manager Interface, from all the components of the Node model, and also from the DSD Controller. All the collected information is available to the rest of the sub-components through the WebMDS Interface it provides. Only the necessary information is passed to the Node Model. Node Model The Node Model is responsible for keeping all the information about FWAN. It provides us with a complete view regarding the FWAN. The node model contains information regarding physical resources available and used, and data about running services. User Profile User Profile is the data–storage where the downloaded User Profile is stored. It is responsible for keeping the User Profile. Service code and Requirements The Service Code and Requirements data-storage is responsible for storing the downloaded code and the requirements (in terms of physical resources) that describe a service. Running Services and Configuration The Running Services and Configuration data-storage is responsible for storing data about running services and their current configuration.

4 Discussion of Related Work Distributed component models such as Cobra [11], DCOM [12] are widely used mostly in the context of commercial applications. The Common Component Architecture developed within the CCA forum [13] defines a component model for highperformance computing based on interface definitions. XCAT3 [14] is a distributed framework that accesses Grid services e.g. OGSI [1] based on CCA mechanisms. It uses XSOAP for communication and can use GRAM [2] for remote component instantiation. Vienna Grid Environment [15] is a Web service oriented environment for supporting High Performance Computing applications. Vienna Grid Environment (VGE) has been realized based on state-of-the-art Grid and Web Services technologies, Java and XML. Globus Toolkit 4 [2] is an environment that mostly deals with the discovery of services and resources in a distributed environment rather than the deployment of the services themselves.

5 Conclusion and Future Work We presented an architecture that adds a dynamic perspective to Web service based Grid Infrastructure. Our component-based model is addressing the issue regarding the

A Web-Services Based Architecture for Dynamic-Service Deployment

211

dynamic deployment of new services in a distributed environment and the way they address themselves in that environment. We expect this work to be not only relevant to the Grid community but also to the Web service and the Network communities as we did not only address concerns related to Grid computing but also discussed architectural issues regarding Web service configuration and deployment. Our implementation of the model is still in prototype stage which requires further refinement and analysis. For future work we plan to provide a more sophisticated model for service deployment and selection based on QoS properties.

References 1. Foster, I., Kesselman, C., Nick, J., Tuecke, S.: The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration, Globus Project (2002), http://www.globus.org/research/papers/ogsa.pdf 2. The Globus Alliance, http://www.globus.org 3. The Web Service Resource Framework, http://www.globus.org/wsrf/ 4. The Globus Alliance, http://www.globus.org/toolkit/docs/development/3.9.4/info/ wsmds.html 5. FP6-IST1 507646 FlexiNET Technical Annex 6. FP6-IST1 507646 FlexiNET D21 Requirement, Scenarios and Initial FlexiNET Architecture 7. FP6-IST1 507646 FlexiNET D22 Final FlexiNET Network Architecture and Specifications 8. Aladros, R.L., Kavadias, C.D., Tombros, S., Denazis, S., Kostopoulos, G., Soler, J., Haas, R., Dessiniotis, C., Winter, E.: FlexiNET: Flexible Network Architecture for Enhanced Access Network Services and Applications. In: IST Mobile & Wireless Communications Summit 2005, Dresden (2005) 9. RFC 3748: Extensible Authentication Protocol (EAP) (June 2004) 10. Haleplidis, E., Haas, R., Denazis, S., Koufopavlou, O.: A Web Service- and ForCES-based Programmable Router Architecture. In: IWAN 2005, France (2005) 11. CORBA Component Model, v3.0, OMG, http://www.omg.org/technology/ documents/formal/components.htm 12. COM Component Object Model Technologies, Microsoft, http://www.microsoft.com/com/default.mspx 13. The CCA Forum, http://cca-forum.org/ 14. Krishnan, S., Gannon, D.: XCAT3: A Framework for CCA Components as OGSA Services. In: Proceedings of the Ninth International Workshop on High-Level Parallel Programming Models and Supportive Environments, pp. 90–97 (April 2004) 15. Benkner, S., Brandic, I., Engelbrecht, G., Schmidt, R.: VGE - A Service-Oriented Environment for On-Demand Supercomputing. In: Proceedings of the Fifth IEEE/ACM International Workshop on Grid Computing (Grid 2004), Pittsburgh, PA, USA (November 2004)

The Active Embedded Ubiquitous Web Service Framework Dugki Min1,*, Junggyum Lee1, and Eunmi Choi2,** 1

School of Computer Science and Engineering, Konkuk University Hwayang-dong, Kwangjin-gu, Seoul, 143-701, Korea [email protected], [email protected] 2 School of Business IT, Kookmin University Chongnung-dong, Songbuk-gu, Seoul, 136-702, Korea [email protected]

Abstract. We develop an active embedded middleware framework, called the EUWS (Embedded Ubiquitous Web Service), in WinCE.NET. The EUWS seamlessly integrates home network services and the Web Services on the Internet and provides a management framework for ubiquitous web services. As the initial stage of our project, our current focus has been on designing and implementing a prototype of the EUWS in WinCE.NET. The architecture of the EUWS prototype system includes an extensible and reconfigurable Embedded Ubiquitous Web Service(EUWS) framework and an UPnP2WS processing module that seamlessly integrates the UPnP standard with the Web Service standard.

1 Introduction Recently, a number of middleware standards are proposed to implement home network. They are the UPnP(Universal Plug and Play)[1] for easy interoperability among devices, the HAVi(Home Audio and Video Interoperability)[2] for interoperability between video and audio devices, the Jini[3] for interoperability for Java applications, and the OSGI[4] for middleware framework between networked services. These recent home network middlewares are used to connect, integrate, and manage services provided by devices that are in a restricted area. However, none of them considers the seamless interconnection and integration with the external Internet services, i.e., to access home network services from the external client or to reach out the external Internet services from home network services. As the standard technology to integrate Internet services, the Web Service[5] becomes the major trend. The Web Service is platform-independent and programming languageindependent, and it is the XML-based middleware standard determined and developed by * This paper was supported by Konkuk University in 2005", and also by Microsoft Research Asia under the Grant of MSRA Joint Research Project in 2004. **Corresponding author: This work was supported the Korea Research Foundation (KRF) under Grant No. D00021 (R04-2003-000-10213-0), and also by research program and research center UICRC of Kookmin University in 2005. D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 212–217, 2009. © IFIP International Federation for Information Processing 2009

The Active Embedded Ubiquitous Web Service Framework

213

most of IT vendors. The Web Service provides the fundamental middleware standards of Internet distributed computing: SOAP[6] for the communication standard between services, WSDL[7] for description standard to define the Web Service in XML, UDDI[8] for service searching standard over Internet. Moreover, it extends up to the SOA-based application middleware standard by considering security, transaction, event, and business process management. We develop an active embedded middleware framework, called the EUWS (Embedded Ubiquitous Web Service), in WinCE.NET that can be applied to home gateways. The EUWS seamlessly integrates home network services, and the Web Services on the Internet and provides a management framework for ubiquitous web services. Through the EUWS home gateway, the device services are converted to the Web Services for external accesses, so that a remote client can control the device via the Web Services. At the same time, the EUWS gateway converts the external Web Services into the device-specific services, so that the internal devices can access and use the external services according to the device-specific protocol. As the initial stage of our research, our current focus has been on designing and implementing a prototype of the EUWS in WinCE.NET for the UPnP middleware protocol. The architecture of the EUWS prototype system includes an extensible and reconfigurable Embedded Ubiquitous Web Service(EUWS) framework and a UPnP2WS processing module that seamlessly integrates the UPnP standard with the Web Service standard. The EUWS technology will be used as an encore technology to build the Advanced Home Gateway. We have the EUWS prototype be deployed into a home gateway in our demo system where a digital audio and a digital TV can be controlled by an external remote controller. While the traditional gateway focuses on connection between internal segment and external segment at the network level, the EUWS focuses on connection between internal services and external services at the service level. The EUWS integrates various services which exist in home network environment, and integrates internal and external services. The next section presents the EUWS architecture. Section 3 presents our demo prototype system currently implemented. We conclude in the last section.

2 The EUWS Architecture In this section, we introduce the architecture of the active EUWS (Embedded Ubiquitous Web Service) framework. As shown in Figure 1, the active EUWS framework has two major parts: one is the Protocol Abstraction Sub-framework and the other is the Service Orientation Sub-framework. The Protocol Abstraction Subframework is for seamlessly integrating various devices each of which uses different middleware protocols. The Service Orientation Sub-framework is for creating a virtual service-oriented space where everything in a ubiquitous environment, e.g. devices or services, is a standard service. 2.1 Protocol Abstraction Sub-framework In order to support various ubiquitous devices that use different communication protocols, the Protocol Abstraction Sub-framework contains an Active Protocol

214

D. Min, J. Lee, and E. Choi

Fig. 1. The EUWS Framework Architecture

Reconfigurable architecture that can dynamically deploy protocol processing modules on demand. The active protocol reconfigurable architecture is composed of two dedicated modules and one or more pluggable modules. The two dedicated modules are the Protocol Detection Module and the Dynamic Protocol Deployment Module. The Protocol Detection Module is used for detecting new devices whose protocol processing module is not yet plugged-in. While the EUWS framework is running, the Protocol Detection Module periodically broadcasts a sequence of protocol-specific discovery messages one-by-one at a time. When it receives any response from a new device whose protocol execution module is not yet plugged-in, the related protocol processing module is downloaded and deployed automatically by the Protocol Deployment Module, if the related protocol processing module is available. Otherwise, error message is sent to the newly detected devices. The Protocol Detection Module can be upgraded whenever its new version is available. 2.2 Service Orientation Sub-framework The Service Orientation Sub-framework provides a service orientation environment where every distinctive device or service is recognized and treated as the same type of standard service. This framework also provides common middleware services, such as resource management service, event service, and security service. In our project, we employ the Web service as our service-orientation standard, since the Web service becomes the de-facto standard of business domain service area, and is also good at extensibility and self-description. The Service Orientation Sub-framework has three components: Service Manager, Service Container, and Middleware Services. The Service Manager is the manager of service orientation; it is in charge of transforming everything to standard service, registering and searching a registered service to the service directory, and providing metadata information of the registered services. Let us suppose that an UPnP device is newly arrived into the managed space. Then, the UPnP Processing Module detects the UPnP device and registers it to the Service Manager. The Service Manager creates a service proxy that acts as the corresponding service object for the device and uploads

The Active Embedded Ubiquitous Web Service Framework

215

it to the Service Container. At the same time, the WSDL of the service proxy is automatically generated. After the service proxy is deployed with WSDL into the Service Container, the Service Manager registers the device as a Web service into the UDDI. Other web services, which locate outside of the framework, consider the UPnP device as a registered Web service. Within our framework, this device is also treated as a standard service. That is, the Protocol Execution Module or the Service Manager accesses a registered device through the corresponding service proxy. However, external devices, that use their own protocols, access and use the registered device through their own protocols via the related Protocol Execution Modules. Other functions of the Service Orientation Sub-framework are the Middleware Services related to Service Container. The Service Container is in charge of system resource management and dynamic service deployment into memory if necessary. Also, the Service Container performs various management functions by detecting service invocation and generating events.

3 EUWS Prototype Implementation In this section, we introduce the EUWS prototype implemented. The EUWS prototype is a system operated on .NET framework and it contains the initial version of EUWS Framework with the UPnP execution module. In order to deploy the EUWS into a device, Win CE .NET Platform Builder is used to upload a kernel image into the board. 3.1 Development Environment The EUWS is implemented in an embedded board on top of Win CE .NET containing .NET Compact Framework. Two embedded boards are used; one is for a device and the other is for home gateway. The prototype device and home gateway are implemented on the similar boards called X-Hyper255B and X-Hyper255BTKUIII respectively. These boards have a 400MHz Intel XScale PXA255 CPU, 64MB SDRAM, 32MB flash memory, 10Base-T CS8900A and PCMCIA Slot. Detailed information is in Table 1. As for the external control client, HP iPAQ PDA is used. As a design tool, the IBM Rational Rose XDE is used, and as a development tool, the MS Visual Studio .NET is used. Table 1. Device Platform & Home Gateway Platform

Device Platform

Home Gateway Platform

3.2 Devices of Demo System As our demo systems, a digital audio and a digital TV are developed as UPnP devices (see Figure 2) Those devices contain UPnP device modules deployed on top of .NET

216

D. Min, J. Lee, and E. Choi

Compact Framework. When initially operating, their device information is transferred to the home gateway. Also, they have UPnP control point modules so that they can access web services provided by the home gateway as UPnP services. For example, the digital TV can receive channel broadcasting information service from the home gateway, and the digital audio can receive new media information.

Fig. 2. UPnP Devices (Digital TV & Digital Audio)

The home gateway contains the active EUWS framework explained in section 2. It discovers internal devices, and converts the services of the internal devices into Web services. It also converts external Web services into UPnP services. At the same time, the home gateway reads events from UPnP devices and transfers them to external clients. Especially, when an external Web service is accessed by an UPnP device, the external Web service is perceived as an UPnP service by the EUWS framework of the home gateway, that is an UPnP device including an UPnP control point can access the external Web Services as easy as UPnP services via the home gateway. In order to control digital audio and TV devices within home area, a PDA is used as external device that contains the home control application. When booting the PDA, the control application automatically begins and receives service information of home devices from the designated home gateway. The device information received by the home control application is written in the Web services of internal UPnP devices exported by the home gateway. Thus, when a user selects and invokes a service shown in the screen of the PDA, it invokes a Web service provided by the home gateway and it consequently invokes an UPnP service provided by an internal device. The Figure 3 shows the GUI of the PDA.

Fig. 3. External Devices

The Active Embedded Ubiquitous Web Service Framework

217

4 Conclusion In order to establish a ubiquitous home network, we developed an active embedded middleware framework, the EUWS, in WinCE.NET environment. The EUWS seamlessly integrates home network services and the Web Services on the Internet, and also provides a management framework for ubiquitous web services. In this paper, we presented a prototype of the EUWS in WinCE.NET for the UPnP middleware protocol, so that we can seamlessly integrates the UPnP standard with the Web Service standard, and work with UPnP devices and home gateway for the home network. Through our demo system, we could control a digital audio and a digital TV by an external remote controller. As an active embedded middleware framework, the EUWS achieved to integrate various existing services, internal and external services.

References [1] Miller, B.A., Nixon, T., Tai, C., Wood, M.D.: Home networking with Universal Plug and Play. Communications Magazine 39(12), 104–109 (2001) [2] HAVI, http://www.havi.org [3] Allard, J., Chinta, V., Gundala, S., Richard III, G.G.: Jini meets UPnP: an architecture for Jini/UPnP interoperability. In: Proceedings. 2003 Symposium on Applications and the Internet, pp. 268–275, January 27-31 (2003) [4] Dobrev, P., Famolari, D., Kurzke, C., Miller, B.A.: Device and service discovery in home networks with OSGi. Communications Magazine 40(8), 86–92 (2002) [5] Hung, P.C.K., Ferrari, E., Carminati, B.: Towards standardized Web services privacy technologies. In: Proceedings IEEE International Conference on Web Services, p. 174, July 6-9 (2004) [6] Box, D.: SOAP 1.1., http://www.w3.org/TR/SOAP/ [7] WSDL Verstion 2.0 Part 3: Bindings, http://www.w3.org/TR/wsdl20bindings/ [8] UDDI Technical WhitePaper, UDDI.org, http://www.uddi.org/whitepapers.html

Framework of an Application-Aware Adaptation Scheme for Disconnected Operations Umar Kalim, Hassan Jameel, Ali Sajjad, Sang Man Han, Sungyoung Lee, and Young-Koo Lee Department of Computer Engineering, Kyung Hee University Sochen-ri, Giheung-eup, Yongin-si, Gyeonggi-do, 449-701, South Korea {umar,hassan,ali,i30000,sylee}@oslab.khu.ac.kr, [email protected]

Abstract. The complex software development scenarios for mobile/ hand-held devices operating in wireless environments require adaptation to the variations in the environment (such as fluctuating bandwidth). This translates to maintenance of service availability in preferably all circumstances. In this paper we propose that a mobile computing system (for hand-held, wireless devices) must be based on the combination of reflection, remote evaluation and code mobility mechanisms such that the communication framework1 allows developers to design disconnectionaware applications which maintain service availability in case of varying circumstances by automatically redeploying essential components to appropriate locations. This not only allows the application to continue executing in varying conditions, but also in entirely disconnected modes.

1

Introduction

The complexity, size and distribution of software today is rapidly increasing. This has complemented the ubiquity of hand-held devices and promoted the growth of distributed systems and applications. One can thus think of numerous, complex software development scenarios which utilize a large number of handheld devices, such as in environment monitoring and surveying, postal services, patient monitoring etc. Such scenarios present intricate technical challenges for middleware technologies [1]. In particular, the middleware must adapt to the variations in the environment (e.g. fluctuating bandwidth) of the mobile device and service availability must be maintained in (preferably) all circumstances [1]. The conventional middleware being heavy, and relatively inflexible, fails to properly address such requirements. The fundamental reason is that traditional middleware systems have been designed adhering to the principle of transparency. Despite the fact that this design [2] [3] has proved successful for traditional distributed systems, this concept has limitations when considered in a mobile environment, where it is neither possible, nor preferred, to hide the implementation details from the user. Also, applications may posses information 1

This research work has been partially supported by KOSEF, Korea, for which Professor Sungyoung Lee is the corresponding author.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 218–223, 2009. c IFIP International Federation for Information Processing 2009 

Framework of an Application-Aware Adaptation Scheme

219

that could facilitate the middleware to perform efficiently. Thus to cope with such limitations, numerous research efforts have been made [4] [5] on designing middleware systems suitable for such environments. However the solutions developed to date do not fully support the necessary level of middleware configurability and reconfigurability that is required to facilitate mobile computing and disconnected operations. Thus in our opinion a simple but dynamic solution is the need of the hour. We propose that a mobile computing system for hand-held devices must be based on the combination of reflection [6], remote evaluation [7] and code mobility [8]. The remote evaluation paradigm not only enables the clients to out-source resource intensive tasks, but also allows more client-side applications (because of their smaller footprint). Reflection is a fundamental technique that supports both introspection and adaptation. In order to maintain service availability in a distributed system, in case of varying circumstances the middleware can utilize code mobility and reflection to automatically redeploy essential components to appropriate locations defined by the application policy. Moreover, such systems can be implemented optimally if the adaptation scheme is application aware, i.e. the framework allows the developer to determine the policies, such as the constraints the components may have, dependency among components, restriction on collocation of components, how the system should react to different circumstances etc. 1.1

Code Mobility and Autonomy of Components

Under favourable circumstances, remote evaluation is one of the most appropriate solutions for mobile, hand-held devices. However in unfavourable conditions, code mobility overcomes the limits of fluctuating bandwidth and disconnections as it allows for specifying complex computations to move across a network from the server to the client end. This way, the services that need to be executed at a platform residing in a portion of the network reachable only through an unreliable link could be relocated and hence maintain Quality of Service. In particular, it would not need any connection with the node that sent it, except for the transmission of the final results of its computation. Also, autonomy of application components brings improved fault tolerance as a side-effect. In conventional client-server systems, the state of the computation is distributed between the client and the server. A client program is made of statements that are executed in the local environment, interleaved with statements that invoke remote services on the server. The server contains (copies of) data/code that belongs to the environment of the client program, and will eventually return a result that has to be inserted into the same environment. This structure leads to well-known problems in presence of partial failures, because it is very difficult to determine where and how to intervene to reconstruct a consistent state. The action of migrating code, and possibly sending back the results, is not immune from this problem. In order to determine whether the code has been received and avoid duplicated or lost mobile code, an appropriate protocol must be in place. However, the action of executing code that embodies a set of

220

U. Kalim et al.

interactions that should otherwise take place across the network is actually immune from partial failure and can permit execution even in the face of absolute disconnection. An autonomous component encapsulates all the state involving a distributed computation, and can be easily traced, check-pointed, and possibly recovered locally, without any need for knowledge of the global state. Thus to introduce the capability of dynamic reconfiguration to achieve the above mentioned objectives, the system must posses certain characteristics, such as, it should be based on a distributed object framework, the system must be able to redeploy/replace2 components3 , it should be able to recover gracefully in the case of faults and there should be a procedure to reconcile components upon reconnection.

2

Framework

In order to narrow down the scope of the problem, we distinguish between voluntary and involuntary disconnection. The former refers to a user-initiated event that enables the system to prepare for disconnection, and the latter to an unplanned disconnection (e.g., due to network failure). The difference between the two cases is that in involuntary disconnection the system needs to be able to detect disconnection and reconnection, and it needs to be pessimistically prepared for disconnection at any moment, hence requiring to proactively reserve and obtain redundant resources (if any) at the client. Here we are only focusing on voluntary disconnections and defer the task of predicting and dealing with involuntary disconnections as future work. Note that the steps for the remedy will be the same, whether the disconnection is voluntary or involuntary. 2.1

Characteristics of the Components and Their Classification

As the system comprises of components as the building blocks we propose that the primary components participating in the reconfiguration must be serializable and they must implement the DisconnectionManagement interface as shown in figure 1. This interface advertises two primary methods; disconnect and reconnect. These methods are invoked by the framework on disconnection and reconnection. The first requirement facilitates the components in relocating themselves while maintaining their state. The second requirement enables the application to prepare for disconnection. The use of disconnect is to compile the component state and transfer it in marshaled form, over the network along, with the code to be executed locally at the client. Similarly, reconnect is used to perform the process of reconciliation among components upon reconnection, details of which are explained in [9]. The components are classified with respect 2 3

The use of a component with reduced (or similar) functionality but the same interface, as the substitute to a (remote) component with reference functionality. Analogous to an object, here a component is referred to as a self contained entity that comprises of both data and procedures. Also data access has not been considered separately because data is always encapsulated in a component.

Framework of an Application-Aware Adaptation Scheme Remote Object <>

Disconnection Management <>

Application Logic (Server Implementation ) <>

Application Logic <>

221

Fig. 1. Hierarchy of interfaces for disconnection-aware components

reconfigure Transferring state (as per policy)

Traversing reference graph

identify references for relocation

disconnect

initialize reconnection complete

Swapping local references with remote references

Connected

Disconnection triggered

disconnection Swapping remote references with local complete references Reconnection triggered

Disconnected

Traversing reference graph

download references Downloading reference implementation (.class files )

reconfigure identify references for relocation Reconnecting

reconnect finalize [off=true]

Transferring state (as per policy)

create instances

Creating local references

transfer state Disconnecting

Fig. 2. State-transition diagram from disconnection/reconnection management

to disconnection (Log, Substitute and Replica) and reconnection (Latest, Revoke, Prime and Merge), details of which are specified in [9].

3

Disconnection Management

When it comes to maintaining service availability in the face of a disconnection, there is a need to relocate the required server code (partially or completely) to the client, in order to make local processing possible. 3.1

Working

The state-transition diagram in figure 2 summarizes the working [9] of the framework. The mechanisms of Reflection, dynamic class loading and linking and serialization (provided by Java [10]) are employed to achieve code mobility. Once a disconnection event is fired, the framework propagates the event to all disconnection-aware references. These references then invoke the disconnect method. This method prepares the reference for the disconnection. Using the mechanisms of introspection each component and each of its contained objects are traversed recursively and a list of references to be relocated is prepared. This list is prioritized with respect to the policy determined by the application designer and each reference is treated as per its classification [9]. The framework maintains a sufficient state of each reference in order to restore the system to the state before disconnection.

222

4

U. Kalim et al.

Related Work

A substantial debt is owed to Coda [4]. The authors were among the first to demonstrate that client resources could be effectively used to insulate users and applications from the hurdles of mobile information access. Coda treats disconnection as a special case of network partitioning where the client may continue to use the data present in its cache, even if its disconnected. Odyssey [5], inspired by Coda [4], proposed the concept of application-aware adaptation. The essence of this approach is to have a collaborative partnership between the application and the system, with a clear separation of concerns. FarGo-DA [11], an extension of FarGo, a mobile component framework for distributed applications proposes a programming model with support for designing the behaviour of applications under frequent disconnection conditions. The programming model enables designers to augment their applications with disconnection-aware semantics that are tightly coupled with the architecture, and are automatically carried out upon disconnection.

5

Prototype Implementation

The framework is developed using J2SE [10] as the fundamental platform for the application; both the client and server components. Java RMI [12] is used for remote evaluation, where as the Reflection classes are used for introspection and reference management when objects are relocated (from the server to the client or vice versa) and references are swapped. Components are notified about disconnection or reconnection via event-notification mechanism. We have implemented a prototype application for patient monitoring and diagnosis service along with the framework libraries in order to verify the feasibility of our proposal. This implementation [9] is part of our ongoing research [13]. The module layout of the framework along with the application is shown in figure 3. It may be noted that the framework comprises of two sub-systems; one operating at the server end and the other at the client end. Unlike [14], our approach being simple and discreet avoids the computational overhead required to determine the component distribution in different circumstances. This is primarily due to the application aware approach, which allows the developer to determine the application policies Core Application Java (J2SE) API Java RMI

Reference Manager

Component Relocator

Resource Monitor

Event Listener

Java Virtual Machine (JVM)

Fig. 3. Module layout of the prototype implementation

Framework of an Application-Aware Adaptation Scheme

6

223

Conclusion

In this paper we proposed a mobile computing middleware-framework for handheld devices which is based on the combination of reflection [6], remote evaluation [7] and code mobility [8]. We have implemented a prototype application [9] along with the framework libraries in order to demonstrate the feasibility of the approach. The results reflect that significant benefits may be obtained by maintaining service availability even in the face of a disconnection.

References 1. Satyanarayanan, M.: Pervasive computing: Vision and challenges. IEEE Personal Communications, 10–17 (2001) 2. Reference-model: Iso 10746-1 - open distributed processing. International Standardization Organization (1998) 3. Emmerich, W.: Engineering Distributed Objects. John Wiley and Sons, Chichester (2000) 4. Kistler, J., Satyanarayanan, M.: Disconnected operation in the coda file system. In: 13th ACM symposium on Operating Systems Principles, pp. 213–225. ACM, New York (1991) 5. Noble, B., Satyanarayanan, M.: Agile application-aware adaptation for mobility. In: 16th ACM Symposium on Operating Systems Principles. ACM, New York (1997) 6. Maes, P.: Concepts and experiments in computational reflection. In: 2nd Conference on Object Oriented Programming Systems, Languages and Applications 7. Stamos, J., Gifford, D.: Remote evaluation. In: Transactions on Programming Languages and Systems, pp. 537–564. ACM, New York (1990) 8. Fuggetta, A.: Understanding code mobility. In: Transactions on Software Engineering, vol. 24, pp. 342–361. IEEE, Los Alamitos 9. Kalim, U.: Technical report: Framework of an application-aware adaptation scheme for disconnected operations, http://oslab.khu.ac.kr/xims/mgrid/techreport-disconn-umar.pdf 10. Sun-Microsystems: Java, http://java.sun.com/j2se/ 11. Weinsberg, Y., Israel, H.: A programming model and system support for disconnected-aware applications on resource-constrained devices. In: 24th International Conference on Software Engineering, pp. 374–384 (2002) 12. Sun-Microsystems: Java rmi, http://java.sun.com/products/jdk/rmi/ 13. Kalim, U., Jameel, H.: Mobile-to-grid middleware: An approach for breaching the divide between mobile and grid environments. In: Lorenz, P., Dini, P. (eds.) ICN 2005. LNCS, vol. 3420, pp. 1–8. Springer, Heidelberg (2005) 14. Marija, M.: Improving availability in large, distributed, component-based systems via redeployment. Technical Report USC-CSE-2003-515, Center for Software Engineering, University of Southern California (2003)

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions J´erˆome H¨arri, Fethi Filali, and Christian Bonnet Institut Eur´ecom Department of Mobile Communication B.P. 193 06904 Sophia-Antipolis, France {Jerome.Haerri,Fethi.Filali,Christian.Bonnet}@eurecom.fr

Abstract. Multipoint Relaying (MPR) is a technique to reduce the number of redundant retransmissions while diffusing a broadcast message in the network, where only a subset of nodes are allowed to forward packets. The selection is based on instantaneous nodes’ degrees, and is periodically refreshed. We propose in this chapter a novel heuristic to select kinetic multipoint relays based on nodes’ overall predicted degree, which is solely updated on a per-event basis. We illustrate that this approach significantly reduces the number of messages needed to operate the protocol, yet with similar broadcast properties that the regular MPR, such as network coverage, number of multipoint relays, or flooding capacity.

1 Introduction Multipoint relaying (MPR, [1]) provide a localized way of flooding reduction in a mobile ad hoc network. Using 2-hops neighborhood information, each node determines a small set of forward neighbors for message relaying, which avoids multiple retransmissions and blind flooding. MPR has been designed to be part of the Optimized Link State Routing algorithm (OLSR, [2]) to specifically reduce the flooding of TC messages sent by OLSR to create optimal routes. Yet, the election criteria is solely based on instantaneous nodes’ degrees. The network global state is then kept coherent through periodic exchanges of messages. Some studies showed the impact of periodic beacons on the probability of transmission in 802.11, or on the battery life [4,3]. This denotes that these approaches have major drawbacks in terms of reliability, scalability and energy consumptions. The next step to their evolution should therefore be designed to improve the channel occupation and the energy consumption. In this chapter, we propose to improve the MPR protocol by using mobility predictions. We introduce the Kinetic Multipoint Relaying (KMPR) protocol, which heuristic selects kinetic relays based on nodes actual and future predicted nodal degrees. Based 

An extended version of this chapter is available as a technical report under the reference RR 05 148 at http://www.eurecom.fr/people/haerri.en.htm  Institut Eur´ecom’s research is partially supported by its industrial members: Bouygues T´el´ecom, France T´el´ecom, Hitachi Europe, SFR, Sharp, ST Microelectronics, Swisscom, Texas Instruments, Thales. D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 224–229, 2009. c IFIP International Federation for Information Processing 2009 

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions

225

on this, periodic topology maintenance may be limited to the instant when a change in the neighborhood actually occurs. Our objective is to show that this approach is able to significantly reduce the number of messages needed to maintain the backbone’s consistency, thus saving network resources, yet with similar flooding properties as the regular MPR. The rest of the chapter is organized as follows. Section 2 describes the heuristic to compute kinetic degrees. Then, in Section 3, we describe the KMPR protocol. Finally, Section 4 provides simulation results, while Section 5 draws some concluding remarks.

2 Kinetic Nodal Degree in MANETs We explain in this section the method for modeling kinetic degrees in MANETs. We model nodes’ positions as a piece-wise linear trajectory and, as shown in [5], the corresponding trajectory durations are lengthy enough to become a valuable cost for using kinetic degrees. Over a relatively short period of time1 , one can assume that each such node, say i, follows a linear trajectory. Its position as a function of time is then described by   xi + dxi · t Posi (t) = , yi + dyi · t where P osi (t) represents the position of node i at time t, the vector [xi , yi ]T denotes the initial position of node i, and vector [dxi , dyi ]T its initial instantaneous velocity. Let us consider node j as a neighbor of i. The squared distance between nodes i and j is defined as 2 2 Dij (t) = Dji (t) = Posj (t) − Posi (t)22     2 xj − xi dxj − dxi = + · t yj − yi dyj − dyi

= aij t2 + bij t + cij , 2 Considering r as nodes maximum transmission range, as long as Dij (t) ≤ r2 , nodes i and j are neighbors. Therefore, solving 2 Dij (t) − r2 = 0

gives tfijrom and tto ij as the time intervals during which nodes i and j remain neighbors. Consequently, we can model nodes’ kinetic degree as two successive sigmoid functions, where the first one jumps to one when a node enters another node’s neighborhood, and the second one drops to zero when that node effectively leaves that neighborhood. Considering nbrsi as the total number of neighbors detected in node i’s neighborhood at time t, we define nbrsi

Degi (t) =



k=0 1



1 1 · 1 + exp(−a · (t − tfk rom )) 1 + exp(a · (t − tto k ))



(1)

The time required to transmit a data packet is orders of magnitude shorter than the time the node is moving along a fixed trajectory.

226

J. H¨arri, F. Filali, and C. Bonnet

t=16

r

i t=4 j

t=20

k

(a) Node i kinetic neighborhood

(b) Node i kinetic nodal degree

Fig. 1. Illustration of nodes kinetic degrees

as node i’s kinetic degree function, where tfk rom and tto k represent respectively the time a node k enters and leaves i’s neighborhood. Thanks to (1), each node is able to predict its actual and future degree and thus is able to proactively adapt its coverage capacity. Fig. 1(a) illustrates the situation for three nodes. Node k enters i’s neighborhood at time t = 4s and leave it at time t = 16s. Meanwhile, node j leaves i’s neighborhood at time t = 20s. Consequently, Fig. 1(b) illustrates the evolution of the kinetic degree function over t. Finally, the kinetic degree is obtained by integrating (1) i (t) = Deg



∞ t

k=nbrs  i k=0

1 1 ( · ) f rom 1 + exp(a · (t − tto 1 + exp(−a · (t − tk )) k ))



(2)

For example, in Fig. 1(b), node i kinetic degree is ≈ 32.

3 Kinetic Multipoint Relays In this section, we describe our Kinetic Multipoint Relaying protocol. It is mainly extracted from the regular MPR protocol. Yet, we adapt it to deal with kinetic degrees. To select the kinetic multipoint relays for node i, let us call the set of 1-hop neighbors of node i as N (i), and the set of its 2-hops neighbors as N 2 (i). We first start by giving some definitions. Definition 1 (Covering Interval). The covering interval is a time interval during which a node in N 2 (i) is covered by a node in N (i). Each node in N 2 (i) has a covering interval per node i, which is initially equal to the connection interval between its covering node in N (i) and node i. Then, each time a node in N 2 (i) is covered by a node in N (i) during some time interval, this covering interval is properly reduced. When the covering interval is reduced to ∅, we say that the node is fully covered. Definition 2 (Logical Kinetic Degree). The logical kinetic degree is the nodal degree obtained with (2) but considering covering intervals instead of connection intervals. In that case, tfk rom and tto k will then represent the time interval during which a node k ∈ N 2 (i) starts and stops being covered by some node in N (i).

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions

227

The basic difference between MPR and KMPR is that unlike MPR, KMPR does not work on time instants but on time intervals. Therefore, a node is not periodically elected, but is instead designated KMPR for a time interval. During this interval, we say that the KMPR node is active and the time interval is called its activation. The KMPR protocol elects a node as KMPR a node in N (i) with the largest logical kinetic degree. The activation of this KMPR node is the largest covering interval of its nodes in N 2 (i). Kinetic Multipoint Relaying (KMPR) The KMPR protocol applied to an initiator node i is defined as follows: – Begin with an empty KMPR set. – First Step: Compute the logical kinetic degree of each node in N (i). – Second Step: Add in the KMPR set the node in N (i) that has the maximum logical kinetic degree. Compute the activation of the KMPR node as the maximum covering interval this node can provide. Update all other covering intervals of nodes in N 2 (i) considering the activation of the elected KMPR, then recompute all logical kinetic degrees. Finally, repeat this step until all nodes in N 2 (i) are fully covered. Then, each node having elected a node KMPR for some activations is then a KMPR Selector during the same activation. Finally, KMPR flooding is defines as follows: Definition 3 (KMPR flooding). A node retransmits a packet only once after having received the packet the first time from an active KMPR selector.

4 Simulation Results We implemented the KMPR protocol under ns-2 and used the NRL MPR [7] implementation for comparison with KMPR. We measured several significant metrics for Manets: The effectiveness of flooding reduction, the delay before the network receives a broadcast packet, the number of duplicate packets and finally the routing overhead. The following metrics were obtained after the population of 20 nodes were uniformly distributed in a 1500 × 300 grid. Each node has a transmission range of 250m. The mobility model we used is the standard Random Mobility Model where we made nodes average velocity vary from 5m/s to 30m/s. Finally, we simulated the system for 100s. Figure 2 illustrates the flooding reduction of MPR and KMPR. Although MPR is slightly more performing than KMPR, we can see that both protocols are close together and have a fairly good flooding reduction, both in terms of duplicate and forwarded packets. Note that the low fraction of relays in Fig 2(b) comes from the rectangular topology, where only a couple of MPRs are used as bridge in the center of the rectangle. On Fig. 3, we depicted the broadcast efficiency of MPR and KMPR. In the simulations we performed, we measured the broadcast efficiency as the time a packet takes before being correctly delivered to the entire network. As we can see, KMPR has a delivery time faster than MPR by 50%. This might comes from two properties of KMPR. Firstly, as described in [6], MPR suffers from message decoding issues, which we corrected in KMPR. Secondly, as we will see in the next figure, KMPR’s backbone maintenance is significantly less than MPR. Therefore, the channel access is faster and the probability of collisions is decreased.

228

J. H¨arri, F. Filali, and C. Bonnet 30

2

MPR KMPR

25

1.6

Forwared Packets ratio

Duplicate Packets ratio

MPR KMPR

1.8

20

15

10

1.4 1.2 1 0.8 0.6 0.4

5

0.2

0 10

15

20

25

30

35

0 10

40

15

20

Average Speed [s]

25

30

35

40

Average Speed [s]

(a) Duplicate reception

(b) Forwarding Nodes

Fig. 2. Illustration of the flooding reduction of MPR and KMPR 5

MPR KMPR

4.5

Delivery Delay [s]

4 3.5 3 2.5 2 1.5 1 0.5 0 10

15

20

25

30

35

40

Average Speed [s]

Fig. 3. Illustration of the broadcast efficiency of MPR and KMPR 5

x 10

4500

4

4000

3.5

3500

3

3000

# hello packets

Routing Overhead [bytes]

4.5

2.5 2 1.5

2500 2000 1500 1000

MPR KMPR

1 0.5 10

MPR KMPR

15

20

25

30

Average Speed [s]

(a) Routing overhead

35

500

40

0 10

15

20

25

30

35

Average Speed [s]

(b) Number of Hello packets

Fig. 4. Illustration of the network load for MPR and KMPR

40

Kinetic Multipoint Relaying: Improvements Using Mobility Predictions

229

In the two previous figures, we have shown that KMPR had similar properties than MPR in term of flooding reduction and delay. Now, in Fig. 4, we illustrate the principal benefit of KMPR: its low routing overhead. Indeed, by using mobility predictions, the routing overhead may be reduced by 75% as it may be seen on Fig. 4(a). We also show on Fig. 4(b) the number of hello messages which drops dramatically with KMPR, yet still preserving the network’s consistency.

5 Conclusions In this chapter, we presented a original approach for improving the well-known MPR protocol by using mobility predictions. We showed that the Kinetic Multipoint Relaying (KMPR) protocol was able to meet the flooding properties of MPR, and this by reducing the MPR channel access by 75% and MPR broadcast delay by 50%. We consequently illustrated that, after having been studied in other fields of mobile ad hoc networking, mobility predictions are also an interesting technique to improve broadcasting protocols.

References 1. Laouiti, A., et al.: Multipoint Relaying: An Efficient Technique for Flooding in Mobile Wireless Networks. In: 35th Annual Hawaii International Conference on System Sciences (HICSS 2001), Hawaii, USA (2001) 2. Clausen, T., Jacquet, P.: Optimized Link State Routing Protocol (OLSR), Project Hipercom, INRIA, France (October 2003), www.ietf.org/rfc/rfc3626.txt 3. Bianchi, G.: Performance analysis of the IEEE 802.11 distributed coordination function. IEEE Journal on Selected Areas in Communications 18(3), 535–547 (2000) 4. Toh, C.-K., Cobb, H., Scott, D.A.: Performance evaluation of battery-life-aware routing schemes for wireless ad hoc networks. In: 2001 IEEE International Conference on Communications (ICC 2001), June 2001, vol. 9, pp. 2824–2829 (2001) 5. Haerri, J., Bonnet, C.: A Lower Bound for Vehicles Trajectory Duration. In: IEEE VTC Fall 2005, Dallas, USA (September 2005) 6. Haerri, J., Bonnet, C., Filali, F.: OLSR and MPR: Mutual Dependences and Performances. In: Proc. of the 2005 IFIP Med-Hoc-Net Conference, Porquerolles, France (June 2005) 7. NRLOLSR, http://pf.itd.nrl.navy.mil/projects.php?name=olsr

The Three-Level Approaches for Differentiated Service in Clustering Web Server Myung-Sub Lee and Chang-Hyeon Park School of Computer Science and Electrical Engineering, Yeungnam University Kyungsan, Kyungbuk 712-749, Republic of Korea {skydream,park}@yu.ac.kr

Abstract. This paper presents three-level approaches for the differentiated Web Qos. A kernel-level approach adds a realtime scheduler to the operating system kernel to keep the priority of the user requests determined by the scheduler in the Web server. An application-level approach which uses IP-level masquerading and tunneling technology improves the reliability and response speed of the Web services. A dynamic load-balancing approach uses the parameters related to the MIB-II of SNMPand the parameters related to the load of the system resources such as memory and CPU to perform load balancing dynamically. These approaches proposed in this paper are implemented using a Linux kernel 2.4.7 and tested in three different situations. The result of tests shows that the approaches support the differentiated services in clustering web server environment. Keywords: Differentiated Qos, Dynamic load balancing, SNMP, MIBII, Realtime scheduler.

1

Introduction

Recently the technologies related to Web QoS(Quality of Service) which guarantees the quality of Web services are becoming more important[1,2,3]. Particularly for the differentiated quality of Web services, Web servers are required to be able to classify contents depending on the importance of the information and the priority of the customer and perform scheduling among the classified contents. However, most Web servers currently provide best effort services on a FIFO (First In First Out) basis only. This means that, when they are overloaded, the servers cannot provide the appropriate services for the premium user [4,5]. Hence, a new server model is needed so that it may guarantee the quality of services by classifying services according to specific criteria and providing differentiated services. Despite the rapid expansion in Web use, the capacity of current Web servers is unable to satisfy the increasing demands. Consequently 

This research was supported by the MIC(Ministry of Information and Communication), Korea, under the ITRC(Information Technology Research Center) support program supervised by the IITA(Institute of Information Technology Assessment).

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 230–235, 2009. c IFIP International Federation for Information Processing 2009 

The Three-Level Approaches for Differentiated Service

231

even if a Web server providing differentiated services is developed, it cannot guarantee perfect service. As a resolution for Web QoS, Web server technologies employing load balancing have been proposed. However, the exiting load balancing technologies for Web servers still have some problems, such as incompatibility between different client application programs[6], inability to process overloaded servers[7], overload when processing HTTP requests/ replies [8,9,10,11], packet conversion overheads[12,13], and etc. This paper proposed three-level approaches for implementing load balancing Web servers the can guarantee differentiated Web QoS. In the first approach, a scheduling module is added to Web server, which assigns a priority to a client request according to its importance, and a realtime scheduler is inserted into the OS kernel so that the assigned priority can be kept in the OS, and thereby more efficient differentiated service Is provided. In the second approach, the load balancing Web server is configured using masquerading and tunneling technologies to distribute the load by class, thereby the reliability and response time of the Web services are improved. The third approach uses the parameters related to the MIB-II of SNMP and the parameters related to the load of the system resources such as memory and CPU to perform load balancing dynamically.

2

A Differentiated Web Service System

The proposed system uses three-level approaches: kernel-level approach, application-level approach, and load-balancing approach. 2.1

Kernel-Level Approach

For the client requests, this approach maintains their priority order determined by the Web server in the OS kernel. This approach is implemented by mapping the scheduling process in the Apache Web server to realtime scheduling processes in the OS kernel. When the client requests come through a Network Interface Card(NIC), the Web server receives them from port 80 in the TCP listening buffer classified them by connection according to specific classification policies(client IP,URL, file name, directory, user authentication, etc.), assigns the proper priority, then inserts them into the corresponding queues. Thereafter, at the same time the requests are being scheduled, the scheduling process in the Web server are mapped one-to-one the processes in the realtime scheduler(Montavista in this paper) in the Linux Os kernel. 2.2

Application-Level Approach

The load balancing Web server proposed in this paper has a high performance and expansibility by enhancing the packet transmission rate and by resolving the bottleneck in the load balancer through the use of IP-level masquerading

232

M.-S. Lee and C.-H. Park

and tunneling. In the proposed system, a single load-balancer distributes the requests to several real servers, which share a common IP address, using a masquerading techniques so that they look like a single server from the outside. IP masquerading hides the real servers behind a virtual server that acts as a gateway to external networks. 2.3

Dynamic Load Balancing Approach

The load balancer analyzes the load of the actual server, by analyzing the utilization of the ethernet and the rate of system load, after processing the MIB-II value that is related to the load of SNMPv2. The systemic load analysis proposed in this paper is the value in which the utilization of the system is added to all the utilization of the ethernet, The equation(1) for load analysis is as follows: T otal loadi = Ethernet U tilizationi + Sys U tilizationi

(1)

The ethernet utilization, given equation (2), means all the traffic amount of input and output of the load balancer. In other words, the sum of all the bit number of packets that transmitted from the sending side and all the bit number that the receiving side received is divided by the whole bandwidth of the network. The variables used to measure the utilization of the ethernet in this paper are listed in table 1. Ethernet U tilizationi = (total bit senti + total bit receivedi )/bandwidth (2) Table 1. The variables of ethernet utilization Item

Explanation

x T ifInOctets ifOutOctets sysUpTime ifSpeed

Previous polling time. Polling interval. The number of received octets. The number of transmitted octets. System boot time. Current network bandwidth.

In order to determine the utilization of an ethernet network, the input and output traffic must be added, and then the sum is to be divided by the maximum transmission speed. The ethernet traffic analysis equation is given by equation (3). (if InOctets(x+t) − if InOctets(x) + if OutOctets(x+t) − if OutOctets(x) ) × 8 × 100 (sysU ptime(x+t) − sysU pT ime(x) ) × if Speed × 10 (3)

The utilization of the system is the sum of memory utilization, CPU average utilization, and disc utilization, as shown in equation (4) The variables used to measure the utilization of the system in this paper are listed in table 2.

The Three-Level Approaches for Differentiated Service

233

Table 2. The variables of system utilization Item

Explanation

memTotalSwap memAvailSwap memTotalReal memAvailReal memTotalFree laLoad x dskTotal dskAvail dskUsed

The The The The The The The The The

total space of swap memory. available space of swap memory. total space of physical memory. available space of physical memory. total space of free memory. average load of CPU for x minutes. total disk space. available disk space. used disk space.

Sys U tilizationi = memSwapLoadi + laLoadi + dskLoadi

(4)

In order to determine the utilization of a system, the memory utilization and CPU utilization and disk utilization must be added. The calculation equation of system utilization is given below: memSwapLoadi = memRealLoadi =

memT otalSwapi − memAvailSwapi × 100 memT otalSwapi

(5)

memT otalReali − memAvailReali × 100 memT otalReali

(6)

laLoad = laLoadx × 100 dskLoadi =

dskU sedi × 100 dskT otali

(7) (8)

Equation (5) is used to calculate the use rate of swap memory using the memTotalSwap value and the memAvailSwap value. Equation (6) is to calculate the utilization of physical memory using the memTotalReal value and the memAvailReal value. Equation (7) is to calculate the average utilization of CPU for x minutes by percent. Equation (8) is to calculate the utilization of disc using the dskTotal value and the dskUsed value.

3

Implementation and Experiment

The differentiated Web service system proposed in this paper is implemented using a Linux Kernel 2.4.7 and PCs with a Pentium-III 800Mhz processor and a 256MB RAM, while the test environment is built by networking three clients, one load balancer, two servers, and one monitoring server. An Apache Web Server 2.4.17 is modified for the Web server, and a Montavista realtime scheduler is added to the Linux kernel. In this paper, HP’s httperf program, and AB(Apache HTTP server Benchmark tool) that measure the response speed of the Apache server are used to evaluate the capability of Web server.

234

M.-S. Lee and C.-H. Park

Fig. 1. Experimental graphs of the ethernet and system utilization

Test are carried out for three cases: when the servers are not overloaded(test 1), when the servers are loaded (test 2), and when the servers are overloaded and some requests are subsequently stopped (test 3). In test 1, the virtual IP address is 165.229.192.14, the total number of connections 50000, the number of concurrent users per session 1, and the number of calls per session 50. Fig. 1(A) presents the results of the ethernet and system utilization which shows the reply changes of Web servers upon the three clients. As the servers are not overloaded, the graphs are almost the same. However, if Web servers capability 1.3 times better than the least connection scheduling, and 1.5 times better than the round-robin scheduling. In test 3, which uses same conditions as test 2. But the script code was formatted with such mechanism that the CPU load of real server 1 would increase. As shown in Fig. 1(C), the proposed mechanism realized 1.3 - 1.6 times better capability than other scheduling algorithms. It was because load balancing was precise owing to the periodical measure of present load of every real server.

4

Conclusion

To implement a differentiated Web service system that provides differentiated services according to information importance of user priority, this paper proposed three-level approaches : a kernel-level approach, an application-level approach and a dynamic load-balancing approach. In the kernel-level approach, a realtime scheduler is added to the kernel, while in the application-level approach, the load balancer is implemented using an IP-level masquerading technique and

The Three-Level Approaches for Differentiated Service

235

tunneling technique. The performance of the load balancing system was tested in three different situations, and the results confirmed that the system supported differentiated Web services.

References 1. Fielding, R., Getys, J., Mogul, J., Frystyk, H., Berners-Lee, T.: Hypertext Transfer protocol HTTP/1.1, IETF (1997) 2. Bhatti, N., Bouch, A., Kuchinsky, A.: Integraing User perceived Quality into Web Server Design. In: Proc. of the 9th International World Wide Web Conference, Amsterdam, Netherlands, pp. 92–115 (2000) 3. Vasiliou, N., Lutfiyya, H.: Providing a Differentiated Quality of Service in a World Wide Web Server. In: Proc. of the Performance and Architecture of Web Servers Workshop, Santa Clara, California, USA, pp. 14–20 (2000) 4. Apach Group, http://www.apache.org/ 5. Bhatti, R., Friedrich, R.: Web Server Support for Tiered Services. IEEE Network, 64–71 (1999) 6. Yoshikawa, C., Chun, B., Eastharn, P., Vahdat, A., Anderson, T., Culler, D.: Using Smart Client to Build Scalable Services. In: USENIX 1997 (1997), http://now.cs.berkeley.edu/ 7. Kwan, T.T., McGrath, R.E., Reed, D.A.: NCSA’s World Wide Web Server: Design and Performance. IEEE Computer, 68–74 (1995) 8. Dahlin, A., Froberg, M., Walerud, J., Winroth, P.: EDDIE: A Robust and Scalable Internet Server (1998), http://www.eddieware.org/ 9. Engelschall, R.S.: Engelschall, Load Balancing Your Web Site: Practical Approaches for Distributing HTTP Traffic. Web Techniques Magazine 3 (1998), http://www.webtechniques.com 10. Walker, E.: pWEB - A Parallel Web Server Harness (1997), http://www.ihpc.nus.edu.sg/STAFF/edward/pweb.html 11. Andresen, D., Yang, T., Ibarra, O.H.: Toward a Scalable Distributed WWW Server on Workstation Clusters. In: Proc. of 10th IEE Intl. Symp. of Parallel Processing (IPPS 1996), pp. 850–856 (1996) 12. Anderson, E., Patterson, D., Brewer, E.: The Magicrouter: an Application of Fast Packet Interposing (1996), http://www.cs.berkeley.edu/~ eanders/magicrouter/ 13. Zhang, W.: Linux Virtual Server Project (1998), http://proxy.iinchina.net/~ wensong/ippfvs 14. Montavista Software, http://www.montavista.com

On the Manipulation of JPEG2000, In-Flight, Using Active Components on Next Generation Satellites L. Sacks1, H.K. Sellappan1, S. Zachariadis2, S. Bhatti2, P. Kirstein2, W. Fritsche3, G. Gessler3, and K. Mayer3 1

Department of Electronic & Electrical Engineering, University College London, London, UK 2 Department of Computer Science University College London, London, UK 3 IABG mbH, Ottobrunn, Germany

1 Introduction This paper describes two approaches to manipulating JPEG2000 frames with programmable and active networks. The first approach is the use of transcoding and the second is intelligent dropping. These two approaches where considered, in particular, for possible deployment with space based platforms; specifically, communication satellites which are not only IP enabled but may host active components. Each approach offers different possibilities and may be suitable for solving overlapping but different problems. The work presented here brings together a number of background technical developments from the communications satellite world, video-coding and intelligent programming models. A detailed look at the developments of satellite based communication platforms shows that there is the possibility of a fully IP enabled system, supporting multicast and quality of service in space. This not only opens a range of possibilities, but presents new challenges. Further, emerging coding schemes open up new possibilities for manipulation of content within the networks. JPEG2000 was used as an example of the next generation of scalable codecs and it has been found that it lends its self easily to helping the kind of problems considered here, although much of these developments can be applied to other coding schemes. The two scenarios considered in detail in this paper – intelligent dropping and transcoding – show two approaches to coping with varying available bandwidth, as will be available with DVB-S2. They also illustrate two approaches to programmable networks. Intelligent dropping is best performed by dedicated systems where queuing is performed (for example routers in the input to link modulators) and so is best managed through Policies. Transcoding, in contrast, is codec specific and needs to be performed with a procedural language; it is thus an excellent example of an application level active networking technology. The possibility of network level active networking is not demonstrated by these, but is considered as a general issue in this context. The work presented here was initiated and funded by the European Space Agency (ESA), European Space Research and Technology Centre (ESTEC) ARTES 1 program. The complete project report will be made available in due time. The brief was to undertake a “study addressing the use of Active and Programmable Networking in Space and Ground Segment, to improve the delivery of Multimedia Services over Satellite”. The project covered a wide range of issues including architectural issues, D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 236–246, 2009. © IFIP International Federation for Information Processing 2009

On the Manipulation of JPEG2000

237

candidate technologies, standards, performance and security. It also included two demonstrations. The work presented here reflects this project with an emphasis on the demonstrations developed (it should be noted that the intelligent dropping scenario discussed in this paper was developed with Mr. Sellappan, as part of his MSc, and is not identical with that used in the study). Section 2 discusses the architectural issues both from the high level and business model perspective and considering some details of the space segment. Section 3 reviews some technologies used in this study. In particular it looks at the evolution of satellite platforms for broadcast media, JPEG20000 and SATIN, the mobile code technology used here. Section 4 reviews a number of applications for active networking in this context and outlines in more detail the two target scenarios of intelligent dropping and transcending.

2 Architectural Issues To understand the application of active networking to satellite telecommunications it is important to develop a high level architecture and business model, describing both ways in which the technologies may be applied and the roles of organisations and players involved. It is also important to consider the detailed architecture of the space platform, as this is one of the least versatile components and has the most stringent performance requirements. 2.1 The High Level Architecture The high level architecture and context of the technologies discussed here is not well defined; but is open to a number of scenarios, depending on business and application needs. To understand the overall concept, we define the basic service scenario in which some media (still images or a video stream) is sent from a single source to one or several users; and transits a satellite link. There may or may not be wide area or local area networks on the user side as the users may, for example, be within an organisation owning a satellite receive, they may be using a VSAT device or the satellite link may be providing a distribution system between two internet service providers. In our context we define the following roles (which, of course, may be taken by one or several players depending on the details of the business model). The Media Provider owns the content which may be in any format. Optionally, the media provider may participate ‘actively’ in the service by having a server which can encode the content in JPEG2000 format. As an alternative, the server may provide content in other formats which are encoded on the fly at the satellite link ingress. For the intelligent dropping scenario, the ingress point has to be involved in order to prioritise packets and add information to the data stream to support this. In either case, the satellite is considered there to be an active component in which specific flows can be directed to programmable components for treatment (e.g. trancoding or intelligent dropping). Finally, the stream may either be re-coded to it original format at an egress active component, or may be sent directly to a terminal devices which can either directly decode the content through resident or downloaded components. The final role in this high level model is the Active Components Provider which hosts the active components to be diploid in each appropriate node as required. In practice this role may be played by a third party, the content provider or the satellite service provider.

238

L. Sacks et al.

Media Provider Ingress Nodes

Egress Node Satellite Node

Active Component Provider

Users Fig. 1. High level Architecture

2.2 The Satellite Platform Architecture For this study our primary focus was on the functional description of the satellite platform. For this we defined a detailed architecture as a starting point for developing a standard and the appropriate functional requirements. This architecture was developed so as to define the full context for active services on a satellite platform. However we did not define control and management concepts for this. The Active components are expected to be hosted in a virtual machine run time environment such as the JavaVM. Within this context we defined four types of component. The Dynamic Components are those which constitute the active service and are deployed on demand. To support these, we defined two sets of components which interact via the same semantics and interfaces as the dynamic components; the Interface and Resident components. The Interface components allow the service to interact with the infrastructure of the satellite and the Resident components allow the service to receive and send the stream data. The final class of components in the execution environment are those which manage the location and deployment of the active components themselves. Around the execution environment is the transport system and the platform infrastructure. The transport system comprises the DVB and MPEG (multiplex) capabilities; and some sense of switching or routing capability. The transport system has to be capable of re-directing appropriate flows to the active components as required and so would integrate with an active routing technology (which was not explored in this study). Further, the transport system can be controlled through policies from the active components. The control through policies represents a second, widely accepted, view of active networking and thus our system facilitates both application level active networking and policy based programmability. Both of these are useful and have been explored in this study. The infrastructure of the satellite platform is accessed to retrieve and, possibly, manipulate key capabilities. For example the action of an active

Deployer/Registrar Registrar Deployer/

Edu.UCL.satin … Edu.UCL.satin …

JVM:J2ME:CDC

239

JNI

On the Manipulation of JPEG2000

Sat Platform

IF-LMU Platform IF

PAN Resources Dynamic -LMU Dynamic -

Res -LMU Flow - IF Processing Resources

‘IP’ Layer Comms Control

Encap/ Decap

demod demod

Switching

mod mod

Fig. 2. Satellite Active Architecture

component may need to know the quality of the down link (discussed in detail below), the state of IP queues in the switch/router or the current loading on the execution environment resources (CPU and Memory). The function of the resident components is to provide consistent interfaces to the dynamic components, which preserving the security and integrity of the satellites systems. Although components to be deployed may be checked ‘off line’ and will be certified, it is still important that the platform is capable of protecting its self. Thus the Interface components would not just provide APIs, but should restrict and schedule access to the platform; and should monitor for integrity issues such as deadlock and livelock situations.

3 Technologies This section discusses the technologies used to demonstrate transcoding and intelligent dropping with JPEG2000. The overall project reviewed a range of possible technologies, both for media transport and programmable network implementation. The SATIN mobile code platform was selected as an interesting example of a framework for reasons discussed below. JPEG2000 was selected as an interesting scalable codec, compatible with a wide range of future applications. 3.1 The Programmable Component System: SATIN We used the SATIN [1] platform to implement our active network system. SATIN is a component metamodel, which can be used to build adaptable systems. It is instantiated

240

L. Sacks et al.

as a middleware system, which can adapt itself or component based applications which run on top of it. Its use as an active networking platform was initially outlined as a case study in [2]. SATIN uses the principles of reflection and logical mobility to offer adaptation primitives, and offers them as first class citizens to applications. Reflection offers a meta-interface to the system, that allows SATIN applications discover which components are available locally, to be notified of changes in component availability, to load and discard components, to discover the interfaces that they offer and to read and write metadata attached to a component. Logical mobility allows SATIN systems to send and receive components, classes, objects and data. SATIN was designed for mobile devices and devices with limited resources, such as mobile phones and PDAs, and is implemented using Java 2 Micro Edition (Connected Device Configuration / Personal Profile). It occupies 150329 bytes of memory, and provides the following services which are relevant to an active networking system: •

• • • •

Reflection. The use of reflection allows the system to reason about what it can currently do, dynamically invoke components, use an event service which notifies when there are changes in component availability, and to discover new APIs that are offered by components. Logical Mobility. The use of logical mobility allows components to be dynamically transfered from one SATIN node to another. Dynamic Component Instantiation. Components can be dynamically discovered, instantiated and invoked. Advertising and Discovery. SATIN provides an adaptable framework for component advertising and discovery. Security. SATIN nodes can employ digital signatures and trust mechanisms to verify incoming components. Moreover, SATIN uses the Java sandbox to instantiate components in.

In conclusion, SATIN is a small footprint middleware system that can be used to build adaptable systems. It provides a minimal runtime API that can be used to discover, request, deploy and invoke new components and an interface to reason about what individual components or the system itself can do. 3.2 The JPEG2000 Codec The final component used in this study was the JPEG2000 scalable codec. The fast expansion of multimedia and Internet applications led to the development of a new still image compression standard, JPEG2000 [3]. This image coding system uses latest compression techniques based on wavelet technology. Designed to complement the older JPEG standard, JPEG2000 provides low bit-rate operation, error resilience and superior compression index. Some of the important features of JPEG2000 are lossless and lossy compression, progressive transmission by resolution or component and region-of-interest (ROI) coding. In JPEG2000, images are typically divided into multiple tiles and encoded independently. This is done to avoid the need for complex and powerful processors when loading and encoding huge images in hardware. The Discrete Wavelet Transformation (DWT) is designed for this purpose. A tile-component is referred to a tile which consists of only one colour component. Each tile-component is then further divided down to different

On the Manipulation of JPEG2000

241

resolutions and sub-bands with the use of DWT. Each resolution is then divided into multiple precincts which identify a geometric position of a tile-component of an image. Furthermore, each sub-band at each resolution is divided into multiple code-blocks, which will be coded into individual packets. The packets are arranged in the codestream following a particular progression order specified at the encoder. Motion JPEG2000 (MJ2) has been defined in part III of the JPEG2000 standard [5] for compression and encoding of time sequences of images, like video streams. The standard was developed to generate highly scalable compressed video, which can be easily edited. Thus, MJ2 does not include motion compensation and every frame in the video stream is individually encoded [6]. The concept of intra-frame coding reduces the complexity of inter-frame interdependencies found in other video codec. Since each frame is treated like a still image, a single codec can be used for both JPEG2000 still pictures and MJ2 video compression and encoding.

Pixel Depth (SNR) coding

Code Stream Æ Sequence Progressively resolution coding

Fig. 3. JPEG2000 Coding by Resolution and SNR [4]

A key feature of JPEG2000 is that it supports two forms of scalability. The first SNR scaling can progressively reduce the amount of information per pixel. This may be performed in a number of ways, on the various coding layers. The affect of SNR scaling is shown in Figure 4. The second form of scaling is progressive resolution coding. This effectively changes then size of the transmitted frame. Illustrated in Figure 3 is the organisation of the JPEG2000 code stream. Four levels of resolution coding are shown. The dark square is a low resolution image, when combined with the neighbouring three code blocks; a higher resolution image is formed. This is then repeated with the next two sets of three code blocks. At the same time the number of bits per pixel (bpp) represents the SNR coding depth. 3.3 Satellite Transport At present, the trend of satellite communication is heading towards deployment of next generation broadband satellites that provides multimedia applications with high demands for quality and availability of service. In line with the anticipated advancement and to meet the growing demand for high data rates, much research has been focused on regenerative and full on board processing (OBP) payloads, advance mesh

242

L. Sacks et al.

antennae, high speed communication system, optical satellite links, high speed transponders and miniaturisation of satellite components [7, 8]. The first regenerative satellite payloads are operational or under construction, performing on-board MPEG-2 cell multiplexing and switching (e.g. Skyplex or AmerHis) or ATM cell switching (e.g. WEST and WEB 2000 architecture), and the UK-DMC satellite even implements an IP stack. It is foreseeable that future communication satellites will implement an IP stack and on top of this a programmable network platform. Future generations of communication satellites may support a range of new capabilities. The most immediate is the emergence of DVB-S2[9], an effective upgrade of the current Digital Video Broadcast over Satellite (DVB-S) transport technology, which is the dominant means for transporting most broadcast video to date. DVB-S2 includes adaptive Forward Error Correction (FEC) which means that the up and down link data capacities can adapt to changes in fading, for example from varying cloud cover. This also means, however, that both the up and down link transport capacities may independently vary; increasing with weaker FEC and contracting as stronger FEC is required. Each FEC frame has fixed size of either 64,800 bits for normal FEC frame or 16,200 bits for short FEC frame. Depending on the FEC code rates, the capacity of the frames may be anything between these limits. Further, work is already progressing on IP enabled capabilities for satellites. Although this may not be an obvious thing by its self, combined with developments in tuneable, multiple footprint platforms, we see a model of a satellite which not only may have to do routing, but multicast and some amount of Quality of Service management. Standards for DVB over IP are already in progress – and so we see the emergence of true IP based broadcast architecture.

4 Active Services in Satellites A wide range of applications scenarios can be considered for application in the architecture described above. The following is a list of applications considered in some detail in the study. • • •

•

•

Reliable Multicast (RM) scenario: In the RM scenario, active networking may be used to load RM protocol instances and FEC codecs to relevant network nodes on demand while runtime. Intelligent Dropping (ID) scenario: In the ID scenario, intelligent dropping processes (or just policies) that evaluated the priority of packets or streams are loaded dynamically via PAN to satellite nodes that have to drop packets. Transcoding (TC) scenario: In the TC scenario, via active networking transcoders are controlled and loaded dynamically by satellite network nodes in order to adapt parameters (e.g. codec, data rate, etc.) of multimedia streams to network conditions or user requirements. MHP scenario: In the Multimedia Home Platform (MHP) scenario an intelligent process in the satellite routes certain MHP content only to specific spot beams and performs user feedback aggregation. via active networking, the intelligent process could be loaded by the satellite and adapted to new applications. MPEG-4 scenario: In the MPEG-4 multiplexing scenario content from different sources composing a single MPEG-4 scene are multiplexed in the satellite. via

On the Manipulation of JPEG2000

• •

243

active networking, the composition software can be loaded by the satellite and controlled from the base station. Advanced network management: In the advanced network management scenario, management or monitoring software is adapted on demand to operator needs via a active networking system. Advanced caching scenario: Caching software is loaded, updated, and controlled on demand via a active networking system in order to adapt the caching software to applications and services.

These scenarios represent a broad range of; applications, network and policy level programmable network problems. The scenarios described below focus on application level and policy level approaches. Both cases are to do with manipulating JPEG2000 images. Both where implemented on PC based test-beds and used the Java JJ2000 implementation [10] available from EPFL. At this time, there is no reference satellite platform defined for developing and testing the kind of applications discussed here; and one of the outputs from the Arties 1 project was the recommendation that such a platform be developed. 4.1 The Transcoding Scenario The issue of transcoding has been widely explored (see for example [11]). This transcoding scenario considers a stream of JPEG2000 images, possibly forming a moving image and which requires that a constant frame rate is preserved (or considers cases where the download latency is just to slow for ‘full fat’ images). Issues impeding this can arise in a satellite situation when, for example, the down-link FEC reduces the available link bandwidth. It may also occur if there is routing in the satellite platform, which may have multiple foot prints. There are then two options; reduce the resolution or change the information depth (SNR) of the picture as illustrated in Figure 4. The former of these may be preferred if, for example, the terminal devices has a small screen.

Fig. 4. SNR Progressive coding (3.55bpp, .355bpp, .0355bpp and -0.009bpp)

To implement this application the following functions are performed, with regard to the reference architecture (shown in Figure 1): • •

The Media Provider may re-code the images in JPEG2000 format. This may, optionally, be performed on the Ingress Node. The Satellite Node hosts the active components, loaded from the Active Component Provider.

244

•

L. Sacks et al.

If the stream is encoded at the Ingress Node, it should be decoded back to the originating format at the Egress Node. Otherwise the User should have the appropriate decoder.

On the satellite node, the active component is loaded as a Dynamic Component. It should then have access to the link capacity from the modulator (Figure 2) to discover the available down link capacity and decide how to transcode the image. It should, of course, also know the rate at which the images are being sent for the target stream and the overall downlink load. Implementation of the transcoding component may be approached in a number of ways. Within the scope of the ARTIS project, and expedient approach was taken and the encoder and decoder provided with [10] where used. However, the code streams of JPEG2000 are so designed that significant efficiency gains may be had. The resolution transcoding is the most straightforward as can be seen from Figure 3, this requires simply that the code stream is truncated at the right place. In this respect, it is similar to the intelligent dropping scenario below. SNR progressive scaling is more complex and detailed information about each tile is required. Never the less, these are all integer operations and so can be quite efficient from the performance perspective. 4.2 The Intelligent Dropping Scenario As with the transcoding scenario, intelligent dropping may be appropriate when constant frame rates are required in the presence of congestion or reduced link capacity. However it maybe that there are queuing mechanisms involved which by default drop packets randomly – where by randomly we mean, with out regard to the contents of the packets. The impact of this can be seen in Figure 5 in which the first image is the reference graphic and the second has 1% of packets lost at random. Of course, it is possible that dropping packets has little impact and the figure here shows a bad case, although not unusual.

Fig. 5. Intelligent Dropping (0% loss, 1% Random loss, 80% intelligent dropping)

The effect seen, can be understood with reference to Figure 3. It can be seen that if a packet containing the lowest resolution ‘thumbprint’ of the coded image is lost, recovering the graphic will be almost impossible and the impact becomes progressively less server as the outer code blocks are lost. Thus, prioritising loss progressively, following the flow of the codec would allow a more graceful information loss; and allowing for this was part of the initial intent of the JPEG2000 technology. The last image in Figure 5 has 80% of its data dropped, but using low priority packets.

On the Manipulation of JPEG2000

245

Architecturally, the implementation of intelligent dropping is similar to the transcoding scenario. The two key changes are the introduction of an intelligent, adaptive encapsulateor at the satellite ingress point and the control of the dropping mechanism in the space segment. These are shown in Figure 5. Intelligent Dropping Service

Link Quality & Congestion Feedback

Link quality Feedback

Satellite (Active Node)

Satellite RF Link

Intelligent Dropping Service

Video Recorder (Source)

Motion JPEG 2000 Encoder

Satellite TX Terminal

Active Encapsulator

Satellite RX Terminal

LDPC & FEC feedback (max DFL)

Active Decapsulator

Motion JPEG 2000 Decoder

Video Player (Sink)

Fig. 6. The Intelligent Dropping Architecture

In this architecture [12], the active encapsultor has two jobs. The first is to decide, depending on things like link quality, how to place the JPEG2000 code stream in the IP packets. There is an important trade off here as, on the one hand, the finer the granularity this is done at the more precisely the available band width can be matched; but the overheads are increased. Too course a granularity and the quality of the image will be degraded too quickly. The second job is to add a header which describes the priority of the packets as well as which is the; first, last and sequence number of the packets of a given video frame. The ingress point can drop packets in response to the uplink quality as can the satellite platform its self. On the satellite platform, the condition of packet dropping can be controlled with policies transported via any policy management framework. Finally, the satellite egress point has to extract and reassemble the code stream.

5 Conclusions This paper has reviewed the issues which arise when considering the role of programmable and active networking in the context of satellite based telecommunications. We have motivated the plausibility of such an architecture by considering the evolutionary path of telecommunications satellites. We have also tried to motivate the advantages of considering placing active components on the satellites themselves. Indeed, throughout our project trying to understand where the business advantage come has been more difficult then considering its technical viability. However, if we consider the combination of factors such as the adaptive FEC, multiple, tuneable footprints with onboard routing or switching, the importance of on-board processing

246

L. Sacks et al.

becomes more apparent. Finally, it is important to note that the timescales of satellite deployment are long compared to those in the fixed network world, so it is very difficult to know which application level protocols will be used once the satellites are commissioned. Thus, if it is important to have intelligence in the satellite at all, it is important that that intelligence is adaptable both to protocols and codecs which might emerge in the future; and can adapt to local conditions (such as link capacity variation and congestion). To emphases these issues of adaptation we have both used a codec which is very much in development and have explored how adapting to local conditions can be used to improve application performance in the face of degraded transport (down link) quality.

References [1] Zachariadis, S., Mascolo, C., Emmerich, W.: SATIN: A Component Model for Mobile Self- Organisation. In: International Symposium on Distributed Objects and Applications (DOA), Agia Napa, Cyprus. Springer, Heidelberg (2004) [2] Zachariadis, S., Mascolo, C., Emmerich, W.: Exploiting Logical Mobility in Mobile Computing Middleware. In: Proceedings of the IEEE International Workshop on Mobile Teamwork Support, Collocated with ICDCS 2002, pp. 385–386 (July 2002) [3] Boliek, M., Christopoulos, C., Majani, E. (eds.): JPEG 2000 Part I Final Draft International Standard (ISO/IEC FDIS15444-1), ISO/IEC JTC1/SC29/WG1 N1855 (August 2000) [4] Marcellin, M., Gormish, M., Bilgin, A., Boliek, M.: An Overview of JPEG 2000. In: Proceedings of IEEE Data Compression Conference, Snowbird, Utah (March 2000) [5] Information technology - JPEG 2000 image coding system - Part 3: Motion JPEG 2000, ISO/IEC 15444-3 (2002) [6] Dagher, J., Bilgin, A., Marcellin, M.: Resource-Constrained Rate Control for Motion JPEG 2000. IEEE Transactions on Image Processing 12(12), 1522–1529 (2003) [7] Iida, T., Suzuki, Y.: Communications satellite R&D for next 30 years. Space Communications 17, 271–277 (2001) [8] Verma, S., Wiswell, E.: Next Generation Broadband Satellite Communication Systems. In: 20th AIAA International Communication Satellite Systems Conference and Exhibit, Montreal, Quebec, May 12-15 (2002) [9] ETSI: Final Draft EN 302 307 (v.1.1.1) Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications (DVB-S2) (January 2005), http://www.etsi.org [10] http://jj2000.epfl.ch/ [11] Gibson, J.D.: Multimedia Communications: Directions and Innovations. Academic Press, London (2000) [12] Sellappan, H.K.: Active Networks in Satellite Communications: Intelligent Dropping Scenario for Motion JPEG 2000 Transmission MSc. Dissertation, UCL 2005 (2005)

TAON: A Topology-Oriented Active Overlay Network Protocol Xinli Huang, Fanyuan Ma, and Wenju Zhang Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai, P.R. China, 200030 {huang-xl,ma-fy,zwj03}@sjtu.edu.cn

Abstract. Built upon overlay topologies, Peer-to-Peer (P2P) networks behave in an ad-hoc way, conduct application-layer routing, enable usercustomized decentralized resources sharing, and thus can be taken as an emerging representative of Active Networks. An important problem in current unstructured P2P networks is that, however, existing searching mechanisms do not scale well because they are either based on the idea of flooding the network with queries or because they know very little about the nature of the network topology. In this paper, we propose the Topology-oriented Active Overlay Network (TAON) which is an efficient, scalable yet simple protocol for improving decentralized resources sharing in P2P networks. TAON consists of three novel components: a Desirable Topology Construction and Adaptation algorithm to guide the evolution of the overlay topology towards a small-world-like graph, a Semanticbased Neighbor Selection Scheme to conduct an online neighbor ranking, and a Topology-aware Intelligent Search mechanism to forward incoming queries to deliberately selected neighbors. We deploy and compare TAON with a number of other distributed search techniques over static and dynamic environments, and the results indicate that TAON outperforms its competitors by achieving higher recall rate while using much less network resources, in both of the above environments.

1

Introduction

In contrast to traditional data networks, Active Networks not only allow the network nodes to perform computations on the data but also allow their users to inject customized programs into the nodes of the network, that may modify, store or redirect the user data flowing through the network [1]. These programmable networks open many new doors for possible applications that were unimaginable with traditional data networks. For example, Peer-to-Peer (P2P) overlay networks conduct application-layer routing in an ad-hoc way, enable user-customized decentralized resources sharing, and thus can be taken as an emerging representative of Active Networks. 

This research work is supported in part by the the National High Technology Research and Development Program of China (863 Program), under Grant No. 2004AA104270.

D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 247–252, 2009. c IFIP International Federation for Information Processing 2009 

248

X. Huang, F. Ma, and W. Zhang

The most dominate application in use on current P2P networks is large-scale distributed file sharing, especially the Web-based search applications. YouSearch [2] maintains a centralized search registry for query routing, making it difficult to adapt the search process to the heterogeneous and dynamic contexts of the peer users. A more distributed approach is to completely decentralize search, as in Gnutella [3]. Queries are sent and forwarded blindly by each peer. But since the peer network topology is uncorrelated with the interests of the peer users, peers are flooded by requests and cannot effectively manage the ensuing traffic. Adaptive, content based routing has been proposed to overcome this difficulty in the file sharing setting. NeuroGrid [4] employs a learning mechanism to adjust metadata describing the contents of nodes. A similar idea has been proposed to distribute and personalize Web search using a query-based model and collaborative filtering [5]. Search however is disjoint from crawling, making it necessary to rely on centralized search engines for content. The major limitation of these systems lies in their relatively poor search performance and ignorance of the nature of the underlying topology, which results in fatal scaling problem. To address the scalability limitations mentioned above, we in this paper consider the Web information retrieval problem and propose a Topology-oriented Active Overlay Network (TAON ) protocol. TAON allows for symbiotic interactions of Web crawling and searching, whereby a peer can vertically adapt to its users’s search interests, while horizontally peers can achieve better coverage by learning to collaboratively route and respond to queries. TAON consists of three key components: a Desirable Topology Construction and Adaptation algorithm to guide the evolution of the overlay topology towards a power-law graph, a Semantic-based Neighbor Selection scheme to conduct an online neighbor ranking, and a Topology-Aware Intelligent Search mechanism to forward incoming queries to deliberately selected neighbors. We predict that the resultant topology for such a network is a small world, allowing for any two peers to reach each other via a short path (small diameter) while maximizing the efficiency of communications within clustered peer communities. To evaluate the performance gains of TAON, we will deploy and compare TAON with a number of other distributed search techniques over static and dynamic environments, through extensive simulations. The rest of this paper is organized as follows: In Section 2, we detail the design of TAON. In Section 3 and 4, we present the experimental setup and the simulation results respectively. We conclude this paper in the last section.

2

TAON Design

The objective of TAON is to help the querying peer to find the most relevant answers to its query quickly and efficiently rather than finding the largest number of answers. To achieve this goal, TAON exploits both the semantic and geographical locality to construct small-world-like peer communities, by incorporating three novel techniques presented below respectively, in a very brief fashion due to the space limitation.

TAON: A Topology-Oriented Active Overlay Network Protocol

2.1

249

Desirable Topology Construction and Adaptation

The Desirable Topology Construction and Adaptation algorithm is the core component that connects the TAON node to the rest of the network. To obtain desirable overlay topology and sequentially adapt it towards a better one dynamically, we prefer to keeping the out-degree of the network following a powerlaw distribution, and expect that this unique topological property, together with the other two novel techniques (to be addressed in the Section 2.2 and 2.3), will produce the desired “small-world ” phenomena [6]. We achieve the goal by adding and deleting links in a way that the total number of outgoing links at each node is conserved. We choose a node A at random, build a link from this node to a new node B chosen by a certain metric, and then immediately delete an existing link say with C to conserve links at A. In addition, by increasing the fraction of links rewired we get the required short path length. If the fraction of links deleted and rewired is p, then for very small p the average path length L(p) comes down by orders of magnitude and is close to that of a random graph whereas the clustering coefficient C(p) is still much large similar to that of a regular graph [7]. 2.2

Semantic-Based Neighbor Selection

To decide to which peers a queries will be sent, a node ranks all its neighbors with respect to a given query. To do this, each node maintains a profile for each of its neighbor peers. The profile contains the list of the most recent past queries, which peers provided an answer for a particular query as well as the number of results that a particular peer returned. According to [8], we use the Cosine Similarity function below to compute the similarity between different queries:  (q ∗ qi )  sim(q, qi ) = cos(q, qi ) =  , (1) (q)2 ∗ (qi )2 where sim(q, qi ) is the similarity of the query q and the query qi , calculated by the cosine of the angle between the two vectors q and qi . Based on this similarity between queries, we then use the relevance function in [9] to rank the neighbor peers of a node P0 following:  RP0 (Pi , q) = sim(qj , q)α ∗ S(Pi , qj ), (2) j

where α is a parameter allowing us to add more weight to the most similar queries, j is the ID of each query answered by Pi , S(Pi , qj ) is the number of results returned by Pi for query qj , RP0 (Pi , q) denotes the relevance rank function of Pi and is used by P0 to perform an online ranking of its neighbors. The R function allows us to rank higher the peers that returned more relevant results, and thus realizes the semantic-based neighborhood optimization. In addition, we also make this semantic-based better neighbor selection strategy be orthogonal to the physical proximity based strategy that is integrated into the Topology-aware Intelligent Search mechanism (Section 2.3).

250

2.3

X. Huang, F. Ma, and W. Zhang

Topology-Aware Intelligent Search

To make the TAON node in the overlay topology being aware of the physical proximity in the underlying network, we divide its neighbors into local neighbors and global neighbors. The fraction of neighbors that are local, called the proximity factor (α), is a key design parameter that governs the overall structure of the topology. Different values of α let us span the spectrum of this class of overlay topologies. In between these two ends of the spectrum, we foresee that the topologies, with many local links and a few global links, have desirable properties: They not only have low diameter, large search space and connectedness, but are also aware of the underlying network and can utilize these links better than the both topologies. We aim to find a suitable balance between these advantages by simulation through populating the range of α value. The combination of the Semantic-based Neighbor Selection and the Physical Proximity based Neighbor Discrimination ensure that increasing queries from a node P can be answered by its neighbor nodes or their nearby nodes in the overlay topology, and that many such answerers may be geographically close to the requester. These properties are especially useful for reducing response time and network resources consumption. Based on these techniques, we then develop a novel search mechanism, called Topology-aware Intelligent Search, to conduct a kind of bi-forked and directed search as follows: – flooding the incoming queries to all local neighbors with a much smaller TTL value than that of the standard Gnutella protocol. – forwarding the incoming queries to the first k best global neighbors using multiple random walks coupled with the mechanisms of termination checking and duplication avoiding proposed in [10]. Here, all the local and global neighbors are beforehand selected and optimized using the Semantic-based Neighbor Selection strategy, and are discriminated by their physical proximity.

3

Experimental Setup

TAON is designed to perform efficient, scalable yet simple Web-based search by exploiting the locality semantically and geographically. Hence, our experimental evaluation focuses on four performance metrics below: – recall rate, that is, the fraction of documents that the search mechanisms retrieves. – search efficiency, that is, the number of messages used to find the results as well as the required time to locate the results. – utilization of underlying network, measured by the traffic load on the links in the underlying network, according to [11]. – small-world statistics, as a indicator to show whether the network topology is being evolved towards a “small-world” graph, and measured using the factors of clustering coefficient and diameter.

TAON: A Topology-Oriented Active Overlay Network Protocol

251

Based on the PLOD topology generator [12], we create a simulator (in which the TAON protocol is implemented and deployed) that initiates a power-law overlay topology and allows users to run their queries over real indexes obtained from actual distributed Web crawlers. Our simulator takes a snapshot of the network for every time step, during which all of the peers process all of their buffered incoming messages and send them following the TAON protocol. This may include the generation of a local query as well as forwarding and responding to the queries received by other peers.

4

Simulation Results

In this section, we describe a series of experiments that attempt to investigate the performance gains of TAON over its competitors of a) Breadth First Search (BFS, i.e., Gnutella), b) Random Walks (RW), and the Most Results in Past (MRP, i.e., the technique proposed in [13]).

Fig. 1. Comparisons of Recall Rate (a), Messages (b), and Physical Latency to Results (c) between the four search techniques, and Small-World Statistics of the TAON network (d)

Fig.1.(a) and (b) indicate that BFS requires almost three times as many messages as its competitors with around 1, 230 messages per query. In contrast, all of RW, MRP and TAON use dramatically less messages but TAON is the one that finds the most documents. In addition, the curves in Fig.1.(c) shows clearly that TAON results in smaller physical latency than the other three techniques, which means a better utilization of the underlying physical network.

252

X. Huang, F. Ma, and W. Zhang

Fig.1.(d) shows that the diameter remains roughly equal to the initial random graph diameter, while the clustering coefficient increases rapidly and significantly, stabilizing around a value 100 ∼ 125% larger than that of the initial random graph. These conditions define the emergence of a “small world ” topology in the TAON network. This is a very interesting finding, indicating that the peer interactions cause the peers to route queries in such a way that communities of users with similar interests cluster together to find qualified results quickly, while it is still possible to reach any peer in a small number of steps.

5

Conclusions

The TAON protocol we proposed in this paper provably results in significant performance gains of both enhanced search efficiency and reduced traffic load, by explicitly guaranteeing the desirable topological properties like small-world properties, and by exploiting the semantic and geographical locality to form better neighborhood and peer communities dynamically.

References 1. David, L., David Sincoskie, W., Wetherall, D.J., Minden, G.J.: A Survey of Active Network Research. IEEE Transactions on Communications (1997) 2. Bawa, M., et al.: Make it fresh, make it quick searching a network of personal webservers. In: Proc. of 12th WWW (2003) 3. http://rfc-gnutella.sourceforge.net 4. Joseph, S.: Neurogrid: Semantically routing queries in Peer-to-Peer networks. In: Proc. of Intl. Work. P2P Computing (2002) 5. Pujol, J., Sang¨ uesa, R., Berm´ udez, J.: Porqpine: A distributed and collaborative search engine. In: Proc. of 12th WWW (2003) 6. Watts, D., Strogatz, S.: Collective dynamics of ‘small-world’ networks. Nature 393, 440–442 (1998) 7. Puniyani, A.R., Lukose, R.M., Huberman, B.A.: Intentional Walks on Scale Free Small Worlds. LANL archive: cond-mat/0107212 (2001) 8. Baeza-Yates, R.A., Ribeiro-Neto, B.A.: Modern Information Retrieval. ACM Press Series/Addison Wesley, New York (1999) 9. Zeinalipour-Yazti, D., Kalogeraki, V., Gunopulos, D.: Exploiting locality for scalable information retrieval in peer-to-peer networks. Information Systems 30(4), 277–298 (2005) 10. Lv, C., et al.: Search and replication in unstructured peer-to-peer networks. In: Proc. of ACM International Conference on Supercomputing (ICS) (June 2002) 11. Ripeanu, M., Foster, I., Iamnitchi, A.: Mapping the Gnutella Network: Properties of Large Scale Peer-to-Peer Systems and Implications for System Design. IEEE J. on Internet Computing, Special Issue on Peer-to-peer Networking (2002) 12. Palmer, C.R., Steffan, J.G.: Generating Network Topologies That Obey Powers. In: Proc. of Globecom 2000, San Francisco (November 2000) 13. Yang, B., Garcia-Molina, H.: Efficient Search in Peer-to-Peer Networks. In: Proc. of Int. Conf. on Distributed Computing Systems (2002)

A Biologically Inspired Service Architecture in Ubiquitous Computing Environments Frank Chiang and Robin Braun Faculty of Engineering, University of Technology Sydney, Broadway, NSW 2007, Australia [email protected]

Abstract. This paper describes the design of a scalable bio-mimetic framework in the management domain of complex Ubiquitous ServiceOriented Networks. An autonomous network service management platform - SwarmingNet is proposed. In this SwarmingNet architecture, the required network service processes are implemented by a group of highly diverse and autonomic objects. These objects are called TeleService Solons as elements of TeleService Holons, analogue to individual insects as particles of the whole colony. A group of TSSs have the capabilities of fulfilling the complex tasks relating to service discovery and service activation. We simulate a service configuration process for Multimedia Messaging Service, and a performance comparison is made between the bio-agents scheme and normal multi-agents scheme.

1

Introduction

The operational management of Next Generation Network (NGN) services is expected to be autonomous, scalable, interoperable and adaptable to the diverse, large-scale, highly distributed, and dynamically ever-changing network environment in the future. The functional management for them are also desired to be as simple as possible from the perspective of both designs and implementations. Current network management infrastructure is struggling to cope with these challenges. In contrast, social insects and biological organisms have developed relatively easy and efficient mechanisms to thrive in hostile, dynamic and uncertain environments after many years’ evolution and natural selection. Hence, taking advantages of the synthesis on full-scaled biological societies is of vital importance in achieving autonomic management in the future Ubiquitous ServiceOriented Network (USON) [1], which will dynamically connect human beings and home/office electronic appliances via distributed devices (e.g., cell phones, notebooks, PDAs) and applications running on these devices to enable services at any time, any places without constraints in quantity or frequency [2]. The aim of this paper is to propose a bio-swarming framework — SwarmingNet for network service managements. The biological platforms proposed by Suda [3] and Suzuki [4] are more emphasizing evolutionary behaviors of agents. The status of network services (mutation, clone, reproduction and replication) depends on D. Hutchison et al. (Eds.): IWAN 2005, LNCS 4388, pp. 253–258, 2009. c IFIP International Federation for Information Processing 2009 

254

F. Chiang and R. Braun

multi-agents’ internal states. These platforms are particularly complicated in terms of rapid practical application. We distinguish our framework from theirs by applying TeleSolon hierarchy1 concepts into hierarchical network management system which is analogue to the ecosystem in nature and colony structure in ants. We apply stigmergic ant-foraging behaviors into the threshold-based selforganization algorithm. This is much easier to be applied into practical embedded systems with industries. This paper is organized as follows: The design principles and our self-organized provisioning algorithm for event-based autonomic management architecture are mainly specified in section 2. The system-level architecture are included in section 2. Section 2.1 covers the definitions and theorem for the threshold-based self-organized algorithm. Service configuration process of MMS is simulated as an illustrative application, simulation results are shown in Section 3. Finally we conclude with performance comparisons and future work trends in section 4.

2

Design Principles

The incorporation of social insects paradigm into autonomic service configuration is believed to be the right solution to meet these requirements. This can be achieved by modelling networks as a distributed aggregation of self-organized autonomous TSS solons in our approach. This is similar to the social insects colony (networks) consisting of large amount of individual insect (solon). 2.1

Self-organized Service Provisioning and Algorithm

Future networks should not only provide basic connectivity but also intelligently and immediately enable on-demand services in pervasive computing environments at anywhere, anytime. Those services must be provisioned in a flexible and distributive way in highly dynamic runtime infrastructure. Thus, service deployment and management for devices in USON is extremely difficult since a provisioning infrastructure ought to cope with the high level of heterogeneity, degree of mobility, and also take into account limited device resources. In this context of self-organization, we describe the service provisioning as the ability to create, to remove, to reproduce, to reconfigure the instances of services at runtime. Moreover, the bio-mimetic agents running at particular network nodes, (1) measure the local demands for network services autonomically beyond other nodes; (2) reconfigure/reproduce local services when demands are detected; (3) remove the services when there are no demands of quantity. Self-organization Algorithm — This section defines the algorithm2 to enable self-organized bio-networks. This algorithm also considers the scalable design principle, such as adaptivity and robustness in distributed environment; localized 1 2

Due to the limitation of pages, details of THSs and TSSs can be referred to in the full version under requests. Details of this algorithm and proof can be referred to in full version of this paper.

A Biologically Inspired Service Architecture

255

decision making process based on neighborhood information. Hence, it is also a practical principle to consider only local customers who are not too far from the service center. The content-based event messaging system categorizes and stores the messages for different services into different space in information store (e.g., database). The following definitions as a whole define the problem domain in our service provisioning process. Our self-organization algorithm considers both the factors of time and space as follows: Definition 1. A dynamic threshold θ is configured for each requested service respectively; A parameter η is used to evaluate the keen degree for customers who require certain services; A parameter d represents Euclidean distance between available server of services and customers; The localized service zone ω is designated as ω(d) ≤ 10% · D, where D is the diameter value of the whole service area. Definition 2. A parameter τ evaluates the intensity of digital pheromone which are placed along the traces to servers in dispersed area by previous bio-agents. The intensity of digital pheromone measures how easy the service is available in the particular server the path gets to. Moreover, τ is related to the Euclidean distance d. Lemma 1. (Time) When customer requests are accumulated to the θ value, the service provisioning starts. This is a dynamic value varying in accordance with essence of specific services. For some reason, some services should be activated as soon as there is a demand for it. While some services can be activated only when there are enough number of requests; (Space) When the customer and services are both inside localized service zone, the service could be provisioned. Theorem 1. The self-organized process for service provisioning is activated successfully iff Lemma 1 and Lemma 2 are satisfied simultaneously. 2.2

System-Level Architecture

This architecture we propose here is partly depicted in Figure 1 of our paper [5]. We have to omit it due to page limitations. This systems-level architecture illustrates the combinatorial links among our three indiscerptible parts for autonomic service activation process: 1) Users; 2) Instrumentation support and measurement, monitoring; 3) Enhanced 4-layers TMF management model. Analogue to the biological society, we introduce the concept of ecosystem into the whole system which acts as the environment where agents create, live and die. We designate the energy exchange is the ”currency” between ecosystem components (e.g. swarm agents) and eco-environment.

3

Simulation and Experimental Measurement

We choose the Multimedia Messaging Service (MMS) as an evaluation application. As for the system-level architecture, the managed object in this context is MM Box (MultimediaMessaging Box); The product components are 1)

256

F. Chiang and R. Braun

Gold MM Box (capacity=1000MB), 2) Silver MM Box (capacity=100MB), 3) Bronze MM Box (capacity=10MB). The events messages contain on-demanding service provisioning requests from clients, these messages include information about: 1) creation and deletion of users’ MM account in the product or 2) migration Multimedia Messaging (MM) account among the products – Gold, Silver and Bronze boxes. The service provisioning results indicate bio-inspired network management paradigm and maintain SLA compliance as well as efficient transaction time. Digital pheromone evaluates the degree of difficulty in activating or migrating MM accounts which are stored in MM servers in this context (The large intensity of digital pheromone means MM boxes are easier to be migrated from silver to gold, or from bronze to silver, etc.). The effectiveness of digital pheromone in MMS server configuration process in the framework has been tested. The service-configuration performance comparison between the bio-agents and normal agents are analyzed. Java classes R  are built on the hybrid modelling platform AnyLogic . The experiment scenario is summarized here: The event messages with service requests from clients PC in our testbed will trigger the service configuration process whenever the service requests approach a service threshold θ ij where i represents the service ID, j represents the clients’ ID. We argue this is an autonomic process instead of an automatic paradigm because the θ ij value changes according to the requested service profiles and autonomic agents learn and decide the best threshold. Our adaptation strategies are not depending on a set of preconfigured rules like that in automatic system, on the contrary, the autonomy is achieved by goal setting and suggestion through learning and modification of the existing adaptation strategy. The multiplication ω of digital pheromone intensity and customer keen index will be considered as an important index in an exponential formula (e.g., exp(ω)), which determines which MM account will be configured to activate in certain MM servers. Service lifetime is calculated by multiplication of these two factors. Moreover, network vendor agents go through cach´e database for updated information being synchronized with our 4-layer structure which covers the specification files for products and services, and all the configuration files for resources (e.g., devices, equipment, etc.). Specifically, by taking into fact that service requests usually are provisioned by local servers, the factor d, an Euclidean distance measuring our virtual distance between service requests to MM server in the coordinate plane. If there are multiple servers meeting the requirement simultaneously, we will randomly pick up one of them. Figure 1 describes the overall simulation configurations in details. Figure 2 shows the parameters of 3 experimental scenarios which test the service provisioning. As shown in Figure 2 for Experiment 3, the number of MM servers is decreased till 100 while other parameters remain the same as above. 3.1

Experimental Results

Based on the three experimental test scenarios described in the previous subsection, the performance comparison between bio-agents and normal multi-agents

A Biologically Inspired Service Architecture

Topology

1000 virtual MM servers are uniformly distributed into an area [0, 280]

Event Parameters

Requests for on-demanding service are randomly generated by clients with fixed seed=1 over a time interval of 20 days Services lifetime are not permanent, they will deceased whenever there are no needs or termination willing from customers. {We give maximum_ service_lifetime = 1 day}

Space/Time Dynamics

Transaction time for each service requests dynamically change according to A = Customer_Keen_Index and B = Digital_Pheronmone_Intensity; In order to simplify the simulation factors, we set A=0.5; B = γ × d , (γ =0.5 or 0.6) where d = ( x − x1 ) 2 + ( y − y1 ) 2, d represents the Euclidean Distance between one particular service request and one particular MM server; Maximum duration for any certain service provisioning λ = 0.4 days Services configuration happen on those servers which are close to customers like in real world. We only provision the service distance d ≤ 30

257

Fig. 1. Experiment Description Digital_Pheromone_ Num_of_MM_Servers Initial_Value_Provision Intensity ed_Servers

Customer_Service_Keen _Index

Test 1

1000

0

0

0.5

Test 2

1000

0

0.6

0.5

Test 3

100

0

0.6

0.5

Fig. 2. Parameters for Experimental Test 1, 2 and 3

100

450

90 Service Provisioned for Services Requests (%)

Number of Current Provisioned Servers for Service Requests

Bio-inspired Service Provisioning Scheme

500

400 350 300 250 200 150 Biological agents scheme Normal agents scheme

100 50 0

Biological agents scheme Normal agents scheme

80 70 60 50 40 30 20 10

0

2

4

6

8

10

12

14

16

18

20

0 Low Client Nodes Density

High Client Nodes Density

Time in days

Fig. 3. Performance Comparison for Fig. 4. Service Configuring Percentage in Number of Servers Configured between Heterogeneous and Dynamic Network EnBiological Inspired Agents Scheme and vironment with Different Clients Density Normal Agents Scheme

258

F. Chiang and R. Braun

without biological behaviors are presented in Figure 3. As we can see, the number of servers in service provisioning process is bigger for bio-inspired agent framework when the same quantity of service requests (=11692) arrives. Service configuration tasks, or workload are distributed uniformly into servers with a shorter response time, and performance for load balancing is also optimized by this bio-inspired framework. We calculate the percentage of configured service of the total number of services, which though are finally provisioned respectively in the low client node density (=100 in the fixed area) and high client node density (=1000 in the fixed area). In low client requests environment, service configured percentage is 72%, which is higher than that in high client requests environment. However, our biological agents scheme results in better service configured percentages in the same environment as those normal multi-agent schemes. Details are illustrated in Figure 4.

4

Conclusion and Future Work

Firstly, we conclude that our bio-inspired multi-agent framework provides a solution to envision future autonomic service management system. This framework outperforms the current normal multi-agent based system in terms of service discovery and service assurance for future IP networks. Secondly, this framework does not rely on particular types of insects societies or colonies, i.e. agents could be entities in USON ranging from any hardware devices to robotic agents, or biologically-inspired software elements. Finally, our future work will specifically focus on the performance comparison among Particle Swarm Optimization (PSO), Ant Colony Optimization (ACO), and Genetic Algorithm (GA) with regards to efficient service configuration issues on the basis of this framework.

References 1. Yamazaki, K.: Research directions for ubiquitous services. In: Proceedings of International Symposium on Applications and the Internet, p. 12 (2004) 2. Suzuki, K.: Ubiquitous services and networking: monitoring the real world. In: Proceedings of ISAI, p. 11 (2004) 3. Nakano, T., Suda, T.: Self-organizing network services with evolutionary adaptation. IEEE Transactions on Neural Networks 16(5), 1269–1278 (2005) 4. Makinae, N., Suzuki, H., Minamoto, S.: Communication platform for service operations systems in advanced intelligent network. In: IEEE International Conference on Communications, vol. 2, pp. 872–877 (1997) 5. Chiang, F., Braun, R., Magrath, S., Markovits, S.: Autonomic service configuration in telecommunication mass with extended role-based Gaia and Jadex. In: Proceedings of IEEE International Conference on Service Systems and Service Management, vol. 2, pp. 1319–1324 (2005)

Author Index

Ardon, S´ebastien

145

Baldi, Mario 28 Banfield, Mark 83 Bhatti, S. 236 Bless, Roland 121 Bonnet, Christian 224 Boschi, Elisa 1 Bossardt, Matthias 1 Braun, Robin 194, 253 Chaudier, Martine 96 Chiang, Frank 253 Choi, Eunmi 212 Chrysoulas, Christos 206 Dedinski, I. 13 De Meer, H. 13 Denazis, Spyros 108, 206 D¨ ubendorfer, Thomas 1 Eyal, Amir

194

Farkas, K´ aroly 53 Filali, Fethi 224 Fritsche, W. 236 Gamer, Thomas 121 Gelas, Jean-Patrick 96 Gessler, G. 236 ´ G´ omez, Angel M. 200 Haas, Robert 108, 206 Haleplidis, Evangelos 108, 206 Han, L. 13 Han, Sang Man 218 H¨ arri, J´erˆ ome 224 Huang, Xinli 247 Hug, Hanspeter 53 Hutchison, David 83, 132 Jameel, Hassan

218

Kalim, Umar 218 Kim, Myung-Kyun Kirstein, P. 236

182

Kloul, Le¨ıla 168 Koufopavlou, Odysseas

108, 206

LakshmiPriya, T.K.S. 38 Leduc, Guy 156 Lee, Junggyum 212 Lee, Myung-Sub 230 Lee, Sungyoung 218 Lee, Young-Koo 218 Lef`evre, Laurent 96 Leopold, Helmut 83 Levitt, Karl 65 Lockwood, John 188 Lopez-Soler, Juan M. 200 Ma, Fanyuan 247 Martin, Sylvain 156 Mathy, L. 13 Mauthe, A. 132 Mayer, K. 236 Min, Dugki 212 Mokhtari, Amdjed 168 Park, Chang-Hyeon 230 Parthasarathi, Ranjani 38 Pezaros, D.P. 13 Phu, Phung Huu 182 Plattner, Bernhard 53 Portmann, Marius 145 Ramos-Mu˜ noz, Juan J. Risso, Fulvio 28 Ruf, Lukas 53

200

Sacks, L. 236 Sajjad, Ali 218 Sch¨ oller, Marcus 121 Sellappan, H.K. 236 S´enac, Patrick 145 Sifalakis, M. 132 Smith, Paul 83 Sproull, Todd 188 Sterbenz, James P.G. 83 Sventek, J.S. 13

260

Author Index

Tylutki, Marcus Xie, Linlin

65

Zhan, X.Y.

83

Yi, Myeongjae

Zachariadis, S. Zhang, Wenju

182

236

13 247

Zitterbart, Martina

121