BIO-NETWORKING ARCHITECTURE

[Home | Research | Publications | Resources | FAQs | People | Undergraduate Research Opportunities | Related Sites/Papers]

Research Overview

Project Status

We are investigating the Bio-Networking Architecture in the following aspects: Development of a Bio-Networking Simulator and Simulation Studies

In order to evaluate general characteristics of the Bio-Networking Architecture, a Bio-Networking simulator has been developed that models network environement (see project resources page). Several applications have been constructed using this simulator. Please see also the section on application development).

For example, using the Bio-Networking simulator, we have developed a web content distribution application called Aphid and simulated its performance. Simulations have performed to demonstrate adaptability, scalability and evolution of the Aphid application. The adaptability of the Bio-Networking Architecture was evaluated with respect to cyber-entities' ability to adjust their location to user distribution and their ability to adjust their population to meet user demand. The scalability of the Bio-Networking Architecture was addressed by comparison of different user demand loads. Evolution ability of the Bio-Networking Architecture was also evaluated. In order to test evolution ability of the cyber-entities, simulations were conducted to compare evolving and non-evolving cyber-entities.

Through simulations, the Bio-Networking architecture has been demonstrated to show the ability to adapt to dynamic user environments. In one set of simulations, cyber-entities were designed to adapt their resource usage and location relative to dynamic user demand. User demand was distributed across a network and cyclically increases and decreases in overall user demand. Several cyber-entities ("r3d4m3") were modeled with reproduction, death, and migration behaviors. Even though the cyber entities are only aware of their local environment, the location and utility of the cyber-entities were well adapted with respect to the changing user environment. Simulation results of "r3d4m3" cyber-entities were compared to a non-adaptive, "static" simulation (where cyber-entities are strategically placed and do not migrate) and a "best" adaptation simulation (where cyber-entities are centrally controlled with full/global information and can exactly match user demand). The "r3d4m3" cyber-entities performed significantly better than the "static" cyber-entities and had utility at 89.7% of the "best".

The Aphid simulations have also been performed to demonstrate the evolution of cyber-entities on the Bio-Networking architecture. Cyber-entities contain functions ("factors") that evaluate its environment and return numeric values. Each factor is given a certain weight relative to its importance, and behaviors (reproduction, death, and migration) are activated if the total result of the evaluating function exceeds a certain threshold. The values of the weights were allowed only to change at each generation of cyber-entities where a child is mutated from its parent. Therefore, evolution in cyber-entities occurred over generations. Evolution was measured through the average weight of each "factor" over all cyber-entities. In these simulations, users were modeled as a localized group migrating within the network. In one set of simulations, cyber-entities were intentionally designed to poorly follow users. Non-mutating, "poorly" designed cyber-entities were shown to lag behind the users, whereas mutating, "poorly" designed cyber-entities were shown to be able to evolve themselves, and thus, closely follow user demand. This demonstrated that evolution of certain cyber-entity parameters over generations could affect the performance of cyber-entities in the Bio-Networking architecture.

Bio-Networking Platform

The Bio-Networking platform is middleware environment for deploying and executing cyber-entities. Each cyber-entity lives on a specific Bio-Networking platform to provide its service to others and perform its biological behaviors. The Bio-Networking platform consists of Bio-net services and Bio-net containers. Bio-net services provide a set of general-purpose runtime services that cyber-entities frequently use for executing their services and invoking behaviors according to their policies. Examples of Bio-net services include energy management, relationship management, lifecycle, resource sensing, social networking, migration, and pheromone emission services. Bio-net services run on a Bio-net container. A Bio-net container provides the low-level operations that handle memory, storage and network connections. We have designed detail mechanisms in Bio-net services and Bio-net container, and are currently implementing them. We also started examining performance measurements.

The platform design/implementation page provides more details.

Stability of the Bio-Networking Architecture

In the Bio-Networking Architecture, cyber-entities autonomously behave (replicate, reproduce, migrate, die, etc.), and it is not clear whether the Bio-Networking Architecture operates at an equilibrium point. Thus, considering stability is important in the Bio-Networking Architecture. A mathematical model is created, and conditions for the Bio-Networking Architecture to be stable are obtained.

