Next: The Physical View
Up: CANS Architecture
Previous: CANS Architecture
CANS views networks as consisting of applications,
services, and data paths connecting the two. CANS extends the
notion of a data path, traditionally limited to data transmission
between end points, to include application-specific components
dynamically injected by end services, applications, or other entities;
these components adapt the data path to physical link characteristics
of the underlying network and properties of end devices (see
Figure 1(a)).
Figure 1:
(a) Logical organization of CANS, (b)
Physical realization of CANS data paths.
|
Components are self-contained pieces of code that can perform a
particular activity, e.g., protocol conversion or data transcoding.
Components operate on typed data streams and are connected with
each other based upon compatibility of output and input types (see
Section 3 for details). Injected components come
in two flavors: stateful services and mobile soft-state objects
called drivers. Services extend the original data path to
multiple hops, and drivers generalize the traditional notion of a data
path to include data transformation in addition to transmission. The
primary reason for distinguishing between drivers and services is to
ensure efficiency.
CANS data paths are created dynamically, using information about user
preferences, properties of services and client applications, as well
as characteristics of the underlying platform. The components which
constitute a data path, the interconnections amongst them, and their
internal configuration parameters can all be modified at run time.
Modifications are triggered based on either system events (e.g.,
breaking of a network link) or component-initiated events. The CANS
infrastructure provides support to efficiently reconfigure data paths,
while preserving application semantics.
Next: The Physical View
Up: CANS Architecture
Previous: CANS Architecture
Weisong Shi
2001-01-08