Next Generation Networks in Europe

Next Generation Networks in Europe

ΔΕ ΙΓ Μ

Α

From ACTS to IST

Next Generation Networks in Europe From ACTS to IST

ISBN 84-923942-1-8 Edited by the ACTS Project InfoBridge (AC 359) InfoBridge is partly funded by the European Commission DGXIII through the Advanced Communications Technologies and Services (ACTS) Programme.

Enrique Vázquez Gallo

ΔΕ ΙΓ Μ

Dep. Telemática ETSI Telecomunicación 28040 Madrid Spain [email protected]

Α

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

Copyright 2000 by InfoBridge Reproduction in whole or part is only permitted with explicit reference to the source.

2

3

ΔΕ ΙΓ Μ Α

Table of contents Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 1.2 1.3 1.3.1 1.3.2

1.4 1.5 1.6

2

From ACTS to IST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The High-Speed Networking Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . The IP-ATM Project Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Papers from IP-ATM Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP-ATM Guidelines and Other References . . . . . . . . . . . . . . . . . . . . . . . . . . . Quantum and TEN-155 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topics in NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . New IST Projects Related to NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Α

1

The High-Speed Networking Domain of ACTS . . . . . . . . . . . . . . . . . Towards Global Broadband Communications . . . . . . . . . . . . . . . . . . . . . ATM Circles the Globe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NICE and JAMES—The Largest ATM Network Ever . . . . . . . . . . . . . . . . . . . Extending ATM to Japan via Satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Satellites, ATM and the Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrating Satellites into ATM Networks . . . . . . . . . . . . . . . . . . . . . . . . . . WATT puts the ACTS Trials on-line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Global 360 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Access Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM and Internet for the Home and Office . . . . . . . . . . . . . . . . . . . . . . . . . . Broadband to the Home over Optical Fibre . . . . . . . . . . . . . . . . . . . . . . . . . 25-50 Mbit/s over Twisted Pairs? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building Blocks for Future Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATLAS—a Single Chip ATM Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REFORMers promote Co-existence between Network Technologies . . . . . IN and B-ISDN Signalling Integration on ATM Platform . . . . . . . . . . . . . . . Protection across Network Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Charging Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . High-Speed Networks in Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intercontinental Virtual Classrooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 22 22 22 23 23 23 24 24 24 25 25 26 26 26 26 27 28 29 29

High Flying High-Speed Networks for the Automotive 29 and Aerospace Industries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Guidelines for Interoperability in Networks and ATM deployment . . . . . . .

29 30

ΔΕ ΙΓ Μ

2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6

2.3

2.3.1 2.3.2 2.3.3

2.4

2.4.1 2.4.2 2.4.3 2.4.4 2.4.5

2.5

2.5.1 2.5.2 2.5.3

4

8 11 11 11 12 12 15 17 18 19 19

3.1 3.1.1 3.1.2 3.1.3

3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5

ΔΕ ΙΓ Μ

3.3

The IP-ATM Project Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP-ATM Trials and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Next Generation Network Trends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Project Trials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Results from the Trials . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AROMA: The Role of the MAC Protocol in Offering QoS to IP Services Over Shared Access Systems . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Differentiation in an Access Multiplexer . . . . . . . . . . . . . . . . . . . . . The MAC as an Executor of Per Hop Behaviours . . . . . . . . . . . . . . . . . . . . . Performance Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ELISA: QoS for IP over ATM—a Combined IntServ / DiffServ Approach Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The ELISA Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Business Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion and Outlook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IthACI: Layer 4 QoS Detection in Flow-Based IP-Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . An Implementation of RTP Flow Detection . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PETERPAN: Integration of IP and ATM for QoS and Multimedia Services Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PETERPAN Network Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applications and Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experiments and Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6

3.4

3.4.1 3.4.2 3.4.3 3.4.4

3.5

3.5.1 3.5.2 3.5.3 3.5.4 3.5.5

31 31 32 34 40 49 49 50 52 55 57 57 57 58 58 58 59 62 64 66 67

Α

3

69 70 72 75 78 78 80 80 82 84 87 91 92 92

5

3.6 3.6.1 3.6.2 3.6.3

Quantum and TEN-155 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 4.1

TEN-155 Managed Bandwidth Service . . . . . . . . . . . . . . . . . . . . . . . . . . 101 101 101 102 103 104 105 105 Interim Results of the Quantum Test Programme . . . . . . . . . . . . . . . . . . 106 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Multicasting (IP and ATM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 Differentiated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Other Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TEN-155 Managed Bandwidth Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Users of the Managed Bandwidth Service . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ΔΕ ΙΓ Μ

4.1.1 4.1.2 4.1.3 4.1.4 4.1.5 4.1.6

4.2

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5

5

5.1

5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6

5.2

6

94 94 95 96

Α

4

SUSIE: Project Objectives and Relationship to Next Generation Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference Model and Business Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Field Trial Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trial Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Topics in Next Generation Networks . . . . . . . . . . . . . . . . . . . . . . . . . IP version 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPv6 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What is IPv6? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Why have IPv6? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IPv6—New Opportunities for European Public Network Operators . . . . . . IPv6 Forum: IPv6 Around the World . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

109 109 109 109 110 110 110 111 115

DTM—A Comparison with ATM in the Support of IP Applications with Constraint Needs of QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATM and DTM—Advantages and Drawbacks in Aspects of QoS . . . . . . . . . Perfomance Analysis of ATM and DTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration of IETF QoS Models with ATM and DTM . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Advanced Collaborative Services over Broadband Networks: the ISABEL Experience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Group-collaboration models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A description of ISABEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Set-up services over heterogeneous networks . . . . . . . . . . . . . . . . . . . . . . Experiences of use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

143 143 144 147 151 155 159 159

6.3

New IST Projects Related to NGN . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Fifth Framework Programme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Emerging IST Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Value-added Integrated Service Delivery . . . . . . . . . . . . . . . . . . . . . . . . . . . Protocol Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conventional and Integrated Services Networks Integration . . . . . . . . . . . Local Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Challenge for Industry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

161 161 162 162 163 163 163 164

7.1 7.2 7.3

Appendices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alphabetical List of Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Details of ACTS Projects in the IP/ATM Cluster . . . . . . . . . . . . . . . . . . . . List of Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

165 167 167 169

5.3.1 5.3.2 5.3.3 5.3.4 5.3.5

5.4 5.5

ΔΕ ΙΓ Μ

5.5.1 5.5.2 5.5.3 5.5.4 5.5.5 5.5.6

6

6.1 6.2

6.2.1 6.2.2 6.2.3 6.2.4

7

126 126 129 132 135 138 138 140 142

Α

5.3

7

Preface

ΔΕ ΙΓ Μ

Α

At the time of writing this book, the Advanced Communication Technologies and Services (ACTS) Programme is coming to its end, and the last active projects are finishing their activities. At the same time, new R&D projects on advanced networking and other topics are being launched by the Information Society Technologies (IST) Programme, within the European Fifth Framework Programme of research, technological development, and demonstration. Next Generation Networks in Europe—From ACTS to IST gives an overview of the results produced by ACTS in High-Speed Networking (one of the six Domains of the programme), and presents the objectives of new IST projects included in the Action Line IV.2.3: Network Integration, Interoperability, and Interworking. This book has been edited by the ACTS project InfoBridge (former InfoWin), based on input from InfoBridge partners and from external contributors, including representatives of the European Commission, other ACTS projects, companies, and research institutions. The editor is particularly thankful to Paulo de Sousa (European Commission) and Martin Potts (Martel GmbH) for their valuable contributions and kind help in the preparation of this publication. Articles from the following authors are gratefully acknowledged (in alphabetical order): Jose Manuel de Arce (DANTE) Arturo Azcorra (Universidad Carlos III de Madrid) Bert F. Koch (Siemens) Tomás P. de Miguel (Universidad Politécnica de Madrid) Kevin O’Leary (Teltec Ireland) Jordi Palet (IPv6 Forum) Martin Potts (Martel GmbH) Roberto Sabatino (DANTE) Paulo de Sousa (European Commission)

8

The editor would also like to thank Latif Ladid (IPv6 Forum), Cathrin Stover and Marine Chartois (DANTE), Sathya Rao (Telscom AG), and all the authors of the papers selected from the 4th International Distributed Conference IDC ‘99, and Globecom’99 (session on IP and ATM convergence). This book is also available on the WWW at http://www.dit.upm.es/infowin/ngn/

ΔΕ ΙΓ Μ

DIT-UPM Departamento de Ingeniería de Sistemas Telemáticos Universidad Politécnica de Madrid, Spain http://www.dit.upm.es/

Α

Enrique Vázquez Gallo Editor [email protected]

9

10

ΔΕ ΙΓ Μ Α

1 Introduction 1.1

From ACTS to IST

ΔΕ ΙΓ Μ

Α

Throughout the Advanced Communication Technologies and Services (ACTS) Programme [1], the project InfoBridge and its predecessor InfoWin have produced a series of printed and online publications called Thematic Issues. These publications describe the objectives, trials, and results of projects within the different R&D domains covered by ACTS: Multimedia, Photonics, High-Speed Networking, Mobiles, and Service Engineering. Two previous Thematic Issues, ATM in Europe—ACTS Trials [2] and Next Generation Internet in Europe [3], published in 1998 and 1999 respectively, have reported the progress of the projects included in the High-Speed Networking (HSN) Domain of ACTS. Under the title Next Generation Networks in Europe—From ACTS to IST, this book summarises the most recent results obtained by ACTS projects in the HSN domain, and gives an outlook to the related work planned by new projects in the Information Society Technologies (IST) Programme [4]. IST is one of the major specific research activities in the Fifth Framework Programme of research, technological development, and demonstration, involving a European Union funding of 3.6 billion Euro over four years. The following paragraphs introduce the main chapters of this book.

1.2

The High-Speed Networking Domain

Chapter 2 gives an overview of the work done in the HSN Domain of ACTS. It is divided into the following sections: ATM circles the globe, access networks, building blocks for future networks, and high-speed networks in action. Some of the projects covered in detail in chapters 3 and 4 are briefly mentioned here together with other projects that belonged to the HSN domain. The material presented in this chapter has been extracted from the impACTS 2000 publication [5], also produced by InfoBridge. ImpACTS 2000 outlines the main results of all Domains of ACTS.

11

1.3

The IP-ATM Project Cluster

Α

During the last part of ACTS, the HSN domain addressed the problem of IP-ATM interoperability and associated Quality of Service issues. Eight projects stemming from the ACTS 3rd call (June 1997) studied different aspects of this problem: • AROMA: Advanced Resource Management in Service Integrated Multi-layered HFC Access Networks • BTI: Broadband Trial Integration • COIAS: Convergence of Internet and ATM in Satellite • DIANA: Demonstration of IP & ATM Networking Applications • ELISA: European Experiment on the Linkage between Integrated Services & ATM • IthACI: Internet ATM Experiments for Convergence & Integration • PETERPAN: Provision of an Enhanced Transport by Exploiting Reservation in IP & ATM Networks • SUSIE: Charging for Premium IP services in Information Infrastructures & Services Pilots

ΔΕ ΙΓ Μ

These projects formed the so-called IP-ATM Cluster in order to co-ordinate their activities, avoid overlaps, and share developments. The thematic issue “Next Generation Internet in Europe” presented the objectives and technical approach of each project, and their status at the end of 1998. At the time of writing this book, the projects are reaching completion, and are performing trials and making measurements. Section 3.1 of this book describes the trials, relates the results obtained by the different projects, and examines the implications of their findings for next generation networks. Although all projects focused on solutions that include some form of IP-ATM convergence, some of them evaluated also other new solutions for Quality of Service (QoS) support.

1.3.1

Papers from IP-ATM Projects

Sections 3.2 through 3.6 present a selection of papers that provide a more detailed view of the work done by each project. Most of these papers were published in IDC ‘99 or Globecom ‘99. The 4th International Distributed Conference—IDC ‘99 (Madrid, Spain, 22-23 September 1999) was organised by the ACTS NI Chain Group (see Section 1.3.2) with the support of the European Commission, the ACTS project GINA, Quantum, and other European projects. The Globecom’99 Business and Application Session on IP and ATM Convergence (Rio de Janeiro, Brazil, 7 December 1999) was organised by Paulo de Sousa, from the European Commission. The paper “The Role of the MAC Protocol in Offering QoS to IP Services over Shared Access Systems” describes the application of the Differentiated Services model to shared access networks such as Hybrid Fibre Coaxial (HFC) and Passive Optical Networks (PON).

12

ΔΕ ΙΓ Μ

Α

DiffServ is well suited to the hardware-based MAC protocol that allocates upstream (user to network) time slots to the different traffic streams sharing the transmission medium. The paper describes the DiffServ implementation made by the AROMA project, and its evaluation using simulation. In addition to best-effort and QoS enhanced IP services, the system implemented by AROMA supports native ATM services. Time slots are designed for ATM cells and Classical IP over ATM is used to map IP flows to ATM connections. Several consecutive slots are assigned to transmit an IP packet. However, a delay-sensitive packet can interrupt the transmission of a lower priority packet at a time slot boundary. The transmission is resumed later, when the delay-sensitive packet has been sent. AROMA decided to aggregate traffic flows at the MAC layer in four priorities: CBR traffic (equivalent to Expedited Forwarding), real-time VBR traffic, e.g. video or voice over IP (top Assured Forwarding class), data traffic with higher requirements than best-effort (lower Assured Forwarding classes), and best-effort traffic. A MAC algorithm was designed to support these priority levels and the delay observed by each priority was estimated by simulation. This paper was presented in the Business and Application Session on IP and ATM Convergence during Globecom ‘99. The paper “QoS for IP over ATM—a Combined IntServ / DiffServ Approach” reports on the experimentation of a network architecture for Quality of Service for Internet applications. The new architecture, defined by the ELISA project, supports the Integrated Services as well as the Differentiated Services approaches in a smoothly integrated way and uses the capabilities of an underlying ATM network to realize QoS. The enhancements to the existing network infrastructure are deliberately limited to the integration of a single new type of network element called Edge Device. The paper presents the network architecture as well as business scenarios and scalability analysis. This paper is based on a chapter of the book “Flexible Working—New Network Technologies—ACTS Activities” jointly produced by the ACTS projects DIFFERENCE, InfoBridge, and ACTSLINE [6]. In “Layer 4 QoS Detection in Flow-based IP Switching”, the IthACI project describes a solution for providing Quality of Service to applications that use the RTP protocol. With this solution, RTP flows are detected in real-time without explicit signalling. The characteristics of each flow are analyzed and the flow is assigned to a particular Class of Service that determines the priority of the flow in the network. Thus, the approach taken by IthACI is similar to DiffServ, and does not support per-flow QoS guarantees. As RTP does not have a protocol number like e.g. TCP, the detection of flows is based on simple RTP header validity checks. RTCP packets are not considered, although the question of whether RTCP packets should also receive QoS is open. The scheme proposed by IthACI was implemented on the IPSOFACTO IP switching architecture. IPSOFACTO, defined by NEC, is a soft-state, traffic-driven IP switching technique, where each node creates shortcut paths independently of the others, and uses ATM hardware

13

ΔΕ ΙΓ Μ

Α

for fast packet forwarding. The IPSOFACTO router-switch consists of a standard PC with Linux, which controls a NEC ATM switch with the GSMP protocol defined by Ipsilon. IthACI integrated the RTP flow detection function in the IPSOFACTO multicast-forwarding module. In this implementation, RTP multicast flows are mapped to dedicate point-to-multipoint ATM VCs with the highest GSMP priority. This paper was presented in IDC ‘99. The paper “Integration of IP and ATM for QoS and Multimedia Services Support”, presented by the PETERPAN project in IDC ‘99, proposes a network concept based on hybrid IP-ATM nodes for supporting Quality of Service guarantees. This network concept focuses on Integrated Services and RSVP, although it can also accommodate the Differentiated Services approach, for example IntServ at the network edge and DiffServ at the core. The paper considers two ways of providing QoS to the applications. In the first one, an RSVP Management Module handles resource reservations on behalf of RSVP-unaware applications. In the second one, a QoS middleware provides a generic QoS interface to applications. The interface is generic in the sense that it can be used with RSVP or with other signalling protocols. Two applications, video telephone and interactive multimedia retrieval, were used to test the interface. To evaluate its network concept, PETERPAN performed trials in four countries: Italy (Milan and Pisa), Portugal (Lisbon), UK (Lancaster), and USA (Los Angeles). The paper “SUSIE: Project Objectives and Relation to Next Generation Internet” describes the charging approach proposed by the SUSIE project for Premium IP Services (i.e. IP services enhanced with Quality of Service). New service models based on Integrated Services, Differentiated Services and MPLS were addressed. The SUSIE charging approach includes the development of a charging reference model, the design of charging algorithms for various Premium IP services, and the design, implementation and testing of systems for metering, accounting and charging. The paper reviews the charging reference model and business model considered by SUSIE, the field trials made, and the results and feedback obtained. SUSIE used a layered charging reference model. The metering layer collects measures of resource usage and forwards them to the accounting layer, which consolidates them. Then, the charging layer applies the appropriate tariffs, and, finally, the billing layer sends the bill to the customer. The business model assumes that retail IP services with QoS are provided directly to the customer, with the retailer purchasing wholesale services from another provider. The various metering, accounting and charging prototypes developed by the project were validated in a field trial with real users. A virtual classroom environment was set up, in which schools from Ireland, Germany, Switzerland, and Canada interacted through videoconference sessions. ATM backbone traffic (“wholesale traffic”) and IP traffic at one school (“retail traffic”) were metered and charged. Consolidate charging was performed at the IP layer in a TINA-based accounting system.

14

1.3.2

IP-ATM Guidelines and Other References

ΔΕ ΙΓ Μ

Α

In ACTS, Domains and Clusters allowed the co-operation of projects working in similar technical problems. The ACTS Concertation process included also the concept of Chains. A Chain was formed by a group of projects from different technical areas (i.e. Domains) which collectively addressed an objective of strategic importance outside ACTS. Chains were organised in five Chain Groups and presented their results in documents called Guidelines. Guidelines are not compulsory rules, but road maps for the introduction of advanced communication networks and services. They point not only to purely technical issues, but also to potential roadblocks, techno-economic aspects, social aspects, policy and regulatory issues, and standardisation activities. In general, its target audience includes equipment manufacturers, network operators, policy makers, and users. The Network Level Interoperability and Management (NI) Chain Group is the most relevant for the topics addressed in this book. In particular, the Network Global Interoperability (NIG) Chain has produced two guidelines based on work done by the projects described in this book: • NIG Guideline G3: IP and ATM Integration [7]. This guideline is based on input from CONVAIR, DIANA, EXPERT, IthACI, MULTICUBE, PETERPAN, and other projects. • NIG Guideline G12: IP and ATM Co-existence Trials [8].

The first guideline is organised in a set of scenarios and questions that apply to the different aspects of IP and ATM integration. Integration, defined as the support of IP over (or within) ATM, is a particular case of co-existence. Another particular case is IP and ATM interworking, which means the interoperation between applications or between complete protocol stacks, IP on one side and ATM on the other side. Interworking is not covered in NIG-G3. Nine basic scenarios of IP and ATM integration have been identified, grouped in three levels. Level 1: use of IP over an intermediate layer over ATM: • B1: IP over LAN Emulation over ATM.

Level 2: use of IP directly over ATM: • B2: trunking of IP systems (host and/or routers), over ATM (best effort). • B3: use of Classical IP over ATM to emulate a virtual unicast IP subnetwork over ATM. • B4: use of MARS to emulate a virtual multicast and broadcast IP subnetwork over ATM. • B5: use of NHRP to provide unicast IP shortcuts between devices over ATM. • B6: use of MPOA to provide shortcuts for bridged IP traffic between two LAN based devices over ATM. • B7: use of RSVP over ATM to associate IP and ATM resource reservations. • B8: use of Differentiated Services over ATM to associate various services classes (resources) to IP flows.

15

Level 3: IP merged with ATM: • B9: use of MPLS to provide IP flow forwarding at the ATM level.

Α

Additionally, four combination scenarios have been defined: • C1: use of classical IP with MARS (combination of B3 and B4) to provide an unicast, multicast and broadcast virtual IP subnetwork. • C2: use of MARS with NHRP (combination of B4 and B5) to provide unicast shortcuts with a full IP subnetwork emulation. • C3: use of trunking with RSVP (combination of B2 and B7) to provide trunking with resource reservation. • C4: use of trunking with Differentiated Services (combination of B2 and B8) to provide trunking with service classes.

ΔΕ ΙΓ Μ

The guideline NIG-G3 aims at clarifying the state-of-the art of the competing IP-ATM architectures and technologies. It is intended to help Technology Strategists when advising Business Strategists (commercial management and marketing decision-makers) or End Users (including both purchasing decision-makers within large companies as well as SMEs and individual residential users). For each scenario listed above, the guideline provides answers to the following questions: • What is the state of the art in this scenario? • What opportunities/threats are there for my business using this scenario? • Will this scenario allow my company to best progress our business? • What are the cost/benefits of this scenario? • When should I use this scenario? • Should I use another scenario? • Will the next generation be compatible/interwork with my existing equipment? • What impact (if any) would the next generation Internet Protocol (IPv6) have on this scenario? For example, the following figure (adapted from [7]) summarizes the answers to the question “should I use another scenario?” An arrow from X to Y indicates that scenario X may be replaced by scenario Y for the reason indicated on the arrow. The guideline NIG-G3 focuses on technology, and gives neither commercial, nor time dependent information. Its statements and recommendations are supported by results from ACTS project trials. The second guideline, NIG-G12, complements NIG-G3 by including more direct results from the project trials. At the time of writing this book, NIG-G12 was in a draft state [8]. Contributions were expected from projects DIANA, ELISA, IthACI, PETERPAN, and SUSIE. These guidelines assume that the reader is familiar with the different approaches compared: CLIP, LANE, MPOA, MPLS, etc. A comprehensive introduction to these approaches

16

Α ΔΕ ΙΓ Μ Figure 1: Transitions between IP-ATM Integration Scenarios (see [7]).

can be found in the report “IP and ATM—A Position Paper” written by the ACTS project EXPERT [9]. For additional information, see the links to ACTS domain, chain, and project Web home pages listed in the references at the end of this chapter.

1.4

Quantum and TEN-155

Several international trials of SUSIE, DIANA, BTI, and other projects were supported by the TEN-155 pan-European network. TEN-155 is a high-speed backbone, with access speeds up to 155 Mbps, that interconnects National Research Networks in Western and Central European countries. It replaced the former 34 Mbps backbone (TEN-34) on December 1998. TEN-155 is one of the results of the project Quantum, co-funded by the European Commission DGXIII. Much of the capacity of the TEN-155 network is devoted to a best effort IP service. However many European projects use multimedia applications requiring a high Quality of Service which cannot be provided over best effort IP. The TEN-155 Managed Bandwidth Service (MBS) addresses this issue by allowing the definition of Virtual Private Networks with dedicated end-to-end bandwidth across Europe. The service allows projects to request bandwidth for specified periods of time, connecting specified nodes, with various service guaranties.

17

Another result of this project is the Quantum Test Programme (QTP) on advanced ATM and IP testing. QTP tests new technologies with a view to introducing them into the operational TEN-155 network at some future date. Work items in QTP include, for example: IP and ATM level multicasting, Differentiated Services, MPLS, RSVP to ATM SVC mapping, Quality of Service monitoring, IP over ATM, and IP version 6. Chapter 4 of the book includes two contributions from DANTE, the company that coordinates Quantum, describing respectively the TEN-155 MBS and the QTP.

1.5

Topics in NGN

ΔΕ ΙΓ Μ

Α

The preceding overview of European project results focused on IP Quality of Service and IPATM integration issues. To complement this overview, Chapter 5 presents related technical topics under the generic label of Next Generation Networks. It includes an interview and several papers by different authors. Except for the last one (see list below), the papers do not describe direct results of any particular ACTS project. However, the European contribution in most of these areas is being very significant. • The first topic in this chapter is IP version 6. The IETF has been working on the next generation of the IP protocol since 1994. With the standardization work basically complete, in July 1999 a worldwide consortium of leading Internet companies and research institutions formed the IPv6 Forum to promote the protocol deployment. The first paper, presented by the President of the IPv6 Forum in the IDC ‘99 conference, gives the background of IPv6 and summarizes the main advantages of the protocol. Then, an interview with the chairperson of the IPv6 Forum Education and Awareness Working Group describes the Forum structure and activities, the IPv6 trials, and the current status of IPv6 around the World. • The paper “DTM—A comparison with ATM in the Support of IP Applications with Constraint Needs of QoS.” compares the Dynamic Synchronous Transfer Mode (DTM) with ATM in terms of Quality of Service support, performance, and complexity. The integration of IntServ and DiffServ with DTM is outlined. This paper was presented at IDC ‘99. • Much of this book deals with the problem of guaranteeing Quality of Service in communication networks, in particular in the future Internet. The large effort dedicated to the development of ATM and, more recently, of Integrated/Differentiated Services Internet, shows the interest of the networking industry in supporting a range of QoS levels in packet (cell) switched networks. The paper “Active Networks” introduces a new network model recently proposed to solve a different problem: developing a networking technology that provides a broad range of functional services. The paper describes the main components of the active network model and presents current projects in this area. • The chapter concludes with an example of the advanced interactive multimedia applications that put high-speed networks at the users’ service. In general, these

18

applications are in an experimental state today, but its use will soon be generalized. The paper is titled “Advanced Collaborative Services over Broadband Networks: the ISABEL Experience”. ISABEL, the application chosen for the example, has its origins in the European Programme RACE (Research and Development in Advanced Communications in Europe), and has been extensively used later by NICE and many other ACTS projects. By way of illustration, see the reference to the Global 360 event in Chapter 2. Additional information is provided in the section about the NICE project in [2], and in the ISABEL Web home page [10].

1.6

New IST Projects Related to NGN

ΔΕ ΙΓ Μ

Α

The EU is now starting the Information Society Technologies (IST) Programme [11] as part of the Fifth Framework Programme. IST includes four Key Actions: I) Systems and Services for the Citizen; II) New Methods of Work and Electronic Commerce; III) Multimedia Contents and Tools; and IV) Essential Technologies and Infrastructures. The IST 1999 workprogramme identified 24 Action Lines in Key Action IV. One of these is Action Line IV.2.3: Network integration, interoperability and interworking. According to the workprogramme, the objective of IV.2.3 is “to develop the next generation network technologies ... in order to enable integration at the transport level of multiple heterogeneous networks.” The scope includes “... networks that will support advanced generic services with end-to-end Quality of Service” running over wireline and wireless networks. The new projects may be tentatively classified into four groups: Value added Integrated Service Delivery, Protocol Extensions, Conventional and Integrated Services Networks Integration, and Local Access Networks. Topics related to traffic engineering, Class of Service implementations, Differentiated Services, IPv6, charging, etc. are addressed in the first group. Chapter 6 presents some of the new proposed projects, and outlines how the project collaboration in IP-ATM issues may continue in IST.

19

References

[2]

[3]

ΔΕ ΙΓ Μ

[4]

The ACTS Information Window. (Created by the ACTS project InfoWin and currently maintained by the ACTS project InfoBridge.) http://www.infowin.org/ (See note below.) – ACTS projects: http://www.infowin.org/ACTS/RUS/PROJECTS/ – High-Speed Networking Domain: http://www.infowin.org/ACTS/ANALYSYS/CONCERTATION/HSN/ – Network Integration Chain Group: http://www.infowin.org/ACTS/ANALYSYS/CONCERTATION/CHAINS/NI/ – ACTS Guidelines: http://www.infowin.org/ACTS/ANALYSYS/CONCERTATION/guihome.htm ATM in Europe—ACTS Trials. Edited by E. Vázquez, Technical University of Madrid. 2nd edition, September 1998. http://www.infowin.org/ACTS/ANALYSYS/PRODUCTS/THEMATIC/ Next Generation Internet in Europe. Edited by P. Feil, Deutsche Telekom Berkom GmbH, and R. Bayou, European Commission, DGXIII. 1999. http://www.infowin.org/ACTS/ANALYSYS/PRODUCTS/THEMATIC/ Information Society Technologies (IST) Programme. European Commission. http://www.cordis.lu/ist/home.html impACTS 2000. CD-ROM produced by the InfoBridge project. 1999. http://www.infowin.org/ACTS/RUS/IMPACTS/ “Flexible Working—New Network Technologies—ACTS Activities”. ACTS projects DIFFERENCE, InfoBridge, and ACTSLINE. IOS Press, 1999. IP and ATM Integration. Network Global Interoperability (NIG) Guideline G3. Edited by Eric Manie . Version 3.0 (final). May 1999. http://gina.iihe.ac.be/guidelines/ IP and ATM Co-existence Trials. NIG Guideline G12. Edited by Piergiorgio Cremonese . Draft 1.1. October 1999. http://gina.iihe.ac.be/guidelines/ IP and ATM—A Position Paper. Silvia Giordano, et al. ACTS project EXPERT. 1997. http://www.elec.qmw.ac.uk/expert/ The ISABEL tool. http://isabel.dit.upm.es/ Information Society Technologies (IS) Programme. http://www.cordis.lu/ist/home.html

Α

[1]

[5] [6] [7]

[8] [9]

[10] [11]

As InfoBridge and other ACTS projects are finishing in 1999 or early 2000, some project home pages, on line documents, and other ACTS-related Web pages referenced throughout this book may not be available in the future. In particular, the ACTS Information Window www.infowin.org will not be updated after December 1999. InfoBridge will create a master CD-ROM with the final contents of this site and deliver it to the European Commission.

20

2 The High-Speed Networking Domain of ACTS 2.1

Towards Global Broadband Communications

ΔΕ ΙΓ Μ

Α

High-speed networking is of strategic importance for Europe. New approaches to networking are needed to cope with the explosive growth of the Internet and the demands of mobile and multimedia services. The Advanced Communication Technologies and Services (ACTS) programme responded to this demand by making major advances in the High-Speed Networking domain at all levels: from the largest experimental ATM (Asynchronous Transfer Mode) network in the world, to a switch with Gbit/s capacity integrated in a single microchip. The next generation of the Internet must provide a better Quality of Service (QoS) that allows its users -all of us- to form virtual groups and interact in real-time using video, voice, text, and graphics. To make this a reality, it is necessary to overcome the limitations of the present Internet, increasing its capacity and improving its protocols. Several ACTS projects have explored different approaches to provide QoS on the Internet. They have implemented IP (Internet Protocol) nodes based on new models like Integrated Services, Differentiated Services, and various forms of IP switching and IP-ATM integration. (See Chapter 3.) Of course, improving the Internet not only means faster core network nodes and links, but also faster access lines that can deliver advanced services to both homes and offices. ACTS projects have demonstrated a range of broadband technologies for the ‘last mile’ of the network using optical fibre, coax cables, and even copper pairs. The technologies considered include ATM Passive Optical Networks, cable TV networks based on Hybrid Fibre Coax systems, and DSL (Digital Subscriber Loop) systems over copper lines. (Note that ACTS did not forget mobility. Quite to the contrary, mobile communications was one of the six key domains of ACTS, and very important results were obtained to pave the way for the 3rd generation of mobile systems.) Finally, ACTS projects in the High-Speed Networking domain have worked in several network building blocks, which may be less visible than the aspects mentioned above, but are equally important for future networks. These blocks include, for example, signalling protocols, charging schemes, mechanisms for automatic network recovery after failures, and network management procedures. The technical work of ACTS has produced a large impact, measurable in terms of technical publications, contributions to international standardization bodies (ETSI, IETF, etc.), prototypes and commercial products. Citizens of the Information Society will benefit from this work through advanced communication services available in all ambits of life. The following sections have been extracted from the impACTS 2000 publication, produced

21

by the InfoBridge project. Together with Chapter 3, which focuses on ACTS results in the area of IP-ATM integration and Quality of Service issues, these sections provide a general view of the work done in the High-Speed Networking Domain of ACTS.

2.2 2.2.1

ATM Circles the Globe NICE and JAMES—The Largest ATM Network Ever

ΔΕ ΙΓ Μ

Α

An advanced communications infrastructure will be the cornerstone of the Information Society. JAMES showed what this infrastructure might look like by setting up the largest experimental ATM (Asynchronous Transfer Mode) network in the world. The network brought together the achievements of more than ten years work in two major European collaborative research programmes: RACE (Research and Development in Advanced Communications in Europe) and ACTS. Eighteen major European network operators worked together to set up the JAMES network and use it for testing the interoperability of ATM features and capabilities. The JAMES network also provided trans-European connections for a large number of trials by other ACTS projects. These trials thoroughly tested both the service and technology aspects of the delivery platforms. All the trials were successful not only technically but also from the service usage and acceptance viewpoints. NICE started the process of extending the JAMES network to the rest of the world. It set up the first high-speed networking link between the Ukraine and the European Union using ATM technology to connect Kiev and Turin. The experiments have helped to create a basis for collaboration between researchers in the EU and in Central and Eastern Europe. They have also helped to promote the use of common technologies and standards between telecommunications operators in the EU and in Eastern Europe. 2.2.2

Extending ATM to Japan via Satellite

The global village is brought together by high-speed connections over optical fibre or satellite links. GAMMA used a satellite to connect European and Japanese researchers so that they could develop and test new applications over an ATM infrastructure. The trial used the JAMES European network, an INTELSAT link from the Leuk earth station in Switzerland to the Yamaguchi Earth Station in Japan and an ATM link provided by the Japanese operator IDC to the CRL Laboratories in Tokyo. The link was used for a videoconference between France and Japan which included several interactive presentations and interviews for French TV. The trial demonstrated clearly that a high quality intercontinental ATM could be established over heterogeneous networks including a satellite hop. A later trial linked the European and Japanese Satellite Agencies to demonstrate image and file retrieval from Japanese satellite catalogues using Internet browsers and file transfer

22

software. Part of this trial was an oil slick monitoring application, in which satellite pictures of the slick were beamed around the world for expert feature analysis. The rapid turn-round made possible by the broadband link could give the authorities vital information for controlling an incident within a couple of hours of it being detected. 2.2.3

Satellites, ATM and the Internet

ΔΕ ΙΓ Μ

Α

COIAS (see Chapter 3) showed how to design a global Internet infrastructure using IP over ATM and DVB satellite networks. Satellites are the only way of connecting to those parts of the world that fixed networks cannot reach. The trial used the new generation Internet Protocol (IPv6) and focussed mainly on performance, Quality of Service (QoS), mobility and security features. Several applications; such as Air Traffic Control and Air Navigation, were demonstrated. The COIAS platform is one of the first IPv6 based networks in Europe and its results will have significant impact within and outside Europe as one of the partners (Cisco) is a USA based company. The results show how to optimise the choice of the communications path by including alternate path routing mechanisms depending of the required quality of service. 2.2.4

Integrating Satellites into ATM Networks

The project VANTAGE has also demonstrated that ATM networks can include satellite hops and that ATM switching is a viable long term option. The project showed that SNMP network management protocols can be used across and within satellite networks. This means that the terrestrial infrastructure’s migration from SNMP to CMIP is possible even when satellites are embedded in the network, and it will be possible to set up Switched Virtual Circuits (SVC) over a satellite network. 2.2.5

WATT puts the ACTS Trials on-line

WATT provided an information service about the European ATM network testbeds. As well as details of the facilities and the trials being carried out, it offered users the opportunity to monitor the trials on-line as they were happening. WATT supported a number of field trials conducted by ACTS projects on the EXPERT testbed. During the trial, interested users could observe the experiments using the remote monitoring facility. The trial data was also recorded, processed and structured so that it could subsequently be used for off-line demonstrations and courses based on the trial results. The East European WATT partners have particularly benefited from the project as it has allowed them to find out about leading-edge telecommunications research and establish contacts with EU researchers. The EXPERT testbed has continued to use the WATT infrastructure after the end of WATT and there are plans to maintain it even after the end of EXPERT and ACTS.

23

2.2.6

Global 360

2.3 2.3.1

Access Networks

Α

One of the most visible demonstrations of global broadband communications was ‘Global 360’. In 1997 and 1998 the JAMES ATM network was used to link a number of major international conferences in Brussels, Madeira, Calgary and Moscow for several days. In addition, participants could join the event from other sites spread across Europe, European Russia, Siberia and Canada. Seventeen sites were involved and communications between 16 of them were fully symmetric. The events were scheduled like a TV channel and 11 of the 17 sites provided programmes. Most of these programmes were interactive, allowing full audio and video participation from receiving sites. The reaction of participants was that it had been an exciting, but—given the number of time zones covered—tiring three days.

ATM and Internet for the Home and Office

ΔΕ ΙΓ Μ

The introduction of broadband bi-directional communications and multimedia services on existing networks is a major challenge for both telecommunications and cable TV network operators. ATHOC has evaluated the options open to cable operators. The most significant results were the development and demonstration of: • Dynamic Media Access Control for shared media systems • Multiple channel techniques for efficient use of the limited upstream (user to network) bandwidth • Privacy and conditional access for ATM based user to user communication • IP/ATM integration The project has also carried out field trials with real users. The results have contributed significantly to the development of Internet access systems, and the evolution of standards for the twenty-first century. The ACTS project AROMA (see Chapter 3) was launched to build on the results of ATHOC and used its platform for testing and demonstrating the system functionalities. This will ensure that future networks really can handle all the different types of services and that services with demanding QoS (Quality of Service) can be integrated into multi-layered Hybrid Fibre Coax (HFC) systems to deliver broadband services to the home. The project has successfully demonstrated: • The addition of QoS guarantees to legacy TCP/IP networks and the use of QoS as a service differentiator • The upgrading of native ATM architectural solutions to ATM networks with QoS guarantees The Medium Access Control (MAC) layer used makes QoS and efficient dynamic bandwidth

24

sharing available to all applications. The multiple priority classes and permit allocation mechanisms allow the provision of services differentiated by their QoS. The MAC layer, in conjunction with the resource management controls, allocates and de-allocates resources on the HFC access network. 2.3.2

Broadband to the Home over Optical Fibre

ΔΕ ΙΓ Μ

Α

High quality multimedia services to the home and office require a high capacity network and optical fibre is the obvious solution. BONAPARTE developed and tested an ATM Passive Optical Network (PON) suitable for deployment in real communication environments and demonstrated its capabilities with telemedicine and teleteaching applications involving 125 real users. Public teleteaching courses were held in the autumn of 1996 and 1997 and telemedicine users have held routine clinical sessions since November 1997. The project has made significant contributions to ETSI on the standardisation of the VB5 interface. It also supported the world wide FSAN (Full Service Access Network) initiative, which resulted in the rapid approval of the ITU-T G.983 recommendation on ATM-PON systems. 2.3.3

25-50 Mbit/s over Twisted Pairs?

The major obstacle in the way of a nationwide Full Service Access Network is bandwidth. Optical cables have the bandwidth, but a Fibre-To-The-Home solution is frighteningly expensive. How much more bandwidth can be squeezed out of the existing copper pair? Not so long ago a 9.6kbit/s modem was the best you could buy. Now a 56kbit/s modem is a standard feature of any personal computer. Recent developments in Digital Subscriber Loop (DSL) technology suggest that reports of the copper pair’s death are, in the words of Mark Twain, greatly exaggerated. Commercially available products already offer megabits downstream and about a hundred kilobits upstream over existing telephone wires. However, real FSAN requires two way access at 2550 Mbit/s to each customer. ITUNET has explored how to combine DSL and fibre technologies so that fibre cables are used to feed small geographical cells and VDSL/ADSL is used on the last drop to the customer premises. The approach involves some civil works, but the really expensive last few hundred metres use the existing copper pair. This means that network investment can be tuned to demand for broadband services. A key element of the ITUNET strategy for upgrading the existing telephone access network is using inverse multiplexing to aggregate bandwidths of up to 1,000 Mbit/s between the main ATM switch and concentration points in the access network. This makes it possible to offer access at 25-50 Mbit/s, or maybe even more, to the majority of today’s telephone subscribers. This provides traditional network operators with a cost-effective way of providing high quality interactive multimedia services to every household that wants them.

25

2.4 2.4.1

Building Blocks for Future Networks ATLAS—a Single Chip ATM Switch

ΔΕ ΙΓ Μ

Α

The explosive growth in Internet traffic and the need to reduce latency call for highly integrated, high performance, ATM switching elements. ASICCOM has designed and built the ATLAS-I single chip 16x16 ATM switch, with point-topoint serial links running at 622Mbps It was fabricated by ST Microelectronics in 0.35 micro m CMOS technology. Its advanced architecture will facilitate the development of giga-switches for communications. Another important development is the 1.5 Gbit/s serial link transceiver, which will make it possible to develop even more highly integrated ATM switches and components. A 2 port macrocell with the same characteristics for embedding in ASICs was developed. This has already resulted in commercial products: a 1.065 Gbit/s Fibre Channel Transceiver, a 1.25 Gbit/s Fibre Channel Transceiver and a 2-2.5 Gbit/s Transceiver for both Ethernet and ATM. Results from evaluations of the devices have helped the partners develop specifications for the next generation single-chip ATM switch. This will address the market requirements that have emerged in the last two years and exploit the latest advances in semiconductor technology. 2.4.2

REFORMers promote Co-existence between Network Technologies

Network technologies are continually evolving to meet the needs of future services. They address different aspects of network operation and management; from physical layer operation to service and business management. The Holy Grail would be a unified technological framework for the analysis, specification, design, deployment, operation and management of telecommunications networks and services. Unfortunately it may prove hard to find. Telecommunications will continue to use many technologies and, in the real world, interoperability between them is more important than an abstract vision of an ‘ideal’ system. REFORM has specified, designed and realised a system for making ATM networks resilient to changing mixes of traffic, topologies and services with different QoS requirements. The system was based on ITU-T, ATM Forum, OMG, TINA and ISO standards. The REFORM system has shown that different technologies, even different cultures, can indeed coexist and interoperate, to the benefit of both network design and operation. A strong message from the project is that emerging technologies should treat existing ones as their heritage rather than a burden. 2.4.3

IN and B-ISDN Signalling Integration on ATM Platform

INSIGNIA developed a prototype Broadband Intelligent Network (IN) and successfully demonstrated it over a pan-European ATM network. The project carried out practical trials of

26

Broadband IN services involving Germany, Italy and Spain. The project successfully demonstrated: • Upgrade of four different types of ATM to Broadband Service Switching Points (SSPs) which offer a specific interface (Broadband INAP) to influence call control • Upgrade of an existing (narrowband) Service Control Point (SCP) to inter-operate with the Broadband SSPs • Intelligent Peripherals (IPs) suitable for Broadband Multimedia applications • Interworking at the network signalling level

Α

It also implemented a number of applications and services to test the network, e.g.: • a generic Broadband Virtual Private Network (B-VPN) service • Interactive Multimedia Retrieval (IMR) • Broadband Virtual Intranet (B-VI) for ATM end systems

ΔΕ ΙΓ Μ

As well as making contributions to standards bodies (e.g. ITU-T: IN CS3), INSIGNIA has produced a book “Intelligent Broadband Networks” which presents a definitive account of the state-of-the art for the benefit of technology managers, scientists and academics. 2.4.4

Protection across Network Layers

The traffic carried on a single link increases with every generation of network technology. Networks are also carrying increasing amounts of information that is critical to the routine operation of customers’ businesses. Network faults are no longer just a minor inconvenience to users, they can be a commercial disaster. The ACTS project PANEL set out to determine how complex multi-layer networks could survive faults and recover from them. It started by reviewing the reliability requirements from an operator’s viewpoint and comparing these with the protection strategies offered by today’s transport technologies. A new strategy (common pool) was developed for more efficient use of spare capacity in multi-layer networks. The impact of multi-layer recovery on TMN network management was studied in detail. The project evaluated a number of interworking strategies and drew conclusions from them about which layer should deal with a particular type of fault. Equally important is preventing management systems in different layers from initiating counterproductive actions in response to a fault. A software demonstration was developed to present these results. PANEL has made significant contributions to ETSI- TM-3 on survivability of SDH networks; to ITU-T SG-13 on survivability strategies and to Q.19 discussions on fault localisation problems between an Optical Network and a client SDH network. It has also organised the First International Workshop on the Design of Reliable Communication Networks, which attracted contributions from major equipment manufacturers and network operators. Networks will never repair themselves but PANEL has shown how planning and management tools can be used to ensure that they automatically restore service after likely

27

faults. Someone will still have to repair the broken cable or replace the faulty bit of circuitry, but the customers need never be affected. 2.4.5

Charging Mechanisms

ΔΕ ΙΓ Μ

Α

Charging has always been an important issue for both providers and users of telecommunications services. Existing telecommunications charges are based on distance, duration, and time of day. While there are many schemes for the charging of fixed and mobile telephony, the area of Internet charging and ATM charging is relatively uncharted to date. ATM can support voice, data, video etc, offering an appropriate Quality of Service for each. Traditionally, customers were charged for each of these services in a way that matched the network operators’ costs. Unfortunately, with ATM it costs little more to provide the ‘goldplated’ service than the ‘bargain-basement’ service. However, if everybody chooses the ‘goldplated’ service, the network will soon overload and extra capacity will have to be installed and paid for—even though it is not really needed. Therefore, ATM charging schemes ought to offer customers an incentive to choose the Quality of Service needed by their applications. CA$HMAN and CANCAN have developed and evaluated suitable charging and accounting schemes for ATM networks. These charging schemes and accounting management have been demonstrated by CA$HMAN in an operational environment where user-network interface issues and the use of intelligent agent software were investigated. This showed that the approach is based on sound economic principles and could be extended to Internet charging. CANCAN has focused on the application of accounting and customer care, and the development of a connection details record for this application. The project has also developed charging models which can be used in designing a billing system for ATM services and comparing the different charging schemes. The project developed and successfully tested prototypes for charging systems implementing the recommended charging schemes. A strong message is that they should not be cost based, and probably not distance based either. CANCAN proposes new charging parameters for an environment where quality is an important feature of the network service. Apart from challenging the principle of cost-based pricing, these schemes open up the possibility of on-line auctions of network resources. In addition, the balance of market power between actors is very sensitive to some of the parameters. Regulators may therefore find ATM interconnect even harder to define and police than PSTN interconnect. Network operators have used the results to make significant contributions to the ITU-T standard on charging for ATM and to the ATM Forum. Proposals supported by Telia, Telefónica, Telenor and Swiss PTT for standardising the network capabilities required to perform charging in an ATM network have been accepted by Study Group 13 of ITU-T (on broadband networks). KPN has also proposed a list of parameters for charging ATM that have been accepted by ITU Study Group 3 (on tariffing and accounting).

28

2.5 2.5.1

High-Speed Networks in Action Intercontinental Virtual Classrooms

ΔΕ ΙΓ Μ

Α

In October ‘95 students from the International School in Basel and the Glashan High School in Ottawa started to work together, thanks to broadband communications provided by ACTS. As part of their studies, Glashan High School students were designing a shopping mall that would meet the needs of today’s and tomorrow’s society. This appeared to be an ideal topic for collaborative work with the school in Basel, because it would allow the students to explore the many cultural and economic differences between Canada and Switzerland. The first “Virtual Classroom” event took place in May 1996. The students introduced themselves and then presented the general shopping facilities in their respective towns. They were surprised at the differences! Later discussions focussed on questions such as the types of shops needed to cater for different age groups, interests, etc. The Virtual Classroom event has now become a permanent fixture in the schools’ calendars and link ups take place, on average, every 8 weeks. Coverage of the events has been shown on the local Ottawa TV station. The event gained an even higher profile when it was presented at the “Second Conference on Global Lifelong Learning” organised by G7/GIBN projects in March ‘97 in Ottawa. The theme of the conference was “Investing in Human Potential—Making Strategic Choices”. The Glashan High School presented the work that they and the International School in Basel had produced so far, and the project manager of EXPERT described the ISABEL videoconferencing application (see also Section 5.5) supporting the link-up live from Basel. The ACTS project SUSIE (see Chapter 3) has extended the Virtual Classroom project with a video-on-demand server, a media-on-demand server and multimedia communication services. The SUSIE trial examines how multimedia services could be delivered on a IP/ATM network and also tests charging schemes for multimedia and premium IP services. The Managed Bandwidth Service, provided by project QUANTUM (see Chapter 4), is now being successfully used to provide the European section of the network. More schools are involved, including the Sir Wilfrid Laurier School in Ottawa, the Jules Verne School in Berlin, and the Lucan Community in Dublin. The Virtual Classroom not only provides an ideal opportunity for students from different cultures to collaborate and share ideas, but it also serves as a means of illustrating the capabilities of the new technologies and how they can directly affect our lives. 2.5.2

High Flying High-Speed Networks for the Automotive and Aerospace Industries

Advanced design and testing of cars and aeroplanes involve close collaboration between specialised designers and equipment in many different places. MULTICUBE showed how advanced high-speed networks can bring these teams together for seamless co-operative work.

29

Guidelines for Interoperability in Networks and ATM deployment

ΔΕ ΙΓ Μ

2.5.3

Α

The MULTICUBE consortium included partners from the telecoms, automotive and aerospace industries, so that developers of network services could work closely with users who are well placed to judge the usefulness of the services for collaborative engineering. MULTICUBE provided facilities for IP multicast over ATM multicast hardware. This infrastructure allowed the users’ high-speed LANs to be interconnected across the JAMES European ATM network. Over 200 hours of trials have been carried out, testing not only the performance of the infrastructure but also how well it supported collaborative working. Automotive users made extensive use of the ATM high-speed connections to run collaborative design sessions. By sharing CAD applications they were able to synchronously design a car part and to supervise its development. These applications were supported by high quality audio and video conference for face to face decision making. Aerospace users made extensive use of the ATM high-speed connections to run sessions of distributed interactive simulation. Experiments involving the remote manipulation of a robot arm in St. Petersburg were carried out for the first time during the 2nd MULTICUBE Workshop (Torino, 6-10 October 1997).

GINA has helped ACTS projects to establish consensus and develop guidelines about network evolution, network interoperability and ATM deployment. The guidelines not only reflect the latest findings and results of ACTS trials, but also take note of worldwide trends in Network Interoperability and ATM. (See Section 1.3.2.) The guidelines are aimed at telecommunications network operators, computer vendors, corporate users, services providers, regulators, and policymakers.

30

3 The IP-ATM Project Cluster 3.1

IP-ATM Trials and Results

Martin Potts Martel GmbH, Switzerland

(See list of contributors in Appendix 7.1)

ΔΕ ΙΓ Μ

Α

In March 1998, the following new projects were introduced into the ACTS Programme in the area of IP and ATM interoperability, with the focus on Quality of Service aspects: AROMA, BTI, COIAS, DIANA, ELISA, IthACI, PETERPAN, and 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. An outline of the activities in these projects was given in a previous publication: “Next Generation Internet in Europe” (issued in mid ’99). These projects are now reaching completion, and are performing trials and making measurements. It is therefore appropriate to report again from these projects and examine the implication of their findings for next generation networks, in general. The projects covered in this chapter focus heavily on solutions that include some degree of IP-ATM convergence. This is felt to be a realistic and important environment, given, on one hand, the increasing installed base of ATM technology in the backbone and its capability to support guaranteed QoS, and, on the other hand, the ubiquitous nature of IP applications, and their increasing requirement for QoS support. However, this is not the only scenario that has been implemented by the projects in this Cluster. Indeed, some of the projects recognised the drawbacks of some of the early IP-ATM “solutions” being proposed, and included the evaluation of new techniques for providing QoS. These protocols will therefore also be mentioned in this chapter. Within the converged IP-ATM solutions, certain projects are addressing specific topologies (e.g. Hybrid Fibre/Coaxial (HFC), ATM Passive Optical Networks (APON), and satellite). Next generation networks will offer a huge range of new value-added services to consumers. Service providers will generate revenue from these services with novel charging methods that will likely be a significant departure from the straightforward flat-rate approach used in current services like PSTN, mobile or Internet access. Indications are that some form of usage-based charging will be implemented. Additional charging complexities will be introduced when customers can opt for varying degrees of preferential treatment for their traffic – a radical change from the current best-effort Internet model, where all traffic has

31

equal priority, and therefore the same charge. Section 3.1.1 describes the general evolution of networks, emphasising the increasing demands for bandwidth, and QoS. Sections 3.1.2 and 3.1.3 describe the trials and provide some results. 3.1.1

Next Generation Network Trends

ΔΕ ΙΓ Μ

Α

As the acceptance and popularity of the diffusion of multimedia applications offered over the Internet grows, the traffic volume is increasing accordingly. This is leading to demands for faster and more effective backbones, and—more interestingly—modifies the requirements on the network by introducing the need for QoS. Thus, resource partitioning, e.g. through bandwidth reservation, assumes progressively more relevance. An ATM infrastructure accommodates the possibility to merge over the same physical transport backbone legacy services offering at the same time the capability to efficiently handle the long lived IP flows, originated by QoS-aware IP applications. It has, however, been observed that the trend in network evolution is not toward a global environment, such as the one developed in the past for the POTS. Rather, the network deployment looks more like a galaxy of ISPs, of alternate and historical operators, all moving to offer IP-services of some kind. Multiple network technologies and services with varying characteristics are the dominant principles of this evolution. Accordingly, the ‘network’ as foreseen by these projects is not intended to be one ‘global’ network, but rather one representative of the constellation of networks of coexisting ISP/network operators’ infrastructures (which might geographically overlap each-other). Any network of a significant size is reasonably organised in edge and core (backbone) devices. Within the DIANA, ELISA and PETERPAN projects, a network concept has been developed, based on IP-ATM Hybrid Devices both at the edge and in the core. Two special types of nodes have been identified, referred to as Hybrid Edge Devices (HED) and Hybrid

Figure 1: An Example (from ELISA) of Mapping IntServ and DiffServ Flows to ATM

32

ΔΕ ΙΓ Μ

Α

Core Devices (HCD). These network elements are able to operate as plain ATM switches for pure ATM traffic, but can even be used as pure IP routers in a full IP perspective. The edge devices communicate with end-users using a protocol (e.g. RSVP, xDSL, N-ISDN dial-up) whilst communicating across the core network using a different protocol (e.g. ATM, DiffServ), with all the associated signalling and resource allocation mapping. The DiffServ approach is currently popular within the IETF, as an alternative to using ATM in the backbone. The DiffServ solution is simpler as it removes the concept of associating resource reservation to singular flows (as it is in the Integrated Services (IntServ) model by means of the RSVP signalling protocol) and eliminates the need to maintain soft states within the nodes to record the resource assignation to flows. This is especially relevant in the core of the network, where the number of flows that each router has to handle might reach very large figures indeed. Nevertheless, the projects see the advantage, for the IntServ/RSVP approach, to guarantee precise resource reservation. Implementations and experimentation encompass both RSVP and DiffServ. In particular, DIANA ([email protected]) has achieved world renown expertise for the DiffServ implementation on LINUX. In DIANA, two novel techniques (Scalable Reservation Protocol – SRP, and Simple Integrated Media Access – SIMA) were developed, that provide similar levels of QoS assurance to DiffServ. The SRP implementation has the advantage that a minimum of explicit signalling by the source is required. IP switching is a further promising approach to integrate ATM and IP network technologies. Several flavours of IP Switching (Ipsilon, Tag Switching, ARIS, IPSOFACTO) have been proposed; all of them very different and not able to interoperate. IP Switching has recently been adopted by the IETF under the umbrella of Multi-Protocol Label Switching (MPLS). Although the specification of MPLS has made good progress, it still has functional deficiencies with regard to the support for IP Multicast, QoS, Resource Management and Mobility support. These issues have been investigated (and solutions proposed) by the IthACI project. Shared access networks such as HFC and APON have emerged as promising ways to reduce the cost of the transition to a broadband access infrastructure and also provide a graceful upgrade path towards fully optical local loops. However, these systems have to multiplex the upstream (from customer to network) traffic using a Medium Access Control (MAC) protocol. At the same time, the need to integrate various telecommunications services with differing quality requirements over the same infrastructure brings new issues to the design of such an access mechanism. The Differentiated Services (DiffServ) concept of bundling behaviour aggregates is particularly well suited to the hardware-dependent MAC mechanisms enabling the support of diverse service needs, while aligning the system to the emerging DiffServ Internet strategy. The combination of ATM and satellite technologies is a good example of new technologies that offer high bandwidth links together with some support for better QoS. These technologies appear to be also quite complementary, as the satellite can reach some parts of the world where the installation of an ATM infrastructure is not possible or would be too expensive.

33

3.1.2

Project Trials

ΔΕ ΙΓ Μ

Α

The trial phases not only validate the project developments, and allow performance characterisations, but they also prove the compatibility or interoperability of the projects’ solutions with products already available on the market. The purpose is to highlight limitations or benefits possible on a real networking environment expected to be the network of the future, and not only in a somewhat artificial project-specific situation. The focus is always on the offering and support of QoS, which is deemed to be the paramount characteristic of tomorrow’s Internet. Experiments and field trials with realistic, end-to-end resource-demanding applications are currently being performed in all projects. The experimental platforms in many of the projects consist of a number of sites, located in different countries. For example, the PETERPAN trial scenario includes project-specific network elements, HED and HCD, surrounded by commercial equipment (Routers, ATM nodes, Hubs, Workstations, PCs) and integrated with user side hosts running QoS sensitive RSVP-enabled applications. PETERPAN’s trial islands are in Italy (Milan and Pisa), in UK, in Portugal, and in USA, as shown in Figure 2 (see Section also 3.5): ELISA has also implemented HEDs that map incoming traffic to both ATM networks (dedicated SVCs, or aggregated into an existing PVC) and DiffServ systems, where resources are provided according to the marking of the packets. Four DiffServ classes are supported (as in AROMA – see later): Expedited Forwarding (EF), Assured Forwarding (AF), better than best effort, and best effort. The ELISA HED is able to perform DiffServ marking for end-systems that do not support DiffServ marking themselves. In this case, the traffic class is derived from the IP address or

Figure 2: PETERPAN Trial Sites

34

ΔΕ ΙΓ Μ

Α

other selectors (e.g. TCP port number) based on information, which is maintained on the HED in a configurable way. The HED performs policing based on volume limits for traffic in a specific DiffServ class, and therefore enables QoS guarantees for reservations following the DiffServ approach. As an additional function, the HED is able to collect information for usagebased charging, for explicit reservations as well as for DiffServ class usage. The ELISA trial architecture therefore combines the IntServ and DiffServ models by mapping reservation requests onto DiffServ classes where possible, thereby removing some of the scalability problems for explicit QoS reservations in Wide-Area Networks. In the ELISA architecture, the user interface is based on ATM under the hypothesis that a network operator provides ATM semi-permanent and switched connections. A common subset of ATM Forum UNI v3.1 and ITU-T Q.2931 is used. IP packets are encapsulated into ATM according to RFC1483, as used typically by xDSL systems. The control plane of the ELISA HED is based on two concepts. The first is that RSVP is used with “end-to-end” significance through the core network domain. This means that RSVP messages are interpreted only in the access network domain and in the HED, but not in the core network domain. The second concept is that the RSVP reservations can be mapped either onto DiffServ classes or dedicated ATM connection that will be set-up on demand. The trials in the DIANA project have also evaluated the options and combinations offered by both IP and ATM technologies, and QoS interworking between them, using an RSVP-overATM approach. This solution was then compared with two IP level approaches: DiffServ and the Scalable Resource Reservation Protocol (SRP). The DIANA RSVP-over-ATM approach creates RSVP flow aggregates with similar QoS requirements and sets up a SVC for each aggregate. The Flow-to-VC mapping control module is a key element. It provides signalling translation from RSVP to ATM, handles the admission of flows to ATM VCs and controls an IP over ATM queuing discipline. It is thus an example of a traffic descriptor and QoS parameter based resource reservation that strictly guarantees endto-end QoS. In order to address scalability issues, a concept of massive aggregation of flows to VCs and a dynamic bandwidth management is applied to reduce the control overhead introduced by signalling and the maintenance of per-flow state information. However, aggregation improves scalability at the expense of either the efficiency of the resource allocation or an increased effort for re-negotiation. Furthermore, aggregation may affect the service quality as observed by a single flow. In order to investigate whether these conflicting requirements can be balanced, a reference application is multiplexed with background traffic at an ingress Integration Unit. One of the applications is allocated a VC of its own, whereas the other application shares a VC with the flows generated by the background source. This scenario is illustrated in Figure 3: The DiffServ framework covers a set of Per Hop Behaviour (PHB) schemes where priority levels are set in the headers of each individual packet at domain boundaries. Packet discarding and scheduling is performed in the subsequent routers. DIANA has been working on a solution called Simple Integrated Media Access (SIMA). The mechanism is very scalable

35

Figure 3: DIANA’s RSVP over ATM Scenario

ΔΕ ΙΓ Μ

Α

and adaptive but offers only relative QoS for sender originated flows. Although SIMA is easy to manage with only two parameters, it is flexible enough to be used as an end-to-end solution in wide scale networks. As opposed to RSVP-over-ATM, the Scalable Reservation protocol (SRP) establishes a QoS path without per-flow state in routers. Senders set a request bit in data packets until the desired reservation level is signalled back from the receivers. Similar to RSVP over ATM, and contrary to DiffServ, the reservation is absolute and reliable. Senders, routers and receivers obtain the current reservation level by counting packets that have the request or reserved bit set. However, 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, DIANA is investigating if SRP provides stable reservations and whether applications can cope with the transient phases at the beginning. All of the DIANA developments are implemented on the same (LINUX-based) Integration Unit (see Figure 3). This offers an interoperable control framework towards the integration of IP and ATM. The trials in the COIAS project demonstrate how a network infrastructure can be engineered to obtain the full benefit from interoperable 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. COIAS uses existing ATM and DVB satellite technologies. The selected applications for this project relate to air traffic control and passenger services: • aeronautical applications: this category includes flight management system, radio/telephone systems, flight simulations, • media server, • multimedia applications for the passengers applications (e.g. audio-conferences).

36

Α ΔΕ ΙΓ Μ Figure 4: COIAS Trial, with Alternate Path Capabilities

The infrastructure required by these applications is shown in Figure 4. The key features of the COIAS trial are: • wide geographical coverage: the network infrastructure is spread over several countries in Europe. • global services: The applications supply services to users that are located at different sites. The implementation of these distributed services demands system resources and communication infrastructure. • system resources: the chosen applications require the use of resources, such as satellite links, ATM links, computers, etc. • communication infrastructure: the communication infrastructure includes a LAN network for the local platform in each location and a WAN network for interconnecting LANs. This infrastructure has particular requirements in terms of data rate, QoS and availability. An overview of the communications links is shown in Figure 5. The AROMA (HFC) and BTI (APON) projects have made trials on shared access network topologies. These present attractive cost advantages for broadband access networks by

37

Α ΔΕ ΙΓ Μ Figure 5: COIAS Communications Links

allowing many customers to share the expensive head-end equipment and the feeder section. In addition they offer re-use of the existing copper feeds to customers, at least during the crucial introductory phase (e.g. for HFC, by using legacy CATV systems and their coaxial medium beyond the fibre node, and for APONs, by using twisted pairs of the telephone network enhanced with xDSL beyond the Optical Network Unit). In both systems, sharing of the upstream channel is usually effected through TDMA multiplexing. A MAC protocol is employed to arbitrate the access to the slotted common medium by allocating slots to customer terminations according to demand. This results in a distributed queuing system characterised by the long time required to pass control information from the queuing points to the service controller residing at the head-end. Typically, the allocation of upstream slots in a tree-topology access system is based on a reservation method which allows to dynamically adapt the bandwidth distribution to traffic fluctuations. The MAC controller collects access requests and then allocates the upstream slots by sending access permits. It is important to note that the service policy of the MAC governs the distributed multiplexing from a central point situated miles away at the head-end. This has the important implication that the acquisition of arrival information and buffer-fill levels includes a considerable delay element not found in the centralised multiplexing typically operating in a switch queuing point. Because of the much larger reservation delay and statistical behaviour of the aggregations from many customers, special care must be

38

ΔΕ ΙΓ Μ

Α

taken to safeguard QoS to sensitive traffic. This requires a prioritisation scheme and the DiffServ strategy of IETF has been found to be a very suitable approach to handle this issue. In the downstream direction, the broadcast nature of the medium creates replicas of the signal (in the taps of HFC systems, or the passive splitters of PONs) giving rise to privacy and security issues. These are typically dealt with by means of encryption. The SUSIE project (see Section 3.6) developed a charging approach for Premium IP Services (i.e. those that have been enhanced with QoS). The SUSIE charging approach includes the development of a charging reference model, the design of usage-based charging algorithms for various Premium IP services, and the design, implementation and testing of systems for metering, accounting and charging. The project addressed one very general type of business model, where retail IP services with QoS are provided directly to the customer, with the retailer purchasing wholesale services from another provider. In the SUSIE project, the wholesaler is assumed to sell ATM services, though the SUSIE charging approach is also applicable to wholesale services implemented using DiffServ or MPLS. This business model mandated the development of metering, accounting and charging systems for both ATM and IP, as well as a technique for combining both charges into a consolidated bill for the customer.

Figure 6: The Virtual Classroom Connectivity Network

39

ΔΕ ΙΓ Μ

Α

The principal field trial goal of the project was to provide a premium service to a community of real users, and then to validate the various metering, accounting and charging prototypes developed by the consortium, using this example service. A schools user group was identified for this purpose. Participant schools from Ireland, Germany, Switzerland and Canada were equipped with video-conferencing hardware and software to use in a Virtual Classroom environment. The year-long experiment included ongoing contact between teachers and students at the different schools, interspersed with a series of video-conference sessions. A virtual learning environment of this kind is typical of the services that next generation networks will offer. QoS was provided by organising dedicated connections between the schools. ATM backbone traffic (“wholesale traffic”) and IP traffic at one school (“Retail Traffic”) were metered and charged. Consolidate charging was performed at the IP layer in a TINA-based accounting system. The SUSIE project experimented with different ways of providing the network infrastructure required to support multi-point video-conferencing and collaborative learning activities. The project provided a backbone network, to which the schools gained access through various mechanisms including ADSL, ISDN and direct ATM connection (see Figure 6). 3.1.3

Results from the Trials

The IP-ATM projects have developed a number of edge and core devices, handling RSVP, DiffServ, MPLS, and the novel techniques SRP and SIMA, embedded in various IP-ATM platforms including commercial and project developed elements and applications, with specific attention to: • the functional verification of interworking functions between IntServ, DiffServ and ATM, signalling, admission control, traffic parameter mapping, policing and shaping as well as charging • the aggregation of IP traffic onto shared ATM VCs • the efficient dynamic (ATM) bandwidth management • the efficient IP forwarding in the IP-ATM node • the use of IP trunking and short-cut functionality • LINUX implementation of DiffServ • LINUX-based queuing mechanisms • performance measures related to the traffic, affecting QoS, for example: – QoS mapping between IP and ATM, for sensitive applications (e.g. Telemedicine) – alternate edge device queuing discipline characterisation and evaluation – IPv6 vs IPv4 over ATM – IPv6 and RSVP over ATM • experiments assessing end-service aspects and taking into account both the user perception and the service provider perception.

40

ΔΕ ΙΓ Μ

Α

In general, the trials demonstrated the correct interworking of the project components that have been implemented and deployed. The traffic and QoS testing resulted in performance parameters (throughput, packet delay, packet loss, QoS session setup-time, etc…) for different flows. Comparisons of the performance of “IntServ” flows and “best-effort” flows under different network load have already been made. For a future QoS-aware Internet approach, it can be expected that more sophisticated mechanisms are used for QoS control. The concept of “bandwidth brokers” forms the starting point for a QoS architecture that is based on DiffServ principles in the core network but adapts its resource allocations automatically to user demand. This leads to an overlay network of QoS administration agents that interact autonomously and intelligently, in order to optimise the network configuration under all possible conditions. The scalability of RSVP has been a particular focus of the trials activity. With the term “scalability” is meant the implications of large networks on the network elements; in particular, the system requirements of a single node should not grow linear with the number of network elements. Several issues have been addressed; the main one being the management of single flows: Once a reservation has been established, all the routers in the path have to recognise the packets belonging to a reserved flow and provide a convenient handling. These actions can easily become an unacceptable processing burden when hundreds of thousands of different flows must be handled (e.g. in a gigabit core router). Similarly, the need to exchange and store “per flow” information is another heavy burden for core routers. These scalability concerns led the Internet community to investigate simpler solutions for the support of QoS. In the DiffServ model, the basic idea is to support a set of traffic classes providing a different service to each one. User flows are only controlled at the edge of the network and then aggregated into a small set of traffic classes: this approach relieves the scalability impairments on the core router in the classical RSVP approach and overcomes the scalability issue. Since IntServ and DiffServ focus on reservations and scalable service differentiation, respectively, it is advantageous to combine both for an overall solution: IntServ can be used in the access network and DiffServ in the core network, as it is supported in the DIANA, ELISA and PETERPAN architectures. The admission control procedure for a DiffServ domain is performed with the help of an Admission Control Server (ACS), which can keep information at an aggregate level (per link, per HED), while per flow information is only stored in the HED. The HEDs maintain the per-flow “soft” state, which is created with the first RSVP RESV message and is constantly refreshed by RESV messages. The ACS can alternatively (as tested in ELISA) work with “hard” states, i.e. a resource is allocated once until explicitly deallocated. This approach has a positive impact on the scalability, as it reduces the interactions of HEDs with the ACS. Restricting RSVP to the access also makes the architecture relatively future-proof, since it can be easily adapted for different mechanisms to signal QoS requests (as they may for

41

ΔΕ ΙΓ Μ

Α

instance appear in future object communication middleware). Such an upgrade would involve parts of the HED, but would not affect the core network. In the core network, IP routers are generally interconnected by an underlying ATM layer. In a small-scale network, direct ATM connections between all the HEDs can be assumed, but in a large-scale network a fully meshed topology with direct links between all HEDs is not feasible. In such a scenario, DiffServ-enabled routers in the core network can be installed to achieve good scalability, since every “per flow” operation is confined to the HEDs and does not impact the core of the network, where only highly aggregated traffic flows are dealt with. In such a mixed RSVP/DiffServ environment, the simplest approach is to keep local reservation/admission control in the HEDs and to follow a static approach. In this case a preallocation of bandwidth is needed, which typically results in a loss of efficiency. More efficient solutions imply a dynamic exchange of information, which can involve the HEDs and the intermediate routers. This has been trialled in DIANA, both with RSVP implementations, and the new technique SRP. When using an ATM-based core network, scalable mechanisms for translating IP addresses into ATM addresses are needed. These mechanisms (e.g. NHRP) are under study within IETF, but their interaction with RSVP is still unclear. A suitable straightforward extension to RSVP to support IP/ATM address resolution has been proposed by ELISA. If there is an ATM path between two HEDs, this mechanism allows the establishment of direct QoS ATM shortcuts. The interoperability of project solutions with commercial equipment (e.g. Cisco routers, ATM switches, Sun implementations of RSVP) is always possible, but effective only on the ATM link and in the presence of enhanced ATM interfaces, capable to exploit RSVP-ATM, QoS interworking and to correctly shape traffic, e.g. as available on Cisco routers with the latest generation of ATM interfaces. (The earlier releases, with low shaping and control capability, are not able to create dedicated connections and to enforce traffic profiles). In COIAS and BTI, tests on packet classification latency for IPv4 and IPv6 RSVP flows showed negligible difference. However IPv6 flows using a flow label classification technique produced noticeably lower classification latency times. End to end packet latency was found to be slightly higher for IPv6 RSVP flows than for IPv4—regardless of the packet size. IPv6 flows using flow label classification exhibit the lowest end to end packet latency. The efficient support of multicast services is an essential requirement for the future Internet. Standardisation efforts have produced a second generation of multicast routing protocols, improving the scalability of multicast groups. Within the IthACI project, several solutions to support IP multicast in an MPLS environment have been developed, focusing on the PIM Sparse Mode multicast routing protocol. These MPLS multicast solutions have been put forward in several Internet draft documents, proposed by IthACI partners NEC, Alcatel and Cisco to the MPLS working group. At this time a common working group document on MPLS multicast has been achieved.

42

Two different approaches have been explored for QoS support in MPLS: • a framework denominated “explicit network Class of Service”, and • service differentiation and QoS support without the need for additional (explicit) signalling protocols.

ΔΕ ΙΓ Μ

Α

QoS support in the IthACI prototype concentrates on RTP (real-time) flow detection as well as on the provisioning of special QoS treatment for multicast RTP flows, based on the detected class of the real-time flow under observation. The detection of RTP flows is independent of the QoS provisioning itself, but rather a prerequisite. Because RTP is not a protocol by itself which can be recognised by a protocol number (as defined e.g. for UDP), the detection of RTP flows is done with a “weak test” based on the RTP header validity check which may be misleading in some cases. The impact of errors in the detection of RTP flows is being studied in order to assess the implications of faulty flow RTP recognition. In the IETF, it has been discussed whether to elevate RTP to ‘protocol status’, thereby eliminating the necessity of the above mentioned “weak test” and making RTP flow detection much easier. Special treatment for RTP flows based on their detected QoS requirements is achieved by assigning different ATM priority classes for RTP flows. This does not provide true “Per-Flow QoS”, but rather “Per-Class Quality of Service” or “Class of Service”. The goal of resource management in MPLS is to use network capacities efficiently, from both the network’s and the user’s perspective. Flow information is collected and presented in a Flow MIB. The Flow MIB is an extension of the SNMP Meter MIB proposed by the real time flow monitoring Working Group of the IETF (RFCs 2063 and 2064). A different, more network management oriented approach to class of service based QoS handling scheme is based on the notion of “explicit network Class of Service” (enCoS). In this scheme, traffic is categorised into different enCoSs. An enCoS is characterised by a set of performance parameters (or attributes) and associated targets, which are explicit values for the performance parameters. Mobility support for multicast applications in MPLS networks is another enhancement within the IthACI project. More specifically, roaming support for multicast clients has been developed. This was achieved by setting up special tunnels between the mobile clients and their home and foreign agents. These tunnels are then switched within the MPLS-based network. The protection of MPEG flows with respect to competing flows and network load has been trialled in several projects. QoS degradation of the MPEG streams is proportional to the amount of competing traffic. PETERPAN noticed a small degradation only once the network load reaches 90%. This was due to collisions on the Ethernet segments. ATM links showed perfect protection of flows with stringent QoS requirements. Hardware MPEG decoders were found to be much more sensitive to frame loss and jitter than software ones (less flexible in reconfiguring/adapting frame rate to the reduced one received in case of noisy/lossy channel). Aspects of QoS routing have been considered by the COIAS project, especially for satellite

43

Α

systems, and ground-airplane communications. The use of the air traffic simulation highlighted several issues that appear when integrating IP, ATM and satellite technologies: • IP (in its current form) is not able to deal efficiently with the unidirectional nature of satellite links. Therefore, a new Uni-Directional Link Routing mechanism (UDLR) has been implemented, • security (IPsec, IKE (key exchange), authentication, encryption) is very important in the context of such an application because the pilot and the traffic controller must be able to authenticate themselves. Security may also be required by passengers for their own traffic (electronic commerce for instance), • navigation data must be multicasted to each aircraft in a reliable manner. Therefore, a reliable multicast mechanism adapted to satellite networks is needed, • route selection should be made according to QoS and security.

ΔΕ ΙΓ Μ

The results from the shared access network topology trials (projects AROMA and BTI) showed that it was not possible to simply transmit delay-sensitive and non-delay-sensitive traffic classes together, without unacceptable loss of grade of service for the former class. Additionally, TCP/IP also employs flow control on the transport layer based on the detection of losses. Thus a TCP flow gradually increases the rate submitted to the network up to the point that buffer overflow occurs and re-transmission is triggered. Then the rate is reduced and a new balance point is sought. This action will disturb the other traffic classes, which cannot benefit from re-transmission. Given the fluidity of the standardisation for high QoS traffic and the several options open for PHB variants and the fact that the MAC protocol requires a significant hardware part, a flexible strategy is required. The AROMA project (see Section 3.2) developed a strategy, based on the use of access priorities in the reservation system which can be programmed to fit with required PHBs by means of software programming of the mapping of flows to priorities. To reduce complexity in this cost-sensitive residential access system, services were grouped into behaviour aggregates (classes) with a similar set of requirements. This is in line with the DiffServ philosophy of flow aggregation for better scalability and flexibility. Four priority classes have been implemented in the MAC, leaving finer aggregations and more elaborate forwarding policies, to be implemented in the router at the egress of the HFC system. The characteristics of the four aggregation levels/priorities are the following: • The high priority is devoted to delay-sensitive periodic CBR traffic, which is supported by pre-allocated, unsolicited permits issued at fixed intervals by the MAC controller. This class is suitable for services with very strict delay requirements, which undergo strict traffic profile control (traffic conditioning) such as the Expedited Forwarding (EF) service. • The second priority level is devoted to real-time variable bitrate flows, such as video services or VoIP and it is provided with peak rate policing for guaranteed QoS. The MAC exercises a policing function by rate checking before issuing the permits. This is based on

44

credit allocation at the time of subscription or connection set-up. In the DiffServ context it could be used for the top Assured Forwarding (AF) class. • The third priority is devoted to data services with higher requirements than best-effort. The traffic profile control assumed for this class aims at minimising the loss of packets and the disturbance to other traffic. The credit scheme is used to guarantee a minimum rate (while credits last) while traffic exceeding this limit is relegated to the 4th priority permit generation. The 3rd priority mechanism is suited to the support of the lower three AF classes. (Drop policies can be applied independently at the modem queuing points). • The fourth priority is reserved for best-effort services which employ loss-based flow control at the TCP level and can be very disruptive to the other classes when sharing the same queue.

ΔΕ ΙΓ Μ

Α

The last three priorities employ reservation while the first uses unsolicited permits. For the operation of the MAC all that is important is that a number of permits provided on a periodic basis correspond to the number of upstream slots over the same period. The achievable speed in the upstream direction is 3Mbit/s. The frame structure in the downstream direction is dictated by several mandates of the physical layer (synchronisation, flexibility over many modulation constellations and rate-adapting to plant conditions, interleaving, Reed-Solomon FEC etc). The behaviour of the above MAC mechanisms was studied with the help of a scenario using 10 cable modems loaded with uniform traffic for each priority. The slot (170.6 µs) was used as a time unit. The traffic sources used the common ON-OFF model, generating traffic at the slot/cell level with exponentially distributed on and off periods. The peak rate was the system rate simulating the arrival of IP packets with geometrically distributed lengths, which were instantaneously segmented into slots. Figure 7 depicts the probability distribution function (pdf ) of the access delay for the 3 lower priorities under a total load of 85%. (The 1st priority is not presented since it exhibits deterministic behaviour with the delay never exceeding the fixed permit distance as preprogrammed). Only the variable part of the delay is shown i.e. the fixed round trip time of about 4 slots for the travel of the request upstream and the permit downstream is not included. The 1st priority traffic was using 10% of the load for CBR traffic (or virtual leased lines by EF in the DiffServ model of usage) with the other 75% equally distributed among the other 3 priorities. The delay advantage provided by the prioritisation leads to almost all the slots of the 2nd priority accessing in less than 250 slots (43 ms) while those of the 3rd in less than 350 slots (60 ms). Of course there is no bound for the 4th priority which can exceed any limit depending on the total loading. This is better illustrated in Figure 8, which shows the mean delay as a function of the total load for each priority. The delay for the first priorities increases very smoothly with the load, leaving the 4th priority to suffer the congestion with the delay increasing asymptotically to the 100% line as is typical of any queuing system. The buffer size increases without limit.

45

Figure 8: Mean Delay vs Total Load

Α

Figure 7: pdf of the Access Delay

ΔΕ ΙΓ Μ

Note, however, that the sources used do not model higher layers where the typical congestion avoidance of TCP exercises flow control in response to losses and would reduce the rate, while re-transmitting lost packets. The SUSIE project developed the charging reference model for usage-based Premium IP services shown in Figure 9 (see Section 3.6). The metering layer performs the function of measuring the amount of resources used. This measurement is forwarded via a reader layer to the accounting layer, where usage information is consolidated into accounting data records. (The project has proposed standardised records for IntServ, DiffServ and MPLS). In a multi-provider environment, this layer is responsible for distributing collected usage data to other domains. Once the charging layer receives the accounting records, the appropriate tariffs can be applied, and a price assigned for the service. The billing layer collates all charges in a bill to be sent to the customer. Note that all layers can be configured from a set of policies. A TINA system was built using C++, Java and CORBA to perform charging and accounting for Premium IP services. The Premium IP Metering System listens to the IP flow in the network. Using special rule-files, it filters packets of interest to the accounting system. This information is then sent to the IP Accounting System using the “TINA Gateway”. The TINA Gateway receives the data measured by the Premium IP Metering System and transports it to the Accounting System. It does so by converting the incoming accounting records into TINA Accounting data packets. The TINA accounting System is designed to account for a number of different services. Its major functions are the storage of accounting data, the management of user sessions and the calculation of charges. Multicast, cost-sharing and hot-billing capabilities have been demonstrated. TINA management functions of subscription and session management have been integrated, and the robustness and reliability have been proved in a 7-day stress test.

46

Figure 9: SUSIE

Α

Charging Reference Model

ΔΕ ΙΓ Μ

The prototype is limited to approximately 400 sessions, but the CORBA technology used by the system permits scaling. The project also tested converged charging, where retail and wholesale charges were consolidated into a single charge. This function was performed on the TINA system, which receives accounting records from the ATM system and combines them with IP charges. ATM metering functionality was included, and the ATM usage information was encapsulated in an accounting record that is an extension of the Connection Detail Record (CDR) proposed by the ACTS project CANCAN. The trials validated the metering component of the switch as well as the mediation object that passes the accounting records to the outside world. A system was also designed and implemented to perform charging and accounting for ATM As there will be a range of services, the charging and accounting system needs the ability to identify what type of service has been used, in order to apply the correct tariff structure. The SUSIE project has proposed a method for querying the accounting record, and identifying the correct service based on a set of logical rules applied to the contents of the record. This capability was built into an ATM charging and accounting system. This system contains three processes for calculating charges for ATM services. The first process is service customisation that allows the parameters that define a service to be established. The second process is tariff management that defines the tariff parameters for each service. External to the rating engine, a mediation system produces results from metering within the ATM switch. The third process is a service identification process that identifies the correct service type from the raw accounting record data. Finally there is the core rating process which uses the service type results and applies a charging algorithm to the raw data and so produces a charge. The SUSIE trial demonstrated service discrimination between ten different services, and could record and process the data with appropriate speed. The trial stages of the project also included an opportunity for European operators to

47

ΔΕ ΙΓ Μ

Α

comment on various aspects of the charging approach including the charging reference model, the charging algorithms and usage metering. Operators reached nearly full consensus that it is appropriate, and the experts are unanimous that the definition of reference points is the most critical issue here. Regarding charging schemes, there is less consensus. However, experts agree that QoS charging should be based on both reserved and used resources. Finally, regarding usage metering, there is the least consensus, however it is evident that metering simplicity and flexibility are the biggest challenges.

48

3.2

AROMA: The Role of the MAC Protocol in Offering QoS to IP Services Over Shared Access Systems

J. D. Angelopoulos, N. Leligou, Th. Orphanoudakis, G. Pikrammenos National Technical University of Athens. Telecom Lab, Polytechniopolis Zographou, Athens, Greece.

ΔΕ ΙΓ Μ

Α

Shared access networks such as hybrid fiber/coaxial and passive optical networks have emerged as promising ways to reduce the cost of the transition to a broadband access infrastructure and provide a graceful upgrade path towards the photonization of the local loop. The TDMA multiplexing of traffic entering such a system is governed by the MAC protocol, which arbitrates the allocation of bandwidth to the shared feeder. At the same time the need to integrate telecom services presenting demanding quality requirements with plain best-effort services over the same infrastructure, brings new issues to the design of such an access mechanism. The Differentiated Services architecture with its bundling of behaviour aggregates is particularly suited to the hardware based MAC mechanisms enabling the support of diverse service needs, while aligning the system to the emerging Differentiated Services Internet strategy. The implementation of this mechanism in the AROMA research system and its evaluation using computer simulation are presented in this paper. 3.2.1

Introduction

Tree-shaped topologies present attractive cost advantages for broadband access networks by allowing many customers to share the expensive head-end equipment and the feeder section. In addition they offer re-use of the copper last drops to the customer, at least during the crucial introductory phase and probably for many years to come. Re-use of the existing infrastructure greatly reduces the initial investment outlay and provides a graceful upgrade path in step with service demand. Typical examples of tree topology systems are Hybrid Fiber Coaxial (HFC) and Passive Optical Networks (PON). The first use legacy CATV systems and their coaxial medium beyond the fiber node, while the latter re-use the twisted pairs of the telephone network enhanced with xDSL beyond the Optical Network Unit (ONU). In both systems, sharing of the upstream channel (from customer to network) is usually effected through TDMA multiplexing. A Medium Access Control (MAC) protocol is employed to arbitrate the access to the slotted common medium by allocating slots to customer terminations according to demand [5], [6]. This results in a distributed queuing system characterised by the long time required to pass control information from the queuing points to the service controller residing at the head-end. The allocation of upstream slots in a tree-topology access system is based on a reservation method which allows to dynamically adapt the bandwidth distribution to traffic

49

fluctuations. The MAC controller collects access requests and then allocates the upstream slots by sending access permits. It is important to note that the service policy of the MAC governs the distributed multiplexing from a central point situated miles away at the headend. This has the important implication that, as regards delay control, the acquisition of arrival information and buffer fill levels includes a considerable delay element not found in the centralized multiplexing typically operating in a switch queuing point. In contrast, drop policies must be distributed over all network terminations (cable modems) where the flow identity and fill levels are known. Because of the much larger reservation delay and statistical behaviour of the aggregations from many customers, special care must be taken to safeguard QoS to sensitive traffic. This requires a prioritization scheme and the Differentiated Services strategy of IETF [1] is a very suitable approach to handle the problem.

Α

3.2.2 Service Differentiation in an Access Multiplexer

ΔΕ ΙΓ Μ

From a traffic engineering point of view, the tree-shaped access system exhibits a very different behaviour between the upstream (from customers to core) and the downstream (from core to the customers) direction. In the downstream, the broadcast nature of the medium creates replicas of the signal (in the passive splitters of PONs or the taps of HFC systems) giving rise to privacy and security issues. These are typically dealt with by means of encryption, which is out of the scope of this work. In the upstream on the other hand, the MAC control function effects multiplexing / concentration of the traffic from all active modems as typically occurs in the output ports of any switching node. However in this case it is characterized by the distributed nature of the queuing points and the additional difficulties in the exchange of control information. Failure to recognize the packet precedence and behave accordingly would result in loss of QoS for any sensitive flow under high load. To apply any scheduling or priority discipline requires the correlation of the traffic from all multiplexed sources going to the one common egress point of the system. The Differentiated Services (DS) strategy recently adopted by IETF as a scalable and relatively simple methodology towards enriching with QoS the IP services, is applicable and quite appropriate in the case of such tree-shaped access systems where IP services are dominant. To align such an access system to the DS concept requires the incorporation of provisions in the MAC function for the appropriate handling of each flow aggregation respecting its requirements. Each QoS class must encounter the specified Per-Hop-Behaviour (PHB) and this can only be embedded into the MAC control function. The experiencehat led to the DS architecture was the emergence of requirements for ISPs to offer QoS to certain flows in the presence of disturbing plain best-effort traffic without complex maintenance of state information in core routers. Eventually quality can not be guaranteed without some maintenance of state variables relating to reservations and flow intensities, but the strength of DS lies in the slow and graceful introduction of such complexities in line with revenues from a previous stage of introduction of such mechanisms. Dealing with behaviour aggregates and starting with static management based Service Level

50

Α

ΔΕ ΙΓ Μ

Figure 1. Typical HFC system

Agreements (SLAs) executed at slow timescales while keeping traffic conditioning at the edges of the network, enables a low cost starting phase while smaller granularity levels can be sought out at later stages of deployment. Non-compliant intermediate nodes can be transparent but at risk of reduced overall performance should they become the bottleneck in the route of the flow. A slow distributed access multiplexer such as an HFC system residing at the network edge can not be relied upon to operate in a transparent fashion as regards the DS strategy since the MAC directly affects the temporal properties of the egress stream. Even before the emergence of the DS architecture, it had become apparent that differentiation in the handling of traffic classes was required in the MAC function of PONs and HFC systems [5]. This was reflected in the adopted MAC solutions in the EU research projects PLANET and AROMA. These demonstrator systems supported both delay-sensitive and besteffort services. It was obvious that it was not acceptable to mix these two classes without unacceptable loss of grade of service for the former class, which employed preventive flow control. In contrast TCP/IP traffic uses flow control on the transport layer based on the detection of losses. Thus a TCP flow increases gradually the rate submitted to the network up to the point that buffer overflow occurs and re-transmission is triggered. Then the rate is reduced and a new balance point is sought. This action will disturb the other traffic classes, which can not benefit from re-transmission. Given the fluidity of the standardisation for high QoS traffic and the several options open for PHB variants and the fact that the MAC protocol requires a significant hardware part, a flexible strategy is needed that can accommodate the changing environment. In the sections

51

ΔΕ ΙΓ Μ

Α

below, a MAC design approach is presented which can execute the currently available PHBs and adapt to a broader framework of service differentiation in the MAC protocol. The basis of the approach is the use of access priorities in the reservation system which can be programmed to fit with required PHBs by means of software programming of the mapping of flows to priorities. The system implemented in the framework of the AROMA project employs a TDMA slotting designed for ATM cells since native ATM services in addition to IP best-effort and QoS enhanced services are also supported. This required many more functions to map the IP flows to ATM VC/VPs using the Classical IP (CLIP) framework. However we do not deal with these other system implications of the ATM based solution which may have a narrower scope and we will simply consider the ATM size slots as a quantum of the MAC assigned bandwidth allocation. To accommodate IP frames, several slots are successively assigned by the MAC. However, even if IP is not offered over ATM, the legacy of short slots can be used to advantage in the context of the DS architecture over a slow shared link such as HFC. Namely, it allows to suspend the transmission of a lower priority packet, on the boundary of a slot (cell), and transmit delay-sensitive packets before resuming the transmission of the low priority one. In addition, fixed slots are easier to handle in a hardware based MAC. Such an ATM slotting is anyway the approach followed by the main standards bodies, like DAVIC 1.3 and 1.4, DVB/ETSI ETS 300 800, (now incorporated in DAVIC), and IEEE 802.14 [4]. 3.2.3

The MAC as an Executor of Per Hop Behaviours

As in the centralized multiplexer case, flows with demanding QoS (e.g. Expedited Forwarding or Assured Forwarding) must be identified and receive properly differentiated treatment from the plain best effort traffic. This is accomplished in the termination (ONU or cable modem) during packet classification by placing the corresponding cells in the high priority queue which will subsequently place higher priority requests and activate the higher priority permit allocation MAC algorithms. To reduce complexity in this cost-sensitive residential access system, services are grouped into behaviour aggregates (classes) with a similar set of requirements. This is in line with the DS philosophy of flow aggregation for better scalability and flexibility. Given the fluidity of service class definition and the fact that the MAC is implemented mainly in hardware, it was deemed adequate to implement just 4 priority classes in the MAC, leaving finer aggregations and more elaborate forwarding policies to be implemented in the router at the egress of the HFC system. All that is required from the MAC is not to deny quality to any groups of flows. The characteristics of the four aggregation levels/priorities are the following: • The high priority is devoted to delay-sensitive periodic CBR traffic which is supported by pre-allocated, unsolicited permits issued at fixed intervals by the MAC controller. This class is suitable for services with very strict delay requirements, which undergo strict traffic profile control (traffic conditioning) such as the EF (Expedited Forwarding) service [2].

52

Α

• The second priority level is devoted to real-time variable rate flows, such as video services or VoIP and it is provided with peak rate policing for guaranteed QoS. MAC exercises a policing function by rate checking before issuing the permits. This is based on credit allocation at the time of subscription or connection set-up. In the DS context it could be used for the top AF (Assured Forwarding) class. • The third priority is devoted to data services with higher requirements than best-effort. The traffic profile control assumed for this class aims at minimizing the loss of packets and the disturbance to other traffic. The credit scheme is used to guarantee a minimum rate (while credits last) while traffic exceeding this limit is relegated to the 4th priority permit generation. The 3rd priority mechanism is suited to the support of all four or the lower three AF classes [3]. (Drop policies can be independently applied at the modem queuing points). • The fourth priority is reserved for plain best-effort services which employ loss based flow control at the TCP level and can be very disruptive to the other classes when sharing the same queue.

ΔΕ ΙΓ Μ

The last three priorities employ reservation while the first uses unsolicited permits. The reservations operate by means of three request fields totaling 8 bits. Two bits are used for the 2nd class and three bits for the other two creating a byte which is piggy-backed in every upstream slot. In the AROMA system this byte uses the place of the HEC field of the ATM cell which is not needed for cell delineation since an additional synchronization preamble is employed because of the burst mode operation. The total length of the upstream slot has in the AROMA system a size of 64 bytes accommodating except of the cell payload a synchronization preamble. The speed of the upstream is 3Mbps and each modem has a slot-by-slot agility over a triplet of FDM channels which allows further dynamic statistical load balancing over all the customers of three channels, i.e. the MAC controller assigns not just a slot but also one of three channels. The frame structure in the downstream direction is dictated by several mandates of the physical layer (synchronization, flexibility over many modulation constellations and rates adapting to plant conditions, interleaving, Reed-Solomon FEC etc). These issues are covered in the relevant standards, e.g. [4], and will not be discussed here since we focus on the traffic multiplexing issues. For the operation of the MAC all that is important is that a number of permits is provided in a periodic basis corresponding to the number of upstream slots over the same period. The reservations in the HFC MAC are usually assisted by contention on special reservation mini-slots [4] in addition to the piggy-backed requests. This is needed for the announcement of the first arrival of a burst since the piggy-back mechanism is not self-starting but relies on the existence of previous traffic for the announcement of new arrivals [6]. However the MAC implemented in the AROMA system departs from this approach in two points: first it provides for all three simultaneous requests (one from each queue) as explained above, irrespective of which queue provided the cell, and second it employs round robin polling instead of

53

Α

Figure 2: Operation of

ΔΕ ΙΓ Μ

the permit scheduler

contention. Simple polling is considered adequate since the AROMA system targets an advanced stage of deployment when the HFC take-up will be significant and the customer clusters will be smaller with much higher bandwidth needs. The use of contention, as adopted in IEEE802.14 [4], is an advantage for the initial introductory stage, when high number of customers can share the limited bandwidth of the coax system. However, at some point the number of customers sharing the 3Mbp channel will have to become lower than 100 and in such a case polling is adequate. The multiple requests are the tool for the higher QoS capabilities of the system. They are necessary if higher priority traffic is to be quickly made known to the head-end. This feature enables the algorithm at the head-end to offer precedence in the permit allocation to the high priority on a global basis and not just among the cells of the same termination which is of a very limited value. The MAC algorithm works as follows: The first priority employs a list of 512 permits, which has been prepared by the embedded processor on the basis of subscription data. The list is cyclically read out by the MAC controller hardware, and the permits sent downstream. Since ATM signalling is also supported in AROMA, the list can be updated dynamically to add new connections using a second copy. At the end of the read cycle the hardware is switched over to the updated copy. Techniques to space the permits in the list are given in [7]. The other three priorities are serviced dynamically on the basis of requests by filling in locations whenever they are left empty in the list (representing unallocated bandwidth). The requests per queue/priority arriving at the MAC controller in the head-end, are used to update

54

3.2.4

Performance Assessment

Α

the 3 outstanding request totals for each modem and queue, by incrementing the relevant counters by the amount of new cell arrivals. At the same time the downstream permit positions in the frame are filled with permits produced by an engine scanning in a round robin fashion the outstanding request counters and reducing them by one for each permit scheduled. The higher priority counters are inspected first and only if all are empty the same process is repeated for the immediately lower priority. To expedite the process, flags are used to quickly detect and skip all empty locations. At the end of each cycle, the embedded controller updates a list of credits corresponding to the established peak rate of connections for the 2nd priority. The MAC hardware subtracts the credits as it issues permits and stops serving any modem queue that exceeded its allocated apportionment. This policing action guarantees that malicious users can not disturb complying traffic. The credit check is used differently in the 3rd priority. When credits are exhausted, left-over requests are added to the 4th priority ones thus a minimum rate is guaranteed but any excess is considered plain best-effort, in accordance with AF rules.

ΔΕ ΙΓ Μ

The behaviour of the above MAC mechanisms was studied with the help of computer simulation created with the PTOLEMY tool. The scenarios used 10 cable modems loaded with uniform traffic for each priority. The slot (170.6 µs) was used as a time unit. The traffic sources used the common ON-OFF model, generating traffic at the slot/cell level with exponentially

Figure 3.

Pdf of access delay

55

ΔΕ ΙΓ Μ

Α

Figure 4. Mean delay vs. total load

distributed on and off periods. The peak rate was the system rate simulating the arrival of IP packets with geometrically distributed lengths, which were instantaneously segmented into slots. The 1st priority will not be presented since it exhibits deterministic behaviour with the delay never exceeding the fixed permit distance as pre-programmed in the list. (More on the behaviour of such an approach is given in [7]). Figure 3 depicts the probability distribution function (pdf ) of the access delay for the 3 priorities under a total load of 85%. Only the variable part of the delay is shown i.e. the fixed round trip time of about 4 slots for the travel of the request upstream and the permit downstream is not included. The 1st priority list was using 10% of the load for CBR traffic (or virtual leased lines by EF in the DS model of usage) with the other 75% equally distributed among the other 3 priorities. The delay advantage provided by the prioritization leads to almost all the slots of the 2nd priority accessing in less than 250 slots (i.e. 43 ms) while those of the 3rd in less than 350 slots (60 ms). Of course there is no bound for the 4th priority which can exceed any limit depending on the total loading. This is better illustrated in Figure 4, which shows the mean delay as a function of the total load for each priority. Again 10% was provided by the list as necessary for the polling of new bursts and the rest equally distributed among the priorities and modems in a way that the total was the one shown on the horizontal axis.

56

The delay for the first priorities increases very smoothly with the load leaving the 4th priority to suffer the congestion with the delay increasing asymptotically to the 100% line as is typical of any queuing system. The buffer size increases without limit. However, the sources used do not model higher layers where the typical congestion avoidance of TCP would exercise flow control in response to losses and reduce the rate, while re-transmitting lost packets. So the system thanks to prioritization can guarantee the performance enjoyed by sensitive traffic while exploiting any unreserved bandwidth for the support of best-effort traffic. 3.2.5

Conclusion

ΔΕ ΙΓ Μ

Α

Tree-shaped shared medium access networks such as PONs and HFC effect a distributed multiplexing function which concentrates traffic from many users and many services with diverse requirements. To be able to guarantee that the QoS of sensitive traffic will not be disturbed by best-effort data traffic requires embedding differentiated support for flow aggregates with common requirements. The DiffServ architecture is quite advantageous in this context and a MAC protocol taking advantage of this approach was implemented and evaluated with satisfactory results.

Acknowledgement

The work presented in this paper was partially funded by the EU ACTS project AC327 “AROMA”.

References [1]

[2] [3] [4] [5]

[6]

[7]

IETF, Differentiated Services Working Group, RFC 2475 “Architecture for Differentiated Services”, December 1998 Van Jacobson, Kathleen Nichols, Kedarnath Poduri, Internet Draft, draft-ietf-diffservphb-ef-02.txt, “An Expedited Forwarding PHB”, February, 1999 Juha Heinanen, Fred Baker, John Wroclawski, Internet Draft, draft-ietf-diffserv-af-06.txt “Assured Forwarding PHB Group”, February, 1999 IEEE 802.14 MAC Draft (R3) Specifications, May 1997 (not publicly available). J.D.Angelopoulos, G.C. Boukis, I.S.Venieris, “Delay priorities enhance utilization of ATM PON Access Systems”, Computer Communications Journal, Elsevier, Vol. 20, No. , December 1997, pp. 937-949. J. D. Angelopoulos, Th. Orphanoudakis, “An ATM-friendly MAC for traffic concentration in HFC systems”, Computer Communications Journal, Elsevier, Vol. 21, No. 6, 25 May 1998, pp. 516-529. J. D. Angelopoulos, N. I. Lepidas, E. K. Fragoulopoulos, I.S. Venieris,”TDMA multiplexing of ATM cells in a residential access SuperPON”, IEEE Journal on Selected Areas in Comm., Special issue on high capacity optical transport networks, Vol. 16, No. 7, September, 1998.

57

3.3

ELISA: QoS for IP over ATM—a Combined IntServ / DiffServ Approach

Editor: Bert F. Koch, Siemens, Germany. Co-authors: C. Prehofer, Siemens, Germany; I.S. Venieris, G. Mamais, G. Politis, NTUA, Greece; G. Eichler, T-Nova, Germany; M.A. Barba, Telefónica I+D, Spain; R. Cocca, S. Salsano, CoRiTeL, Italy; H. Hußmann, F. Fünfstück, TU Dresden, Germany; T. Van Do, TU Budapest, Hungary.

ΔΕ ΙΓ Μ

Α

This paper reports on the experimentation of a network architecture for Quality of Service (QoS) for Internet applications. The new architecture supports the Integrated Services as well as the Differentiated Services approaches in a smoothly integrated way and uses the capabilities of an underlying ATM network to realize QoS. The enhancements to the existing network infrastructure are deliberately limited to the integration of a single new type of network element called Edge Device. The paper presents the network architecture as well as business scenarios and scalability analysis. It is based on a chapter of the book “Flexible Working—New Network Technologies—ACTS Activities” jointly produced by the ACTS projects DIFFERENCE, InfoBridge, and ACTSLINE [1]. 3.3.1

Introduction

The Internet gives a fascinating vision of a future global and user-friendly information infrastructure. Unfortunately, current Internet technology is technically not suitable for reliable multimedia services, since it does not provide adjustable Quality of Service (QoS). The Internet relies on a protocol layer (IP) which enables interoperation of various network technologies, but uses the least common denominator of the capabilities of underlying networks (best-effort quality). On the one hand, several concepts for QoS on the IP-level have been proposed, in particular the IETF Integrated Services (IntServ) and Differentiated Services (DiffServ) architectures. On the other hand, there are already commercially available networks (of competitive technology, e.g. ATM) where high potential for QoS support exists but is not exploited in the Internet. Therefore, an interaction and integration of QoS Internet and ATM becomes necessary. This paper describes a new architecture that tightly integrates the mentioned approaches in order to provide QoS. This approach is based on a careful analysis of the main functional building blocks for QoS and shows that rather different-looking concepts can be supported by a single homogeneous and elegant architecture. The described approach defines an open QoS architecture that provides flexibility to incorporate new concepts beyond those already supported. For example, a QoS request (as it is defined by IntServ) may be mapped directly to an individual ATM connection or may be aggregated with other requests in a “controlled” DiffServ traffic class (Expedite Forwarding).

58

3.3.2

The ELISA Architecture

Α

The main objective of the ELISA project is to offer a practical approach for the provisioning of Integrated Services (with the help of RSVP) and Differentiated Services architectures based on Internet IP technology. Moreover, the ELISA project brings together such an advanced IP service approach with the capabilities offered by an ATM-core network (e.g. guaranteed QoS through ATM switched connections). In order to achieve that goal the ELISA architecture focuses on an Edge Device, which acts as an edge router as well as an Integrated Services gateway. The AC310 ELISA consortium is formed by public network operators (Deutsche Telekom AG, Telefónica I+D), equipment manufacturers (Siemens AG and Siemens Telefongyár Kft), an SME (TOPOLOGIX GmbH), as well as research institutes and universities (GMD FOKUS, CoRiTeL, Dresden University of Technology, National Technical University of Athens, and Technical University of Budapest). It provided a trans-European testbed to demonstrate the feasibility of the architectural approach.

ΔΕ ΙΓ Μ

One of the main goals of the ELISA architecture is to enable operators of wide-area ATM networks to offer the advanced features of ATM technology to end-users who are using IP-based applications. The architecture assumes as the standard case that end-users are not connected directly to the ATM wide-area network but are connected through the infrastructure of an Internet Service Provider or an intranet, which may use, for instance, various LAN technologies, ISDN dial-up access or xDSL access networks. The ELISA architecture is flexible enough to be applied to configurations where the core network is not ATM based, but this is out of focus of the prototype currently being developed. In order to bring QoS to IP-based applications, it is necessary that QoS is somehow accessible in the Internet world, i.e. applications or end systems can define their specific QoS requirements. There are two main approaches to QoS, which are currently discussed in the Internet community: • The Integrated Services (IntServ) architecture [2] is based on individual resource reservations issued by the applications using reservation protocols, in particular the Resource Reservation Protocol (RSVP) [3]. The routers in the core network have to reserve resources for the individual flows. • The Differentiated Services (DiffServ) architecture [4,5] takes a much simpler approach and simply assumes that IP packets are marked as belonging to one out of a number of different traffic classes. Network elements treat these with appropriate Per Hop Behaviors (PHB) [3]. Core routers simply have to follow the general rules for the respective traffic class/PHB and do not deal with individual QoS requests. Both approaches have their advantages and disadvantages. The main problem with the Integrated Services architecture is that it does not scale well to large wide-area networks, since in this case reservation processing on central core routers becomes a bottleneck. The problem with the Differentiated Services approach is that it can give true service guarantees

59

Figure 1: ELISA reference architecture

ΔΕ ΙΓ Μ

Α

only if it is combined with rigorous policing of the access to the high-quality service classes. And a problem with both approaches is how to interwork with already available ATM infrastructure. ELISA solves these weak points. Several aspects related to the interworking of IntServ and DiffServ approaches are considered in [6]. The definition and implementation of the ELISA architecture has progressed in parallel with the work reported in this IETF draft. The ELISA architecture focuses on one important network element, which is particularly relevant for QoS. This network element is called Edge Device (ED) within ELISA, but it may also be called an extended access router or a QoS gateway. The Edge Device prototype developed in ELISA connects an access network to a wide-area core network. The interconnection of EDs realizes an overlay QoS network for the IP-based applications. ELISA targets only end-systems that are connected through an Edge Device. The access network is typically based on LAN technologies or on POTS, ISDN or xDSL. The core network can be a plain ATM network, which is the optimal network base for ELISA. But the ELISA Edge Device also works in more general configurations where the core network is an arbitrary DiffServ-based IP network, which possibly resides upon an ATM layer. The ELISA network architecture does not require any changes or upgrades to any of the involved sub-networks. Figure 1 shows the reference network architecture of ELISA. Details are shown only for a pair of end-systems, but the general assumption is to have many end-systems connected to each Edge Device and many Edge Devices to the core network. The end-systems connected to the access network use only IP-based protocols and can specify their QoS requirements in two different ways: either they issue reservation requests using RSVP/IntServ or by subscription to a specific DiffServ traffic class. The Edge Device deals with both kinds of requirements. Reservations are analyzed, policed and mapped onto appropriate core network traffic classes (Figure 2). These core network traffic classes can be carried over a dedicated ATM Switched Virtual Channel (SVC) to another Edge Device, or over a portion of a pre-established ATM Permanent Virtual Channel (PVC) using a specific DiffServ class. Note that the end-

60

Α

Figure 2: ELISA Edge Device – an approach for integrating IntServ/DiffServ over ATM

ΔΕ ΙΓ Μ

system just uses the reservation protocol without any knowledge of the mechanism chosen by the Edge Device. Note further that the reservation processing is done only in the Edge Device and not in the core network. The flexible mapping into ATM VCs distinguishes the Edge Device from other proposals for the IntServ/DiffServ integration known to the authors. In summary, the following network capabilities will be implemented in the Edge Devices: • IntServ, where resources are explicitly requested. Resources will be provided by a dedicated SVC or by aggregation into an existing link. • DiffServ, where resources are provided according to the marking of the packets. The following classes are available: Best Effort (BE), Priority (P), High Priority (HP), Expedited Forwarding (EF).

DiffServ traffic is analyzed and policed in the Edge Device. The Edge Device is able to carry out DiffServ marking for end-systems that do not support DiffServ marking themselves. In this case, the traffic class is derived from the IP address or other selectors (e.g. TCP port number) based on information, which is kept on the Edge Device in a configurable way. The ED is able to do policing based on volume limits for traffic in a specific DiffServ class, and therefore enables QoS guarantees for reservations following the DiffServ approach. As an additional function, the ED is able to collect information for usage-based charging for QoS usage, for explicit reservations as well as for DiffServ class usage. The advantages of the ELISA architecture are that it flexibly combines the Integrated Services and Differentiated Service model by mapping reservation requests onto DiffServ classes where possible and that it removes some of the scalability problems for explicit QoS reservations in wide-area networks. Of course, this raises the question how the scalability of the ELISA architecture itself is ensured. Aspects related to the scalability of an architecture combining IntServ and DiffServ are considered later.

61

ΔΕ ΙΓ Μ

Α

In the ELISA architecture, two different kinds of interfaces must be considered. Figure 1 shows these two interfaces, which will be referred to as Access Interface and Edge Interface. The Access Interface allows the host to interact with the network and in particular to be connected to the Edge Device. The Edge Interface allows the Edge Device to access the core network. This distinction is consistent with the choice to partition the network in an access domain and a core domain. Let us briefly analyze the protocol stacks used at both interfaces to transport IP packets (user plane) and the control mechanism needed to signal QoS requirements (control plane). On the Access Interface, the IP packets are carried over LAN (Ethernet) or ISDN (using PPP). At the control plane level, the RSVP protocol is the mechanism which is used by the applications to signal their QoS requirements on the Access Interface, according to the Internet Integrated Service model. The ELISA RSVP protocol messages are fully compliant with the relevant RFCs issued by the IETF [3]. In the ELISA architecture, the RSVP can be used within the access network domain to allocate resources up to the Edge Device. RSVP is used in the ED to allocate resources and to map the user requests onto the mechanisms used in the core network. The Edge Interface is based on ATM under the hypothesis that a network operator provides ATM semi-permanent and switched connection. It is a UNI interface; for the ELISA project a common subset of ATM Forum 3.1 and ITU-T 2931 is used. IP packets are encapsulated on ATM according to RFC1483. The control plane of the Edge Interface is based on two concepts. The first concept is that RSVP is used with “end-to-end” significance through the core network domain. This means that RSVP messages are interpreted only in the access network domain and in the Edge Device, but not in the core network domain. The second concept is that the RSVP reservations can be mapped either onto DiffServ classes or directly onto a dedicated ATM connection that will be set-up on demand. 3.3.3

Scalability

With the term “scalability” the implications of large networks on the network elements is meant; in particular, the system requirements of a single node should not grow linear with the number of network elements. For our architecture, there are several issues to be discussed. The main feature of RSVP is the management of single flows. Once the reservation has been established, all the routers in the path have to recognize the packets belonging to a reserved flow and provide a convenient handling. These actions can easily become an unacceptable processing burden when hundreds of thousands of different flows must be handled, for example in a gigabit core router, resulting in a bottleneck. Similarly, the need to exchange and store “per flow” information is another heavy burden for core routers. These scalability concerns have led the Internet community to investigate simpler solutions for the support of QoS. In the Differentiated Services model [4], the basic idea is to support a set of traffic classes

62

ΔΕ ΙΓ Μ

Α

providing a different service to each one. User flows are only controlled at the edge of the network and then aggregated into a small set of traffic classes: this approach relieves the scalability impairments on the core router in the classical RSVP approach and overcomes the scalability issue. Since IntServ and DiffServ focus on reservations and scalable service differentiation, respectively, it is advantageous to combine both for an overall solution: IntServ can be used in the access network and DiffServ in the core network, as it is supported in the ELISA architecture. Restricting RSVP to the access also makes the architecture relatively future-proof, since it can be easily adapted for different mechanisms to signal QoS requests (as they may for instance appear in future object communication middleware). Such an upgrade would only involve parts of the Edge Device but would not affect the core network. Imagine now that the IP routers in the core network are interconnected by means of an underlying ATM layer. In a small-scale network scenario direct ATM connections among all the EDs can be assumed. This configuration (an example is shown in Figure 3) has been deployed in the ELISA trial. In a large-scale network a fully meshed topology with direct links between all EDs is not feasible. Therefore, DiffServ-enabled routers (DS-R) are used in the core network. In such a scenario, good scalability is achieved since every “per flow” operation is confined to the EDs and does not impact the core of the network, where only highly aggregated traffic flows are dealt with. The underlying network infrastructure (for interconnecting DS-Rs and for connecting EDs) should be ATM in the ideal case, but non-ATM portions can be handled. Two issues must be considered when dealing with this target architecture: • The first one is typical for the DiffServ approach: how to enforce QoS reservations in a network composed of a set of routers. Obviously the intermediate routers must be involved in providing the QoS between two EDs and since intermediate core routers do not interpret RSVP messages, these routers are not updated on bandwidth requests. There is a wide range of possible solutions, with a different trade-off between complexity and efficiency. The simplest approach is to keep local reservation/admission control in the EDs and to follow a static approach. In this case a sort of advance pre-allocation of bandwidth is needed, which typically results in a loss of efficiency. More efficient solutions imply a dynamic exchange of information, which can involve Edge Devices and the intermediate routers. This new control mechanism could be a peer-to-peer mechanism or ad-hoc devices (often called bandwidth brokers) can be introduced, with the purpose of controlling resource allocation in a DiffServ network. The admission control procedure for a DiffServ domain is performed with the help of an Admission Control Server (ACS), which can keep information at an aggregate level (per link, per Edge Device), while per flow information is only stored in the Edge Devices. The EDs keep per-flow “soft” state, which is created with the first RSVP RESV message and must be constantly refreshed by RESV messages. The ACS could work with “hard” state,

63

Α

Figure 3: Target scenario

ΔΕ ΙΓ Μ

which means that a resource is allocated once until explicitly de-allocated. This approach has a positive impact on the scalability, as it reduces the interactions of EDs with the ACS. • The second issue is typical of the wide-area IP over ATM architectures. Scalable mechanisms for translating IP addresses into ATM addresses are needed. These mechanisms (e.g. NHRP) are under study within IETF, but their interaction with RSVP is still unclear. A suitable straightforward extension to RSVP to support IP/ATM address resolution is described [11]. If there is an ATM path between two EDs these mechanisms allow the establishment of direct QoS ATM shortcuts. 3.3.4

Business Scenarios

In this section two possible business scenarios based on the network architecture developed in ELISA are discussed. Depending on who owns which part of the network, different revenue models are considered. In addition, each player can optimize the network usage in order to optimize his part of the network structure and to optimize revenues. There are two main scenarios, the public access and the corporate access scenario, which are discussed below. The public access scenario is shown in Figure 4. Users connect to Edge Devices owned by ISPs, e.g. by ISDN, xDSL or any other access technology. The ISPs connect their Edge Devices via an ATM network, which is owned by an ATM core network provider. Clearly, a possible special case is that both ISP and ATM operator coincide. In this scenario, we have at least two business relations. The end-user will be charged by the ISP for the individual user services or by flat rate models, which may include access to some services. In addition, it is possible that the service is initiated and paid by a content provider, who in turn charges the user, e.g. by credit card. Another option is that the ISP charges for application level services, which provide QoS.

64

Α ΔΕ ΙΓ Μ Figure 4: Public access business scenario for the ELISA architecture

In turn, the ISP has to lease the ATM connections from the ATM operator. In the case of dedicated ATM connections for one user QoS request, there is a direct mapping of the cost for the ATM connection to the user service. In the other cases, traffic is aggregated in service classes. The ISP has to lease a number of statically provisioned ATM connections (fixed costs) which are supported by on-demand switched VCs (variable costs). Although one user request may trigger an extra VC, there is no direct relation between the ATM connection and the user service. From a technical point of view, bandwidth management can take place on the IP-level (DiffServ scheduling in the ISP Edge Device) and on the ATM layer via ATM VCs. With the former, DiffServ classes can borrow unused bandwidth of other DiffServ classes in order to utilize the available link layer bandwidth. On the other hand, we can map DiffServ classes to different ATM VCs providing different traffic capabilities. In this case, the ATM layer has to assure that bandwidth is not wasted. However, in the first case, the ISP can use extra bandwidth for best effort and other traffic, while in the other case, the ATM operator may use the extra bandwidth. Hence the ELISA Edge Device design provides flexible mechanisms to utilize bandwidth (and in turn service charges) for both ISP and ATM operator. In the corporate scenario in Figure 5, the Edge Devices are operated by a coperation inside its local area network. In this case, the users are typically connected via LAN infrastructure.

65

Α ΔΕ ΙΓ Μ

Figure 5: Corporate business scenario for the ELISA architecture

The CPE equipment and the Edge Devices are administered by the same corporate network operator. (In case the Edge Device is leased from the another operator, the model is similar to the one above.) For the core network, it is convenient for the coperation to lease ATM connections, which serve as a virtual private network (VPN). In this case, other issues like security and service availability can play a more important role than in the above-mentioned case. 3.3.5

Trial

The final target of ELISA was to evaluate the DiffServ and IntServ features mapped onto ATM SVC connections as well as the charging capabilities of the ELISA platform related with the provision of services. For this purpose, an Edge Device and Customer Premises Equipment have been implemented. The feasibility of the ELISA approach has been tested and demonstrated in an international testbed. The testbed involves Edge Devices located in four core sites (Munich, Darmstadt, Berlin, Budapest) and end systems deployed in several remote sites in different European countries (Spain, Italy, Greece), as it is shown in Figure 6. The remote sites and local terminals have been connected to Edge Devices using some selected access technologies.

66

Figure 6: Trial sites of

Α

the international testbed

ΔΕ ΙΓ Μ

The experiments focus on: • the functional verification of interworking functions between IntServ, DiffServ and ATM, signaling, admission control, traffic policing and traffic shaping as well as charging modules, • performance measures related to the traffic, affecting Quality of Service, and • experiments assessing end service aspects and taking into account both the user perception and the service provider perception.

The functional testing demonstrated the correct interworking of the components of the ELISA architecture, which have been implemented and deployed. The traffic and QoS testing aims at obtaining, at measuring time, some performance parameters (throughput, packet delay, packet loss, QoS session setup-time, etc.) of different flows. For example, a comparison of the performance of IntServ flows and best effort flows under different network load has been done. The goal was to show that ELISA provides an efficient QoS-framework for IP flows. Quantitative measurements of the relevant parameters will be performed later. Finally, the testing of the end-user applications demonstrated the functionality of the applications deployed in the ELISA project. 3.3.6

Conclusion and Outlook

We have introduced an innovative approach that integrates the major trends for QoS (IntServ, DiffServ, and ATM) into a single and scaleable architecture. Such a “convergent network”, bringing together the best of all these concepts, is technically feasible and economically viable. Moreover, a generic and elegant design concept for an Edge Device has been presented which enables the practical usage of the proposed architecture in well-defined migration steps, and which is currently being realized. For a future QoS-aware Internet approach, it can be expected that more sophisticated

67

mechanisms are used for QoS control. The concept of “bandwidth brokers” forms the starting point for a QoS architecture that is based on DiffServ principles in the core network but adapts its resource allocations automatically to user demand. This leads to an overlay network of QoS administration agents that interact autonomously and intelligently, in order to optimize the network configuration under all possible conditions.

References B. F. Koch et al., “Internet Service Architectures and ATM – The ELISA Approach”, in “Flexible Working—New Network Technologies—ACTS Activities”, IOS Press, 1999, pp 179 – 194. [2] R. Braden et al., “Resource Reservation Protocol (RSVP)—Version 1 Functional Specification”, IETF RFC 2205, September 1997. [3] S. Blake et al., “An Architecture for Differentiated Services”, IETF RFC 2475, December 1998. [4] K. Nichols et al., “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, IETF RFC 2474, December 1998. [5] V. Jacobson et al., “An Expedited Forwarding PHB”, IETF RFC 2598, June 1999, available via http://www.ietf.org/html.charters/diffserv-charter.html [6] Y. Bernet et al., “A Framework For Integrated Services Operation Over DiffServ Networks”, Internet Draft draft-ietf-issll-diffserv-rsvp-03.txt, September, 1999. Available via http://www.ietf.org/html.charters/issll-charter.html [7] E. Crawley et al., “A Framework for Integrated Services and RSVP over ATM”, IETF RFC 2382, August 1998. [7a] M. Garret, M. Borden “Interoperation of Controlled-Load Service and Guaranteed Service with ATM”, IETF RFC 2381, August 1998 [8] J. Davin and A. Heybey, “A Simulation Study of Fair Queueing and Policy Enforcement,” Comput. Commun. Rev., Vol. 20, October 1990. [9] S. Floyd, V. Jacobson, ”Link-sharing and Resource Management Models for Packets Networks”, IEEE/ACM Transaction on Networking, Vol.3 No.4, 1995. [10] M. Fowler, K. Scott, “UML Distilled” Addison-Wesley, 1997. See also http://www.rational.com/uml [11] R. Cocca, M. Listanti, S. Salsano “Interaction of RSVP with ATM for the support of shortcut QoS Virtual Channels” –Proceedings of 2nd International Conference on ATM “ICATM’99”, June 21-23, 1999, Colmar, France. [12] T. Do et al. “ELISA: European Linkage between Internet Integrated and Differentiated Services over ATM”, IEEE Workshop on QoS Support for Real-Time Internet Applications, June 2-4, 1999, Vancouver, BC, Canada. [13] E. Gamma, R. Helm, R. Johnson, J. Vlissides, “Design Patterns” Addison-Wesley, 1995.

ΔΕ ΙΓ Μ

Α

[1]

68

3.4

IthACI: Layer 4 QoS Detection in Flow-Based IP-Switching

Frederic Griffoul, Jürgen Röthig, Sibylle Schaller, Heinrich J. Stüttgen. Computer and Communication Research Laboratories NEC Europe Ltd.Germany.

ΔΕ ΙΓ Μ

Α

This paper describes a novel approach to provide application flow specific Quality of Service support in IP networks for multimedia applications. The architecture is built around an implicit signaling scheme based on the analysis of the transport layer and its payload, e.g. RTP protocol information. Therefore this QoS architecture is applicable only to those applications which use specific higher layer protocols like RTP. Although recent traffic statistics show that backbone Internet traffic consists of some 60 to 80% web traffic, we expect the RTP share to grow significantly in the future. Many new experimental multimedia applications already use RTP for the transmission of their data over the network. More and more multimedia and real-time applications push into the Internet. The architecture is applicable to general IP routers and switches. A first implementation was done in the ACTS IthACI project and based on NEC’s IPSOFACTO IP-Switching architecture. ACTS IthACI is a third call ACTS project focusing on MPLS evolution and multimedia extensions for IP-Switching. QoS support for the traffic driven IPSOFACTO technology starts with real-time RTP flow detection and parameter analysis for RTP flows. The provisioning of a flow specific QoS is then based on the detected QoS class (i.e. “Class of Service” or CoS) of the real-time flow under observation. This first step, i.e. the detection of the RTP flows, is independent of the QoS provisioning itself, but rather a prerequisite. Because RTP is not a transport protocol by itself (like TCP and UDP) which can be recognized by a protocol number as defined e.g. for UDP, the detection of RTP flows is done with a “weak test” based on the RTP header validity check which may be misleading in some cases. The QoS provisioning for RTP flows itself is then achieved by assigning different priority classes for RTP flows within the ATM switch. Hence in this architecture a “Class of Service” approach, rather than a true “Per-Flow QoS” approach is supported. Since IPSOFACTO is an IP-Switching technique, i.e. an IP over ATM architecture, QoS/CoS support depends on the QoS/CoS capabilities of the underlying ATM switches, in particular on the QoS/CoS capabilities in the GSMP interface between ATM switch and switch controller. In our case a simple priority-based CoS scheme is used. However, the general architecture is independent of ATM. A similar scheme could be used in an environment based on a pure DiffServ-based IP router.

69

3.4.1

Introduction

ΔΕ ΙΓ Μ

Α

New IP switching techniques, using higher layer control information (layer 4 and above) are considered in order to provide improved network services with regard to security, performance, or QoS support for multimedia traffic. One of the main ideas behind this so called layer 4 switches is that higher layer information within the first packet(s) of a data flow can be utilized to set up a switched path for this flow. If this scheme is extended first to detect and then to allocate the appropriate QoS for such a flow, it is an attractive way of handling QoS allocation in-band, without explicit out-of-band signaling. The remainder of this section contains a short introduction to Layer 4 switching and an example scenario. Section 3.4.2 gives general and architectural information for RTP flow detection. The feasibility and problems to recognize RTP packets are described and a basic approach is given. Some information about QoS provisioning concludes the section. Section 3.4.3 presents a description of an implementation of RTP flow detection and its QoS provisioning scheme based on NEC’s IPSOFACTO IP-switching technology within the ACTS IthACI project. Section 3.4.4 closes the paper with some conclusions. 3.4.1.1

Layer 4 Switching

Layer 4 switching is an approach which can be beneficially used at the edge node of a multigigabit IP backbone, independent of whether the backbone is based on ATM or other high

Figure 1: Example scenario

70

ΔΕ ΙΓ Μ

Α

performance transport technologies like WDM. High priority data or real-time flows can be detected when they leave the high-performance, typically over-provisioned LAN and enter the IP backbone (see Figure 1). This backbone generally requires explicit QoS support for performance and/or charging reasons. The combination of layer 4 switching with MPLS can result in a backbone network with efficient data transport and distinguished service and resource management. An example is for an ISP to provide DiffServ for general traffic and to offer extra paths and service for determined applications (e.g. the voice transmission in a video conference using a certain RTP payload type). Layer 4 switching uses transport layer information, e.g. TCP or UDP port numbers, to forward packets. Using layer 4 information to forward data allows collecting additional information about source and/or destination of a data frame. Not only the destination machine is determined by the layer 4 information, but also the type of program which transmits and receives the data units via well-known ports. Today’s routers already use this information to enable or disable selected services (firewall). At layer 4 each TCP stream or UDP packet is associated with two port numbers (source and destination port). Many TCP/UDP port numbers have a specific meaning in all TCP/IP implementations [4]. These port numbers help to identify the application (FTP, HTTP, Telnet...) used with the corresponding communication. The protocol number is used at the IP layer to determine the appropriate transport protocol that has to handle the packet. Some protocols like RTP do not use well-known ports, other protocols like HTTP are not forced to use their well-known port and may use other ports. In those cases the port number cannot be used to detect these flows. Additional information from layers above layer 4 is needed to determine the type of a flow (layer 4+). Several different approaches to layer 4 switching are currently used or discussed. They differ in the information extracted from the higher levels and the usage of this information. The existing implementations are used, for example, in security filters and firewalls. 3.4.1.2

Technical Challenges

Adding layer 4+ support to the existing router and switch concepts may increase some of the major bottlenecks of the forwarding task. Performance loss due to even more complex search and update operations may be the result. The fact that the switch-router now needs to access the encapsulated data where classic routers and switches don’t need to care about the payload and its encoding may add to the problems. The major technical challenge will presumably be the search engine. Furthermore, the mapping of layer 4(+) based QoS parameters onto Integrated/Differentiated Services has to be done by the switch-router. Another challenge is the handling of encrypted data, which inhibit the switch-router from accessing the transferred data. Support for layer 4 port number handling increases the sizes of search/routing tables dramatically, since for every entry additional information has to be stored where standard IP

71

Flow Detection

ΔΕ ΙΓ Μ

3.4.2

Α

routers need to hold only one entry per destination address. Since a layer 4+ switch-router handles different protocols separately, such a switch-router needs to store one entry for each protocol used on each destination machine. As routing table lookup is a bottleneck for standard IP routers, fast lookup will become an even more important issue with layer 4(+) switching. Furthermore the length of the look-up keys is increased by the source address (which is not used in IP routers, but is needed to identify a TCP connection), the port numbers of source and destination and additional information extracted from layer 4+ information. The information derived from layer 4 and above needs to be mapped to the QoS parameters or classes of the respective network QoS model used, like IP Differentiated Services, IP Integrated Services or ATM, or other future QoS architectures. This requires a translation of implicit priorities and service requests given by the information extracted from layer 4 and above, explicit priorities and requests given by applications or extracted from information of layers 4 and above to the service parameters and classes of the respective target model. In addition, signaling for explicit reservations may be included to allow some applications to reserve dedicated resources for a stream.

RTP, the Real Time Protocol, runs on top of UDP and is mainly used for audio and video streaming, hence for those applications that will require better QoS support in terms of bandwidth (i.e. safe/assured transmission of data without loss at application-required data rates) and jitter in the future. Today’s multimedia applications using RTP create only a small fraction of the total network traffic. However, multimedia traffic will grow considerably in the near future and therefore it is advisable to investigate whether the layer 4+ switching approach can be applied to RTP flows. While TCP flows are easy to detect due to their connection-oriented nature, UDP traffic imposes several problems when the detection of a certain kind of flows is intended. UDP is a connectionless protocol, where the data is sent in (unrelated) datagrams over the network. No obvious relationship between the packets of one single flow exists on UDP level. 3.4.2.1

The Identification of RTP

RTP traffic is, from a logical point of view, connection-oriented. But, this kind of ‘connection’ is only seen above layer 4. RTP neither has a specific protocol number that could be carried in the IP header’s protocol type field, nor uses well-known ports. Therefore, in order to identify RTP streams it is not sufficient to look at layer 4 only. The data packet’s layer 4 payload must also be examined. RTP is currently part of the application layer. It forms a part of the application and requires the existence of an underlying transport protocol, i.e. UDP. The fact that RTP packets are encapsulated in UDP and that they do not use a fixed port make it difficult to detect and classify RTP flows. The proposed RTP flow detection is based on a weak test, which means that flows may not be detected with absolute certainty. On one hand, non-RTP flows might

72

Α

Figure 2: RTP packet structure [5]

ΔΕ ΙΓ Μ

get special QoS treatment without being eligible. On the other hand, some RTP flows might go undetected and not get proper treatment: they will remain in the best-effort path. In the IETF, work is currently under way to advance RTP and the RTP profile specification to the draft standard stage. An Internet-draft [8] brings forward the idea of elevating RTP to transport protocol status by having a header, which is identical to the concatenation of the UDP and RTP headers. In this way, RTP would become a transport protocol on the same level as UDP and TCP. Elevating RTP to transport protocol status would imply that RTP packets are explicitly labeled as such in the IP packet header. If this idea was accepted and implemented universally, the detection problem of RTP streams could be solved deterministically. However, the mentioned Internet-draft expired in September 1998, and the authors of this paper are not aware of any progress on that topic. 3.4.2.2

Basic Approach to Flow Detection

The packets that can be part of an RTP flow are the RTP data packet, RTCP Sender Report (SR), RTCP Source Description packet (SDES), RTCP BYE packet (BYE) and the RTCP Application Specific packet (APP). The RTCP Receiver Report (RR) travels in the reverse direction, i.e. from the receivers to the sender. Layer 4+ switching can identify RTP streams and also distinguish between different originating streams. Regarding the current RTP definition, a detection scheme is needed, which is based on RTP not being a distinct protocol, i.e. not having assigned a protocol number like e.g. UDP or TCP. A simple and thus efficient heuristics is used to identify RTP data packets, according to the RTP data header validity checks in [5]. RTP data packets (see also Figure 2) are identified based on:

73

Parameter

Description

Version field

The RTP version has the value 2 as defined in [5].

Payload Type field

Payload types are values within a certain range as specified in special RTP profiles, e.g. [6].

Sequence Number

The sequence number increases by one in subsequent packets.

Length of the packet The X-bit must be zero, if the profile does not specify that the header extension mechanism may be used. Otherwise the extension length field must be less than the total packet size minus the fixed header length and padding.

P bit

If the P-bit is set then the last octet of the packet must contain a valid octet count.

ΔΕ ΙΓ Μ

Α

X bit

The detection of RTCP packets and their mapping to a particular service class is not considered in this paper since they constitute only a small fraction of the overall RTP traffic. [5] suggests the RTCP portion to be fixed at 5%. Nevertheless, it remains an open question whether RTCP packets should receive appropriate QoS mapping or other special treatment.

3.4.2.3

Approach to QoS

The mapping of RTP traffic to special services can be done in various ways. One way is to attach RTP flows to pre-established paths that fulfill the requirements for certain services. The second way is to use a set of priorities to provide basic QoS support in the switch. In this scheme traffic flows will be assigned different priorities according to their type, importance and urgency. RTP flows then could be sent with higher priority, according to their different needs as compared to other non-real-time traffic. Actually, this does not provide true “PerFlow QoS”, but rather “Per-Class Quality of Service” or “Class of Service”. Another possibility to map RTP traffic is to open a single switched path with its own set of special service parameters for each RTP flow. The advantage lies in the ability to offer very special services to some applications and flows, and in the ability to protect the other traffic from a flow’s unfair behavior (e.g. UDP does not behave well in situations with congestion in the network). The main disadvantage of this approach lies in the high consumption of labels/VCs for all the special paths. Also, this approach cannot be used with DiffServ alone, because DiffServ provides only relative priority classes and there is no possibility of per-flow QoS.

74

3.4.3

An Implementation of RTP Flow Detection

A first implementation was done in the ACTS IthACI project and is based on NEC’s IPSOFACTO IP-switching architecture. 3.4.3.1

IPSOFACTO and IthACI

ΔΕ ΙΓ Μ

Α

ACTS IthACI is a third call ACTS project focusing on MPLS evolution and multimedia extensions for IP-switching. The overall scope of this project is to evaluate and contribute to the different technologies that permit the evolution of circuit-switched to ATM-based networks and thus the efficient transport of IP traffic over an ATM backbone infrastructure (either private or public). The project investigates and enhances schemes for the efficient integration of IP and ATM network technologies suitable not only for traditional data, but also for multimedia applications. The project concentrates on Layer 2 forwarding methods for IP flows using different IP switching architectures as deployed by the IETF within the Multi-Protocol Label Switching (MPLS) working group. In this context, the project addresses the requirements for efficient IP multicasting over ATM, accommodating QoS demands, mobility and resource control. NEC’s IPSOFACTO is a soft-state, traffic-driven IP switching technique where each switchrouter decides independently when to create a shortcut path. It uses the ATM switch as a fast cell forwarding machine, and the GSMP version 1.1 [7] interface to control the switch hardware and to specify priorities for specific VCs. The IPSOFACTO prototype is based on the NEC ATOMIS 5SE ATM switch. A Linux PC acts both as traditional IP router and as the switch controller performing flow detection, deciding about shortcut establishment, etc. (see Figure 3).

Figure 3: IPSOFACTO switch-router

75

Originally IPSOFACTO did only IP switching using information in the TCP and UDP headers. Switched paths for flows were established depending on the transport protocol, source and destination addresses, and source and destination ports. The IPSOFACTO prototype was changed to implement layer 4+ switching, which means to use additional information from the transport protocol’s payload to further distinguish between different flows. IPSOFACTO now supports RTP flow detection for native IP multicast over MPLS as proposed by NEC to the IETF [2,3]. RTP multicast flows are dedicated to ATM point-tomultipoint VCs with the highest GSMP priority. The GSMP priority corresponds to the ATM ‘class of service’ queue in the ATM hardware and thus the best-effort traffic (UBR queue) is discriminated from the RTP traffic (CBR queue). 3.4.3.2

RTP Detection Implementation

ΔΕ ΙΓ Μ

Α

RTP application flows can be treated individually with RTP flow detection. By the discrimination of flows, certain flows and their respective applications will receive preferred treatment and thus higher transmission quality than others. The implementation of RTP flow detection and switching consists of the following five steps: • Check whether the protocol on top of IP is UDP. This step is easy to implement since it only requires looking up the protocol number in the IP header. • Check whether the protocol on top of UDP is RTP. In this step the data header validity check according to [5] must be performed on the payload of the UDP packet. This basically consists of looking up several values at given locations within the RTP header, to check whether they are within a given range, and to verify a checksum. • Derive information about the RTP flow. After the packet is identified as a RTP packet, this step extracts information about the type of flow detected. • Establish the flow switching. This means to instruct the layer 4+ switch to establish some kind of flow switching. This has to be done based on, at least, the source and destination addresses that can be derived from the IP packet header. The flow switching may also include port numbers or can be based on flow labels as for example those in IPv6. • Assignment of flows to priority or service classes. This step consists in the consultation of a table, which maps different types of flows to priority or service classes. The switch is instructed to set the switched flow’s priority to the appropriate value. The RTP flow detection implementation is integrated in the IPSOFACTO LCATM (Label-Switch Controlled ATM) multicast-forwarding path. The first multicast packet of a new flow is received at the IP switch-router and handed over to the IP multicast module where the lookup of the forwarding information in the PIM daemon is done and where the multicast forwarding cache is updated. Then the packet is checked in the RTP flow detection module whether it contains RTP data. After the packet is forwarded normally, the switch-router sets up a switched path for the new flow and gives it the priority returned by the RTP detection module.

76

ΔΕ ΙΓ Μ

Α

All following packets of this flow are then switched in Layer 2, not routed (Layer 3). When a new packet is received and no MFC entry exists, the kernel asks the multicast routing daemon about the route to assign to this packet. When the kernel receives the daemon reply, a new MFC entry is created and subsequent packets will be forwarded without any request to the daemon. The LCATM IP Multicast support provides an MPLS extension of the MFC: some “hooks” are introduced in the IP multicast path to store the Multicast Label Information Base (LIB). The LIB entry contains mainly the IP multicast flow parameters (IP source address, group address), some statistics provided by GSMP, the input/output ports and VPI/VCI and the GSMP priority as CoS indicator. When a new MFC entry is created, the hook “pre_forward” is called to create a new LIB entry: the RTP flow detection is applied to set-up the CoS indicator as described in the previous section. In the downstream mode, the packet is then forwarded on the routed path to all the next hops and a hook “post_forward” is called afterwards to send a message to the upstream node indicating which VPI/VCI to use for the corresponding (S, G) traffic. The protocol used is the minimal LDP implementation called LDPLite. When the kernel receives a LDPLite Mapping message containing an outgoing label for an outgoing port (a branch of the MFC entry in the router), a branch is added to the corresponding ATM point-to-multipoint VC on the ATM switch. The subsequent packets will be switched in the hardware. Note that this implementation is flexible enough to support simultaneous Layer 2 and Layer 3 IP multicast forwarding, as defined in [3]. 3.4.3.3

QoS Provisioning

The IPSOFACTO LCATM assigns RTP multicast flows to dedicated ATM point-to-multipoint VCs with the highest GSMP priority. The GSMP priority corresponds to the ATM class of service queue in the ATM hardware and thus the LCATM discriminates the best-effort traffic (UBR queue) from the RTP traffic (CBR queue). It is easily possible to further discriminate between RTP flows depending on their payload type. 3.4.3.4

Performance Issues

With the presented RTP flow detection algorithm and implementation, RTP flows are identified on IP switch-routers with a very high probability. If some RTP flow is not detected it is probably because of a payload type unknown to the switch-router which, in our case, only looks for payload types defined in [6]. Also, our implementation only looks for RTP within UDP packets. On core switch-routers, more overhead is introduced for the first packet of a new flow due to the traffic-driven approach and the additional checking of the packet’s payload for RTP data. The following packets then are switched at Layer 2 and there is no processing in the router.

77

3.4.4

Conclusion

Α

At edge routers, flow detection has to be done for EVERY packet in order to sort them into the correct switched path with the appropriate QoS parameters (LSP/VC). Optimizations to this added processing overhead at the router are possible: If it is safe to look only at the address and port information in the packet after a flow is detected, then only every nth (n>1) packet needs to be examined for RTP content. Not doing a full check increases the risk to give some packets inappropriate QoS when e.g. the RTP payload type of the flow changes. For the performance of a network with RTP flow detection it is important how the special QoS for such flows looks like. As an investigation at the University of Braunschweig shows, UDP traffic may easily supersede TCP traffic. Assigning RTP traffic a certain amount of bandwidth and priority ensures that those flows can travel with an ensured transmission quality. At the same time it is made sure that e.g. Web traffic can travel undisturbed.

ΔΕ ΙΓ Μ

RTP flow detection is implemented in IPSOFACTO on the NEC Atomis 5SE ATM switch with a Linux machine as switch-router. RTP traffic can be detected with a very high probability. However, it happens that traffic is mistaken for RTP when the first bytes of a packet’s payload and its length accidentally match the parameters that are tested in the header validity check. The impact of those errors on managing QoS in the network has to be studied further. Information from flow detection may be used to support reservation and/or packet classification in Integrated or Differentiated Services inter-nets. Layer 4+ information extracted from RTP and other protocols as, for example, HTTP (see also [1]) can be used for various applications like flow aggregation, reservation, and prioritization. First, this mechanism can be applied to do packet classification for Differentiated Services, i.e. to support the Class of Service model for multimedia traffic. Further, flow aggregation may be used to bundle several flows into one ATM VC or similar (e.g. a couple of low traffic connections, or traffic of the same type). Another usage of flow based layer 4 information can be bandwidth reservation. One obvious application is to reserve bandwidth for audio and video connections and to automatically route all audio and video traffic from a particular source through this reserved connection. Another application is to reserve bandwidth for dedicated client-server pairs and protocols.

References [1]

[2] [3] [4]

78

T. Harbaum et.al, Layer 4+ Switching with QoS support, paper accepted at GLOBECOM’99. A. Acharya et.al, IP Multicast Support in MPLS Networks, IETF Internet-draft draftacharya-ipsofacto-mpls-mcast-00.txt; work in progress, August 1999. D. Ooms et.al, Framework for IP Multicast in MPLS, IETF Internet-draft draft-ietf-mplsmcast-00.txt; work in progress, June 1999. J. Reynolds, J. Postel, Assigned Numbers, RFC 1700, IETF, October 1994.

[5] [6] [7]

ΔΕ ΙΓ Μ

Α

[8]

H. Schulzrinne et al. RTP: A Transport Protocol for Real-Time Applications. RFC 1889, IETF, January 1996. H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, Request for Comments 1890, IETF, January 1996. P. Newman et al., Ipsilon’s General Switch Management Protocol Specification Version1.1, RFC 1987, August 1996. Rosenberg, et al, “Elevating RTP to Protocol Status”, work in progress, draft-rosenbergrtpproto-00.txt, March 1998.

79

3.5

PETERPAN: Integration of IP and ATM for QoS and Multimedia Services Support

Α

Nikos A. Nikolaou. National Technical University of Athens (NTUA), Athens, Greece. G. Rigolio. Italtel S.p.A., Milan, Italy. A. Casaca. INESC, Lisboa, Portugal. N. Ciulli. University of Pisa, Pisa, Italy. G. Stassinopoulos. NTUA, Athens, Greece.

ΔΕ ΙΓ Μ

A considerable increase in the traffic volume is expected, as multimedia applications are becoming more common. Current networks consist of different technologies (e.g. IP and ATM), where multiple types of traffic coexist, including pure ATM, Best Effort IP and IP requiring coarse or strict Quality of Service (QoS)guarantees. As a result, the issue of supporting QoS over contemporary networks is very critical. Within this framework the PETERPAN Project has defined and developed a Network Concept that is based on hybrid IP-ATM nodes. At the edge of the network a Hybrid Edge Device (HED) is defined, serving as an access element, while a Hybrid Core Device (HCD) is utilised for the core network. Both of them exploit standard ATM features and, at the same time, they support approaches currently proposed by IETF (IntServ and DiffServ). Their hybrid functionality provides a solution for offering end-to-end QoS for the prevailing class of IP services. In order to provide QoS-support to an application, two complementary directions have been followed. More particularly, an RSVP Management Module (RMM) has been implemented, capable of establishing reservations on behalf of RSVP-unaware applications. On the other hand, two resource demanding applications, namely Interactive Multimedia Retrieval (IMR) and Video Telephone (VT), have been enhanced with RSVP functionality, by introducing a generalised QoS Middle-Ware. Having materialised the PETERPAN platform, the Project advances itself with experimental activities, carried out in five different trial islands. In this paper, some of the initial results are reported, showing the effectiveness of the adopted solution. 3.5.1

Introduction

When the diffusion of multimedia applications, offered over the Internet, receives the expected acceptance and popularity by end-users, a growth in the traffic volume and an alteration in the traffic characteristics will come as a natural consequence. This will push

80

ΔΕ ΙΓ Μ

Α

the demand for a faster and effective backbone and, more interestingly, will modify the service requirements on the network by introducing the need for Quality of Service (QoS). Thus, resource partitioning, e.g. through bandwidth reservation, will progressively assume relevance. The trend in network evolution is not toward a global environment, such as the one developed in the past for the Plain Old Telephony System (POTS). Rather, it seeks for a galaxy of Internet Service Providers (ISPs), moving to offer IP services of some kind. Multiple network technologies and services with varying characteristics are the dominant principles of this evolution, where the coexistence of multiple types of traffic, including pure ATM, Best Effort IP and IP requiring coarse or strict QoS guarantees, is inevitable. The Network Concept, developed within the framework of the PETERPAN Project [1], is based on hybrid IP-ATM nodes, both at the edge and in the core network. It provides flexibility and accommodates the contemporary adoption of the Integrated Service (IntServ) beside Differentiated Service (DiffServ) in the core network. In fact, the Project sees the advantage for the IntServ approach to actually guarantee the resource reservation, worth for very demanding services. On the other hand, the DiffServ approach only offers a qualitative and coarser QoS support, which might not be enough for many QoS sensitive applications. However, less demanding applications can benefit from the DiffServ model, which in counterpart offers undoubtedly the advantage of easier scalability. The co-existence of IP and ATM is an inherent characteristic of the adopted Network Concept. This is evident in both the Hybrid Edge Device (HED), which acts as a network access element, and the Hybrid Core Device (HCD), which resides in the core network. The HED and HCD are innovative network devices that materialise the convergence of IP and ATM, with the objective of continuous QoS support, inside the access and core network. They exploit standard features already available by ATM and, at the same time, they support approaches currently proposed by IETF (IntServ [2] and DiffServ [3]). Their hybrid nature and functionality provide an enabling technology for offering end-to-end QoS for the prevailing class of IP services. To justify the adopted Network Concept, field trials with realistic, end-to-end, resourcedemanding applications have to be performed. The Project has followed two different directions, motivated by the observation that most of the existing IP-based applications will not be upgraded with the functionality of the Resource Reservation Protocol (RSVP). Thus, an RSVP Management Module (RMM) has been developed, capable of establishing reservations on behalf of RSVP-unaware applications, in an automatic fashion. In this manner, applications that do not inherently support a mechanism for obtaining QoS— although, they would benefit from network resource reservations—can take advantage of this service. The second direction suggests the modification of resource-demanding services, such as Interactive Multimedia Retrieval (IMR) and Video Telephone (VT), with a QoS MiddleWare, which provides support for QoS in a generalised and extendable manner and can accommodate, apart from RSVP [4, 5], other signalling protocols (e.g. Q.2931).

81

3.5.2

Α

Having materialised the Network Concept, the Project advances itself with the evaluation of the results. The outcome of the experiments is expected to validate the architectural directions and the implementation solutions adopted by the Project. At the same time, experience gained during implementation activities, which range from user to kernel level and include various operating environments, can be of significant importance to similar attempts, towards the integration of IP and ATM. In order to test the functionality of the new network devices and applications, various strategies and scenarios have been selected and performed. In return, they can provide useful guidelines on how to perform tests in a hybrid IP/ATM environment. This paper presents a network architecture that integrates ATM and IP with the objective to provide QoS support for multimedia applications. More particularly, in Section 3.5.2 the adopted Network Concept is presented. Section 3.5.3 deals with issues regarding services and applications, while, in Section 3.5.4 some results are presented from the field trials. Finally, conclusions are summarised in Section 3.5.5.

PETERPAN Network Concept

ΔΕ ΙΓ Μ

Currently, various standardisation bodies and international forums are putting considerable effort to specify mechanisms that will provide a sufficient level of QoS to resource demanding applications. Towards this direction, network devices are going to be re-organised and supplied with enhanced functionality, without compromising compatibility with existing technology and network scalability. It is well understood that ATM has been designed with intrinsic characteristics of scalability and reliability, with the objective of providing a common network infrastructure for broadband applications. The effort carried within the framework of the PETERPAN project is to exploit the intrinsic scalability of ATM in supporting the IETF’s IntServ approach. In addition to RSVP/IntServ [6, 7], currently the DiffServ approach is very popular within the IETF. The DiffServ solution [8, 9] is simpler, because it removes the concept of associating resource reservation to singular flows (as is the case of IntServ by means of the RSVP signalling protocol). Moreover, it eliminates the need to maintain soft-states within the intermediate nodes to record the resource assignation to flows; thus, no per-flow signalling or state information is required. This is deemed relevant, especially in the core of the network, where the number of flows each router has to handle might eventually reach high figures indeed. Although, applications with low and medium resource requirements can benefit from the DiffServ model, the QoS support that is feasible with the DiffServ approach might not be adequate for many QoS sensitive applications. In conclusion, DiffServ only offers a coarse QoS support, while IntServ, despite its complexity and the need for signalling and states, is undoubtedly superior, as far as the QoS guarantees are concerned. Thus, more recently, approaches combining an RSVP capability in the peripheral/access segments with DiffServ in the backbone have been proposed, to optimally compromise effective QoS support with scalability of the solution.

82

3.5.2.1

Hybrid Network Devices

ΔΕ ΙΓ Μ

Α

Any network of a relevant dimension is, normally, structured in an edge and a core backbone. Within the PETERPAN project, the Network Concept [10, 11] that has been developed is based on IP-ATM Hybrid Devices, both in the edge and in the core, as presented in Figure 1. Two special types of nodes have been identified, referred as Hybrid Edge Device (HED) and Hybrid Core Device (HCD). These are innovative network elements that are able to operate as plain ATM switches, for handling pure ATM traffic. Additionally, they can be used as pure IP routers, in a full IP perspective. Hybrid Devices allow the QoS differentiation between IP flows requiring some kind of guarantees (via the RSVP protocol) and the Best Effort flows. Also, they can support pure ATM connections for non-IP traffic; network resources need not be strictly separated and can, consequently, be better utilised. Moreover, Hybrid Devices can take locally optimal decisions about how to support IP flows requiring guarantees. Thus, none or little co-ordination between nodes is required. HED and HCD have, partially, common functionality, as both are capable of mapping RSVP messages to B-ISDN signalling messages, mapping RSVP parameters into ATM traffic classes and associated ATM traffic descriptor and performing IP filtering, classification and scheduling, as well as IP/ATM address resolution. Additionally, the HCD aggregates separate RSVP flows onto the same ATM connection, to ensure scalability, and performs short-cut connections at the ATM level. The role of the HED is to present traffic originating from edge networks to the core

Figure 1: PETERPAN Network Concept

83

ΔΕ ΙΓ Μ

Α

network and vice-versa. Moving from the border towards the core of the network, the node after the HED may be a HCD or a plain ATM switch. In case of being an ATM switch, ATM cells are switched to the HCD along the VPC/VCC which connects the HED with the HCD and, obviously, no IP level functionality is here possible. In complex networks, multiple paths across several HCDs can exist to connect any couple of ingress/egress ports. It can even be possible that all the nodes of a network are HCDs, and no pure ATM node exists. Nevertheless, in such a network end-to-end, pure ATM connections are also possible, exploiting the ATM switching capability of the Hybrid Devices. From the IP perspective, within the network, the Hybrid Device is the “next hop router” to which any (hybrid) router forwards its traffic according to the regular IP routing rules. In addition, within the backbone, a technique for aggregating several QoS-IP flows into dedicated ATM connections can be adopted, to favour scalability of the solution, while guaranteeing protection for mission critical traffic. It is worth mentioning that the presence of Hybrid Devices allows a great simplification in the traffic control functional architecture. In particular, it is possible to avoid any “replication” of similar functionality (e.g. support of priority) at the ATM and at the IP level, which is not possible when completely separate devices handle the two layers. Accordingly, the Network Concept developed by the Project is flexible enough to accommodate the adoption of DiffServ in the core network. The HCD design, in particular, has been carried out with attention to leave “hooks” to a dual mode operation. Therefore, it can be configured for use as an IntServ capable node, with capability to process RSVP messages and to correlate RSVP requests to ATM signalling. Additionally, it can also be used as a DiffServ capable node, where packet handling, in terms of QoS, depends directly on information contained in the IP packet header (Differentiated Services Code Point-DSCP [8], in DiffServ terminology). As a result, the PETERPAN Network Concept can be adjusted to service a mixed solution. More particularly, it can offer a Guaranteed Service [12] (like in the IntServ approach) using the RSVP protocol for resource reservation, for those applications/flows that are very sensitive in network resources. Alternatively, for less demanding applications (e.g. like those that can be served by Controlled Load [13] in the pure RSVP solution), the IntServ at the edge and the DiffServ at the core approach can be activated. 3.5.3

Applications and Services

In order for the Project to evaluate the effectiveness of the adopted Network Concept, resource-demanding applications that utilise the RSVP protocol for obtaining QoS, must be exercised over the trial platform. Although there are numerous resource-demanding applications, none of them was RSVP-aware. The same stands for other, less demanding applications, which could also benefit from the application of RSVP. Motivated by the aforementioned observations and knowing that it is impossible to modify all of the existing applications with RSVP, two different directions have been followed.

84

3.5.3.1

RSVP Manager Module—RMM

Α

The first one involves the specification and development of an RSVP Management Module (RMM) [14], which has the appropriate functionality to establish reservations on behalf of RSVP-unaware applications, in an automatic fashion. This approach presents an independent service/tool that can be used to enhance the performance of legacy applications, without modifying their code. The focal point of the second direction was the specification and development of a QoS Midle-Ware [15], which provides to applications a generalised interface for obtaining QoS. Such a middle-ware offers the possibility of incorporating, under the same interface other signalling protocols in addition to RSVP. Utilising this module, two resource demanding applications have been developed, namely, the Interactive Multimedia Retrieval (IMR) and Video Telephone (VT) [14].

ΔΕ ΙΓ Μ

RMM is an application-level tool that intends to provide QoS support to applications that are not aware of the RSVP protocol. The RMM tool primarily consists of three modules (as shown in Figure 2): the Graphical User Interface (GUI), which provides all the necessary interaction with the user; the Automatic TSpec Retrieval (ATR) module, which automatically determines the TSpec parameters of a specific IP flow; the RSVP QoS module, which interacts with the RSVP daemon. RMM has two operative modes: “testing” and “support”. The former is intended to offer the user a complete handling of the RSVP signalling, whereas the latter is the main RMM task: provides the non-QoS-aware applications with an interface to the RSVP signalling, through a user-friendly tool (that is, requiring from the user a minimal knowledge of QoS mechanisms and needs of the applications). In both modes, RMM allows the user to open and close RSVP sessions, as well as specify their parameters (TSpec, RSpec, reservation style and filterspecs). In order to create a new RSVP session, the user must specify the transport

Figure 2: RSVP Management Module

85

protocol and the destination IP address and port. All the events related to the RSVP functionality are reported to the user. As far as the ATR module is concerned it is responsible for estimating the TSpec parameters of particular IP flows. The filtering of the flows is achieved using the libpcap library, which provides an interface for user-level packet capture. The ATR module uses the information returned by the libpcap library to calculate all the TSpec parameters. Finally, the RSVP QoS Module receives input from the GUI and, in those cases where the automatic TSpec retrieval is active, from the ATR module, too. Based on that input, it manipulates RSVP sessions—creates, deletes or modifies their parameters. 3.5.3.2

QoS Middle-Ware

ΔΕ ΙΓ Μ

Α

The major purpose of the QoS Middle-Ware is to render applications independent from the underlying reservation protocol. That is to say the application should not be bound to a specific reservation protocol, but it is more preferable to use a uniform interface to access any of the different reservation mechanisms. To achieve this, a new software module is required that will take the role of an umbrella, under which a number of different reservation mechanisms can be placed. Thus, the QoS Middle-Ware provides a generalised interface for reservations and is placed between the application and the specific reservation protocol. The QoS Middle-Ware is organised in two successive layers, as shown in Figure 3. The bottom layer, which is called Specialised QoS Module, embodies all the functionality to interact efficiently with a specific reservation protocol. The upper layer, which is called Generic QoS Module, provides to applications a uniform and stable interface for making and maintaining reservations. At the same time, it interfaces with the Specialised QoS Module, in order to activate the particular resource reservation mechanism. The Generic QoS Module provides to applications a uniform Application Programming Interface (API), consisting of operations that can be used to establish, release and modify reservations. The result of an operation, successful or not, is returned to the application by means of asynchronous events. The Specialised QoS Module that is based on RSVP embodies all the functionality to interact with the RSVP protocol. The actual implementation of the operations supported by Generic QoS Module takes place inside the Specialised QoS Module. Additionally, all the events related with the RSVP are mapped to the events supported by the Generic QoS Module. On top of the QoS Middle-Ware two applications have been built, namely the Interactive Multimedia Retrieval and the VideoTelephone. IMR is a client/server application that enables the selection and transfer of MPEG video, over a network. MPEG streams are stored on the server side and decoded on the client side, using specialised hardware. VT is a point-to-point, videophone service that handles audio and video separately, using for their compression software modules. Both applications are able to reserve network resources, utilising the operations of the QoS Middle-Ware. The reservation mechanism that is used is the one defined by RSVP.

86

Α

ΔΕ ΙΓ Μ

Figure 3: QoS Middle-Ware

3.5.4

Experiments and Results

To justify the Network Concept adopted by the Project, as well as the implementation decisions taken during the materialisation phase, field trials [16] with realistic, end-to-end, resource-demanding applications have to be performed. For that reason an experimental platform has been carefully established, consisting of a number of islands, located in different countries. The Project Network Concept and “philosophy” are pursued within all the islands, while, at the same time, each one emphasises on specific aspects. In some of the islands, real users are involved in the experiments, whilst elsewhere only laboratory experiments are carried on. The island platforms include network elements produced within the project (HED and/or HCD), surrounded by commercial equipment (routers, ATM nodes, hubs, workstations and PCs). All these are integrated with user-side hosts, running QoS sensitive and RSVP capable applications, which are either produced by the project or are available from previous activity or commercially. The major objective of the experimentation phase is to validate the project development and verify the compatibility and interoperability of the adopted solutions with products that are already available in the market. It is expected that useful conclusions will be inferred from the experiments, referring to possible limitations and benefits when the adopted solutions are applied to a real networking environment.

87

Α

ΔΕ ΙΓ Μ

Figure 4: Trial Islands

3.5.4.1

Trial Islands

The trial islands that have been established are located in different countries, including Italy (Milan and Pisa), United Kingdom (Lancaster), Portugal (Lisbon) and USA (Los Angeles), as shown in Figure 4. In each island specific experiments are performed. More particularly, the focus in the Milan experiment is the evaluation of a prototype HCD, embedded in a rich IP-ATM platform, which includes commercial and project developed network elements and applications. Special attention is given to: • Mapping of RSVP messages to B-ISDN signalling messages. • Mapping of RSVP RESV traffic parameters to ATM Traffic Classes and associated Traffic Parameters. • Performing efficient IP forwarding in a hybrid IP-ATM node. • Utilising IP trunking and short-cut functionality. Within the trial island of Pisa, experiments are concentrated on traffic measurements, at both IP and ATM levels, with specific interest to: • QoS mapping between IP and ATM, for network resource sensitive applications (Telemedicine). • Characterisation and evaluation of alternate HED queuing disciplines. As far as the trial island in Lancaster is concerned, the focal points are: • Comparison of IPv6 and IPv4 over ATM for QoS support. • Provision of QoS utilising IPv6 and RSVP over ATM.

88

Within the Lisbon trial, special attention is given to: • Scheduling of packets in the IP level. • Mapping of RSVP to ATM signalling. Finally, at UCLA focus is given on advanced algorithms for QoS routing. 3.5.4.2

Results

ΔΕ ΙΓ Μ

Α

As the work within the trial islands progresses, results are being produced and carefully studied to formulate conclusions. A brief summary of the current status of the experiments is presented in Table 1 and further analysed in the following paragraphs. In an environment where all the nodes support the RSVP protocol, protection of precious flows is effective (far less degradation with respect to Best Effort flows) on both ATM and Ethernet type links. In a mixed environment, where RSVP and non-RSVP capable nodes exist, uncontrolled flows can overload the network and cause noticeable degradation of quality in the Ethernet links. However, this is not the case in the ATM links, where, with adequate signalling, the necessary protection for the controlled flows is provided. Over Ethernet links, differences are appreciable only if the link is loaded at 60% or above, but the protection decreases as the load approaches the 100% load condition. Obviously, in low loading case (for example, below 50% of channel capacity), even in a fully shared media, like Ethernet, no protection mechanism is strictly needed to protect precious traffic, provided that the link bandwidth is sensibly higher than what the applications require. When dealing with an Ethernet interface, we need to apply an efficient scheduler, so as to achieve low delays and no (or small) packet loss for flows demanding QoS. An interesting point is that when building RSVP-aware applications we must take into consideration that IP packets must not be fragmented. This is a mandatory prerequisite that is explicitly stated in [4]. However, not many of the existing applications are able to fulfil this restriction, which implies code modifications. As an alternative, changes could be introduced inside the RSVP to make it capable of handling fragmented IP packets. Nevertheless, they demand more resources and cause delays in the packet forwarding at the routers. Experiments with the IMR application have shown that the average delay of a fragmented flow, carrying an MPEG-I stream, was between 6000 and 29000 ms, depending on the network load. Incorporating a mechanism, inside the IMR application, that avoids fragmentation of IP packets, a considerable decrease has been observed, resulting in an average delay which was about 100 times less than the one measured in the fragmented scenario. In case of IP fragmentation, the delay is mainly introduced because packets have to be reassembled before classification, at the transport layer, can take place. Using the IMR application to watch an MPEG movie, the user realises distortion in the video and audio quality when the network load increases and the Best Effort service is utilised. Advancing the service class of the IMR flows to Guaranteed service, no distortion is observed, even under increased network load. This proves that the utilisation of the RSVP

89

Table 1: Summary of Results

Topic

Result

RSVP capable network.

Precious flows can be protected (ATM and Ethernet links). Precious flows can be protected only on ATM links.

When differences are appreciable.

The (Ethernet) link is loaded at 60% or above.

Requirement for Ethernet interfaces.

Efficient schedulers.

RSVP-aware application.

IP packets must not be fragmented.

IMR and un-fragmented IP packets.

The average delay of an IP flow carrying an MPEG-I stream is considerably low, compared with the results of the fragmented scenario. MPEG flows are protected and no distortion is observed in the video/audio quality, when network load increases.

ΔΕ ΙΓ Μ

IMR over the PETERPAN platform.

Α

RSVP semi-capable network.

Interoperability of PETERPAN solution.

Effective only on ATM links. Requires enhanced ATM interfaces.

RSVP and MPEG-I streams.

Small degradation noticed when network load reaches 90%.

IPv4 vs IPv6: packet classification latency. When the Flow Label field is used, the IPv6 results in less latency. Otherwise, negligible difference has been observed.

90

IPv4 vs IPv6: end-to-end packet latency.

IPv6 results in slightly higher latency. However, when the Flow Label field is used for classification, then IPv6 results in substantially less latency.

IPv4 vs IPv6: HED throughput.

It is similar for both cases. When the Flow Label field is used for classification, then IPv6 results in slight improvement.

QoS routing.

Bellman-Ford algorithm is more effective than traditional approaches, when 2 routing metrics – bandwidth and delay – are used.

ΔΕ ΙΓ Μ

Α

within a resource demanding application, running over the PETERPAN platform, is fully protected. It has been proven from the experiments that interoperability of the PETERPAN solution with commercial equipment (e.g. Cisco routers, ATM switches and Sun’s implementation of RSVP) is always possible. However, interoperability is effective only on ATM links and while enhanced ATM interfaces are present. Such ATM interfaces must exploit the QoS interworking between RSVP and ATM and shape the traffic correctly. These features are made available on Cisco routers with the latest generations of ATM interfaces, while first releases, which have low shaping and control capability, are not able to create dedicated connections and enforce traffic profiles. A significant benefit that arises from the PETERPAN Network Concept is the protection of MPEG-I flows with respect to competing flows and the overall network load. In case of the Best Effort scenario, QoS degradation of the MPEG-I streams is proportional to the amount of competing traffic. With the PETERPAN scenario, small degradation is noticed only once the network load reaches 90%. This is due to collisions on the Ethernet segments, while ATM links show perfect protection of precious flows. A significant part of the experiments are related to on how IPv4 and IPv6 behave within an RSVP-capable environment. More particularly, tests regarding the latency of packetclassification for IPv4 and IPv6 flows (protected by RSVP) have shown negligible difference. However, when for the packet classification of IPv6 flows the Flow Label field [17] of the IP header is used, then noticeably lower classification latency times have been produced. Regarding the end-to-end packet latency it has been observed that it is slightly higher for IPv6 (RSVP protected) flows than for IPv4—regardless of the packet size. IPv6 flows that are using the Flow Label for the classification exhibit the lowest end-to-end packet latency. Experiments on the throughput of the HEDs have shown that is similar for both IPv4 and IPv6 flows protected by RSVP. A slight improvement was noticed for IPv6 flows, when the Flow Label classification was activated. As far as QoS routing is concerned, the simulation study has confirmed the effectiveness of the Bellman-Ford algorithm with respect to traditional approaches, when 2 routing metrics —bandwidth and delay—are taken into account. The study is progressing in investigating the effectiveness of modifying the time period between refresh of routing information among stations. 3.5.5

Conclusions

As multimedia applications become more common, the issue of providing QoS will receive considerable attention. Considering that ATM and IP are two widespread technologies, within contemporary networks and are, currently, featured with mechanisms for supporting QoS, it seems very challenging and promising to integrate them under the same platform. Towards this direction, PETERPAN has specified, implemented and is, currently, experimenting a platform, where IntServ and ATM coexist, allowing hooks for the DiffServ approach.

91

ΔΕ ΙΓ Μ

Α

It is almost evident the advantage of the IntServ/ RSVP against the DiffServ approach, to actually guarantee the resource reservation. This feature is deemed so important that the attempts to overcome the scalability difficulties are worth to be addressed, trying to minimise their impact on the network elements complexity. Although the Network Concept developed by PETERPAN can accommodate DiffServ, the implementations and experimentation were concentrated on the IntServ/RSVP approach, which is not extensively considered and still has a number of open points (e.g. actual scalability) worth to be covered. PETERPAN has followed two complementary approaches for providing QoS support to an application: either using the RMM signalling tool or introducing RSVP functionality inside the application. In this manner a range of applications with varying QoS requirements can take advantage of the PETERPAN solution and be tested over the experimental platform. It must be noted that experimental activities, within the various trial islands, are still running, and more results are expected to further refine the knowledge that has been acquired. In addition, more indications are to be collected on different topics, like: • How effective is the trunking operation in the HCD, both as far as data traffic performance is concerned and in terms of control plane resource consumption. • How effectiveness is the short cut functionality in the HCD. • Traffic characterisation.

Acknowledgements

This work was performed in the framework of ACTS project PETERPAN [1] (Provision of an Enhanced Transport by Exploiting Reservation in iP and Atm Networks—AC307). The authors wish to express their gratitude to the other members of the PETERPAN Consortium (CSELT, University of Lancaster, UCLA and Hewlett Packard UK) for valuable discussions.

References [1]

[2] [3] [4] [5] [6] [7]

92

ACTS PETERPAN—Provision of an Enhanced Transport by Exploiting Reservation in IP and ATM Networks, AC307, URL: http://peterpan.lancs.ac.uk/peterpan/ Integrated Services (IntServ), URL: http://www.ietf.org/html.charters/intservcharter.html. Differentiated Services (DiffServ), URL: http://www.ietf.org/html.charters/diffservcharter.html. R. Braden, L. Zhang, S. Berson, S. Herzog and S. Jamin: “Resource ReSerVation Protocol (RSVP)—Version1 Functional Specification”, RFC 2205, September 1997. Lixia Zhang, Steve Deering, Deborah Estrin, Scott Shenker and Daniel Zappala: “RSVP: A New Resource ReSerVation Protocol”, IEEE Network Magazine, September 1993. J. Wroclaski: “The Use of RSVP with IETF Integrated Services”, RFC 2210, September 1997. Paul P. White: “RSVP and Integrated Services in the Internet: A Tutorial”, IEEE Communications Magazine, May 1997.

[9] [10] [11] [12] [13] [14]

ΔΕ ΙΓ Μ

[15]

K. Nichols, S. Blake, F. Baker and D. Black: “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, December 1998. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang and W. Weiss: “An Architecture for Differentiated Services”, RFC 2475, December 1998. PETERPAN consortium, Deliverable D01: “Interim Architecture Definition and Platform Specification”, AC307/ITL/WP11/DS/L/001/b1, May 1998. PETERPAN consortium, Deliverable D02: “Architecture Definition and Platform Specification”, AC307/ITL/WP11/DS/L/002/b1, September 1998. S. Shenker and C. Partridge: “Specification of Guaranteed Quality of Service”, RFC 2212, September 1997. J. Wroclaski: “Specification of the Controlled-Load Network Element Service”, RFC 2211, September 1997. PETERPAN consortium, Deliverable D08: “QoS Aware Applications over Trial Platform”, AC307/NTUA/WP23/DS/R/008/b1, July 1999. Nikos A. Nikolaou, Charilaos A. Tsetsekas, Iakovos S. Venieris: “A QoS Middle-Ware for Network Adaptive Applications”, IEEE Multimedia Systems’99, International Conference on Multimedia Computing and Systems, June 7-11, 1999, Centro Affari, Florence, Italy. PETERPAN consortium, Deliverable D07: “Initial Trial Platform Integration Report”, AC307/INESC/WP31/DS/P/007/b1, February 1999. S. Deering and R. Hinden: “Internet Protocol, Version 6 (IPv6) Specification”, RFC 1883, December 1995.

Α

[8]

[16] [17]

93

3.6

SUSIE: Project Objectives and Relationship to Next Generation Internet

Kevin O’Leary Teltec Ireland

ΔΕ ΙΓ Μ

Α

The Next Generation Internet will offer a huge range of new value-added services to consumers. Service providers will generate revenue from these services with novel charging methods that are a significant departure from the straightforward flat-rate approach used in current services like PSTN, mobile or Internet access, with a move towards some form of usage-based charging. Additional charging complexities will be introduced when customers can opt for varying degrees of preferential treatment for their traffic—a radical change from the current best-effort Internet model, where all traffic has equal priority, and therefore the same charge. The SUSIE project developed a charging approach for the next generation Internet. The project has explored three approaches for providing Premium IP Services (i.e. those that have been enhanced with Quality of Service). Emerging service models based on Integrated Services, Differentiated Services and MPLS were addressed. The SUSIE charging approach includes the development of a charging reference model, the design of charging algorithms for various Premium IP services, and the design, implementation and testing of systems for metering, accounting and charging. 3.6.1

Reference Model and Business Model

It is useful to briefly review the SUSIE charging reference model to better understand the trial scenario.

94

Figure 1: SUSIE

Charging Reference Model

ΔΕ ΙΓ Μ

Α

SUSIE investigated usage-based charging, and the metering layer performs the function of measuring the amount of resources used. This measurement is forwarded via a reader layer to the accounting layer, where usage information is consolidated into accounting data records. (The project has proposed standardised records for Integrated Services, Differentiated Services and MPLS). In a multi-provider environment, this layer is responsible for distributing collected usage data to other domains. Once the charging layer receives the accounting records, the appropriate tariffs can be applied, and a price assigned for the service. The billing layer collates all charges in a bill to be sent to the customer. Note that all layers can be configured from a set of policies. The project addressed one very general type of business model, where retail IP services with QoS are provided directly to the customer, with the retailer purchasing wholesale services from another provider. In the SUSIE project, the wholesaler is assumed to sell ATM services, though the SUSIE charging approach is also applicable to wholesale services implemented using Differentiated Services or MPLS. This business model mandated the development of metering, accounting and charging systems for both ATM and IP, as well as a technique for combining both charges into a consolidated bill for the customer. 3.6.2

Field Trial Architecture

The principal field trial goal of the project was to provide a premium service to a community of real users, and then to validate the various metering, accounting and charging prototypes developed by the consortium, using this example service. A schools user group was identified for this purpose. Participant schools from Ireland, Germany, Switzerland and Canada were equipped with video-conferencing hardware and software to use in a Virtual Classroom environment. The year-long experiment included ongoing contact between teachers and students at the different schools, interspersed with a series of video-conference sessions. A virtual learning environment of this kind is typical of the services that the next generation Internet will offer. Quality of Service was provided by organising dedicated connections between the schools. ATM backbone traffic (“wholesale traffic”) and IP traffic at one school (“Retail Traffic”) were metered and charged. Consolidate charging was performed at the IP layer in a TINA-based accounting system. The SUSIE project experimented with different ways of providing the network infrastructure required to support multi-point video-conferencing and collaborative learning activities. The project provided a backbone network, to which the schools gained access through various mechanisms including ADSL, ISDN and direct ATM connection. The diagram of Figure 3 shows a typical Virtual Classroom layout. In this case, the SUSIE project exploited the TEN-155 Managed Bandwidth Service (see Section 4.1).

95

Figure 2: A Virtual Classroom session

3.6.3

Trial Results

3.6.3.1

IP Metering

Α

in action (Lucan Community College, Dublin)

ΔΕ ΙΓ Μ

The performance of the IP meter was measured in a simulated environment. The results graphed in Figure 4 show CPU utilisation in the meter, according to varying packet lengths and traffic up to OC-3 rate. It is apparent that the meter performance is acceptable for long packets. However, with short packets, the meter becomes saturated, and some form of sampling is needed to reduce CPU load.

Figure 3: SUSIE Architectural Environment

96

Α ΔΕ ΙΓ Μ

Figure 4: CPU utilization in the IP meter

3.6.3.2

IP Charging and Accounting

A TINA system was built using C++, Java and CORBA to perform charging and accounting for Premium IP services. The Premium IP Metering System listens to the IP flow in the network. Using special rule-files, it filters packets of interest to the accounting system. This information is then sent to the IP Accounting System using the “TINA Gateway”. The TINA Gateway receives the data measured by the Premium IP Metering System and transports it to the Accounting System. It does so by converting the incoming accounting records into TINA Accounting data packets. The TINA Accounting System is designed to account for a number of different services. Its major functions are the storage of accounting data, the management of user sessions and the calculation of charges. Key results obtained from the trial: • Demonstrated multicast, cost-sharing and hot-billing capabilities • Integrated TINA management functions of subscription and session management • Proved robustness and reliability in 7-day stress test • Prototype limited to approximately 400 sessions, but the CORBA technology used by the system permits scaling 3.6.3.3

Converged ATM and IP charging

The project also tested converged charging, where retail and wholesale charges were consolidated into a single charge. This function was performed on the TINA system. Using a standardised interface, the TINA system receives accounting records from the ATM system and combines them with IP charges. See Figure 5.

97

3.6.3.4

ATM Metering

The project used the Flextel 1200 unit as part of the ATM backbone. This switch was enhanced with ATM metering functionality, and encapsulated ATM usage information in an accounting record that is an extension of the Connection Detail Record (CDR) proposed by the ACTS project CANCAN. Testbed trials validated the metering component of the switch as well as the mediation object that passes accounting records to the outside world. 3.6.3.5

ATM Charging and Accounting

ΔΕ ΙΓ Μ

Α

A system was also designed and implemented to perform charging and accounting for ATM. This platform was also used to implement another requirement of next generation Internet. As there will be a range of services, the charging and accounting system needs the ability to identify what type of service has been used, in order to apply the correct tariff structure. The project has proposed a method for querying the accounting record, and identifying the correct service based on a set of logical rules applied to the contents of the record. This capability was built into an ATM charging and accounting system (shown in Figure 6). This system contains three processes for calculating charges for ATM services. The first process is service customisation that allows the parameters that define a service to be established. The second process is tariff management that defines the tariff parameters for each service. External to the rating engine, a mediation system produces results from metering within the ATM switch. The third process is service identification process that identifies the correct service type from the raw accounting record data. Finally there is the core rating process which uses the service type results and applies a charging algorithm to the raw data and so produces a charge.

Figure 5: IP/ATM converged charging

98

Α ΔΕ ΙΓ Μ Figure 6: ATM charging and accounting

Key results obtained from the trial • Demonstrated Service Discrimination among ten different services • Fasted rating speed of records/second for two services 3.6.3.6

Feedback from Operators

The trial stages of the project also included an opportunity for European operators to comment on various aspects of the charging approach including the charging reference model, the charging algorithms and usage metering. Key results are summarised in three points below. • Regarding the SUSIE Reference Model, operators reached nearly full consensus that it is appropriate, and the experts are unanimous that reference points definition is the most critical issue here. • Regarding charging schemes, there is less consensus, however experts agree that QoS charging should be based on both reserved and used resources. • Finally, regarding usage metering, there is the loosest consensus. However, it is evident that metering simplicity and flexibility are the biggest challenges.

99

4 Quantum and TEN-155

ΔΕ ΙΓ Μ

Α

After the success of TEN-34, the pan-European research backbone network at 34 Mbps that was operational during 1997 and 1998, the Quantum project deployed TEN-155. The TEN-155 network (see figure) interconnects the National Research Networks of 20 European countries with access capacities up to 155 Mbps. Quantum (Quality Network Technology for User-Oriented Multimedia) is co-funded under the Telematics Applications, Esprit and ACTS Programmes of the European Commission. The project is co-ordinated by DANTE (Delivery of Advanced Network Technology to Europe Limited), a not-for-profit company established by the National Research Networks in Europe. DANTE plans, builds and manages the provision of pan-European Internet connectivity for the European research community. A main objective of Quantum and TEN-155 is to provide an operational IP service to the National Research Networks. This section describes two other objectives of Quantum, also supported by TEN-155. Firstly, the Managed Bandwidth Service (MBS), based on ATM, which provides end-to-end connections with guaranteed Quality of Service. Secondly, the Quantum Test Programme (QTP), which evaluates emerging technologies with the aim to develop new operational services.

Figure 1: The TEN-155 Network (from http://www.dante.net/ ten-155/)

100

4.1

TEN-155 Managed Bandwidth Service

Jose Manuel de Arce DANTE 4.1.1

Introduction

ΔΕ ΙΓ Μ

Α

The success of EuropaNET [1] and TEN-34 [2] has demonstrated that a dedicated that a networking infrastructure dedicated to the European research community is essential for successful co-operation amongst European researchers. Both these networks have had a short life-time, mainly due to the excessive cost of international capacity. Nevertheless, with the help of funding from the European Commission (EC) it has been possible to deploy them and demonstrate their vital importance to the research community. The Quantum project [3] foresees the exploration and implementation of providing Quality of Service across a pan-European network of very high speed. TEN-155 [4] is the operational network built as a result of the Quantum project and interconnects the National Research Networks of 20 Western and Central European countries. The liberalisation and evolution of the telecommunications market in Europe has allowed the European Academic community to evolve from deploying a simple IP best effort interconnection service to being in a position of offering a Managed Bandwidth Service that allows provisioning of dedicated network resources (bandwidth, bounded delay, etc) between connected end sites. 4.1.2

TEN-155 Managed Bandwidth Service

In addition to the best-effort IP service, the TEN-155 network provides a Managed Bandwidth Service (MBS) [5]. MBS enables connectivity among academic research projects in countries connected to TEN-155 and allows groups/projects to request bandwidth for specific periods, connecting specific nodes, with various service guarantees, via Virtual Private Networks (VPNs). The service is provided end-to-end and involves collaboration with the National Research Networks (NRNs) in its provisioning and operation. Access to the service is via ATM and is available to institutions connected to an NRN or, exceptionally, directly at a Point of Presence (PoP) of TEN-155 in each country. Since resources are allocated to specific subset of users, agreement from all the involved parties is necessary. Allowing a specific project or user group to use this service is a national policy decision, very much in the same way as the academic networks in Europe have an Acceptable use policy in place for their IP service. The architecture of the networks built is described in figure 2. The dashed lines enclose management boundaries between organisations, and the number of such domains varies between projects. The routers in figure 2 are used for the IP service provided over TEN-155. They are not involved in the TEN-155 MBS service since only ATM level links are used.

101

Α ΔΕ ΙΓ Μ Figure 2:TEN-155 Managed Bandwidth Service Architecture

The direct connection is subject to acceptance from the NRN management and the resources needed to establish the interconnection up to the TEN-155 equipment are to be provided by the project. MBS may use existing network resources of those NRNs connected to TEN-155. An initial guideline is to allow 10% to 20% of the existing bandwidth between an NRN and TEN-155 to cater for Managed Bandwidth Service requests. MBS is an end-to-end service. Its availability depends not only on the TEN-155 network but also on the NRN network infrastructure and the existing technical and human resources within the participating NRNs. There are similar services in some NRNs connected to TEN-155. DFN, SURFnet and SWITCH have their operational national ATM service, UKERNA is piloting their National Managed Bandwidth Service based on SuperJANET and some other networks are developing similar services on an nation-wide basis (GRNET, RENATER-II, BELNET, RCCN). An overview of existing services is given at: http://www.dante.net/mbs/nrn/matrix.phtml 4.1.3

Deployment

As the TEN-155 Managed Bandwidth Service is a new service, two test phases were planned before the service would become operational. The alpha test phase was carried out from the

102

ΔΕ ΙΓ Μ

Α

beginning of January to the end of March 1999 based on one pilot project (MECCANO) with sites in a limited set of countries (France, Germany, United Kingdom). The beta test phase lasted from the beginning of April to the end of June 1999 and involved eight projects/groups, with sites in most countries connected to TEN-155. The projects/groups were either involved in EC co-funded research and development activities (DYNACORE, EDISON, SUSIE, RCnet), research activities between Universities (ENCART), between research institutions (Czech Physicists and CERN) or research activities within the Quantum Test Programme (TF-TANT MPLS experiments, TF-TANT DiffServ experiments; see Section 4.2). The results from the alpha and beta phases have been published and are available at: http://www.dante.net/mbs/ The list of all the Managed Bandwidth Service users, including references to the project information and networks is available at: http://www.dante.net/mbs/participants.phtml The conclusion of the test phases has been satisfactory. Although all the projects involved were able to get access to the service, in one case the price of the national service and limitations in scheduling short life connections (two hours per day) made the service not adequate. The service has been considered in “production” since the beginning of September 1999, and it has been used continuously since then by a variety of EC funded projects and other research organisations. 4.1.4

Service Procedures

Access to the MBS is based on the establishment of ATM connections between network equipment belonging to or used by one of the project members and network equipment of the NRN or the TEN-155 network. Having the project participant sites already connected as part of the National Research Networks, or in a position to connect in a short period of time, is a strong requisite. DANTE acts as a co-ordinator in the process of setting up the network, establishing contacts with the ATM Service Managers (ASM) in the different countries and making sure that all persons involved in the project have the correct information. Organisations participating in a project must identify a Group Network Manager (GNM) whose role is the co-ordination of all the members in the project and communication with DANTE. The GNM should have a good knowledge of networking and the networking needs of the project and/or strong project management skills to co-ordinate the flow of information between the technical contacts, DANTE and the ASM. The primary channel of communication is between the GNM and DANTE. DANTE contacts the responsible persons of the NRNs involved and stays in constant contact with the GNM, as the single contact point to the project. Most if not all of the contact is done using electronic mail and web tools. The initial contact address is [email protected], and more information is available in [5].

103

But how can someone make use of the TEN-155 Managed Bandwidth Service? The MBS management procedure consists of five main stages that are briefly described here: 4.1.4.1

Proposal Stage

Agreement Stage

ΔΕ ΙΓ Μ

4.1.4.2

Α

In this phase, the project GNM collects information about the project sites and the suitability of TEN-155 and the NRNs as the transport network. To make the initial request the GNM sends DANTE ([email protected]) a description of the project and information about the project’s planned network, including a minimum set of information aimed to help evaluating the project feasibility, the amount of resources needed and a reference for calculating costs in case additional equipment or resources are necessary. Electronic mail or web based tools (located under [5]) are used for this initial contact. As a result of this preliminary contact, the whole project will be evaluated by DANTE, consulting the involved NRNs when necessary or referring to existing national service information as necessary. The final goal of this phase is to make sure that the requested network can be implemented in a convenient way and will fulfil the project needs.

After the project is evaluated as feasible, DANTE produces a network topology diagram in which the different elements constituting the network are identified. This information is per site and it gives DANTE and the NRN ASM all the details needed to indentify the equipment and configure the PVCs. It also helps in case of problems and supplies information about specific characteristics like limits in values for VP range, etc. The last piece of information needed describes the traffic parameters. It serves to establish the configuration of equipment. Bandwidth and time are limited resources, therefore this information is very important for evaluating the initial request and answering the question of “Do we have that amount of resources in that period of time?” 4.1.4.3

Production Stage

The operational network consists of different segments managed by their correspondent network operations centre. A list of technical contacts for network troubleshooting is made available as part of the network plan for problem debugging and solving. 4.1.4.4

Termination Stage

At the end of a project’s life, network resources no longer needed are freed. A final report can be produced describing the network and its usage, as part of the project networking contribution. All project related data can be archived for future reference.

104

4.1.5

Users of the Managed Bandwidth Service

Potential users of MBS are distributed research projects and connected universities and research institutions, as well as European organisations participating in EC co-funded research and development activities with sites in countries of participating NRNs. During the beginning of the initial tests, some of the participants were projects involved in the the ACTS programme that needed international connectivity between the project participants in order to carry out some of the project experiments. 4.1.6

Conclusions

ΔΕ ΙΓ Μ

Α

The network needs for the European academic and research community have gone further than best effort IP connectivity. Dedicated bandwidth, or dedicated network resources to assure a certain degree of quality is a requirement nowadays. Also the possibility of transport of user traffic by using a lower layer protocol is a usual demand that cannot be satisfied with the classical IP service. The TEN-155 Managed Bandwidth Service is aimed at fulfilling these needs by providing ATM-based virtual networks. This service has proven useful for some EC funded projects and other research activities, and there is a constant growing demand. The challenges for the service are more in the management area than in the technical arena. Dealing with different administrative domains is a slow process and difficult to automate, but a necessity to get end-to-end service across Europe. An interesting area of development of this service is based on the IP QoS field, with some documents now in the standardisation process. The combination of DiffServ and MPLS, aimed to provide the same Quality of Service that exists today in the ATM network, could be the tool to implement Managed Bandwidth Services over the future IP network without depending on the existence of an ATM layer. But it remains to be seen whether these technologies will be able to support the traffic separation and security characteristics of the current MBS.

References [1] [2] [3] [4] [5]

EuropaNET. http://www.dante.net/europanet.html TEN-34—The Information Superhighway for European R&D (February 1997—December 1998). http://www.dante.net/ten-34/ The Quantum Project. http://www.dante.net/quantum/ TEN-155—The Next Generation of European Research Networking. http://www.dante.net/ten-155/ TEN-155 Managed Bandwidth Service. http://www.dante.net/mbs/

105

4.2

Interim Results of the Quantum Test Programme

Roberto Sabatino DANTE 4.2.1

Introduction

ΔΕ ΙΓ Μ

Α

The Quantum Test Programme (QTP [1]) is one of three components of the Quantum Project [2]. The project aims at: • Delivering a stable IP service with access speeds up to 155 Mbps interconnecting the European National Research Networks. • Providing a Managed Bandwidth Service (MBS [3]) based on ATM for end to end guaranteed QoS across management domains. (See Section 4.1.) • The evaluation and experimentation of emerging technologies with the aim to develop operational services. Experimentation under the label of QTP is co-ordinated by DANTE as part of the Quantum project that resulted in the deployment of the TEN-155 network [4] which fulfils all three goals of the Quantum project. 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). The Task Force is primarily composed of representatives of National Research Networks, but participation is open to any individual or representative of an organisation that can offer appropriate expertise, manpower, equipment or services. TF-TANT actively seeks collaboration with teams working on similar goals, e.g. national initiatives such as Internet2. The next sections present current areas of experimentation. The group’s web page contains the list of experiments and is kept up to date. It can be found at: http://www.dante.net/quantum/qtp/ 4.2.2

Multicasting (IP and ATM)

The goal of the multicasting activity is to evaluate both IP and ATM level multicasting. Initial activity has focused on IP multicast for the provisioning of a TEN-155 multicast service based on PIM-SM, MBGP and MSDP. From April to July 1999 the migration from the DVMRP based European Mbone to the native multicast technology was performed. Currently TEN-155 offers native multicast in pre-production quality, whilst a fully operational service for all NRNs is expected in January 2000. Future work will concentrate on the evaluation of BGMP/MASC and the interaction between IP and ATM multicast with point-to-multipoint ATM SVCs.

106

This activity has confirmed that in order to provide a stable and reliable end to end multicast service it is essential that the same technology migration occurs also within the NRNs up to the campuses. This is proving to be a problem mainly because of the limited knowledge of the technology itself and the availability of the appropriate hardware and software all along the paths interconnecting the participants of a multicast session. 4.2.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 signaling 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 Differentiated Services [DS] 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-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 services that are envisioned to be provided on TEN-155 are: • Virtual leased line service (VLL) • Capacity allocation on congested links • Better than best effort

Testing of the Differentiated Services implementations has been carried out on TEN-155 using the MBS to setup a dedicated VPN interconnecting nine sites. The testing has so far focused on Cisco’s and IBM’s implementations of the technology, such as CAR, CB-WFQ (Cisco) and SCFQ (IBM). The results have shown that the configuration is extremely complex and that a simple mis-configuration can drastically reduce the effectiveness of the technology. Also, for some of these implementations, inconsistent results have been achieved with the same technical setup in different locations. Future work will involve testing of Cisco’s WRED functionality and a more exhaustive test of IBM’s features. In addition, other vendor products and their interoperability are to be tested. 4.2.4

MPLS

Label switching is a technique based on an integration of layer 2 switching and layer 3 routing. This technique has been designed so that high speed networks can combine the

107

performance of switching with the scalability and flexibility of IP routing in a more efficient way. The main activities 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

ΔΕ ΙΓ Μ

Α

So far work has been carried out on Cisco’s implementation of MPLS (Tag Switching). Basic functionality tests have revealed that the available software is stable and that the basic configuration of the features is rather straightforward. The VPN functionality of Cisco’s MPLS has been successfully tested and proved to work well. Results regarding re-routing of label switched-paths (LSPs) has not proved satisfactory: long re-routing and restoration times have been observed. These problems are currently under investigation by Cisco. Future work concerns the testing of other vendors’ solutions and their interoperability. 4.2.5

Other Activities

Several other activities are being carried out, all of which have detailed descriptions available at http://www.dante.net/tf-tant/ • • • • • • • • •

RSVP to ATM SVC Mapping IPv6 IP over ATM (SBR2/3, ABR, GFR) Policy Control (IP and ATM) Route Monitoring Flow-based Monitoring Analysis Quality of Service Monitoring WDM STM-1 vs STM-4c

References [1] [2] [3] [4]

108

The Quantum Test Programme. http://www.dante.net/quantum/qtp/ The Quantum Project. http://www.dante.net/quantum/ TEN-155 Managed Bandwidth Service. http://www.dante.net/mbs/ TEN-155—The Next Generation of European Research Networking. http://www.dante.net/ten-155/

5 Topics in Next Generation Networks 5.1

IP version 6

5.1.1

Introduction

Α

Latif Ladid Vice President, Ericsson Telebit A/S President, IPv6 Forum

ΔΕ ΙΓ Μ

The IPv6 Forum (see the interview with Jordi Palet in Section 5.2) was launched in July 1999 by 50 leading Internet vendors, carriers, Internet Service Providers and Research & Education to promote Internet Protocol version 6. IPv6 will improve the overall quality and security of the Internet, establishing a viable framework for the new millennium. IPv6 will be particularly important as the proliferation of mobile computing devices continues over the next decade. If companies don’t take action soon to migrate from IPv4 to IPv6, upgrade costs likely will dwarf those for the Y2K fix, causing global economic chaos. The enormous stakes involved in preparing the Internet for the future make the work of the IPv6 Forum among the most important of any industry advocacy group operating in the world today. To accomplish its mission, the Forum must have a management infrastructure that frees the Forum’s leaders to focus on vision and education. The Forum must also implement a potent global communications and public relations campaign, beginning now to aggressively educate companies and consumers in what is likely to be a years-long process. 5.1.2

IPv6 Background

With the changing nature of the Internet and business networks, the current Internet Protocol (IP), which is the backbone of Transmission Control Protocol (TCP)/IP networking, is rapidly becoming obsolete. Until recently, the Internet and most other TCP/IP networks have primarily provided support for rather simple distributed applications, such as file transfer, electronic mail, and remote access using TELNET; but today, the Internet is increasingly becoming a multimedia, application-rich environment, led by the huge popularity of the World Wide Web. At the same time, corporate networks have branched out from simple e-mail and file transfer applications to complex client/server environments and intranets that mimic the applications available on the Internet. All of these developments have outstripped the capability of IP-based networks to supply

109

5.1.3

Internet Addressing

Α

needed functions and services. An internetworked environment needs to support real-time traffic, flexible congestion control schemes, and security features. None of these requirements is easily met with the existing IP. However, the driving force behind the development of IPv6 is the stark fact that the world is running out of IP addresses for networked devices. The fixed 32-bit address length of IP is inadequate for the explosive growth of networks. The driving motivation for the adoption of IPv6 was the limitation imposed by the 32-bit address field in IPv4. In addition, IPv4 is a very old protocol, and new requirements in the areas of security, routing flexibility, and traffic support have developed. To meet these needs, IPv6 has been defined, and includes functional and formatting enhancements over IPv4. In addition, a set of security specifications have been issued that can be used with both IPv4 and IPv6. With most of the technical details of these enhancements frozen, vendors may begin to move this capability into their product lines. As IPv6 is gradually deployed, the Internet and corporate networks will be rejuvenated, able to support the applications of the 21st century.

ΔΕ ΙΓ Μ

All addresses used in the Internet must be unique. With the present method of address allocation, there is a finite limit that will be reached sooner rather than later. The problem is a bit like the millennium bug. Potentially a time bomb waiting to go off. 5.1.4

What is IPv6?

IPv6 is a replacement Internet Protocol that will enhance the ability to sustain the continuous growth of the Internet, solving the IP address space depletion dilemma and enhancing other properties that will eventually impact on the viability of the Internet. By the use of the IPv6 Addressing capability, rather than the existing IPv4 protocol, the limit on addresses has been extended from a theoretical 4 billion to 340 trillion, trillion, trillion (3.4x1038) 5.1.5

Why have IPv6?

IPv6 is more than an improved longer term addressing facility. It is also a protocol that offers more scalable network architecture, improved security and data integrity, improved quality of service and security enhancements. The 128 bit address space that IPv6 uses will allow businesses to deploy a great array of new desktop, mobile and embedded network devices in a cost effective, managed manner. The advanced auto configuration features will allow automatic attachment of these devices to the network without the costs of manual configuring. Other factor that is important in the Internet changes is the need for effective scalable routing. This is the technique that enables the addresses of all nodes or devices on the Internet to be located by a tree structure search without the need to hold all addresses on key routers only. As a consequence of the existing 32 bit addressing architecture, the IPv4 network

110

IPv6—New Opportunities for European Public Network Operators

ΔΕ ΙΓ Μ

5.1.6

Α

regularly experiences small “tremors” when these key Internet routers have difficulty in keeping up with the current network. The way that IPv6 assigns addresses will make this a lot more effective with a minimum of human intervention. Consequently new devices can be configured in a simpler manner and existing ones renumbered without any visible impact on the bulk of users. As with many new technical advances, networked business enterprises that invest in IPv6 planning now will enhance their competitive advantage as the growth of Internetworking proceeds. IPv6 as the standard for Internet Protocol or IP as set out by the Internet Engineering Steering Group has been approved as far back as 1994. Most major vendors have started to deliver IPv6 on desktop machines, servers and routers. A wide range of support already exists for the protocol. IPv6 is not just an address improvement, it introduces a completely fresh start and structured hierarchy of routing that will replace the present chaotic anomalies and liabilities.

Classical Internet has a vast potential and covers a wide range of applications. However, a serious drawback is that the Internet cannot guarantee the bandwidth required by real-time services, such as telephony or videophone. The EURESCOM Project P702 has set out to investigate the support of user initiated bandwidth-on-demand for the Internet, especially in connection with IPv6. The idea is to use (public) switched networks, such as PSTN, ISDN, ATM or Frame Relay, to explore opportunities for so-called Non-Broadcast Multiple Access Networks (NBMA), the Internet terminology for public switched networks, to transport specific IP flows with a specified QoS. The current Internet is based on IPv4. Although it has some limitations, Internet usage is increasing dramatically. Almost all known telecommunication services and applications are technically feasible over this network. Examples are: e-messaging, Web-site hosting, telephony, audio, video (still and moving pictures), retrieval and conference services. Despite its undoubted success and ubiquity, IPv4 reflects the limitations of a protocol of the early seventies. It is increasingly unable to cope with the migration towards services with real-time and multicast requirements. Problems also arise for delay and delay variation sensitive multimedia services, where there is a need for specific QoS or for differential service levels. IPv6 is being developed by the IETF to address many of these problems and to enable scaleable IP services to meet future growth demands. Not only the protocol has been extended to meet new requirements, such as address space, flow labels, traffic class field and security features. It has also been simplified with old parameters, such as check-sum, type of service, flags and identification options being removed.

111

ΔΕ ΙΓ Μ

Α

Project P702 has investigated network scenarios and specified building blocks which combine the best of two worlds: the Store and Forward IP world and the Circuit Switched Telephony world. Two experiments were specified by P702. The first was internal to the Project, and experimented with IPv6 tunnelling and traffic-driven switching over to ISDN. The second is being carried out in co-operation with the Danish vendor Telebit Communications and the University of Lancaster in the UK. The Project has developed a so-called Cut-through Reference Model that exploits the general characteristics and requirements of a dynamic bandwidth-on-demand service. The model identifies the main elements of the architecture that are common in all scenarios. The main elements of the Cut-through Reference Model are: • CLNS: Connection-less Network such as Public Internet or Private Intranets. • Non-Broadcast Multiple Access Networks (NBMA): currently ISDN and ATM. • Decision Point: the machine that has the hardware and software to route packets to different networks types (CLNS, NBMA). • Cut-through Data: the point where all the relevant static or dynamic information is stored or calculated. • Policy: the information about who is allowed to use what, when, with what characteristics, for how long and at what price. • Flow Specification: the information about the specific characteristics of a cut-through, such as bandwidth and delay • Autonomous System (AS): a collection of machines (router and hosts) that share one Decision Point and one set of associated Cut-through Data. Examples are: a PNO/ISP and the customer base. The decision is made by the user, but the Decision Point is in the network. The user must therefore signal his or her flow requirements to the Decision Point. The IETF RSVP is used for this purpose in conjunction with an IPv6 QoS routing table based on subscription information that enables the requested flow requirement to be mapped to the appropriate network type and bandwidth. Users subscribe to this bandwidth-on-demand service and the subscription information is stored at the Decision Points as policy information. When starting an application, the user selects the QoS parameters for the flow transmitted by the application via a graphical interface. The application may also make this selection automatically. The selection is signalled to the Decision Point using an RSVP PATH message and then routed according to the next-hop information found in an IPv6 QoS routing table. A Flow ID based on source address and the IPv6 Flow Label is then used to register the flow in the reservation table, enabling subsequent data packets for which a Flow ID match is found to bypass a full router table look-up. The mapping of QoS parameters to the selection of bearer network at the Decision Points

112

ΔΕ ΙΓ Μ

Α

is subscription specific and under the control of the PNO. This is an implicit choice of the bearer network and the required network bandwidth. Users are notified of rejected requests for QoS. The signalling of flow requirements and subsequent reject or success results is signalled by RSVP. Accounting information is collected at the Decision Points and transmitted as account records to a Network Management Centre, where they are logged. In general, as much as possible is designed according to available or emerging IETF RFCs, ATM Forum specifications and ITU Recommendations. In particular, the signalling between the host and the Decision Point of user or application selections is done by means of IETF RSVP over IPv6, which is currently on the standards track. IPv6 for different media is also encapsulated according to IETF drafts or RFCs. The ATM SVC service is accessed according to ATM Forum UNI 3.1. The main item that goes beyond the framework of the above specifications is the concept of Decision Points, where the assignment of routes of IPv6 packets in a flow are based not only on Destination and Source IPv6 addresses, but also on a EURESCOM defined interpretation of other fields in the RSVP PATH message. This interpretation, together with policy information, is configured in the Decision Points by means of network management and forms the basis of deciding whether to assign a route for a flow via ISDN via ATM SVC networks or via normal IPv6 Internet. The main advantage of IPv6 is its random integer flow label which is used as a hash key. In conjunction with the source address, a globally unique flow identifier is created that identifies traffic flows in case of collisions. This results in an efficient look-up process far superior to the traditional association of source address, destination address, as well as possible protocol identifier and port number. Further items of note are: • The first operational National IPv6 network (UNI-C) is already two years old. • The kernel of the IPv6 specification and address format is stable. • IPv6 is less about address shortages and more about providing a scaleable addressing structure to enable the Internet’s growth to continue. In summary, IPv6 provides: • Extended address space allowing hierarchical prefix based routing (smaller routing tables) and overcoming future address shortages. • A standardized header format and size making it easier to process packets in modern 64 bit hardware architectures. • Header and payload compression. • Standards track QoS and differential service features. • Mandated security (authentication, integrity, confidentiality and key management). • Mandated autoconfiguration in both stateful and stateless modes. • Updated routing protocols (RIPv6, OSPFv6, BGP4+, IDRPv6). • Multi-homing possibilities.

113

ΔΕ ΙΓ Μ

Α

• Dual stack migration strategy ensuring interoperability with the installed base of IPv4 devices. • Simplified mobility supporting mobile and nomadic scenarios.

114

5.2

IPv6 Forum: IPv6 Around the World

Jordi Palet Consulintel Chair of the IPv6 Forum Education and Awareness WG.

Α

In this interview, Mr. Palet describes the structure of the IPv6 Forum, its main activities, and the current status of IPv6 trials, products, and deployment around the world. The IPv6 Forum was created on July 1999 with an important participation of European companies. The press release reproduced below announced the new Forum and its founding members:

ΔΕ ΙΓ Μ

The New Internet Forum has been established: The IPv6 Forum luxembourg, july 7th, 1999. A worldwide consortium of leading Internet solutions vendors, Internet service providers (ISP’s) and research and education networks joined to form the IPv6 Forum. This Forum will have a clear mission to promote IPv6 (Internet Protocol version 6) in order to create a higher quality and more secure next generation Internet: The NEW INTERNET. The Forum plans to dramatically improve the market and user awareness of IPv6 providing worldwide, equitable access to knowledge and technology. The Forum will work closely with the Internet Engineering Task Force, which is responsible for the IPv6 technical specifications and to which many Forum members contribute. “IPv6 is here and now, so take the Internet where no other network has gone before!” comments Dr. Vint Cerf, Chairman of the Internet Societal Task Force and known as one of the fathers of the Internet. “We’ve known for some years that IP version 4 was heading towards its limits, and the IETF has been working on IPv6 since 1994. Now, the basic standards are agreed and implemented, and it is time to move forward,” adds Dr. Brian E. Carpenter, Chair of the IETF’s Internet Architecture Board, and a Program Director in IBM’s Internet Division. “We have been very active in building a strong IPv6 infrastructure in Japan as we see immediate benefits to our economy, knowledge and education potential to our people” confirms Dr. Jun Murai, General Chairman of the WIDE IPv6 Project and Professor of KEIO University. “Nokia believes that IPv6 is a fundamental enabler of Nokia’s vision of the Mobile Information Society. Today, the number of cellular handsets already far exceeds the number of fixed Internet terminals; IPv6 is the only viable architecture that can accommodate the coming wave of Internet capable cellular devices. Nokia is eager to contribute to the IPv6 Forum’s efforts to accelerate the acceptance and deployment of IPv6 throughout the Internet.” states Pekka Ala-Pietilä, President, Nokia.

115

“Ericsson has a clear business and technology vision about how IPv6 enables the performance and service offerings mandated by both mobile infrastructure (GPRS, UMTS), broadband networks, consumer electronics and terminals, and the interoperability/management thereof, extending therefore full support to the IPv6 Forum”, emphasizes Jan Uddenfeldt , Senior VP and Technical director of L.M.Ericsson. “The IPv6 Forum’s noble objectives will be to promote this new technology on a worldwide basis sharing knowledge, experience and interoperability and creating common grounds for the New Internet of the next millennium”, states Latif Ladid, President of the IPv6 Forum & VP at Telebit Communications.

ΔΕ ΙΓ Μ

Α

IPv6 Forum Founding Members Initial members of the IPv6 Forum include 42 of the top companies and institutes active in the new Internet technology, a truly international forum from day one: Europe & Middle East (18): BT, Case Technology, Consulintel, Deutsche Telekom, CSELT, DFN, Ericsson, Eurocontrol, Gigabell, IABG, Intracom, Netmedia, Nokia, Teldat, Telebit Communications, CSELT, Telia Networks Services, Thomson-CSF Detexis. North America(18): 3Com, Advanced Systems Consulting, AT&T, Cisco, Compaq, ESNet, Hewlett-Packard, IBM, MCI WorldCom, Mentat, Microsoft, Motorola, Qwest, SGI, Sprint, Sun, The Business Internet, Viagenie-Canarie. Asia Pacific(6): Centre for Wireless Communications (Singapore), Hitachi, NTT, NTT Software Corporation, Trumpet Software, WIDE Japan. For more details about the IPv6 Technology or membership in the IPv6 Forum, please visit the IPv6 Forum Web Page: http://www.ipv6forum.com/ InfoBridge: Is IPv6 still a theory?

Jordi Palet: From July 1999, we have the right to say that IPv6 is not a theory, it is a fact. The reason is because on that date the major industry players joined together in a non profit organization, the IPv6 Forum, with a common mission: educate the market on the advantages of IPv6 protocol, and promote its use, to enforce its worldwide deployment. The list of corporations involved in this project is a powerful mix, including manufacturers, research & development institutions, education organizations, telecom operators, consulting companies, amongst others. That means, of course, generating a lot of efforts, from persons to entire companies, to press the standards organizations for speeding up the process, to terminate the creation of a stable and complete protocol definition. Just as a “measure” of the importance for the market of the IPv6 protocol, we can mention an anecdote about the number of members in the constitution of the Forum. We have reached 42 founding members in a few weeks of work, while some years ago, the ISDN Forum took more than 2 years to reach the same number of players! It goes without saying, as a

116

comparison, the importance that ISDN technology has played over the last years in the worldwide telecom market. I.: How many members has the Forum now?

26 27 28 29 30 31 32 33 34 35 36 37 38 39

Qwest – US IABG – Germany ESnet-6REN – US MCI WorldCom – US Ericsson – Sweden Microsoft – US 3Com – US Advanced Systems Consulting, Inc. – US Consulintel – Spain The Business Internet – US NTT Software Corporation – Japan Motorola – US Telia Networks Services – Sweden Centre for Wireless Communications – Singapore Siemens – Germany IBM – US BellSouth – US Teleglobe – US Silicon Graphics, Inc (SGI) – US Etisalat – UAE SwitchCore AB – Sweden UCAID – Internet2 – US University College of London (UCL) – UK University of Southampton – UK

ΔΕ ΙΓ Μ

IPv6 Forum Members (1 December 1999) (*) waiting for approval. 1 Case Technology – UAE 2 Thomson-CSF Detexis – France 3 Ericsson Telebit – Denmark 4 Eurocontrol – France 5 Gigabell – Germany 6 Hitachi – Japan 7 Hewlett-Packard – US 8 DFN – Germany 9 Canarie-Viagenie – Canada 10 NTT – Japan 11 WIDE – Japan 12 BT – UK 13 CSELT – Italy 14 Mentat – US 15 SUN – US 16 Netmedia – Finland 17 Trumpet Software – Australia 18 Intracom – Greece 19 Cisco – US 20 COMPAQ – US 21 SPRINT – US 22 NOKIA – US 23 AT&T – US 24 Teldat – Spain 25 Deutsche Telekom – Germany

Α

J.P.: The membership of the IPv6 Forum on December 1st, 1999, is 69 companies/organizations, with some additional companies in the process of joining, waiting for internal approval procedures. The list of members, compiled in order of when these companies joined the Forum, is kept up to date in the IPv6 Forum Web site: http://www.ipv6forum.com/navbar/members/foundingmembers.htm (founding members) and http://www.ipv6forum.com/navbar/members/generalmembers.htm (general members).

40 41 42 43 44 45 46 47 48 49

117

62 YDC (Yokogawa Digital Computer Corporation) – Japan 63 Alcatel – France 64 GITEP – France 65 ISI – US – UK 66 Nortel Networks – US 67 ISOC 68 Stardust.com – US 69 Telefónica – Spain France Telecom, France (*) Apple, US (*) Lucent, US (*) SPAWAR, US (*)

Α

50 University of Lancaster – UK 51 Royal Philips – The Netherlands 52 Royal KPN (Royal Dutch Telecom) – The Netherlands 53 The Open Group – UK 54 CIAC – France 55 UNINETT – Norway 56 NEC – Japan 57 ETRI – Korea 58 INTAP – Japan 59 Alpha Group – US 60 Korea Telecom – Korea 61 CNRS – France

ΔΕ ΙΓ Μ

I.: Which are the main activities of the Forum?

J.P.: According to the words of Latif Ladid, Chair of the IPv6 Forum, our mission is to improve the market and user awareness of IPv6, creating a quality and secure Next Generation Internet and allowing world-wide equitable access to knowledge and technology. To this end, the IPv6 Forum will: • Establish an open, international Forum of IPv6 expertise • Share IPv6 knowledge and experience among members • Promote new IPv6-based applications and global solutions • Promote interoperable implementations of IPv6 standards • Co-operate to achieve end-to-end quality of service • Resolve issues that create barriers to IPv6 deployment The IPv6 Forum will not develop protocol standards, because the Internet Engineering Task Force has the authority to do that. I.: How is the IPv6 Forum organized?

J.P.: It has been organized in two main parts, both depending on the IPv6 Forum Board: the IPv6 Deployment Technical Directorate and the IPv6 Forum Promotion Group. The IPv6 Deployment Technical Directorate. has full autonomy in its decisions from the promotion group, guaranteeing an objective and vendor-independent definition of IPv6 technical deployment solutions, and is available to the Forum members to assist with technical, deployment, and implementation issues and opportunities. The directorate consist of about 20 members “active contributors”, aiming for a wide

118

ΔΕ ΙΓ Μ

Α

range of expertise covering areas such as security, routing, mobility, QoS, PC environments, open source software, network managers, application developers, testing and verification, IP telephony, etc. The IPv6 Forum Promotion Group consists of the following Work Groups (always open to additions): • Projects: Real Life Business Cases, IPv6 Success Stories, National & International Projects, Funded Projects, ... The goal is to demonstrate the ongoing evolution towards the New Internet with collaborative projects working on the IPv6 technology, facilitate interchange of information between projects and the creation of new projects. • Education, Awareness and Public Relations. The target is to create and promote queality messages, documents, presentations, and tools, to educate-evangelize about IPv6 and to ensure a clear and powerful image of the benefits of IPv6. • Global IPv6 Summits: IPv6 International and Regional Summits/Conferences, Partner Conferences, ... intended to create worldwide and local events to promote diverse IPv6 aspects. • Fellows Program: Alternative way, non-cost, for individuals to participate in the promotion of the IPv6 protocol. Destined to people interested in writing articles, giving lectures, presentations, or any other promotional/educational activity, mainly locally based. I.: Where and when will future IPv6 events take place?

J.P.: The first official IPv6 Forum meeting was held in Oslo, in July 1999, together with the IETF meeting. This was more a “constitution” meeting than a public one. After that, the 1st Global IPv6 Summit was organized in Paris, in October 1999. It was a big event with great success. Upcoming events are planned in Berlin (December 1999), Birmingham (May 2000), Tokyo, US (March 2000), and Madrid (November 2000). The IPv6 Forum is open to any cooperation to prepare this type of events, regardless they are locally or globally focused. I.: Does the Forum cooperate with other organizations?

J.P.: Underlining it’s promotional goal, the IPv6 Forum will keep open the doors to relationships with other institutions or industry Forums. In fact, we’ve already established very close cooperation with the UMTS Forum, GSM Forum, ISOC, and ETSI, amongst others. As a direct result of this collaboration, the IPv6 Forum participates in other events, for example the UMTS Forum Workshop (Singapore, November 1999), Next Generation Billing Systems (Cannes, December 1999), ComNet 2000 (Washington, January 2000), Mobile.ISP (Paris, March 2000).

119

I.: Let us talk now about the protocol. Is the definition of IPv6 complete?

ΔΕ ΙΓ Μ

Α

J.P.: According to the experts, in general, the IPv6 protocol is well defined, and the core specifications are pretty solid. But still some key points need extra work: • Multi-homing problem. Basically the same that we have in IPv4, and we are surviving! Several proposals in the way, including using mobile IP mechanism, host mechanisms, router-only mechanism, ... Anyway, any of these proposals should hold IPv6 deployment. • Is fixed length addressing the right approach? Some people still don’t agree. But it’s clear that fixed length address of 128 bits is a “hard” boundary. Actually, we are working within this boundary with the IPv6 aggregatable format. It’s widely adopted, so no longer a question to redefine. • The IETF Dynamic Host Configuration Working Group wants to verify that the models that are being used with DHCPv6 (the architecture is different and must incorporate RFC 2462 Stateless Address Configuration) are valid and will work based on the knowledge gained from DHCPv4 implementors. The IPng Working Group wants to extend what could not be done in DHCPv4 but not loose learned knowledge from DHCPv4. This work is being done right now, and we should have a solid draft by May 2000, ready for implementation and for Proposed Standards. • Use of scopes for unicast IPv6 addresses as far as nailing down how they are used and deployed. Scopes are already well understood in IPv6 for unicast global addresses, link-local addresses, and multicast. Currently, there are discussions about the use of site-local addresses and how they are used within the architecture, and they affect to implementations. • We still need to deploy and test IPv6 multicast protocols, which unfortunately have not been tested enough yet. There is work ongoing for PIMv6, but we do not have to await the multicast routing to begin IPv6 deployment. It would be good if we saw more OSPFv6 implementations as that has not been well tested at this time. • Another recent request has been for work on IS-IS for IPv6. IS-IS is an OSI protocol that can adapt to any other protocol by encapsulating it, like IPv4, IPv6, IPX, DECNET, ... Most of the standardization work was considered done after the 45th meeting of the IETF in Oslo. The Internet Engineering Steering Group (IESG) indicated that we just need some more experience “in the field”. I.: Who are the initial target users of IPv6?

J.P.: Obviously, the best targets for IPv6 deployment are places where you can’t get IPv4 addresses today, for instance emerging and growing countries (because major US ISP’s are trying to reserve the remaining IPv4 address space for themselves). There is no killer application for IPv6. It solves the address space problem. This problem

120

ΔΕ ΙΓ Μ

I.: Is IPv6 enough for end-to-end QoS?

Α

has no other real solution and it can kill any new application with large address space requirements, like IP mobile telephony. If anybody has any doubts about the importance of this fact, consider that the number of cellular phones has already grown over the number of Internet connections! Any application actually running over IPv4 will run better on IPv6, having a lot of extra resources, and offering better ways for QoS and CoS. What about Voice over IP? I’ve my own experience in Voice over Frame Relay and Voice over IP in really large installations ... I’m convinced about IP success over FR in the future, but also, I’m convinced about VoFR while we can’t offer real world wide “VoIPv6”, I mean over public IP networks, over Internet. Users? IPv6 Forum is defining this situation. End users will go first!, because IPv6 will grow from the Intranets to the Internet. As many Intranets use it and tunnel between them and more vendors ship products, and the IPv6 Forum does its own job, ISP’s and Telcos will be able to feel comfortable moving to IPv6. But no one will move without products being shipped. It’s like the chicken and egg. It’s the main IPv6 Forum mission!

J.P.: If we figure out how to best use the Traffic Class and Flow Label, it is at least a start and the IPv6 header provides an inherent infrastructure type right within the IP header. But like IPv4, the issue is how applications use QoS when this is turned on application by application. What does this mean? Easy: IPv6 alone is not sufficient for that. Being just a network layer protocol, IPv6 will only be able to provide a network to network QoS when combined with appropriate mechanisms in network routers under a particular approach of providing quality service: Integrated or Differentiated services. As we said, fortunately, IPv6 couples well with both these technologies and offers some improvements over IPv4, such as availability of the Flow label field along with the Traffic Class to carry micro-flow identification for IntServ or ID of DiffServ behavior aggregate. There are proposals for using these fields to place Multiprotocol Label Switching (MPLS) labels if MPLS is used as a QoS enabling technology. In summary, we can say that the advantage of IPv6 over IPv4 is that we have no legacy problems, and the easier classification of packets with flow ID’s. I.: Are there IPv6 competitors?

J.P.: Some people can say that some form of adjustable length addressing can be pretty well implemented and no one would need to delegate anything down. All addresses would be scoped to the length at which they are used. It’s a sort of CLNS in nature. Yes, it could be a better solution. However, options processing is still a big win with IPv6 over any other solution.

121

ΔΕ ΙΓ Μ

Α

The fact is that there is no real proposal for other protocols (they were rejected during the IPng selection process). So the real competitor can be NAT (Network Address Translation) and its son RSIP (Realm-Specific IP). RSIP is a way to temporarily allocate a public IP address (and maybe some extra info, like port ID) to a host attached to a private IP network, in order to allow for an end-to-end transparent communication across the private/public Internet boundary to that host. NAT is nearly “transparent” by in fact exchange address space against management complexity (this will kill it in the long term). NAT isolates intranets from Internet working around the scarcity of address. Schemes are devisable, where unlimited number of NAT boxes are used to provide global connectivity. However this approach is violating the overall concept of Internet: transparency at the network level. NAT also increases the complexity of configuration and creates a single point of failure for connection of networks. NAT breaks the end-to-end model too (it breaks end-to-end security for instance) and puts some state at the wrong place (i.e. in the network, which is bad for scalability). RSIP is not transparent. It needs an upgrade for every application at the end nodes (like IPv6) and extends only by a few bit the real address length (i.e. It can’t be enough). So the only real advantage of RSIP is its NAT relationship! NAT is an aid to solve IPv4 problems, but somebody compared these with fantasy islands if we think they can solve the core IPv4 problems that IPv6 fixes. NAT is the main Band-Aid and we aren’t fighting it anymore but will coexist with it until IPv6 makes it unnecessary. I.: Are there other barriers to IPv6 deployment?

J.P.: Not too many: day to day work will solve them. The main ones are: • The multi-homing problem • The fans of adjustable-length addressing • IPv4 itself, in some way, with the “patches” like NAT. • Lack of real support from dominant router and software vendors (i.e. no IPv6 running on current or near future router firmware releases or Windows OS). • Complexity of transition/migration. • End users need business “enforced” reasons to move to IPv6. I.: Tell us about IPv6 trials

J.P.: You can’t believe it: Hundreds of them! With real users, real corporations, education and research institutions, and more coming. Just go to the 6Bone web site ... lot’s of links, really worldwide. If not enough: 6Ren, 6Init, 6Tap, FREEnet, WIDE, US Navy, Eurocontrol. Probably no other technology has got in so short term a large success like IPv6. Just go to the web ...

122

Somebody isn’t clear about this? Of course, since IPv6 Forum started, and this is another of our big targets, we will promote these initiatives, and open new projects, new collaborations; we need and will involve as many people as possible. D. Vinton Cerf just confirmed that MCI WorldCom runs “native mode IPv6” in the very High Speed Backbone Network Service (vBNS), for example. I.: ... and about IPv6 products and services

ΔΕ ΙΓ Μ

Α

J.P.: The first IPv6 implementations were available in 1995 (the first trace of an IPv6 connection is dated at the end of March 1995). Most of the software and OS vendors have IPv6 stacks in their standard products, and some others as “early access kits”, free of charge, without any official support. But a lot of users and large development communities self-support these packages. No software vendor is without it’s own offering. That’s the indisputable reality. We defined IPv6 as the “Next Millenium Internet”, and this is just around the corner! Year 2000 is many things, and it’s the year for vendors really to start shipping their prototypes. Some of them already have products, real products, working very well in fact, not just betas. But of course, most people is using IPv6 through tunneled systems/servers everywhere. Today 22 corporations/institutions applied for subTLA allocation. And just starting; not bad! Some of these have already announced native IPv6 regular services offerings. They took the chance to bet on the future: they will be winners! Some other major ISP’s will wait for customers willing to pay for IPv6 service before investing. It’s their own business chance. A subTLA (sub top level aggregator) is a sub-space of a full top level address range. Such subTLAs are allocated in the bootstrap phase of commercial IPv6 address allocation. Look at this site for and automatic and updated list of production subTLA allocations: http://www.dfn.de/service/ipv6/ipv6aggis.html I.: Can you summarize the current status of IPv6 around the World?

J.P.: We can identify five distinct regions in terms of their IPv6 development status: • Asia Pacific: In this area, the impact of the IPv4 address shortage is more obvious, and APNIC, the Regional Internet Registry for this region (http://www.apnic.net/) is expected to run out of IPv4 addresses in some months. Correspondingly, the pressure to find related solutions is very high, and a number of activities have been started, particularly in Japan: WIDE (http://www.v6.wide.ad.jp/), KAME (http://www.kame.net/) and TAHI (http://www.tahi.org/). • Europe: The mobility industry is a strong supporter of the transition to IPv6. Correspondingly, the European Telecommunications Standards Institute (ETSI) and the IPv6 Forum have established a cooperation agreement to join their forces; this move of ETSI was quoted to be prompted by “the strong desire of wireless operators”. In addition

123

ΔΕ ΙΓ Μ

Α

to its cooperation agreement with ETSI, the IPv6 Forum has also partnered the UMTS Forum and GSM Association, and is in discussion with the 3rd Generation Partnership Project (3GPP). • North America: Many activities related to IPv6, both in terms of standardization and deployment/testing have their origin in this region. Quite a lot of these activities can be found when looking to the “6bone”, the international IPv6 test bed (http://6bone.net/). Other IPv6 related activities with strong North American participation are 6REN (http://www.6ren.net/)—coordination initiative for IPv6 research and education networks, 6TAP (http://6tap.net/)—initiative to provide a central IPv6 router in Chicago facilitating peering between multiple IPv6 networks, and FREEnet/Viagénie (http://www.freenet6.net/ and http://www.viagenie.qc.ca/)—automatic tunneling initiative. Nevertheless, commercial IPv6 deployment in this region has started slow; currently only 2 commercial IPv6 address ranges (out of 20 worldwide) have been allocated in North America. This reflects the appearance that operational deployment of IPv6 “may be not in this area first” (as quoted in the IPng minutes IETF-46), since the problems of IPv4 address shortage have not emerged to be urgent in this region yet. • Russia: There are strong relations between the official IPv6 Forum, their National one, and FREEnet (Russia-wide academic and research network) aiming to create a Russian community of IPv6 users and service/solution providers. • Rest of the World: Soon we will see several examples of new actions in Mexico, Korea, India, Australia and Singapore. Not so strange as they are high tech countries (India) or between two big development areas (Australia, squeezed between Japan and US). In Singapore the reason is the high degree of wireless communications. According to D. Vinton G. Cerf, there is speculation that this could become much more mainstream as large numbers of end devices, such as cell phones and cable set top boxes require IP addressing and the developers choose to use IPv6 rather than IPv4 to achieve unique addressing of each device. Such step would also involve the use of Network Address Translators, in many cases, to allow for transport of the IPv6 packets across IPv4 backbones. I.: So, in conclusion, when should we migrate to IPv6?

J.P.: Most of us already started in some way, probably through tunnels. We need to push building test beds and using IPv6 over the Internet with other IPv6 users. Commercial companies should wait until standardization issues become clear, evaluate cost, etc. But non-profit networks, like research, education, must migrate gradually now, gaining experience and sharing it with others. After all, the R&D networks always are first to start working with anything, as it was with the Internet. Conclusion: as soon as possible, depending on your case. Maybe when you can forecast you’re not going to get any more IPv4 address space it will be too late!

124

I.: Where can we learn more about IPv6?

Α

J.P.: These are some useful web sites where the reader can continue learning about IPv6: • IPv6 Forum: http://www.ipv6forum.com/ • IPv6 Information Page: http://www.ipv6.org/ • IPv6 Over Everything: http://www.data.com/issue/991021/ipv6.html • Why IPv6?: http://www.opengroup.org/orc/xnet/yv6/ • IPng: http://playground.sun.com/pub/ipng/html/ • IETF IPng Working Group: http://playground.sun.com/pub/ipng/html/meetings.html • The 6Bone Network: http://www.6bone.net/ • Internet2: http://www.internet2.org/ • Internet Architecture Board: http://www.iab.org/

ΔΕ ΙΓ Μ

This relation is a very limited list of available resources in the Web. It’s something like a “point to start”. On most of these sites you will find links to a lot of extra information. If that’s not enough, just point your window to any web search tool and ask for “IPv6”. Probably you will not get enough time to read all you can find! And some mailing lists related to IPv6: • [email protected] • [email protected] • [email protected] • [email protected] • [email protected] • [email protected] I.: Thank you very much, Mr. Palet.

125

5.3

DTM—A Comparison with ATM in the Support of IP Applications with Constraint Needs of QoS

Cláudia J. Barenco. Catholic University of Brasilia, Brazil. Sidnei O. Guerra. Technical University of Madrid, Spain.

ΔΕ ΙΓ Μ

Α

The ATM (Asynchronous Transfer Mode) technology has been seen as a miracle with its cell switching technique and in the support of diverse services: CBR, rt-VBR, nrt-VBR, ABR and the new GFR. Nowadays it has been asked if these facilities bring on an efficient solution for real-time applications. Some drawbacks like the inefficiency of the 5 bytes of cell overhead, the CDV (Cell Delay Variation) caused by the multiplexing, the necessity of computationdemanding principles for policing and buffering and a still high operational cost has lead people in the network area to look for solutions like DTM (Dynamic Synchronous Transfer Mode). DTM is a broadband network architecture based on a synchronous fast circuit switching solution with dynamic reallocation of resources. It provides multicast services, channels with varied bit-rates and a millisecond setup time. As any other circuit switching solution, it isolates the traffic of each channel and provides a constant delay, which makes it well suited for real-time traffic. DTM is designed to fully use the capacity of the optical fiber and support TDM (Time-Division Multiplexing) and WDM (Wavelength Division Multiplexing). It is not necessary to be an expert in the telecommunication area to say that the future will hold the wide spread IP applications directly above a dynamic data-link and physical layers. The DTM solution starts to get off the panacea of layers defined to substitute the static characteristics of the SONET/SDH technology. The DTM technology is designed to be used in an Integrated Services network, thus it combines the quality of the fast circuit switching with the flexibility of the packet switching, also having the inherent multicast capability, affording high efficiency to carry IP. Compared to ATM, DTM offers a higher network utilization rate and provides the support of new advanced services at a much lower cost. The purpose of this paper is to give a background necessary to place DTM in a usage context beside the comparable principles of ATM, SONET/SDH and WDM, as a solution for the real-time IP applications with constraint needs of QoS (Quality of Service). 5.3.1

Introduction

Actually the real-time applications occupy an important place in the Internet. Before we used to transmit only data but now the networks are being used for teleconference, distributed simulations, voice and other real-time applications. As a first point, the datagram networks are not appropriated for real-time traffics as the

126

ΔΕ ΙΓ Μ

Α

packets are sent independently through the networks using shared resources, and consequently we have significant losses, delays and jitter. In case of congestion, the packets indiscriminately can be delivered delayed and consequently obsolete. The QoS concept in network transmissions appeared to give preferred treatment to some traffics, based on their necessity of QoS, during periods of congestion, opposite to the common treatment in the Internet called Best-Effort. With this we can provide a differentiated service for traffics that really need QoS. So, what are the QoS components ? The QoS can be expressed as a combination of impositions: bandwidth, delay, jitter and losses. If we imagine an environment where real-time IP applications are being transmitted on transport networks like ATM and DTM, that have their own QoS model and guarantees, their interoperation with the QoS Internet solutions, are very important, to have a better functionality. In this paper we will analyse each technology concerning QoS guarantees and then describe the interoperation of each one with the IETF QoS models IntServ/RSVP and DiffServ. The ATM technology [1] can be defined based on various principles: (1) Information is transported by units of fixed length, called cells, that are composed by a header and an information field (payload); (2) It´s connection oriented and the cells of the same virtual circuit maintain their sequence; (3) The sources can generate cells whenever they want, there isn´t a pre-determined temporal position, so the cells have to transport labels to identify the connection that only have a local mean because they are translated on each switch; (5) The payload field is transported transparently, for example there aren´t error controls; (6) the cells are multiplexed in a asynchronous manner per time division. ATM can be seen as a method of interchange of information between UNIs (User Network Interface), multiplexing, routing and switching inside the network. And furthermore, it is a technology for the integration of various kinds of traffic (data, video, audio, voice) under the transmission, user access and switching views. Nowadays is bringing up the use of antique switching solutions, but simpler and with reasonable performance for real-time applications with QoS constraints, like the DTM technology [2]. DTM is based on the high-speed circuit switching architecture, with dynamic reallocation of resources. It provides multicast services, channels with varied bit-rates and low time of circuit configuration. DTM defines the technique for the medium access, signalling, schemes of synchronization, routing and addressing assignation. It can be used as an end-to-end solution or as a transport of protocols like ATM and IP. The latter is our objective here. As any other circuit switching solution, DTM isolates the traffic in each circuit, which means that the activities in one circuit don´t disturb the activities in the other one. This brings the possibility of the transmission with a guaranteed quality, for example a constant transfer delay. This architecture can be extended to include a large number of buses using the

127

ΔΕ ΙΓ Μ

Α

switching on the nodes. The switching is synchronous, so the delay caused by this activity is constant on each channel. The service offered by DTM is based on channels, each one formed by a set of time slots originated in the transmitter with a destination to one or various receivers. The channels, that pertain to a shared medium, are composed by TDM (Time Division Multiplexing). The total capacity of the medium is divided in cycles of 125 µs, that are then each one divided in slots of 64 bits. DTM supports WDM too, but this is not our interest here. The slots are composed by slots of control and data. Each node has the access for at least one control slot, that is used for the transmission of control information to other nodes. A node can temporarily increase its capacity of signalling, announcing that some of its data slots will be used as control slots. At the beginning of a DTM system, the data slots are allocated to each node as a pre-defined distribution [8]. The channels in DTM are multirate, and each channel can have an arbitrary number of slots. The capacity of each channel is a multiple of 512 Kbps until the maximum capacity of the medium. In DTM the final systems are connected to the medium indirectly through the controller node, providing the sharing of the hardware interface, decreasing the number of directly connected units to the medium. As soon as the physical medium like the fiber becomes cheaper, it won´t be necessary. The addressing and forwarding of IP packets on a IP/DTM environment use the IPv4 or IPv6 together with “link local” 48 bit IEEE addresses to forward packets or to route a DTM channel to a particular interface. This means that each DTM switch or router relies on an IP routing table for a multi-hop (switching) channel setup or for IP forwarding. As will be shown in section 5.3.4, with the integration of DTM and RSVP protocol, the IP/DTM forwarding and addressing resolution can be easily implemented. The DTM technology has an interesting property called “partial distributed switching”. A controller node can actuate as a switch or as an access unit for end systems and it only has to deal with the traffic that is transmitted to it or the traffic that it has to switch. Other traffic flows pass without the knowledge of the controller node. This is important in the future, since the fiber will carry hundreds of gigabits and some nodes wouldn’t be able to deal with this bitrate. Another property is the simple mechanism of synchronization of different parts of the network, a natural broadcast characteristic that brings a simple multicast service and the multi-channel communication between the nodes, that supports the scalability of optical components. The DTM technology is fundamentally similar to SONET/SDH (Synchronous Digital Hierarchy) in terms of low complexity and low overhead, and includes signalling and switching to increase the flexibility and avoid the hierarchical structure of SDH/SONET. The paper is organised as follows. Section 5.3.2 will present the advantages and drawbacks of ATM and DTM. Section 5.3.3 describes a comparative study of ATM and DTM in aspects of throughput, delay, jitters, losses and complexity for IP applications with strict need of QoS.

128

Section 5.3.4 presents the interoperation aspects of each technology with IETF IntServ and DiffServ models and finally Section 5.3.5 presents the conclusions. 5.3.2

ATM and DTM—Advantages and Drawbacks in Aspects of QoS

ΔΕ ΙΓ Μ

Α

The principal advantage of ATM in respect to QoS is that it offers a Traffic Manager [3] to protect the network and users against congestion and to provide the performance objectives defined in its services classes: CBR (Constant Bit Rate), rt-VBR (Real-Time Variable Bit-Rate), nrt-VBR (Non Real-Time Variable Bit Rate), ABR (Available Bit-Rate) , UBR (Unspecified BitRate) and the new GFR (Guaranteed Frame Rate) [4]. The parameters necessary to define the performance desired in ATM Traffic Manager are: (negotiated) (a) Peak-to-peak Cell Delay Variation (CDV); (b) Maximum Cell Transfer Delay (maxCTD); (c) Cell Loss Ratio (CLR); (not negotiated), that is, they depend on the fixed or temporary characteristics of the network (d) Cell Error Ratio (CER); (e) Severely Errored Cell Block Ratio (SECBR) and (f ) Cell Misinsertion Rate (CMR). ATM defines the following functions for the traffic control and congestion: (a) Control Admission; (b) Usage Parameter Control; (c) Selective Cell Discarding; (d) Traffic Shaping; (e) Explicit Forward Congestion Indication; (f ) Resource Manager using VPs (Virtual Paths); (g) Frame Discard; (h) Generic Flow Control; (i) ABR Flow Control [3]. As we are interested in applications with strict needs of QoS, the CBR and rt-VBR ATM classes will be the classes of our study here, because we believe that they are more adequate for these applications. Although studies like [5] show that ABR can provide end-to-end delay guarantees, apart from the low loss and good bandwidth utilization, the sources and networks have to perform complex functions and the network has to be well-designed to reach this objective. The CBR class needs the specification of two traffic parameters, PCR (Peak Cell Rate) and CDVT (Cell Delay Variation Tolerance), and the following QoS parameters: CDV, maxCTD, and CLR. It guarantees a strict delay, jitter and losses rate. The final systems and network elements are simple because they only have to do the admission control and police functions. The major problem is that it does not provide an optimal statistical multiplexing gain in case of bursty traffic because the establishment of circuits are based on the PCR. The rt-VBR needs the specification of the PCR, MBS (Maximum Bursty Size) and SCR (Sustained Cell Rate) and QoS parameters (CDV, maxCTD and CLR). It provides the same guarantees as the CBR service with an efficient use of the bandwidth, but the final systems and network elements are more complex than in CBR, because the police function is based on the SCR too. Apart from the inefficiency of the 5 bytes of cell overhead, other drawbacks of ATM are: (1) the cells are small with a fixed size, so it’s more oriented to the packet switching solution. This means that many of the deficiencies of the packet switching technology are in the cellswitching technology, particularly about the guarantees of QoS. As a consequence, many mechanisms have to be implemented: control admission, shaping, scheduling and

129

ΔΕ ΙΓ Μ

Α

resynchronization in the receptor, all at a good effective cost; (2) the problem of the CDV occurs frequently in ATM, as the cells have to be multiplexed in the switch, multiplexer or other intermediary systems, from many transmitters. The delay accumulated can be critical if the application doesn’t tolerate delays (exs: video and audio); (3) the lack of applications that use directly the ATM classes of service with distinct QoS; (5) operational cost is still high. As a consequence, the QoS in terms of delay, jitter and losses are a fundamental discussion in ATM. The support of multiple classes of traffic and the protection of their QoS, at the same time the maximization of the statistical sharing and the use of the resources, is the most difficult objective in the implementation of ATM. As was said before, the DTM technology guarantees a constant delay of transmission, low jitter, bandwidth directly proportional to the number of slots that are on the channel [6] and low loss rate. Moreover, the medium access is deterministic, so it can provide a fixed delay for the access medium. The switching is synchronous, so we have a constant switching delay of 125 µs on each hop [7]. The processing of control information occurs only in the channel establishment and disconnection phases. The queues occur in the switches only in case of clock synchronization between buses, so there is neither congestion, nor overflow. One node can sometimes transmit data at a higher rate than the rate of the channel, but as the medium access is deterministic, if the channel is established, they won´t have losses if there’s sufficient buffer capacity on the transmitter. DTM as a solution of circuit switching has the advantage that the delay during the connection is low and deterministic. However it needs the establishment of a channel before the transmission of data, so the time spent to establish the channel and the blocking probability are important aspects. The access delay will be analysed on the next section. Some mechanisms are suggested to the improvement of the establishment time of the DTM channels: (a) Block of token- the representation of a group of tokens in the same control message, decreasing the volume of messages necessary for the channel establishment and slot reallocation [9]; (b) Slots defragmentation—the average number of free contiguous blocks of slots can be small, caused by the random movement of the tokens and the variability of the needs of transmission capacity. The defragmentation scheme tries to increase the average length of free token blocks in the node (distributed control of slots) or in the server (central control of slots), so there´s an improvement on the access delay [9]; (c) fast-circuit switching establishment—in order to avoid waiting for a confirmation from the receiver to the establishment of channels, a timer-based scheme is used to reduce the access delay and makes it independent of the propagation delay. But with this scheme it is not guaranteed that there will be slots available along the whole path, so there is the risk that the channel can not be established, and hence it is not appropriate for applications with strict necessity of QoS. One of the great drawbacks pointed out about circuit switching techniques, in which is included DTM, is the lack of traffic multiplexing from distinct sources on the same channel.

130

ΔΕ ΙΓ Μ

Α

Techniques like “slot reuse” permits the simultaneous transmission on the same slot when there are disjoint physical segments. In [10] it has been shown that in a dual-bus with source/destination pairs uniformly distributed, the throughput was increased twice with this technique. In the literature we can find some methods for the sharing of slots in the DTM channels, maintainingthe guarantees of delay, jitter and bandwidth for high priority traffics. In one of them [11], the sources with low priority attached to the same controller node have permission to transmit once a time at each frame (“M” successive cycles form a frame), while the high priority source can transmit at each cycle of the channel. This method guarantees the queuing delay of zero for high priority source, if is transmitted one flow at each cycle and if a suitable bandwidth is reserved; for the low priority sources, the queuing delay only reaches a few hundreds of milliseconds if there are many low priority sources connected to the same controller node and high aggregated load. In another one [12], appropriate to be used in case of transmission of packets, that is our interest here, the high priority source, for example an ATM VBR source, can transmit whenever it wants on the channel to which it pertains and low priority sources, like ATM UBR, can transmit in the subchannels (each channel is subdivided in “M” subchannels) that are allocated to it, if the high priority source is not using it. An observation is that another low priority source can’t be served until the end of the transmission of an entire packet. This method has a drawback that is complex, and can overstep the control processing capacity of the controller node, so only some low priority sources can participate on the sharing of the slots. About the blocking probability, in [13] is presented an analytical and simulation method for the evaluation of blocking probability in relation to bus capacity and bandwidth requested by the user. The model describes eight DTM controller nodes that are trying to access a unique output port. Traffic generators are generating based on an on-off process with an exponentially distributed idle period. The active period is assumed to be a constant. Its assumed that each traffic generator is using a 90.9% capacity of its processor. This study showed that with a low blocking probability like 1%, that is acceptable in case of transmission of applications that need QoS guarantees, we must limit the number of nodes in a bus. In reality, DTM is not designed to serve one network with a thousand nodes. It is more appropriate for the control of networks in an optical environment. In [14], results point out that the blocking probability in a distributed slot control is similar to the central slot control and that the blocking probability is higher for bursty traffic and the higher the bursty, the higher the blocking probability. We can’t forget that in the case of CBR and VBR ATM connections, if there are insufficient network resources, they may be rejected and if the available bandwidth is reduced for the same reason, the network simply disconnects the CBR and VBR connections, as it is not possible to renegotiate the traffic contract. On the contrary, with DTM the renegotiation of bandwidth resources during the connection lifetime is possible.

131

The time for the establishment of a channel is very important in a DTM environment. If the channels are established for a session, we can spend resources, especially in the case of bursty traffics, but we can provide a QoS guarantee during the session. On the other hand, if we establish a channel per packet, we can have a better utilization of the bandwidth but it can introduce additional delays. The argue here for the establishment of a channel per session is that we believe that applications like video and audio transmission will be more common in a short future and consequently the sessions will require large bandwidths and will be of large duration. 5.3.3

Perfomance Analysis of ATM and DTM

ΔΕ ΙΓ Μ

Α

In [15] an interesting investigation was done in respect to an Internet MCI backbone traffic and it revealed that the TCP traffic is dominant in a mix of traffics (95% and more of total bytes, 85%-95% of total packets and 75%-85% of the total) in an international link and (95% of the overall bytes, 85%-90% of the overall packets and 70-75% of the overall flows) in a US domestic link. Based on these results, TCP will be the transport protocol analysed here. The TCP protocol provides a reliable transfer of data using a window-based flow and error control algorithm. The VBR ATM class performs quite well with TCP except in cases where utilization is high and MBS is too small, because a large number of frames are partially tagged [16]. The CBR minimizes losses end-to-end, pushing the queue to the edge device, where the queue depends only on the round trip times and switch congestion avoidance scheme, and not on the number of connections. But we have to remember that bursty characteristic of TCP flows doesn’t have benefits from the statistical multiplexing in case of CBR. As DTM might only have congestion on the edge devices, its behaviour is similar to the ATM CBR, but in the former the queue only depends on the round trip times. 5.3.3.1

Throughput

The TCP maximum segment size (MSS) for this study is 512 bytes. The TCP data is encapsulated over ATM as follows: a set of headers and trailers are added to every TCP segment. We have 20 bytes of TCP header, 20 bytes of IP header, 8 bytes for the RFC1577 LLC/SNAP encapsulation and 8 bytes of AAL5 (ATM Adaptation layer), a total of 56 bytes. Hence, every 512 bytes becomes 568 bytes. This payload with padding requires 12 ATM cells of 48 data bytes each. The maximum throughput of TCP over ATM is (512 bytes/(12 cells x 53 bytes/cell))=80.5%. In DTM there are several proposals for the frame format to be used to multiplex packets on top of DTM channels, but the current implemented environment uses a 64 bit trailer after each TCP/IP packet (figure 1). With a 512 bytes MSS, will be transported 520 bytes on the medium (65 slots), where 472 bytes are of data (59 slots) and 6 slots of overhead, so we have 90% of maximum throughput. But in DTM there’s the overhead of the control messages. For example, 40 nodes attached to a bus of 622 Mbps, each one with one control slot, we have 3.3 % of overhead, with a final maximum throughput of 86.7%. Obviously, the overhead of

132

Figure 1: TCP/IP

Α

encapsulation over DTM

ΔΕ ΙΓ Μ

control messages depends on the number of nodes per bus, the capacity of the bus and the number of control slots per node. We can conclude that meanwhile DTM has the overhead of control messages, if the factors that affect it are well-dimensioned, we can have lower overhead than ATM as in the last example. A mechanism called “token block” [9] can represent a group of tokens in the same control message, decreasing the quantity of messages in the establishment of channels and reallocation of slots, and consequently decreasing the overhead caused by control messages. In [2] the throughput of DTM was analysed as a function of the bus length, and the conclusion is that the throughput is independent of the bus length, even though the time to propagate the control messages can increase with the length of the bus. In respect to the load, the throughput increases linearly with the load; at a higher load, we have frequent slot reallocation, so some transfers are rejected and the throughput increases slowly and finally at a higher load the signaling capacity doesn’t support it and the throughput doesn’t increase. But again, we say that we can improve the utilization of the DTM channels, establishing them for whole a session, instead of per packet and multiplex high priority flows with low priority flows. 5.3.3.2

Delay and Jitter

The recommendation of ITU-T I.356 [17] gives the worst guess case for a 27500 km connection, passing 29 ATM systems. Here we are only interested in ITU-T QoS Class 1, that is appropriate for real time services. QoS Class Class 1

CTD 400 ms

CDV (2 points) 3 ms

CLR all cells 3.0 E -7

Table 1: ATM QoS classes according to I.356 [17]

133

ΔΕ ΙΓ Μ

Α

The DTM access delay is composed by : (a) node controller processing = 5 µs; (b) finding and allocating free tokens depends on the kind of slot control but on average it is 100 µs. For a distributed control, there isn’t the time to send and receive slot requests. For central control we have 10 µs before the message hits the medium, physical distance 10 µs, 10 µs before the replay hits the fiber and 10 µs more to the physical distance; (c) waiting for the first available control slot 50 µs; (d) waiting for the first allocated data slot to be filled with user data 62.5 µs and finally, waiting in the queue at the input to node controllers, that for high priority traffic is zero, if one message is generated at each cycle time [9], giving a total average of access delay of 0.217 ms. The average delay on each hop is around 125 µs, the fundamental delay on each hop is the time between an incoming slot and the scheduled outgoing slot, that is on average 62.5 µs. Having as on the table 1, 29 DTM hops along the path, we have around 3.625 ms of transfer delay, considering that we are using a fiber medium and the velocity of propagation is irrelevant. We have a total of slot transfer delay around 3.842 ms. Here we are not mentioning the worst case, but the average in case of a normal load in the network. The total slot delay is extremely lower than in an ATM environment with 29 systems. The jitter is almost non-existent because there isn’t congestion in the hops, and DTM isolates one channel from another. 5.3.3.3

Losses

In DTM the looses are controlled in the queues on the transmitters, so it is only necessary to implement the correct buffer algorithm. For high priority it is not expected to have losses, if the controller node has capacity to handle efficiently the high traffic flows and the channel capacity is adequate. In ATM CBR and rt-VBR the loss is guaranteed and low (see Table 1). 5.3.3.4

Complexity

The CBR ATM service is not as complex because the queues at the switches used to be small and the end systems only have to do the admission control and policing functions, but the user has to specify the PCR and CDVT and some QoS parameters, indicated before. The rtVBR is slightly more complex because the user has to know precisely the PCR, SCR, MBS, and like CBR some QoS parameters, the admission control decision and billing is difficult because the accumulation of some values is not simply the sum of them and more buffering control at the switches is necessary than with the CBR service. We can say that the rt-VBR is of a total medium complexity, meanwhile CBR is of a total low complexity. The complexity in DTM is at the controller nodes. The switches are very simple because there is only a cycle queue inside them and they only have to copy slots from one bus to another one. The complexity at controller nodes depends on the choice between a distributed or a central controller. In the case of a distributed controller, the complexity is also distributed among the nodes, because each one controls the slot allocation and reallocation. In the case of a central control, it is more complex because the scheme of allocation and reallocation in a

134

bus is its responsibility but the other ones are very simple because they only have to control the end systems connected to it. The admission control and billing are very simple ecause they depend only on the value of the bandwidth requested. 5.3.4

Integration of IETF QoS Models with ATM and DTM

ΔΕ ΙΓ Μ

Α

Traditionally, the IP services give the same quality of service for all packets. The IETF IntServ/RSVP model extends this model permitting the applications to elect the appropriate service for them and permitting the network to have a better control of the service offered to the flows [18]. The DiffServ (Differentiated Service) [19], recently proposed by IETF, gives simpler QoS guarantees, which are mainly qualitative, because it assumes that some applications don’t need an explicit guarantee of QoS; adequate traffic engineering and classification of flows by priority are sufficient for the necessary functionality. So the DiffServ model solves the problem of scalability of the IntServ model. As the IntServ and DiffServ are expanding in the Internet world, it’s crucial to have an integration of these QoS models with the QoS provided at ATM and DTM, having more functionality in terms of QoS. 5.3.4.1

Integration of IntServ/RSVP Model with ATM and DTM

Many of the RSVP (Resource Reservation Protocol) parameters can be mapped directly to the ATM Traffic parameters, which makes the integration simpler. As we are interested in strict guarantees of QoS, the IntServ guaranteed service (GS) model is adequate [21]. The GS model used to be mapped to the CBR ATM Service, where the PCR is the peak rate ‘p’ and the CDVT is set to b/p. But there are some incompatibilities with the CLR, parameter that IntServ/RSVP doesn’t signal. Other differences are listed on table 2. As we have seen some functions of the IntServ/RSVP model are not supported by ATM. Although the current ATM facilities can emulate these functions, for an efficient support of this IETF model, ATM has to be modified to support principally the dynamic QoS renegotiation and the multicast reservation heterogeneity. DTM integrates gracefully with the IntServ/RSVP model as many of its functions can be mapped directly and the traffic control is automatic. The RSVP protocol can be used here as the bandwidth signaller (the GS model peak rate parameter ‘p’ is the quantity of slots to be reserved) to the establishment of QoS DTM channels. To make a comparison with ATM in respect to the integration with the IntServ/RSVP model, table 3 lists for DTM the same parameters as table 2 did for ATM. The RSVP integrates nicely with DTM, except in respect to the multicast heterogeneity reservation. A possible scenario of the RSVP and DTM integration can be seen in figure 2.

135

5.3.4.2

Integration of DiffServ Model with ATM and DTM

One of the differences of the DiffServ model and ATM, is that the former defines a qualitative QoS, while the latter supports the qualitative and quantitative QoS. Here our interest is the strict QoS, i.e. the quantitative definition. The end-to-end QoS of ATM is defined in a DiffServ model by the concatenation of traffic conditioners and PHBs (Per-Hop Behaviour) along the path. ATM

Dynamic reservation

CBR and rt-VBR don't support it. It's necessary to bring down the channel and establish another one with the new parameters

Reservation lifetime controlled by the application

Controlled by inactivity of the VCs The heterogeneity of reservation of the IntServ/ RSVP contradicts the ATM native homogeneous multicast VC tree. In [20] there's a proposal of how to configure the RSVP styles to ATM VCs.

ΔΕ ΙΓ Μ

Multicast heterogeneity reservation

Α

Characteristics of IntServ/RSVP

Aggregation

ATM Aggregation model [20]

Traffic Control

It's necessary in case of congestion and as a demand control

Table 2: Interaction of IntServ/RSVP with ATM

The DiffServ PHB EF (Expedited Forward) [23] guarantees the latency, losses, jitter and an assured bandwidth basically by provisioning, so it is the appropriate PHB to offer a strict QoS service. The traffics on this “Premium” service have to be aggregated based on the DiffServ DSCP (DiffServ Codepoint) bits and isolated from other traffic, defining exclusive ATM VCs for them. The guarantees are provided by the scheduling algorithms and priorities. The ATM CBR service is the adequate mapped service as it can provide smart scheduling and police algorithms on the border of the network [22], where each flow can be seen and it guarantees QoS. As both have strict control of traffic descriptor, violation results in discard and the highest priority queue. The VBR service is appropriate too but can be more complicated as it enforces priorities and guarantees inside the network, just where the queues are so long and the traffic is not seen isolated. In the same manner as ATM, DTM supports the qualitative QoS. DTM guarantees the bandwidth end-to-end or inside a DTM domain, so the DiffServ model can be extended end to end concatenating traffic conditioners and PHBs. An important observation, is that DTM, as a circuit switching technology, has the transfer delay, jitter and losses fixed as soon as the

136

DTM

Dynamic reservation

Dynamic reallocation of slots

Reservation lifetime controlled by the application

The DTM channels lifetime does not have any control so the application has the liberty to control it

Multicast heterogeneity reservation

Like ATM, multicast DTM traffic is naturally homogeneous

Aggregation

Aggregation from different RSVP sessions, for example based on Tspecs and IP destination can be done by short-cuts DTM

Traffic Control

The traffic control is done inherently by the token control and synchronous time slots

ΔΕ ΙΓ Μ

Table 3: Interaction of IntServ/RSVP with DTM

Α

Characteristics of IntServ/RSVP

channel is established. Therefore, the differentiation of packet treatment, objective of the DiffServmodel, will concern only the medium access at the edge device. The mapping of EF PHB to DTM service is direct. It’s possible to define a high priority class correspondent to the EF DSCP bits, where the aggregated flows with this priority only share

Figure 2: DTM Shortcut

Establishment

137

its slots if they are not being used, providing a bandwidth guaranteed and a minimum access delay. Here it is necessary to have a well dimensioned bandwidth to avoid a situation where channels cannot be established due to lack of resources, but we can not forget that DTM has the additional facility of dynamic slot reallocation. To avoid queues, at the edge of the network, it has to implement traffic conditioners (police, scheduling) to maintain the demand below the output traffic. The loss guarantees can be supported by an adequate buffer dimension at the edge of the network. 5.3.5

Conclusion

ΔΕ ΙΓ Μ

Α

The ATM technology has its merit with the provision of a complete QoS support for a variety of traffic but it has to do per cell processing and queuing controls in the switches, generating performance problems. DTM is a fast circuit switching technique that guarantees latency, small jitter, traffic isolation and flexible resource reservation. And using some methods, mentioned before, it can improve the access delay and bandwidth utilization. The telecommunication community bets that the future is the IP applications on top of physical pipes like SDH/SONET, but some of their drawbacks like the static hierarchical structure and the lack of multichannel interface, make it still too expensive. DTM doesn’t provide a complete QoS service but for IP applications with strict needs of QoS, this can be a simpler and cost effective solution that has a good interaction with the IETF IntServ and DiffServ QoS models, providing a better QoS functionality.

References [1] [2]

[3] [4] [5] [6]

[7] [8]

[9]

138

McDysan D. E. and Spohn D. L.: “ATM—Theory and Application”. McGraw-Hill. 1994. Bohm C., Hidell M. et al: “Fast Circuit Switching for the Next Generation of High Performance Networks”. IEEE Journal on Selected Areas in Communications, Vol.14, No. 2. February 1996. Sathaye S. S.: “Traffic Management Specification”. ATM Forum/TM4.0. April 1996. Kenney J. B.: “Traffic Management Draft Specification”. ATM Forum/TM4.1. February 1999. Fahmy S. et al: “Quality of Service for Integrated Traffic over ATM Service Categories”. Computer Communications special Issue on enterprise networks. 1999. Bohm C., Lindgren P. et al: “Resource Reservation in DTM”. Proc. 1st IEEE Symposium on Global Networking , Cairo. December 1993. Lindgren P.: “A Multi-Channel Network Architecture Based on Fast Circuit Switching”. Ph.D. Thesis. Royal Institute of Technology, Sweden. May 1996. Gauffin L., Hakansson L., and Bjorn P.: “Multi-gigabit networking based on DTM. A TDM medium access technique with dynamic bandwidth-allocation”. Computer Networks and ISDN Systems 24 (1992), 119-130. 1992. Ramfelt L. H.: “Performance Analysis of Slot Management in DTM Networks”. Technical Report TRITA-T. Dept. of Teleinformatics, KTH, Stockholm. January 1996.

Garrett M. W. and Li S. Q.: “A study of slot reuse in dual bus multiple access networks”. Proceedings of the Conference on Computer Communications INFOCOM, San Francisco, California. June 1990. [11] Antal C. and Biró J.: “Analysis of a Time Division Multiplexing Method with Priorities”. IFIP WG7.3, Performance’99, Istambul, Turkey. August 22-26, 1999. [12] Antal C.: “Servicing Bursty Sources efficiently via a Fast Circuit Switched System”. International Conference for Computer Communication’97, pp. 19-21, Cannes, France. November 1997. [13] Chang C. and Nilsson A. A.: “Analytical Model for DTM Access Nodes”. Technical Report TR-98/11, Dept. of Electrical and Computer Engineering, NCSU, N.C.. April 1998. [14] Chang C. and Nilsson A . A .: “Performance Evaluation of DTM Access Nodes”. Technical Report TR-98/11, Dept. of Electrical and Computer Engineering, NCSU, N.C.. November 1998. [15] Thompson K. et al: “Wide-Area Internet Traffic Patterns and Characteristics”. IEEE Network. November/December 1997. [16] Hellstrand F. and Veres A .: “Simulation of TCP/IP router traffic over ATM using GFR and VBR.3. ATM forum/98-0087. February 1998. [17] ITU-T Recommendation I.356: “B-ISDN ATM layer cell transfer performance”. Geneva. 1996. [18] Braden R., Clark D. and Shenker S.: “Integrated Services in the Internet Architecture: an Overview”. RFC1633. June 1994. [19] Blake S. et al: “An architecture for Differentiated Services”. IETF RFC2475. December 1998. [20] Crawley E. et al: “A Framework for Integrated Services and RSVP over ATM”, RFC 2382. August 1998. [21] Shenker S., Partridge C., and Guerin R.: “Specification of Guaranteed Quality of Service”. RFC2212. September 1997. [22] Bragg A .: “Addendum to TM 4.1—Enhancements to support IP Differentiated Services and IEEE 802.1D over ATM—Draft”. July 1999. [23] Jacobson V. et al: “An expedited forwarding PHB”, RFC2598. June 1999.

ΔΕ ΙΓ Μ

Α

[10]

139

5.4

Active Networks

Arturo Azcorra Universidad Carlos III de Madrid, Spain

ΔΕ ΙΓ Μ

Α

Much effort has been placed on developing a packet (cell) switched network technology that provides a continuous range of guaranteed transfer rates (not only a constant scalar rate, but also variable statistical rate), while guaranteeing at the same time a low delay and delay jitter. Frame Relay, ATM and more recently Integrated/Differentiated Services Internet are examples of the interest of the global networking industry in guaranteeing QoS within packet networks. However, much lesser effort has been placed in developing a networking technology that provides a broad range of functional services. The limitations of current networking technologies to allow fast development and deployment of new network services were identified in DARPA along 1995 and have led to a recent proposal of a new network model called Active Networks. In this model the nodes provide an execution environment over which the code used to process a packet is executed. The code may be included in the packet itself or pre-loaded as a result of a previous packet of the same class. The objective is a network technology that allows the fast design and deployment of new network services without requiring the modification of the network nodes. The key elements of the different Active Network approaches are: the Network API, the Code Distribution Technique and Security techniques. The network API is a virtual (routing) machine that interprets a specific language. The expressive power of the language is balanced against the safety of the operations performed by code injected by the users. The current alternatives range from very simple languages, that barely allow the user to select parameter values over a fixed set of operations, to complete languages Turing equivalent. Some reasonable balanced proposals call for powerful languages, but with restrictions that simplify the safety analysis on the code such as prohibiting the usage of loops and pointers. Besides the expressiveness of the language, another issue is the possibility, or not, of storing state information in the Active Nodes. Again, permanent (or soft-state) storage in the nodes allows the development of a broad range of services, but implies that some technique must be provided to perform a fair and optimal allocation of resources among the users. The last aspect related to the network API is its support for the composition of basic-services, referred to as “components”. A flexible and simple support for the dynamic combination of components to easily produce richer network services is considered one of the most important aspects for the success of a network API. In respect to Code Distribution, there are two main approaches. The first one is the discrete or out-of-band approach, and the second is the integrated or in-band approach.

140

ΔΕ ΙΓ Μ

Α

Under the discrete approach the code is loaded on the nodes under the responsibility of the network administrator. This has the advantage of off-line control on the safety of the programs, but a big drawback is that it concentrates all the flexibility on the network provider hands. Under the integrated approach, each packet injected by the user “carries” the code needed to process it. This can be accomplished in two different ways: embedded-code or demand-loading. The embedded-code technique implies that the code is really within the packet, and therefore is appropriate for “rare” packets that require simple but specific processing. In the demand-loading technique the code is automatically loaded in the node when the first packet of a given “class” is received. The code remains then within the node in order to process all subsequent packets that belong to the same “class”. The usual way to load the code is by requesting it to the node from which the packet was received, inasmuch as the packet has been forwarded by it and therefore this node should have previously loaded the code. Embedded-code and demand-loading can be combined in a single Active Network framework, as they are more complementary than alternative techniques. The Security area is the one considered less developed on the AN field. Security implies first that only authorized users access the network, each with its corresponding level of resources, and solutions are based on relatively conventional technology such as digital signatures and access lists. Second, it is also required that authorized users, either maliciously or not, do not cause malfunctions to other users or to the complete network. This aspect is typically denoted by safety or robustness, and requires the development of new paradigms. Distributed resource measurement, fair resource allocators, and code verifiers are some of the algorithms and techniques still to be developed. DARPA is currently funding several projects, which involve various Universities and companies such as MIT, UCLA, Univ. of Columbia, Univ. of Pennsylvania, BBN, TASC or TIS. These projects are focusing in different aspects of active networks technology such as: execution environments, active node operating systems, specific programming languages, new cryptographic techniques and security issues and potential active applications (i.e. Reliable multicast, active firewalling) Nowadays, two execution environments seem the most relevant to investigate possible applications of active technologies: • PLANet, developed at Univ. of Pennsylvania. This active networking testbed is based on PLAN, a programming language especially designed for active networks. PLANet supports both active packets; providing per-packet customizability and active extensions that allows modifying nodes functionality by downloading and dynamically installing Ocaml bytecodes. The last version is the 3.2 and was delivered in August 1999. New security mechanisms have been added in this version, providing access control at authentication time via namespace-adjustment. • ANTS, developed at MIT. ANTS is a Java based toolkit and provides a node runtime that can participate in a active network and a protocol programming model that allows users to customize the forwarding of their packets. The last version is the 1.2 and was delivered in

141

November 1997. ANTS is the most commonly used due to its simple programming interface and the fact that the language used to program the active network is Java.

References

D. Clark. The design Philosophy of the DARPA Internet Protocols. Proc. Of ACM SIGCOMM’88, August 1988. D.L. Tennenhouse, J.M. Smith, W.D. Sincoskie, D.J. Wetherall and G.J. Minden. A Survey of Active Network Research. IEEE Comunications Magazine, pp. 80-86, January 1997. D.L. Tennenhouse and D. Wetherall. Towards an Active Network Architecture. Proc. Multimedia Computing and Networking 96, MMCN 96, San Jose, CA, SPIE, January 1996. D. Wetherall. Developing Network Protocols with the ANTS Toolkit. August 1997. D. Wetherall, J. Guttag and D.L. Tennenhouse. ANTS: A Toolkit for Building and Dynamically Deploying Network Protocols. Submitted to IEEE OPENARCH’98, San Francisco, CA, April 1998.

ΔΕ ΙΓ Μ

[1]

Α

The node operating system area is also a very hot topic as showed by the presentation of the Janos node OS at the Active Network Demo Workshop sponsored by DARPA (Virginia, USA, September 1999). Janos is a Java-oriented active network operating system, developed in the University of Utah that intends to provide a solid, resource-aware foundation for future active networks. Janos provides many of the interfaces designed by the active networks Node Operating System Committee, but with a Java binding. The European Union is also likely to fund several research projects on Active Networks under the IST program. However, as of the date of the production of this document, the projects are technically approved, but still under negotiation and therefore it is not possible to provide formal detail about their content.

[2] [3]

[4] [5]

142

5.5

Advanced Collaborative Services over Broadband Networks: the ISABEL Experience

Tomás P. de Miguel, Juan Quemada, Santiago Pavón, Joaquin Salvachúa, Tomás Robles, Gabriel Huecas, Héctor Velayos, Eva Castro. Department of Telematic Engineering (DIT), Technical University of Madrid (UPM), Spain.

5.5.1

Introduction

ΔΕ ΙΓ Μ

Α

Effective group work is the key to the success for most organisations. One barrier to group work in a global economy is the geographical separation among team members, and hence the need to travel long distances. Fortunately, the unprecedented growth of the communication networks is quickly reducing this barrier. Many activities, which in the past have required physical presence and direct interaction among participants, can be performed now in a distributed fashion. This is possible thanks to new information technologies such as CSCW [1,2] (Computer Supported Co-operative Work), interactive multimedia services or broadband communications. Technologies aiming at supporting the collaboration among individuals or groups are identified under the term GroupWare. Asynchronous interactions, which do not require physical presence of interacting persons, have matured during the last years. Very successful examples of asynchronous GroupWare exist. LOTUS Notes [3] is considered probably the most successful commercial product in this area. The Internet and many of its application can be considered as GroupWare technologies to some extent. New collaborative services allowed users geographically dispersed to be telepresent in the same virtual information space without ever leaving their own location. However, this synchronous interaction is not a mature field. The necessity of using a large amount of bandwidth and the necessity of having a very reliable communication service in order to achieve a good quality synchronous interaction have introduced additional difficulties for putting up commercial services [4,5]. Nevertheless the availability of large broadband infrastructures is enabling the design of large scale services which are providing a better understanding of the role which synchronous interaction will play in the communication services of the future. There seemsto be little doubt that new collaboration technologies will revolutionise our daily activities, not just in our workplaces, but also in our homes, schools and other social areas [6]. In this paper, we introduce fundamental concepts and trade-offs in group-collaboration services, focusing on the event and floor management aspects. We use the term groupcollaboration to address the services required when many users try to access and manipulate objects synchronously in a shared workspace. The paper describes the ISABEL CSCW system designed within European broadband

143

programs RACE and ACTS to support the creation of innovative group-collaboration services. ISABEL has been used to distribute conferences like ABC (Summer School on Advanced Broadband Communications, from 1994 to 1997) in NICE, university seminars in BONAPARTE or technical meetings in TECODIS. The paper ends with the most relevant experiences in the field of distributed conference over heterogeneous broadband and narrowband networks. 5.5.2

Group-collaboration models

Α

Any group-collaboration system must include the following facilities: • Connecting everybody either synchronously or asynchronously, • Structuring communication, • Systematising group process, • Facilitating deliberation on a topic and • Providing participants with whatever information they need whenever they need it.

ΔΕ ΙΓ Μ

New models are focused on synchronous interactions developed during events. A collection of users connecting from various locations to work together on a shared data or using conferencing components to communicate ideas is called an event. Events can consist of individuals or groups sharing specific interests. Individual events means collaboration between two persons only whereas group collaboration concern any interaction at a distance between groups fully or partially separated. The event is becoming the central concept of a synchronous interaction. A distributed event is a synchronous collaborative interaction where physical presence is substituted by telepresence with the use of advanced IT such as CSCW and communication technologies. In many application domains, the remote collaboration is as effective as direct presence. Thus travel or movement of persons can be avoided or reduced with substantial benefits for the overall productivity of any organization [7]. Three concepts are used to characterise any distributed event. Telepresence is defined as the achievement of sense of presence of the remote participants by means of audio, video or virtual reality transmission. The telepresence paradigm used bi-directional teleconference, with virtual representations of real people, to create a sensory environment that is dynamically controlled by the actions of the individuals, so that the virtual environment appears real to the user. Shared Workspace is a shared media space, which enables users to achieve a common view and understanding of the objects or ideas subject of the collaboration. Shared workspace applications aim to create at a distance the computer mediated sharing information as well as sharing the actual products on which the participating individuals are working. We say that the workspace is shared if it satisfies the conjunction of two functions: joint viewing and teleoperation. Joint viewing is copying information to one or several remote displays. Teleoperation, unlike passive display, provides tools to participants to interact with and comment on the joint view. We define interaction mode as concrete shared workspace

144

ΔΕ ΙΓ Μ

Α

scenario. A group-collaboration service can be defined as a sequence of one or more interaction modes provided during a session. Interaction control is the mean by which an ordered collaboration is achieved in a conference with remote participants. Interaction control is particularly important for tightly coupled sessions, which require explicit member registration or follow a more formal agenda. Interaction control can be deployed with one or more human moderators in a session, or by the system using prediction, filtering and reservation to respond to floor requests for a shared resource. Interaction control uses interaction mode primitives to place temporal permissions on resources to mediate concurrent access. For example, the request of an interaction mode can open audio and video streams of two sites or it can open the audio of all sites, but allow a component interaction from only one site. Control should be defined at service definition time. Various methods to implement interaction control have been proposed within the last years. They can be narrowed down to three criteria: • Token passing between sites used at each site to indicate the Control State for a remote resource. For example, to allow the access to a shared whiteboard. • Control is centralised and static. Only one site or a reduced set of sites are allowed to control the interaction during the event. For example, in a big distributed conference the main site is devoted to co-ordinate the individual management of each site to obtain a coherent global workspace. • Control is fully distributed. All sites involved in the conference are allowed to activate interaction modes at any time. All sites are free to open or close their media streams. For example in a distributed meeting, the control is distributed and permissions are distributed using audio.

Each particular group-collaboration service needs a different configuration of the three elements in order to provide the desired interaction. The way in which previous parameters are particularised defines an activity. An activity is the definition of a particular combination of interaction modes devoted to provide a concrete service type. We have identified two basic activity types: teleconference and telemeeting.

5.5.2.1

Teleconference model

A teleconference service is defined as the realisation of conferences, workshops or seminars in a distributed fashion. It permits the interconnection of physically separated auditoriums or lecture rooms in order to create a unique virtual auditorium where participants can interact with any other participant in any auditorium. A teleconference is clearly a homogeneous event where all the participants must have the same view of the distributed conference. In this service the usual type of interactions among participants are lectures, talks, demonstrations, panel, discussions or question sessions (Figure 1).

145

Figure 1.

Α

Examples of interaction modes: panels, discussions, questions and presentations

ΔΕ ΙΓ Μ

Any teleconference interaction mode supports N active and M passive participant sites. Active sites are the active members of the shared virtual workspace and are allowed to speak. However, passive sites are watching the conference and do not have the opportunity to speak. The set of active sites is defined for each interaction mode instantiation. Therefore, during a conference a site is sometimes active and sometimes passive. Interaction control is the means by which the conference changes from one interaction mode to another. In teleconference, interaction control is centralised. It is inspired in the auditorium control room where a central control and management point exists. The Event Control Center is responsible for creating and controlling the distributed conference. It is usually located in a control room in one of the sites. Sometimes the event control center gives interaction control partially to one site. For example, during questions periods the moderator site is free to accept questions of any site. When a question is accepted, the question site is added to the active set in combination with the speaker’s site. 5.5.2.2

Telemeeting model

The telemeeting service is related to all collaboration types between reduced groups with more distributed control than centralised teleconference services. Ideally, a telemeeting service should interconnect geographically disperse meeting rooms where the attendees can interact among them as if they were in a single room. There are many kinds of meetings, which are potential candidates for being transformed into a distributed meeting and not all can be covered with a single service. The telemeeting service covers thinks like teleclassroom or telework. A teleclassroom interconnects physically separated lecture rooms in order to create a

146

ΔΕ ΙΓ Μ

Α

unique virtual lecture room where all attendees can follow the lecture and interact with the lecturer independently of the location. This service creates a homogeneous distributed event where all the participants share the same view of the class. The control is simple enough to allow the teacher to give the lecture while operating the system at the same time [8]. Telework covers all synchronous groupware facilities related to the most conventional collaborative environments targeted at desktop interconnection. It provides just a set of components, which can be used by the teleworkers to exchange information among themselves. This collaboration type is focussed in real time shared components: editors, whiteboards or applications in general [9]. The telemeeting service supports a conventional chaired working meeting. Such a meeting has two conflicting requirements. It must support, on one hand, the chairperson running the meeting and provide him the instruments to control the interaction modes when needed. On the other hand, it must facilitate an unplanned and easy change of interaction modes as decided by participants, in order to encourage active involvement of the participants in the meeting. Therefore the interaction control of the telemeeting shall be in the meeting room and not centralised in a manager separated from the rest of participants. The telemeeting falls into the category of homogeneous event where all the participants must have the same view of the event. Its main target is interconnecting meeting rooms, but it can be also used to connect directly from a workstation to the distributed event. 5.5.3

A description of ISABEL

ISABEL [10] is a CSCW application designed within the European broadband programs RACE and ACTS to support the creation of innovative remote collaboration services in the area of synchronous group-collaboration. By group-collaboration we mean interconnection of people located in auditoriums or various kinds of rooms, using a workstation based CSCW application, whose display is shared by all site attendees (projected on a large screen if the number is big). The service platforms created using ISABEL have supported the realisation of any group synchronous collaboration model. 5.5.3.1

The ISABEL service model

An ISABEL Event is a concrete group collaborative service modelled as an activity, which involved all, or part of participating sites. A Site is an access point to the virtual workspace for one or several attendees located in the room or a big auditorium. Several types of sites can be differentiated [11]. Most sites are Interactive Sites (IS), which are associated with maximum interaction functionality and standard interaction control permissions. Most interaction modes apply to IS because event attendees are distributed over all connected IS. We defined an Open Event when any ISABEL site is free to connect with the event, whereas a Closed Event allows the connection of only a reduced set of sites given during event definition. Sometimes special privileges sites are considered. For example, in teleconference and teleclassroom only one

147

ΔΕ ΙΓ Μ

Α

site holds lectures. This site has been called Main Interactive Site (MIS). A MIS has the functionality of any IS but some interaction modes give it a special configuration: its video is bigger than the rest or is allowed to make a presentation. This is because usually they should provide a more reliable network access. There is a special IS devoted to start the event. A Master Site (MS) is an interactive site, which is the first site connected to the event. (Sometimes the MS is not an interactive site. It is possible to configure a site as dispatcher of ISABEL conferences. For example, when a Web Server is used to co-ordinate the connection phase.) When an IS wants to be involved in an event it contact the master site to be authenticated, check its participation permissions and receive the event description. After connection phase, the site is included in the event group as IS with a particular set of roles assigned. Each event has its particular set of roles defined in the activity. For example, in a teleclassroom one site has a lecturer role and the rest the attendee role. Therefore, the site defined as lecturer is able to activate some interaction modes that are forbidden for attendee sites. There are roles common to many activities. For example, in teleconference the centralised interaction control is a role defined in all activities with one centralised and static control. ISABEL provides sophisticated interaction modes to help advanced conference control interface (Figure 2). Figure 2: The global Control Panel

In homogeneous activities, with control fully distributed interaction modes, activation can be performed in a more natural way. For example, in telemeeting all interaction modes are available to all participant sites. All sites have the same view and the same capability of requesting resources and roles directly from a simple control panel (Figure 3). This activity does not use sophisticated protocols to transmit interaction control; a simple audio communication between participants is enough to pass through a sequence of interactions.

Figure 3: The telemeeting control panel

148

When a conference is open and distributed in broadcast way, it is possible to attend the conference only in receiving mode. A Watch Point (WP) is a site able to receive event information, however it is not included in the event group and it is not able to send information to the rest of participants. In video on demand services, attendees use WP to receive the programme. To allow such kind of services ISABEL provides tools to record any event. The ISABEL Grabber (IG) is a special kind of site, similar to WP, devoted to record all information received during an event and store it in a server. After the event, users can playback the event from the Events Server, connecting its workstation as a WP. 5.5.3.2

The ISABEL architecture

ΔΕ ΙΓ Μ

Α

ISABEL has been designed using a layered approach with the goal of being modular and easily updateable, as shown in the left part of Figure 4. ISABEL provides two different parts in each layer, a control related part and a shared media part. The system is structured in three basic layers: the user interface, the conference control and the distributed object layer. These layers have been constructed over a standard TCP-UDP/IP service [12]. The right part of the figure provides a more detailed view of the interaction between the control stack and the media stack. A general conference manager is devoted to set-up the event and takes care of sites group management. It implements the management policy of a given service controlling the local managers. The communication between the media components is always performed through the local managers.

Figure 4: The ISABEL architecture

The User Interface Layer defines the interaction control between the user and all application elements. It has been implemented using TCL-TK. Each operation mode of ISABEL has a different user interface. The interface of the control part provides access to the management

149

Α

Figure 5: Data traffic and network traffic

ΔΕ ΙΓ Μ

capabilities, either global or local. The interface of the shared media part is the screen of the projection WS. The Conference Control Layer is the real ISABEL kernel. It is a distributed object mainly devoted to provide the real time conference control. The Conference Control Layer is also devoted to allow the interconnection of the User Interface Layer with the isolated and distributed components. The Component Layer provides access to the individual media component managers. It is in this layer where the flows of the different multimedia streams are established. The media components are dynamically configurable in order to allow the change of interaction modes required by service operation. Depending on the role assigned by the management agent to a media components in a given interaction mode, the components can be a traffic source, traffic sink or both. Finally, the Communications Layer is a Transport Network that provides stream multiplexing over standard TCP/UDP protocols. Conferences with many participants can only make effective bandwidth usage by using multicast facilities. This layer allocates the different information streams to TCP or UDP depending on bandwidth demands. The data traffic generated by ISABEL is therefore generated by many independent and variable rate sources (Figure 5). However, the overall traffic is sent to the network as only one source, aggregated of all the individual sources. The overall traffic generated has a complex pattern and shape, and is not well suited for transmission across existing networks. This is the reason why a special network agent (the ISABEL Network Adapter) has been added to aggregate the traffic coming from the various sources and to adapt the traffic shape and rate to the requirements of the network service available. This network agent is called the ISABEL Network Adapter (INA). The previous architecture provides a very flexible framework, which allows building different kinds of distributed CSCW configurations. This architecture has been implemented on a SUN WS with UNIX. The X window interface has been used. Special hardware boards

150

providing ATM connection and video compression are also used. ISABEL has been ported to Silicon Graphics and recently to LINUX. 5.5.4

Set-up services over heterogeneous networks

ΔΕ ΙΓ Μ

Α

ISABEL is based on TCP-UDP/IP. It has been designed to support sites interconnection through heterogeneous networks, from narrowband (like ISDN or standard Internet) to broadband networks (like ATM or asymmetric satellite connections) and from unicast point to point to multicast multipoint connections. The ISABEL Network Adapter (INA) [13,14] is the transport agent for the ISABEL application providing an additional layer in the software structure of the application. None of the ISABEL components sends its data directly to the network. Instead, they all rely on having the INA do it for them. ISABEL isolates data transportation (devoted to INA) from processing. INA is related to all multimedia information distributed between group members during the meeting. INA is mainly focused in data flow information providing the following functions: • Application level traffic shaping to fit a given bit rate. This feature improves the usage of bandwidth drastically and decreases the amount of packet drops. It transforms VBR into CBR like at application level. Therefore, eliminates the buffering required in the network to cope with traffic bursts. It also sorts out application traffic to reduce the jitter of the most time sensitive media. • It supports a wide range of bit rates: from very low (128 Kb/s) to very high (10Mb/s and even more) rates. It allows working with most used network profiles. • It enables internetworking between users connected through multicast and users connected through any unicast network. This is necessary for satellite and ISDN networks which require high link efficiency, where it is not convenient to split the capacity between unicast and multicast, or in cases where tunnelling IP multicast over IP unicast is not possible. • It supports flexible data service pattern specification. Service differentiation for each component: priority and required packet discarding policies, fragmentation, etc. Packet scheduling is developed according to the specified service pattern of each component data stream and preserving the negotiated bandwidth. Packet scheduling is performed through an intelligent packet discarding that allows reducing the bandwidth of a highquality multimedia data flow by a given factor by dropping lower priority packets. This operation is performed preserving the integrity of the application; e.g. reducing the performance of secondary components (keeping the functionality) to prevent the degradation of primary ones (usually the audio stream). • It can work as an autonomous application flow distribution. ISABEL Network Node (INN) has become a complex application router to connect certain remote users with special network characteristics with the rest of meeting users. It minimises copies when a group has to be linked from one site and multicast is not available.

151

Α

ΔΕ ΙΓ Μ

Figure 6: The INA architecture

• It supports intelligent multiplexing of several sources into a single stream. In case of overloading of the output circuit, enables a selective intelligent traffic shaping at application level. The primary adaptation is audio streams. Different audio codecs are mixed simultaneously (G.711, G.721, etc) in a single audio stream, so that audio can be sent/received at multiple qualities according to available bandwidth without compromising performance of other components. • It supports internal signalling, used to simplify the set-up of virtual ISABEL interconnection network between ISABEL sites. The INA is implemented as a separate process in each host taking part in the conference and in some specialised systems (ISABEL Flow Server) devoted to interconnect heterogeneous networks within a single ISABEL conference. The INA working principle is that the multimedia data generated by a distributed interactive application is short lived: data not delivered in time is better not delivered. A packet that will not be delivered in time can cause the full media flow to stop and resynchronise (insert buffering in the application) and a waste of bandwidth. The packet has been delivered but that application has continued without waiting the packet and will discard it as soon as the packet arrives. It is a bad decision to let the network discard packets. First of all, because different media can collide with each other introducing a lot of uncontrolled jitter. In addition, the network devices will discard traffic without a clue of what they are discarding. INA solves the above problems by trying to keep the network by sorting out packets. This is accomplished by

152

ΔΕ ΙΓ Μ

Α

sorting out attending their priorities and jitter requirements. These packets are then handled through a traffic scheduler which decides which traffic can be sent and when. This decision implies a shaping of the traffic pattern suited for the output link, such that the link is kept busy but the required buffering is (theoretically) void. The traffic schedule decides which packets cannot be delivered within a time limit (the liveness of the information in that packet). Consequently, INA will drop that packet. This packet dropping however is not blindly done as in the network devices along the output path. The very first reason is that the traffic schedule has been done according to each componentselected priorities, timeliness requirements and notion of what is more useful.. The internal architecture of INA is composed of a set of input queues and a set of output queues. Output queues have an associated bandwidth and each type of data traffic manipulated has a relative priority associated. Each multimedia data flow accesses INA by one input queue. All information is delivered there is enough output bandwidth. Otherwise, a intelligent packet discarding mechanism is activated. It’s important to note that typically one unit of information can be distributed across several packets. The lost of one packet makes the rest unusable. This is the case of big documents, images or video frames. If we leave the responsibility of packet elimination to the network devices, we end up with a bunch of unusable packets and only from time to time will be possible to reconstruct a full information unit. With the INA help, the component should specify its clustering structure; which packets are parts of the same semantic unit. The priority in combination with clustering information is taken into account by the INA when generating a packet scheduler, so that the information is discarded in clusters and the whole cluster selection is considered when accepting traffic from the component. Figure 6 shows the actual implementation of the INA, where traffic from the input queues is subject to analysis by the INA and discarded or accepted based on the application selected parameters for media. Some packets, which would be initially discarded, are accepted because of the clustering of packets. The information on which packets have been saved by clustering is continuously used as feedback information for the scheduler, which tries to generate an optimal traffic schedule associated to a network and application constraints. The same figure shows also that the INA includes several schedulers. There is typically a scheduler per link (i.e. one scheduler per ISDN call), although two or more remote sites, which in fact share the link, can share also the scheduler. The INA generates a traffic schedule, which tries to balance the available bandwidth and provide a fair share of the bandwidth between the remote applications. For each media the application defines an access gate over which the media traffic will flow. At a typical user workstation each media within INA will have two gates: One connected to the local application component and the other bound to the network transport layer to send and receive the media data to the rest of sites. In a typical scenario, there is no much difference between the INA set-up or having the components directly using unicast or multicast sockets to send or receive media data.

153

Figure 7: Interconnection architectures: Unicast Mesh and Flow Concentrator

ΔΕ ΙΓ Μ

Α

The full power of our scheme comes to hand when different things are tried. For instance, within a multicast conference a new gate from a workstation connected by a unicast link, can be accommodated. This gate is connected with other gate in the INA remote client workstation (Figure 7). This new user could forward all of its traffic to another user or even to another segment of multicast users. The essential concept is that application components are kept isolated from network issues. We can change from a standard multicast set-up to another using unicast copies if required, to another mixing both in a way completely transparent to the application. ISABEL components always see the same INA as network service. How it performs its work is of no concern to the application. An important functionality associated to INA is the capacity to use it to perform some flow adaptation to lower bandwidth users. A high performance conference in ISABEL typically runs at an aggregated bandwidth of 2 Mb/s (2 active audio sources and several video streams from all participants), or even 6 Mb/s in certain configurations. However, users want to participate in the conference and cannot afford such a high bandwidth (for example a low bandwidth ISDN link). In this case we have an ISABEL Flow Server configured to forward all traffic from the network to some application filters which perform the bandwidth adaptation, and then forward the output from filters to the user(s) with limited bandwidth capabilities. In this way, it is also possible that the user requests the application to send more data than the data channel available. INA is configured to fitter the excess before transmitting to the network. For audio flows, the transformation usually consists in mixing all sources in a single flow and quality degradation from ISABEL standard (16bits, 16 KHz) to more restricted audio format (G711, G723 or GSM). With video, the same type of transformation is not possible. Channel selection, frame resizing and degradation of frame rate are used instead. This way of providing support to lower bandwidth users is aligned with the IETF proposal of application bridges in the RTP specification. 5.5.5

Experiences of use

ISABEL is a multimedia CSCW application, which was created associated to the realisation of

154

ΔΕ ΙΓ Μ

Α

distributed events. Since the first version in 1993, many use experiences have been taken place. The experience and understanding gained during that period show a significant progress and actually there seems to be the opportunity to provide cost effective groupcollaboration services. The first Summer School took place during July 1993. It was supported only by the IBER project experimental network [15], which interconnected the University of Aveiro Auditorium in Aveiro (Portugal) with Telefónica I+D located in Madrid (Spain). It was the first time that two ATM nodes from different countries were interconnected using public and commercial optical links covering the conformance of ATM network relaying on PDH links. The second Summer School took place in July 1994 [16]. This event interconnected six European auditoriums located at Portugal (two sites), Spain (two sites), France and Switzerland. The core of that ATM distributed network was again the IBER project, adding ATM satellite links to reach Basel (Switzerland) and Paris (France). It was the first time that an experiment was made towards the conformance of ATM networks relaying on satellite links testing interworking between terrestrial and satellite environments. The third Summer School ABC’95 took place in June 1995 and was distributed to 14 sites (Figure 8). Since the Pan-European ATM Pilot Network was on from November 1994, we used it to get the necessary international ATM links. The availability of broadband multicast subnetworks is the main limiting element that we have for the set up of distributed events. Events with two sites have some usefulness, but the real impact of distributing events comes from minimising movements of persons. Therefore service platforms must be scalable and support an increasing number of participating sites as in ABC´95. Multicast was the only effective way of sharing the bandwidth. The cost of establishing a full mesh network was unacceptable for more than two sites.

Figure 8: The ABC´95 IP network

155

ΔΕ ΙΓ Μ

multicast network

Α

Figure 9: The ABC´95

The IP network designed to support ISABEL used TCP-UDP/IP and ATM-AAL5 for site interconnection. Gateways to ATM AAL3/4 were used too. Ten sites were interconnected in ABC’95 in a conference with full interaction capabilities (audio, video, etc). Two logical networks over the Pan European ATM Network (PEAN) were established. One of them was a multicast network for multimedia data traffic, whereas the other one was a unicast network for control data traffic. Both of them shared the underlying ATM resources, which were a mesh of PVPs with peak cell rate of 15.6 Kcell/s (6Mbits/s). The node sites of the networks were also the same for both networks: DIT-UPM and ASPA. The multicast network had a tree like structure (Figure 9). Traffic generated from each leave (upstream traffic) travelled to the root (UPM) through zero or more nodes. At each node (or the root), traffic aggregation was performed by a Multicasting WS attached to the local ATM switch. The Multicasting WS was the destination of all incoming PVCs from the leaves (or secondary nodes) attached to its node. The Multicasting WS forwarded all incoming datagrams from the leaves (or secondary nodes) to the PVC that communicated to the superior node (or finally the root). At the root, the Multicasting WS was the destination of all incoming PVCs from nodes (or leaves directly connected to the root). The Multicasting WS forwarded all incoming datagrams to a single output PVC. This PVC was a point to multipoint PVC, within the local ATM switch, that replicated the cells to all outgoing PVCs communicating the root to the next hierarchical nodes in the tree, or leaves directly connected to the root. At each node in the tree, the incoming PVC was connected to a point to multipoint PVC, within the local ATM switch. It replicated the cells to all outgoing PVCs communicating the node to the next hierarchical nodes in the tree, or leaves connected to the node.

156

Α

Figure 10: Multicast upstream and downstream traffic

ΔΕ ΙΓ Μ

When the number of interactive sites is very large, a pure multicast ATM network is not always possible. For example, ABC’96 [17] was of largest events organised with ISABEL with 20 interactive sites connected through terrestrial ATM links and satellite. Additionally five ISABEL watch points received the summer school with the same quality as in the interactive sites. To solve the broadband multicast network a different approach was applied.

Figure 11: The ABC´96 network

157

ΔΕ ΙΓ Μ

Α

To perform multicast at the application level with the help of application routers and by using only unicast communications at the network level is technologically more effective. Specially when the number of copies is very large and expensive international links are involved. WSs are cheaper than ATM switches and can perform copies of application packets with a reasonable efficiency. In ABC´96, multicast nodes with ISABEL Flow Servers made over ten copies successfully. The first trial where heterogeneous networks were connected with the help of the ISABEL Flow Server was Global 360 [11]. Global 360 was a distributed event, held in June 1997, in which sites in Europe and North America participated during 3 days. Global 360 included windows into 4 conferences where professional TV production techniques were used to design the content of the events: Network Interoperability in Madeira (Portugal), Global Networking ‘97 in Calgary (Canada), Broadband for Education & Research in Moscow (Russia), and 21st Century—the Communications Age in Brussels (Belgium) The role of the flow server in Global 360 was the connection of an ATM multicast network at 6 Mbps and a 2 Mbps Satellite connection to Moscow. This first version of the flow server did only QoS by downgrading the video stream.

Figure 12: The Global 360 at IST’98 conference—connecting the world with ISABEL

158

Subsequent events like Global 360 at IST’98 in Vienna have used the flow server in a more heterogeneous way. During IST´98, flow server was used to create event networks with ISDN lines from 256Kbps (4*N) to 512Kbps (8*N), ATM VPs with rates from 1-3Mbps, satellite connections at 2 Mbps and less, and variable QoS connections over the Internet. QoS adaptation factors of up to 8 were achieved, but it seems that higher factors may be possible in the future with more sophisticated algorithms. 5.5.6

Conclusions

ΔΕ ΙΓ Μ

Α

The availability of large broadband infrastructures during the RACE and ACTS programmes enabled the design of large-scale synchronous distributed services. The availability of powerful workstations with low price gives the opportunity to open the new services to the public. There seems to be little doubt that new collaboration technologies will revolutionise our daily activities, not just in our workplaces, but also in our homes, schools and other social areas. ISABEL is a group collaboration application, which was created associated to the realisation of distributed events. The experience and understanding gained during past years shows a significant progress to demonstrate the ability of such kind of services to be a cost effective approach to training in distributed conferences or other educational events. The experience gained shows that management of distributed multi-conferences is a central aspect in distributed event organization. Proper models identifying the roles of each actor at each site have to be developed and clear procedures have to be defined. Future developments in the ISABEL interaction control part are planned for the future. ISABEL was originally designed as a high quality teleconference tool over broadband networks, but the demand forced us to produce versions for more restricted network conditions. Therefore, during the last years a rapid incorporation of more effective video codecs, audio codecs or echo cancellation devices has taken place to allow the interaction from restricted bandwidth sites.

References [1]

[2]

[3]

[4]

[5]

P.Wilson: “Computer Supported Cooperative Work”. Computer Networks and ISDN Systems, pp 91-95, volume 23 1991, North Holland. D. Marca and G. Bock: “Groupware: software for computer-supported cooperative work”. IEEE Press, 1992. L. Lindop, T. Relph-Knight, K. Taylor, A. Eager, G. Einon, K. Joyce, A. Stevens: “Groupware : Let’s work Together”. PC Magazine, August 1995. T.P. de Miguel, S. Pavón, J. Salvachúa, J. Quemada, P.L. Chas, J. Fernandez-Amigo, C. Acuña, L. Rodríguez, V. Lagarto, J. Bastos: “ISABEL—Experimental Distributed Cooperative Work Application over Broadband Networks”, pp. 353-362, SpringerVerlag—Lecture Notes in Computer Science, Volume 868, September 1994. A. Azcorra, T.P. de Miguel, M. Petit, L. Rodríguez, C. Acuña, P.L. Chas, V. Lagarto, J.

159

[7] [8]

[9] [10] [11]

ΔΕ ΙΓ Μ

[12]

Α

[6]

Bastos: “Multicast IP support for distributed conferencing over ATM”. Networld+Interop 95, pp. 9, March 1995. Las Vegas (USA). J. Nunamaker: “Collaborative Computing: The next milennium”. IEEE Computer, Vol. 32, n. 9, pp. 66-71, September 1999. F. Fluckiger, “Understanding Networked Multimedia”, Prentice Hall, 1995. J. Quemada, T.P. Miguel, A. Azcorra, S. Pavón, J. Salvachúa, M. Petit, J. I. Moreno, P. L. Chas, C. Acuña, L. Rodríguez, V. Lagarto, J. Bastos, J. Fontes, J. Domingues: “Teleeducation Experiences with the ISABEL Application”, High Performance Networking for Tele-teaching—IDC’95, Madeira November 1995. The TECODIS Project home page: http://www.dit.upm.es/~tecodis ISABEL Application home page: http://isabel.dit.upm.es/ J. Quemada, T.P. de Miguel A. Azcorra, S. Pavón, J. Salvachúa, M. Petit, D. Larrabeiti, T. Robles, G. Huecas, D. Rodríguez, F. Echevarrieta, E. Castro: “Teleservice creation with ISABEL in heterogeneous network environments”, Interoperability of Networks for Interoperable Services, ISSN 1385 9501, Ottawa, July 1998. J. Quemada, T.P. de Miguel, A. Azcorra, S. Pavón, J. Salvachúa, M. Petit, D. Larrabeiti T. Robles, G. Huecas: ISABEL: “A CSCW application for the distribution of events. Multimedia Telecommunications and Applications”, Ed: G. Ventre, J. Domingo, A. Danthine. Springer-Verlag,—LNCS 1185, ISSN 0302-9743, 1996. M. Petit, T.P. de Miguel: Distribution of Multimedia Information Experiences over Broadband Networks. EUNICE ‘96 Summer School, Lausane, September 1996 M. Petit, T.P. de Miguel: Flexible Support for Advanced CSCW Conferences: the ISABEL irouter. PROMS’96: Protocols for Multimedia Systems, Madrid, October 1996. S. Pavón, T.P. de Miguel, M. Petit, J. Salvachúa, J. Quemada, L. Rodríguez, P.L. Chas, C. Acuna, V. Lagarto, J. Bastos: “Integracion de Componentes en la Aplicacion de Trabajo Cooperativo ISABEL”, Jornadas Telecom 94, Noviembre, 1994. A. Azcorra, T. Miguel, J. Quemada, S. Pavón, P. Chas, C. Acuña, P. Aranda, V. Lagarto, J. Bastos, J. Domingues: “Distance Learning: Networks and Applications for RACE Summer School ’94”, Centro de Etudos de Telecomunicacoes, The ATM Forum Newsletter September, 1994—Volume 2 Issue 3. D. Larrabeiti, M.C. Agúndez, A. Azcorra, C. García, J. Quemada, T.P. de Miguel, M. Petit: “Towards the integrated configuration and management of multicast teleconferences based on IP over ATM”, HP Openview University Association Workshop, Madrid, April 1997.

[13]

[14]

[15]

[16]

[17]

160

6 New IST Projects Related to NGN Paulo de Sousa European Commission

6.1

The Fifth Framework Programme

ΔΕ ΙΓ Μ

Α

The period of the fourth Framework Programme (1994-1998) has seen a rapid convergence of technologies, industries and markets in related economic sectors, setting the stage for the emergence of an Information Society. The EU is now starting the IST (Information Society Technologies) Programme as one of the major specific research activities in the fifth Framework Programme, involving 3.6 billion Euro of EU contribution over four years. Technologies for—and the management of—information processing, communications and networks, together with their implementation, interoperability and application is a key development area within IST. The Action Line IV.2.3 (Network integration, interoperability and interworking) has the specific objective of developing the next generation network technologies (including switches, routers, modems and access devices), with the associated protocols and signalling mechanisms, in order to enable integration at the transport level of multiple heterogeneous networks. The scope includes component and system interoperability. Another goal is to develop new service-independent architectures and systems to ensure all users have affordable access to nomadic multimedia services, and that service providers can easily incorporate new resources and users. Networks that will be considered are those that support advanced generic services with end-to-end QoS, running over fibre, copper cable, radio, powerlines and broadcast channels. The work will ensure the interworking of core networks with local networks (mobile and fixed) and interoperability across the Internet, wide area, metropolitan area, local area and home networks.

161

6.2

Emerging IST Projects

Details on some of the new proposed IST projects resulting from the first IST call (June 1999) are presented here. 6.2.1

Value-added Integrated Service Delivery

ΔΕ ΙΓ Μ

Α

CADENUS. The main goal of the project is to develop, implement, validate and demonstrate a framework for the configuration and provisioning of end-user services with QoS guarantees in Premium IP networks. Will make inter-domain trials and will incorporate charging and accounting aspects. TEQUILA. Traffic engineering for QoS Internet, for large scale networks, based on a generic end-to-end QoS architecture. The project intends to study, specify, implement and validate a set of service definition and traffic engineering tools to obtain quantitative end-to-end Quality of Service guarantees through adequate planning, dimensioning and dynamic control of scaleable and simple qualitative traffic management techniques within the Internet, considering the DiffServ approach. AQUILA. AQUILA intends to define, implement and evaluate a new enhanced architecture for Quality of Service provisioning over IP networks. For that, it will use as basis existing approaches to QoS specified for the Internet (Differentiated Services), and it will enhance it with dynamic resource and admission control. The architecture will be tested in user trials of QoS-supported multimedia services. The project addresses a broad coverage of QoS in IP-based networks attacking most relevant issues including measurements, charging, and business plans. GCAP. GCAP’s goal is to develop new transport architecture and protocols that would provide guaranteed QoS to advanced multimedia applications in heterogeneous networks (IPv4/IPv6, IP/ATM, native ATM-satellite, all optical networks). The approach will be based on IP version 6 and active networks, and will follow the work in IETF. It will allow a rapid deployment of new services built upon IPv6 technology. 6INIT. IPv6 project with IPv4 interworking. Small size project using off the shelf components. Will collaborate with Canarie, NTT and Quantum for networking. The objective of this proposal is to prove the business case for EURO-IPv6 by setting up an European network to offer a production native IPv6 Internet service. VoIP and video Broadcasting would be two of the applications.

162

6.2.2

Protocol Extensions

Conventional and Integrated Services Networks Integration

ΔΕ ΙΓ Μ

6.2.3

Α

WINE. Development of an end-to-end TCP protocol for wireless applications. It has the potential for simplifying the use of IP over wireless LANs and in the future mobile networks. GEOCAST. GEOCAST intends to develop interoperability protocols that will enable the successful integration of the satellite into the (mainly terrestrial) Global Information Infrastructure. The approach is to extend the inherent satellite broadcast capabilities traditionally applied to TV into Internet multicast services. The result will be Internet with multicast, (today only unicast is widely available in the Internet) and a new use for geostationary satellites. It addresses a novel technique to implement multicast facilities for satellites using multibeam technology seamlessly integrated with terrestrial multicast services. BRAHMS. IP over satellite, for speeds over 20 Mbit/s. Will include real time IP applications. Mainly based on GEO satellites, with additional use of LEO. Direct IP over satellite is preferred, but ATM may be a possibility.

NETGATE. Development of a gateway to permit network interoperation for different types of data including Voice over IP. It will address both wireless and terrestrial networks. It should facilitate efficient implementation of such devices as GPRS support modules and enhanced Voice over IP gatekeeper. VIDEOGATEWAY. The main goal of the proposal is for a system that functions as a gateway between the next generation Internet streaming video standards and the narrow band Internet with its own video streaming standards. It provides a good solution for delivering MPEG video over low and medium speed IP networks, which is an important issue to be solved for the widespread broadcast of video in the Internet. 6.2.4

Local Access

e-HOME. Development of a Universal gateway between public access networks and private in-home networks for communication services and intelligent home automation. This is an important topic with a user-centric perspective. INHOMNET. Development of services and applications for multimedia in-home networks, based on IEEE-1394 backbone. BASS. Definition and implementation of “dial-up broadband networking” concept, with call based choice of broadband services and Quality of Service.

163

6.3

The Challenge for Industry

ΔΕ ΙΓ Μ

Α

The convergence of communications, networking and broadcasting, will present major new challenges for industry and for the IST Programme—notably because key aspects of the Internet evolution are currently determined from outside Europe, and Internet developments compete in all areas: from telephony to broadcasting. Successful companies need to stay ahead of and lead developments by their speed of realisation. In addition, there may be the need to form or join alliances and to collaborate in standardisation activities. The key challenge for the Programme is how to engage new players, with no tradition of co-operation and often no established RTD strategy or infrastructure: examples are cable TV companies; electricity power supply companies; water companies; direct satellite broadcasters, Internet service providers, new “web-casters”, and major retail/mail order groups. The second challenge is to find the right balance for the collaboration to be successful: to avoid the potentially conflicting situation, in which the more organisations are involved in a collective initiative, the slower is the progress. A sufficient commitment of major players must be achieved, but with a minimum “dead weight” of unnecessary participants and institutional constraint. Recent MoU initiatives have sought this balance with various degrees of success: DVB, DAVIC, ATMF, UMTS, NMF, OMG, and the Open Access to Electronic Commerce. Finally, the challenge of the speed of change needs to be handled. The pace of development in information processing will remain as fast as in the 1990s, but it is already being exceeded by the pace of development in communications capacity. However, while most companies can afford to renew their computers and software every 3-5 years, network operators will not be ready to renew their physical infrastructures at this frequency in the foreseeable future. Interoperability between systems must therefore be complemented with interoperability over time—between past, present and future infrastructures. Backward and forward compatibility is an essential protection for everyone’s investment, and requires continuity and long-term strategic visions.

DISCLAIMER: The views expressed in this paper are those of the author and do not necessarily reflect the views of the European Commission.

164

7 Appendices Alphabetical List of Contributors Company/Institution DSC Communications, Denmark University of Surrey, UK National Technical Univ. of Athens, Greece DANTE, UK Universidad Carlos III de Madrid, Spain Telefónica I+D, Spain Catholic University of Brasilia, Brazil INESC, Portugal Technical University of Madrid, Spain ICS FORTH, Greece University of Pisa, Italy CoRiTeL, Italy T-Nova, Germany TU Dresden, Germany AlgoSystems, Greece NEC, Germany Technical University of Madrid, Spain Technical University of Madrid, Spain TU Dresden, Germany Siemens, Germany Thomson-Detexis, France IPv6 Forum National Technical Univ. of Athens, Greece National Technical Univ. of Athens, Greece GMD FOKUS, Germany Technical University of Madrid, Spain National Technical Univ. of Athens, Greece Teltec, Ireland Alcatel Bell, Belgium National Technical Univ. of Athens, Greece IPv6 Forum Technical University of Madrid, Spain National Technical Univ. of Athens, Greece

ΔΕ ΙΓ Μ

Name Niels Andersen Illias Andrikopoulos John D. Angelopoulos Jose Manuel de Arce Arturo Azcorra M.A. Barba Cláudia J. Barenco Augusto Casaca Eva Castro Magda Chatzaki N. Ciulli. R. Cocca G. Eichler F. Fünfstück Panos Georgatsos Frederic Griffoul Sidnei O. Guerra Gabriel Huecas H. Hußmann Bert F. Koch Wladimir Ksinant Latif Ladid N. Leligou G. Mamais Mihai Mateescu Tomás P. de Miguel Nikos A. Nikolaou Kevin O’Leary Dirk Ooms Th. Orphanoudakis Jordi Palet Santiago Pavón G. Pikrammenos

Α

7.1

165

Α

National Technical Univ. of Athens, Greece Martel GmbH, Switzerland Siemens, Germany Technical University of Madrid, Spain Italtel, Italy Technical University of Madrid, Spain NEC Europe, Germany DANTE, UK CoRiTeL, Italy Technical University of Madrid, Spain NEC, Germany GMD FOKUS, Germany European Commission National Technical Univ. of Athens, Greece NEC Europe, Germany TU Budapest, Hungary Technical University of Madrid, Spain National Technical Univ. of Athens, Greece IMEC, Belgium

ΔΕ ΙΓ Μ

G. Politis Martin Potts C. Prehofer Juan Quemada Giancarlo Rigolio Tomás Robles Jürgen Röthig Roberto Sabatino S. Salsano Joaquin Salvachúa Sibylle Schaller Mikhail Smirnow Paulo de Sousa G. Stassinopoulos Heinrich J. Stüttgen T. Van Do Héctor Velayos I.S. Venieris Mike Vogeleer

166

Details of ACTS Projects in the IP/ATM Cluster

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/

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.coritel.it/projects/elisa/

ΔΕ ΙΓ Μ

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

DIANA (AC319) Martin Potts Martel GmbH Berner Technopark Morgenstrasse 129 CH-3018 Bern Switzerland phone: +41 31 994 25 25 fax: +41 31 994 25 29 email: [email protected] http://www.telscom.ch/diana/

Α

7.2

COIAS (AC363) Vladimir Ksinant Thomson-CSF Detexis 1, bld Jean Moulin F-78852 Elancourt Cedex France phone: +33 1 34 59 77 50 fax: +33 1 34 59 56 47 email: vladimir.ksinant @detexis.thomson-csf.com http://www.cs.ucl.ac.uk/research/coias/

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] http://www.algo.com.gr/acts/ithaci/

167

SUSIE (AC320) Kevin O’Leary Teltec Ireland Dublin City University Glasnevin Dublin 9 Ireland phone: +353 1 7045029 fax +353 1 7045092 email: [email protected] http://www.teltec.dcu.ie/susie/

ΔΕ ΙΓ Μ

Α

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://peterpan.lancs.ac.uk/peterpan/

168

ATM Adaptation Layer Available Bit Rate Allowed Cell Rate Admission Control Server Asymmetric Digital Subscriber Line AESA ATM End System Address AF Assured Forwarding AFI Authority and Format Identifier AINI ATM Inter-Network Interface ANSI American National Standards Institute API Application Program Interface ARIS Aggregate Router-based IP Switching ARP Address Resolution Protocol ASM ATM Service Managers ATD Asynchronous Time Division ATM Asynchronous Transfer Mode ATMARP ATM Address Resolution Protocol ATMF ATM Forum ATR Automatic TSpec Retrieval B-ICI Broadband Inter Carrier Interface B-ISDN Broadband ISDN B-ISUP Broadband ISUP B-NT1 Broadband Network Termination 1 B-NT2 Broadband Network Termination 2 B-TA Broadband Terminal Adaptor B-TE Broadband Terminal Equipment BCDS Broadband Connectionless Data Service BE Best Effort BECN Backward Explicit Congestion Notification BGP Border Gateway Protocol BLLI Broadband Low Layer Information BOM Beginning of Message BT Burst Tolerance

BUS CAC CAS CATV CBDS CBR CCS CDR CDV CDVT CER CES CI CIDR CIF CIR CL CLIP CLLM

Broadcast and Unknown Server Connection Admission Control Channel Associated Signalling Cable Television Connectionless Broadband Data Service Constant Bit Rate Common Channel Signalling Connection Detail Record Cell Delay Variation Cell Delay Variation Tolerance Cell Error Ratio Circuit Emulation Service Congestion Indication Classless Inter-Domain Routing Common Intermediate Format Committed Information Rate Connectionless CLassical IP over ATM Consolidated Link Layer Management Connectionless Network Access Protocol Connectionless Network Service Connectionless Overlay Network Cell Loss Priority Cell Loss Ratio Connectionless Server Function Cell Misinsertion Ratio Customer Network Connection Oriented Continuation of Message Common Object Request Broker Architecture Common Part Convergence Sublayer Customer Premises Equipment Customer Premises Network

ΔΕ ΙΓ Μ

AAL ABR ACR ACS ADSL

List of Acronyms

Α

7.3

CLNAP

CLNS CLON CLP CLR CLSF CMR CN CO COM CORBA CPCS CPE CPN

169

DAVIC DBCES DBR DCC DFFG

Indication Edge Device Expedited Forwarding Explicit Forward Congestion Indication EGP Exterior Gateway Protocol ELAN Emulated LAN enCoS explicit network Class of Service EOM End of Message EPD Early Packet Discard ERM Explicit Rate Marking ES End System ESI End System Identifier ESP Encapsulating Security Payload ET Exchange Terminator ETSI European Telecommunication Standards Institute EURESCOM European Institute for Research and Strategic Studies in Telecommunications FBR Fixed Bit Rate FCS Frame Check Sequence FDDI Fiber Distributed Data Interface FEC Forward Error Correction FECN Forward Explicit Congestion Notification FR Frame Relay FRAD Frame Relay Assembler Disassembler FRM Fast Resource Management FTP File Transfer Protocol FUNI Frame UNI GCRA Generic Cell Rate Algorithm GFC Generic Flow Control GFR Guaranteed Frame Rate GIBN Global Interoperability in Broadband Networks GMDP Generally Modulated Deterministic Process GNM Group Network Manager ED EF EFCI

ΔΕ ΙΓ Μ

DFI DHC DHCP

Cyclic Redundancy Code Convergence Sublayer Cell Switch Router Cell Transfer Delay Closed User Group Class of Service Delivery of Advanced Network Technology to Europe Digital Audio-visual Council Dynamic Bandwidth CES Deterministic Bit Rate Data Country Code Default Forwarder Functional Group DSP Format Identifier Dynamic Host Configuration Dynamic Host Configuration Protocol Data Link Control Identifier Dense Mode Domain Name System Distributed Queue Dual Bus Differentiated Services Digital Signal Level n Differentiated Services Code Point Digital Subscriber Line Domain Specific Part Digital Subscriber Signalling System Designated Transit List Dynamic Synchronous Transfer Mode Digital Video Broadcast Distance Vector Multicast Routing Protocol Dense Wave-Division Multiplexing Digital Cross-Connect Data eXchange Interface Differentiated Services Explicit Backward Congestion

Α

CRC CS CSR CTD CUG CoS DANTE

DLCI DM DNS DQDB DS DS-n DSCP DSL DSP DSS DTL DTM

DVB DVMRP

DWDM DXC DXI DiffServ EBCI

170

GUI HCD HEC HED HFC HP IASG ICD ICFG

IS IS ISCP ISDN ISO ISOC ISP ISUP ITU ITU-T IWU InARP IntServ L-NNI

Intermediate System International Standard ISDN Signalling Control Part Integrated Services Digital Network International Standards Organization Internet Society Internet Service Provider Integrated Services User Part International Telecommunication Union ITU - Telecommunication Standardization Sector Interworking Unit Inverse ARP Integrated Services LAN Emulation Network-Node Interface LAN Emulation User Network Interface Local Address Group Local Area Network Local Area Network Emulation Link Access Procedure Label-Switch Controlled ATM Label Distribution Protocol LAN Emulation LAN Emulation Client LAN Emulation Configuration Server LAN Emulation Server LAN Emulation ARP Label Information Base Logical IP Subnetwork Logical Link Control Local Management Interface Label Switched Paths Line Terminator Medium Access Control

ΔΕ ΙΓ Μ

ICMP ICR IDI IDRP IDU IEEE

General Switch Management Protocol Graphical User Interface Hybrid Core Device Header Error Control Hybrid Edge Device Hybrid Fiber Coaxial High Priority Inter Address Sub-Group International Code Designator IASG Coordination Functional Group Internet Control Message Protocol Initial Cell Rate Initial Domain Identifier InterDomain Routing Protocol Interface Data Unit Institute of Electrical and Electronic Engineers Internet Engineering Steering Group Internet Engineering Task Force Ipsilon Flow Management Protocol Internet Group Management Protocol Interior Gateway Protocol Internet Header Length Interim Inter-Switch Signalling Protocol Interim Local Management Interface Inverse Muxltiplexing for ATM Interactive Multimedia Retrieval IP over NBMA Internet Protocol Integrated PNNI Internetwork Packet eXchange IP next generation IP version 4 IP version 6

Α

GSMP

IESG

IETF IFMP IGMP IGP IHL IISP

ILMI

IMA IMR ION IP IPNNI IPX IPng IPv4 IPv6

L-UNI

LAG LAN LANE LAP LCATM LDP LE LEC LECS LES LEARP LIB LIS LLC LMI LSP LT MAC

171

MBS MBS MCR MFC MFS MIB MID

PCR PDH PDU PHB PIM PM PMD PNNI PNO POH PON POTS PPD PPP PRS PSTN

Peak Cell Rate Plesiochronous Digital Hierarchy Protocol Data Unit Per Hop Behaviour Protocol Independent Multicast Physical Media Physical Media Dependent Private NNI Public Network Operator Path OverHead Passive Optical Networks Plain Old Telephone System Partial Packet Discard Point-to-Point Protocol Primary Reference Source Public Switched Telephone Network PT Payload Type PVC Permanent Virtual Circuit PoP Point of Presence QTP Quantum Test Programme QoS Quality of Service Quantum Quality Network Technology for User-Oriented Multimedia RARP Reverse ARP RD Routing Domain RDF Rate Decrease Factor RED Random Early Detection RESV Reservation RFC Request For Comments RFFG Remote Forwarder Functional Group RIF Rate Increase Factor RIP Routing Information Protocol RM Resource Management RMM RSVP Management Module RSFG Route Server Functional Group RSIP Realm-Specific IP RSOH Regenerator Section OverHead RSpec Reserve Specification

ΔΕ ΙΓ Μ

MPC MPEG MPLS MPOA MPS MSF MSN MSOH MTP MTU N-ISDN NAT NBMA NHC NHRP NHS NIC NNI NRN NSAP OAM ONU OS OSI OSPF PNNI

Metropolitan Area Network Mobile Application Part Multicast Address Resolution Server Managed Bandwidth Service Maximum Burst Size Minimum Cell Rate Multicast Forwarding Cache Maximum Frame Size Management Information Base Multiplexing Identifier / Message Identifier MPOA Client Moving Pictures Experts Group Multiprotocol Label Switching Multi Protocol Over ATM MPOA Server Multicast Server Function Multiple Subscriber Number Multiplex Section OverHead Message Transfer Part Maximum Transfer Unit Narrowband ISDN Network Address Translation Non-Broadcast Multiple-Access Next Hop Clients Next Hop Resolution Protocol Next Hop Server Network Interface Card Network-Node Interface National Research Network Network Service Access Point Operation and Maintenance Optical Network Unit Operating System Open Systems Interconnection Open Shortest Path First Private Network-to-Network Interface PNNI Augmented Routing

Α

MAN MAP MARS

PAR

172

SVC SVC TA TAXI TC TCAP TCP TDMA TDP TE TEI TEN TERENA

Level n Signalling VC Switched VC Terminal Adaptor Transparent Asynchronous Transmission Reception Interface Transmission Convergence Transaction Capabilities Application Part Transmission Control Protocol Time Division Multiple Access Tag Distribution Protocol Terminal Equipment Terminal Equipment Identifier Trans-European Network Trans-European Research and Education Networking Association Task Force Tag Information Base Telecommunications Information Networking Architecture Top Level Aggregator Type Of Service Terminal Portability Traffic Specification Tributary Unit Tributary Unit Group Telephone User Part Unspecified Bit Rate Uni-Directional Link Routing User Datagram Protocol Unstructured Data Transfer Unified Modelling Language User-Network Interface Usage Parameter Control very High Speed Backbone Network Service Variable Bit Rate VBR Non-Real Time VBR Real Time

Α

Resource reSerVation Protocol Real Time Control Protocol Real Time Transport Protocol Signalling ATM Adaptation Layer Service Access Point Service Access Point Identifier Segmentation and Reassembly Statistical Bit Rate Signalling Connection Control Part Sustained Cell Rate Synchronous Digital Hierarchy Session Description Protocol Structured Data Transfer Service Data Unit Severely Errored Cell Block Ratio Simple Integrated Media Access Session Initiation Protocol SMDS Interface Protocol Switching IP Through ATM Service Level Agreement Sparse Mode Switched Multimegabit Data Service Sub Network Access Point Simple Network Management Protocol Synchronous Optical Network Scalable Reservation Protocol Synchronous Residual Time Stamp Signalling System number 7 Service Specific Coordination Function Service Specific Connection Oriented Protocol Service Specific Convergence Sublayer Single-Segment Message Synchronous Time Division Synchronous Transfer Mode Synchronous Transport Module

ΔΕ ΙΓ Μ

RSVP RTCP RTP SAAL SAP SAPI SAR SBR SCCP SCR SDH SDP SDT SDU SECBR SIMA SIP SIP SITA SLA SM SMDS SNAP SNMP

SONET SRP SRTS SS7 SSCF SSCOP SSCS

SSM STD STM STM-n

TF TIB TINA

TLA TOS TP TSpec TU-n TUG-n TUP UBR UDLR UDP UDT UML UNI UPC vBNS

VBR VBR-nrt VBR-rt

173

Α

Virtual Channel Virtual Connection Virtual Container Virtual Channel Connection Virtual Channel Identifier Virtual Destination Virtual LAN Virtual Leased Line Virtual Path Virtual Path Connection Virtual Path Identifier Virtual Private Network Virtual Source Video Telephone Voice and Telephony over ATM Video on Demand Voice over IP Wide Area Network Wavelength Division Multiplexing Weighted Fair Queuing Working Group

ΔΕ ΙΓ Μ

VC VC VC-n VCC VCI VD VLAN VLL VP VPC VPI VPN VS VT VTOA VoD VoIP WAN WDM WFQ WG

174

175

ΔΕ ΙΓ Μ Α

176

ΔΕ ΙΓ Μ Α