As mentioned before, new technologies have been developed to provide enhanced services at the infrastructure network level. The COIAS project has chosen two of these technologies that can be considered as two main pillars of the GII.

The first one is ATM that has been heavily supported by the EC through previous ACTS calls and is being deployed in Europe. One important feature of the ATM technology is the potential ability to provide point-to-point and point-to-multipoint VC with a specified QoS. From the operator point of view, ATM brings its scalability and flexibility in terms of traffic management in order to deliver to the user the exact expected level of performance.

The second technology that can be considered as complementary to ATM is the satellite. Satellite is being increasingly used in the Internet, for technical, economical and strategic reasons. Satellite is chosen whenever:

• the same information need to be broadcast to many receivers disseminated over a wide area,
• or a high-speed but temporary link has to be established,
• or it is required to bypass intermediate nodes or transborder interfaces,
• or a fast network deployment over a wide area is required,
• or a gradual increase of bandwidth requirement overtime is expected.

In addition, with the successful world-wide introduction of the DVB standard, satellite communications offer, today, at minimal cost for the receive terminals, very high-speed transmissions. Other emerging satellite technologies such as on-board demodulation and multiplexing also reduce the size and cost of equipment at the transmit site.

The main goal of the COIAS project will be to demonstrate how the GII can be engineered to get full benefit of ATM and Satellite networks and can satisfy the requirements of an increasing number of various applications, using the tools available with the new generation Internet protocols. The COIAS will therefore participate to the Internet - ATM - Satellite convergence and integration effort.

Internet protocols in their current version (TCP/UDP/IP v4) were originally designed 15 years ago for data transmission. At that moment, communications link layers offered low data rates and a high percentage of data loss. The goal of the Internet protocols was to ensure reliable transfers between two hosts. However, these protocols are not well suited to bring efficient network and transport services to satisfy the requirements of the applications to be supported by the GII.

The Internet protocols do not provide any QoS guaranty. This single-class, "best-effort", service works well with applications that do not have any real-time constraints such as electronic mail or file transfers, but has clear limitations during network congestion periods for interactive applications (telephony, videoconferencing, network games,...). This leads to new classes of service and a QoS signalling protocol being discussed in the IETF. Secondly, the current version of IP does not include efficient mechanisms for mobility and security management.

IPv6 is the core element of the new Internet technology and should be the target protocol towards all existing networks, including ISO and IPv4 based networks, will have to migrate. The IPv6 specification (RFC 1883) is today a Proposed Standard and is still subject to small evolutions. Nevertheless, the IPng IETF working group expects a Draft Standard at the beginning of 1998. But there are also a large number of related specifications with the status of Proposed Standard or even Informational Draft that need to be completed taking into account the results of the first experiments. The COIAS project will implement IPv6 including the security and the mobility features and experiment these new capacities. The COIAS network infrastructure will be one of the first IPv6 based network in the world and will provide important feedback before the completion of the IPv6 standardisation process and before the complete IPv6 deployment. The COIAS partners already involved in the IETF standardisation process will take benefit of the COIAS project results to enhance Proposed Standards. Two full partners of the COIAS consortium have already developed an IPv6 stack. These stacks will be used and completed during the project.

The issues related to the management of the QoS over an aggregation of ATM and Satellite networks fall into several general classes:

• how to map the Internet IntServ model to the ATM QoS model,
• how to make RSVP, the Internet signalling protocol, run over ATM and Satellite,
• how to handle the ATM VCs to be able to provide the requested QoS and to optimise the network resources,
• how to aggregate IP flows,
• how to handle the many-to-many connectionless features of IPv6 and RSVP,
• how to map efficiently the routing algorithms with the switching mechanisms,
• how and when to use satellite to dynamically set up shortcut route between nodes,
• which time-critical data should be routed over a satellite overlay network on top of a terrestrial network,
• how to balance the load between satellite and terrestrial links,
• how and where to monitor the achieved QoS performance,
• which measures to prevent misuse/unauthorised use of network resource,
• how to optimise the use of network resource to fulfil the required QoS.

Most of these issues are subject to standardisation works, but most of them still require research activities and experiments feedback. The goal of the COIAS project will be to design up-to-date solutions to solve these issues and to experiment these solutions. The COIAS platform will include up-to-date version of routers provided by one of the Sponsoring Partners of the project. These IPv6 routers will include IntServ mechanisms and RSVP functions. Two full Partners and a Sponsoring Partner are already working on IP satellite transmissions. Their research and prototyping developments will be used in the COIAS project.

At the transport level, several problems have also to be solved. RM data transfer is probably the most complex one. Within the COIAS consortium three full partners are working on this subject and should bring their expertise to propose and implement a reliable multicast protocol that could be used for large groups of users. This protocol will have to run on asymmetric links such as the satellite ones. A TCP over satellite working group has been recently created at the IETF to standardise the specific protocol options required. This standardisation activity will be also followed by the COIAS consortium.

At the user access level, one major issue to address for the future Global Internet Infrastructure is probably the one of the access to Media Servers. The pull technology (WWW) as well as the push technology (broadcasting) require high performance and scalable media servers. These servers will be part of the infrastructure and could probably be the bottleneck of the future Internet services. Two of the COIAS full partners have already study this problem and bring their knowledge and developments to the project.

The COIAS project will take advantages of the last researches and developments in the networking domain and will evaluate the integration of these different technologies. So, one major phase of the project will be the trials phase. To specify these trials and to evaluate the results, representative applications will be used.

A first step will be to demonstrate individual applications that are representative of potential applications to run over the GII. These applications, audioconference and videoconference interactive tools, Web browsers, distributed games, distributed simulations using the DIS standard, will be provided by the consortium partners and will be very useful to measure the performances on the platform. In a second step, a GII representative application, mixing data, audio, video and security aspects, will be brought by a partner to evaluate the migration process between the current and the new generation of Internet protocols and test an operational application over an Internet NG network using the media server previously mentioned.

The 3rd ACTS call is clearly focused on two main technical objectives that are clearly addressed by the COIAS project:

• The development of novel technologies: the COIAS project is focused on the technologies required for delivering adequate services to distributed multimedia applications using the new generation of Internet protocols above high speed ATM and satellite links. The R & D effort undertaken within the COIAS project can be considered as an added value work taking directly benefits from the results of the previous ACTS programmes that heavily contributed to the deployment of new infrastructure technologies.

• The demonstration of advanced multimedia applications: a large part of the COIAS project is devoted to the demonstration of such applications over a European platform connecting high tech wired and wireless LAN platforms through available terrestrial ATM infrastructures and commercially available satellite links. To be as comprehensive as possible, the COIAS project has chosen various applications in terms of service requirements. This choice makes the demonstration very representative of the services to be offered to new applications in the near future.

To achieve the COIAS project objectives, close relationships will be established with the following standardisation bodies: ATM Forum, IETF. All the partners involved in the project R&D tasks, either industrial (P01, P05, SP02) or academic ones (P02, P03), have already made significant contributions to these organisations. This involvement will guarantee that the results of the COIAS project will be in accordance with the standardisation process thus guaranteeing a direct industrial impact of the R&D effort.

The objectives of the COIAS project therefore mainly address the 3rd ACTS call - Area3 - Task AC321 - (Convergence and Integration: ATM - Internet).

However the project has close connections with Tasks AC126 and AC419.

• AC126 - Interactive Multimedia Services Interoperability:

• AC419 - Concerted actions on satellite communications:

The COIAS project may also have liaisons with other tasks from the 3rd ACTS call. An activity of the COIAS project is totally devoted to inter-projects relationships. It will identify connections with projects focused on other tasks and find ways of co-operation between projects. For example, the COIAS platform will be available for studying the migration of multimedia applications over the new generation of Internet protocols.

The COIAS project has been built around clear industrial objectives that guarantee a direct use of R&D results.

