The objective of the HIPPARCH project is to study and design high performance communication architectures and implementations, based particularly on the Application Level Framing and Integrated Layer Processing concepts. The HIPPARCH project holds annual workshops at which papers from leading communications research centers are presented. The papers in this issue of JHSN represent early results of the project and other groups engaged in similar research. 1. Introdnction HIPPARCH is an EC ESPRIT Basic Resarch project which began in january 1994 and is tasked with establishing a novel architectural design for communications protocols to be used for distributed applications over high speed networks. The project partners, INRIA, SICS, UCL and UTS, are all longstanding members of the research community working on improving our understanding and implementation of communications systems. The requirement for a new architecture is clear. Traditional layered protocol architectures such as the ISO OSI model (see for example [3]) and the ARPA Internet model (see for example [4]), are reaching the very end of their extended lifetimes. The problem can partly be blamed on an artificial separation of concerns in layers that represented interfaces between different service providers: The service/protocol concept derives historically from the model X.25 originally presented to the user of a network as inteiface. There would be a link, network, transport and session provider, perhaps all of which would be different potential vendors. This absurd extreme view of a potential in layers in the stack has proved one thing: The costs of such a market in inefficiency mean buyers go to other markets the workable market appears to be in three layers: end system hardware and operating systems; end systems communications stacks; finally transmission networks. HIPPARCH concentrates its efforts on the second of these, to focus on end-to-end transmission control mechanisms and architecture. We are seeing a frantic flurry of effort piggybacked on the IPng effort to introduce a new architecture. Examples of such attempts include [5] and [6]. Some of these have led to partial attempts to address transport protocol problems as well [2]. While these address the network layer, they do not provide an integrated approach to designing the whole stack. We have adopted Application Level Framing and Integrated Layer Processing as intuitively reasonable guiding principles for selecting a new architecture that does address whole protocol stack design. In the initial year, we have carried out a number of tasks to deconstruct the problem. These fall roughly under the following headings: Adaptable transmission control mechanisms. Networks and End systems are and will probably always be heterogeneous. We should design systems that can operate for a large range of applications as well as TCP does now for a small one. 0926-6801/96/$8.00 © 1996 lOS Press. All rights reserved 106 1. Crowcr()ft / High peiformance protocol architectures HIPPARCH project and workshop Novel implementation techniques. We want to gather as many manual implementation techniques together as the basis of our decision on an architecture we want to maximise the gene pool diversity of the communications eco-system we are trying to build. In particular, we want to avoid pitfalls present in hidden assumptions about operating system structures (Unix, OS/2, Windows NT, etc) and about processor/memory architectures (uni versus multi, shared versus distributed memory) in the end system. In general, the final goal is a novel communication support architecture. This is not limited to implementation architecture, but to gain more from implementation techniques, the architecture itself has to be modified. Experiences with ALFIILP. While we seek new techniques, we would like to gain as much experience as possible using these particular guiding principles. Tools and description languages for protocol implementation. Initially, a lot of our efforts have involved manual programming of our new stacks. However, the objective is to eventually provide descriptions of application requirements, and automatically synthesize new protocols and protocol stacks to support the applications. To this end, initially, we wish to describe protocols and modules, and automatically generate working systems. Later this will permit verification/[8] and validation [8].
Search from 250 M+ research papersSearch from 250 M+ research papers
Apr 1, 2014
Vladimir Aristov + 2
Open Access