In the mathematical analysis model, a cyber-entity provides a service to users in exchange for energy. It pays energy to a Bio-net platform for using the resource (e.g., CPU and memory) that the platform manages. A utility function is associated with a Bio-net platform, and the platform determines the prices of resources based on the utility function. Similarly, a utility function is also associated with a cyber-entity, and a cyber-entity determines the amount of resources it consumes based on its utility function. A utility for a cyber-entity, and thus, the amount of resource that a cyber-entity consumes, depends on various system variables such as the amount of resource consumed by other cyber-entities within N hops from the cyber-entity, and the prices of resources and the number of users that are within N hops. Similarly, a utility of a Bio-net platform also depends on various system variables such as resource prices on other platforms and the amount of resources that cyber-entities consume.

A mathematical model is created based on the assumptions described in the above paragraph and analyzed to obtain conditions for the model to be stable. A series of simulations demonstrated that the mathematical model analyzed is stable under the conditions obtained in this analysis and that the realistic Bio-Networking Architecture without simplifying assumptions introduced in the analysis also is stable under the obtained conditions.

Protecting Energy in the Bio-Networking Architecture

The energy in the Bio-Networking Architecture is a unit of exchange for service or use of resources, and the behavior of a cyber-entity is influenced by its energy level. Protecting the energy level of each cyber-entity is essential for secure and fraud-free communication between cyber entities.

In Bio-Networking Architecture, the following four types of possible attacks on energy level were identified:

  • malicious modification of the energy level by a cyber-entity itself
  • tampering the energy level of a migrating cyber-entity by a malicious node
  • malicious modification of the energy level by another cyber-entity
  • malicious modification of the energy level by a platform
Effective protection techniques depend on the location where the energy level is stored. Thus, the following three patterns of storing the energy level were also identified:
  • within each cyber entity
  • within the Bio-Networking platform in which the cyber-entity resides
  • within a centralized trusted node

As for malicious modification of the energy level by a cyber-entity itself, if the energy level is stored in a cyber-entity itself, it is difficult to prevent this type of security attacks. Storing the energy level in a platform or a centralized trusted node can prevent this type of attacks.

Tampering of the energy level of a migrating cyber-entity by a malicious node can be avoided using ordinary secure connection, such as Secure Socket Layer (SSL), if the energy level is stored either in a cyber-entity or in a platform. Storing the energy level in a trusted node also prevents this type of security attacks, as, in this case, the energy level is not transferred during cyber-entity migration.

Malicious modification of the energy level by another cyber-entity can be avoided with the inherent Java security and with encrypting sensitive data in object serialization, if the energy level is kept in a cyber-entity. Java security is also effective in preventing this type of attacks if the energy level is kept in a platform. If the energy level is stored in a trusted node, an authentication mechanism is required to prevent any masquerade attack by a malicious cyber-entity.

All the three storage models have difficulty in protecting the energy level from malicious modification by a platform. A secure infrastructure for cyber-entities using secure coprocessor is necessary to prevent a malicious platform attack.

Considering that the malicious modification by a cyber-entity may be the most probable attack to energy level in Bio-net applications, it is not safe to keep the energy level in cyber-entity. If the energy level is stored in a trusted node, the overhead of transferring each energy-related transaction from cyber-entities to the trusted node may cause the trusted node to become a processing bottleneck and create a heavy congestion around the trusted node, limiting the scalability of this solution. Keeping the energy level in a platform combined with the secure coprocessor seems to be the best, as it effectively prevents the malicious modification of the energy level by a cyber-entity. The only conceivable overhead is that of maintaining the energy level table in a platform. The table should be constructed in a way that facilitates insertion, deletion, and search of an item efficiently. If the size becomes fairly large, a hash table will show a good performance.

Decentralized Discovery

The dynamic and ad-hoc network produces the need for a method to search for network objects (data, applications, and users). The discovery mechanism is targeted at providing a method to locate objects in a network, while remaining decentralized and adaptive to the network environment. One potential method of searching for a network object is to have each network object contain links (also called relationships) to, and information about, several other network objects; and to use such links and information effectively in searching for network objects. As we explain below, this extra layer of links and information provides a highly decentralized mechanism to discover other network objects and yet remain adaptive to a dynamic network environment. We are investigating and developing the following key mechanisms:

Relationships
In the proposed discovery mechanism, we assume that the discovery mechanism abstracts data, applications and users as network objects, locatable on the network. Each network object is created with a globally unique identifier (GUID) and is capable of moving from one network node to another. Each network object also contains descriptive information about itself, such as information describing whether it is data or an application. Some objects may have additional information. For example, an application may provide its type of service or additional keywords describing the service. Keywords allow searches to distinguish between applications of the same type.

In the proposed discovery mechanism, each network object has a list of relationships to other network objects. A network object has a relationship with another network object when it knows about the other network object (i.e., when it knows the identifier, address and location of the other network object). A relationship may also contain descriptive information about the network object that it knows.

A network object may establish a relationship with another network object through actively searching for other network objects nearby, through introduction via other network objects, and through discovery-related interactions. Actively searching for other network objects involves broadcasting an inquiry message using the network?s node level connectivity to learn about nearby network objects. (Once a nearby network object is found, a relationship can be established.) A network object can introduce two network objects that it has relationships with to each other by having one network object pass knowledge about itself to the other network object. Discovery related interactions occur when network objects communicate during the discovery process, and can be used to introduce other network objects. Through these mechanisms a set of relationships is built and adjusted to form a network of relationship over all network objects.

Using relationships among network objects provides an adaptive and decentralized mechanism for searches . Searches originate from a network object and travel from object to object based upon relationships. Even when network objects migrate, relationships are maintained, as network objects are aware of which other network objects they have relationships with, and the migrating object can update the other objects? relationships when it changes location on the network. This provides a robust environment for the movement of network objects. Since each network object only uses its own relationships to perform searches, the search method based on relationships is entirely decentralized.

Search Forwarding
A search request contains parameters indicating the type of search, namely, if a search is for a particular network object, for a certain class of network objects (such as certain types of applications), or perhaps for network objects (data) related to some topic [HKB99]. When a network object receives a search request, it first compares itself to the search, and if it matches, it responds to the search. When the network object itself does not satisfy the search, it uses its relationships to forward the search request to other network objects. Searching is improved by using the additional relationship information (i.e., descriptive information about other network objects such as service type and keywords). Based on the parameters of the search and the descriptive information contained in a relationship, a decision can be made regarding which relationship is more likely to lead towards a network object that meets the search parameters, and a search request may only be forwarded to such network objects. (The other relationships can be tried after these likely network objects have been tried.)

The network object may forward a search request in a sequential manner, trying a new network object after the search based on a network object failed, or in parallel to more than one network object at a time. Sequential searching minimizes the overhead due to search request packets, whereas a parallel search minimizes the amount of time required to find the network object(s) being sought for [PGHRRGKP98]. The overall search process can be limited by hop count (of the path that a search request takes), search time, or by path cost.

Search Backtracking
The network object that matches a given search request may respond either directly back to the origin of the search, or back through the chain of network objects that a search request followed to the match (backtracking). To respond directly to the origin, the search request must include the network address of the search origin. Response through backtracking the chain of network objects leading to the match provides a certain amount of anonymity. Anonymity results since the matching network object does not have any information about the origin. Note that the address of the search origin is not required in a search request in backtracking. Instead, the search origin assigns a globally unique identifier (GUID) to a search request, and each forwarding network object records the GUID of the search request it receives, from which node the search request came, and to which node the search request was forwarded. Once the network object that matches the search is found, the information stored at each relationship hop has adequate information to backtrack through the path of network objects leading to the matching network object.

Some of the key research issues to be addressed in our project are listed below:

Discovery Usability: The proposed discovery mechanism is useful if it returns meaningful results within an acceptable amount of time. The dynamic environment (where network objects migrate) also adds the need for the search to find network objects that are relatively close to the user. An additional usability concern is related to how the discovery mechanism performs when no matches to a search exist. In the proposed project, we consider these usability factors and investigate the quality of search results returned by the proposed discovery mechanism.

Resource Usage: The proposed discovery mechanism produces a certain amount of overhead. Overhead takes the form of data storage for relationships, processing to prioritize relationships in search, and network usage to propagate search requests. An additional overhead is also required to establish the network of relationships among network objects. In the proposed project, we consider the resource usage and evaluate the proposed discovery mechanism with respect to resource usage.