P01 already develops a software stack for the new generation of Internet protocols. For P01, the COIAS project is an opportunity to add some new functions to its product line to handle communications over satellite links, to manage mobility or QoS over heterogeneous networks. The heavy activity in standardisation committees like IETF shows the interest of the industry towards these subjects.

The COIAS project also associates, as a Sponsoring partner (SP02), a major American player in the field of LAN interconnection. This company will put at the COIAS project partners' disposal the IPv6 router software as well as local support. It shows that the COIAS is directly connected to the market with a world-wide vision.

From the satellite network point of view, Sponsoring partner (SP01), has announced that providing advanced Internet satellite services will be one of its strategic future business. This partner is therefore interested in the COIAS project and will heavily support the project by providing significant infrastructure and equipment to the project.

P04 is an SME acting as independent IT security consultant in Germany. The main service offers include enterprise wide analysis and conception of security issues, the implementation of individual security solutions and the development of application-independent security modules (e.g. to provide end to end security - authentication, integrity and confidentiality), strong authentication techniques, digital signatures, key- and certificate management and smartcard solutions).For P04, the COIAS project is an opportunity to add new security techniques according IPv6 to their product range. Furthermore, the provision of a strong certificate infrastructure in a heterogeneous and distributed environment and the following trail and validation phase will give the possibility to improve implementation and maintenance of this infrastructure and the software modules to enhance user trustworthiness and acceptance.

P05 has a clear commercial objective to provide high quality services over the GII and is keen to see the ideas for adaptation and QoS handling proposed in this project, which will assist with reaching this objective, tested in a realistic way. P05 is therefore contributing an application scenario, knowledge of QoS and management requirements, and an application server to enable testing, together with test and integration expertise. P05 anticipates using the results of the project to improve its next generation products and services.

P06 is an SME acting as a network integrator and telecommunication services provider in Greece. Its main involvement is in Internet, X.25, Frame Relay, and ATM technologies. Building the network management components of the COIAS platform will help to further develop an integrated network management system that could work transparently of underlying network resources. This will give the opportunity to control and maintain its network infrastructure and offer to current and future customers better services. Since P06 is acting as an Internet service provider, he will also evaluate the pros and cons that new Internet technologies (IPng, RSVP) will offer to further development of Internet services.

For all these reasons, all the partners of the COIAS project have a strong commitment to develop Internet services over communication networks taking into account satellite communications, heterogeneous networks, mobility, security and to validate these services through significant and short-term industrial and multimedia applications.

TCP/IP protocols in their current version 4 were originally designed 15 years ago for data transmission. At that time, communications link layers offered low data rates and a high percentage of data loss. The goal of these protocols was to ensure reliable transfers between hosts. Now, the need for multimedia (data, audio, video) applications has widely changed and high-rate technologies, such as the ones used in ATM network infrastructure and telecommunication satellites, provide a quite perfect quality of transmission. So, we better understand why the engineering community are redefining communication services and protocols. Simplicity, scalability and universality of IP were the keys of its success. It was designed in order to be easily implemented in a large range of networks from LANs to dial-up access via low-rate modems.

Starting from the quite simple TCP/UDP/IP version 4 model, the communication model for the new generation of Internet protocols has evolved to the more sophisticated one described in Figure 2. This evolution can be explained by:

• The introduction of QoS management that was totally missing in the v4 goals,
• The approach that considers that the variety of new applications cannot be addressed by a single transport protocol,
• The variety of subnetwork technologies to be supported by the GII (IEEE LAN, ATM, ISDN, Cable networks, ...).

The first brick taking place at the network level layer of the model, is the IPv6 one. It brings:

• IP addresses expansion from 4 bytes to 16 bytes,
• Authentication and encryption algorithms,
• Packet size optimisation,
• Header simplification for faster routing,
• Flow label identification for QoS management,
• Autoconfiguration for mobility management purposes,
• IPv4 compatibility.

Today, numerous proposed standards related to IPv6 have been defined in the IETF IPng working group and have still to be refined before getting the Standard status. The first IPv6 implementations on wide area platforms will provide results that will lead to the final standardisation step. In the US a first IPv6 +backbone (CAIRN) is going to be deployed and will interconnect major academic and industrial laboratories.

On top of the IP layer, we find the classical TCP and UDP transport layers that have been slightly adapted to the IPv6 version.

The large variety of application requirements imposes to define QoS classes. QoS classes have been defined first in ATM networks. For few years, the IETF has been defining the Internet IntServ and the RSVP signalling protocol. It is used to carry the booking information throughout the network, complies with the multicast data transfer requirements and allows a user to join an existing session. The goal of the QoS Manager is to define an API that would make the interface between RSVP and the user/application. The idea is the QoS Manager should propose the user/application few QoS classes with very simple and easily understandable QoS parameters so that the application does not have to be preoccupied with the detailed RSVP mechanisms.

The IntServ are aimed at defining the mechanisms to be implemented in the network nodes such as admission control and scheduling mechanisms. To be implemented over subnetwork technologies, the IntServ have to be mapped in order to take advantages of the under layer services. That is the role of the ISSLL. ISSLL have already been specified for ATM.

Three classes of service have been defined by the IETF:

• guaranty,
• controlled load,
• best effort.

For all these three classes, the mapping with the ATM services has been studied. It will also implement all the functions needed for the use of ATM such as the MARS and the Multicast Server. The use of large ATM clouds will lead to implement new mechanisms able to optimise the use of the ATM infrastructure. The solution consists in setting up shortcut route between the routers connecting to the ATM cloud, to minimise the number of routers when possible. It provides the best way to take advantage of the ATM infrastructure deployment.

The use of unidirectional satellite links, with the use of a terrestrial network for the return path of communication, introduces also new problems. This kind of asymmetric network has been studied for a couple of years by three partners. Their works have led to a proposed IETF standard.

Above transport layers, protocols adapted to the nature of the applications have been defined. The first one is RTP that has been specified to support audio and video transfers. Other protocols have not been specified yet. An other important feature of the new generation Internet protocol is the capability to provide enhanced transport functions and facilities whatever the network topology, and whatever the communication topology (point-to-point or multipoint) might be. RM data transport is a requirement for numerous applications. The applications used in the project have this kind of need. But that is also the case of many distributed applications that require coherent data bases, and also the case of applications using a publisher/subscriber model of communication (delivery of news, business information, stock exchange information...). To allow a future standardisation of RM protocols, a new IRTF working group has been created in December 1996.

The DVB standard is a remarkable success, not only in Europe where it is well established, but also in the rest of the world where it is gaining widespread acceptance. In Europe, it is THE standard for digital TV, DTH distribution. over Europe, there are already more than 500 DVB TV channels being beamed down from various satellites located within an geo-stationary orbital arc, serving approximately 1.5M homes (direct digital satellite reception) as of mid-1997. At least 4 other satellites dedicated to digital TV for Europe, are going to be launched into orbit by the end 1998, each satellite adding roughly 160 additional digital TV channels (at 4 Mbps per channel). DVB services are also rapidly deploying in America (North and South), Africa and South-East Asia. Thanks to this economy of scale, the DVB standard offers the benefit of very low-cost digital terminals not only for consumer applications but also for small business applications.

There are many different user applications that could be specified as using data transmission protocols. They have been developed to meet different user requirements. Nevertheless, the applications data transmission requirements can be generalised in terms of the type of data to be transferred. These data types are:

• text message/Email,
• file/image,
• real-time voice and video,
• interactive,
• distributed.
• broadcast,

During the trials phase of the project, applications based on partners technologies or on commercial products will be used to evaluate the performances of the proposed GII. These applications will cover these data transfer types.

Today, the data communications are undergoing a period of revolutionary change towards real-time and multimedia. This deployment is based upon three enabling technologies:

