| | Principles
The IBN approach
extends the functionality provided by the current peer-to-peer lookup services
(such as CAN, Chord, Pastry, and Tapestry) by allowing different instances of
the same content to be published in the network (and hence the name IBN). It
supports the following functionalities:
| Instance-node
mapping: The IBN user can ask the IBN to map an instance to a
particular node (through a ``publish'' operation). All mapping are leased,
that is, if the user does not refresh the lease before it expires, the
content is removed (or unpublished) from the IBN. Moreover, the user can ask
the IBN to
freely publish an instance according to a policy of the IBN to achieve a
specific objective (like load balancing). |
| Instance
communication: Active endpoints can send messages to other
instance-identified endpoints. |
| Instance-based
routing: The IBN can route a message to a specific content instance
or to the closest instance (the neighborhood metric is discussed below) if
no exact match is found for the destination content instance. |
| Replication:
The IBN replicates the stored contents in order to provide fault tolerance.
Replication can be implemented by using the instance-based feature of the
IBN. Replicas can be thought of as instances of the same object. |
The following figure illustrates the architecture of an IBN node model showing
its main components.
|