Scalability: Scalability in networking environments deals with concerns that arise when certain parameters of the network increase; the number of network nodes, the network usage, the number of users, the number of applications, or the amount of data. In the proposed project, we investigate the scalability of the proposed discovery mechanism through simulations where these network parameters are varied.

Robustness: Robustness for the proposed discovery mechanism addresses the dynamic nature of the environment and how losses of network nodes or objects may affect the properties of the proposed discovery mechanism. In the proposed project, we consider the dynamic nature of the environment (e.g., movement of network objects) and investigate robustness of the proposed discovery mechanism by measuring its usability, resource usage, and scalability through simulations.

We have developed two distinct discovery mechanisms.

This link provides more details about discovery using preference for query hits.

Decentralized Directory Architecture

Another approach to searching for an object on the network uses a distributed network of directories. In this method, network objects register themselves with a local directory server, and local directory servers self-organize to create a network of directory servers. This directory service is adaptive, distributed, and self-organized, thereby solving the downsides of a centralized architecture. The adaptive nature allows the directory service to locate moving network objects; the distributed nature leads to decisions that are based only on local information; the self-organizing nature reduces administrative burden, and further ensures the directory withstands failures. In the following discussion, we describe the proposed directory service based on a network of directories.

In the proposed technique, directory service is provided using mobile autonomous directories that keep information about network objects that exist within their respective local environments. These mobile autonomous directories are called directory servlets (DSs), and they collectively compose the directory for the network. This DS-based directory operates in three key phases, the construction phase in which individual DSs learn about local network objects, the relationships establishment phase in which DSs locate each other, and finally the lookup phase that allows network objects to use the directory to locate other network objects in a network.

Construction Phase
When a new network object joins the network, it examines if there is a DS within n-hops from itself. (This examination is done through an n-hop-range inquiry broadcast.) If no nearby DSs respond, then the newly joining network object becomes a DS. Otherwise, the newly joining network object will register itself with the first DS that responds to the broadcast inquiry. When a network object migrates, it un-registers itself from the DS that it is currently registered with, migrates, and then re-registers itself with a new DS following the same process described above. As network objects join the network and migrate, an ad-hoc structure of DSs with local network objects registered to them emerges.

Relationship Establishment Phase
Each DS can resolve lookup requests (LR) for network objects within its local environment. However, in order for a DS to resolve LRs for all network objects, it must first obtain information about network objects that are registered with other DSs. There are two approaches for DSs to exchange information on their registered network objects. One approach is to use relationships between network objects and apply the discovery mechanism explained in section E.1.1 to locate other DSs. Once other DSs are located, DSs can establish relationships among themselves and exchange information about their registered network objects. (This searching for DSs and exchanging of directory information may be done on an on-demand basis when a LR is received at a DS, or may be done prior to receiving a LR.) Another approach is to use the process of finding nearby DSs in the construction phase. This provides a way for a given DS to learn about other DSs without a discovery mechanism. In this approach, if multiple DSs respond to a newly joining object?s n-hop range broadcast, the object registers with the first responding DS, and then informs all other DSs about the existence of all other responding DSs. Once DSs know about each other, they can establish relationships among themselves and exchange information about their registered network objects.

Lookup Phase
Resolving lookup requests (LRs) depends upon the level of decentralization currently being used in the directory. If the directory is centralized to the point that every DS knows of every network object in the network, then any DS can resolve a LR simply by checking its internal list of network objects. If the directory is distributed and none of DSs have globally complete information, a Gnutella-like search technique must be employed [GN00]. In other words, a DS first looks in its local network object list. If a network object is found, then the LR is resolved; otherwise this DS assigns the LR a globally unique identifier (GUID). It then forwards the LR to all other DSs that it has established relationships with. The GUID is used at each forwarding DS to ensure that LRs are not forwarded in loops indefinitely; a DS discards a LR with the GUID that it has seen before. The process continues until the LR has been resolved. Once a LR is resolved, the communications endpoint associated with the network object being looked for is directly sent to the originator of the LR. (Here we assume that the originator?s communications endpoint is contained in the LR). This lookup technique has many variations, and these were elaborated on in the discovery mechanism discussion in section E.1.1. (Different options will be explored in the proposed project.)