• most new workstations now include built-in multimedia hardware, including audio codecs and video frame grabbers, and the necessary video gear is nowadays inexpensive,
• for the new hardware resources, highly-sophisticated digital audio and video applications have been developed,
• applications using multicast, such as news distribution, distributed interactive simulation, network games have been developed.

These technologies allow widely-scaled use of audio and video applications over the network, and a smooth integration with the data processing ones. But, the problem for a wide dissemination of these new generation applications is the network capacity limitations:

• multicasting is not yet generally available in commercial routers, and is being provided by the MBONE, a temporary Multicast Backbone,
• time-constrained applications often do not work well in the Internet because of variable delays and network congestion of the best effort service.

Time-constrained applications are quite different from standard data applications and require service that cannot be delivered within the typical data service architecture. The following paragraphs present the characteristics of three categories of time-constrained applications.

Digital video and audio require periodic updates of information to prevent the image or voice playback from degrading. Latency is the principal concern because of human perception limitations. Depending on the quality of signals transmitted, throughput demands can be very high. Compression is typically used to lower this throughput requirement. For video to appear normal, however, data must be digitised, compressed, transmitted, received, uncompressed and undigitalised within 1/30 of a second. The distribution of this type of data does require the reserving of net resources for the purpose of assuring a QoS level where, typically, latency and jitter are the constraints.

Video teleconference requires group formation policy that allows initiating a session, joining existing sessions, leaving a session without tearing it down if any participants remain connected, and terminating the session. It requires the capability to conduct a tightly-controlled N x N session if the number of participants is restricted; or, a loosely-controlled session in a session from 1 to N where the number of participants may be quite large. In any case, control over group membership must be available.

Collaborative work tools, planning tools and distributed whiteboards are examples of interactive multimedia applications. A distributed whiteboard is a conferencing tool that distributes pages of a whiteboard such that any participant can draw on any page. The goal is to have consistent views across multiple platforms, therefore, the processes implementing the whiteboard must exchange the current state of the data. The operations that any participant performs on a page must be sequenced and timestamped. Each participant is both sender and receiver. Each member is responsible for detecting loss and reporting this to the group and for periodically informing the group of their place in the session. Repair requests could be multicast to the group and any member of the group could effect repair. This, in turn, requires the members of the group to have some concept of the distance to each participant in the group and to invoke an algorithm for repair that minimises responses to repairs. This can be satisfied by timestamping the status information multicast to the group. Priority is utilised to determine the importance of transmitting the current page, a new page, or repairs to a previous page. Data in these applications are characterised as reliable, duplicate free, ordered by source, and delivered within a finite period of time.

Distributed simulations, situational awareness, real-time sensor data, virtual reality gaming, billing distribution, and the dissemination of stock quotes are examples of real-time data exchanges in this category. Any virtual environment among hosts in a distributed system that are simulating the behaviour of objects in that environment fit this category. Applications like distributed gaming and virtual reality require that terrain and environmental updates be distributed in a multicast fashion with low packet loss and low latency. Objects in this environment are capable of physical interaction and can sense each other by visual and other (sensor) means.

These applications are characterised by large scale memberships which need to share a consistent view of the game space even in the face of packet loss. In entertainment scenarios the number of simulated objects could exceed 100,000 where each object produces a real-time flow of 15 packets per second. Unlike applications like videoconferencing, these applications cannot tolerate frequent updates of data to guarantee freshness. Freshness is required yet updates necessarily are infrequent for objects like terrain updates. These applications are intended to work with input to and output from humans interacting with distributed simulators in real time. Human perception is the normal quantifier of latency requirements (approx. 100 milliseconds).

The distributed process control or replicated database are also this category. The distinguishing requirement is the need for total order. Application tasks could be divided among processors in a system and data replicated to protect against failures. There is a need to co-ordinate the tasks and reach consensus on state. Manufacturing process control needs to schedule processes distributed across the system. A consistent database is necessary to reach consensus.

The first goal of the project is to bring efficient solutions to map a widespread technology like Internet whose current specifications are not able to provide the necessary level of service, with a new infrastructure technology, namely ATM, that includes all the requested features in its specifications. The COIAS project is focused on the development of missing elements that will drive to a true convergence between the new IP and ATM. New applications and services taking benefits from this convergence will be brought to the users.

Concerning satellite communications, the COIAS project aims at developing the technologies to be embedded in end systems in order to provide the market with added value services. Referring to the market analysis led by the EC, it is obvious that the COIAS project contributes to strengthen the European position on this key market. Only communication architectures based on the new generation of Internet protocols will be able to satisfy the users requirements in terms of mobility management, Quality of Service guarantee, security management. As the project deals with Internet network and transport layers, the proposed solutions will be easily transposable to future satellite technologies.

At last, the COIAS project includes comprehensive trials over a very wide platform. The results of the project will be therefore representative of a global Internet infrastructure thus guaranteeing a direct exploitation of the project results.

The primary strength of the COIAS project comes from the team itself. The consortium relies on a close co-operation between well known and highly skilled research centres and major industrial and non-competitive partners including technology providers and end users. The COIAS project will take advantages of the knowledge and developments of the different partners to specify and build an efficient Internet Infrastructure that complies with the ongoing Internet standards.

The COIAS project is based on the Work Breakdown Structure depicted in Figure 4. The project is structured around three WPG:

• Management (WPG 1000),
• Global Internet Infrastructure (WPG 2000),
• Validation platform and Trials (WPG 3000).

These WPG are themselves divided into eight WP that can be easily managed by an individual partner.

Figure 5 shows the inter-relationships between the different WP. The proposed duration for the COIAS project is 24 months.

Figure 6 depicts the overall work schedule for the project and also shows the date of availability of the project deliverables..

The management WPG includes the project management itself as well as the co-ordination with other ACTS projects related to with overlapping areas of interest. The COIAS organisation for management is clarified in section 5. The partners involved in the COIAS project are fully committed to respect this organisation that is necessary to manage efficient relationships between widely geographically distributed companies and research organisations.

The Project Manager is responsible for all the technical and financial aspects related to the project. For that purpose, the Project Manager will be in charge of updating:

• The current technical progress that indicates the project progress compared to the expected one. This document gives a regular status concerning the availability of the deliverables. It points out potential problems in the programme schedule and describes corrective actions to overcome these problems.

• The current cost estimates which verify that the expenses are in accordance with the project estimates. The costs for equipment, trials, communication expenses will be periodically refined.

As the trial phase is very important to validate the project results, the Project Manager will particularly take care of the trials schedule. The COIAS platform is wide and involves a lot of technologies, so the trials require an efficient organisation to be performed.

For important decisions, the Project Manager relies on the support of a Steering Committee including a representative of each partner. A co-ordinator for each WP is in charge of the work to be done for a technical task. This organisation seems to be a good trade-off between an efficient project management organisation and too heavy administrative procedures

The EC pays attention to the links between ACTS projects. A specific activity has been organised and placed directly under the Project Manager responsibility for that purpose. At the very beginning of the project, the Project Manager will release a document identifying the potential areas of co-operation and the way and schedule to put this co-operation in place. This document and the associated actions will be periodically updated.

Validation and demonstration of the R&D work done in the WPG 2000 is of prior importance for an ACTS project. As the COIAS project brings into play a lot of technologies, careful attention will be paid to that subject. A comprehensive platform distributed over Europe will be put in place to support the trials planned to verify the choices in terms of:

• services identified in WP2100 to be provided to the applications,
• architecture definition,
• implementations of the functions identified in WP2200 (IP over ATM and satellite, QoS management, security management, mobility management, TCP and RM over satellite, alternate path routing and network management).

A first idea of the validation platform used for the COIAS project is depicted Figure 7. It gives its main features and this architecture will be refined during the WP3100. This European platform relies on a WAN based on two kinds of infrastructure technologies:

