Task: A.1
Task Leader: UCL
Participants: UCL 16 mm, INRIA 2 mm, SICS 3 mm, UTS 4 mm
From: T0 To: T0+24
Input from: B.1, C.1, D.1
Output to: A.2, B.2, C tasks, D.2, D.3
Deliverables: UCL-1 (Report): Application requirements.
UCL-2 (Report): Description of the protocol architecture.
Due at: T0+24
Milestones: Draft version at UCL-1 at T0+6, final version
at T0+12; First draft of UCL-2 at T0+12, second draft at T0+18, final
version at T0+24.
Description:
The next generation of protocol architectures
will be based around the characterization of the requirements of the
application. To this end, we will study the communication
requirements of a wide range of applications, such as:
We will also focus on the study of the synchronization requirements of some applications such as video conferencing and RPC. The main goal is to analyze specific needs of the applications and to propose guidelines for the ``integration'' of these mechanisms with other manipulation functions without jeopardizing the performance of the complete communication stack.
The selected applications are intended to be representative of the distributed applications that will exist in the future. The requirements will be used to form a paradigm from which we can draw a formal description of the communication requirements of an application as a vector of orthogonal metrics over the requirements' space.
Whilst we recognize that attempting to second-guess the future is a difficult art, we hope to provide a paradigm that encompasses the current state of the art, and provides flexibility for future applications with novel requirements to be slotted in.
The next task will be to develop the protocol architecture. The application requirements paradigm will be used to identify the functions required to provide the necessary services, building upon current and expected future networking technologies. The functions will then be characterized as to whether they are a control or a manipulation function (such as connection setup versus encryption), whether they require detailed knowledge of the application context (such as copying to application space), and what functions they depend upon for correct operation, and other aspects determining their implementation. We shall produce a set of functions, rules and constraints from which a protocol profile can be synthesized to meet an application's requirements, and which allow implementation to be optimized using techniques such as Integrated Loop Processing.
The architectural impact on protocols from integrated layer design and implementation will also be studied. In particular we will focus on implications for transport protocols, supporting multimedia applications. It seems that the ILP architecture will foster protocols with PDUs (actually application frames) as independent as possible, both with respect to shared states and ordering constraints. This means independence of application data streams and independence of PDUs in the same streams and it could mean separation of data and control in PDUs.
We will be drawing upon the considerable body of experience gleaned from detailed study and implementations of protocol stacks, and in particular on implementation of the functions grouped in the Transport, Session and Presentation layers from the OSI Reference Model and other architectural models such as the DoD TCP/IP suite, Xerox XNS and DECNet, as well as other work on distributed systems. Abstractions necessary to understand the task of communications architectures, such as the layering concept from the OSI reference model will be refined and enhanced.
Guidelines will be established for extending the architecture to encompass new functionality, so that the architecture is future proofed to a limited extent.
An important aspect of the new protocol architecture will be the increased use of formal techniques. It is intended that the protocols themselves will be automatically compiled, and so it will be important that the correctness of the protocol profiles produced can be reasoned about. One possibility that may occur is that through judicious choice of the elements allowed in a protocol profile we can reduce the state space necessary to search for the protocol so that analysis using traditional formal descriptive techniques (FDT) may be become tractable and viable. Taking into account the maturity of several FDTs as well as the availability of several software platforms to support them, it is our intent to apply some of these techniques to the formal specification and verification of protocol profiles.