Some of the key research questions to be addressed in our project are listed below:

Decentralization: The manner in which relationships between DS are used affects the level of decentralization of the directory. In the most centralized way of using relationships, a DS uses its relationships to build a complete list of all network objects that exist. This decreases DS-DS communication in resolving LRs (lookup requests), yet results in large memory overhead. In the most distributed way of using relationships, a DS only stores information about its local network objects. This results in minimal memory overhead, yet communications between DSs increase. In the proposed project, we investigate under which circumstances that each option works best, thereby providing a basis for a hybrid technique.

Organization of Directory: A desirable aspect of a directory is the ability to organize directories (DSs) in some manner. For example, during the relationship establishment phase of the proposed directory service, DSs may choose to organize themselves into several layers of hierarchy to achieve faster lookups. The upper layer DSs will provide summary and routing to DSs in lower layers so that not all LRs have to be forwarded through the entire network. In the proposed project, we investigate techniques for creating a hierarchy of DSs and examine the overhead of the hierarchy and its impact on the performance of the proposed directory service.

Lookup Optimization: The lookup process of the proposed directory service may be combined with a variety of techniques to produce a faster lookup. One technique is to exploit the mobility of DSs so that if a large number of LRs originate from a particular area of the network, under appropriate constraints a DS may migrate closer to this area. In the proposed project, we investigate a variety of techniques to improve the lookup performance.

Dynamic Load Balancing and Optimal Allocation of Cyber-entities

Resource usage in the dynamic network environment is highly unpredictable. Since users frequently enter, leave, and move about the network, network traffic does not have static or cyclic (e.g. daily/weekly patterns) characteristics. With such dynamically changing traffic, often some network nodes may be heavily accessed, whereas other nodes may remain entirely idle. In addition, a particular node may contain a disproportionate number of processing-heavy or data-heavy network objects. Because of such disparity of resource usage across network nodes, a network?s performance and usability may not reach its full potential. To allow applications to adapt to changing network conditions, network objects (data, applications and users) in the proposed project are allowed to move around the network. In addition, since there are different levels of usage between network objects, multiple priority levels are introduced to provide an additional guide towards resource utilization.

In our project, we develop decentralized techniques for dynamically balancing the processing load and for optimizing the locations of network objects throughout a network. We assume that each network node hosts a resource optimization server. A resource optimization server monitors its local node?s resource availability (such as CPU cycles and memory space), allocates resources to network objects running on the local node, communicates with other resource optimization servers on remote nodes, and dispatches network objects to remote nodes.

Associated with a resource is the cost of using it. A resource optimization server dynamically determines the cost of resources it manages based on the availability of and the demand for the resources. (For instance, the more memory available, the cheaper the cost may be.) A resource optimization server exchanges information with other nearby servers on available resources (e.g., types, amounts, and costs) that it manages. (A resource optimization server may either send an inquiry message to nearby servers to obtain information, or may broadcast information about available resource to nearby servers.)

When the demand for resource on a node exceeds the supply on the node, or when the cost of available resources on a node becomes too high for the network objects on the node, the resource optimization server on the node broadcasts an inquiry to nearby servers to identify servers that are willing to host some of its network objects. Based on factors such as the amount and cost of resources available on remote nodes, current load of remote nodes, proximity of remote nodes to the clients of network objects, and the priority levels of network objects, a resource optimization server decides which network objects will migrate to which remote nodes. On the other hand, when a node?s resources are under utilized, a resource optimization server broadcasts the availability of resources to nearby servers so that the resource optimization server of an overloaded node can dispatch some of its network objects to such under utilized nodes.

Some of the key research questions to be addressed in the proposed project are listed below:

Policies For Resource Optimization Servers: A resource optimization server decides the cost of the resources it manages. It also decides which network objects will migrate, and to which remote nodes, when it is overloaded. There are a number of potential policies to dictate the actions and decisions of a resource optimization server. In the proposed project, we consider a number of policies and examine how different policies impact the performance of a network.