• An ATM terrestrial WAN interconnecting partners premises. At the present time, there are ongoing negotiations amongst the Service Providers, and between them and the EC on the nature of networks which will be provided to support the ACTS projects. It will be necessary to determine exactly what ATM networks will be available to the projects, which partners will be connected, and the characteristics of the networks. Nevertheless, most of the partners involved in the project have already connections with ATM networks. They will be described hereafter.

• An existing satellite infrastructure based on SP01 satellite network. The satellite test network will be dimensioned to ensure initially the reception of 2 Mbps with consumer-type TVRO of 80cm in the Western part of Europe. In the course of the Project, occasional extension of the receive coverage and the data bandwidth (up to 6 Mbps keeping the same receiving antenna size) can be offered and will be decided on a case-by-case basis (in view of the relevance of the new requirements and subject to capacity availability from SP01 at the time of the request). The COIAS satellite network will include three uplink stations, located at P02, P03, SP01 premises respectively in Nice, London and Paris. An additional mobile uplink antenna will be made available at the end of the project for demonstration purposes. Each partner will have receiving links, thanks to PC boards (up to 15 for the whole project) provided by SP01 to all the partners without any contribution from the EC. A reasonable number of free of charge communication hours (around 20) will be offered by SP01 to test the different validation scenarios. Additional hours are budgeted for extensive tests and demonstration purposes.

The partners' INTRANET networks will be interconnected through this WAN infrastructure thanks to commercial routers including IPv6 routing functions. This software will be provided by SP02 without any contribution from the EC. Each INTRANET network includes a comprehensive set of computers (workstations, PCs) running under various environments (UNIX, Windows). P01, P02 and P03 will make available their IPv6 stack and related protocols for end system software development as well as their in-house available applications (audioconferencing, visioconferencing, mail, browsers, distributed simulations). These applications will be used in first integration and validation steps as well as for basic demonstration purposes.

At the P01 premises, a local network infrastructure built around ATM switches from different vendors will be used. This ATM backbone network interconnects LAN thanks to ATM/Ethernet switches. The platform also includes WLAN based on two different technologies. A first one in the 2GHz frequency range providing a 2 Mbps data throughput will be used. A second one, the recent ETSI HIPERLAN standard, will provide up to 20 Mbps data rates using transmissions within a 5GHz frequency range. Products compliant with the HIPERLAN standard are being developed by P01 and will be available for the COIAS project platform. The P01 network interconnects workstations and PCs running under UNIX, AIX, Windows environments. Regarding the connectivity of this platform with other partners ones, ISDN links are now available and P01 plans to connect this platform to an ATM infrastructure in 1998. Throughout its INTERNET protocols developments, P01 is also connected to the 6Bone network by a router including a firewall and security management functions.

P02 has installed its own platform including LAN, ATM and a WLAN provided by NEC (25 Mbps), and is experimenting the support of an Internet videoconference application on a global network with wireless links. Problems such as high level versus low level FEC and multicast congestion and error control are studied in this context. P02 will have access to a national ATM network through a regional platform. P02 will also have access to the MIRIHADE platform in a collaboration with French research centres. This platform will allow us to evaluate the ATM technology, but also to design mechanisms for end-to-end resource control on heterogeneous network with IPv6 as the interoperability level.

At the P03 premises, there will be an ATM infrastructure inside the site, with gateway facilities to the outside world. We hope that this infrastructure will provide ATM connectivity to two other partners. It is clear that there will be such connectivity to P05, at high speed; at least 155 Mbps will be available using the LEARNET facilities. P03 will also have access to JAMES network, as long as some variant of that is being provided; this should allow access to P02 via RENATER, but this is less certain. P03 will be running both an ISDN and a mobile radio IP gateway. The P03 mobile facilities will be at the least WAVELAN equipment with a capability of 2 Mbps; there will probably be other forms of mobile equipment with both higher capacity and broader range lower capacity (GSM).

A media server and a cache will be available at P05 premises. This will be connected to the internal LAN (switched Ethernet and ATM backbone). P05 will also connect with P03 via LEARNET, an ATM wide area broadband research net.

P04 will interconnect its Intranet to the platform through available ISDN links.

The network management system will be available at the P06 premises. This will be connected to the internal LAN and through P06 international connectivity used in the COIAS project. P06 will use ATM LAN infrastructure located in its premises at the trials phase of the project. The P06 network interconnects workstations and PCs running under UNIX, Solaris, Windows environments. P06 could also use an already established internal backbone that presently connects three POP. This backbone is currently used to offer connectivity services to large corporations. Regarding the connectivity of P06 platform to other partners platforms international connectivity (2 Mbps) to London and Paris is already existing and is planned to be upgraded in 1998.

As the COIAS platform integrates a very large number of components, the WP3100 will define the integration steps. These steps will follow a bottom - top approach, firstly for individual INTRANET integration then for the WAN platform integration. This integration will begin on a partner to partner basis and then will go on with the whole platform integration.

The WP3100 will also define the validation strategy including the following actions:

• Identification of the different elements of the platform in terms of infrastructure networks, local area networks, end systems,
• Identification of the services to be tested related to the user requirements definition,
• Test organisation,
• Test management (synchronisation between remote resources for example),
• Definition of the necessary scenarios to test the identified services,
• Definition of the parameters (which ones, which values) to be measured,
• Description of the tools, measurement equipment necessary to perform the test,
• Precise description of the scenario including equipment, human resources and skills, communication links availability, ...
• Estimation of the scenario costs,
• Test planning.

A document including the test forms will be issued with a preliminary test schedule. This schedule will give a first idea of the necessary logistics to perform the tests. It will be updated later during the platform integration in order to take into account the latest information in terms of resource availability and communication costs.

This WP3200 is devoted to the implementation of the seven main functions identified and specified in the WP2200 and required for a Global Internet Infrastructure.

Compared to the WP2200, the distribution between the different activities is driven by implementation purposes. The work will be therefore divided as follows:

• Protocol stack development: It will include the development of the functions to be implemented in the end system such as end system network layer functions (IPv6), transport layer functions (TCP, RM), end system functions for QoS management (IntServ and RSVP), mobility management, end system functions for alternate path routing. The end system software is also related with other development activities. As a matter of fact, the security functions (IPSEC, authentication of users) as well as network management functions will have to be integrated in the host. As these functions will be developed by different partners, particular attention will be paid to interface between functions in order to ease the whole software assembly, integration of test. The developed software will tested in front of the IPv6 router software provided by SP02.

• Security development software: To provide host security according to the policies specified in WP2200 it is necessary to define an interface between the IPv6 ESP and AH implementations and the CPKI represented by the enhanced DNSE. User authentication requires also an interface to the CPKI, but moreover the specification of the whole infrastructure itself, e.g., certification and registration authority, which provides the key, certificate generation and their distribution. Additionally support of SmartCard or SPSE must be integrated to ensure proper authentication of individuals. The reference implementation will be set-up at the premises of P04. The reference software will be developed on one hardware and operating system only. P04 will receive the software modules necessary to provide security functions within the IPv6 stack provided by P01. Security servers will remain at premises of P04. Additional software for user authentication will be delivered to the partners (binaries), additional hardware (SmartCard reader) are required at each site.

• Media servers development: This development will make possible the capability of generating the data streams to be distributed over the satellite channel representing the data exercising the applications, of distribution of the media streams to different proxies to emulate realistic testing scenarios, for multicast operation, capability to record media streams in specified proxies and to collect, aggregate and annotate the media streams from the proxies.

• Multimedia application development: This development will include the necessary adaptations to take benefits from the new protocols to be developed in the project. Current applications are adapted to standard TCP/IP v4 protocols and are not able, for example, to use the IPv6 and RSVP parameters for QoS management. The specifications issued in WP2200 will be used as a starting point for the application adaptation. The development will derived from an existing product.

• Network management: This development will provide the management system distributed over the COIAS platform. The management platform will be installed at the P06 premises and the management agents will be installed in the distributed equipment. It also provides the user interface and the report management files.

