MM-Broadcasting in ACTS

InfoWin Thematic Issue: Next Generation Internet 19.07.1999

Next Generation Internet in Europe

Published by the ACTS Multimedia Information Window http://www.InfoWin.org

1 InfoWin Thematic Issue: Next Generation Internet 19.07.1999

Impressum

Next Generation Internet in Europe ISBN 3-00-004250-4

Edited by the ACTS Project InfoWin (AC 113)

InfoWin is partly funded by the European Commission DGXIII through the Advanced Communications Technologies and Services (ACTS) Programme.

Basic InfoWin design: Stef Stagel Layout & Production: Querverbindungen, Agentur für Öffentlichkeitsarbeit GmbH

If you have any comments or questions, or if you would like to receive a copy, please contact:

Peter Feil Deutsche Telekom Berkom GmbH Goslarer Ufer 35 D-10589 Berlin

[email protected] http://b5www.berkom.de

PREFACE

Next Generation Internet in Europe gives an overview of R&D related to Internet and IP technologies, focusing on the novel developments, testbeds and results of the Advanced Communication Technologies and Services (ACTS) Programme.

This publication has been edited by the ACTS project InfoWin (Multimedia Information Window for ACTS), based on inputs from InfoWin partners and from various external contributors, including representatives of the European Commission, ACTS projects, National Research Networks, as well as companies and research institutions.

The editors are particularly grateful to Urte Besson (Berkom) and the regional representatives of InfoWin for their contributions and help in gathering information for this publication. Thanks also to the representatives of the ACTS projects, the High Speed Networking Domain, and the actors involved in COST-Telecommunication and the ESPRIT and TELEMATICS Applications Programmes.

Finally, articles and significant contributions from the following persons are gratefully acknowledged (in alphabetic order):

Franck Boissière (EC DGXIII, Belgium) Martin Potts (Martel GmbH, Switzerland) Michel F. Roy (EC DGXIII, Belgium) Mikhail Smirnow (GMD-Fokus, Germany) Roman Tirler (EC DGXIII, Belgium)

This book is available on the WWW, as one of the Thematic Issues included in the ACTS Information Window at http://www.infowin.org/

The editors

Peter Feil, Deutsche Telekom Berkom GmbH Email: [email protected]

Rémy Bayou, EC DGXIII Email: [email protected]

CONTENTS

1. Introduction...... 7 2. Technical Background, State of the Art...... 8 2.1. IPnG - State of the Art...... 8 2.1.1. History and Evolution...... 8 2.1.2. Host and Applications...... 8 2.1.3. Network Functionality...... 9 2.1.4. Why IPnG?...... 10 2.1.5. What Happened to develop IPv6...... 11 2.1.6. Conclusions...... 13 2.2 Towards the Next Generation Multimedia IP-Telephony...... 13 2.2.1. Introduction...... 13 2.2.2. Signalling for Internet Telephony...... 14 2.2.3. QoS Control for Multimedia Communication in the Internet...... 14 2.2.4. Application and Services...... 15 2.2.5. Accounting and Charging...... 15 2.2.6. Summary...... 15 2.3 Next Generation Internet - New Challenges for Network Operators...... 16 2.3.1 Introduction...... 16 2.3.2 What is EURESCOM?...... 16 2.3.3 Strategic Studies...... 17 2.3.4 Services and Applications...... 18 2.3.5 Middleware, Service and Network Management...... 18 2.3.6 Internet and IP Technology...... 18 2.3.7 Networking...... 18 2.3.8 Some active EURESCOM Projects in the IP Area...... 19 2.3.9 European IP Testbed (P803)...... 19 2.3.10 IP Multicast (P911)...... 19 2.3.11 Security for Mobility in IP (P912)...... 19 2.3.12 Real-time Services on the Internet (P913)...... 19 2.3.13 Study and Trials for Internet Roaming in Europe (P914)...... 19 2.3.14 Integration of IP over Optical Networks: Networking and Management (P918)...... 20 2.4. New IP Services and Internet Economics - A Look in a Gap...... 20 2.4.1 Introduction...... 20 2.4.2 Conventional Wisdom...... 21 2.4.3 Voice on the Net...... 22 2.4.4 Advertisement always works for Content...... 23 2.4.5 Bottom line: Need for an Internet Economic Task Force...... 23 3. Next Generation Internet Activities in the R&D Programmes of the European Commission. .24 3.1 Introduction...... 24 3.2 Next Generation Internet in ACTS...... 25 3.1.1 Emerging Techniques for the Integration of IP and ATM, with QoS...... 26 3.1.2. Experimental issues...... 36 3.2 Next Generation Internet in Esprit and Telematics...... 41 3.2.1 TEN 34 and QUANTUM...... 41 3.2.2 Projects toward NGI...... 42 3.3 The NGI Activities in COST-Telecommunication...... 42 3.3.1 COST 263 - Quality of Future Internet Services...... 43 3.3.2 COST 264 - Enabling Networked Multimedia Group Communication...... 45 4. Projects and Trials in Acts...... 48 4.1 AROMA - Advanced Resource Management in Service Integrated and Multilayered HFC Access Networks...... 49 4.1.1 Introduction...... 49 4.1.2 System Overview...... 49 4.1.3 ATM Signalling over HFC...... 50 4.1.4 Integration IP/ATM...... 50 4.1.5 Native ATM API...... 51 4.1.6 Dynamic MAC Layer...... 51

4.1.7 Services and Applications...... 52 4.1.8 Conclusions...... 53 4.2 BTI – Broadband Trial Integration...... 53 4.2.1 Overview...... 53 4.2.1 Network Architecture and Implementation...... 54 4.2.3 ATM Switching for QoS Support...... 56 4.3 COIAS - COnvergence Internet ATM Satellite...... 58 4.3.1 Overview...... 58 4.3.2 Mapping Internet NG Protocols above ATM and Satellite Networks...... 58 4.3.3 Reliable Multicast...... 59 4.3.4 Mobility...... 59 4.3.5 Security...... 60 4.3.6 Applications...... 60 4.3.7 Industrial Aspects...... 60 4.4 DIANA - Demonstration of IP and ATM Networking for Real-time Applications...... 61 4.4.1 Introduction...... 61 4.4.2 RSVP-over-ATM Scenario...... 62 4.4.3 RSVP-peering-with-ATM Scenario...... 62 4.4.4 Differentiated Services over ATM...... 63 4.4.5 Software Architecture for the DIANA Integration Unit...... 64 4.4.6 Applications and their Requirements for QoS Interworking...... 65 4.4.7 Bandwidth Management in the DIANA Integration Unit...... 65 4.4.8 Bandwidth Management on VCs used for Aggregation...... 66 4.5 ELISA - European Experiment on the Linkage between Internet Integrated Services and ATM 66 4.5.1 Main Objective...... 66 4.5.2 Technical Approach...... 67 4.5.3 Summary of Trial...... 68 4.6 IthACI...... 68 4.6.1. Technical Background/State of the Art...... 68 4.6.2 The IthACI Project...... 69 4.6.3. The IthACI Testbed...... 72 4.7 MULTICUBE - IP Multicast over ATM Research...... 73 4.7.1 Overview...... 73 4.7.2 The Multicast Integration Server Architecture...... 75 4.7.3 Properties...... 76 4.7.4 Conclusions...... 76 4.8 PeterPan...... 78 4.8.1 Project description...... 78 4.8.2 Internet and Telecom Networks Evolution...... 78 4.8.3 PeterPan network concept...... 79 4.8.4 Cross-Connection and Trunking Concepts...... 80 4.8.5 Project current assessment...... 81 4.8.6 Project trial configuration...... 81 4.9. SUSIE - Charging and Accounting for QoS-enhanced IP Multicast...... 82 4.9.1 Charging and Accounting Reference Model...... 83 4.9.2 Value Added IP Multicast Charging and Accounting Service (VIPCAS)...... 84 4.9.3 Premium IP Network Accounting Record (PIP-NAR)...... 85 4.9.4 TINA Gateway...... 85 4.9.5 Summary...... 86 5. Next Generation Internet around the World...... 87 5.1 The Joint DANTE/TERENA Task Force TF-TANT...... 87 5.1.1 RSVP testing...... 88 5.1.2 Multicasting (IP and ATM)...... 88 5.1.3 Differentiated Services...... 89 5.1.4 RSVP to ATM SVC Mapping...... 89 5.1.5 IP Version 6...... 89 5.1.6 IP over ATM experimentation...... 90 5.1.7 Policy Control (IP and ATM)...... 90 5.1.8 Route Monitoring...... 90 5.1.9 Flow-based Monitoring Analysis...... 90 5.1.10 QoS Monitoring...... 91

5.1.11 MPLS...... 91 5.1.12 VPNs...... 91 5.1.13 Wave Division Multiplexing (WDM)...... 91 5.1.14 STM-1 vs STM-4c...... 92 5.2 Gigabit Testbeds in the German Research Network...... 92 5.2.1 Overview...... 92 5.2.2 Network-oriented Work Packages...... 92 5.2.3 Application-oriented Aspects...... 93 5.2.4 Operational Gigabit Testbeds...... 93 5.2.5 Future Activities...... 94 5.3 Status and Evolution of the French National Telecommunication Network for Technology, Education and Research...... 94 5.3.1 RENATER 2...... 95 5.3.2 Experiments...... 95 5.3.3 International Connectivity...... 96 5.4 GigaPort – The Next Generation Internet in the Netherlands...... 96 5.4.1 The Infrastructure Sub-Project: GigaNet...... 98 5.4.2 Input from the Users of the Infrastructure: GigaWorks...... 99 5.4.3 A Major Step...... 100 5.5 Current Status of the Next Generation Internet Deployment in Norway...... 101 5.5.1 Introduction...... 101 5.5.2 National Research Network infrastructure...... 101 5.5.3 International Connectivity...... 102 5.5.4 Application Focus...... 103 5.5.5 Norwegian Research Groups focusing on Next Generation Internet...... 103 5.6 United Kingdom / JANET...... 105 5.6.1 Overview...... 105 5.6.2 External Connectivity...... 106 5.7 Next Generation Internet Activities within ESA...... 106 5.7.1 Overview...... 106 5.7.2. ESA Activities for Next Generation Internet...... 106 5.8 USA - Internet2...... 108 5.8.1 Executive Summary...... 108 5.8.2 Background...... 109 5.8.3 Project Description...... 109 5.8.4 Relation to NGI...... 112 5.8.5 Impacts...... 113 5.8.6 Some Commercial Initiatives...... 113 5.8.7 Conclusion...... 114 5.9 A Review of Next Generation Internet Services in the Asia Pacific...... 114 5.9.1 Introduction...... 114 5.9.2 An Overview of Commercial Fast Internet Access in the Region...... 115 5.9.3 High Performance Networks for Next Generation Applications...... 116 5.9.4 Concluding Remarks...... 120 5.10 CA*net 3 - Canada's Next Generation Internet Initiative...... 121 5.10.1 Introduction...... 121 5.10.2 Canada’s Optical Internet CA*net3...... 121 5.10.3 The R&D Program...... 123 Annex 1: Alphabetical List of Contributors...... 124 Annex 2: Details of ACTS Projects in the Area of NGI...... 125 Annex 3: List of Acronyms and Abbreviations...... 127

1. Introduction The Internet and the IP technologies are more and more used as universal platform for the integration of telecommunication services within public and corporate networks. Today the number of Internet users and IP-based solutions is dramatically increasing accompanied by the large-scale introduction of new powerful desktop systems with multimedia capabilities. In order to be able to meet the requirements of these new users and applications Next Generation IP networks have to provide advanced functionalities like support of quality of service or broadcast distribution capabilities.

World-wide many companies, research organisations, and standardisation bodies like the Internet Engineering Task Force (IETF) are heavily working on adding new features to the existing IP-based networks in order to make them ready for the future.

This publication provides an overview of the current European activities in the area of Next Generation Internet (quality of service, multicast, differentiated services, etc.), also preparing the migration towards networks based on the new version IPv6 of the Internet protocol. This includes R&D work, network and service deployment, status of relevant standards, and market evolution. Focusing on the activities, trials, and results of ACTS and other EC-funded programmes, an outline of the ACTS R&D areas, the High-speed Networking domain, and other relevant groups working on this subject is given.

Starting with a state-of-the-art technological overview, a survey of technical approaches and experimental issues in the area of Next Generation Internet within the R&D Programmes of the European Commission is given. The next chapter presents a sample of several important ACTS projects working in this area, presenting for each of them the project goals, key issues, ongoing activities, and trial results. Finally, up-to-date information about the current status of the Next Generation Internet deployment in different European countries and around the world is given – this covers pilot and commercial networks, testbeds and trials, as well as user experiences together with an outlook on the foreseeable evolution in the near future.

This InfoWin Thematic Issue is a publication targeted mainly to professionals in the field of advanced communication technologies and services. This includes not only researchers, consultants, decision makers, etc., but also (potential) users interested in the current status of Next Generation Internet and the evolution of IP-based networks in the near future. The target audience is expected to have a good knowledge of telecommunication technologies and the Internet, but need not be specialised in the details of the Internet protocols.

Next Generation Internet in Europe is a publication of the ACTS Multimedia Information Window provided by the InfoWin project. This book is also available as on-line document which can be accessed on the World Wide Web via http://www.infowin.org by following the link labelled Thematic Issues.

2. Technical Background, State of the Art

2.1. IPnG - State of the Art

Jon Crowcroft, Peter Kirstein Department of Computer Science, University College London, UK

2.1.1. History and Evolution The Internet is undergoing a stormy adolescence as it moves from being a playground for academics into being a commercial service. With more than 50% of the subscribers being businesses, the Internet is now a very different place from what it was in the 1980s.

The mere size of the current Internet makes it very difficult to incorporate radical change; yet such change is required. The introduction of change is made more difficult by the cachet surrounding the start-up of any company with the goal of providing new Internet services or components. Many of these companies either want to introduce proprietary techniques, or at least get a fast return on investment; this is not a good environment for the introduction of long-term, fundamentally different, procedures - which must be introduced in a compatible manner. There are major problems in routing, addressing, security (or lack of it), Quality of Service and accountability. These factors have led to the most interesting debate in the history of communications, as political, economic and technical concerns become inextricably intertwined.

This chapter is about the factors in the choice of future technology for the Internet.

2.1.2. Host and Applications The emergence of some simple APIs has led to the rapid growth of new user-friendly applications in the Internet. Information services provided by archive and Web servers are accessible through WWW/Mosaic, archie/prospero and gopher and wais via Z39.50.

The value of the service is now becoming clearly the value of the information, rather than the communications channel. This means that some mechanism for charging and auditing access to information is a new requirement. This must be a secure mechanism to assure people that charges (or audit trails) are correct.

New end-systems such as laptops and PDAs are leading to the requirement for access to home systems by travellers. This leads to a new requirement for mobile communications support in the Internet, both while travelling, and when arriving at a new site.

Most new systems have the power to handle sound and vision, as well as text and graphics. This multimedia requirement leads to the need for integrated services in the network, much higher bandwidths, and the need to support the delay intolerant applications that are emerging from the R&D world into products.

The vast number of systems attaching to the Internet leads to whole new problems in management. We foresee a time when every home will have many devices networkable (e.g. heating, lighting, appliances like answer-phones, VCRs and surveillance). These new applications will provide new potential - but problems of security and management will be key factors impacting deployment.

The growth in CPU, memory and storage performance/price has made possible all these new applications. The reduction in connectivity costs is leading to the use of these new

8 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 applications. The corresponding increase in network functionality has yet to happen. Communications costs have come down significantly - but not yet by the large factors achievable by the technology or required for the large-scale uptake in applications like appliance control and multimedia conferencing.

We look at this next.

2.1.3. Network Functionality

Background The Internet Growth is remarkable. It is sustaining an exponential increase in end systems of 100% each 8-9 months; we must worry about the current limits, and consider a Next Generation Internet protocol, the basic glue that holds the whole system together.

Firstly, we must ask ourselves whether ´More is Better`. Is it advisable to permit the increase to continue at this rate? The answer must be yes, since the market has chosen this technology, but that implies the need to solve the scaling problems first and foremost.

Another interesting question to ask ourselves is: What were IPv4 requirements? The Internet evolved out of a defence experiment, with special requirements for robustness above all else. This has led to the possibility of running a severely under-engineered network and still getting useful service from it. We need to persuade the Public Network Operators (PNOs) to provide a properly engineered Internet service (somewhat like the latest NSFNet service in the US).

The requisite changes must be orchestrated and aligned - but by whom? The older institutions like the International Telecommunications Union cannot assume this mantle; they do not have the background or mandates to consider the end-station and end-network interactions, and are very concerned with maintaining the value of current investments. Luckily for the community, there is an appropriate body - the Internet Engineering Task Force (IETF).

The Internet Engineering Task Force and IPnG The IETF is a voluntary organisation chartered to provide Standards for the Internet. It has a broad constituent of members; this is much broader than that of the ITU - though there is a sizeable representation now from the PNOs in the IETF deliberations. In addition to Standards, members of the IETF write Informational and Experimental notes called ´Requests for Comments` (RFCs); these are very relevant to the exploration of the evolution of the Internet. Around a year ago, the IETF formed a new directorate, the IPnG Directorate, to look into the next generation Internet.

The IPnG Process Members of the IPnG WG of the IETF wrote RFC 1550 to solicit white papers, and they got about 15 of them from a broad range of interested parties, from government agencies (around the world) to large businesses (including TV entertainment). A requirements document by Craig Partridge of BBN, and Frank Kastenholz of FTP Software was brought in by the directorate as a base document.

The IPnG directorate and external review board reviewed the white papers. They were be turned into informational RFCs. After this, the IETF IPnG area directors responded to the white papers -- describing how they meet the white papers' needs. Finally, a selection of technology was made, and the IPnG process started in earnest, with the formation of IETF working groups to work through the details of the protocol(s) change(s).

2.1.4. Why IPnG?

The Original Motivation The initial drive to IPnG was from exhaustion of the address space. The current version (4) of the Internet Protocol (IPv4) uses node addresses that are allocated from a 32-bit space. These addresses indicate an interface of a computer (host/end system, or router), on a network, and are therefore at least from a two-part hierarchically administered assignment - host + network. Initially, these addresses were assigned by the Internet Assigned Numbers Authority (IANA) to sites in chunks taken from three ranges - the so-called class A, B and C ranges, which constituted network part of 8, 16 or 24 bit, with corresponding host part of 24, 16 or 8 bit, depending on the number of expected hosts on a given network. This led to extraordinarily inefficient use of the 232 possible addresses, since many ´important` organisations automatically asked for class A or B addresses using up 224or 216 addresses at each single assignment, even when they often only had several host computers, or had many subnets with several computers on each. A second problem was that addresses were rarely re-claimed after they were no longer in use.

The number of hosts and networks on the Internet has been growing exponentially since 1981, doubling roughly every 8-9 months. It was predicted in 1992 that we would exhaust the address space by 2001 at the rate of assignment then current. To side step this principal problem, the IPnG process was put in place. However, it was decided that since this would entail changing the Internet Protocol (which only had control fields large enough in version 4 to accommodate 32 bits of source and destination), it would be a good opportunity to make other changes as well. To constrain these changes to a reasonable set, a requirements document was written to capture the consensus on what such an IPnG would contain functionally (to be version 6, since version 5 had already been assigned to the experimental and now largely obsolete ST protocol):

Current Needs While the initial motivations have been greatly extended, in the process we must ensure that we do not lose many of the current virtues of the IPv4. These include the following:  The Internet is simple. You do not need a PhD or have to have a phone company build you an exchange to access it. Keep it that way.  One Protocol to Bind Them All. The Internet has a great deal of commonality, while still supporting multi-protocol working. Keep it that way; in diversity is strength.  Long Life. Any change in the Internet Protocol must be designed to last at least as long as the previous version of the system (15 years).  Long Life with Prosperity. There is a great deal of business to be made. This should not be obstructed.  Co-operative Anarchy. The Internet promotes incremental growth par excellence, through lack of central management. This is a pre-requisite for its continued success.

Criteria for the Next Generation Internet Protocol  Scale, Topological Flexibility, Performance, Robust Service. The Internet supports a range of performance from 1 bps to 1 Gbps, a range of topologies of subnets from 2 hosts to 20,000, and reliabilities from losses of nearly zero to packet error rates of a few percent. It should continue to expand its repertoire.  Transition, Extensibility. Any new protocol must have backward compatibility modes.  Media Independence, Unreliable Datagram Service, Configuration, OAM. These are current facilities in the Internet. A new Internet should not limit itself to existing media, should not change the underlying communications model, and should permit user configuration and management.  Allow Secure Operation. The Internet must permit better security, or commercial usage will be limited, which will in its turn limit non-commercial use, through lack of services, and through lack of a community that can fund improvements.

 Multicast Addressing. The Internet has developed to include a multicast facility that is essential for autoconfiguration, routing and multimedia support. This must improve in performance and scalability.  Network Service Support for Mobility. The Internet currently has a single service model and that only for largely stationary hosts. It needs to support a variety of service models, including bandwidth, error and delay guaranteed services, link sharing policy rules, and mobile hosts and routers.  Tunnelling. Tunnelling is a common technique for other protocols to use the Internet as a carrier. It should be a base part of the architecture.  Quality of Service. QoS is an important requirement for many of the newer applications of the Internet; there should be facilities for demanding, receiving and paying for such a service to any desired degree.

2.1.5. What Happened to develop IPv6

The Search for a new IP The process of looking for an extension of IPv4 led to several competing proposals for a new IP protocol - the leading ones were SIP (Simple Internet Protocol) from Steve Deering at Xerox and PIP (Paul's Internet Protocol) from Paul Francis at UCL and Bellcore. Competing proposals such as the adoption of ISO CLNP and NSAPs and the proposal to adopt IPX were not politically acceptable.

Eventually, IPv6 emerged with 128 bit addresses, and a simplified IP header with separation of host and routing options, a flow ID field (possibly for label swapping based forwarding) and no fragmentation functionality.

Activities in the IETF Within the IETF now, detailed work on IPv6 specification is pretty much done. Changes to routing protocols, transport protocols (the pseudo-header checksum in TCP and UDP) and applications that reference IP addresses (particularly DNS, but also FTP) have been specified. More subtle wok in routing (beyond OSPF and RIP v6 changes) needs to be done, and more especially, the impact on RSVP and on multicast routing and Mobile IP routing as well as RTP/SDP and MPLS needs a lot of work to see what the real benefits may be.

The critical missing piece in IPv6 is a deployment plan that includes seamless interworking with IPv4, but provides clear benefits to a site to migrate. Three possible ways this may happen are: VPNs, Satellite IP (DBS) and large scale PDA/GSM mobile phone integration by a provider and vendor. The importance of the seamless interworking is because the Internet is now far too large to envisage event the switchover that occurred in going from previous NCP to IP in 1980; and that switchover was even painful then - with a few hundred hosts rather than tens of millions. Moreover, there is clear reluctance by commercial vendors to invest into extensive upgrade; it must be made worthwhile by the quality of the benefits provided.

Available implementations, Products and Services We can divide implementations into host and router side code. In the router side, most of the major vendors have at least beta products for the basic IPv6, although its not clear if their routing protocols changes all interwork. On the host side, major operating systems such as Windows 2000 will have IPv6 in, although to date, only the research part of Microsoft have released a Windows implementation (the best that UCL has tested). For Unix systems, there are releases for most major flavours, although many are very early code, and have a number of shortcomings. The best systems are the public domain offerings for FreeBSD and Linux, including DNS for IPv6 and other important infrastructural tools.

The implementations have many of the components that have been defined - but not all. For example, strong security is mandatory in IPv6; political considerations related to export controls have made it very difficult to have exportable implementations which meet the Standards. Moreover, some of the key components, like IP Multicast, Quality of Service facilities and Public Key Infrastructure are not yet fully standardised.

See http://www.cs-ipv6.lancs.ac.uk/ for more information from the UK IPv6 site.

What has happened to the Address Space in Reality In practice, the IPv4 address space has lasted longer than expected due to two technologies: Classless Inter-Domain Routing (CIDR), and Network Address Translation (NAT). This has reduced the urgency to move to IPv6.

CIDR is a generalisation of the class based address assignment that was originally devised for IPv4. Nowadays, the address assignment authorities (and they are devolved to regions of the Internet geographically now) assign IPv4 (and IPnG (or IPv6 as it is known to some)) addresses hierarchically, together with masks. The mask determines how many bits of the address are network and how many are host, and the mask can be different at different places in the network topology - this allows the address + mask to be treated like a variable length prefix. The forwarding decision that used to be made by routers, based on simple best-next-hop, is no longer a simple lookup; it consists of a longest-match procedure. Routing protocols no longer exchange lists of network numbers to build upon a network map, but now exchange addresses + masks, to allow this hierarchical address space management to work. A secondary, but very important side effect of this is that the routing tables can now be summarised; typically, a country might be assigned a short mask, and within the country, each region, longer masks. This allows each router nearer to each local region to contain small number of (even just 1 per interface) entries.

The questions of the technical and political feasibility of address-space deployment are relatively separate. One advantage, for example, of the larger address space is that mobile users can keep their same low-order addresses, while the mobile network operator controls only the high-order bits. However when there is a real conflict between technical and commercial pressures, the solution is less clear. It would be possible to carve out a complete set of numbers and address for IP-telephony; early attempts to do this in conjunction with the ITU telephony groups have failed so far. One suspects that this is partly because attempts to make IP numbering as universal and well-structured as the telephone numbering is seen as a very real threat by the PNOs to their telephone revenue.

NATs are another technique for containing the growth of address use, but are based in two other important requirements: to avoid having to renumber hosts, and to provide some network security. Many sites had assigned IP addresses in isolation from the Internet, and had used addresses already in use in the world-wide Internet. To avoid the problem of re- numbering all their hosts and routers, such sites developed a technology to translate ´on-the- fly` the addresses of source hosts within IP packets being forwarded through firewall routers. This was done only for hosts which wished to communicate with the ´outside world`, changing the addresses in packets to and from them, from the internal non-unique ones, to ones drawn (dynamically assigned) from a small pool of legitimate public addresses. This works well in typical large corporate networks as few hosts communicate with the outside world at any one time (principal of locality!). Often, the dynamic assignment in the firewall router was controlled by an application level authentication protocol (e.g., based on an RPC mechanism, or even just a telnet/login user-name + password to the firewall router). This meant that the NAT acts as a quite effective barrier to outside hosts accessing internal hosts (even if packets could get in by pure random luck, the responses would not get out...).

Other Improvements Promised with IPv6 Many of the improvements promised for IPv6 have been specified in a simplified way for IPv4; the specifications are often less powerful than is possible with IPv6, but would provide enhanced services. It has turned out to be very difficult to organise even the IPv4 deployments of IPSEC, QoS and Mobile IP. This is partly from lack of motivation by the many smaller ISPs, but it is also because of the need to orchestrate the introduction of the services. There is often little advantage in introducing such services in an isolated part of the system. Moreover, in some cases the specifications were not really complete, or it was felt that their viability had yet to be demonstrated by the R&D community. Here there was the serious problem that small-scale deployment was no feasibility demonstration; large-scale deployment was often beyond the means of the R&D community, and was not really supported by those providing the research networks.

It is probable that these improvements will come more with IPv6 than earlier, because the whole of the transition to IPv6 must be managed to some extent in any case. This will encourage the establishment of larger testbeds, at least by the bigger ISPs and PNOs. There are some substantial test-beds already; who are active on the 6Bone, which is a set of European sites who are experimenting with IPv6 in an encapsulated form.

2.1.6. Conclusions The specifications for a Next Generations Internet are largely complete from a technical viewpoint. There are still some loose ends, but they are not very significant. The large-scale deployment of many of the newer features over the current Internet is proving difficult, and will probably never happen on a large scale. Implementations of the basic feature sets are available in research prototypes, and starting to become available in commercial offerings. Implementations of advanced features are becoming available in research prototypes, but still require substantial experimentation and refinement. However, there are starting to be a number of substantial research networks on which the implementations are being deployed for R&D purposes. The general commitment to large-scale commercial deployment, and the time-scales over which this could be achieved, are much more uncertain.

References See http://www.ietf.org/html.charters/ipngwg-charter.html for all the relevant work.

2.2 Towards the Next Generation Multimedia IP-Telephony

Dorgham Sisalem, Michael Smirnov, Henning Sanneck, Jiri Kuthan GMD Fokus, Germany

2.2.1. Introduction The rapid growth, increasing bandwidth and the availability of low-cost multimedia end systems has made it possible to use the Internet for multimedia applications ranging from telephony to conferencing, distance learning, media-on-demand and broadcast applications [1]. Due to the prospects of tremendous financial gains both the telecommunication industry as well as the Internet community are propagating the use of Internet-based telephony.

However, to provide IP-based telephony with a comparable quality to that of traditional telephony several aspects need to be considered such as signalling, QoS control, innovative applications, and charging and accounting for the IP-telephony services.

2.2.2. Signalling for Internet Telephony Due to the entirely different nature of IP-based networks compared to traditional circuit- switched network new paradigms for signalling a communication request between two end

13 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 systems are needed. At the current stage, there are already two signalling protocol suites available for realising such a service. H.323 [3] as well as the session initiation protocol (SIP) [2] are intended to standardise call signalling and multimedia transport for IP-Telephony services. Both standardisation bodies agreed on using the same multimedia transport protocol (RTP). Although a similar set of services is offered by both standards they are not interoperable at the call signalling level. The primary reason for the lack of the interoperability is the different development approach of the H.323 and SIP. H.323 tries to utilise its existing complex protocols and integrate them in a new even more complex protocol family whereas SIP tries to retain a set of lightweight, orthogonal protocols.

It is the complexity of the H.323 which is often objected by SIP backers [4]. It results in higher call set-up delays, complicated firewalling, and high implementation overhead. Not only the complexity, but also the architecture is being criticised. H.323 was primarily designed for use on a single LAN and is difficult to scale to the Internet dimension. H.323 signalling does not support multicasting, inter-zone communication is limited and its stateful nature reduces its reliability in heavily loaded environments. Conferencing is also complicated due to the centralised design approach.

On the contrary, the SIP protocol family is based on a set of lightweight protocols that are easy to implement and combine with each other. SIP's straightforward design does neither introduce additional set-up delays nor complicates the design of firewalls as H.323 does. Multicasting at the signalling level is supported and allows for a better conference scalability. Traditional Internet services may be utilised for the inter-zone communication. The stateless nature of SIP implies higher reliability.

To achieve a high interoperability degree with the current PSTN infrastructure both SIP and H.323 need to define clear integration schemes with the signalling protocols of PSTN (SS7).

2.2.3. QoS Control for Multimedia Communication in the Internet To achieve a high customer acceptability for IP-telephony services, the service providers need to offer a low price service with an acceptable quality. However, the Internet as the install base infrastructure for IP-networks supports no level of quality of service guarantees. Currently, different approaches are being discussed for solving the QoS and congestion control problems such as: resource reservation [5], priority mechanisms [6], and end-to-end based application control and forward error correction mechanisms.

Reserving enough resources for supporting a certain QoS level in advance guarantees this quality level and would be the most straightforward approach for handling the problem. However, as it is usually impossible to know the exact characteristics of a stream in advance, one would tend to over-allocate resources to guarantee the requested QoS level, leading to network underutilisation. In addition to the complexity and scalability problems of reservation based QoS control schemes, these schemes do not easily allow for example the use of extra bandwidth for improved quality during network underload states.

With priority mechanisms, different data packets or streams are labeled with different priorities and thereby treated differently at the network routers. Such an approach is simpler than the reservation approach as it requires no signaling and less complicated control mechanisms at the routers. However, the exact mechanisms for setting the priority levels, the router mechanisms for controlling these levels and the actual gain achieved with such an approach are still under discussion [6].

In the area of end-to-end QoS control for voice over IP the authors [7,8] propose a simple yet effective mechanism for improving the QoS of audio communication based on intelligent concealment of audio data based on the importance of the data contents. The performance of this concealment approach can be even further improved using buffering mechanisms at

14 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 the routers specially enhanced for IP-Telephony [9]. In the area of video communication over the Internet have been various proposals for adaptive video transmission for improving the video quality and avoiding network congestion [10]. That is, based on feedback information from the receivers, the sender would increase its transmission rate during underload situations and reduce it otherwise. This is especially beneficial when the bandwidth availability may change during a session, particularly during long-lived sessions typical for multimedia communications. Note, that with such an approach no QoS guarantees can be made, but the user perceived quality is improved through loss reduction.

2.2.4. Application and Services Traditional telephony devices have gained a wide popularity partly due to their simplicity. This is especially evident for low end devices designed for point-to-point communication and simple monolithic pricing schemes. High-end ISDN devices offer a much wider range of functionalities like detailed phone books, hold-on or redirect services at the cost of a much higher user interface complexity. Due to the complexity of the telephone system itself, the usage complexity is substantially increased for group communication or special services like blocking certain numbers which can only be realised by the service provider or programming the PBX. For the Internet to find wide acceptance the end users need to have powerful and yet easy to use applications and simple mechanisms for determining the appropriate providers to contact.

Early studies [11] already suggest the simplicity of adding services like call redirection, camp-on and further advanced telephony services can be realised based on simple extension to the signalling protocols. Providing services of intelligent network are additionally under investigation.

To allow for easy location of appropriate service providers some gateway location mechanisms are needed [12]. Here, the user can choose among a variety of IP-Telephony providers based on offered services, quality or price.

2.2.5. Accounting and Charging To account for the introduction of new services and quality-based communication on the Internet the pricing structure of the Internet will surely change in the near future. Additionally, due to the liberation of the telecommunication markets world-wide the end user is faced with a large variety of services and service providers with rather complicated charging policies. Thus, clear and simple mechanisms for accounting and charging for the new services and quality will be needed.

2.2.6. Summary Internet-Telephony bears a great potential for simplifying the communication infrastructure and introducing new services. However, to actually profit from these possibilities there are still various aspects that need to be investigated in the areas of signalling, QoS control and service realisation. Without clear and simple solutions for these problems IP-Telephony will not be able to take over the role of the current circuit switch telecommunication infrastructure. However, early solutions already suggest that these problems are manageable without considerably increasing the complexity of the current Internet.

Bibliography [1] H. Schulzrinne, ´Re-engineering the telephone system`, in Proc. of IEEE Singapore International Conference on Networks (SICON), (Singapore), Apr. 1997. [2] M. Handley, H. Schulzrinne, and E. Schooler, ´SIP: session initiation protocol`, Internet Draft, Internet Engineering Task Force, May 1998. Work in progress. [3] International Telecommunication Union, ´Visual telephone systems and equipment for local area networks which provide a non-guaranteed quality of service`, Recommendation

H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, May 1996. [4] J. Rosenberg and H. Schulzrinne, Á comparison of SIP and H.323 for Internet telephony`, in Proc. International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Cambridge, England), July 1998. [5] R. Braden, L. Zhang, and S. Berson, ´Resource reservation protocol (RSVP) - version 1 functional specification`, Internet Draft, Internet Engineering Task Force, Nov. 1995. Work in progress. [6] S. Blake, ´Some issues and applications of packet marking for differentiated services`, Internet Draft, Internet Engineering Task Force, Dec. 1997. Work in progress. [7] H. Sanneck, Ádaptive loss concealment for Internet telephony applications`, in Proceedings INET'98, (Geneva, Switzerland), July 1998. [8] H. Sanneck, A. Stenger, K. B. Younes, and B. Girod, Á new technique for audio packet loss concealment`, in Proceedings IEEE Global Internet 1996 (Jon Crowcroft and Henning Schulzrinne, eds.), (London, England), pp. 48-52, November 1996. [9] H. Sanneck and G. Carle, ´Predictive loss pattern queue management for Internet routers`, in Internet Routing and Quality of Service, S. Civanlar, P. Doolan, J. Luciani, R. Onvural, Editors, Proceedings SPIE Vol.3529A, (Boston, MA), November 1998. [10] D. Sisalem and H. Schulzrinne, ´The loss-delay based adjustment algorithm: A TCP- friendly adaptation scheme`, in Proc International Workshop on Network and Operating System Support for Digital Audio and Video (NOSSDAV), (Cambridge, England), July 1998. [11] H. Schulzrinne and J. Rosenberg, ´SIP call control services`, Internet Draft, Internet Engineering Task Force, Feb. 1998. Work in progress. [12] J. Rosenberg, B. Suter, and H. Schulzrinne, ´Wide area network service location` Internet Draft, Internet Engineering Task Force, July 1997. Work in progress.

2.3 Next Generation Internet - New Challenges for Network Operators

Magnus Krampell, EURESCOM GmbH

2.3.1 Introduction European Telecom Operators (Telcos) are intensifying their efforts in the area of IP networks (and their involvement in the development of the Internet). Most of the traditional Telcos are already Internet Service Providers (ISPs) or own a substantial share of some ISP. Since the business opportunities of the Internet (e.g. electronic commerce, IP telephony) are lurking around the corner, it is vital for these Telcos to have relevant knowledge about key technologies. EURESCOM is a means for these Telcos to achieve such knowledge. The number of projects being executed within the EURESCOM framework has increased rapidly during the recent years. This article gives an overview of EURESCOM as a research facility, serving the Telcos, and describes some highlights from active projects in the IP area.

2.3.2 What is EURESCOM? EURESCOM is an European institute for research and strategic studies in all areas of telecommunications. EURESCOM performs collaborative R&D, with the purpose of identifying and developing new scenarios, network solutions and services. In this role it acts as a technical forum for sharing visions and concepts, as an initiator of targeted activities, and as a facilitator for common undertakings on technical issues.

By pooling and sharing resources and expertise at the early stages of evolving services, telecommunications’ players can profit from the results whilst minimising risks and costs. The main benefit of collaborative research may be seen in at least three major areas: • Upgrading internal processes (e.g. investment programmes, network planning, network testing methodology and procedures)

• Expanding the market on traditional services (e.g. upgrading existing technologies with new network solutions and platforms for the development of new services) • Entering new business lines (e.g. reinforcing Telcos’ role in Internet strategy and in e- commerce, being more proactive in new ´home` and ´infomobility` services).

The amount of work carried out under the EURESCOM umbrella average 2750 man-months per annum in around 40 parallel projects. The project results are owned by, and made available for exploitation by, all shareholders. The work is divided into five ´Programme Areas`:

Strategic Studies

Services and Internet and Applications

Technology Middleware, Service and Network Management

Networking

2.3.3 Strategic Studies The objectives of Strategic Studies are to identify topics considered to be of a strategic nature to shareholders, explore them and formulate further actions to be taken by the shareholders either individually or collectively. Part of the objectives is also to undertake studies on the future of the global Information and Communication Technology (ICT) industry and identify trends and possible disruptive events.

Major topics within the Strategic Study Programme Area include:  market and trend analysis including customer aspects  studies of user behaviour and user requirements  investigations of macro social, economic and environmental aspects of telecommunications  the impact of global convergence in information technology, telecommunications and media  strategic aspects of the integration of networks (e. g. fixed, mobile, satellite, CATV, etc.)  investigation of scenarios for the development of the European Information and Communication Industry  human Centredness: the impacts of information and communication technologies on society

2.3.4 Services and Applications Collaboration in Telecommunication Services and Applications enables access to wider markets, ensuring service portability across Europe, etc. Major topics within this Programme Area include:  user interfaces and usability of all services

 generic requirements for new customer equipment  multimedia services and applications  agent based services and applications  terminals and customer premises equipment  Quality of Service and network performance in multi-domain environments

2.3.5 Middleware, Service and Network Management In a liberalised European telecommunication market, middleware plays an important role in the seamless interworking of services across network platforms.

Service Service Service

Middleware

network 1 network 2 network 3

Major topics within this Programme Area include:  choosing the most suitable middleware technology (e.g. CORBA, DCOM)  supporting middleware services, such as service management, naming and addressing, security and billing  co-existence/interworking of middleware and legacy systems  service management and quality of service  evolution of the Telecommunications Management Network (TMN)  interoperability of Operations Support Systems (OSS)  intelligent agent technology

2.3.6 Internet and IP Technology IP-based infrastructures and services/applications are being deployed faster than any other communication technology. This includes the usage and exploitation of connectionless versus connection-oriented services and applications. The major topics within this Programme Area include:  migration of services from legacy systems to new systems  backbone provisioning  security, accounting, charging, and billing  economic models for Internet-based service provision including real-time services  usage and exploitation of connectionless versus connection-oriented services and applications (especially to provide differentiated Quality of Service)  IP multicast

2.3.7 Networking Telecommunication access and core networks are studied. The emphasis is on optical systems, broadband issues, convergence of fixed and mobile networks. The major topics within this Programme Area include:  new network architectures and interworking  performance and planning aspects of networks and systems  identification and preparation of trials to test new systems configurations and interworking  evolution towards fixed/mobile convergence  UMTS (Universal Mobile Tele-communication System)  optical networking  wireless network techniques  in-house networks

2.3.8 Some active EURESCOM Projects in the IP Area Early 1999, the following projects are performing collaborative research in the IP area: (the number indicates the EURESCOM project number. This can be used when looking for further information at http://www.eurescom.de)

2.3.9 European IP Testbed (P803) This project investigates aspects of IPv6, such as migration strategies, interoperability and multicast usage from a Telco point of view. It also investigates techniques for support of differentiated Qualities of Service in IP networks. Many techniques are being proposed for supporting QoS in IP networks. Examples are DiffServ and IntServ models (e.g. Resource ReServation Protocol, RSVP). These techniques are examined in isolation and combined. IP telephony is used as an example service to demonstrate the effects of the tested techniques Last, but not least, the project tries to promote the creation of European agreements (e.g. service or carrier interconnection MoUs) and to build relations to industry and Internet standards bodies (e.g. IETF).

2.3.10 IP Multicast (P911) IP Multicast is becoming stable enough to be commercially deployed. Its importance is emphasised on the activities of commercial router manufacturers and software companies trying to meet the increasing demand of the market by incorporating multicast functionality into their products. This project examines the actual status of the IP Multicast, runs local and international trials with IP Multicast (applications, routing: intra-domain, inter-domain) and will make recommendations for the roll-out of IP Multicast services.

2.3.11 Security for Mobility in IP (P912) The expansion of mobile accesses to the Internet will bring the problem of security especially related to mobility into focus. Network operators and service providers will be forced to take special notice to provide customers with a high level of security. This project will perform a security-oriented review of protocols for mobility management in IP, make an analysis of IPSec security protocols (with an emphasis on mobility), investigate threats and risks related to mobility in IP and propose security services to be implemented in a mobile environment.

2.3.12 Real-time Services on the Internet (P913) Real-time services over the Internet are gaining attention from customers, who expect reduced costs and from operators who need to open new markets. Real-time conversational services, such as IP- telephony, are currently being deployed. More demanding real-time services, such as audio/video streaming or multi-party conversational services still suffer from technical problems. This project investigates both audio/video -streaming and multi-party conversational services and is testing how these services perform in best-effort Internet and with IP networks, which offer some bandwidth control. From these results possible scenarios, recommendations on protocols and solutions for access networks, Internet and Internet Gateways will be produced.

2.3.13 Study and Trials for Internet Roaming in Europe (P914) Access to the Internet should be easy for a person who is far from home, without the need to connect to his/her home Internet Service Provider (ISP) with an expensive international call. Internet users who are frequent travellers would greatly benefit from a roaming arrangement among national ISPs, which would allow accessing the Internet services at the cost of a local (or short distance) call when travelling to a country covered by the agreement.

Other ISP’s Roaming User Traditional, Centralized Solution: 3rd Party Clearing Point

Authentication Authentication Authentication Server Server Protocol for Remote ISP for Home ISP

NAS: Network P805 Solution: Access Service Direct A-A Interface Home ISP Remote ISP (H-ISP)(H-ISP) (R-ISP)(R-ISP) the Internet

The work of this project focuses on the further development and enhancement of an Internet roaming architecture set up in an earlier project.

Special focus is also given to the IETF standardisation activities (e.g. the DIAMETER protocol).

2.3.14 Integration of IP over Optical Networks: Networking and Management (P918) A distribution of network functionality across the different layers of the transport network poses the problem of inter-layer networking and its relative impact on the network level management requirements of the network. An optical WDM layer should be a client-independent layer with its own management system. This project will investigate  IP over ATM (CLIP, MPOA, IP switching, etc.)  IP over SDH (PPP/SDH, HDLC/SDH MAPOS, etc)  IP over WDM (from WDM point-to-point to optical networking) in order to reach a common understanding on how to manage an optical network. The project will also identify business opportunities and risks for the network operators (new entrants versus incumbent operators), due to the development of new IP over WDM infrastructures and the potential substitution of the current solution based on IP over ATM or SDH.

2.4. New IP Services and Internet Economics - A Look in a Gap

André Zehl, Dirk Hetzer Deutsche Telekom Berkom GmbH, Germany

2.4.1 Introduction New IP services have been showing up on the Internet over the last years faster than any other network technology would have allowed to build new services on top of it. Prospering Internet startup companies have developed new services and at least some of them have grown to large and highly successful companies. Internet search engines, instant messaging, Web based email services, IP telephony, Internet gaming – the areas of these new Internet services are too large to mention all of them. ´Traditional` Internet Service Providers1 are also expanding their services, Web- and other server-hosting are accompanying traditional Internet access and backbone services. Some of these new Internet services are very profitable, some expect to become profitable according to promising business plans, and the stock value of many companies has exceeded their revenues multiple times making them ready for mergers and acquisitions.

Yet, also these providers offer completely new and innovative Internet services, they often copy economic models from existing non-Internet Services. Although it might be one of the most common misconceptions to assume E-Commerce would prosper independently of existing ´real-world` production and sales, it does not necessarily mean, that this is true for all new Internet services. Unfortunately, hardly any research activities deal with this issue today, except a few selected areas bearing some publicity, E-Commerce again as an example. It also can be argued that business models are subject to the skill and aptitude of every company or economic entity, there are some underlying economic impacts, which can hardly be ignored.

First of all, an understanding of the underlying forces of an industry brings some trust and security in the activities and behaviors of individuals and economic entities. Also companies have made huge investments in their Internet service activities, from simple network access and Web-presence to complete Internet shops, there is still a lot of doubt and uncertainty about impact and outcome of these ventures, besides market pundits’ promises about never-ending Internet growth.

Secondly, there are macro-economic welfare implications concerning the industry as a whole, which need to be considered. There is e.g. the possibility for incidents on the Internet affecting the ´online`- uptime of the networked community as a whole, which have adverse welfare impacts on single economic entities and thus need to be considered. Issues of outages of bundles of thousands of fiber optic lines of the underlying network technologies causing massive rerouting in IP core networks, ´Smurf` attacks avalanching Internet backbones with 200 Mbps, rendering major backbone provider lines unusable and possibly hitting small companies’ Web sites paying by volume are just some examples of major economic damages. These risks, which are still fundamentally different from other supply industries, like electrical power plant or aviation industry, can have severe negative economic

1 Awkward enough to call a business ´traditional` which is not yet 20 years old.

20 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 impacts on Internet service industries, but are not tackled in questioning the economic fundamentals of the industry. It would be the wrong sign to raise fear, uncertainty and doubt in the community of Internet users given that trust in the Net is slowly evolving. But the industry itself needs to be aware of economic basis and its implications and develop appropriate models and solutions for problems which can be applied by the Internet Service Provider industry as a whole.

Finaly, there is a huge potential for innovation and farewell from traditional telecommunications industry principles, which have been around since the early days of the telegraph system, the ´Victorian Internet` [Standage98]. While it still remains to the single economic entity to prosper with a given economic model, many fundamentals for these new economic models in the Internet community cannot be employed efficiently by single service providers. While it gets more and more obvious, for example, that there is a need for quality differentiation in Internet transmission services2, it is also clear, that this cannot be implemented by a single provider3. The rest of this article reviews the economic principles of IP transmission services so far and takes a closer look on two imminent examples of the need to explore issues of Internet economics for new Internet Services: IP telephony and IP gaming (and some other services) with an excursion to IP QoS.

2.4.2 Conventional Wisdom One of the IETF’s design principles and one of Einstein’s favorite quotes is: ´Keep everything as simple as possible. But try not to make it simpler`. Coming to basic economic issues like accounting and pricing for network services, the model, that has been around since the days when the Internet was a public utility of US governmental projects and the educational community, is to charge individuals, institutions and companies for the access to the network. Accounting is done by access devices at the edges of the network, like network access servers, in the telephone network itself or at customer routers. Charging is usually done by the minute, by volume, by access speed, by average usage over periods of time, by a mixture of these options or by a ´flat` rate. Pricing was usually done according to the pricing pattern of underlying communication networks’ costs plus basic fees. Usage specific pricing, like charging for specific applications, or charging the customer based on distance were concepts which never took off in the Internet4. Additionally, a concept of ´receiver-pays` evolved, where the recipient of traffic deliberately pays for the costs imposed on him. This concept - somewhat strange considering traditional postal service, where the sender pays – is fundamental not only to the basic IP service itself, where for example, a provider of a Web server pays for all traffic sent in his direction5, but also to important applications like email, where the receiver of an email is subject to costs for downloading emails over telephone lines or paying for additional storage capacity on email servers.

One of the most popular public myths, which got some fuel by headlines like ´free telephony over the Internet`, is that the transmission in the Net is free, since users do not pay for transmission over distant provider’s backbone networks and connections, be it a slow 2.4 Kbps V.22bis connection or an OC-48 connection with 2.4 Gbps. Backbone providers are usually paid by Internet Access Providers for transit through the backbone network, few providers, especially large providers have special so- called peering agreements, where each party pays for its part of the connection between two providers, except in cases of massive imbalances in traffic volume no payment is usually done6. Since public peering between large IP backbone providers is usually done only between carriers of similar size, smaller providers do cooperative peering at Commercial Internet Exchanges (CIX) or Metropolitan Area Exchanges (MAE). Since large ISPs usually only peer with other large ISPs on a

2 The level of services necessary: Are two levels sufficient or is it necessary to have a freely configurable amount of service qualities. This can be topic of hot discussions, but the principle seems to be generally accepted.

3 A single provider can run its own backbone network with differentiated service, but this would not be the Internet anymore, and an economic theory suggests that a single network with multiple services can be run more efficiently than multiple networks for single services.

4 In Internet backbone networks, charging by distance is common, due to the fact that underlying network technologies like Frame Relay or ATM are usually charged by distance.

5 Talking about ´receivers` is a bit confusing, since from a protocol point of view, most protocols work bi-directionally, and from a Web servers point of view, most people download data from the server, thus receiving the data. Strictly speaking, the side which traffic is imposed upon is paying for this traffic, no matter in which direction this traffic flows, downlink to the server site or uplink to the requester. To make it more even complex, additionally, as mentioned, the requester – as the receiver - also pays for his side of the connection to the Net.

6 Peering is one of the few areas in Internet economics which has gained some interest in the academic community [Bailey95] [Srinagesh95].

´keep-it-all` basis, small ISPs are forced to either buy transit, do cooperative peering, or buy transit from a bigger ISP, which has access to the core backbones. Thus we find a hierarchy of ISPs. Basically this system of basic Internet transmission services works stable today, except that there is a huge concentration process going on in the industry, especially in the US market, where many small ISPs ´merge` with large ISPs.

Everything was fine until IP telephony came...

2.4.3 Voice on the Net Quiet in contrast to another common misconception, Internet telephony is not as bad as it usually sounds. The H.323-standard allows for a wide range of speech codecs, for high-end, high-bitrate to low-end, low-bitrate voice transmission. Low-bitrate codecs do not necessarily mean low-quality. Subjective Mean Opinion Score (MOS) tests, a common measurement to characterize voice qualities, show, that in this respect there is almost no difference between the rating of a 64 Kbps G.711 (PCM) codec and a 6.4 Kbps G.723.1 (MP-MLQ) codec. The sometimes perceived lower quality of Internet telephony is closely related to another issue: missing bandwidth in some areas of the public Internet and missing established mechanisms for reservation of quality of service parameters in the net.

There is actually a wide range of mechanisms to ensure a hop-by-hop quality of service in the Internet (e.g. IP Precedence, Weighted Fair Queueing (WFQ), Random Early Detect (RED) mechanisms in routers) and a few end to end mechanisms (e.g. Resource Reservation Protocol (RSVP), concepts for bandwidth broker architectures) none of which is finalized yet. Neither of the standards are widely supported on the Internet, nor exist common QoS-enabled applications today.

One of the reasons for this is, that there is no viable business model for QoS support in the IP network. Internet Service Providers (ISPs) can charge for the dial-up Internet access, Internet backbone providers can charge ISPs for the access of the backbone, but there is no business model how to charge single customers for single high quality connections over several providers throughout the Internet. For companies’ Intranets and virtual private networks (VPNs) the situation is somewhat better, they can be charged for better IP services, but in the public Internet there is basically one network with one quality only.

Of course it is possible to do IP telephony on the network today. According to a recent study on a major US IP backbone, IP telephony is among the top ten UDP applications. Hypothetically there would be scaling issues, if some provider tried to put billions of minutes of voice on the Net from one day to the other, but since this is not going to happen, network backbone capacity will follow behind demand as it has been over the last decade.

What is really necessary here are economic incentives for IP network providers to increase backbone capacity, stepping out of the business of selling simply bandwidth as a commodity, to provide services that differ and are valuable to Internet users. How those services are technically accounted and how they are priced by the service provider – of course nobody wants to buy basically the same service much more expensive – is a different issue. But the step that needs to be taken is the development of economic models, which tackle the welfare considerations as mentioned, which are feasible mechanisms and can be technically implemented by carriers.

2.4.4 Advertisement always works for Content Another good example for the fundamental lack of appropriate economic models in higher level Internet services are micro communities like Internet game players. Mostly, service providers start to look at Internet gaming as an extension of existing services, not as a business model of its own, only very few providers, basically coming out of the gaming and content provision industry, start pure Internet gaming services.

Costs of Internet gaming are mainly cost of gaming content, bandwidth for IP service, maintenance and customer care and possibly additional game specific support. Pricing centers around traditional pricing for entertainment services: 6 Euro per 1.5 hours of cinema, 1.5 Euro for 2 hours video rental, 10 Euro seems to be a maximum threshold. Accounting and billing for content services is a huge problem, since training the kids to use their parents credit cards is not part of the solution and micro- payment and smart card technologies are still somewhat uncommon.

One of the fundamental problems again is the lack of appropriate economic models for this type of content services in the Internet. There are options in models that work, like the telecommunications

22 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 business, the cable TV business model, or online game models which are derived from the games themselves, but there is no Internet service model that funcions on its own.

There are many ways to almost get Internet business running, like banner advertisement (nested ad content, ´interstitials`, ´advertorials`), sponsorships (special event sponsorships, competitions), or flat rates. All those mechanism are deployed today in search engines, shareware distribution sites, in Internet games, and at other services all over the Internet. Permanent subscription fees and pay per hours are ways that work for other non-Internet services, but convincing customers for permanent subscription is hard in a highly volatile industry and a competition with other ad-financed ´free` servers. Advertisements are usually of limited reach, since they are usually of local scope and language barriers and legal considerations often influence the general validity of this mechanism. Available personalized information are hardly taken into consideration. Internet gaming as a spectator shop has not lifted large scale yet.

New ways of charging and financing new Internet services are needed, particularly in the non- business market segment, ideas beyond ´flat` pricing models, advertisement and sponsoring. Appropriate economic models which leverage content and communication are still missing.

2.4.5 Bottom line: Need for an Internet Economic Task Force There are many areas, where new business models either do not exist or where they are not well understood, mostly because there is no established economic framework for Internet services, Internet transmission and content services in particular. Especially in the area of basic Internet transmission, many new services are at the end of the standardization process or close to large-scale-deployment, like IP Version 6, IP QoS, IP Multicast, mobile IP, but considerations about innovative mechanisms for the efficient, cost recovering economic usage of those new services are still missing.

What is really needed are joint efforts between the various involved parties. Considering the very innovative work and the rapid implementation cycles that the Internet industry is pursuing in organizations like the IETF and other industry consortia, academic economic research on Internet technology are light-years behind technological research. Taking into account that it is outside the scope of the IETF’s work to support specific business models, it is – nonetheless – necessary to develop economically viable models for the industry as a whole, which have the technical support from gear manufacturers, which include the operative know-how from the Internet operators and which have the support from the Internet service provider industry.

Literature [Bailey95] Joseph P. Bailey 1995: Economics and Internet Interconnection Agreements. In: The Journal of Electronic Publishing. University of Michigan Press. May, 1995. [Claffy98] Claffy, K.; Miller, G.; Thompson, Kevin 1998: The Nature of the Beast: Recent Traffic Measurements from an Internet Backbone. In: Proceedings of the Internet Society INET’98. Geneva. [Srinagesh95] Srinagesh, Padmanabhan 1995: Internet Cost Structures and Interconnection Agreements. In: The Journal of Electronic Publishing. University of Michigan Press. Mai 1995. [Standage98] Standage, Tom 1998: The Victorian Internet. New York.

3. Next Generation Internet Activities in the R&D Programmes of the European Commission

3.1 Introduction

Rémy Bayou, European Commission DGXIII, Belgium

Three specific Programmes exist within the 4th Framework Programme (1994-1998) related to information and communication technologies, Esprit, Telematics and ACTS. The following sections present the initiatives and projects that have implemented the next generation Internet technologies

23 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 within these three Programmes. The last section of this chapter details the COST Actions related to those technologies.

Each of these Programmes addressed specific aspects of the Information Society technologies as explained below and led in the 5th Framework Programme (1999-2002) to the IST (Information Society Technologies) Programme addressing information and communication technologies and applications.

IST is a Programme managed as a single integrated infrastructure within the DGXIII, thus guaranteeing an optimal consistency with critical mass focused on strategic issues, with a better visibility and enhanced international co-operation potentialities. It has a total budget of 3.6 billion Euro and its work-plan will be revised yearly.

The strategic objective of the IST Programme is to realize the benefits of the Information Society for Europe both by accelerating its emergence and by ensuring that the needs of individuals and companies are met. It is structured in four inter-related Key Actions with specific objectives that will offer a comprehensive balance of RTD activities, from basic research to demonstration and take-up actions:

The four Key Actions address the following topics:  Systems and services for the citizen.  New methods of work and e-commerce.  Multimedia contents and tools.  Essential technologies and infrastructures.

While generic RTD activities concentrate on:  Future and Emerging Technologies.  Research networking.

Demonstration KEY ACTION 1 KEY ACTION 3 KEY ACTION 2 Systems and services Multimedia contents New methods of work for the citizen and tools and e-commerce

KEY ACTION 4 Technology Essential Technologies and infrastructures

Integrated Key Actions

The Key Action 4 ´Essential Technologies and Infrastructures` will address most of the issues related to the Next Generation Internet. The IST Programme will complement these activities through the generic activity on ´Research Networks` by developing the necessary networking infrastructure in Europe. This infrastructure will serve the academic and industrial research communities by providing an operational platform allowing them to deploy their Next Generation Internet based applications, and by offering testbed facilities for integrating and validating the Next Generation Internet technologies, protocols and applications.

Detailed and updated information is available at http://www.cordis.lu/ist.

3.2 Next Generation Internet in ACTS

Rémy Bayou, European Commission DGXIII, Belgium Martin Potts, Martel GmbH, Switzerland

The Next Generation Internet technologies for networking have been developed in the ACTS Programme under the umbrella of domain 3 ´High Speed Networking`. In particular, the 3rd Call of ACTS has introduced the following new projects with a focus on IP and ATM interoperability and associated Quality of Service issues: AROMA, BTI, COIAS, DIANA, ELISA, IthACI, PeterPan, SUSIE.

These projects meet together within the framework of a so-called ´Cluster` to exchange ideas, ensure that there is no overlap between their activities, and to exploit the specific expertise and/or available developments from other projects. The issues being considered by these projects include:

 How to map the Internet Integrated Services and Differentiated Services models to the ATM QoS model,  are other Internet models more suitable?,  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,  how to get full benefit from IPv6 features,  how and where to monitor the achieved QoS performance,  which measures are necessary to prevent misuse/unauthorised use of network resource,  how to optimise the use of network resources to fulfil the required QoS,  how and when to use satellite to dynamically set up shortcut route between nodes,  how to provide alternate path routing,  how to ensure efficient and reliable multicast,  how to make applications QoS-aware,  how to charge for a ´Premium IP` service.

The first part of this section (3.1.1) describes the common areas of interest (Integrated Services, Differentiated Services, application adaptation), whereas the second part of the section (3.1.2) deals with more experimental-related issues covered essentially by individual projects. This section covers more in general some possible technical approaches and experimental issues; the following chapter 4 then goes more into detail and describes for every of the projects within this ACTS Cluster the project goals, key issues, ongoing activities, and trial results.

3.1.1 Emerging Techniques for the Integration of IP and ATM, with QoS

3.1.1.1 Internet Integrated Services and Differentiated Services The first solution to provide QoS to the Internet was the IETF’s Internet Integrated Services (IIS or IntServ) architecture. IntServ defines two new service models to complement the best-effort model; namely, Controlled Load (CL) and Guaranteed Service (GS).

The Controlled Load Service has the following properties:  A very high percentage of transmitted packets will be successfully delivered to the receiving end- nodes of the network.  The transit delay experienced by a very high percentage of the delivered packets will not very much exceed the minimum transmit delay experienced by any successfully delivered packet.

To ensure that these conditions are met, clients requesting the Controlled Load Service provide the intermediate network elements with an estimation of the traffic they will generate, the Tspec.

The Guaranteed Service has the following properties:  A delay-bounded service with no queuing loss for all conforming datagrams.  The maximum end-to-end queuing delay and bandwidth provided along a path will be stable.

The GS does not control the minimal or average delay of datagrams, merely the maximum queuing delay.

For dynamic GS and CL reservations, a signalling protocol is needed and the IETF has specified the Resource Reservation Protocol (RSVP) for this purpose. RSVP conveys information about the requesting flow (IP address and port number), the desired service model, and token bucket filter parameters. RSVP is initiated by the receiver and is designed to integrate smoothly into a multicast environment from different receivers towards the root of a multicast distribution tree. The reservation status at the routers is maintained in so-called ´softstates`. This means that the receiver must send reservation messages periodically in order to keep its reservation alive; otherwise the reservation is torn down. Besides this time-out mechanism, the reservation can be disabled by a specific teardown message.

Many of the projects dealing with this topic in ACTS are developing their own platforms in order to manage the request of QoS originated by the IP hosts, e.g. via RSVP messages according to the Integrated Services model. They establish connections via standard ATM signalling procedures (on an ATM-VC-basis), either related to a single IP flow or by aggregating several IP flows. A typical architecture suggested for the mapping of IP/RSVP and ATM (taken from the DIANA project) is shown below:

Policy Control IP ATM

Flow Admission Control CAC

RSVP Signalling Translation UNI

Traffic ControlAdaptation Traffic Control Adaptation ControlPlane User Plane Classifier Policer Scheduler Flow-to-VC SVC Shaper Binding

Flow based IPover ATM Queueing Discipline

The PeterPan project is developing a RSVP-capable core network node, in which a Central Controller is dedicated to host code for the ATM (ITU-T) signalling protocols, as well as the RSVP and IP routing protocols.

Interworking B-ISDN signalling Control Function protocols

RSVP deamon ATM Resource Manager

IP (routing, ICMP,..) Central Controller

ET-IP-CC ET-IP

IP flows

Signalling messages

PeterPan’s Central Controller is based on a Single Board Computer, running the (real-time) VxWorks operating system. The Central Controller collects all the ´information` received over the peripheral access boards (ET-IP) and, after processing signalling and IP routing messages, it performs the appropriate setting and instructs the local control process, again running in a VxWorks environment, on the ET-IPs, to allow a fast processing of IP flows directly over the periphery of the node. The use of a real-time operating system guarantees fast switching context between tasks and a strong control of the scheduling of tasks together with the management of system resources, such as timers, semaphores and message queues, that are heavily used in such an application. For IP routing and control processes, including the RSVP daemon, the prototype of the hybrid core network node includes a ported version of publicly available software.

The scalability problems of IntServ and the need to find solutions for IP QoS quicker than a strict end- to-end solution have driven the Internet research community to look for a simpler solution. In the beginning of 1998 a Differentiated Services (DiffServ) working group has been founded at the IETF to address this problem. Their goal is to define simple (compared to IntServ) methods of providing differentiated classes of services for Internet traffic. The mechanism uses the Type of Service (TOS) field, a currently unused field of the IPv4 header, to mark packets with a certain priority. According to this priority a particular forward treatment, or per hop behaviour, is established in the intermediate network routers. The principle of operation is that the router at the network boundary evaluates each packet and sets bits in the TOS field in accordance to a preinstalled profile. This profile is defined by the network administration according to special contracts with the customers. Inside the boundary the packets are treated according to the so called per-hop-behaviour which can include different scheduling, different drop decisions, or different route selections.

The DiffServ approach is very popular within the IETF and vendors are already offering various features of queuing, traffic shaping and filtering technologies for implementing traffic priority and controlling congestion across the network. In the Internet community there is a strong belief that in future networks the QoS model has to be simple. DiffServ fulfils this requirement because it can be implemented step by step and DiffServ-capable islands are interoperable with non-DiffServ-capable islands. Furthermore, no modifications in any end systems are required.

SUSIE is the only project in this Cluster of projects that is specifically addressing charging and policy aspects for ´Premium IP` services. The project partners have developed a reference model for accumulating the charging and billing of customers, taking into account the concept of retail and wholesale service providers, and the fact that the underlying technologies (e.g. packet-based and circuit-based, respectively) in these two environments may not be the same. The model includes the possibility for billing between different Network Operators. The project will use IntServ and DiffServ implementations from DIANA.

Integrating IntServ and DiffServ over ATM All projects in this cluster will use implementations of RSVP and/or DiffServ, though these usually represent only the fundamental technologies on which the projects will do further investigation of

27 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 issues such as (for example) multicast, security, mobile IP, alternate path routing, scalable resource reservation protocols, etc.

DIANA, ELISA, PeterPan and IthACI focus on the convergence of Internet service architectures with ATM network technology. ELISA is validating the support of 2 models of Internet QoS (IntServ and DiffServ) in a combined approach:

Access Core Access Host Network EF BR Network BR EF Network Host

Edge Device Edge Device

Int Serv Domain Diff Serv Domain Int Serv Domain (RSVP aware) RSVP Tunnel (RSVP aware)

EF Edge Functionality BR Border Router

The DiffServ service class byte (DS) is added at the host or ´Edge Device`. RSVP is tunnelled in the core and only interpreted at the Edge Devices. The Edge Device is also the place where admission control and policing are applied. In the core network there is no flow separation. In particular, routers put all packets of a specific class into a dedicated queue.

The DIANA, ELISA and PeterPan projects are developing ´Edge Devices`, but each based on a different platform (LINUX, Solaris, VxWorks, respectively) and each with individual techniques for mapping DiffServ and IntServ traffic flows originating from hosts in the access network onto ATM VCs in the core network. For the ATM side, single VCs per flow and aggregated flows mapped onto one VC will be used.

Access Edge Device ATM Core

RSVP requests / reservations* Diff Serv config

IntServ Int Serv / Diff Serv Flows SVCs

DiffServ Aggregation Integrated Packets Packet Scheduler Diff Serv / Best Effort

PVCs Best Effort Packets • relative preference • guaranteed service *mapped to ATM VCs

In addition, it is desirable to multiplex DiffServ traffic with aggregated IntServ flows. For this purpose, the ELISA Edge Device allocates a (locally defined) DiffServ traffic class for all aggregated RSVP flows. With appropriate queuing mechanisms, this class is managed in such a way that the bandwidth guaranteed for the accumulated requests is available. Moreover, ATM signalling allows to adapt the bandwidth of the VC allocated to DiffServ traffic as well as to aggregated IntServ flows. Using UNI 4.0, this can be achieved by renegotiating the parameters of a VC; using UNI 3.1, it is necessary to bundle several VCs to a single pipe with multi-link characteristics.

Several issues remain regarding flow and bandwidth management as well as admission control. In particular, managing DiffServ networks with reservations for aggregated or individual flows appear to be challenges, for which different solutions (treating individual IntServ flows separately or bundling flows of a similar type, use of short-cut mechanisms, alternate path routing, etc.) will be examined by projects in the cluster.

3.1.1.2 Multi-Protocol Label Switching (MPLS) IP switching is a promising approach to combine the speed of ATM switch hardware with the simplicity and flexibility of IP Internetworks. The basic idea of IP switching is to use IP network control on top of ATM switch hardware. The full Internet functionality for addressing, routing, and transmission is used within the IP router, but the high-speed data forwarding functionality is performed by means of IP switching. The complex ATM signalling is replaced by a simple IP switch coordination protocol (Ipsilon IFMP, Tag-Switching TDP), or by implicit signalling means (IPSOFACTO).

Router

ATM switch

A variety of IP switching architectures have been proposed (Ipsilon Switching, CISCO Tag Switching, IBM ARIS, Toshiba CSR, NEC IPSOFACTO, etc.). This has prompted the Internet Engineering Task Force (IETF) to define a standardised approach within the working group on Multi-Protocol Label Switching (MPLS). Today, MPLS mainly focuses on interoperability aspects, such as the Label Distribution Protocol (LDP). This provides the signalling facilities between the Label Switching Routers (LSRs), and coordinates the distribution of label bindings, and initially concentrates on point-to-point best-effort communication. Recently, work began on traffic management issues in MPLS. Although neither restricted to any layer 2 technology nor to a specific layer 3 protocol , IP over ATM is currently the most likely to be implemented as a first instantiation of MPLS.

Currently, several concurrent IP switching solutions exist. MPLS as the proposed standard solution for IP switching has deficiencies with regard to functional enhancements, compared to traditional IP networks in the areas of QoS, resource management and multicast support.

The overall scope of the IthACI project is to evaluate and contribute to the different technologies that permit the efficient transport of IP traffic over an ATM backbone infrastructure (either private or public). The project is investigating and enhancing schemes for the efficient integration of IP and ATM network technologies. It concentrates on fast layer 2 forwarding methods for IP traffic based on labelled flow mechanisms. In this context, the project is also addressing how the previous facilities are affected by requirements for efficient IP multicasting over ATM, accommodating QoS demands, mobility and resource control. Three independent islands are being built; each one using its own proprietary IP switching technique - NEC’s IPSOFACTO, CISCO’s Tag Switching, and Alcatel’s YALSA. Each of these islands will be enhanced with features in several or all of the areas of multicast, QoS, resource management, and mobility. The islands will then be interconnected to demonstrate the interoperability of the IP switching techniques as well as the enhanced features.

3.1.1.3 IPv6 With the changing nature of the Internet and business networks, a new protocol, known as IPv6, has been defined to ultimately replace IPv4.

The IPv6 retains many of the features that contributed to the success of IPv4. However, despite many conceptual similarities, IPv6 changes many of the details of the protocol. The changes can be summarised as:  larger address  flexible header format  improved options  support for resource allocation  provision for protocol extension

A brief introduction to the main differences between IPv4 and the new Internet protocol IPv6 is given below. It concentrates on the changes in the header format, addressing and routing as well as noting new support for flows and real-time traffic.

Header Format The new IPv6 header format is far less complex than that of IPv4. In total, the IPv6 header has only 8 fields compared to the 13 fields plus some options of IPv4. Unlike the variable length header of IPv4, the IPv6 header length is fixed at 40 bytes. Thus, there is no need for a field to record the length of the header.

Only the 4-bit version field remains the same in both versions. Seven fields from the IPv4 format have been removed (Header Length, TOS, Identification, Flags, Fragment Offset, Header Checksum, Options/Padding).

The removal of the header checksum reduces the cost of processing headers in the network, as there is no need to check and update the checksum at each hop. Since most link-layer technologies include their own checksums, the risk of undetected errors is seen as minimal.

The Type of Service (TOS) field in IPv4 can be used by applications to indicate transmission preferences for their data. However, it is not frequently used by applications and was removed from IPv6.

The remainder of the IPv4 fields, has been re-defined for IPv6:  the Total Length field is replaced in IPv6 by the Payload Length  the Time-To-Live field (TTL) in IPv4 has been renamed to Hop Limit

There are no options present in the IPv6 header. Any options are appended after the IPv6 header, and before the transport protocol header, as Extension Headers. An arbitrary number of extension headers may be inserted between the IPv6 header and the transport protocol; a few extension headers have already been defined.

Finally, there are two new fields, Priority and Flow Label. These fields are intended to support flows and real-time/multimedia traffic.

Addressing IPv6 addresses differ considerably from IPv4 addresses in size, notation, meaning and structure. IPv6 addresses are 128 bits in length, and are written in hexadecimal notation as eight 16-bit integers separated by colons. For the sake of brevity, leading zeros in each hexadecimal component may be omitted and a set of consecutive null components may be replaced by two colons.

An IPv6 address will be one of three types: Unicast, Multicast, Anycast.

Unlike IPv4, IPv6 addresses have no fixed structure. There are no definitive boundaries between network, subnetwork and interface identifiers. A host can treat an IPv6 address as an opaque string of 128 bits, and entries in routing tables will be simple prefixes ranging from 1 to 128 bits. However, hosts and routers must be able to identify special addresses. These include, among other, unspecified addresses, IPv4-based addresses, Provider-based (aggregatable global unicast) addresses, multicast addresses, anycast addresses.

It is envisaged that the majority of IPv6 addresses will be allocated according to a provider-based addressing scheme (also known as aggregatable global unicast addressing).

IPv6 mandates the recognition of multicast addresses by routers using the functionality of IPv4’s Internet Group Management Protocol (IGMP) for managing the join/release to a multicast group and, generally, to communicate membership information to a multicast group. Since IPv6 inherently contains multicast functionality, the features of IPv4’s IGMP have been incorporated into the basic Internet Control Message Protocol (ICMP) of IPv6, which is the protocol that allows routers to exchange error and control messages with other routers.

Routing

One of the problems with IPv4 is the explosion in the size of routing tables inside the Internet. In many cases, routers can only maintain precise routing information for a subset of the Internet, and use default routes for the remainder. IPv6 attempts to solve this explosion in routing table sizes by aggregating routing entries. These routing entries will be exchanged through the Inter-Domain Routing Protocol (IDRP). The Border Gateway Protocol (BGP) as used in IPv4 is highly optimised for 32-bit addresses, and could not be easily upgraded for IPv6.

Routing entry aggregation can only be achieved if there is some form of hierarchy in the addressing scheme. The provider-based addressing scheme is the hierarchical addressing scheme that will be used by IDRP. By definition, all customers of a provider are routed through the provider’s network. Outside this network it is sufficient to enter a single prefix in the routing tables for all hosts contained inside it.

For intra-domain routing, IPv6 does not use a different protocol as IPv4. The current interior routing protocols such as Open Shortest Path First (OSPF) and RIP are simply updated, making changes to accommodate the new address format.

Support of Flows and Multimedia Traffic Unlike IPv4, the IPv6 specification explicitly supports flows. It defines a flow to be ´a sequence of packets sent from a particular source to a particular (unicast or multicast) destination, for which the source desires special handling by the intervening routers`. In real terms, an IPv6 flow is a set of packets from the same source to the same destination which all bear the same Flow Label.

The 20-bit Flow Label field is used to identify flows. The labelling of a flow does not have any effect on routing. However, it is anticipated that the Flow Label could be used in conjunction with the routing header to provide source routing for flows.

The Flow Label fits particularly well with resource reservation. It provides a mechanism by which intermediate routers can efficiently classify incoming IPv6 packets according to their flow requirements.

The BTI, COIAS and PeterPan network infrastructures will be some of the first European IPv6 based platforms and will provide important feedback before the completion of the IPv6 standardisation process and the complete IPv6 deployment.

For the mapping of IP addresses to ATM addresses for IPv6, BTI shifts this function from a part of a link layer convergence function (as the ARP protocol for Ethernet LAN’s, and the ATMARP function for IPv4 over ATM), to a common sub-function for NBMA (Non Broadcast Multiple Access) link layer technologies. The NBMA sub-functions enhance the basic link layer technology with emulated multicast facilities through a MARS (Multicast Address Resolution Server). The aim of the NBMA sub functions is to have the Neighbour Discovery protocol for IPv6 to be implemented commonly for all NBMA networks. The IPv6 router will at each trial site provide MARS service for the LIS. If appropriate more LIS can be defined spanning a particular subset of terminal equipment.

3.1.1.4 Security Nowadays, no one can imagine to provide network services without addressing the security problems, that is why a clear security policy has to be defined and security functions and protocols must be implemented in the network infrastructure and within the end stations.

The COIAS platform provides IP Authentication and Security (encryption) mechanisms according to the latest research of the IETF IPSEC working group. This work also includes the implementation of a key management protocol (Internet Key Exchange - IKE). The following figure shows the overall structure of the security framework using the IKE approach.

Applications

Application Security API CA & LDAP directory services SAD & IKE SPD LDAP LDAP

TCP/IPv6 stack Cryptographic Service Provider

IPSec including AH and ESP

LDAP: Lightweight Directory Access Protocol IKE: Internet Key Exchange (protocol) AH: Authentication ESP: Encryption CA: Certification Authority

Since the Internet and many other networks are multinational, security mechanisms have to be adapted to the national regulations. This is particularly true when using encryption mechanisms. To fulfil the requirements of the users, trade and industry as well as the various demands of government agencies, the COIAS approach proposes a security infrastructure which enables multi-level security and introduces services to establish security policies between session participants. The IPv6 software stack includes well-defined interfaces allowing the use of different encryption algorithms, as well as the use of different security policies.

3.1.1.5 Application Adaptations for QoS The IETF Integrated Services (IntServ) framework provides the ability for applications to choose among multiple, controlled levels of delivery service. To support this capability, two features are required:  Individual network elements (subnets and IP routers) along the path followed by an application’s data packets must support mechanisms to control the QoS delivered to those packets.  The application’s requirements must be communicated to network elements along the path, and QoS management information must be conveyed between network elements and the application.

All projects in the Cluster require IP applications that are capable of indicating some QoS requirements to the network. A number of applications have been surveyed in order to determine their feasibility to be used as bench mark applications, and VIC (VIdeo Conferencing tool), VAT (Visual Audio Tool) and ARMIDA are amongst those selected, essentially because the source code for these is available.

The following model of an application allows to explain where the QoS functionality has to be inserted. We consider an user application to be composed of the following essential modules:  (Graphical) User Interface (UI) Module  Core Application (CA) Module  Network Interface (NI) Module

The UI module allows for interaction between the user and the application. The Core Application implements the main part of the application. It interfaces directly to the UI and the NI.

The NI module implements the communication features, providing to the CA access to the underlying network, and an abstraction of the functionality of the lower layers.

According to the OSI reference model, the UI and CA are at the application layer, while NI covers the presentation layer, and possibly also the session and the transport layer. Another essential element is the Operating System services used by the application. The operating system controls access to the layers beneath NI (e.g. typical Web browsers have their own HTTP library (NI), which accesses the TCP transport provided by the Operating System).

In the case of the TCP/IP protocol, the TCP and UDP are located between the CA and NI module, while the IP operates in the NI module. The RSVP protocol operates also in the NI module.

In order to introduce RSVP capabilities into a pure IP based application, it must be extended by:  a new module between the CA and NI modules to manage the resource reservation: the interface between RSVP and IP. Normally this is provided by the Operating Systems’ developers.  the inclusion of an RSVP API (RAPI) into the application itself. This allows the interaction between the CA and RSVP.

The VAT application already offers different audio coding standards. They vary according to their bandwidth but they all emit a constant stream of data bits. The supported audio formats use a relatively low bitrate, which makes them vulnerable to packetisation delays. Packets are therefore chosen to be small which in turn affects the router performance. This fact and the fact that the transmission of interactive audio has often been reported to be more sensitive than a video transmission makes this application an important test case for any RSVP-ATM validation.

VAT uses an adaptive equalisation algorithm to cope with the transmission delay variance (jitter). This is implemented with a receive buffer FIFO where the filling-level is controlled by adjusting the readout ´sampling` rate. The filling-level is controlled to remain slightly above the minimum level caused by the last ´extreme` delay. This mechanism has been designed for the ´best effort` Internet service, but it reasonably works only over a lightly loaded network, and should therefore be well-suited to the Controlled Load Service (see section 3.1.1.1). With the Controlled Load Service the overall buffer requirements could be minimised (because bursts are not cumulative) at the cost of some additional delay. However, for the small bitrates of compressed audio (where buffering is not an issue) this alternative is considered to be not worth the additional delay.

The existing VAT application is being extended to perform the necessary signalling functionalities.

Based on the audio coding scheme chosen by the user, the required bandwidth must be requested. Opening the RTP (Real Time Protocol) connection also causes a connection to the local RSVP daemon to be opened. Over this control path the reservation information is passed from the application to the local RSVP daemon and from there to the routers, the Integration Unit/Edge Device and the switches. The traffic descriptor must be calculated based on the coding scheme. It defines the bitrate (as a token bucket specification and peak rate) as well as the frame size for the connection.

When the user selects a different scheme a re- negotiation will be initiated on the RSVP level. If the required bandwidth is not available the user will be prompted to try connecting using a less demanding coding scheme. Since the RSVP Application Programming Interface is completely separated from the communication interface, the VAT application can be made ´signalling-aware` without much interference with the existing source code.

The QoS specification of the Controlled Load Service is deliberately imprecise. The application may expect to ´experience little or no average delay … [and] congestion loss…`. When testing the interworking infrastructure, packet loss and delay variance seen by the application will be measured. The RTP protocol built into the receiving VAT detects missing packets and informs the ´playout engine` to remain muted for the corresponding time. These events can be recorded and compared with a transmission over the ´best effort` service. The end-to-end transmission delay will not be measured from within the application, but the jitter provided by the interworked IP/ATM networks can be derived from the operation of the equalisation algorithm. The first derivative of the presentation (playout) clock indicates the amount of acoustic distortion caused by the jitter.

The video on demand application ARMIDA encompasses a Web server and a Web client. The server runs on Solaris2.5.1 or Windows NT, the client only on NT. ARMIDA’s video encoding and decoding is based on MPEG1, MPEG-2, or MPEG-4. ARMIDA is being extended to use RSVP and IP as well as native ATM.

Real-time and near-real-time video may require several attributes from the network in order to offer a sufficiently high quality to satisfy the users. The main requirements for the delivery of video are:  sufficient bandwidth: depending on the amount of video information transmitted and the compression method,  low latency: necessary for ´live` sessions such as long-distance teleconferencing when users at either end must respond to each other without undue delays,  low jitter: required even in one-way applications to avoid frame slips or poor synchronization between audio and video,  efficient multicast: so that the entire video stream is not replicated n times for n users, but is replicated only at the last possible branch point to each user.

The image size on the screen, resolution, image depth, and transmission rate all determine the amount of bandwidth. By using compression, lower resolutions and frame rates, the raw bandwidth requirements are reduced substantially.

The ARMIDA application is being adapted to make it ´signalling-aware`. A ´signalling-aware` application has strict delay bounds; this kind of application has to wait for the establishment of a resource reservation before it starts to send data. In the case of ARMIDA, the Guaranteed Service is used to assure the required maximal end-to-end delay. A signalling-aware application recognises two different signalling states: Negotiation and Renegotiation.

Negotiation With RSVP, the receiver must set the flowspec according to the sender_tspec and the received adspec and return a RSVP message to the sender. Depending upon the received flowspec, the sender may react in one of the following ways:  Start data communication  Continue negotiation  Abort

In the first case, the negotiation succeeded and the required resources were reserved.

In the second case, the reservation made by the receiver was not sufficient for the application, but the sender could reduce the request indicated in the sender_tspec and try again to reserve the sufficient amount of resources, until it obtains the minimum rate allowed by the application or it obtains a reservation.

In the last case, the negotiation failed because insufficient resources were available. The sender can send the data only if a satisfactory resource reservation has been made in advance; otherwise the data cannot be sent and an error message must be sent to the user.

Re-Negotiation The re-negotiation phase starts when the QoS has to be changed during the data transfer. It can be triggered by a change of the application requests or by a change in the network.

Re-negotiation is possible by sending periodically Path messages to confirm the required QoS. The Path message passing through the RSVP routers, checks the resource availability and carries

34 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 information about the network status. In the case that the application requirements change, the sender sends, via a Path message, the new traffic descriptor to activate the new reservation at the receiver’s side.

The re-negotiation phase does not affect data transfer. It will be influenced by this phase only if enough resources are no longer available.

The MPEG-4 standard introduces Delivery Multimedia Integration Framework - DMIF: It hides the delivery technology details to the applications, managing the end-to-end QoS required by the application and passing them to the Network Interface Module. The DMIF specifies the DMIF- Application Interface in a way that it satisfies the requirements for many network scenarios and maintains uniformity across all cases. The DMIF adopts a QoS descriptor that allows the application to pass its requirements without considering what is the transport mechanism.

To enhance the ARMIDA application with RSVP features, a mapping between the Integrated Services parameters and the DMIF parameters had to be defined.

3.1.2. Experimental issues 3.1.2.1 Scalable Resource Reservation Protocol (SRP) SRP aims at providing a low delay, low loss service, and therefore any ATM traffic class can be used that guarantees a minimum bandwidth at or below which losses due to congestion are unlikely to occur, and that has either an explicit delay bound or a statistically low delay. This includes the ATM service classes CBR, VBR, ABR and GFR. For simplicity, the use of the most basic and most commonly available traffic class, CBR, is assumed.

As opposed to RSVP-over-ATM, SRP establishes a QoS path without per-flow state in routers. Senders set a request bit in data packets until the desired reservation level has been confirmed via a signal sent back from the receivers to the senders. Similar to RSVP over ATM, and in contrary to DiffServ, the reservation is absolute and reliable. However, senders, routers and receivers only obtain the current reservation level by counting packets that have the request or reserved bit set. Since a network is a system of distributed elements, those network elements may have a slightly divergent view of the currently reserved resources. Furthermore, a reservation builds up gradually. Hence, SRP is more dynamic than the traditional, explicit reservation schemes of (for example) B-ISDN. For this reason, the project DIANA will investigate through experiments if SRP provides stable reservations and whether applications can cope with the transient phases at the beginning.

Sender Router

Measure Application Resv Resv reservation rate Receiver

Reservations Reservation Req Admission + Established ? possible ? Requests NO YES Marked as Resv, Req or BE Req BE

Feedback messages

Since a router must know the admission decision of the ATM network prior to deciding whether a request packet can be accepted, and also since frequent set-ups or re-negotiations would put a significant load on the signalling processors in the ATM network, routers should anticipate future reservation behaviour in order to reduce the number of adjustments that need to be made. A simple example of how ATM bandwidth can be adjusted to accommodate SRP reservations has been defined, in which ATM reservations are changed in comparably large steps. An increase is initiated whenever the SRP reservation exceeds a certain threshold below the current ATM reservation.

Likewise, a decrease is initiated when the SRP reservation drops below a second, lower threshold. If the SRP reservation reaches the ATM reservation and the increase has not yet been accepted by the ATM network, the request packet has to be degraded, thereby delaying the reservation increase. More advanced algorithms for dynamically adjusting the ATM bandwidth are also being studied.

In the absence of re-negotiation capabilities in the ATM network, a similar functionality can be obtained by setting up new VCs which either replace or complement the existing VCs. In the former case, roughly twice the required bandwidth has to be reserved in the ATM network during transitions from old to new VCs, which may lead to admission failures even if there would be enough bandwidth to accommodate the actual traffic. In the latter case, the number of active VCs in the ATM network is increased and the router needs to support load balancing over multiple parallel VCs. Such load balancing may lead to packet re-sequencing, which may negatively affect the performance of higher layer protocols.

3.1.2.2 Simple Integrated Media Access (SIMA) SIMA is a special implementation of DiffServ aiming at balancing resource usage based on a so-called nominal rate that has to be specified by the user. In the access node, the data is measured and classified into flows. The rate is checked against the specified nominal rate and the priority is calculated. In the core network, packets may be dropped or delayed, depending upon the setting of the DS bits and buffer occupancy. An option is available to specify a dynamic nominal rate (an integration of RSVP and DiffServ), which would exploit ATM’s L2 flexibility.

SIMA’s capabilities enable a user to control its resource share at a bottleneck. This control scheme will be experimented with two reference applications with a different nominal rate sharing resources at a bottleneck with synthetic background traffic.

static + Nominal Bit Rate

dynamic PL

Yes (Discard)

Meter Scheduling & Buffering Unit “SIMA queueing discipline”

Flow based rt/nrt Classifier Marker SBU

Behaviour Aggregates

3.1.2.3 ´Peer` IP-ATM In this scenario, an user application that communicates with an ATM API without involving RSVP, interworks with an application that uses RSVP to signal its resource requirements. The Integration Unit is now the terminating entity for the ATM signalling and the originating entity for RSVP Path messages or vice versa:

Integration Unit

Integration Layer IP Network ATM Network with UNI RSVP RSVP Routers

UNI4.0 Hosts RSVP Hosts

The investigation of this ´peering` scenario has highlighted issues related to the correct sequence of handling the ATM and RSVP signalling messages, since ATM-initiated paths have to be taken into account. The mapping of the ATM address (contained in the incoming SETUP message) to the IP address information that the ATM signalling daemon requires, is problematic. Furthermore, if user plane mapping (e.g. from AAL5 to UDP) takes place, such information has to be obtained or statically configured and stored in the kernel. Nevertheless, DIANA will make a demonstration of this scenario, using the IP-based VAT application.

3.1.2.4 MPLS in a Multicast environment The multicast enhancement within the IthACI project aims to apply MPLS-style shortcut techniques to IP multicast, in order to optimise the network without any modification to the end-user environment or

37 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 to existing IP multicast protocols. The shortcut point-to-multipoint ATM connections will follow dynamically the tree topology changes that are the result of IP hosts joining or leaving the group.

Currently, several multicast routing protocols are being implemented and standardised (DVMRP, PIM- SM, PIM-DM, MOSPF, CBT, …). These protocols expose different tree set-up and maintenance characteristics, which result in some Multicast Routing Protocols combining better with IP Switching than others: e.g. Flood&Prune protocols (DVMRP, PIM-DM, …) will create highly dynamic L2 trees, resulting in much label advertisement signalling and label consumption. Also, some multicast routing protocols (e.g. PIM-SM, CBT) allow to use a shared tree for all sources which leads to less label consumption, but to potential merging problems.

IthACI is deploying PIM-SM as the multicast routing protocol. Three label advertisement methods (IPSOFACTO: implicit, tag switching: piggy-backing; Yalsa: dedicated protocol) are represented in 3 different testbeds. A dedicated protocol (e.g. LDP) has the disadvantage that it needs to be developed from scratch. Label advertisements piggy-backed onto PIM Join/Prune messages (Tag Switching) have several disadvantages: The periodicity of the messages creates more signalling than required, only ´downstream` mode is possible, the deployment of each new multicast routing protocol demands adaptations to allow piggy-backing, the method cannot be used for Flood&Prune protocols and finally, it limits the scope of the MPLS domain in mixed (LSR and non-LSR) multi-access networks.

Besides the correct interworking of IP multicast and IP switching in the separate testbeds, the goal of IthACI is to demonstrate the interoperability between Alcatel’s, NEC’s and CISCO’s multicast solutions, either on layer 2 or layer 3.

3.1.2.5 Mobile IP Driven by new wireless systems and services, the market for mobile terminals is growing rapidly. Considering that the mobility concept appeared only recently, the current version of IP does not include mechanisms for its management. Mobile IPv4 has now been introduced mainly to solve the mobile host problem (actually, the ´nomadic` host problem) where a host needs to retain its IP address to retain TCP connectivity, whilst roaming.

Two main schemes are possible to make the multicast service available to a mobile node. While away from home, a mobile node may be allowed to exercise its role either as if it was a logical entity in the home network or a logical entity in its current foreign network. In the first scheme, a ´Home Agent` acts as the logical point of the service. In the second scheme, the mobile node has to use a temporary co- located ´care-of` address to fulfil its role in multicast scenarios.

In the unicast case, mobile IP relies on protocol tunnelling to deliver packets to mobile nodes that are away from their home network. The mobile node's home address is hidden from routers along the path from the home agent to the mobile node due to the presence of the tunnel. The encapsulating packet is destined to the mobile node's ´care-of` address – a topologically significant address – to which standard IP routing mechanisms can deliver packets. The above first scheme for the multicast case is a natural extension to the unicast case and it maintains the semantics of multicast. The first scheme also has several other advantages over the second scheme and it is therefore favoured for further consideration and implementation.

Because of security concerns, the assumption of routing based exclusively on the destination address in the datagram header of an IP packet can no longer be made. Network ingress filtering based on the source address of IP packets is increasingly being used by routers according to [RFC 2267] in order to avoid security breaches. This requires that the source and destination address in a packet must be topologically correct, i.e. they must be properly assigned with respect to their locations.

More specifically, the set of RFCs [RFC2002 – RFC2006] which specifies the current version of mobile IPv4 and some related Internet drafts such as [draft-ietf-mobileip-tunnel-reverse-05.txt] will be used by IthACI as appropriate.

The COIAS project will also implement the new mobile IPv6 specification, to analyse the performance of this protocol and to propose a solution for providing secure mobile accesses.

3.1.2.6 Int Serv and Diff Serv in a shared media HFC environment Modern IP-based applications have an increasing demand for reliable Internet connections with a guaranteed QoS. An intelligent resource management scheme is required to guarantee end-to-end QoS.

The AROMA project is determining how Internet-related QoS, as provided by the RSVP and DiffServ mechanisms, can be introduced into an ATM-based HFC environment. Most important for QoS in the HFC network segment is the successful mapping of the Internet QoS requirements to a suitable ATM traffic contract. It is in the responsibility of the ATM system to provide contract conformant ATM connections, by using appropriate media access priority schemes.

It has been discovered that the DiffServ model is similar to the QoS architecture of the AROMA HFC network, consisting of various queues with distinct QoS characteristics. Taking into account the tendency of the market to move towards DiffServ, this method is currently being implemented in the AROMA project. It is expected that the AROMA HFC network will then be able to provide IP QoS that is interoperable with the core Internet and is efficiently mapped to the corresponding hardware resources and mechanisms of the HFC network nodes.

3.1.2.7 Alternate path routing Modern networks must optimise the management of communication among nodes that are interconnected by diverse routes. An increasing number of alternate paths are becoming available, with various qualities in terms of (for example) delay, throughput and security. This allows for selecting routes in accordance with the required QoS and price.

COIAS provides a testbed comprising satellites and terrestrial ATM links to demonstrate the importance of intelligent path selection. The convergence of diverse communication technologies based on different underlying technologies introduces in the same environment quite different links. These can be characterised in terms of bandwidth, latency, security, and uni- or bi-directionality. The management of these links (both individually, and in the framework of the network as a whole) is difficult; alternate path routing must not obstruct dynamic routing fault tolerance, and must respect a number of policies related to performance, reliability, availability, security, etc.

In the demonstration of COIAS, users will employ meta-information to mark their packets or flows with their needs for bandwidth, latency, security and reliability. This meta-information will help the system to classify the packets, and make an intelligent path selection. By doing this, the packets will be routed using the optimum path.

COIAS will integrate diverse technologies over IP and will provide the mechanisms required to allow network nodes to perform alternate path selection. The mechanisms for routing, reliable multicast, authentication and network interconnection can be performed on several levels. Since the mechanisms interact, it is necessary to make compromises in optimising the route. In particular, the project will resolve these issues for heterogeneous network scenarios involving Internet, ATM and satellite and enable the various infrastructures to be used correctly by the applications.

3.1.2.8 Multicast Intrinsically, satellite broadcast communication channels offer a natural way of multicasting data over a large geographical region. Using such links, one can benefit from an environment where adding thousands of new recipients does not cost anything in terms of network resources. There are many potential applications, such as software distribution, database updates, information broadcast (weather forecast, financial data, TV, ...).

However, some constraints are associated with satellite links:  For geo-synchronous satellites, transport protocols must be able to cope with the propagation delay. Long delays lead to a poor system reactivity and, when combined with link asymmetry, or even uni-directionality, feedback from receivers may be quite difficult to be implemented efficiently.  Satellite links, as all other wireless links, may be susceptible to a high Bit Error Rate. This can be reduced to a rate comparable to that of wired-links by adding link-level bit redundancy, but this reduces the useful throughput of the link.  It is likely that some of the recipients will receive the data directly from the satellite link, whilst others receive it relayed by an antenna through a terrestrial path. This introduces a heterogeneity of paths to the end-users in terms of bandwidth and error rate.

The problem is therefore to deal with a large and heterogeneous environment where feedback is quite inefficient and losses are not all due to congestion. The COIAS project aims to ensure reliable data transmission and optimised reception time for each end-user.

To match the constraints mentioned above, as well as scalability considerations, COIAS proposes a feedback-free mechanism, which means that the recipients do not acknowledge the data received. To ensure reliability, a Forward Error Correction (FEC) technique is implemented, whereby lost data can be recovered with redundancy packets. This technique avoids NACK implosion and has the possibility of correcting independent errors for different recipients with the same redundancy packet.

To deal with heterogeneous receiving rates, COIAS proposes a multi-layer approach, where receivers join and leave multicast groups to adapt their receiving rates. The data is interleaved to approximate optimal reception time, still enables late joins (i.e. gives users the opportunity to join a session that has already started), and is adapted to a good reactivity to congestion signals.

In the context of IPv6 the project BTI has introduced two main extensions for multicast into the router they are using:  PIMv6 multicast routing.  Integration of RSVP/IS with multicast.

IPv6 handles ATM as a special case of a class of subnet technologies designated as NBMA (Non Broadcast Multiple Access). These subnet technologies include beside ATM: Frame Relay, X.25, ISDN and POTS dial-up. The basic subnet technology is extended with multicast emulation. In the case of ATM this is done through a MARS (Multicast Address Resolution Service). This allows the direct use of the Neighbour Discovery protocol, including address resolution between IPv6 addresses and ATM addresses.

Multicast routing for the IPv6 router has been included through the implementation of the Protocol Independent Multicast-Sparse Mode (PIM-SM). The SM variant of PIM has been selected due to the scaling properties in a sparsely populated multicast domain, as the access network is the target of the BTI project.

The Protocol Independent Multicast-Sparse Mode (PIM-SM) architecture  maintains the traditional IP multicast service model of receiver-initiated membership,  uses explicit joins that propagate hop-by-hop from members’ directly connected routers toward the distribution tree,  builds a shared multicast distribution tree centred at a rendezvous point, and then builds sourcespecific trees for those sources whose data traffic warrants it,  is not dependent on a specific unicast routing protocol,  uses softstate mechanisms to adapt to underlying network conditions and group dynamics.

The RSVP and PIM implementation for the BTI router has been extended to cover IPv6 and reservations for multicast flows. PIM provides in this respect the multicast routing information to RSVP, i.e. when the set of output interfaces for a particular IP group is required to send out path messages for RSVP a local request is issued for the PIM router and, based on the response, Path messages are forwarded.

3.2 Next Generation Internet in Esprit and Telematics

Franck Boissiere, Jean-Pierre Euzen, European Commission DGXIII, Belgium

3.2.1 TEN 34 and QUANTUM The Telematics Applications Programme (TAP) and the Esprit Programme had a major initiative to improve network services for researchers in Europe, with particular emphasis on improved quality of service over IP networks, and trial of ATM based services.

In 1995 two major projects were launched: TEN-34 and JAMES (also in association with ACTS). TEN- 34 established the 34 Mbit/s backbone network connecting national research networks across Europe, offering an IP service, an order of better magnitude than the previous EuropaNET backbone. The JAMES project allowed researchers to obtain direct access to ATM based trials for specific experiments. Both projects were open to participants in Eastern and Central Europe.

TEN-34 was operational between February 1997 and December 1998.

The QUANTUM project follows on from the successful TEN-34 project. The main objective of the QUANTUM project is the implementation of an interconnect facility at 155 Mbit/s with access capacities up to 155 Mbit/s. The service, known as TEN-155, provides a stable IP service and a managed bandwidth service for specific user groups.

More and more co-operative development activities in Europe are based on the use of multi-media services, which are only feasible if they can rely on high Quality of Service levels which cannot be provided on a loaded ´best effort` IP network. Protocol enhancements such as RSVP, DiffServ and IPv6, as well as the Quality of Service management inherent in the ATM technology are addressing these issues. It is apparent that for multi-media services to develop on a pan-European scale a new approach to Quality of Service is required. An important element of the QUANTUM project is to trial the new protocols and technology developments both in a test and a wide area network environment with view to deploying them in the operational TEN-155 service at a later stage.

A consortium of 16 national research networks, one regional research network and DANTE as the co- ordinating partner are responsible for the organisation of the QUANTUM project. DANTE is a non-

41 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 profit company which plans, builds and manages the provision of pan-European Internet connectivity for the European research community. QUANTUM has recently been extended to Israel, through the Q-MED project.

The Quantum Test Programme (QTP) has the objective of testing and validating new technologies, products and services with a view to introducing them into the operational TEN-155 service at some future date. For that purpose a task force - TF-TANT (Testing of Advanced Networking Technologies) was set up as a joint activity between TERENA (Trans-European Research and Education Networking Association) and DANTE. The participation to TF-TANT is open to the entire European research community.

3.2.2 Projects toward NGI Besides the support for research infrastructure, Esprit and Telematics funded projects related to the development of next generation Internet technologies, notably the upper layer technologies with emphasis on distributed multi-site industrial applications. The stimulation of the take-up of technologies and application best-practices in the business and industrial sectors were also promoted.

Significant examples are:

ATRE, which is a TAP project using ATM services. This project is using an ATM platform to offer virtual presence for educational and training purposes, using IPv6.

EDISON (http://cec.to.alespazio.it/edison.html), a project that is developing a European infrastructure for distributed simulation framework which requires many of the new features being developed in the latest version of Internet protocols such as predictable and manageable quality of services. The areas of application are mainly for simulation in the automotive and aerospace sector.

ROXY (http://www.roxy.nu), which is developing the tools and services for the creation, delivery and presentation of interactive audio-visual multimedia information services. It is critically dependent upon the emergence of new Internet features such as a standardised support for multicasting and resource reservation capabilities.

3.3 The NGI Activities in COST-Telecommunication

Michel F. Roy, European Commission DG XIII, Belgium

International collaboration on research, particularly pre-competitive research, brings many advantages in key areas. It allows the concentration of the necessary resources and facilitates the development of consensus. COST that stands for ´Coopération européenne dans le domaine de la recherche scientifique et technique` has been a framework for European co-operation since its establishment in 1971. COST is an intergovernmental initiative, which co-ordinates, at the European level, scientific and technical effort carried out on a national level by its member states. The financing for the research is provided on a national level, while COST covers the co-ordination costs only. There are currently 28 Member States: The 15 members of the European Union, Iceland, Malta, Norway, Switzerland, Turkey and most Eastern Central European countries. Bulgaria, Cyprus, Latvia and Lithuania are currently observers.

The inherent flexibility and pre-competitive nature of the COST framework, falling somewhere between fundamental research and development work aimed at defining new products or methods, enables any group of scientists to propose a new Action on a research activity where they see a need to co- operate, with the Action operational once five COST countries have signed a Memorandum of Understanding.

This ´bottom-up` approach and the broad range of activities possible are among the attributes that distinguish COST. The mechanisms for co-operation and the methods of working are considered very productive by the research community. COST is also a way to initiate co-operative R&D, often as a nucleus for community research projects, and as such offers a strong synergy and complementarity with the Framework Programmes, in particular the ACTS Programme, and the new IST Programme.

Research on the next generation of Internet technologies is therefore a natural arena for researchers interested in COST-Telecommunication (http://www.cordis.lu/cost/src/telecom.htm), the COST domain related to the Information Society Technologies.

Architectures, technologies, protocols and applications from the computer connectivity industry will have a predominant influence on the future telecommunication networks, its operators, the equipment manufacturers and the customers. The Internet network, the pervasiveness of its technologies, and its new developments are key components of this evolution. Currently two new COST Actions will help co-ordinate the work performed to achieve the development of these new technologies. One foresees the Internet related topic to become more prominent in the COST-Telecommunication framework while keeping a stronger synergy with the future projects of the IST Programme.

The COST Action 263,´QoIS: Quality of Future Internet Services`, will deal with the evolution of the Internet technologies to be able to offer Quality of Services to the applications. Focus is on the next generation protocols, the interoperability with sublayers like ATM, charging and the QoS issues specific to the Internet, notably the multicast routing in Internet and real-time and reliable applications.

The COST Action 264 ´Enabling Networked Multimedia Group Communication` will enable the co-operation of European scientists involved in the design of the architecture and applications related to group communication. Results of the work will be made available to the participants in the Action as well as to the industry. Also, contributions will be sent to standardization bodies. Another primary goal of the Action will be to experiment solutions and applications on a MBone type of network and provide recommendations on how such a network can be enhanced.

3.3.1 COST 263 - Quality of Future Internet Services

Michael Smirnov, GMD Fokus, Germany

´The Internet has met its enemy and its name is QoS`7

Introduction, Background and Motivation The Internet is diverse by its nature. The IETF - Internet Engineering Task Force - has currently in its 5 areas more than 100 short-lived working groups standardising well focused issues of Internet engineering. However, it is not easy to contribute to the IETF workflow: the input should arrive in needed time (say, when addressed mechanism is still under construction) and fit well the previous output of the working group. The IETF lacks inter-group and inter-area co-ordination: the work reported to one working group is to be repeated in another relevant one. The issues of Quality of Internet Services for example are addressed in about a dozen IETF working groups! On the contrary, COST provides a framework for the long-term, easy-to-join co-ordination - the two key issues with regard to the Quality of Internet Services.

While the long-term feature of the Action permits thorough planning of its co-ordination activities, the essence of the topic requires that the COST 263 outcomes is visible in the short- and middle-term scale. These outcomes, in a form of recommendations, guidelines, technical specifications, evaluation of proposed standards, studies of impact and acceptability, testing and measurement results, trial and implementation reports, together with the proceedings of the Actions' workshops and conferences, will be made available to all participants. The Action will perform its co-ordinating role not only via continuous aggregation, filtering, evaluation and dissemination of the above, but also via the synergy of efforts, accumulation of relevant information and establishment of links between research groups.

The Scope The following is a summary of a complete Technical Background found in the memorandum of Understanding for COST 263 (http://www.fokus.gmd.de/cost263/start/):

1. The Internet was designed for data traffic, its protocols were optimised for the transmission of discrete objects. However, modern workstations and PCs are already multimedia machines, thus it is very desirable to enable those machines to exchange multimedia data streams over the network.

7 B. Carpenter, J. Crowcroft, ´Prospects for Internet Technology`, CERN-CN/96/18, p. 5.

2. It is expected that most of the bandwidth in future high-performance networks will be used up by multimedia applications, providing the whole set of QoS requirements. Current projects in the Internet community are only first steps; similarly, current ATM technology is still far away from the necessary functionality. 3. The emerging service requiring the QoS is reliable multicast delivery for large groups, needed for applications that follow the dissemination model such as news on demand, distribution of stock market or weather information, electronic journals, distribution of educational material or distribution of software. 4. The need to assure the QoS comes also from supranet services, heavily demanded by the high technology European industry ever more relying on the collaborative nature of contemporary businesses. A supranet idea is allowing any user to set up and manage a virtual network for a group via a service consisting of software tools and available to everybody. 5. The World Wide Web caching and contents replication in the Internet using reliable multicast aims at efficient distribution of the information closer to the end user which is a way to handle, master and, finally, cope with the explosive growth of the Internet usage in order to improve the response times, and to support the introduction of new types of applications. 6. Convergence and integration of IP/ATM Internetworks as well as migration of Internet applications to a Gigabit rates require research in the directions of network technology enhancements coupled together with application development, and, being more business oriented, consequent services development. 7. The Internet support becomes vital for DPE - Distributed Processing Environments vendors and provides the strong demand for the IP telecommunication service combined with the multicast capabilities and QoS guarantees and, therefore, charged appropriately. 8. QoS combined with the Internet means nothing without pricing – this COST Action really wants to include this, and to sponsor as much in the area of usage/QoS related pricing and differentiated services, and also try to get good consensus on authentication and privacy as part of the pricing/QoS architectural concerns. 9. No longer the Internet could keep the best-effort as the only service and convergence with the ATM technology is the best focus to address the QoS issue for the IP services, including IP multicast and Internet Integrated Services over ATM.

Draft Technical Programme The Technical Programme includes the following activities.

C.1.1 QoS Enhancements for the Internet protocol stack These activities will address: QoS Enhancements for the Internet Protocol Stack; Supranet services in IP/ATM networks with QoS; Protocol engineering; Performance Modeling and Analysis of TCP/IP suite protocols, of statistical multiplexing, connection admission control, End-to-end guarantees for multimedia applications; Reliability performance of RSVP; QoS requirements of continuous media- data; agent based reservations and routing; specifying quality framework and quality indicators, IP- ATM QoS signalling issues. C.1.2 QoS in Multicast The Action will study the following questions: Protocol design for multipoint communication; Congestion and flow control for multipoint communication; Use of multipoint communication to improve latency in Web caches. Interaction of pricing and accounting databases with monitoring and policing of differentiated services IP for unicast, multicast and mobile IP, in a SCALABLE manner. Router and Interworking Issues of QoS in Multicast. QoS negotiations and estimation. IP multicast over ATM with

44 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 the QoS guarantees. QoS routing in multicast. Protocol mechanisms for fully reliable group communication. Convergence and integration with ATM.

C.1.3 QoS in Next Generation protocols The Action will study the following questions: Signalling and scheduling in RSVP, IntServ and DiffServ, IPv6. ToS (type of service) and QoS (quality of service) in a future Internet. QoS in Next Generation Protocols: IP switching and next generation protocols. Measurements of the QoS in the Enhanced and Next Generation Internet Protocols. QoS and Robustness in Internet. Bringing intelligence to the end- user, mobile agents, Java-based environment for service creation and distribution of service components in broadband and mobile network.

C.1.4 QoS in Applications This task will address: Study of security requirements of numerous emerging applications which place real-time restrictions. QoS through adaptation and reservation in applications. QoS issues in CORBA (DPE) extensions to support enhanced Internet services. Reliable multimedia services.

C.1.5 Charging for the QoS This activity will perform the following: Study of IETF activities on signalling and scheduling and pricing in RSVP, IntServ and DiffServ as well as other WGs. Charging for IP over ATM networks and for supranet services. Cost allocation and pricing. Protocol mechanisms for usage-based charging and accounting of IP Integrated Services and IP Differentiated Services.

3.3.2 COST 264 - Enabling Networked Multimedia Group Communication8

Serge Fdida, Université de Paris VI - LIP6, France

A) Background The work carried out within various projects including COST Action 2379 (Multimedia Telecommunications Services) has demonstrated the importance of multimedia group communication for enabling high-performance networking and new emerging applications. One can mention multiparty conferencing, Internet telephony, collaborative work or distributed interactive simulation. They are characterised by interactivity, real-time constraints, and a various number of participants. Obviously, all these applications require multi-peer functionalities that are not currently available as a basic service. It has been recognised that providing both multi-peer capabilities as well as quality of service in various forms is not achieved, no matter what technology is considered, i.e.: ATM, IP, mobile networks, satellites, etc. Moreover, it was shown that there is a lack of practical understanding and experience in this area, mainly because no experimental network is available in Europe. The only existing infrastructure is the experimental MBone (overlay multicast network on the Internet); but it is not satisfactory as it does not provide any transmission control facility (congestion/flow control, reliability, Quality of Service, group and address management, etc.). Nowadays, there exists an increasing demand and a large potential market for multimedia multi-peer applications that justify the development of an efficient European multicast network infrastructure.

B) Objectives and Benefits By building on the COST Action 237 results the Action brings together European research teams involved in group communication from the infrastructure and application perspective. They will co- operate in order to identify solutions for the improvement of the multi-peer communication architecture, including application, communication mechanisms, and infrastructure. Complementary experiments will be conducted to enable and understand multimedia group communications that will be available on various networks in the future. These activities will contribute to leverage European research in this domain as well as to the development of enhanced architectures on the international level.

This area is becoming of utmost strategic importance from the research and industrial perspective. An incredible amount of work is done in this domain in the USA and Japan. Some work is also visible in Europe but with a lack of co-ordination and dissemination of results to the academic and industrial world.

8 www.lip6.fr/COST264

9 http://www-run.montefiore.ulg.ac.be/projects/COST237.html

The Action is divided into two complementary parts of similar importance, that together will enable the Action to meet its goals:  Infrastructure and dissemination.  Research and experimentation.

The ´infrastructure and dissemination` part aims at co-operation and co-ordination between research actors to improve the existing infrastructure to support group communication (principally the MBone). The infrastructure activity is a pre-requisite to the scientific co-operation. It will allow experimentation with the applications and mechanisms developed by participants, as well as providing a way to support an effective dissemination of the work. This activity will:  Create a multicast group on the MBone (named the ´Costbone`) dedicated to this Action and to the European networking research community.  Co-ordinate work to improve the infrastructure based on the participant’s contribution.  Define and support an homogeneous environment in the sites connected on the Costbone to fulfill the requirements for distributed experimentation.  Disseminate the Action activity through Euro-seminars and other forms (multiparty conferencing, telephony, collaborative work, etc.).

The ´research and experimentation` part is devoted to co-operation between participants in the areas of multicast, multi-peer, group communication and relevant applications. This is an area of utmost and strategic importance for research and industry. Multimedia group communication will leverage industry competition and provide new tools for co-operative work. This Activity will:  Bring together European teams already involved in the area of group communication to discuss research activities, identify key issues and potential solutions, and therefore benefit from cross- fertilization.  Invite people from industry to whom these technologies will be very important in the near future, to describe their needs and expectations.  Evaluate the work carried out in the different standardization or project bodies and provide feedback as users and researchers to the standardization groups (in particular to IETF).  Discuss solutions through meetings (including electronic meetings over the Costbone).  Experiment new multi-peer transmission control algorithms and mechanisms designed by the Action’s participants. Evaluate experimentally the proposed solutions on the available infrastructure (the Costbone).  Provide a framework for the exchange of research scientists and students in order to improve the level of collaboration between research groups.

Both activities are complementary and tightly coupled. The ´research and experimentation`activity will explore the multi-point communication paradigm and provide the relevant inputs to the ´infrastructure and dissemination` activity. This will enable a clear understanding of the requirements on the Costbone as well as how it can be enhanced.

On the other hand, the utilisation of the Costbone as defined by the ´infrastructure and dissemination` activity will provide a strong feedback on the research part according to the observations collected through experimentation. This process is continuous and a tightly coupled liaison will be maintained between both activities.

Benefits, as described above, will be an understanding of the issues to enable group communication that appears as a challenging research area as well as an emerging market. It will organise the research community involved in these areas and disseminate the results outside the Action participants (academic and industry). Finally, the Action should have an influence on the standardisation activities in this domain. Recommendations on how to use the results achieved in the Action and solutions to enhance the MBone will be provided.

According to the issues mentioned above, the Action will deliver and emphasise on the following results:  Manage and experiment distributed multimedia applications,  Dissemination through Euro-seminars,  Design new solutions (algorithms and mechanisms) for multi-peer communication,  Report Action results to major standardization bodies,  Deliver a final report published as a book or as a special issue of a technical journal,

 Identify solutions to enhance the MBone infrastructure.

C) Technical Program The Action will enable a strong and permanent co-operation and co-ordination between the actors from different perspectives, mainly technical but also through experimentation that is of utmost importance when group communication is involved. The Action goals are on one hand to identify the problems encountered with group communication (and propose solutions to these problems), and on the other hand to make a ´well-behaved` multicast backbone become true to support experiments, allow fast and easy dissemination of results and support tele-collaboration.

C1 Research and Experimentation Group communication is recognized as a new paradigm that requires a deep modification of the networking functions, mechanisms and protocols designed with only “ unicast ” communication in mind. The Action participants are already involved in this research. The following are currently addressed:

Naming and Addressing In the current Internet, multicast address allocation is done on a random basis. With group communication becoming popular, and applications using more than one group per session, it becomes urgent to define hierarchical address allocation schemes together with a unified naming strategy. Both will improve error control and congestion control by providing a simple and efficient way to select multicast addresses and to identify objects within a data flow.

Error Control Today, there are three main approaches to error control in multicast: local recovery, hierarchical recovery, and FEC. These three approaches are nowadays deployed in many different experimental protocols, but their specific advantages and disadvantages are not well understood. These protocols have to be tested on a real platform to be qualified regarding application characteristics and network dynamics.

Congestion Control Congestion control for multicast is an unsolved problem. There are two approaches to multicast congestion control: Rate based control (such as in TCP slow-start) and application based control (with techniques such as layered multicast or media-scaling). Congestion control is being studied in the Internet community as one of the compulsory mechanisms to enable the wide deployment of multicast.

Scalability: Group Management Having all the participants of a session in the same group is neither scalable, nor useful. The scalability problem is obvious. At the same time, each participant does not need to receive all information coming from all other participants. He will be mostly concerned by his neighbours, by his allied, by people with the same communication medium, etc. This will allow to subdivide the group of participants in sub-groups with different constraints and attributes. Solutions are required to target very large group communication systems such as the one encountered in applications like distributed games, distributed interactive simulation, large scale document dissemination, etc. The dynamic of the group activity as well as the management of the group properties and semantic relationships between users will be addressed.

Multicast QoS Capable Architectures The ability to support multi-peer Quality of Service (QoS) will be studied for various technologies available today or in the near future such as IP, ATM, mobile networks, satellite networks or any kind of heterogeneous technology. The mechanisms mentioned above will be considered from the perspective of efficiency, network support or signalling. The different technical issues described above are the foundation for the design of a multi-peer communication infrastructure. Research work in this area requires a close co-operation of involved research groups in order to be efficient and converge to a coherent solution.

C 2 Infrastructure and dissemination The target of this activity is to identify how to improve the existing infrastructure (mainly the MBone) as well as provide the support for distributed multimedia experiments and Action dissemination:

Contributing to the improvement of the infrastructure

The infrastructure is mandatory for the Action to settle a continuous efficient and active co-operation between the participants. It will also add to the international credibility of the Action, in particular in the Internet community (IRTF and IETF). Improving the infrastructure will allow research groups to experiment with their work in a wide-area network, with the support of other European researchers.

The goal of this activity is to allow participants to share their experience in local or MBone environments and provide recommendations and understanding to the deployment of an efficient infrastructure.

The Action participants are already active in the research area of group communication. However, anytime they want to experiment with their algorithms and protocols, they face the problem of the lack of a robust experimental network infrastructure. They also face the absence of feedback from other research groups. This activity will have a direct influence on the importance and on the credibility of the Action contributions. It will also allow the Action to contribute, at the highest scientific level, in a domain where the USA have dominated for many years.

Dissemination of information Information dissemination is a key factor for efficient co-operation in research. Solutions such as multiparty conferencing, telephony, and CSCW (Co-operative Support for Collaborative Work), will be made available through the Costbone. It will allow all European countries to profit and/or to participate at their own technology level: as simple participants or as researchers. Moreover, design, test, and distribution of new multicast multimedia applications will be done through the entire Action life. The results of the Action will be made available to a large extend, to industry and research actors.

4. Projects and Trials in Acts

The previous chapter gave an overview of some technical approaches and experimental issues in the area of Next Generation Internet within the R&D Programmes of the European Commission. This chapter now gives a sample of several important ACTS projects working in this area, presenting for each of them the project goals, key issues, ongoing activities, and trial results. The following projects are covered:  AROMA: Advanced Resource Management in Service Integrated and Multi-layered HFC Access Networks  BTI: Broadband Trial Integration  COIAS: COnvergence Internet ATM Satellite  DIANA: Demonstration of IP and ATM Interworking for Real-time Applications  ELISA: European Experiment on the Linkage between Internet Integrated Services and ATM  IthACI: Internet-ATM Experiments for Convergence and Integration  MULTICUBE: Efficient Multipoint to Multipoint Broadband Switched Network Services for Distributed Multimedia Applications  PeterPan: Provision of an Enhanced Transport by Exploiting Reservation in IP and ATM Networks  SUSIE: Charging for Premium IP Services in the European Information Infrastructures and Services Pilots

A complete list of contacts for these projects is included in the Annex. Information on all other ACTS projects is available online at http://www.infowin.org/ACTS/PROJECTS/

4.1 AROMA - Advanced Resource Management in Service Integrated and Multilayered HFC Access Networks 4.1.1 Introduction Currently there are two possibilities to achieve the required Quality of Service (QoS) for modern communication tasks: Adding QoS sensitive support to the Internet protocols for enhancing legacy TCP/IP applications and defining native ATM architectural solutions in new applications.

The AROMA project will demonstrate how intelligent resource management can provide end-to-end QoS in a heterogeneous network environment consisting of a Hybrid Fibre-Coax (HFC) access network as a shared medium, a SDH/ATM core network with ATM signalling and Internet support

48 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 including differentiated services (DiffServ). The main issue in the project is the smooth end-to-end operation of IP based applications and native ATM applications using different types of protocols to guarantee QoS.

Fig. 1: Architecture of the HFC system used by the AROMA project

4.1.2 System Overview Within the framework of the ACTS project ATHOC (ATM Applications on Hybrid Optical Fibre Coax) cable modems and HFC systems have been realised. The system architecture of the ATHOC equipment, which will be used by AROMA, is shown in figure 1. The Access Network Adapter (ANA) converts the SDH physical layer format of the backbone to the 64-QAM and QPSK physical layer formats of the HFC network, and vice versa. For the user traffic, the ATM connections are not terminated in the Access Network Adapter. The latter performs the ATM demultiplexing (or multiplexing in the other direction) in order to map the high capacity of the SDH-link into several lower rate HFC cable modem channels of about 34 Mb/s downstream and 9 Mb/s upstream. Similarly, the modem (ANT) provides the physical layer conversion between the HFC network and the subscriber premises network. The modem is connected to the user terminal (e.g. PC) via the 25.6 Mbit/s ATM Forum interface.

The implemented HFC system delivers ATM connections up to the user's end-terminal, meaning that ATM user traffic is not terminated in the modem. VPI/VCI filtering in the modem passes only the ATM connections directed to the specific user behind this modem, which provides inherent rate adaptation to the lower rate 25.6 Mbit/s ATM Forum interface. The ATM end-to-end connectivity guarantees bandwidth flexibility, service independence, and support for many different higher layer protocols on top of the ATM layer such as TCP/IP and others.

On the HFC network, several interactive broadband channels can be frequency multiplexed with the existing TV distribution channels. The downstream frame is compliant with the current DVB specifications. Grants for TDMA access are transported in ATM cells - called ´Grant cells` - with a uniquely specified header. However, this is in line with the emerging IEEE802.14 specifications. The upstream frame is one ATM cell with 4 bytes preamble for burst synchronisation, and 4 bytes FEC.

4.1.3 ATM Signalling over HFC In an ATM based HFC access network, multiple end user ATM terminals are connected via a common physical media to an ATM switch. Each terminal must be able to establish switched connections to a server or another terminal by using the primitives of the Q.2931 protocol. As all terminals are sharing a single ATM Switch port, there must be a way to distinguish the signalling flows of each terminal.

This is done by setting up virtual UNIs to support multiple signalling channels (implies multiple users) on a single UNI. Each end user (ANT) has one or more VPC(s). Within the user individual VPC, signalling messages are transferred on a dedicated signalling channel. The ATM switch identifies the signalling messages from different users looking at the different VPCs.

Set-up and release of VCCs have influence on the occupied allocation of HFC resources. An Access Control Unit (ACU) is responsible for managing the HFC resources. As a consequence the ACU has to view all signalling messages to be able to take appropriate HFC activities. Therefore, all signalling channels are transferred from the end users via the ACU to the ATM switch (fig. 2). The ACU proxy signalling agent receives all signalling messages and behaves towards the ATM switch as user side UNI and towards the terminals as network side UNI. Furthermore, the proxy signalling agent stores for each connection the connection status in a finite state machine (FSM). In case of signalling messages, which change the occupied HFC resources, the HFC resource manager is asked for accepting or simply for information. A c c e s s C o n t r o l U n i t A c c e s s N e t w o r k T e r m . A T M S w i t c h A d a p t a t i o n

n n A T M C o r e A c c e s s D i s t r i b u t i o n N e t w o r k N e t w o r k S i g n a l l i n g C h a n n e l s

S V C C s S w i t c h P o r t T e r m .

Fig. 2: Logical diagram of the signalling channels and ACU

4.1.4 Integration IP/ATM A smooth integration of IP and ATM has two major challenges, the provision of QoS and a homogeneous network management.

The AROMA network is build up by devices distributed in the HFC network and by ATM switches and IP routers distributed in the SDH/ATM network. The management system requirements are monitoring, configuring and generation of diagnostic messages. There are two dominant management protocols, the Internet’s Simple Network Management Protocol (SNMP) and OSI’s Common Management Information Protocol (CMIP), with management interactions of different ranges of complexity. In both protocols data is collected from agents located on the devices and analysed centrally on the manager. They suffer from bottlenecks at the manager, large processing requirements for the management platform and excessive network traffic between the manager and the numerous agents, involving many unnecessary transmissions.

With the objective to provide a new approach to the area of network management new concepts like Mobile Agents have been studied. Current network management systems are based on centralised intelligence. The central management application query the management information located in numerous distributed network elements (i.e. managed systems) by means of an appropriate management protocol via a communication network. The use of Mobile Agents provides new opportunities for the distribution of processing and control in network management.

Mobile code is a computer program written in some particular language, which travels through the network and is executed in some or all the nodes it crosses. A practical example of the concept is the well-known Java applet. Java applets are computer programs, that being sent from some Web server, are received by clients (Web browsers) and executed by them.

Unlike the simple concept of mobile code, as found in Java applets, Mobile Agents integrate code to be executed at destinations, data and non-transient states of the system, that all move as an unique entity autonomously through the network. The information is present in the agent but depending on its current location does not move with the agent. Compared with mobile objects, Mobile Agents have the additional responsibility of representing some entity when facing other network elements, being capable to execute operations on their behalf.

The main conclusion of this study was that setting up a management environment based on the Mobile Agents concept requires special support from the network and agents must establish a close contact with managed resources, which in the case of AROMA would not be possible.

4.1.5 Native ATM API The existing native ATM APIs, e.g. WinSock 2 and X/Open Transport Interface (XTI) provide basic ATM services, as the dynamic establishment and tear down of ATM connections and the allocation of bandwidth needed by an application. But none of the mentioned APIs can access management plane

50 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 functions. And they all run under only one operating system, except the Java native ATM API. Unfortunately the Java based API has other drawbacks.

These problems were solved by specifying a new API, extending the capabilities of the existing APIs. The new specified native ATM API has the following advantages:  The new API is the same for all operating systems. This allows the implementation of platform independent access to native ATM.  Management plane functionality is not included in current native ATM APIs. The new API will provide simple management primitives.  The implementation is simple. For the control and data planes the primitives can be mapped directly to WinSock 2 for PCs or to the X/Open Transport Interface for Unix. Only the management primitives must be implemented.  The new native ATM API is easier to use than the generic APIs WinSock 2 and XTI. It is suited for native ATM networking.  The new API is easier to implement on platforms where no ATM API exists (embedded systems, set-top-box).

The first implementation of the native ATM API will be done for the Windows-PC platform. In fig. 3 the architecture of this native ATM API is shown. The gray boxes depict the parts that will have to be implemented. In order to use the primitives which are provided by WinSock 2 the control and user planes are built on top of WinSock 2. There are no interfaces for the management plane primitives. Lower layer hardware drivers must be used. With the management plane primitives, defined by the ATM Forum, loopback tests can be set up. Errors and alarms from the lower protocol layers can be indicated. And finally management variables can be set and queried by the application.

A p p l i c a t i o n

N a t i v e A T M A P I

C o n t r o l P l a n e U s e r P l a n e M a n a g e m e n t W i n S o c k 2 A P I P l a n e

W i n S o c k 2

W i n S o c k 2 S P I

T r a n s p o r t S e r v i c e P r o v i d e r H a r d w a r e D r i v e r

Fig. 3: Architecture of the Native ATM API

4.1.6 Dynamic MAC Layer The focus of the AROMA MAC layer is the dynamic support of a mix of four service classes covering all present and future service characteristics ranging from delay-sensitive CBR and real-time VBR traffic to plain best-effort traffic. To this end the supported services are divided into 4 classes according to their QoS requirements and an appropriate access mechanism is provided for each class. The ANT (cable modem) is equipped with four distinct logical queues featuring four priority levels. The MAC controller residing in the ANA module in the head-end contains corresponding permit allocation mechanisms which distribute the bandwidth while arbitrating the medium access by specifying which ANT will fill each upstream slot. Each application will map its connections to an appropriate class (and corresponding queue) by means of the VC value. The cable modem will inspect the VC and place the cell to its proper queue. Each mechanism follows a different service policy according to the traffic characteristics of each supported class. The cells from each queue are given access permits originating from the corresponding permit allocation mechanism.

The main innovation in the permit allocation mechanisms is the incorporation of a credit mechanism in addition to the bandwidth distribution algorithm. The credits can be used as a policing tool to check violations of the peak rate or as a tool to make sure that each connection gets a minimum rate or a guaranteed rate.

The credit allocation is based on call acceptance or subscription criteria. It is used to add additional support characteristics that are necessary to make the HFC system capable of offering QoS guarantees without the inefficiency of peak rate based permit allocation.

The first priority is used for delay-sensitive CBR traffic which still uses pre-arbitrated permits which have been pre-programmed by the embedded controller. This programming is updated with every connection set-up and tear-down.

The second priority is devoted to VBR traffic which has a pre-allocated permit rate corresponding to its sustainable cell rate and a variable part which covers the traffic fluctuations by permit reservations. The credit allocation corresponds to its peak rate which results in connection policing since MAC permits are denied when the credits corresponding to the peak cell rate have been exhausted. Thus the QoS of concurrent connections is protected.

The third priority is devoted to ABR and/or GFR traffic and uses the credit mechanism to make sure that in the first case the agreed minimum has been provided and that in the latter case the guaranteed rate is available.

Best-effort based services are accommodated as the last priority traffic serviced in a round robin fashion guaranteeing fairness among all competing cable modems which can thus share the rest of the bandwidth available on the system.

In this way the MAC protocol of AROMA is designed for a full coverage of presently known and future service classes It protects both the stringent class from disruption from the tolerant class and the tolerant class from misbehaviour from the stringent class. Misbehaviour of a low priority connection is not possible since it is in any case restricted to an equal share of the left-over bandwidth.

The MAC protocol will be implemented in hardware (using FPGAs) both in the head-end (ANA) and the cable modem (ANT).

4.1.7 Services and Applications Several applications are being implemented to verify and demonstrate the performance of the AROMA network.

In order to check the MAC protocol for guaranteed services (CBR, rt-VBR) a performance measurement system is under development. It uses the new native ATM API. The measurement system can determine delay, jitter and cell loss. In addition to common ATM measurements at the ANT the system will be able to perform end-to-end measurements which include all system components needed for native ATM transmissions between two ATM terminals. In order to collect information about the processing time of different layers in the native ATM protocol stack, the system will allow measurements on the ATM adaptation layer (AAL) and on the ATM layer.

The performance measurement system is a centrally controlled system with multiple traffic sources on different end systems. A number of traffic sources generate background traffic and traffic under test. For this purpose different traffic models, e.g. constant bit-rate, Poisson distribution and Markov modulated Poisson distribution are needed.

Based on the Harmonised Native ATM Application Programming Interface an application framework is under development. This framework provides components which facilitate the development of native ATM applications.

A telephony application will serve as a sample application using the application framework. It uses the recently defined AAL 2 to achieve low end-to-end delay and incorporates standard PCM speech coding, compatible with the existing Plain Old Telephony Service (POTS), as well as H.323 coding, compatible with the emerging Internet telephony. In a field trial a PBX with integrated ATM interface will be integrated in the demonstration of the telephony application.

Two other applications deal with video transmission. A video conferencing tool was developed and is currently enhanced to handle multipoint-to-multipoint sessions. In contrast to current ATM videoconferencing standards the multipoint-to-multipoint traffic will be handled in a decentralised way to avoid the availability problems of centralised systems. This will be done by using the multicast capabilities of ATM which are based on point-to-multipoint VCs. The second video application is an

ATM based Camera Environment (ACE). ACE is a real time system to remotely control cameras as well as to distribute the MPEG encoded video to multiple clients. This native ATM application presents high resolution images with true colour and a high number of frames per second. All manipulations that can be applied to a camera like panning and tilting, controlling zoom, focus (manually or automatic), and back light compensation are accessible form the remote client application. The system will be expanded with signalling and multicasting capabilities within the AROMA project. Therefore the clients can dynamically access the service and establish switched virtual connections (SVC) to the camera server. The video data will be distributed to the clients using the ATM multicast capability of the HFC system.

4.1.8 Conclusions Within the AROMA project new architectures, techniques, software and components are developed to demonstrate a solution for the smooth integration of ATM and the Internet in the so-called ´last mile`. This is very important for the acceptance of new applications. Due to the lack of suitable applications these are also developed within the AROMA project. Field trials will demonstrate the correct operation in various countries.

4.2 BTI – Broadband Trial Integration 4.2.1 Overview The objectives of the BTI project are to develop and evaluate an integrated IPv6 and switched ATM network concept including multicast capabilities with well defined QoS support of user controlled bandwidth and delay parameters. The project consists of two balanced developments in the areas of QoS capabilities of networks and QoS requirements of applications. The effect of network performance on the perception of the user with QoS control will be evaluated using educational applications adapted for the project.

4.2.1 Network Architecture and Implementation The BTI trial platforms are implemented in Portugal, Denmark and Poland and interconnected through Pan European ISDN and ATM connections. The trials are primarily build up around the access networks provided by the Broadbandloop (BBL) project. In addition to the BBL platform access networks will be used where appropriate i.e. ISDN, telephone modems and ADSL.

Within the BTI project the ATM PON is extended with a control plane in order to support signalling controlled set-up and release of virtual channels/connections (SVC’s). This control function will be used by an overlaying IP network to create QoS guaranteed IP services. The IP network will be established by multiprotocol routers that support IP version 6 and the RSVP signalling protocol.

The router equipment used for the BTI project will be the TBC2000, which provides a fully integrated multiprotocol router and ATM switch, supporting ATM access and switching, IPv6, IPv4, X.25, CLNP (ISO/IP), Frame Relay, FDDI, Token Ring, Ethernet, Fast Ethernet LANs concurrently in one unit. In the BTI context the TBC2000 will be applied as an edge router providing IPv6 service for the access network.

The network supported by the BTI project is a network with two networking layers. An IP layer that is used by the application to communicate with the routers and an ATM layer used by the IP routers and terminals to set up connections within the physical network. The individual BTI trial in Poland, Portugal and Denmark will be set up as an IPv6 LIS operating over an ATM sub net. User site equipment will in an IP perspective be considered as regular hosts. Characteristics of the classical model are (from [RFC2225] Classical IP and ARP over ATM):  The same maximum transmission unit (MTU) size is the default for all VCs in a LIS. However, on a VC-by-VC point to point basis, the MTU size may be negotiated during connection set-up using Path MTU Discovery to better suit the needs of the co-operating pair of IP members or the attributes of the communication path.  Default LLC/SNAP encapsulation of IP packets.  End-to-end IP routing architecture stays the same.  IP addresses are resolved to ATM addresses by use of an ATMARP service within the LIS – ATMARPs stay within the LIS. From a client’s perspective, the ATMARP architecture stays faithful to the basic ARP model.  One IP sub net is used for many hosts and routers. Each VC directly connects two IP members within the same LIS.

The mapping of IP addresses to ATM addresses for IPv6 is moved from being a part of a link layer convergence function (as the ARP protocol for Ethernet LAN’s, and the ATMARP function for IPv4 over ATM) to a common sub function for NBMA (Non Broadcast Multiple Access) link layer. The NBMA sub functions enhances the basic link layer technology with emulated multicast facilities through a MARS (Multicast Address Resolution Server). ATM is probably the main NBMA network technology but includes also Frame Relay, SMDS and X.25. The aim of the NBMA sub functions is to have the Neighbour Discovery protocol for IPv6 to be implemented commonly for all NBMA networks.

The requirements for IP members (hosts, routers) operating in an ATM LIS configuration are:  All members of the LIS have the same IPv6 network prefix.  All members within a LIS are directly connected to the ATM network.  All members of a LIS MUST have a mechanism for resolving IP addresses to ATM addresses via a MARS service.  All members within a LIS MUST be able to communicate via ATM with all other members in the same LIS, i.e., the Virtual Connection topology underlying the intercommunication among the members is fully meshed.

The IPv6 router will at each trial site provide MARS service for the LIS. If appropriate more LIS can be defined spanning a particular subset of terminal equipment.

The IETF’s Integrated Service framework provides the ability for applications to choose among multiple, controlled levels of delivery service. To support this capability, two things are required:  Individual network elements (subnets and IP routers) along the path followed by an application’s data packets must support mechanisms to control quality of service delivered to those packets.  A way to communicate the application’s requirements to network elements along the path and to convey QoS management information between network elements and the application must be provided.

In the Integrated Service (IntServ) framework the first function is provided by QoS control such as Controlled Load Service (CL) and Guaranteed Service (GS). This function will in the BTI context be established through mapping IP flows to dedicated ATM virtual connections. In the BTI context the second function will be provided through the resource reservation set-up protocol RSVP.

The traffic characteristics for both Controlled Load and Guaranteed Delay are announced by a Tspec and controlled through a token bucket. The Tspec contains 5 parameters, the bucket depth (b), the bucket rate (r), the peak rate (p), the minimum-policed unit (m), and a maximum data gram size (M). The values must be supplied by the sender and receiver of a specific flow. For the guaranteed service the receiver must additionally specify the Rspec which consists of a rate R and a slack term S used to signify the difference between the desired delay and the delay obtained by using a reservation level R.

4.2.2 QoS-aware IPv6 IPv6 Multicast Two main extensions to the TBC2000 router used by BTI have been specified and implemented:  PIMv6 multicast routing  Integration of RSVP/IS with multicast

Further details of this implementation are described in section 3.1.2.8.

Integrated Service Architecture in an ATM Environment The IP services considered are Controlled Load Service (CL) and Guaranteed Service (GS). The default Best Effort Service (BE) is also considered in parallel with these. These services are considered for both IPv4 and IPv6. RSVP is used as the IP-level QoS signalling protocol for IP-level resource reservation. RSVP Extensions for IPv6 Flow Label Support are discussed.

For the interfacing to the BTI ATM networks, ATM Forum UNI Signalling, version 4.0 will be used. ATM UNI signalling version 3.1 is also considered for backward compatibility. The former uses the more complete service model of the ATM Forum's TM 4.0 specification. ATM provides both point-to- point and point-to-multipoint Virtual Circuits (VCs) with a specified Quality of Service (QoS). Furthermore ATM provides both Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs). Only SVCs are used to support RSVP over ATM. Both point-to-point and point-to-multipoint SVCs are considered.

The ATM services in TM/UNI 4.0 are:  CBR Constant Bit Rate  rtVBR Real-time Variable Bit Rate  nrtVBR Non-real-time Variable Bit Rate  UBR Unspecified Bit Rate  ABR Available Bit Rate

In the case of UNI 3.1 signalling, where these services are not all clearly distinguishable, the appropriate available services are identified. Additional QoS parameters are not available in UNI 3.1 and those that are available are vendor-specific. Consequently, the level of QoS control available in standard UNI 3.1 networks is somewhat limited. UNI 4.0 with the Traffic Management (TM) 4.0 specification allows much better control of QoS.

The issues for RSVP and Integrated Services over ATM have been analysed:  How to make RSVP run over ATM.  When to set up a virtual circuit (VC) for a specific Quality of Service (QoS) related to RSVP.  How to map the Integrated Service models to ATM QoS models.  How to know that an ATM network is providing the QoS necessary for a flow.  How to handle the many-to-many connectionless features of IP multicast and RSVP in the one-to- many connection-oriented world of ATM.

BTI decided to specify the following service mappings, since they follow most naturally from the service definitions:  Guaranteed Service -> CBR (with tagging!)  Controlled Load -> ABR (with a minimum cell rate)  Best Effort -> UBR

One of the important features of ATM technology is the ability to request a point-to-point Virtual Circuit (VC) with a specified Quality of Service (QoS). An additional feature of ATM technology is the ability to request point-to-multipoint VCs with a specified QoS.

Point-to-multipoint VCs allow leaf nodes to be added and removed from the VC dynamically and so provide a mechanism for supporting IP multicast. It is only natural that RSVP and the Internet Integrated Services (IntServ) model would like to utilize the QoS properties of any underlying link layer including ATM.

Classical IP over ATM (CLIP) has solved parts of this problem, supporting IP unicast Best Effort traffic over ATM. CLIP is based on a Logical IP sub network (LIS), which is a separately administered IP

55 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 sub-network. Hosts within a LIS communicate using the ATM network, while hosts from different subnets communicate only by going through an IP router (even though it may be possible to open a direct VC between the two hosts over the ATM network). Classical IP over ATM provides an Address Resolution Protocol (ATMARP) for ATM edge devices to resolve IP addresses to native ATM addresses. For any pair of IP/ATM edge devices (i.e. hosts or routers), a single VC is created on demand and shared for all traffic between the two devices. A second part of the RSVP and IntServ over ATM problem, IP multicast, is being solved with MARS, the Multicast Address Resolution Server. MARS complements ATMARP by allowing an IP address to resolve into a list of native ATM addresses, rather than just a single address.

A key remaining issue for IP in an ATM environment is the integration of RSVP signalling and ATM signalling in support of the IntServ model. There are two main areas involved in supporting the IntServ model, QoS translation and VC management. QoS translation concerns mapping a QoS from the IntServ model to a proper ATM QoS, while VC management concentrates on how many VCs are needed and which traffic flows are routed over which VCs.

4.2.3 ATM Switching for QoS Support Within the project focus is on usage of the UNI 4.0 signalling protocol. As no NNI signalling will be provided the trials will be considered as a star network with the OLT as the centre. The UNI 4.0 differs from previous version of the signalling protocol, by supporting leaf-initiated joint and support for the ABR service class. The BTI PON based network, consist of two type of resources that need to be allocated during a call set-up: bandwidth and buffers. In the optical segment between the OLT and the ONU a shared capacity of 149 Mbit/s downstream and an individual capacity of 9.36 Mbit/s upstream is available. In both ONU and OLT the buffer is split into 4 priority classes. The amount of capacity allocated to each priority and how it is used can be configured. Between the ONU and the terminal the transmission is split into a VDSL segment (with either 51Mbit/s down and 200 Kbit/s up or 26 Mbit/s down and 3 Mbit/s up) and an ATM-25 segment with a symmetrical 25 Mbit/s capacity. The NT that is beyond the control from the signalling system performs the transformation between the two segments. In order to cope with the capacity differences the NT contains a large buffer. From a signalling perspective the link between the ONU and the terminal has a downstream capacity limited to 25 Mbit/s and an upstream limited to either 200 kbit/s or 3 Mbit/s. As the NT supports 2 interfaces the detailed topology must be known by the resource allocation procedure, but is otherwise invisible to the system.

The following figure shows the configuration of the PON seen from a logical and signalling point of view (due to this the PON looks like point-to-point connections and the NT is not visible). The figure contains 3 databases used by the Call Acceptance Control (CAC). The connectivity database contains information about connected terminals (ATM and IP addresses, connected NT and ONU). The connection database contains information about established connections (and path through ONU and OLT). This is aware of internally used identifiers and the related call and is used to find an unused identifier during a call set-up, to release resources when a call is released, and to find the most appropriate point to add a user to a multicast group. The resource database contains information of allocated resources on the different links and multiplex points. The figure illustrates the handling of a call in the PON when it is configured as a star network. All the elements connected to the PON (real users, routers, servers or other trial sites) will be treated as individual users. All signalling messages will be terminated within and handled by the OLT. Based on a connectivity database the OLT will determine the most optimal way to provide connectivity either for a new call or if a new user is connected to an existing session. If users are connected to the same ONU sub-switch, the connection will be made directly at the point, whereas other connections will pass through the central OLT switch.

Connectivity database (PON user based)

Connection database (OLT/ONU switch based) CAC application Resource database UNI 4.0

(link/buffer/priority based) l l e o r n

SSCS t n n a

o ONU SSCOP h C c AAL-5

OLT ONU

IP-router Server ONU

Figure: Logical configuration of the PON with distributed switching and centralised signalling handling

After the connectivity issue has been solved the CAC application determine the available resources on the path and in case resources are available (without disturbing existing calls e.g. with respect to latency/delay) the call will be registered in the connection database and resources allocated in the resource database. When a connection is closed (or a user leaves a multicast group) the reverse action will be performed within the two databases. The set-up and release of a call will require a configuration of the label translation tables (including allocation of priority class) in all the switches (ONU and OLT) that the call will pass. In case of multicast it further requires to configure the copying function appropriately.

Monitoring and enforcement of resources used by a call will be made as close to the source as possible in order to ensure that any violations are actually due to the user behaviour and not to the multiplexing point in the network. For PON users this will require the UPC in the ONU to be activated, while traffic from the router, the server or other trials will be monitored by the OLT. However, in case excess traffic is accepted at the first multiplexing point with the UPC activated, it may be beneficial to activate a UPC in later switch elements as well as in order to ensure a fair action to be made in case of overload or congestion. The use of a centralised control system is made in order to demonstrate a cost and resource efficient concept similar to the Vb5.2 protocol. However, as the Vb5.2 protocols still is under development a proprietary solution based on the AAL-5 protocol with some secure transfer enhancements and simplified message format is applied for the project.

4.3 COIAS - COnvergence Internet ATM Satellite 4.3.1 Overview The main objective of the project AC-363 COIAS is to demonstrate how the Global Internet infrastructure 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 project therefore participates in the Internet - ATM - satellite convergence and integration effort.

The COIAS project aims at developing and demonstrating the new generation of Internet protocols based on IP version 6 (IPv6) above ATM and satellite while taking into account the main features for the Information Society: performance, quality, mobility and security.

The project framework is depicted in the following figure.

Applications Media Server

Security QoS Reliable Multicast

INTERNET NG IPv6/v4

QoS Mobility Alternate path routing management

ATM Satellite

The project uses existing ATM LAN and WAN technologies and DVB satellite technologies. It focuses on the development, implementation and evaluation of IPv6/v4 software including the latest proposed IETF standards on security (IPSEC), mobility (Mobile IP), Integrated Services (IS), IP over ATM including the MARS protocol, and IP over DVB. It investigates the way to optimise the choice of the path by including alternate path routing mechanisms depending on the required quality of service. It also implements and experiments a reliable multicast (RM) protocol to provide an efficient information delivery service necessary to the targeted applications.

Concerning the applications, the COIAS project does not develop any new application, but adapts existing applications to map them on top of the new protocol stack. The project builds evaluation scenarios based on the use of the IP, ATM and satellite technologies using air traffic control, air navigation and wide-spread personal applications.

The detailed objectives of the project are described in the following sections.

4.3.2 Mapping Internet NG Protocols above ATM and Satellite Networks As mentioned before, the COIAS project is focused on the use of two WAN technologies that can be considered as two main pillars of the Global Internet infrastructure:  The first one is ATM. One important feature of the ATM technology is the potential ability to provide point-to-point and point-to-multipoint VCs with a specified QoS. From the operator’s point of view, ATM brings its scalability and flexibility in terms of traffic management in order to deliver to the user the expected level of performance.  The second one, that can be considered as complementary to ATM, is the satellite. Satellite links are being increasingly used in the Internet, for technical, economical and strategic reasons. In particular, the use of satellite based network technologies is efficient whenever the same information need to be broadcast to many receivers disseminated over a wide area, or when a fast network deployment over a wide area is required.

Of course, the project does not forget existing LAN technologies, and ATM as well as Ethernet or radio LAN sub-networks are used on the project partners platforms.

IPv6 is the core element of the new Internet technology and should be the target protocol towards which all existing networks will have to migrate. The objective of the COIAS project is to implement IPv6 including the Differentiated Services, the security, the mobility and management features and experiment these new capacities. This work did not start from scratch. Two full partners of the COIAS consortium (INRIA and Thomson-CSF DETEXIS) have already developed an IPv6 stack, and the

Thomson-CSF DETEXIS stack is enriched with the new functions and provided to the other partners during the project. Cisco routers including IPv6 new software are also tested during the project.

The COIAS network infrastructure will be one of the first European IPv6 based platforms and will, as the US and Japan IPv6 experimental platforms, provide important feedback before the completion of the IPv6 standardisation process and the complete IPv6 deployment.

The COIAS project addresses issues related to the management of the QoS over an aggregation of ATM and satellite networks. These issues fall into several general classes:  How to map the Internet Differentiated Services model to the ATM QoS model,  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,  How and when to use satellite to dynamically set up shortcut routes 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.

Many of these issues are subject to standardisation work, some of them still require research activities, but all of them require feedback based on practical experiments. The goal of the COIAS project is to design up-to-date solutions to solve these issues and to test these solutions. The COIAS platform includes up-to-date versions of routers provided by Cisco. These IPv6 routers will include QoS mechanisms. INRIA and Eutelsat have already worked on IP satellite transmissions. Their research and prototyping developments are used in the COIAS project.

4.3.3 Reliable Multicast At the transport level, several problems have also to be solved. Reliable multicast data transfer is probably the most complex one. Within the COIAS consortium three full partners (Thomson-CSF DETEXIS, INRIA, UCL) are working on this subject and are bringing in 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. The objective of the project on this topic is to design and experiment congestion control mechanisms for reliable multicast on top of a satellite/terrestrial multicast infrastructure.

4.3.4 Mobility Driven by the new wireless systems and services, the market for mobile terminals is rapidly growing. Considering that the mobility concept appeared just recently, the current version of IP does not include mechanisms for its management. Recently, mobile IPv4 has been introduced mainly to solve the mobile host problem (actually, the ´nomadic` host problem) where a host needs to retain its IP address to retain TCP connectivity, whilst roaming. With IPv4 currently home and away agents look after tunnelling packets, possibly over large ´triangular` routes between the sender and recipient. IPv6 introduces a much more efficient mechanism that allows direct exchange between the sender and the receiver without being relayed by a home agent.

The objective of the project is to implement the new Mobile IPv6 specification, to analyse the performance of this protocol and to propose solutions to provide secure mobile accesses, which is still a hot topic of discussion within the IETF working group.

4.3.5 Security Nowadays, no one can imagine to provide network services without addressing the security problems. Thus a clear security policy has to be defined and security functions and protocols must be implemented in the network infrastructure and within the end systems.

The COIAS platform provides IP authentication and security (encryption) mechanisms according to the latest research of the IETF IPSEC working group. This work includes also the implementation of a key management protocol (IKE).

Since the network is multi-national, security mechanisms have to be adapted to the national regulations. This is particularly true when using encryption mechanisms. To fulfil the requirements of the users, trade and industry as well as the various demands of governmental agencies, the COIAS approach proposes a security infrastructure which enables multi-level security and introduces services to establish security policies between session participants. From the development point of view, the IPv6 software stack will include well defined interfaces allowing the use of different encryption algorithms, as well as the use of different security policies.

4.3.6 Applications The trial scenarios applied within the project are based on operational system requirements provided by Eurocontrol. This includes air traffic control, air navigation, as well as airline and passengers applications. The objective of the project is clearly to provide network solutions which are able to overcome the constraints introduced by new applications.

Operational schema

CONTROLE CENTRES, .... AIRCRAFT OPERATOR, ....

Air Traffic Services Radio - Telephone INTERNET Aircraft Operator Services Aircraft Passengers Applications

ATM network

GATEWAYS & SERVICE PROVIDERS AIR SEGMENTS

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

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

The COIAS project also associates Cisco as sponsoring partner, a major player in the field of LAN interconnection products. This company puts at the COIAS project partners' disposal the IPv6 router software as well as technical support. It shows that the COIAS is directly connected to the market with a world-wide vision.

From the satellite network point of view, Eutelsat as sponsoring partner, has announced that providing advanced Internet satellite services will be one of its strategic future business. This sponsor is therefore interested in the COIAS project and heavily supports it by providing significant infrastructure and equipment.

Secunet GmbH 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

60 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 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 SECUNET, the COIAS project is an opportunity to add new security techniques according to IPv6 to their product portfolio. Furthermore, the provision of a strong certificate infrastructure in a heterogeneous and distributed environment and the following trail and validation phase gives the possibility to improve implementation and maintenance of this infrastructure and the software modules to enhance user trustworthiness and acceptance.

British Telecom has a clear commercial objective to provide high quality services over the Internet 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. British Telecom is therefore contributing to the service requirement definition, to the platform definition and development and to the trials. British Telecom is providing an application server to enable testing, together with test and integration expertise. The company anticipates using the results of the project to improve its next generation products and services.

The mission of Eurocontrol is to carry out research and development in order to improve air traffic management in Europe. IPv6 coupled to Asynchronous Transfer Mode (ATM) and satellite technologies is investigated in the COIAS project as a solution to meet the Air Traffic Management and passengers applications requirements for air-to-air, air-to-ground and ground-to-ground segments with multimedia high-bandwidth. In other words to use the latest COTS technologies, for which there are enormous and increasing investments, for aeronautical applications gets the Internet world to part- develop specific technologies. The large simulations facilities of the Eurocontrol Experimental Centre (EEC) which represents real and advanced air traffic control and air navigation systems are proposed to experiment and validate at application level these emergent network and telecommunication technologies.

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.

4.4 DIANA - Demonstration of IP and ATM Networking for Real-time Applications 4.4.1 Introduction The main objectives of the AC-319 project DIANA are to develop, integrate, validate and demonstrate resource reservation, signalling mapping, and traffic control functionalities which seamlessly inter- operate between ATM and IP networks to achieve QoS.

The development is based on a flexible integration unit that allows the investigation of different approaches for the convergence of RSVP/IP and ATM, as well as providing an insight into the feasibility and efficiency of this topology and technology in comparison to other emerging techniques. Guidelines will be produced for the design of networks combining the scalability of ATM with the flexibility and dynamics of IP based equipment, services and applications.

The generic network model depicted below serves as the reference for the specification, implementation and evaluation of resource management, protocol translation and QoS sensitive applications that DIANA deals with.

Integration Unit Integration Unit Integration Layer Integration Layer RSVP ATM RSVP ATM Signalling RSVP ATM Signalling RSVP

Fig. 1: RSVP over ATM Scenario

The control plane of the Integration Unit is assigned the key role for prototyping the signalling translation from RSVP and ATM signalling and vice versa, for the mapping of QoS specifications given by the respective flow descriptors in the RSVP/IP domain and traffic contracts in the ATM domain, and for the allocation of ATM virtual connections for IP flows. The Integration Unit comprises a modular design, and access to all relevant control functions will allow to work on several approaches experimenting with different schemes. For practical reasons, ATM will preferably be used in the IP domain as well, but merely as a link layer technology offering high, guaranteed bandwidth. Hence, ATM attached hosts at the same site may belong to both the RSVP/IP domain and the native ATM domain dependent on whether they run RSVP/IP or ATM applications and stacks. This means that the domains can be extended in either the IP or the ATM direction in order to investigate whether different levels of IP or ATM usage scale well, where guaranteed service has to be favoured over best-effort and, if resource reservation is used, which strategies are most promising. For simplicity, the routers and switches within the respective domains that are needed to ensure the transfer of data with the desired QoS are not shown.

DIANA is focussing on 4 implementations in a LINUX environment, with which experiments, trials, and measurements will be made:  RSVP-over-ATM  RSVP-peering-with-ATM  Differentiated Services  Scalable Resource Reservation Protocol (SRP)

Particular aspects considered include signalling mapping (including re-negotiation), flow-to-VC mapping, traffic control and aggregation.

4.4.2 RSVP-over-ATM Scenario DIANA’s Integration Unit (DIU) can be regarded as an implementation of an edge device as considered in RFC2381. With such an edge device a RSVP-over-ATM scenario can be realised, in which both connection end-points are controlled by RSVP.

The latest ATM signalling standards permit modifications of traffic parameters by the connection initiator. In ITU-T standards Q.2963. and Q.2963.2 modification procedures for the peak cell rate and sustainable cell rate have been defined, and this might ease the capability to retain RSVP reservation dynamics in ATM. This will also be experimented in the project.

4.4.3 RSVP-peering-with-ATM Scenario

Integration Unit Integration Layer IP Network ATM Network with UNI RSVP RSVP Routers

UNI4.0 Hosts RSVP Hosts

Fig. 2: RSVP-peering-with-ATM Scenario

In the RSVP-peering-with-ATM scenario, an user application that communicates with an ATM API without involving RSVP, inter-works with an application that uses RSVP to signal its resource. The DIU is now the terminating entity for the ATM signalling and the originating entity for RSVP path messages or vice versa:

In the ´RSVP-peering-with-ATM` case, ATM-initiated paths have to be taken into account. The mapping of the ATM address (contained in the incoming SETUP message) to the IP address information that the ATM signalling daemon requires, is problematic. Furthermore, if user plane mapping (e.g. from AAL5 to UDP) takes place, such information has to be obtained or statically configured and stored in the kernel.

4.4.4 Differentiated Services over ATM The definition work of the Differentiated Services (DiffServ) is still in an early state and nearly all drafts are based on IP scenarios. However, the following information represents the opinions from the DIANA project concerning the mapping to ATM networks.

Mapping Provisioned Paths to ATM: In order to support DiffServ, a number of VCs can be set up between adjacent routers; one VC per traffic class. The VCs can be provisioned as CBR with some appropriate bandwidth assigned to them, perhaps proportional to the amount of traffic of each class that is expected to be carried by the provider. In this manner, the ATM network will treat the traffic classes preferentially. It is also possible to use VBR VCs in order to provide some statistical multiplexing gains. An alternative is to provide a single VC with enough capacity to carry all the packets in all traffic classes. In this case, the ATM network is treated as a single link and the routers manage the traffic among various classes themselves, with no support from ATM.

Mapping Packet Marking to ATM: If VBR VCs are used to connect routers and two levels of precedence are applied, cells in excess of their profiles could be tagged while others could not. There will be some interaction here between the excess traffic of an individual profile and the aggregate excess traffic of all profiles traversing this link, so the VC bandwidth must be provisioned carefully. No tagging is permitted with CBR. Also, ATM does not specify how tagged cells will be treated, but it is expected that such cells are handled in a best-effort manner.

Mapping MPLS to ATM: When MPLS is used to set up differentiated paths for traffic, each MPLS path can be mapped to a single ATM VC. The ATM VPI/VCI can carry the MPLS labels and the VC resources can be provisioned based on the MPLS path requirements.

Service Interworking: In all the above scenarios, the IP QoS flows were encapsulated in ATM VCs; ATM was merely providing transport to IP packets without interpreting the packets or services provided by those packets. This is also known as ´network interworking`. In this case, the IP QoS mechanisms are mapped to ATM QoS mechanisms. Another form of QoS interworking is possible using ´service interworking`. In this case, the service being provided by the IP packets is mapped to an equivalent service into ATM, and the IP packets are translated (instead of being encapsulated) into ATM. One example of work-in-progress in this area is transport of voice over IP, using H.323. In the IP network, voice is encapsulated in RTP, which is then transported over UDP/IP. Since the voice packets are being carried over a separate VC (using the special encapsulation), this VC can be provisioned to provide appropriate QoS. The VC can be set up statically (PVC) or dynamically (SVC).

4.4.5 Software Architecture for the DIANA Integration Unit

Fig. 3: Block Diagram of the DIANA Integration Unit (DIU)

The DIU has to be fully functional in both RSVP/Integrated Services as well as in ATM environments. On the RSVP side, the DIU adopts the role of a RSVP capable router, i.e. processes RSVP messages, reserves resources, and maintains soft state (in the control path), and classifies, polices and schedules packets (in the data path) before finally forwarding them. As an ATM end system, the DIU sets up ATM connections and accepts or refuses incoming connections.

The key issue is that admission control for Integrated Services is now dependent on the successful set-up or modification of a connection across the ATM network. In RSVP terminology, the Link Layer Dependent Adaptation Layer (LLDAL) is supposed to provide this functionality. As a first step, an ATM specific LLDAL translates between IIS to ATM traffic descriptors. Then the set-up of a new VC, the modification of an existing VC or, if aggregation takes place, a simple look-up for an already active VC and the respective admission decisions will be performed.

In the user plane, a flow classifier and scheduler need to be implemented to redirect data packets from flows to be routed over VCs and to ensure that several flows can share a single VC. An ATM queuing discipline (an extension of the standard LINUX IP kernel traffic control capabilities), has thus been implemented:

Filter Class Queueing discipline ATM VC

Filter Class Queueing discipline Default Queueing discipline

ATM Queueing discipline

As QoS and traffic parameter mapping from RSVP to ATM as well as flow-to-VC management functions and scheduling can be highly interdependent when aggregation takes place and a management function may decide to allocate extra resources in anticipation of further reservations, e.g. when a certain percentage of the available VC bandwidth is consumed, they deserve further studies treating QoS mapping, VC management, and CAC in an integrated manner. The outcome of

64 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 this research will help to incrementally improve the flow-to-VC traffic control module within the atmtcd process.

CLIP will be used for the IP to ATM address resolution. For this purpose, the ATM traffic control module being implemented by DIANA makes use of a UNIX socket based interface offered by the LINUX implemenation of CLIP’s atmarpd.

Signalling messages arriving or leaving on the standard signalling VCs are handled by the UNI signalling daemon whereas other switched VCs, namely the RSVP control VCs and the RSVP over ATM VCs, terminate in the IP module in the same way as IP paths. From there, IP packets carrying the well-known RSVP port numbers are redirected to the RSVPd while data packets are subject to routing and classification (to identify the flow to which they belong) before they are scheduled to be sent. The settings of the classifier and scheduler are controlled by the RSVPd, by a set of integrated services specific data structures grouped in the integrated services traffic control block.

4.4.6 Applications and their Requirements for QoS Interworking The DIANA project aims to solve the signalling issues associated with interworking between ATM- based networks and general IP-based networks, both supporting some resource reservation protocol in order to offer QoS support to the application layer. Even if the main focus of this project is at the lower layers, we also consider real applications generating some traffic that requires QoS. More precisely, a generic scenario consists of two instances of the same application running on both the ATM-based and the IP-based side, communicating with each other, and typically requesting a given QoS from the network(s) via some signalling protocol(s).

The project surveyed a number of applications in order to determine their feasibility to be used as bench mark applications and to find out the relevant requirements that they pose to the integration unit. From the studied applications, two were selected, an audio application (VAT) and a video application ARMIDA.

Audio application - VAT The VAT (Visual Audio Tool) was developed by the Network Research Group at Lawrence Berkeley National Laboratory. VAT already offers different audio coding standards. They vary by their bandwidth but they all emit a constant bit rate stream. The supported audio formats have a relatively low bit rate, which makes them vulnerable to packetisation delays. Packets are therefore chosen to be small which in turn affects the router performance. This fact and the peculiarity that the transmission of interactive audio has often been reported to be more sensitive than a video transmission makes this application an important test case for the DIU.

The existing application is being extended to perform the necessary signalling. Based on the audio coding scheme chosen by the user, the required bandwidth must be requested. Opening the RTP (Real Time Protocol) connection also causes a connection to the local RSVP daemon to be opened. Over this control path the reservation information is passed from the application to the local RSVP daemon and from there to the routers, the DIANA integration unit and the switches. The traffic descriptor must be filled out based on the coding scheme. It defines the bit rate (as token bucket specification and peak rate) as well as the frame size for the connection. When the user selects a different scheme a re-negotiation will be initiated on the RSVP level. If the required bandwidth is not available the user will be prompted to try to connect using a less demanding coding scheme. Since the RSVP application programmers interface is completely separated from the communication interface the VAT application can be made signalling aware without much interference with the existing source.

Video on demand application – ARMIDA The video on demand application ARMIDA encompasses a Web server and a Web client. The server runs on Solaris2.5.1 or NT, the client only on NT. ARMIDA’s video encoding and decoding is based on MPEG1-/MPEG-2/MPEG-4. ARMIDA is to be extended to use RSVP and IP as well as native ATM. In DIANA, ARMIDA will be used on a SUN workstation with INTEL’s RSVP implementation.

4.4.7 Bandwidth Management in the DIANA Integration Unit The DIU will manage the bandwidth resources on all ATM and IP interfaces by performing appropriate traffic control functions. The bandwidth management functions and policies implemented in the DIU have been designed to achieve efficient utilisation of the available resources.

For each reservation request received at the DIU, admission control has to be performed in order to check whether sufficient resources are available to support the request. More specifically, the

65 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 admission control and resource reservation will be based on the information given in the Resv messages containing the traffic flow specification (Tspec) and in case of Guaranteed Service also a reservation specification (RSpec). For IP over ATM the atmtcd will receive a message from the RSVPd containing the necessary Resv parameters for making a new reservation. The received IP domain traffic parameters will be mapped to a set of corresponding ATM traffic parameters. This kind of mapping has been investigated in RFC2381.

After the parameter mapping has been performed the question arises if the flow should be carried by a new SVC or be aggregated on an already existing SVC. One reason for aggregating flows on VCs is to reduce the number of VCs, which could be a scarce resource in a large network carrying a huge number of flows. Several policies for aggregating flows on VCs can be envisaged.

If a new SVC has to be established in order to cater for the new flow, ATM Connection Admission Control (CAC) has to be performed. In the case of one-flow-per-VC, the traffic parameters obtained from the mapping function can be used in the connection set-up message. However, if the SVC is intended for flow aggregation, additional bandwidth in anticipation of new flows can be taken into account, thereby possibly avoiding modification of the SVC bandwidth when adding another flow.

Before aggregating a new flow on an already existing VC, one has to check if there is enough spare capacity on the VC to carry the new flow. If the VC is of the CBR category, this check could be similar to the algorithm performed by a conventional CAC when checking the available bandwidth on a VP. If there is insufficient bandwidth on the VC, one can either try to renegotiate the VC bandwidth, establish a new VC or reject the reservation request.

The question of how to manage flow aggregation in an efficient way has many aspects. A scheme for dynamically changing the VC bandwidths in order to obtain good bandwidth utilisation, and at the same time limiting the frequency of bandwidth renegotiations to reduce the load on the signalling system, has been proposed.

4.4.8 Bandwidth Management on VCs used for Aggregation A potential problem of any ATM-based solution is ´VC explosion`. This occurs when the network attempts to map every IP flow into an individual ATM VC. Given the fluctuations of Internet flows, the number of VCs on a service provider link could easily become exhausted. A technique to aggregate the IP flow traffic into a relatively small number of VCs is therefore desirable. Such a scheme entails several elements among which are:  a procedure for determining IP flows eligible for aggregation (based on route and possibly other parameters)  policies rules for initiating new VC or let an IP flow join an existing one  a method for flow admission control on VCs  a strategy for bandwidth management on VCs carrying aggregated IP flows

The method proposed by DIANA for bandwidth management on VCs carrying aggregated IP flows is as follows: Virtual connections used for aggregating GS flows will be of the CBR/rt-VBR category and consequently be assigned a certain amount of bandwidth. This bandwidth could be fixed in the sense that the bandwidth allocated at connection set-up time would be kept until release of the connection. However, with a highly fluctuating traffic pattern this can easily lead to poor bandwidth utilisation. Therefore, to obtain a more efficient utilisation of network resources, an adaptive scheme for renegotiating connection bandwidth according to the actual demand at the IP flow level is proposed.

4.5 ELISA - European Experiment on the Linkage between Internet Integrated Services and ATM 4.5.1 Main Objective The project investigates the technical feasibility of a new architecture for the Internet that provides different levels of QoS, based on a combined Differentiated Services (DiffServ) and Integrated Services (IntServ) model, and which uses specific features of ATM networks, in particular switched connections with guaranteed Quality of Service. The key objectives are:  Combination of existing and, in a sense, complementary technologies (DiffServ and IntServ) in order to provide QoS over IP networks.  Specification and development of a prototypical edge device.

 Usage of existing wide-area ATM networks to support QoS guarantees through ATM switched connections (signalling)  Integration of a trial testbed which makes realistic assumptions about the way how terminals are connected to the network (i.e. through a LAN or ISDN using an edge device connected to the wide-area ATM backbone).  Study of architectures, strategies and algorithms to ensure scalability for large network size and high network load (e.g. aggregation of traffic between edge devices).  Study and prototypical implementation of charging and admission control mechanisms which apply to individual QoS requests issued by a user’s terminal.  Provision of set of example applications to demonstrate the manifold possibilities to use the enhanced network features in multimedia services.

4.5.2 Technical Approach The project will provide a trans-national testbed which will bring some of the key advantages of ATM (in particular QoS) to end systems which are not directly connected to an ATM network but via other technologies like Local Area Network or ISDN/POTS connections. The technical basis for the integration of such a heterogeneous network platform is the Internet Protocol (IP) together with its extensions for an integrated services architecture (e.g. RSVP).

A set of end systems and applications will be provided which support QoS requests over IP. These end systems will be deployed to several trial islands in different European countries where they will be connected to typical access technologies for business and residential users (LANs, ISDN or POTS). By means of special "edge devices”, the islands will be interconnected through a trans-European ATM network which is capable of establishing switched ATM connections. This backbone network will be derived from the INSIGNIA (ACTS project AC-068) trial configuration.

Internet

Edge Edge Device Device ATM Switched ISDN, LAN Network POTS

RSVP ATM Signalling RSVP CPE CPE Fig. 1: Initial Reference Architecture

Key issues of the project are:  Practical experimentation on a combined IntServ / DiffServ architecture;  Usage of existing wide-area ATM networks to support QoS guarantees through ATM switched connections;  Integration of a trial testbed which makes realistic assumptions about the way how terminals are connected to the network;  Provision of an example application to demonstrate the manifold possibilities to use the enhanced network features in multimedia services.

The project expects the following achievements:  Definition of an architecture for an RSVP over ATM solution and of an architecture for edge devices which interconnect IP and ATM  Design of edge devices to interconnect different access network technologies using TCP/IP and RSVP / DiffServ and an ATM core network using SVCs  Development of an efficient flow admission control algorithm which will guarantee the QoS requirements of the application components according to the RSVP parameters mapped into ATM traffic parameters  Selecting a charging scheme suitable for the type of application used in the project

 Development of a charging and billing mechanism able to cope with IP traffic characteristics

The project generally aims to broaden the range of applications and users for high-speed networking in Europe by integrating advanced network features into Internet-based applications. If applied to public networks in a large scale, the project results will enable a new generation of Internet applications which are characterised by high-quality and real-time multimedia transmission, but also by a different economic model than in normal Internet usage (individual billing for improved QoS). Such an integrated Internet/ATM network will have a number of implications.

4.5.3 Summary of Trial The ELISA project focuses on the specification and development of a prototypical Edge Device (ED). Moreover, a set of end systems and applications which support QoS requests over IP will be provided. The feasibility of the ELISA approach will be tested and demonstrated through mid scale field trial. The field trial will involve edge devices located in various places of Europe (Munich, Darmstadt, Berlin and possibly Budapest). The EDs will be inter-connected through switched ATM connections. Moreover, end systems, deployed to several trial islands in different European countries (e.g. Germany, Hungary, Spain, Italy, Greece), will be connected to EDs using typical access technologies such as ISDN, POTS, LAN.

4.6 IthACI 4.6.1. Technical Background/State of the Art IP switching seems to be a possible approach to combine the speed of ATM switch hardware with the simplicity and flexibility of IP inter-networks. The basic idea of IP switching is to use IP network control on top of ATM switch hardware. The full Internet functionality for addressing, routing, and transmission is used within the IP router, but the high-speed data forwarding functionality is performed by means of IP switching. The complex ATM signaling is abandoned, and replaced by a simple IP switch coordination protocol (Ipsilon IFMP, Tag-Switching TDP), or by implicit signaling means (IPSOFACTO).

A variety of IP switching architectures have been proposed (Ipsilon Switching, Cisco Tag Switching, IBM ARIS, Toshiba CSR, NEC IPSOFACTO, etc.). This has prompted the IETF to define a standardized approach within the working group on Multi-Protocol Label Switching (MPLS). Today, MPLS mainly focuses on interoperability aspects (Label Distribution Protocol/LDP), and initially concentrates on point-to-point best-effort communication.

4.6.1.1 IP Switching Basics The various IP switching methods are categorised by two main aspects:

First, how the establishment of a special path within the network is triggered.  Topology-driven path establishment is based purely on the source and destination endpoints. For each pair of endpoints within the network, first a path in the network is determined based on the routing information available, then an unique label on every link is allocated, and lastly a label swapping at each LSR is established in advance for that path.  Request-driven path establishment uses some signalling protocol for establishment (and deletion) of paths and the appropriate labels. In other words, when planning to send data, the path has to be established by issuing some special command on the network.  Another solution is the traffic-driven (flow-driven, data-driven) path establishment. This means that an IP router analyses the traffic, and establishes a shortcut path whenever it detects the beginning of a flow.

Second, how the co-ordination among the IP switches is performed, which is necessary in order to have a consistent view of paths and labels within the IP switching network.  By using some special distribution protocol among the LSRs, to establish paths or announce data flows. The advantage is the simplicity: the only requirement is the addition of a relatively simple protocol within a LSR. On the other hand, the delay deriving from path establishment and the protocol overhead are increased.

 By using implicit signalling, for example, choosing an unused VC on an ATM line initiates a new flow. No additional communication overhead is imposed, but this way one may not be able to transfer all the necessary information (e.g. about routing or QoS treatment) among LSRs.  Piggy backing on an existing protocol.

4.6.1.2 Evaluation of IP Switching The various methods of path establishment have several advantages as well as drawbacks:  The advantage of the topology-driven approach is, of course, its simplicity: In order to transfer data, it is only necessary to pre-establish a path according to source and destination. Applications just have to pick the appropriate label according to the desired destination. Drawbacks are the high VC consumption in large networks, as well as the difficulty to give special QoS treatment on a per-flow-basis. Aggregation (merging of data on common sub-paths) is also an issue for topology- driven approaches. It is often required, but complicates per-flow treatment.  The request-driven approach overcomes these drawbacks at the cost of some additional delay at path establishment, and increased complexity due to signalling. Nevertheless, it is not in each case necessary to use an additional protocol for this, as some already existing protocol messages (RSVP, IGMP) might be re-used or piggybacked for that purpose.  The traffic-driven approach has the great advantage that there is no need for special (additional) functionality at the endpoints, or co-ordination among the routers. Nevertheless, this solution may have several drawbacks: Not all types of flows may be detected, and some data may be recognized as the beginning of a flow although it is not. VC consumption may be an issue, as the usable VC range is limited. Flow detection may be time-consuming. The first packet of a flow experiences longer delay than the subsequent data, because it is routed, not switched. And last, but not least, the decision about the release of a shortcut is a critical issue due to the fact that the LSR has no means to detect the end of a flow (as it is not able to analyze any further data after flow establishment).

4.6.1.3 MPLS The Internet Engineering Task Force (IETF) has established a working group on Multi-Protocol Label Switching (MPLS) in early 1997 to consider methods for label-swapping based forwarding (´label switching`) in conjunction with network layer routing. Although neither restricted to any layer 2 technology nor to a specific layer 3 protocol, IP over ATM (´IP switching`) is currently most likely to be implemented as a first incarnation of MPLS.

The IETF MPLS working group builds up a general MPLS framework and architecture. So far, the main focus of the MPLS working group was on interoperability aspects, especially the Label Distribution Protocol (LDP), which provides the signalling facilities among the LSRs, and coordinates the distribution of label bindings. Recently, work on traffic management issues in MPLS has also begun.

4.6.2 The IthACI Project Currently, several concurrent IP switching solutions exist. MPLS as the proposed standard solution for IP switching has deficiencies with regard to functional enhancements, compared to traditional IP networks in the areas of Quality of Service (QoS) / resource management and multicast support.

The overall scope of the IthACI project is to evaluate and contribute to the different technologies that permit the efficient transport of IP traffic over an ATM backbone infrastructure (either private or public). The project will investigate and enhance schemes for the efficient integration of IP and ATM network technologies. It will concentrate on fast layer 2 forwarding methods for IP traffic based on labelled flow mechanisms. In this context, the project will also address how the previous facilities are affected by requirements for efficient IP multicasting over ATM, accommodating QoS demands, mobility and resource control. The project will make critical assessment of emerging solutions, perform incremental development on existing solutions addressing specific feature enhancements and generate recommendations based on analysis and applied experimentation. For this purpose, three independent islands each one using its own proprietary IP switching technique - NEC’s IPSOFACTO, Cisco’s Tag Switching, and Alcatel’s YALSA - will be built. Each of these islands will be enhanced with features in several or all of the areas of multicast, QoS, resource management, and mobility in order to provide some real added value compared to existing solutions. In the end, the islands shall be interconnected to demonstrate the interoperability of the IP switching techniques as well as the enhanced features.

4.6.2.1 Multicast within IthACI The multicast enhancement within the IthACI project and testbed aims to apply MPLS-style shortcut techniques to IP multicast to optimize the network without any modification to the end-user environment nor any modification to existing IP multicast protocols. The shortcut point-to-multipoint ATM connections will follow dynamically the tree topology changes that are the result of IP hosts joining or leaving the group.

Currently several Multicast Routing Protocols are being implemented and standardized (DVMRP, PIM- SM, PIM-DM, MOSPF, CBT, …). These protocols expose different tree set-up and maintenance characteristics which yield that some Multicast Routing Protocols combine better with IP Switching than others: e.g. Flood&Prune protocols (DVMRP, PIM-DM, …) will create highly dynamic L2 trees, resulting in a lot of label advertisement signalling and label consumption. Also, some multicast routing protocols (e.g. PIM-SM, CBT) allow to use a shared tree for all sources which leads to less label consumption, but to potential merging problems.

The project decided to deploy PIM-SM as Multicast Routing Protocol in all the islands. However, each island uses its own method to do the mapping of multicast streams onto L2 connections. The three possible label advertisement methods are represented in the three islands (IPSOFACTO: implicit, Tag Switching: piggy-backing; Yalsa: dedicated protocol). A dedicated protocol (e.g. LDP) has the disadvantage that it needs to be developed from scratch. Label advertisements piggy-backed onto PIM Join/Prune messages (Tag Switching) have several disadvantages: the periodicity of the messages creates more signalling than required, only ´downstream` mode is possible, the deployment of each new Multicast Routing Protocol demands adaptations to allow piggy-backing, the method can not be used for Flood&Prune protocols and finally, it limits the scope of the MPLS domain in mixed (LSR and non-LSR) multi-access networks.

Besides correct interworking of IP multicast and IP switching in the separate islands, the goal is to demonstrate the interoperability between Alcatel’s, NEC’s and Cisco’s multicast solutions, either on layer 2 or layer 3.

4.6.2.2 QoS and Resource Management in an IP Switching Environment

Quality of Service for RTP Flows The aim of this enhancement for the IPSOFACTO based IP switching island within IthACI is to provide QoS to established flows in NEC’s IP switching island. This island will be supporting a joint MPLS/IPSOFACTO prototype platform. Rather than providing per-flow QoS, a task which can be done with RSVP but which incurs several complexity and scalability issues (this has already been done by the participating companies indepedently from each other), the primary goal is to provide Class of Service (CoS), thus approximating a DiffServ solution. The existing flow detection mechanisms in the IPSOFACTO architecture will be further enhanced with an RTP flow detection mechanism (it should be noted here that RTP-based applications are very important as they are actually real-time and therefore require a better service than traditional data applications). Furthermore, flow differentiation among the RTP flows will be done using some clever assignment of flows with specific RTP profiles, which will be mapped to the appropriate ATM switch service classes treatment. The use of the appropriate buffer management and scheduling mechanisms in the ATM component of the LSR together with the availability of a flow MIB (see Resource Management) and a distribution protocol will allow for an efficient CoS provisioning.

Joint MPLS/IPSOFACTO Platform Architecture The goal of this task within the IthACI IPSOFACTO based IP switching island is the development of a common prototype for the co-existence of a topology-driven unicast-oriented IP switching technique (MPLS) and a flow-driven IP switching technique (NEC’s IPSOFACTO). Interoperability and resource management issues involved with the co-existence of these two techniques will be studied.

Unicast Routing LDP IPSOFACTO Multicast Routing Protocol Module Module Protocol

TCP/UDP IP

VC Resolution VC Manager

Fig. 1: The common IPSOFACTO/MPLS architecture. The basic idea of a combination of standard MPLS and IPSOFACTO within one box is to use MPLS as a ´standard` method for unicast traffic, whereas IPSOFACTO may be used whenever standard MPLS has deficiencies, that is QoS support for unicast, and general multicast support. The IPSO- enhanced MPLS would be able to speak standard MPLS protocols (that is LDP) whenever communicating to any pure MPLS-capable device, but may use the additional functionality of IPSOFACTO within an IPSOFACTO sub-cloud.

The common architecture is shown in figure 1. The unicast and multicast daemons are influenced by the routing protocols. Both daemons have a common interface to LDP and the VC manager. The LDP functional block in figure is a transport layer responsible for sending/receiving LDP PDUs. The label manager is a single point of control for managing the Label Table and the GSMP interface.

QoS and Resource Management Approach for Tag Switching This enhancement within the IthACI project aims at adding QoS provisioning and resource management functionality to the tag switching technology. The approach to be taken can be straightforwardly applied to MPLS. The goals of QoS provisioning is to provide better and more predictable network service by providing dedicated bandwidth controlled jitter and latency and improved loss characteristics. Enhancements to tag switching towards QoS and resource management are based on the idea of establishing an overall QoS provisioning framework from the viewpoint of a service provider.

The QoS provisioning framework should provide differentiation between the services in terms of their transfer characteristics and above all differentiation among customers in terms of the services they may request. The framework is compatible with both IntServ and DiffServ approaches for QoS provisioning emerging in the Internet. It entails two aspects:  Definition of a service template for requesting QoS-based services (definition of discrete Service Classes)  Definition of a suitable architecture and protocols required for supporting the provisioning of the defined QoS-based services in the network.

The basic idea underlying this QoS framework is to create and dynamically manage a virtual topology induced to the physical one for allowing the cost-effective and, according to business policies, segregation of network resources (i.e. bandwidth) to the different Service Classes. This virtual topology is called „soft-network“. The „soft-network“ is used to configure and reserve the available network resources according to the characteristics of the supported Service Classes.

In the above framework, the network needs to provide intelligent routing and resource management functionality for:  establishing and dynamically managing the ´soft-network`  connection admission at the edge nodes of the network  policing/classification of packets according to the traffic and QoS characteristics of their Service Class  routing flows belonging to a specific Service Class across the ´soft-network`

The focus is on the enhancements to tag switching supporting the above bullet-points. Tag Switching is enhanced with resource allocation among several service classes and virtual links in order to control the way traffic flows inside the network. Existing IP switching technologies assume that routing is accomplished using traditional network layer routing protocols. Consequently network administrators have no control on the way traffic navigates through the network. This can easily lead to unpleasant situations where some parts of the network are congested and some others are under-utilised. Combining tag switching with routing mechanisms that take into account on-line network performance metrics and at the same time give network administrators the ability to influence routing decisions according to their preferences appears to be very challenging yet promising task.

4.6.2.3 IthACI IP Switching Enhancements The enhancements for IP switching addressed within the IthACI project, mainly fall into the areas where current MPLS has deficiencies:  Multicast: MPLS, so far, defined only unicast solutions for IP switching. IthACI shall implement PIM SM for several IP switching architectures and demonstrate interoperability between them. Thus, this might be a proposed solution for multicast within MPLS.  QoS and Resource Management: Several issues are performed within the IthACI project for this area.  RTP flow detection for IPSOFACTO: The goal of this issue is to obtain performance improvements for realtime traffic with no additional signalling overhead. This is performed by detecting RTP flows within the IP switch and give them special handling, accordingly. RTP is designed for real-time multimedia traffic (audio, video). Currently, it is used within the MBone (Multicast Backbone) for applications like vic and vat for audio and video conferencing. RTP may gain considerably increased usage within IP-based networks in the future.  FlowMIB: This is an extended MeterMIB-similar information base specially designed for traffic- driven IP switching techniques which provides various information about shortcut flows. It shall be used for effective and efficient network resource management within the IPSOFACTO environment.  QoS and Resource Management Framework: Within the IthACI project, a framework for tag switching is designed and implemented to provide QoS provisioning and resource management functionality. This framework comprises the establishment of a virtual network (´soft network`) on top of the physical one, establishing and dynamically managing this ´soft network“`, connection admission at the edge nodes, policing and classification of packets according to their service class, and routing of flows across the „soft network“ belonging to a specific service class.  Mobility: The issue of mobility within an IP switching/MPLS-like environment, which is even capable of handling multicast traffic, is also addressed within the IthACI project.

4.6.3. The IthACI Testbed The enhanced features described above, will eventually eliminate the deficiencies of current MPLS. Nevertheless, all these developments are carried out within IthACI in three islands using three different IP switching techniques. The goal of the project is to interconnect these islands and make the one enhancement, which is common to all islands, the multicast extension, interoperable between the islands. By that IthACI will prove the applicability and suitability of this approach for several IP switching techniques and thus also for MPLS.

The approach taken to meet the stated project objectives has three main elements:  the forming of three geographically disparate switching islands with different IP-switching solutions,  the specialisation of the islands by the development and integration of enhanced features over the baseline IP-switching solutions, and  a phased approach to validation and demonstration consisting of both isolated and interconnected islands’ demonstration and trials.

IBM Compatible

Workstation IBM Compatible IBM Compatible

Workstation IBM Compatible

Red Island Green Island

IBM Compatible

Workstation IBM Compatible

Blue Island

Fig. 2: The IthACI Wide-Area Testbed

Ultimately the project will form 3 distinct islands in selected partner locations. The islands will be situated in the countries of Belgium, Greece and Germany. The IthACI IP-switching islands are based on ATM switching technologies from different vendors. Partners of the IthACI consortium will bring the required equipment and IP switching solutions as baseline technologies.

4.7 MULTICUBE - IP Multicast over ATM Research 4.7.1 Overview The IP Multicast service model is receiver-oriented: Hosts who want to participate in a multicast session as receivers join the multicast group, which is identified by an IP class-D address. The IP multicast architecture takes care of distributing data sent to the class-D address to receivers which joined it. Senders do not even care about the unicast addresses of receivers. On the contrary, ATM embraces a sender-oriented philosophy: only the senders are able to establish new VCs, to add or delete receivers10. However, the most efficient mechanism to transport IP multicast data flows in ATM networks is to involve ATM point-to-multipoint channels, thus enabling the use of ATM hardware fabric for data replication. Hence the need for a mechanism for the translation of IP class-D addresses to a set of ATM NSAP addresses, which are used by senders to open point-to-multipoint channels towards the receivers of a multicast session. Currently, the IETF standard for IP-ATM multicast address resolution is the Multicast Address Resolution Server (MARS, [RFC2022]). The MARS solution follows a hard-state approach, and retains the separation of LIS's connected by IP multicast routers. One MARS serves one LIS for both IP unicast and multicast address resolution. Bypassing routers for inter- LIS communication would require coordination of multiple MARS's and could congest the network.

Another approach is followed by the EARTH (EAsy IP multicast Routing THrough ATM clouds, [Smir97]) protocol. EARTH, in contrast to MARS, allows efficient shortcuts for multicast connections

10 This refers to UNI 3.1

73 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 and separates address resolution for IP unicast and multicast. In addition, EARTH supports a softstate approach and ATM QoS features. EARTH introduces the concept of MLIS (Multicast Logical IP Subnet), spanning a whole physical ATM network (ATM cloud) which is served by a single EARTH server. The EARTH's shortcuts for multicast traffic inside the MLIS, bypassing edge routers on the borders between LIS's, help to achieve better performance in terms of join/leave latency and better efficiency in the multicast distribution tree (MCT) establishment.

EARTH, being an ATM protocol supporting IP multicast with embedded support for the QoS settings, can also work even without any reservation protocol to enable QoS settings. In any case, it would provide an address resolution for best effort flows, supporting minimal QoS functionality in order to allow set-up of QoS VCs by manual configuration or management protocols. This is especially useful if other QoS models like the Differentiated Services Model should be supported where the representation of the service classes are individually chosen by the provider.

As shown in figure 1, a potential receiver (which can be located in any LIS inside the ATM cloud) of an IP multicast flow, sends its registration messages (EARTH_join) within a given refresh period to the EARTH server. The EARTH_join message contains the IP and ATM addresses of the receiver. A sender, or a re-sender (MRouter11) of a given IP multicast group, periodically queries the EARTH server with EARTH_request messages in order to get the membership information. The EARTH server answers with the EARTH_multi message, containing the NSAP addresses of all receivers registered for a requested source. The sender keeps its local cache of the membership information, and is thus capable of opening and dynamically managing the set of point-to-multipoint connections to the receivers. EARTH messages and data-structures offer full support for QoS connections. In particular, source specific QoS requested by receivers can be registered within the EARTH server's address resolution table (MARP Table), either by means of a reservation protocol (RSVP), by network management mechanisms or manually by a network operator. Senders examine QoS information retrieved together with membership information, and are thus capable of opening both best-effort and QoS point-to-multipoint connections, depending on receivers' requests. Senders notify the EARTH server about the success or failure in the opening of a new QoS connection, using the EARTH_QoS_notify message.

The EARTH-S in the MIS architecture supports resource reservation with two local interfaces: QSSI (Quality of Service Support Interface) and eRSRR (earth Routing Support for Resource Reservations). These interfaces define specific messages in order to pass information to/from the EARTH-S.

ATM cloud (MLIS) EARTH_joinEARTH_join EARTH_requestEARTH_request LIS A LIS B Sender

Receiver 1

Receiver 4

EARTH Server Receiver 3

Receiver 2

Multipoint data VC EARTH_multiEARTH_multi

Point-to-point control VC

Fig. 1: Distribution of basic EARTH messages within the MLIS.

11 An MRouter, interconnecting the MLIS at the IP layer with another network, can act as a re-sender for traffic coming from a sender which is located outside the MLIS.

The QSSI provides the EARTH_RESV and EARTH_RESV_ACK messages, used to set and confirm the requested QoS information from the EARTH-S. The routing support interface (eRSRR) gives the possibility to get the information about receivers participating in a multicast session locally from the EARTH-S through two messages: EARTH_query, used to request an address resolution, and EARTH_response, used to return the addresses of receivers which joined the group to the requester.

The EARTH client keeps the EARTH server informed about it’s membership. Futhermore it has the address resolution table with information received from the EARTH server about members and their QoS preferences. Each host which runs an EARTH client has to run an additional module – the cache manager - which is a part of the EARTH design and co-operates with the EARTH client. The cache Manager runs in the ATM driver and has its own address resolution table (cache) which corresponds to this one of EARTH client but contains additional information needed for connection management and IP packets forwarding. Thus in MIS the two tasks, EARTH protocol machines execution and forwarding (connection establishment - best effort and QoS, assignment of packets to connections) are separated.

4.7.2 The Multicast Integration Server Architecture Known solutions for the integration of QoS in Internet and IP Multicast with ATM treat multicast address resolution and QoS support issues separately. Currently standardised within IETF solutions for IP over ATM consider multicast without QoS and QoS without multicast [RFC2379, RFC2380, RFC2381, RFC2382]. This raises efficiency, scalability and resource consumption issues, and would force either to adopt a reduced set of capabilities for the VAIP over ATM, or to improve the current ATM signalling in order to meet specific needs. This consideration leads to the approach called the MIS architecture. The approach is to consider both IP-ATM address resolution and QoS support issues in an integrated manner. By the merging of a layer-3 protocol like RSVP and a layer-2 protocol like EARTH, a generalised, integrated and server-based approach has been designed for providing shortcuts for both best-effort and QoS multicast flows in IP over ATM networks. ATM cloud (MLIS)

LIS A LIS B Sender

Receiver 1

Receiver 4

Multicast Integration Server Receiver 3

Receiver 2

Multipoint data VC PATH messages

Point-to-point control VC RESV messages

Fig. 2: Distribution of PATH and RESV messages within MLIS

The Multicast Integration Server is a specialised node on an ATM cloud (MLIS in EARTH terminology). A MIS is composed of an EARTH server, for IP class-D to ATM NSAP address resolution and layer-2 QoS management, and of an RSVP server, for layer-3 QoS management. The address of the MIS is a well-known address to every IP node on the MLIS. Each participant in an IP Multicast session within the MLIS, either sender or receiver, opens a control VC to the MIS. The control VCs are used to exchange EARTH and RSVP protocol messages between IP nodes and the MIS, as shown in figure 2.

On one side, EARTH protocol messages are exchanged between EARTH clients (IP end-systems) and the EARTH server on the MIS for resolving IP class-D addresses to ATM NSAP addresses dynamically. On the other side, RSVP protocol messages are exchanged between RSVP daemons (IP end-systems) and the RSVP server on the MIS, for distributing information about the requested QoS. In particular, PATH12 messages are sent from sender(s) to the MIS, where the RSVP server

12 PATH messages carry a description of the sender's data stream (SENDER_TSPEC object). An ADSPEC object may be included, which carries additional information (e.g. delay estimates) and can be updated by every IIS-aware network element along the path from sender to receivers.

75 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 processes, replicates and forwards them to receivers. At the same time, all reservations (RESV13 messages) within the MLIS are sent to the MIS, merged and forwarded to the sender(s). This server- based model, where the RSVP server within the MIS acts as a dispatcher of RSVP protocol messages, contrasts with the usual RSVP distributed processing adopted on conventional IP networks.

4.7.3 Properties The issues of the operation of a reservation setup protocol and a multicast group management protocol solved by employing the MIS architecture are the following:

Independence of specific reservation / group management protocols Since EARTH is a generic ATM protocol to support layer-3 multicasting, it works with various group management protocols, which e.g. offer sourcespecific groups. Furthermore, no dependence on any specific reservation set-up protocol has been introduced, because EARTH's basic functionality (address resolution for best effort flows) had to be retained. EARTH itself provides QoS functionalities to allow setup of QoS VCs by manual configuration or management protocols (e.g. SNMP). When using EARTH for multicast and ATMARP for unicast address resolution with a certain reservation setup protocol, the behaviour for unicast and multicast communications does not differ significantly. The MIS concept has been described assuming an Internet environment with IGMP as the group management protocol and RSVP as the reservation set-up protocol operating well with IP multicast (receiverinitiated approach). Nevertheless, the QoS capability of the EARTH protocol allows the adaptation to other QoS models on IP layer.

Separation of address resolution/VC setup (layer-2) from QoS management (layer-3) RSVP is a layer-3 QoS signalling protocol to provide end-to-end QoS setup in disparate networks. EARTH is a layer-2 signalling protocol which provides layer-3/layer-2 address resolution and triggers admission/setup of layer-2 data paths. The two protocols and their respective functionalities are separated as far as possible, yet co-operation is effective. The separation of layer-2/layer-3 protocols is also important with respect to a modular implementation, which supports the capability to use other service models than these supported by RSVP.

Co-operation of the address resolution and reservation setup protocol The probably most important issue is the interoperation of both protocols within the MLIS, i.e. the sequence of events to setup a QoS point-to-multipoint VC. Synchronisation problems, resulting from concurrent operations with overlapping functionality of the layer-2 and layer-3 protocol have to be avoided. Few, clear interfaces were defined where information is passed between the two protocols.

Retain original functionality of standard protocols A major goal of RSVP/EARTH co-operation is to retain RSVP functionality as far as possible. However, as no QoS re-negotiation exists in UNI 3.0/3.1, a certain QoS granularity should be introduced for reservations across the ATM cloud. That means that receivers should choose one of several QoS levels with predefined parameters instead of having the possibility to change (at any time) the value of every specific parameter of its requested flow specification. Applications need to use an unmodified RSVP API, i.e. MIS operation have to be as transparent as address resolution to applications. The semantics of other RSVP interfaces (Traffic Control Interface, interface to multicast routing) are also used in connection with EARTH. In general, changes to the RSVP protocol and interface specifications are avoided since they are becoming stable standards.

4.7.4 Conclusions The architecture for the Multicast Integration Server provides increased efficiency, reduced layer-3 processing, reduction of the amount of identical data passing the switch several times, reduced VC consumption, and finally reduced reservation establishment delay, when compared to existing architectures. All these achievements are facilitated by major key design issues collected below from the above text and commented from a more generalised perspective.

Separation of data and control The separation of data and control paths over ATM seems to be inevitable for any IP control protocol supporting multicast due to the unidirectional nature of ATM pt-to-mpt connections. In the MIS architecture this has additional benefits arising from the fact that RSVP can re-use control VCs being maintained by EARTH clients.

13 RESV messages carry QoS requirements of receivers.

Why EARTH and not MARS ? The current IETF ION standard RFC 2022 does not support QoS and retains the Classical IP over ATM approach (an IP unicast protocol over ATM) to separate the ATM cloud to a number of logically disjoint subnets (clusters) which must consist of members of a single Logical IP Subnet (LIS) only. Complete mapping of the IP multicast service model to the ATM multicast service model would require bypassing of IP routers (shortcuts) in order to take the advantage of connecting all the ATM endpoints - receivers (whatever LIS they belong) with a single pt-to-mpt VC. The reduction of VC consumption with MIS (due to shortcuts) in comparison with hypothetical MARS (even if supporting the QoS differentiation) could be estimated as O (Q*N), where Q is the number of QoS levels and N is the number of receivers.

Another benefit when using EARTH protocol is the support for QoS. Additional advantage of EARTH (however referring to implementation only) is that it manages the VC establishment via the UNI 3.x signalling in such a way that the multicast data forwarding could be started from the [re-]sender even on not completely established pt-to-mpt VC. This fact brings additional savings to the join/leave/reservation latency.

The MIS architecture is open The MIS architecture is server-based and layered: it defines specific mapping procedures between RSVP and EARTH. The layer-3 RSVP is a consumer protocol with regard to the address resolution and data handling service provided by the layer-2 EARTH protocol.

In the MIS scenario, only QoS assured IP multicast requires limited and strictly specified collaboration between the protocols through the two interfaces (QSSI and eRSRR) supported by the EARTH; IP unicast could be supported by RSVP unicast over ATM which is combined with the legacy atmarp.

On the other hand, any other resource reservation protocol can use information provided by EARTH in order to get the receivers' NSAP addresses for an IP multicast session and to use the QSSI in order to set the desired QoS state for any of these receivers. Furthermore, this information can be used for allocating the costs for the individual receivers if a cost splitting tariff model is used.

The MIS is open also for the inclusion of any policy admission control, network management or security modules.

Remote capacity admission control Because of the separation of IP data and IP control paths over ATM the question of regulating arises between the place where the reservations are collected and merged (MIS) and the place where the capacity admission control is applied (sender(s)). This problem is solved via the modification of the original EARTH protocol (the EARTH_qos_notify message was added). Therefore this solution is safe with regard to the "standard" operation of RSVP and provides timely updates for the EARTH data base, which data base could be safely used by other consumer protocols.

Scalability Major scalability issues depend on the MIS-centric organisation of the MIS architecture. A single server both for multicast address resolution and for QoS management may become a bottleneck if the ATM cloud size grows. On one hand, some solutions to efficiently face the scalability of the EARTH protocol are proposed in the draft [Smir-97]. On the other hand, no scalability matters are due to the RSVP protocol, as the distribution of the RSVP signalling messages is organised on the base of the EARTH control connections.

References [RFC2022]G. Armitage: Support for Multicast over UNI 3.0/3.1 based ATM Networks, IETF RFC 2022, November 1996 [RFC2205] L. Zhang, R. Braden, S. Berson, S. Herzog, and S. Jamin. Resource ReSerVation Protocol (RSVP) - Version 1 Functional Specification. IETF RFC2205, September 1997. [RFC2379] L. Berger. RSVP over ATM Implementation Guidelines. IETF RFC2379, August 1998. [RFC2380] L. Berger. RSVP over ATM Implementation Requirements. IETF RFC2380, August 1998. [RFC2381] M. Carrett, and M. Borden. Interoperation of Controlled-Load Service and Guaranteed Service with ATM. IETF RFC2381, August 1998.

[RFC2382] E. Crawley, L. Berger, S. Berson, F. Baker, M. Borden, and J. Krawczyk. A Framework for Integrated Services and RSVP over ATM. IETF RFC2382, August 1998. [SaCS97] L. Salgarelli, A. Corghi, H. Sanneck, and D. Witaszek. Supporting IP Multicast Integrated Services in ATM Networks. Proceedings of SPIE VV'97 - Broadband Networking Technologies, Dallas, Texas, November 1997. [Smir97] M. Smirnov. EARTH - Easy IP multicast Routing Through ATM clouds. Work in progress, IETF Internet-Draft , March 1997.

4.8 PeterPan 4.8.1 Project description The PeterPan project, whose name is an acronym for ´Provision of an Enhanced Transport by Exploiting Reservation in IP and ATM Networks`, is one of the projects activated in the framework of the ACTS European Program.

The Project consortium accounts for companies representative of the major players in the evolution of the world wide communication infrastructure, namely network operators, Telecom and IT manufacturers, and also relies on the co-operation of research centres and universities, traditionally leading the research on Internet issues. Given the intrinsic world-wide scope of issue addressed, the project has deemed it appropriate to assume a perspective as wide as possible, involving partners not only from Europe (Italy, UK, Greece, and Portugal) but also from overseas (USA), where one of the trial islands is located. This section will present the project perspective, the goals it aims to achieve, and an overview of the results currently obtained.

4.8.2 Internet and Telecom Networks Evolution PeterPan work founds its rationale on the widely accepted assumption that in the traditional telecommunications world, the technological push to multimedia has been given by the development of ATM. The importance of ATM as the basis for the development of new markets towards the users is also demonstrated by the intense activities in the standardisation arena, to which the development of dedicated industry forum is a corollary. The technique attracts the attention of the traditionally non- telecommunication players, such as the IT industry. Convergence from a technological point of view will also have to take into account these aspects.

The second fundamental basis over which PeterPan builds is the observation of the astonishing growth of the Internet, and the more and more relevant role in the life, either in business or in private affairs it is having.

Above all, as third elements considered, the evolution of multimedia applications is a reality, and the integration of different ´media` and technological carriers smoothes the differentiation between the telecommunications and IT industries.

Due to the increasing quality of service request from the Internet community, the traditional best effort IP protocol is simply not able to satisfy the strictest user needs in terms of quality. In order to face this problem, the IETF task force elaborated a new service model, referred to as ´Integrated Service` which accounts for two more service classes in addition to the best effort, namely, Guaranteed Service and Controlled Load. In addition the RSVP protocol has been defined as a signalling protocol over IP that handle QoS-aware application needs, e.g. bandwidth and delay.

In terms of ATM, it is not surely foreseen to migrate all IP-based applications to native-ATM solutions or vice versa; it is more realistically expected that both protocols will be used, in the mid term, for different cases. In these conditions, it is foreseen that in future the Internet must have capability to handle with efficiency persistent IP flows, originated by QoS-aware applications. However, this traffic will be a fraction (even relevant) of the total traffic flowing through the ATM network, as, due to flexibility of the ATM, other types of traffic will co-exist, namely native ATM and other types of non-IP traffic.

The PeterPan Project has as its main objective to identify and develop an integrated functional architecture for core network devices which will ensure:  Avoidance of duplication of functionalities between IP and ATM  Maximisation of efficient use of resources for both IP and ATM

In addition, PeterPan performs:  Comparison of IPv4 and IPv6 over ATM in presence of QoS-sensitive applications  Accurate characterisation of IP over ATM traffic  Development of specific measurement and traffic modelling techniques

4.8.3 PeterPan network concept In order to handle IP flows in an ATM network, Integrated IP-ATM nodes have to be developed. They will be flexible and efficient in order to change the resource allocation for IP traffic, mainly generated by QoS-aware applications. They also should associate IP flows to the ATM QoS classes.

The following figure shows a view of the PeterPan network concept.

IPv4/IPv6 subnet RSVP flows mapped to PED separate VCs. No flow IP/ATM IP/ATM aggregation. Edge ethernet Edge Networks Networks

RESV PATH Core ATM ATM RESV ATM switch Network switch ethernet RESV RESV HED ATM ATM HED switch switch ATM ATM subnet ATM sig. HCD ATM sig. PATH

PATH PATH

RSVP info mapped to ATM signalling semantics. RSVP flows may be HED - Hybrid Edge Device aggregated HCD - Hybrid Core Device PED - Pure RSVP-IP Edge Device

Figure: A View of the PeterPan Network Concept

A role for the pure RSVP/IP node in terms of measurements and experimentation can be seen, but within the network concept, the concern of the project is more with defining the roles of the Hybrid Edge Device (HED) and the Hybrid Core Device (HCD). The PeterPan network concept consists of an ATM core network connecting both ATM based and non-ATM based (e.g. Ethernet) subnets. The role of the HED is to present the traffic originating from these heterogeneous edge networks, to the core ATM network. The HED performs standard routing actions and runs routing protocols, but within PeterPan its additional relevant role is to map RSVP flows to distinct VCCs on the outgoing ATM interfaces.

The core ATM node after the HED may be a Hybrid Core Device (HCD) or a normal ATM switch. In the case of it being a normal ATM switch, ATM cells are switched to the HCD along the ATM VCC which connects HED with HCD; note that the connection from HED to HCD can obviously pass through pure ATM switches. In fact, the HCD (which according to the ordinary IP architecture is fully seen as a router) is the ´next hop router` to which the HED (or any (Edge) Router) forwards its traffic according the regular routing rules. In a more complex core network architecture, with more than one HCD (router) the traffic can be forwarded along different routes across the network.

As shown in the figure, the HED device is in control of setting up connections between itself and the HCD, following the direction of the PATH RSVP messages, according to RESV requests it receives from downstream. Accordingly, the core device would then be in charge of aggregating the RSVP flows, and setting up the remaining portion of the connection, i.e., the HCD performs the signalling that sets up the VCCs to give a path through the core network. It is even possible, in theory, that all nodes within the core network could eventually contain the functionality of the HCD.

The HCD has a number of distinct features. Firstly, it is capable of dealing with switching pure ATM, i.e. it is designed for a scenario where native ATM as well as RSVP/IP capable applications exist. Secondly, it may aggregate separate RSVP flows onto the same ATM connection, a feature considered important in terms of addressing the problem of scalability inherently found with RSVP. Separate RSVP flows with the same QoS requirements and traversing the same path would be obviously candidates for aggregation.

In conjunction with the ´trunking` of IP flows, the HCD should be able to perform QoS based routing, an issue that will be addressed at least theoretically by the project, even if possibly not practically experimented.

The project concentrates on the elements which integrate IP and ATM, namely upgrading non-native- ATM applications running in user terminals, and addressing the hybrid IP-ATM Edge (HED) and Core (HCD) network devices.

In terms of functionality, both the Hybrid Edge Device (HED) and the Hybrid Core network Device (HED) have to perform the following:  mapping of RSVP signalling messages to B-ISDN signalling messages  mapping of RSVP parameters to ATM traffic classes and associated ATM Traffic Descriptor  IP classifying  IP scheduling  QoS routing  development of RSVP middleware within the host applications.

4.8.4 Cross-Connection and Trunking Concepts When the reservation message flows through the network, several ATM connections are set up between the various network elements. Therefore, corresponding to the request of reservation for a single IP flow, several ATM connections have to be established and maintained, increasing the delay to set up the complete path and with a high utilisation of network resources. In addition, in each HCD, the IP flow is rebuilt up to the UDP/TCP layer in order to filter the flow on the basis of the QoS requested.

In order to increase the efficiency of the whole mechanism and to provide a more accurate utilisation of network resources, PeterPan will experiment the cross-connection (or short-cut) and the trunking functionality.

The cross-connection (or short cut) permits to bind connections related to the same IP flow so to avoid to rebuild the flow up to the TCP/UDP layer. It is possible to realise a cross connection in a HCD when the following conditions are verified:  The incoming connection (with the previous hybrid device) and the outgoing connections (the next hybrid device) are related to the same IP flow. The flow information of the call is known when RSVP Resv message requires the resources. For the incoming call, the flow information can be received explicitly in the set up message. Otherwise, it can be derived by monitoring the incoming IP flows for each connection;  The incoming connection and the outgoing connections have the same values of quality of service parameters.

We speak about trunking, when an ATM connection carries different IP flows. From the user plane point of view, the pull of connections is seen as a single end-to-end ATM connection. The aggregation of different IP flows on the same ATM connection can be done considering mainly two different criteria:  On the basis of IP address of the receiver, in this case the ATM connection carries IP traffic related to a single destination;  On the basis of next hop IP Address, in this case the ATM connection carries IP traffic of several destinations.

In addition, the rules to merge IP flows on a single ATM connection should take into account the quality of service requirement.

4.8.5 Project current assessment At the end of the first out of two project years, PeterPan is currently running in the middle of a process started with the definition a functional architecture for the efficient support of IP over ATM, and will end up with practical evaluation, by means of trials, of the solution implemented.

Starting from the network concept as illustrated above, the project has completed the detailed definition of specific functionality needed for the efficient handling of traffic flows, and is now working on the implementation of the user and control plane of the hybrid nodes. Also, it is implementing the necessary RSVP middleware for common multimedia applications.

Field trials in different islands are planned in the second project year to demonstrate the convenience of the approach taken; the results will be evaluated to derive conclusions on the performance of the integrated network.

All this process is continuously sustained by an intense traffic and performance evaluation activity, which has supported since the beginning the selection of system alternatives, and is now in charge of the definition of relevant measurements, and will finally carry over the analysis of traffic characterisations resulting from experimental activity.

4.8.6 Project trial configuration The project foresees one trial period, in the second project year. The trial will start with commercial equipment, upgraded with project defined functionality, which, in some of the trial sites, will be progressively integrated with equipment coming as result of development activity carried out by the project.

The experimental platform consists of a number of islands, located in different countries and providing access to real users. However, users, although ´real`, are basically ´friend users`, and not generic subscribers of public telecom networks.

Trial islands are in Italy (Milan and Pisa), in UK, in Portugal, and in USA, as shown in the following figure. The PeterPan philosophy is pursued in all the experimental islands, with different emphasis on specific aspects in each island.

IP & ATM users groups HCD prototype (HED) QoS-aware IP mapping to ATM using Signalling Lancaster Trunking / Short-cut IMR, Videotelephony Local ATM environment RSVP apps. by NTUA IPv4 .vs. IPv6 Gigakit network Multimedia serv. with QoS

Los Milan Angeles Lisbon Pisa

Flexible-programmable ATM nodes Local ATM environment IP & ATM LAN Connection to NSF Gigakit net. QoS-aware-IP mapping to Traffic measures IP-over-ABR/VPC, QoS routing ATM using Signalling Telemedicine Virtual world, telemedicine, MM IP scheduling

Figure: Trial sites

The islands will perform experiments to test the effectiveness of the solution identified within the project. Each island can guarantee by itself a sufficient environment to run a full test of the new functionalities, but nevertheless, experiments over a wider environment across Europe are not excluded.

The focus in the Milan island is to develop and experiment a prototype of an integrated IP-ATM node, with specific attention to:  mapping of RSVP messages to B-ISDN signalling messages

 mapping of RSVP RESV traffic parameter to ATM Traffic Class and associated Traffic Parameters  efficient IP forwarding in the IP-ATM node  use of IP trunking and short-cut

Within the Pisa island, focus is on experiments involving measurements at both IP and ATM levels, with specific attention to:  QoS mapping between IP and ATM, for sensible applications (like Tele-Medicine)  Development of suitable middleware code to include RSVP awareness into existing medical applications.

At Lancaster, focus is on measurement experiments (in co-operation with HP Labs) on a subset of existing IPoverATM campus network, with specific attention to:  IPv6 vs. IPv4 over ATM  IPv6 and RSVP over ATM

Focus at Lisbon island is on experiments on a RSVP upgraded commercial equipment, with specific attention to:  IP scheduling  RSVP to signalling mapping

Finally, focus at UCLA is on the adaptation of programmable IP-ATM nodes, deriving from an NSF Project (the Gigakit Project), with attention to experiments on:  QoS routing  mapping of IP flows over ATM Traffic Classes and appropriate Traffic Descriptor.

Set-up of trial islands has started recently, and trial are planned to start with the spring 1999.

4.9. SUSIE - Charging and Accounting for QoS-enhanced IP Multicast The AC-320 project SUSIE deals with the development of a charging approach for QoS-enhanced IP services or premium IP services provided over ATM. This includes the development of charging schemes as well as the design and implementation of the charging systems. The charging approach is evaluated and validated in the SUSIE trials. In the following, selected achievements of the SUSIE project related to Next Generation Internet are presented.

A reference model for a charging and accounting service has been defined. The model can be configured to meet requirements of both IntServ and DiffServ. An initial implementation, called VIPCAS (Value Added IP Charging and Accounting Service), has been started within the SUSIE project.

4.9.1 Charging and Accounting Reference Model SUSIE developed a reference model for classifying charging, accounting and closely related processes, and for describing their interaction (see Figure 1). At the right, five layers are shown that encompass processing for charging and accounting. A configuration plane allows for providing configuration parameters for the processing layers.

The configuration can be done on-line using signalling, as for Integrated Services, or off-line using management tools, as for Differentiated Services. Configuration parameters are derived from pricing policy, accounting policy and metering policy. These policies are provided by interaction of dedicated servers with the corresponding entities of the configuration plane.

The metering layer performs metering of resource usage. Metering must allow to distinguish the two types of network resource: reservation of network resources, and actual usage of network resources. This distinction is useful as resources that are reserved but not used by a user may be offered to a different user, but usually under different conditions (lower price). Charging schemes may reflect this difference, e.g. by charging separately for reservation, and for actual usage. In case of multicast, depending on the cost sharing schemes, the meters can be placed at the edge routers only or also at the splitting points.

The meter reader layer encompasses functional entities that access data provided by metering entities and forwards it for further processing to the Accounting Processing Layer. For supporting multicast charging, this layer is also responsible for selection of appropriate meters (meter placement). Transfer of metering data to the meter reader can be initiated explicitly (the meter reader initiates transfer of metering data) or implicitly (after a triggering event such as detection of a new flow, the meter initiates transfer of metering data to the meter reader).

Entities of the accounting processing layer process usage data collected by meter readers, try to consolidate them based on service parameters and create accounting data sets (i.e., accounting records) which will be passed to the charging layer for pricing assignment. For supporting multicast charging, this layer is also responsible for reconstructing the multicast topology including splitting points where required by the cost sharing scheme. Additionally, the layer is also responsible for distributing collected usage data to other domains in a multi-provider environment.

The charging layer derives costs for accounting data sets based on service specific tariffing parameters. Different cost metrics may be applied to the same usage of resources, and may be evaluated in parallel. A detailed evaluation of the resource usage can be used for generating bills to the customer, or for internal analysis (auditing) by the service provider. A simple evaluation of current costs can be used for displaying an estimation of accumulated costs for the service user, or for control purposes by the customer organisation or by the provider. For charging of multicast services, cost allocation assigns costs to specific endpoints, such as sender(s) and receivers of a multicast group.

The billing layer translates costs calculated by the charging layer into monetary units and generates a bill for a customer. This process may combine technical considerations with economic considerations, such as volume of resources used by the customers, and marketing methods (e.g. offered discounts).

User Specific Billing Layer Pricing Tariffing Parameters e

Policy n a Service Specific l Charging Layer P Tariffing Parameters n o

Accounting i

Accounting t Accounting Processing a Policy Parameters r Layer u g i Meter Reader f n Meter Reader Layer Metering Parameters o C Policy Metering Parameters Metering Layer

Figure 1: Charging and Accounting Reference Model

4.9.2 Value Added IP Multicast Charging and Accounting Service (VIPCAS) Based on the reference model introduced in the previous section, SUSIE introduces an architecture for implementing a charging and accounting service, extending the architecture presented in [CaSZ98]. Figure 2 shows a sample architecture designed to support this service referred to as VIPCAS (Value Added IP Charging and Accounting Service). Despite its simplicity, the architecture provides generic components to build a more complex platform for charging and accounting service. In explaining the architecture we show how the layers of the CA reference model introduced in the previous section can be realised.

In this architecture, metering takes place only at the edge routers of the provider domain. This allows for core routers to be simple and fast, while more complex metering tasks can be limited to edge routers. The SUSIE platform uses a meter that is conformant to the Real Time Flow Measurement Architecture (RTFM) of IETF [RFC2063, BrMR98]. For the configuration of a meter and for the collection of data, SNMP is used with a special meter MIB [RFC2123].

Billing TINA Accounting Charging

PIP NAR TCP PIP NAR (to other domain) UMS Accounting Meter Reader

Egress Router SNMP Meter

Meter Meter Core (Interior) Routers Egress Router Ingress Router

Provider Domain

Figure 2: Generic CA Architecture

The data from the meters is collected by a meter reader. An accounting data structure is filled with the collected information by the accounting layer. For transporting the collected information to the charging layer, we have specified a data structure, referred to as PIP-NAR (Premium IP Network Accounting Record), as discussed in the next section.

Since filling of accounting data structures can be done immediately after metering data has been collected, our solution combines meter reader and accounting functions in a single entity, the usage metering server (UMS).

Filled PIP-NARs are forwarded to a charging server where a charging scheme is applied to the data. In our implementation, the charging server is implemented within a TINA/CORBA based accounting system. The UMS passes the accounting data to the TINA accounting system through an interface, called TINA Gateway, which has been defined within this SUSIE project (see section on TINA Gateway).

Within the TINA accounting system, subsequently calculated charges are passed to a billing server, where information about network related charges is used together with additional tariff information (user information, discounts, etc.) to generate bills and to prepare current billing information for users in real-time (hot billing).

4.9.3 Premium IP Network Accounting Record (PIP-NAR) The PIP-NAR data structure contains reserved and used resources for an IP flow. It carries a measurement point identifier and a record description to support different styles of PIP-NARs (unidirectional/bi-directional, DiffServ/IntServ style, and others). For unique identification of the flow, a flow description is used. A detailed specification of the PIP-NAR can be found in [ETSI98].

Measurement point identification Record Description Flow Description Reserved Resources Used Resources Data Extension

Figure 3: Basic Elements of the PIP-NAR

The semantics of the reserved resources section differ for the Integrated Services model and for the Differentiated Services model. Used resources contain the data volume and the number of transmitted packets. The PIP-NAR record format is extensible, where future metrics can be included in the Data Extension section using the TLV (type, length, value) syntax. Currently defined extensions are distance and burstiness.

4.9.4 TINA Gateway The TINA gateway provides an interface between the ´Internet world`, where usage metering data is collected, and the ´TINA world`, where the collected information is charged. The TINA gateway provides the following functions:  Collect data from network nodes (UMS)  Pre-process data if necessary  Fill PIP-NAR  Pass PIP-NAR to TINA accounting

Two logical entities are defined, which can either be co-located in one physical device or reside in different physical devices (Figure). The Usage Metering Server (UMS) takes over the meter reader functions, the pre-processing of data and the filling of the PIP-NAR structure. It then communicates the PIP-NAR to a CORBA Client (CC). This CORBA client provides an Internet style communication mechanism, like a TCP connection. Since the CORBA client is already part of the TINA/CORBA system, it can easily forward the data to the accounting system by using CORBA.

TINA Accounting

CORBA CC PIP-NAR TCP

UMS Processing

SNMP/TCP/CAP

Meter Meter MIB Flow Table

Flow1: #Pckts =012 Rules Flow2: #Pckts =01

IP Packet Flow

Figure 4: The TINA Gateway: Basic Architecture The UMS fills PIP-NARs with the provided information. Since the data reported from the network are mostly not presented in the form of the PIP-NAR, some pre-processing might be necessary in order to fill the PIP-NAR structure. Furthermore, some parameters should be calculated in the UMS, because they depend on the combination of records from several locations (e.g. distance) or measurement times (e.g. burstiness). In order to calculate these parameters, it is necessary to store information from previous records in the UMS. If parameters can not be calculated, the field in the PIP-NAR is marked unknown.

As shown in figure 4, different communication mechanisms can be used for passing the usage metering data to the UMS. One possibility is to use SNMP. In [RFC2063], the Real Time Flow Measurement (RTFM) working group, within the IETF, has defined a specialised meter MIB which can be used for the collection of accounting relevant data. An extension for the monitoring of RSVP messages is defined in [Maic98, HaBR98]. The work of the RTFM group provided a useful framework for the implementation of the UMS.

We use the Network Traffic Meter (NeTraMet) metering software [Brow97, RFC2123] as the basis for the monitoring of accounting relevant data. NeTraMet conforms to the accounting architecture defined by the IETF Real Time Flow Measurement WG [RFC 1272, RFC2063, BrMR98]. The interaction between the meter and the meter reader is based on SNMP. The NetTraMet meter is a stand-alone SNMP agent and stores the measured data in a meter MIB defined in [RFC2064, Brow98b]. Several extensions already exist, like a specialized version for using Cisco’s netflowd [Brow98c] and an extension for monitoring RSVP states [Maic98]. Further extensions are planned [HaBR98]. The rules

85 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 for the pattern matching process in the meter are given in special rulesets [RFC2063]. For simplification of the creation of rulesets, a Simple Ruleset Language has been developed [Brow98a].

4.9.5 Summary In the first operation year of SUSIE, we have defined a reference model and implemented a charging and accounting architecture based on the reference model. The architecture allows its components to be configured for meeting charging and accounting requirements of IntServ or DiffServ in unicast or multicast scenarios. A data structure, the PIP-NAR, has been defined for the implementation. This data structure is used for transporting usage information from an accounting processing entity to a charging entity, and allows exchange of accounting information in multi-provider scenarios.

Future work is planned for extending the RTFM-conformant metering components, and for deploying and testing the architecture within a multi-provider environment. For this purpose, the PIP-NAR data structure will be used by the accounting processing layer to exchange usage information among different providers.

REFERENCES [BrMR98] N. Brownlee, Mills, G. Ruth: Traffic Flow Measurement: Architecture. Work in progress, IETF Internet draft , September 1998 [Brow97] N. Brownlee: Reference Manual NeTraMet & NeMaC Version 4.1, Information Technology Systems & Services, The University of Auckland, New Zealand, November 1997 (http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html) [Brow98a] N. Brownlee. SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups. Work in progress, IETF Internet draft , September 1998 [Brow98b] N. Brownlee. Traffic Flow Measurement: Meter MIB, Work in progress, IETF Internet Draft , September 1998. [Brow98c] http://www.auckland.ac.nz/net/Accounting/ntm.Release.note.html [CaSZ98] G. Carle, M. Smirnow, and T. Zseby. Charging and Accounting Architecture for IP Multicast Integrated Services. In Proc. of the 4th International Symposium on Interworking (Interworking'98), Ottawa, Canada, July 1998. [ETSI98] H. Orlamünder (Editor). Parameters and Mechanisms for Charging in IP based Networks [Network Aspects]. TR/NA-080301 V1.0.4 (1998-06), ETSI Working Group NA8 Technical Document, 1998 [HaBR98] S.W. Handelman, Nevil Brownlee, Greg Ruth, S. Stibler: RTFM Working Group - New Attributes for Traffic Flow Measurement, Work in progress, IETF Internet draft , October 3, 1998 [Maic98] A. Maiocchi. NeTraMet & NeMaC for IIS Accounting: User’s Guide, CEFRIEL, Politecnico di Milan, May 1998. [RFC1272] C. Mills, G. Hirsch, G. Ruth: „Internet Accounting Background”, RFC1272, November 1991 [RFC2063] N. Brownlee, C. Mills, and G. Ruth. Traffic Flow Measurement: Architecture. IETF RFC2063, January 1997. [RFC2064] N. Brownlee: „Traffic Flow Measurement: Meter MIB”, RFC2064, University of Auckland, New Zealand, January 1997 [RFC2123] N. Brownlee. Traffic Flow Measurement: Experiences with NeTraMet. IETF RFC2123, March 1997.

5. Next Generation Internet around the World

In many countries national initiatives have been set up for the deployment of Next Generation Internet technologies and applications. This chapter gives an overview of some of these activities, mainly in the context of the National Research Networks. The focus is on the developments in Europe but also activities in other parts of the world are included.

It must be emphasised that it is impossible to cover all relevant activities ´around the world` in the area of Next Generation Internet in such a publication. Thus this chapter just tries to give an overview of some typical and relevant developments without making any prioritisation or guaranteeing for completeness.

5.1 The Joint DANTE/TERENA Task Force TF-TANT The QUANTUM project follows on from the successful TEN-34 project. Between February 1997 and December 1998, TEN-34 provided the European academic and research community with a stable IP based pan-European network service. The main objective of the QUANTUM project is the continuation of this stable IP network service but at access capacities up to 155 Mbit/s. In parallel with the IP service, the continuation service known as TEN-155, provides a managed bandwidth service to the participating national research networks and other specific groups of users.

More and more co-operative development activities in Europe are based on the use of multi-media services, which are only effective if they can rely on high Quality of Service levels which cannot be provided on a loaded ´best efforts` IP network. Protocol enhancements such as RSVP and IPv6, as well as the Quality of Service management inherent in the ATM technology are addressing these issues. It is apparent that for multi-media services to develop on a pan-European scale a new approach to Quality of Service is required.

The QUANTUM Test Programme (QTP) has the objective of testing and validating new technologies, products and services with a view to introduce them into the operational TEN-155 service at some future date.

TF-TANT is a joint DANTE/TERENA task force in charge of carrying out the experiments of the QUANTUM Test Programme. For many of these experiments, it makes use of the facilities offered by the TEN-155 Managed Bandwidth Service (MBS). Experimentation under the label of QTP is co- ordinated by DANTE as part of the QUANTUM project which includes the TEN-155 network. The QUANTUM Project is co-funded under a joint initiative by DG XIII (Telematics for Applications, Esprit and ACTS) of the European Commission.

The Task Force shall primarily be composed of representatives of National Research Networks, but participation is open to any individual or representative of an organisation which can offer appropriate expertise, manpower, equipment or services.

The following areas of experimentation have been identified and will be worked upon. Additional work items are being discussed and will be included at a later stage. The following list is therefore not exhaustive and will grow during the lifetime of QUANTUM. The group's web page contains the list of experiments and will be kept up to date. It can be found at the following URL: http://www.dante.net/tf- tant.

5.1.1 RSVP testing RSVP and Integrated Service as defined within the IETF provide a framework for assigning QoS to flows within an IP network. QoS parameters are signalled by the RSVP protocol. Integrated Service defines Controlled Load Service and Guaranteed Service. The former providing basic bandwidth and the later additional delay characteristics. Tests will include multicast flows.

The set of tests should verify capabilities as defined in RFC2380 ´RSVP over ATM Implementation Requirements`. Scenarios for evaluating Controlled Load service can be found in RFC2211 ´Specification of Controlled-Load Network Element Service` and for Guaranteed Service in RFC2212 ´Specification of Guaranteed Quality of Service`.

The most direct approach for mapping RSVP/IS flows to ATM is to establish an ATM VC with QoS parameters reflecting the QoS parameters of the RSVP/IS flow. Lacking general ATM signalling capabilities in the QUANTUM network the tests will primarily verify proper queuing and packet scheduling. Along the lines mentioned in ´IP over ATM testing` it might be possible to use the VP approach and utilise signalling for VCs within the VP to  Verify RSVP interaction through the QUANTUM network,  Test Controlled Load Service compliance,  Test Guaranteed Service compliance,  Test proper handling of excess traffic,  Test that a reasonable balanced between best effort traffic and traffic on reserved flows is maintained both under light and heavy load of the network.

5.1.2 Multicasting (IP and ATM) Testing of new technologies and services that are needed with the evolution of the operational TEN- 155 Mbone. This includes:  Set-up of a monitoring and performance measurement environment on selected user premises and on backbone borders with emphasis on IP multicast routing monitoring and performance measurements,  Evaluation and test of Cisco’s- and GATED’s implementation of the Multicast Border Gateway Protocol (MBGP, also known as BGP4+)

The following further tests of advanced technologies which could be deployed in the near future are planned:  Ongoing and advanced tests for mapping PIM Sparse Mode to ATM point-to-multipoint connections in an ATM based backbone,  Testing of the Border Gateway Multicast Protocol (BGMP) which is currently implemented in GATED,  Evaluation of the Multicast Address Set Claim (MASC) protocol as soon as implementations are available,  Evaluation of native ATM multicast architectures over WANs and interconnected local ATM multicast architectures.

5.1.3 Differentiated Services The goal of the Differentiated Services (DiffServ) architecture is the enhancement of the IP protocol for the support of quality of service in a scalable manner, i.e. without relying on either signalling protocols or per flow state information. The DiffServ architecture supports both end-to-end and intra-domain reservations, and it has been designed for both parameters and class differentiation based requirements. According to the DiffServ architecture services can be implemented through the following components:  Packet classification at the edge of the stub DiffServ networks,  Packet marking or packet re-marking at network boundaries (the DS-Differentiated Services - field is used for the service identification),  Packet forwarding inside a given DiffServ domain according to the current content of the DS  Traffic conditioning at the network boundaries according to the requirements of each service, e.g. monitoring, policing and shaping

The following scenarios will be studied in this activity:  IP precedence based QoS mechanisms: Precedence based techniques could be considered as pre-DiffServ mechanisms. IP precedence tests give the possibility to divide traffic into different classes and to reserve an amount of bandwidth on a best-effort connection for a given class of IP traffic. IP precedence could be also regarded as a tool for the implementation of Europe wide VPNs.  DiffServ architecture: A network adopting the DiffServ approach to provide end-to-end guarantees will be put to test.  Mixed DiffServ-IntServ architecture: Mixed scenarios have the flexibility of the RSVP protocol and the scalability and simplicity of the DiffServ approach. The DiffServ mechanism can be used in the transit network, while the IntServ architecture can be used at the edge. The DiffServ part of the network may consist of one or more DiffServ domains.

5.1.4 RSVP to ATM SVC Mapping The goal of this experiment is to verify if the integration of the IP and ATM QoS mechanisms is viable and applicable for the support of applications devised by the academic and research community. The interest in this type of integration is manifold:  It fits to the TEN-155 network infrastructure and to the type of traffic, since the backbone is ATM based and applications are IP based.  For some National Research Networks the access to the backbone is IP-based, but with the integration of ATM and RSVP applications may still make use of the ATM QoS features in the backbone, while the access to the backbone is through RSVP.  According to the TEN-34 test programme results, SVCs can be deployed in a wide area ATM network and RSVP is now supported by several vendors, also the protocol standard development process has now reached its maturity.  It gives the possibility to make use of the ATM QoS features (even if limited to the backbone of the network) to a wider range of user applications.

Since the ATM QoS features need the support of the ATM signalling protocol in the backbone, the pre- requisite of this test is the existence of a stable ATM overlay network with UNI access points at the edge, or, if possible, supporting PNNI in the backbone. This implies the need of dedicated VPs for the tunnelling of a signalling protocol until the SVC service will not be offered in the backbone.

5.1.5 IP Version 6 The goal of this proposal is to provide the information needed to implement IPv6 connectivity as a service in the TEN-155 production network. The proposal consists of two parts:  An outline of how to implement the IPv6 backbone, identifying both technical and logistic issues that need to be addressed,  A description of the tests that will address the technical issues.

5.1.6 IP over ATM experimentation TEN-155 is using a combination of UBR-like (SBR3, SCR=~0 cells/s) ATM PVCs and CBR PVCs to carry at the same time and in a dynamic manner the best-effort IP traffic and guaranteed traffic for the MBS. Other traffic classes such as SBR3 with SCR 0, SBR2, and ABR together with the support of a built-in functionality in the end system may prove to more suitable for use on TEN-155. End systems should be able, for instance, to perform tagging of cells according to the parameters of the VC being used. This is essential in order to use SBR2. In theory SBR3 with SCR 0 could be used to enable to peak to full line rate if bandwidth is available, and at the same time guarantee SCR in cases of congestion. This mechanism needs to be thoroughly tested on the Ascend switches before it may be deployed. ABR is also a promising mechanism to carry best effort IP traffic, in this case though support on end systems needs to be evaluated.

The main goal is the identification of the best combination of ATM Transfer Capabilities (ATCs) for co- existence of best-effort IP traffic and dedicated ATM VCs for other purposes. Efficient usage of bandwidth and fair sharing among competing bandwidth users are important success factors. The main tasks are:  Understand the theory of each ATC  Identify possible use of each ATC and co-existence issues with other ATCs  Evaluate feasibility of testing on TEN-155  Evaluate developing technology or ATCs

5.1.7 Policy Control (IP and ATM) With the provisioning of QoS at the user, user group or even application level, Policy Control is becoming an integral part of networking services provisioning. To provide QoS at a specific level, e.g. user group level, one must be able to identify that entity. Based on that identification and the QoS policy for that identified entity, the Policy Control service will grant/deny specific service requests. The identification service itself is not covered by this activity, but the relation to the Policy Control service must be studied! The Policy Control service that possibly emerges from this activity, will be used in the activities on integrated and differentiated services and activities including SVC services to control who/what gets which part of the (scarce) bandwidth. The bandwidth broker model will also be studied as part of this activity. The work will concentrate on:  Study the relation between Policy Control protocols/servers and IP services like Integrated and Differentiated Services  Study the relation between Policy Control protocols/servers and SVC services in the ATM environment  Test available implementations of Policy Control servers  Evaluate the usefulness and provisioning aspects of Policy Control

5.1.8 Route Monitoring The RATool set (The Routing Arbiter project tool set from Merit) is a set of applications allowing the analysis of the real Internet routing tables (about 51 000 entries now) and compare them with the registered routing policies, evaluation of the different routing possibilities in the case of the lines outages, checking the current routing, monitoring of the routing updates without massive involvement of router processor etc. The tool set runs on several platforms, the most used one is the SUN workstation.

The main goal of this activity is to create a tool for the operational BGP routing stability monitoring and to check the routing tables against registered policies.

Operators of research networks have been using different methods of traffic measurements for purposes of general network health monitoring, long-term traffic planning, fault diagnosis, and in some cases charging. The following phases are planned:  Evaluate the performance and usefulness of the RAToolset,  Definitions and plans for the development of the monitoring tools suitable for our purposes,  Planning of the possible application in the production network.

5.1.9 Flow-based Monitoring Analysis Recently, new mechanisms have been proposed which provide accounting data based on flows in real or near-real time. A flow is a sequence of packets, identified by source and destination transport layer addresses so that usually it corresponds to a session between two applications. Information gathered about a flow can include transport protocol, transport layer addresses, number of bytes and packets transferred, times of first and last packet seen, IP TOS/DS field information and other parameters which are common to the flow. The main tasks of this activity are:  collect requirements for flow-based traffic analysis,  develop test environment,  evaluate existing software,  suggest deployment scenarios,  develop new applications.

5.1.10 QoS Monitoring In the QUANTUM Test Programme three main QoS architectures will be considered: ATM, RSVP and Differentiated Services. Also mixed architectures will be tested: RSVP-ATM, RSVP-DiffServ and ATM- DiffServ. For each scenario a proper set of monitoring tools should be identified and tested. QoS monitoring requires an underlying network configuration for QoS support and vice versa: QoS monitoring is necessary to validate a QoS support mechanism. The proposal is therefore to run this test in parallel with each QoS test of QTP, when possible.

QoS parameters will be IP-based when at least one network segment on the end-to-end path relies on IP-based QoS support mechanisms. QoS parameters will be ATM-based when end systems rely on native ATM connections or when at least a segment of the end-to-end path is an ATM and QoS monitoring is limited to that segment.

The definition of IP performance metrics is under development at the ´IP Performance Metrics (IPPM)` working group at IETF. The goal of this group is to provide a formal definition of parameters defining the IP traffic performance. The parameters currently under study are: one-way delay, round-trip delay, instantaneous packet delay variation, one-way packet loss, bulk transport capacity (BTC) and connectivity. When the first RFCs will be available, IPPM compliant implementations and applications should be deployed to probe the network.

5.1.11 MPLS The label-based switching is a technique based on an integration of layer 2 switching and layer 3 routing. This technique has been designed for high speed networks to use in a more efficient way the performances of switching with the scalability and flexibility of IP routing. Main tasks are:  Study of the MPLS IETF activities,  Survey of existing implementations,  Experimentation of available solutions,  Cisco Tag Switching,  If possible, other technologies,  Test the interoperability of available solutions.

5.1.12 VPNs Virtual Private Networks are becoming more and more important (like extra-nets over WANs, working at home, QBone related services). First of all it is important to know what the features are of IP VPNs and how they will effect the IP wide area networks. Also the interaction on generic services like identification/authorisation and accounting is important, so that these generic services can be placed at the correct logical location in the WAN and/or LAN. The generic services are not the main issue, it is the use of these generic services within the VPN concept:  Get knowledge on the standardisation/implementation status of VPNs in IP networks,

 Get an idea what the effects of VPNs are on the wide area IP networks (are VPNs going to influence WANs [like due to IP protocol bits] or only access to LAN/MANs),  Study the security issues (identification, authorisation, accounting and encryption) that are particular to VPNs,  Determine the use of and policies on VPNs in national networks,  Get some idea about possible policies that float around in NRNs on VPNs,  If WAN issues are involved in VPNs, initial testing of VPNs in the TF-TANT network environment.

5.1.13 Wave Division Multiplexing (WDM) Wave Division Multiplexing is an emerging technology to get high bandwidth on a single fibre (pair), up to at least 640 Gbit/s. With this technology it is possible to transport IP over SDH over WDM (the present way of doing it) and, in the future, IP over WDM. This activity will primarily streamline experience exchange gained from national or local environment. There will perhaps not be many possibilities to test WDM on international fibres (although there is perhaps a BE-NL fibre possibility), but at least information exchange will take place on how to connect routers/switches (interfaces: IP over SONET over WDM or IP over WDM) in a NRN environment to WDM equipment (like WDM repeaters, OADM (Optical Add and Drop Multiplexers), OXC (Optical X-cross Connects)). Discussions will take place on the type of fibre needed (´normal` or ´zero dispersion` type). This activity will concentrate on:  Exchange information between the participants on the use of WDM in WAN-networks,  Test WDM in a small environment on international links (if possible!!! otherwise LAN/MAN environment),  Get an idea on fiber quality, management and resilience issues of WDM provision.

5.1.14 STM-1 vs STM-4c It seems that a lot of connectivity providers in Europe, provide their SDH services over equipment that is not able to offer concatenation of multiple STM-1 channels (to realise ONE clear channel). This leads to the effect that if one wants a clear channel of 644 Mbit/s (STM-4c) between two routers this is sometimes not (yet) possible to get. In most instances this will be a STM-4 link which is in effect 4 separate channels of 155 Mbit/s (and the equipment on this STM-4 will have to do the multiplexing and de-multiplexing). This activity should provide stimuli for the SDH connection providers and routers/switches manufacturers to implement concatenation in their equipment and perform the following tasks:  Determine what the effects of SDH implementations (mainly concerning concatenation) will have on aggregated traffic over these SDH links.  Make international/national/intercontinental SDH providers aware of the problems concerning the lack of SDH concatenation implementations.

5.2 Gigabit Testbeds in the German Research Network

Jürgen Rauschenbach, DFN-Verein, Germany

5.2.1 Overview The section gives an overview of information about basic concepts, technical structures, current status and planned extensions of the implementation of gigabit-testbeds for the DFN-community. Besides of these testbeds some more projects are mentioned in the context of building a new generation network in Germany.

The German research network B-WIN (Broadband-Wissenschaftsnetz) provides mainly IP services to the customers. ATM services (PVCs) are available on request. The B-WiN is based on an ATM infrastructure provided by the Deutsche Telekom (cross-connect, central service switches). The attached IP equipment (central routers and WiN routers) is managed by the DFN NOC. The customer access speed is in a range of dial-in (modem or ISDN) up to 155 Mbit/s. For further information see http://www.dfn.de/win.

Right after the start of the B-WiN in spring 1996 the DFN Association initiated projects in preparation of the next generation B-WiN: the so-called gigabit-testbeds (GTB). The GTB's are the framework for

91 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 gathering technical experience in the high speed area and for the development of new kinds of applications with extreme bandwidth demands to open innovative network appliances.

5.2.2 Network-oriented Work Packages The network-oriented work packages include the following topics:

1) Usage of OC-12 and OC-48 data links between switches and end systems. This includes e.g.:  interoperability tests,  measurements of delays, throughput, jitter etc.,  validation of end-to-end capabilities via heterogeneous systems,  management aspects of a gigabit network,  firewall technology in the high speed area.

2) To introduce and test the very advanced capabilities of WDM-technique (Wavelength-Division- Multiplexing): The WDM-technique offers the possibility to have several ´paths of light` within one optical fibre, thus multiplying the transfer capacities of an optical fibre. The WDM-technique includes a lot of new problems, e.g.:  stability of WDM-equipment,  usage of multiple optical amplifiers,  usage of optical add/drop-multiplexers to add or subtract single ´paths of light`,  usage of different wavelengths for different protocols (ATM, HiPPI, ...),  protection and restoration technology. There is a large range of very electrical/optical aspects up to management problems to solve.

3) IP in different protocol stacks:  Classical IP over ATM with 622Mbps and more,  Gigabit-Ethernet,  IP over glass,  QoS issues.

5.2.3 Application-oriented Aspects The application-oriented aspects are: Advanced applications with high throughput needs and high Quality of Service requirements with respect to real-time conditions will be introduced into the GTBs. This includes application support issues (middleware).

Both research areas, network technique and new applications, depend on each other. The provision of high networks is necessary to run the projects; the new style applications will influence the needed bandwidth in a next generation network.

5.2.4 Operational Gigabit Testbeds Currently the following two DFN-GTBs are operational:

GTB-West: Since August 1997 the GTB-West has connected two research laboratories in Nordrhein- Westfalen (GMD St. Augustin and Research Center Jülich). The optical fibre is provided by one of the new carriers (o.tel.o). Several large computers (CRAY T90/12, Cray T-3E/512, IBM SP2, NEC Cenju- 3, Parsytec Power Explorer) are interconnected and a set of applications with simulation and visualisation needs are realised, e.g.:  to calculate the spread out of environmental damages (pollution); algorithms for the magnetic enzephalographie of human brain,  to implement complex visualisation tools; distributed calculation of climatic model,  to develop methods and tools for supercomputers.

The GTB-West started with 622 Mbit/s in August 1997, the capacity was upgraded to 2.5 Gbit/s in August 1998. Also in August 1998 new ATM-Switches (FOREASX-4000) with 2.5 Gbit/s-Interfaces were successfully installed. The extension to the city of Cologne links the University of Cologne and the Art School for Media to the GTB infrastructure. A virtual TV production project and a traffic simulation project with different ways of visualisation based on multicast were started in addition to the already mentioned projects.

GTB-Bavaria/Berlin: This GTB was started with the Munich-Erlangen link (WDM, 3 Lambda's) in July 1998 and extended to Berlin in December 1998. Deutsche Telekom is providing this dedicated optical fibre with two times 2.5 Gbit/s based on WDM-technique including ATM equipment for 2 lambdas. The third wavelength will be used for other tests, e.g. interconnection of HiPPI-environments with Cray- Supercomputers or IP over glass (POS, IP over WDM) experiments.

The application projects include e.g.:  ´grand challenge` applications from different areas (physics, biochemistry, fluid dynamics, tele- immersion etc.) with high performance visualisation tools and the interconnected capacity of several super computers (meta-computing),  distributed production environments for digital videos and video on demand,  transfer of high-quality video streams in the field of tele teaching and conferencing,  transfer of high-quality medical images and videos (tele-endoscopy, cancer surgery, mouth-jaw- area modelling),  middleware to support the applications.

At the beginning of July 1998 the first high-speed ATM-switches with 2.5 Gbit/s-interfaces (Ascend GX550) was successfully interconnected between Munich and Erlangen. This was a world premiere for the usage of such 2.5 Gbit-Switches outside laboratory environments. The first measured throughput was about 2.33 Gbit/s.

The second part from Erlangen to Berlin has been operational since December 1998 and interconnects about 8 institutions in the Berlin/Potsdam area with the Bavarian cities. The regional distribution network of the GTB in Berlin/Potsdam will use mainly an existing optical fibre infrastructure which is led to the scientific community by the country of Berlin. At some regional links WDM- equipment will be installed opening the possibility for several ATM- and HiPPI-connections in parallel.

It is planned to interconnect the DFN-GTB in Berlin with the photonic test environment KOMNET, also in Berlin. KOMNET will implement and test very advanced network components for the near future photonic network (e.g. photonic switches) and the DFN-community will get an early knowledge and experience with these rather new components.

5.2.5 Future Activities The current GTB project will last until spring/summer 2000 - at that time the next generation of the Wissenschaftsnetz, the Gigabit-WIN (G-WIN), will be launched. This will assure the continuation of the new developed applications as well as the provision of the network performance including QoS to the research community in Germany.

Besides of the gigabit testbeds DFN runs projects necessary to prepare to the next generation network in special areas.

After a long specification period in the IETF the basic IPnG standards are now available. After active participation on the 6bone we are ready for the next step. More production oriented networks like the 6REN are to come. DFN will - together with the European research community using the TEN-155 infrastructure - also take part in further IPv6 test work.

One of the very fast extending user groups is that of mobile IP. Not only laptops but also PDAs (Private Digital Assistants) should be plugged in on different places and get the needed network support based on mobile IP, the service location protocol and similar means. A DFN project has been started now to gather experience in this field.

In spring 99 the test of the Managed Bandwidth Service of DANTE will start, giving the opportunity to use some capacity for sophisticated tests among the European National Research Networks in several areas like QoS (DiffServ, RSVP, MPLS), multicast etc. This will be a further step on the way to a renewed Internet in Europe.

5.3 Status and Evolution of the French National Telecommunication Network for Technology, Education and Research

Dany Vandromme, GIP RENATER, France

Preamble Since the early 90’s, the French research and education network has provided full Internet connectivity to a wide academic community, from the major public research organizations to the higher education actors and even now to the whole school system. Beginning July 1999, the network will switch to a new infrastructure called RENATER 2, allowing a significant improvement in terms of capacity, technology and services to the end-user. In parallel to the operational network, a full set of experiments is carried out on a separate broadband infrastructure, to test and validate new protocols and innovative uses of high performance telecommunication networks.

5.3.1 RENATER 2 The current education and research network has evolved since its launch in 1992, from an average 2 Mbit/s to roughly n*2 Mbit/s, allowing a mean increase ratio of 6% per month, in term of capacity. RENATER is a two layer infrastructure. Users access the network through a regional network. There are 22 regional networks today. RENATER provides a full IP service interconnection between these regional networks, and brings also users connectivity to US Internet and to other European research and education networks. RENATER will end in June 1999 and will be replaced by a brand new broadband interconnection infrastructure named RENATER 2.

A call for tender was launched in 1998 in order to define and realize the RENATER 2 infrastructure. The major requirements, which have been given, are as follows:  Separate provision of links and services (ATM and IP),  Neutral location of RENATER 2 POPs with respect to any telecommunication operator,  Significant gap in terms of capacity and services provided to users,  3 years contract for services but yearly contracts for the network physical links to take profit of the growing competition between carriers.

The final choice of the providers was made in January 99 and the network is in the deployment phase during the first semester, to be fully operational by July 1st, 1999.

RENATER 2 will still be an interconnection backbone between regional networks or/and metropolitan networks, which will carry ATM and IP services with various levels of quality of services. These services will go from best effort IP connectivity to advanced classes of services for IP, or from classical on-demand VP services to the full dynamic ATM SVC provision. Capacities on the RENATER2 POPs will range from 34 to 155 Mbit/s at the starting date, to evolve quickly after the first year to a full 155/622 Mbit/s capacity. The Paris area will be equipped with one or two 2.5 Gbit/s metropolitan loops to interconnect all the links coming from several regional POPs and the international lines. Equipment located at each POP will enable a commutation capacity up to 2.5 Gbit/s. As it is today in the current situation, RENATER operates a GIX, on which 35+ commercial ISP are present to exchange their traffic. RENATER will go on organizing interconnections on the GIX, called SFINX.

5.3.2 Experiments ATM Safir This program of experiments started with the MIRIHADE project of CNRS (Paris, Rouen, Sophia- Antipolis, Toulouse) in 1996-1997 and moved to SAFIR by inclusion of new sites (Grenoble and Lyon) in 1997. SAFIR relies on a separate infrastructure from the RENATER operational network. This ATM- based infrastructure is provided by France Telecom and provides the sites with a modest capacity in the range of 2-24 Mbit/s. It is used for different purposes:  To support the research activities of CNRS and University teams in the field of new protocols including growing requirements in terms of qualities of service (native ATM, IPv4 with QoS, IPv6 etc:),  To test, evaluate and validate the interoperability of equipment of different vendors, and participate in the global standardization effort (such as the ATM-Forum or the IETF),  To develop skills and competence within the participating teams for the operation of new high performance networks,  To evaluate, validate and disseminate new applications on broadband networks and to promote innovative use of these infrastructure (real time, meta-computing, control/command processes, distance teaching, teleconferencing, etc…),  Co-operate with vendors and carriers to experiment new network services (SVC, flexible bandwidth) in an operational context.

Gigabit Experiments Because of the modest bandwidth allocation in SAFIR (25 Mbit/s max) it was not possible to experiment applications or equipment in a context of very high speed networks. This deficiency was amplified by the total lack of any commercial offer for broadband links (no offer above 155 Mbit/s links), whereas 622 Mbit/s or 2.5+ Gbit/s long distance links would have been required to test capacities of meta-computing applications or control/command processes. Such applications, which have their own funding from research programmes of the RNRT (Réseau National de Recherche en Télécommunications) or at an European scale from ACTS, TELEMATICS or ESPRIT 4th FP, could not meet their network requirements. Therefore RENATER has started a tender consultation for the provision of a gigabit link, between Paris, Nancy and Strasbourg. That link should have a possible prolongation on the German side to go to Stuttgart. That piece of network, which would primarily support research projects on the national level (@IRS) and on the European level (METODIS, EDISON), could also become a contribution to an experimental INTERNET2 European initiative.

Industrial Partnerships From the early beginning of RENATER, only research center and higher education entities were eligible to use the backbone and the international links. Together with a growing demand of Internet connectivity and higher quality of services, the range of users of RENATER was significantly widened. The complete national education system is now using RENATER (for Internet use mostly) and industrial research teams are also welcome in the RENATER community, as long as they follow the Acceptable Use Policy of RENATER. Some of the industrial research teams participate also to the SAFIR experiments at the national or European level.

5.3.3 International Connectivity TEN-155 RENATER is part of the TEN-155 European network which interconnects the research and education networks. From the 16-22 Mbit/s available bandwidth in the TEN-34 project, the European connectivity has now evolved to a full 155 Mbit/s ATM service. That connectivity will allow IP services and circuit services as well. For the last one, the managed bandwidth service, which is a significant part of the QUANTUM project (EU, 4th FP), aims to provide flexible high quality services to the end-users at the European scale.

Nevertheless, the TEN-155 network is still far from the Gigabit experiments being deployed in Canada or the US. An European initiative would be more than welcome in that field, to prepare the follow-on of the current TEN-155 network, beyond the year 2001.

US Link The US link was permanently upgraded during the year 1998, to reach a capacity of 155 Mbit/s in December. That link is divided into two separate circuits: one circuit, with a capacity of 10 to 45 Mbit/s ends at STAR-TAP in Chicago. It aims to exchange traffic with the high performance research networks of Internet2 project (vBNS, ABILENE), with the Canadian network Canet*3 and with thematic networks such as ESNET, NASA etc… STAR-TAP will also permit peering with Asian-Pacific networks such as SINGARNET and APAN.

The other circuit of the transatlantic link is devoted to the Internet traffic through a network access point on the East coast (110 to 145 Mbit/s).

5.4 GigaPort – The Next Generation Internet in the Netherlands

SURFnet bv14

In August 1997, three leading experts in the Dutch Internet community urged the government to drastically improve the capacity of the communications infrastructure available to the educational and scientific community. At the same time the business community expressed their wish to get linked to

14 SURFnet manages the SURFnet infrastructure, the Dutch computer network for higher education and research that connects R&D institutes with the worldwide Internet. For more information see http://www.surfnet.nl

95 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 the new Internet2 and the Next Generation Internet activities in the United States of America. Both ideas came together under the notion that by investing in ICT developments, the leading nations ensure that their ICT-sector will become stronger and their knowledge infrastructure will be reinforced. This will create economic growth in those countries and, thanks to the growing communication options, increases the scope of other sectors such as services, manufacturing and transport.

This has culminated in an ambitious project, known as GigaPort, proposed by the Ministry of Economic Affairs. This project proposal was developed in co-operation with the Ministries of Transport, Public Works & Water Management and Education, Science & Cultural Affairs, a number of large companies, the Telematics Institute and SURFnet. The Ministry of Economic Affairs submitted the proposal to an inter-departmental high-level working group preparing major infrastructure projects to be financed by the national Economic Structure Reinforcement Fund (ICES). The working group recommended the GigaPort project proposal to the new cabinet for a positive decision. In its coalition charter of July 1998 the cabinet expressed its intention to create a considerable incentive for developments in information and communication technology (ICT) and to develop a third mainport (Netherlands Brainport) after Schiphol Airport and the Port of Rotterdam. The GigaPort project is well- attuned to this intention. In October 1998, the Cabinet therefore allocated NLG 142 million (some EUR 64 million) to the GigaPort project that will have its formal start early 1999.

History of the GigaPort Project

Parliament Submission Start of motion: of business the project Invest also in plan knowledge infrastructure Submission of request for Grant of national Opinion article in US$ 85 infrastructure million NRC Handelsblad grant 1997 1998 1999 Aug Nov Jan June Sept Oct Jan

GigaPort consists of two interrelated sub-projects, GigaNet and GigaWorks. Within the context of GigaNet a highly advanced communications network is being developed with super-fast connections across the Netherlands and Europe and to North America and Asia. GigaWorks offers the Dutch business community the opportunity to carry out large-scale research into new applications for the next generation of the electronic highway.

Overview of the GigaNet Project

Users (e.g. via wireless DAN) Access Organisations IP over wireless LAN

AmsterdamAmsterdam Access y

t Internet Exchange i Internet Exchange IP over GSM, v i t National UMTS, satellite c

e Research Infrastructure n

n EuropeEurope o SURFnet4 / SURFnet5 C

Users l

a (e.g. via wireless DAN) n r e t IntercontinentalIntercontinental x Access E IP over cable, xDSL,PON

= Gateway Users (e.g. via wireless DAN)

The overall responsibility for the GigaPort project will be in the hands of a steering committee which embodies the interests of both the scientific and the business community. Within this frame SURFnet bv will manage the GigaNet activities, while the GigaWorks activities will be managed by the Telematics Institute15.

5.4.1 The Infrastructure Sub-Project: GigaNet GigaNet is in line with the plans as laid down in the SURF multi-year plan 1999-2002, which has led the universities, colleges and research institutes (the target group of its subsidiary SURFnet) united in the SURF Foundation to extend their commitment to SURF and its activities for further four years. The most significant parts of the plans concerning GigaNet are:  National Research Infrastructure The development of SURFnet5, a state of the art infrastructure for higher education and research, which will ensure that the Netherlands will assume a leading role in the construction and use of the electronic highway.  External connectivity The international connections with both scientific communications networks and the public Internet will be upgraded to state-of-the-art level.  Access The access to this infrastructure for the affiliated organisations and end users will be improved, inside and outside the campus as well as wired and wireless

National Research Infrastructure Whitin the frame of the GigaPort project companies will be allowed to use this fast SURFnet5 infrastructure to test innovative Internet applications. Right from the start of the GigaPort project in 1999 companies will be able to use the existing, state-of-the-art, SURFnet4 infrastructure to develop and test new applications and services (possibly in co-operation with other companies, universities, colleges or (commercial) research institutes).

As soon as the new SURFnet5 infrastructure will be available, organisations belonging to the SURFnet target group and companies will also be able to use this new network. However, companies that wish to operate commercial services will have to utilise commercial networks and not the GigaNet infrastructure, the same applies to their ordinary Internet traffic. Institutions in the SURFnet target group use the GigaNet infrastructure for education, research and development.

History of the SURFnet infrastructure

100 Gbit/s SURFnet5 20 Gbit/s 10 Gbit/s

1 Gbit/s SURFnet4 y t

i 155 Mbit/s

c SURFnet4

a 100 Mbit/s

p 34 Mbit/s a c

s 10 Mbit/s SURFnet3 s

e 2 Mbit/s c c

A 1 Mbit/s SURFnet2 100 kbit/s 64 kbit/s SURFnet1 9,6 kbit/s 10 kbit/s

1987 1989 1992 1995 1998 2002

15 The development of the backbone will start in 1999 with 2.5 Gbit/s pilot connections. According to the plan, this speed must be increased to 80 Gbit/s by the year 2002. The capacity for customer connections must be increased from 155 Megabit/s early in 1999 to 20 Gbit/s by the end of 2002.

The intention is that initially the existing SURFnet4, and later the new SURFnet5 infrastructure, will serve as the basis which the participating organisations in higher education and research and in the business community will use for their GigaPort developments. However, thanks to its vast capacity, these GigaNet infrastructure is innovative in itself. It will be essential to use new technologies and protocols to achieve the speeds mentioned above.

Traditionally, data communications uses transmission technology developed to carry voice traffic. This changes rapidly. If all goes according to plan, the network will start with speeds in the Gigabit per

15 The Telematics Institute was founded as a ´joint venture` between the business community, the scientific community and the government, to conduct research on information and communication technology (telematics). The focus is on advanced applications and on middleware. For more information see http://www.telin.nl

97 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 second (Gbit/s) range. These speeds demand a new technological approach. Developments in new transmission technologies will be extensively studied and tested in GigaNet. The Internet Protocol (IP) will be the leading technology at the network layer. However, new protocols and technologies as well as the expansion of existing protocols will be required to transport IP at Gigabit speeds, both beneath the IP layer (the transmission layer) and above the IP layer (the transport/session layer). Developments in the IP layer itself will also be the focus of extensive attention within the GigaPort project.

New technologies such as Wavelength Division Multiplexing (WDM) will be examined at the transmission layer. WDM enables transport of several colours simultaneously along a single pair of fibre-optics, allowing higher bandwidths. WDM technology has been available for a number of years, although it is expected that the hardware used to transport IP will be able to directly utilise the benefits offered by WDM.

One step further in the evolution of transmission technology is optical switching, which uses Optical Cross-Connects (OXCs). As soon as this technology generates applicable products, this will become another focal point within GigaNet.

Offering Class of Service (CoS), for instance to provide guaranteed bandwidth for a certain type of application, is a technology undergoing rapid development at present, but is still in its infancy. It is expected that products will become available early in GigaNet that actually allow guaranteed service. This new development, in both the current version of IP and its successor IPv6, will be subject to extensive tests in GigaNet.

At the transport/session layer of the Internet protocol suite new developments will take place that will support optimal use of high speeds even within real time applications. GigaNet will also focus on this to ensure that individual end-users can be offered improved performance.

External Connectivity Naturally, such a high-capacity network will require a proportionally high bandwidth for international access. This will enable close co-operation in the development of applications and services of equal standing abroad. The table below shows the international connections provided by GigaNet within the context of the GigaPort project.

1998 1999 2000 2001 2002 AMS-IX 200M 400M 1G 2.5G 5G Europe 155M 200M 400M 800M 1.6G US/Asia 155M 2*155M 622M 1.2G 2.5G

Access The aim of this activity is to acquire knowledge and gain experience with new wireless (e.g. GSM/GPRS, DVB and satellite) and wired (e.g. xDSL and cable modems) access technologies and with the use of generic services over IP, such as authentication, authorisation and directory services. This knowledge and experience are necessary to be able to offer these technologies on a commercial basis in the future. For that purpose during GigaNet a number of small pilot projects (with 1.000 connections maximum) will be started in co-operation with suppliers.

These generic services (middleware) will also be part of GigaWorks with focus on the application level, while GigaNet concentrates on the network aspects. Interaction regarding these services is self- evident.

5.4.2 Input from the Users of the Infrastructure: GigaWorks The GigaPort project not only focuses on infrastructure, but rather on the development of new applications and services. It is in this area in particular that much is expected of the companies and organisations that are interested in the development of these new applications and services. Both the business community and universities, colleges and (commercial) research institutes will participate in the development and deployment of new applications and services on a large scale. Applications already mentioned in the GigaWorks proposal include: . Linking multiple CAVEs for 3-dimensional simulation. . Extensive tele-co-operation and tele-consultation across IP networks with guaranteed quality of service (MESH platform). . High-speed, home-based tele-working and tele-learning.

. International tele-consultation and international data analysis. . E-commerce.

Many new generic applications (middleware) and services will be required for these applications and services. They include: . Authentication (chipcards, Trusted Third Parties). . Encryption (Secure IP, Transport Layer Security). . High-speed Internet/Intranet interfaces (firewalls, proxy services). . Improved searching, cataloguing and indexing systems. . Real-time and asynchronous multimedia conferencing. . Multiparty virtual reality communication.

Undoubtedly, many applications and services, which cannot even be envisaged at present, will arise among the users of the GigaNet infrastructure.

Overview of the GigaWorks Project

GigaWorks Areas Focus on Industry Sectors

Electronic Commerce Financial Services

Electronic Collaboration Media

Electronic Information Retrieval Research and Education

Generic Projects Industry

Health

8 The reason the business community has joined the GigaPort project is to accelerate deployment of resulting products or technologies in an operational environment. The incentives from the business community will be highly market-oriented and will prevent the project from becoming locked in an ivory tower. In addition to the creative input and innovative efforts contributed by the business community, the Telematics institute, universities, colleges and research institutes will also be prime movers.

The group of research institutes will be given the tough task of preparing their internal infrastructure for the high speeds used in the GigaPort project to ensure that they are able to participate in the development of new applications and services. Those institutions within the SURFnet target group are also a pilot target group for testing new applications and services.

The size and scope of the GigaPort project is such that it is essential that in addition to computer centres, the informatics and telematics faculties of the institutes involved will participate in the various components of the GigaPort project. These faculties have access to in-depth knowledge of developments that are still at the research stage, but which could develop into new applications and services for the next generation Internet.

5.4.3 A Major Step The GigaPort project is a big step ahead for the Internet in the Netherlands. A leap forward that will only be effective if it brings us viable new applications and services. Therefore, broad-based participation is essential: the business community, government, education, research, the Telematics institute and SURFnet together can ensure the success of the project and guarantee that the GigaPort project not only brings technological progress, but also contributes to the healthy growth of the Netherlands economy.

More information on this is available on the Internet at the following Web sites: . GigaPort: http://www.gigaport.nl . SURF: http://www.surf.nl . SURF/Meerjarenplan: http://www.surf.nl/mjp . SURFnet: http://www.surfnet.nl . Telematica Instituut: http://www.telin.nl

5.5 Current Status of the Next Generation Internet Deployment in Norway

Haakon Bryhni, University of Oslo, Norway

5.5.1 Introduction The R&D challenges related to Next Generation Internet technologies have received a lot of attention in Norway during the last two years. On the 23th of March 1998 the Norwegian experimental Internet2 network was inaugurated by the Norwegian Minister of education Mr. Jon Lilletun. A high capacity research network infrastructure is now operational between all R&D institutions in Norway. Research groups as well as industry with activities related to tele- and data communication are moving focus on IP-based networks. The academic sector has been very active in this field, and multimedia laboratories with state-of-the-art multimedia workstations and IPv6/ATM connectivity have been established at the University Campuses in Tromsø, Trondheim, Kjeller and Oslo. This work is being co-ordinated by Uninett, the Norwegian academic network operator for research and education.

The major Internet Service Providers in Norway are starting to migrate to IPv6 based technologies, but most await the general availability of IPv6-based applications and general operating system support. Thus, most commercial activities are at an early experimental stage. Telenor, which is the largest Telecom operator in Norway, has been active in R&D projects related to Next Generation Internet technologies, both through ACTS projects and through internal projects such as the Telenor Project-I. Telenor has also opened up for experimental access at reduced rates to IPv6 based network for the public sector and for commercial companies with R&D activities.

Industrial exploitation of Next Generation Internet technologies is emerging. These include primarily Ericsson Research Labs Norway and the Thomson-CSF Norcom AS, doing research and development related to next generation products based on the IP platform.

5.5.2 National Research Network infrastructure The national research network is co-ordinated by Uninett, which is also responsible for the further expansion of the network on a national and international level. The research network was significantly upgraded in September 16th 1998, when Uninett, the Norwegian Research Council and Telenor officially opened a state-of-the art research network connecting R&D groups on a national level. Wide area connectivity is obtained by a high capacity ATM infrastructure (Nordicom) provided by Telenor to universities and R&D institutions, offering OC-3 speed.

In order to support both application and network-related research, two separate networks are maintained. Primarily, a stable research network is operated with excess capacity for application research. About 20% of the capacity in the stable network is used for production traffic, while 80% of the capacity is set aside for experiments related to innovative use of applications. This network spans all academic institutions in Norway. In addition, a separate experimental test network is established to explore Next Generation Internet technologies connecting the major network-oriented research institutions in Norway; University of Oslo, NTNU and Uninett in Trondheim, University of Tromsø and UNIK and Telenor R&D at Kjeller. New functionality such as IPv6, Quality of Service (QBONE) with RSVP router support, mobile IPv6 and switched ATM services are tested in this network, and gradually migrated to the stable research network.

Research Network Experimental Network

Experimental Applications (80% capacity)

Production traffic (20%)

IPv4 over OC-3 ATM IPv6 over OC-3 ATM Excess capacity available Diffserv, RSVP, Mobile IPv6 for application research. Switched ATM services etc

The test network is interesting since it gives the academic institutions the opportunity to work with new technology and collaborate to find new uses of wide area networks, without interfering with production traffic. New test networks can be operated in parallel, as an example, both an IPv6 test network and a switched ATM Switched Virtual Circuit network is available simultaneously in the test network. 5.5.2.1 Capacity Upgrade Plan During the year 2000, deployment of OC-48 capacity is planned in the backbone network. The following table details the capacity upgrade plan of the Uninett backbone, transit and access wide area networks. Note that all university campus locations are part of the backbone network. Other academic institutions (such as various R&D institutions) are connected using the transit or access network.

1998 1999 2000 2003 Backbone network 40-150 100-300 300-600 2000-4000 Transit network 0,25-30 10-60 20-150 150-600 Access network 0,1-10 0,5-20 2-150 150-300

5.5.2.2 Wireless Access to the Experimental IPv6 Network In Oslo and Trondheim, experimental wireless access networks are being deployed for access to the Uninett IPv6 test network. Standard wireless LAN technology is being extended for metropolitan use, and IPv6 capable routers and end systems are used to build a wireless ´mobile IPv6`-based MAN. The network is based on the new IEEE 802.11 standard for WLANs (Wireless Local Area Network). Beside standard technology, the researchers use careful radio system planning and other methods to extend the reach of wireless LAN technology onto metropolitan distances within the legally allowed power and antenna gain limitations of the ISM band (Industrial, Scientific and Medical band). This band is license- free in most countries.

5.5.3 International Connectivity 5.5.3.1 Use of the QUANTUM Infrastructure In the past few years, Telenor R&D, Uninett and University of Oslo have made use of the TEN-34 and the JAMES ATM infrastructures in research projects such as ACTS National Hosts, MERCI (funded by the EU 4th framework research program), and joint European experiments organised by TERENA (Trans-European Research and Education Networking Association). The first international IP over ATM measurements in these projects were performed in 1995. Similar experiments are now being executed in the Meccano project where a dedicated multicast network is being established on top of the QUANTUM high capacity IP network and the managed bandwidth TEN-155 ATM infrastructure.

University of Oslo is contributing with research related to IPv6, video streaming, and multicast in particular.

5.5.3.2 The Nordunet 2 Initiative NORDUnet was started as a Nordic project financed by the Nordic Council of Ministers in the years 1985-1991. This resulted in development of cross border networking and in 1988 the Nordic data network, NORDUnet, was realised and financed by the respective national research networks. The Nordunet2 project is a new Nordic initiative, funded by the Nordic Council of Ministers. The initiative is a project framework for network applications with the aim to put forward advanced use of networking in research and education. The focus is on applications for electronic collaboration and advanced use of high capacity network infrastructure. Nordunet2 will focus on four areas:  Distance education and lifelong learning  Telemedicine  Digital libraries  Infraservices

5.5.3.3 Internet 2 Collaboration The Nordic networking community follows the ambitious Internet 2 initiative closely through collaboration through UCAID (University Co-oporation for Advanced Internet Developments), which recently has established a direct connection to the new US research network vBNS (very high speed Backbone Network Service), and Abilene (High availability backbone network application and advanced network capabilities) through STARTAP, the Science, Technology, and Research Transit Access Point in Chicago. The collaboration is based on joint application-oriented research activities, connecting advanced US and Nordic research groups in general fields of science where both groups work at a recognised international level.

5.5.4 Application Focus Uninett and the Norwegian Research Council is now actively working to strengthen the application development activity in the network, and pilots are being established in collaboration with the Internet 2 initiative in the USA. The Research Council is considering new methods to motivate research groups outside the traditional computer science and networking community by doing active match-making between application ´owners` and computer science experts. This approach has been used with success in the US Internet 2 project. In the following, a few examples of application-oriented research activities exploring Next Generation Internet technologies are presented.

As an example of potential new applications, Telenor R&D has developed a 3D collaboration tools called DOVRE, using IPv6 to transport data between participants in a 3D environment. Another example of new use of high speed network technology is the Electronic Classrooms used in the national research network. The classrom is based on open protocols such as IP, RTP and Multicast, and features shared whiteboards, position-sensitive microphones and remote controlled cameras.

Personal and group-based collaboration tools to facilitate distributed learning is another field of application focus. This class of tools addresses the need for knowledge transfer. In the Meccano project several tools were developed for the purpose of distance education.

Telemedicine applications is another field of focus. As an example, the 3D ultrasound activities at the University Hospital and the Center of Medical Technology in Trondheim, are being investigated to better exploit next generation Internet technologies. The main goals of this project are to improve existing surgical techniques and develop new minimally invasive procedures by means of ultrasound guidance.

5.5.5 Norwegian Research Groups focusing on Next Generation Internet The following is a brief introduction of Norwegian research groups doing research related to Next Generation Internet. Other groups are starting to work in this field, and industrial research and development groups are omitted due to Non Disclosure.

5.5.5.1 University of Tromsø The distributed operating systems research group work primarily in the fields of mobility, security and agents in relation to Next Generation Internet technologies. Moving agents is studied in the TACOMA project (Tromsø and Cornell Moving Agents). Through a collaboration with University of Lancaster, mobile IPv6 is being studied through a prototype implementation. The group operates a multimedia lab and runs the Tromsø IPv6 network. A ´satellite` mobile IPv6 lab is located in Bodø using mobile IPv6 technology to enable seamless IPv6 lab environment for distributed collaboration between the two laboratories. The focus of this work is to study how light-weight, low-power mobile devices can take advantage of IP mobility. The open distributed systems research group focus on distributed interoperable multimedia, by means of advanced middleware, and study reconfigurable protocols in the CORBA environment in the MULTE project in collaboration with UNIK at Kjeller. 5.5.5.2 Norwegian University for Science and Technology (NTNU) The department's research is both discipline and system-oriented. Along the discipline axis there is research on: Architecture and systems development, information security, traffic and reliability. Along the system axis there is research on networks and applications for mobile and stationary/fixed terminals and users. The work is related to the following systems and areas: Distributed systems and services, intelligent networks, network administration, access and transport networks A Next Generation Internet laboratory is installed at NTNU, and a number of research project such as the Plug & Play for Teleservices project is initiated. 5.5.5.3 University of Oslo, Department of Informatics Projects related to Next Generation Internet are performed in the communication systems group and most of the network-oriented research activities are performed in the Multimedia Communication Laboratory, which is the national ´hub` of IPv6 connectivity in the Uninett IPv6 test network. This includes the following projects:  Meccano (EU-project) focusing on IP Multicast and streaming media  Distributed Media Journalling  Scalable web servers in next generation Internet  High capacity media servers by use of networks of workstations.  Robust networks for mobile multimedia  Virtual video wall (research collaboration between IFI and the Victoria Institute in Stockholm)  Nordic secretariat for the Nordunet 2 project (USIT/IFI) 5.5.5.4 University of Oslo at Kjeller (UNIK) The distributed multimedia systems group at UNIK is working in the field of communication protocols, advanced middleware, Quality of Service, and distributed multimedia database systems. Projects in the DMS group at UNIK include:  Da CaPo - Dynamic Configuration of Protocols  DEPEND - Distance Education for People with Different Needs  INSTANCE - Intermedia Storage Node Concept  MULTE - Multimedia Middelware for Low-Latency High-Throughput Environments  OMODIS - Object Oriented Modelling and Database Support in Distributed Systems Most relevant to Next Generation Internet is the MULTE project which explores middleware platforms for distributed teleservices and multimedia applications, including transmission and end system protocols to support a broad range of QoS requirements. A prototype of the system will be implemented using CORBA over IPv6. UNIK is a hub in the national research network, and provide IPv6 connectivity to Telenor R&D. 5.5.5.5 Norwegian Computing Centre The Interactive Media Group (IMEDIA) at the Norwegian Computing Centre focus on the convergence of information technology, telecommunication and traditional media. IMEDIA works in the field of digital media and broadband communication technologies, and uses these technologies within a number of projects which involve application areas such as computer-supported co-operative work, electronic publication and information networks. In terms of Next Generation Internet technologies, the IMIS- Kernel project is most relevant. The goal of the IMiS (Infrastructure for Multimedia in Seamless networks) Kernel project is to establish a national lab environment for experimenting with multimedia services in a seamless network environment to the benefit of research and higher education in Norway. The IMiS project explores issues such as mobility, voice over IP, IPv6 infrastructure etc.

5.5.5.6 Telenor R&D Project I The primary goal of Project I is to identify new markets and services by developing a cross-disciplinary research program dedicated to the ´Next Generation` Internet. Research areas cover infrastructure, services, content, multimedia, production, trades and markets. On a short term basis the project will be a resource center monitoring the rapid development of the net for strategies and business opportunities for Telenor. Examples of current activities related to Next Generation Internet are:  ´Things that think` (Project I is part of the MIT consortium)  Automatic configuration of services, directories, secure transactions and resources by means of mobile-aware middleware (taking advantage of Java/Jini and Corba technology).  Nomadic computing and mobile IPv6. This project studies the effect mobile computing will have on network architecture and infrastructure. One of several problems is how to guarantee QoS when users move between different networks which may offer different services. Other issues are security and the relationship between QoS and billing of mobile services.  Universal Mobile Telecommunication System (UMTS) and the use of mobile IPv6.  Quality of Service: This activity focuses on solutions for service quality guarantees. That includes detailed studies of the suitability of the current de facto standards RSVP and ATM as well as the upcoming technologies such as IPv6 and MPLS. The activity has an experimental focus based on performance evaluation to evaluate different solutions by using the national and international IPv6 networks that are emerging.  Performance evaluation and performance metrics for the Internet and its networking technologies. Traditional telecommunication network operators have invested a significant effort into billing, management, and control systems. Similar solutions are not readily available for the Internet. However, in the future the Internet will need some of these capabilities to implement a reservation scheme.

5.6 United Kingdom / JANET

Jeremy Sharp, UKERNA, UK

5.6.1 Overview Since 1984 the UK academic and research community has been operating its own high speed national network, JANET, which has been continuously enhanced to meet expansion in the community and to take advantage of new technology. In that time: . The number of institutions directly connected to the network has increased from just under 50 to about 180 and a large number of other sites connect to the network indirectly via these institutions. . The number of individuals having access to the network is estimated to have increased from about 5,000 to over 1,000,000. . The access capacity of the network for individual connections has increased from about 10 kbit/s to 155 Mbit/s.

This expansion has been achieved by careful management, and by a continuing programme of providing new technology and improved organisation. Throughout this period end users have enjoyed a consistent and stable service.

JANET was originally conceived as a Higher Education network, however technological progress and changing user requirements have led to fundamental changes in the constitution of the network user base. UK Government initiatives focussing on the spread of Information and Communications Technology (ICT) to support The Information Society and Life Long Learning are further increasing pressure for change. As a consequence UKERNA undertook a study on the future use of JANET in the context of these changes. To inform the study an extensive consultation exercise was undertaken during May to August 1998 which involved talking to institutions and communities that could potentially be affected by any significant changes in the use or method of provision of the JANET network. Particular attention was taken to canvass opinion as widely as possible in the existing JANET community. Full details of the study can be found at http://www.ja.net/documents/net_arch.html

5.6.2 External Connectivity The JANET link to the rest of Europe has been operational since December 1998 on the TEN-155 network. In addition to this connection, UKERNA is contracted by DANTE to provide operational monitoring of the TEN-155 network.

Following an open procurement UKERNA has signed a new three-year agreement for the supply of transatlantic bandwidth to JANET. Teleglobe, supplier of the existing transatlantic links utilised by JANET, has again been selected for this increased provision. They will be utilising one of the new transatlantic cables (AC-1) which features dual routing over the ocean bed and Wave Division Multiplexing. This means that Teleglobe will be able to provide a service that is automatically resilient against a break in a single fibre path, and which will be capable of simple upgrade to higher bandwidths as overall demand for capacity increases.

The new agreement specifies that a 155 Mbit/s (STM-1) link be provided ready for service by 1 March 1999. This will replace the existing dual 45 Mbit/s links, which will be kept only for a short period to provide a fallback service during initial operation of the new service.

The new links will terminate in London, the UK and in New York in the US. The standard IP service to North America and the Pacific Rim countries will continue to be provided through Teleglobe's GlobeInternet network. An improvement to previous arrangements will be that UKERNA will maintain a fully-fledged JANET Point of Presence (PoP) in New York. This will allow JANET both to exercise better management of the transatlantic resource and to consider connection of JANET to other relevant US-based research networks.

UKERNA and UCAID/Internet2 announced a collaboration on advanced Internet technologies and applications and signed a Memorandum of Understanding (16th February 1999) to jointly collaborate on the development of next generation Internet technologies and applications.

5.7 Next Generation Internet Activities within ESA

Roberto Donadio, European Space Agency - Directorate of Application Programmes

5.7.1 Overview The European Space Agency (ESA) carries out R&D activities involving satellite communications under its own ARTES (Advanced Research in Telecommunications Systems) programme.

The ARTES programme is structured into programme elements, of which the following are relevant to advanced Internet R&D:  Artes Element 1 - Preliminary Studies and Investigations  Artes Element 5 - Advanced Systems and Telecommunications Equipment (ASTE)  Artes Element 3 - Multimedia/Global Information Infrastructure

ESA is also active on matters related to standardisation for satellite communications in both ETSI and the ITU. ESA has hosted the meetings of the Ad-Hoc Group, formed by the major satellite operators and ESA to draft a standard for a Satellite Interactive Terminal to be used with the first generation of interactive satellites, which will be available in Europe from 1999 with the ARCS initiative from SES/Astra.

5.7.2. ESA Activities for Next Generation Internet 5.7.2.1 Activities carried out under ARTES Element 1 ARTES element 1 is dedicated to advanced studies. Two activities have been running in 1998 after the tender action ´Performance Optimisation of Internet Protocols over Satellite`, with the purpose of analysing how the performance of TCP, the dominating protocol on the Internet, can be improved when satellites are used in the connection, while maintaining full compatibility to the terrestrial portion of the network.

The first project has been run by a consortium including Delta Communications Ltd., the University of Aberdeen and Globecast Northern Europe and has concentrated on the use of satellites in the access network, to provide high speed Internet connectivity to end-users via a digital DVB channel.

The project has analysed in depth the current limitations of Internet protocols. Current implementations of TCP have been designed to operate in a stable manner over a large number of media and platforms. The characteristics of geo-stationary satellites (in particular the inherent large delay of ca.

255 ms.) cause connections over satellites to exhibit non-optimal performance. A number of mitigations obtained by modifying protocol parameters have been proposed as well as modifications to the TCP protocol, giving importance to the compatibility of these modifications with the security standard (IPSEC) proposed for the Internet. The project has actively participated in the discussion in the IETF, where the subject is being discussed in a specially created group (TCPSAT).

The second project has been run by a consortium including CSEM, Swisscom AG, Solinet GmbH, and has concentrated on the use of satellites to provide a backbone connectivity. The subject of fairness at routers between connections using long-delay links (typically satellite) and connections with a short delay has been analysed, and the advantages of using advanced discard techniques such as RED have been studied.

A workshop on the subject (´Workshop on Internet Protocols over Satellite`) has been held on 12th January 1999 at ESTEC.

5.8.2.2 Activities carried out under ARTES Element 5 ARTES Element 5 (ASTE) is dedicated to R&D support for the medium term. The specific problems of dissemination of earth observation products and giving access to environmental databases via the Internet have been addressed:  in 1997 in the project ARTE, run by a team including Alenia Aerospazio, GCS and Etnoteam and others, using the techniques of asymmetric Internet provision over DVB satellites with a terrestrial return link;  in 1998 by the project Sawa, run by NLR, West Consulting B.V., Origin and ICT Automatisering. This project has particularly concentrated on the advantages of using caching and replication, and has included a demonstration at three sites of the MERCURE network of the United Nations Environmental Programme (UNEP).

5.8.2.3 Activities carried out under ARTES Element 3 ARTES Element 3, Multimedia, was launched in 1996 to address the needs of European satellite industry to respond to the rapidly evolving multimedia market.

A first line of activity (Development of Satcom Multimedia Market), dedicated to pilot projects based on existing technology, has included two tender actions on ´High Speed Internet Demonstrations` and ´Intra-Enterprise and other Networking Demonstrations`. After the evaluation has been completed in late 1998, a number of projects will start in the first quarter of 1999 covering subjects such as enhancing DVB Internet provision with fully interactive satellite dishes, Internet e-commerce supported by DVB dishes, Intranet applications based on satellite. These two tenders are expected to be re- issued in 1999.

A second line of activities (Development of Satcom System Elements) addresses the development of specific components for the satellite multimedia market. A first tender ´Low Cost Earth Stations` has resulted in a number of projects in 1998, the most relevant ones for the NG Internet are:  the project IMMIS, run by Alenia Aerospazio, Nortel and Spar Aerospace, building on the results of a previous activity run under ARTES element 5, with the aim of developing a prototype satellite interactive terminal compatible with the specification of the Ad-Hoc Group. Special critical areas for the development are the indoor unit, including the logic for the multiple access which is being realised using the Multi-frequency Time Division Multiple Access (MF-TDMA) technique which is very well suited to bursty communications such as it is the case of the traffic generated by Internet terminals, and the outdoor unit, including the Solid-State Power Amplifier (SSPA) and the satellite dish, which has to provide sufficient power to support a high data rate on the up-link but at the same time has to be realised at low cost in order to be successful on the consumer market.  the project SIMPLE, run by GCS and the University of Salzburg, is developing a platform for Internet offering over DVB satellites providing special advanced multicasting capabilities, caching and replication. Although high speed Internet operation has been demonstrated over DVB satellites, in order to be commercially viable the provision of Internet over satellite has to include a mix of point-to-point services and multicasting services, because the latter uses the point of strength of satellites and can be provided at an advantageous cost.

The tender action ´Communications Control` has also resulted in several projects, relevant is the project ´MultiCom` run by ESYS Ltd., developing a software suite to be used by service providers and content providers to support scheduling and billing functions and to monitor Quality of Service aspects.

A third line of activities is meant to address the next generation of communications satellites (constellations); activities have not yet started and are foreseen for 1999.

5.8 USA - Internet2

Roman Tirler, European Commission - DGIII, Belgium

5.8.1 Executive Summary Internet2 (I2) is about inventing the future of networking and about the creation of incentives for developing new technologies and applications that will initially be deployed in the research community and then migrated to the commercial sector. Today’s applications are possible because of yesterday’s innovations. Internet2 is focused upon the needs of academia first, but is expected to develop technologies and applications that will eventually make their way into the rest of society and business. Although Internet2's development work on advanced network engineering and applications is aimed at the research and education community, it is expected that the commercial Internet will benefit from the research and the innovations of the Internet2 project as well. Internet2 will advance the technology of the global Internet. As Internet2 participants work with industry to transform the way that university research makes use of networking technology, those advances will emanate out and transform the Internet for the regular end user.

Internet2 is not an actual physical entity. Internet2 hopes to create the network environment referred to as Internet2 by connecting and upgrading a number of federal and campus-funded networks that already exist. Internet2 hopes to take advantage of investments in networking already made by its partner institutions, industry, and the government. Internet2 is not just about faster pipes or higher capacity backbones; it sets out to provide solution to other network parameters that are as important as bandwidth and in some cases more so.

Internet2 will not replace the Internet. Rather, its goal is to enhance the current Internet. Universities maintain and continue to experience substantial growth in use of existing Internet connections, which they still obtain from commercial providers. The commercial sector is a full partner in this project and will benefit from applications and technology developed by Internet2 members. Just as the Internet and the World Wide Web are legacies of earlier investments in academic and federal research networks, the legacy of Internet2 will be technology adopted not only by universities, but by the commercial sector.

Internet2 NGI. Founded October 97 October 97 Lead by UCAID – University consortium White House Funding University Community, Corporate Congress Sponsorship Goals Advanced Application development, Development of advanced deployment of networking tool networking technologies, deployment of testbeds Backbones vBNS, Abilene vBNS, Abilene, SuperNet

Table 1: US Networking Initiatives

The Internet2 project is not the only initiative to accelerate the availability of advanced networking services and applications required by the research community (see table 1). The Presidential Next Generation Internet Initiative (NGI) is complementary and offers a different answer to the problem of Internet performance. Both initiatives have triggered activities in the commercial sector.

Networking research and development is of necessity an iterative process - a ´spiral design` requiring continuous feedback between network researchers and researchers of various disciplines testing the applications on the network. These two activities are vertically coupled: networks enable the applications, and applications drive the advance of networks.

5.8.2 Background Internet2 is the university community's response to the need for a return to dedicated bandwidth for academic and research use exclusively. Prior to 1995, the National Science Foundation's (NSF) NSFnet served the research and academic community and allowed for cross-country communications on relatively uncongested lines that were unavailable for commercial use. However, NSFnet went public in 1995, setting the stage for today's Internet. As the Internet has become irrevocably a part of American life, the increase in e-mail traffic and the proliferation of graphically dense pages have eaten up valuable bandwidth. The privatisation of that network and the frequent congestion of its commercial replacement have deprived many research institutions of the network capability to support world class research. Internet2 represents the interests of the academic community through its concentration on applications that require more bandwidth and end-to-end Quality of Service (QoS) than is available relying upon the commercial Internet. Internet2 will focus on better reliability for network-critical problems.

The Organisation In October 1996 the Internet2 University Consortium was formed with initially 34 members. Currently, 135 Universities and 44 corporate sponsors are members of Internet2, which in October 1997 incorporated itself forming the University Corporation for Advanced Internet Development (UCAID). UCAID now serves as the support and administrative organisation for the Internet2 project. This is the first UCAID project. Members pay an annual fee of between $10,000 and $25,000 and must demonstrate that they are making a definitive, substantial, and continuing commitment to the development, evolution and use of networking facilities and applications in the conduct of research and education before they are approved for membership. The second UCAID project is Abilene, an Internet2 backbone based on a partnership with Qwest, Nortel and Cisco.

5.8.3 Project Description Objectives and Mission The mission of Internet2 is to facilitate and co-ordinate the development, deployment, operation and technology transfer of advanced, network-based applications and network services to further U.S. leadership in research and higher education and accelerate the availability of new services and applications on the Internet. The goals of Internet2 can be summarised as follows:  Demonstrate new applications that can dramatically enhance researchers' ability to collaborate and conduct experiments;  Demonstrate enhanced delivery of education and other services (e.g. health care, environmental monitoring) by taking advantage of ´virtual proximity` created by an advanced communications infrastructure;  Support development and adoption of advanced applications by providing middleware and development tools;  Facilitate development, deployment and operation of an affordable communications infrastructure, capable of supporting differentiated Quality of Service (QoS) based on applications requirements of the research and education community;  Promote experimentation with the next generation of communications technologies;  Co-ordinate adoption of agreed working standards and common practices among participating institutions to ensure end-to-end quality of service and interoperability;  Catalyse partnerships with governmental and private sector organisations, Encourage transfer of technology from Internet2 to the rest of the Internet, and  Study impact of new infrastructure, services and applications on higher education and the Internet community in general.

Soon after the announcement, Internet2's central goals were adopted as part of the White House's Next Generation Internet (NGI) initiative.

Funding and Partnership UCAID’s University members have committed over $50 million per year in new funding for Internet2, and UCAID’s corporate members have promised to provide nearly $20 million over the life of the project. In addition, it is expected that Internet2 member institutions will receive funding in the form of competitively awarded grants from the NSF and other federal agencies participating in the federal Next Generation Internet initiative. Substantial related federal R&D funding will be awarded through related agency applications initiatives.

Funds committed to Internet2 will not be used to provide currently available services (commodity Internet) and the universities will continue to send the majority of their traffic over the commodity network.

The Backbone Networks vBNS and Abilene vBNS (very high performance Backbone Network Service) is a network provided under a co-operative agreement between the National Science Foundation (NSF) and MCI to NSF-approved institutions of research and higher education that supports high-performance, high-bandwidth research applications, and is used by the Internet2 project as an initial interconnect backbone. In spring 1995, the NSF made a five-year co-operative agreement that was worth up to $50 million with MCI for vBNS. vBNS runs at 622 Mbit/s and will be upgraded to Gigabits/s. The Internet2 program is in partnership with the National Science Foundation's (NSF) meritorious High Performance Connections program. Many institutions have already received competitively awarded grants (131 up to now) to connect to the vBNS.

The vBNS was designed for the scientific and research communities and originally provided high speed interconnection among NSF supercomputing centres and connection to NSF-specified network access points. The vBNS is only available for meritorious research projects with high bandwidth uses and is not used for general Internet traffic.

Before NGI, before Internet2, NSF already was working to provide its constituency with networking beyond what the commercial Internet could deliver. The NSF's answer was to begin a dedicated network, vBNS, to provide next-generation network service to qualified researchers and academic users.

Abilene is a high-performance backbone network for the Internet2 project developed by the University Corporation for Advanced Internet Development (UCAID) in partnership with Qwest Communications, Nortel (Northern Telecom) and Cisco Systems. Abilene adds an alternative backbone network to the existing vBNS Internet2 backbone. While both provide advanced IP connectivity, they do so using different underlying technologies.

Abilene will enable faculty and staff at Internet2 universities and research labs to develop advanced network services and applications. The Abilene project will also explore the frontiers of network research by providing a ´separate network` to do network research. Abilene runs at 2,4 Gbit/s and started operation beginning of 1999 and has 33 access points serving 64 members. Abilene's advanced capabilities will help Internet2 members develop and deploy new applications more quickly and more broadly.

As with Internet2, Abilene will support the NGI, an initiative among federal research agencies. Abilene will be a key enabler of the University community's effort to collaborate with federal agencies on research and development of advanced network technologies and applications.

Abilene is based on a five-year agreement among the collaborators and therefore has a time horizon reaching beyond that provided by the vBNS (the present co-operative agreement between NSF and MCI ends on 31st March 2000).

QBone initiative As part of the Internet2 initiative to test interoperability of equipment and software a testbed known as QBone was initiated. The QBone testbed proposal issued September 1998 asks for contributions on how to build and explore pre-production Quality of Service technologies over the Internet. 13 proposals were recommended for initial interoperability tests. SURFnet (the Dutch National Research Network) participates in one of the projects.

Applications The development of advanced applications to meet the emerging requirements in research, teaching and learning, and to exploit the capabilities of broadband networks, media integration, interactivity, real time collaboration, is a major goal of the Internet2 project. Internet2 is application driven. The projects aim is more about how to adapt the applications to the increased bandwidth, and to create applications previously not possible than about provision of more capacity. The following table illustrates the requirements on bandwidth, response time (latency) and quality of service (Qos) of typical advanced applications.

Type Bandwidth Latency QoS Distributed Database > 10 Mbit/s < 100 msec high Interactive Remote 20 – 30 Mbit/s < 100 msec medium Visualisation Digital Libraries 10 Mbit/s < 150 msec medium Advanced Distributed 15 Mbit/s < 30 msec high Simulation Metacomputing Research 15 Mbit/s < 30 msec high Quality Video 15 Mbit/s < 50 msec high Conferencing Collaborative Health Care 20 Mbit/s < 30 msec high Interactive Molecular 15 Mbit/s < 50 msec high Modelling Entertainment 10 Mbit/s < 100 msec high Shared Learning 30 Mbit/s < 50 msec high

A virtual laboratory, an application environment for computational science and engineering, is a heterogeneous, distributed problem solving environment that enables a group of researchers located around the world to work together on a common set of projects.

Another example is multi-disciplinary design and manufacturing. A company involved with the production of a large and complex product, such as an aeroplane, must be able to direct simulation processes to interact with design data bases which contain technical and manufacturing specifications. The design and simulation can require simultaneous access to hundreds of sub-computations which are provided by subcontractors at different locations.

A third example is a weather forecasting system that incorporates satellite data, large numbers of sensor inputs, and massive simulation for short and medium range weather predictions. Distributed learning will enable education on demand through storage, access and distribution of multimedia courseware including high quality video over dependable networks. Collaborative research allows researchers world-wide to share large amounts of data with predictable responsiveness. Digital libraries - large archives of multimedia files can be accessed and transferred at high speed with high quality.

As applications become more advanced and more demanding of the underlying network infrastructure, it will be necessary for them to interact with the network itself. The design and implementation of middleware is intended to achieve exchange between application and infrastructure.

Middleware The Internet2 middleware initiative in partnership with industry will accelerate the development of advanced network applications and define a suite of enhanced network services that will serve as building blocks for the advanced research and education applications being developed at Internet2 sites. These services include digital audio and video frameworks, storage systems, network security, quality of service, reliable multicast, and others.

The Internet2 Digital Video Network will establish a national, higher education video network service for developing scalable and easy-to-use applications to deliver live or stored streaming and interactive digital video. These applications will provide video quality comparable to high definition TV.

The Internet2 Digital Storage Initiative will develop and refine advanced server system technology located throughout the network to store and deliver efficiently terabytes of data to users on any Internet2 campus. Corporate partners will help realise the project’s goal of making these new technologies widely available to the global Internet.

The goal is to increase the deployment of middleware technologies (security, QoS, directory, accounting, collaboration frameworks, audio/video frameworks, file systems) as part of a pre- commercial production environment.

International Interconnections / Collaborations Science is a global activity and requires broad interconnection of US and international research networks for optimal advancement. The objective is to interconnect high-performance networks and to ensure global interoperability of advanced technologies. The procedure is to build peer-to-peer relationships by looking for similar goals and similar constituencies. The mechanism used is by signing Memoranda of Understanding with UCAID. Presently the following institutions have signed MoUs: Canarie (CA), SURFnet (NL) and NORDUnet (Nordic Countries), TERENA, Renater (FR), APAN (Asia-Pacific Advanced Network), SingaREN (Singapore), and others are in process.

5.8.4 Relation to NGI Complementary to the Internet2 project is President Clinton's Next Generation Internet (NGI) initiative launched October 10, 1996. NGI is broader and deeper than the Internet2 project, and some NGI funding will flow to the Internet2 project. The NGI initiative is a multi-agency (NSF, DARPA, NIST, NIH, NASA, and DoE) federal research and development programme that is developing advanced networking technologies and revolutionary applications that require advanced networking, and demonstrate these capabilities on testbeds that are 100 to 1,000 times faster end-to-end than today's Internet. NGI is part of the U.S. government's large-scale networking initiative. The NGI program will be co-ordinated in the framework of the National Science and Technology Council. High-level strategy will come from the Committee on Computing, Information, and Communications (CCIC), and implementation strategy from the large-scale networking working group.

Objectives NGI will address fundamental problems with the present Internet, such as security, Quality of Service, dependability, scaling, and management. In brief, these goals include:  Conduct R&D in advanced end-to-end networking technologies: reliability, robustness, and security, Quality of Service, network management.  Establish and operate two testbeds: The ´100x` testbed will connect at least 100 sites - universities, federal research institutions, and other research partners - at speeds 100 times faster end-to-end than today's Internet. The ´1,000x` testbed will connect about 10 sites with end-to-end performance at least 1,000 times faster than today's Internet.  Conduct R&D in revolutionary applications: these include enabling applications technologies like collaboration technologies, digital libraries, distributed computing, privacy and security, remote operation and simulation, and disciplinary applications in basic science, crisis management, education, the environment, federal information services, health care, manufacturing.  Promote experimentation with the next generation of networking technologies to enable use of these more advanced networks.  Demonstrate new applications that meet important national goals and missions.

Internet2 will be used as an implementation vehicle for these goals. It is important to note that the goals of Internet2 and of the NGI are entirely compatible and complementary. Many of the persons involved from both sides have worked together for a number of years. For example, Internet2 engineers are currently participating on the Joint Engineering Team that will ensure interoperability between federal agencies involved in NGI and Internet2. The Abilene backbone will be used for NGI ´100x` testbed activities. It is however foreseen that DARPA will set up its own terabit/s testbed (SuperNet).

The NGI initiative will play an important role in catalysing partnerships between federal agencies, the private sector and the academic community.

A substantial component of NGI is long-term experimental research on networks themselves, something Internet2, as an application driven project, will not focus on, but upon which Internet2 will rely on advances in networking technology.

Funding As a federal initiative, depending on upon the reallocation of appropriated agency resources, NGI faces a trickier funding scenario than Internet2. Whereas Internet2 draws upon membership dues and industry support and contributions, NGI requires the support of the Congress. While the concept of a ´Next Generation Internet` has seeped into the American consciousness and garnered considerable public support, the project still faces a battle with Congress at appropriations time each year, especially as Congress looks for new ways to reduce spending while cutting taxes.

Agency FY R&D Testbeds Applications 99 Darpa 50 25 25 - DoE 15 6 5 4 NASA 10 2 3 5 NIST 5 3 - 2 NIH 5 - - 5 NSF 25 6 11 8 Totals 110 42 44 24

5.8.5 Impacts A key goal of this effort is to accelerate the technology transfer necessary to move the appropriate technologies into the commercial sector -- thus creating the basis of a next generation network that will continue United States' leadership in this important area. Internet2 will also share its discoveries with others in the educational community. Internet2 is developing structures to share its experience and expertise with others in the education community and beyond. This is the approach that characterised the first Internet and it can work again today.

The investments by universities in Internet2, coupled with the efforts of industry and government, are helping to develop technologies such as IPv6, Multicasting, and Quality-of-Service that will enable a new generation of Internet applications, from which all sectors of the society benefit. The wisdom of this approach to network research has been proven by the rise of today's Internet from the academic and federal research networks of the 1980s. Internet2 has the ambition to replicate this success for the new millennium by relying on the university community for pre-commercial development.

Internet2 and the other initiatives are prime movers for continuous improvement of information technology and development of R&D applications leading to business investment. The public investment in R&D networking leads to spin-offs and business creation. Internet is now strategic for most enterprises.

5.8.6 Some Commercial Initiatives The Internet was, of course, not designed for the purpose it now serves for business. As commerce becomes more dependent on the Internet the repercussions of the present implementation limit its usefulness. Therefore several commercial initiatives are under way.

MCIWorldcom recently announced a new commercial high-speed network to be known as Next Generation Network (NGN). From January 1999 NGN will offer similar services to the vBNS to commercial customers at commercial rates. It is a physically separate network from the vBNS and will have none of the restrictive vBNS acceptable use policy constraints. Customers will be able to choose access from 45 Mbit/s up to 2,4 Gbit/s line-speeds using technologies such as frame-relay, ATM or Gigabit Ethernet. NGN will offer IPv4 or IPv6, both in native mode. World-wide IP services will be provided by onward connection through the UUNET global Internet.

Microsoft and Qwest teamed up recently to deliver Next Generation Internet based broadband services for vital business software applications. The spectrum of services offered will include dedicated electronic commerce, web application hosting, streaming media, managed software services, Virtual Private Networks.

IXC Communications recently announced that it activated its Next Generation Internet backbone network (running at 2,4 Gbit/s), named Gemini2000, to carry both commercial and research traffic. The network is being reviewed by NSF for Internet2 compliance. The Gemini2000 Networks intends to connect to vBNS network and other special purpose networks certified by the NSF as High Performance Network Service Providers.

5.8.7 Conclusion Over the past decade, federal government R&D agencies, the University community, and private companies have worked together to develop many of today's Internet technologies. That partnership created a multi-billion dollar industry. By renewing this partnership, Internet2 will develop and

112 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 implement a new technology needed by all network users, ensuring continued U.S. leadership in the application of computers and communications.

Internet2 will be a success when the applications and technologies developed by university participants have been migrated to the broader networking community. Major challenges lie ahead, like the massive growth of users doubling every 18 months and content doubling every 12 months. Technical requirements like scaling bandwidth and servers, management skills, new applications like telephony and high quality video, application and network convergence, single network for all applications, different classes of service with appropriate management and billing are challenging. Business challenges like technological complexity, skill shortages, migration of gigantic legacy businesses will have to be mastered.

Internet2 and NGI both have obstacles before them -- Internet2 depends upon academic resources and investment; and NGI, relies on congressional budgets and endorsement. Both expect to produce meaningful results by the year 2000, and expectations for both plans are very high. Networking together with information technology constitute the fundamental infrastructure for the information age on which science, engineering, education, commerce, and even entertainment are built.

5.9 A Review of Next Generation Internet Services in the Asia Pacific.

Goh Kheng Wee, Foo Ji Haw, Pak Suk Foon and Ravi S. Sharma Multimedia Competency Centre, Deutsche Telekom Asia

5.9.1 Introduction The proliferation of the Internet in the 1990s has taken many by surprise. Nowhere is the rate of growth (in terms of hosts as well as users) more staggering than in the Asia Pacific region. From the realm of universities and research institutes in its early days, the Internet is now truly a device of the modern economy. Activities such as business communications, marketing, learning, collaboration and so on are taking place over the Internet, hence adding true value to e-mail, web-hosting, VPN and security services which are commonplace. However, the letdown is often the poor availability of access and the bandwidth (especially in the backbone). Recognising this, the major ISPs of the region have acted together to try improve the interconnectivity between themselves and have acted with Telcos to introduce higher bandwidth access solutions. Left in the back-burner for now, is the upgrading to IPv6 (and its associated increases in addressing, security and bandwidth management).

In this brief review, the authors (technical members of Deutsche Telekom’s Multimedia Competency Centre in the Asia Pacific) report the various commercial and research activities being undertaken in the region in promoting next generation Internet services. The example of Singapore, Malaysia and Hong Kong serve as trend-setters for the rest of the region. Singapore is known for its proactive government incentives while Hong Kong leaves it to the private sector. In Malaysia, the government provides a vision (and incentive scheme) for private sector implementation. The contrasts in business models are useful as reference points for the rest of the region (save Japan and Australia). Finally, a synopsis of the higher profile R&D activities is covered. While most of this is restricted to testbeds and academic interests, it is clear that they provide directions for future expansions. The authors conclude with the central message that may be distilled from observing the various activities over the Internet.

5.9.2 An Overview of Commercial Fast Internet Access in the Region The phenomenal growth of the Internet has fuelled the need for fast Internet access. At the same time, the increased usage of Internet services has also led to the development of a new on-line and on- demand culture. To meet customers’ demand, several Asian countries have developed or are planning to develop high-speed network infrastructures to deliver multimedia content. Hong Kong, Singapore and Malaysia reviewed in the subsequent sections are examples of such countries. As the development of IPv6, QoS and IP-casting are still confined to the research laboratories, this section will provide an overview of what Asian countries are doing to deliver on-demand services using existing technologies.

5.9.2.1 Singapore Singapore, a little island of 3.1 million people on a land mass of merely 42 kilometres from west to east and 23 kilometres from North to South, became the first country in the world to deploy a nation-wide broadband network infrastructure called Singapore ONE (One Network for Everyone, http://s- one.net.sg) in June 1997. Residential users can access the network via asymmetric digital subscriber line (ADSL) or cable modem while business customers can be connected by Asynchronous Transfer Mode (ATM). The backbone has a total bandwidth of 622 Mbit/s. Since December 1998, there are about 12,000 home users with over 120 commercial applications.

The applications in Singapore ONE are running entirely on Internet technology. Hence, to support these IP-based applications, the ATM switches at the core backbone and at the access switches are running LAN Emulation or Classical IP. While users in Singapore could have up to 6 Mbit/s access to local sites via ADSL, access speed to Internet sites outside Singapore remains slow. The high bandwidth available locally allows service providers to stream multimedia contents, including MPEG video, to the desktop without the need for any protocols to reserve bandwidth (e.g. RSVP).

5.9.2.2 Malaysia The Multimedia Super Corridor (MSC) is the first step into Malaysia’s Vision 2020, a national agenda that sets out specific goals and objectives for long-term development (http://www.mdc.com.my). The MSC, primarily driven by the Malaysian Prime Minister Dato Seri Dr. Mahathir bin Mohamad is to be the centrepiece of Malaysia’s multimedia/IT development strategy.

Built from the ground up on an oil palm plantation, the MSC is an area, 15km by 40km, encompassing the Technology Park Malaysia, the Petronas Twin Towers, the Kuala Lumpur International Airport (KLIA), and two of the world's first smart cities: Putrajaya and Cyberjaya. World-class multimedia corporations will be invited to locate their business units and R&D facilities in this catalyst centre to be used as a springboard to serve the regional and world market for multimedia products and services. With the success of MSC, it is the direction of Malaysia to extend its services and infrastructure throughout Malaysia, making the whole country connected by a nation-wide backbone.

The MSC Flagship Applications projects in areas such as medicine, education and public administration use multimedia technologies as a critical enabler. These projects have long-term objectives to transform core elements of Malaysia's technology infrastructure and social systems. Elements of these applications have already been implemented in other parts of the world. But nowhere in the world has attempted to implement such applications within a single location from a green field. Thus, these projects will allow their implementation partners to use the MSC as a global test bed for multimedia and IT development. The contracts for these applications have already been awarded and in the tender specification unfortunately there is no specific commitment on the use IPv6.

5.9.2.3 Hong Kong The development of Hong Kong network infrastructure is being undertaken by the private sector telecommunication services operators under favourable market conditions from the government. This is very much the Hong Kong way of doing things.

Interactive Multimedia Services (IMS) ( http:// www.itvhk.com), a subsidiary of Hong Kong Telecom, launched the world's first broadband interactive TV (iTV) service in March 1998. This interactive multimedia service transforms the home into a full-time entertainment, shopping and information centre. iTV services include Video-On-Demand (VOD), Music-On-Demand (MOD), Racing-On- Demand (ROD), Radio-On-Demand, Home Shopping and Home Banking.

The iTV platform, chosen in 1996, is the first in the world to offer consumer television applications created with JAVA and transported with ATM technology. The set top box manufactured by NEC is running a PowerPC 602 processor with Microware’s OS-9 real-time operating system and DAVID (Digital Audio/Video Interactive Decoder) system software platform for digital television. In addition, the box also incorporates Sun Microsystem Java Virtual Machine (JVM v1.1.4) for DAVIC. To connect to the Internet at a high speed, IMS provides subscribers with a basic start-up kit, which includes a proprietary iTV Ethernet card for the set top box and a LAN cable to connect the set top box to a Ethernet card in the PC.

5.9.3 High Performance Networks for Next Generation Applications During the boom times in Asia, many Asian countries have seen exponential growth in Internet usage and the various governments and related research institutions have recognised the importance of investing in Internet related R&D activities. Led by Japan, the undisputed technology leader in Asia, several Asian Internet initiatives such as the Asia Pacific Advance Network and the Asian Internet Interconnection Initiatives were started to link the various projects in different Asian countries together. In this review, countries like Australia, Japan, Korea and Singapore are reviewed as they play an important role in the Asian R&D arena.

5.9.3.1 Asia Pacific Advance Network (APAN) Various countries in Asia like Australia, China, Japan, Korea, Malaysia, Singapore, Taiwan and Thailand have developed its own high-speed testbeds for research and development. In 1997, the APAN (http://www.apan.net) was formed to interconnect these national projects into a mega R&D network in Asia with global interconnectivity. Global links are available through STAR TAP in Chicago, which has connections to CANARIE, CA*net 2 and various European high performance research networks such as TEN-34. APAN and Indiana University have also initiated a project called TransPAC to create a high-speed interconnection with vBNS through STAR TAP. The TransPAC project is supported by the US National Science Foundation with a US$10 million grant. The APAN project is also part of the Asia Pacific Information Infrastructure (APII) championed under the auspices of APEC.

As a consortium of research networks, APAN does not own any international circuit. Network infrastructure such as the communication links and exchange points in Japan, Korea and Singapore are paid by individual APAN members. The primary members of APAN are Australia, Japan, Korea and Singapore while associate members, which are linked via the Asian Internet Interconnection Initiatives, are countries like Indonesia, Hong Kong and Thailand.

To conduct research into network technology, APAN has formed various sub-working groups to examine issues in IPv6, MBone, traffic measurement, RSVP, Security and Cache. APAN has also formed various Application Working Groups in the domain of Bio-Informatics, Education, Engineering, Environment, Medical Informatics and Science.

Source: http://apan.net/topology/map.JPG

5.9.3.2 Asian Internet Interconnection Initiatives (AI3) The goal of the AI3 project (http://www.ai3.net) is to focus on technologies to provide an open Internet testbed for the research and academic community in Asia. The AI3 is organised as a joint research

115 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 program with other research entities called the AI3 partners. Current partners include organisations from Hong Kong, Indonesia, Japan, Malaysia, Singapore and Thailand.

The AI3 testbed network uses the VSAT satellite links provided by JCSAT-3 communication satellite, which provides the Asian Zone Beam (Ku band) that covers several east and south-east Asian countries. The VSAT communication channel is currently modelled as a point-to-point 2 Mbit/s satellite link but the satellite communication is based on broadcast transmission mechanism.

The AI3 project is involved in network design for the future Asia-Pacific Information Infrastructure (APII), research into new technologies which enables IP multicasting over satellite communication channels and advanced routing method based on IPv6 to use the channels efficiently. The project also includes promotional activities of Internet technologies for other countries in Asia. AI3 testbed network is currently part of several global testbeds such as MBone and 6Bone.

5.9.3.3 Australia As part of the Australia Information Industries Online Program to encourage collaboration between Australian and Japanese researchers, the Department of Industry, Science and Tourism (DIST) tasked the Cooperative Research Centre for Advanced Computational Systems (ACSys CRC) to establish a dedicated computer network link between Australia and Japan (http://www.au.apan.net/). The link, running over international Frame Relay became operational in February 1998, for an initial period of two years. A dedicated 768 kbit/s Committed Information Rate (CIR) on a 1.5Mbit/s bearer is provided initially and provision is made for future growth depending on demand. In Australia, the link terminates on the Australian National University campus in Canberra. In Japan, the link is in turn connected to APAN. ACSys CRC is currently seeking expressions of interest from Australian researchers wishing to make use of the Australia-Japan link for projects which could possibly include IPv6.

5.9.3.4 Japan The Widely Integrated Distributed Environment (WIDE) project is a research consortium in Japan consisting of a few hundred researchers in universities and companies that focus on the Internet and related technologies (http://www.v6.wide.ad.jp). The WIDE project manages an IPv6 network, called WIDE 6bone since June, 1996. Currently, the WIDE 6bone is one of the largest IPv6 test-beds in the world. In this testbed, various data-links including serial links and ATM PVCs are used.

The Topology of WIDE (Source: http://www.isoc.org/inet98/proceedings/6b/6b_3.htm)

The WIDE project has developed an IPv6 protocol stack in the KAME project (originally called hydrangea). It supports a whole bunch of IPv6 standard specifications like IPsec protocol. The members of the WIDE project have also developed an IPv6 and IPv4 translator and an Ipv6 name server. Hitachi Ltd, a partner in the WIDE project had developed a commercial IPv6 router.

5.9.3.5 Korea APAN Korea Consortium (APAN-KR) was established in 1998 as a local consortium of APAN (http://kr.apan.net). APAN-KR is intended to be a high-speed network for research and development on advanced applications and services in Korea. Since June 1998 three APAN-KR sites, namely, Seoul-XP, Korea Advance Institute of Science and Technology (KAIST), and KT Lab. KAIST and KT Lab are connected to Seoul-XP via ATM from the Advanced Testnet Project, co-ordinated by Korea Telekom. These two labs have also established an IPv6 tunnel between them.

Source: http://cosmos.kaist.ac.kr/whchoi/apan-kr/docs/topology.jpg

5.9.3.6 Malaysia APAN-Malaysia Consortium (http://network2.cs.usm.my) was formed to promote advanced research in networking technologies and the development of high-performance broadband applications. To build competency in its national project, the Malaysian Multimedia Super Corridor, APAN-Multimedia Working Group was created. Its main objective is to support and encourage R&D of multimedia applications that need the usage of high bandwidth networks which could be using either layer 2 (ATM cell) or layer 3 link (IP packet).

5.9.3.7 Singapore To support the research communities in Singapore in the area of broadband networking and the Next Generation Internet services, a separate research network called the Singapore Advanced Research and Education Network (SingAREN, http://www.singaren.org.sg) was announced in 1997. SingAREN, funded by the government, is managed by Kent Ridge Digital Laboratories (a government funded research institution), and the research centres of two local universities, the Nanyang Technological University and the National University of Singapore. SingAREN also administers a Broadband Grant to support R&D projects in broadband multimedia networking.

SingAREN Topology (Source: http://www.singaren.org.sg)

To link Singapore's R&D community to the global information infrastructure, SingAREN currently has a 14 Mbit/s link to STAR TAP in the United States, which in turn is connected to vBNS in the US and Canada’s CANARIE. SingAREN also has a 2 Mbit/s link to Japan and through that a further 2 Mbit/s link to Korea. Linkage to Europe is possible via CANARIE's transatlantic link. Research and Education establishments in Singapore can therefore make use of the international links to carry out collaborative research with their counterparts in the US, Canada, Japan, Korea and Europe.

The Multicast Technology Group (SAMToG) in SingAREN is a grouping of local and foreign project partners from industry, universities and research institution. Its main task is to evaluate the performance and suitability of various multicasting schemes (e.g. MBone, 6Bone, ATM multicast using MARS and LAN Emulation) over various broadband access technologies. It will also examine other issues like new multicast routing schemes, architectures, signalling platforms and interfaces as well as multicast in wireless/mobile environment.

5.9.4 Concluding Remarks The recent Asian economic crisis has certainly slowed down the cutting-edge activities in countries like Indonesia and Thailand. However, countries like Singapore and Japan which see the knowledge economy as the future for economic growth, still maintain large budgets for R&D – re-investing about 1% of their GDPs. It can also be seen that the R&D focus in Asia are different in each country. Countries like Thailand and Indonesia which have large rural areas, are committed to R&D activities in VSAT technology as it could be cheaper than having to lay fixed-lines. Malaysia, with its behemoth plan in the MSC, plays a role in leading the Multimedia Working Group in APAN. Singapore, with its huge national reserve and its government-led initiatives of developing a knowledge economy, is actively pursuing connectivity and R&D projects internationally. Hong Kong, lacking in a national infrastructure, is led mainly by commercial entities; this account for its low involvement in the R&D activities internationally. Japan and Korea which have a mature industry of technology driven companies have many projects that are commercially sponsored. Especially in Japan, the WIDE project partners consist of partners such as Fujitsu, NTT and Hitachi.

The net result, however, is that the Asian region is currently focussed on catching up with the building of a physical infrastructure for Next Generation (broadband interactive multimedia services) Internet. At present time, the core networks consists of mainly dark fibres. Concepts such as IPv6, QoS, multicasting and so on are at formative stages in the region. Given the lack of standard

118 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 implementations in the United States and Europe, it is unlikely that this will change in the near future. But the vision remains that in preparing for the knowledge economy, Asian countries are poised to ´turn the lights on` should the need arise.

5.10 CA*net 3 - Canada's Next Generation Internet Initiative

Bill St Arnaud, CANARIE, Canada

5.10.1 Introduction Recent developments in high density Wave Division Multiplexing fibre systems allow for the deployment of a dedicated optical Internet network for large volume backbone pipes that does not require an underlying multi-service SONET/SDH and ATM transport protocol. Some intrinsic characteristics of Internet traffic such as its self similar nature, server bound congestion, routing and data asymmetry allow for highly optimised traffic engineered networks using individual wavelengths. By transmitting GigaBit Ethernet or SONET/SDH frames natively over WDM wavelengths that directly interconnect high performance routers the original concept of the Internet as an intrinsically survivable datagram network is possible. Traffic engineering, restoral, protection and bandwidth management of the network must now be carried out at the IP layer and so new routing or switching protocols such as MPLS that allow for uni-directional paths with fast restoral and protection at the IP layer become essential for a reliable production network. The deployment of high density WDM municipal and campus networks also gives carriers and ISPs the flexibility to offer customers an integrated and seamless set of network services: IP directly over WDM for large volume IP networks and regional local loops, IP over ATM for VPNs and small bandwidth networks and IP over SONET for multiplexing with traditional TDM services.

In his budget speech on February 24th, 1998, federal Finance Minister Paul Martin announced a $55 million investment in a project to equip Canada by the year 2000 with the world's first optical Internet. This project is to be undertaken by CANARIE Inc.

5.10.2 Canada’s Optical Internet CA*net3 The optical Internet will be a pre-competitive R&D network to provide a research facility for Canadian companies and carriers to test new routing and switching technologies that will be required in commercial, optical Internet networks of the future and provide them with a platform for showcasing their Next Generation Internet products; and to provide Canadian researchers at universities and research laboratories doing advanced meritorious research or applications development with a high performance, high bandwidth network to carry out R&D that would not be possible on the existing commercial Internet.

There is a well-established body of research in optical network design, and many carriers are deploying WDM networks throughout the world. The intent of the R&D component of the optical Internet project is not to pursue pure research relating to optical networking technology, but to investigate how optical networks of the future may be optimised to take advantage of the unique characteristics of IP traffic and architecture.

Currently, all networks, even the most recent optical networks, are designed first and foremost to carry voice traffic. The optical Internet project will be the first attempt to build, from the ground up, a network designed first and foremost for data traffic, specifically Internet traffic.

On June 21st, 1998 a consortium led by Bell Canada was selected by CANARIE to be its research partner in deploying the optical Internet. The consortium members include Cisco, Nortel, Newbridge, JDS Fitel and Cambrian Systems amongst others.

In partnership with CANARIE the consortium will initially deploy an 8 wavelength OC-192 optical Internet across Canada next year. Initially only 2 wavelengths will be activated and the network will run in parallel with the existing CA*net 2 ATM network.

The network will interconnect 13 GigaPOPs where regional high speed research networks will interconnect to the optical Internet backbone. The GigaPOPs are already connected to the CA*net 2

119 InfoWin Thematic Issue: Next Generation Internet 19.07.1999 network and it is expected that most of the research into restoral and optical Internet engineering issues will be carried out at the GigaPOPs themselves.

The regional high speed networks connect up the major universities and research institutions in each province. Most of the networks are ATM or SONET based ranging anywhere from DS3 to OC-48 connectivity. Some of the regional high speed research networks will also be migrating to optical Internet architectures as well. So part of the overall research program will investigate optical Internet, network to network connectivity.

CA*net 3 GigaPOP Regional

WURCnet SRnet MRnet OC3 DS3 OC12 BCnet ACORN St. John’s OC3 Calgary Regina Winnipeg RISQ Charlottetown ONet OC48 Fredericton OC12 Teleglobe Montreal

Vancouver Ottawa Halifax

STAR TAP Toronto Chicago

CA*net 3: Canada's National Optical Internet Initiative

One of the major research topics that will be investigated will be the use of hybrid optical Internet architectures and various layer 3 restoral techniques using both WDM and ATM configurations.

Edmonton

Saskatoon Additional OC-192 WDM Routes for future use

Winnipeg Ottawa Calgary Regina Montreal Charlettown Vancouver St. John’s

Fredericton Toronto Teleglobe Chicago - CANARIE Drop Site Halifax

8 Wavelengths per route CANARIE OC-192 Route 4 reserved for traditional SONET 4/BLSR CANARIE OC-48 Route by carrier

5.10.3 The R&D Program The R&D program will also look at many aspects and issues related to optical Internet networking including, but not limited to:  asymmetric number of wavelengths for transmit and receive data  use of both sides of a fiber ring and parallel link paths  hybrid optical networking combining WDM IP with ATM or SONET  cut-through SONET  cut-through WDM  interfacing to tributary WDM, SONET and ATM services  wavelength striping  deployment of framing protocols other than SONET  routing convergence issues in the event of a fiber cut  artificial traffic generators to test QoS and convergence issues  data stripping over WDM  advanced QoS, explicit routing and multicast techniques  advanced caching and video server services  wavelength to wavelength routing from one regional network to another

The Canadian Next Generation Internet program will also explore how the optical Internet technologies developed for CA*net 3 can be used to provide low cost high speed Internet connectivity to the home- Gigabit Internet to the Home (GITH). The proposed GITH strategy calls for the deployment of a third residential network service operating in parallel with existing telephone and cable delivery mechanisms and thereby avoiding the regulatory and technical hurdles of integrating traditional telephone and cable services into one common delivery mechanism. The ´divergence` of these services rather than ´convergence` may allow for early and rapid deployment of GITH perhaps in advance of the currently planned large scale rollouts of cable modem and xDSL services.

There are many research issues that need to be addressed such as scaling, integrated layer 3 optical services and network management. The project goal envisages an economically viable architecture that allows for competitive equal access at both the physical and logical layers, by using low cost Dense Wave Division Multiplexing (DWDM) equipment, and new Internet architectural concepts currently under development in CANARIE’s optical Internet network -CA*net 3. It is estimated that a GITH system would cost less than Hybrid Fiber Coax (HFC) systems currently being deployed and would be marginally more expensive than xDSL or Cable Modem services. The access bandwidth could scale from as little as a few megabits per second to a mind boggling several terabits per second using either individual dedicated fibres, dedicated wavelengths, logical switched paths or direct statistical multiplexing in a neighbourhood router on a chip called a ´routing puck`. Governments may play a key role in accelerating the deployment of a GITH network by requiring service providers who want to provide public funded Internet service to schools and libraries to deploy at the same time a GITH network infrastructure that would easily scale to support thousands of homes with competitive equal access.

Research will also be carried out in new high bandwidth applications such as ´always on` applications, multimedia ´push` services, mega e-mail, DWDM caching, and DVD video applications.

More information is available at  http://www.canarie.ca  http://ww.canet3.ca

Annex 1: Alphabetical List of Contributors The following list contains the authors of all contributions in this publication, except for chapter 4 (Projects and Trials in ACTS); the contacts for the individual ACTS projects can be found in Annex 2.

Name Company/Institution Email

Rémy Bayou European Commission DGXIII [email protected] Franck Boissiere European Commission DGIII [email protected], Haakon Bryhni University of Oslo [email protected] Jon Crowcroft University College London J. [email protected] Roberto Donadio European Space Agency [email protected] Jean-Pierre Euzen European Commission DGXIII [email protected] Peter Feil Deutsche Telekom Berkom GmbH [email protected] Serge Fdida Université de Paris VI, LIP6 [email protected] Dirk Hetzer Deutsche Telekom Berkom GmbH [email protected] Peter Kirstein University College London [email protected] Magnus Krampell EURESCOM GmbH [email protected] Jiri Kuthan GMD Focus [email protected] Martin Potts Martel GmbH [email protected] Jürgen Rauschenbach DFN-Verein [email protected] Michel F. Roy European Commission DGXIII [email protected] Henning Sanneck GMD Focus [email protected] Ravi S. Sharma Deutsche Telekom Asia [email protected] Jeremy Sharp UKERNA [email protected] Dorgham Sisalem GMD Focus [email protected] Michael Smirnow GMD Focus [email protected] Bill St. Arnaud CANARIE Inc. [email protected] Roman Tirler European Commission DGIII [email protected] Dany Vandromme GIP RENATER [email protected] Goh Kheng Wee Deutsche Telekom Asia [email protected] André Zehl Deutsche Telekom Berkom GmbH [email protected]

Annex 2: Details of ACTS Projects in the Area of NGI For further information on the individual projects described in chapter 4 please contact the following persons:

AROMA (AC327) Dietrich Böttle Alcatel SEL AG Dept. ZFZ/NV Holderäckerstr. 35 D-70499 Stuttgart Germany phone: +49 711 869 32126 fax: +49 711 869 32453 email: [email protected] http://www.athoc.de/AROMA/

BTI (AC362) Niels Engell Andersen DSC Communications A/S Lautrupbjerg 7-11 DK 2750 Ballerup Denmark phone: +45 44 732 573 fax +45 44 733 650 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac362.htm

COIAS (AC363) Patrick Cocquet Dassault Electronique 55 Quai Marcel Dassault F-92214 Saint Cloud - Cedex France phone: +33 1 34 81 65 90 fax: +33 1 34 81 45 50 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac363.htm

DIANA (AC319) Martin Potts ASPA - Berner Technopark Morgenstrasse 129 CH-3018 Bern Switzerland phone: +41 31 999 42 80 fax: +41 31 999 34 22 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac319.htm

ELISA (AC310) Berthold F. Koch Siemens AG, Public Communication, Networks Group OE ME 11 Hofmannstr. 51 D-81359 München Germany phone: 49 89 722 22465 fax: 49 89 722 41920 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac310.htm

ITHACI (AC337) Nikos Karatzas Algosystems S.A. 4, Sardeonstr. 17121 N. Smyrni, Athens Greece phone: +30 1 93 10 281 fax: +30 1 93 52 873 email: [email protected] www.algo.com.gr./acts/ithaci/

MULTICUBE (AC012) Antonio Sciarappa Department UF/D CSELT Via Reiss Romoli 274 I-10148 Torino Italy phone: +39 011 228 6153 fax: +39 011 228 6190 email: [email protected] http://www.cselt.it/sonah/MULTICUBE/

PETERPAN (AC307) Giancarlo Rigolio Italtel - Central R&D Labs-Co2 I-20019 Settimo Milanese (Milan) Italy phone: +39 02 4388 8518 fax +39 02 4388 7989 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac307.htm

SUSIE (AC320) Donald Morris Teltec Ireland, Dublin City University Glasnevin, Dublin 9 Ireland phone: +35 31 704 5405 fax +35 31 704 5092 email: [email protected] http://www.infowin.org/ACTS/RUS/PROJECTS/ac320.htm

Annex 3: List of Acronyms and Abbreviations AAL ATM Adaptation Layer ACTS Advanced Communication Technologies and Services APAN Asia Pacific Advanced Network API Application Programming Interface ARP Address Resolution Protocol ATC ATM Transfer Capability ATM Asynchronous Transfer Mode BGP Border Gateway Protocol CAC Call Admission Control CBR Constant Bit Rate CIDR Classless Inter-Domain Routing CL Controlled Load CLIP Classical IP over ATM CSCW Computer Supported Co-operative Work DNS Domain Name Service EARTH Easy IP Multicast Routing Through ATM Clouds EC European Commission ESA European Space Agency GS Guaranteed Service GTB Gigabit Testbed HFC Hybrid Fibre-Coax ICMP Internet Control Message Protocol IETF Internet Engineering Task Force IRTF Internet Research Task Force IGMP Internet Group Management Protocol IP Internet Protocol IPnG Internet Protocol Next Generation IPX Internet Packet Switching Protocol (from Novell) ISO International Standards Organisation ISP Internet Service Provider IST Information Society Technologies ITU International Telecommunication Union LIS Logical IP Subnet MARS Multicast Address Resolution Server MIB Management Information Base MPEG Motion Picture Experts Group MPLS Multiprotocol Label Switching MPOA Multiprotocol over ATM MTU Maximum Transmission Unit NAT Network Address Translation NBMA Non-Broadcast Multi-Access NGI Next Generation Internet NSF National Science Foundation OAM Operation and Maintenance PBX Private Branch Exchange PDA Personal Digital Assistant PIM Protocol Independent Multicast PNO Public Network Operator POTS Plain Old Telephony Service PSTN Public Switched Telephone Network PVC Permanent Virtual Circuit QoS Quality of Service RED Random Early Detect RFC Request for Comment (Internet Standard) RPC Remote Procedure Call RSVP Resource Reservation Protocol RTP Real-Time Protocol SDH Synchronous Digital Hierarchy SIP Session Initiation Protocol

SNMP Simple Network Management Protocol SONET Synchronous Optical Network STM Synchronous Transport Module SVC Switched Virtual Circuit TCP Transmission Control Protocol TOS Type of Service TTL Time-To-Live UDP User Datagram Protocol UMTS Universal Mobile Telecommunication System UNI User Network Interface VAT Visual Audio Tool vBNS very high performance Backbone Network Services VBR Variable Bit Rate VC Virtual Channel VPN Virtual Private Network WDM Wave Division Multiplexing WWW World Wide Web

Next Generation Internet in Europe is a publication of the ACTS project InfoWin (AC113). InfoWin produces regular publications covering the activities of ACTS projects as well as hot topics in advanced telecommunications.

Other InfoWin publications include:

 ACTS Headline News and events  InfoWin Bulletin with articles for and about ACTS  Thematic Issues of telecom topics (e.g. Multimedia Broadcast, Mobile Communications, ATM in Europe, Information Brokerage, Photonic Technologies in Europe)

InfoWin publications are available on paper, CD-ROM, or on the World Wide Web at http://www.infowin.org/

ISBN 3-00-004250-4