Resource Optimization Server Coordination: A resource optimization server broadcasts its availability when it is under utilized. If it broadcasts more often, remote nodes will receive more accurate and current information. However, this increases communication overhead [GHIRS01]. Furthermore, a resource optimization server dispatches network objects to remote nodes. The more often network objects are dispatched, the more evenly the load is distributed over the network nodes, but at an increased cost of communication. In the proposed project, we consider these tradeoffs and investigate how the frequency of actions by resource optimization servers impacts the performance of a network.

Authentication Mechanism for Cyber-entities

In order to develop security sensitive applications in the Bio-Networking Architecture, it is required for cyber-entities to authenticate each other. Since cyber-entities are dynamically created through replication and reproduction, they should be registered into CAs (certificate of authorities) by on-line mechanisms for authentication afterwards. Although traditional mobile agent systems have proposed several authentication mechanisms, they do not work well in the Bio-Networking Architecture because they do not assume on-line registration of mobile agents to CAs (mobile agents are often assumed to be registered off-line) and autonomous replication or reproduction of the mobile agents (i.e. cyber-entities).

We designed two mechanisms that are used for cyber-entities to authenticate each other: (1) on-line registration mechanism and (2) peer-peer authentication mechanism between cyber-entities. Each cyber-entities use on-line registration mechanism when it creates a clone cyber-entity (i.e. replicated or reproduced cyber-entities) and gives it an id and private/public key pair. On-line registration process can be performed in both single-CA environment and multiple-CA environment. The peer-peer authentication mechanism is used by cyber-entities when they check if other cyber-entities are trustworthy. This authentication mechanism was carefully designed with efficiency in mind because it is used much more frequently than registration mechanism.

Dynamic Service Composition

Dynamic service composition, a concept of composing a service (or application) on demand through combining multiple components (or cyber-entities), has the potential to realize future applications that adapt to various user preferences and contexts. In our project, we are studying, designing and developing various aspects of the Bio-Networking architecture including its component model, description framework, composition mechanism and execution mechanism in order to realize flexible, adaptable, extensible, efficient, and user-friendly service composition.

We develop a new component model called Component Service Model with Semantics (CoSMoS), and a service composition mechanism called Semantic Graph based Service Composition (SeGSeC). CoSMoS introduces semantic graphs and ontologies to define and annotate components in a flexible, extensible and intuitive manner. SeGSeC enables a software agent to compose an application through combining several components based on a user request. SeGSeC achieves flexibility, adaptability and efficiency by investigating different combinations of components using semantic graphs and ontologies.

Please see the dynamic service composition project homepage for more detail..

Application Development

Several applications have been constructed using Bio-Networking simulator and platform.

The first application is a web content distribution application called Aphid. The Aphid application consists of multiple Aphid cyber-entities. Aphid cyber-entities have a series of biological behaviors such as energy exchange, replication, reproduction, relationship building and death. In particular, Aphid cyber-entities have a service behavior that accepts requests for web pages and delivers them using the HTTP protocol. The body of an Aphid cyber-entity may contain a single web page or a set of web pages. Aphid application has been constructed on a Bio-Networking simulator and will run on a Bio-networking platform. The scalability, adaptability and survivability/availability features of Aphid will ensure that web pages are always available and delivered to users with minimal delay regardless of the amount of user demand.

Standardization Effort in OMG Super Distributed Objects DSIG

Since the Bio-Networking Architecture is innovative and new, it is important that the research and industry communities recognize the advantages of the proposed architecture. In order to gain support from the communities, we have worked with the Super Distributed Objects (SDO) DSIG (Domain Special Interest Group) in Object Management Group (OMG). The OMG SDO DSIG focuses on exploring the characteristics of super distribution (i.e. massive numbers of objects, decentralization, autonomy of objects, and cooperation between objects) in distributed object systems, and specifying the standards that allow us to develop super distributed systems. We have worked on standardizing key concepts and mechanisms in the Bio-Networking Architecture in standard specifications of OMG SDO DSIG.

We published a white paper that defines common terminology for describing super distributed systems and provides a standard reference architecture for developing, deploying, interoperating, and managing the systems. We also issued a Request for Proposal (RFP) that solicits models and interfaces for describing capabilities and properties of objects, supporting uniform management of objects, and enabling ad-hoc usages of objects.

Network Research Group
Dept. of Information and Computer Science
University of California, Irvine


FastCounter by LinkExchange