After testing, all these software components will be distributed between the partners according to the COIAS platform definition. The partner in charge of the development will bring its support to the others for installation, configuration and test.

The WP3400 will verify that the network architecture proposed in WP2200 is able to satisfy the service requirements defined in WP2100. The trials performed in WP3300 will be used to qualify and quantify this ability.

A first part of the WP3400 will compare the user requirements listed in WP2100 to the trials results. For each identified class of service, this comparison will be based on quantitative and qualitative aspects. In case of mismatches between the expected results and those obtained, a critical interpretation will be given.

Secondly the WP3400 will give a feedback on the architecture design. The capacity to extend to apply the results obtained on the COIAS platform to a more general architecture will be analysed and discussed. For the main issues studied in the project (QoS management, security management, mobility, alternate path routing, network management, reliable multicast, IP over satellite, media server), the WP3400 will show that the chosen options during the specification and design phases are relevant for an efficient convergence between Internet and ATM, for using the new generation of Internet protocols over an heterogeneous architecture including satellite links. The WP3400 will give some guidelines about the appliance of the project results to future satellite technologies.

A road map to implement these solutions in commercial products will also be proposed.

After the detailed description of the WPG and WP in section 2, they are hereafter summarised using the M4C forms.

Forms M4C to be inserted:

• 1000, 1100,
• 2000, 2100, 2200, 2300,
• 3000, 3100, 3200, 3300, 3400.

The contents of each deliverable are detailed using the M4DD forms.

During the first year, all the WPG will be in progress.

The following WP will be concluded:

• WP 2100 - Service Requirements,
• WP 3100 - Platform Definition.

The WP 2200 (Network Architecture Design) and WP 3200 (Platform Development) will be in progress and will be concluded during the second year of the COIAS project. The general WP related to project management (WP 1100) and standardisation activities (WP 2300) will be of course in progress.

The WP3300 (Trials Campaign) and WP 3400 (Trial Results Evaluation) WP will only begin during the second year of the project.

• 01/00 (Project beginning)

• D0: Inter-relationships with other ACTS projects

This activity is devoted to the co-ordination of the COIAS project with other identified ACTS projects.

The objectives of this activity are to disseminate as largely as possible the technical objectives of the COIAS project in order to find as soon as possible in the course of the project areas of co-operation with other ACTS projects.

The management of relations between COIAS and other projects is directly placed under the responsibility of the Project Manager. At the very beginning of the project he will establish direct contacts with other ACTS projects in order to identify a first list of projects.

After this first step, he will focus on the most promising ones and will issue a document describing the selected projects, the area of co-operation with other projects, the expected benefits as well as the impacts in terms of results, schedule and costs.

During the project he will participate in periodic concertation meetings. Particular attention will be paid to projects selected in the AC126 and AC419 ACTS third call tasks since their goals seem to be very complementary to the AC321 ones.

In order to keep the EC informed, the status of the relations with other projects will be summarised in a section of the Management Control Report. It will be detail in the Progress Report.

• 01/00 (Project beginning)

• D7: First annual project report

This activity is devoted to the COIAS project co-ordination vis-à-vis the EC.

The goals of this activity, placed under the responsibility of the Project Manager, are to co-ordinate and supervise the partners activities to maintain technical progress, schedule and costs as necessary to achieve the project objectives. As authorised representative of all Partners, the Project Manager maintains the primary interface with the Commission for the submission of deliverables, for technical verification and audits and for any other required clarification or justification.

The overall management of the COIAS project is directly placed under the responsibility of the Project Manager. He is responsible for:

• detailing the project procedures for aspects such as document control, project meetings...
• maintaining project archives;
• being responsible for tracking the project flows (financial, time allocation, progress...);
• co-ordinating the consortium dissemination policy;
• acting as the Co-ordinating Contractor in front of the EC;
• delivering to the partners the formal documentation;
• reporting the project status to the EC (through project reports and project reviews);
• collecting and submitting Cost Statements.

To minimise any risk during the course of the project, the Project Manager is in charge of setting up a risk management chart at the very beginning of the project.

Thanks to these permanent monitoring activities, he will be able to decide corrective actions in a timely and cost effective manner. For important decisions, he will be helped by the Steering Committee.

• 01/00 (Project beginning)

• D1: User application requirements document

This activity is devoted to the identification and definition of the GII applications requirements, from an end-user viewpoint.

This activity will characterise the GII user application requirements in order to have a reference for the trial phase. The results of the trials will be compared to the requirements in order to verify the relevance of the work done within the project.

The process will follow this path:

• Identification of the individual applications to run over the GII architecture. By individual applications, we understand applications like electronic mail, file transfer, audioconference, visioconference, browser, distributed game,... A realistic GII application generally combines these individual applications to offer multimedia services.
• Description of the services expected by each application (data transfers, network synchronisation, network management, ...).
• Classification of these services in terms of kind of transfers (bandwidth, accepted delay and jitter, accepted bit error rate, ...), communication topology (point to point, multipoint, broadcast), priority, geographical coverage, expected reliability, level of QoS, level of security expected, mobility, ...
• Identification of network management impact.
• Identification of relevant parameters for each class of service.
• Quantification of these parameters.

The COIAS partners will use their background gained in Internet applications development. The user requirements characterisation will be used as a reference during the rest of the project.

• 01/00 (Project beginning)

• D2: Service providers capabilities and requirements

This activity will give a detailed description of the services offered by the infrastructure networks selected for the COIAS project, from a network operator and service provider viewpoint.

The goal of this activity is to characterise the services to be offered by the infrastructure network in order to compare them with the user application requirements.

The work will be shared in two parts, each one corresponding to one of the selected infrastructure network - ATM and Satellite.

For each network and for different corresponding communication costs, the following information will be given:

• Available bandwidth,
• Transfer types,
• Delay and jitter,
• Bit error rate,
• Communication topology,
• Offered levels of QoS,
• Service availability,
• Service reliability;
• ...

The activity will also precise the requirements of the network operators and service providers in terms of network management, exploitation and billing.

• End of WP2100

• D3: Network architecture specification - Part 1
• D9: Network architecture specification - Part 1

In this activity, we will specify the way to map IPv6 with ATM and satellite facilities, the mechanisms necessary to handle the ATM VCs and set up shortcut route between nodes. We will also defined the IntServ mechanisms, their link with the RSVP protocol and the QoS manager.

The objectives of this activity are to specify:

• the services provided to the applications and the associated qualities. These services will be defined in term of APIs (sockets type APIs),
• the protocols and their options that will be implemented,
• the functions and mechanisms that will have to be developed to complete the existing software.

Starting from the definition of the Internet QoS classes (guaranteed, controlled load and best effort), we will specify the required functions and mechanisms to implement in the end-systems as well as in the routers. These mechanisms will have to be compliant with the RSVP and IntServ proposed standards. A particular attention will be given to the definition of the API and of the QoS manager.

Among the QoS mechanisms we will define: the admission control mechanisms, the policy control mechanisms, the classifying and scheduling mechanisms. For that we will propose a way to use the IPv6 priority and flow label fields.

About the coupling between IP and ATM, this phase will allow to specify the way to aggregate IPv6 flows over VCs, the management of the VCs to allow RSVP traffic, and the set-up of shortcut routes to optimize the use of the ATM technology. These specifications will be driven in relationship with IETF and ATM-Forum standardization efforts. The QoS translation between the Integrated Services and ATM will follow the current proposed standard.

For the multicast data transfers, we plan to use a MARS server. This server could be completed to managed not only ATM based station addresses, but also satellite based station addresses. On ATM, a multicast server architecture will be used to provide multicast services.

• End of WP2100

• D3: Network architecture specification - Part 2
• D9: Network architecture specification - Part 2

In this activity we will specify the facilities that must be supported by the GII to allow the use of mobile stations or of mobile users.

The objective of this activity is to specify the necessary functions and mechanisms required by a mobile station or a mobile user to set up communications with the GII.

