User:Mjs:Xlayer:Fcomp

From ResiliNetsWiki
Jump to: navigation, search

Cross-Layer Driven Functional Composition

The following figure illustrates the three operational phases where functional composition may take place.


Functional Composition Phases


The first stage refers to bootstrap time, when a network node associates with the network. Composition at that phase can be more or less dynamic depending on the level and degree of autonomicity of the association process. Typically at that phase a configuration of layer functions and protocols takes place that forms the core functionality of the network stack. This configuration is driven by the nature of the network and physical environment (e.g. ad-hoc versus structured, full stack versus reduced stack, etc) and is prescribed in a specification.

At the second stage, the function composite is enhanced taking into account user input by means of policies and application requirements that essentially prescribe a certain “mission”. The composite essentially needs to enrich constrain or heuristically bound the provided functionality by integrating functional blocks either at the control plane (supervise) or data plane (enhance) of the ANA node operation. This step may be repeated several times (non periodically) throughout the uptime of a node as the mission objectives and the application requirements change (r.g. during session initiation time).

The last and possibly most frequent stage is the one during which re-composition takes place in response to internal state changes, optimisations, or external operational environment changes rendering the system runtime adaptive. This step can be periodic if it needs to take place in response to a periodic event, or adhoc if an unexpected or stochastic event triggers it. This may entail either something as simple as modifying some protocol parameters in the network stack (buffer sizes, window sizes, etc) or as complex as replacing modules to improve performance (e.g. replace the error correction scheme) or integrating modules to enhance functionality (e.g. upgrade the role of a node from a host to a gateway).

The product of the composition process is a data structure (function composite), which lists the components (functional modules) their dependencies and relationships, that form the network stack and a structure among them enforcing the processing order. This structure essentially dictates the data processing path in the network subsystem.

In its simplest form this data structure is a simple set or linked-list dictating a sequential processing path through a set of components. However more sophisticated forms are more likely (such as trees, or digraphs) that enable the conditional or parallel (pipelined) processing of a packet by a (subset of) function(s).

Finally a number of such composites is possible to exist simultaneously (potentially combined) allowing functional composition to be performed at various granularity levels (on a per network compartment basis, on a per flow basis, or even on a per session basis).


Types of Functional Composition

When it comes to the actual composition aspects we differentiate between two main cases, where composition may be required to maximize flexibility and often maintain correctness. We use the terms micro-composition and macro-composition to distinguish the two and at the same time to capture the fact that one of them takes place at the protocol/function level while the other takes place at the micro-protocol level.

As stated micro-composition takes place at the micro-protocol level and it is protocol skeleton driven. The idea here is that a sequence of finite state machines are “glued” together as prescribed in a protocol specification. A protocol skeleton essentially provides the glue for the functions that should be enabled as part of the protocol specification. Different mechanisms implementing a prescribed function or null functions can be inserted or replaced in the skeleton. For example where a protocol specification prescribes the existence of an error correction function it would be possible to insert a FEC implementing function, an ARQ implementing function, or a null function if the function is redundant (e.g. because it takes place at a higher or lower layer). A few proposals for such mechanisms exist in the literature such as [Feld94][AP93]. The main advantage of having such skeletons is protocol correctness, since the strictness of the specification has to be obeyed. For example one cannot insert a congestion control module in the place of an error control module. In representing the implementation of the skeleton as a graph (see figure below), one can enable the deployment and conditional use of a set of different mechanisms implementing the same function at run time and on a per packet flow basis (a flow may be defined at the application level, transport level or network level). So for example given the three different options available for error correction as depicted in the figure, one end-to-end transport level packet flow such as a file transfer may use ARQ, another that is over a high latency satellite link may use FEC, and a lossy media stream may use no-error correction at all. Note that the same graph structure could be representing a link layer protocol skeleton (signifying the functional reuse potential at different levels) whereby the different types of error correction are deployed across different types of physical links attached to the host (e.g. a satellite link, a wireless link and a reliable wired one).


Functional Micro-Composition


On the other hand macro-composition takes place at the protocol or function level. This type of composition allows for more flexibility as there are not strict specifications to be enforced. Examples of such composition are for example layering protocols on top of each other (e.g. layering a network protocol over another network protocol is perfectly fine thing to do as well as not doing it), or introducing functionality in between standard protocol behavior to enhance functionality or include control plane operations (e.g. extension headers in IPv6, measurement/accounting operations, etc). In the literature such flexible composition composition has been proposed in [SCSS06], [CDM96], [EKT95], [CAK93]. This type of composition can also be expressed by means of a graph signifying the data path that information flows across as is indicatively illustrated in the following figure from [SCSS06].


Functional Macro-Composition


Taking into account both types of composition on could represent the whole functional composition process as constructing a two dimensional graph (or a graph of graphs) whereby on the first dimension takes place the macro-composition and on the other the micro-composition.

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox