User:Mjs:Xlayer

Draft Cross-Layer project page

Current Status

We are seeking feedback from the Resilinets community on this initial proposal.

Introduction

This project aims to address primarily the issue of feasibility and then the problem of optimal and resilient communication across challenged networks. As with the Metrics and Modelling project, challenged networks refers to a broad category of networks that have limited capabilities in terms of connectivity, bandwidth, channel characteristics, node resources and is required to function satisfactorily under special conditions of mobility, traffic patterns, environmental conditions and natural or man made disruptions. As an evolution from the current Internet, we hypothesise an environment of more loosely connected compartments of networks, some implementing a full TCP/IP stack and some not, consisting of IP and non-IP devices (eg WSNs, MANETs, etc.). At the interstices of these compartments will be cross-layer-aware interconnect points which will manage ‘network impedance’ and tackle inter-compartment communication issues such as addressing, routing, protocol translation, security/trust, performance etc. These interconnections will maintain any necessary views of end-to-end communication in challenged environments, while adapting and tailoring communications through the application of cross layering principles and functional composition. The composition (and re-composition) of communication functions will be determined from application requirements and the sensing of metrics derived from the compartment network spaces. Incorporation of resilience mechanisms is also intrinsic to functional composition, embedding means of detection, diagnosis and remediation of faults. Interconnect points will also support dynamic composition and deployment of resilient communication functions as network conditions fluctuate.

Motivation

(The following figures are courtesy of Stefan Schmid and the ANA project)

In the above three cases C1 Node's functionality can vary in complexity depending on the type of networks it is interfacing (Cross-layering is expected to assist the sensing and determining of the task C1 is expected to perform as well as drive the composition of the necessary functions to fulfil its role).

For the following analysis an identifier is simply a 'label' (of alphanumeric nature) that identifies a node with regard to some semantics. Example semantics involve:

• host interface location (it is an address as in IP)
• host entity (it is a node/host id as in HIP)
• host role (it is a service identifier as in port numbers, dont care about who is providing it)
• host property (e.g. OS platform, performance capability - sensor vs PC)
• combination of any of the above (eg. network location and a property)

Scenario 1

If the ABC network and the 123 network are of exactly the same type (same protocol suites) and they only use different identifier (protocol SAP/address/port) spaces, then Node C1 only needs to do identifier translation. Its functionality is limited to the protocol layer within which it needs to provide translation between different identifiers spaces.

In the most typical IP case that will be the network layer, which makes C1 a NAT box, but in theory it can also be any other layer (e.g. the link layer) or a combination of layers (e.g. network+transport - as in NAT/PT), and/or bridge between non-IP networks such as MANETs.

Scenario 2

Network ABC and network 123 are similar but not the same. By similar we mean the same type of protocol suites in terms of numbers of layers and/but some of the layers are implemented by different protocols that nevertheless provide similar type of service - and thus translation from one protocol in one suite to its counterpart in the other suite is easy (e.g. TCP/IP/TokenRing and TCP/IPv6/Ethernet). In this case Node C1 needs to be capable or a slightly more complex functionality than simple identifier translation. It should be able to provide gatewaying functionality by means of protocol translation at one (or more) layers, while preserving end2end semantics.

A typical example is a gateway that can translate IPv4 to IPv6 headers and vice versa and possibly Token Ring and Ethernet headers. A further example would be a gateway between a wireless mesh access network and the IP network. Note that although this function is easily implementable during the translation there may be encountered some loss of functionality (eg. IPv6 extension headers might need to be dropped if similar options do not exist in IPv4). Therefore translation will be based on the maximum common denominator of the features of the two protocols

Scenario 3

Network ABC and network 123 are completelly dissimilar, that is they are serviced by different stacks both in terms of number of layers (one has LL-NET-TRANSPORT, the other has LL-TRANSPORT) as well as in terms of protocols servicing each layer. Imagine that even the common layers between the two stack configurations (common denominator) are supported by protocols that use different assumptions in terms of funtionality (e.g. one provides a best effort unicast service, and the other provides an episodic publish-subscribe type of functionality) and identifier semantics (assuming that we are talking about the link layer, one uses identifiers that encode topological information, the other uses identifiers that encode service capability (butcher/baker/grocer) and performance metric (how many requests it can serve simultaneouly)). In this case Node C1 needs to have a very complex gatewaying capability up to and including the application layer, that not only spawns across all the common denominators of the layers of both stacks, but also needs to be able to collapse/expand layer functionality from one stack to the other.

To add to the complexity encountered if an end node of the ABC compartment does not understand the semantics of the 123 compartment (most likely case), then the gateway node C1 needs to be able to make decisions (based on external policies, and external sensing) if and how to propagate data from ABC to 123 and vice versa, and to whom!

Finally if we assume that node A from ABC and node 3 from 123 are also members of an overlay compartment so that they can share a common identifier space that will allow them to address each other and establish e2e communication, then in order to establish an e2e session in the first place there is implicit need for node C1 to also participate in the overlay, even if is that is transparently (i.e. not having an explicit overlay identifier), so as to be able to understand the functions and semantics of the overlay space and make correct decisions when gatewaying between the two underlay compartments (ABC and 123)