When mobile computers move and attach themselves to new networks within the GII, they can use mobile-IP as a means to achieve seamless roaming transparently to application software. Mobile IPv6 takes advantage of the mobile IPv4 experience and provides smooth solutions to manage mobility. These solutions take advantages of new IPv6 features such as the management of the anycast addressing.

Starting from the mobile IPv6 draft specification we propose to specify the complementary functions required by host stations and routers to provide mobile access points to the GII. Several ideas have been proposed. As an example, we plan to investigate the Logical Addressing concept whose goal is to specify an intermediate layer between the transport protocol and IP in order to transfer information in a transparent way. The intermediate layer allows to manage the correspondence between the logical layer and physical addresses that may change if some of the subscriber are mobile.

• End of WP2100

• D3: Network architecture specification - Part 3
• D9: Network architecture specification - Part 3

In the frame of this activity we will specify the functionality of the security infrastructure, which must be provided to implement a secure platform and the impacts to the COIAS network according to the demands coming from the services requirements.

The objectives of this activity are to specify the architecture to be provided in COIAS from the viewpoint of providing a security infrastructure to meet the requirements of a common security policy. The specification of a COIAS security policy should meet the requirements of D1 (application) and D2 (service provider).

Security policies represent a set of selected security countermeasures. For information purposes a security policy also reflects the security requirements which are enforced by security measures. Therefore, a security policy can be understood as a catalogue or a list of security measures together with corresponding security requirements. Based on the result of the requirement analysis (WP2100) the security policies for the COIAS platform will be specified as well as the required technology for implementation.

Inter-domain security policies require the availability of an infrastructure with certification and registration authorities as well as key distribution services based on the concept of Public Key Cryptography. According to the ISAKMP framework, the OAKLEY-approach will be used to grant user and host authentication supported through negotiation, establishment and management of SA between the communicating entities. The implementation of these protocols is based on ISAKMP version 6 and ISAKMP+Oakley version 2 (depending on the availability of that implementation for the COIAS target platform and for the active network components (routers)).

ISAKMP does not specify the protocols for communicating with the TTP or certificate directory services. These protocols are defined by the TTP and directory services themselves and are out of the scope of the ISAKMP specifications.

However, the verification through certificates is required and must be provided through the CPKI. Host certificates can be provided through the enhanced DNSEC (RFC 2056). User authentication requires CA and RA to be located in the COIAS network.

To provide the highest possible availability of the CPKI, two different approaches have to be investigated: redundant design and implementation of sensitive network components (CAs/RAs) or the usage of Caching and Revocation lists.

• End of WP2100

• D3: Network architecture specification - Part 4
• D9: Network architecture specification - Part 4

This activity will described the mechanisms for enhancing the performance of TCP and RM in a hybrid satellite/terrestrial network.

The objectives are to describe the design and the implementation of these mechanisms.

We expect to require a range of services for the applications being pursued here. Some of these, like audio and video, require a reasonable QoS – but not reliable transmission. Some of the point-to-point services must be reliable; for these TCP is probably adequate. TCP can provide reliable transmission, but it can be a very inefficient mechanism if there are large variations in QoS in constituent parts of the path. For this reason, we expect to explore some of the window control strategies developed in UC Berkeley for dealing with mobile systems. These adopt different window management systems, and have the gateway play an active part in the flow management.

Another set of services will require RM; here it is very inefficient to request retransmission from the source of the transmission; it is much more efficient to request it progressively up the multicast tree. This is the technique used in one form in the Shared WhiteBoard tool, and in another way in the Network Text Editor. A number of mechanisms for achieving reliable multicast have been proposed; indeed the September IRTF meeting in Cannes have been devoted entirely to this subject. Several of the mechanisms, which have been proposed by the IRTF, will be investigated further in this activity to assess their relevance to these applications.

• End of WP2100

• D3: Network architecture specification - Part 5
• D9: Network architecture specification - Part 5

For the COIAS targeted applications, many forms of network can be used from a given end-station; these may include satellite, terrestrial and mobile. Some of the end-stations will be able to use mobile and satellite; which is more appropriate depends on a complex interplay of QoS, tariff and service parameter considerations. We will deliberately introduce situations where such alternate paths would be possible, and develop techniques by which optimal routes would be adopted -within the constraints proposed.

The objectives of this activity are to specify the architecture to be provided in COIAS from the viewpoint of providing alternate path capability .to meet specific requirements. The specifications should both meet the requirements, and be sufficiently complete to allow a further implementation phase.

Once the natures of the networks, which will be available in the trials, have been established, we are in a position to specify the complex routing, which will be possible. This will incorporate the choice of mechanisms that we intend to implement in the gateways, and the routing strategies we plan to support in the routers. The mechanisms for routing, reliable multicast, authentication and network interconnection all have a mutual interaction. We will specify the architecture – including what mechanisms are immutable, and where choices must be allowed to enrich the possible experimentation.

• End of WP2100

• D3: Network architecture specification - Part 6
• D9: Network architecture specification - Part 6

In this activity, we will specify the facilities, which must be provided in the media servers, and the architecture required for their performance.

The objectives of this activity are to specify the architecture to be provided in COIAS from the viewpoint of providing media servers to meet specific requirements. The specifications should both meet the requirements, and be sufficiently complete to allow a further procurement or an implementation phase.

In this activity, we will describe detailed components of the multimedia server prototype. Clearly the prototype must meet the applications requirements of D1 and the Service Provider capabilities of D2. It is expected that the server will be derived from an existing product with its own documentation; hence our first activity will be to survey the status of existing multimedia products – both from the partners and from commercial vendors. The aim will be to have a good understanding of what products could form the base for the COIAS multimedia servers. We will then link with the other activities in this activity, to ascertain their needs in a server.

The Server must provide many functions; some of them are defined below:

• To allow the storage and controlled replay of data needed to run the trials scenarios;
• To provide information of interest in its own right during the trials;
• To act as a repository for project material, including recordings;
• To provide consistent data to exercise specific components during a testing phase;
• To record measurement and monitoring data during the trials.

These functions will require considerable expansion in the light of the other activities in WP2200; thus there will be strong liaison with those carrying out these aspects. We expect that many of the functions will be achievable with a centralised server; indeed at least one centralised server will be required. In addition, some of the media serving may be best done in a distributed fashion – particularly when the interconnecting data networks cause delays and act as communications barriers. For this reason, part of the media serving will include a distributed architecture, where a central server controls proxies. Sometimes the data must obey particular protocol conventions; it remains to be decided to what extent these protocols will be embedded in the data, and to what extent the players will need to be designed to obey the relevant protocols. In the Server architecture, we will pay particular attention to the protocol activities of the MMUSIC group in the IETF, with their RTSP – though we will look carefully to what extent the RTSP assumed environment matches the COIAS applications.

• End of WP2100

• D3: Network architecture specification (intermediate) - Part 7
• D9: Network architecture specification - Part 7

In this activity we will specify the functionality and the architecture of the network management system that meets the requirements coming from WP2100.

The objectives if this activity are the following:

• to specify the functionality of the network management system that meets the requirements,
• to specify the architecture of the network management system,
• to design the human computer interface of the network management system,
• to specify interactions of the network management system to other components of the COIAS platform.

Having in mind service requirements coming from WP2100 and in parallel with information on network elements (MIBs, supported management protocols) we will obtain from other activities inside WP2200, we will start specifying the required functionality of the network management system.

Service requirements and standards related to human-computer interfaces will also affect the design of the user interfaces of the COIAS network management system.

Interaction of the network management system with other components of the COIAS platform (e.g. alternate path routing) will also be studied and specified.

• 01/00 (Project beginning)

• D8: Standardisation first annual report

Assessment of the standardisation activities in a number of relevant Standards bodies in relation to the activities being pursued in this project.

The main objective of this activity is to ensure that our activities are consistent with the relevant standards that are being developed both inside, and outside the ACTS programme.

In general the ACTS programme is pioneering the field of B-ISDN, and the relevant standardisation is carried out mainly in the context of the relevant ITU-T, ETSI and ATM Forum bodies. While the main activity in the IETF was IPv4, and its many related protocols, this was a valid approach; it was clear that the Internet of that generation was unable to provide the QoS required for the B-ISDN. Now, however, the IETF is moving towards IPv6, and there are many relevant activities in Routing, Mobility, Transport Resource Reservation, Multicast and Security, which have a direct bearing on the work of this project. We expect to participate strongly in those aspects of the IETF, which impinge on this project in two ways. We will ensure that we take due note of the advances being made in the IETF to guard against our going in a lone direction, and we will ensure that the relevant protocol results are fed back into the IETF to influence its directions. Here we will capitalise on the excellent relationships particularly the academic partners in the project already have with the IETF. Many of the partners to this proposal already participate in ETSI and the ATM Forum; we do not anticipate increasing our involvement with these bodies; we do, however, expect to link between the attendees at these bodies and the IETF.

The aim of this project is to emphasise the convergence of the ITU-T and IETF approaches. For this reason, we will link also with the ACTS projects in this area. The procedures used over the DBS satellite are fundamentally the DVB procedures; for this reason there is a close involvement already with some aspects of the DAVIC standards. We expect positive stimulation to all parties from the fact that this activity is involved with this rich range of standardisation bodies.

During the first year, the main concern will be to ensure that the architecture chosen, and the implementation phases to be adopted, are aligned to the emerging standards. This activity will be partially to track, evaluate and apply the relevant standards; during this year it will also involve influencing the standards to be compliant to the distributed architectures, multicast facilities, and QoS services, that are required.

• 01/07

• D4: Platform architecture definition report

This activity is devoted to the definition of the platform that will be used to validate the developments undertaken within the project.

The goal of this activity is to define a platform as representative as possible of a GII architecture. The platform will be based on the equipment and applications at the partners’ premises interconnected trough a WAN infrastructure based on ATM and satellite links.

The first step will be to identify the partners resources that can be used to demonstrate through validation scenarios that the requirements listed in WP2100 are fulfilled on the platform.

So, this report issued during this activity will give a precise description of the WAN links used to interconnect local Intranet networks that will also be individually detailed. End systems (workstations, PCs, servers) and routers will be identified as well as software configurations running on each end system (operating system, communication protocol software, applications).

As the COIAS platform includes a large set elements, the document will also detail the different steps necessary for software delivery and platform integration.

• 01/07

• D5: Validation strategy definition and tests forms
• D6: Tests and measurements planning

We will define the strategy to be used to validate the advantages of this application to the emerging communications infrastructure, and the way the individual components can be tested.

The objective of this activity is to specify the strategy for assessing the suitability of the COIAS architecture for the applications foreseen.

For each application portion, we will generate a set of realistic scenarios. The applications partners will provide detailed information on the data, and much of this will be stored on the media servers with instructions on how it is to be invoked.

From D1, we will have a clear indication of the user applications requirements; from D2 we will understand the network services that can be provided. In activities 2210 – 2260, we are providing the intermediate architecture specifications of the different components. In this activity, we will link closely with the other activities in WP2200, to understand the approximate architecture that will be provided in COIAS; this includes what network connections should be provided, and the hardware and software configurations that will be employed. These will be used to define the component tests that must be performed, and the testing components needed to achieve the validation. The validation tests may have implications on the components that need to be provided; for instance distributed timing may require the provision of appropriate timing facilities by incorporating GPS-based clocks at each participating site. The early work will include an assessment of the measuring facilities available; this will include an analysis of the measurement tools provided for both NICE and MECCANO network measurements. We will also investigate whether the NetMetrix monitoring facilities will help for these applications; it is already deployed with some of the partners.

Once the mechanisms for measurement and monitoring have been defined, we will identify the different elements of the infrastructure and the application systems that need to be monitored. We will describe the test scenarios, the parameters that must be measured, and how the tools can be synchronised using the timing components deployed. It will also be necessary to make a detailed costing of the facilities that would need to be developed, the equipment and human resources required, and the time needed to put together the facilities. Finally, we must assess whether the resources needed are available to the project.

• End of WP2100 and availability of intermediate deliverables (D3) from WP3100

• D10: Platform design report - Part 1
• D11: End system software prototype

This activity includes all the necessary software developments to be implemented in an host and corresponding to the WP2200 identified functions.

The goal of this activity is to develop, assembly, integrate and test the different software pieces to be implemented in a GII terminal (IPv6 layer, IPv6 over ATM and satellite link, IntServ, RSVP , QoS management, IPv6 mobility, TCP layer, RM transport layer).

The process will follow this path:

• Detailed end system software architecture definition,
• Specifications of the different interfaces between functions (IPv6 layer, IPv6 over ATM and satellite link, RSVP, QoS management, IPv6 mobility, TCP layer, RM Transport layer),
• Specification of each function developed within the project (IPv6 over ATM and satellite link, QoS management, IPv6 mobility, TCP layer, RM, Transport layer, Alternate Path Routing),
• Study of the interoperability with the IPv6 router functions (IPv6, QoS management, RSVP, IPv6 mobility, Alternate Path Routing),
• Definition of the different steps for the assembly, the integration and the test the end system software with other related pieces of software (security and management),
• Definition of the different steps for end system software assembly, integration and test,
• Report of assembly, integration and test for the end system software.

• End of WP2100 and availability of intermediate deliverables (D3) from WP3100

• D10: Platform design report - Part 2
• D12: Security policy and key management software

In this activity we will develop the security modules which are necessary to build the security infrastructure according to the required functions specified in WP 2200.

The objective of this activity is to implement a security infrastructure in order to provide authentication, confidentiality and integrity services at different levels for the COIAS trials.

The deliverable of this activity will contain software modules in order to provide security on the network and application layer. It should be possible to use existing products for key generation and certification. We assume that we can derive the servers for key distribution issues from an available solution. However, we have to carry out some modifications according to meet the requirements specified in WP2200.

To provide host security it is necessary to define an interface between existing IPv6 ESP and AH implementations and the CPKI represented by the DNSE. The implementation of the protocols should be based on ISAKMP v6 and ISAKMP-Oakley v2 (depending on the availability of those implementations). By means of this module, it will be possible to provide security (host to host authentication, confidentiality and integrity) at the network layer.

But this security level is not sufficient for other circumstances. In order to provide security, especially for electronic commerce applications there is a strong requirement for user authentication within the COIAS platform. For that reason it is necessary to develop an interface at the application layer to the CPKI. According to the policies specified in WP2200 this activity will describe detailed components of the whole infrastructure itself, e.g. certification and registration authority, which provides the key, certificate generation and their distribution. Additionally support of SmartCard or SPSE must be integrated to ensure proper authentication of individuals.

• End of WP2100 and availability of intermediate deliverables (D3) from WP3100

• D10: Platform design report - Part 3
• D13: Media server prototype

This activity will be to develop the multimedia server required for the COIAS trials.

The objectives of this activity are to make available appropriate media servers for the COIAS trials.

Clearly the prototype must meet the specifications of D9 and be compliant with the design of D10. It is expected that the server will be derived from an existing product, though we assume that it will require considerable modification.

The Server must provide many functions; some of them are defined below:

• To allow the storage and controlled replay of data needed to run the trials scenarios;
• To provide information of interest in its own right during the trials;
• To act as a repository for project material, including recordings;
• To provide consistent data to exercise specific components during a testing phase;
• To record measurement and monitoring data during the trials.

Many of the functions will be achievable with a centralised server; indeed at least one centralised server will be required. In addition, some of the media serving may be best done in a distributed fashion – particularly when the interconnecting data networks cause delays and act as communications barriers. For this reason, part of the media serving will include a distributed architecture, where a central server controls proxies. Sometimes the data must obey particular protocol conventions; it will be determined in D3 and D9 to what extent these protocols will be embedded in the data, and to what extent the players will need to be designed to obey the relevant protocols.

We expect that the distributed nature of the communications architecture will match well the server implementations. The broadcast nature of the satellites transmission can be used to maintain data shadows of media information on a central server. This may allow the data itself to be independent of the protocols, but to develop players which are distributed, and perform the correct protocols.

• End of WP2100 and availability of intermediate deliverables (D3) from WP3100

• D10: Platform design report - Part 5
• D14: Management software prototype

This deliverable describes the modification to multimedia applications in order to run over COIAS hybrid infrastructure.

The objectives of this activity are to study the impact of using the new generation of Internet protocols on existing applications and to have a representative GII application running over these protocols.

The technical approach we propose is to use a third party dynamic web page server (MS Merchant Server, PageBlazer are possibilities) rather than perlscripted CGI (too restrictive) and embed video content and videostreaming ourselves via server side controls (with appropriate adaptability).

Application layer adaptation to the base server can be handled by ISAPI extensions (in-proc dlls). Network layer adaptation can also be initiated by our dlls but will require a Winsock API for IPv6.

End to end error and congestion control is important feature in a heterogeneous environment. We will study the mechanisms that should be added to the application in order to overcome the network heterogeneity in terms of bandwidth, error rates and bidirectionality.

• End of WP2100 and availability of intermediate deliverables (D3) from WP3100

• D10: Platform design report - Part 7
• D15: Management software prototype

In this activity we will implement the specified functionality and the architecture of the network management system coming from WP2200.

The objectives of this activity are as follows:

• to select tools and platforms needed for the development of the management system
• to start implementing the architecture of the network management system
• to start implementing the human computer interface of the network management system

According to studies related to different approaches on the network management made in WP2200 and taking into account that the intermediate deliverable D3 will contain the required information a selection procedure on tools platforms (software, hardware) that will be used on the development of the COIAS network management system will take place at the beginning of this activity. After this procedure we will start implementing the architecture and the Human Computer Interfaces of the network management according to inputs being available from D3 (intermediate).

The different activities that are active during the first project year are described using the same M4C form already used for the WP description.

The project management approach of COIAS is based on organisations and techniques which have been successfully adopted in other international collaboration projects and especially in European ones. Its primary aim is, without being too time and budget consuming, to set up a responsive management structure. In this respect, the COIAS project is broken down into a number of WP and activities. This breakdown helps to structure the project and to support the monitoring of the technical and financial progress. The project management is performed by a structure which includes:

The overall project management is performed by P01. Therefore, P01 will appoint a highly skilled engineer as Project Manager to:

• detail the project procedures for aspects such as document control, project meetings...
• maintain project archives;
• be responsible for tracking the project flows (financial, time allocation, progress...);
• co-ordinate the consortium dissemination policy;
• act as the Co-ordinating Contractor in front of the EC;
• report the project status to the EC (through project reports and project reviews);
• collect and submit Cost Statements.

To minimise any risk during the course of the project, the Project Manager is in charge of setting up a risk management chart at the very beginning of the project.

A Steering Committee is in charge of monitoring the progress of the overall project. It takes all the relevant decisions necessary for the project to reach its objectives. This committee gathers the Project Manager and one delegate for each partner, in charge of representing contractors’ individual interests.

These delegates have been nominated by each contracting organisation amongst their senior representatives. In particular, they have been selected for their background in project management and in budget responsibility.

The main functions of this committee are to:

• decide the strategies of the project within the framework of the contract;
• monitor and assess the project progress owing to correct realisation of project milestones;
• propose, decide and agree upon any corrective action in case of deviation from the work plan;
• propose some co-operation initiatives with other projects,
• review dissemination policies and strategies, in particular with regard to the release of public information about project achievements;
• approve nominations of WP Technical Coordinators.

The Steering Committee gathers on a quarterly basis during a Project Steering Meeting or, if an emergency situation is identified in the course of the project.

Project milestones are defined by the Steering Committee to be corner stones for a good project tracking. Completion of these milestones are required and are necessary for the smooth progress of the COIAS project. Therefore any major delay in their completion is considered as not acceptable and shall lead to an emergency situation requiring an extraordinary Project Steering Meeting.

For each WP, the main contributor is made responsible for the activities and for the deliverables of that WP. In this respect a technical co-ordinator must be appointed by the WP leader. This co-ordinator reports on a monthly basis to the Project Manager by referring to dedicated yardsticks initially set with him on the WP to assess the work progress. He is also made responsible for:

• co-ordinating the overall technical progress of his task;
• establishing and maintaining technical plans of the WP;
• reporting on a quarterly basis to the steering committee;
• organising technical interchange meetings for his WP whenever necessary.

The responsibility for the different WP has been distributed according to Table 3.

Project Reviews take place every year with representatives of the ACTS program. These reviews gather the Project Steering Committee, the ACTS Project Officer and ACTS Project Reviewers.

The aim of these reviews are for ACTS representatives to verify the correct progress of the COIAS project:

• technical progress is assessed according to the project work plan;
• financial progress is assessed according to the project budget;
• dissemination and exploitation strategy of each industrial partner is individually and confidentially evaluated in order to "monitor" the introduction of the COIAS technology on the European market.

To help the ACTS representatives in their evaluation, two types of reports are issued to the commission by the Project Manager:

• a 2 pages Management Control Report is issued every 3 months to give a brief overview of the project status;
• a Progress Report is issued every 6 months to provide a detailed status of the project.

The Management Control Reports and the Progress Reports which are communicated to the commission are considered as confidential and, must be used by EC experts only for establishing their Project Reviews.

A consortium agreement will be negotiated between the partners at the very beginning of the project. This agreement will define a common position as regards:

• Background and foreground information,
• Intellectual Property Rights,
• Exploitation principles,
• Dispute settlement.

In preparation of the Consortium Agreement document, the Background of each partner of the consortium has been examined during the set up of the COIAS project.

SP02 is an American leader in the field of INTERNET routers and is of course deeply involved in the INTERNET protocol standardization and in the development of routers software that will be compliant with the next generation of INTERNET protocols. SP02 has already developed a first version of IPv6 router software and is very interested to test its implementation in front of different IPv6 end system implementations (provided by P01, P02 and P03) through the COIAS platform. The COIAS project schedule is totally in accordance with P03 development roadmap.

SP02 will provide its IPv6 code free of charge to the COIAS partners. This software will be installed on hardware available at the partners premises. SP02 will also provide local support for free both in the development and platform integration phases. SP02 will not request any funding from the EC for its participation in the COIAS project.

For P01, results of the COIAS project will be straightforwardly exploited at different commercial levels which are listed hereafter:

• INTERNET NG technology provider:

• Digital set-top boxes manufacturer:

• Information System provider:

For P04, the results of the COIAS project will reuse the COIAS technology in the following areas of information security:

• Service provider for information systems:

• Certification authorities:

P06 is already providing connectivity services to various kinds of businesses. One of the services is Internet. P06 is planning to offer these services to isolated regions (islands). Through COIAS it will be feasible to evaluate (in terms of cost, QoS) the use of satellites and Internet new generation technologies. This will offer the opportunity to P06 to offer advanced Internet services, by extending its backbone network, to isolated regions that could be used for educational medical and business purposes.

P06 designs and develops management systems based on commercial platforms for networks installed in various businesses. Most of these systems are designed for terrestrial networks. Among customers of P06 are bank organisations that plan to introduce satellite usage to connect domestic and abroad branches. By investing in the COIAS project P06 aims at developing an integrated network management system that could be purchased from large organisations acting in the banking sector and additionally could be used when the extension of P06’s backbone network (i.e. including satellite links) will take place. This extension is estimated to happen around 2000.