A potential solution may be that the node C1 collects enough knowledge through cross layering techniques that will allow either the dynamically construction of a "babelfish" (Hitch Hiker's guide to the galaxy) type-of-service or infer the selection of a pre-existing module that will make possible the interfacing of the two compartments/worlds/stacks/languages.

Research Scope

The focus of this project lies mainly (although by no means exclusivelly) in the following areas:

• Design and development of framework for cross-layer sensing and optimisation
• Methods/Models for studying the feature interactions in face of multiple cross-layer optimisations.
• Use of cross-layering to leverage and facilitate functional composition in modern composable network subsystems.
• Use of cross-layering to facilitate interfacing and gatewaying between heterogeneous network compartments

In scope with the work intended is the study of the following aspects

• How to relax the opaqueness of layers by enabling cross-layer and cross-over/underlay optimizations and inter-layer control loops. This calls for the development of a framework that will allow information flow across layers and within layers to enable optimizations, yet without breaking modularity or increasing complexity to the extend that impacts scalability.
• How to monitor and safeguard correct operation (w.r.t. the goals) of the overall system in face of potential feature interactions among multiple cross-layer optimizations. Most work on cross layering today has focused on optimizing operation of a network subsystem using a single cross layer optimization or enabling cross layering in a system altogether assuming that the optimization logic is external to the system and therefore externalizing the problem of correctness. However, for any such solution to be realistically usable there this problem needs to be addressed.
• How to incorporate the flexibility, dynamicity and composability anticipated in component models effectively in a layered system whilst preserving the ability to incrementally enhance functionality in a scalable and abstracted way.
• Ways of determining vertical (across the stack) composition. It is well known that a full TCP/IP or other protocol suite is not necessarily needed complete in any possible environment. For example in a small sensor or ad-hoc network which is seen as a flat topology all link-layer and network layer functions can be collapsed in one layer. If FEC and ARQ are available at the link layer it may be possible to make the transport layer redundant too. There is need to engineer ways and mechanisms for assessing the functions needed to deploy and where in a protocol suite. Moreover being able to do this in a dynamic way (either while bootstrapping or at run-time) makes it useful when the network role of a node may change dynamically.
• Ways of enabling horizontal (micro-protocol) composition. Typically, protocol implementations are based on a set of FSMs that collectively provide a set of semantically related control plane and data plane functions (e2e versus hop-by-hop error control, flow control, congestion control, check-summing, etc). Very often in the name of modularity and isolation many of these microprotocols are repeated across the stack at more than one layers (e.g. ARQ inTCPoGPRS) thus introducing unnecessary overheads and yet other times their existence is blindly (falsely) assumed (TCP assumes error control at the LL). To address this problem a less rigid and tightly coupling of the protocol functions can be promoted and advocated in the design of network protocol, which could allow independent and optional use and integration of these micro-protocols as well as the replacement of one implementation of them with another subject to requirements. Several research efforts towards this direction have been recorded in the literature including [DH98], [Feld94], [CDM96], etc. It is likely that even some of the current protocols could be re-written to favour such a model. Using cross-layer information flow can then allow optimised decision making across the whole stack of what protocol function to enable at which layer, so as to eliminate unnecessary redundancy and evaluate performance.
• Determining data path selection. Once all the protocol functionality for intra-compartment communication is in place, there comes the time of establishing communication with other peer hosts within and across compartments. In a common globally configured environment like today’s Internet this has not been a problem because the network stack is fixed. However in an autonomic network environment which is expected to promote diversity for the shake of localised optimisation the problem of selecting a path across a multiprotocol stack can be a challenge. A similar (yet not quite the same) problem existed in the past when multiple protocol suites were available for use by different applications Unlike the past though where the different protocol suites were competing for their dominance over one specific environment, the future is more diversity-friendly thus promoting the co-existence of complementing protocols in equally diverse network environments each tailored to a specific application domain. Given all this multiplicity and diversity (number of layers, micro-protocol configurations, set of protocol suites) when two peers need to communicate and especially across compartments there is need to determine a suitable data path across the stack (partly common with the next hop, partly with the local compartment, and partly with the remote end). A challenging research objective is to develop mechanisms that will allow deterministic selection of suitable data paths across a see of network functions within a node or gatewaying dissimilar protocol configurations between compartments.

Research Methodolgy

The following activities are anticipated.

• Review previous work related to cross-layering such as Application Level Framing and Integrated Layer Processing (ALF/ILP)
• Analyse and characterise performance parameters/metrics of existing and emerging networking paradigms, such as MANETs, wireless mesh, WSNs, DTNs etc., and their requirements for protocol functionality, both intra and inter compartments, and end to end.
• Investigate possible ways of formalising cross layer interactions in a network subsystem and develop a framework for examining and assessing the stability of the system in the face of multiple (potentialy competing) cross-layer feature interactions.
• Develop a framework for cross-layer information sensing and sharing, and typical protocol function profiles for different scenarios derived from this information. Test performance of synthesised cross-layer protocols through simulation.
• Develop an architecture and algorithms for dynamic and adaptive cross-layer driven functional composition.
• Implement, deploy and test on an appropriate test-bed.

Related Literature

Here is a list of references that relate in one way or another to the objectives of this project, as well as additional material referenced from this page.

Related Projects

• Autonomic Network Architecture (ANA). By EU-IST, FET-ACF track
• Haggle. By EU-IST, FET-ACF track

People

Kansas University: James Sternenz

Lancaster University: David Hutchison, Manolis Sifalakis

University of Sydney: Michael Fry

... (add your name here if you want to be involved :)) ...

Cross-Layer Architecting

• Cross-Layer sensing and optimisations framework
• Cross-Layer driven functional composition
• Cross-Layer model for Ns2